Mathieu Desnouveaux

L'ensemble de mes sketchnotes

J'ai regroupé ci-dessous l'ensemble des sketchnotes que je partage depuis 2019.

#AFUP Lorraine #API Days Paris 2024 #API platform con 2024 #Apéro agile #Apéro web #Forum PHP 2022 #Forum PHP 2023 #Forum PHP 2024
Sketchnote illustrant une table ronde sur les alternatives à l'agilité, avec des blocs d'idées reliés par des flèches et des liens cycliques, soulignant la vision itérative et humaine de l'agilité.

Quelles alternatives à l'agilité

Le sketchnote est divisé en trois blocs principaux, chacun représentant une idée clé de la conférence de Valentin Manceaux Panot sur la dette technique. 1. Définition de la dette technique : Le premier bloc présente une définition commune de la dette technique, souvent utilisée dans le développement logiciel pour décrire le coût futur de choix techniques rapides ou sous-optimaux. 2. Critique de l'analogie financière : Le deuxième bloc remet en question l'analogie financière de la dette technique. Valentin Manceaux Panot souligne que cette analogie est caduque car les développeurs ne sont ni créditeurs ni débiteurs dans ce contexte. 3. Proposition de renommage : Le troisième bloc propose de renommer la dette technique en "poids technique", suggérant une nouvelle perspective sur la manière dont ces défis devraient être perçus et gérés. Des flèches relient ces blocs pour montrer la progression logique des idées. Certains mots clés sont mis en valeur pour souligner leur importance.

La dette technique n'existe pas

La sketchnote de la conférence 'Meeting or Missing Target' est une illustration colorée qui explore la durabilité dans le secteur technologique. En haut au centre, le titre 'Meeting or Missing Target' est affiché, avec le sous-titre 'Data Center, Hardware, AI, and Sustainability'. Sous le titre, une flèche horizontale illustre le modèle linéaire de consommation : 'Take', 'Make', 'Consume', 'Dispose'. Au centre, trois blocs blancs distincts représentent trois idées principales : 1. 'Sustainable Consumption' : Cette section propose des conseils pour une consommation durable, avec des bulles et des flèches indiquant des actions telles que 'Think Globally', 'Don't focus on carbon assessment only', 'Consider other things', 'Reuse', 'Material/Social', et 'Circular Economy'. 2. 'How Too' : Ce bloc met en avant les éléments clés à travers des cercles orange et bleus, soulignant l'importance de 'Compare', 'Be Proactive', et 'Evaluate'. 3. 'To Make Informed Decisions' : Cette section insiste sur l'utilisation des 'Right Metrics' et l'augmentation de la collecte de données pour définir des cibles précises et développer des métriques utiles. En bas, une phrase finale rappelle la nécessité de métriques pour aborder la durabilité.

Meeting or missing target

La sketchnote de la conférence "7 Key Lessons on Building Great REST APIs" par Vedran Cindrić présente une vue d'ensemble des meilleures pratiques pour concevoir des API REST efficaces. En haut à gauche, le titre "API Days Paris 2024" est affiché en lettres blanches sur fond rouge. Le titre de la conférence, "7 Key Lessons on Building Great REST APIs", est écrit en lettres orange et noires sur fond blanc. La sketchnote est organisée autour de sept blocs principaux, chacun représentant une leçon clé relié par une ligne pointillée : 1. Design : Ce bloc met en avant l'importance de la sémantique, des méthodes HTTP spécifiques, des codes de réponse clairs, et de la versioning précoce. 2. Sécurité : Ce bloc souligne l’utilisation de HTTPS, l'authentification rigoureuse, la validation des données, et la protection des données. 3. Performance : Ce bloc recommande la mise en cache, la pagination, et l'optimisation des performances de la base de données. 4. Documentation : Ce bloc conseille une documentation descriptive avec des exemples et l'utilisation de standards comme OpenAPI. 5. Adoption : Ce bloc propose de fournir un SDK, un support technique, et un portail développeur de qualité pour faciliter l'intégration. 6. Gouvernance : Ce bloc recommande de définir des standards, centraliser la versioning, et établir un processus de revue des API. 7. Monétisation : Ce bloc conseille de proposer un niveau gratuit, un support commercial, et des tarifs prévisibles pour monétiser les API. Chaque bloc est entouré d'un cadre rouge et contient des notes manuscrites détaillant les points clés de chaque leçon.

