Pour commencer, après quelques péripéties (erreur sur la gare de RER, Val de fontenay != Fontenay sous Bois ), me voila sur les lieux dans le magnifique chalet de la porte jaune. Le cadre est très sympa, très vert avec un petit lac, des oies, des canards, des chats qui se baladent…
Je récupère mon badge ainsi que mon sac de goodies. Cette année, le cadeau était un timer (style minuteur de cuisine), cool, j’en voulais justement un (très important pour timeboxer une réunion).
La journée commence par une brève présentation, cela me permet de constater que l’évènement est une réussite : plus de 250 inscrits venant de toutes la France, de Belgique, du Canada (et d’ailleurs). Décidément, l’agilité en France à de beaux jours devant elle.

Première conférence de la journée : Comment soigner sa schizophrénie MOA/MOE

Le but de cette intervention était de monter comment rapprocher ces deux entités au travers des spécifications exécutables. L’accent est principalement mis sur Fitnesse.
J’en retiens que le fait d’écrire ces tests de hauts niveaux en collaboration avec la MOA permet de structurer la phase de spécification, et de lever toute ambiguïté et interprétation.
De plus, cela structure la manière de coder tout comme le fait le TDD à un niveau plus bas.
Les spécifications sont faites sous formes de scénarii au formalisme : Given … when … then …
Je vous recrache le schéma présenté sur les tests qui permet de situer les différentes catégories :

Je trouve qu’il est pas mal.
L’outil présenté est bien évidemment Fitnesse (utilisé avec SLIM) qui est pour un eux un premier bon pas vers les spécifications exécutables. Cependant, l’aspect peu sexy du wiki peut être un frein à l’acceptation par la MOA selon eux.
Parmi les problèmes soulevés il y a également le découplage du versionning avec le versionning de l’application (deux workflow différents, un wiki, l’autre basé sur le SCM), cependant il parait que la communauté Fitnesse y travaille. En discutant avec les gens de Pyxis, nous avons constaté que le problème était similaire sur GreenPepper qui se base sur la gestion des versions par Confluence.
Enfin, deux pistes à suivre : Jbehave2 (plutôt un DSL pour écrire du test à ce que j’ai compris) et Twist, poussé par Thoughwork, qui propose une solution basée sur Eclipse RCP pour écrire et avoir une aide syntaxique à la volée des tests fonctionnels (payant cependant). A creuser…

Ceintures et brettelles, test d’une application Web puis, mon JavaScript est agile lui aussi.

Je regroupe en une seule ces deux présentations car la deuxième est la suite de la première.
Arnaud Bailly, nous détaillait la chronologie des méthodes de tests utilisés pour tester une application RIA, avant de s’arrêter sur la méthode qu’ils avaient retenu.
Tous d’abord, il nous présente le duo Selenium/WebDriver. C’est sympa, les écrans défilent, c’est facile, on peut l’enregistrer avec un mode record/play. Mais au final, c’est trop lent avec prêt de 30 secondes pour lancer 3 tests et surtout c’est très dure à lire (donc à maintenir) et très peu souple. Dès que l’on bouge un peu à la page, tout s’effondre et il faut retravailler les expressions Xpath d’accès au élément HTML.
Ils ont essayé d’améliorer la chose en créant une surcouche pour décorréler la partie métier de la partie quincaillerie de manipulation des pages. Cependant, pour lui les problèmes demeurent et surtout la lenteur d’exécutions des tests. Sur un projet 500 tests peuvent mettre une nuit entière à s’exécuter. Dans ce contexte il se pose la valeur ajoutée par ceux-ci.
La solution qu’il a choisie est de tester unitairement la partie cliente tout comme il le fait pour la partie serveur. Ce qu’il cherche à tester c’est du JavaScript fait avec une bonne dose de JQuery. Pour cela il a démontré comme se créer un DSL en JavaScript (en utilisant massivement les prototypes), afin de rendre les tests facile et très expressifs. Pour finir il a intégré le tout avec HTMLUnit et Maven.
C’est assez sexy, mais je crains que le coût d’écriture du DSL soit trop élevé. De plus, qu’est ce qui prouve que le DSL n’est pas buggé. Je suis mitigé. Sinon il parait que Google a lancé un projet similaire multi-navigateurs, je vais chercher (c’est ici ).

