Jy[B]log

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.

Faire du drag and drop avec flash en utilisant canvas

Laurentj — Thu, 11 Feb 2010 15:18:00 +0100

À Zoomorama, Flash nous rend bien service. De par ses performances au niveau rendu, il nous permet de développer notre navigateur de documents zoomable, notre "ZoomViewer", que l'on peut intégrer dans une page web. Seul souci avec Flash : il ne connait pas le drag and drop.

Vous aurez beau commencer un geste de drag à partir d'une appli flash, aucune application, même pas le navigateur html, ne reconnaitra cela comme étant un mécanisme de drag and drop. Pour la simple raison qu'il n'y aucune API disponible dans Flash pour notifier de tels évènements au système. C'est particulièrement balot, quand on sait que même en HTML (et en XUL), il y a tout ce qu'il faut. L'inverse est également vrai : dragguez quelque chose du navigateur (l'url de la barre de navigation), où encore d'une autre application, vers l'application flash, vous n'avez aucun moyen en Flash/ActionScript, de prendre en charge ces évènements, et donc de permettre un drop.

Cela est particulièrement ennuyeux dans notre logiciel ZoomCreator2, que nous développons, David et moi. C'est un éditeur permettant de créer des documents zoomorama. Nous réutilisons notre application flash, légèrement modifiée, pour la zone principale d'édition "wysiwyg". Notre logiciel est basé sur XulRunner, donc son interface est du XUL, CSS, HTML etc. Nous voudrions pouvoir faire du drag and drop de cette zone flash vers le reste de l'application et vice versa, ou même à partir de l'extérieur de l'application vers notre zone flash (pour drag and dropper des images d'un explorateur vers notre éditeur par exemple). Cependant, à cause des lacunes de flash, c'est impossible de l'implémenter.

Ou alors en rusant.

J'ai en effet trouvé un hack, mais un hack qui n'est pas trop moche à mon sens.

L'idée générale est la suivante : puisque Flash ne génère pas, ni ne reçoit des évènements de drag and drop, virons-le, cachons-le, temporairement, en le remplaçant par un élément XUL ou HTML. Ce remplacement s'effectuerait immédiatement lorsqu'on détecterait le début d'un drag dans l'application (évènement dragstart, ou dragenter quand le drag vient de l'extérieur). Pour cela, pas de souci. Reste à faire ce remplacement proprement dit.

La première solution imaginée a été de positionner un élément XUL ou HTML transparent, au dessus de la balise object de flash. Hélas, ça marchouillait, voir pas du tout. Impossible de mettre cet élément "au dessus", il restait à coté, certainement à cause du modèle de boîte XUL. Et de toute façon, même en HTML pure, il y a des soucis, qui différent selon les plateformes si mes souvenirs sont bons.

Je n'ai pas trop persisté dans cette direction, sachant que j'allais certainement arriver à une impasse. Et puis en fait, j'ai eu une autre idée, celle d'utiliser <canvas>. Pour les développeurs d'extensions et d'applications XUL (mais pas pour les applis web), <canvas> possède un méthode drawWindow. Vous lui donnez un objet window (typiquement, la fenêtre d'une page HTML), les coordonnées d'un rectangle, et ça affiche dans <canvas> une capture d'un morceau de la fenêtre correspondante aux coordonnées données. C'est particulièrement utilisé dans des extensions qui vous affichent vos bookmarks avec une capture de la page web correspondante, ou pour faire un "alt+tab' sexy etc.

Ainsi donc, dés que je détecte le début d'un drag dans l'application :

je donne à la méthode drawWindow d'un élément <canvas> la fenêtre de notre application XUL, en lui donnant les coordonnées (x,y + taille) de l'emplacement de l'affichage de la balise object de notre zone flash.
dans ce canvas, j'ai alors une capture de ce qu'affiche le flash.
je rend invisible le flash, et fait apparaitre le canvas au même emplacement. Merci CSS et le modèle de boite XUL j'ai juste à faire en faite un display:block sur le canvas, canvas qui est un élement frère de ma balise object, et tout deux dans une boite XUL. Un overflow:hidden sur cette boite fait que le canvas "pousse" l'object vers le bas, mais du coup invisible, et sans faire apparaitre de scrollbar.
tout ce passe instantanément, et on ne remarque rien.

En définitive donc, je n'ai plus de "trou noir" dans l'interface de l'application, que des éléments XUL et HTML sur toute la surface. Je suis à même alors de recevoir tout les évènements drag and drop sur ce canvas et de les traiter. Une fois traités (évènements dragend ou drop), je fais disparaitre le canvas, la balise object reprend sa place, le flash est de nouveau là. Ni vu ni connu.

Vivement WebGL et/ou l'accélération matérielle graphique pour canvas dans tout les navigateurs, Ce sera alors certainement suffisamment performant pour se passer de Flash pour notre technologie de zooming, et nous évitant tout ces hacks acrobatiques :-)

La puissance de HTML5 dans vos applis web

Laurentj — Tue, 02 Feb 2010 20:21:00 +0100

Paul Rouget vient de sortir une nouvelle démo montrant les possibilités techniques de Firefox pour les développeurs web. Ici cependant, c'est plus qu'une démo, c'est une véritable petite application concrète.

Il s'agit d'un outil, qui permet d'envoyer des images sur twitpic et comportant un éditeur d'image. Vous sélectionnez les images que vous voulez envoyer, vous les retouchez éventuellement, et vous les envoyez. Visualisez la video, c'est carrément génial, d'un point de vue technique. C'est du jamais vu dans une application web HTML (je ne parle pas d'applet java ou flash, souvent lourdes et peu ergonomiques).

