Feed Info - jy[B]log

Il y a tout juste dix ans, le premier site français entièrement dédié aux standards du web ouvrait ses portes : Openweb.eu.org. Il fut le résultat du travail de 11 passionnés du web : Tristan Nitot, Laurent Denis, Pascale Lambert-Charreteur, Florian Hatat, Fabrice Bonny, Emmanuel Clément, Mathieu Pillard, Denis Boudreau, Olivier Meunier, Samuel Latchman et moi même. Nous publions tous un peu de notre coté des articles sur les standards (je venais d'ouvrir mon blog deux mois auparavant), et un jour nous nous étions dis que cela serait bien de rassembler toutes ces ressources en un seul lieu.

La magie du web a permis cela, bien que nous soyons tous aux quatre coins de la France (et du canada !).

Je me rappelle encore de certains soirées à coder chez moi dans mon bureau, ou encore cette seule et unique réunion IRL pour discuter du projet, dans les locaux d'AOL où Tristan travaillait. J'y rencontrais donc pour la première fois celui qui allait devenir le président de Mozilla Europe. Je crois aussi que j'avais croisé très furtivement à la cantine d'AOL celui qui allait devenir mon patron 1 an et demi plus tard, Daniel, chez Disruptive Innovations. En effet, les locaux abritaient ce qui restait de Netscape France (Daniel, Tristan, Peter...), filiale de la société à l'origine du projet Mozilla.

Depuis la publication des premières pages d'Openweb.eu.org, de l'eau a coulé sous les ponts. Les personnes qui animent le site ont changé, mais le site est toujours là et est encadré par des gens tout aussi passionnés par le web. Et malgré des périodes d'inactivité il y a quelques années, des articles continuent à paraitre régulièrement. Avec cette "monoculture" webkit qui menace, les standards du web sont plus que d'actualité.

Pour ma part, j'ai tourné la page "openweb" depuis quelques années. Mais j'en suis toujours aussi fier et je continue à soutenir les standards du web. Ce projet fut pour moi le départ de beaucoup de choses, comme mon aventure dans le projet Mozilla, qui démarra avec l'ouverture de xulfr.org dont je fêterai aussi les 10 ans cette année.

Bon anniversaire Openweb !

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

Depuis 3 ans, dans le cadre d'un partenariat entre Mozilla et la Miage d'Evry, je donne des cours sur les technos Mozilla, accompagné de Fabien Cazenave les deux premières années, et de David Rajchenbach-Teller en cette 4ième année. C'est le projet CoMETE. Jusqu'à maintenant, on enseignait les technologies pour réaliser des extensions pour Firefox (XUL, XBL, XPCOM etc...), mais cette année, nous avons décidé d'enseigner le développement web ++, avec les toutes dernières technologies proposées non seulement par Firefox, mais aussi par Firefox OS. Autant dire que les étudiants auront des cours à la pointe (pas comme moi quand j'étais à la Miage d'Orsay en 1996-98, où on nous enseignait encore du Cobol alors que Java faisait fureur :-/ ).

Je suis le projet Firefox OS (aka Boot 2 Gecko) depuis le début. Vivien, l'un des développeurs de Firefox OS, m'avait fait l'honneur de me montrer les toutes premières versions de Firefox OS fonctionner sur un smartphone. C'était en Octobre 2011, 3-4 mois après le démarrage du projet et il y avait déjà des applis 100% HTML, dont celle pour lancer un appel téléphonique ! (bon, un bug empêchait de raccrocher :-) ).

Cependant, je n'ai pas non plus suivi le projet de très près (comprendre : je ne suis pas les commits comme autrefois sur Firefox, et je ne contribue pas - encore ?- au projet). Mais pour préparer ces cours, je suis bien obligé de me plonger dans toutes ces webAPI, dans la réalisation d'une WebApp, ou encore compiler/tester Firefox OS sur mon laptop.