Rétrospectives, la clef de l’amélioration continu.

Une présentation assez rapide sur laquelle j’ai pris peu de note.
Cependant, elle m’a fait pointer l’intérêt crucial qu’apportait les rétrospectives d’itérations et de projets ainsi qu’également la complexité de garder du dynamisme autour de celles-ci. En fait au bout de quelques itérations elles peuvent devenir routinière et il devient alors intéressant de varier les approches et les exercices. A ce titre, j’ai bien aimé le jeu de carte proposé par François Bachmann et Jacques ? qui ont synthétisé dans quelques cartes assez sympas le livre « agile retrospective ». Je vous conseille d’aller voir sur leur site www.alchimiste-agile.com
En vrac les infos que j’ai noté :
Pour les rétrospective de sprint, prendre 30’ par semaine d’itération, avoir un groupe réduit (équipe + chef de projet).
Pour les rétro de projets, avoir une équipe la plus ouverte possible (inviter le management, la production voir même les commerciaux). Préparer des débriefs individuels avant et essayer de sortir la rétrospective du lieu de travail habituel (terrain neutre).
Une idée pour collecter de l’information :
Placer une pile de post-it et écrire en vrac les idées des participants, regrouper en grosse catégories et identifier ainsi les principaux problèmes et réussites. Trouver une ou plusieurs actions pour l’itération suivante.
Pour la rétrospective de projets l’aspect chronologique est préféré, on refait la liste des faits selon un axe.
Il y a un groupe yahoo pour ceux qui ont des questions.

La suite dans un prochain post…

J’hésitais un peu à y aller, craignant que les présentations soient plus de l’introduction à Scrum. Puis je me suis décidé pour voir Eric Mignot de chez Pyxis, voir le Touilleur (aka Nicolas Martignole) faire sa première et pour revoir Guilaume Bodet qui avait fait une très bonne présentation au Scrum User Group en mars. Bien m’en a pris, car la soirée était très instructive !

Première présentation

La première présentation, sous la forme d’un dialogue, a été une introduction à Scrum. Le Touilleur en a profité pour ressortir sa métaphore de la machine à laver.

Je ne ferais pas un topo complet de cette présentation qui a principalement reposé les bases de Scrum et du manifeste agile, mais j’ai cependant bien aimé certaines idées avancées par Eric Mignot.

Notamment : apprendre Scrum c’est désapprendre autres choses (avec en cible de mire les processus lourds et parfois incohérents imposés par certaines méthodes).

L’idée véhiculée tout au long de cette présentation est que les méthodes agiles ne doivent pas être vues comme une méthodes à appliquer aveuglement « out of the box ». Les méthodes agiles sont là pour nous faire réfléchir sur ce que l’on fait, et pour nous redonner le goût de faire du dev. Pour cela, elles proposent un ensemble d’outils, mais elles ne doivent pas être vues comme une méthode à part entière.

Le but ce n’est pas de faire du scrum, mais de s’améliorer. Ainsi, pourquoi pas introduire petit à petit le daily Scrum ou bien la démonstration post itération tous les mois ?

Je vous ai refait au propre le schéma d’Eric qui synthétise assez bien Scrum ci-dessous :

Info intéressante, Eric estime que la vélocité sur un projet se stabilise au alentour du 5^ème ou 6^ème sprint.

Deuxième présentation

La deuxième présentation, proposée par Guillaume Bodet a été encore une fois extrêmement enrichissante. Guillaume nous proposait de confronter la réalité de l’introduction de Scrum sur les équipes en place.

Premier problème, comment trouver un Product Owner ? Pour cela, et contrairement à ce que la littérature propose on se rend compte fréquemment :

• que le product owner n’est pas forcément seul
• qu’il n’est pas forcément responsable de tout
• qu’il n’est pas forcément un visionnaire

