Un benchmark des performances des solutions RIA

J'ai publié cet article ici pour les retardaires qui n'auraient pas encore noté le déménagement de ce blog... je vous encourage donc à aller le voir ici, en particulier si vous voulez faire un commentaire (ceci étant officiellement le dernier message à être publié à cette adresse).

J’avais souligné il y a quelques temps combien le besoin de comparer objectivement les solutions RIA se faisait pressant. J’avais fourni une première base de comparaison avec les fonctionnalités disponibles dans chacune des technologies et leurs exigences pour être déployées.

Il manquait deux éléments pour que la comparaison soit valable :

1- la productivité

2- les performances

Voilà justement un benchmark qui permet une bonne comparaison des différentes solutions en terme de performances. Le code source utilisé étant disponible pour chaque implémentation, on peut aussi avoir une petite idée du potentiel de productivité de chacune de ces technos.

A l’heure du choix d’une techno RIA, un site à visiter et à revisiter sans hésiter…

Alerte : Web2rules déménage !

J'avais annoncé, il y a environ 6 mois, un déménagement de ce blog afin de bénéficier des atouts de la plate-forme wordpress. Cette heure est aujourd'hui venue : vous pourrez désormais lire mes bafouilles sur blog.eutech-ssii.com et en finir avec le système de commentaires assez rebutant
qu'est celui de blogger.

Pensez aussi à changer votre flux RSS : http://blog.eutech-ssii.com/feed/rss2/
Pour les fans, le flux des commentaires existe aussi maintenant : http://blog.eutech-ssii.com/comments/feed/

Vous pouvez au passage laisser votre impression sur le nouveau look du blog, y compris
avec des phrases du genre "tiens, il a gardé son rose tout pourri ?" ou encore "encore un mec qui se la donne alors qu'il s'est contenté de repomper un thème wordpress !".

AIR / Gears : la preuve par ext

Mon billet précédent vous annonçait combien AIR et Gears étaient proches dans leur philosophie mais je ne m'attendais pas à une confirmation aussi rapide de cela dans les faits.

Pour s'amuser un peu, Jack Slocum auteur de la très réussie librairie ext, a décidé de se prendre quelques Red Bull et de coder une application AIR. Résultat ? Il nous pond un truc qui marche aussi bien avec AIR qu'avec Google Gears, en nous faisant don au passage d'une petite couche d'abstraction permettant de coder simplement une application qui fonctionnera sous l'une ou l'autre formule.

Les vainqueurs de la vague RIA ne seraient-ils pas déjà là ?

AIR (ex Apollo) / Google Gears : même combat !

Je ne suis pas de ceux qui tracent une ligne rouge entre ce que certains appellent RDA (pour Rich Desktop Application qui s'exécutent hors navigateur) et les RIA (Rich Internet Application qui s'exécutent dans un navigateur).

Les marchés, les technologies, les contenus et les possibilités de ces 2 familles sont trop proches pour les considérer comme véritablement distinctes... Je continuerai donc ici de parler de plate-formes RIA pour des technos aussi différentes que WPF, AIR, Ajax, Flash, Silverlight, XUL, Java ou les plate-formes de widgets : j'excluerai par contre OpenLazlo ou Flex de cette terminologie dans la mesure où ils ne sont que des technologies serveur (pour plate-forme RIA, certes) et non des runtimes.

Cette proximité entre des technologies au prime abord assez différentes me paraît d'ailleurs chaque jour un peu plus évidente. Dernier exemple en date avec quelques essais menés sur Google Gears d'une part et AIR d'autre part.

Ces 2 technos partent d'un même principe : l'inertie des habitudes de développement web est telle, la concurrence entre nouvelles technos si féroce, que pour s'imposer il vaut mieux accomplir une révolution douce. Et quel est le discours de ces gentils révolutionnaires ?

- Continuez à utiliser vos technos de développement web : Ajax, Flash... ce sont de bonnes technos, et vous avez encore pas mal de clients à satisfaire avec.
- Continuez à développer des sites/applications que l'on peut visiter avec un simple navigateur : c'est une avancée majeure du web qu'il ne faut pas perdre.
- Allez plus loin sur certaines fonctionnalités avec les clients/utilisateurs qui le souhaitent grâce à nos technologies : mode offline, accès aux ressources systèmes.
- Soyez rassurés, nos technologies sont convergentes : Javascript, XML, SQLite...

Et vous savez quoi ? C'est vrai ! Il n'agit pas simplement d'un discours commercial comme on en a beaucoup entendu ces dernières années. Les quelques essais que nous avons faits mes collègues et moi, nous ont montré que pour une même application les implémentations AIR et Gears sont très proches... et, ça, c'est une très bonne nouvelle, vous ne trouvez pas ?

Traduction de "What is web 2.0" : nouvelle release

Avec l'aide de Christelle, collaboratrice de passage, j'ai pu compléter les quelques morceaux qui manquaient à la version française de "What is web 2.0", l'exposé de la brillante vision de Dale Dougherty et Tim O'Reilly. Tout cela a été mis sur le site de la jeune et sympathique société de votre serviteur. Les liens de la version originale ont également été ajoutés et quelques bourdes corrigées.

Ce nouveau petit plongeon dans cet article fondateur a d'ailleurs été pour moi l'occasion de constater que près de 2 ans après, il garde encore toute sa fraîcheur et sa pertinence comme si ses grands principes étaient intemporels...