Pour rappel, Firefox OS est un système d'exploitation pour smartphone (et dans le futur pour tablette), dont la particularité est que toutes les applications, y compris le "bureau", sont des applications HTML. En gros, Firefox OS, c'est seulement trois principales couches logicielles :

• un noyau linux et des drivers adéquates
• Gecko, le moteur de rendu de Firefox, accompagné de son moteur Javascript
• des applications 100% HTML5/JS

Et bien sûr, pour que les applications puissent accéder au matériel (comme démarrer un appel téléphonique, envoyer un SMS, utiliser le capteur photographique...), il faut des nouvelles fonctions JS utilisables dans le fichier HTML de l'application. Ce sont les fameuses WebAPI, que Mozilla ne se contente pas d'ajouter, mais aussi de proposer à la standardisation au W3C.

Je dois dire que je suis de plus en plus enthousiaste sur Firefox OS. On va pouvoir réellement tout faire, y compris dialoguer avec les autres applis via les WebActivities. On va pouvoir porter tout ces nouveaux Jeux HTML reposant sur WebGL, vers FirefoxOS, en profitant de nouvelles api (faire vibrer le téléphone, utiliser l’accéléromètre...). L'interface actuelle de Firefox OS montre ce que l'on peut faire avec les transformations et animations CSS3 pour tout les petits effets graphiques. Bref, on va pouvoir refaire le monde avec des technologies que finalement bon nombre de développeurs maitrisent déjà (HTML, JS, CSS), à savoir des technologies standards.

Plus je vois Firefox OS avancer, évoluer, plus je me dis que Mozilla va réussir son pari, celui d'offrir une réelle alternative à IOS et à Android, comme Mozilla l'avait réussi avec Firefox dans un tout autre contexte. Les sceptiques diront que d'autres ont déjà essayé (WebOs par exemple), mais comme l'a écrit Daniel, Firefox OS n'est pas qu'un simple navigateur posé sur un noyau, Firefox OS va plus loin, car Mozilla standardise. De plus, Mozilla ne fait pas ça dans son coin, il a des partenariats avec des opérateurs, en particulier Telefonica, qui vendra des abonnements+téléphones avec Firefox OS préchargé, dés le premier trimestre 2013 , au Brésil.

Vivement que je puisse m'acheter un smartphone et une tablette Firefox OS :-)

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.

Quand on surf sur le web, il faut savoir que l'on est de plus en plus pisté, tracké. Notre parcours est analysé, et permet alors aux régies publicitaires de vous afficher des pubs ciblées, ou encore à d'autres sociétés de compléter votre profil qu'elles ont déjà en partie, comme facebook,et google. Ces grosses entités commencent à tout savoir de vous. Et de moi. Et le gros souci, c'est que l'on ne sait pas ce qu'elle font de toutes ces données (en dehors des pubs). Vous avez des doutes sur le fait d'être pisté ? Lisez la suite.

En mars dernier, à sa sortie, j'ai installé l'extension Collusion. Elle permet de visualiser justement tout "ces espions" et leur liens avec les sites web. Après l'installation, je trouvais ça rigolo de voir ses graphiques, Et puis je l'ai oublié jusqu'à aujourd'hui. Cependant, Collusion n'a pas oublié de faire son job, et a continué à faire ses statistiques.

Ce matin, je l'ouvre. Et voici le résultat :

(cliquez dessus pour voir en grand).

Les ronds représentent les sites web que vous visitez, et surtout ceux que vous ne visitez pas explicitement. Cette deuxième catégorie de site web sont les sites auxquels font appels les sites que vous visitez, pour leurs statistiques, pour afficher des pubs, pour afficher les boutons twitter, facebook, google+ etc. Plus un site à de liens avec d'autres sites, plus le le rond est gros.

Sur mon graphe, devinez quels sont les sites que les plus gros rond représentent ?

Du plus gros au moins gros:

