SoCraTesFR (Software Craftsmanship and Testing Conference) est une conférence craftsmanship qui se déroule en Allemagne depuis 2011. Il s’agit d’une conférence open space aussi appelée unconference.
Houssam Fakih a pris l’initiative d’organiser cette année une version française de SoCraTesFR.
Franziska Sauerwein (@Singsalad) a accepté de jouer le difficile rôle de facilitatrice de la conférence.
Un immense merci Houssam et Franziska ! SoCraTesFR 2015 sera sans doute l’un des meilleurs moments de ma vie de développeur !
Dans une conférence traditionnelle, le programme est établi à l’avance. Les organisateurs sélectionnent les sepakers en amont. Vous savez qui va parler et de quoi. Les participants sont essentiellement spectateurs de la conférence.
L’événement a eu lieu dans la Drôme, dans un lieu un peu particulier, le château de Rochegude… Du Jeudi 24 septembre au samedi 25 septembre, SoCraTesFR a réuni une trentaine de softwarecrafts(wo)men.
Pour vous imprégner de l’ambiance : #socratesfr
Échanges non-stop à SoCratesFR !
L’envie de partager et l’enthousiasme des participants sont ce qui m’a le plus marqué à SoCraTesFR. Les participants, tous passionnés, partageaient sans cesse leurs expériences, leurs lectures et leurs réflexions. Nous échangions sans arrêt, lors des sessions, au petit déjeuner, aux poses, aux repas, dans la soirée, dans la nuit… Pour ma part, j’ai beaucoup discuté d’agilité et de craftsmanship hors des sessions. Même si des sessions tournaient autour du craftsmanship j’ai dû me résoudre à y renoncer afin de pouvoir participer à d’autres types de session ! Lors des repas, certaines tables proposaient un thème de discussion : « Comment recruter des craftsmen ? », « Comment avoir une revue d’un talk ou un article de blog ? », …
Jeudi 24 septembre 2015, que s’est-il passé ?
Un kata de refactoring en mode mob programming se met rapidement en place. Dans ce type de kata, un seul ordinateur, les participants prennent donc tour à tour le clavier. Pour commencer nous modifions le code à l’aide des outils de refactoring automatisés de l’IDE (IntelliJ). Les dépendances statiques sont isolées. Ensuite, nous écrivons des tests unitaires. Pour cela, nous utilisons junit-dataprovider pour tester plusieurs couples input/output, ou encore JunitParams ou le runner Parameterized de JUnit pour écrire des tests paramétrés avec JUnit.
Après le dîner, un « World Café » est mis en place. Les participants sont regroupés autour de tables où l’on a disposé de grandes feuilles, des « posters ». Ils discutent des sujets qu’ils souhaiteraient aborder ou de ce qu’ils voudraient faire les deux prochains jours. Au bout d’une vingtaine de minutes, nous changeons de table. Les idées déjà inscrites peuvent nous en donner de nouvelles.
Cette session de tables rondes a permis d’élaborer six posters :
Le contenu de SoCraTesFR commence à se dégager : tests (normal vu l’intitulé de la conférence 😉 ), DDD, SOLID, programmation fonctionnelle, CQRS, craftsmanship, Javascript, Docker, … Après, reprise du kata ! Nous pouvons refactorer le code couvert par les tests sans les outils automatisés de l’IDE. @acraphae s’apprête à prendre possession de l’ordinateur du kata.
Vendredi 25 septembre 2015, que s’est-il passé ?
Les participants souhaitant proposer un sujet de discussion ou une activité se répartissent en deux files. A tour de rôle, ils collent un post-it sur un poster représentant l’ordre du jour de la journée. Si l’un d’entre eux a plusieurs propositions il est obligé de faire la queue plusieurs fois.
Bien sûr, il s’ensuit une phase de «négociation» ou des participants tentent d’influer sur l’ordre des sessions. 😉
Une fois l’ordre du jour établi, le choix entre plusieurs sessions en parallèle a parfois été difficile. Quand le contenu le permet, les sessions donnent lieu à un poster où nous notons les idées abordées. Les posters de SoCraTesFR ont été photographiés par Franziska qui a ensuite publié les photos ici
Property-based testing (@malk_zameth)
L’idée est d’injecter des données respectant certaines propriétés et de vérifier les propriétés des données en sortie. Cette approche est adaptée à l’exploration d’un legacy. Les exemples donnés utilisaient junit-quickcheck
Design for composability (@cyriux)
Éléments qui favorisent ou cassent la composabilité du code : poster
Pair programming practice (@m_baechler)
Nous avons appliqué des tests unitaires sur de la programmation concurrente en Java 8.
Architectural kata (@cyriux)
Votre mission, concevoir l’architecture d’un système permettant à une flotte de vendeurs de hot dogs d’être réapprovisionnée et de communiquer sur les réseaux sociaux. Les détails ici
Plusieurs équipes d’architecte en herbe s’affrontent. L’équipe victorieuse a proposé la solution la plus simple et la moins coûteuse répondant au besoin du client.
Vous voulez vous entraîner à des katas d’architecture ?
Accidental complexity (@Lilobase)
Comment éviter la complexité accidentelle ?
Poster
Liskov substitution principle (@malk_zameth)
Rappels sur le principe de substitution de Liskov
Un retour détaillé dans ce billet par @jfsaguin
Après le dîner, plusieurs lightening talks ont lieu : congruent design (@cyriux), CQRS « framework » (@Ouarzy), …
Ensuite, nous sommes plusieurs à reprendre le kata commencé jeudi. Nous appliquons le property-based testing vu dans la journée. Pendant le kata, un petit groupe assis derrière moi discute de craftsmanship. Les échanges m’interpellent. Je décide donc de quitter le kata pour les rejoindre, s’en est suivi des discussions jusque tard dans la nuit.
Samedi 26 septembre 2015, que s’est il passé ?
Nous établissons l’ordre du jour comme pour le vendredi matin.
Du TDD en C++ (@JeromeAvoustin & @brunoboucard) Nous l’avons fait !
Exchange on Object-Oriented Programming & Functional Programming (@PatrickGIRY & @Lilobase)
Durant cet atelier nous sommes revenus aux bases des programmations orientées objet et fonctionnelle. Nous avons ainsi abordé les définitions d’objet et de fonction.
Common DDD mistakes (@clem_bouillier)
Durant cette session, inspirée d’un article de Daniel Whittaker, nous nous sommes intéressés aux principales erreurs commises en Domain Driven Design (DDD).
Posters :
(1) https://drive.google.com/file/d/0B90yjzn99fqfdXN0RW14Sm1UMWM/view?pli=1
(2) https://drive.google.com/file/d/0B90yjzn99fqfaHRBWjN5dG5BMTg/view?pli=1
Living Documentation (@cyriux)
Que faut-il documenter dans un wiki par exemple ? La documentation est-elle à jour ? Cyrille a réfléchi de manière approfondie sur la manière de documenter une application. L’idée d’une « documentation vivante » est apparue dans le livre « Specification By Example » de Gojko Adzic. Les tests automatisés, intrinsèquement synchronisés avec le code qu’ils décrivent, constituent une source de documentation. Dans une approche Domain Driven Design, les classes sont annotées avec @Entity , @ValueObject, @DomainService, @CoreConcept, … Le glossaire du domaine métier de l’application est alors généré automatiquement en détectant ces annotations lors d’un parsing du code. L’animateur présente aussi un nuage de mots obtenu en analysant le code de l’application. Si le code est écrit dans une approche DDD, les mots du métier apparaissent alors clairement dans le nuage. Des idées très intéressantes…. Pour aller plus loin, Cyrille a bien avancé l’écriture d’un livre sur le thème de la documentation vivante !
Troll fest! (@jeanhelou)
Chateau de Rochegude, samedi 26 septembre, 15h. La fin de SoCraTesFR approche. Lors de cette session, les participants sont invités à « troller » sur les langages et à se « lâcher »… Résultat, « Scala fait chauffer la machine ». « Scala c’est lent ! », précisons tout de suite « à la compilation » avant d’être accusé d’être de mauvaise foi. 😉 Javascript en a pris pour son grade. 😉 Un participant relate un souci dans sa suite de tests dans ce fabuleux langage. parseInt(« 08 ») ne donne pas vraiment le résultat auquel on s’attendrait…
SoCraTesFR, et si on se disait à l’année prochaine ?
Avant notre départ nous faisons la rétrospective de SoCraTesFR 2015. Franziska demande à chaque participant d’écrire une lettre afin de figer son ressenti sur les moments passés à SoCraTes. La lettre a ensuite été insérée dans une enveloppe libellée à l’adresse du participant. Hâte de recevoir ma lettre ! Je m’attends à ce que de très bons souvenirs ressurgissent !
J’ai vraiment apprécié l’envie de partager, faire et réfléchir ensemble lors ce SoCraTesFR.
Vous pouvez vous faire une idée de SoCraTes en participant le temps d’une soirée au Software Craftsmanship meetup à Paris, Lyon, Toulouse ou Lille.
Une nouvelle aventure SoCraTesFR aura lieu l’année prochaine ! Je recommande vivement !
Comme l’annonçait l’un des leitmotivs de la version 2015 : « Be prepared to be surprised ! »
Auteur : Jean