Coté technique donc, voici ce qui est utilisé :

HTML5 Canvas: on ne présente plus l'élement <canvas>, qui permet d'avoir une zone dans la page web où l'on peut "dessiner" programmativement. Les images que l'on a glisser dans l'application sont "injectées" dans un canvas. Cela permet alors de les modifier, de proposer à l'utilisateur une mini application de retouche, avec des fonctions de découpage, de décoration, de mirroir etc. Avec Canvas, on peut aller très très loin. Voir par exemple cet outil, sketchpad, un paint-like bien plus beau que l'original :-)
HTML5 Drag and Drop: Paul utilise les évènements drag-and-drop, pour permettre, d'une part, de glisser des fichiers de votre bureau ou explorateur de fichiers vers l'application, mais aussi de glisser les images à l'intérieur de l'application entre les différentes fonctionnalités (glisser une image précédemment sélectionnée vers la poubelle par exemple).
File API : permet dans l'application d'avoir des informations sur les fichiers, à partir de ce qui est indiqué dans un <input type="file"> ou un évènement drag and drop qui concerne un fichier. Ça permet à l'application de réagir ensuite en fonction du type du fichier, de sa taille etc..
HTML5 localStorage: localStorage est un objet javascript qui permet de stocker ce que l'on veut, durablement, coté client. Il est utilisé ici pour stocker les images sélectionnées, en attendant de les envoyer vers twitpic. L'image, affichée en fait via un canvas (ce qui permet de la modifier), est en fait transformée en data URL. Cette URL est alors stockée dans localeStorage.
HTML5 Application Cache : toute la machinerie permettant de continuer à faire fonctionner l'application même en étant déconnecté, est utilisée. En particulier, un manifest "offline" est utilisé pour indiquer les fichiers de ressources (js, css) à stocker durablement dans le cache du navigateur, de manière à pouvoir recharger l'application, même en étant déconnecté. En fait, c'est comme si l'application était stockée en local. De plus, les évènements offline et online sont écoutés, pour pouvoir autoriser ou non la publication des images.
Cross Site xmlHTTPRequest, un mécanisme http permettant d'autoriser ou non à une application web (ici la demo) de communiquer avec une autre application web (ici twitpic).

Toutes ces technologies, dorénavant présente dans Firefox 3.6 et déjà plus ou moins dans d'autres navigateurs (je n'ai pas vérifié, ça ne va pas tarder en tout cas), offrent de bien belles perspectives en matières d'applications web puissantes et agréables à utiliser. À quand de telles fonctionnalités dans mon outil de blog préféré, pour faciliter l'insertion et la retouche de nouvelles images dans un billet sans ouvrir de lourdes applications graphiques desktop ? ;-)

Cerise sur le gâteau : cette application fonctionne parfaitement dans la version mobile de Firefox, qui est sortie hier pour Maemo :-)

What's wrong in Mozilla's plan for Firefox ??

Laurentj — Mon, 11 Jan 2010 02:05:00 +0100

I just read the blog post of Mike Connor, Firefox's lead engineer. And I'm depressed.

In future version of Firefox, it's proposed to "deprecate" the current extension system in favor of jetpack. And I don't know why, but in his blog post, it reads like "remove". And I'm afraid, like many other readers, that the current extension system will be removed.

Update: Mike used wrong words, and it seems that the current install system will be kept, if we believe some responses.

Update: a confirmation by the addons team. No plan to remove the current extensions system.

~~Mozilla, please confirm, officially, that the deprecation and the removal are not in your plans~~ ! If you do it, it will be a big mistake.

I'm not against Jetpack. I agree that it is a good idea to have a mechanism to extend easily the browser. For those who don't know what Jetpack is, it is an extension system with a Javascript API that allows you to add menus, toolbars button, status bar elements, to change things on web pages and more. And you can do it in a few lines of codes, rather easily. The user can load the extension in one click, and there's no need to restart the browser. You can try jetpack right now, with Firefox 3.5. Mozilla plans to include jetpack natively into Firefox 3.7 or 4.0.

So Jetpack, in theory, is good for web developper who wants to create little extension without reading 400 pages of doc.

However, this is pure theory. Jetpack (same applies to the extension mechanism of Google Chrome) has several issues.

First, it has a limited API, and you (as developer) are in kind of sandbox. Mike says "If Jetpack isn’t capable enough, file bugs and request functionality". Well ok, but even if we have an extended API, it will remain limited. And more the API will grow, the harder the API will be to use (so creating an extension that way won't be far easier than today's way of doing). On the contray, the current extension system has not limitl. You can do everything. You can even load any binary components, use any libraries provided by Gecko, and you can do everything you want in the UI, thanks to XUL overlays ! The current extension system is totally OPEN. Jetpack, because of its architecture, of its goal, will never have this openness. We won't be able to create amazing extensions like we do today.

Second, the syntax. Jetpack API is using the jQuery syntax. Web developper, if you don't know what is a closure, or don't understand the concept of closures, creating an extension with Jetpack is not for you.

Third, the goal of jetpack, is to make development of extension easier than with the current extension system. Well, sorry to say that, but for the moment, it is kind of a joke. When the developper have to manipulate XPCOM components or use properties like wrappedJSObject, I don't see where is the progress. Granted, things like jetpack.menu.context.page.on("img").add(..) saves many line of codes, comparing what we have to do in the current extension system.

