Jy[B]log

Jelix 1.3 et au delà

Laurentj — Thu, 20 Oct 2011 11:44:00 +0200

10 mois après la version 1.2, voici la version 1.3, avec son lot de nouvelles fonctionnalités. J'ai pu amélioré et stabiliser cette version 1.3 sur des projets clients, dont un gros projet de plusieurs mois (application B2B), et qui tourne maintenant en production.

Pour ceux qui n'ont pas suivi l'actu Jelix ces dernières semaines ou mois, sachez que ça a pas mal bougé avec l'aide des contributeurs :

migration des sources de bitbucket vers github
migration des services jelix.org sur un nouveau serveur plus puissant
nouveau site, booster.jelix.org, qui référence les modules et plugins existants pour jelix, réalisés par des utilisateurs et contributeurs.
une nouvelle charte graphique du portail est en préparation, avec une toute nouvelle et belle page d'accueil. Le forum sera aussi migré vers la version 1.5pre de havefnubb.

Et puis je réfléchi en ce moment à la version suivante. J'ai bien sûr des tonnes d'idées d'améliorations, dont pas mal dorment dans le bug tracker depuis des lustres. Reste qu'il faut les prioriser, et puis décider si c'est le moment ou pas de casser des choses pour mieux les refaire. Voir de casser des choses pour profiter de ce qui est déjà fait ailleurs (comprendre, réutiliser des composants existants).

La mode est au 2.0 en ce moment : Symfony 2.0, CakePHP 2.0, et bientôt Zend 2.0. La concurrence est rude et soutient un rythme plutôt soutenu :-). Jelix était en avance sur certains points. Il va falloir garder cette avance, et rattraper certains retards. Un challenge continuel.

Par exemple, Symfony 2 vient d'intégrer le concept de "bundles", qu'on appelle "modules" ici dans Jelix. Jelix a ce principe de module^[1] depuis sa naissance en 2006, et on peut même dire que ça date depuis 2002 si je me souviens bien, puisque je l'avais implémenté pour la première fois dans Copix, l'ancêtre de Jelix. Symfony 2 et CakePHP 2 mettent aussi plus en avant l’interaction avec des objets représentant la requête et la réponse HTTP, un concept dominant dans Jelix depuis ses débuts. Mais Jelix a perdu du terrain par exemple sur les problématiques de cache. Ainsi il n'y a pas encore de prise en charge du mécanisme de cache de HTTP. Même si il est tout à fait possible de le faire actuellement "à la main". C'est quelque chose que l'on va améliorer (un patch est en review ;-)), entre autres choses (par exemple la couche ORM mériterait qu'on la rénove)..

Certaines améliorations vont pouvoir être faites sans casser les applis existantes, donc qui auront leur place dans une version 1.4 ou 1.5. Mais d'autres devront être faite dans une version 2.0 qui cassera quelques compatibilités. Cependant, pour le moment, la vision que j'ai d'un Jelix 2.0, ne remettra pas en cause fondamentalement les principes du framework. Je pense qu'il y aura moyen de faire des profondes modifications dans le noyau, sans rendre totalement incompatibles les modules existants. En effet, l'organisation des sources dans les modules Jelix est suffisamment structurée et éprouvée pour pouvoir ajouter d'autres types de fichiers sans bouleverser le reste. D'ailleurs, une des tendances des frameworks, d'après ce que je vois, est de structurer assez fortement l'organisation des sources, et de le faire de manière à ce que ce soit modulaire, extensible. Ce que fait Jelix depuis 6 ans maintenant ;-).

Bref, proposer toujours plus de fonctionnalités, en évitant de trop casser l'existant :-)

Une dernière chose, Jelix est un projet encore à "taille humaine". Tout contributeur potentiel peut y trouver sa place facilement^[2], et il y a de quoi faire ;-). Et nous, les contributeurs actuels et moi, sommes ouvert à toute discussion, pour permettre aux développeurs de construire leurs projets de manière toujours plus efficace et plus robuste.

Venez imaginer avec nous le framework du futur^[3]!

Notes

[1] Je dois reconnaître que Symfony pousse le concept un peu plus loin, mais il va suffire de peu de chose dans Jelix pour être "à niveau"

[2] ce qui est plus difficile dans un projet à plusieurs centaines de contributeurs

[3] en PHP bien sûr ;-)

Adieu Mr Ritchie

Laurentj — Fri, 14 Oct 2011 00:20:00 +0200

L'inventeur du langage C et co-créateur d'Unix, Dennis MacAlistair Ritchie, est mort. Malgré sa relative anonymie (vis à vis du grand public en tout cas), ses travaux ont énormément bouleversé l'informatique et continue d'influencer l'informatique d'aujourd'hui. Linux, les systèmes BSD (dont MacOS) et donc tout ce qui motorise les équipements les plus modernes comme les tablettes et les smartphones (Android, iOS), dérivent des créations de Dennis.

Le langage C et Unix sont les technologies qui ont marqués mes années d'études. J'ai découvert le C et le C++ au début de l'année 91 pendant mes années lycées, avec mon premier PC, équipé de Borland C++. J'ai tout de suite adoré (faut dire que ça me changeait du Basic 128 du TO9). Tellement adoré que les matières sur le C/C++ et Unix en IUT m'ont permis d'avoir des notes très élevées, moi qui était un élève moyen en général.

Je peux vous dire que quand j'ai pu enfin utiliser linux sur mon PC, puis quelques temps après, reléguer définitivement Windows sur une partition secondaire de mon disque dur, ce fut jour de fête.

Sale période en ce moment pour les figures de l'informatique, pour ceux qui ont marqué mes débuts en informatique. Même si pour moi Dennis a fait bien plus que Steve Jobs pour l'informatique.

Jelix : de Mercurial à Git

Laurentj — Thu, 01 Sep 2011 08:57:00 +0200

