jy[B]log

Dans le courant de la semaine, j'ai publié des nouvelles versions correctives des deux branches actives de Jelix, le framework PHP. Vous pouvez mettre à jour vos installations Jelix sans risque. Il est même hautement recommandé de mettre à jour votre Jelix 1.1 si vous utilisez les modules d'interfaces de gestion de droits et de gestion d'utilisateur, à cause de problèmes critiques lorsque l'on change les droits (des droits peuvent être enlevés inopinément), et sur l'édition d'un profil d'un utilisateur.

Et puis aujourd'hui, je viens de sortir une nouvelle version de WikiRenderer, la 3.1, qui corrige quelques bugs, et qui apporte quelques facilités pour les développeurs de règles de transformations. Pour rappel, WikiRenderer est une classe qui permet de transformer un texte wiki dans une autre syntaxe wiki, ou en XHTML, ou tout autre langage de markup. Elle m'est très utile dans les petits modules de CMS, ou encore récemment, pour migrer le contenu wiki de XULFR d'un vieux wiki vers un nouveau wiki qui a une syntaxe différente. Et pour l'occasion de cette sortie, le site de WikiRenderer est maintenant disponible en Anglais, avec une documentation pour les développeurs.

Un p'tit billet pour dire que ce Forum PHP 2008 était sympathique, bien organisé, avec des conférences intéressantes (au moins pour la journée de Mardi, à laquelle je suis allé).

J'ai pu notamment faire la connaissance de Fabien Potencier (monsieur Symfony), et j'ai trouvé sa conférence sur l'injection de dépendance et l'inversion de contrôle très intéressante et très pédagogique. Et du coup, j'ai enfin tout compris de ces termes barbares. (les tutoriels que j'ai pu lire par le passé sur le sujet étaient ultra théoriques et peu compréhensibles...)

En fait j'ai surtout compris que j'ai déjà utilisé l'injection de dépendance sans le savoir, et j'ai compris aussi l'intérêt d'un patch dans Jelix que m'avait soumis un contributeur, Christophe, qui a assisté lui aussi à cette conférence.

En fait donc, dans Jelix 1.1, il y a un embryon de possibilité d'inversion de contrôle ! (C'est dingue ce qu'on peut apprendre dans ce framework :-D). Christophe et moi, on a quand même constaté que ce n'était pas suffisant (d'où le terme employé, "embryon"), et donc pour la 1.2, on vous prépare du vrai IOC et de la vraie DI, bien intégré dans Jelix, réutilisant la philosophie des sélecteurs de classes de Jelix. (pour la 1.1, c'est un peu tard là, vu qu'on est au stade RC1..).

mise à jour 04/12/2008 : finalement je viens !

Mis à part le fait que je ne pense pas pouvoir aller au forum php 2008, je ne trouve pas le programme vraiment excitant^[1]. Par exemple, un truc qui m'a frappé : PHP 5.3 va bientôt sortir, et il n'y a aucune conférence dessus^[2]. Rien non plus sur l'avancement et le futur de PHP. Les conférences parlent plus de sujets connexes à PHP que PHP lui même...

Un petit récapitulatif des conférences :

• 3 conférences très "généralistes" sur les langages, l'histoire de php, success story...
• 5 retours d'expérience (gloups !!)
• 2 conférences (publicitaires) sur Oracle^[3] . Rappel : Oracle est un SGBD non open-source, et peu utilisé par des projets PHP... Ça aurait été plus sympa de parler de PostgreSql, qui n'a rien à envier à Oracle sur de nombreux points...
• 2 conférences sur le monde de l'entreprise (aucun rapport direct avec PHP, même si ça peut être intéressant)
• 3 conférences sur des outils pour du code php (analyse de code, qualité du code, environnement de dev...)
• 2 sur la programmation javascript et les performances coté client
• 1 sur la sécurité, sous forme d'atelier (ça a l'air sympa ça)
• 2 conférences plus techniques : mysql, decouplage (pfff, encore symfony :-))

L'année dernière, c'était beaucoup plus technique et orienté PHP, et avait l'air plus intéressant pour moi (bon, je n'y étais pas non plus..)

Aller, l'année prochaine, j'essaierai de faire une conf technique...

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 !.

Je réagis à certains billets comme celui de nexen qui annoncent que in_array est lent, comme si c'était un scoop.

Franchement, tout développeur ayant un minimum d'experience en programmation (niveau IUT première année, premiers cours en algorithmie), sait que faire une recherche séquencielle dans un ensemble de valeur est plus lent que faire une recherche en passant par un index. Ce n'est pas un scoop. C'est mathématique.

Maintenant on n'utilise pas in_array pour faire la même chose qu'avec des isset. C'est comme si on s'aperçevait sur un circuit que la 2CV est plus lente qu'une formule 1. Bah oui mais la 2CV n'est pas conçu pour aller sur un circuit.

Bref, l'auteur du billet original n'a pas choisi les bonnes fonctions pour coder son truc, et il s'étonne ensuite que c'est lent. Normal quoi.

Conclusion : in_array n'est pas lent. Il fait ce qu'il doit faire. Il n'est lent que si on l'utilise dans des situations inadaptées. point.

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".

Ce qu'il y a bien dans Mysql 5, c'est qu'on peut enfin commencer à utiliser triggers, procédures stockées et vues. Ça permet d'alléger le code PHP des applis web, et de garder une meilleure cohérence dans les données (et de meilleurs perfs dans le traitement des données je pense).

