Mix-IT 2012 : retours

Introduction

Jeudi 26 avril avait lieu Mix-IT 2012 à Lyon, une conférence visant à mixer agilité, écosystème Java et Innovation IT et j’ai enfin pu y aller : en voici mon retour.

Avant de rentrer dans les détails des sessions que j’ai suivies, un mot sur l’organisation : impeccable ! Très bon accueil, bonne organisation, affichages efficaces, collations irréprochables. Côté programme, une grande diversité et des sessions de qualité : le problème est alors de devoir faire des choix ! Côté point d’amélioration : circulation un peu serrée entre les sessions et écrans un peu bas pour les projections en session, il valait mieux être devant. Mais bon, c'est mineure !

Après les mots d’accueil, nous avons eu une intervention de Martin Gömer (Google France) qui nous a parlé du nouveau Chrome pour Android et a fait sa pub de recrutement ... Pas trop compris ce que ça faisait là ... Mais bravo pour l'écharpe et pour la capture d'écran animée ...

Keynote (Claire Blondel)

Claire s’est présenté comme une « alien » dans cette conférence, et nous a parlé du droit de se tromper, de l’apprentissage par l’erreur, en se basant sur ce qu’elle a vécu et observé avec ses filles rentrées dans le système scolaire Français après plusieurs années en écoles internationales au Japon, et le choc qu’elle a eu par rapport à leur réactions, leurs découragements.

Quelques points notés :

• L’omniprésence de la peur de se tromper, notamment dans l'esprit Français
• S’appuyer sur les forces et les réussites plutôt que d’insister sur les erreurs 
• Promouvoir l’auto-contrôle (cf méthode Jidoka vue chez Toyota) 
• La réussite est rare, un grand nombre d’échecs permettront d’accéder aux quelques pistes menant à la réussite 
• Churchill : le succès, c’est aller d’échecs en échecs 

Bref, une véritable promotion de l’erreur et de l’échec !

La veille de cette journée, j’étais en pair-programming avec un développeur pour l’accompagner vers les tests unitaires et le TDD, et je lui disais : « vas-y, essaie, n’aies pas peur de te tromper ! ». Facile à dire pour les autres, mais moi-même, est-ce que je m’autorise l’échec ? …

Difficile d’en dire plus sur l’intervention de Claire, le mieux est de l’écouter, j’ai été très intéressé par son intervention, le reste de l’auditoire également apparemment. D’ailleurs, l’ovation d’applaudissements après son intervention a bien témoigné de l’écho de ses propos !

Oui à l’erreur, oui à l’échec, n’ayez plus peur de vous tromper pour aller au succès !

Play 2.0 (Julien Richard-Foy)

Je connais et utilise Play 1.x depuis environ 3 ans, et je vais démarrer un nouveau gros projet, probablement avec Play et donc pourquoi pas Play 2.0. D'où mon choix pour cette session, voir les nouveautés et peut-être démystifier Scala ...

Sur les notions de base de Play, qui n’ont pas changées entre les versions 1 et 2, je n’ai pas appris grand-chose. Par contre, j’étais surtout curieux de voir Scala en action car, je l’avoue, un peu retissant du peu que j’en ai vu … Et là, la surprise est assez bonne, la marche à franchir ne semble pas si haute que ça, et surtout, Play 2.0 permet d’écrire ses contrôleurs aussi bien en Java qu’en Scala. Il est donc possible d’y passer en douceur, d’écrire certains contrôleurs « simples » en Scala, ou inversement, de se lancer dans Scala en sachant qu’on pourra toujours revenir à Java en cas de gros problème. Par contre, côté « vues », pas de choix, c’est du Scala, mais à petite dose puisque les vues sont essentiellement écrites en HTML. L’insertion de données se fait par la simple instruction « @name », les boucles et autres instructions seront peu nombreuses à apprendre et prendre en main.

Julien a terminé sur les possibilités de programmation asynhrone. Malheureusement pris par le temps, il a dû passer assez vite sur ce sujet, mais cela m’a donné un aperçu de ce qui peut être fait et rentrer dans les détails lorsque ce sera nécessaire. Là encore, Scala semble obligatoire, mais avec la possibilité de déléguer les actions à des « acteurs » qui pourraient être sur d’autres machines : l’aspect « scalable » de l’approche. La solution est basée sur Akka.

En conclusion, un orateur qui semblait maitriser son sujet mais cherchait un peu ses mots, dommage, mais une bonne présentation qui me motive à partir sur Play 2.0 pour mon prochain projet !

Hibernate Search : un tigre dans son moteur (Emmanuel Bernard)

Je l’avoue, ma première motivation pour aller à cette session était de voir, en chair et en os, Emmanuel Bernard que je suis sur le podcast Java http://lescastcodeurs.com/, et de vérifier par moi-même ses qualités d’orateur. Et je n’ai pas été déçu : il est à l’aise, maitrise ses sujets, et les démos donne une impression de facilité (parce que très bien préparée).