• Google Analytics, "l'espion" de google installé par les développeurs sur leurs sites pour savoir les statistiques de visites. Mais qui profite aussi à Google pour vous pister (faut pas se leurrer)
• Google.com : il est vrai que j'utilise google comme moteur de recherche principal. Mais ici on parle de liens entre site. Il s'agit donc très probablement la faute aux boutons "google+" installés un peu partout.
• Facebook.com : c'est "très rigolo" de le voir là, je ne vais JAMAIS sur facebook. Je n'aime PAS Facebook. J'en déduis que sa "popularité" dans les stats de Collusion est due aux boutons "facebook" installés partout sur les sites que je visite.
• Twitter : j'utilise le site twitter au quotidien. Mais il y a aussi des boutons "twitter" partout, la preuve en est sa présence dans ce top 5 des sites les plus liés.
• Googleapis.com : représentent tous les outils google utilisées par les sites web

Et il y aussi Facebook.net (le retour), quantserve.com (outil statistique), Xiti, autres sites annexes de google etc. Bref, beaucoup des rond moyens et gros sont des sites de stats, de collectes d'informations, de trackers pour les régies publicitaires. Il y a aussi Gravatar qui est pas mal lié aux sites web, dans mon graph.

Par contre peu de site de régies publicitaires en elles-même, probablement parce que j'ai depuis longtemps installé l'extension AdBlock+ pour bloquer les pubs dans les sites web. Je ne supporte pas les pubs.

Mais Collusion montre déjà que le nombre d'espions installés sur les sites web sont faramineux, sans même que les développeurs qui installent ces bouts de scripts JS n'aient conscience du potentiel qu'ils apportent à ces entreprises de collectes d'informations. Et si vous pensez que je crois trop aux théories du complot, il y a plein d'articles sur le web et même des reportages à la télé (Jeudi dernier dans Envoyé Spécial par exemple), où les annonceurs avouent ces pratiques.

Je vais maintenant tenter de ne plus laisser mes traces sur le web. Parce que ça me dérange que l'on me piste ainsi. Les actions que j'ai dés maintenant entrepris :

• effacer les données de Collusion, pour voir l'impact de cette expérience
• faire le grand ménage parmi les cookies
• installer Ghostery dans mon navigateur préféré.
• Continuer à ne pas utiliser Google Chrome
• Continuer toutefois à utiliser mes sites habituels, comme Google pour son moteur de recherche et son serveur mail, pour mieux voir l'efficacité de Ghostery.

Rendez-vous dans quelques mois pour les résultats :-)

Après cela, je penserai peut-être à migrer mon compte mail vers un hébergeur moins curieux, à changer de moteur de recherche etc..

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

J'ai une freebox depuis quelques années. J'ai migré vers la V5 quelques mois avant la sortie de la v6. C'est bête me diraient certains. Ou pas. En fait, j'aurais mieux fait de rester avec une V4. Car le constat après 2 ans d'utilisation est amère : j'aimerais bien moins payer si je le pouvais.

En effet, je n'utilise au final que la partie "modem" et "routeur" de la freebox : pour faire du web, lire mes mails, faire du ssh, irc etc..

Le téléphone ? je ne l'ai jamais utilisé. Bon, faut dire aussi que je n'ai transmis le numéro à personne. Mais mon mobile étant suffisant....

Les centaines de chaînes télé ? Je ne les regarde pas. Déjà avec la V4, j'avais vite arrêté de zapper tellement il y a de chaînes, et tellement il y a de programmes inintéressants. Ou alors il faut passer à la caisse pour avoir accès aux chaînes susceptibles de m’intéresser. Et encore faut-il que la qualité d'image soit là. Je constate trop souvent des "patés" dus à de trop fort taux de compression. La TNT est de meilleure qualité globalement. Donc je reste avec les chaînes de la TNT, en passant par ma télé en direct bien sûr, parce que le module TNT de ma freebox n'a jamais fonctionné.

