Mix-IT 2015 – Jour 1

Mix-IT, c’est deux journées de rencontres et découvertes, des présentations de sujets techniques et agiles ainsi que des ateliers pratiques. L’événement lyonnais est organisé par une équipe de choc : membres du Lyon JUG et CARA, bénévoles et même professionnels de la gastronomie ! Toutes les conditions étaient réunies pour nous offrir un programme sur mesure lors de cette cinquième édition, du 16 au 17 Avril 2015. Voici un retour sur les conférences et ateliers de la première journée auxquels nous avons pu participer (le programme de la deuxième journée est dans un autre billet).

The Three Ages of Innovation

Keynote d’ouverture – par Dan North (slides)
Dan North n’est autre que le créateur du BDD (Behaviour-Driven Development). Conférencier invétéré, il est aussi coach, développeur et consultant, activités qu’il exerce depuis les vingt dernières années.
Il nous explique que l’Innovation est définie par les trois étapes suivantes :

Explore: maximise discovery

Expérimenter, analyser, étudier, faire émerger de nouvelles idées. Une expérience qui a échoué EST une découverte. Dan cite Isaac Asimov :

The most exciting phrase to hear in science, the one that heralds new discoveries, is not “Eureka!” but “That’s funny…”

Stabilise: minimise variance

Catégoriser, valider, obtenir des retours sur des idées neuves. Trouver un pattern répétitif pour chaque scénario.

Commoditise: maximise efficiency

Optimiser les coûts, la productivité et les efforts.
Bien que ces différentes dimensions possèdent des objectifs conflictuels, elles sont complémentaires car c’est lorsqu’elles sont toutes les trois réunies que l’Innovation se produit.

Agilité par le code grâce à CQRS et Event Sourcing

Atelier technique – par F. Pellet, C. Bouiller, J. Helou et E. Pecoul (slides)
Florent, Clément, Jean et Emilien sont des craftsmen du logiciel sur la région lyonnaise. Après une présentation rapide de CQRS (Command Query Responsibility Segregation), puis de l’Event Sourcing (stocker les changements d’état d’une application plutôt que son état actuel), nous avons pu mettre les mains dans le cambouis.
L’exercice consiste à appréhender les différents concepts clés en simulant des événements d’un utilisateur lambda sur Twitter :

1. Delete command (le C de CQRS)

Publication de l’événement MessageDeleted depuis l’agrégat Message.

2. Timeline messages projection (le Q de CQRS)

Transformation d’événements en une structure de représentation : TimelineMessageProjection.

3. Subscription aggregate (le C de CQRS + Event Sourcing)

Création d’un nouvel agrégat Subscription, rejouer une séquence d’événements.

4. Aggregates interaction

Interactions entre les agrégats Message et Subscription, concept d’Eventual Consistency.