Pour les connaisseurs, quelques raccourcis vers les nouvelles parties traduites (ce sont les pavés latéraux) :
Une plateforme gagne contre une application à tous les coups
L'architecture de participation
Une thèse de l'investissement dans le Web 2.0
Les modèles de conception du Web 2.0

Développement Ajax : quelques clés pour une architecture javascript moderne

A l'heure où Ajax se répand au point d'envahir bon nombre des offres d'emploi de certains sites spécialisés et où de plus en plus de code repasse côté client, il devient nécessaire de se poser quelques questions sur l'architecture des développements Javascript.

Ces questions, les voici :
1- Utilisera-t-on (ou non) des frameworks intégrant serveur et client (backbase, GWT, webdev) ?
2- Le javascript sera-t-il situé uniquement côté client ou alors sera-t-il aussi généré par le serveur ?
3- Quelles librairies js utiliser côté client ? comment les articuler ?
4- Utilisera-t-on (ou non) Javascript comme un vrai langage objet avec "espaces de nom" et "classes" héritant les unes des autres ?
5- Quelles couches distinguer dans le développement Javascript et comment les articuler à la fois entre elles et avec les couches serveur ?
6- Quelles bonnes pratiques architecturales suivre de manière générale en js ?

Je vous donne rapidement MES réponses à ces questions... je tranche assez franchement pour mieux faire naître le débat !

1- Un framework Ajax côté serveur ?
Non, déléguer la reponsabilité du client à une technologie serveur est une mauvaise idée. Ca vous permettra peut-être un temps d'être plus productif, mais certainement pas sur la durée. Pour traiter les problèmes côté client, il est bien entendu beaucoup plus efficace d'utiliser une technologie cliente... même si ça peut paraître pénible à certains de se (re)mettre à Javascript, XHTML et aux css.

2- le JS côté client uniquement ?
Oui, autant que cela est possible... les avantages sont nombreux : séparation des couches applicatives claire, performance, productivité du développement sur le long terme.

