Cet article explique comment résoudre les erreurs CORS liées aux requêtes OPTIONS dans Symfony 7, un problème fréquent lors du développement d'applications modernes avec des architectures microservices ou SPA. L'erreur survient lorsque le navigateur envoie une requête OPTIONS (preflight) pour vérifier si une requête cross-origin est autorisée, mais Symfony ne la gère pas correctement, provoquant une erreur "Access-Control-Allow-Origin".

La solution proposée consiste à créer un Event Subscriber (CorsSubscriber) qui intercepte les requêtes OPTIONS avant qu'elles n'atteignent le routeur. Ce subscriber renvoie une réponse HTTP 200 avec les en-têtes CORS nécessaires (Access-Control-Allow-Origin, Access-Control-Allow-Methods, etc.), empêchant ainsi Symfony de chercher une route inexistante ou de générer une erreur. L'article détaille le code à implémenter, l'importance de la priorité élevée (9999) pour bloquer l'exécution du routeur, et souligne l'utilité de cette approche pour garantir la compatibilité des APIs Symfony avec les applications frontend modernes. Une solution propre, performante et indépendante des routes spécifiques.

Dans cet article un peu décousu, l'auteur expose ses réflexions sur l'IA dans le développement. Ayant connu l'explosion de la bulle des années 2000, il essaye de relativiser un peu ce que nous vivons ces derniers temps : beaucoup d'emballement. Il poursuit en rappelant que certains devs sont avant tout des passionnés, même si le monde du travail tend à rendre le dev moins excitant en cherchant à tout prix la rentabilité. En particulier, l'automatisation permise par l'IA peut faire gagner du temps, mais gomme l'apprentissage de la résolution de problème par soi-même. Il rappelle aussi qu'il y a 10 ans, la grande mode était de délocaliser le développement à l'étranger... et qu'on en est bien revenus ! Il finit par conclure que l'IA est un outil intéressant pour les profils comme le sien : senior et qui sait ce qu'il fait... mais qu'il demande à voir ce que ça donnera avec des juniors qui n'auront que ça.

L’article explique comment déployer des applications PHP sans interruption de service en utilisant la méthode blue-green : deux environnements identiques (blue et green) sont maintenus, l’un actif, l’autre en standby. Le déploiement consiste à installer la nouvelle version sur l’environnement inactif, à vérifier son bon fonctionnement, puis à basculer le trafic de manière instantanée et réversible (via un lien symbolique, un load balancer ou Kubernetes). Les avantages incluent un temps d’arrêt quasi nul et un retour arrière rapide en cas de problème. Pour PHP, il est crucial de centraliser les sessions (Redis/Memcached), les uploads (dossier partagé ou S3), et de gérer l’Opcache et les migrations de base de données avec la méthode "expand/contract" pour éviter les ruptures. L’article propose des scripts prêts à l’emploi pour un serveur unique avec Nginx/PHP-FPM, un load balancer ou des conteneurs, ainsi qu’une checklist pour un déploiement sécurisé, incluant des vérifications de santé et la gestion des caches. Les pièges courants (sessions perdues, caches obsolètes, migrations bloquantes) et des outils comme Deployer ou GitHub Actions sont aussi abordés, soulignant que cette approche transforme les déploiements en opérations sans stress.

L’article explique en détail le dithering, une technique toujours utile en traitement d’image, même à l’ère des écrans haute résolution. Le dithering permet de simuler des couleurs ou des nuances indisponibles en répartissant intelligemment les pixels disponibles, ce qui est particulièrement utile pour réduire la taille des fichiers, adapter des images à des imprimantes en noir et blanc ou à des palettes de couleurs limitées. L’auteur présente onze algorithmes de dithering, dont les célèbres Floyd-Steinberg, Jarvis-Judice-Ninke, Stucki, Atkinson, Burkes et Sierra, en expliquant leur fonctionnement basé sur la diffusion d’erreur. Chaque algorithme utilise une matrice spécifique pour propager l’erreur de quantification aux pixels voisins, améliorant ainsi la perception visuelle des dégradés. L’article inclut des exemples visuels comparatifs et des conseils pour implémenter ces méthodes, ainsi qu’un lien vers un moteur de dithering open-source (PhotoDemon). Une ressource précieuse pour les développeurs et designers souhaitant optimiser ou styliser des images sous contraintes de couleurs. Lire l’article complet.