Depuis deux ans déjà, j'ai complètement abandonné subversion et utilisé Mercurial pour gérer le code source de mes projets. J'avais choisi Mercurial au départ parce que je devais l'utiliser pour contribuer à Firefox. J'avais alors apprécié le produit et l'avais adopté pour mes autres projets personnels. Pour les projets professionnels comme chez Zoomorama, et ou pour Jelix, nous (moi et mes collègues ou les contributeurs) avions étudié bien sûr Git avant de choisir Mercurial. À l'époque, Mercurial paraissait plus simple d'utilisation : des commandes plus claires, plus concises, moins verbeuse. Il avait aussi un meilleur support multi-plateforme en particulier sous windows. Ce dernier critère me paraissait essentiel par exemple pour Jelix, car j'avais des contributeurs sous Windows.

Au fil du temps, en particulier dans le projet Jelix, la gestion des branches de Mercurial me paraissait de plus en plus limitante. Une branche ne pouvant être supprimée, il est préférable de cloner le dépôt pour développer une nouvelle fonctionnalité, de manière d'une part à garder une branche "officielle" relativement stable, et d'autre part pour ne pas se retrouver au bout d'un moment avec 50 branches qui ne servent à plus rien. En fait, dans Mercurial, il est tout à fait naturel et normal de cloner un dépôt, un clone devenant implicitement une branche.

Mais à la longue, cette manière de faire devient assez lourde, on se retrouve avec de multiples clones sur son disque, même si on peut les supprimer quand on n'en a plus besoin.

L'alternative alors dans Mercurial est d'utiliser les "queues" de Mercurial, alias mq. C'est un système qui permet de gérer une pile de patchs. C'est quelque chose que j'apprécie particulièrement, et très utile pour les projets où le mode de collaboration impose la soumission de patchs pour être revues, avant de les committer dans le dépôt du projet. C'est ainsi que fonctionne le projet Mozilla et Jelix jusqu'à maintenant. L'autre avantage de mq est que cela évite d'avoir de multiples commits dans l'historique : on a au final un seul commit correspondant à un patch complet^[1] qui fonctionne, puisqu'il a normalement été revue par une personne tierce.

Cependant cela n'élimine pas un autre souci qui m'agaçait de plus en plus dans la gestion du projet, et qui est lié à la revue de code : il est compliqué de commenter les patchs. Que ce soit dans le Trac de Jelix ou sur Bitbucket, site sur lequel est hébergé le code source de Jelix, il n'y a pas la possibilité de commenter ligne à ligne. Ça alourdi la revue de code. Ça alourdi le processus de contribution.

À propos de Bitbucket, le site n'est pas trop mal. Mais les fonctionnalités ne sont pas aussi évoluées que son concurrent principal, Github. Il évolue, mais pas aussi vite que Github, et j'ai même l'impression que depuis son rachat par Atlassian, le projet est un peu moins actif. Des fonctionnalités comme la revue de code sont attendues depuis des lustres par beaucoup d'utilisateurs, mais on ne voit toujours rien venir.

Autre point, le couple Git/Github semble maintenant avoir une popularité qui surpasse celle des autres systèmes de "versionning".

J'ai donc décidé, pour Jelix, après en avoir discuté avec mes contributeurs, de passer à Git, et d’héberger le projet sur Github. J'ai été convaincu par la gestion des branches de Git, beaucoup plus souple. En effet, pour les utilisateurs de Mercurial, sachez qu'une branche dans Github s'apparente à un bookmark dans Mercurial (mais Bitbucket ne prend pas en charge les bookmarks). De plus, Github est fonctionnellement beaucoup plus puissant, avec un système de revue de code bien conçu. Cela va nous permettre d'avoir un "workflow" plus fluide pour les contributions, plus simple.

Bref, un nouveau chapitre se tourne dans l'histoire du projet Jelix, qui est de plus marqué par la sortie de la première version candidate de Jelix 1.3 ;-).

"Forkez" Jelix !

Notes

[1] pour les grosses contributions, on peut avoir plusieurs commits correspondant à plusieurs étapes de la modification, mais l'historique reste tout de même clair

Testez la beta de Jelix 1.3

Laurentj — Tue, 07 Jun 2011 18:51:00 +0200

J'ai sorti ce week-end dernier la beta du framework PHP Jelix 1.3. Pas mal de nouveautés sont disponibles.

Tout d'abord, quelques allègements dans la structure d'une application : il y a maintenant qu'un seul boostrap application.init.php pour tous les points d'entrées, et un seul répertoire temporaire. Ensuite, le script jelix.php pour lancer des commandes d'aide au développement, a été remplacé par un script cmd.php qui est placé dans l'application. Son utilisation est alors facilitée puisqu'on n'a plus le nom de l'application à indiquer en argument.

Il y a une nouvelle gestion des erreurs et des exceptions, plus puissante, mais aussi plus conviviale. Les messages d'erreurs sont en effet maintenant pris en charge par le système de log de Jelix, qui a lui aussi connu des évolutions (il a maintenant un système de plugin). On peut aussi fournir sa propre page d'erreur, permettant d'afficher un message "convivial" à l'utilisateur, avec le look de l'appli, plutôt qu'un message technique barbare sur une page blanche.

Deuxième grosse nouveauté : le développeur peut activer la toute nouvelle barre de debug pour avoir un affichage détaillé des erreurs, mais aussi des logs, de la liste des requêtes SQL, des messages SOAP, du contenu de la session etc. Et comme la barre est extensible, on peut développer/ajouter des plugins pour afficher d'autres informations.

Du travail a aussi été fait pour faciliter le développement de tests PHPUnit pour une appli Jelix. L'intégration de Simpletest, bien que toujours disponible, est considérée maintenant comme obsolète. D'ailleurs la migration des tests de Jelix vers PHPUnit a commencé.

Enfin le système de droits jAcl2 a vu quelques améliorations techniques, mais aussi au niveau de l'interface de gestion de droits. Et puis bien sûr, une tonne de petites améliorations ont été faite ici et là.

Pour la migration d'une application jelix 1.2, c'est une affaire de quelques minutes, grâce au système de mise à jour de Jelix, mais aussi parce que les API n'ont que très peu changé.