Le magnétoscope numérique ? comme il y a 20 ans pour mon magnétoscope VHS, ça m'est arrivé d'enregistrer un épisode d'une série par exemple, mais j'oubliais toujours de regarder l'enregistrement. Bref, je n'utilise pas.

Les jeux et autres applications : qualité trop moyenne. Et puis ça commence à faire quelques années que je ne joue plus et que je n'ai plus vraiment de temps pour ça.

Le wifi ? pas de wifi chez moi. Le filaire (ethernet 1Gb) me suffit.

Le NAS de la V6 ? Il me serait inutile car J'en ai déjà un. Et puis "bizarrement", je n'ai pas envie de confier mes données à une boite noire,

Bref, je paye au final des services dont je ne me sers pas. D'ailleurs j'ai fini par débrancher le boitier multimédia.

J'ai bien pensé à changer de fournisseur d'accès internet, mais le souci est que plus aucun ne propose une offre ADSL simple, à un prix inférieur. Il y a quelques jours encore, OVH en avait une, mais elle a disparu. Avec FDN, le tarif est à peine inférieur qu'une offre triple play (certes, on a une neutralité totale du réseau..). Et free reste le moins cher parmi toutes les offres "machinbox". Alors voilà, je suis "condamner" à utiliser une "freebox".

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 !

Au début des années 90. Je délaissais mon TO9, pour commencer à manipuler le PC flambant neuf de mon père, en découvrant le langage C. Mais j'étais aussi à fond sur la programmation de la calculatrice HP48.

Une pure merveille cette machine. Elle avait un écran large, des touches inusables, un port série et infrarouge pour communiquer, et pour la version SX, deux ports pour mettre des cartes mémoires. Elle n'était pas encombrante, du coup, elle ne me quittait quasiment jamais. Je pouvais coder n'importe où. Chez moi, dans le bus, au lycée. Je me rappelle de mon prof de math en terminal, qui me faisait remarquer en classe, au début de l'année, qu'il serait bon de suivre les cours, plutôt que de coder à longueur de temps. Mais il avait fini par m'ignorer, me laissant tapoter sur ma machine, sous son nez, au premier rang. J'ai tout de même été puni : j'ai raté mon bac cette année là (1992).

Mais cela ne m'a pas calmé, loin de là, parce que cette même année, j'ai découvert les capacités insoupçonnées de cette machine. J'utilisais jusqu'alors le langage de haut niveau intégré au système de cette machine, le RPL, On arrivait à faire pas mal de trucs, mais ce n'était tout de même pas très performant. Ça commençait d'ailleurs limite à me lasser. Mais le destin, dans sa grande bonté, ne m'a pas laissé dans ce marasme geekesque...

Comme tout bachelier en préparation, j'allais passer quelques concours pour tenter de rentrer dans des écoles supérieures. Avec la HP48 bien sûr. Et voilà qu'à la sortie d'une des épreuves, un petit groupe d'étudiant se forme, tous avec une HP48 à la main. Ah ? Tient ? des HP ! Mais que font-il ? Ah tient, ils s'échangent des programmes. Faites voir les gars ! Et là le choc. Tellement un choc d'ailleurs que je m'en souviens encore, 20 ans après. L'un d'eux me montre un clone de Pacman.Oui oui, le petit jeux des années 80. Ça vous fait rire hein ? Mais attention, ce n'était pas un truc laid et lent fait en RPL. Non non. C'était un jeu bien fluide, super jouable. C'était comme sur une Game Boy, la console portable phare de l'époque. Mais comment était-ce possible ? "C'est programmé en assembleur" m'a t-on répondu.