L’article explore trois méthodes pour gérer les chevauchements temporels dans une base de données PostgreSQL, en prenant l’exemple d’une application de location de vélos. La première méthode utilise deux colonnes (start_datetime et end_datetime) avec un déclencheur PL/pgSQL pour vérifier les conflits, ce qui est efficace mais complexe à maintenir. La deuxième méthode exploite le type TSTZRANGE et une contrainte d’exclusion avec un index GiST, offrant une solution plus élégante et performante, surtout depuis PostgreSQL 9.2. Enfin, la troisième méthode, introduite avec PostgreSQL 18, utilise la clause WITHOUT OVERLAPS pour simplifier la déclaration de cette logique directement dans une contrainte unique. L’article compare les performances d’insertion, la taille des index et les temps de recherche : les solutions basées sur les plages de dates (range) sont plus rapides à l’insertion, mais les index GiST occupent plus d’espace disque. Les tests montrent aussi que l’optimisation des requêtes dépend fortement de la structure des index et du type de recherche effectué. En conclusion, le type range et la clause WITHOUT OVERLAPS apportent une gestion plus propre et intégrée des chevauchements, au prix d’un stockage légèrement plus important.

Je copie colle ^^

Sous le coude : la commande à utiliser quand la clé ssh d'un host a changé.
ssh-keygen -R

L'auteur partage une réflexion sur l’importance d’expliquer un concept avant de le nommer, surtout dans un contexte technique ou d’équipe. Selon lui, partir d’un problème concret, explorer les solutions possibles et leurs implications permet à l’équipe de comprendre et d’adhérer à une approche avant même de lui attribuer un nom — souvent un « buzzword » qui peut générer des biais ou des préjugés. Il illustre cela avec l’exemple de l’architecture hexagonale, adoptée naturellement par son équipe une fois le besoin et la logique compris, alors que le terme seul aurait pu être rejeté d’emblée. L’enjeu est d’éviter que les mots ne deviennent des arguments d’autorité et de privilégier la compréhension profonde pour évaluer la pertinence d’une solution. Une pratique qui favorise la réflexion critique et l’adhésion collective.

Shopify gère 30 To de données par minute pendant des événements comme le Black Friday, tout en maintenant une architecture "monolithique modulaire" et scalable. Leur secret ? Une approche disciplinée basée sur un monolithe modulaire en Ruby on Rails, organisé en "quartiers" logiques (checkout, paiements, commandes, etc.), chacun avec sa propre équipe et ses responsabilités claires. Ils utilisent l’architecture hexagonale (Ports and Adapters) pour isoler la logique métier des dépendances externes, et des Pods (clusters isolés) pour répartir la charge et limiter les pannes. Leur pipeline de données repose sur Debezium + Kafka pour du traitement en temps réel, tandis que MySQL, optimisé avec des centaines de shards et un équilibrage dynamique, supporte 10 millions de requêtes par seconde. Grâce à des outils internes comme Packwerk (pour la modularité) et Sorting Hat (pour le routage intelligent), Shopify prouve qu’un monolithe bien conçu peut rivaliser avec des architectures microservices, même à l’échelle mondiale — tout en restant simple, fiable et "ennuyeusement" efficace. Une leçon de sobriété technique à l’ère de l’hyperscale.

Le 16 octobre 2025 s’est tenue à Paris la première édition de la PlatformCon Live, un événement dédié au Platform Engineering, organisé par l’Organisation Platform Engineering et WeScale. L’occasion pour les professionnels de partager leurs expériences et retours sur la mise en place de plateformes internes, avec une approche centrée sur la simplicité (KISS), l’expérimentation continue et l’alignement produit. Les keynotes, notamment celles de Luca Galante et Kelsey Hightower, ont rappelé que le Platform Engineering n’est pas une nouveauté, mais une évolution naturelle de la plateformisation, désormais adoptée par 90% des entreprises tech selon DORA. Les conférences ont mis en lumière des retours d’expérience variés (Deezer, Mirakl, MeilleureTaux, Ministère de l’Intérieur, Bpifrance), soulignant l’importance de commencer par des API, d’impliquer les équipes utilisatrices, et d’éviter de se précipiter vers des solutions complexes comme l’IA avant d’avoir une plateforme mature. Des projets inspirants, comme Cloud du Cœur (Restos du Cœur) ou Cloud Pi Native (secteur public), ont illustré comment le Platform Engineering peut allier efficacité technique, souveraineté numérique et impact social. L’événement a aussi insisté sur la nécessité de mesurer la satisfaction des développeurs et de prouver la rentabilité des plateformes, avec des exemples concrets de ROI (jusqu’à 300% chez Bpifrance). Une journée riche en enseignements, qui confirme que le Platform Engineering est bien plus qu’une tendance : un levier stratégique pour accélérer l’innovation et améliorer la DevX.

À retenir de la PlatformCon 2025 :