Ensuite, le sujet m’intéressait quand même. Ce n’est plus le cas dans mes projets actuels, mais j’ai utilisé Hibernate pendant quelques années, et le sujet de la recherche est important, surtout avec la quantité croissante de données que nous sommes amenés à manipuler.

Après un introduction théorique rapide et efficace, Emmanuel est passé à une démo, rien de tel pour avoir un bon aperçu du concept. Nous avons d’abord pu voir comment choisir ce qu’il faut indexer dans les entités, puis comment faire des recherches de différentes manières.

Le sujet qui m’a le plus marqué est le « faceting » qui consiste, après une recherche, à présenter à l’utilisateur des moyens d’affiner sa recherche en lui indiquant, par exemple, les catégories (et leurs quantités) présentes dans les résultats. Là, la démo est bluffante (encore une fois car bien préparée), quelques lignes ajoutées au code, et les filtres pour affiner sont à l’écran : la classe !

Emmanuel a ensuite conclut par les autres grandes possibilités, actuelles et futures, d’Hibernate Search.

En conclusion, une très bonne présentation, un orateur de qualité, et pour moi, la découverte du « faceting » et la simplicité d’instanciation avec Hibernate Search : bravo !

Sky Castle Game (Philippe Launay , Fabrice Aimetti , Antoine Vernois et Pablo Pernot)

Le jeu est omni-présent dans le monde de l’agilité. Il permet, de façon simple et ludique, de faire prendre conscience aux participants de point précis sur les relations humaines, l’esprit d’équipe, l’auto-organisation, les stratégies prédictives ou adaptatives, la confiance, etc … Je ne suis pas un expert des jeux, je les découvre en ce moment (j’y reviendrai dans un prochain article), mais je suis convaincu de leur intérêt, à condition qu’ils soient simples et permettent une prise de conscience PAR le joueur de quelques points précis ciblés par le jeu. Pas toujours si évident …

Pour ce « Sky Castle Game », nous avons été accueillis par 3 rois pour lesquels nous avons dû construire des chateaux. Je ne rentrerai pas dans les détails du jeu pour ceux qui auraient l’occasion de le pratiquer un jour. Personnellement, j’ai eu du mal à trouver ma place (au sens propre), comprendre les règles, mon rôle, le déroulement, etc … Et apparemment, je n'étais pas le seul. Merci à Alex qui faisait partie de notre équipe et a été bien moteur pour lancer notre « production ».

Le déroulement du jeu est assez stressant, et le « gong » de Pablo très … bruyant ! ;-) …

La rétrospective collective en fin de jeu a permis des échanges intéressants, et m’a permis de constater que les réflexes, que l’agilité tente d’enrayer, ont la vie dure.

Côté amélioration du jeu (encore une fois, juste mon ressenti, sans être expert des jeux) :

• Peut-être simplifier un peu les règles et le vocabulaire (même s’il devient moins « historique ») ?
• Avoir une salle plus adaptée, plus grande, avoir plus d’espace pour laisser place aux initiatives ?
• Eviter d’avoir 2 équipes qui produisent beaucoup de bruit et rentrent vite en compétition ?
• Introduire, en cours de jeu, un facilitateur par équipe ?

 Tout comme pour mon coding-dojo à l’Agile Tour de Marseille 2011, je pense que le contexte de la conférence n’est pas le plus représentatif de ce qu’un jeu peut apporter à une équipe. Autrement dit, le jeu joué au sein d'une équipe existante, dans une entreprise, aura bien plus d'effets pédagogiques que le même jeu joué en conférence : les participants viennent en partie pour voir le jeu et non pas forcément pour bénéficier de ses aspects pédagogiques (comme moi par exemple), et l'esprit d'équipe n'est que temporaire.

En conclusion, un bon moment, une bonne découverte et de bonnes rencontres, mais quelques interrogations sur le niveau de portée pédagogique d’un tel jeu.

Selenium WebDriver, TestNG et Selenium Grid (Mathilde Lemee)

Ici aussi, je l’avoue, je suis allé à cette session autant pour voir Selenium en action, que pour voir Mathilde Lemée avec qui j’avais échangé il y a quelques années, par internet, autour des tests unitaires et des mocks (Mockito vs jMock). Et cette double attente a été satisfaite.

Au-delà d’être charmante, Mathilde est une très bonne oratrice. Elle maitrise son sujet, la présentation alterne entre théorie et pratique, et les démos donnent une impression de grande facilité, résultat d’une préparation précise et rodée !

