Le voilà enfin,  le nouveau langage web  révolutionnaire, la fin des problèmes de compatibilité entre les navigateurs, la solution à tous nos soucis de développeur web. Bon, ce que je viens d’écrire est peut-être un peu trop optimiste… Certes, HTML 5 a pour objectif de standardiser les technologies du web mais il ne faut pas rêver,  ce ne sera pas, ou plutôt,  cela ne semble pas être la solution miracle.

<Intro>

Si vous ne le savez pas encore, HTML 5, comme le présuppose son nom, est la nouvelle version de HTML après HTML 4.1. Cette évolution de l’HyperText Markup Language se veut être à la fois un regroupement de bonnes pratiques observées depuis plusieurs années sur la toile et dans les entreprises mais aussi un regroupement de nouvelles fonctionnalités qui faisaient défaut. Initiées au départ, par les trois géants du web que sont Apple, Google et Mozilla au sein du Web Hypertext Application Technology Working Group (WHATWG), ces spécifications ont été ensuite reprises par le W3C pour être normalisées.

HTML 5 a aussi pour ambition de simplifier son utilisation qui s’est complexifiée avec le temps. Prenons pour exemple, la déclaration de certaines balises qui a été réduite au strict minimum. La déclaration du doctype devient très simple. La déclaration des scripts JS inline devient implicite.

L’implémentation de nombreux types de validations client comme la validation d’une chaine de caractères (email, code postal, numéro de téléphone…) est facilitée par l’utilisation d’attributs natifs.

La réalisation d’effets graphiques simples tels que, les coins arrondis, les ombres (de texte ou de boite) ou les dégradés de couleur deviennent natifs en CSS 3 (avec malheureusement encore quelques variations entre les différents navigateurs…).

<ASP.NET MVC>

The right way for HTML 5 !

HTML 5 arrive avec son lot de bonnes nouvelles et nous devons, en tant que modestes développeurs ASP.NET, être prêts à l’accueillir. Pour celles et ceux qui n’auraient pas encore mis leur nez dans l’implémentation du pattern MVC en ASP.NET, c’est le moment.

A mon sens, pour faire du HTML 5, il faut oublier les contrôles ASP.NET standards, produisant du code HTML plus que perfectible. Il faut désormais se tourner vers ASP.NET MVC qui permet d’avoir la maitrise totale du code HTML final. Fini les gros Datagrid très pratiques générant un code HTML lourd. Le développeur revient aux fondamentaux du développement web et doit recoder son beau tableau à la main mais avec beaucoup plus d’API qu’avant, simplifiant ainsi son implémentation. Le résultat est un code HTML plus propre, plus léger pour transiter sur les réseaux et facilement maintenable pour les éventuels intégrateurs. Le passage à HTML 5 se fait alors naturellement.

Des frameworks déjà disponibles, fournissent des méthodes évitant aux développeurs de réinventer la roue. Ils permettent notamment de simplifier l’accès aux éléments des pages, la gestion des évènements, la communication avec le serveur…

<Limitations>

HTML 5 en ASP.NET est donc bien possible mais jusqu’où ? Il est aisé de dire « Mon application est en HTML 5 » en ajoutant simplement le doctype qui correspond, mais l’est-elle vraiment ?

Les principaux acteurs du web se sont incontestablement associés pour définir les standards de cette nouvelle mouture mais, malheureusement, ils ne s’accordent toujours pas sur l’ensemble des aspects de la spécification. L’exemple frappant reste celui de la prise en compte des formats vidéo. Chacun voudrait que son standard vidéo soit celui retenu dans la spécification et cela donne un grand n’importe quoi. Pour le moment, pas de réel changement par rapport à la version précédente d’HTML, le format vidéo supporté dépend du navigateur. Pour être cross navigateur, il faudra prévoir une version de la vidéo pour chaque format existant. Quel dommage pour une spécification qui se veut être une standardisation ?!

Certaines implémentations de HTML 5 ne sont pas encore disponibles pour toutes les plateformes. En effet, parmi les évolutions apportées par cette nouvelle version du langage, l’implémentation des flux duplex via les web sockets n’est pas entièrement prise en charge par la plateforme .NET. Si la partie cliente dépend uniquement du navigateur, la partie serveur a aussi un rôle à jouer.  Or, le serveur IIS ne supporte pas encore le protocole web sockets. Pour le moment, seuls quelques serveurs d’application les supportent, tels que Jetty et Node JS (le serveur en Javascript). Il n’est donc pas possible d’utiliser cette évolution avec une plateforme full .NET. Il faudra attendre la plateforme Windows 8 avec IIS 8 et ASP.NET 4.5.