Cette beta a été développée et largement éprouvée lors de la réalisation d'un gros projet d'un de mes clients (et par des contributeurs bien sûr). Vous pouvez donc l'utiliser à priori sans soucis particulier :-). Et d'ici la version finale dans quelques semaines, je ne pense pas qu'il y aura de gros changements.

À propos de clients et de l'avenir de Jelix, il faut savoir qu'une bonne partie des contrats que j'ai eu au cours de ces 12 derniers mois, concernait des projets relatifs à Jelix (consulting, formations, développement d'appli...), et ce n'était pas que pour des petites boites (BNP Paribas, Transatel..). Ce framework ne cesse donc de se déployer en entreprise. Et je compte faire en sorte que pour les prochains mois, le mouvement s’accélère !

Bien souvent on me posait la question de la pérennité du framework. Après 5 ans d'existence, motorisant des gros sites comme Overblog, tout un tas d'intranets et de sites publiques divers et variés, j’espère que cette question se posera moins souvent :-) Merci à ceux qui ont fait confiance au projet, et à ceux qui contribuent, que ce soit au niveau du code ou au niveau communauté.

PS: j'ai oublié de dire que le manuel pour cette version 1.3b est disponible, complet, en français et en anglais, en ligne ou en PDF

Un an après

Laurentj — Sat, 04 Jun 2011 11:12:00 +0200

Cela fait grosso modo un an que j'ai commencé l'aventure de l'entrepreneuriat. Fin avril 2010, Zoomorama fermait ses portes. Quelques semaines de paperasserie plus tard, j'étais créateur d'entreprise, avec 4 autres anciens de Zoomorama dont un qui ne participe qu'au capital, étant parti vivre des aventures ailleurs.

Avec David Marteau, Olivier Gambier et Emmanuel Tabard, nous avons donc monté la société Innophi, qui propose du service dans le développement logiciels et applications web. Et depuis, nous ne sommes pas croisé les bras (d'ailleurs l'activité de ce blog s'en ait ressenti :-) ). Par le biais de nos réseaux respectifs de connaissances dans le milieu, nous avons pu trouver nos premiers contrats.

Après un an, les résultats sont encourageants, nous continuons donc l'aventure :-)

BlueGriffon 1.0

Laurentj — Tue, 10 May 2011 10:28:00 +0200

Septembre 2008, Daniel écrivait les premières lignes de code d'un nouvel éditeur HTML wysiwyg, BlueGriffon. L'idée du projet germait déjà depuis plusieurs mois dans le bureau (j'étais alors salarié de Disruptive Innovations), après l'arrêt du développement de Nvu. Nvu était le premier éditeur HTML de D.I, téléchargé à plusieurs millions d'exemplaires. Cependant l’impossibilité de poursuivre le développement de Nvu^[1] et la volonté de repartir sur des bases neuves et saines^[2], ont fait naître BlueGriffon.

Développer un tel logiciel n'est pas chose aisée. Cela demande du temps, du financement. Je me rappelle que les débuts n'étaient pas simple. Mais Daniel y est finalement arrivé ! Bravo Daniel !

Deux et demi après, voici enfin la première version stable de BlueGriffon, disponible gratuitement. Support de HTML5, de CSS3, basé sur le moteur de rendu de Firefox 4. Tout y est !

Il y a aussi plusieurs extensions disponibles pour ajouter des fonctionnalités évoluées. Elles sont pour la plupart payantes mais pas chères. N'hésitez pas, ça aidera à faire vivre le projet.

Notes

[1] pour diverses raisons, dont des raisons juridiques

[2] Nvu était basé sur le code de Mozilla Composer, datant du début de la fin des années 90, avec donc un long passif et utilisant une vieille version de Gecko

Jelix 1.2 et la suite

Laurentj — Wed, 19 Jan 2011 01:22:00 +0100

Le temps passe vite : presque un mois que j'ai sorti Jelix 1.2. Ça fait donc un mois que je me dis qu'il faudrait que j'en parle sur mon blog :-)

La liste des changements est assez conséquente. Pour faire rapide, elle comporte :

un nouveau système d'installation automatique des modules, ce qui est très agréable dés lors il faut installer un module tiers, ou pour mettre à jour une application en production, puisque ce système d'installation permet les mises à jour incrémentales.
le support de bases de données NOSQL, avec une API abstraite d'accès à ces bases
des améliorations dans jForms, le système de formulaire
le support de tout les noms des types natifs des bases SQL dans jDao (l'ORM)
enfin un composant de gestion de cache de donnée
et des dizaines d'autres petites améliorations

Sitôt la 1.2 sortie, sitôt le développement de la 1.3 commencé. Déjà fait :

nouvelle gestion des erreurs et des exceptions. Le logger jLog est utilisé pour les stocker. On peut maintenant fournir sa propre page d'erreur, et les erreurs ne s'affichent plus dans une div pas très jolie, mais dans une toute nouvelle debugbar, désactivable.
jLog, justement, accepte maintenant des plugins, pour étendre ses possibilités
Tout comme l'objet jResponseHtml (la "vue"). Ainsi les fonctions de "minification" des fichiers CSS/JS, reposant sur Minify, ont été migrées dans un plugin. Et la nouvelle debugbar est également un plugin.

Et il est prévu :

polissage de la debugbar et des plugins pour la debugbar
une petite refonte de la partie routage
des simplifications ici et là, du nettoyage de code
le début de la migration de Simpletest à PHPUnit pour les tests unitaires
et plein d'autres petites choses

Je vais essayer de sortir cette prochaine version assez rapidement, même si tout ce que j'ai prévu n'est pas développé à temps. Je veux en effet accélérer le rythme des releases. Le système de mise à jour de Jelix permettant des migrations plus douces. Et bien sûr, les mises à jour correctives pour les deux branches actives, 1.1 et 1.2, vont continuer à sortir. La 1.2.1 ne va pas trop tarder ;-)

Plus de H264 dans Chrome

Laurentj — Wed, 12 Jan 2011 11:25:00 +0100

Google vient de l'annoncer : le support du format video H264 va être retiré de Chrome (sachant que dans Chromium, la version opensource du navigateur, il n'y en avait déjà pas). Ce qui veut dire que Google va commencer à pousser fortement à l'utilisation de son propre format vidéo, WebM, déjà supporté par Firefox, Opera et d'autres navigateurs libres.

C'est une excellente nouvelle pour le web, et pour la balise video, que d'avoir un format, WebM, de qualité et non encombré de brevets logiciels connus. J'en avais déjà parlé il y a quelques mois, quand Google libérait ce format. Depuis, cette époque, même s'il n'a pas trop fait parlé de lui publiquement, WebM a progressé, tant au niveau logiciel qu'au niveau hardware, puisque des puces vont bientôt être disponibles.

Il ne reste "que" Internet Explorer et Safari (sur Macbook ou iphone) à ne pas supporter nativement WebM. Toutefois, avec IE9, il suffira d'installer le codec au niveau du système.

Attention cependant, ne crions pas victoire trop vite. Le retrait du support n'est pas encore fait, et l'annonce de ce retrait provoque une vague de mécontentement chez beaucoup d'utilisateurs et de développeurs, si on en croit les nombreux commentaires sur la news (les menaces de passer à un autre navigateur sont particulièrement risibles).

Sans parler du fait que c'est philosophiquement un peu en contradiction avec une précédente décision : celle d'inclure dans le navigateur, Flash, un produit propriétaire.

Espérons que Google tiendra bon dans sa décision sur WebM. Cela fait de lui un allié de plus à Mozilla, dans la lutte pour garder un web ouvert, dans sa volonté de ne pas supporter de formats propriétaires.

Mercurial/Git : ne pas "brancher" est une erreur

Laurentj — Sun, 07 Nov 2010 14:07:00 +0100

Et c'est une erreur que j'ai faite pour le développement de Jelix 1.2. Cela a conduit à un gros retard (presque 1 an !) sur la sortie de la version stable, avec toutes les conséquences qu'un retard de la sortie d'une version d'un projet peut avoir.

Pour mon framework, depuis longtemps je voulais y intégrer un système d'installation automatique, qui permette d'installer, d'initialiser (mise à jour de la base de données, de la configuration de l'application...) un module, et aussi de le mettre à jour très facilement.