I have one question, though: why not invest time in the FUEL API ? It was a good start to have a simple API simplifying recurrent tasks compared to the current extension mechanism. It was a good place to include shortcuts API like the ones proposed for Jetpack. I don't understand why it was abandonned...

Fourth, jetpack have some lacks. No possiblity to localize jetpack extensions, many other issues pointed out by Glazou, and worse (IMHO) no possiblity to use XUL instead of HTML. By XUL, I talk about the XML language, not the aggregate of all Mozilla technologies. The HTML box model just sucks to create user interfaces. Some jetpack extensions try to ease the pain absolutely positioning some html elements. It just cannot live with the flexible box model we use in XUL, in the Firefox UI, or in other toolkits in other UI languages (qt or other).. Using HTML elements inside a flexible layout can be a nightmare for the developer, but also for the user because it can break the UI (and possibly induce conflicts with other extensions?). With XUL, you don't have to care about the position of your XUL widgets, just insert them in the right container, and the flexible layout will do the rest. You also write less code because XUL widgets are really made for UI. HTML is not. So IMHO, XUL remains better and simpler than HTML to create UI. In fact, it seems to me that the current Jetpack API tries to reach the power of XUL, but with ugly hacks and using a language (HTML) which is not designed for that goal.

I hope Jetpack will become simpler than it is today and will have less lacks. But for the time being, I'm not entirely convinced by its supposed superiority, even for simple extensions.

But even with enhancements, jetpack won't reach the richness of XPI extensions. If the current extension system is removed from Firefox, it won't be a progress. Firefox will lose some its key values in the current Browser War (except its beautiful logo). No reasons for the user to choose Firefox instead of Chrome or Opera or any other browser. And the project will loose probably many contributors (including possibly myself).

So Mozilla, ok for Jetpack, ok to provide a mechanism to create easily some extensions, but please --confirm you won't deprecate or remove the current extension system-- (done, see update above). Developers should still have access to all the richness and power included in Gecko to allow them to create amazing extensions. Do not build a fence around your technologies and our creativity! Remain Open!

Pub google chrome

Laurentj — Thu, 07 Jan 2010 12:36:00 +0100

Depuis hier, des pubs en 4x3 fleurissent dans le métro et dans les stations RER, vantant les mérites de Google Chrome^[1]. C'est la première fois que je vois une pub pour un navigateur.

Je ne trouve pas cette pub en elle-même super percutante, mais bon, on va dire que c'est un avis très subjectif, à cause de mon statut de contributeur à Mozilla :-).

Mais pas seulement. En fait je la trouve totalement nulle.

En effet, il y a quelque chose qui m'a fait bondir dans cette pub, c'est la mention "0 bug". Ce qui est tout à fait mensonger. Ce n'est pas comme si le nombre de bugs ouverts sur le bugzilla de webkit était à 0, hein. Nous avons même à Zoomorama, découvert des crashers (mais je n'ai plus les numéros de bug sous la main).

Un logiciel a toujours, et aura toujours des bugs. Même dans une pub, on ne devrait pas raconter ce genre de connerie "0 bug", mais plutôt se focaliser sur d'autres aspects du logiciel (rapidité, fonctionnalités ou je ne sais quoi d'autre...^[2]). Dire "0 bug", c'est prendre les gens pour des cons.

Et hop, Google descend encore d'un cran dans mon estime.

Notes

[1] désolé, je n'ai pas de photos, mais j'en ai trouvé une ici

[2] ce que google fait aussi dans la pub

Bonne année !

Laurentj — Sat, 02 Jan 2010 20:29:00 +0100

Bonne année à vous tous ! Que 2010 vous soit meilleur que 2009.

Je n'ai pas vraiment de résolutions pour cette nouvelle année, sauf celle d'essayer de réduire drastiquement ma todo list, sous peine de pétage de plomb. Car j'ai vraiment manqué de temps en 2009. Mes contributions ont beaucoup diminuées, et mes projets perso ont beaucoup pati de ce manque de temps.

Il va falloir que j'arrête de me disperser, de dire oui à tout et que je me concentre sur seulement quelques projets. Ma productivité n'en sera que meilleure, la qualité aussi. Reste à savoir quels projets je "sacrifierais", au moins pour cette année...

Donnez moi du temps pour geeker

Laurentj — Fri, 11 Dec 2009 12:17:00 +0100

J'ai besoin de temps. beaucoup de temps. Par exemple, là maintenant, j'ai besoin de temps pour installer en double boot linux sur mon macbook. Ce n'est pas une nécessité, juste une envie de retourner sur l'OS au pingouin. Linux me manque, après 11 mois passés quasi exclusivement sous MacOS.

MacOS est très bien, il est supérieur en pas mal de points à ses concurrents, notamment la gestion du matériel, ce qui est aussi un peu normal, vu que le système n'est conçu et optimisé que pour un matériel précis. Mais quel bonheur de pouvoir brancher n'importe quel écran et que ça fonctionne du premier coup ! Quel bonheur que la connexion wifi se fasse en 2 clics sans soucis ! Quel bonheur cette gestion de l'énergie sans faille ! Combien de fois j'ai dû refermé mon laptop en urgence pour ne pas rater ma station RER, sans pour autant n'avoir aucun soucis de reprise à l'ouverture (ce qui n'est le cas d'aucun laptop sous linux que j'ai possédé jusqu'ici). Bref, MacOS, c'est le premier OS que j'ai utilisé, qui sait se faire oublier. Tout en étant ouvert aux développeurs, avec sa console, ses origines unix..