7 Key Lessons on Building Great REST APIs

La sketchnote de la conférence de Gregor Hohpe présente les idées clés pour créer des abstractions efficaces. En haut, le titre "API Days Paris 2024" est affiché, suivi du titre de la conférence "Build Abstractions, Not Illusions". La sketchnote est organisée autour de plusieurs points : Limites Technologiques : La technologie doit être poussée à ses limites, tout en respectant ses contraintes. Plateformes et Complexité : Construire une plateforme lorsque quelque chose devient complexe pour augmenter la réutilisation et la collaboration. Pyramide IT : La construction de la base est coûteuse, et une planification excessive peut nuire à l'innovation. Plateforme Partagée : Une plateforme partagée offre une base standardisée pour l'innovation. Abstraction vs Illusion : Créer des abstractions claires et nommer les choses par leurs usages pour éviter les illusions. En bas, une note rappelle l'importance d'être explicite.

Build Abstractions, Not Illusions

La sketchnote de la conférence de Jean-Baptiste Kempf explore l'importance de l'open source, en particulier avec l'IA. En haut à gauche, le titre "API Days Paris 2024" est affiché en lettres blanches sur fond rouge. Le titre de la conférence, "Why Open Source Matters... And Even More Now With AI", est écrit en lettres orange et noires sur fond blanc. La sketchnote est structurée autour de plusieurs blocs et annotations : The Cone Player : L'open source est décrit à travers l'exemple du "cone player", le surnom du lecteur multimédia VLC, créé par et pour la communauté, offrant un logiciel libre et ouvert. Analogie du Gâteau : L'open source est comparé à un gâteau où le boulanger fournit le gâteau (logiciel), la recette (code source), et les spécifications du four (plateforme). Capacités de l'Open Source : L'open source permet d'utiliser, d'étudier, de modifier et de partager le logiciel, avec accès à la documentation, au code, et aux paramètres. Importance pour l'IA : L'open source est crucial pour l'IA car l'IA est omniprésente et l'open source garantit la transparence et l'accessibilité technologique. Des flèches relient ces concepts pour montrer les relations et les similitudes entre eux.

Why Open Source Matters...

La sketchnote de la conférence de Ikenna Nwaiwu traite du problème de la dérive des spécifications OpenAPI. En haut à gauche, le titre "API Days Paris 2024" est affiché en lettres blanches sur fond rouge. Le titre de la conférence, "Tackling Open API Drift", est écrit en lettres orange et noires sur fond blanc. La sketchnote est structurée autour de plusieurs blocs et annotations : 1. Dérive des Spécifications OpenAPI : La dérive survient lorsque la documentation OpenAPI ne correspond pas au comportement des API, entraînant des erreurs comme des champs manquants ou des schémas incorrects. 2. Statistiques : * 75 % des endpoints ne sont pas conformes à la spécification OpenAPI. * 25 % des endpoints n'ont pas de documentation. 3. Solutions Proposées : * Générer une description OpenAPI à partir du code, une tâche difficile. * Générer du code à partir de la description OpenAPI, une solution à long terme. * Utiliser des tests proxy pour la validation. * Utiliser les données et le code existants pour lutter contre la dérive des spécifications OpenAPI. Des flèches et des annotations relient ces concepts pour montrer les relations et les solutions proposées.

Tackling Open API Drift

