Speaker

Guillaume Saint-etienne

Guillaume Saint-etienne

Senior Coder, Dev Advocate, Software & Team Architect

Dévelopeur Senior, Artisan Logiciel, Architecte, Lead Equipe

Toulouse, France

I'm a software coder since my first ZX81 at 11 yo (guess my age) and agile practitioner since 2006.
Kotlin and C# fanboy. Monads saved my life. Currently working for ITER organization.

J'ai écrit mes premières lignes de code à l'age de 11 ans sur un ZX81. J'ai développé des écrans Videotex
Je suis artisan développeur depuis 30 ans déjà, élève de Laurent Bossavit, Jonathan Peret et Olivier Azeau.
J'ai été aussi architecte logiciel, chef de projet, responsable d'équipe , j'ai travaillé pour diverses ESN et éditeurs logiciels, dont Varian Medical Systems pendant 10 ans, Primobox plus récemment.
Codeur C# + JS depuis le début, j'ai récemment plongé dans Kotlin avec délectation. Je pense que bien développer c'est: 70% de discussion, 20% de tests, 10% de code.

Area of Expertise

  • Information & Communications Technology

Topics

  • TDD
  • ATDD
  • Domain Driven Design
  • Clean Code
  • Clean Architecture
  • Hexagonal Architecture
  • Lean Software Development
  • Agile software development
  • 🙋 Soft skills for developers
  • C#
  • .net core
  • Kotlin
  • Software Craftsmanship
  • Modern Software Development
  • Event Storming
  • CQRS & Event Sourcing

Sessions

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 !

Hexagonal Architecture, let's test! en

The hands-on workshop for Hexagonal Architecture, Clean archi, Onion layers, etc... you name it.
One of the most discussed software architectural pattern.
And subject to a wide range of various interpretations.
You may already know a bit or a lot about it.
But what's its advantage, whenever you implement it?
Tests !!!!
You want to experience them for real ?
So let's dive into practical and real life examples and tactics.
Mob coding coming from excerpts from the trenches.
TDD all the way. C# Net Core or Kotlin. CI/CD in mind.
Unit tests, mocks, fake, ArchUnit, Mutation testing in one day.

A practical workshop to show you how to decide between unit test, integrations and so on. Mock it or fake it? Fake it until you make it? Let's go deeper into a concrete, full working example.

Worskhop sources:
https://github.com/music-action/how-to-test-the-hexagon-kotlin-2024

How to test the Hexagon? en

You've probably heard or even practice Hexagonal Architecture, Clean architecture, Onion layers... you name it.
Perhaps one of the most discussed software architectural pattern.
Strangely, its implementations are subject to a wide range of interpretations.
But, undoubtedly, its major advantage, whenever you implement, is ... Testability !!!!
Somehow, it has been forgotten.

So let's dive into practical, real life examples and tactics.

Quick Live coding and samples from the trenches included.
TDD all the way. C# Net Core or Kotlin.

This conference comes with a workshop where you will mob on a concrete example.
https://github.com/music-action/how-to-test-the-hexagon-kotlin-2024

Slides are here:
https://docs.google.com/presentation/d/1SSBVGOQQK-vMRIJfDtYu-01PGvweMvcTnQx9a4wkHHE/edit?usp=drive_link

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

What is simplicity, really ? en

Define simplicity is no simple.
Everyone has its own definition
Simplicity is cultural
Simplicity is hard
Simplicity is not a bestseller
Simplicity is not speed
Do we (really) learn simplicity?

after those fundamental questions, we will dive into some real life experiences (of mine):
Strategic Simplicity
- In Product Vision
- In design

Tactical Simplicity
- In architecture
- In code
- In testing strategy

Unfortunately, we'll cover a lot of fallacies. Because, once again, simplicity is not obvious, for humans at least.

A basis for a general discussion on the necessity of KISS that remains hard to achieve.

Refactoring Objects to Calesthenics then to Functional Style, step by step en

We gonna start with a legacy code written in Java.
In Ensemble (Mob) Programming, we will clean the mess a bit, then at some point see if some Functional Style could also leads us to clarity and simplicity.
Of course, we do TDD all along. Let's code with more fun.

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!

Mental load for developers, how to reduce it ? en

As a developer, you may have asked yourself that question: why is it so difficult? why is my brain twisting when I see that code? Is it too complex? too simple?
Those questions are simply about the cognitive efforts required when doing or entering a project.
Is there way to tackle it? at least lower it?
But what if, complexity (and its counterpart, simplicity) might not have the same definition for everybody?
Well, we will show up how and why mental load applied to software development is a trap.
And, as Franck Herbert said: “Knowing where the trap is—that's the first step in evading 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.

Ensemble programing: revue de code et refactoring par petits pas en

Cet atelier vous permettra de travailler vos revues de code, et de refactorer en toute sécurité grâce à une bonne couverture de test.

