jy[B]log

Tangi vient de publier un billet très intéressant sur une nouvelle façon de faire une application web, une architecture XRX, qui utilise XForms, Rest, et XQuery. Vu de loin, ce triplet à l'air sexy, et fait renaître l'idée de faire du XML de bout en bout, sans avoir à taper une ligne de code "fonctionnelles". Et pour Tangui, cela apporte beaucoup de simplicité par rapport au triptique Javascript/PHP/MYSQL. Sur ce point, je ne suis pas d'accord avec lui.

J'ai eu un truc que je ne comprenais pas avec Mercurial. J'avais créé une branche nommée sur mon dépôt local, et fait des commits. Du coup, tout logiquement, j'avais deux "heads", une pour la branche nommée, et une autre pour la branche "default". Au moment de faire mon push, Mercurial a ralé, comme quoi ça allait créer des nouvelles têtes sur le dépôt distant, et me disait qu'il faudrait faire un merge avant de faire le push. Le problème, c'est que je ne veux pas fusionner les deux branches !

Du coup, j'ai eu un gros doute sur ma compréhension de ce qu'était un head, une branche nommée et à quoi ça servait. Mais j'avais beau lire la doc, il me semblait bien avoir compris tout ceci. Et ça ne m'avançait pas sur le pourquoi de l'erreur de Mercurial. Pourquoi fallait-il absolument faire un merge ? Pourquoi avoir un système de branches si c'est pour les fusionner systématiquement ?

Et puis j'ai expliqué mon problème sur le channel irc de Mercurial, et je fus plutôt rassuré. Ou presque. Parce qu'en fait, c'est moi qui n'ait pas tout à fait compris le sens du message d'erreur. Je l'ai trop pris au pied de la lettre. Ce n'est pas une erreur, mais un avertissement, et l'ordre qu'il faille fusionner, n'est pas un ordre, mais une simple proposition pour résoudre le problème (parmis d'autres non explicitées). Et on m'a expliqué qu'en fait, je devais forcer^[1] le push avec l'option -f , et que dans les prochaines versions, le message sera plus explicite (pas seulement indiquer qu'il faut merger) ou n'apparaitra plus tout simplement (j'imagine, seulement dans les cas où il s'agit que de têtes de branches, et pas plusieurs têtes sur une même branche).

Bref, voilà mes doutes levés. Je peux continuer à travailler :-)

Bon, il suffit que je me déconnecte quelques jours pour que le serveur du projet Jelix décide de ne plus répondre. Malheureusement, je n'en sais pas plus pour le moment. J'ai contacté son propriétaire pour qu'il le redémarre, mais j'ai bien peur que lui aussi soit parti quelque part sous le soleil.

Désolé donc pour les utilisateurs de Jelix, il va falloir patienter quelques jours. Je retourne sur la plage.

C'est bête, j'avais quelques nouveautés intéressantes à "pusher" sur le dépôt Mercurial pendant ce brêve temps de connectivité :-)

En ce moment, je m'amuse pas mal avec Mercurial.

Chez Zoomorama, parce que Subversion devenait limitant pour nous, nous avons décidé de migrer vers Mercurial. On a pas mal recherché et discuté des différents avantages et inconvénients entre git et mercurial, et hg nous semble plus approprié pour nos besoins.