Au début de l'été 2009, j'ai donc commencé à développer ce nouveau système d'installation de module. Quand j'ai commencé, je pensais que je n'en aurais pas pour longtemps. J'ai donc commencé à commiter les modifications... dans le trunk. Mais plus j'avançais, plus je découvrais des problèmes à résoudre. Et puis une fois qu'il était opérationnel, j'ai découvert à l'usage d'autres soucis, qu'il a fallu corriger. Tout ceci a pris au final beaucoup de temps. En ajoutant les longues périodes où j'étais trop occupé sur d'autres projets, le système d'installation a commencé à être stable qu'en juin dernier !

Parallèlement à ça, j'ai amélioré d'autres composants, des contributeurs ont proposé de nombreux patchs correctifs ou de nouvelles fonctionnalités, tout ça commité... aussi dans le trunk...

Bref, le trunk contenait à la fois des nouveautés et corrections diverses et variées, mais aussi un composant expérimental. Et ce composant impactant le fonctionnement interne du framework, il n'était pas possible de sortir des versions intermédiaires pour que les utilisateurs puissent profiter des nouveautés autre que ce système d'installation. Créer une branche à partir d'un "changeset" antérieur aux premiers commits du système d'installation, en y backportant les autres modifications, ou faire un "backout" de tous les changements apportés par le système d'installation, aurait demandé trop de travail, à l'époque où je me suis rendu compte de mon erreur.

D'habitude, j'essaye toujours d'avoir un trunk "stable", fonctionnel. Mais la sous-estimation du travail sur ce nouveau composant, l'envi de l'intégrer à la prochaine version, et certainement l'enthousiasme que j'avais à le développer, ont fait que je n'ai pas vraiment réfléchi à l'organisation de ce développement. Et au final le trunk a souvent été inutilisable durant cette période. Et je n'ai pas vraiment d'excuses, dans la mesure ou brancher et merger avec Mercurial (ou Git) ne pose en général peu de problèmes (ce n'est pas le cas avec subversion, ça n'a jamais vraiment fonctionner avec moi).

J'aurais donc du développer ce système d'installation dans une branche à part, laissant sur le trunk que les corrections de bugs et améliorations sur les autres parties de jelix. Ça aurait permis de sortir des versions intermédiaires de Jelix à partir du trunk, qui soient opérationnelles (et sans le système d'installation) . Et j'aurais pu continuer le développement du système d'installation dans son coin, pour ensuite intégrer les modifications de cette branche dans le trunk une fois qu'il était utilisable.

Les prochains gros chantiers sur Jelix seront donc développés dans des branches, afin de pouvoir sortir des versions stables de jelix plus régulièrement :-)

Jelix 1.2RC2, forum PHP et Rarangi

Laurentj — Sun, 07 Nov 2010 13:57:00 +0100

Ça fait quasiment un an que je n'ai pas parlé de Jelix sur mon blog (oups !). Ce n'est pas pour autant que le projet n'a pas avancé, bien au contraire !

Bien qu'initialement, la version 1.2 du framework était prévue il y a plus d'un an, elle ne va sortir que ce mois-ci. J'expliquerai pourquoi dans un prochain billet. Une "release candidate" est donc disponible, avec son manuel en ligne et en version PDF, le tout bien sûr, en anglais et en français. Cette version comporte une tonne de nouveautés.

Cette version 1.2 à venir est particulièrement stable car déjà utilisée sur pas mal de projets, ce qui a permis de remonter pas mal de bugs et améliorations à faire. Ainsi des préversions de Jelix 1.2 sont utilisées :