<Applications>

Pour résumer, HTML 5 est déjà là. Plus ou moins terminé, plus ou moins standard entre les navigateurs et les plateformes. Mais attention, si certaines fonctionnalités sont déjà présentes, la spécification n’étant pas finalisée, celles-ci peuvent être modifiées !

Donc, pour savoir dans quels cas il faut se lancer dans l’aventure HTML 5 et dans quels cas il vaut mieux l’éviter, il faut se poser les bonnes questions. Il faut commencer par identifier le type de l’application concernée et les utilisateurs finaux de cette application.

Si l’application est un site grand public, on veillera à bien étudier les nouvelles fonctionnalités que l’on souhaite utiliser sur le site. Cette fonction est-elle implémentée sur tous les navigateurs ? Y a-t-il un risque que l’implémentation change avant la fin de l’élaboration des spécifications ? (Et bien sûr, cette fonctionnalité est-elle bien adaptée à tous les visiteurs ?)

Si l’application est une application intranet, le scope des utilisateurs finaux est plus réduit et le nombre de navigateurs utilisés est souvent limité. On peut donc choisir d’utiliser telles ou telles nouvelles fonctionnalités du langage en ciblant les navigateurs. En entreprise, il est aussi possible de les imposer ce qui réduit encore l’éventail des navigateurs clients.

<Conclusion>

Au final, HTML 5 apporte un réel plus dans l’implémentation des applications web mais il faut prendre garde car les spécifications ne sont pas encore terminées. La version finale est prévue pour cette année mais rien ne dit que cette version sera conforme à ce qui est déjà écrit.  En attendant, tous les grands acteurs du web s’y préparent et Microsoft sera évidemment au rendez-vous.

Une application web fonctionnant sans connexion réseau et capable de sauvegarder les données de l’utilisateur, quelle drôle d’idée ? Grâce à HTML 5 se sera pourtant bientôt possible !

Mercredi 8 février 2012, je me suis rendu aux MS TechDays 2012 dans le but d’assister à une présentation répondant au nom de « Création d’une application HTML5 gérant l’offline et le stockage client » afin d’en savoir un peu plus sur le sujet.

L’objectif de cette présentation était de découvrir quatre briques importantes d’HTML 5 : « le mode offline », « le DOM storage », « l’Indexed DB » et « le drag & drop ».

Les deux intervenants Microsoft que sont David Rousset, responsable de la relation avec les développeurs Web,  et David Catuhe, spécialiste interface utilisateur, ont commencé la session par une démonstration de SnapX, une application de gestion de diaporamas sur laquelle a été basée toute la présentation. SnapX est entièrement développée en HTML 5.

David Rousset a alors présenté le mode Offline permettant l’utilisation d’une application web sans connectivité réseau permanente. Le principe est le suivant : L’application est téléchargée par le navigateur comme une simple application web à la différence que celle-ci indique au navigateur la liste exhaustive des fichiers nécessaires à son fonctionnement en mode hors ligne. Tout ceci grâce à la définition d’un fichier « manifest » dans lequel on précise, les ressources hors ligne, les ressources en ligne et les ressources à utiliser en cas d’erreurs.

L’application SnapX, est utilisable en mode hors ligne grâce à cette technique mais elle permet aussi l’import de fichiers images ainsi que leurs manipulations et leurs sauvegardes, normal me direz-vous pour un diaporama… David Catuhe nous a alors décrit les méthodes utilisées pour permettre ces fonctionnalités en passant par la manipulation des fichiers grâce à la « File API » et la brique « DOM storage » qui permet de sauvegarder jusqu’à 10 Mo de données sur le poste client. Cette nouvelle brique qui permet d’outrepasser les limites des cookies, embarque deux objets que sont le localStorage (données partagées pour une application) et le sessionStorage (données de session uniquement).

