Actualité éditeurs / SSII

• TC Server spécial printemps

Le coin de la technique

• Html5 en action
• soapUI ajout le test de JMS et AMF
• Des tests unitaires expressifs grâce à Spock
• JBoss simplifie les tests dans les conteneurs EJB

Evènements de notre communauté en France et à l'étranger

• Salon "Solutions Linux Open Source"

La revue de presse de l'actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

TC Server spécial printemps

Plus besoin de vous présenter Spring TC Server dont nous avons déjà parlé plus d'une fois sur le blog. Pour mémoire, TC Server est un Tomcat intégré à la sauce Spring. La nouveauté de la semaine vient de l'annonce d'une édition spéciale du TC Server 2.0 pour le printemps. Le TC Server Spring Edition est annoncé pour Avril et déjà mis à disposition des développeurs via la Developer Edition. L'offre TC Server se répartit donc maintenant en trois éditions différentes:

• L'édition standard qui intègre l'offre de base TC Server (Administration, Déploiement, Diagnostique par Thread et Heap dump).
• L'édition spring, ajoute à la première offre, le monitoring automatique des applications déployées.
• L'édition developer, intègre TC Server dans Spring Tool Suite pour que les développeurs puissent surveiller en temps réel les performances de leurs applications.

C'est aussi l'occasion pour SpringSource de fournir une bonne intégration avec les solutions VMWare pour déployer et tester facilement sur des machines virtuelles. Pour notre bonheur à tous, SpringSource inscrit donc durablement son TC Server dans le paysage des serveurs J2EE et continue de participer activement au développement de Tomcat.

Le coin de la technique

Html5 en action

Comme une suite logique à notre article HTML5, les nouveaux éléments, DevelopperWorks propose un tutoriel HTML5 + CSS3. Après quelques rappels succincts sur ces deux standards, Joe Lennon propose de soumettre quelques unes de ces nouveautés à l'épreuve du feu. Un survol relativement complet, puisqu'il couvre la nouvelle structure de page, quelques nouvelles balises sémantiques, la vidéo, CSS3, les nouveaux formulaires et le canvas. Un complément intéressant pour tous ceux qui étaient impatients de découvrir ces nouvelles possibilités.

soapUI ajout le test de JMS et AMF

Le célèbre outil de test de WebService, SoapUi, poursuit sa marche en avant, et ajoute de nouvelles cordes à son arc. La version 3.5 offre de nouvelles fonctionnalités particulièrement utiles aux développeurs travaillant sur des architectures web complexes, en particulier le test des ressources JMS.
Les développeurs de chez EviWare n'ont pas réinventé la roue, et ont seulement intégré un framework robuste sur ce sujet, HermesJMS. A vous les joies de poster / recevoir des messages JMS (texte ou xml), de manipuler les headers, de scripter vos files, et surtout d'automatiser vos tests d'intégration facilement.
De manière plus anecdotique (à notre sens en tout cas), cette nouvelle version propose aussi un ensemble d'outils pour tester vos ressources JDBC.
Enfin, dernière évolution majeure que nous n'avons pas eu l'occasion de tester, mais qui semble prometteuse, la possibilité de tester vos scripts AMF (Flash et Flex).
Tous les tutoriels se trouvent dans la page de la release 3.5 (qui ne va bien sûr pas sans son lot de corrections de bugs).

Des tests unitaires expressifs grâce à Spock

Spock est une petite librairie de tests unitaires en Groovy permettant d'écrire un test sous le format spécification (le format given/when/then est aussi supporté) :

La version 0.4 apporte la notion de "Data tables". On retrouve cette notion dans d'autres API (notamment testNG), cependant l'apport de Groovy rend le test vraiment très expressif :

Une petite librairie sympa à découvrir ici.

JBoss simplifie les tests dans les conteneurs EJB

JBoss vient d'annoncer une première version alpha d'un nouveau projet baptisé Arquillian. Ce projet permet de simplifier l'écriture de tests unitaires qui doivent s'exécuter au sein d'un conteneur EJB. S'il est parfaitement possible de tester un session bean hors conteneur depuis l'arrivée de Pojos dans EJB 3.0, disposer d'un conteneur EJB permet de simplifier les injections de dépendance qui doivent être réalisées via l'annotation @EJB ainsi que les accès à des ressources propres au conteneur.

Conscient de cette problématique, pour laquelle l'univers Spring offre de nombreuses solutions, JBoss tente depuis plusieurs années d'apporter une réponse satisfaisante aux développeurs. Cette quête s'est engagée dès le développement des première versions de son conteneur EJB 3.0 avec le développement d'une déclinaison pouvant être démarrée depuis des tests et nommée Embeddable EJB (renommée depuis JBoss Embedded AS) ; cette initiative avait par ailleurs permis d'embarquer un conteneur EJB 3.0 dans Tomcat. Aujourd'hui Arquillian va plus loin en proposant une API de plus haut niveau pour tester ses EJB : l'ensemble des fastidieuses tâches de démarrage du conteneur sont ainsi masquées et le développeur n'a plus qu'a décrire son besoin.

Le projet est pour le moment à un stade embryonnaire et il faudra probablement plusieurs mois avant que l'on dispose d'un ensemble cohérent pour l'utilisation au sein des projets EJB. Toutefois, le souhait affiché d'utiliser Arquillian pour les tests internes de Seam 3 et pour les TCK de Weld permet d'espérer une rapide évolution pour cette API.

Evènements de notre communauté en France et à l'étranger

Salon "Solutions Linux Open Source"

Le salon "Solutions Linux Open Source" se déroulera cette semaine à la Porte de Versailles. De nombreux exposants y seront présents tels Oracle, Linagora, Alter Way, Canonical et bien d'autres encore... C'est l'occasion d'assister à de nombreuses conférences dont celles qui nous semblent les plus intéressantes sont:

• Oracle et l'open source
• Progiciels, le logiciel libre envahit le domaine fonctionnel
• Virtualisation: retours sur investissement et bonnes pratiques de la virtualisation
• Mobilité: smartphones, le libre prépondérant ?
• Développement logiciel collaboratif : bonnes pratiques, premiers bilans
• Meilleures pratiques pour l'intégration continue et méthodes agiles avec : Subversion, Ant, Maven et CruiseControl

De nombreuses formations seront aussi dispensées, mais par contre, elles sont payantes. L'an passé, c'est surtout l'omniprésence des solutions de virtualisation qui nous avait marqué. Quel sera le thème majeur du salon cette année ?

N'imaginez plus, vivez-le !

N'hésitez pas à nous contacter à travers le Formulaire de contact ou directement à l'adresse recrutement@xebia.fr.

Vous avez également la possibilité d’échanger librement avec un de nos consultants afin de mieux nous connaitre : Rencontrer un consultant Xebia.

Agilité

• Convaincre votre MOA de passer aux méthodes Agiles

RIA

• Sortie de SproutCore 1.0

Le coin de la technique

• Commenter son code: jusqu'où aller ?
• Où l'on reparle de la JSR-310

Agilité

Convaincre votre MOA de passer aux méthodes Agiles

Dans un récent article, Alexandre Boutin explique comment convaincre une MOA de s'intéresser à l'agilité.
La démarche d'Alexandre a été de demander à la MOA de répondre à un questionnaire reprenant les divers problèmes habituellement rencontrés :

• difficultés à définir le besoin fonctionnel et à maîtriser son évolution au cours du temps,
• délais importants entre chaque version et effet tunnel pendant les périodes de développements,
• les versions se terminent généralement avec du retard,
• communication avec la MOE,
• la productivité n'est pas au rendez-vous.

Ce questionnaire ayant permis à la MOA de mettre le doigt sur des problèmes récurrents, Alexandre présente les avantages que vont apporter l'utilisation des méthodes agiles dans leur travail :

• meilleure communication et visibilité sur le travail de la MOE,
• livraisons fréquentes à dates fixes d'un produit démontrable et fonctionnel,
• amélioration de la productivité.

Alexandre termine par préconiser un accompagnement pour se former et passer aux méthodes agiles le plus rapidement et le plus efficacement possible.

L'adoption d'une méthode de travail (agile ou non) par l'ensemble des acteurs d'un projet est fondamentale. Il est en effet compliqué pour une MOA de travailler avec des méthodes différentes de celles employées par la MOE. Cela génèrera immanquablement des problèmes de communication entre les deux parties.
Convaincre une MOA de changer ses habitudes de travail n'est pas chose aisée, et le questionnaire proposé par Alexandre Boutin (potentiellement agrémenté en fonction des spécificités du contexte du projet) peut-être un bon moyen de déclencher le besoin de changement.
L'adoption d'une méthode agile n'est pas sans contrainte, mais un bon coach agile saura mettre en avant les bénéfices de l'agilité pour combler les lacunes de l'ancienne méthode.

RIA

Sortie de SproutCore 1.0

Les frameworks HTML5 continuent de se mettre à jour. Et après 52framework, c'est au tour de SproutCore de sortir en release majeure (version 1.0, information relayée ici).

