Mob atelier TDD et DDD, vers une architecture Hexagonale fr en

En 3 ou 4h, nous allons apprendre à mettre en oeuvre le TDD de manière concrète, avec une approche DDD pour un cas métier, et des adapters vers des services externes. Un cas simple qui fait se poser beaucoup de question. Préparez vous à être surpris.

Comprendre les tests unitaires et le besoin de doublures dans un début d’architecture hexagonale; clarifier ce que l’on appele doublure de tests.

TDDD : Hexagonal testing with Doubles fr en

You're asking yourself: how to practically isolate my domain code from moving parts like databases or external systems, APIs... in the simplest way either. How can I do that without integration testing. Are Unit Test sufficient? Can I apply TDD literally?
I've heard about mock as a perfect solution to test my dependencies.
Well, we need to talk. Better than that: we need to code!
Let's work on a very concrete and representative example. And let's mob it!

Format: 3/4h ( live coding/workshop) ; fish bowl MOB programing
Isolate domain rules and invariants
Add external system and test then
Learn about test doubles : stubs, spy, fake, mocks
When and how to use it? How to avoid mocks.

We will work on Concrete examples:
- ask time / generate random values (like UUIDs)
- send a mail / print an invoice
- access to an external resource (like a file)
- invoke a read/write repository
- summon an API
Showing what’s legitimate and what’s beyond reason

Profession Développeur: prisme de la société ou singularité? en

Assurément, mon titre aurait dû être "Profession développeur-euse"... et ce sera là mon premier constat :
Qu'avons-nous de si particulier pour que les femmes soient à ce point sous-représentées ?
Et, si c'était là le seul biais... il y en a tant d'autres.