3- quelles librairies JS ?
Une et une seule bonne librairie "noyau" (prototype ou JQuery sont mes premiers choix mais il n'est pas interdit de regarder ailleurs... en faisant très attention !) qu'il faut utiliser à fond : plus question par exemple d'utiliser prototype uniquement pour Ajax.Request ! La librairie noyau doit servir à la gestion des événements, la manipulation du DOM et aux appels AJAX dans l'ensemble de votre code.
Si vous avez bien choisi la librairie noyau, les éléments qui viennent s'y raccrocher (en particulier les effets graphiques évolués) ne devraient pas vous manquer.

4- des classes et des espaces de nom ?
Oui, bien sûr ! Même si javascript n'offre pas ces possibilités de manière native, il est tout à fait possible de les simuler et de tirer tous les bénéfices que l'on connaît depuis longtemps côté serveur à ces pratiques. Prototype en est un excellent exemple.

5- quelles couches côté JS ?
A l'heure où le stockage local devient une réalité dans les applications Ajax, établir une véritable couche d'accès aux données paraît de plus en plus incontournable : lire à ce sujet le très bon brief de l'équipe de Google Gears.
De manière générale, les couches côté JS vont ressembler de plus en plus à celles que l'on connaît habituellement "server side" : données / accès aux données / logique métier / interface. Tout le défi va être d'articuler cela avec les responsabilités attribuées au serveur : rien d'infaisable en réalité.

6- les bonnes pratiques architecturales JS ?
Ce ne sont évidemment pas tout à fait les mêmes que sur une technologie serveur : Javascript est un langage bien particulier (mais pas un sous-langage !) et le client riche pose des problèmes très spécifiques. Cependant, ça n'empêche pas, bien au contraire, d'avoir recours à des motifs de conception pour bien aborder et résoudre la plupart des problèmes : un petit tour sur Ajax Patterns sera utile à toute personne qui se pose de bonnes questions sur le sujet.

Allez-y, réagissez, indignez-vous, lancez moi des fleurs, insultez moi ! Ces questions-là sont capitales, alors il vaut mieux en parler...

Google Gears : tout l'intérêt de WorkerPool en une démo

Je reviendrai très prochainement plus en détail sur ce qui risque de changer Google Gears pour les utilisateurs, les développeurs et les entrepreneurs du web... mais je ne résiste pas dans l'attente au plaisir de vous faire partager une petite démo qui montre tout l'intérêt d'une partie de Gears qui n'a, semble-t-il, pas été apprécié à juste valeur par nombre de lecteurs : WorkerPool.

En effet, si les atouts d'un serveur et d'une base de données accessibles en JS sur le poste client paraissent assez évidents, le concept du workerpool l'est moins. Rappelons-le. Le workerpool permet de faire fonctionner des morceaux de javascript dans un processus différent des autres. Ce n'est pas vraiment un "thread", mais ça a le même goût : les processus créés ne se bloquent pas les uns les autres et sont traités de manière efficace par le système d'exploitation.

Pas convaincu ? Après avoir installé Gears, essayez la démo suivante avec workerpool et sans workerpool... on reparlera ensuite des limites de performance de javascript !

Google Gears... une révolution ?

Je ne pouvais décemment pas passer à côté de la sortie du projet sur Google Gears après tous mes articles sur le web offline. Faute de temps, il va néanmoins me falloir faire (très) court sur le sujet pour le moment.

Google Gears arrive en 3 morceaux : workerpool (une solution pour faire tourner le JS hors du runtime habituel du navigateur), localserver (un mini-serveur web pour page stockées en cache) et Database (une base de données SQLite munie d'une API Javascript).

Cela n'a pas grand chose à voir avec l'approche de Dojo Offline Toolkit, mais c'est tout de même très excitant : cette solution est même techniquement à ce point séduisante qu'elle pourrait à terme être inclue dans les systèmes d'exploitation et/ou les navigateurs. On parie ?

Les principales technos RIA enfin comparées

Cela faisait un moment que je recherchais un comparatif clair entre les technologies RIA majeures : n'ayant rien trouvé de satisfaisant, j'ai décidé de faire mon propre comparatif.

Vous trouverez donc ci-dessous Flash, Ajax, Apollo, WPF, Silverlight et Java comparés au regard des critères qui permettent - pour moi - d'apprécier une technologie RIA : dessin vectoriel, animations, multimedia, mode offline, 3D, accès système, besoin d'installation, cross-platform.

	Des. Vect.	Animation	3D	Multimedia	Accès syst.	Offline	Installation	Multi plateforme
Flash	Oui	Oui	Difficile	Oui	Non	Difficile	Plug-in	Oui (dont mobile)
Ajax	Limité	Limitée	Non	Non	Non	Difficile	Non	Oui
Apollo	Oui	Oui	Difficile	Oui	Oui	Oui	Oui	Oui
Silverlight	Oui	Oui	Non	Oui	Non	Non	Plug-in	Windows / MacOSX
WPF	Oui	Oui	Oui	Oui	Oui	Oui	Non	Vista / XP SP2
Java	Oui	Oui	Oui	Perfectible	Oui	Oui	Oui	Oui (dont mobile)

Conclusion ? Java semble être la killer app des RIA ! Le gros problème de ce comparatif, c'est qu'il occulte quelques points importants : performances (et là, Java en prend un coup), et productivité du développement en particulier.

Ma préférence personnelle continue à aller vers Ajax dans la mesure où il peut avantageusement tirer partie de toutes les autres technologies selon les besoins. La productivité du développement reste évidemment son gros problème, mais on y progresse indéniablement.

Et vous, votre opinion ?

HTML 5 sur les rails !

Grande nouvelle : le W3C a accepté d'utiliser le travail du WHATWG comme base de spécification pour HTML5 !

On peut donc affirmer que les grandes avancées proposées jusque là dans les working draft (la balise canvas, les datagrids, la cohérence HTML/DOM/javascript...) ont désormais de grandes chances d'être officiellement recommandées par l'organisme de Tim Berners-Lee.

Je vous invite à relire mon article sur HTML5 pour comprendre à quel point cela est une bonne nouvelle...

Tamarin : le futur de Javascript par Adobe et Mozilla

A une époque où le web est la technologie dominante et Javascript son nouveau ressort, on comprend aisément que ce qui peut révolutionner Javascript peut changer beaucoup de choses par ailleurs.

Javascript, je l'ai déjà dit à de nombreuses reprises est bourré de défauts, et parmi ceux-ci, ses performances calamiteuses n'est pas le moindre. Or, à l'heure où tout est bon pour faire du javascript, cela peut s'avérer très pénible. Pénible au point que notre web 2.0 se surprend à reprendre des couleurs 1.0, lorsque toutes ces jolies fonctions ajax qui facilitent la vie de l'utilisateur se mettent à patiner à un point invraisemblable. Pire : certaines applications (comme la 3D) resteront hors de portée de JS tant que ces limitations ne seront pas levées.

Une fois encore, le problème de vient pas vraiment de javascript en tant que langage mais plutôt des moteurs d'exécutions embarqués dans les différents navigateurs... et c'est précisément là que Tamarin intervient.

Tamarin est le nom de code donné par Adobe à son projet de moteur ecmascript (javascript si vous préférez, la nuance est subtile) destiné à le booster significativement en le compilant Just In Time en code machine (façon Java ou .Net) : une excellente idée... Et Adobe ne s'est pas arrêté en si bon chemin, puisqu'en novembre dernier, le code du projet a été ouvert et que le leadership du projet confié à la fondation Mozilla.

Résultat ? Les applications web de demain pourront être autrement plus exigeantes que les bricolages d'aujourd'hui ! Pour être plus précis, sachez que FlashPlayer 9 utilise déjà Tamarin et Firefox devrait l'intégrer en 2008 (à l'occasion du passage vers Javascript 2). C'est aussi pour cela qu'à contre-courant de l'actualité, je choisis de parler aujourd'hui de ce projet : parce qu'il crédibilise encore un peu plus Ajax et Flash face aux alternatives RIA montantes.

Dojo Offline Toolkit : la beta est sortie

Annoncé dès janvier, Dojo Offline Toolkit fait partie de ces projets qui m'ont immédiatement passionné : visionnaire et pragmatique, DOT répond à un vrai problème (le web offline) avec d'excellentes solutions. J'avais d'ailleurs expliqué le fonctionnement de DOT dans un précédent billet.

L'infatigable Brad Neuberg a sorti une première version bêta hier. Je la qualifierais personnellement de version alpha tant il reste de problèmes à résoudre :
- seules les plate-formes MacOS X et Windows (hors Vista) sont supportées à ce jour
- de nombreux bugs restent à corriger
- la couche de persitance en javascript doit devenir plus indépendante de Dojo

Malgré tout cela, il faut saluer la performance et ne pas hésiter à commencer les tests (et remonter les bugs) sur cette techno sous license BSD et franchement très prometteuse.

Quelques ressources pour aller plus loin :
La FAQ
Une démo (Moxie, un éditeur de texte... attention bugs !)
Le SDK pour les développeurs
Une video expliquant l'intérêt du web offline version DOT

Google "PowerPoint" : le retour de Java sur le web ?

Le web est un truc si riche qu'il retrouve régulièrement de vieilles techniques comme solution à de nouveaux usages :
- c'est ainsi qu'on a redécouvert, il y a 3 ans, Javascript pour enrichir les interfaces
- que Flash redevient une solution acceptable pour de nombreux problèmes
- et que Java pourrait repointer le bout de son nez à la faveur de Google

Je m'explique. Google nous a récemment expliqué que son powerpoint maison (prévu pour l'été) utiliserait une technologie venue d'une boîte rachetée récemment (Tonic Systems). Le site de la boîte en question a disparu mais le cache Google (!) nous apprend que ces gens proposaient une API Java pour faire du powerpoint.