Bref, j'aimerai bien commencer à pouvoir faire des vrais schemas de bases de données dans les applis web (et dans certaines briques de jelix), quand je n'ai que mysql sous la main.

Seulement voilà, je ne suis pas sûr que Mysql 5 soit dispo chez tout les hébergeurs. Aussi, si vous pouviez me dire les versions de mysql, php, et posgresql que propose votre hébergeur (en donnant son nom), ce serait sympa :-)

Attention, n'allait pas seulement voir dans le phpmyadmin de votre hébergement. En effet, par exemple, je sais qu'OVH propose depuis peu du mysql 5, mais seulement pour les nouveaux inscrits, les bases sur mysql 4 des "anciens" n'étant pas migrées automatiquement.

PS: si vous avez votre propre serveur dédié, ça m'interresse aussi, indiquez alors "hébergement perso" comme nom d'hebergeur :-)

Pour le projet Jelix, j'utilise Trac pour le suivi et la gestion des bugs (il est hebergé sur http://developer.jelix.org/). Au départ, je l'avais trouvé sympa : simple à utiliser, avec des rubriques utiles comme la gestion et la visualisation des roadmap, la timeline pour être au courant de toutes les dernières modifications, le wiki intégré, la navigation dans les sources plus "sexy" que websvn.

Par contre à l'usage, Trac commence sérieusement à me gonfler :

• Contenu des tickets vraiment minimal. Certes on peut ajouter des champs via le trac.ini (très facile), mais on ne peut définir aucune règle de gestion, sauf à développer un plugin (et le python n'est pas encore ma tasse de thé), ou alors à faire du javascript dans tout les sens pour cacher la misère (le plugin des dépendances de tickets est un bel exemple en la matière).
• Les plugins parlons-en : du fait du minimalisme dans les tickets, on est obligé d'en installer un minimum afin d'avoir un truc décent. Par exemple, pour pouvoir créer des dépendances entre tickets (tel ticket bloque tel autre ticket), pouvoir gérer certaines choses "basiques" (liste des composants des versions etc), Ou encore avoir une authentification un peu mieux foutu. Cependant, le problème avec les plugins, c'est que la plupart sont soit incomplets, soit buggés, soit obsolètes ou utilisables seulement pour une version supérieure (et instable) de trac.
• Il en découle un autre problème : la complexité de mettre à jour trac ou d'installer les plugins. Faut avoir les droits d'admin pour installer trac, modifier la conf apache et cie. Il y a des dépendances de partout. Il faut taper des lignes de commandes dans tout les sens, dont on ne se rappelle jamais la syntaxe. Bref, par rapport à une appli PHP traditionnelle, c'est l'horreur.
• Impossible de rajouter des informations sur les pièces jointes. La gestion des pièces jointes est finalement trop pauvre pour mes besoins.
• L'affichage des pièces jointes : buggé tout simplement. Quand on attache un patch par exemple. Pour certains, on peut les visualiser directement dans trac (avec coloration syntaxique et tout), pour d'autre, obligation de les télécharger pour les voir. Je soupçonne un problème de reconnaissance du mime type du fichier lors de l'upload, ou un truc dans le genre. Toujours est-il que c'est très énervant.
• Bon et puis c'est pas super réactif, dû peut-être au fait que c'est en Python (pas taper :-) ), mais aussi certainement dû à la base de donnée : les concepteurs de trac sont vraiment des newbies en modélisation de base de données. Le schéma fait vraiment peur à voir. Un exemple : ils ne connaissent pas varchar, et vas-y que je te met tout les champs textuel en type "TEXT", des champs contenant uniquement des valeurs numériques en type "TEXT" également... Bien sûr, j'ai tenté d'améliorer tout ça, en changeant certains types, en ajoutant des indexes (primaire ou pas) là où il devait y en avoir etc.. Mais ça n'a que vaguement améliorer les choses.
• Je ne parle pas des templates super lourdingues à modifier. J'en ai passé des heures à intégrer le design "jelix.org"...

J'utilise une version 0.10, je sais que la 0.11 est en préparation et corrige certains points (le langage des templates, l'admin par ex). Mais j'envisage sérieusement de changer de gestionnaire de projet. J'en ai déjà regardé quelques-uns : Bugzilla, Mantis, Redmine. Cependant, ils ne me conviennent pas forcément.

• La gestion des tickets dans bugzilla est tout à fait ce qu'il faut. Mais l'interface est austère, et il n'y a pas de rubriques annexes comme la vue des roadmaps, de la timeline, la navigation dans les sources, ni de wiki intégré.
• Redmine : ça a l'air sympa, mais un peu simpliste quand même. Et j'ai eu des retours comme quoi c'était plutôt lent, même sur une machine dédiée (rails oblige ?)
• Mantis : l'interface est tout simplement une horreur. Pas seulement le design, mais aussi la façon dont elle est organisée. Et c'est lent.

Je suis en train de regarder une autre solution, mais je vous en dirais plus un autre jour.

Mise à jour : autres produits vus

• phpBugTracker : trop simpliste, moche
• Jira : ça a l'air complet et semble y avoir tout ce qu'il faut. Mais faut installer un serveur java, et puis c'est pas libre, bien que la licence soit gratuite pour les projets libres.

J'ai écrit^[1] un petit tutoriel qui montre un exemple simple sur l'utilisation de jForms, le système de formulaire de Jelix. J'ai repris le même exemple de formulaire que dans ce récent post sur un exemple simple d'utilisation de Zend_Form