[Maven] Qu'est-ce qu'une version SnapShot ?

Ce billet présuppose que vous connaissez un peu l'utilité de Maven. Si ce n'est pas le cas, je vous conseille d'abord d'aller faire un tour sur l'un de ces liens : Site Officiel (en), Wikipedia.

En ayant eu l'occasion de discuter avec Tanguy lors de la rédaction de mon dernier billet, je me suis souvenu que la notion de version snapshot, proposée par Maven, a le don de pousser les personnes à s'interroger sur sa raison d'être. Il suffit d'aller consulter rapidement les forums de développement ou de soi-même s'initier à l'outil pour le comprendre.

Pourtant la notion de version snapshot est relativement simple à saisir et ne fait que reprendre, sous un autre nom, un système de nommage des versions déjà bien accepté dans la communauté des développeurs.

Les versions release

Commençons par le commencement : les versions release. C'est le deuxième type (et le plus important) de version que propose Maven. Sans surprise, une version release, c'est :

• Une version stable : les développements ont été terminés, elle a été entièrement testée et n'évoluera donc plus dans le temps,
  
• Une version publiée : elle peut donc être utilisée en production ou par d'autres applications en cours de développement.

Si l'on fait le parallèle avec les outils de versionning, du type Subversion, une version release aura été taggée au moment de sa publication.

J'abordais notamment dans mon précédent billet une façon spécifique de publier les versions release de certains types d'application, sans impacter les utilisateurs.

Qu'est-ce qu'une version SnapShot ?

Tout ce que n'est pas une version release. Une version snapshot est donc :

• En cours de développement,
• Potentiellement instable,
• Non garantie comme étant testée,
• Non accessible en production.

Si l'on considère ces différents points, il est facile de noter que la notion de snapshot regroupe les notions de versions Alpha et Beta, plus largement connues dans le monde du développement.

Dans la logique de Maven, une version snapshot s'identifie avec le "-SNAPSHOT" qui suffixe le numéro de version du projet concerné. Typiquement, une application se trouvant dans une version 1.0.0-SNAPSHOT n'a encore jamais été publiée*.

Une fois recettée et validée, une version snapshot est publiée et devient une release. Le numéro de version est ensuite incrémenté, et une nouvelle version snapshot rentre en cours de développement.

Comment publier une version SnapShot ?

Si vous utilisez les outils communs liés au développement d'un projet (Maven, outil de versionning type Subversion et un dépôt de dépendances Maven type Archiva), la procédure pour publier une version snapshot reste relativement complexe :

1. Commiter tous les changements puis updater le code,
2. Exécuter les tests unitaires pour vérifier que rien ne vient les faire échouer,
3. Supprimer le "-SNAPSHOT" de votre fichier pom.xml,
   
4. Tagger la version sur votre outil de versionning,
5. Checkouter le tag,
   
6. Compiler le projet issu du tag,
7. Publier la dépendance compilée sur le dépôt,
8. Incrémenter le numéro de version puis ajouter "-SNAPSHOT" à la nouvelle version,
9. Commiter les changements.

Cette procédure étant identique pour tous les projets, et ce quelque soit leur type, Apache a eu la bonne idée de créer l'excellent plugin release permettant de la réaliser à votre place. Celui-ci fournit ainsi les deux commandes prepare et perform réalisant respectivement les étapes 1 à 4 et 5 à 9. Leur utilisation reste très simple :

1. mvn release:prepare
2. mvn release:perform

En cas de problème pendant la phase de publication, la commande mvn release:clean vous permettra de recommencer à zéro.

Je reviendrais, dans un prochain billet, sur la procédure globale de publication d'une release, pouvant poser certains problèmes dans certains cas très particuliers.

Quelques éléments supplémentaires...

Afin de compléter ce billet, voici quelques informations complémentaires qui peuvent vous intéresser :