Côté Selenium, j’avais testé cet outils il y a quelques années, en version 1, et évidemment, en commençant par Selenium IDE (la « mauvaise » approche). J’avais senti tout l’intérêt d’un tel outils, mais le rapport investissement / ROI n’était pas intéressant. J’ai découvert la V2 et les WebDrivers récemment à la SAMSE (Merci @LLeseigneur et @cascrum), et j’ai pu constater les évolutions intéressantes de cette nouvelle version.

Le début de la présentation de Mathilde ne m’a rien appris, juste confirmé ma nouvelle vision sur cet outil. Par contre, après avoir introduit l’intérêt d’automatiser les tests GUI, Mathilde n’hésite pas à insister sur les inconvénients, comme leurs durées d’exécution et leurs éventuels couts de maintenance, donc à utiliser à bon escient.

La seconde partie de la présentation m’a permis de redécouvrir TestNG (testé et écarté il y a quelques années) permettant de paralléliser les tests, d’autant plus intéressant pour ces tests GUI qui sont longs. L’autre outil très intéressant est évidemment Selenium Grid (et ses "hubs") qui permet de lancer les tests, en parallèle, sur des nœuds distants, machines réelles ou VM, permettant ainsi de dérouler les tests sous différents navigateurs : pas tout compris dans les détails, mais impressionnant et évidemment intéressant !

Mathilde conclut sa présentation en posant la question : pourquoi un tel outil, existant depuis des années, performant et abouti, n’est-il pas plus utilisé. Apparemment souvent à cause de mauvaises pratiques menant à l’échec. Mathilde a donc la bonne idée d’insister sur une douzaine de bonnes pratiques pour éviter les pièges : excellent idée pour nous aider à bien démarrer ! Exemples :

• Eviter Selenium IDE, pratique en apparence, mais tests difficiles à maintenir
• Utiliser obligatoirement le concept de « Page Object Pattern »
• Découpler les tests et les données
• 1 test = 1 assertion (NDLA : ou 1 série d’assertions)
• Soigner son code de test (NDLA : comme pour les tests unitaires)
• Penser parallélisation des tests
• Faire des tests atomiques (exemple pour une archi CRUD, éviter le lire les données écrites par le test d'écriture)
• Ne pas se limiter aux tests via le GUI et, par exemple, vérifier les données directement en BDD
• Industrialiser les tests
• Penser incrémental, commencer petit, observer, analyser, compléter … 

Lors des questions/réponses, Mathilde précise quelque chose qui me semble important : garder à l’esprit la «pyramide des tests» : beaucoup de tests unitaires, un peu moins de tests d’intégration, et encore moins de tests GUI (les choisir à bon escient).

En conclusion, une session très riche et très motivante, pour un outil dont j’aurai l’usage pour mon prochaine gros projet, avec quelques bonnes billes pour démarrer : merci !

Stresser son application avec Gatling (Stéphane Landelle)

Pour la dernière heure, j’ai pas mal hésité, et je suis resté technique et curieux en allant voir « Gatling », et le titre m’avait accroché : stresser une application, pourquoi pas !? Et pourquoi pas reprendre une couche de Scala …

En introduction, Stéphane explique pourquoi les outils existant n’ont pas répondu à leurs attentes et pourquoi ils ont été amenés à développer un nouvel outil : problèmes de performance, problèmes de threads (grand nombre de threads qui finalement ne font souvent rien), compliqué à l’usage, configurations XML volumineuses, etc … L’idée est donc de partir sur une solution portable, réellement asynchrone, ergonomique et économique (pas besoin d’avoir une salle de machine rien que pour tester l’application). Et naturellement, les développements se sont orientés vers Scala (encore) et sa bibliothèque Akka (décidemment) pour la partie asynchrone, basée sur le concept « d’acteurs ».

Autre choix important : pas de GUI, une description des tests sous forme de scripting. La suite de la séance s’est déroulée sous forme de mélange de démo et d’atelier pour ceux qui avaient un ordi.

En conclusion : une découverte pour moi, un sujet intéressant, une solution qui présente effectivement des avantages et propose une approche logique (je ne connais pas les autres solutions, donc pas de comparaison possible) et une équipe de motivés ! A noter dans les outils …

Conclusion

Pour moi, le ROTI est à coup sûr de 5/5 : au-delà de mes attentes.

Mon principal regret est de ne pas avoir vu certaines sessions, peut-être aurais-je dû faire d’autres choix ? En tout cas, j’ai choisi ce qu’il me fallait au moment qu’il me fallait … ;-)

Je remercie donc toute l’équipe d’organisation pour cette belle journée bien réussie. Je remercie également le groupe de Grenoble avec qui j’ai covoituré et co-voyagé : c’était plus sympa, et nous avons pu avoir des échanges et discussions très riches ! Et pour finir, je remercie toutes les personnes que j’ai pu croisé, avec qui parfois j’ai pu échanger un peu, rapidement, là encore, c’était très riche et trop court !

 Vivement l’édition 2013 !