The new Xajax is out, and the new Xajax is cool!

I started working on a recode of the Xajax library a few weeks ago, and today, I am pleased to present you with the new Xajax library.
The main goal was to use the latest PHP features to make the Xajax library extensible and modular.

So what is it about?

The new Xajax is modular and extensible

The library is now separated into two main packages.

The first package is the core PHP library
It provides the main Xajax class, which is now named Xajax, and implements the functionalities needed to export PHP classes to javascript, and handle the Xajax requests and responses.

The second package contains the javascript files of the library
Having a javascript only package will later allow to use an open source CDN like or to deliver the files. By default, the Xajax core library gets the files from a server of mine, which offers HTTP and HTTPS access (thanks to Let’s Encrypt). Of course, they can also be installed on a private server.

This two packages are the minimum requirement to create an Xajax application, however the library can be extended with additional plugins.
I have created three plugins, which are used in the sample codes in the xajax-examples package
this package implements javascript notifications with the Toastr JQuery plugin
this package implements responsive modal dialog with the PgwModal library
this package implements modal dialog with the Twitter Bootstrap library. It requires to manually load the Twitter Bootstrap javascript and CSS files to work properly.

What’s new is this package

First of all, the package is namespaced, uses PSR-4 autoloading, and installs with Composer.
Some features are deprecated, some others, like javascript code generation (see the examples below) are recoded, and some new features are added.

The new feature I consider the most important is the ability to automatically register all the classes in one or more directories, each directory being associated to a namespace or not.
When exporting PHP classes from a directory, the generated javascript classes are named accordingly. In a directory D, the class A in the file D/S/A.php will generate the javascript class S.A, and if the associated namespace is N, the generated javascript class will be N.S.A. As we’ll see in the examples below, the new Xajax library also takes advantage of PHP autoloading to optimize request processing.
This feature makes the Xajax library more suitable for use in modular applications with hundreds of classes.


Samples code demonstrating the use of the new Xajax library are provided in the xajax-examples package: All examples are based on the helloword.php example in the original Xajax repository The installation process is described in the homepage of the repository. After the examples are installed, enter the name of any file in the browser to see the result.

– hello.php
This example shows how to export a function with Xajax.

– class.php
This example shows how to export a class with Xajax.

– merge.php
This example shows how to export the generated javascript code in an external file, which is then loaded into the webpage.
You’ll need to create the « deferred » directory, and adapt the parameter of the mergeJavascript() function to your webserver configuration for this example to work.
The compression of the generated javascript code is not yet implemented.

– plugins.php
The example shows the use of Xajax plugins, by adding javascript notifications and modal windows to the class.php example with the xajax-toastr, xajax-pgwjs and xajax-bootstrap packages.
Using an Xajax plugin is very simple. After a plugin is installed with Composer, its automatically registers into the Xajax core library. It can then be accessed both in the Xajax main object, for configuration, and in the Xajax response object, to provide additional functionalities to the application.

– classdirs.php
This example shows how to automatically register all the PHP classes in a set of directories.
The classes in this example are not namespaced, thus they all need to have different names, even if they are in different subdirs.

– namespaces.php
This example shows how to automatically register all the classes in a set of directories with namespaces.
The namespace is prepended to the generated javascript class names, and PHP classes in different subdirs can have the same name.

– autoload-default.php
This example shows how to optimize Xajax requests processing with autoloading.
In all the examples above, an instance of all exported Xajax classes is created when processing a request, while only an instance of the requested class is needed. In an application with a high number of classes, this can cause performance issues.
In this example, the Xajax classes are not registered when processing a request. However, the Xajax library is smart enough to detect that the required class is missing, and load only the necessary file.

– autoload-composer.php
This example illustrates the use of the Composer autoloader.
By default, the Xajax library implements a simple autoloading mechanism by require_once’ing the corresponding PHP file for each missing class. When provided with the Composer autoloader, the Xajax library registers all directories with a namespace into the PSR-4 autoloader, and it registers all the classes in directories with no namespace into the classmap autoloader.