Mais il a aussi ses défauts, qui sautent aux yeux quand on a été habitué à une distro linux. Gestion des fenêtres limitée, peu configurable, qui fait qu'il y a des choses énervantes qu'on ne peut changer (comme le fait de devoir cliquer une première fois sur une fenêtre pour l'activer, avant de pouvoir y faire quoi que ce soit). Gestion de bureaux virtuels : à chier. tout simplement. Heureusement que son mode Exposé permet de pallier un tout petit peu à ça.

Et puis c'est énervant de ne pas avoir n'importe quel programme sous la main en deux clics de souris. Sous mac, l'offre logicielle libre est quelque peu limitée (malgré MacPorts). La plupart des programmes sont payants (même si souvent bien foutu), et j'ai souvent une réticence à payer sur le net, surtout sur des petits sites (comment ça paranoïaque ?).

Et puis depuis quelques temps, les screenshots de KDE 4 me font des clins d'oeil. Les news sur les dernières nouveautés du noyau linux me font saliver. J'ai envie de voir si il y a eu de vrai progrès sur le support matériel.

Mais je n'ai pas le temps. Parce que s'engager sur ce genre de chose, veut dire indisponibilité de travailler pour plusieurs heures. Car c'est un peu l'inconnu pour moi l'installation de linux sur un macbook. Ne me parlez pas d'une autre machine. Je n'ai pour l'instant pas trouvé mieux ailleurs (peut être les Dells, ou les anciens Thinkpads). Cette semaine encore, j'ai fait un tour à la Fnac. Et il n'y a pas photo : les plus belles machines, tant d'un point de vue technique (raaaah ce trackpad géant multi touch !) qu'esthétique, restent les macbooks. Bon après, certes, il y a le prix, bien que ça le vaille...

Vous allez me dire que c'est dommage de s'arrêter sur des critères aussi superflus. Mais après 25 ans passés sur des machines diverses et variées (et souvent moches), j'ai envie de faire plaisir à mes yeux. Mine de rien, ça rend le travail plus agréable.

Nouveau serveur pour jelix, et avancées prochaines

Laurentj — Wed, 09 Dec 2009 17:58:00 +0100

Ces jours-ci, j'ai été pas mal occupé à migrer tout les sites de jelix.org vers un nouveau serveur. Merci beaucoup à Nicolas Jeudy pour nous avoir hebergé ces dernières années, et merci à Bastien Jaillot pour nous accueillir sur une de ses machines :-).

Ce ne fut pas une mince affaire, il y a quand même une huitaine de sites et services principaux. Le plus ennuyant étant la forge, qui comporte une vingtaine de projets, tous sous trac. On est passé de trac 0.10 à 0.11, et il a fallu que j'upgrade tout les environnements tracs, mais aussi les plugins, dont un fait maison. Donc étude de la doc de migration, modifier ce qu'il y avait à modifier, vérifier le bon fonctionnement après la migration, adapter les configurations pour le nouveau serveur etc.. Même punition pour notre bug tracker, lui aussi sous trac.

Tout s'est finalement bien passé, mais une chose a été perdue en cours de route : mes beaux templates. Ils ont changer de système de template dans trac 0.11, avec un langage à la XSLT (le langage de transformation le plus hideux de la terre, il faut le dire). Je n'ai pas eu encore le temps de refaire les templates pour avoir le look "jelix.org". Et je ne sais pas quand à vrai dire j'aurais le temps, tellement XSLT ça me gave.

Mais.. J'ai des gentils contributeurs qui vont certainement pouvoir m'aider ;-). En effet, la grande nouveauté avec ce nouveau serveur, c'est que nous en avons le contrôle total, et qu'il n'y a que le projet jelix. Du coup, je peux donner les clefs. Je peux enfin déléguer ! Ce qui est déjà fait en fait. Nous sommes donc trois à pouvoir gérer la machine, et surtout, à pouvoir travailler sur les sites proprement dit, à les faire évoluer. Ce qui va être fait dans les semaines à venir, en commençant par la forge.

Olivier a déjà réalisé des améliorations dans la forge, pour que les utilisateurs puissent gérer plus facilement leurs projets. Ces améliorations seront mis en ligne certainement dans les jours prochains. Au passage d'ailleurs, j'ai migré les sources des sites web de Subversion vers Mercurial. Un autre chantier sera probablement de migrer le forum vers havefnubb, histoire d'utiliser un peu plus d'applications jelix sur nos propres sites :-)

Parallèlement à cette migration, le développement de Jelix n'a pas stoppé (merci Mercurial). J'ai pas mal avancé notamment sur le nouveau système d'installation et de mise à jour de Jelix. Après une troisième refactorisation de code, il commence à se stabiliser en terme de fonctionnement. Ce système va permettre à un module de fournir un script d'installation et de mise à jour, permettant alors d'installer toute une application (base de données, configuration...) en une ligne de commande.

J'espère sortir une beta avant Noël.

PS: si toi aussi, cela t'intéresse de contribuer aux sites jelix.org ou au framework, n'hésites pas à nous contacter.

Jelix sillonne la France en camion

Laurentj — Fri, 20 Nov 2009 13:22:00 +0100

Le Camion Des Mots est un camion qui, dixit le site :

sillonne les routes de France pour aller à la rencontre des enfants scolarisés du CE2 à la troisième (8 à 15 ans). Accompagnés de leur professeur, les élèves participent à une animation pédagogique de 30 minutes sur des ordinateurs. Au cours de leur visite, ils jouent avec la langue française, ses pièges, ses règles et son histoire.

Et cette animation repose sur "4000 jeux éducatifs autour de la langue française et de ses bizarreries".