Dans quelques un de mes projets clients, réalisés ces derniers mois :-)
Dans des projets à venir d'Over-blog, réalisés donc par l'équipe d'Over-blog. Sachant que, pour ceux qui ne sont pas au courant, qu'ils utilisent Jelix depuis plusieurs années pour motoriser les blogs d'Over-blog ;-) (l'une des plus grosses plateforme européenne de blog).
Dans la future version 1.4 de HavefnuBB, un forum réalisé avec Jelix (et utilisé sur http://jelix.org ;-)) (la 1.3 utilise jelix 1.1)
Dans Rarangi, une alternative à phpdoc.

Bref, n'hésitez pas à tester et à utiliser cette RC2 !

Si vous voulez en savoir plus sur les nouveautés, rendez-vous au stand jelix au forum php, mardi et mercredi prochain. J'y serais avec d'autres contributeurs, dont Olivier "Foxmask" Demah, l'auteur de HavefnuBB.

Au sujet de Rarangi, c'est un autre projet qui me tiens à coeur et que j'avais commencé fin 2008, mais avec le manque de temps, ce n'est que maintenant qu'il commence à être opérationnel. PHPdoc commence à me gonfler sérieusement. Il est buggé de partout, compliqué à personnaliser, demande énormément de ressources. Et je n'accroche pas à doxygen. Bref, je compte m'en débarrasser définitivement sur jelix.org, en le remplaçant par Rarangi ces prochaines semaines, une fois que j'aurais finalisé les templates de détails des classes et fonctions, et amélioré la navigation. J'espère apporter une alternative sérieuse à phpdoc. Les futures versions embarqueront notamment un moteur de recherche et autres fonctionnalités inédites.

Une démo de Rarangi est visible en ligne. Il reste comme je l'ai dit, des améliorations de design et de lisibilité sur certains type de pages. N'hésitez pas à me faire part de vos impressions sur cette pre-0.1 :-) (et si quelqu'un veut bien se dévouer pour le design.. car comme vous le voyez, ce n'est pas ma spécialité :)

Diantre ! Un billet !

Laurentj — Thu, 14 Oct 2010 16:02:00 +0200

Quatre mois presque, sans blogger^[1] . Et là, d'un seul coup, paf, je publie un billet sans prévenir !

Désolé cher lecteur pour cette absence prolongée. Mais j'étais très très occupé ces derniers mois. La cause : après mon licenciement économique de chez Zoomorama, je me suis lancé dans un projet fou, un truc qui me trottait dans la tête depuis des années : créer une boîte. Et depuis, ça n'arrête pas, les journées sont plus que remplies. C'est du délire complet ! :-D

Je vous en reparlerai plus longuement une autre fois :-)

Notes

[1] Si on ne compte pas mes micro billets sur twitter :-)

Le moteur Javascript de Firefox rattrape son retard

Laurentj — Thu, 14 Oct 2010 15:30:00 +0200

Connaissez-vous http://arewefastyet.com/ ? C'est un site mis en place par l'équipe des développeurs du moteur javascript de Mozilla, SpiderMonkey. Il permet de suivre l'évolution des performances de ce moteur, en exécutant deux tests : sunspider et v8bench.

Il y a quelques jours, SpiderMonkey avait dépassé Apple Nitro (le moteur js de webkit) sur v8bench. Depuis hier, il est sur le point de le dépasser sur sunspider ! Il reste maintenant à battre le moteur de Google, V8. (Ce sont les versions de développement de ces moteurs javascripts qui sont testés)

Légende: courbe violette : spidermonkey (Tracemonkey + JaëgerMonkey); courbe rouge : apple nitro. courbe verte : google v8. courbe noire : spidermonkey (JaëgerMonkey seul)

À noter que ces résultats sont obtenus en lançant les tests non pas dans un navigateur, mais avec les versions "autonomes" des moteurs javascripts (hors navigateur donc). On a donc ici des performances pures, qui ne sont pas impactées par d'autres choses comme un moteur de rendu ou des scripts d'autres sites etc. Il est évident donc que vous n'obtiendrez pas des résultats comparatifs du même ordre, en les lançant dans un navigateur.

C'est ainsi que ce n'est pas encore parfait du coté Mozilla, puisqu'on obtient encore des écarts en lançant ces tests avec Firefox. Probablement que les tests dans Firefox sont biaisés à cause de l'exécution de code JS en dehors de la page de tests, puisque l'interface de Firefox est développée en partie en javascript.

Cependant, les améliorations entre Firefox 3.6 et Firefox 4 sont énormes, et les performances des moteurs javascripts des principaux navigateurs (IE9, Chrome, Safari et Firefox 4) sont maintenant équivalentes. On arrive à des différences qui ne seront pas perceptibles par l'utilisateur.

Je pense que d'ici quelques mois, on aura atteint les limites sur les améliorations dans les moteurs javascript.

la bataille des navigateurs va pouvoir aller se focaliser sur d'autres sujets :-) (accélération matériel etc..)

Pourquoi Firefox n'aura probablement jamais 100 au test acid 3

Laurentj — Thu, 24 Jun 2010 11:42:00 +0200

Parce que. Je vous l'ai déjà dit, ce test est débile ! :-)

Ok, plus sérieusement, et ça fait un bon moment que je voulais en parler (je sais je lag), la raison est toute simple : les trois derniers points à passer concernent le support des fontes SVG. Et Mozilla n'envisage pas de les implementer, au moins dans un avenir proche. Des développeurs, dont Roc, de Mozilla, en donne les raisons, sur son blog et dans les commentaires du bug. En gros :

Globalement les fontes SVG n'apportent techniquement rien par rapport aux fontes TTF ou WOFF
On peut faire des glyphes multi coloré et animé avec les fontes SVG, mais en fait, la spécification sur ces points est un cauchemar. D'ailleurs Opera et Webkit n'implémentent pas ces choses, et ont apparement un support très minimal des fontes SVG (juste pour passer le test acid3 ? ;-) )
Les autres types de fontes ont plus d'avantages :
- techniquement plus riche ("Hinting, rasterization with subpixel antialiasing, far richer support for glyph selection and text shaping") puisqu'elles permettre de créer des glyphes pour des caractères aussi complexes que les caractères arabes par exemple
- énormément plus de fontes déjà disponibles
- plus compacte
- support beaucoup plus large dans les logiciels (outils auteurs etc)

En conclusion, le support des fontes SVG ne leur semble pas très important pour le web, et pas très utile en fait.