Et alors, me direz-vous ? Et alors, vous dirais-je, il se pourrait fort qu'utiliser Java (côté client) soit une excellente solution pour :
- d'une part, faire du offline/online
- d'autre part, faciliter un certain nombre de fonctions très pénibles pour l'utilisateur web telle que la copie d'images.

Si tout ce que je dis se vérifiait, ça pourrait marquer le retour de Java très intéressant à l'époque des RIA... Et puis jouer les madames Irma ne m'a trop mal réussi jusque là, alors je tente ma chance !

5 bonnes raisons de regarder HTML 5 de plus près

Il paraît que les internautes-lecteurs sont friands de listes en tout genre. Racoleur à mes heures, je me plie aujourd'hui à cet exercice sans rien oublier de mon sacerdoce : livrer aux surfeurs échoués ici une véritable valeur ajoutée informative.

Avant de lister, quelques mots de présentation : HTML5, aussi appelé "web applications 1.0" est une proposition avancée par le WHATWG (think tank du web très écouté, à l'origine par exemple du système de cookies persistants de Firefox 2.0) pour succéder à HTML4/XHTML1. HTML5 est donc à distinguer de XHTML2, qui couvre les travaux actuels du W3C sur le sujet.

HTML5, donc, est un vrai truc emballant, et ce pour au moins 5 raisons :

- HTML5 est pragmatique
le WHATWG ne préconise pas la révolution, mais une évolution qui saura garder une compatibilité avec les pratiques courantes des développeurs web actuels. Ca embête souvent les puristes mais ça permet d'avancer.

- HTML5 est ambitieux
On peut être pragmatique mais ambitieux avec des balises comme canvas pour réaliser des graphiques en javascript ou encore l'élément datagrid qui permettrait de résoudre un problème constant des développeurs Ajax.

- HTML5 est ouvert aux contributions
Les travaux du WhatWG sont ouverts à toutes les contributions (dont la vôtre ?)... contrairement à ceux du W3C.

- HTML5 est pensé pour le web de demain
HTML5 tente de répondre à un grand nombre d'utilisations modernes du HTML : le contenu multimédia, les applications web, ou les échanges entre internautes. HTML5 assume en ce sens définitivement la rupture avec le langage de structuration de données qu'était HTML à l'origine. XHTML2 fait plutôt le chemin inverse en cherchant à nettoyer HTML de ses incohérences avec ses principes initiaux.

- HTML5 est très suivi de ceux qui font le web
Mozilla, Opera, Apple ont récemment et très officiellement demandé au W3C d'utiliser le travail du WhatWG comme d'une base de réflexion pour le nouvel HTML... tout en implémentant en parallèle certaines propositions (telles que canvas) sans attendre une quelconque approbation de ce dernier !

Ext, OpenAjax : la planète Ajax s'organise

Un des doux rêves que caresse plus ou moins consciemment l'intégralité des développeurs Ajax est de disposer de librairies javascript organisées, modulables et répondant à des normes limitant au maximum les problèmes de compatibilité. Bien loin de penser qu'un tel Graal puisse être atteint à court terme, c'est avec un plaisir non dissimulé que je vous fait part du lancement de la bêta de Ext.

Ext est une librairie qui, à son origine, étendait le noyau de Yahoo UI pour mettre à disposition un certain nombre de widgets bien pratiques (calendriers, onglets, sliders...). Bien architecturée, la librairie a pu être rapidement adaptée pour se passer du noyau YahooUI, pour le remplacer par l'excellent JQuery ou encore le célèbre couple Protoype + scriptaculous.

Ext possède à ce jour une vingtaine de widgets d'une grande qualité, mais aussi et surtout une excellente documentation tirant pleinement partie de ext. Au delà de la performance, c'est l'effort de généricité/modularité des auteurs de cette librairie qui me rend optimiste pour l'avenir.

Cette démarche me semble s'inscrire dans un mouvement plus général de rationalisation du petit monde Ajax. Autre fait révélateur de ce mouvement, l'OpenAjax Alliance est en train de sortir de l'impasse dans laquelle je pensais qu'elle se trouvait :
- Google et Microsoft l'ont récemment rejointe
- l'OpenAjax Hub, un ensemble de spécifications à respecter pour les librairies Ajax produites
par les membres de l'Alliance, est sur le point de sortir en version 1.0

Il est assez heureux de voir ajax arriver à maturité à l'heure où les alternatives RIA se multiplient et où les éditeurs se donnent un mal fou à faire venir les développeurs ajax vers leur technologie.

L'heure du choix d'une techno RIA est-elle arrivée ?

Les choses bougent sérieusement côté des techno RIA en ce moment :

- Apollo, le framework, vient de sortir en version alpha
- Microsoft Expression Blend, l'outil de design pour WPF est disponible en évaluation
- le petit monde RubyOnRails propose SlingShot, une alternative alléchante à Apollo
- OpenLaszlo 4.0 est sorti et permet désomais de générer des interfaces
Ajax tout comme des interfaces interprétées par un lecteur Flash.

A vos marques, prêts, testez !

La 3D, le web et javascript

La 3D sur le web est un vieux rêve qui semble être repoussé chaque jour :
- VRML n'a jamais vraiment pris
- X3D son successeur désigné, ne semble pas vraiment prendre la suite
- aucune solution de remplacement n'a réellement émergé

Une fois encore, des hackers javascript se sont retroussé les manches pour parvenir à une solution à l'aide de le nouvelle balise HTML "canvas" (malheureusement inconnue de nos amis de chez Microsoft)... et à ma grande surprise, ça marche ! Du moins, de temps en temps.

Quelques exemples, parce que ça vaut quand même le coup d'oeil :
- une démo d'un moteur de rendu (qui fait ce qu'il peut)
- un jeu en 3D (injouable)
- une démo de voiture avançant une route improbable

