jy[B]log

En 2003, j'ouvrais le site xulfr.org, pour publier de la documentation sur XUL, et pour promouvoir cette technologie, utilisée par Mozilla pour réaliser l'interface du navigateur Firefox entre autres, et utilisée donc dans le développement des extensions de ce navigateur.

Depuis quelques années, Mozilla abandonne peu à peu XUL au profit de HTML5. D'ailleurs nombre d'innovations apparues dans XUL ont évolué et ont été standardisées en dehors de XUL, pour être utilisable dans le monde web : modèle de boite flexbox en CSS, WebComponents avec le shadow tree, etc..

Depuis quelques années donc, je délaissais peu à peu l'animation et la maintenance du site xulfr.org. On peut même dire que le site était complètement à l'abandon ces 2-3 dernières années. Et plus le temps passait, plus je songeais à fermer le site. D'ailleurs il y a un peu plus d'un an, j'avais annoncé sur le site sa prochaine fermeture (news que j'ai supprimé depuis).

En fait, je voulais fermer le site, non pas parce que je voulais qu'il disparaisse, mais parce que sa maintenance devenait de plus en plus problématique, et que je n'avais plus le temps de m'en occuper. En effet, les applications sur lesquelles étaient basées le site, comme Dotclear pour la partie news, ou Phorum pour la partie forum, nécessitaient d'être mis à jour. Cependant la mise à jour de Dotclear demandait pas mal de boulot, puisque c'était une vieille version 1.2.3 datant de 2005, et celle de Phorum était impossible puisque cette application n'est plus maintenue depuis 2008. J'avais pourtant bien fait quelques évolutions il y a quelques années, en remplaçant le wiki, basé à l'origine sur PHPWiki, par une application wiki fait maison, mais que je n'ai jamais eu le temps de terminer (entre autre, il n'était pas possible d'éditer les pages, ce qui était balo pour un wiki).

Bref, xulfr était basée sur des applications, certainement trouées au niveau sécurité, mais aussi qui devenaient de plus en plus incompatible avec les versions successives de PHP. J'avais dû les patcher par le passé pour corriger quelques incompatibilités au rythme des déménagements d'un serveur à l'autre. Mais la semaine dernière ça a été la catastrophe, en installant le site sur une Debian récente avec PHP 5.6 (le serveur actuel sur lequel il est installé devant être éteint ces prochaines semaines). Le bon vieux dotclear provoquait des erreurs dans tous les sens. Phorum tournait tant bien que mal. Le wiki tenait presque la route.

Manquant de courage, j'avais décidé alors Lundi de ne pas faire cette migration vers un nouveau serveur, et de fermer définitivement le site : une page bouchon avec un joli message d'adieu sur mon serveur perso, des redirections et des configurations "http 310 gone" bien placées, un message sur twitter et l'affaire était pliée.

Sauf que j'ai eu des gros remords. Et d'anciens camarades de jeu faisaient part de leur tristesse sur twitter, de voir partir ce site (même si plus personne ne l'utilise vraiment, si j'en crois les statistiques :) ). Et puis faire disparaitre une partie de l'histoire française du projet Mozilla, c'était tout de même dommage.

Alors, du courage venu de je ne sais où s'est immiscé en moi, du temps s'est magiquement libéré, et j'ai retroussé mes manches pour faire fonctionner ce satané site avec une version récente de PHP. Mais comment ?

L’intérêt principal du site, actuellement et pour l'avenir, est, il faut l'avouer, purement "historique" et archéologique. De plus, n'ayant plus le temps ni l'envie de m'en occuper (publier des news, modérer les messages du forum etc), avoir xulfr.org en lecture seule serait une bonne chose.

J'ai donc eu l'idée de faire la migration autrement : au lieu de faire des mises à jour impossibles des vieilles applications, pourquoi ne pas les virer et faire quelques scripts PHP tout bêtes pour simplement afficher le contenu de la base de donnée ? Cela fera déjà beaucoup, beaucoup moins de code à gérer lors d'un prochain changement de version de PHP, mais aussi plus rien à modérer. (L'utilisation de fichiers statiques a aussi été envisagée, mais vu le nombre de messages dans le forum ça aurait été monstrueux en terme de nombre de fichiers et donc de la place que cela aurait demandé).