• Un projet utilisant des dépendances en version snapshot doit systématiquement être considéré comme étant dans une version snapshot. Cela peut paraître évident ; cependant le plugin release de Maven n'effectue pas ce genre de vérification. Vous pouvez ainsi publier par erreur un projet utilisant une dépendance qui n'est pas officiellement validée.
• Si le besoin s'en refait sentir (par exemple dans le cadre de projets importants impliquant plusieurs développeurs), vous pouvez rendre disponible une version snapshot sur le dépôt de dépendances, et ce dans un repository spécial nommé... snapshot. Cela permet de ne pas bloquer le développement d'un projet s'il utilise une partie validée de la dépendance en cours de développement. Vous devrez alors être particulièrement vigilant et vous assurez de l'efficacité de vos tests unitaires, vérifiant la stabilité des règles métier quelque soit les évolutions de la dépendance. Je vous laisse consulter la documentation de Maven et de votre dépôt de dépendances pour en savoir plus sur ce point.

Conclusion

En résumé, Maven propose deux grands types de versions :

• Les versions snapshot, représentant la phase de développement de ladite version,
• Les versions release, représentant la version stable issue dudit développement.
  

* Cette assertion dépend de votre politique de nommage de version. C'est un vaste sujet que j'aborderais dans un article plus complet.

Utiliser les versions floues pour publier des fonctionnalités

Votre département propose à ses utilisateurs (interfaces Web ou autres) un ensemble de fonctionnalités sous forme de Web Services (par exemple), permettant de gérer votre métier. Celui-ci évoluant rapidement, ou étant en pleine phase de construction, vous mettez régulièrement à jour ces fonctionnalités.

Comment permettre à vos utilisateurs d'avoir accès à ces mises à jour sans pour autant leur demander de mettre à jour systématiquement leur code ou leur client de connexion à vos Web Services ?

En utilisant les versions floues.

Les mises à jour que vous publiez sont (normalement) toutes soumises à un numéro de version, que je prendrais sous la forme majeure.mineure.révision (ex : 1.5.16) pour l'exemple. L'astuce réside dans le fait de ne faire apparaître qu'une partie seulement de ce numéro de version dans l'adresse des Web Services, que vous fournissez à vos utilisateurs.

Par exemple, vos Web Services sont accessibles à l'adresse http://monServeur.com/mesWebServices.

Si vous laissez l'adresse sous cette forme, toute modification de l'interface (WSDL) de ces Web Services entraînera obligatoirement une mise à jour du côté de vos utilisateurs, ce qui peut s'avérer problématique pour vos utilisateurs (modification de leur code, compilation, recettage et mise en production seront alors nécessaires). En plus de cela, la mise en production de vos Web Services et de leur propre application devront être parfaitement simultanées, de façon à ne pas impacter leurs services. Si vous avez plusieurs clients, cette opération relève de l'impossible.

Inversement, vous pouvez faire apparaître le numéro de version complet dans l'adresse de vos Web Services, ce qui pourrait donner par exemple : http://monServeur.com/mesWebServices-1.5.16. A chaque nouvelle publication, vous prévenez l'ensemble de vos clients qui peuvent alors choisir ou non d'utiliser cette version supérieure. Cette solution présente l'avantage de laisser vos utilisateurs maîtres de leurs évolutions, ce qui est un point particulièrement important. En revanche, s'ils veulent bénéficier de toutes les évolutions, y compris les corrections de bugs (n'incrémentant normalement que la révision), ils devront effectuer autant de mises en production que vous en faites. De plus, vous devrez maintenir l'ensemble des versions que vous publier et disposer d'un serveur suffisamment puissant pour toutes les faire tourner.

La solution...

Une solution intermédiaire consiste à flouter la version complète de façon à ne faire apparaître que la partie majeure et mineure. Dans le cas de notre exemple, vos Web Services seraient accessibles à l'adresse http://monServeur.com/mesWebServices-1.5.x ou http://monServeur.com/mesWebServices-1.5. Dans ce cas, vous pourrez faire évoluer votre version en cours (la 1.5), c'est-à-dire y apporter des corrections de bugs ou des évolutions mineures, et en faire profiter vos utilisateurs sans leur demander la moindre modification.