La sketchnote de la conférence de Maxim Danilov présente une perspective alternative sur la documentation des spécifications OpenAPI (OAS). En haut à gauche, le titre "API Days Paris 2024" est affiché en lettres blanches sur fond rouge. Le titre de la conférence, "An Alternative View on Open API Docs: Start Finally Doing It Right", est écrit en lettres orange et noires sur fond blanc. La sketchnote est structurée autour de plusieurs blocs et annotations : 1. Un bloc "Problèmes" avec les point suivant : - Les spécifications OpenAPI ne décrivent pas comment organiser ou découvrir la documentation. - La documentation est difficile à comprendre pour les humains et les ordinateurs. - Les tests de grandes spécifications OAS consomment beaucoup de ressources. - Plusieurs standards similaires existent en même temps. 2. Un bloc "Solutions Proposées" avec les points suivant : - Diviser et conquérir : Diviser la documentation en fichiers plus petits pour une meilleure lisibilité et une consommation réduite de ressources. - Utiliser la méthode option : Fournir de petits fichiers YAML. - Utiliser un service : Servir des fichiers YAML à partir de fichiers OAS plus grands. Des flèches relient ces concepts pour montrer les relations entre les problèmes et les solutions proposées.

An Alternative View on Open API Docs

La sketchnote de la conférence de Beppe Catanese présente sept règles pour créer des bibliothèques API conviviales pour les développeurs. En haut à gauche, le titre "API Days Paris 2024" est affiché en lettres blanches sur fond rouge. Le titre de la conférence, "7 Rules for Crafting Developer Friendly API Libraries", est écrit en lettres orange et noires sur fond blanc. La sketchnote est structurée autour de plusieurs blocs et annotations : 1. Pourquoi (Why) : * Atteindre les développeurs qui vont exploiter les API. * Mettre en place des abstractions. * Augmenter la productivité. 2. Règles : * Open API Driven : Passer du schéma au code pour éviter la duplication. * Idiomatic : Adopter les conventions de langage et les frameworks. * Release Note : Déclarer les changements importants. * Code Snippets : Fournir de bons exemples de code. * Reference Implementation : Offrir divers exemples complets de cas d'utilisation. * Deprecation Markers : Utiliser des marqueurs pour indiquer l'obsolescence. * Great Documentation : Prioriser les meilleures pratiques de documentation. Des flèches et des annotations relient ces concepts pour montrer les relations entre les différentes règles.

7 Rules for Crafting Developer Friendly API Libraries

Illustration d'un arbre représentant l'AST (Abstract Syntax Tree) avec des branches montrant ses usages : compilation, interprétation, IDE, analyse statique, transpilation, réécriture automatique. L'AST est décrit comme 'partout et puissant'. Un exemple (3×7+42) est décomposé en arbre pour expliquer l'extraction de l'essentiel, le stockage du contexte, et la gestion des nœuds. La modification de code est illustrée avec des actions comme le déplacement, l'ajout ou la suppression de nœuds.

L'AST, L'arme Secrète Des Développeurs

Welcome To The Age Of Static Analysis And Automated Refactoring

Welcome To The Age Of Static Analysis And Automated Refactoring

The Business Of Bisecting

The Business Of Bisecting

Le Zero Downtime Deployment En Pratique

Le Zero Downtime Deployment En Pratique

L Aventure D Une Requête HTTP

L Aventure D Une Requête HTTP

Dis Siri Mets Des Elephpants Dans Ma Domotique

Dis Siri Mets Des Elephpants Dans Ma Domotique

PMU Un Plugin Composer Pour La Gestion De Monorepository En PHP

PMU Un Plugin Composer Pour La Gestion De Monorepository En PHP

PHP Parallel Accélérer Sensiblement Ses Temps D Exécution

PHP Parallel Accélérer Sensiblement Ses Temps D Exécution

How To Eliminate Waste In Your Developpement Process

How To Eliminate Waste In Your Developpement Process

Comment Déboguer Xdebug Ou N importe Quel Autre Bug Bizarre En PHP

Comment Déboguer Xdebug Ou N importe Quel Autre Bug Bizarre En PHP

Intégrer Une IA Générative Dans API Platform Bonne Idée

Intégrer Une IA Générative Dans API Platform Bonne Idée

Comment Tester Une API En Ayant 0 Mock

Comment Tester Une API En Ayant 0 Mock

Comment Se Sortir Du Legacy

Comment Se Sortir Du Legacy

Realtime Notification

Realtime Notification

Opening Keynote

Opening Keynote

How Developpers Became Villains

How Developpers Became Villains

API Platform Admin The Ultimate Admin Generator