Et voilà comment j'ai basculé dans la programmation très bas niveau. Je me suis renseigné, je me suis procuré plein de nouveaux programmes que j'ai récupéré au fil du temps, dont le seul outil de l'époque pour faire de l'assembleur, ASMFlash (j'ai fini par faire le mien, J-Asm). J'ai acheté les bouquins "voyage au centre de la hp48", détaillant tout le fonctionnement des processeurs Saturn des HP, les instructions assembleurs, allant même jusqu'à indiquer le nombre de cycle d'horloge que prenait chaque instruction. Et pour faire des prouesses en termes de performances, je n'hésitais pas à calculer le nombre de cycle d'horloge que me prenait telle ou telle partie du programme. Un peu cinglé quoi :-).

Mais je n'étais pas le seul cinglé. J'avais eu l'occasion de retrouver d'autres passionnés à des "HP parties", organisées dans des écoles informatiques, ou même carrément dans les locaux de Hewlett Packard sur Paris. HP en a ainsi organisé quelques unes - avec des concours de programmation, dont un où j'avais terminé 2ième \o/ -, très intéressés qu'ils étaient par ce que cette petite communauté de développeurs pouvait faire avec cette calculatrice. Intéressés à un point qu'ils finiront par embaucher quelques un d'entre eux, Cyrille de Brebisson et Jean-Yves Avenard, qui étaient les créateurs du "Meta Kernel", un firmware alternatif pour la HP48, bien plus véloce que l'original. Ils participeront ainsi au développement du système de la HP49 (qui reposera une bonne partie sur le meta kernel si je ne me trompe pas).

Bref, on pouvait aller très loin avec cette machine, sans avoir à la modifier physiquement. C'était une machine très ouverte. Un vrai bonheur pour les geeks, je vous dis.

Cependant, je n'aurais pas vécu tout ça, et je n'aurais pas eu le loisir de faire tout ces développements sur cette HP48 et ces rencontres avec d'autres passionnés à ces HP parties, si il n'y avait pas eu un autre élément de taille dans cette aventure (en tout cas en ce qui me concerne) : les échanges virtuels, via entre autre RTC-ONE.

RTC-ONE, ce n'était pas un site web. Je n'avais pas internet à l'époque. Et de toute façon, en 1992-93, le grand public (dont moi), ne connaissait pas internet, il n'y avait pas de fournisseur d’accès pour les particuliers. Pas à ma connaissance en tout cas. Rappelez vous, le web n'est né qu'en 1993^[1], et donc Internet n'avait encore que peu d'atout pour le grand public, même si on pouvait déjà faire plein de chose (le mail entre autre). Bref, RTC-ONE, ce n'était pas un site web, mais un site... Minitel. Un serveur quoi. Pas un serveur payant par le 3615 ou autre 36 machin. Non, un serveur privé, comme il y en avait d'autres, mise en œuvre par un particulier. Il suffisait de connaître le numéro de téléphone, d'appeler, et de taper la touche "connexion/fin" du minitel. De l'autre coté, un serveur s'occupait d'envoyer les pages demandées via un bon vieux modem à 1200 bauds.

RTC-ONE avait été monté par Franck Denis^[2]. C'était un simple PC, sur lequel étaient branchés 5 modems, eux même connectés à 5 lignes téléphoniques. Ce PC faisait tourner un logiciel maison pour gérer les connexions, envoyer les pages etc... Bref, un peu comme le web, sauf que c'était de l'affichage vidéotex (en noir et blanc pour moi), que ça se chargeait très lentement^[3] et qu'il ne pouvait y avoir que 5 personnes connectées simultanément. Mais c'était presque Byzance à coté d'autres RTC privés qui ne comportaient bien souvent... qu'une voie !

RTC-ONE permettait de télécharger des programmes, en particulier pour HP48, mais proposait aussi des news et des salons de discussions, pas pour parler avec Ulla, mais pour discuter entre développeurs. Comme sur IRC quoi.