Personnellement, j'utilise la version floutée avec un "-x" de façon à faire comprendre clairement à mes utilisateurs que cette version n'est pas figée et que des évolutions, transparentes pour lui, peuvent avoir lieu.

Les mises à jour plus importantes (modification de l'interface par exemple : nouvelles méthodes ou modification des types utilisés) seront publiées sous un numéro de version dont la partie mineure (ou majeure) sera incrémentée. Le choix de passer à cette nouvelle mouture est alors laissé à vos utilisateurs.

Un autre avantage de cette solution est de permettre tout en douceur le passage même obligatoire) à une version supérieure. Il vous suffit alors de laisser les deux versions tourner en parallèle pendant quelques temps et de donner à vos utilisateurs une date de retrait de la version obsolète. Ils auront alors le temps d'effectuer la mise à jour.

Notez que cette solution peut très bien être mise en place avec d'autres formes d'application que des Web Services. Une interface Web peut, par exemple, subir le même sort...

Reste à définir ce que vous considérez comme une évolution majeure, mineure ou une simple révision... Mais cela fera l'objet d'un autre billet...

Vous pouvez consulter cet article particulièrement intéressant, abordant également la notion de publication des releases et leur utilisation par les clients (merci à Tanguy pour le lien).

Les templates d'Eclipse pour unifier l'équipe

Comment faire lorsque vous devez imposer de nouvelles contraintes de développement à votre équipe mais qu'elles peuvent être perçues comme une perte de temps au premier abord ou qu'elles peuvent être implémentées différemment suivant les habitudes de chacun ?

Je prends deux exemples rapides :

1. Dans le cadre des projets Java dont j'ai la charge chez mon client, notre système de logging, basé sur log4j, n'a pas été mis en place pleinement dès le début des développements. Résultat : les traces dont nous disposions il y a encore quelques semaines étaient parfois trop justes pour nous permettre de gérer correctement le suivi d'un appel, directement sur nos serveurs. Nous avons donc demandé à nos développeurs d'ajouter des logs un peu partout dans le code, avec certaines règles précises (on signale le début de la méthode, on loggue les paramètres envoyés à un web service...). Pour ces développeurs, n'assurant pas la maintenance des projets, l'ajout de logs est une véritable gageure qu'ils réduisent au minimum.
2. Lors de la vérification des paramètres à l'entrée d'une méthode, nous demandons à nos développeurs de vérifier que les String ne soient ni nulles ni vides (uniquement des espaces ou aucun caractère). C'est une règle qui s'applique à la très grande majorité de nos méthodes, et qui demande systématiquement les mêmes vérifications, qui peuvent être faites de manières différentes suivant les habitudes de chacun.

Nous voyons bien ici les problèmes qui peuvent se poser : dans un premier temps, les développeurs vont éluder la question en en faisant le moins possible (ce qui peut se comprendre sur certaines tâches fastidieuses et peu valorisantes). Dans un second temps, les habitudes de chacun risquent de conduire à des comportements métier différents, difficilement repérables.

L'une des solutions consiste à contrôler le code produit par les développeurs. Il existe pour cela des solutions que nous aborderons dans un autre billet. Le contrôle implique cependant que vous mettiez en place des métriques, que vous passiez du temps à les analyser, que vous demandiez les rectifications et que les développeurs appliquent vos corrections. Et chaque fois, il faut recommencer...

La deuxième solution consiste à expliquer l'intérêt de ces contraintes, afin qu'elles soient comprises et mieux acceptées. Si vous travaillez avec des gens ayant un minimum de conscience professionnelle et que vous avez un sens pédagogique dépassant celui du babouin nain, vous devriez avoir un minimum de résultats.

Une autre solution consiste à fournir à vos développeurs le moyen d'en faire le moins possible, et le plus facilement possible. Nous sommes tous humains : moins l'on en fait, mieux l'on se porte. Et c'est là que les templates d'Eclipse viennent à notre secours...

Pour les présenter rapidement, les templates d'Eclipse, accessibles via l'assistant contextuel, permettent de générer du code (de quelques mots à plusieurs dizaines de lignes), tout en permettant au développeur de remplir rapidement les vides, configurés par vos soins.