Bien entendu, les supporters des fontes SVG pensent le contraire, et ne sont pas d'accord avec les arguments de Roc et cie. Honnêtement, je ne suis pas assez calé en typographie et sur les formats de fontes pour vous dire qui a raison et qui a tord.

Le fait est que Mozilla ne veut pas implémenter un truc qui leur semble peu utile et qui servirait juste pour avoir un meilleur score à un test. Ils préfèrent dépenser leur énergie à des choses plus importantes. Techniquement, je trouve que ça fait sens, très pragmatique, mais au niveau marketing, c'est sûr, c'est dommage.

Cependant, rien n'interdit à quiconque de proposer un patch. Si il est bon, il n'y a pas de raison (à mon sens) qu'il soit rejeté. Qui veut faire passer Firefox à 100 au test acid3 ?

Mise à jour 25/01/2011 : Alexander Limi, un des développeurs de Firefox, confirme le fait que Firefox n'aura pas 100%. Il rapport aussi, des propos de Boris Zbarsky (un des core-developers de Mozilla), expliquant que le support des fontes SVG dans les autres navigateurs est très minimes et tout juste suffisant pour afficher un score de 100% au test Acid3 (ce qui confirme les propos de Mitch 74 dans son commentaire plus bas).

IE9 a quasi rattrapé son retard

Laurentj — Thu, 24 Jun 2010 10:39:00 +0200

La troisième preview de IE9 est sortie. J'avoue être plutôt impressionné par toutes les améliorations qu'ils ont encore apporté. IE9, une fois que la version finale sera sortie, sera vraiment dans la cour des grands et aura rattrapé tout son retard technologiquement parlant.

Une partie des questions que je me posais il y a quelques mois ont maintenant une réponse : c'est implémenté.