Le développeur de ces jeux vient de me faire savoir qu'ils sont développés avec le framework PHP Jelix et jQuery. Ce développeur étant en fait un contributeur à Jelix :-)

Et puis bien sûr, c'est Firefox qui est utilisé pour accéder aux jeux.

Bon, à quand un "Jelix Tour" officiel ?

Des nouvelles de IE9

Laurentj — Thu, 19 Nov 2009 13:03:00 +0100

Un nouveau billet sur le IEBlog dévoile les premières nouveautés de IE9. En résumé :

accélération matériel pour l'affichage, en utilisant Direct2D et DirectWrite
meilleures performances générales, et en particulier pour le moteur JS, qui arrive quasiment au même niveau que ceux des concurrents (dans leurs versions de développement)
progression sur le support des standards
- en l'état actuel du développement de IE9, le score au test acid3 est de 32/100. La version finale aura à priori un meilleur score. Il reste toutefois pour l'instant en queue de peloton.
- support des bordures arrondies en CSS (border-radius)
- support des sélecteurs CSS3

C'est encourageant, mais encore bien maigre comme annonce. Quid du support de certaines balises HTML5 comme <canvas>, <video>, audio ? Du support de SVG ? Des APIs de geolocation, web workers, acceleromètre ? Est ce que le moteur JS sera conforme à Ecmascript ? Est ce que l'API DOM sera enfin conforme aux spécifications DOM2 ? DOM3 ? Et j'en passe...

Il y a peut-être des réponses à ces questions dans les vidéos pointées par ce billet, mais je n'ai pas pu les lire, il faut installer Silverlight... (j'ai assez d'un plugin propriétaire dans mon navigateur...).

Javascript coté serveur

Laurentj — Fri, 13 Nov 2009 06:39:00 +0100

Ça commence à faire pas mal d'année que je fais du javascript, non seulement pour le web, mais aussi dans les applications XUL. Ce qu'il y a d'intéressant à utiliser Javascript avec le XUL, c'est qu'on peut se lâcher, et utiliser tout le potentiel du javascript de la plateforme Mozilla, comme les générateurs et iterateurs, les propriétés et méthodes avancées sur les objets de base (comme sur Array). Même si je ne suis pas fan de certaines constructions syntaxiques^[1].

Et depuis quelques jours j'ai une lubie : pourquoi ne pas utiliser javascript coté serveur, en remplacement de PHP par exemple ?

Et j'ai découvert sur wikipedia qu'il existait quelques dizaines de projets de générateurs de pages web à base de javascript. La majorité de ces projets reposent sur les moteurs JS de Mozilla :

SpiderMonkey, le moteur (en C) utilisé dans Firefox 3/Gecko 1.9.0 et précédent
Rhino, un moteur en java

Ceux à base de SpiderMonkey m'intéresse plus particulièrement. Je ne les ai pas encore tous regardé, mais jslibs semble sympa, dans la mesure où la dernière version ne repose plus sur SpiderMonkey, mais sur TraceMonkey, le moteur JS accéléré de Firefox 3.5.

Pour faire le choix d'un de ces projets, il va falloir regarder de plus près les API proposées. En effet, il faut savoir qu'un moteur JS ne fait qu'exécuter du code, et ne contient nativement que quelques objets primitifs comme String, Array, Date, Math... C'est au code embarquant de "brancher" des bibliothèques ou fonctions C sur des objets JS (faire des wrappers donc), pour enrichir l'API utilisable dans le code JS. Ce que fait d'ailleurs un navigateur, pour les objets window, document, les objets DOM etc.

Reste aussi à faire quelques benchmarks, pour voir si ça vaut vraiment le coup par rapport à PHP, Python ou autre..

Notes

[1] disons que depuis la publication de ce billet, j'ai un avis moins tranché :-) On s'y fait

Et le meilleur moteur javascript est....

Laurentj — Tue, 10 Nov 2009 18:01:00 +0100

On voit circuler ces slides sur des astuces pour les perfs en javascript, et on y voit notamment que les résultats de Firefox par rapport aux autres moteurs, notamment V8, ne sont pas folichons.

Cependant, comme beaucoup de benchmarks, ces résultats sont sujets à cautions, d'autant plus qu'ici :

On ne sait absolument quelles versions de chaque moteur sont mises en comparaison
Comparer SpiderMonkey, moteur d'ancienne génération (Firefox 3.0 et précédent), à V8, ce n'est vraiment pas "fair play". Il aurait pu prendre au moins TraceMonkey (Firefox 3.5). À moins qu'il confond dans les noms, mais ça m'étonnerai, car pour les quelques tests que j'ai effectué avec son script, les résultats de TraceMonkey sont plus proches de V8 que de IE (dernières versions stables des navigateurs).

Et puis bien sûr, aucune mention d'Opera.

Enfin, c'est bien beau d'avoir un moteur rapide, encore faut il qu'il soit en conformité avec la spécification Ecmascript. Ce qui est encore loin d'être le cas pour certains d'entre eux.

Payer en ligne devient de plus en plus compliqué avec la Société Générale

Laurentj — Fri, 30 Oct 2009 13:06:00 +0100

Payer sur Internet, ça devient vraiment le parcours du combattant, en tout cas pour ceux qui sont à la Société Générale. De quoi vraiment dégouter les gens d'acheter quelque chose. Jugez plutôt.

Dans les débuts du commerce électronique sur internet, payer sur internet consistait à donner votre numéro de carte et la date de validité. Pour cela, vous étiez redirigés vers une page de la banque de la boutique électronique (c'est toujours le cas aujourd'hui).