On n’a pas tous un Steve Jobs dans nos entreprises. Le rôle de du product owner est avant tout un rôle logique.

Deuxième problème comment on démarre un projet agile et comment on constitue un Backlog de produit.

Pour démarrer un projet il faut au mininum :

• la taille estimée du projet
• le ROI
• la liste des principaux risques
• la composition de l’équipe

Le tout pouvant tenir dans un document d’une dizaine de pages max.

A partir de ceci on obtient le go du projet et on peut partir sur un Sprint 0 avec une équipe réduite. A l’issu de ce Sprint le Product Owner, aidé par l’équipe, aura créé un premier backlog de produit.

Le burdown chart a ensuite été évoqué. La notion intéressante est de mettre en avant deux courbes, une qui montre les stories implémentées à partir de l’estimation initiale, l’autre pour montrer l’ajout de story (ou le retrait) ou la réévaluation des tâches. C’est plus motivant et vendeur de voir un burdown qui globalement est en baisse.

Guillaume nous livre la difficulté rencontrée de vendre le burdown aux comités de direction, habitués au diagramme de Gantt et aux jalons clairs. Il convient selon lui de maintenir à jour 5 niveau de planification :

• daily (quotidienne en heures)
• itération (toutes les 2 semaines)
• releases (trimestriel)
• product roadmap (semestriel)
• product vision (annuel)

La scalabilité de Scrum a ensuite été mise en avant au travers de plusieurs retours d’expérience. Le but est d’avoir ses équipes de Scrum avec chacun un ScrumMaster. Puis les ScrumMaster se retrouvent tous les 2/3 jours avec un « Meta ScrumMaster » qui est le ScrumMaster des ScrumMasters. Le principe s’applique en théorie sur n’importe qu’elle profondeur (j’ai déjà vu ça dans des présentation de Yahoo).

Sur le projet ProRail au Pays-bas, 25 personnes étaient réparties en 4 équipes. La V1 a été livré au bout de 8 mois puis les releases s’en sont suivis tous les 3 mois.

Enfin, Guillaume a fini la présentation en parlant d’architecture.

Il met un léger bémol au principe d’architecture émergente. Selon lui, l’architecture doit quand même être réfléchi au début du projet, on sait globalement qu’elles vont être les besoins et on doit prévoir ce dont on aura besoin au minimum. Selon lui, les erreurs d’architecture peuvent être très lourdes à corriger (si c’est possible) si l’architecture est fondamentalement fausse.

Il a fini par présenter la notion d’architecte agile (que l’on trouve présenté sur le blog de Xebia) 

L’architecte agile est cet architecte qui propose des règles flexibles plutôt que dogmatique.

D’après Scott Ambler (IBM) :

• piloter l’architecture par les besoins
• essayer de modéliser à plusieurs
• préférer la collaboration plutôt que la documentation (à quoi servent des best practices de centaines de pages si personnes ne les lit ni ne les comprend).
• faire simple (KISS)
• s’attaquer aux grandes problématiques tôt, régler les détails au moment voulu
• rester flexible
• publier les modèles d’architecture/métaphores.

Pour conclure, la soirée a été encore très intéressante. Merci aux présentateurs et au ParisJug pour ces présentations de qualité.

Un résumé très complet et avec photos est disponible également ici.

Vendredi dernier Sun organisait une journée de conférences gratuites dans ces locaux rue de Iena à Paris. Pour cette journée, Sun faisait une tournée de ces programmes OpenSources.
Malgré des salles parfois un peu petite, l’organisation était très correcte et le contenu des sessions très intéressant. Avec deux salles en parallèles j’ai porté mon choix sur ces conférences : JavaEE 6, Grizzly Comet, OpenSSO, GlassFish V3 prélude, JavaFx, JavaFx tools, Xwiki, Hudson. Beaucoup de choses intéressantes dont je vais vous faire part ci-dessous.

Présentation du Business Model pour les produits OpenSources Sun