InfoQ a récemment réalisé une interview de Charles Jolley (CEO de Sproutit) concernant SproutCore.
On y apprend ainsi que le framework gère certaines fonctionnalités d'HTML5 (comme l'offline storage ou le nouveau tag video) et qu'il est possible d'intégrer du code existant jQuery, ExtJS, YUI ou bien encore Prototype.
Il explique aussi les raisons principales de la migration, côté vue, de Ruby à JavaScript. La première est l'arrivée prochaine d'un Drag & Drop UI Designer (facilitée par les APIs JavaScript) et la seconde pour des raisons de performances (jusqu'à 10 fois plus rapide que la version précédente !).

Rendez-vous sur cette page pour une petite démonstration de SproutCore et sur celle-ci pour le téléchargement.

Le coin de la technique

Commenter son code: jusqu'où aller ?

Rebondissant sur une discussion qu'ont eu des programmeurs .Net de Seattle, InfoQ publie un article sur l'intérêt de commenter (ou non) son code. Le sujet, tel un éternel serpent de mer, donne toujours matière à discussion. A tel point que les interventions des lecteurs, à la suite de l'article, sont des plus intéressantes !

Le consensus semble être que les commentaires sont à éviter au maximum car le code se doit de s'auto-documenter: sans commentaires, et seulement avec le nom des méthodes et des variables, nous devons être capable de le comprendre. Ainsi, pour Thiébaut Champenier, il y a 2 types de commentaires:

• Les commentaires documentant l'API (notés /** */ )
• Les commentaires dans le code (notés /* */ ou // ) qui doivent un maximum décrire pourquoi le code existe plutôt que comment le code agit.

Alex Suvorov ajoute qu'une suite de plusieurs opérations successives nécessitant un commentaire devrait plutôt être extraite en une fonction nommée de manière explicite. Tim Linquist, lui va même plus loin en souhaitant disposer d'une fonctionnalité lui permettant de sortir les commentaires du code une fois la documentation (javadoc) générée. Pour contrebalancer ces avis, la palme du meilleur commentaire revient à Pete Haidinyak. Celui-ci se permet une suggestion amusante destinée à toutes les personnes "qui ne commentent pas leur code ou qui pensent qu'un commentaire toutes les 10000 lignes est suffisant". Il leur demande de rajouter un en-tête dans leur code spécifiant: "A toute personne chargée de maintenir ce code: si vous ne comprenez pas mon code ou êtes troublé par mon style, n'hésitez pas à m'appeler à toute heure, nuit et jour, au numéro suivant: { numéro_de_téléphone_du_développeur }. Je vous expliquerai ce que j'avais en tête lorsque j'ai écrit ce code". L'idée est bonne, avec un tel en-tête, les développeurs risqueraient de se soucier un peu plus de la façon dont les autres peuvent comprendre leur code !

Où l'on reparle de la JSR-310

La JSR-310 (Date and Time API) était initialement prévue pour le JDK 7 mais il y a un an, la roadmap de Sun l'en excluait. Cette spécification était pourtant attendue par tous ceux qui étaient lassés par les défauts de java.util.Date et qui voyaient en Jodatime (dont la JSR-310 est largement inspirée) une échappatoire tentante. L'API proposée par cette JSR est en effet beaucoup plus riche et permet de représenter tous les concepts d'instants et de durées.

Lors de l'annonce du report du JDK 7 en novembre dernier, Mark Reinhold avait laissé la porte ouverte aux fonctionnalités qui avaient été abandonnées faute de temps ; la JSR-310 en faisait partie. Courant février, questionné sur cette spécification par un spectateur d'un webcast, il disait regretter qu'elle n'ait pu être finalisée dans les temps. Dans le même temps, Stephen Colebourne, spec lead de la JSR-310, expliquait sur son blog qu'il disposait désormais de temps libre pour travailler sereinement sur cette spécification. Quelques semaines plus tard une early draft review voyait le jour. Enfin, il y a quelques jours, Stephen Colebourne répondait à un commentaire en disant que l'inclusion de la JSR-310 dans le JDK 7 dépendrait de sa finalisation et de la volonté de Sun/Oracle.

La saga de la JSR-310 semble donc renaître de ses cendres et la possibilité de son intégration au prochain JDK est bien réelle. L'affaire est donc à suivre...

A l'origine, JDuchess est un JUG féminin provenant des Pays Bas. Après avoir rencontré Clara Ko (JUG Leader de JDuchess), elles nous a proposé de représenter son JUG en France. Ce que nous souhaiterions pour JDuchess c'est de monter une communauté où les femmes faisant du Java peuvent se rencontrer et partager leurs expériences, leurs points de vue. Nous voudrions pouvoir monter un réseau social pour rendre les femmes plus visibles dans ce domaine, les inciter à participer à des événements comme le Paris JUG, et d'autres événements techniques ou conférences. Et pourquoi pas y faire une présentation.

Vous pouvez rester en contact avec les Duchess via Twitter , notre Google Group et LinkedIn.

Pour celles qui assisteront à la soirée Emmanuel Bernard du Paris JUG le 9 Mars vous pourrez retrouver les Duchess pour l'Avant JUG qui se passera au Vavin Café (18, Rue Vavin, 75006 Paris) à partir de 18h30.

Lorsque vous serez inscrites au JUG, contactez ellene(dot)dijoux(at)jduchess(dot)org qui vous accueillera Mardi prochain.

J'y serai et je serai heureuse de vous y rencontrer.

Sommaire

• HTML5 ?
• Nouveau modèle de contenu
• Nouveaux éléments de mise en page
• Eléments interactifs
• Les WebForms
  • Nouveaux input
  • Validation native
  • Auto-complétion
  • Répétitions
  • Etat des lieux
• Multimedia
  • Audio et Video
  • La guerre des Codecs
  • Le Canvas
• Conclusion

HTML5 ?

HTML5 est au départ la nouvelle version du langage HTML en cours de développement par le W3C. Pour le moment, il s'agit d'une recommandation en DRAFT, fruit du travail initial réalisé par le WHATWG depuis 2004. Le W3C espère en faire un de ses standards libres aux alentours de 2022. De prime abord, ça nous laisse le temps de réfléchir au problème pendant les 10 prochaines années. L'idée d'une nouvelle version de HTML serait motivée par quelques constats simples :

• Les navigateurs ont besoin de plugins pour gérer le multimédia (flash et consorts)
• La structure des documents n'est pas intuitive et rend l'accessibilité difficile
• Les API JavaScript varient trop d'un navigateur à l'autre pour garantir la portabilité des documents
• Les sites sont de plus en plus proches des applications de bureaux mais souffrent encore de limitations

Pour répondre à ces problématiques et favoriser l'émergence du web sémantique, la spécification propose :

• Un nouveau modèle de contenu des éléments
• Des éléments de mise en page
• De nouveaux éléments pour les formulaires
• Du contenu multimédia
• Plus d'interactivité
• Des APIs standards JavaScript

Bien que la spécification soit encore en cours d'écriture, certaines parties sont déjà très avancées et les navigateurs ont tous commencé à les implémenter. Google Chrome est actuellement en tête. Il bénéficie nativement de Gears et respecte 87% de la spécification. Parmi les principaux supporters de ce standard en devenir, nous retrouvons Google, Mozilla, Opera, Apple et Palm, pour ne citer que les plus grands. Apparemment, les navigateurs qui ont le vent en poupe sont tous de la partie. Microsoft, de son côté, suit la tendance de très loin en intégrant des fonctionnalités au compte goutte dans son IE, qui supporte tout de même 28% du langage.

Nouveau modèle de contenu

Bye, bye, les alignements hasardeux dus aux éléments de type bloc ou en ligne. Les éléments seront plutôt classés par catégories.

• La catégorie ancêtre Flow correspond à tous les éléments qui contiennent un flot de texte
• Phrasing correspond aux éléments qui apparaissent dans le texte (a, li)
• Interactive définit les éléments qui fournissent une interaction avec l'utilisateur
• Embedded affiche des ressource externes dans le document
• Les Metadata représentent tout ce qui n'est pas affiché (style, script, ...)
• Heading définit les en-têtes d'une section
• Sectioning définit le scope des en-têtes et pieds de page

Toutes ces catégories permettent de définir le contenu autorisé pour les éléments. Leur but est d'une part de fournir une grande souplesse de composition (par exemple la balise a peut maintenant contenir un paragraphe entier, une liste ou des headers (h*)), d'autre part ces catégories permettent aux navigateurs d'assimiler le contenu de la page, notamment pour les exports d'impression ou l'accessibilité.

Nouveaux éléments de mise en page

Jusqu'à maintenant, l'élément de mise en page par excellence était la balise div. La grande majorité des sites est construite sur un modèle d'empilement de ces boites avec des id différents pour finir par une grosse partie de styles CSS assurant le positionnement. Mais cela a quelques inconvénients:

• Ce n'est pas intuitif pour le développeur, vous en conviendrez.
• Le navigateur ne peut pas connaître le rôle de chacune des parties de la mise en page, ce qui rend beaucoup plus difficile la génération de plan ou d'aide à la navigation.

Les balises article, section, header et footer indiquent clairement à quel type de texte elles correspondent et comment s'organise leur contenu. La balise aside définit un contenu lié au sujet principal, sans en faire partie pour autant. Reste le tag nav qui est prévu pour servir les liens de navigations de la page comme un menu par exemple. La mise en page proposée ci-dessus ne révèle pas la flexibilité d'utilisation de ces éléments. Notez bien que les article et section peuvent avoir leur propre header et footer.

Avec ces nouvelles balises, nous serons enfin capables de gérer l'organisation de nos documents de façon intuitive et les navigateurs pourront générer le plan des documents eux-mêmes. L'algorithme nécessaire est d'ailleurs décrit dans la spécification. Tous ces éléments sont déjà supportés nativement par les navigateurs avec l'exception habituelle de IE pour lequel il existe un workaround JavaScript. Vous pouvez dès maintenant vous familiariser avec ces nouvelles balises sans avoir peur des problèmes de compatibilité.

Eléments interactifs

Sous ce terme limpide se cachent les éléments qui fournissent de l'interaction utilisateur dans la page. Ce qui correspond aux Interactive elements de la spécification. La grosse nouveauté ici est la définition d'une balise menu permettant de construire des barres de menu (type="toolbar"), des menus contextuels (type="context") ou de simples listes de commandes. Un tag menu peut contenir des sous-menus et se compose d'éléments permettant de lancer des commandes.

Pour les commandes, HTML5 propose directement un élément command qui permet d'associer un texte ou icône à une exécution JavaScript sur événement onclick="alert('hello world')". Pour utiliser le menu contextuel, il suffit d'ajouter l'attribut contextmenu="menu_id", sur l'élément qui doit utiliser le menu.

L'autre nouveauté parmi les éléments interactifs est la balise details. Le fonctionnement de ce tag est proche d'un menu en accordéon, avec une partie de texte toujours affichée et une partie cachée pouvant être rendue visible sur demande de l'utilisateur. Cela peut être utile, pour cacher des options avancées par exemple.

Ici, le tag details est utilisé pour cacher les informations techniques d'une copie. Vous noterez au passage l'utilisation d'une balise progress, pour afficher une barre d'avancement.

Les WebForms

Nouveaux input

Les formulaires aussi profitent de la mise à jour en reprenant en partie XForms pour les connaisseurs. Le principe est de fournir des input fortement typés ainsi qu'une API JavaScript de validation en plus d'une interactivité accrue. Parmi les nouveaux types d'input, il y a :

• Le support des saisies de dates et heure décliné sous plusieurs formes (date, datetime, datetime-local, month, week, time). Nous n'aurons donc plus besoin des widgets supplémentaires JavaScript pour générer des calendriers.
• La saisie de formats numériques via les number et les range qui pourront prendre la forme d'un slider vertical ou horizontal
• Différents types de chaînes formatées comme les url, les email et tel
• Le selecteur de couleur color
• Le champ de recherche search

Les anciens types sont maintenus. Ils bénéficient d'un bon lifting, tel le type file qui permettra désormais de sélectionner plusieurs fichiers d'un seul coup, tout en précisant le type mime accepté. Il y a aussi l'attribut placeHolder qui permet de fournir un texte descriptif affiché dans le champs si il n'est pas renseigné.

Validation native

Tous les input supportent de nouveaux attributs de validation qui permettent de contraindre les saisies de l'utilisateur, et peuvent interdire la soumission du formulaire, s'il n'est pas valide. Encore une fois, cela permettra de remplacer des solutions hétérogènes JavaScript par un standard nativement supporté par le navigateur. La validation s'accompagne aussi de nouveaux évènements DOM pour notifier les erreurs ou surcharger la validation avec son propre code JavaScript. Plus besoin non plus de jouer avec les classes CSS pour faire ressortir les champs en erreur grâce aux pseudo-formats (:invalid, :valid, :Out-of-range, ...).

Des validateurs par défaut sont fournis sous la forme de nouveaux attributs à placer sur les input :

• required pour un champ requis
• min et max permettent de définir une valeur minimum et maximum sur les types numérique et date
• pattern fournit une expression régulière que la saisie doit respecter

Auto-complétion

Autre nouveauté inspirée des widgets JavaScript existant, les datalist sont des listes de valeurs construites à l'aide d'éléments de type liste (li, option, ...). La datalist est transparente par défaut mais elle peut-être liée à un ou plusieurs input avec l'attribut list. Une fois l'association établie avec un input, la liste est utilisée pour fournir des suggestions à la saisie. Les éléments à l'intérieur de la liste peuvent-être décorés par CSS directement.

Répétitions

Une autre évolution sympathique est la création d'un système de template, facilitant la création de formulaire dynamique. Dans les applications de gestion, il est souvent utile de pouvoir ajouter et supprimer des lignes de saisie dans le formulaire. Le système de répétition est fait pour ça. Je peux définir un bloc comme étant mon template, et le contenu de cet élément pourra être dupliqué via une API JavaScript.

C'est l'attribut repeat qui définit notre bloc de répétition, le repeat-start permet de gérer les aller-retour serveur, pour afficher la liste avec le nombre d'éléments précédemment soumis. Pour assurer l'ajout et la suppression de ligne, j'ai utilisé les boutons de type add et remove mais j'aurais aussi bien pu utiliser des méthodes JavaScript de l'élément template addRepetitionBlock(). Il y a aussi des solutions pour gérer l'ordre des répétitions permettant de monter et descendre les lignes répétées.

Etat des lieux

Voilà la promesse d'un monde meilleur dans lequel nous aurons moins de travail à fournir (CSS, JS) pour obtenir des résultats simplement meilleurs. Notez une dernière chose, les input peuvent être liés à un ou plusieurs formulaires via le nouvel attribut form. En d'autres termes, il sera possible de placer nos input pour un formulaire à l'extérieur de ce dernier.

Comme vous l'avez remarqué, j'ai utilisé le futur dans ce paragraphe car pour le moment seul Opera 9 supporte nativement les WebForms. Pour permettre aux développeurs de s'y essayer et valider la spécification, le projet WebForms2 propose une implémentation partielle en JavaScript. La spécification au départ avait été séparée du langage HTML5, mais le W3C a décidé de la ré-intégrer en y apportant des modifications. Du coup la plupart des fonctions développées sont liées à une ancienne version des WebForms.

Pour les autres navigateurs, notez tout de même que les développements ont déjà commencé. Par exemple Chrome 5 devrait être livré avec le support des nouveaux input et l'API de validation(Chrome Web Platform Status). Safari bénéficie du même support que chrome qui se limite aux types search, range et file multiple. Du côté de Firefox, les choses sont moins claires ; il existe bien un ensemble de bugs pour le support des WebForms mais Mozilla communique peu sur le sujet. Actuellement, Internet Explorer 8 ne supporte aucune des ces nouveautés et il est impossible de connaître la roadmap de Microsoft sur le sujet. Tout ce que l'on sait, c'est que l'éditeur a décidé de mettre les bouchées doubles pour améliorer son support des travaux du W3C. Peut-être une bonne solution pour inverser la vapeur et en finir avec la descente aux enfers de son précieux navigateur.

Page de démonstration pour Chrome, Safari et Opera.

Multimedia

Il est temps de parler des nouveaux types de contenu poussés par HTML5. Les auteurs du whatwg se sont probablement demandé pourquoi doit-on installer des plugins dans nos navigateurs ? Nous savons a priori tous aujourd'hui que Flash est utilisé principalement pour 3 choses dans les applications :

• Pouvoir écouter de la musique
• Pouvoir regarder des vidéos
• Faire des animations de folies

J'ai mis volontairement de côté Flex car il cible plutôt les applications d'entreprise, et les jeux Flash car le Boss ne veut pas en entendre parler . Sachez, si vous êtes passé à côté de ça, que HTML5 adresse ces trois problématiques en sortant trois nouvelles balises de son chapeau :

• audio permet de gérer la lecture de fichiers audio en streaming.
• video assure la lecture de vidéos en streaming toujours.
• canvas permet de dessiner et de faire des animations en JavaScript.

Audio et Video

Jusqu'à maintenant, les gros avantages de la technologie d'Adobe sont la portabilité puisque Flash est disponible pour tous les navigateurs, et la performance en comparaison avec les moteurs JavaScript. Il est clair que ces trois balises viennent marcher sur les plate-bandes de Flash. Les éléments média disposent des attributs :

• controls pour activer l'affichage de l'interface de contrôle du navigateur
• autobuffer pour activer le chargement automatique de la ressource en cache
• autoplay pour activer le lancement automatique de la lecture
• loop pour lire le ou les médias en boucle
• src pour fournir l'url du fichier média à lire

La balise source placée à l'intérieure d'une balise audio ou video permet aussi de définir l'url (@src), le type mime et le codec (@type) d'une ressource média. Il suffit de mettre plusieurs source pour créer une playlist.

Si le navigateurs n'arrivent pas à lire le fichier ogg, il tentera de lire le fichier H.264. De même, si le navigateur ne supporte pas l'élément video, il affichera le texte alternatif. Il suffit donc de placer un lecteur Flash à la place du texte pour que la vidéo reste lisible dans un ancien navigateur.

Si vous ne voulez pas utiliser l'interface native, ou que vous souhaitez simplement cacher le lecteur audio, vous pouvez utiliser l'API standard JavaScript pour créer un lecteur, et profiter des méthodes play(), pause(), et load() pour charger la prochaine ressource média. Une dernière méthode : canPlayType(type), permet de demander au navigateur si il supporte le format vidéo ou audio fournit en paramètre. Cela sera très utile pour gérer les incompatibilités de format.

De plus l'interface HTMLMediaElement fournit quantité de propriétés allant du volume à l'état du buffer en passant par le temps de lecture courant. Le tout est, bien sûr, accompagné d'une batterie d'événements qui permettent de suivre l'avancement du chargement, l'état du lecteur, et les action lancées par l'utilisateur.

Pour plus de détail sur le sujet, je vous invite à lire la spécification W3C des éléments média et à tester la démo de jPlayer un lecteur audio pour jQuery.

La guerre des Codecs

Venons en au problème des codecs. Le W3C se contente de citer un certain nombre de formats allant du H.264 au DIRAC pour la vidéo en passant par mpeg-4 et Theora; même chose pour l'audio avec AAC, FLAC, Vorbis, ... La spécification laisse le libre choix aux navigateurs et table sur la création d'extensions propres à ces derniers pour apporter le support de nouveaux formats. Si aujourd'hui YouTube et Vimeo ont choisi le H.264, DailyMotion joue les fidèles Mozilla avec sa démo basée sur Ogg et ne supportant que Firefox.

Chrome et Safari poussent H.264 tandis que Mozilla le rejette totalement et pousse les formats libres Vorbis et Theora (Ogg). Le gros avantage d'H.264, à mon sens, tient au fait qu'il est parfaitement adapté à l'embarqué et beaucoup plus optimisé que Theora. Malgré le barrage de Firefox (25% de parts de marché), avec Apple et Google le codec H.264 semble avoir de beaux jours devant lui. Google qui est justement le plus gros contributeur de Mozilla, fournira peut-être une extension, sinon ce sera probablement du codec pack pour tous.

Codecs supportés par navigateurs

Internet Explorer est pour le moment hors-jeu, sauf si on installe Google Chrome Frame. Mais il semblerait que Microsoft s'intéresse au sujet pour l'avenir et participe à la rédaction de la spécification. En attendant, Flash conserve une avance confortable et profite de sa très large base installée. Le changement arrive bizarrement par l'embarqué, iPhone et iPod Touch en tête, qui, d'une part, supportent pleinement les balises audio, et video, et d'autre part prouvent que les utilisateurs peuvent se passer de Flash sur le web.

Le Canvas

Passons maintenant au canvas. Inventé par Apple pour le Dashboard d'OS X et ses widgets, le canvas fournit une API JavaScript pour le dessin 2D. La balise définit une aire de dessins avec sa hauteur et sa largeur. L'objet DOM donne accès au contexte graphique qui possède les primitives de dessins. Outre les formes géométriques standards, l'API permet de faire de la composition, des transformations, de manipuler des images et d'afficher du texte formaté. Avec un timeout ou un intervalle sur l'objet et un peu de JavaScript, il devient possible d'animer les dessins. Les implémentations ne sont pas encore très optimisées. Un simple gif animé reste pour le moment plus performant en terme d'animation. Il existe déjà un tas de librairie JS construites autour de l'élément canvas pour générer des graphes et des charts par exemple (Flotr, ProtoChart, fgCharting).

Les détracteurs déplorent l'utilisation d'une API procédurale, et l'absence d'éléments crées dans l'arbre DOM de la page comme le fait SVG. Autre inconvénient, canvas travaille la composition directement en pixels et non en calques. SVCKit a donc implémenté en grande partie SVG dans canvas dans SVGCanvas. Il existe déjà beaucoup de documentations et tutoriels autour de canvas qui rencontre, malgré ses défauts (de jeunesse ?), un grand succès. Mozilla a même développé un IDE en ligne basé sur canvas, nom de code : BeSpin.

Voilà pour les domaines d'application, passons maintenant à la question des navigateurs. Avec Apple pour inventeur et Mozilla comme évangéliste, canvas est déjà supporté nativement sur Safari, Firefox, Chrome et Opéra. Comme d'habitude IE est à la traine, mais il existe des contournements comme le plugin IECanvas, ou le portage Flash ExplorerCanvas.

Conclusion

Nous voici à la fin de ce tour d'horizon des nouveautés d'HTML5, côté contenu du moins.
Avec les grands du web dans la poche, HTML5 est déjà promis à un bel avenir, malgré son jeune age. La prochaine échéance du W3C devrait être le passage en recommandation dans le courant de cette année peut-être. Si les WebForms ne sont pas pour tout de suite, le multimédia et le canvas sont déjà suffisamment supportés pour être utilisés aujourd'hui. Il faudra attendre la sortie d'IE 9 pour connaître les plans concrets de Microsoft sur le sujet. A mon humble avis, Microsoft intégrera HTML5 au fur et à mesure qu'il s'imposera sur le web. Il faudra aussi regarder de près l'évolution du standard CSS car HTML5 ne va pas sans CSS3. De ce côté, pas de crainte à avoir puisque même IE est dans la course.

Il reste un problème d'outillage, car il n'existe pas pour le moment de WYSIWYG compatible HTML5. Et il ne faut sans doute pas compter sur Adobe pour le faire rapidement. Apple propose déjà DashCode pour créer des widgets ou des applications web iPhone avec un éditeur graphique bien monté. Mais l'export vers d'autres navigateurs est presque impossible tant les applications construites reposent sur des fonctionnalités spécifiques de Safari.

Dans le prochain article, je vous présenterai les nouveautés JavaScript poussées par HTML5 et leur état actuel d'implémentation.

Actualité éditeurs / SSII

• Sonatype ouvre son dépôt maven pour java.net
• La fusion JRockIt / Hotspot pas pour demain

Agilité

• Utilisez-vous des métriques intelligentes sur vos projets ?

Le coin de la technique

• Jigsaw, les modules du pauvre ?
• Comment les closures seront implémentées dans OpenJDK 7 ?
• L'actualité des bases de données NoSQL toujours aussi riche
• Astuce de la semaine, récupérez la liste complète des options de votre JVM

Actualité éditeurs / SSII

Sonatype ouvre son dépôt maven pour java.net

L'idée est venue d'une quantité toujours grandissante de plaintes sur les dépôts Maven fournis par java.net. A l'heure de la fusion annoncée entre Kenai et java.net, Kenai n'a aucune solution pour gérer les dépôts et java.net fait mauvaise presse sur ce point. Il n'aura pas fallu longtemps à Sonatype pour saisir l'opportunité de mettre en avant sa solution Nexus. L'éditeur propose donc à tous les projets java.net de migrer vers leur instance Nexus OSS, allant même jusqu'à organiser le 5 mars une grande journée migration, avec la mise à disposition pour tous des services de conseil et d'ingénierie interne. Outre la performance et la stabilité du dépôt Maven maintenu par Sonatype, Nexus génère des fichiers d'index utilisés par nos IDE pour rechercher les dépendances de nos POM.

• La nouvelle sur DZone
• L'annonce sur le blog Sonatype

La fusion JRockIt / Hotspot pas pour demain

Nous en parlions il y a quelques semaines, Oracle envisage de ne proposer à l'avenir qu'une seule JVM, qui tirerait le meilleur des deux que la firme s'est offert (JRockit via BEA, et Hotpsot via Sun). Dans un récent webcast (via InfoQ), Mark Reinhold s'est exprimé sur le sujet. Cette fusion n'est pas pour tout de suite : trop de clients utilisent les fonctionnalités spécifiques à l'une ou l'autre des JVMs en production, et il serait risqué de les forcer à migrer vers une version fusionnée bancale. Ce dernier se dit jaloux de certaines fonctionnalités de JRockIt et donc particulièrement excité d'avoir l'occasion de l'étudier en profondeur. Cependant, ce qui transparait dans son discours (et peut être via nos diverses expérience), c'est que la JVM de Sun est en avance sur celle de BEA. La prochaine version fusionnée devrait donc tendre plus vers Hotspot que vers JRockit. En résumé rapide, cette future VM Oracle devrait avoir les fonctionnalités runtime de Hotspot, et le garbage collector et la robustesse de JRockit. Finalement, à part l'ébauche d'une timeline, nous ne sommes pas beaucoup plus avancés.
Coté nouveautés du JDK 7, Mark Reinhold se dit aussi particulièrement excité par l'intégration du projet Coin (au contraire de la grande majorité des consultants Xebia, qui trouvent que la plupart de ces évolutions syntaxiques confinent au gadget).
Il reparle aussi des closures, principalement sous l'angle des raisons de la polémique, mais personne ne semble réellement savoir comment elles seront implémentées dans le JDK 7 (voir ci-dessous pour l'avancement du projet Lambda).
Dernière annonce, pour ceux qui comme lui sont impatients de voir une JVM enfin modulaire (aka Jigsaw, prévu dans le JDK 7, voir ci-dessous), ils devraient en avoir un aperçu mi-mars, avec la release 88 de l'OpenJDK.

Certains noteront avec un certain amusement (ou une certaine nostalgie) quelques ratés : "We, at Sun..."

Agilité

Utilisez-vous des métriques intelligentes sur vos projets ?

Mike Griffiths, agiliste expérimenté et bloggeur actif, nous présente sa réflexion sur l'utilisation des métriques dans un projet.
Au préalable, Mike nous prévient que :

• Toutes les observations ne sont pas utiles et d'une grande aide pour analyser et comprendre un phénomène. Elles peuvent même amener à de mauvaises conclusions.
• Certaines mesures très utiles ne sont pas facilement observables.

Une autre caractéristique à ne pas négliger est l'effet Hawthorne : L'observateur influence la mesure. On retrouve d'ailleurs ce phénomène en physique quantique. Mike nous explique alors que le fait d'observer et donc d'influencer la mesure, à un effet positif.

Pour lui, une métrique « intelligente » doit avoir les caractéristiques suivantes :

• Simple et auto-générée.
• Influence de manière significative ce que l'on cherche à observer.
• Permet de prendre des décisions et décrire des tendances pour le futur.

Mike nous conseille de donner plus d'attention aux métriques permettant d'observer des tendances futures et d'anticiper.

On peut ainsi opposer aux vieilles métriques : nombres de lignes codées, points de fonctions réalisés ou nombres d'heures travaillées ; des métriques plus « intelligentes » : confiance des sponsors, satisfaction client, nombre de fonctionnalités réalisées, ou encore temps passé à la correction de bugs.

Dans la dernière partie de l'article sont présentés un certain nombre de métriques plus ou moins connues des agilistes, comme : le taskboard de Scrum ou Kanban. L'utilisation de métriques intelligentes est indispensable pour mener à bien un projet. Elles permettent d'observer des tendances, d'identifier et d'anticiper des problèmes; et ainsi, de prendre les bonnes décisions.

Le coin de la technique

Jigsaw, les modules du pauvre ?

Adam Bien est l'un des Java champions les plus visibles et les plus lus d'internet. Il a publié cette semaine un petit article au titre accrocheur : « Jigsaw / JDK 1.7 sera une solution qui permettra de répondre à 80% des besoins de modularité ». Vous avez probablement suivi les différents épisodes et rebondissements de la modularité dans le JDK 7. C'est peut-être l'occasion de faire le point sur ce que propose Jigsaw.

Le projet Jigsaw proposera une implémentation permettant la mise en place d'un système de modules bas niveau pour vos projets. Il sera également utilisé en interne pour découper le JDK Oracle/Sun lui-même.

• Jigsaw vous permettra de choisir tout ou partie du JDK tout en restant 100% rétro-compatible, d'améliorer les temps de démarrage de la JVM et son utilisation mémoire.
• Jigsaw  pourra être utilisé directement sur vos projets si vous disposez d'une JVM reposant sur ce système. Jigsaw sera chargé avant rt.jar et sera donc disponible à quiconque désirant l'utiliser. Ce projet étant open source, il sera également possible de réutiliser celui-ci dans d'autres contextes.
• Jigsaw vous permettra de rendre vos applications modulaires progressivement. Nul besoin de migrer vos applications dans leur ensemble pour tirer parti des bénéfices de la modularité. Un même package peut être éclaté dans plusieurs modules.
• Contrairement à OSGi, Jigsaw ne vous permet pas le rechargement de modules à chaud. Vos modules sont chargés statiquement au démarrage de vos applications.
• Tous vos modules sont chargés dans un même classloader, cela permet de simplifier grandement son utilisation. Du même coup, il vous sera probablement possible de 'tricher' en chargeant, au runtime, des classes d'un module sans que vous en ayez réellement le droit.

Si vous confondiez modularité du JDK avec OSGi, cette liste vous a certainement ouvert les yeux : Jigsaw vous propose une solution beaucoup moins fournie qu'OSGi.

Dans les faits, ce projet a été créé, avant tout, pour casser notre bon vieux JDK monolithique. Bon nombre de polémiques ont été faites sur ce choix. Pourquoi se contenter d'aborder 80% des problématiques de la modularisation avec une nouvelle solution alors qu'OSGi en aborderait 90% ? La simplicité et la souplesse d'utilisation ont été préférées à une solution décrite comme lourde (nécessitant beaucoup de glue), vieillissante (datant de 1998) et difficile à maîtriser. Ce choix a été sans conteste difficile à effectuer, il s'est ailleurs attiré les foudres des défenseurs d'OSGi, mais reste complètement défendable.

Comment les closures seront implémentées dans OpenJDK 7 ?

Fin 2009, le projet Lambda, dont le but est d'apporter les closures à la prochaine version de Java, apparaissait au sein d'OpenJDK. Le lancement du projet faisait suite aux rebondissements dans l'actualité du JDK 7 lors de la conférence Devoxx un mois auparavant. Une documentation montrant la syntaxe des closures avait accompagné la création du projet, plus tard, un draft d'une spécification plus formelle est apparue, mais quid de l'implémentation ?
Rémi Forax, contributeur au projet Lambda, a mis à disposition la présentation qu'il a faite au FOSDEM'10, dans laquelle il résume les discussions ayant eu lieu sur la mailing list du projet concernant les possibilités d'implémentation :

• Convertir les closures en classes anonymes. Cette solution présente l'inconvénient de produire beaucoup de classes et pose problème pour certaines constructions liées au closures.
• Convertir les closures en invocations dynamiques telles que le permettra la JSR-292 (Supporting Dynamically Typed Languages on the Java Platform). Cette solution ne produit pas de classes supplémentaires et bénéficie de bonnes performances puisque l'invocation dynamique présentera un temps d'exécution similaire aux invocations de méthode classiques.

Le reste de ses slides présente certaines des problématiques d'implémentations des closures liées à l'accès aux variables locales et aux champs de la classe hôte.

L'actualité des bases de données NoSQL toujours aussi riche

Depuis plusieurs mois maintenant le mouvement NoSQL s'est installé dans l'actualité. A Paris, le NoSQL User Group a attiré l'attention en réunissant une cinquantaine de personnes à chacune de ses 2 sessions jusqu'à présent.

D'un point de vue plus général, l'actualité des bases de données NoSQL est marquée par l'intérêt croissant qu'elles suscitent, et par leur évolution rapide grâce à l'effort soutenu de leurs développeurs. Ainsi on a pu noter récemment :

• Neo4j, une base de données orienté graphe, est maintenant disponible en version 1.0 finale. L'intérêt de la représentation en graphe est la possibilité de modéliser les données relatives aux réseaux sociaux, mais également tout type d'objets qui seraient liés entre eux de manière arbitraire. De plus, il est possible d'appliquer à ces données divers algorithmes de graphe classiques tels que la détermination du plus court chemin entre deux objets ou de l'objet central/majeur dans un nuage d'élément.
• Cassandra vient pour sa part d'être publié en version 0.5.1, et connait un succès tout particulier puisque Twitter vient d'annoncer qu'il l'utiliserait désormais comme solution de persistance en remplacement de MySQL. Par ailleurs le projet Lucandra a été créé récemment pour permettre d'utiliser Cassandra comme solution de persistance pour les indexes Lucene. Donné à la Fondation Apache par Facebook, Cassandra est pour rappel un hybride entre BigTable de Google et Dynamo d'Amazon.
• HBase profite d'une communauté très active et d'un intérêt important, renforcé par sa position de sous-projet du très populaire Hadoop. Sematext vient de publier un digest de l'actualité récente de ce projet. Celle-ci est principalement marquée par le développement d'une réplication multi datacenter, par l'arrivée d'un plugin DataNucleus pour HBase et par la disponibilité prochaine d'une solution de benchmark pour les cloud storages développée par Yahoo!.

Enfin, deux conférences entièrement dédiées au NoSQL sont à venir : NoSQL Live le 11 mars à Boston et, plus proche de nous, NoSQL Europe du 20 au 22 avril à Londres.

Astuce de la semaine, récupérez la liste complète des options de votre JVM

Cette astuce est complètement inutile, et donc également complètement indispensable. Cet article nous propose une petite commande permettant de récupérer la liste complète des options de votre JVM Hotspot à partir de sa library native Linux, la voici :

Je vous propose donc un petit tutoriel pour mettre en place une gestion des utilisateurs, avec gestion des rôles, filtres URL/Rôles, formulaire de souscription de compte. Pour cela, nous allons nous appuyer sur le Spring Security Plugin de Grails. C'est une étape incontournable de la création d'application, et nous allons pouvoir constater à quel point l'utilisation de Grails booste la productivité.

Béni soit le scaffolding

Commençons par créer l'application BookStore qui nous servira de base, ainsi qu'une classe de domaine Book.

Apportons quelques modifications à notre classe pour qu'elle soit un peu plus parlante dans la suite des exemples :

grails-app/domain/fr/xebia/bookstore/common/Book.groovy

Maintenant nous générons le CRUD autour de notre classe Book.

Installation du plugin Spring Security. Pas de panique, acegi est toujours le nom du plugin, c'est un héritage de l'histoire

Creation des classes de domaines pour la gestion de la sécurité, Utilisateur, roles et mapping de security et génération des managers associés

Maintenant nous générons les composants nécessaires à la souscription d'un compte par un internaute.

A ce stade, nous disposons des contrôleurs suivants (et des vues qui vont avec) :

• CaptchaController : permet de générer des images captcha pour éviter que des robots ne viennent créer des comptes utilisateurs
• fr.xebia.bookstore.common.BookController : CRUD de gestion de la classe Book
• LoginController : Contrôleur de connexion
• LogoutController : Contrôleur de déconnexion
• RegisterController : Contrôleur d'enregistrement d'un compte utilisateur par un internaute
• RequestMapController : CRUD de gestion des règles de sécurité
• RoleController : CRUD de gestion des rôles
• UserController : CRUD de gestion des utilisateurs, destiné à notre espace d'administration

On peut déjà démarrer l'application avec un grails run-app et voir ce que ça donne :

Configuration et sécurisation

Cela fait déjà beaucoup de matières à exploiter en un temps relativement court. Mais en l'état c'est encore un peu brut de fonderie pour ressembler à une vraie application. Nous allons donc faire un peu de configuration et de rangement autour de tout ce code parachuté par Grails. Pour atteindre notre objectif, nous allons maintenant procéder à la sécurisation des écrans de :

• CRUD complet des utilisateurs
• CRUD complet des rôles
• CRUD complet des mappings de sécurité
• Création de Book

Tout est déjà en place pour cela grâce au code que nous avons généré. Commençons par utiliser le RoleController pour créer un rôle utilisateur et un rôle administrateur :

Maintenant que nous avons des rôles, il faut créer un compte utilisateur avec le rôle ROLE_ADMIN pour éviter de se retrouver bloqué quand on posera les mappings de sécurité. Cette fois, c'est du coté des écrans du UserController que ça se passe :

Et pour finir, on pose des mappings de sécurité sur les URL qui nous intéressent, avec la liste des rôles autorisés à accéder. Pour cela, nous utilisons le RequestMapController :

Et voilà ! Notre application répond déjà mieux à nos attentes en terme de sécurité :

• tout le monde peut voir la liste des Book présents en base.
• seuls les utilisateur ayant le rôle ROLE_USER ou ROLE_ADMIN peuvent insérer de nouveaux Book
• seuls les utilisateur ayant le rôle ROLE_ADMIN peuvent créer des utilisateurs, des rôles et modifier les règles de sécurité

Si un utilisateur non authentifié tente d'accéder à une URL protégée, il sera automatiquement redirigé vers un écran de login avant d'accéder à la page désirée.

Adaptations de confort

Par défaut, une application Grails utilise HSQLDB et démarre avec une base vierge à chaque lancement. Nous allons donc changer cela pour intégrer directement à chaque démarrage les rôles, mappings de sécurité et un compte administrateur :

grails-app/conf/BootStrap.groovy

Voilà, au prochain démarrage nous retrouverons toutes nos chères données directement en base. Ensuite, nous pouvons nous attaquer à l'enregistrement des internautes en tant qu'utilisateur standard. Par défaut, le formulaire lié au RegisterController crée des utilisateurs sans rôle, ce qui ne nous convient pas du tout. De plus, comme il serait agréable pour les nouveaux utilisateurs de recevoir un mail de confirmation de leur inscription, on va le mettre en place dans la foulée :

grails-app/conf/SecurityConfig.groovy

Avec ces modifications, tous les internautes qui créeront des comptes par le formulaire obtiendrons le rôle ROLE_USER et recevront un mail comme ceci :

Si vous souhaitez adapter un peu le format du mail, le code associé est situé vers la ligne 170 du code de RegisterController :

extrait de grails-app/controllers/RegisterController.groovy

Et voilà comment en quelques minutes on peut avoir une application, basique certes... mais sécurisée !

Pour aller plus loin

Le plugin Grails Spring Security possède de nombreuses autres options. Je n'ai développé ici que la stratégie de stockage des règles de sécurité dans la base, mais il est également possible de les définir directement dans le fichier SecurityConfig, ou par annotations des méthodes des contrôleurs.

On peut appuyer la sécurité sur OpenID, LDAP, CAS, NTLM ou même utiliser une connexion FaceBook Connect. On peut changer l'algorithme de cryptage des mots de passe, les possibilités sont assez étendues.

Et si vraiment Spring Security ne vous convient pas, il existe d'autres solutions de sécurité à base de plugins comme Shiro ou Stark, qui feront peut-être l'objet d'autres articles dans le futur.

Conclusion

L'utilisation du plugin Grails Spring Security permet de mettre le pied à l'étrier très rapidement, en s'appuyant sur un standard des frameworks de sécurité en Java. J'ai personnellement beaucoup apprécié la simplicité de prise en main et les exemples fournis dans la documentation officielle. Je vous invite d'ailleurs à la parcourir, elle contient d'autres tutoriels notamment pour l'utilisation de OpenID et LDAP.

Nota Bene : Cet article est fortement inspiré de celui-ci, mais il méritait des précisions à mon goût.

Ressources :

• Le projet Grails
• Grails Spring Security Plugin
• Tutoriels officiels Spring Security Plugin

• Le catalogue numérique.
• Le catalogue PDF.

Xebia Training se positionne logiquement dans la continuité de Xebia, tant sur la qualité de son offre de formation technique que méthodologique (méthodes agiles), en proposant des formations haut de gamme animées uniquement par les référents de leur domaine.

Avec pour principe premier le refus de tout compromis sur la qualité du formateur et du contenu, Xebia Training fait systématiquement intervenir des acteurs de références dans leurs domaines respectifs.

Nos formations, savant équilibre entre théorie et travaux pratiques, sont destinées à un large public soucieux d’acquérir les meilleures pratiques de notre industrie.

AMQP (Advanced Message Queuing Protocol) est un protocole de messagerie créé à l'initiative de la banque JP Morgan Chase pour gérer la communication entre ses différents partenaires. Le but affiché était de fournir une solution alternative aux solutions payantes et relativement chères dans le domaine du MOM (Message-Oriented Middleware) dominé largement par Websphere MQ d'IBM et RendezVous de Tibco (93% du marché à eux deux en 2008). Un certain nombre de partenaires se sont fédérés autour de ce projet pour aboutir à une première spécification en 2006. L'ambition avouée est qu'elle devienne l'équivalent du HTTP pour l'internet, ce qui explique qu'elle décrive aussi bien les différentes sémantiques liées au MOM que la partie plus bas niveau du transport de ces messages. Cette normalisation permet la multiplication des solutions clientes ou serveurs dont la compatibilité sera garantie par cette spécification. Par exemple, un broker de message écrit en Erlang comme RabbitMQ transférera de façon transparente un message d'un client ruby vers un autre client Java/JMS.

Notez bien qu'AMQP s'identifie clairement comme un protocole et non comme une API, contrairement à JMS. Donc un client Java basé sur JMS peut, moyennant des adaptations plus ou moins coûteuses, communiquer avec un broker AMQP.

Un nouveau protocole

Les spécifications AMQP sont parties de cas d'utilisation très concrets pour aboutir à des spécifications essayant d'englober un maximum de typologies. Voici quelques unes d'entre elles (QPid ou RabbitMQ) :

• Store-and-forward: les messages sont persistés puis récupérés par un seul client qui décidera s'il faut les supprimer.
• Point-to-point: une communication dédiée entre un émetteur et un receveur, éventuellement bidirectionnelle.
• One-to-many (ou fanout): un message est retransmis à toutes les queues d'une zone d'échange. Ceci permet de modéliser le multicast.
• Transaction (distribuée ou pas): l'émetteur peut englober un paquet de messages dans une transaction, ces messages ne pourront être lus que lorsque l'émetteur les aura acquittés.
• Publish-subscribe (pub-sub): plusieurs émetteurs postent des messages en fonction de mots clés (topics) auxquels s'abonnent plusieurs receveurs.
• Content-based routing: le routage des messages est déterminé selon le contenu du message ou par une fonction externe.
• Queued file transfer: on n'envoie plus de simples messages mais des fichiers, voire tout le contenu d'un répertoire.

Ces différentes architectures se combinent bien sûr entre elles, je pense particulièrement aux transactions. Ces schémas de base un peu abstraits rejoignent des concepts ou des applications connus de tous. Un serveur de mail par exemple s'appuiera sur un "store-and-forward", un chat sur un "point-to-point" ou un streaming de fichier sur un "queued file transfer". Cette sémantique est un vrai plus pour la phase de conception d'un projet même si ensuite rien n'est figé dans la réalisation.

Derrière ces grands concepts se cachent des briques élémentaires très simples :

• Queue de message (Message Queue): zone de stockage des messages (en mémoire ou sur le disque). Elle aura les propriétés privée/partagée, durable/transitoire, permanente/temporaire.
• Zone d'échange (Exchange): l'entité qui accepte les messages et les route vers les queues de messages. Les critères de routage peuvent se faire de plusieurs façons (inspection du contenu, du header, clés de routage...). Les zones d'échange peuvent être créées dynamiquement par les applications clientes.
• Zone virtuelle (Virtual Zone): ce concept est copié de celui des serveurs HTTP d'Apache. Cette zone crée un espace contenant différentes zones d'échange et de queues de message complètement étanches aux autres zones virtuelles. Donc une connexion au serveur ne pourra être associée qu'à une zone virtuelle. C'est très utile lorsqu'on veut mutualiser les ressources.

Pour le routage, la zone d'échange pourra implémenter différents algorithmes :

• Direct: la clé de routage correspond exactement à l'adresse de la queue.
• Topic: la clé de routage correspond à un certain pattern (une expression régulière) de l'adresse de la queue.
• Routage par le header: analyse une table clé/valeur pour décider vers quelle queue aller.
• Système : appel à un service externe.

De même les queues de message peuvent avoir des typologies assez variées: durables après un redémarrage de serveur, auto-suppression si plus utilisées, dépendant d'un souscripteur, partagées par plusieurs souscripteurs, répondant à un message particulier...

La gestion des transactions et des transactions distribuées est également spécifiée. Un message envoyé à l'intérieur d'une transaction ne sera récupéré par les souscripteurs qu'à partir du moment où l'émetteur acquittera la transaction. Cependant, cette gestion peut varier selon l'implémentation des serveurs car lors d'un rollback, seules les commandes de l'émetteur sont dépilées. Certains états du serveur peuvent donc être modifiés malgré tout (par exemple la déclaration d'une nouvelle queue de message).

