C’est bien connu, le printemps signe le retour de nombreuses conférences pour les développeurs Java et assimilés : BreizhCamp, Devoxx France, Riviera Dev, …

Cette année, c’est MiXiT qui m’a tapé dans l’œil. Une conférence avec des sujets de talks variés et passionnants, à taille humaine, avec de la bonne bouffe et surtout avec des valeurs, ça me parle forcément. On ne peut pas s’y tromper : une conférence qui est obligée de mettre en place une loterie pour gérer équitablement les inscriptions ne peut pas être mauvaise.

Une conférence à part

La conférence Lyonnaise avec des crêpes et du cœur

Une chose est sûre, le slogan de MiXiT est dans le vrai ! Passons l’évidence des crêpes, qui accompagne le quotidien des participant·e·s durant les deux jours.

Crédit photo : @jessbordeau

Côté cœur, l’équipe d’organisation de MiXiT porte haut ses valeurs. La conférence n’a clairement pas volé son slogan !

Accessibilité

Des transcriptions automatiques sont présentes dans les deux amphis pour les malentendant·e·s.

Éthique

De nombreux sujets ont été proposés sur le libre, l’empathie, l’ingénierie positive …

 

Écologie

Un hackaton organisé pour Plastic Odyssey, une association orientée IOT qui monte une expédition à bord d’un navire qui recycle les déchets plastiques pour avancer, une donation box était disponible pour soutenir l’association.

Mixité

On pouvait remarquer une participation plus importante de femmes qu’à d’autres événements (c’était en tout cas mon ressenti), dont de nombreuses Duchesses (membres de l’association Duchess France, qui valorise et promeut les développeuses dans le milieu très (trop !) masculin de l’IT en France)

Consommation responsable

Les paniers repas ont été préparés par la Communauté du Goût, une association qui valorise le slow-food, les producteurs locaux et les produits de qualité. Autant dire qu’en conférence je n’étais pas habitué à manger autre chose que des sandwichs industriels, et que les tajines, parmentiers de canard, tartes aux pralines ont été très appréciés.

Apprentissage

Durant la conférence, un événement dédié à la découverte du développement pour les enfants de 7 à 15 ans a eu lieu : MiXTeeN (le cousin de Devoxx4Kids).

Retour sur les talks

Bon, l’objectif de base était clairement de profiter de ces deux jours pour apprendre, partager, pratiquer et revenir avec plein d’idées pour s’améliorer et faire bénéficier mes collègues de ces expériences …

Parmi les talks qui m’ont marqués …

Zero bug kata – Johan Martinsson

Inspiré des observations de Arlo Belshee, ce workshop de deux heures avait pour objectif de montrer comment le design d’une application peut aider à rendre son code moins sujet aux bugs lors de son évolution (bref … plus maintenable).

