On essaie d'être le plus régulier possible dans la sortie des versions de maintenance, donc voici Jelix 1.0.5 qui corrige des bugs mineurs. La version 1.0.6 sortira dans deux mois. Si il y a de nouveaux bugs bien sûr :-)

Après un calme assez plat dans les développements de la version 1.1, à cause de la préparation des RMLL, et d'autres occupations qui ont accaparé mon temps, l'activité a repris ces derniers jours, avec encore des nouveautés dans jForms, comme la possibilité de grouper des contrôles, une API plus complète sur les contrôles, et un nouveau contrôle <choice> pour avoir une liste de choix contenant des contrôles, comme dans un bug tracker :

  <choice ref="task">
     <label>Task status</label>
     <item value="new">
         <label>New</label>
     </item>
     <item value="assigned">
         <label>Assigned</label>
         <input ref="assignee" required="true">
             <label>assignee name</label>
         </input>
     </item>
     <item value="closed">
         <label>Closed</label>
         <menulist ref="task-done">
             <label>Status</label>
             <item value="done">Done</item>
             <item value="cancelled">Cancelled</item>
             <item value="later">Later</item>
         </menulist>
     </item>
  </choice>

J'ai encore quelques améliorations à faire, pour rendre jForms plus maléable (rajouter des champs de saisie à la volée par exemple), et après ça, probablement qu'une version beta sortira.

Au passage, si j'ai développé cette balise <choice> avec cet exemple d'utilisation pour un bug tracker, ce n'est pas par hasard. Souvenez vous de mon coup de gueule sur Trac, et des résultats de mes recherches d'un nouveau bug tracker, qui sont finalement restées vaines. Au bout du compte, j'avais décidé à l'époque d'en créer un nouveau, je me suis lancé donc dans ce développement.

Cela m'a permis d'utiliser pleinement Jelix, et de découvrir sa force (2 heures seulement pour faire la gestion complete des reports comme dans trac !), mais aussi certaines faiblesses. D'où la création d'un nouveau système de gestion de droits, jAcl2, avec son module d'admin, mais aussi des améliorations dans jForms, dont celles que je viens d'évoquer. Et tout ça est dans le trunk de jelix maintenant. Ces développements ont bien sûr ralenti ceux de mon projet de bug tracker, mais maintenant que je vais presque avoir tout ce qu'il faut, je vais pouvoir me relancer à fond dans ce projet.

Alors bien sûr, je sais que c'est un peu la mode en ce moment de faire un bug tracker en PHP (à cause entre autre je pense du concours sur developpez.com). Mais je me suis lancé dans ce projet bien avant cette mode ;-). Pour le moment, il n'est pas vraiment utilisable, mais ça va le devenir :-) Enjoy !.

---

© 2008 Laurent Jouanneau. Ce billet a été originellement publié sur Le blog de Laurent Jouanneau

Il y a un moment maintenant, je vous avais présenté un plugin Jelix permettant de faciliter l'utilisation des librairies du Zend Framework.

Comme ce plugin pourrait servir à bien d'autres que moi et permettre aux Jelixians d'avoir à disposition les librairies intéressantes du Zend Framework, il a été finalement intégré directement dans Jelix. Il sera donc disponible dans la version 1.1 (et dès demain dans les nightly build du trunk).

Pour l'utiliser :

• copier le fichier lib/jelix/plugins/coord/zendframework/zendframework.coord.ini.php.dist vers votreappli/var/config/zendframework.coord.ini.php
• configurer la variable zendLibPath dans ce fichier de configuration
• activer le plugin dans le fichier de configuration de votre application :

[coordplugins]
zendframework = zendframework.coord.ini.php

Comme vous ne voudrez certainement pas charger inutilement le loader du Zend Framework à chaque action de votre application, il faudra explicitement déclarer que vous voulez vous servir de ses librairies. Cela se fait avec la variable de classe $pluginParams du controller (ici je n'active le ZF que pour l'action fooPdf de mon controller) :

public $pluginParams = array('fooPdf' => array('zf.active' => true));

Ensuite libre à vous, dans votre action ou dans une classe métier qui sera utilisée dans cette action, d'utiliser les librairies du ZF. Je reprends l'exemple que j'avais précédemment donné avec Zend_Pdf :