Solutions existantes :

RabbitMQ (Mozilla Public License) est sans doute le broker AMQP le plus connu. Il est basé sur le langage Erlang et ses librairies OTP, développé par Ericsson et réputé pour sa haute-disponibilité et sa tolérance aux pannes (règle des "nine nines" : 99.9999999% de disponibilité !). Au-delà de sa maturité, le point fort de ce produit est sa volonté de faciliter son intégration dans les systèmes existants. Par exemple, des distributions dédiées à Amazon EC2, avec intégration à EBS, sont proposées. La gestion du cluster est également très simple, en une commande on peut rattacher un broker à un autre. Toutes les zones d'échange, les queues de message ou les zones virtuelles seront alors partagées et répliquées. Côté client, une API Java est incluse dans la distribution, très simple et proche de l'API JMS. La communication avec un client JMS est possible grâce à une librairie proposée par OpenAMQ.

OpenAMQ propose lui-même un broker. Développé par iMatix, en C++, une API (WireAPI) est proposée. Sans doute plus complexe à appréhender, un effort particulier a néanmoins été apporté aux outils de développement (débogage, constructions de test...) et de monitoring (log, tuning...). Un langage XML (PAL) a été développé pour scripter des scénarios utiles pour les tests par exemple. Ou encore une console de monitoring pour serveur AMQP. Très pointu, OpenAMQ semble s'adresser à des experts confrontés à des projets soumis à de fortes contraintes. Il y a un côté un peu R&D qui permet par ailleurs de jouer un rôle moteur dans la communauté. A noter également que la distribution linux vient avec une implémentation de RestMS.