Sun a commencé cette journée par nous présenter son Business Model pour l’OpenSource. Du grand classique, Sun apporte principalement du support, de l’assitance et de la formation pour l’ensemble de ses softs et fournis pour certains cas des distributions commerciales en parallèle de distribution free.
J’y apprend deux/trois infos intéressantes, Sun pense être le premier contributeur OpenSources (au monde ou de ses produits ???) je découvre le logiciel de virtualisation virtualbox (www.virtualbox.org) qui a l’air assez puissant et simple (en plus d’être gratuit).
Parmi les avantages de l’Open Source Sun met en avant une meilleure interopérabilité entre les logiciels, par contre le point sur la sécurité et le nombre de bugs portent plus à débat.
Une petite apparté sur MySQL : Sun pense qu’Oracle est sur utilisé. Parce qu’un gros projet nécessitant des fonctionnalités très avancé choisie Oracle, alors tous le SI devient Oracle. Sun essaye de casser ce schéma en ventant la facilité et la souplesse d’un MySql. Je suis relativement d’accord, reste à convaincre les DSI.

Retour d’expérience par SFR

Cette présentation m’a laissé très dubitative. Certes ce n’était pas le speaker prévu, mais bon je n’ai pas bien compris le message et je n’ai du tout était convaincu.
En gros la personne de chez SFR présentation la migration d’une de leur offre sur une stack « full Sun ». Passer d’un Tomcat, Axis (et je ne sais plus le reste) vers une solution Glassfish + Grizzly + Metro. Pas vraiment de données techniques intéressantes, pas de justification pour ce choix. J’ai juste eu l’impression que le choix a été plus marketing qu’autre chose (on a pris parce que c’était Sun). D’après le speaker Tomcat+Axis supporte mal la scalabilité.
Seul info intéressante : « SFR veux de – en – de produit à licences », ce qui confirme la tendance.

JavaEE6 par Roberto Chinnici (spec leader JavaEE6)

Certainement la présentation la plus intéressante de cette journée. Pour moi qui suivais ça de loin j’y ai appris pas mal de chose sur l’avancement de la specs ainsi que des specs liés.
Tout d’abord Roberto à mis en avant les grands axes de cette nouvelle mouture :

• Facilité d’apprentissage
• Facilité d’utilisation
• Flexibilité

On est clairement dans la continuité de J2EE 5.
Ce qui m’a interpellé par contre c’est : « L’agilité de la plateforme pour interchanger les composants ». En gros c’est de pouvoir rester sur un serveur d’application JavaEE6 mais de pouvoir par exemple rajouter la nouvelle API Servlet 4 lorsqu’elle sortira. Cet axe m’a l’air très intéressant mais je me demande encore comment cela sera mis en œuvre. Roberto pense à la possibilité pour les serveurs d’applications de faire des updates (un peu à la manière de GlassFish qui contient un module d’update). Je trouve ceci très intéressant en tout cas, car le gros problème de J2EE est que l’on est dépendant de la version du serveur d’application choisi par la production. A suivre donc…

Pour les grandes nouveautés on a droit :

Profils

Les profils permettent de découper la norme en sous ensemble cohérent et donc de ne pas devoir implémenter l’énorme stack entière J2EE. Le seul profil pour le moment validé (en plus du profil complet) et le profil web. En gros un clone de tomcat + JSF + JPA + JTA + EJB Lite (+ peut-être JAX-RS et WebBeans).
Il est parlé de profil type portail ou intégration, mais rien d’encore concret à priori.

Elagage

L’élagage permettra enfin aux développeurs de serveurs d’application de ne plus avoir à implémenter de vieilles normes complètement dépassées. Parmi celle-ci on retrouve notamment JAX-RPC, Entity Bean, JAXR, JSR-88. Ces normes seront facultatives et il y aura un marqueur particulier dans la javadoc pour préciser.

Extensibilité

L’extensibilité permettra l’enregistrement automatique de la configuration sans passé forcément par un fichier de configuration du type web.xml. Les servlets, filtres, listener… seront découverts à la volée par le serveur. De plus, les frameworks (style Spring MVC, Struts, etc.) pourront mettre dans leur jar la définition des listeners par exemple (dans META-INF/web-fragments.xml) ainsi le développeur n’aura plus besoin de faire la configuration explicitement.