function fooPdf() {
    $rep = $this->getResponse('binary');

    Zend_Loader::loadClass('Zend_Pdf');
    $pdf = new Zend_Pdf();
    $pdf->pages = ($page = $pdf->newPage('A4'));
    $font = Zend_Pdf_Font::fontWithName(Zend_Pdf_Font::FONT_HELVETICA);
    $page->setFont($font, 32);
    $page->drawText('Zend Framework with Jelix !', 120, 500);        
       
    $rep->content = $pdf->render();
    $rep->outputFileName = 'fooo.pdf';
    $rep->mimeType = 'application/pdf';

    return $rep;

}

Dans ce cas précis il n'est pas exclu que je propose une réponse personnalisée jResponseZfPdf pour mapper de manière plus élégante l'utilisation des pdf dans Jelix avec Zend_Pdf.

Cette nuit, j'ai du allé au lit à minuit. Une heure à laquelle mon corps est incapable de dormir.

Donc, étant pleinement réveillé et ne pouvant rien faire d'autre que réfléchir, j'ai réfléchi. A plein de choses. Ca va du personnel au professionnel. Ceci n'est absolument pas un exercice que j'aime pratiquer mais je suis actuellement à un point de saturation dans mon cerveau qui me mine le moral donc je fais un GROS point.

Que ceux qui n'ont pas le temps de lire s'abstienne, ce qui arrive est LONG à lire.

Je travaille actuellement essentiellement en PHP5, et je contribue un peu au développement d'un framework nommé Jelix. Je pense sincèrement que PHP est un langage débile et qu'en tout point Python est bien meilleur et propose déjà plein de chose que j'ai envie de développer pour Jelix. Mon ami Bruno Bord me bassine depuis pas mal sur Python et pour en avoir pas mal parlé/pratiqué pendant les RMLL je dois avouer que Python et Django c'est quelque chose de génial pour plein de raisons que je ne vais pas aborder ici.
Je donnerais beaucoup pour pouvoir passer uniquement développeur web sur du Django, ne pas faire d'intégration web, ne pas utiliser/intégrer diverses solutions que je ne maitrise pas etc.. MAIS cela impliquerait de changeait complètement de vie, de profession, de contacts professionnels or je ne le souhaite pas (je ne lâcherais pour rien au monde Alain, Fred, Corinne, Jean-Luc, Laurent et les autres). De plus mes compétences en PHP valent quelque chose (du moins je le pense) et je n'ai pas envie/la possibilité pour le moment de tout plaquer mes compétences pour passer sur du Python. Peut-être dans quelques années.

Encore une fois cette décision demande de la patience. J'aimerais pouvoir toujours tout plaquer et changer complètement tout, mais je suis encore jeune, je suis étudiant, je travaille pour une toute petite structure qui a malheureusement du mal à décoller pour le moment suite à quelques erreurs à la con dont je parlerais plus tard.
Toujours à propos de patience, j'ai - comme beaucoup de personnes - du mal à me concentrer sur un seul projet. VRAIMENT du mal. En fait je ne suis même jamais satisfait, car quand je suis sur un projet, je pense déjà au prochain et au final je ne termine quasiment jamais ce que je fais^[1]. Et comme je suis au quotidien sur 5 ou 6 projets à la fois, quand je suis sur le projet 1 je pense aux projets 2 et 3 et ainsi de suite. Une merde absolue dans ma tête. Il faut absolument que j'apprenne à me focaliser sur un et un seul projet;

Mes projets actuels