Par ailleurs OpenAMQ a fait main basse sur un autre broker AMQP : ZeroMQ. Enfin plus précisément un broker qui implémente plusieurs protocoles dont AMQP. On est ici à la limite du sujet tant cette application s'attache moins à son intégration dans une application de gestion classique qu'à construire une bête de course aux performances affichées impressionnantes (13.4 microsecondes de latence end-to-end, 4.1 millions de messages à la seconde).

Avec Qpid on revient un peu sur terre. Ce broker est incubé chez Apache et ne semble a priori rien apporter de plus que ceux cités plus haut. Il vaut malgré tout le coup de s'y intéresser pour les différents frameworks et librairies auxquels il s'intègre et en premier lieu celles d'Apache (Axis2, Camel, Synapse). Il est également intégré à la distribution de Red Hat MRG et est compatible avec l'outil de visualisation et de contrôle HermesJMS.

A noter également que le projet très en vue HornetQ de JBoss prévoit également de supporter ce protocole dans une prochaine version.

Perspectives et enjeux

Une communauté

La capacité d'AMQP à s'imposer comme un standard sera liée à sa capacité à drainer une vraie communauté autour de lui. Cette communauté se divise en deux actuellement : les membres du groupe de travail AMQP et la communauté open source.

Les membres du groupe de standardisation sont eux-mêmes divisés en trois familles : des fournisseurs de brokers AMQP (RabbitMQ, OpenAMQ...), les clients historiques (JPMorgan, Goldman Sachs...) qui poussent ces solutions et les fournisseurs de solutions matérielles (Cisco, Solace Systems Inc., Tervela Inc. ...). Ce mélange a le gros avantage de proposer d'ores et déjà des solutions implémentées et en production qui éprouvent ce standard et l'enrichissent en retour. La réalité du terrain guide largement les spécifications comme le montre leurs Business Requirements.

