Planning BreizhC@mp 26

Marre d'utiliser Docker comme un simple lanceur de containers ? 🤔 Vous pensez avoir fait le tour de la question avec un docker run et un docker-compose up qui fonctionne "plus ou moins" ? Venez donc (ré-)apprendre à dompter les baleines ! Cette université est faite pour les développeurs et les SRE qui veulent passer au niveau supérieur. Repartons des bases et allons explorer les fonctionnalités méconnues qui transformeront votre workflow : * Compose, ce chef d'orchestre de génie : Découvrez le pouvoir caché des fichiers docker-compose.yml pour mettre en musique vos microservices et orchestrer des applications multi-conteneurs sans effort. * Buildx, le couteau suisse de la construction d'images : Dites adieu aux builds lents et bonjour aux images multi-architectures et aux caches partagés. Nous explorerons la puissance de docker buildx, notamment sa commande bake pour compiler plusieurs images simultanément avec une simple configuration, comme un chef préparant un festin de containers ! * Multi-stage builds, le Saint Graal du build : Réduisez la taille de vos images de 90 % et faites rougir votre CI/CD. Rejoignez-nous pour (re)découvrir que Docker est bien plus qu'un simple outil, c'est une philosophie, et que vos applications méritent un style qui va bien au-delà de la ligne de commande.

Existe-t-il quelque chose de pire qu’un bug vicieux ? Oui : un code legacy inefficace ! Non seulement sa maintenance nous terrifie, mais il exige toujours plus de ressources et alourdit notre empreinte carbone. Et si l’IA venait à la rescousse ? Comment peut-elle nous aider à convertir un vieux projet legacy vers une technologie plus frugale en énergie ? Nous explorerons deux pistes : • convertir un code source écrit dans un langage énergivore vers un langage plus performant ; • détecter, mesurer et optimiser les "hotspots" d’un projet existant. Enfin, nous verrons si l’opération en vaut la peine : avons-nous réellement économisé plus d’énergie avec notre code optimisé que celle dépensée par l’IA pour y parvenir ? Préparez-vous à découvrir comment l’IA peut transformer votre legacy en code plus performant et plus respectueux de l’environnement !

Dans la plupart des jeux vidéo modernes, un “replay” n’est pas une vidéo mais une simple liste d’événements : les inputs des joueurs, quelques événements système et un état initial minimal. Pour revoir une partie, le moteur ne fait “que” tout rejouer dans l’ordre et reconstruit ainsi l’intégralité de la session. 🎮📜 Côté backend, l’event sourcing applique exactement la même idée : au lieu de stocker uniquement l’état courant, on enregistre la chronologie des décisions métier (events) qui ont mené à cet état. On peut alors “remonter le temps” pour débuguer un bug tordu, auditer un comportement étrange, ou reconstruire un système sur une nouvelle architecture. Dans ce talk, on partira de cas concrets côté jeux (replays, rewind, killcams) pour expliquer pas à pas : - comment fonctionne un système de replay basé sur un log d’événements, - en quoi ce modèle diffère d’une approche CRUD classique, - ce que l’event sourcing reprend de cette idée pour nos SI. Je montrerai un mini-système de replay dans un petit jeu ainsi qu’un exemple d’event store côté backend (Java/TypeScript), sans masquer les limites : coût de relecture, complexité, tooling… 🎯 Public cible : dévs backend / fullstack, architectes, curieux d’architecture qui aiment les métaphores vidéoludiques 💾 Plan proposé 1 - “Un replay, ce n’est pas une vidéo” Comment les jeux enregistrent une partie : log d’événements + état initial. Démo simple : rejouer une partie en réinjectant les inputs dans une boucle de jeu. 2 -De la partie au système : introduction concrète à l’event sourcing Modèle CRUD vs modèle “flux d’événements rejoués”. Notions d’event store, projection/lecture, relecture d’événements. 3 - Cas d’usage réels : debug, audit, résilience Time-travel debugging, audit, reconstruction d’état / migration. 4 - Limites, pièges et conseils pragmatiques Coût de la relecture, snapshots, complexité pour les équipes, tooling et quand ne PAS utiliser l’event sourcing.

On attend du Techlead qu’il sache. On vient le voir pour chaque décision : relecture de code, décision d'architecture, arbitrage produit, debug complexe, médiation d'équipe... Et plus il est compétent, plus il est sollicité ! Le paradoxe ? Sa valeur crée sa surcharge. Et si le rôle du TechLead n’était pas d’avoir les meilleures réponses… mais de poser les meilleures questions ? Le questionnement puissant est une compétence centrale en coaching mais quasiment absente de la culture technique. Alors permettez-moi de vous offrir cet angle nouveau qui pourrait vous permettre de : - réduire la charge cognitive du TechLead, - faire émerger des solutions plus solides, - responsabiliser sans imposer, - et d'éviter les dépendances invisibles Un sujet pour celles et ceux qui veulent faire grandir leur impact sans s’épuiser.