Exemple : vous devez logguer le début d'une méthode avec le code suivant :

if(LOGGER.isDebugEnabled()) {
LOGGER.debug("Starting method...");
}

Il vous suffit pour cela de déclarer un template, nommé lstart, qui génère automatiquement le code précédent. Vous souhaitez saisir le message ? Pas de problème vous définissez le template ldebug, qui aura la tête suivante :

if(LOGGER.isDebugEnabled()) {
LOGGER.debug("${message}");
}${cursor}

Lorsque le développeur appliquera ce template, son curseur se placera automatiquement au niveau du message, ce qui lui permettra de le saisir. En tapant ensuite sur "entrée", son curseur se déplacera après les accolades, lui permettant de poursuivre son code sans toucher à sa souris.

Je vous laisse regarder un peu toutes les possibilités des templates d'Eclipse :

1. Import automatique des classes pré-configurées,
2. Saisie unique du nom de variable et remplacement automatique de toutes les occurences de cette variable dans le template,
3. ...

Vous voyez bien là l'intérêt des templates : en saisissant simplement un nom, vous générez un code précis, répondant aux règles définies à l'avance, sans que les développeurs aient à y réfléchir. En tant que référent technique de votre équipe, il vous suffit ainsi de créer les templates que vous jugez utiles (Windows/Preferences/Java/Editor/Templates) et de les exporter dans un fichier XML. Vos développeurs pourront ensuite les importer facilement dans leur propre environnement pour les réutiliser rapidement et facilement.

Pour que l'utilisation des templates soit réellement efficace, il faut cependant que les noms de ceux-ci soient logiques (pour que l'on puisse s'en souvenir facilement) et courts (pour inciter les développeurs à les utiliser).

Attention également à ne pas créer des templates pour tout et n'importe quoi. Les templates doivent être simples et d'utilisation évidente. Il ne faut pas qu'il y en ait une multitude.

Quelques liens rapides sur le sujet:

http://eclipse.developpez.com/faq/?page=developpement#creerTemplates

http://www.programmez.com/tutoriels.php?titre=Eclipse-et-les-templates-Java-par-l-exemple&tutoriel=82

JavaCamp #2 - compte rendu

Ce soir c'était le deuxième BarCamp Java de Paris. C'est l'occasion de se retrouver entre technophiles dans un format ouvert où chacun peut échanger librement.

Ce que j'aime dans le format BarCamp, c'est que l'on vient avec ses idées, on les post-it-ise et si son sujet rassemble suffisamment de monde on en discute dans la foulée. Ce côté discussion autour du feu de camp est très enrichissant et complète parfaitement les présentations plus grosses du Paris JUG (quoique les premières sessions du Paris JUG avaient un peu cette tête là d'ailleurs).

Côté organisation : 2 sessions de 45 minutes, et un buffet pour finir.

Session #1

Les sujets :

• Retour d'expérience de Devoxx.
• Génération de code
• Bases de données orientés objets

J'ai participé à la session sur Devoxx, qui a accueilli le plus grand nombre de personnes il me semble. Ceux qui étaient à Devoxx - principalement Nicolas Martignole (le touilleur) et Fabrice Robini (Octo) - ont parlés de leur retour d'expérience, de l'ambiance dans un premier temps, puis des sujets techniques qui nous intéressaient, à savoir Java FX, REST et SpringSource dm Server. Didier est venu nous faire partager son point de vue en fin de session.

Session #2

Les sujets :

• L'intégration continue et ses outils
• Les ESBs légers Mule et Spring Intégration
• Un autre sujet qui m'a échappé

J'ai participé à la session sur les ESBs. Julien Dubois (SpringSource) a présenté Spring Intégration et Spring Batch. On a ensuite parlé de Mule et des outils implémentant les patterns d'intégration de manière plus générale avec un retour d'expérience dans chaque cas.

Le buffet