Je travaille actuellement sur (ATTENTION, j'ai toujours était discret sur mes projets pro et perso, ça va changer) :

• un dl.free.fr like mais réservé à une clientèle uniquement composée d'entreprise, avec marque blanche, et réservé aux échanges de fichiers entre personnes d'un même réseau. En Jelix.
• un projet de planification de tâches en fonction de plein de critère, en Jelix.
• je me forme à OpenERP.
• je dois me former à Alfresco.
• je dois optimiser mes compétences en Zimbra OSS.
• je suis contributeur Jelix, j'ai environ 5454453 millions d'idées, lire plus loin.
• projet wechange, lire plus loin.

Wechange

Commençons d'abord par celui qui me les brise le plus : wechange. Wechange est un projet initialement créé par deux étudiants en jesaisplustropquoimaisquin'arienàvoiraveclinformatique. Le projet est sympa : mettre en place une plateforme d'échange de cours. J'aime beaucoup l'idée.
N'étant absolument pas informaticien et encore moins développeur, ils ont fait appels au pire programmeur de toute l'histoire de l'humanité pour développer le site qui est actuellement en ligne. Le code qui propulse ce site est certainement le pire que j'ai été amené à voir et vous n'imaginez pas à quelles horreurs mes yeux ont pourtant étaient exposés. J'ai trouvé dans le code une bonne soixante de milliers de lignes de code inutiles, mal écrites, bref tout. Tout est mauvais dans la réalisation de ce site. Et le pire c'est qu'ils ont payé cher pour ça, alors qu'ils sont étudiants sans un sous.

L'initiative étant sympathique et étant eux-mêmes fort sympathique, je me suis proposé de les aider à refaire le site. Inconvénient, et comme dit ci-haut, ils étaient déjà pas bien riches mais en plus ils se sont fait escroqués (je pense que c'est bien le mot). Donc pour me payer, walou. Je ne veux pas faire le grincheux, le raleur, le ce que vous voulait, mais j'avoue que bosser gratuitement sur un projet qui n'est pas le mien et dont je ne crois pas que je puisse un jour retirer de l'argent m'emmerde beaucoup. Le code coute cher, et développer sans que ça ne me serve à rien à plus ou moins grande échéance m'emmerde encore plus.

C'est donc là qu'intervient mes réflexions de cette nuit. Puisque je suis persuadé que je n'en tirerais rien ou pas grand chose, je propose un développement communautaire. Le nom de la plateforme est wechange, cela pourrait-être sympa de libérer le code que j'ai déjà écrit, sans évidemment tout le code permettant de faire la migration de la version merdique à la belle version en Jelix. Ce développement communautaire permettrait :

• de me motiver, travailler pour rien et pour personne me fait chier
• d'avoir un exemple open source de site complet utilisant Jelix
• d'avoir un certain nombre de modules que je pense être sympas publiés
• de faire un micro buzz autour de Jelix et Wechange. Il y aurait le wechange officiel qui possède la marque, et le code exempt de toute allusion à wechange et possédant peut-être quelques fonctionnalités en moins. En tout cas ceci assurerait une grande pérennité de la plateforme, et surtout de mon travail que - je me répète encore - j'ai du mal à lâcher sans contrepartie.
• peut-être que ça attirera des personnes, des projets, peut-être pas, mais en tout cas je pense pas que ça puisse être négatif pour personne.

C'est le modèle de Zimbra, d'Alfresco et ce sont tous les deux des projets qui fonctionnent très bien. Je n'ai évidemment pas la prétention de pouvoir créer un projet à cette mesure mais j'aime leurs moyens de vivre.

Ju, Jerem c'est à vous de décider. Vous seriez les chefs de files niveaux idées et projet. Je serais responsable de tout ce qui est code, proposition, amélioration etc. Je pense que c'est un moyen de vous faire connaître encore plus. De toute manière je dois avouer que sans ça, ma motivation est quasiment inexistante en ce moment, et ce n'est bénéfique pour personne.

Jelix, module d'administration, installation/désinstallation de module

J'ai pour idée de développer un gros gestionnaire de modules dans Jelix. Je sais que je n'aurais jamais de la vie le temps de développeur ça donc je poste juste ici mes diverses idées. Plus tard quand elles seront plus claires dans ma tête ça deviendra des tickets et/ou des patchs.

Les modules qui existent déjà et/ou que je suis en train de développer proposent toutes un dossier install contenant les scripts sql d'installation. A ce sujet là, j'aime beaucoup la manière de gérer les versions, les installations et les désinstallations de projets comme Pluf ou Drupal. Je pense à :

• xhtml.net : Ajout d'un système de migrations pour Pluf
• drupal.org fichier install du module akismet (module choisi au hasard)

Un truc avec du versionning sur l'installation des modules. J'en ai besoin en ce moment...

Le module d'administration checkerait la liste des modules, proposerait l'installation, la mise à jour des modules. La création des modules créerais les droits jAcl2 en base de données.

J'aimerais vraiment avoir le temps de développer tout ça.

Et de finir sharecode.

Bon et puis je suis crevé. Je suis sûr que j'ai écrit de la m**** mais rien à faire....

Quand j'utilisais Code Igniter, j'utilisais beaucoup la librairie Messages développée par Vijay Mahrra et Sheikh Ahmed. C'était pratique à utiliser et permettait de générer facilement des messages qui sont affichés par la suite à l'utilisateur.