Ça a été donc ma première expérience de discussions virtuelles avec d'autres personnes qui habitaient à des kilomètres de chez moi, et surtout avec des personnes qui partageaient le même centre d'intérêt. Et pour mes parents, c'était leurs premières factures de téléphone à 1200 francs par mois. J'ai dû leur expliquer la première fois que non, ce n’était pas une erreur de France Telecom, mais que c'était à cause de mes échanges télématiques. Ils ont finit par me faire comprendre que c'était un peu abusé, en fermant à clé - quand ils y pensaient - le bureau de mon père dans lequel se trouvait le précieux Minitel.

20 ans après, France Telecom a (enfin) débranché le Minitel. Adieu Minitel. Sans regret, mais avec tout de même un brin de nostalgie :-) En ce qui me concerne, ça fait des années que je l'ai débranché. En 1994, je découvrais Internet à l'université, et en 1997, j'avais ma première connexion à la maison, avec le fournisseur d’accès Havas On Line (j'ai encore le dossier d'inscription !), ce qui me fit complètement abandonner le Minitel. J'ai par contre délaissé la programmation HP48 plus tard, à la fin de mes études. Certains de mes programmes traînent encore sur le web, que j'avais publié sous le pseudonyme "Jylog". Un jour, il faudrait que je prenne le temps de libérer les sources...

Il y a un peu plus d'un mois et demi, j'avais tenté un truc. Mon laptop a deux cartes graphiques, une intégré au chipset intel, et une carte séparée, NVidia. Cela permet, pour les systèmes d'exploitations qui prennent en charge, de pouvoir utiliser l'une ou l'autre carte graphique en fonction des besoins des applications, et donc optimiser la consommation en énergie. C'est la fameuse fonctionnalité "Optimus".

Sous Windows, pas de souci. Sous Linux par contre, aucun support (j'étais alors sur une Ubuntu 11.04 32bits). C'est soit la carte faiblarde Intel, soit la carte puissante NVidia, mais il faut alors désactiver l'Optimus dans le bios pour pouvoir l'utiliser. Et l'ennui c'est que, bien qu'il n'y ait qu'une carte utilisée par le système, la deuxième est toujours active, donc pompe du courant pour rien. Et comme j'ai choisi la NVidia, j'ai alors une autonomie plutôt limitée, à peine deux heures :-/

Il y a toutefois un projet pour apporter ce support : Bumblebee. Cela semble prometteur même si un peu embêtant à utiliser puisque si on veut le support NVidia pour une application, il faut la lancer avec un utilitaire fourni.

Cependant, fin Avril, je tente le coup, j'avais du temps, je passais des vacances en Bretagne. J'installe les paquets, mais au final rien ne fonctionne. Problème au redémarrage au niveau de X-Windows. Pire, la désinstallation des paquets ne règle pas le souci. J'essaye de régénérer les fichiers de boot etc, rien. Que dalle. Mon système est flingué. Merci Bumblebee.

Je n'avais pas envie de passer toutes mes vacances à tenter de régler le problème. J'aurai plus vite fait de tout réinstaller. Et ça tombe bien, il fallait que je mette à jour vers une version plus récente d'Ubuntu. Cependant, Unity ne me plaît pas du tout, les dernières avancées dans Gnome ne me satisfont pas.

Et si je retentais KDE ? KDE, mon environnement de bureau fétiche jusqu'à la sortie de sa version 4. J'avais été pas mal déçu par KDE 4.1, et j'étais alors resté sous Gnome (qui était pré-installé sur le laptop que je m'étais payé quelques mois auparavant). Depuis 4 ans, tous les problèmes ont dû être réglé, me dis-je. Hop, c'est parti pour la dernière Kubuntu.

Et je ne suis pas déçu. Effectivement la plupart des reproches que j'avais n'ont plus lieu d'être. C'est réactif, fluide, agréable à utiliser. Il y a bien quelques petits trucs qui me chiffonne (comme le fait que dès qu'on approche une fenêtre du haut de l'écran, KDE met cette fenêtre en plein écran, et je n'ai pas encore trouvé comment désactive ce truc, Merci à Hello dans les commentaires, c'est réglé :-) ), mais ça reste supportable. Depuis un mois et demi donc, je suis très satisfait de KDE4.