J'ai donc viré Dotclear, Phorum et toutes autres applis legacy, et j'ai développé en quelques heures des scripts tout neufs qui ne font au final que de l'affichage. Et quelques modules et contrôleurs jelix plus tard, le site était de nouveau en ligne. En lecture seule.

Xulfr.org n'est plus actif. Mais Xulfr.org reste accessible pour quelques années encore !

I'm pleased to announce the release of SlimerJS 0.10!

SlimerJS is a scriptable browser. It is a tool like PhantomJS except it is based on Firefox and and it is not (yet) "headless" (if some Mozillians could help me to have a true headless browser ;-)...).

This new release brings new features and compatibility with Firefox 46. Among of them:

• support of PDF export
• support of Selenium with a "web driver mode"
• support of stdout, stderr and stdin streams with the system module
• support of exit code with phantom.exit() and slimer.exit()
• support of node_modules with require()
• support of special files (/dev/* etc) with the fs module

This version fixes also many bugs and conformance issues with PhantomJS 1.9.8 and 2.x. It fixed also some issues to run CasperJS 1.1.

See change details in release notes. As usual, you can download SlimerJS from the download page.

Note that there isn't anymore "standalone edition" (with embedding of XulRunner), because Mozilla ceased to maintain and build XulRunner. Only the "lightweight" edition is available from now, and you must install Firefox to run SlimerJS.

Consider this release as a "1.0pre". I'll try to release in few weeks the next major version, 1.0. It will only fix bugs found in 0.10 (if any), and will implement last few features to match the PhantomJS 2.1 API.

Il y a 20 ans (en septembre 1994 donc), je faisais ma rentrée à l'IUT informatique d'Orsay. Cela faisait déjà quelques années que j'avais découvert les ordinateurs et appris à programmer : Basic sur Thomson TO9, C/C++ sur PC (avec Borland ;-)), assembleur/RPL sur HP48... Bref, j'entrais dans un monde qui ne m'était pas totalement inconnu.

Dans un billet précédent, j'avais fait un comparatif d'outils d'intégration continue. Après quelques jours d'utilisation, revirement de décision, j'ai finalement abandonné Jenkins...

Once upon a time, on the december 10th, 2012, I discovered CasperJS and PhantomJS and this was the beginning of a great history....

Le Mobile World Congress se termine aujourd'hui, et on peut dire que Mozilla a fait beaucoup parler de lui avec son nouveau système d'exploitation pour mobile, Firefox OS. Ça a démarré par une conférence de presse la veille de l'ouverture du salon. Mozilla annonçait alors que 18 opérateurs téléphoniques de par le monde, et 4 fabricants de mobiles (Alcatel, LG, ZTE et Huawei) allaient proposer à leurs clients, dans les mois à venir, des téléphones utilisant Firefox OS. Durant le salon, Sony a aussi déclaré se joindre à la partie, en publiant sur un blog comment installer Firefox OS sur un XPeria.

Bref, Mozilla, avec son stand impressionnant, n'est pas passé inaperçu. Et c'était le but.

Par contre, comme à l'accoutumé, à coté des gens approuvant à 100% le nouveau système de Mozilla, j'ai pu remarquer pas mal de scepticisme parmi les commentateurs en tout genre, la presse etc.

1) Face à Google (Android) et à Apple (IOS), Mozilla a peu de chance

Mozilla aurait peu de chance si la fondation attaquait de front ces deux mastodontes, c'est à dire sur le même marché, ciblant les mêmes clients. Ce n'est tout simplement pas le cas. Mozilla cible en priorité les marchés émergents : Amérique du sud, certains pays d'Asie, et probablement l'Afrique. Elle cible les pays où le taux d'équipement en smartphone est très bas, voir quasi inexistant. Ce sont des pays où un Iphone ou un Galaxy SII n'ont que peu de chance de s'y vendre, à cause des revenus plutôt bas dans ces régions du monde.

On pourrait dire donc que Mozilla vise la complémentarité. La fondation vise surtout à promouvoir le choix sur le mobile, comme elle l'a fait sur le desktop au temps où IE était utilisé par 95% des internautes. Elle avait Firefox Mobile sous Android. Elle a maintenant un système d'exploitation alternatif pour les mobiles, qu'elle propose aux intégrateurs, sans royalties.

2) Je suis déçu des spécifications des téléphones Firefox OS, ça ne me tente pas d'en acheter un

Si vous vous dites cela, c'est que vous n'êtes tout simplement pas la cible. Malgré les bonnes ventes des Iphone et autre Galaxy, n'allez pas croire que tout le monde a autant les moyens que vous pour en acheter un.

Certes, les téléphones annoncés avec Firefox OS ne sont pas très puissants (1GHz, mono-core ou dual-core maxi, 512Mo de RAM..). Mais rappelez-vous : Mozilla vise les marchés émergents. Donc nécessité de fournir des téléphones bas prix, donc peu puissants.

Il se pourrait même que ces téléphones intéressent des gens dans nos pays "riches". D'une part à cause de la crise, et d'autre part, je suis persuadé que beaucoup de gens n'ont pas besoin d'un quad-core dans leur poche. En les observant dans le train ou ailleurs, que font-ils la plupart du temps : téléphoner, envoyer des sms ou des mails, jouer à des petits jeux, lire leurs messages facebook ou twitter.

Très franchement, y-a-t-il vraiment besoin d'un dual-core, voir un quad-core pour faire ces tâches toutes simples ? Si le système est optimisé et peu gourmand, NON. Vous rappelez-vous des machines d'il y a 15 ans ? Elles étaient 10 fois moins puissantes, prenait 10 fois plus de place, mais on pouvait y faire le même genre de tâches sans aucun souci.

Même moi je trouve que mon téléphone, un Galaxy SII, est "overkill" pour l'usage que j'en fais.

3) C'est motorisé par Firefox ? encore un téléphone qui va laguer lol mdr ptdr webkit roxor

Vous savez quoi ? Vous devriez essayer un smartphone motorisé par Firefox OS. Là où un système Android devient vite pénible à utiliser sur les téléphones ciblés par Mozilla, FirefoxOS est plutôt véloce ! Moins de surcouches logiciels et un moteur (celui de Firefox), qui a connu d'énormes progrès en terme de performances et d'occupation mémoire : c'est la recette de Mozilla pour faire tourner correctement son système sur des petites configurations. D'ailleurs, ces améliorations faites pour Firefox OS, profitent également à la version Mobile et à la version Desktop de Firefox !

J'ai pu expérimenter un téléphone Firefox OS pendant une semaine au début de l'année ^[1] et j'ai été convaincu. Ok, c'est un avis tout à fait subjectif, surtout pour quelqu'un comme moi qui contribue à Mozilla depuis presque 10 ans, mais, même si j'étais plutôt excité par ce nouveau projet à l'automne 2011 quand j'ai vu les premières versions tourner "en vrai", j'avoue que j'étais un peu sceptique. Où allait Mozilla avec ce truc ?! Maintenant je le sais. J'ai pu expérimenter. Et je suis maintenant rassuré et conquis !

Le seul gros point faible que je trouve à mes yeux, c'est tout ce qui utilise la 3D (et donc WebGL) : c'est lent. Mais ce genre de chose est dû au processeur graphique faiblard de ces téléphones, plutôt qu'à Firefox OS.

4) Je trouve l'interface peu innovante

Et bien faites-en une ! Non, je ne plaisante pas. Non je n'ironise pas. Je suis très sérieux.

Il est vrai que l'interface, le "bureau" du système n'est pas très innovant par rapport à la concurrence. On y retrouve les mêmes manières d'interagir avec le téléphone qu'avec les autres smartphones, des applications plutôt normales et simples (quoique, l'application de recherche intégrée de Everything.me apporte une fonctionnalité originale). Mais il y a plusieurs raisons à cet état de fait :

1. Entre les premières lignes de code du projet, et cette annonce au MWC, il s'est passé 1 an et demi environ. 1,5 an pour développer un système d'exploitation mobile complet. Le noyau, les applications, et toutes les API pour les développeurs d'applications. C'est peu de temps. Très peu. Mes amis développeurs qui bossent à plein temps sur le projet dans les bureaux parisiens de Mozilla peuvent vous en parler^[2] ! Même si ils réutilisent des briques open-source (noyau linux, moteur Gecko de Firefox..). Les délais étant très courts, l'innovation dans l’interaction homme-machine a été remise à plus tard.
2. Cela permet aussi aux futurs utilisateurs de se retrouver en terrain connu, ou d'apprendre à utiliser un smartphone "comme sur les autres". Rappelez-vous, la cible, ce n'est pas le "power-user" du mobile, ce n'est probablement pas vous, mais les personnes qui n'ont jamais eu de smartphones.
3. FirefoxOS est un système maléable. Son originalité est que toutes les applications sont en HTML5/JS/CSS. Et "toutes" cela comprend vraiment tout : l'appli pour téléphoner, le "bureau", la barre d'état etc. Bref, toute l'interface. Comme l'a dit mon pote Paul Rouget, "le moindre pixel de l'écran est affiché par une application HTML".

Vous n'êtes pas content de l'interface ?

• En tant que développeur, faites vous plaisir, contribuez au projet Gaia, l'interface de Firefox OS ! Contribuez aux développement des applications fournies en standard ! Le système de Mozilla est 100% Open Source !
• En tant qu'entreprise innovante, lancez-vous ! Développez un remplaçant à Gaia ! Un nouveau marché s'ouvre à vous !
• En tant que "power user", un peu de patience, et probablement vous aurez le loisir de remplacer les applications standards par d'autres alternatives :-)

Tenez, d'ailleurs, en quelques heures, un développeur a implémenté une nouvelle manière d'utiliser le clavier virtuel. Firefox OS n'est-il pas sympa ?

En d'autres termes, l'innovation dans Firefox OS ne se trouve pas dans l'interface, mais dans le système et dans sa philosophie. C'est 100% HTML5. Ça repose sur les standards du Web. N'importe quel développeur web peut créer une application HTML5, ou même porter une appli existante en quelques heures seulement, voire quelques minutes (si elle est déjà prévu pour s'afficher correctement sur mobile). Et il a en plus à sa disposition des dizaines d'API innovantes pour développer des fonctionnalités originales dans ses applications web !

5) Chez Mozilla ils ont encore confondu renard de feu et panda roux

Oui, bon. Le logo mis en avant pour Firefox OS, légèrement inspiré de celui de Firefox, est un renard. Cela ne fait aucun doute. Certains avancent même que chez Mozilla, ils sont vraiment nuls en zoologie. Mais vous remarquerez que depuis Firefox 1.0, la bestiole sur le logo de Firefox est vraiment un renard (si vous ne me croyez pas, allez vraiment voir à quoi ressemble un panda roux). Et que si Mozilla a parlé de Panda Roux, c'est d'une part à cause de la traduction de "Firefox", et d'autre part pour faire parler des pandas roux, espèce menacée.

Et puis entre nous, on s'en fout, hein :-)

La grande question, en ce moment, est plutôt : mais quand est-ce que Geeksphone va enfin vendre ses téléphones Firefox OS pour développeurs ?!

Pour tester certains composants du framework Jelix, comme la partie "routage", j'ai besoin d'avoir des paramètres serveurs correctement définis, en particulier dans la variable globale $_SERVER. En effet, les tests étant lancés en ligne de commande avec PHPUnit, $_SERVER ne contient pas du tout la même chose que lorsque le script PHP est lancé par un serveur HTTP. Pire, pour une même URL, nous n'avons pas la même chose selon si PHP est lancé en CGI/FPM, ou si c'est le module PHP pour Apache qui est utilisé.

Bref, cela devient fastidieux dans un environnement de tests en ligne de commande de simuler un contexte HTTP.

C'est pourquoi j'ai crée cette petite bibliothèque, FakeServerConf. On lui indique le type de serveur que l'on veut simuler, et l'url que l'on demande (avec la méthode GET, POST, DELETE...), et FakeServerConf rempli correctement $_SERVER, $_GET et $_POST avec les bonnes valeurs. Vous n'avez plus qu'à tester vos classes qui utilisent ces variables. Et vous pouvez de plus tester avec les différents types de serveurs pris en charge par FakeServerConf. Pour l'instant il n'y a qu'Apache+mod_php et Apache +cgi ou fpm.

Il y a un mois je sortais les dernières versions correctives de toutes les branches actives du framework Jelix. Et ça fait un mois que je pensais à écrire ce billet :-).

La raison de ce billet est que ces versions correctives inclues non seulement quelques corrections de bugs comme d'habitude, mais aussi une amélioration dans le système d'authentification de Jelix : il peut désormais utiliser la nouvelle API de mot de passe que proposera PHP 5.5. Une bibliothèque en PHP, password_compat permet de l'utiliser dés maintenant en attendant la sortie de PHP 5.5 et est incluse dans Jelix. J'y ai d'ailleurs apporté quelques modifications pour l'utiliser sur Debian Squeeze.

Pourquoi utiliser cette API ? Parce qu'elle est très simple à utiliser, tout en apportant un hachage fort des mots de passe en utilisant l'algorithme Blowfish par défaut. Dans PHP, on a déjà des fonctions pour encrypter fortement du contenu. Mais il faut avouer que c'est particulièrement compliqué à utiliser.

Pour en savoir plus sur cette nouvelle API, voir l'article de Pascal Martin.

Abandonnez md5, sha1 pour hacher vos mots de passe et les stocker en base de données, ou au moins ajoutez un sel aléatoire. Préférez SHA2 ou supérieur, bcrypt, blowfish, qui sont plus robustes aux attaques de type "brute force", aux "rainbow tables" etc...

Diantre ! 10 mois que je n'ai pas parlé de mon framework PHP Jelix sur mon blog ! Cela date de... la sortie de Jelix 1.3 :-) Et dire que quelques semaines après la 1.3, j'avais annoncé sur la mailing-list que j’accélérerais la cadence des sorties à 2-3 mois. C'est raté. Il faut croire que le rythme est bloqué à 10 mois.

Donc voilà Jelix 1.4 avec sa tonne de nouveautés : cache HTTP, autoload PSR0, templates virtuelles, amélioration de la prise en charge des codes langues, des modules de plus en plus autonomes etc...

Le retard de cette sortie est due à plusieurs choses :

• Déjà, les vacances d'été, chantiers chez moi etc : j'ai été souvent offline ces dernières semaines :-)
• La faute à pas de temps
• La mise en place de docs.jelix.org
• La libération du code source des sites de Jelix.org

La faute à pas de temps : en effet, j'ai eu un contrat de plusieurs mois (qui se termine), sur un projet hyper intéressant (à base de XUL/javascript), mais plutôt éloigné de chez moi. Donc beaucoup de temps de trajets et de fatigue. Résultat, avec les autres tâches à coté, le projet n'a pas avancé aussi vite que j'aurai voulu

La réalisation du site http://docs.jelix.org a permis de migrer les manuels, du wiki Dokuwiki vers un nouveau système de wiki basé sur Git, et que j'ai développé avec Jelix bien entendu : Gitiwiki. J'en parlerai plus longuement une autre fois. Basculer la documentation sur Git a permis d'accélérer les améliorations du manuel : je peux maintenant écrire en offline (dans le RER par exemple). Par contre, plus en online...Temporairement... Gitiwiki fonctionne pour le moment en lecture seule. Il faut encore que je développe la possibilité d'éditer en ligne :-) (c'est en cours). Cependant, cela ne devrait empêcher personne de contribuer au manuel : il est sur github.

Enfin, comme je disais, j'ai aussi passé du temps à libérer le code source du site jelix.org et bien sûr le code du nouveau site docs.jelix.org, dans l'espoir d'avoir plus d'aide sur tout ce qui fait tourner le projet ;-).

Et puis comme je ne suis pas toujours discipliné, j'ai préféré ces 2-3 derniers mois, à commencer à développer Jelix 1.5 plutôt que de paufiner Jelix 1.4 !