Par exemple : "Machin a bien été créé", "Truc a bien supprimé avec succès", "J'aime manger", "une erreur est survenue", etc.

Bizarrement dans tous mes projets Jelix, je n'en avais pas eu spécialement besoin. Du coup je n'y avais pas repensé. Mais depuis, j'en ai l'utilité. A peine évoqué le sujet que l'ami Loic Mathaud découvre qu'il en a aussi besoin.

Donc il l'a développé. Au final ça fait pas grand chose en nombre de lignes, mais c'est toujours ça de moins que j'aurais à développer moi-même :p.

L'API est consultable sur le ticket.

Le projet Jelix était initialement hébergé sur la plateforme developer.berlios.de. Mais petit à petit, à cause d'une qualité moyenne de l'hébergement, et parce que Nicolas me prête un peu de sa dedibox, j'ai migré certaines choses de berlios vers le serveur jelix.org. Ça d'abord été le site principal (berlios trop chargé), puis abandon du bugtracker (trop simpliste) après installation d'un trac sur http://developer.jelix.org.

Je gardais toutefois le dépôt subversion sur berlios, par flemme de migrer d'abord, mais ensuite parce que ça animait les stats d'activité du projet, donnant alors en principe une certaine visibilité au projet. Mais les problèmes récurrents d'accès aux dépôts subversions ces dernières semaines m'ont fait prendre la décision de migrer, d'autant plus que ces stats n'ont finalement rien apporté en 2 ans.

Bref donc, à coup de svndump et svn load, le dépôt est maintenant sur svn.jelix.org. On a donc maintenant un accès plus rapide, et plus fiable normalement :-).

Les fichiers en téléchargement et les mailing lists restent par contre sur berlios pour le moment.

Je vais aussi certainement ouvrir en partie le dépôt subversion des fichiers des sites *.jelix.org^[1] , en espérant avoir quelques contributeurs qui m'aideront à les faire évoluer. Il y a de plus en plus de chose à faire dessus (notamment l'intégration d'un site de "snippets" codé avec Jelix qui ouvrira dans les prochaines semaines), mais mon temps disponible, lui, ne s'allonge pas. Si au passage il y a des volontaires...

---

© 2008 Laurent Jouanneau. Ce billet a été originellement publié sur Le blog de Laurent Jouanneau

Les développeurs de Jelix l'ont remarqué, depuis peu il n'y a plus moyen d'accéder au dépôt Jelix en svn.

Pour corriger le problème, il suffit de passer du protocole svn à https pour l'adresse du dépôt :

svn switch --relocate svn://svn.berlios.de/jelix/trunk https://svn.berlios.de/svnroot/repos/jelix/trunk .

C'est décidément la journée des chassés-croisés.

J'ai développé il y a deux mois un script js pour générer une table des matières, NiKo a créé le sien en 14321x mieux.

Aujourd'hui j'ai enfin commencé à développer le gestionnaire de snippets en Jelix que l'on (la team jelix) repousse à plus tard depuis des mois avec pour modèle http://snippets.prendreuncafe.com/ propulsé par Symfony et snipeet.

Snipeet a l'air très bien foutu, mais par pur honneur/principe/classe c'est difficilement imaginable d'utiliser une appli en Symfony pour se servir sur le site de Jelix (pour les véritables touristes qui passent par ici, Symfony et Jelix sont "concurrents" dans la mesure où ce sont tous les deux des frameworks PHP5).

NiKo, j'ai une question : snipeet ne gère vraiment que le php/xml/js/css comme colorisation syntaxique de langages ? Pour l'instant j'utilise Geshi dans sa version 1.0.7 et c'est vraiment pas ça :