Du côté OpenSource par contre la communauté reste encore discrète. En faisant une recherche rapide sur internet on trouve tout de même une bonne quantité de projets, plus ou moins expérimentaux :

• RestMS pour poster des messages directement en Rest.
• amqp-js pour poster des messages en javascript.
• ici une idée pour faire du twitter avec html5.
• réplication en base de données.
• des librairies spring pour utiliser de façon transparente les brokers.

Du chemin reste encore à faire, mais la diversité des projets prouve malgré tout qu'il y a une demande.

Une version de référence

Pour l'instant la version 0.10 est la dernière version officielle. Mais la plupart des brokers sont en version 0.8 ou 0.9. En effet, tout le monde attend la vraie version de référence, la 1.0. qui devrait sortir cette année. Elle devrait apporter de gros changements : un système d'adressage inspiré des mails (queue_message@my_server), le remplacement des zones d'échanges par deux nouvelles entités (une queue d'entrée et un service d'échange), la suppression des Virtual Hosts (conséquence de la suppression des zones d'échanges), l'amélioration de la partie administration du broker et l'ajout de support pour les services DNS.

Ces gros changements apportent sûrement des améliorations majeures à ce protocole. Il n'y a plus qu'à espérer que la migration se fera rapidement. Il est difficile de dire aujourd'hui si les clients sur les versions 0.x pourront se connecter à cette nouvelle version de façon transparente, mais si ce n'est pas le cas, cela risque de casser la dynamique autour d'AMQP.