Comme beaucoup de français, tu as peut-être juré de ne plus jamais utiliser la langue de Shakespeare une fois le bac terminé ! Mais… tu as choisi l’informatique… GAME OVER! Je suis américaine native et formatrice en anglais depuis 20 ans pour le public français. Beaucoup de mes stagiaires se sentent “nul en anglais”, enfermés dans cette INFINITE LOOP de la cuisine de Brian parce qu’ils n’ont pas retenu toute la liste de verbes irréguliers! Il est encore temps de faire un BREAK de ses peurs et RESTART sur de bonnes bases. En effet la cuisine de Brian, l’ancienne méthode d’enseignement qui s’appuie beaucoup sur l’apprentissage par coeur, est beaucoup trop étroite pour développer ta créativité… pour coder… pour t’exprimer… t’ouvrir de nouvelles portes ! Si tu n’as pas réussi à retenir ne serait-ce que la moitié de la liste de verbes irréguliers, ou tu n’as pas réussi à bien faire la différence entre I was going, I went, et I have gone, ce talk est pour toi! Bonne nouvelle, ce n’est pas forcément de ta faute et il existe d’autres méthodes très efficaces pour y remédier… Je vais donner quelques astuces et bons plans qui ont fait leurs preuves avec mes stagiaires et qui permettent d’avancer efficacement en anglais au quotidien. Et après, promis Brian will EXIT ;)

L’IA est incontestablement consommatrice de ressources. Mais puisque le mal est fait, pourquoi ne pas l’utiliser à bon escient pour réduire notre impact carbone ? Je l’ai mise à profit sur notre projet Zou pour optimiser les tests et la CI. Venez découvrir les résultats, c’est impressionnant.

Un SI moderne est souvent composé de nombreuses applications hétérogènes, portant chacune ses propres données. Comment dans ce cas vérifier la cohérence des données de ces différents référentiels, et centraliser une donnée fiable, notamment dans un but de reporting aux équipes métier ? Comment mettre en place une gouvernance des données, des tests de qualité sur ces données dans un contexte réparti ? Ce sont les questions que nous nous sommes posées, et auxquelles nous avons répondu par la création d'une plateforme de données utilisant la philosophie ELT (Extract, Load, Transform) basée sur l'orchestrateur Airflow, sur la brique de gouvernance OpenMetadata et sur DBT pour la gestion des transformations "as code", le tout déployé par Terraform sur Google Cloud. Lors de ce talk, nous partagerons notre retour d'expérience sur la création de cette plateforme : - Réflexions initiales et choix des briques technologiques - Prototypages de la solution et apprentissages - Industrialisation - État actuel de la plateforme et réflexions futures Nous zoomerons notamment sur les différentes briques techniques utilisées, sur notre compréhension de leur fonctionnement et sur nos retours d'utilisation. Nous expliquerons également comment nous avons cherché à rapprocher les pratiques Data, Dev, Ops et sécurité pour réduire le "time to insight" (le temps entre la génération d'une donnée et la mise à disposition d'analyses basées sur cette donnée) et augmenter le "data trust" (la confiance dans les données utilisées pour le reporting) tout en assurant la robustesse de la plateforme.

> Le hasard fait bien les choses. Si on applique cette idée aux tests unitaires ou aux tests d'intégration, on peut rendre nos tests beaucoup plus imprévisibles et du coup trouver des problèmes que notre esprit n'aurait jamais osé imaginer ! Par exemple, récemment, j'ai découvert dans une bibliothèque de gestion de configuration, [un bug](https://github.com/gestalt-config/gestalt/issues/242) qui se produit lorsque la `Locale` est configuré en `AZ`. 🤦🏼‍♂️ Un autre exemple encore plus simple : ```java int input = generateInteger(Integer.MIN_VALUE, Integer.MAX_VALUE); int output = Math.abs(input); ``` Peut générer `-2147483648`... Ce qui est assez inattendu pour une valeur absolue ! 😉 Les tests aléatoires peuvent découvrir ces cas tordus... C'est ce que l'équipe elasticsearch a mis en place depuis plusieurs années à l'aide du framework [RandomizedTesting](https://labs.carrotsearch.com/randomizedtesting.html) pour tester tout le code Java. Ajoutez à ça de vrais tests d'intégration à l'aide de [TestContainers](https://java.testcontainers.org/modules/elasticsearch/) et vous aurez une approche complète pour des tests qui échouent régulièrement ! Après cette conférence, vous ne verrez plus jamais la fonction `random()` comme avant et découvrirez comment la (mal)chance peut vous aider ! 🍀

Les UUID sont partout, utilisés souvent machinalement comme identifiant. Revenons un instant sur leurs origines et ce qu'ils garantissent vraiment — l'unicité globale sans coordination, pratique, mais pas toujours le meilleur choix comme clé d'unicité. On explore ensuite quand les employer (ou pas) dans des bases de données et des systèmes distribués, avant de comparer les différents générateurs créant des arbitrages concret entre confidentialité et performance.