(le design n'est évidemment pas du tout définitif)

La page du projet : http://forge.jelix.org/projects/sharecode

Bientôt (peut-être) une démo sur jelix.org :p.

On continue avec les sorties régulières de versions de maintenance de Jelix 1.0. Hier donc c'était la sortie de Jelix 1.0.4 qui corrige quelques bugs mineurs. Nous continuons à suivre une politique stricte sur les versions :

• Les versions mineures en 1.0.x ne corrigent que des bugs, et n'apporte que des "micro" améliorations, pour éviter d'avoir des regressions ou des nouveaux bugs. La stabilité avant tout.
• Les versions intermédiaires en 1.x apporteront des nouveautés, voir quelques APIs cassées mais seulement sur des composants "périphériques" : on ne modifie pas l'API du coeur du framework (contrôleurs, vues etc...) tout au plus peut-on se permettre de rajouter des méthodes et propriétés ou nouveaux objets dans le coeur. Avec bien sûr son lot de nouveaux composants et d'évolutions sur les composants existants.
• Les version majeures : on se permettra de tout casser si il le faut. Je pense qu'une version 2.0 sera envisagée pour la sortie de PHP 6, profitant des évolutions de ce dernier (et sera donc incompatible avec PHP5). Mais il n'y a rien d'arreté pour le moment, Jelix fonctionne bien comme il est :-).

La sortie de cette version 1.0.4 coïncide avec la sortie de l'article de Bastien (contributeur au projet) dans le numéro spécial de Linux+ DVD : "Développer efficacement avec Jelix".

---

© 2008 Laurent Jouanneau. Ce billet a été originellement publié sur Le blog de Laurent Jouanneau

Je viens de perdre ma soirée pour.... that !

Bataillé toute la soirée avec le plugin de template image de Jelix, mais il s'avère que le problème ne vient pas du plugin (qui fonctionne impeccablement sur mon xampp) mais de la lib gd de php5 sous debian etch.

Resolved with a fresher version of php5 : http://dotdeb.org/mirrors

 deb http://packages.dotdeb.org stable all
 deb-src http://packages.dotdeb.org stable all

Ca y est, je l'ai dans les mains, le nouveau numéro de Linux+DVD contenant mon article de présentation et d'initiation à Jelix.

Et maintenant au travail ! Bastien Jaillot vous présentera le framework PHP Jelix, un outil qui vous facilitera considérablement votre tâche créatrice.

Dommage, pas de mention Jelix sur la couverture, mais tout de même un article de huit pages sur comment fonctionne Jelix, ses atouts et enfin un tutoriel "rapide" montrant le développement d'un moteur de blog.

Au programme de numéro, vous trouverez aussi :

• L'histoire et l'avenir du Web,
• Conception 3-tiers d'un site web
• Développer efficacement avec Jelix
• Utilisation de Munin
• ...
• Revue des outils de programmation,
• Webmastering et logiciels libres.

Je ne sais pas encore quand ce numéro paraîtra, sûrement dans les premiers jours de Juin.

Je retourne à mon code (Jelix évidemment), ++

MAJ : nous sommes début juillet, je publie le PDF

La documentation sur un outil de développement comme un framework est souvent un problème. D'une part parce que, bien souvent, le développeur n'aime pas écrire de la doc, mais aussi parce que soit la rédaction de la documentation n'est pas aisée, soit elle n'est pas disponible dans un format autonome et imprimable.

Ainsi, on remarque bien souvent deux types de documentation mutuellement exclusifs :

• documentation dans un wiki : c'est pratique pour tout utilisateur. Chacun peut contribuer et faire évoluer la documentation. Mais aucun de ces wikis ne permettent, à ma connaissance, l'export de toutes les pages écrites dans un autre format, comme PDF pour pouvoir l'imprimer, ou même un simple export HTML pour consultation hors-ligne.
• documentation uniquement disponible dans un PDF, ou alors consultable sur un site "statique", donc non éditable pour qui veut compléter. Cela peut être un choix de la part des dirigeants du projet, mais cela peut être aussi dû à une contrainte technique. En effet, bien souvent la création de cette documentation passe par la création d'un fichier en Docbbok, ou Odf, et exporté en PDF (pour l'impression) ou HTML (pour le site). Par expérience, je sais que, même si la source en docbook ou autre est disponible librement, les contributions sont rares, car c'est "pénible" à modifier : il faut utiliser un outil d'édition autre que le navigateur, en plus d'un autre pour télécharger les fichiers (lecture et sauvegarde). On voit ainsi tout de suite que c'est beaucoup moins aisé qu'une page wiki où il suffit juste de cliquer sur un bouton "éditer la page".

Par exemple, du temps où j'étais core-developer de Copix, nous avions la doc au format docbook^[1]. Contributions externes à l'amélioration de la doc : aucune. Par contre, sur la documentation de Jelix, qui est dans un wiki, le nombre de contributions ne se compte plus, que ce soit les simples corrections d'orthographe ou l'ajout de sections entières.