Bon, par contre, malgré que je profite d'un noyau plus récent, toujours pas de prise en charge d'Optimus. Ni d'ailleurs de mon lecteur d'empreinte, ni de mon touchpad multitouch (pour ce dernier, j'ai ouïe dire que c'était réglé dans le tout dernier noyau...). Cependant, depuis un an que j'ai ce portable ^[1], le lecteur de carte SD, le firewire et les diverses fonctions de mise en veille fonctionnent enfin sans bugger ! Avec Linux, il faut être patient :-)

Aller Dell, un petit effort pour fournir des drivers linux (même proprio, je m'en fiche) avec vos nouvelles machines, comme dans le temps...

Firefox, avec ses 25-30% de part de marché des navigateurs, est un projet très vivant, et des entreprises ont souvent besoin de réaliser des extensions pour Firefox ou des applications basées sur Firefox. La technologie utilisée est donc XUL, XPCom, et cela peut aller jusqu'à des Firefox personnalisés qui nécessitent recompilation etc...

À Innophi, société que David Marteau et moi-même avons fondé il y a 2 ans, nous avons donc régulièrement des demandes de prestation pour des projets XUL. Cependant il nous arrive d'en refuser faute de disponibilités. Aussi, si vous proposez des prestations avec les technologies XUL, que vous soyez une société de service ou un développeur freelance, nous pourrions avoir des projets pour vous. Contactez-moi : laurent@innophi.com ;-)

I just released publicly a new version of a component : jsDatasource.

This component allows to use javascript objects as datasource for XUL templates. You can use it in your own extension or XUL applications. It becomes easy to use XUL templates with js datasources!

I started this component in 2009, for a software, ZoomCreator, when I worked for Zoomorama. Even if it was written under a free licence, I didn't release it at this time (well, I had so much work..). And for a recent customer project, I need it with some improvements, like the support of recursion or the support of sorting. So I improved it, and I just open a public repository :-)

I hope it will help some XUL developers :-)

Pour une grosse extension pour Firefox (un projet client), j'ai réalisé entre autre chose un composant qui agit sur des pages web. Pour tester ce composant (avec des tests unitaires bien sûr !), j'avais besoin d'un serveur web servant des pages HTML statiques.

J'avais bien pensé à apache, mais ça m’embêtait de déployer toute une artillerie comme WAMP, surtout sur la machine de travail que l'on me prête, pas très performante (et sous windows mais bon, c'est une autre histoire... :-) ). Et puis ça m’embêtait de configurer un serveur web tout court. Donc exit aussi Nginx.

Bref, je voulais un truc très simple, très light. Je me suis alors tourné très vite vers node.js. Téléchargement, lancement de l'installateur, click, click, c'était installé.

J'ai choppé ensuite un script JS implémentant un serveur http de fichiers statiques, pour node.js, comme on en trouve par dizaine sur le web. Une ligne de commande plus tard, j'avais un serveur qui écoutait patiemment le port 8080.

En moins de 5 minutes, j'étais prêt à écrire mes tests. J'ai trouvé ça génial :-) Ça c'est de la productivité !

Dans un billet de Loïc d'Anterroches qui cherche à comprendre pourquoi Symfony 2 est très lent dans les benchs qu'il a fait, j'ai appris via un commentaire que Symfony 2 chargeait par défaut tout un tas de truc (avant d'arriver à l’exécution même du code propre à la page), et notamment donc, des "autoloaders" pour chaque composant. D'ailleurs, un "conseil" de la part d'un "expert" SF2, indique qu'il faut désactiver des choses, comme par exemple l'autoloader pour swiftMailer, qui serait l'une des causes de ralentissement. La conséquence ne m'étonne guère au final. Par contre que SF2, soit disant un framework performant, le fasse par défaut, m'a étonné, voir même stupéfié.