Mais cela ne suffisait plus, ils décidèrent alors qu'il fallait aussi donner un numéro à trois chiffres situé derrière votre carte.

Puis il y a 2-3 ans (je crois), ils décidèrent qu'il fallait indiquer en plus d'autres données, comme votre date de naissance et ceci dans une autre page vers laquelle vous étiez redirigés après le premier formulaire, page fournie par votre banque. La première fois, j'ai cru que j'avais été redirigé vers une page de phishing, tellement le nom de domaine ne ressemblait à rien, et tellement ma banque ne m'avait pas informé d'un tel nouveau dispositif. Résultat, j'avais annulé ma commande en attendant d'en savoir plus.

Au passage, on constatera qu'on a deux redirections, et donc au total trois formulaires à remplir : celui du commerçant pour vos coordonnées pour la livraison ou autre, celui de la banque du commerçant, et enfin celui de votre banque.

À ce stade, ça commençait à m'agacer.

Et voilà que la Société Générale a décidé d'emmerder encore plus ses clients (pour notre sécurité parait-il). Ils ont remplacé le formulaire de saisie de la date de naissance par un autre formulaire, dans lequel vous devez indiquer un code. Ce code vous est envoyé automatiquement par la banque, par SMS, sur votre téléphone portable. Le souci, c'est que pour recevoir ce code, il faut s'être inscrit auprès de votre agence ou par un service vocale (je ne sais plus), pour activer le service de paiement sur le web, et indiquer votre numéro de téléphone. J'avais bien reçu il y a quelques semaines un courrier m'avertissant de ce changement, mais je n'ai pas eu le temps et oublié de faire cette activation, et surtout ça me faisait chier.

Ça me faisait chier de m'inscrire parce que d'une part, les trucs administratifs, ça me gonfle à un point que vous ne pouvez imaginer, et d'autre part, je trouve ce système idiot. Vous avez perdu ou oublié votre téléphone ? Il n'a plus de batterie ? Tant pis pour vous, allez voir ailleurs, ne payez pas ce que vous devez payer. Et hop, un client de moins pour le commerçant. Et tant pis si c'est un achat urgent (comme, au hasard, un renouvellement de nom de domaine).

Et voilà, j'ai un truc à payer, là, maintenant, et je me retrouve coincé, je ne peux pas recevoir ce pu*** de code parce que j'ai omis de m'inscrire (et bien sûr, je n'ai pas sur moi les numéros de comptes, de code en tout genre ou je ne sais quoi d'autres pour activer de suite le service).

Vous allez voir que ça ne va pas suffire pour contrer les fraudes, parce que bien sûr, ça ne va pas empêcher les voleurs de sacs à main d'aller acheter sur internet, puisqu'ils auront votre carte bleu et votre téléphone^[1], et que dans 2 ans, il va falloir vous trimballer avec un lecteur d'empreinte digitale pour payer sur internet^[2]. Et dans 3 ans, ça va être quoi ? un lecteur d'empreinte génital ? rectal^[3] ? Il va falloir prouver 15 fois que c'est bien vous le propriétaire de la carte bleue avant de valider le paiement ?

Du grand n'importe quoi. Déjà que je n'avais pas une haute estime de la relation des banques avec internet, avec entre autre leurs API de paiement^[4] pour ajouter un système de paiement dans votre site web, mais là, ça commence à friser le ridicule. Pour votre bien on vous dit !^[5]

Notes

[1] certes, il y a moins de vols de sac à main que de piratage de carte bleue sur internet

[2] j'ai cru comprendre que certaines banques proposaient déjà un tel ustensile

[3] classe de payer au bureau, devant les collègues, non ?

[4] SIPS par exemple, qui fournit quasiment le même binaire depuis 8 ans, binaire qui ne fonctionne que sur des vieux noyaux linux plus maintenu (on peut en obtenir un plus récent, seulement après avoir donné 15 coups de téléphone) , avec une API pourrie, qui génère du code HTML pourri, etc. Il y aurait tant à dire, peut être un jour j'en ferais un billet tiens.

[5] Bien sûr, ce billet contient une pincée de mauvaise foi :-)

Transitions CSS

Laurentj — Fri, 16 Oct 2009 13:24:00 +0200

La version de développement du futur Firefox 3.7 implémente depuis quelques jours les transitions CSS. Vous avez peut être pu le voir, en lisant Paul qui a parlé discrètement sur son blog, en même temps que la nouvelle implémentation de l'API de l'accéléromètre. Vous pouvez voir une démo de Paul avec les transitions CSS.

Le principe est assez simple:

avec la propriété transition-property, vous indiquez les propriétés CSS qui seront concernées par la transition, c'est à dire, quand leur valeur changera, il y aura une transition entre l'ancienne valeur vers la nouvelle valeur, le changement ne sera donc pas immédiat.
transition-duration permet d'indiquer la durée de la transition, pour chacune des propriétés
transition-timing-function, indique la fonction de transition, c'est à dire la manière dont la transition sera faite. Par exemple la fonction ease-in-out fait une transition rapide au début, lente au "milieu", et rapide à la fin. On a ainsi des fonctions pour faire des effets élastiques, smooth etc..
transition-delay pour indiquer à partir de combien de temps la transition doit être faite, à partir du moment où la valeur est changée.
transition pour indiquer tout ça en une seule instruction.

Voir la spécification complète sur le site du W3C (spécification qui est encore un brouillon).