La concurrence

La lutte est assez féroce dans le domaine du MOM. Si on met de côté Websphere MQ et Tibco, il existe de nombreuses solutions, parfois assez éloignées conceptuellement.

On peut s'en douter, ActiveMQ ne reste pas les bras croisés. Ils poussent entre autre une solution générique, STOMP, très simple d'utilisation mais moins complète et moins performante. Ils annoncent aussi une compatibilité AMQP, sans qu'on sache très bien comment.

Jusqu'à un certain point, ce protocole rentre également en concurrence avec XMPP, le protocole de messagerie instantanée.

MuleMQ est apparu également sur la scène et est proposé comme broker dans la nouvelle distribution de l'ESB Mule. C'est un broker JMS fourni avec quelques outils. Le "tout-intégré" de cette solution peut être assez attirant, par contre on peut regretter que MuleSoft s'éloigne de plus en plus de l'Open Source.

Au contraire, HornetQ joue le jeu de l'Open Source et peut profiter de la grande expérience de JBoss dans ce domaine. Mais cela reste du JMS... Cela sera sûrement la solution privilégiée pour les applications tournant sur JBoss mais difficile de dire si la solution out of the box aura du succès.

Au final JMS est le vrai concurrent d'AMQP même si encore une fois les deux peuvent vivre ensemble. Un adaptateur JMS pour AMQP peut sembler intéressant pour des projets qui migrent vers un nouveau broker, mais il semble plus pertinent pour un nouveau projet de commencer directement dans ce nouveau standard. Par exemple l'utilisation de la librairie Java de RabbitMQ est vraiment très proche de l'API JMS et la vitesse d'apprentissage semble assez rapide pour un développeur Java.

