What's wrong with DDD en

A lot of us already know what DDD is about. Some of you are experts. You've read the books, the articles.
You've already participated in one (only one) “Event Storming”.
Furthermore, you thought that DDD was cool, even safe. We all do.
Well, maybe we're wrong. DDD is not straightforward.
DDD has drawbacks. There's no silver bullet, we all know that.
Let me introduce some “weird DDD” that I saw in some projects. I realized that some parts of DDD could be very confusing. And that the lack of consensus among DDD experts can be dramatic.

Oh, by the way, I'm not an expert at all.

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

IA vs humains: sommes nous en train de jouer “the imitation game” ou “ the crying game” ? fr

On ne va pas se cacher derrière son petit doigt, les Large Language Models comme ChatGPT3 viennent de terroriser une partie de la communauté mondiale des développeurs, qui voient à l’horizon leur métier menacé.

Tout cela nous pousse à nous poser quelques questions, avant de préparer activement notre CAP de plombier/chauffagiste (qui, au moins, nous assurera des lendemains lucratifs, à coup sûr):
- comment et pourquoi en est-on arrivé là (et pas que pour le métier de développeur) ?
- est-ce surprenant et nouveau ?
- qu’y a-t-il derrière une IA?
- faut-il vraiment craindre que les IA dépassent les humains ?
- à quel point notre métier peut-il changer?
- et au fait, ça consiste en quoi notre métier de développeur logiciel ?

Toutes ces questions, nous ne sommes pas les seuls à nous les poser, mais nous proposerons un bon coup de projecteur scientifique et sourcé. Et donc, espérons le, éclairant.

Une conférence à deux voix par Ionut MIHALCEA, ingénieur en développement logiciel, qui depuis quelques années travaille également sur des produits de machine learning.

Et Guillaume SAINT ETIENNE, tech lead et dev, qui s'intéresse depuis un bout de temps à la place des sciences et des machines au milieu des humains. Également cinéphile, grand fan de Metropolis, 1984, Terminator, Blade Runner et le génialissime “Her”.