Un exemple :

  .mydiv {
     width: 100px;
     transition: width 1s linear;
  }

 .mydiv:hover {
    width:200px;
 }

Quand on passera la souris au dessus de l'élément, sa largeur changera à 200px. Avec la propriété transition, ce changement ne sera pas immédiat. La largeur passera de 100px à 200px en 1 seconde, de manière linéaire. Bien sûr, ce changement de valeur peut être fait via javascript plutôt que sur un :hover, par exemple: document.querySelector(".mydiv").style.width="200px";.

Le gros intérêt de ces propriétés CSS, c'est que ça va rendre obsolète beaucoup de fonctions d'animations que l'on retrouve dans beaucoup de frameworks javascript (jquery, mootools...). Ça permettra des pages plus légères (les frameworks seront moins lourds à terme) et plus rapide.

C'est donc implémenté dans webkit (donc dans Safari, et Chrome je crois), et dans une future version de Firefox, en utilisant bien entendu les prefixes -webkit- et -moz- sur les propriétés pour que ça fonctionne.

Et, comme je l'avais déjà dis il y a quelques mois dans un billet sur notre technologie à Zoomorama, c'est aussi implémenté dans notre browser (développé en actionscript 3). J'ai mis en ligne deux démos faites par David Marteau, et c'est utilisable dés maintenant dans vos fichiers ZML :-)

TI: interdiction de bidouiller sa machine ??

Laurentj — Wed, 14 Oct 2009 16:02:00 +0200

Mékilsoncon ! Texas Instrument interdit d'installer un firmware sur ses calculatrices, pour des histoires de droits !

D'un coté, ça ne m'étonne pas, j'ai toujours trouvé que Texas Instrument faisaient des calculatrices ~~de mer..~~ pas assez bidouillables. Au début des années 90 déjà, faire un programme qui utilisait au maximum les possibilités de la machine (comprendre, en assembleur), c'était presque mission impossible. Fallait faire des hacks de malade, peu pratiques. Peu interressant.

Contrairement à HP. Dans les HP48 par exemple, en programmation RPL, il y avait des objets pour les nombres, pour les chaines, pour les sources en RPN, pour les bibliothèques etc. Et il y en avait aussi... pour les programmes binaires ! On pouvait donc installer un assembleur (merci à Phong "hpninja" Nguyen pour avoir crée le premier assembleur sur hp48 :-)), et coder comme des malades en assembleur, créé des binaires super optimisé, torturant au maximum cette petite machine, arrivant à en faire une véritable console de jeu digne des gameboys de l'époque ! (qui plus est, autorisées officiellement en cours et au BAC :-) ). On pouvait aussi appeler en RPL, des routines de la ROM, offrant encore plus de possibilité à celui qui programmait simplement en RPL (non officiellement documentés, mais heureusement, il y avait des livres pour ça, merci Paul Courbis et Sebastion Lalande !).

Bref, je me suis éclaté avec cette machine (en réalisant entre autre ces programmes là). Et d'autres développeurs aussi, au point de justement refaire un OS (le metakernel !). La mémoire ROM à l'époque n'était pas flashable (encore chère à l'époque), mais il y avait de quoi changer le boot, pour faire démarrer la machine sur un autre endroit que la ROM.

HP n'a jamais d'ailleurs interdit ces pratiques ou limiter cette "bidouillabilité", bien au contraire. Ils ont même fini par embaucher des auteurs du metakernel, qui servira de base plus tard à l'OS de la HP49.

Les gusses de Texas Instrument devraient y réfléchir...

L'utilité de l'API de l'accéléromètre dans les navigateurs

Laurentj — Wed, 14 Oct 2009 14:59:00 +0200

Paul Rouget nous a fait de jolies demos (que vous pouvez voir en vidéo sur hacks.mozilla.org), pour montrer ce qu'on peut faire avec la nouvelle API qui permet de profiter de l'accéléromètre embarqué dans votre laptop ou tablette.

Les réactions n'ont pas tardé un peu partout sur le web, et en gros, j'en ai retiré 3 différentes :

"vous feriez mieux de travailler sur autre chose"
"c'est inutile, ça sert à rien"
"c'est génial !"

Pour le "vous feriez mieux de travailler sur autre chose", on va passer vite fait, c'est du pur troll. Il y a plusieurs dizaines de développeurs qui bossent à temps plein sur Firefox, et il est évident que chacun bosse sur des sujets différents. Le support de l'accéléromètre a été fait par un seul gars, pas 250. Bref, ce n'est pas une perte de temps.