Mais voilà, depuis la naissance de Jelix, j'ai souvent eu des demandes d'une version téléchargeable et imprimable de la documentation. Un nième message m'a fait passé à l'action.

J'ai donc essayé de trouver un moyen pour concilier les deux avantages :

1. extrème facilité d'édition de manière à encourager les contributions (et donc alléger le travail des développeurs, ou au moins, une meilleure répartition du travail entre eux pour la rédaction de la doc).
2. fournir une version téléchargeable pour pouvoir consulter hors-ligne et l'imprimer.

Impensable de remplacer le wiki (sous dokuwiki) par autre chose. Je tiens à conserver les avantages du point 1. Aussi j'ai imaginé une solution qui permet d'exporter le contenu du wiki dans un fichier Docbook. L'avantage du Docbook est qu'il existe déjà tout ce qu'il faut pour exporter le docbook vers du HTML, du PDF et autre. Bien entendu, l'export d'un ensemble de page dokuwki vers du Docbook n'existe pas, je me suis donc atteler à la tache. Voici donc maintenant comment ça fonctionne :

• j'ai réalisé des plugins pour Dokuwiki, afin de permettre d'indiquer dans une page, des informations sur le "livre" que l'on veut créer, en particulier, le sommaire complet, c'est à dire la liste de toutes les pages ainsi que leur hierarchie et leur ordre. Ces plugins stockent ces informations en base de données^[2] pour être réutilisables par d'autres composants.
• Parmis ces autres composants : des fonctions pour le template de dokuwiki, qui affichent automatiquement des bandeaux de navigation sur chaque page du wiki qui font partie du livre. Cela a un gros avantage par rapport à "avant" : si on veut changer l'ordre d'une page, en insérer une nouvelle quelque part, on n'a plus à changer les liens qui étaient en dur dans le texte wiki des pages, et qui permettaient la navigation dans le "livre". Il y a juste à changer le sommaire. Deuxième avantage : le contenu stocké des pages ne contient que le texte du manuel. L'exporter est donc plus facile (pas de tri à faire entre le contenu à insérer dans le docbook, et les liens de navigations propre au contexte wiki).
• On a donc maintenant en base de donnée, tout ce qu'il faut pour générer le fichier DocBook : les metas-informations sur le livre, et la liste des pages. En plus bien sûr du contenu des pages stocké par Dokuwiki dans des fichiers textes. En utilisant Jelix, j'ai réalisé un script en ligne de commande qui génére le Docbook. Il s'appuie entre autre sur WikiRenderer^[3], pour lequel j'ai développé des rêgles pour parser la syntaxe wiki des pages et générer des tags docbook plutôt que HTML. Assez long à faire, sachant qu'il a fallu convertir les liens dokuwiki, importer les images utilisées dans les pages etc... Au passage, j'ai dû améliorer le moteur de WikiRenderer, la version 3.1 sera encore plus souple :-).
• Enfin, écriture d'un script shell qui appelle le script d'export docbook, et ainsi que les commandes d'export Docbbok vers PDF. Ce script shell est installé dans le cron, permettant la génération des PDF toutes les nuits.

Au départ, je pensais que ça me prendrait quelques heures, mais j'y ai passé quelques un de mes jours de congés^[4] :-) Cependant, le résultat est là : on dispose maintenant de la version PDF du manuel (ainsi que du tutoriel) qui est édité dans le wiki. Et sur le wiki, la navigation s'est largement améliorée. Il y a toutefois encore des petits choses à améliorer, comme la présentation dans le PDF, l'organisation des pages, mais le système est en place.

Seul bémol : je garde tout ces développements pour moi. Pour deux raisons :

• C'est fait un peu à l'arrache. Il y a plein de trucs (chemins, urls et cie) en dur dans le code, il y a du code pas aussi propre que dans Jelix (oui j'ai un peu honte), et surtout vraiment pas mal de trucs spécifiques à l'installation du site et de la config du serveur.
• Du coup, pour en faire quelque chose de distribuable, propre, y a encore du boulot. Et je n'ai plus de temps. Surtout que, qui dit distribution, dit un minimum de doc pour expliquer comment installer tout ça. Et pour ça, j'ai encore moins de temps :-)

Peut être qu'un autre jour, quand j'en aurais le courage...

---

© 2008 Laurent Jouanneau. Ce billet a été originellement publié sur Le blog de Laurent Jouanneau