Bon, en attendant que tout ça progresse, Flash et WPF semblent pour le moment les alternatives les plus raisonnables... à moins que vous n'ayez une meilleure idée ?

AJAX, JSON et BISON au secours de la bande passante

Dans la formidable époque que nous sommes en train de vivre, le web subit une révolution discrète et pourtant cruciale au royaume de "l'expérience utilisateur" : les applications du web ont en effet maintenant plus que jamais les moyens de réduire considérablement la bande passante utilisée.

Or sous des dehors techniques, cet aspect du web 2.0 est tout sauf un problème de geek :
- pour l'utilisateur, moins de données à faire transiter signifie une meilleure réactivité de l'application à ses différentes actions.
- pour le financier, moins de bande passante entraîne une baisse qui peut être significative des coûts de structure... en particulier dans le cas d'une montée en charge rapide de l'application.

Comment concrètement s'opère cette baisse de consommation ?
- Dans le passé, ce fut AJAX qui permit d'économiser des rechargements de page complets à chaque fois que des appels serveur sont nécessaires.
- Aujourd'hui, c'est JSON (si il est bien utilisé) qui diminue de manière considérable la taille des réponses renvoyées par les serveurs suite à une requête AJAX.
- Demain, ce sera peut-être quelque chose comme BISON (qui n'est qu'une expérimentation) d'une part et le stockage client massif d'autre part qui permettront d'optimiser encore un peu plus le flux d'information transitant entre le serveur et le client.

Google Apps For Your Domain V2 : une killer app pour les PME

On le dit depuis longtemps et ça devient chaque jour qui passe une réalité plus tangible : Google va bientôt devenir un acteur important de l'application d'entreprise. La nouvelle mouture de GAFYD a en effet de nombreux arguments pour convaincre un bon paquet de PME (parole d'utilisateur d'entreprise !) :
- un webmail loin devant les solutions concurrentes
- un système d'édition et de partage de documents terriblement efficace
- un agenda en ligne au top
- une gestion des comptes simple et conviviale
- des possibilités de support et de développements spécifiques enfin dignes d'une société comme Google

Si les équipes commerciales de Google for enterprise sont un peu etoffées en France, ça pourrait changer pas mal de choses dans nos petites entreprises. Surtout que la suite va probablement arriver dans l'année... c'est à dire :
- une solution de PowerPoint-like
- un mode Offline pour les différentes applications
- la poursuite du développement des interfaces Smartphone
- l'intégration à la Google Appliance

Bon courage aux concurrents !

OpenID s'impose comme référence de l'identité numérique

La gestion de notre identité à travers les différents services de l'internet est un des problèmes non résolus qu'avait évoqués oncle Tim O'Reilly dans "what is web 2.0". Petit rappel du problème en question par exemple tout bête...

JB Boisseau est terriblement jaloux du talent et du succès de Fred Cavazza et décide de se venger de ce sale coup du destin en usurpant l'identité de ce dernier.
Comment ? Rien de plus simple : il lui suffit d'aller sur le blog de Loic Lemeur et d'y décharger un flot d'insultes... en signant "Fred Cavazza". N'ayant pas de moyen d'identifier clairement la personne en question, le machiavélique JB Boisseau réussira à déboussoler les internautes 2.0 de passage aisément et ce, potentiellement sur une grande quantité de services.

D'un autre côté, le bon Fred aimerait bien pouvoir bénéficier d'un "single sign-on" sur la toile lui permettant d'accéder à tous ses services avec une seule authentification... chose qu'il lui ferait gagner un temps précieux.

Bien des services ont tenté de s'imposer en tant que standard dans le domaine (où, par définition, il ne peut rester qu'un acteur) et il semble qu'un vainqueur soit en train d'émerger. Le vainqueur en question, serait donc OpenId. Les raisons en sont les suivantes :
- AOL a annoncé à la suite de Microsoft être prêt à utiliser OpenId pour l'authentification à ses services.
- Plusieurs sites web de référence (Digg, Technocrati, MovableType...) ont adopté le système
- Les fournisseurs d'OpenId sont à la fois nombreux et influents : Verisign, JanRain, Sxip, MyOpenID.com..