– autoload-disabled.php
In this example the autoloading is disabled in the Xajax library.
The developer then needs to provides its own autoloading, otherwise the Xajax library will raise an error at any attempt to register classes from a directory.
This example will not work until the autoloading is setup.

What’s next?

This version of the package is still an early alpha release, not yet suitable for use in production.
There is still much work to do, and in my point of view the most important ones are:
– Check security, mainly for input data.
– Write tests.
– Write documentation and tutorials.

All ideas, all comments and any help are welcome.
The plugin interface is quite stable now, so anyone willing to write a plugin is encouraged to do so.


Comment lire l’adresse MAC d’un conteneur OpenVZ dans Proxmox

Supposons qu’on soit en train d’automatiser la création et la configuration d’un conteneur dans Proxmox, dans lequel il faut configurer une interface réseau virtuelle (veth). On peut avoir besoin de récupérer l’adresse MAC virtuelle de l’interface réseau du conteneur, par exemple pour y créer un fichier ifcfg-eth0 s’il est sous CentOS.

Le script ci-dessous s’exécute sur un noeud Proxmox et permet de lire l’adresse MAC d’une carte réseau virtuelle dans un conteneur OpenVZ. Pour des raisons de simplicité, les vérifications sur la présence des paramètres sont supprimées.


# Le nom du noeud Proxmox à interroger
# L'id du conteneur OpenVZ, par exemple 101
# L'interface réseau, par exemple eth0
pvesh get /nodes/${NODE}/openvz/${VMID}/config 2>/dev/null | grep netif | \
	sed -re "s/.*ifname\=${IFNAME}[^;]*\,mac\=(([0-9A-F]{2}:){5}[0-9A-F]{2}).*/\1/"

Maintenant voyons dans le détail ce que fait ce script.

D’abord, il y a la commande

pvesh get /nodes/${NODE}/openvz/${VMID}/config

qui affiche la configuration d’un conteneur sur un noeud Proxmox.

Le résultat ressemble à ceci pour un conteneur qui a une interface réseau eth0.

   "cpus" : 1,
   "cpuunits" : 1000,
   "digest" : "c90",
   "disk" : 50,
   "hostname" : "www.domainname.tld",
   "memory" : 1024,
   "nameserver" : "",
   "netif" : "ifname=eth0,bridge=vmbr0,mac=C6:BD:74:7D:FF:81,host_ifname=veth105.0,host_mac=D2:83:D5:54:01:69",
   "onboot" : 0,
   "ostemplate" : "centos.tar.gz",
   "quotatime" : 0,
   "quotaugidlimit" : 0,
   "searchdomain" : "domainname.tld",
   "storage" : "local",
   "swap" : 512

Ou à ceci pour un conteneur qui a deux interfaces réseau eth0 et eth1.

   "cpus" : 1,
   "cpuunits" : 1000,
   "digest" : "c90",
   "disk" : 50,
   "hostname" : "www.domainname.tld",
   "memory" : 1024,
   "nameserver" : "",
   "netif" : "ifname=eth0,bridge=vmbr0,mac=C6:BD:74:7D:FF:81,host_ifname=veth105.0,host_mac=D2:83:D5:54:01:69;ifname=eth1,bridge=vmbr1,mac=92:C5:0C:F2:BE:25,host_ifname=veth100.1,host_mac=4A:99:39:23:FB:CC",
   "onboot" : 0,
   "ostemplate" : "centos.tar.gz",
   "quotatime" : 0,
   "quotaugidlimit" : 0,
   "searchdomain" : "domainname.tld",
   "storage" : "local",
   "swap" : 512

La commande grep netif filtre ce texte pour ne retenir que la ligne qui contient les informations sur les interfaces réseau, et enfin la commande sed -re utilise une expression régulière pour extraire dans cette ligne l’adresse MAC recherchée.