Le buffet est le moment le plus intéressant, où tout le monde discute par petits groupes dans une joyeuse anarchie. J'ai pu discuter avec des personnes ayant participé à la session sur la génération de code ; elles ont visiblement apprécié ce format ouvert où chacun venait avec sa propre expérience. J'ai également eu une discussion intéressante au sujet d'IntelliJ vs Eclipse : avec des gens qui connaissent bien les deux IDEs on obtient des comparaisons constructives !

Et pour rester dans l'ambiance de Devoxx on a eu le droit à quelques goodies Octo : boîte à meuh et white paper sur la productivité en Java version papier. Félicitations à Luc pour l'organisation !

Release de SmartGWT

Sanjiv, le créateur de GWT-Ext vient de sortir la première release de SmartGWT. Sanjiv a réussi à sortir un wrapping de la librairie JavaScript SmartClient en à peine 4 mois !

SmartGWT reprend les principales fonctionnalités de GWT-Ext auxquelles s'ajoutent un databinding puissant, d'avantages de widgets (notamment le composant Calendar, un Google Agenda simplifié) et de meilleures performances d'affichage. Sanjiv a su prendre du recul par rapport à sa précédente expérience, et présente une librairie mieux adaptée au développement d'applications de gestion. Allez voir les sources, vous verrez que l'utilisation des composants graphiques et des datasources se fait de façon beaucoup plus simple qu'auparavant.

Utilisation d'une grille éditable à la volée

A cela s'ajoute une très grande réactivité de l'équipe : critiqués sur leurs styles un peu old school, ils sont déjà en train d'y remédier.

Quelques indicateurs :

• GWT-Ext incite à passer sur SmartGWT : lien
• Evolution du nombre de posts du google group GWT-Ext : lien

Note : ce billet est également disponible à l'adresse suivante : http://www.insideit.fr/post/2008/12/03/Release-de-SmartGWT

Methodes Agiles

Pragmatisme & Réactivité au royaume du développement informatique

Les méthodes agiles apportent une nouvelle conduite de projet dans le domaine du développement de logiciels. L'objectif est d'obtenir une meilleure réactivité et une beaucoup plus grande souplesse dans un cadre hautement qualitatif. De manière générale, elle sont beaucoup plus pragmatiques que les méthodes traditionnelles et sont customer centric : leur seul objectif est d'assurer la satisfaction continue du client.

Enseignements

La baseline des méthodes agile est "We value individuals and interactions over processes and tools". Globalement, les principaux enseignements que je tire de ces méthodes sont les suivantes : 