Pourquoi diable configurer l'autoload de manière à ce qu'il puisse trouver une classe... qui n'est que rarement utilisé ?? Sauf cas très spécifique (je cherche encore), en effet, il est rare qu'on envoi un mail à chaque visite d'une page du site. Par exemple sur un site e-commerce, on va envoyer un mail lors de la confirmation de commande. Et cette page de confirmation de commande est une page rarement "visitée", en regard du nombre de "hits" sur les pages permettant de parcourir le catalogue produit par exemple.

Admettons que sur 100 000 page visitées, un seule page va envoyer un mail. Cela veut donc dire que, dans 99,999% des cas, la préparation de l'autoload pour trouver les classes de swiftMailer, ne sert strictement à rien. Déjà à ce niveau, on perd en temps d’exécution (celui du chargement de l'autoloader de swiftmailer), même si c'est quelques milli-secondes (allez, disons micro-secondes), et on perd en occupation mémoire, même si c'est quelques dizaines d'octets. Cependant, quand tout ça est multiplié par le nombre de requêtes par jour ou simultanée, ça peut commencer à devenir significatif.

Alors on me répond, "oui mais bon, c'est mieux que de faire un require pour chaque page". Certes. Mais n'empêche, rien que de charger l'autoload, ça bouffe du CPU et de la mémoire pour rien, à chaque page.

Et ce n'est pas tout. L'autoload de swiftmailer, une fois chargé, est rarement actif. Il va manger encore plus du CPU et de la mémoire que ce que je disais. Comment ? tout simplement, quasiement à chaque fois que PHP tente de charger une classe. Car lors de ce processus, PHP va demander à tout les autoloaders si ils ne veulent pas essayer de charger le fichier qui contient la définition de la classe qu'il demande. Quand un framework charge, rien que pour un projet vide, des autoloadeurs à tout va, qui eux même vont faire un, deux, dix, 20 tests sur le nom de la classe ou faire des manipulations de chaîne dans tout les sens sur ce nom de classe (un autoloader compatible PSR0, n'est pas anodin en ce sens...), tout ça prend du temps, forcément. Multipliez ça par le nombre de classes utilisées dans chaque page, et par le nombre de page chargée, le temps passé dans l'autoload commence à ne pas devenir anodin (vis à vis du "temps de latence" du framework dont parle Loic), avec une part significative des autoloaders pour les composants utilisées rarement. Et on en arrive a des perfs catastrophiques, même pour un hello world.

Bref, l'autoload, c'est bien, ça évite au développeur de faire des require/require_once dans tous les sens. Mais il ne faut pas en abuser.

Dans Jelix, voici ce que je fais :

• pour les classes de jelix utilisées à chaque "page" ou presque : require. Utiliser l'autoload n'a pas de sens pour des classes utilisées tout le temps. Les classes sont chargées directement, PHP n'a pas à faire appel aux autoloaders.
• pour les classes rarement utilisées : require. Le développeur va utiliser les classes en question une fois de temps en temps, il n'y a donc pas de raison de les déclarer pour l'autoload, Le développeur peut très bien prendre 10 secondes à écrire un require là où il en a besoin (ce qui n'empêche pas le fichier inclus de configurer l'autoload pour les classes que le développeur est alors susceptible d'utiliser). Il peut même utiliser l'objet jClasses pour indiquer de charger la classe de tel module, sans avoir à connaitre le chemin.
• Pour toutes les autres, c'est à dire les classes utilisées souvent mais pas tout le temps : autoload.

On a ainsi un bon compromis entre performance et facilité de développement.

PS : l'utilisation de l'autoload pour toutes les classes dans SF2 n'explique probablement pas totalement les problèmes de performances...

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

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.

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 !

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

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 :-)

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.