Un mot sur l’expression régulière


Le s qui la commence indique qu’on souhaite faire une substitution. On parcourt la ligne jusqu’à trouver la chaîne ifname=, suivie de notre interface. A partir de là, on saute tous les caractères jusqu’à trouver la chaîne ,mac=, suivie d’une adresse MAC que matche l’expression régulière ([0-9A-F]{2}:){5}[0-9A-F]{2}.

Il y’a deux remarques à faire à ce niveau. D’abord, il faut noter la présence de la virgule dans la chaîne ,mac=, qui est importante pour ne pas récupérer le paramètre host_mac à la place. Ensuite, les caractères qu’on saute entre le ifname= et le ,mac= doivent absolument être différents du point-virgule, car sinon à cause de la règle du longuest prefix match on récupère systématiquement la dernière adresse MAC présente dans la ligne, qui sera la mauvaise s’il y’en a plusieurs. D’où l’usage de l’expression [^;]*.

Pour que la commande sed renvoie uniquement l’adresse MAC, on utilise en plus de la substitution, une référence arrière. On demande à sed de mémoriser l’adresse MAC en mettant son expression régulière entre parenthèses, puis on fait en sorte que la ligne entière matche l’expression régulière en ajoutant un .* en début et en fin. Le /\1/ substitue la chaîne matchée par la première référence trouvée, et renvoie donc uniquement l’adresse MAC de l’interface réseau de notre conteneur.


Coming soon: Maelys on Ubuntu

J’ai le plaisir d’annoncer la sortie prochaine de Maelys on Ubuntu (en abrégé MoU). MoU est un pack qui comprend le logiciel Maelys, son extension Doomedo, le tout dans un Linux Ubuntu préconfiguré avec quelques outils, dont un serveur web et un firewall. Il est disponible sous la forme d’un live CD installable, et d’une machine virtuelle. Dans la grande famille des Ubuntu-based OS, XUbuntu a été choisi pour sa légèreté.



L’objectif de MoU est de permettre aux cybercafés qui veulent tester la solution Maelys de le faire sans avoir à réaliser une installation complète, soit en démarrant une machine physique sur le live CD, soit en exécutant la machine virtuelle. Ceux qui veulent adopter la solution pourront par la suite installer définitivement MoU sur leur machine, et dans le cas où ils désirent conserver Windows, ils peuvent continuer à utiliser la machine virtuelle.

MoU est la solution que nous apportons à un problème récurrent, celui de l’adoption de Linux par les utilisateurs, qui ont généralement cette crainte, somme toute légitime, de l’inconnu. MoU doit leur montrer que Linux c’est facile à utiliser, et qu’il est possible de le personnaliser à sa guise.

Pour terminer, j’aimerais donner un grand coup de chapeau à Julius qui a assuré la réalisation technique de cet outil. Merci champion!

Maelys and Doomedo: what next?

Comme je le faisais remarquer dans le post précédent, il me semble que le moment est venu pour Maelys, surtout avec l’arrivée de Doomedo, de faire le bilan et de poser les bases pour passer une nouvelle étape. L’objectif étant de gérer tout le bazar de façon plus professionnelle, et aussi d’élargir les retombées des développements au délà de la simple satisfaction de faire un produit techniquement au point.

Avant d’aller plus loin, je voudrais revenir brièvement sur l’historique de Maelys. Au départ, en 2000-2001, il s’agit d’un défi technique d’un jeune diplômé qui veut comprendre, par la pratique, le cycle complet de développement d’un logiciel, de sa conception à sa distribution. Ensuite, lorsque les premiers utilisateurs commencent à faire des feedbacks, 2005-2006, l’aspect fonctionnel a pris le dessus. L’objectif est alors de faire un logiciel simple à installer et à utiliser, et qui s’adapte à des utilisateurs dont les besoins peuvent varier. Cet objectif a donné lieu à des choix tels que la transformation du module d’administration en application web, ou l’ajout d’un système d’extensions qui permet d’ajouter des fonctionnalités « à la carte ». À partir de fin 2008 enfin, il y a eu la dernière phase où l’objectif est de générer des revenus, même sans être forcément rentable (ce qui sera probablement l’objectif de la prochaine phase), avec notamment le service Doomedo.

