Jy[B]log

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

Dés le départ, quand j'ai conçu l'architecture du système de formulaire jForms, dans Jelix, j'ai fait en sorte que chaque partie de jforms soit suffisamment bien séparée des autres, de manière à le faire évoluer le plus facilement possible. Par exemple, un des objectifs premiers était, à partir d'un unique fichier descriptif de formulaire en XML, de pouvoir générer un formulaire dans le format que l'on veut : HTML, XUL, XForms etc.. Ainsi donc, dans jForms il y a

• un objet pour l'analyse du fichier XML jforms
• un ensemble d'objet pour l'instanciation et la manipulation d'un formulaire coté serveur dans les contrôleurs,
• d'autres pour la validation des données coté serveur,
• et enfin un autre pour la génération finale d'un formulaire dans un format précis.

Dans Jelix 1.0.1, il n'y a qu'un format de sortie disponible, qui est du HTML que je qualifierai de "classique" (comprendre, pas de DHTML et ajax dans tout les sens), avec une génération de code javascript pour la validation coté client. On peut ajouter d'autres formats, mais il faut modifier quelques lignes dans le code même de jForms, ce qui n'est pas des plus pratique, malgré l'existence d'une documentation sur ce sujet pour les "hackers".

Ce temps est cependant révolu : je viens de passer deux petites heures à modifier légèrement jForms afin que les générateurs de sortie soient sous forme de plugins. Ainsi, plus besoin de modifier le code de jForms pour ajouter un nouveau format. Il suffit de faire une simple classe que l'on dépose dans un répertoire de plugin, de faire les plugins de templates qui vont avec et c'est tout. Bien entendu, rien ne change au niveau utilisation ;-)

Il est probable ainsi que l'on puisse, dans Jelix 1.1, générer un formulaire HTML utilisant extjs par ex, ou générer un formulaire en XUL (et plus tard un plugin pour générer un formulaire HTML5 ;-) .

Prochaines évolutions dans jforms : de belles balises comme <htmleditor>, <captcha>.. ;-)

Deux ans après l'annonce officielle du démarrage du projet, la version 1.0 du framework Jelix est enfin disponible. Je vous invite donc à l'essayer et à l'utiliser :-) Si il y en a parmi vous qui veulent propager la bonne nouvelle, ils peuvent réutiliser le communiqué de presse.

Quelques chiffres parce que j'aime bien les chiffres :

• Je n'ai pas passé 2x365 soirées à le développer, à le débogguer, à répondre aux sollicitations des utilisateurs, à valider les patchs des contributeurs. Mais presque. Sans compter les heures que Disruptive Innovations me permet de passer sur le projet.
• 732 commits dans le dépôt subversion
• 293 tickets fermés dans le tracker, sans compter une soixantaine qui était dans le tracker sur berlios dans les débuts. Parmi ces 293, 54 tickets concernent des patchs fournis par des contributeurs (et intégrés dans Jelix).
• plus de 120 tickets sur le total ont été ouvert par des contributeurs.
• Il y a actuellement encore 117 tickets ouverts, pour la plupart concernant des améliorations et des nouvelles fonctionnalités (c'est dire si il y a encore du boulot :-)).
• 1557 messages à ce jour dans le forum.

Bon, faut pas se leurrer, ce sont quand même des petits chiffres par rapport à d'autres projets :-). Mais on va voir comment ça va évoluer.

Merci à tout ceux qui ont aidé à faire aboutir Jelix 1.0 !

Trackbacks manuels :

• Torgan : Jelix 1.0 est sorti !
• Phpindex.com : jelix 1.0
• Linuxfr.org : Jelix 1.0

J'ai le plaisir de vous annoncer la sortie d'une version candidate pour le framework PHP5 Jelix 1.0. Je vous encourage à la tester afin que la version 1.0 soit la plus robuste possible. Je pense sortir cette 1.0 au tout début Janvier. La documentation en français est bien fournie maintenant, mais la documentation en anglais laisse à désirer. Si il y a des volontaires dans la salle pour aider à la compléter, ce serait vraiment chouette :-)

Enjoy !