Bref, si certaines questions se posent encore sur la capacité technique d'OpenId de jouer pleinement son rôle, ce dernier est à ce jour bien mieux que placé que les autres pour remporter la bataille.

Scenario d'un krach 2.0

Le krach 2.0 aura lieu, soyez-en assurés : les cycles économiques et financiers sont ainsi faits que toute croissance rapide s'accompagne d'une correction. Seules incertitudes : le moment et l'ampleur de la crise. Mouillons-nous un peu...

Je crois (c'est plus qu'une croyance en fait) que ce krach 2.0 sera assez, voire très, différent du premier. L'effondrement de la "nouvelle économie" fut en effet assez lent : pas de véritable journée noire mais plutôt un processus régulier de baisse marquée des valeurs technologiques étalé de la fin 2000 à la mi-2003. Les investisseurs avaient toujours de l'argent à mettre sur la table, même s'ils en avaient moins : ils se mirent donc à éviter les valeurs technologiques qui s'avéraient moins rentables qu'envisagé. Les conséquences furent donc un ralentissement généralisé de l'économie mais une situation de crise véritablement centrée sur le secteur IT.

A l'opposé, la prochaine crise pourrait être beaucoup plus violente et ne pas toucher simplement la branche des nouvelles technologies. Pourquoi ? Parce que certains fondamentaux de l'économie américaine font peur : ainsi, les marges de manoeuvre qui existaient en 2000 pour absorber le choc se probablement considérablement amoindries.

Ces fondamentaux, les voici :
- les déficits jumaux (budget de l'état, balance commerciale) n'ont cessé de se creuser depuis 2000 pour atteindre aujourd'hui des proportions assez inquiétantes aux yeux de beaucoup.
- du fait de ces déficits, le dollar a logiquement repris sa baisse, mais pourrait connaître des tensions bien plus graves si les banques asiatiques cessaient de soutenir le trésor américain comme elles le font depuis de nombreuses années pour favoriser leurs exportations.
- l'éclatement de la bulle immobilière américaine est réel, et aura très bientôt des répercutions sur le reste l'économie. En effet, les foyers américains s'endettant considérablement en hypothèquant leur domicile, une chute importante de l'immobilier aurait des conséquences très directes sur leur capacité à emprunter.

Le premier domino à tomber est donc bien celui de l'immobilier américain et selon la violence de sa chute (qui n'est pas terminée) , il entrainera (ou non) les suivants :
=> recul de la consommation => panique puis crise financière => crise économique généralisée (où le secteur IT trinque comme tout le monde) => exportation de la crise au niveau mondial

Voilà un scénario qui, si il se déroule, devrait s'ammorcer dans les 18 prochains mois (le temps de pousser le deuxième domino)... mais dont la probabilité et surtout l'ampleur sont incertaines tant nous sommes peu de chose face à la nature profondément chaotique (au sens mathématique du terme) de l'économie.

Les vrais héros du web 2.0

Chaque jour, dans l'ombre des hommes d'affaires et des blogueurs à succès, des bidouilleurs géniaux ont les intuitions et la volonté qui construisent le web (2.0) d'aujourd'hui et de demain.

Etant donné qu'ils ne connaîtront probablement jamais la renommée qu'il méritent, je me permets aujourd'hui de leur rendre un petit hommage via une sélection 100% subjective des meilleurs d'entre eux.

David H. Hanson, définitivement sur les rails
Cet homme est plus qu'un techie habile : sa vision du développement web est à ce point efficace qu'il a révolutionné le métier pratiquement à lui tout seul. Son oeuvre, RubyOnRails, est en effet en rupture avec beaucoup d'habitudes : un langage méconnu, un pattern (activeRecord) trop souvent jugé laxiste, une structure (MVC) qui rimait jusque là plus avec rigueur qu'efficacité... et maintenant, beaucoup essaie de le copier !

Alex Russel, le maître du dojo
Alex Russel est le responsable du projet dojo, cette librairie javascript innovante qui non seulement comprend un nombre impressionnant de fonctionnalités mais qui en plus possède une architecture très bien pensée.
Alex Russel est également un de ceux qui se penchent le plus sur le développement COMET, une techno qui a certes de l'avenir mais qui est encore plus cauchemardesque qu'AJAX à mettre en place.

Brad Neuberg, hors ligne mais dans le coup
J'en ai déjà beaucoup parlé, mais le travail de Brad sur le mode offline et son coup de force pour exploiter les cookies Flash en Javascript sont vraiment impressionnants.

Sam Stephenson, prototypeur en chef
Sam Stephenson n'est ni plus ni moins que le créateur de prototype, la librairie javascript de référence pour le développement Ajax. Il fait aussi partie de l'équipe travaillant sur le noyau de RubyOnRails.

Thomas Fuchs : scriptaculeux !
Thomas Fuchs a eu la bonne idée de s'appuyer sur prototype pour bâtir scriptaculous, sa très pratique librairie d'effets Javascript... qu'il soit lui aussi impliqué dans le développement de RubyOnRails ne doit donc probablement rien au hasard. A noter également, ses bonnes pratiques de développement Javascript qui mériteraient d'être plus connues.

Joe Hewitt, notre sauveur au quotidien
Joe Hewitt a eu l'excellente idée d'élaborer le plus fidèle ami du développeur javascript à travers Firebug : loué soit-il !