Suite à ça donc, je me dis que Maelys, après avoir atteint une certaine maturité technique, doit maintenant s’attaquer à une nouvelle étape. Pour ça, il y a deux aspects sur lesquels je sais qu’il va falloir que je prenne des décisions, et je ne sais pas encore très bien lesquelles.

Il y a d’abord l’aspect communautaire. Maelys a bien un forum où ses utilisateurs interviennent de temps à autre, mais on ne peut pas dire que ceux-ci constituent réellement une communauté. C’est un peu chacun qui utilise Maelys dans son coin, et vient poser son problème quand il en rencontre un. En gros, il y a un manque de suivi et coordination. La grande question ici est de savoir comment faire pour créer une vraie communauté dans laquelle les utilisateurs se sentent réellement impliqués, et qui soit reconnue comme telle. Un corollaire doit être ajouté  à cette question, qui concerne en particulier les utilisateurs en Afrique, puisque c’est eux la première cible du logiciel.

Ensuite, il y a les aspects marketing et rentabilité qui je dois l’avouer n’ont jamais vraiment été sérieusement pris en compte. Pour poser la question avec des termes connus, je dirais simplement: quel modèle économique pour Maelys? Il y’en a bien sûr un qui se dégage avec Doomedo, mais pourrait-on en trouver d’autres? Quels avantages, risques et inconvénients? Comment faire de Maelys une marque?


Doomedo est un service qui propose aux clients des cybercafés en Afrique d’envoyer des SMS dans le monde entier. Ils achètent les crédits dans les cybercafés, et utilisent un logiciel mis à leur disposition pour envoyer leurs messages à partir d’un poste du cybercafé.

C’est en ces termes que le service que je lance en ce moment même est décrit sur le site qui lui est consacré. Le site en question est composé d’une page d’accueil qui a des allures de blog (et pour cause, c’en est un), une page de présentation, une page de documentation (en cours de rédaction) et un forum de discussion.

Comme sa description l’indique, il s’agit de vente de SMS dans les cybercafés en Afrique. En Afrique francophone, pour le moment, vu que le français est la seule langue disponible. Trois pays ont été choisis pour accueillir le service dans cette première phase de lancement : Le Cameroun, la Côte d’Ivoire et le Bénin. Il s’étendra progressivement dans la suite aux autres pays, y compris l’Afrique anglophone.

Doomedo va s’appuyer sur Maelys, un autre projet que je conduis depuis quelques années déjà.

Maintenant que vos fils et vos filles vont la main dans la main

Il y a quelques années alors que j’étais encore en fac à Yaoundé, deux ingénieurs de deux grosses boîtes sont venus nous faire une présentation commune sur l’état et les évolutions des technologies réseaux. Ladite présentation avait frôlé la perfection, tellement elle était instructive pour l’étudiant que j’étais. C’est dire si les deux intervenants s’accordaient à merveille dans leurs exposés. Et pendant que nous discutions après l’exposé, on leur a fait remarqué que leurs sociétés respectives étaient concurrentes sur le marché. Ce à quoi l’un d’eux a répondu que c’était certes le cas, mais lorsque leurs intérêts respectifs l’imposaient, ils n’hésitaient pas à travailler ensemble. A travailler à fond ensemble, dirais-je, au vu de la qualité de leur exposé.