Nouvelles API

Il nous a été présenté plus en détail les nouveautés de Servlet 3 et des EJB 3.1 mais je me contenterai de vous renvoyer vers d’autres articles en parlant plus précisément.

Nouveau packaging des applications EJB

Il n’y aura plus besoin de créer un jar pour ces EJB que l’on incorpore derrière avec un war dans l’ear. A la place l’EJB pourra se greffer directement dans le war. C’est quand même bien plus simple…
Concernant les EJB j’ai été content d’apprendre que le nommage JNDI serait enfin standardisé. Cela permettra donc de pouvoir créer des applications qui soient totalement portable d’un serveur EJB à un autre (en attendant d’autres problèmes ?).

Grizzly Comet par Jean-François Arcand

http://weblogs.java.net/blog/jfarcand/archive/2008/11/writing_a_twitt.html

OpenSSO par Alain Barbier

Alain Barbier qui est architecte chez Sun nous présentait la problématique du « Single Sign On » et de la fédération d’identité. J’avoue n’être que moyennement intéressé par le sujet et j’ai donc suivi plutôt la présentation des concepts plus que le projet OpenSSO en lui-même.

GlassFish V3 prelude par Alexis Moussine Pouchkine

Alexis Moussine Pouchkine nous a présenté la future version de GlassFish V3 nommé prélude. Cette nouvelle version est une réécriture du noyau de GlassFish basé sur HK2 pour la flexibilité et sur OSGI pour la modularité. Même si certains sont resté sur leur faim j’ai bien aimé la présentation qui démontrait vraiment la légèreté de cette nouvelle version.
Un démarrage très rapide, un rechargement automatique lors de la modification de classe tout en conservant la Session (tout comme Jetty) et enfin pour la grande nouveauté un mode embedded. C’est-à-dire la possibilité de livrer une webApplication tout en y intégrant un GlassFish packagé dedans (Jetty permet déjà de le faire également).
La modularité donné par OSGI est intéressante également, on peut désormais télécharger indépendamment les modules de GlassFish et surtout on peut les loader ou unloader à chaud suivant les besoins.
Pour la partie J2EE GlassFish3 souhaite coller aux dernières avancées et implémente déjà la préversion de JSF2.
Pour conclure, en tant que développeur j’ai été assez séduit par cette version de GlassFish que je vais m’empresser de tester. Alexis promet que cette version est aussi particulièrement pensée pour les équipes de production. Espérons que la mayonnaise prenne.

JavaFx

JavaFx était l’attraction phare de la journée. Sortie la semaine précédente, c’était LE sujet que j’attendais le plus. Voir en live les possibilités visuelles et surtout la facilité à produire du code. Avec 3 speakers arrivant directement de devoxx et une salle pleine à craquer on se languissait de voir la bête.
La première impression fut un peu ratée. En effet, le début de la présentation était axé sur la partie langage de script de javaFx. A première vu ça m’a fait pensé à du Groovy … en moins bien. J’ai bien aimé par contre la notion de bind qui permet de lier une variable au résultat d’une expression. Ce qui a raté c’est le fait que l’on à pas reçu les paillettes que l’on attendait et que les slides était écris en petit en blanc sur fond noir.
Puis vint la deuxième présentation qui était centrée sur l’outillage autour de JavaFx. On nous a principalement montré l’intégration faites avec Netbeans. J’ai trouvé ça assez sympa. La première version a l’air bien abouti bien qu’incomplète. Le mode de simulation qui permet de voir le rendu en tant que client lourd, de page web ou d’émulateur pour mobile est assez sympa. J’ai découvert en passant le profiler de netbeans, super simple à utiliser très sympa.
J’ai bien aimé ensuite l’intégration avec Photoshop ou Illustrator, il suffit de bien séparer en calque puis d’exporter pour JavaFx. Ensuite en JavaFx on manipule les calques. A priori beaucoup plus simple que de manipuler une flopé de sprites.

Xwiki par Thomas Mortagne