A noter que 2 de ces hackers 2.0 (David et Sam) font partie de la fameuse équipe de 37signals (BaseCamp, Getting Real) et que 2 autres (Alex et Brad) travaillent pour Sitepen... 2 petites sociétés feraient-elles avancer notre vieux web plus vite que certains mastodontes ?

Firebug : quand l'exceptionnel se fait indispensable

Firebug 1.0 est sorti en début d'année, et si vous développez un peu, je vous encourage vivement à le mettre à jour / réessayer / découvrir si ce n'est pas encore fait. Le meilleur ami du développeur Ajax fait maintenant tout ce qu'il faut pour vous aider au quotidien :
- inspecter et analyser le code HTML élément par élément
- visualiser les styles de vos pages aisément
- voir toutes les requêtes HTTP dans le détail
- débuguer Javascript mieux que jamais
- examiner les objets DOM simplement

Et beaucoup de petites choses pratiques (messages console, débugage sous IE !) que je vous laisse découvrir en font maintenant un outil à la fois fiable et incontournable... qui nous rend impatients d'en découvrir la prochaine version !

Dojo Offline Toolkit : comment ça (va) marche(r) ?

Dojo Offline Toolkit a pour but d'être, comme son nom l'indique, une boîte à outils rendant aisé le développement de fonctionnalités offline pour les applications web d'hier et de demain. Pour cela, plusieurs choses sont nécessaires :
- une librairie qui permet le stockage d'information en mode offline : ça existe déjà, ça s'appelle dojo.storage.
- un proxy web léger sur le poste client permettant de gérer le mode offline de façon transparente pour l'utilisateur (je vais y revenir).
- une API permettant aux développeurs d'utiliser facilement les fonctionnalités du toolkit

Bon, plaçons-nous maintenant sur la machine cliente qui va utiliser une application fonctionnant avec le Toolkit :
- elle va regarder si vous disposez du proxy web de dojo offline
- si vous ne l'avez pas, elle vous propose de l'installer (installation simple : système NSIS pour Windows, XPI pour Linux) immédiatement
- que vous ayez le proxy ou non, vous utilisez ensuite l'application online
- une fois hors ligne et si vous disposez du proxy, celui-ci consulte le fichier ProxyAutoConfiguration (PAC) de votre navigateur et vous dirige vers votre version locale de façon transparente de l'application
- vous utilisez l'application hors ligne qui est alors entièrement basée sur Javascript et qui vous permet de stocker des informations dans votre navigateur grâce à dojo.storage
- dès que vous repassez en ligne, le proxy vous reconnecte au serveur distant et la synchronisation offline /online peut avoir lieu

Tout le travail qui est en cours consiste donc à créer le proxy (à partir de polipo, un projet opensource existant) et construire l'API... résultat des courses dans 3 mois !

Valeur ajoutée du blogueur : pertinence, rareté, reformulation et droit de citation

J'aime lire les blogs. L'expression "sagesse des foules" a pour moi vraiment un sens quand je constate, chaque jour, la richesse d'information qui est désormais disponible sur la toile. Malheureusement, comme toute production, les blogs ont un déchet important... et celui que vous lisez à l'instant même ne doit probablement pas échapper à la règle !

Ainsi, l'agacement qui me gagne à la lecture de certains posts inutiles autant que l'envie de toujours apporter quelque chose à mes lecteurs m'amène régulièrement à me poser la question : qu'est-ce qui fait la valeur ajoutée d'un article ? Autrement dit au delà du sempiternel "comment mener le lecteur à mon article ?" (le référencement), j'aimerais plutôt demander "en quoi mon article peut être utile au lecteur ?".

Parce que je dois dire que j'en assez de voir des "articles" qui ne sont que des catalogues sans logique (genre "87 applications web 2.0"), des listes de liens sans explications ("bonjour, voici 3 liens intéressants !"), voire des articles à 80% pompés d'autres sources. Oui, je sais que c'est bien pratique de prendre des paragraphes entiers chez ses "copains" blogueurs : ça fait du contenu facile pour les robots, ça augmente la fréquence des posts... mais ça n'est ni malin, ni moral, ni vraiment utile à la communauté.

Qu'on ne se méprenne pas : citer les autres en les backlinkant est une excellente habitude de la blogosphère (ça permet de connaître de nouvelles sources pour les lecteurs, c'est une manière de récompenser l'auteur par de nouveaux visiteurs et ça améliore la pertinence des moteurs de recherche), les quasi-plagier en est une autre.

La moindre des choses à faire pour évoquer le contenu réalisé par autrui est de respecter quelques règles de bon sens et de respect :
- le contenu en quelques phrases tu présenteras, en perspective tu le mettras
- pas plus de 10% d'un article tu ne citeras
- toujours tes sources tu backlinkeras

Ca peut paraître évident, mais j'ai vu récemment fleurir ça et là des blogs qui se contentent des catalogues de liens et de pompages divers (et je ne parle pas des "blogs-satellites" purement utilisés pour le référencement) : valeur ajoutée = 0, pollution de la blogosphère = maximale. Voilà c'est dit, et miracle, mes aigreurs d'estomac ont disparu.

J'en viens donc à la valeur ajoutée du blogueur. La plupart des posts blogués en ce bas monde est basé sur une actualité, une analyse ou une découverte faite par autrui. Tout l'art du blogueur est donc d'ajouter une valeur supplémentaire au contenu auquel il se réfère et il a pour cela plusieurs méthodes :
- traduire le contenu dans une autre langue
- critiquer le contenu
- établir des corrélations avec d'autres contenus en les mettant en perspective
- reformuler le contenu pour le rendre intelligible à d'autres lecteurs
- analyser le contenu pour en faire ressortir des aspects particuliers ou peu évidents
- résumer le contenu (sans le trahir... exercice délicat !)
- ... (liste à compléter avec votre aide)