Pour aller un peu plus loin dans la sauvegarde des données utilisateurs en local, la présentation s’est ensuite orientée sur la brique IndexedDB fournie par HTML5. Véritable base de données NoSQL, elle permet de stocker des objets Javascript (typiquement des objets JSON) et est totalement sécurisée (les bases de données d’une application sont liées au domaine). Il n’y a pour le moment pas de limitation sur la quantité de données et celle-ci varie selon les navigateurs. Nos intervenants lors de cette session nous ont laissé penser qu’une forme de limitation sera mise en place avec validation par l’utilisateur lorsque la spécification sera finalisée. Petit plus de la présentation, ils nous ont indiqué une ressource très intéressante permettant d’afficher le contenu de l’IndexedDB (aller sur http://blogs.msdn.com/b/ie/archive/2012/01/25/debugging-indexeddb-applications.aspx)… pratique pour débuguer !

Cette session s’est enfin terminée par une présentation de la brique « Drag & Drop », une fonctionnalité déjà possible avec les frameworks Javascript (jQuery…) existant mais devenue native avec HTML5. Rentrée dans les mœurs des utilisateurs, cette fonctionnalité offre la possibilité d’améliorer l’ergonomie des applications en simplifiant les interactions entre le bureau et le navigateur web.

Ces présentations sont aussi l’occasion de récupérer des bonnes pratiques ou des astuces que l’on ne trouve pas partout. J’en ai retenues deux :

- La spécification n’étant pas encore terminée, les implémentations des API instables sont systématiquement préfixées en fonction de l’organisme qui les a implémentées. Ainsi, l’implémentation de IndexedDB sur IE sera windows.MsIndexedDB, sur FireFox windows.MozIndexedDB, etc.

- Pour savoir si un navigateur implémente une fonctionnalité, il faut tester l’existence ce cette fonctionnalité et non la version du navigateur.

Pour aller plus loin :

http://www.caniuse.com (liste les fonctionnalités HTML5 disponibles en fonction des navigateurs)

http://www.catuhe.com

http://blogs.msdn.com/b/ie/ (IE team Blog)

Quand les Tontons Flexeurs – communauté Flex française – organisent une soirée, j’essaie autant que faire se peut d’y aller. Quand en plus, l’actualité Flex est à ce point mouvementée que Michaël Chaize est de la partie et que l’invitation mentionne “pizzas/bières”, je ne pouvais vraiment pas ne pas en être!

C’était donc hier soir, à la Cantine, avec pour objectif de faire une grande remise à plat des évènements qui ont bouleversé le monde Flex ces dernières semaines.

C’était surtout l’occasion de parler de la grosse erreur (que dis-je, du “cataclysme”) de communication de la part de la direction d’Adobe (voir le fameux article du 9 novembre), à savoir l’annonce de l’arrêt du support du Flash Player sur mobile, et la réorientation stratégique vers HTML5. Et bien sûr panser les blessures de la communauté Flex en regagnant la confiance de tout ce petit monde…

Explications.

Flex is D43D

Après une introduction de Yann Chevalier (leader de la communauté TTFX), Michaël Chaize prend la parole et nous rassure tout de suite :

• Flex n’est pas mort, aucun changement pour les applications côté desktop : ni côté Flash Player embarqué dans les navigateurs, ni côté AIR,
• Seul le support de Flash pour le mobile est arrêté, c’est à dire que seuls les tablettes/smartphones Android sont impactés, mais Android4 ICS sera la dernière mouture embarquant un player Flash,
• Les applications Flex mobile “natives” (tournant sur AIR donc) sont plus que jamais d’actualité, et deviennent même le fer de lance de la technologie Flash/Flex

En clair, Apple a gagné le match, possédant 95% du marché des tablettes (le vrai marché visé par les sites web “riches”) et refusant d’accueillir le player Flash. Adobe capitule donc et stoppe sa R&D autour de ces nouvelles plateformes, en argumentant que se focaliser des années sur les quelques pourcents laissé par Apple  à ses concurrents est une cause perdue…

Néanmoins, Adobe laisse libre cours aux éditeurs d’OS mobile pour continuer à investir s’ils le désirent sur cette technologie. C’est ainsi qu’au lendemain de l’annonce d’Adobe, RIM a répondu immédiatement que leur implémentation de Flash Player sur leurs Blackberry PlayBook actuelles et à venir était maintenue ! Et c’est certainement une bonne stratégie, s’ils veulent conserver un argument de vente contre l’iPad, et grignoter des parts de marché côté tablettes.

Passage par la fondation Apache

Le gros tollé de la semaine dernière c’était donc le “don” de “Flex” à la fondation Apache. Pour Michaël Chaize, c’est une des meilleures choses qui pouvait arriver à Flex, qui plutôt que de tomber dans l’oubli (ou dans un carton perdu chez Adobe) va être aux mains de la communauté, va pouvoir évoluer, et une version 5 du SDK serait en préparation, la première version sous l’étiquette Apache.

Au passage, Flex SDK étant d’ores et déjà open source, son passage chez la fondation Apache serait uniquement un changement de gouvernance, et serait (toujours selon nos interlocuteurs) un grand bien pour notre techno adorée !

Mais en quoi consiste ce don ?
Bien plus que le SDK, c’était l’occasion de happer d’autres projets d’Adobe vers de l’open source, notamment :

• Flex SDK donc,
• les composants Flex 5 déjà réalisés par Adobe,
• Flacon, compilateur Flex 10 fois plus rapide et “temps réel” (valide/highlight le code pendant la saisie, et devait être réservé à FlashBuilder)
• FalconJS, projet expérimental, mais déjà assez avancé de cross compilation Flex (AS3) vers HTML/Javascript (c’était un projet jusqu’alors secret)
• BlazeDS

Ca sera donc l’occasion de faire évoluer plus rapidement et de mutualiser les évolutions/branches de ces produits réalisées par la communauté de flexeurs.

Pourquoi Flex ?

Selon Yann et Michaël, la fin de Flex ce n’est donc pas pour tout de suite. Surtout avec l’engouement des développeurs de jeux pour Flash, l’écosystème Facebook et ses applications en Flash, et la possibilité (unique !) de déployer une application Flex indépendamment sur iOS / Android ou Playbook… Et surtout, quel plaisir de travailler avec ce genre de technologie RIA, quand on voit l’état actuel du marché concernant HTML5, son outillage, son architecture pas vraiment adaptée “composants” etc…

Pour illustrer cela, la semaine dernière, à la Devoxx 2011, à la question “quel IDE et outils de développement utilisez-vous pour concevoir vos jeux en HTML5 ?”, James Williams qui a écrit un livre sur la question, répondait sans honte qu’il utilisait “vim voire emacs pour faire du HTML5, sans tests unitaires ni industrialisation, etc…”. HTML5 ne serait pas encore prêt pour des développements de grande envergure et en équipe… mais tout devrait bien sûr changer dans les années à venir !

D’après Michaël Chaize, le marché est en pleine expansion, Adobe a une carte à jouer et ne va pas rater le coche de l’HTML5 (voir Edge d’Adobe), mais la techno ne serait pas encore prête pour concurrencer/rattraper Flex et son écosystème pour le développement de RIA avant 4 ou 5 ans. Et, nous dit-il, “on ne sait pas non plus comment Flex aura évolué d’ici là”. Dans tous les cas, si transition il y a, la communauté Flex l’aura préparée, et sera la première armée pour ce genre de développement.
D’autant plus que le “Write once Deploy Everywhere” de Flex mobile semble inspirer Adobe qui a expérimenté avec FalconJS la traduction AS3 vers Javascript… pourquoi ne pas imaginer à moyen terme développer toutes nos RIA en Flex, et choisir au déploiement la plateforme cible Flash, HTML5, iOS, etc… ?

Flex et son système de description par composant serait la seule solution puissante pour du développement de RIA, et HTML5 n’y serait pas encore adapté ? C’est ce qu’on nous dit !

Seul le domaine des bannières de pub serait la branche amenée à disparaitre à moyen terme selon Adobe.

Et pour la suite…

Côté annonces, il va surtout y avoir la sortie d’un FlashBuilder 4.6, des nouvelles versions de AIR incorporant des capacités 3D très poussées.

La soirée se termine par des questions réponses, toutes plus passionnées les unes que les autres. La communauté est bien là et s’inquiète pour sa technologie préférée.

Nos deux compères nous susurrent que de grands succès et grandes annonces sont à venir, et vont dissiper ce brouhaha médiatique qui s’est emparé de l’information. D’ici le début de l’année prochaine, la situation devrait être stabilisée… Et ils insistent : nous ne devrions pas être déçus par ce qui se prépare !

Avec les collègues, nous avons fini la soirée à une terrasse chauffée non loin du lieu de la soirée, avec Michaël Chaize en Guest Star… et décidément, il est vraiment très sympa !

To be continued…

Du moins pour mon collègue Mehdi Ben Haj Abbes et moi-même, l’aventure de la plus grosse conférence Java de nos contrées européennes s’est terminée mardi dernier, après deux longues journées remplies (à ras bord, mais qui se plaindra?) de conférences en tous genres. Précisément, lors de ces deux premiers jours à la Devoxx 2011, nous avions accès à deux formats de meeting :
- des “University“: ce sont de grosses sessions de 3h, dont le but avoué est d’entrer le plus en profondeur possible dans un sujet nouveau (du moins un sujet à la mode),
- des “Tools in Action” de 30 minutes chacun où, comme le nom l’indique, les speakers vont parler de leurs outils préférés développés autour de l’écosystème Java (du genre Sonar, Mylyn, jclouds, Jenkins, et d’autres noms farfelus dont certains m’étaient inconnus)

Chaque créneau horaire s’articulant autour de 4 salles de cinéma géantes et tout confort (j’entends par là, des salles de cinémas de province), le choix avant chaque session fut souvent cornélien… avec parfois quelques regrets, comme lorsque je me suis lancé naïvement dans une session de 3h, barbante au bout de 20 minutes. Heureusement dans ce cas là, à la Devoxx il est toujours possible de se lever et changer de salle! Car oui, à la Devoxx 2011, les show n’étaient pas tous du même niveau !

Je vais vous faire pour ma part un debriefing “à chaud” (du moins écrit à chaud…) des sessions que j’ai pu couvrir durant ces 48h intenses d’informations Javaesques. De quoi avoir un aperçu du quart des sujets sur ces deux jours.

Je publierai cet article sur deux billets blog distincts, pour des raisons de place et de format.

University : “Building Next-generation Enterprise Applications in Java a.k.a. Duke’s Duct Tape Adventures”.

(lien résumé officiel Devoxx, speakers : Bert Ertman et Paul Bakker)

Grosse session pure Java EE 6, tenue par deux speakers un peu déjantés (très bien pour commencer une journée après un réveil avant 7h du matin…).

L’idée c’est de voir ce que met à notre disposition la stack Java EE 6 et son CDI (la JSR299 pour les intimes) pour le développement d’applications “d’entreprise”, dans un contexte où le framework Spring semble être LA solution communément choisie.
Concrètement, l’university s’est déroulée comme les “shows à l’américaine” en vogue sur le sujet, à savoir : un couple fonctionnel-”codeur exécutant” (mais attention, ultra performant dans ses exécutions !), un peu l’analogie du good cop / bad cop des séries du genre. Le fonctionnel formule des requêtes un peu “surréalistes” (exemple: “d’accord, c’est bien ce que tu as fait comme application, mais je viens d’être contacté par Amazon, on doit absolument leur fournir une API REST, tu as 4 minutes !“) que bien sur notre développeur survitaminé semble exaucer sans sourciller, ou presque, mais ça, c’est l’effet démo.

C’est l’occasion pour moi de voir la magie de Forge (de JBoss) en action. Car bien évidemment le duo part d’une copie vierge (c’est à dire un MySQL, un serveur Glassfish, un JBoss, Maven et un IDE Intellj IDEA), et va nous réaliser en l’espace de quelques minutes un chef-d’oeuvre d’application CRUD déployable indépendamment sur Glassfish ou autre (quoique le “autre” n’a pas réussi à être démontré en… démo) avec UI en JSF 2. Je ne détaille pas davantage Forge pour l’instant (c’est un outil de RAD : Rapid Development Applications) car j’aurai l’occasion d’en reparler ultérieurement.

On passe donc en revue les étapes de création d’une application d’entreprise “légère”, avec dans l’ordre d’apparition :

• pages JSF qui attaquent la couche de navigation avec gestion de conversations (dans l’exemple, le cas d’un “panier” web)
• cette couche appelle les services métiers
• la couche métier va persister nos entitées ejb avec JPA et faire les requêtes à l’aide de l’API Criteria
• des tests d’intégration sont mis en place très rapidement avec Arquillian (et merci encore à Forge)
• on nous montre la validation de formulaire avec Hibernate-validation (implémentation de référence de la JSR303 embarquée dans la stack Java EE 6, mais qui ajoute quelques possibilités comme la validation des e-mails)
• c’est ensuite le moment de nous montrer comment faire communiquer les beans Java entre eux à l’aide d’event et de listeners pour découpler les traitements entre services (ils nous donnent l’exemple de services d’envoi de SMS)
• logiquement vient ensuite un court laïus sur le scheduling et les batchs tellement simples à mettre en oeuvre qu’on se demande pourquoi on n’en fait pas tous les jours
• dans la même veine, vient le chapitre sur le messaging et le système de souscription/topic tout aussi simple avec ce sixième opus de Java EE
• on expose ensuite nos services en REST (et en 4 minutes donc)
• la présentation se termine sur le déploiement de l’application sur serveur JBoss (FAIL donc) et même dans le cloud avec OpenShift (Double FAIL pour l’occasion et pour terminer la session…)

Voilà donc pour conclure une session très intéressante, mais avec beaucoup de redites si vous aviez déjà pratiqué un tant soit peu JavaEE et sa 6ème mouture. C’était aussi l’occasion de vérifier que tout bon geek frustré va placer des “babes” dans un slide sur deux, et dans toutes leurs démos ! L’avantage, c’est que ça donne des photos… pas banales. Jugez sur pièces.

University : “Intro to HTML5 Game Development”.

(lien résumé officiel Devoxx, speaker : James Williams)

Voilà surement ma grosse déception de la Devoxx 2011. Le mot est lâché. Je m’explique….
Fanatique depuis tout petit de jeu vidéo (10 ans : “je veux faire de l’informatique, comme ça je pourrai faire mes jeux vidéos”, 15 ans plus tard : “alors c’est une application pour vendre des tongs et des slips de bain sur l’internet convivial”…) je n’ai pas été insensible au titre accrocheur de cette session.
Si l’on ajoute qu’en plus j’essaie d’être attentif à ce qui se trame du côté d’HTML5 mais sans jamais avoir le temps de m’y mettre, je dois avouer que j’étais franchement séduit par l’idée de mêler l’utile à l’agréable. D’ailleurs, je ne devais pas être le seul : oui, la salle était pleine à craquer, plus encore que pour les autres conférences.
Nous avons donc eu droit à un étalage des spécifications d’HTML5 avec mini-exemples (comprendre 3 lignes de codes hors contexte) à l’appui.
En vrac, nous avons tout d’abord vu :

• ce qu’est le cache applicatif et sa gestion via le fichier Manifest,
• le concept de “workers” javascript et les échanges de messages avec la page hôte,
• l’existence de websockets qui seraient le TCP des applications habituelles,
• le support de WebSQL dans HTML5 (apparemment un SQLite-Like sur lequel tout le monde ne s’est pas encore mis d’accord),
• la possibilité d’attaquer de manière transactionnelle des DB indexées type NoSQL,
• le stockage de données côté navigateur.

Une fois ce tour “technique” du propriétaire, nous avons eu droit à une énorme quantité de slides concernant l’aspect “Game” de la conférence à savoir :

• comment lancer 2 sources audio en même temps, lire une vidéo,
• le système d’animations,
• le Canvas2D pour le dessin et toutes les techniques de dessin possibles et inimaginables,
• toutes les manières de transformer un canvas, d’afficher une image, la manipulation au niveau pixel des images,
• Tridens.js pour l’animation avec “timeline” et des “easing functions”,
• Raphael.js pour créer des scènes avec des SVG (Scalable Vector Graphics), et permettrait aussi des “easing functions”, le support de “gestures” avec la souris, etc…
• Three.js pour faire du rendu de scene 3D WebGL (basé sur OpenGL) et toutes ses possibilités (gestion de caméras, de lumières, de meshes/shadings/materials… etc), la syntaxe de GLSL (type C) pour l’écriture de pixel et vertex shaders, l’application de textures, le chargement de modèles 3D, les animations (keyframes, cinématique inversée et tout le toutim…)
• Stats.js pour le debugging et le suivi du framerate / performance de l’application

On nous a ensuite détaillé les différentes possibilités de déploiement de nos applications et les business modèles en concurrence. PhoneGap et le rachat de Nitobi par Adobe sont mentionnés. Peut-être la partie la plus intéressante de la conférence…

Le show s’est ensuite terminé prématurément, n’ayant duré que 2h au lieu des 3 prévues, et laissant place à des échanges de questions/réponses… ce qui m’a laissé un peu de temps pour profiter de la fin d’une autre university.

En conclusion, c’était plus un listing des possibilités d’HTML5 qu’une entrée en matière. Pas de vrai démonstration ni de conseils pour se lancer/savoir par où commencer. J’attendais beaucoup de cette session, qu’elle soit moins linéaire et un minimum interactive, et j’ai d’autant plus été déçu.

Tools in action : “Spring Data JPA – Repositories done right”.

(lien résumé officiel Devoxx, speaker : Oliver Gierke)

Je ne vais pas parler de cette partie car Mehdi s’occupe de nous rédiger un bel article sur le sujet !
Je passe donc mon tour.

Tools in action : “Forge new Ground in Rapid Enterprise Java Development”.

(lien résumé officiel Devoxx, speakers : Lincoln Baxter III et Dan Allen)

Vient ensuite la présentation de l’outil Forge de Jboss. Peut être une des plus impressionnantes présentations de ces deux jours.
A la fois concise, poussée et ludique, cette session nous a permis de voir toute la puissance de Forge en action. Si j’avais pour ma part une petite idée de ce que propose cet outil, rien ne vaut une belle démonstration pour être parfaitement bluffé!
On débute avec un environnement Eclipse et le plugin Forge installé. Première impression de ce plugin : c’est bien intégré et vraiment plus pratique qu’une fenêtre en ligne de commande ouverte.
Concrètement, en quelques commandes, apparait une application type CRUD avec JSF 2.0, une base de données embarquée et un support de REST, le tout avec la configuration Maven adéquate. Forge nous permet non seulement de créer des entités JPA, mais aussi de les manipuler, leur rajouter des champs, etc… Des tests sont créés avec la même simplicité.
On nous apprend rapidement comment utiliser des plugins pour forge, mais aussi comment en créer et définir nos commandes.
Une session très intense de 30 minutes !

Tools in action : “Code Review with Git and Gerrit”.

(lien résumé officiel Devoxx, speakers : Chris Aniszczyk and Matthias Sohn)

Pour finir la journée, un “Tools in Action” un peu plus orienté méthodologie. En effet, après un bref descriptif du fameux Git qui va (tarde à?) remplacer nos vieux SVN (voire CVS pour les nostalgiques), après avoir vanté ses mérites  et avoir listé les grands projets qui l’utilisent, on nous parle de Gerrit. Mais qu’est-ce donc ?

Gerrit, c’est simplement un serveur Git, et c’est l’outil miracle pour “enfin” réussir à faire adopter les bonnes pratiques agiles à une équipe de développement. Oui, je parle bien de ces plans d’actions qu’on tente d’établir de sprint en sprint, où l’on répète que le pair programming, la revue de code et les tests sont des axes d’amélioration. Ces utopies annoncées à chaque rétrospectives… mais qui, une fois le sprint lancé, sont si dures à tenir pour toute l’équipe qui garde son nez dans le guidon.

Voilà donc Gerrit. Gerrit va nous prendre par la main, et nous apprendre un workflow agile de développement. Le pair programming, la revue de code, les tests et la validation des commits seront enfin inscrits dans un processus cadré. De concert avec Git, Gerrit, avec son système de commentaires sur les commits, de visualisation des commits (type Fisheye) et surtout le mécanisme de vote sur les commits des autres développeurs, va nous permettre de ne pousser sur la branche commune que des évolutions validées par des collègues. Chaque développeur va ainsi faire de la revue de code, s’impliquer dans celle-ci, apprendre et s’autoformer éventuellement, intéragir avec le développeur/commiteur et échanger avec lui sur ses lignes de code. Bref, l’utilisateur de Gerrit est responsabilisé via son vote à la validation d’une modification.

Le principe a l’air simple et efficace, l’effort louable, mais je continue de me poser une question après cette étalage de bonnes idées :
Gerrit n’est-il pas juste un plan d’action de plus inscrit sur un tableau lors d’une rétrospective puis oublié au sprint suivant ?

La suite du billet JOP à la Devoxx 2011… dans quelques jours !