API Platform Admin The Ultimate Admin Generator

Adopter Un Lapin

Adopter Un Lapin

Cette sketchnote résume la conférence 'Les Objets Paresseux' présentée par Nicolas Grekas lors de l'AFUP Lorraine. En haut à gauche, un sloth représente le concept de paresse, accompagné du titre de la conférence. À droite, une illustration montre un arbre avec une bulle de texte expliquant le lazy loading : 'Je chargerai le code quand j'en aurai besoin.' Les avantages du lazy loading sont listés : économie des ressources, adaptation aux requêtes à court terme, compatibilité avec les dépendances circulaires, et facilitation du reset d'objet. Quatre stratégies de lazy loading sont détaillées : 1. Initialisation : vérifier un marqueur pour charger les données à la demande, avec un exemple de code. 2. Value Holder : un objet intermédiaire qui charge et sert l'objet demandé, avec un exemple de code. 3. Virtual Proxies : un objet avec la même interface que l'objet final, créé à la demande, avec un exemple de code. 4. Ghost Object : un objet enfant vidé de ses propriétés, utilisé pour l'initialisation de l'objet, avec un exemple de code. En bas à droite, les native lazy objects sont décrits comme rapides, compatibles avec les systèmes de réflexion, et ajoutés dans le système de réflexion. La sketchnote est signée par @mdesnouveaux

Les objets paresseux

Webperf Booster Vos Apps PHP Avec Le Code De Statut HTTP 103 Early Hints

Webperf Booster Vos Apps PHP Avec Le Code De Statut HTTP 103 Early Hints

Observabilité Pour Les Devs

Observabilité Pour Les Devs

Changement De Comportement En PHP 8

Changement De Comportement En PHP 8

Apprendre À Apprendre

Apprendre À Apprendre

Apprendre Et Partager Autrement.

Apprendre Et Partager Autrement.

(im)mutabilité

(im)mutabilité

Équilibre Vie Pro Vie Perso

Équilibre Vie Pro Vie Perso

Why PHP Is Awesome In 2023

Why PHP Is Awesome In 2023

Positive Alt'itude

Positive Alt'itude

Mentors Super Héros Ou Super Villains

Mentors Super Héros Ou Super Villains

J ai Créé Un SAAS Les Erreurs À Ne pas Faire

J ai Créé Un SAAS Les Erreurs À Ne pas Faire

Augmentez Votre Couverture Supprimez Des Tests

Augmentez Votre Couverture Supprimez Des Tests

Cette sketchnote résume la conférence 'Les Conteneurs, des outils Dev/Ops' présentée par Jérôme Redel lors de l'AFUP Lorraine. En haut, le titre 'Les Conteneurs, des outils Dev/Ops' est affiché en bleu. À gauche, une illustration montre un développeur (DEV) et un opérateur (OPS) avec une flèche indiquant que les problèmes des OPS sont souvent causés par des dysfonctionnements dans le développement. Le développeur livre des fonctionnalités, tandis que l'opérateur facilite la production, ce qui limite les livraisons risquées. Une boîte centrale intitulée 'Mur de la confusion' symbolise les malentendus entre les deux rôles. En bas à gauche, la culture DevOps est décrite avec des icônes représentant la vitesse de développement, la rapidité de livraison, la fiabilité, la mise à l'échelle, la collaboration, la sécurité, et la rapidité de réparation. Les cinq piliers de DevOps sont illustrés par un temple avec les mots 'Culture', 'Automatisation', 'Mesure', 'Partage', et 'Amélioration continue'. À droite, l'outil DevOps basé sur les conteneurs est expliqué avec des illustrations de layers et d'images, montrant comment grouper les layers, prioriser par cycle de vie, et garantir l'immuabilité des images. La sketchnote est signée par @mdesnouveaux.

Les conteneurs, des outils Dev/Ops