Je suis de ceux qui pensent que le blog n'est pas qu'un espace de liberté pour le blogueur, et que celui-ci doit avoir conscience d'un certain nombre de devoirs implicites en tant que membre de fait de la blogosphère. Or la qualité de cette dernière dépend de chacun de nous.

Web offline : Brad Neuberg prépare la solution ultime

Alors que l'iPhone remporte (déjà) la palme du buzz 2007 et que myBlogLog se fait racheter par Yahoo, Brad Neuberg s'apprête tout simplement à changer le monde du web.

Cet illustre inconnu n'est autre que le génial créateur de Dojo.storage, la librairie qui vous permet de stocker des données de manière persistante et hors ligne dans la mémoire de votre plug-in Flash ou de votre navigateur.

Son nouveau projet, très remarqué par de nombreux hackers de premier plan, se nomme Dojo Offline Toolkit et a pour ambition de rendre disponible en mode offline toute application web de manière assez simple pour les développeurs.

Je vous encourage vivement à regarder les petits cas d'utilisation qu'il a imaginés pour illustrer les possibilités que va offrir son outil (Gmail, Blogger...). Si cela vous intéresse, je pourrai aussi vous expliquer comment cela va marcher techniquement (et je n'oublie pas que je vous dois un tutoriel sur dojo.storage qui est en préparation) dans un prochain post.

Apollo, XUL, WPF... qui sera la prochaine plate-forme web de référence ?

Ayant récemment découvert l'excellent blog "Universal Desktop", je me permets de faire un point sur ce qui sera certainement une des grandes batailles de 2007 : qui sera la plate-forme de référence pour les interfaces web riches ?

Apollo d'Adobe est un nouveau runtime permettant de visualiser des contenus DHTML, Flash ou PDF hors du navigateur. Ce runtime aura d'une part toute la puissance d'Adobe pour s'imposer sur les postes de travail (qui n'a pas Adobe Reader et/ou Flash Player sur sa machine ?), et toutes les communautés de développeurs Ajax, Flex (un excellent framework de développement d'applications web riches) et Flash potentiellement accessibles.
Apollo pourrait bien être la grande nouveauté 2007, surtout lorsque eBay fonctionnera sous ce runtime (c'est pour très bientôt)...

WPF de Microsoft est, là encore, une tentative de faire du web riche hors du navigateur. Les possibilités visuelles que promettent WPF seraient, semble-t-il, bien au-dessus du lot (avec notamment la 3D)... et Microsoft y utilisera ses meilleures armes : d'excellents outils pour le développement (avec par exemple le déconcertant Windows Expression), un déploiement de base sur toutes les machines Vista, utilisation de l'excellent Framework .NET.
WPF/e (e pour everywhere) est le portage de WPF au sein du navigateur pour les gens ne disposant pas du framework. Le "everywhere" est néanmoins très relatif : un plug-in navigateur sera nécessaire et fonctionnera uniquement pour Windows et Mac.

XUL de la fondation Mozilla a le mérite d'être le pionner du genre (et a d'ailleurs été largement copié par MXML d'Adobe et XAML de Microsoft) : réaliser rapidement des applications desktop web riches s'exécutant dans Mozilla Firefox ou un runtime spécifique est maintenant possible depuis plusieurs années... mais XUL ne perce pas significativement malgré tout. Trop en avance sur son temps ? Toujours déservi par un manque criant d'outils adaptés pour le développement ? Mozilla n'a néanmoins pas encore perdu la bataille et avec un soutien extérieur (IBM, Google...), il est possible que XUL refasse surface.

Le web riche classique (Ajax, Flash... et Java ?) a l'avantage considérable d'être le standard actuel surlequel de nombreux dévéloppeurs, mais surtout la majeure partie des utilisateurs, ont leurs habitudes. Ses possibilités sont encore très grandes (COMET, mode offline)... mais plus on va loin dans la richesse et la portabilité des interfaces Ajax, plus le développeur est au royaume de la bidouille Javascript (jusqu'à atteindre des niveaux de productivité lamentable).
Les navigateurs ont néanmoins fait beaucoup de progrès : ie7 et ff2 gèrent tellement mieux JS que leur prédécesseurs que les choses pourraient s'arranger avant que les développeurs (et ceux qui les payent) ne soient complètement dégoutés de ce type de développement.

Quelques challengers tenteront d'émerger dans cette guerre sans merci :
OpenLazlo 4.0 (actuellement en bêta) qui n'est pas une plate-forme à proprement parler mais qui permettra aux développeurs de réaliser une interface Flash et son équivalente Ajax avec le même code.
Quicktime pourrait semble-t-il marquer l'arrivée d'Apple sur ce marché : l'outil est pour le moment techniquement sous-exploité alors qu'il est très répandu sur le poste de travail... à suivre !
Google Desktop qui offre désormais la possibilité aux développeurs de construire des widgets
relativement facilement constitue encore une piste. Cette solution aura néanmoins du mal à offrir plus que de petits gadgets aux utilisateurs finaux.

Au milieu de cette foule de nouveautés, une seule certitude pour le monde du web (utilisateurs, développeurs, décideurs) : préparez-vous au changement !