• KISS (Keep It Simple, Stupid) : Commencez par exposer des APIs pour vos services, avant d’envisager une IHM. L’objectif est d’offrir une vision produit claire et d’impliquer les équipes utilisatrices dès le début.
• Eat your own food : Les équipes en charge de la plateforme doivent l’utiliser en premier pour en identifier les forces et faiblesses, favorisant ainsi l’amélioration continue et l’inner sourcing.
• L’expérimentation est clé : Les échecs sont formateurs, et la plateformisation permet de tester de nouvelles méthodologies ou outils (ex : feature flipping, optimisation Kafka).
• Vigilance sur l’IA : Ne l’intégrez pas prématurément. Une plateforme doit d’abord apporter de la valeur (documentation, golden paths) avant d’envisager des agents IA, sous peine de complexité inutile.
• Mesurer l’impact : Privilégiez des retours simples (ex : Squad Health Check de Spotify) plutôt que des métriques DORA trop tôt. L’objectif est d’améliorer la DevX et de créer un produit interne rentable (ex : 3€ gagnés pour 1€ investi chez Bpifrance).
• Éviter les usines à gaz : Pas de Kubernetes ou d’IdP (comme Backstage) sans besoin avéré. APIser d’abord, puis itérer.

En bref : simplicité, collaboration et valeur métier avant la technologie.

Cet article explique comment exporter les métriques de MariaDB vers Alloy pour une visualisation dans Grafana. L’article détaille d’abord la création d’un utilisateur SQL dédié dans MariaDB, avec les droits nécessaires (PROCESS, REPLICATION CLIENT, SELECT). Ensuite, il présente la configuration à ajouter dans le fichier /etc/alloy/config.alloy pour activer l’export des métriques via Prometheus, en utilisant un relabeling pour afficher le hostname plutôt que l’adresse locale. Après rechargement d’Alloy, les données sont visibles dans l’interface d’Alloy et peuvent être affichées dans Grafana via un dashboard dédié comme celui-ci. L’article est illustré par des captures d’écran de l’interface Alloy et du dashboard Grafana final.

L’article explique comment FrankenPHP a rendu obsolètes les stacks traditionnelles à base de Nginx + PHP-FPM, en offrant une solution plus simple, performante et moderne pour exécuter des applications PHP. L’auteur détaille son passage à une architecture Docker intégrant FrankenPHP (basé sur le serveur web Caddy) et PostgreSQL, mettant en avant plusieurs avantages clés : une isolation complète des services, une parité parfaite entre développement et production, et une expérience développeur optimisée (hot reload, HTTPS local automatique, débogage facilité avec Xdebug). FrankenPHP se distingue par son mode "worker", qui maintient l’application PHP en mémoire, éliminant ainsi les temps de démarrage à chaque requête. Le billet décrit aussi l’utilisation de Docker multi-stage pour générer des images légères et sécurisées, et l’importance d’une configuration adaptée pour le développement (logs détaillés, désactivation du cache) comme pour la production (optimisation des performances). En résumé, FrankenPHP simplifie la stack technique tout en améliorant significativement les performances et la productivité. Une lecture utile pour les développeurs PHP souhaitant moderniser leur environnement.

Ahmad Shadeed explore dans cet article comment construire une mise en page de section moderne et dynamique en CSS, en s’appuyant sur des techniques avancées comme les container queries, le sélecteur :has(), la fonction clamp(), et les unités de requête de conteneur (cqw). Il propose une solution pour adapter automatiquement la disposition d’une section (en-tête + grille de cartes) selon le nombre d’éléments, en évitant les orphelins visuels et en optimisant l’espace. L’auteur détaille aussi l’utilisation de la typographie fluide, des layouts responsives pour les cartes, et des styles conditionnels (par exemple, si une image est absente). Des astuces comme display: contents pour intégrer l’en-tête dans la grille ou random() pour des bordures aléatoires (expérimental) sont également présentées. Une démonstration pratique et des exemples de code illustrent chaque concept, montrant comment le CSS moderne permet de créer des designs flexibles et adaptatifs sans JavaScript.

Ce site sert à documenter collaborativement les protocoles HTTP/3 et QUIC.

Nathan Long partage cinq articles qui ont marqué des tournants dans sa carrière. Il évoque notamment l’impact de l’article d’Ethan Marcotte sur le responsive design, qui l’a aidé à comprendre la conception pour des écrans de tailles variables et à décrocher son premier emploi dans le web. Il mentionne aussi l’influence de l’OOCSS de Nicole Sullivan pour une CSS plus durable, son initiation à Vim grâce à un article provocateur, et l’adoption de flexbox via les tutoriels de Chris Coyier. Enfin, il souligne comment les avancées d’ES6 ont transformé sa façon d’écrire du JavaScript. L’article se conclut par un appel à partager ses propres découvertes, rappelant que chaque publication, même modeste, peut inspirer d’autres développeurs. Une belle réflexion sur la transmission et l’évolution collective du métier.