Après une rapide introduction, des binômes (ou plus dans mon cas) se sont constitués par langage de prédilection (PHP, Java, JS, C#, Kotlin), pour attaquer le refactoring du bien-nommé Ugly Trivia.

L’atelier s’est déroulé en quelques étapes, de manière itérative :

1. Identification des code smells
2. Recherche de solution pour rendre le code plus robuste (en utilisant des techniques simples, comme limiter les types primitifs, casser les successions de if, forcer le système à gérer les erreurs dès la compilation, …)
3. Implémentation de cette solution
4. Contrôle de la non régression grâce aux tests “Golden Master“

Exemple de refactoring possible

Un exemple assez simple de conception qui permet de limiter le risque de bugs. Admettons que l’on souhaite modéliser un menu dans un restaurant.

public Menu() {

}

Le constructeur vide nous permet d’avoir un menu vide (ce qui n’est probablement pas le besoin métier), on ne sait pas s’il est possible d’avoir juste un entrée ou un plat, … Bref, c’est très peu parlant.

On peut prendre la décision de faire un constructeur en fonction des contraintes métiers. Si on souhaite rendre obligatoire la formule “entrée-plat-dessert”, on peut proposer un seul constructeur de ce style :

public Menu(String mainCourse, String starter, String dessert) {
    // attention à l'ordre...
}

Par contre, on réalise assez vite qu’un tel code est assez peu lisible, car l’ordre est capital, et on pourrait tout à fait se retrouver avec une tarte aux pralines en plat principal … Un bel exemple de primitive obsession.

On peut alors appliquer une pratique centrale du DDD, l’utilisation de value object

public Menu(MainCourse mainCourse, Starter starter, Dessert dessert) {
    // oh yeah!
}

Le code devient alors plus robuste (impossible de faire une erreur dans l’ordre des paramètres), les classes créées peuvent être porteuses de leur propre comportement, …

Ressources

Si vous voulez faire ce workshop, toutes les informations sont disponibles à cette adresse : https://github.com/martinsson/BugsZero-Kata

 

Bug free by design – Johan Martinsson

Après le workshop, la conférence ! Johan nous a donné 21 petites astuces pour rendre son code plus robuste.

Les slides sont ici : http://www.changit.fr/bug-free-by-design et la session filmée ici : https://vimeo.com/269838283

Si ce sujet vous intéresse, je vous conseille également les conférences/live codings de Thomas Pierrain et Bruno Boucard :

• Legacy Club
• Du DDD dans mon legacy

 

Vous arrive-t-il d’infliger de l’aide ? – Julie Quille

Ce talk a été l’occasion de réfléchir sur la manière dont on propose (parfois impose) son aide à ses collègues. Ce talk a le mérite de nous rendre vigilant à la manière dont on peut proposer son aide, s’assurer qu’elle soit réellement souhaitée par l’autre, …

Ce que j’en ai retenu :

• Attention à ne pas faire à la place de …
• Prendre le temps de ralentir pour expliquer ce que l’on souhaite
• Résister à l’envie d’en faire trop, et à ne pas sortir du domaine sur lequel on nous a demandé de l’aide
• Reformuler les demandes exprimées, et valider avec son interlocuteur ce qu’il demande vraiment
• Reformuler jusqu’à avoir des objectifs actionnables

Ressources

La conférence est visible ici : https://vimeo.com/album/5133908/video/267814401

 

Comment le gouvernement néo-zélandais s’inspire de l’agilité pour améliorer les conditions de vie ? – Jonathan Scher

Jonathan est un coach agile qui a eu la chance de partir en mission en Nouvelle-Zélande en tant que coach agile, pour auditer une initiative publique un peu particulière. Différentes agences gouvernementales se sont réunies pour réfléchir à la manière dont ils pouvaient résoudre des problématiques sociales rencontrées par leurs citoyens, dans les zones les plus défavorisées. Il a principalement parlé des problèmes rencontrés par certaines personnes qui ne trouvent pas d’autre solution que de conduire sans permis (la procédure pour passer son permis étant plus complexe dans ce pays).

Le gouvernement a donc mis en place une task force issue des différentes agences gouvernementales, qui a mis en place une démarche de design thinking. Elle a procédé de la manière suivante :

• Frame : cadrer le périmètre d’action
• Explore : interviewer les populations avec empathie, découvrir le quotidien des personnes concernées, définition de personas, …
• Imagine : brainstormer sur les solutions envisageables
• Test : mettre en place un environnement de test, où il est possible d’échouer, de redéfinir les modes d’actions, …

Le résultat a été convaincant, des actions ont pu être mises en place pour faciliter le passage de permis pour les personnes avec une promesse d’embauche, et Jonathan a pu bénéficier des actions mises en place par son propre client.

Finalement, c’est plutôt de l’autre côté du globe que la startup nation est en marche.

Ressources

Les projets menés par cette équipe sont tous disponibles ici : https://www.aucklandco-lab.nz/what-we-do/drivers-licensing/

La conférence est disponible ici en vidéo : https://vimeo.com/album/5133908/video/267755888

1 Pixel Per Second – Simon Baslé

Spring a été très présent sur cette édition de MiXiT (le co-créateur du framework a même fait une rétrospective sur les 15 ans du projet lors d’une keynote). Ce talk, réalisé par Simon (membre de l’équipe Spring chez Pivotal), a été l’occasion d’enfoncer le clou sur les nouvelles fonctionnalités de Spring 5 et Spring Boot 2 avant de mettre ça en place sur nos prochains projets.

Il s’agissait d’un live coding d’une plateforme de pixel art collaboratif, avec gestion des droits, API réactives, le tout, mis en production en utilisant les services de Clever Cloud.

Malheureusement, le timing a été trop juste et le live coding n’a pas pu être terminé.

Petite parenthèse au passage : le site de MiXiT a été développé par Sébastien Deleuze, également membre de l’équipe Spring chez Pivotal, en Spring Boot 2 et Kotlin, et est open-source

 

Les sources sont disponibles ici : https://github.com/simonbasle-demos/collaborativeCanvas/tree/complete, et la conférence visible ici : https://vimeo.com/album/5133908/video/267774010

Mentoring à tous les étages – Nicolas Savois & Aurélie Ambal

Nicolas (CTO) et Aurélie (développeuse) ont fait part de leur expérience de mentor/mentorée à la Société Générale. Ils ont abordé les bienfaits de cette pratique, les pré-requis et de la manière dont ça a été mis en place.

Les points que j’ai retenu :

• le ou la mentor doit faire en sorte de sortir le ou la mentoré·e de sa zone de confort, sans aller trop vite/trop loin
• le ou la mentor ne doit pas forcément faire partie de la même équipe, les objectifs fixés ne doivent pas forcément être liés au projet en lui-même
• le mentoring a des avantages pour tout le monde : mentor (sentiment d’être utile, apprendre à connaître les gens, …), mentoré·e (pas laissé·e à l’abandon, intégration et progression plus rapide), entreprise (production de valeur plus rapide, détection rapide des erreurs de castings, …)
• le premier entretien est l’occasion de définir des objectifs actionnables que l’on suivra tout au long de la relation
• la seule interruption acceptée est le andon (terme issu du lean management) : un·e mentoré·e bloqué·e doit impérativement faire appel à son mentor pour essayer de trouver un moyen de se débloquer seul·e

Un manifeste a été écrit pour mettre un cadre autour de cette relation particulière :

Devenir un meilleur moi plutôt qu’imiter un modèle

Trouver des solutions ensemble plutôt que fournir des solutions miracles

Un suivi adapté plutôt qu’un suivi dogmatique

Une relation de confiance plutôt qu’une relation hiérarchique

La conférence est visible ici : https://vimeo.com/album/5133908/video/267996456

Conclusion

Cette première expérience a été particulièrement concluante, j’ai été séduit par l’esprit de la conférence, la qualité de ses talks, …

C’est certain, avec l’ouverture imminente de l’agence Lyonnaise d’INEAT, nous y reviendrons en force !