Chris Shiflett décrit la création d’un serveur MCP (Model Context Protocol) pour son laboratoire personnel, un espace où il centralise ses projets et outils maison. Il explique comment il a rationalisé son répertoire ~/local, autrefois encombré de projets inaboutis, en relançant des outils comme Landice, Faculty ou Schoolcase, tout en adoptant progressivement l’IA malgré ses réticences initiales. Son approche progressive avec l’IA, passant de simple référence à collaborateur, l’a conduit à voir cette technologie comme un "robot" capable d’exécuter du code, bien que des limites persistent, comme l’interface de Claude ou la perte de contexte entre conversations.
Shiflett souligne deux obstacles majeurs dans son utilisation de l’IA : d’abord, l’asymétrie entre l’exécution manuelle du code et l’approche automatisée de Claude Code, qui réduit sa participation active. Ensuite, le manque de mémoire des assistants, obligeant à résumer manuellement l’historique des échanges dans des fichiers Markdown avant de recommencer une conversation. Ces contraintes l’ont poussé à concevoir un serveur MCP pour mieux contrôler l’interaction avec l’IA et intégrer ses outils existants.
L’objectif final est de fluidifier ce processus en créant une interface unifiée, où l’IA agit comme un véritable partenaire de développement plutôt qu’un simple exécutant. Ce projet reflète sa volonté de concilier innovation technologique et méthodes de travail personnelles, tout en résolvant les frictions rencontrées dans l’adoption de l’IA.
L’article propose une version optimisée de l’utilisation de PostgreSQL pour remplacer Redis, en corrigeant les erreurs d’une précédente publication. L’auteur souligne l’importance des valeurs par défaut dans PostgreSQL 18, comme les fonctions uuidv4() ou uuidv7() pour les identifiants, ou encore la génération automatique des dates d’expiration via des intervalles, simplifiant ainsi les opérations côté client. Il met aussi en avant l’utilisation de RETURNING pour récupérer les valeurs générées directement lors de l’insertion, évitant des requêtes supplémentaires.
L’auteur critique l’héritage de tables, une fonctionnalité de PostgreSQL souvent mal comprise, car les index ne sont pas hérités, ce qui peut impacter gravement les performances. Il illustre ce problème avec un exemple comparant une table classique et une table héritée, montrant que l’absence d’index sur la table parente rend les requêtes coûteuses, même sur de grandes volumétries (25 millions d’entrées).
Enfin, l’article aborde brièvement l’utilisation des index, recommandant d’éviter les index inutiles qui alourdissent les opérations d’écriture. L’auteur conclut en insistant sur l’importance de bien comprendre les mécanismes de PostgreSQL pour éviter des erreurs de conception coûteuses en performance.
L’auteur explique comment Domain-Driven Design (DDD) a révolutionné sa vision de l’architecture logicielle, notamment pour les agents IA. Après des années de routine en développement, il découvre ce concept en lisant Domain-Driven Design d’Eric Evans, ce qui transforme sa manière d’aborder la complexité des systèmes. Son expérience précédente avec des microservices mal conçus, où les services manquaient de sens métier, l’a poussé à chercher une approche plus structurée.
Le livre l’a confronté à une réflexion approfondie sur la modélisation du domaine, où chaque détail (noms de classes, relations, effets de bord) devient crucial. Cette approche l’a ramené aux fondamentaux de la programmation orientée objet, avec une attention accrue à la clarté et à la cohérence du code. Il souligne que DDD a comblé un vide entre le développement et la compréhension du métier, contrairement à sa vision initiale où ces deux aspects étaient dissociés.
L’AFUP Day 2026 à Paris a réuni des professionnels de l’écosystème PHP autour de conférences axées sur l’intelligence artificielle, l’architecture et la productivité. L’événement a mis en lumière l’intégration croissante de l’IA dans les outils comme Symfony, avec des présentations sur les embeddings pour des recherches sémantiques et l’utilisation de LLM comme GitHub Copilot pour optimiser les workflows de développement.
Loïck Piera a présenté Castor, un task runner open source développé par JoliCode, tandis que Nicolas Grekas a exploré les avantages de Caddy et FrankenPHP pour moderniser la gestion des applications PHP, proposant une alternative au traditionnel PHP-FPM. Ces outils visent à améliorer la productivité et la durabilité des projets.
Enfin, des discussions ont porté sur les bonnes pratiques en matière de qualité de code, notamment avec PHPStan, et sur la nécessité de concilier fonctionnalité, pérennité et collaboration humaine pour garantir des logiciels robustes et évolutifs.
L’article de Josh W. Comeau compare les performances des animations en CSS et en JavaScript, un sujet souvent abordé avec des idées reçues. L’auteur explique que, contrairement aux apparences, les animations JavaScript ne sont pas nécessairement plus lentes, mais leur exécution sur le fil principal (main thread) les rend vulnérables aux blocages causés par d’autres tâches JavaScript. À l’inverse, les animations CSS s’exécutent sur un fil dédié, ce qui les rend plus fluides dans des applications complexes.
L’analyse se concentre sur deux méthodes : les keyframes CSS et une boucle JavaScript utilisant requestAnimationFrame. Bien que le JavaScript moderne soit optimisé pour des calculs rapides, son exécution sur le fil principal le rend sensible aux interruptions, contrairement au CSS qui bénéficie d’un traitement séparé. L’auteur illustre ce point avec une démonstration où des blocages du fil principal perturbent davantage l’animation JavaScript que l’animation CSS.
Enfin, l’article souligne que le choix entre CSS et JavaScript dépend du contexte : le CSS est idéal pour des animations simples et performantes, tandis que le JavaScript offre plus de flexibilité pour des interactions dynamiques ou complexes, malgré les risques de latence liés au fil principal.
L’article explique comment gérer les options et arguments dans des scripts Bash afin de rendre les scripts plus flexibles et robustes, notamment via les commandes getopts, shift et les variables spéciales comme $1 ou $@. Il détaille la différence entre options courtes et longues, montre comment vérifier la présence d’arguments obligatoires et recommande des pratiques de développement plus sûres comme set -euo pipefail pour détecter rapidement les erreurs et éviter les comportements inattendus dans les scripts shell.
L’article explore les défis liés à la mise à l’échelle des View Transitions entre documents, notamment pour des pages affichant des centaines d’éléments comme une grille de produits. Après avoir résolu les problèmes initiaux (métadonnées obsolètes, délais de timeout, etc.), l’auteur souligne que les tutoriels classiques, conçus pour des transitions simples, échouent face à des cas complexes. La solution idéale, purement CSS, reposerait sur des fonctions comme ident() et sibling-index() pour générer automatiquement des noms uniques, mais cette approche n’est pas encore implémentée dans les navigateurs.
En attendant, les développeurs doivent recourir à des méthodes manuelles fastidieuses, comme des règles CSS répétitives pour chaque élément, ce qui devient ingérable avec un grand nombre d’items. L’article met en lumière l’écart entre les promesses futures des standards CSS et les contraintes actuelles, tout en soulignant l’importance de solutions évolutives pour des interfaces dynamiques.
L’article aborde les difficultés rencontrées avec les Cross-Document View Transitions, une fonctionnalité permettant d’animer les transitions entre pages HTML classiques sans framework. L’auteur explique que les tutoriels obsolètes, utilisant une balise <meta> désormais dépréciée, induisent en erreur, tandis que les solutions pour Single-Page Applications (SPA) ne s’appliquent pas aux sites multi-pages. Les problèmes courants incluent des transitions silencieusement bloquées par un délai de 4 secondes, des distorsions d’images ou des styles CSS complexes pour gérer les noms de transitions.
L’auteur souligne l’absence de documentation claire et actualisée, rendant l’implémentation ardue malgré des démos prometteuses. Il annonce une série en deux parties pour clarifier les bonnes pratiques, comme l’utilisation de l’API @view-transition en CSS, la gestion des événements pagereveal et pageswap, ou encore l’optimisation des noms de transitions pour éviter des fichiers CSS surchargés. La seconde partie promet des solutions pour les projets à grande échelle, notamment la gestion des animations avec prefers-reduced-motion.
L’article dénonce la standardisation d’Internet sous l’ère des réseaux sociaux, qui a remplacé la créativité individuelle et l’expression personnelle par des plateformes uniformes et optimisées. L’auteur évoque son expérience des années 2000, où des outils comme MySpace permettaient de personnaliser son espace web avec du code HTML, transformant chaque profil en une œuvre unique et chaotique. Cette époque, marquée par l’expérimentation et l’authenticité, a cédé la place à des interfaces standardisées et professionnelles, vidant le web de sa dimension humaine.
L’auteur souligne que cette transition n’était pas seulement technique, mais culturelle, réduisant la diversité des expressions en ligne à une « monoculture technologique ». Il cite une analyse de Maria Farrell et Robin Berjon, comparant cette uniformisation à la sylviculture scientifique, qui a remplacé un écosystème créatif par des structures rigides et identiques. Aujourd’hui, les réseaux sociaux, autrefois perçus comme des progrès, sont critiqués pour leur impact négatif sur la société, notamment en termes d’authenticité et de bien-être.
Face à ce constat, l’article appelle à une reconquête du web par ses utilisateurs, en encourageant le retour à des pratiques plus personnelles et créatives, comme le codage ou l’hébergement de sites indépendants. L’idée centrale est de « réensauvager » Internet, en restaurant sa diversité et son âme originelle, loin des algorithmes et des templates imposés.
European Alternatives propose une plateforme pour identifier des alternatives européennes à des services et produits numériques courants, comme les solutions cloud ou SaaS. Le site met en avant l'importance de soutenir les entreprises locales, soulignant les retombées économiques (emplois, taxes) et la conformité aux réglementations européennes, notamment le RGPD, la TVA et les normes juridiques harmonisées au sein de l'UE. Il recense des alternatives dans divers domaines (hébergement, messagerie, moteurs de recherche, etc.) et encourage les utilisateurs à contribuer en suggérant de nouveaux services.
L’auteur explique pourquoi il a attendu d’avoir Redis et un worker Messenger avant de migrer vers Symfony Scheduler en production. Selon lui, sans ces deux éléments, le Scheduler ne serait qu’un cron amélioré, sans les fonctionnalités avancées comme l’asynchronicité, la persistance des états ou la gestion des échecs. Il souligne que Symfony Scheduler ne remplace pas cron, mais s’appuie sur une infrastructure adaptée pour offrir des mécanismes de planification robustes.
L’article détaille trois prérequis essentiels avant d’utiliser le Scheduler : un worker Messenger consommant en continu le transport dédié, un transport asynchrone pour éviter les blocages (comme Redis), et un pool de cache non volatile pour stocker l’état des tâches. Sans ces éléments, l’auteur estime que l’on recréerait les limitations des scripts cron, mais avec une complexité inutile.
Enfin, l’auteur illustre son propos avec cinq jobs actuellement exécutés sur son site, montrant comment le Scheduler simplifie la gestion des tâches récurrentes une fois l’infrastructure en place. Il conclut que le Scheduler est pertinent uniquement si l’environnement technique le permet, évitant ainsi les solutions hybrides peu fiables.
ROM Finder est un outil en ligne permettant de trouver des ROM alternatives pour smartphones. Il référence 623 appareils compatibles issus de 27 constructeurs, avec 5 systèmes alternatifs disponibles. Les informations sont mises à jour régulièrement et proviennent des sources officielles des projets concernés.
L’auteur explique pourquoi une nouvelle YubiKey 5C ne pouvait plus déverrouiller sa base KeePassXC, alors qu’il utilisait auparavant une YubiKey configurée avec le même secret HMAC-SHA1. Le problème vient de la méthode de provisionnement : les anciens outils (YubiKey Personalization Tools) utilisaient des options avancées non documentées, tandis que les outils récents (ykman) standardisent le processus, générant des réponses différentes pour un même secret.
Il souligne la dépendance implicite au logiciel initial, désormais obsolète, qui pourrait devenir difficile à utiliser à l’avenir. Yubico a en effet abandonné ses outils graphiques au profit de ykman, rendant la compatibilité rétroactive problématique. L’auteur recommande de reprogrammer les clés avec ykman et de mettre à jour le challenge-response dans KeePassXC, tout en sauvegardant un accès alternatif à la base avant toute manipulation.
Enfin, il détaille brièvement la procédure pour recréer le challenge HMAC-SHA1 dans KeePassXC via les options de sécurité, en utilisant la ligne de commande (ykman) pour configurer le slot 2 de la YubiKey. Une migration proactive évitera des difficultés futures lors du remplacement d’une clé.
Ce billet de blog, deuxième partie d’un test sur CKE (Clever Cloud Kubernetes Engine), explore les fonctionnalités avancées de stockage sur ce service managé. L’auteur détaille notamment l’activation du Container Storage Interface (CSI) via une commande simple, permettant l’utilisation de Ceph RBD pour des volumes persistants, avec une StorageClass configurée par défaut et la possibilité d’étendre les volumes à chaud. Il illustre ensuite le déploiement d’un PersistentVolumeClaim (PVC) et son utilisation dans un pod, confirmant la persistance des données après redémarrage.
L’article aborde également des cas d’usage concrets comme le déploiement de vCluster, un cluster Kubernetes virtuel fonctionnant dans le cluster hôte, partageant son infrastructure de stockage. L’auteur teste cette solution, soulignant ses avantages potentiels pour l’isolation des environnements (comme des environnements CI) tout en partageant les ressources, bien qu’il reste sceptique sur certains aspects de sécurité.
Enfin, le billet conclut sur les fonctionnalités de gestion du cycle de vie des volumes, incluant les snapshots et la restauration de données, avec une procédure technique détaillée en plusieurs étapes. L’auteur résume son expérience en mettant en avant la simplicité de mise en œuvre et la flexibilité offerte par CKE pour des besoins de stockage avancés dans Kubernetes.
Cette page propose le transcript d’une conférence de Pascal Martin intitulée « Des structures de données qui vont vous étonner », donnée notamment lors de la PyConFR 2025. L’auteur y explore des structures de données méconnues mais utiles, soulignant leur importance pour optimiser les performances des applications. Il illustre son propos avec des exemples concrets, comme les éditeurs de texte, et rappelle les bases des complexités algorithmiques (notation grand O) pour justifier le choix des structures adaptées.
La conférence met en lumière la diversité des structures de données, souvent ignorées au profit de solutions classiques comme les tableaux ou les listes chaînées. Pascal Martin en présente trois particulièrement pertinentes pour des besoins quotidiens, tout en insistant sur l’intérêt de ne pas réinventer la roue. Le transcript, proche du style oral, inclut des précisions absentes des slides, enrichissant la compréhension des concepts abordés.
Destiné aux développeurs et développeuses, ce contenu vise à éveiller la curiosité sur des outils peu exploités, tout en rappelant l’importance de sélectionner la bonne structure en fonction des contraintes algorithmiques. Le document s’accompagne de liens vers les slides et d’archives pour approfondir.
L’article interroge la qualité croissante des logiciels et l’impact de l’IA sur leur fiabilité, dans un contexte marqué par des failles de sécurité fréquentes et des fuites de données. L’auteur souligne que les vulnérabilités (CVE) ont fortement augmenté depuis 2017, attribuant cette hausse à des facteurs comme la pression des mises à jour quotidiennes, l’expansion du numérique et l’intensification des cyberattaques, plutôt qu’à l’IA. Il relativise cependant ce lien, notant que les CVE reflètent aussi une meilleure détection des bugs et une industrie cyber en croissance.
L’auteur évoque des exemples concrets, comme des failles majeures chez GitHub ou des attaques contre des institutions françaises, pour illustrer la dégradation perçue de la qualité logicielle. Il critique l’idée selon laquelle l’IA serait la principale responsable, soulignant que la baisse de fiabilité précède son adoption massive et s’explique davantage par des enjeux économiques et géopolitiques.
Enfin, l’article aborde la perception selon laquelle l’IA accélérerait la production de "code de merde", une idée que l’auteur juge exagérée. Il conclut que la qualité des logiciels dépend davantage des pratiques de développement et des pressions du marché que de l’IA, tout en reconnaissant que cette dernière pourrait aggraver certains problèmes si mal utilisée.
L’article souligne que Symfony, souvent perçu comme un framework monolithique, peut être utilisé comme un simple adapter pour isoler la logique métier du code lié au framework. L’auteur explique que, malgré une architecture apparente propre (contrôleurs légers, services organisés), une application Symfony mature reste profondément couplée à Doctrine et Symfony, ce qui limite sa maintenabilité et sa portabilité. Il illustre ce problème par un exemple concret où l’entité Order gère directement des calculs de taxes via des annotations Doctrine, montrant ainsi une dépendance implicite au framework.
Pour résoudre ce couplage, l’auteur propose une architecture en trois couches : le Domain (PHP pur, sans dépendances externes), l’Application (cas d’utilisation et interfaces) et l’Infrastructure (adaptateurs Symfony/Doctrine). Cette séparation stricte permet de tester et faire évoluer le domaine indépendamment du framework. Un contrôle CI vérifie que le dossier Domain/ n’importe jamais de classes Symfony ou Doctrine, garantissant ainsi l’étanchéité de l’architecture.
Enfin, l’auteur compare cette approche à celle d’un projet Laravel, insistant sur le fait que Symfony, comme tout framework, doit être traité comme un outil d’infrastructure et non comme le cœur de l’application. L’objectif est de rendre le code plus résilient aux changements technologiques tout en conservant la puissance de Symfony pour les aspects HTTP, persistance ou messagerie.
L’article explique comment utiliser Symfony Messenger pour gérer les événements du domaine sans créer de couplage excessif. L’idée principale est de séparer clairement l’interface du domaine (ports) de l’implémentation technique (adaptateurs), en s’inspirant de l’architecture hexagonale. Ainsi, le domaine reste indépendant du framework, utilisant des interfaces comme DomainEvent et EventBus pour publier des événements sans dépendre de Symfony Messenger.
L’auteur illustre cette approche avec un exemple concret : un événement OrderPlaced est défini comme une classe PHP simple, sans annotations ni dépendances vers Messenger. Les agrégats du domaine enregistrent ces événements dans une collection interne, puis l’application les publie via une implémentation de EventBus qui utilise Messenger en arrière-plan. Cela permet de changer de transport (AMQP, Redis, etc.) sans modifier le code métier.
Enfin, l’article souligne l’importance de maintenir cette séparation pour éviter les problèmes de couplage, comme des noms de classes ou de namespaces qui briseraient le code en cas de modification du framework. L’objectif est de conserver une architecture propre et maintenable, où le domaine reste au centre et les détails techniques en périphérie.
L’article explique comment résoudre le problème des requêtes N+1 dans Symfony 8.1 avec Doctrine ORM, un fléau pour les performances des applications. Il détaille d’abord le mécanisme du N+1, où une requête initiale récupère N entités, puis N requêtes supplémentaires chargent leurs relations, dégradant fortement les performances en production.
L’auteur propose des stratégies avancées pour l’éviter, comme l’utilisation de DQL avec JOIN FETCH pour charger les entités et leurs relations en une seule requête, ou encore des modes de récupération précis et l’hydratation via des DTO. Ces méthodes, combinées à des outils comme le Symfony Web Profiler, permettent d’optimiser significativement les endpoints.
L’article explique comment configurer Symfony pour l’architecture hexagonale en utilisant l’autowiring, simplifiant ainsi la gestion des dépendances. L’idée principale est d’éviter les configurations XML complexes en exploitant les fonctionnalités modernes de Symfony (autowiring, autoconfigure et un bloc bind minimal), réduisant services.yaml à moins de vingt lignes pour un contexte métier entier. L’auteur illustre cette approche avec une structure de projet claire, où les interfaces (ports) définies dans la couche Domain sont automatiquement liées à leurs implémentations (adaptateurs) dans Infrastructure sans configuration explicite.
L’exemple montre comment une classe d’application comme PlaceOrder dépend uniquement d’interfaces (ex. OrderRepository, Clock, EventBus), laissant Symfony injecter les bonnes implémentations (ex. DoctrineOrderRepository, SystemClock) via l’autowiring. Trois paramètres dans services.yaml (autowire, autoconfigure et public) suffisent pour automatiser cette injection, tandis qu’un attribut PHP 8.3 gère les cas ambigus. L’article souligne que cette méthode élimine le besoin de fichiers de configuration verbeux, tout en respectant les principes de découplage de l’architecture hexagonale.