Cette sketchnote résume la conférence 'Changer de Boîte' présentée par Alexis Coard lors de l'AFUP Lorraine le 23 juin 2023. En haut, le titre 'Changer de Boîte' est affiché avec le sous-titre 'Le point un an après'. Une note précise qu'il s'agit d'un retour d'expérience après une démission cinq ans après la première entreprise. La question 'Pourquoi partir ?' est posée, avec des motivations comme le salaire, le projet, et l'envie de changement. Les aspects humains et techniques sont comparés : l'herbe est-elle plus verte ailleurs ? L'envie de refaire ses preuves, la volonté de passer en full remote, et les différences de technos, de contexte, de framework, de dépôts, et de données. Une section sur l'intégration propose de demander à connaître les processus, d'appréhender le projet, de découvrir l'équipe, et de devenir membre de l'équipe. En bas à gauche, une illustration montre une personne réfléchissant devant un tableau avec le mot 'Réfléchir'. À droite, une personne est assise sur une pile de boîtes avec des étiquettes comme 'Technologie', 'Expérience', 'Process', et 'Idées'. Une phrase conclut : 'Savoir qu'on redémarre sans renier son expérience'. La sketchnote est signée par @mdesnouveaux.

Changer de boîte

Illustration d'une conférence, présentant 15 astuces pour des réunions efficaces. Chaque conseil est illustré de dessins reprenant les concepts évoqué dans les conseils. Les conseils incluent : présence obligatoire, définition des rôles, discussions en 3D, utilisation de templates, durée maximale de 30 minutes, horaires standardisés, inclusivité, répétition et reformulation, partage des résultats, suppression des réunions inutiles, encouragement à prendre la parole, utilisation du chat pour éviter les interruptions, et partage des ressources.

15 astuces pour vos réunions

Cette sketchnote résume la conférence 'Les Aventuriers du Code Legacy' présentée par Mathieu Desnouveaux lors de l'Apéro Web Nancy le 28 février 2023. Elle est organisée comme une carte au trésor avec un scout symbolisant l'amélioration continue du code legacy. Le code legacy est défini comme du code en production non testé, illustré par une affiche humoristique. Les types de code legacy incluent le code exécuté en production, le code rentable, et le code contenant de la valeur métier. Une balance montre l'équilibre nécessaire entre la correction de bugs, l'ajout de fonctionnalités, et la confiance garantie par les tests. Un cycle illustre le paradoxe du legacy : besoin de tests pour changer le code, mais besoin de changer le code pour ajouter des tests. Les raisons pour toucher au code legacy sont montrées avec des icônes de risque, de correction de bugs, et d'ajout de fonctionnalités. La règle des Boy Scouts est représentée par un scout avec un drapeau, symbolisant l'amélioration continue. Les actions recommandées incluent lever les ambiguïtés, réduire la complexité, découpler le code, et se protéger avec des tests et des feature flags. Un robot symbolise l'automatisation avec des outils comme l'analyse statique et Rector en PHP. Des ressources supplémentaires sont recommandées, avec des icônes de livres et des liens vers des katas et des comptes Twitter. La livraison par étapes est illustrée par des icônes de tests, de réécriture de code, et d'ajout de fonctionnalités, avec une flèche indiquant la réduction du scope. La sketchnote souligne l'importance de l'amélioration continue et de l'utilisation d'outils pour faciliter le travail avec le code legacy.

Les aventuriers du code legacy

Sortir Du Cadre

Sortir Du Cadre

Revue De Code

Revue De Code

Le Bon Outil

Le Bon Outil

Franken Php

Franken Php

Ecoconception

Ecoconception

Worker

Worker

Rules Engine

Rules Engine

PHP

PHP

Onboarding

Onboarding

Elastic Search

Elastic Search

A11Y

A11Y

Cette sketchnote résume la conférence 'Mockoon : Mock to the Moon' présentée lors de l'Apéro Web Nancy le 28 septembre. Elle est organisée autour d'un robot central qui symbolise le processus de proxy et de mocking. En haut, le titre 'Mock to the Moon' est accompagné d'une date et de la mention du meetup Apéro Web Nancy. Les principes de base du mocking sont illustrés par des flèches et des étapes numérotées : 1. Intercepter les échanges, 2. Enregistrer les échanges, 3. Forger des mocks, 4. Transformer en mock, et 5. Sert une réponse ou direct mocké/réelle. Le robot central tient un panneau 'Proxy & Mock' et est entouré de flèches vertes représentant les requêtes et les réponses. En bas à gauche, les options de Mockoon sont listées : mocks modifiables, template de mock, automatisable, conteneurisable, et compatible Open API. En bas à droite, les usages de Mockoon sont décrits : mocks, debug, valider une API, tester les limites, et accès limités. La sketchnote est signée par @mdesnouveaux.