Certainement la présentation la plus décevante. J’y suis allé uniquement parce que GlassFish3 m’avait intéressé et que j’espérait en apprendre plus (la présentation s’intitulait « Xwiki et GlassFish »). Au final, je n’ai pas bien compris cette présentation. Il a été présenté les nouveauté de Xwiki (mais je connaissais pas vraiment les anciennes) et l’accent était mis sur les parties techniques notamment l’intégration de velocity, la création d’un langage de requête, …
Au final je suis assez déçu car je n’ai pas compris le but de cette présentation.

Hudson par Vincent Linsolas

En tant que grand fan de l’intégration continu, je me devais d’aller jeter un coup d’œil à cette présentation. D’autant plus, que jusqu’à présentation je n’ai utilisé que CruiseControl et Continuum comme serveur d’intégration continu).
Après une bonne présentation du but de l’intégration continu, Vincent Linsolas nous a présenté en live Hudson. Mon bilan : c’est sexy je veux essayer !
Hudson à l’air facile à installer et à configurer. Tout peux se paramétrer via l’interface (contrairement à CruiseControl avec ces xml et xsl…).
De plus, il est à priori aisé d’étendre Hudson via un système de plugin assez poussé.
J’ai été notamment intéressé par l’existence de nombreux plugin dont Nant et Nunit. Nous avons actuellement ce problème de vouloir utiliser le serveur d’intégration continu à la fois pour un projet Java et pour un projet .Net.
Enfin, cerise sur le gâteau, l’interface GWT est vraiment super bien faites, notamment l’avancement du build qui défile dans une page web, un peu comme si on avait une console DOS ouverte.
Je vous conseille d’y jeter un coup d’œil, notamment ici.

La première présentation de Guillaume Laforge sur Groovy était très intéressante et axée sur le point de vue d’un développeur Java. L’argument majeur que je retiens est que tout code java est lui même du code Groovy (mais pas l’inverse naturellement!). La prise en main est donc très bonne car on écrit du code java au début que l’on groovyse au fur et à mesure que l’on maîtrise les tricks du langage. Je vous épargne les détails ici car Xebia en fait un compte rendu très complet ici. Le seul aspect au final qui me laisse encore perplexe dans Groovy est le faible pouvoir de détection d’erreurs à la compilation. Guillaume Laforge estime que l’aide des IDE (notamment IntelliJ) combiné à un set minimaliste de test unitaire résout le problème, à voir…
La présentation finit par une présentation des DSL (Domain Specific Langage), je ne suis pas persuadé que n’importe quel utilisateurs puissent les utiliser, mais c’est en effet un vrai moyen de se rapprocher de son client et d’essayer de parler la même langue.

La deuxième présentation était une introduction à Grails faites de manière assez ludique. Le point de vue mis en avant (et c’est l’un des atout majeur de Groovy/Grails) était vraiment la productivité. Avec aussi une partie sur le fait que Grails produisent bien une applis standard J2EE (un War). Il est en effet bluffant de voir en 10 minutes tout ce que l’on est capable de produire. Entre une syntaxe très simplifiée (merci Groovy), un boulôt de génération massive pour la BDD et l’IHM (merci Rails) et le fait de pouvoir s’abstenir de redémarrer le serveur d’application, il est clair que la productivité est au rendez-vous. De plus, d’après les retours d’expériences il semblerait que Grails tiennent globalement bien la montée en charge.
A l’issu de cette présentation, j’ai appris que la communauté Groovy était en train de sortir un équivalent de Grails pour Swing, en cherchant un peu je viens de découvrir Griffon. A tester!

Dernier petit bonus de la soirée, j’ai gagné le livre « Filthy rich client » ce qui vraiment cool, merci au ParisJug!

Pour ceux qui n’auraient pas pu participer à la soirée, vous n’avez pas tout perdu car 2 présentations équivalentes sont disponibles, ce sont globalement les mêmes, celles du ParisJug étant justes un poil mise à jour et rallongées.

Présentation de Groovy sur parleys

Présentation de Grails : T18 – Innover sans contraintes, intégrer sans ruptures (s’inscrire gratuitement sur le site de l’université du SI).