Pour quoi je raconte ça? Vous connaissez certainement le site de l’Interop Ability Lab. Il s’agit d’un projet conjoint de Microsoft et Novell visant à ce que leurs produits respectifs puissent fonctionner ensemble de façon optimale. Rappelons que Microsoft, c’est Windows, c’est la culture du logiciel propriétaire, tandis que Novell, c’est (désormais) Linux et les logiciels libres. Deux mondes qui pendant longtemps se sont méfiés, défiés, affrontés de façon plus ou moins virulente, mais qui aujourd’hui se rapprochent et vont la main dans la main.

Quels sont les facteurs qui peuvent être à l’origine d’un tel rapprochement. On peut certainement en trouver plusieurs, mais à mon sens il y en a deux qui prédominent. Le premier, c’est la pression des utilisateurs. Les solutions libres sont arrivées à une maturité qui leur permet de tenir dans des environnements critiques. Les serveurs Apache, Sendmail, Postfix ou OpenLDAP par exemple sont très souvent choisis à la place de leur équivalent propriétaires. Or de nombreuses entreprises qui ont opté pour une solution libre souhaitent néanmoins conserver des solutions propriétaires déjà présentes et fonctionnelles dans leur système d’information. D’où le besoin d’interopérabilité entre solutions libres et propriétaires. Le deuxième facteur est l’entrée de grandes entreprises telles que Sun ou Novell dans le monde du libre. Ceci a apporté une plus grande crédibilité aux logiciels libres, mais surtout a permis aux éditeurs de logiciels propriétaires de trouver en face d’eux des interlocuteurs avec qui le dialogue est plus aisé, car parlant le même langage. Les acteurs traditionnels du libre avaient la fâcheuse habitude de mettre plus l’accent sur la philosophie que sur le service aux utilisateurs ou la rentabilité. Par conséquent, on imagine mal ce genre de partenariat entre la FSF et Microsoft, par exemple.

Bien sûr, il ne faudrait pas se laisser aller à rêver trop loin. Malgré tous les signes d’ouverture en direction du monde du libre, Microsoft est et restera toujours Microsoft avec tout ce que cela implique. Mais nous vivons dans un monde hétérogène par nature, et complexe, où il est toujours profitable qu’un équilibre s’établisse entre les forces en présence. Ce qu’il faut en retenir, c’est la reconnaissance réciproque de la qualité des solutions libres et propriétaires, et le respect mutuel qui en découle.

Entre théorie..

et pratique.

Soit la suite réelle Endalè que je définis .. Hein? Comment ca pourquoi Endalè? y’a un proe avec Endalè?
Alors! La définition de la suite Endalè() donc:

Soit un entier naturel n, la suite réelle Endalè(n) se définit comme suit:

Endalè(0) = 0.5
Endalè(n+1) = Endalè(n) – 0.1

A. Quelle est la valeur de Endalè(5)?

Vous avez trouvé? Hum, mieux de vous que vous êtes des génies. Moi ca me pash. Je rédige donc un programme java (voir ci dessous) pour m’aider à résoudre ce problème mathématique du siècle, qui a tellement essouflé Einstein qu’il a sorti la langue. Ce qui a donné sa fameuse photo connue dans le monde entier (Copyrights: La photo d’Einstein ci-dessous a été tirée du site Si j’en crois leur UserAgreement, je peux l’utiliser pour un usage personnel, non commercial. Voilà.).

Einstein tirant la langue

Einstein, essouflé par le problème Endalè.

B. Et pourtant quand j’execute le programme et que je lui demande si la valeur Endalè(5) est nulle, il me dit faux. Oú est l’embrouille?

(Toutes les gos qui trouveront auront des bisous[virtuels]. Quand aux mecs, qu’ils aillent loin avec leurs barbes)

Donc pour me résumer,
En théorie:
une suite réelle S(n), n entier naturel

S(0) = 0.5
S(n + 1) = S(n) – 0.1

En pratique:
un programme java qui me dit que no oooh, S(5) <> 0, zéro là c’est pour moi là-bas, il ne sait pas de quoi je parle!!
Cherchez l’erreur.

Lire la suite