Mockoon : Mock to the Moon !

TDD 3 implementation strategies

TDD 3 implementation strategies

Git (2022-05-12)

Git

Buzz (2022-05-09)

Buzz

Typescript (2022-05-02)

Typescript

Vers la sobriété numérique (2022-03-30)

Vers la sobriété numérique

Dark Web (2022-01-26)

Dark Web

Magic the cathering (2021-12-26)

Magic The Gathering

Rencontre avec Burning Sunset (2021-12-11)

Rencontre avec Burning Sunset

La cité des Sciences (2021-12-04)

La cité des Sciences

Jardin des Plantes (2021-12-03)

Jardin des Plantes

Galerie de Paleontologie (2021-12-03)

Galerie de Paléontologie

Les catacombes de Paris (2021-12-03)

Les catacombes de Paris

Event Sourcing Made Easy (2021-11-24)

Event Sourcing Made Easy

accessibilité (2021-09-02)

a11y

Deep Learning Avec Tensor Flow (2021-05-07)

Deep Learning Avec Tensor Flow

Fabrique à fantôme (2021-04-04)

Fabrique à fantôme

Les bonnes pratiques du Télétravail (2021-03-12)

Les bonnes pratiques du Télétravail

Eco-Conception (2021-03-11)

Eco-Conception

Objet Ou Fonctionnel (2021-01-27)

Objet Ou Fonctionnel

Crotte de Licorne (2021-01-10)

Crotte de Licorne

Debuter en domotique (2020-12-23)

Debuter en domotique

A branch in time (2020-12-13)

A branch in time

Comment Arte a simplifié le developpement multi plateforme (2020-11-26)

Comment Arte a simplifié le developpement multi plateforme

Le pouvoir insoupconné des développeurs (2020-09-30)

Le pouvoir insoupconné des développeurs

Mon Cafard et Moi (2020-09-13)

Mon Cafard et Moi

Sablier (2020-09-07)

Sablier

Eleventy (2020-08-19)

Eleventy

Madeleine de proust (2020-08-05)

Madeleine de proust

Pomodoro (2020-07-30)

Pomodoro

Lightning Talk (2020-07-29)

Lightning Talk

bunny challenge 4 (2020-07-27)

bunny challenge 4

bunny challenge 3 (2020-07-22)

bunny challenge 3

bunny challenge 2 (2020-07-14)

bunny challenge 2

Déployer une application on-Premise (2020-06-24)

Déployer une application on-Premise

Typescript (2020-05-27)

Typescript

Mercure (2020-05-07)

Mercure

Bon code (2020-02-26)

Qu'est-ce que du bon code

FrenchKit (2019-12-20)

Retrospective FrenchKit

Cette sketchnote résume la conférence 'Docker en Prod' présentée par @tdutrion. En haut, le titre 'Docker en Prod' est affiché avec la date et le lieu de l'événement. La sketchnote met en avant plusieurs concepts clés pour utiliser Docker en production. Elle commence par souligner l'importance de l'isolation des services par conteneur, avec un conteneur représenté et le mot 'Isolé' souligné. Ensuite, elle aborde la fiabilité en insistant sur la minimisation des dépendances et l'utilisation de fichiers Docker multi-stages. La performance est également un point central, avec des optimisations comme l'utilisation d'Apache, le cache warmup, et des configurations spécifiques pour améliorer les performances. La sécurité est représentée par un cadenas, avec des conseils comme l'utilisation de conteneurs read-only et la gestion des utilisateurs root. Enfin, des éléments de configuration comme 'Php.ini', 'Configurer Apache', et 'User pas root' sont mentionnés pour optimiser les performances et la sécurité. La sketchnote est signée par @mdesnouveaux.

Docker en prod