Andy Clarke explore dans cet article comment les animations ambiantes, discrètes et lentes, peuvent enrichir l’identité visuelle et la narration d’un site web sans distraire l’utilisateur. À travers trois études de cas (Reuven Herman, Mike Worth et EPD), il illustre des techniques concrètes : morphing de chemins SVG, superposition de mouvements pour créer de la profondeur, interactions subtiles et respect des préférences d’accessibilité (comme prefers-reduced-motion). Ces animations, réalisées avec CSS ou GSAP, transforment des éléments statiques en expériences vivantes, tout en restant en arrière-plan. L’article met l’accent sur l’optimisation des SVGs, la performance et l’intégration harmonieuse du mouvement dans le design, prouvant que même dans des secteurs traditionnels, l’animation peut renforcer une marque sans dominer le contenu.

Zellij est un espace de travail terminal moderne, conçu pour offrir une expérience utilisateur riche et modulable directement dans le terminal. Il permet de diviser l’écran en plusieurs panneaux, onglets et sessions, avec des fonctionnalités avancées comme le partage de panneau entre plusieurs sessions, la personnalisation poussée via des thèmes et des plugins, et une gestion intuitive via des raccourcis clavier ou la souris. Le projet met l’accent sur la productivité et la flexibilité, en intégrant nativement des outils comme le multiplexage de terminaux, la recherche dans l’historique, et même la possibilité de lancer une démo en ligne sans installation. Idéal pour les développeurs et les utilisateurs avancés, Zellij se distingue par sa simplicité d’utilisation et sa capacité à s’adapter à des workflows complexes.

L’article explore l’univers des terminaux et shells sous Linux, en soulignant leur importance persistante en 2025 pour la gestion de fichiers, le développement, l’administration système et bien plus. Il commence par rappeler la distinction entre TTY et pts/pty, puis détaille l’évolution des shells (Bash, Zsh, Fish, etc.), leurs spécificités et leurs usages, ainsi que les multiplexeurs comme GNU Screen ou Tmux. L’article passe ensuite en revue une multitude de terminaux disponibles, qu’ils soient intégrés aux environnements de bureau (GNOME Console, Konsole, xfce-terminal), liés à des éditeurs de texte (Emacs, Vim), ou indépendants (Alacritty, Kitty, Wezterm, Warp, etc.), en mettant en avant leurs fonctionnalités, philosophies et particularités techniques. Il évoque aussi des solutions innovantes ou controversées, comme les terminaux intégrant l’IA (Warp, Waveterm). Une ressource utile pour découvrir ou comparer les outils de ligne de commande adaptés à ses besoins.

L’article présente plusieurs alternatives "local-first" à Postman, idéales pour les développeurs souhaitant éviter les comptes en ligne et les dépendances cloud. Parmi les solutions proposées : Bruno (open source, stockage local en fichiers .bru, compatible Git), Hoppscotch (léger, fonctionne dans le navigateur, self-hostable), ApiCat (hors ligne, gestion des environnements et variables), Yaak (multiplateforme, approche local-first, intégration Git), Kreya (pour REST, gRPC et WebSocket, données locales), et Posting.sh (en ligne de commande, fichiers YAML). Pour les utilisateurs de VS Code, des extensions comme REST Client, Thunder Client et RapidAPI Client offrent aussi des fonctionnalités similaires directement dans l’éditeur. Ces outils répondent aux besoins de confidentialité, de légèreté et de travail hors-ligne, tout en proposant des interfaces modernes et des fonctionnalités avancées.

Une application en ligne de commande (TUI) pour gérer le WIFI sous Linux

Ce billet explore le pattern Backend-for-Frontend (BFF), une solution architecturale pour les applications modernes où plusieurs frontends (web, mobile, TV) consomment les mêmes services backend. Le BFF agit comme une couche de traduction dédiée à chaque client, agrégeant les appels API, transformant les données et gérant la logique spécifique (cache, authentification, etc.), le tout possédé et maintenu par l’équipe frontend.

Les signes qu’un BFF pourrait être utile incluent des problèmes de performance (appels multiples, sur/sous-récupération de données), une lenteur de développement (dépendances entre équipes, duplication de logique) ou des frictions organisationnelles (API mal adaptées aux besoins UX). Le BFF permet d’aligner les priorités des équipes, d’améliorer les performances (notamment sur mobile) et d’accélérer la livraison de fonctionnalités.

Cependant, le BFF n’est pas une solution universelle : il ajoute de la complexité opérationnelle et peut être excessif pour des applications simples ou des petites équipes. Des alternatives existent (GraphQL, API Gateway, refonte backend). L’article souligne l’importance d’un pilote pour évaluer son impact avant une adoption large, et rappelle que le succès dépend d’une appropriation par les équipes frontend et d’une approche itérative.