• Le client doit être au coeur du projet. Il doit manipuler les livrables régulièrement et doit vraiment être au coeur de la conception continue de l'objectif. Ceci est très engageant et certains experts de l'agilité imposent qu'une ressource client soit complément intégrée à l'équipe projet (à défaut, il faut un contact très privilégié entre un membre de l'équipe de développement et un membre du fonctionnel). Ainsi, le développeur doit être au contact direct des utilisateurs et observer leurs comportements. Ces contacts peuvent éviter des eccueils évidents en confrontant directement ces deux mondes. Les communications verticales et hiérarchiques doivent être ainsi modifiées pour bénéficier d'échanges très précis et réactifs.
• Etre MonoTâche : la plupart de nos entreprises et systèmes sont multi-tâches, mais le développeur doit demeurer mono-tâche en ordonnancant de manière concertée ces actions. Ceci permet un meilleur versionning du code source de l'application et de manière générale une meilleure efficacité et gestion du développement.
• Le pragmatisme est de rigueur : aucun outil ou méthodologie ne peut être uniquement théorique, ils doivent coller de manière très étroite à un opérationnel étudié. Les outils peuvent apporter une réelle aide mais un simple jeu de Post-it peut parfois jouer exactement le même rôle. Le réflexe de l'ingénieur est bien souvent de trouver la solution avant de cerner le besoin : la démarche inverse est bien souvent plus efficace.
• La simplicité doit demeurer le maître mot. Les concepts de KISS (Keep It Short and Simple) et de DRY (Don't Repeat Yourself) doivent être en permanence appliqués : toujours aller à l'essentiel sans complexifier pour la beauté de l'art et réutiliser les maximum d'éléments existants. 
• La collaboration est omniprésente dans les méthodes agiles, que ce soit entre le client et l'équipe de développement mais également au sein de l'équipe. Il est important que l'ensemble des acteurs aient intégrés ces valeurs pour permettre un échange efficace et non bridé. 
  
• Le changement perpétuel est un élément omniprésent dans les équipes travaillant en agilité. Il faut donc que les collaborateurs soient capables de suivre ce changement. Il s'agit d'insufler une dynamique d'équipe qui permettent de suivre ce rythme.
  
• Le test est la pierre angulaire des méthodes agiles dans le développement informatique. Les développements doivent inclure en permanence et en priorité cette dimension. On parle donc de Test Driven Development. Une bonne couverture de test permet
• de pouvoir opérer des changements radicaux dans le développement (les tests permettant une analyse d'impact fiable)
• d'avoir confiance dans la fiabilité du code en mettant en place des indicateurs et des procédures précis sur la qualité de la réalisation
• de ne plus craindre les mises en production (qui, au demeurant, sont d'ailleurs très régulières dans ce contexte)

Les différentes méthodologies préconisent l'utilisation de cycles d'itération très courts (15 jours maximum). 

Pour ou Contre ?

Pourquoi utiliser les méthodologies agiles et les développement en cycles incrémentaux (itérations courtes) ? En voici quelques avantages : 

• Livrer à temps et atteindre rapidement des quick wins:  le schéma ci-dessus montre bien qu'après quelques itérations permettant de réaliser un socle de base, les retours sur investissement sont rapides et observables.
• Relever les défis du renouvellement fréquent, très courants dans les projets web par exemple. Ainsi, on sera mieux à même 
• Fiabiliser les ressources en permettant une duplication de la connaissance (Collective Ownership)
• Permet de gérer à la fois les demandes régulières et urgentes
• Obtenir une meilleure visibilité continue sur l'objectif final
• Atteindre une meilleure adaptabilité et une meilleure gestion du changement
• La dette technique augmente au fil des projets. Le but de l'agilité est de garantir la qualité constante d'un projet.
  

Cependant, l'adoption de cette organisation rencontre en générale certaines réticences : 

• L'engagement du prestataire semble faible car il ne s'engage pas sur un objectif final. Cependant, les projets ont, en général, tous besoin d'une adaptabilité des objectifs. Même sur un projet simple et très périmétré, on ne maîtrise jamais tous les facteurs (intégration, dépendance extérieure). L'intérêt donc des méthodes agiles est qu'on pourra ajuster l'objectif au fur et à mesure. Ainsi, la règle des 80/20 peut être contrecarrée : peut être qu'avec 85% ou 90% des objectifs initiaux, la réalisation semblera suffisante et nous économiserons une bonne partie des investissements.
• L'engagement du client semble très fort. Trop lié à son opérationnel, il lui semble parfois difficile de pouvoir s'impliquer autant. Cependant, si le projet est important, je pense que le jeu en vaut la chandelle. Cela fait d'ailleurs partie du pragmatisme de certaines déclinaisons des méthodes agiles : "si ta tâche n'est pas importante, elle n'est donc pas indispensable donc ne la fait pas"
• La contractualisation est difficile car l'objectif est flou. En effet, aucun objectif précis n'est visé. Cependant, quand on voit que bon nombre de projets dépassent leur budget initial, ces méthodes permettent de mieux piloter l'évolution et d'anticiper les débordements et ainsi d'assurer une meilleure maitrise continue de l'équilibre budget/résultat
• Les méthodes agiles font parfois peur car elles bousculent les protocoles et les voies hiérarchiques. Ainsi, elle imposent que la communication transversale soit facilitée. Cependant, ces nouvelles organisations permettent une meilleur compréhension du besoin de l'utilisateur et donc un produit final répondant mieux aux objectifs.
• De la même manière, ces méthodologies révolutionnent certaines de nos habitudes et manières de travailler et elles provoquent souvent une réticence naturelle au changement. Une technique telle que la programmation en binôme (pair programming) est dérangeante à bien des égards (perte de contrôle, impression de perte de productivité, diffusion de la connaissance...) mais leurs pratiquants prouvent que sa pertinence est complète.

& Après ?

 

Souvent cantonnées au monde du développement informatique, les méthodologies Agile sont davantage une organisation de travail et peuvent donc être facilement appliquées à un domaine plus large. Il s'agit de méthodes impactantes au niveau des organisations et des hommes. Leurs mises en place doivent être sponsorisées par des poids lourds hiérarchiques pour obtenir leur adoption généralisée. 

Enfin, ces méthodes sont selon moi plus des règles de conduites (comme le code des pirates :-) ) et il appartient à chaque organisation de fixer leur propre application, avec pragmatisme et objectivité. Il y a dans le monde de l'agilité (comme ailleurs) des puristes de méthodologies. Je suis d'un avis différent et j'irais même jusqu'à dire que la notion même d'agilité va contre cette rigidité où les équipes doivent s'adapter en permanence à des contextes particuliers.

Il y a plusieurs déclinaisons des méthodes agiles. Voici 4 d'entre elles que je trouve intéressantes (les branches sont cliquables) : 

 

  

 

Il y a des sources d'inspiration dans chacune de ces méthodes, à vous de vous en faire une idée...

Google Chrome

Quelque chose me dit que ce sera l'annonce de cette rentrée : Google sort aujourd'hui en version bétâ un navigateur internet : Chrome.

La mise en ligne de la version bétâ de Chrome a été précédée d'un googlebook très bien fait se voulant accessible au commun des mortels, expliquant ce que compte apporter Chrome sur le marché des navigateurs internet. Je vous laisse aller le lire, il dresse un état des lieux très intéressant de l'état actuel du secteur.

Voici les principaux points annoncés par Google :

• Chrome est multitâche : chaque onglet fonctionne séparément, et au sein d'un onglet les différents processus d'affichage (rendu HTML, exécution javascript, plugins) fonctionnent en parallèle. Conséquence : si une page cause des problèmes au navigateur, seul l'onglet concerné sera figé.
• Chrome intègre V8, une machine virtuelle javascript (une JsVM ? ^^). C'est un projet interne Google, disponible sous licence BSD. Le code javascript n'est plus interprété, il est compilé. L'ambition affichée de Google est qu'il soit utilisé par les autres navigateurs. J'y vois ici un grand intérêt pour améliorer la propagation des applications Google et de Google Web Toolkit : les applications Google et les applications GWT seront plus performantes, donc plus plaisantes à utiliser. Cela pourrait redonner un nouvel élan aux RIAs basées sur javascript.
• Chrome se veut, comme toutes les applications Google, un modèle d'ergonomie. Ce point ayant déjà été selon moi bien approfondi chez les concurrents, il semble qu'il n'y ait pas grand chose de nouveau comparé à ce qui se fait déjà, si ce n'est que les toutes bonnes idées de chaque navigateur (barre d'adresses façon Firefox 3, page d'accueil façon Opera) ont été reprises et poussées d'avantages.
• Chrome permet un mode "navigation privée" : ce mode permet de surfer sans laisser aucune trace. Tout ce qui est stocké dans ce mode est détruit lorsqu'on le quitte.
• Chrome est déjà massivement testé. Le premier métier de Google est de stocker des pages web, vous savez ? :) Ces pages sont utilisées pour tester Chrome à grande échelle à chaque étape de son développement.
• Chrome intègre Gears en standard.

OK. Et qu'en est-il vraiment ?

Depuis 20h ce soir, Chrome est disponible en téléchargement. J'ai eu l'occasion de m'en servir succinctement (ce billet est rédigé sur Chrome !) et voici mes réactions à chaud.

Première impression : c'est simple, rapide, performant. C'est précisément là où Firefox 3 pourrait s'améliorer selon moi.

• Chrome est bel et bien multi-tâches, équipé d'un gestionnaire de tâches, ce dernier permet même de comparer les performances avec vos autres navigateurs si ceux-ci sont ouverts en même temps que Chrome (cf. capture d'écran ci-dessous). Chrome semble avoir des problèmes avec certains sites de vidéos, chez moi Dailymotion ne se comporte pas correctement : les temps de réponses sont très mauvais et tout Chrome se fige (pas seulement l'onglet en question, comme annoncé). Cependant on peut reprendre assez vite la main (quelques secondes), afficher le gestionnaire des tâches (Maj+Echap) et tuer l'onglet génant sans pour autant perdre tout ses onglets.

Le gestionnaire des tâches selon Chrome

• La JsVM tient ses promesses, gmail et des applications développées en GWT semblent s'utiliser réellement plus vite. Reste ensuite à chiffrer à quel point Chrome est plus rapide.
• Chrome frappe par sa simplicité d'utilisation. Si l'on oublie les boutons précédent, suivant, rafraichir et go (ces fonctions sont utilisables aisément en raccourcis clavier), on se retrouve avec 3 boutons : une étoile pour mettre la page actuelle en favori, une page pour afficher les options de la page, et une clé pour afficher les options générales. Cela me rappelle le post de FredCavazza sur la simplexité.Il faut ajouter à cela une aide en ligne exemplaire qui permet de prendre en main le logiciel en très peu de temps.
• La navigation privée semble parfaitement fonctionner.
• Les pages que j'ai eu l'occasion de visiter s'affichent proprement.
• J'ai essayé plusieurs fois de mettre en offline mes Google Docs : ça plante chez moi au moment de l'étape "updating software". Je ne sais pas encore si l'erreur vient de Chrome, de Gears, ou de moi.

Je pense que le talon d'Achille peut se situer au niveau des tests. Toutes les personnes à qui j'ai eu l'occasion d'en parler m'ont dit "mais, il n'y a pas eu de beta avant ? Sortir un navigateur from scratch c'est extrêmement risqué !". Cette version reste une version beta, et Google semble faire confiance à son système de tests. En tout cas c'est ce point qu'il faudra surveiller dans les jours à venir, le succès technique de Chrome en dépend.

Cela semble être la stratégie de défense de Firefox, comme l'indique Tristan Nitot en interview sur le site du point. Chrome ne doit pas non plus être aux yeux des développeurs web un n-ième navigateur avec lequel il faut se battre pour avoir un rendu cohérent.

Enfin, Chrome n'a pas de lecteur de flux RSS intégré, et certaines personnes semblent le regretter. Personnellement je n'utilise pas les lecteurs de flux RSS intégrés aux navigateurs, mais je comprends que cette fonctionnalité puisse manquer. D'un autre côté c'est l'occasion de créer son premier plug-in Chrome !

Edit : la nouvelle ne laisse personne indifférent et on trouve beaucoup de réactions sur des sujets totalement différents. Je vais essayer de les lister ici :


Benchmark JsVM :
Deux benchmarks, deux résultats sensiblement différent. Le premier utilise le benchmark javascript fourni par Google, pas étonnant donc que Chrome écrase la concurrence. Le deuxième est fait-maison et offre des résultats plus nuancés.
Et bien sûr le test Acid3.

Failles de sécurité :
Il fallait s'y attendre, des premières failles de sécurité ont été exploitées :

Ce lien vous fera automatiquement télécharger un fichier. Il suffit de cliquer sur le bouton pointé par la flèche pour l'exécuter, sans aucun avertissement. Il s'agit d'une faille commune à Safari, corrigée en juillet dernier. Apple avait alors mis 2 mois pour corriger la faille.

Source : http://www.readwriteweb.com/archives/security_flaw_in_google_chrome.php

Merci Damien pour le lien ;)

Eula :
Un incendie s'est déclaré concernant le Cluf de Chrome : ça s'affole mais je ne pense qu'il faut mieux attendre un peu avant.

Propagation :
La propagation de Chrome est assez impressionante, cf. ce post qui parle également des performances javascript. Chez les geeks, Chrome est arrivée en une journée à 10% de part de marché. J'aimerais pouvoir comparer le nombre de téléchargements d'IE8 béta et de Chrome béta ...