Car un des problèmes de JMS c'est justement son manque d'interopérabilité avec d'autres langages. A cet égard il est intéressant de remarquer que Microsoft s'intéresse de près à AMQP. Depuis 2008 il participe au groupe de travail et a collaboré activement avec QPid pour la version C++ du broker. Etre agnostique vis-à-vis de l'environnement DotNet ou Java serait sûrement une carte majeure de ce standard.

Conclusion

Les solutions propriétaires comme IBM et Tibco ne sont pas réellement menacées par ce nouveau concurrent car leurs solutions sont très complètes, éprouvées et ils fournissent un support sérieux qui rassure les DSI. Le défi d'AMQP est moins de concurrencer ces leaders que de promouvoir l'architecture orientée message au sein de projets de taille moyenne et/ou open-source qui n'ont pas forcément un gros budget à investir. L'adoption massive de ce modèle de conception imposerait AMQP comme le protocole référent tant sa spécification est avancée et complète.

Actualité éditeurs / SSII

• Subversion devient un projet top-level Apache

Agilité

• Sortie du livre "SCRUM : Le guide pratique de la méthode agile la plus populaire"

RIA

• HTML5 + CSS3 = 52framework

Le coin de la technique

• Les nulls, c'est nul !
• G1 pas à la hauteur des espérances ?