Pas à pas, nous travaillerons sur une base de code très améliorable (à dessein), et nous appliquerons un à un des contraintes de qualité, dont nous discuterons ensemble dans une phase préalable de revue de code.
Ensuite, tous ensemble (mob programming), au boulot ! Il nous faudra améliorer, c'est-à-dire refactorer, sans casser le comportement attendu. Pas de panique, nous fournissons les tests automatisés.

Cela nous permettra d’apprendre différentes techniques de factoring , utiles à la maintenance et lisibilité de votre code.

Cet atelier se base sur le kata de Pedro Santos.

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...

Code Kata "Tell Don't ask" en

Une session de code Orienté Objet (C#) qui va se rapprocher d'un mob programming (selon le groupe) et se concentrer autour de la SOLIDité du code écrit.
Pas besoin d'être expert en programmation pour s'intéresser à travers un exemple très simple aux dilemmes quotidiens du développeur.
Une façon aussi de discuter de nombreux autres aspects du code orienté objet: testablilité, évolutivité, expressivité. Et bien sûr tout cela en TDD.

La fracture Agile avec les développeurs en

"Agile is almost over" a encore dit récemment Brian Marick. Il y en a pour qui c'est depuis longtemps le cas, ce sont les développeurs; tendons le micro pour comprendre la grogne et ne pas tomber *encore* dans la taylorisation ou la fuite facile de l'Agile vers le Non-IT

Cuisines et Dépendances en fr

Un travail d'équipe dans le monde numérique est fait de relations complexes. Humaines et techniques. Des liens se tissent et très vite les problèmes apparaissent. De mon expérience de software craftsman j'ai poussé la réflexion bien plus loin sur nos dépendances dans le travail et ce que nous pouvons en faire.

Cuisines et Dépendances en fr

Un travail d'équipe dans le monde numérique est fait de relations complexes. Humaines et techniques. Des liens se tissent et très vite les problèmes apparaissent. De mon expérience de software craftsman j'ai poussé la réflexion bien plus loin sur nos dépendances dans le travail et ce que nous pouvons en faire.

Agilité pour l’échafaud en

Cela aurait pu être le titre d'un film. Cela avait commencé sous un autre titre: "Agilité à l'échelle". Mais bien vite, le principe de réalité est venu frapper à la porte. Comment tout ces beaux frameworks si bien pensés peuvent ils échouer? Retours du terrain, panorama des recettes bien concoctées qui finissent par un plat cramé.
Et un bouquet final avec des idées pour rattraper la sauce.
A vos marmites!

10 years challenge: même code, même team, même produit en

Pour la grande majorité des développeurs (ceux ci étant en majorité employés dans des ESN) les projets s’enchaînent et ne se ressemblent pas. Sans compter les effets du turn-over sur la qualité de ce qui est produit.

J'ai connu cela durant mes 15 premières années de carrière.

Et tout d'un coup, l'âge de raison sûrement, je fût pris il y a 10 ans dans une aventure au long terme. Déboussolant ou rassurant? Peut être les deux. Mais cela ne s'est pas fait par hasard.

Laissez moi vous raconter ce qui m'a permis de rester contre tout attente avec la même équipe et le même code durant toutes ces années.

Venez découvrir les raisons d'une telle longévité, avec comme défi permanent de produire du code pensé pour durer. Et c'est du .Net !

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...

Ecologie du logiciel, en route vers la simplicité 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.

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?

Le long voyage sur Mars de 3 explorateurs du code fr


Deux développeurs et un coach agile embarquent à bord d'un rover pour un long voyage sur Mars.
Un kata d'apprentissage pas uniquement technique revu et revisité pour mener l'exploration à son terme. Mais que veut dire "mener à son terme" pour ce groupe ?
Notre attention initiale était de développer complètement ce kata en poussant son développement vers une architecture de type hexagonale nous permettant ainsi de couvrir une large plage de problématiques.
C'était une idée un peu folle, car contraire au principe des coding dojo "traditionnel" où un groupe se retrouve le temps d'une séance en ayant aucun enjeux sur le point d'arrivée.
Ici nous inversons la proposition, tenons sur la durée et poussons un kata sur plusieurs séances de coding dojo !
Cela nous a conduit sur des chemins inattendus et riches nous avons tant appris que nous vous proposons de vous relater cette aventure.

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.

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

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

Agile Tour Bordeaux 2023 Sessionize Event

October 2023 Bordeaux, France

MiXiT 2023 Sessionize Event

April 2023 Lyon, France

Agile Tour Toulouse 2022 Sessionize Event

November 2022 Balma, France

Agile Tour Nantais 2022 Sessionize Event

November 2022 Nantes, France

Agile Tour Bordeaux 2022 Sessionize Event

October 2022 Bordeaux, France

Agile Grenoble 2021 Sessionize Event

November 2021 Grenoble, France

Agile Tour Toulouse 2021 Sessionize Event

October 2021 Balma, France

Agile Tour Toulouse Sessionize Event

October 2020 Balma, France

Agile en ligne Sessionize Event

April 2020

Agile Grenoble 2019 Sessionize Event

November 2019 Grenoble, France

Guillaume Saint-etienne

Senior Coder, Dev Advocate, Software & Team Architect

Toulouse, France