Les deux autres remarques sont plus intéressantes. Et en analysant (à l'arrache) les réactions, j'ai remarqué qu'en fait la première semblait être faite principalement par des non-développeurs, et la deuxième par des développeurs.

En fait, beaucoup de gens, en voyant une des démos qui montre une page web s'orienter ou se tordre en fonction de l'orientation du laptop, n'ont pas vu l'intérêt technique de la chose. Ils ont regardé la démo "au premier degré" pourrait-on dire. Il y en a qui ont cru comprendre que dans les prochaines versions de Firefox, les pages web s'orienteront en fonction de l'orientation du laptop. Du coup, ils disent que ça ne sert à rien, qu'ils ne bougent de toute façon pas leur laptop, ou encore que c'est une horreur, parce que quand une image s'affichera dans le mauvais sens, ils ne pourront plus basculer leur laptop pour voir l'image dans le bon sens, etc...

Et en fait, ce n'est pas du tout ça, et effectivement, la démo est peut être mal choisie au final. Car en fait, l'intérêt de la démo se trouve sous le capot, dans le code source de la page, pour montrer avec quelle facilité on peut utiliser l'accéléromètre. C'est pourquoi la plupart qui ont trouvé cette démo géniale sont je pense des développeurs, ils ont regardé le source de la page.

Il faut donc juste comprendre que Mozilla a mis à disposition un outil, pour les développeurs web. Et il est tellement nouveau que des usages concrets de cet outils restent à inventer. On sait que l'une des premières utilités est pour les jeux, sur Fennec, la version mobile de Firefox, ou pour la version desktop sur les tablettes, comme on peut voir dans les jeux pour IPhone. Pour d'autres utilités, surtout sur le desktop, nul doute que des développeurs vont en trouver ! C'était pareil pour <canvas>, <video>, l'api de géolocalisation etc.. On ne voit pas toujours l'intérêt d'une nouvelle techno quand elle débarque. Mais au final, des usages sont inventés, créés.

Ça me rappelle d'ailleurs la conférence de Paul et Tristan à Paris Web, durant laquelle Paul fait plein de démos sur des nouvelles technos présentes ou à venir dans Firefox, et ajoutant à un moment donné, "j'ai pas dit que ça servait à quelque chose", suivi d'un grand rire dans la salle. Oui, au visionnage des démos (genre une vidéo de Tristan Nitot tournant en rond), un utilisateur lambda, voire un développeur web, peut effectivement se demander l'intérêt de tel ou tel truc. Mais en y réfléchissant, ou quand il sera confronté à un besoin précis, peut être bien qu'il en trouvera.

Si d'ailleurs vous avez des idées de l'utilité de l'accéléromètre dans une appli web, signalez les à Paul ou ici dans les commentaires, cela lui permettra de faire des démos "plus utiles" du point de vue de l'utilisateur :-)

PHP n'est pas un bon langage de template

Laurentj — Thu, 08 Oct 2009 12:39:00 +0200

Ça me fait plaisir de lire ce genre de billet, surtout venant de la part d'une figure du monde PHP, à savoir Fabien Potencier (monsieur Symfony). Ça fait des années que je pense comme Fabien : PHP est un mauvais langage de template. Pas assez sécure (que fait-t-on des templates uploadés par des utilisateurs par exemple ?), trop verbeux, parfois trop complexe pour les intégrateurs web qui ne savent pas programmer, et n'impose pas une séparation entre logique métier et "vue" (vu que dans un template en PHP, on peut appeler tout et n'importe quoi).

C'est pourquoi j'ai toujours préfèré utiliser un langage qui soit conçu pour les templates, pour faciliter leurs écritures d'une part, et de bien faire une séparation entre la logique métier et la "vue". Et c'est pourquoi dans Jelix, j'ai crée mon propre moteur de template, ultra léger et performant, jTpl, qui est disponible en version standalone, dont je devrais sortir la version 1.0 dés que j'ai un peu de temps.

De retour de Prague

Laurentj — Mon, 05 Oct 2009 16:42:00 +0200

Encore une fois, l'équipe de Mozilla Europe s'est démenée pour nous offrir un MozCamp de qualité. Organisation impeccable, lieu impeccable. Merci beaucoup William, Irina, et Paul (j'en n'oublie pas ?), j'ai vraiment apprécié ces trois jours !

J'ai trouvé les conférences intéressantes, et plus encore, la joie de retrouver d'autres contributeurs (plus de 140 !). C'est l'occasion de se voir "en vrai", de pouvoir discuter sur les projets actuels et futurs, et au passage de pratiquer un peu son anglais. Et bien sûr de passer de bons moment autour ~~d'une~~ de plusieurs bières Tchèques, que ce soit à 20-30 ou en petit comité tard le soir, pour discuter de Mozilla, de la life, 42. Quelques bons petits moments de distractions dans cette vie de fou :-). Ça recharge les batteries !

Fortune

Laurentj — Fri, 25 Sep 2009 15:08:00 +0200

Je ne peux m'empêcher de publier un extrait d'un message interne, véritable fortune d'auto-satisfaction de mon collègue Olivier^[1], core-developer du browser de zoomorama, à propos donc de ce browser et d'une demo pour un client :

Mais quand même, je peux pas m'empêcher d'avoir une demi-molle :-): un putain de *browser* avec une putain d'implem DOM *from the ground-up*, du scripting hystéro-maniaque comme si les anglais avaient débarqués, de la stylesheet de motard poilu, du content delivering fondant sous la langue comme un clitoris de parturiente

Mais c'est vrai que c'est assez impressionnant ce qu'on arrive à faire. David et Olivier, vous déchirez :-)

Notes

[1] il est bien entendu d'accord pour la publication

Agenda d'octobre chargé

Laurentj — Fri, 25 Sep 2009 14:23:00 +0200

Que d'évènements en ce mois d'octobre à venir !

Du 2 au 4, je serais à Pragues, pour le MozCamp 2009
Le 8 et le 9, je serais aux conférences Paris Web. je crois qu'il reste encore des places, allez-y ! C'est un évènement à ne pas manquer pour les développeurs web, chefs de projets etc. Tous les ans, ce sont des conférences d'excellentes qualités, faites par des vrais professionnels du métier, et organisées par une équipe au top ! Le prix est ridicule (surtout pour une boîte), en regard des connaissances enrichies qui vous seront transmises.
Enfin, du 19 au 23, Fabien Cazenave (monsieur Kompozer) et moi allons dispenser des cours sur les technologies Mozilla, à l'université d'Evry. C'est le projet Comete. Une première en France :-)