Après 30 d'évolution dans ce métier, je propose une véritable introspection.
Que dis-je ? Une catharsis !!
J'aborderai des sujets sociétaux, mais également des aspects socio-économico-professionnels.
Mais, aussi un peu de technique. Car nous, Développeurs/euses, nous adorons nous compliquer la vie pour paraitre toujours plus des incontournables. Hors, personne n'est irremplaçable, et le mythe du Cowboy coder macho n'a pas encore disparu :(

L'idée est de faire réfléchir tout le monde à la place des uns et des autres dans cet univers particulier qu'est la création de logiciels.

Ecologie du logiciel, en route vers la simplicité en fr

Dès le début du projet, les équipes se perdent dans la complexité
technique, organisationnelle et par manque de clarté dans la vision PM/PO...
La complexité est la soeur jumelle de l'entropie, elles augmentent exponentiellement au cours de la vie du produit.
Nous nous pencherons sur une adaption des principes d'entropie et néguentropie sur l'axe du Product Management et sur l'axe technique.
La complexité est même souvent accidentelle. Une fois installée, elle est difficilement réversible.
“Faire simple c’est difficile”.

Nous vous proposons de voir des stratégies simples, mais exigeantes, pour une simplicité retrouvée et un développement logiciel soutenable.

Ecologie du logiciel, en route vers la simplicité en fr

Dès le début du projet, les équipes se perdent dans la complexité
technique, organisationnelle et par manque de clarté dans la vision PM/PO...
La complexité est la soeur jumelle de l'entropie, elles augmentent exponentiellement au cours de la vie du produit.
Nous nous pencherons sur une adaption des principes d'entropie et néguentropie sur l'axe du Product Management et sur l'axe technique.
La complexité est même souvent accidentelle. Une fois installée, elle est difficilement réversible.
“Faire simple c’est difficile”.

Nous vous proposons de voir des stratégies simples, mais exigeantes, pour une simplicité retrouvée et un développement logiciel soutenable.

Développeurs·euses : facilitez-vous la vie en (re)apprenant à lire. en

Dans nos écoles, nous avons appris à lire avant de savoir écrire. D'après les méthodes usuelles d'enseignement, Comprendre un texte, c’est se faire une représentation mentale cohérente qui intègre toutes les informations du texte. Ces principes s'appliquent tout aussi bien à la compréhension de n'importe quel code logiciel. Car nous avons tous fait l'expérience de lire du code qui ne nous appartenais pas ou même nos propres productions.

Nos constats sont les suivants:

Il est souvent difficile et compliqué de lire ou de relire un code source.
C'est une activité pénible et démotivante pour grand nombre des développeurs.
Et si la raison ne tenait qu'a notre méconnaissance des mécanismes de fonctionnement de notre cerveau ?

Venez explorer, expérimenter et apprendre comment fonctionne notre cerveau lors d'un atelier de lecture d'un code source Et tirez profit de ces nouvelles connaissances pour améliorer vos capacités de lecture ainsi que la lisibilité de votre code source.

L'atelier se base sur les exercices proposés par Felienne Hermans dans son ouvrage "The Programmer's Brain".

TestContainers: turning the Pyramid of Tests upside down en fr

Docker has changed the world of IT (and is still changing it). It's not just about infra or ops. It really is devOps. And in devOps, there's dev.
Developers have everything to gain from using Docker, but sometimes it can seem complicated or cumbersome. That's where TestContainers come in. A technology available for a large number of development frameworks (Java/Kotlin, Python, NodeJs, .Net, Ruby...) . It will change the way you think about unit and integration tests.
As I will show you working code and tests, this will be a good opportunity to return to the true meaning of some magic terms and to talk about the famous test pyramid, once again.

slides are here https://docs.google.com/presentation/d/1TMiNdJxUmbzkcGPHCEuW9_qKHI4uglVcMzFR0Ic8pTc/edit?usp=drive_link

This session comes with a hands on lab , using Kotlin, and presenting a concrete example of testing the Hexagonal Architecture with and without Test Containers
Code is here:
https://github.com/Guillaume-Music-Action/Tester_Hexagone_Parcmetre
https://github.com/music-action/how-to-test-the-hexagon-kotlin-2024

JAVA: 2 weddings and a funeral en

Java is old. But Java is moving.
Let's dive into history,what are the major changes other the years.
Discover the good, the bad and the ugly.
Let's look to the future !
New way of programming is reaching the Java community (too).
But is not always clearly understood. And even less apply.
Let's demystify the progress. New times are now!

You will learn how Java evolved quickly recently and try to understand why people are slower to make the move.
Also, we will cover the true game changer in Java programming styles and foresee how to move to more modern patterns: the functional way !

Monads without Maths, but with Cats (live coding) en fr

You heard about Monads, but the maths behind it seems unreachable? Let's demystify it with an
hands on lab based on TDD and C#/Java/Kotlin (your choice) to simply have fun with Monads and never be afraid of them.
We will auto-learn about simplicity, clarity, Unix style, and fun(ctors).

PLan:
Common Issues in Code
Basic Principles of a Monad
A Simple Case: Option
Where to Find Monads?
Hands-on: TDD Mob Programming
What to Do with a Monad?
Further with Either... or Maybe
Let's Chain, Let's Bind...
Practical Case: Monads in a Web API
Further: Validation
Attention: Treat Your Monad with Respect
Comparison of Styles (What Is Complexity?)

https://docs.google.com/presentation/d/1VPWqxxqrudsR001B0mXeSCY3bdjvT_xdqbsCxj3Kqck/edit?usp=sharing

Workshop: Practical guide to Monads for those who don't like maths en

You heard about Monads, but the maths behind it seems unreachable? Let's demystify it with an
hands on lab based on TDD and C#/Java/Kotlin (your choice) to simply have fun with Monads and never be afraid of them.
We will auto-learn about simplicity, clarity, Unix style, and fun(ctors).

PLan:
Common Issues in Code
Basic Principles of a Monad
A Simple Case: Option
Where to Find Monads?
Hands-on: TDD Mob Programming
What to Do with a Monad?
Further with Either... or Maybe
Let's Chain, Let's Bind...
Practical Case: Monads in a Web API
Further: Validation
Attention: Treat Your Monad with Respect
Comparison of Styles (What Is Complexity?)

the code:
https://github.com/guillaumeagile/MonadsFromTheTrenches_workshop
the slides:
https://docs.google.com/presentation/d/1VPWqxxqrudsR001B0mXeSCY3bdjvT_xdqbsCxj3Kqck/edit?usp=sharing

Petits biais et grands travers du développement logiciel en

Faire partie de la grande famille des développeurs... quoi de plus rassurant? Nous aurons du travail à l'infini.
Oh, vraiment?

Nous savons coder, nous savons faire ce que les autres ignorent. Nous sachons. Nous dirigeons le monde. Car le logiciel dirige le monde.
Ils exigent de nous de la rapidité, pas de problème, nous livrerons à temps.
Puissants et obéissants, quel joli paradoxe.

Et pourtant, nous ne sommes pas au dessus de la mêlée.
Cette belle profession a besoin d'un bon coup de ménage, et surtout de balayer ses propres certitudes.
Let's do it!

Le monde n'est pas CRU(D), il est vivant! en

"Tu veux un logiciel? bah tu n'as qu'à prendre une base de données, un ORM, rajoute une API REST" (parce que c'est la mode) :
"et voila!"

Ajouter, modifier, supprimer... et se planter!
Tout ce qui vient avec le monde CRUD est une simplification de la réalité qui fait froid dans le dos. En étant aussi simpliste, les applications en deviennent horriblement complexe: transactions, verrous, exceptions, mutations... que des sources d'ennuis.

Venez voir comment on peut se débarrasser du mal à la base. Oui le monde évolue en permanence, et votre façon de programmer aussi.
Trop compliqué? En 1h30 de live coding, donnez naissance à du code fermé à la modification mais ouvert à l'infini.

Développeurs, réduisez votre charge mentale! en

Haaaaa, la charge mentale. Encore un truc de coach agile :D
Et si nous appliquions le concept aux développeurs et aux testeurs?
Imaginons nous réellement tout ce qui ce passe dans la tête de ceux ci? et surtout comment faire pour alléger la pression!
Des moyens, il y en a tellement.
Et pourtant, les développeurs eux même rechignent à simplifier leur code.
Allons voir ensemble pourquoi...

L'invasion des mutants dans votre code (oui mais pour votre bien) fr

Tester c'est être agile, car c'est être confiant dans le produit qu'on livre. Vous faites probablement du TDD, ou au moins vous essayez d'écrire des tests. Vous vous vantez même d'avoir une bonne couverture. Mais résisterez vous à l'invasion des mutants?
Cette pratique de test peut faire peur, et pourtant... Quelle puissance! Quelle exigence!
Ce n'est pas (que) un outil de test, c'est (aussi) le gardien de la qualité de votre code. Et il ne tergiversera pas!
Etes vous prêts?

Tout ce que vous avez voulu savoir sur les Doublures de Tests sans jamais avoir osé le demander fr

Vous vous posez des questions sur les doublures de tests ou ce qui est généralement et abusivement dénommé “mocks”.
Venez apprendre et comprendre ce que sont les bouchons, dummy, stubs, fake, spy et mock. Quand et pourquoi les utiliser en situation réaliste, et l’usage d’un fake versus un spy.

DDD: des outils pour le PO (mais pas que) fr

"Ce qui part en prod, c'est ce que le dev a compris", cette phrase n’est pas anodine et Guillaume l’utilise même souvent.

La relation entre le PO et les devs devrait être fusionnelle, au moins intense, animée, vivante et surtout permanente. Le PO doit parler le langage de son client et de son univers (le fameux "domaine"). Le dev doit parler le langage du PO.
Transitivité : Le dev doit parler le langage des utilisateurs, même et particulièrement dans son code. C'est un des piliers de DDD (Domain Driven Design). Mais sans le PO, le dev ne peut pas y arriver.
DDD vient avec une foule de sages conseils et d'outils extrêmement pratiques. Bien connus des développeurs, ils sont encore trop confidentiels dans le monde des POs/PMs.
Je vous invite à une rencontre...

Les monades sans les maths (live coding) en fr

Les monades ne sont pas qu'un OVNI mathématique, mais un vrai paradigme de programmation qui peut s'utiliser à peu près partout dans votre code.
Quel que soit le langage. Peu importe les situations.
Je vous propose une brève intro orientée "pratique" et surtout du live coding avec du TDD pour démystifier la librairie LanguageExt que nous avons en C# / .Net

Vous allez voir, ça ne mord pas, ça ne griffe pas.

Etes vous prêt à arrêter de coder avec des null, des if, des loops, des exceptions et tout autre cochonnerie ?

slides:
https://docs.google.com/presentation/d/1VPWqxxqrudsR001B0mXeSCY3bdjvT_xdqbsCxj3Kqck/edit?usp=sharing

TestContainers: la révolution pour vos tests unitaires en fr

Docker a bouleversé le monde de l'informatique (et est encore en train de le faire). Ce n'est pas qu'une affaire d'infra ou d'ops. C'est vraiment du devOps. Et dans devOps, il y a dev.
Les développeurs ont tout à gagner à utiliser Docker, mais parfois cela peut paraitre compliqué ou lourd. C'est là qu'entrent en scène les TestContainers. Une technologie disponible pour un grand nombre de frameworks de développement (Java/Kotlin, Python, NodeJs, .Net, Ruby...) que je vous propose d'utiliser pour vos tests unitaires et d'intégration ; une bonne occasion de revenir sur le vrai sens de ces 2 termes et de parler de pyramide de tests, une fois de plus.

slides are here https://docs.google.com/presentation/d/1TMiNdJxUmbzkcGPHCEuW9_qKHI4uglVcMzFR0Ic8pTc/edit?usp=drive_link

This session comes with a hands on lab , using C# or Kotlin, and presenting a concrete example of testing the Hexagonal Architecture with and without Test Containers
Code is here:
https://github.com/music-action/how-to-test-the-hexagon-kotlin-2024
https://github.com/Guillaume-Music-Action/Tester_Hexagone_Parcmetre

Comment embarquer PO, Devs, Testers, SM dans le même bateaux en 4 ateliers fr

DDD ou Domain Driven Design rassemble une foisonnante palette d'outils qui s'adressent à tous les membres qu'un équipe ou entreprise Agile.
"Ce qui part en prod, c'est ce que le dev a compris", cette phrase n’est pas anodine.
Avec Rachel Dubois, nous avons entrepris de présenter un certain nombre d'ateliers phares pour faire toucher du doigt la réalité de DDD et de ses bénéfices.

Nous vous proposons de revenir sur les temps forts de ces ateliers : Domain Story Telling, Event Storming, Context Mapping, Wardley Mapping, et même Mob Programming.

Nous y avons embarqués avec joie autant de SM, PO, testeurs/euses et devs.
Les Grenoblois résisteront-ils à la tentation de nous rejoindre ?