Les animateurs ont fourni un travail considérable pour la préparation de cet atelier. Chaque étape de développement s’est faite en TDD, il nous suffisait de fournir les implémentations pour faire passer les tests au vert. En cas de retard, un tag (git) par étape nous permettait de revenir dans la course. Chacun a pu trouver chaussure à son pied en utilisant son langage de prédilection (Java 8 / C# / JS/Node / PHP5.5). En conclusion, un atelier très bien ficelé qui donne envie de creuser sur le sujet et qui aurait mérité plus de temps, en ce qui nous concerne, pour être terminé. Les sources sont disponibles ici.

Le JavaScript du futur au bout des doigts

Atelier technique – par Julien Roche (sources GitHub)
Lors de ce workshop purement JavaScript, Julien Roche (Viseo Technologies), nous présente ES 6 (ou ES 2015), la version à venir du standard ECMAScript.
L’application fournie affiche une simple liste d’utilisateurs sur une page web, avec du Vanilla JS sans fioriture. Après une présentation sur les transpileurs Traceur et Babel, nous commençons à convertir la syntaxe “old-school” d’ES 5 avec les nouveautés de la future spécification : =>, classes, fonctions avec valeur des paramètres par défaut, for..of, template strings, etc. Julien nous montre qu’il est possible d’intégrer directement le processus de transpilation à WebStorm (ce que l’on peut faire aussi avec Gulp / Grunt mais ces derniers ne sont pas dans le scope de la session). Nous continuons l’exercice en implémentant une fonction de recherche d’utilisateur et passons en revu l’export / import de modules.
Cet atelier n’aura pas désorienté les personnes s’intéressant de près à JavaScript et à son écosystème. Cependant, il présente une bonne introduction aux nouveautés qu’apporte ES 6 et aux outils à utiliser pour en profiter dès aujourd’hui.

24 Minutes chrono pour bâtir une appli mobile

Conférence – par Sébastien Blanc
D’entrée, le ton de cette conférence est donné ! Sébastien Blanc (développeur chez Red Hat) va nous prouver qu’il est possible de développer une application web mobile (basique mais fonctionnelle et multiplateformes) en 24 minutes montre en main, et avec son back-end Java EE.
Il commence par un rappel (on ne peut plus clair et subjectif) sur les architectures REST :

REST is the best, f*ck the rest!

Puis il nous montre l’implémentation RESTEasy (utilisée chez Red Hat) de la spécification JAX-RS.
Quant au front-end, l’application à bâtir va être hybride. Sébastien nous présente brièvement Apache Cordova (la partie open source de PhoneGap), dont le principe est de mettre une coquille native autour d’une application web et ainsi d’avoir accès aux fonctions natives des smartphones à travers une librairie JavaScript. Arrive le choix du framework pour l’UI de l’application (hors de question de développer en CSS natif). jQuery Mobile et Bootstrap sont eux aussi emmenés vers la sortie. Le grand gagnant est Ionic (sexy widgets that just work). Son intégration avec AngularJS et sa communauté d’utilisateurs (déjà importante et grandissante) en font un candidat de choix.
Sébastien fait un point sur la sécurité et nous explique que c’est une partie souvent très compliquée et négligée, même avec un framework. Il faut laisser une application tierce s’occuper de tout le travail : Keycloak (une solution SSO pour les applications web et services REST, construite sur les spécifications OAuth 2.0 et JSON Web Token).
Il en va de même pour les notifications push. Leur implémentation multiplateformes est difficile à cause des différents protocoles. La solution : UnifiedPush Server (un war qui permet de centraliser toute la logique des protocoles iOS, Android, Windows, FirefoxOS).
Arrive enfin le moment tant attendu : le Live Coding. Sébastien développe en quelques minutes seulement le CRUD de son back-end grâce à JBoss Forge, un outil qui s’utilise en ligne de commande ou dans un IDE sous forme de plugin (ici Eclipse). Forge propose des commandes, à l’aide d’assistants graphiques, pour générer le code nécessaire à la mise en place des différentes couches de l’application (choix de l’implémentation de JAX-RS, implémentation de JPA, SGBD, etc.). Le squelette de l’application cliente se génère de la même manière mais cette fois-ci avec AeroGear, un autre outil JBoss fournissant un ensemble de plugins Cordova. Bien qu’en présence d’un effet démo (la résolution du vidéoprojecteur était telle que le simulateur Android n’était pas complètement visible et accessible), Sébastien nous démontre le fonctionnement correct de son application (création / visualisation / suppression d’un élément). Il ne lui reste qu’à mettre en place la solution de SSO (Keycloack) et le serveur de notifications push (UnifiedPush Server) avant que le compte à rebours ne se termine. Keycloack se configure à l’aide d’un fichier Json (indique l’emplacement du serveur d’authentification) et UnifiedPush Server s’installe en une commande.
 

On peut dire que le pari est réussi ! L’application est minimaliste mais les différentes couches sont en place et fonctionnelles grâces aux plugins JBoss (JBoss Tools). On croira sur parole Sébastien quant à la parfaite intégration sur les autres plateformes.

Si le TDD est mort, alors pratiquons une autopsie

Conférence – par Bruno Boucard et Thomas Pierrain (slides)
Lors de cette session, Bruno Boucard (craftsman, coach agile) et Thomas Pierrain (architecte .NET, auteur de la librairie open-source NFluent) font un amer constat : le TDD n’est pratiqué, correctement et quotidiennement, que par une faible partie des développeurs qui l’utilise. Et c’est bien dommage ! Les deux conférenciers nous présentent les raisons de ce constat ainsi que les solutions possibles à mettre en place.

1. Foncer tête baissée

Nous sommes tentés de frapper frénétiquement sur le clavier dès qu’une pensée nous traverse l’esprit. Mauvaise idée ! Il faut se poser pour réfléchir, préparer son cerveau, creuser son sujet fonctionnel. Il faut se forcer à formuler à voix haute les spécifications et discuter avec le métier. L’utilisation du mot “should” doit permettre de formuler un message que l’on adresse à soi-même. Bruno établi un rapprochement avec Michel-Ange, travailleur acharné et passionné de son époque qui était constamment insatisfait et en recherche d’amélioration. Soyons des Michel-Ange du développement ! Thomas nous détaille la règle des 10K heures : on ne devient expert dans un domaine qu’à partir de 10K heures de pratique. Comment y arriver ? Pratiquer des katas et participer à des codings dojo, sessions qui permettent de s’entrainer dans les différentes sous disciplines du TDD (designing test cases / clean code, driving development with tests, refactoring safely).

2. Comprendre le besoin

Thomas nous présente le concept agile des “trois amigos”. Il s’agit de discuter / échanger avec les différents acteurs du domaine : développeurs, testeurs (QA), product owners, pour avoir une meilleure compréhension du besoin. On utilise les “cinq pourquoi” (méthode de résolution) pour déterminer les causes racines du problème. Il faut redonner du sens à notre métier de développeurs, nous ne sommes pas de simpl
es pisseurs de code (Impact Mapping). Pour être efficace : KISS (Keep It Simple Stupid), utiliser les bons outils (NCrunch, Infinitest), Outside-In development with Double Loop, lire le GOOS (Growing Object-Oriented Software Guided by Tests).

3. Une mauvaise utilisation

Thomas fait part de son expérience personnelle. Au bout d’un an d’utilisation du TDD, dans une équipe de 10 personnes, le moindre changement dans la base de code faisait échouer près de 20% des tests. De quoi être quelque peu découragé… Le secret : ne pas tester des méthodes mais des “behaviours” (usage de l’API).

4. Ca va moins vite

Bruno nous rappelle qu’il ne faut pas nous voiler la face, le TDD, ça prend du temps. Il existe deux manières de penser : reflex, discussions de comptoirs, sans effort OU étudier, se poser des questions, élaborer une reflexion. Cette dernière demande évidemment plus d’investissement. On cherche des automatismes qui sont pilotés par une réflexion (voir “Thinking, Fast and Slow” de Daniel Kahneman).
Pour conclure, on ne fait pas de TDD car le plus souvent, on en fait mal. Le RED / GREEN / REFACTOR n’est que l’ossature, la partie émergée de l’iceberg. Cependant, en appliquant les bonnes pratiques décrites par nos deux craftsmen, le TDD peut s’effectuer dans la joie et la bonne humeur !