1. Mercurial nous semble plus propre d'un point de vue des commandes (Il n'y a pas 144 scripts différents avec des dépendances dans tout les sens comme dans Git) et il est presque aussi simple à utiliser que subversion. Cela nous fera gagner du temps pour s'approprier l'outil.
2. Il y a une très bonne documentation (bien que celle de Git semble s'améliorer), entre autre ce guide
3. Et surtout il a un bon support sur toutes les plateformes, ce qui est important pour nous puisqu'on fait, entre autres choses, des applis multi plateformes basées sur Mozilla.
4. On utilise Gecko, en le modifiant, et Gecko étant sous Mercurial, ça ne nous fait pas apprendre un nième outils.

Au niveau fonctionnalités, Git et Mercurial se valent je trouve, surtout dans les fonctionnalités de base. Mercurial a beaucoup progressé et comblé son relatif retard ces derniers temps. Et vu qu'on ne va pas forcément utiliser les fonctionnalités super avancées de ces outils ce n'est pas sur ce point qu'on a pu les départager (quoique, j'apprecie beaucoup l'extension mq de Mercurial)... D'un point de vue performance, on n'a pas des projets de plusieurs dizaines de millions de lignes de code, aussi je ne pense pas que Mercurial va nous pénaliser (bien qu'il parait qu'il est plus lent que Git sur certaines opérations).

Le seul inconvénient qu'on lui trouve : le site officiel est moche par rapport à celui de git :-), mais heureusement, il y a un nouveau site plus propre : http://hg-scm.org/.

Un bon comparatif (sans troll et assez objectif je trouve) qui a fini par nous convaincre : Git vs Mercurial.

Et puis, du coté de mes projets perso, je suis en train aussi de passer aussi à Mercurial. Pour Jelix, je viens de monter http://hg.jelix.org. Je dois encore configurer les droits d'accés pour le push via ssh (c'est moins classe à configurer que pour subversion ^[1]) et quelques autres broutilles (comme modifier les cron des builders de nightlies). Je vais enfin pouvoir commiter dans le train !

À propos de gestionnaire de sources, le projet PHP vient de changer lui aussi de système. Ils ont enfin délaissé CVS pour utiliser Subversion. Je m'étonne toutefois qu'ils ne se soient pas orienté vers Git, Mercurial ou un autre système décentralisé. Surtout que je n'arrive pas à mettre la main sur leurs arguments en faveur de Subversion par rapport à Git/Mercurial.

Après Firefox et Chrome, Philip Jägenstedt, un développeur du navigateur Opera annonce que ce dernier embarquera en natif le support pour Ogg Vorbis/Theora. Un autre développeur d'Opera, Anne Van Kesteren, apporte des précisions sur ce choix en expliquant qu'embarquer H264 n'est pas très bon pour le web, et que le web a besoin de format ouvert, libre d'utilisation (sans avoir à payer des royalties), et libre de tout brevet logiciel. Theora est donc le format idéal pour diffuser de la vidéo sur le web.

Beaucoup de développeurs et d'utilisateurs préfèrent cependant H264, sous prétexte que les fichiers sont moins gros, et la qualité meilleure qu'avec Theora. Ils ne savent pas cependant (ou ne veulent pas savoir parfois) que Theora n'est pas si mauvais que ça, et que les encoders pour ce format s'améliorent !

Ainsi, la 1.1 alpha 2 de l'encoder 'Thusnelda' réalisé par la fondation Xiph vient de sortir. Sans changer le format Theora, il permet de produire des vidéos de meilleure qualité, et des fichiers moins gros. (voir ce comparatif sur ce blog). Bien entendu, la prochaine version de Firefox utilisera cette future version de la libtheora, si elle est prête à temps.

Ogg Theora vaincra ! :-)

Énorme ! Le coeur du code de l'extension qui apporte un contexte 3D dans la balise <canvas> vient d'être intégré dans le trunk de Mozilla. Dans une version future de Firefox, on pourra donc faire de l'affichage 3D via cette balise, avec semble-t-il une API proche d'openGL.

Voir la news sur xulfr.

À l'origine, dans le cadre de la balise video, il était prévu d'intégrer le support de DirectShow et de Quicktime dans Firefox, pour ses versions respectives sous windows et mac, en plus du support natif du format OGG/Theora. Finalement, cela ne se fera pas, comme l'explique Robert O'Callahan l'un des core-developer de Mozilla. Voici en gros les raisons :

• Mozilla veut se concentrer sur la promotion des formats ouverts comme OGG/Theora
• Apparemment, peu d'utilisateurs ont les codecs installés pour H264, par défaut, il n'y a que des codecs pour des "vieux" formats (sauf dans Windows 7 qui fournira un codec H264 en standard)
• DirectShow est sous-spécifié, contient des bugs, et les codecs disponibles pour DirectShow sont de qualités très inégales, et ne fournissent pas tous tout ce qu'il faut pour que l'API de la balise video fonctionne correctement. C'est à dire, qu'avec certains codec, des scripts dans les pages web ne pourraient pas fonctionner, et l'auteur de la page web ne pourrait rien y faire. Déjà que la compatibilité cross-browser est un cauchemar, alors si il faut aussi se préoccuper des problèmes cross-codec...
• Vu la qualité inégale des codecs, cela veut dire bugs potentiels, que les utilisateurs attribueraient à tord à Firefox. Les développeurs de Firefox ont assez de problèmes à régler comme ça
• Il y a des codecs "malware"
• Il y a des codecs avec des trous de sécurité, que Firefox ne pourrait pas "contrôler"
• Deux backends en plus, c'est du boulot en plus, de la maintenance en plus etc.
• Mozilla ne peut fournir des codecs par défauts avec le support Quicktime ou DirectShow (pour H264 notamment), à cause des royalties qu'il faudrait payer, et des problèmes de brevet.

Bref, dans Firefox, il n'y aura que le support natif de OGG/Theora (et OGG/Vorbis), ainsi que la backend GStreamer (au moins pour la version mobile, il n'est pas encore sûr qu'il le soit dans la version desktop).

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

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

Une fois n'est pas coutume, je vais vous parler de ce qu'on fait dans la boîte où je travaille, Zoomorama, ou plus exactement, de la technologie que l'on a crée ou utilisé.

Mozilla vient d'ouvrir un site, hacks.mozilla.org. Pendant 35 jours, nous allons vous montrer les nouvelles possibilités du moteur de Firefox, tant en terme d'API javascript, qu'en terme de support de HTML5 et de CSS3. J'ai réalisé une démo qui sera publié sur ce site. Ce sera une démo sur CSS, qui utilisera des fontes téléchargeables (propriété font-face), les ombrages sur les textes (text-shadow) et les boites (box-shadow), accompagné d'une pincé de bords arrondis (border-radius).

Stay tuned !

Mise à jour: comme promis...