Actualité éditeurs / SSII

Subversion devient un projet top-level Apache

Après seulement 3 mois d'incubation (mais sur le point de fêter ses 10 ans, Collabnet ayant sorti la première version en 2000), Subversion est maintenant projet top-level Apache. Pour ce faire, le projet a du se plier aux règles strictes édictées par la fondation Apache, qui touchent à la fois au code source du logiciel, à la provenance des différents codes, à leur licence, au site internet du projet, au processus de release des nouvelles versions... C'est un gros travail mais il permet ensuite aux projets de bénéficier de toute l'infrastructure ainsi que de l'aura de la fondation Apache.
Subversion s'assure donc pour la suite une stabilité et une plus grande visibilité, élargit sa communauté et s'octroit plus de crédibilité vis à vis des entreprises. En effet, être projet top-level Apache est gage de pérennité.
Le projet en aura besoin, étant fortement concurrencé par les outils de gestion de version distribués comme Git ou Mercurial. Martin Fowler notait ainsi récemment plusieurs points négatifs de SVN :

• l'absence de copie locale du repository d'où des problèmes de performance et l'impossibilité de travailler offline sur ce repository.
• le fait que les branches aient une visibilité globale est un frein à l'innovation: les développeurs sont moins enclins à créer une branche pour expérimenter diverses innovations.

Néanmoins, SVN reste pour lui le meilleur des outils non distribué, et est largement recommandable. D'autant que c'est un outil plus simple à appréhender et son ancienneté fait que les bonnes pratiques sont largement répandues. D'autre part, ajoutons que les développeurs semblent ne pas se reposer sur leurs récents lauriers, et annoncent la disponibilité dans la version 1.7 de la fonctionnalité de offline commit. Comme d'habitude, nous bénéficions encore de la concurrence pour avoir à notre disposition les meilleurs outils. Chouette !

Agilité

Sortie du livre "SCRUM : Le guide pratique de la méthode agile la plus populaire"

Claude Aubry, auteur du bien connu blog Scrum, Agilité et Rock'n roll nous délivre dans ce livre un condensé de son expérience sur la mise en place de Scrum. Très pragmatique, ce livre traite point par point les différentes composantes de Scrum en les expliquant et en détaillant pour chacune les pratiques qui fonctionnent et celles à ne pas tenter. Après avoir dévoré les 5 premiers chapitres nous ne pouvons que vous engager à lire cet ouvrage qui fera office de référence pour vous accompagner sur vos projets Scrum.
C'est comme d'avoir un peu de Claude Aubry avec soi sur son projet, mais sans l'accent

RIA

HTML5 + CSS3 = 52framework

Même si c'est en très bonne voie, les navigateurs Web du marché ne sont pas entièrement compatibles HTML5 et CSS3. Néanmoins, plusieurs librairies JavaScript permettent de rendre votre navigateur 100% compatible avec ces 2 technologies et 52framework en fait partie.

Au menu, la librairie nous propose d'utiliser les différentes nouvelles balises HTML5 telles que aside, nav, section ou bien encore article. Les nouveaux input type='email' et input type='url' sont aussi de la partie. La balise script contenant du JavaScript n'a plus besoin de l'attribut type='text/javascript'. Côté CSS3, il est possible d'utiliser les coins arrondis, les text-shadow et les box-shadow.
La démo se trouve ici, le plus intéressant étant son code source où l'on retrouve les nouveaux éléments cités ci-dessus.

Pour le téléchargement, rendez-vous est pris sur le Google Code du projet section Downloads.

Le coin de la technique

Les nulls, c'est nul !

C'est en tout cas ce que beaucoup d'entre nous ressentent en tombant sur certaines NullPointerExceptions. Et suivent les premières questions : Où sont les tests unitaires ? Quel paramètre n'a pas été testé ? Mais, ressenti de plus en plus grandissant avec les derniers langages alternatifs pour la JVM, pourquoi laisser passer des valeurs nulls en paramètre ?

Pour ne prendre qu'un seul exemple, Scala permet d'éviter ce genre de désagrément grâce à la classe Option (Avoid using nulls in Scala). Dans le cas d'une valeur définie, il suffit d'utiliser Some(something) qui est l'option avec valeur. Et pour le null, il faudra se tourner vers None qui est l'option sans valeur. Le code est ainsi réduit et ne contient plus de test if(obj !=null) (englobé dans l'option None) :

Mais pour Java ? Une petite piqure de rappel ne faisant pas de mal, cet article nous présente une solution possible avec en citation Martin Fowler et le pattern Special Case.

L'idée est la même que pour l'option Scala. On commence par définir une classe abstraite ou une interface avec une méthode spécifique qui sera appelée par notre code. Et de là seront créés 2 objets : un objet réel et un objet null. Ce dernier implémentera la méthode demandée mais ne fera rien alors que l'objet réel exécutera son code métier. Ainsi, plus de test de nullité, notre code lancera directement la méthode sur l'objet et ne se souciera plus de savoir si l'objet est null ou non.

Ce pattern anti NPE est une solution possible mais elle n'est pas la seule. Si vous avez suivi l'actualité, vous êtes malheureusement au courant que les operateurs null-safe et elvis ne seront pas implémentés par l'ambitieux Project Coin. Le sucre syntaxique ne viendra donc pas directement dans nos appels de fonctions mais par les annotations de JSR-305 dont @NonNull. Bien sûr, cette spécification a pour cible FindBugs, Intellij IDEA, Checkstyle ou bien encore PMD. On aurait préféré une intégration au Project Coin mais c'est déjà mieux que rien...

G1 pas à la hauteur des espérances ?

G1 (Garbage First) est un nouvel algorithme pour votre Garbage Collector. Il est destiné à remplacer l'implémentation par défaut lors de l'arrivée de la prochaine JVM. Celui-ci apporte un certain nombre d'avancées significatives dont des performances annoncées (quasi) compatibles avec le temps réel. Pour cela, G1 relève le défi de la maitrise des temps de pause des collections stop the world grâce à une gestion innovante de la mémoire (reposant sur beaucoup plus de 'petites' zones).

Nous n'allons pas détailler son fonctionnement ici. Si le sujet vous intéresse, nous vous encourageons à consulter l'un de nos articles sur le sujet. Il date un peu, mais son contenu reste tout à fait d'actualité : GC générationnels traditionnels (jdk6) VS GC Garbage First (jdk7).

Si les fonctionnalités de ce nouvel algorithme sont alléchantes, on retrouve ici et là quelques retours frileux suite à son usage. L'auteur de ce billet annonce des performances moins bonnes qu'avec le garbage collector par défaut lors de l'utilisation de LinkedHashMap. Faut-il s'en inquiéter pour autant ? Non ! Vu la criticité de ce genre de fonctionnalité, il est tout à fait normal que quelques ajustements soient faits lors des premiers retours d'utilisation terrain. C'est d'ailleurs le but recherché suite à l'intégration à Java 6 update 14 (via les options -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC), même s'il est vrai qu'il n'est plus flagué 'expérimental' depuis peu sur les derniers build du jdk 7.

En revanche, en plus de la mise en doute des performances de G1 relayée sur le internet, nous pensons qu'un élément bloque effectivement son adoption en production : le monitoring. Celui-ci est aujourd'hui insuffisant, ni jstat ni VisualGC ne remontent d'informations comme le montrent les captures d'écran ci-dessous.

jstat et VisualGC ne sont pas encore prêts pour G1

$ jstat -gccause 30572 5s
Warning: Unresolved Symbol: sun.gc.generation.0.space.1.capacity substituted NaN
Warning: Unresolved Symbol: sun.gc.generation.0.space.1.used substituted NaN
...
Warning: Unresolved Symbol: sun.gc.collector.0.invocations substituted NaN
Warning: Unresolved Symbol: sun.gc.collector.0.time substituted NaN
...
S0 S1 E O P YGC YGCT FGC FGCT GCT LGCC GCC
? ? ? ? 79.96 ? ? ? ? ? unknown GCCause No GC
? ? ? ? 79.96 ? ? ? ? ? unknown GCCause No GC