Support de SVG (en partie)
éléments HTML5 <video>, <audio>, <canvas>,
support DOM largement amélioré: DOM traversal, DOM level3 core, DOM level3 events,
fontes téléchargeable WOFF, support complet CSS 2.1, support des media queries CSS3, selecteurs CSS3, bordures CSS3, background CSS3
un moteur javascript complet et aussi rapide que celui des autres navigateurs (je ne tiens pas compte des pouillèmes de milli secondes de différences entre chacun, à ce niveau, ce n'est plus tellement significatif)

Bref, tout plein de choses à se mettre sous la dent, avec un score acid3 qui grimpe à 83^[1]. Sans parler d'un support très avancé de l'accélération graphique matérielle.

Il lui manque toutefois encore des technologies qu'ont déjà les concurrents, comme :

les WebWorkers
les WebSockets
formulaires HTML5, HTML5 File API, et autres éléments de sections HTML5 probablement
transitions CSS3, transformations CSS3, animations CSS3, gradients,
WebGL
SMIL
Évènements DOM multi touch, support accéléromètre, support géolocalisation
base IndexedDb
API Drag and drop (à vérifier)

Et j'en oublie certainement^[2]. Ils ont donc encore du chemin à rattraper, et je ne doute pas que certaines de ces technos seront implémentés dans la version finale de IE9. Pour moi, on pourra qualifier IE9 de navigateur moderne. Car une chose est sûre, les développeurs web auront déjà suffisamment de technologies pour faire des sites modernes qui soient compatibles avec la majorité des navigateurs.

Le rouleau compresseur Microsoft a mis du temps à se mettre en route. Il est maintenant en marche, et pas qu'un peu. Mozilla, Apple, et Google ne devront pas s'endormir sur leurs lauriers. Cette nouvelle guerre de navigateurs initiée par Mozilla devient vraiment intéressante.

Notes

[1] Même si, comme je l'ai déjà dit, ce test n'est pas vraiment significatif

[2] je me suis en partie basé sur la liste des fonctionnalités qui sont implémentés dans Firefox 3.6 ou 4

WebM, le nouveau format video du web

Laurentj — Wed, 19 May 2010 22:07:00 +0200

Le petit monde des formats videos, et le web sont en pleine ébullition, avec l'annonce du nouveau format WebM. Mais avant de voir ce que nous promet WebM, faisons d'abord un petit retour en arrière dans l'histoire des codecs pour la balise video de HTML5.

Dans HTML5, un nouvel élément fait son apparition, l'élément <video>. La spécification ne spécifie pas de format particulier pour les fichiers vidéos, tout comme la spécification pour la balise img, bien que les premières versions de la spécification recommandait le format OGG/Theora. Cette recommandation a été retiré car les membres du consortium ne sont pas arrivés à se mettre d'accord à cause de soit disant doutes sur une possible violation de brevets logiciels dans Theora, et donc des procès planant au dessus de la date de ceux qui l'implémenteraient. Et puis certains voulaient plutôt imposer le format H264, plus performant.

Le problème du H264, c'est qu'il est encombré de brevets logiciels. Il faut aussi passer à la caisse, car il est sujet aux royalties, perçu par le consortium qui l'a créé, MPEG/LA. Et la somme à s'acquitter n'est pas minime puisque ça peut se chiffrer en millions de dollars.

Et comme je l'ai déjà dit dans des billets précédents, il est hors de question pour Mozilla d'intégrer le support de H264 dans Firefox, pour les deux raisons citées. C'est pourquoi Mozilla n'a intégré que le support de Theora, subissant alors nombreuses critiques et mauvaises prédictions, comme quoi Firefox allait mourir, que le web ne pourra se faire sans H264 parce que c'est le standard de l'industrie, parce qu'il existe des puces qui décodent le H264 (très utile dans les smartphones et autres mini ordinateurs). Mais Mozilla a tenu bon, car ils avaient un plan...

Parallèlement, Google rachète il y a un an si je me souviens bien, une petite boîte, ON2, qui est à l'origine de Theora, et qui a développé une nouvelle version du format, VP8, qui a des performances bien meilleures que Theora, comparable à H264 selon Google.

Ils avaient ensuite annoncé il y a quelques semaines qu'ils allaient libérer le format VP8, et qu'il n'y aurait pas de royalties dessus, et à priori, qu'il n'est pas encombré de brevets logiciels. Cette annonce ne fit pas énormément de bruit, car finalement, ils n'ont pas vraiment détaillé. En tout cas, rien ne présageait le coup d'éclat d'aujourd'hui.

Ce coup d'éclat, c'est l'annonce de la libération de VP8. Mais pas seulement. Mozilla en a fait un billet. On peut dire que Google, Mozilla et beaucoup d'autres ont bien caché leur jeu depuis des semaines (aaah les NDA..). Jugez plutôt.

Il ne s'agit pas seulement d'un codec, mais d'un format complet, WebM, étudié pour le web, avec un conteneur Matroska simplifié, un codec video VP8, un codec audio, Vorbis
Les sources sont disponibles sur http://www.webmproject.org/
Mozilla propose déjà en téléchargement une version experimentale de Firefox, ayant le support de WebM. Vous pouvez la tester avec une démo de Paul Rouget.
Idem pour Chromium, dans les heures à venir
Youtube a commencé à convertir ses vidéos !

Plus fort encore, une liste a été publiée, présentant des acteurs majeurs qui vont supporter WebM . On y trouve bien sûr des logiciels comme Chrome, Firefox, Opera, mais aussi des gens comme Skype ou encore Adobe, qui indique qu'ils vont supporter WebM dans Flash ! Il y a aussi Microsoft qui a annoncé le support dans IE9, si on installe le codec dans windows.

Et ce n'est pas tout, il y a aussi des fabricants de puces, comme AMD, Texas Instrument ou NVidia, qui vont donc produire des puces de décodage VP8 ! Du très lourd !

Google a donc frappé un grand coup, très fort et bien préparé. Il y a tous les ingrédients pour concurrencer H264 avec succés. Un coup dur je pense pour les supporteurs du H264 comme Apple (qui n'a toujours pas réagi à l'heure où j'écris ces lignes).

Je pense aussi que, contrairement à Theora, et vu l'annonce, VP8 va rapidement percer. Même coté matériel. Si il y a déjà des supporteurs comme AMD ou NVidia, et qu'il y a des expérimentations sur Youtube, c'est que Google a commencé à traiter avec ces fabricants, pour avoir des puces d'encodage le plus rapidement possible, afin de convertir les millions de vidéo du site YouTube en WebM. Car je doute qu'ils le fassent uniquement de manière logiciel, ce serait trop lent. À coté de ça les navigateurs intègrent déjà WebM, donc il y a fort à parier que ce sera disponible dans les prochaines versions stables de Firefox, Chrome et Opera.

Bref, à la fin de l'année, on pourra je pense commencer à utiliser le format VP8 en lieu et place de Theora. Et de H264.

Une très très bonne nouvelle donc pour le monde du web, que ce nouveau codec vidéo libre et performant.

Batterie de macbook morte

Laurentj — Sat, 15 May 2010 12:42:00 +0200

Depuis quelques semaines, la batterie de mon macbook ne durait plus que 45 minutes environ, sachant que neuve, je pouvais facilement pianoter pendant 3 heures. En fait, la durée de fonctionnement a littéralement chuté en quelques semaines, puisqu'il n'y pas si longtemps, je pouvais encore tenir 2 heures.

Cela m'étonnait, car la batterie aujourd'hui n'a que 16 mois. Sur twitter, Nicolas m'avait suggéré de faire un reset du SMC mais je n'ai pas vu d'amélioration perceptible.

Et puis depuis ce matin, impossible de rester plus de 10 minutes avec la batterie. Bien que l'indicateur indique qu'elle est chargée à 75%, le macbook s'éteint au bout de 10 à 15 minutes, sans prévenir évidement.

Il y a eu par le passé des problèmes de ce genre, avec des batteries quasi neuve, et il fallait mettre à jour le firmware du SMC mais le mien est déjà à jour. On peut aussi calibrer la batterie mais des charges et des décharges complètes, c'est ce que je fais quasi tout le temps (ce qui n'est pas bien, voir plus bas).

Et puis j'ai découvert cette page qui donne des informations et conseils pour la durée de vie des batteries macbook.

Les batteries récentes d'Apple sont en lithium-polymère, et donc ont des caractéristiques différentes des batteries classiques Lithium-Ion :

elles n'aiment pas le chaud, ça réduit la durée de vie.
la durée de vie chute rapidement quand elle approche de la fin de vie, contrairement aux autres types de batteries, qui faiblissent sur une plus longue periode.
Apple considère qu'après 300 cycles de charges, la batterie est usagée et doit être remplacée. Même si à 300 cycles de charge, une batterie correctement entretenue devrait être à 80% de sa capacité de charge originelle, toujours selon Apple.
Il faut éviter des cycles de charge et décharge complète, contrairement à ce qu'il faut faire pour des types de batteries plus anciennes. D'une part, cela est inutile car elles n'ont pas ces problèmes d'effet mémoire que l'on trouve souvent, et d'autre part, ça reduirait en fait leur durée de vie.

J'ai installé le petit logiciel Coconut Battery pour avoir des informations sur l'état de ma batterie :

304 cycles de charges (en 16 mois)
capacité de charge : 1662 mAh au lieu de 4100 mAh pour une batterie neuve, soit une capacité qui n'est plus que de 40% (au lieu de 80%)

En tenant compte du fait que j'ai bien "tabassé" le macbook pendant 16 mois, avec des compilations à répétitions (donc fortes chaleurs), et un fonctionnement d'au moins 12h par jour (dans la semaine), que j'ai régulièrement fait des charges/décharges complètes (au moins 1 jour sur deux, parce que je bosse souvent dans le rer), ces chiffres ne m'étonnent finalement pas.

Je dois me rendre à l'évidence : ma batterie est morte.

Je vais attendre un peu avant de la remplacer, car il n'est pas certain que je garde le macbook, il n'est en fait pas à moi mais à Zoomorama. Ça va dépendre du commissaire priseur qui est en charge de liquider le matériel et mobilier de Zoomorama, si il va accepter ou non qu'on lui rachète directement nos machines.

Zoomorama, the end

Laurentj — Fri, 30 Apr 2010 11:23:00 +0200

Depuis le courant de la semaine, Zoomorama est en liquidation. Nous n'avons pas su trouver le bon modèle économique à temps, et du coup, plus d'argent pour continuer l'aventure. C'est assez dommage car je suis intimement convaincu que la technologie était très bonne. Les développeurs web avaient à leur disposition une technologie de zooming, non pas sur une simple photo, mais sur un document entier, document en XML et CSS, et avaient accès au DOM du document pour le modifier dynamiquement, comme n'importe quel page web. David Marteau et Olivier Gambier avaient donc réussi le tour de force d'avoir une technologie de zooming proche de la philosophie des standards du web (ce que n'avaient pas nos concurrents).

J'ai passé un peu plus d'un an et demi dans une équipe formidable, composées de véritables talents. Une dream team. Merci à eux. C'est donc avec un certain regret d'être obligé de s'arrêter là.

Certains membres de l'équipe sont déjà dans les starting blocks pour enchaîner dans d'autres sociétés, comme Akamai. Et d'autres, comme moi, ont des projets plein la tête. Mais je vous en parlerai en temps utile ;-)

Vous pouvez aller lire le billet d'Olivier et celui de Franklin pour en savoir un peu plus sur cette fermeture.

Modifier un fichier ini en php

Laurentj — Mon, 29 Mar 2010 17:00:00 +0200

J'aime bien utiliser les fichiers ini pour tout ce qui est configuration. En php, c'est très rapide à charger avec la fonction parse_ini_file (beaucoup plus rapide qu'un fichier de conf en php, avec un facteur 10 je crois), et puis c'est très simple à modifier, la syntaxe étant minimaliste.

C'est pourquoi j'utilise des fichiers ini dans jelix, et pas des trucs du genre yaml, syntaxe que je trouve hyper compliquée ^[1], en tout cas trop pour l'utiliser pour un fichier de conf ^[2].

Dans Jelix, il y a des outils pour le développeur pour l'aider à construire son appli, et il arrive donc que ces outils aient à modifier un fichier ini. J'avais fait une première implémentation naïve dans une classe, jIniFile permettant d'enregistrer un fichier ini : une méthode pour lire (avec parse_ini_file), une autre pour écrire en lui passant un tableau de clés/valeurs, et le nom du fichier.

Problème de cette classe : on perd tous les commentaires et les sauts de lignes à la lecture avec parse_ini_file. C'est assez fâcheux pour un fichier de configuration, où les commentaires peuvent être nécessaires.

D'où une autre classe jIniFileModifier, qui permet de charger, modifier et enregistrer un fichier ini, sans perdre les commentaires et les espacements. Elle permet même de supprimer une clé/valeur, avec le commentaire qui lui est associé (le commentaire qui la précède). Cette classe supporte les sections et les tableaux de valeurs. En fait, j'ai fait en sorte qu'elle soit compatible au maximum avec le format ini utilisé par parse_ini_file^[3].

Vous pouvez l'utiliser seule dans vos projets, elle est totalement indépendante de Jelix. Par contre, ne l'utilisez pas pour une simple lecture, ce n'est pas son objectif principal, parse_ini_file est beaucoup plus performante pour ça.

Notes

[1] pour preuve : la spécification YAML : 77 pages A4, celle du XML : 30 pages...

[2] si j'avais à choisir un format pour stocker des options de manière arborescente, je choisirais json

[3] il y a en effet quelques variantes, suivant les logiciels

Surcouf, c'etait mieux avant...

Laurentj — Fri, 19 Mar 2010 15:03:00 +0100

Hier, je me suis fait une petite balade au magasin Surcouf, avenue Daumesnil à Paris. Ça fait au moins un an que j'y suis pas allé. Et j'ai découvert un magasin refait à neuf, avec des beaux stands au design moderne. Et du vide.

Qu'ont-ils fait de mon magasin préféré des années 90, avec ses allées étroites, ses stands et rayons bondés de gens, mais aussi rempli de matos ? Elle est où ma caverne d'ali-baba de centaines de m2 où j'étais sûr de trouver mon bonheur ? Il est passé où le royaume du geek, où j'écarquillais les yeux tous les deux mètres à la vue d'une nouveauté ou d'un truc dont j'ignorais l'existence ? Elle est où cette ambiance "circus", totalement décalée, originale, qui existait auparavant ?

Surcouf est devenu un magasin aussi aseptisé que ces autres magasins des chaînes d'électroniques grand public (boulanger, saturne ou autre, voir même la fnac). Je n'y vois plus trop grand d'intérêt d'y aller en fait. Mis à part le fait qu'ils ont peut être quand même encore un peu plus de choix que les grandes chaînes et qu'ils sont dans un quartier encore dédié aux geeks avec tout ces petit magasins d'informatiques autour.

Fini la magie en tout cas.

M'enfin ça ne m'a pas empêcher d'y faire une petite emplette...

Open To Choice

Laurentj — Sun, 07 Mar 2010 13:43:00 +0100

Depuis quelques années, le web se démocratise énormément. Chaque jour des milliers de nouveaux internautes débarquent sur la toile. Bien entendu, la grande majorité d'entre eux ne sont absolument pas au fait des techniques. C'est ainsi que bon nombre d'entre eux ne savent pas qu'il y a autre chose que facebook sur la toile (la preuve avec ce billet de readwriteweb, qui est apparu quelques heures en tête de la recherche "facebook login", et des internautes débarquant alors sur ce site croyant à faire à une refonte du site facebook), ou encore ne savent pas ce qu'est une URL.

Mais ce n'est pas tout, bon nombre d'entre eux ne savent pas ce qu'est un navigateur, ou ne savent pas qu'ils peuvent choisir leur navigateur.

Depuis quelques jours, les utilisateurs européens de windows 7 se voient proposer une page permettant de choisir leur navigateur web. C'est déjà un pas, mais peut être pas suffisant, puisque cela n'explique pas ce qu'est un navigateur, et comment faire le bon choix.

Aussi Mozilla a lancé le site http://opentochoice.org, afin de combler ce manque d'information, et tente de réponde aux questions, et explique notamment pourquoi choisir son navigateur est important.