L’article explore comment adapter des designs éditoriaux et distinctifs aux petits écrans, en évitant la monotonie des colonnes infinies. L’auteur, Andy Clarke, démontre que le design pour mobile ne doit pas se limiter à empiler du contenu verticalement, mais peut s’inspirer des magazines en créant des « moments » visuels uniques : utilisation du défilement horizontal pour regrouper des éléments (comme des pochettes d’albums), placement d’éléments hors-cadre pour conserver la personnalité du design, ou encore création de mini-maquettes défilables qui rappellent les doubles pages imprimées. Il propose des techniques CSS modernes comme les container queries, le shape-outside, et les media queries d’orientation pour recomposer dynamiquement les layouts selon l’espace disponible et l’orientation de l’écran. L’objectif est de préserver l’impact visuel et la narration, même sur mobile, en jouant sur la variété, le rythme et l’interaction.

Eric Meyer propose une méthode pour transformer des notes parenthétiques en "asidenotes" (notes latérales) en utilisant une combinaison de JavaScript et de CSS moderne. Il introduit un custom element <aside-note> qui encapsule le texte de la note, puis utilise JavaScript pour supprimer les parenthèses et ajouter un marqueur en exposant. Le positionnement des notes est géré via CSS et la propriété anchor-name, permettant d'afficher les notes en marge du texte principal. La solution est conçue pour être robuste : elle ne s'applique que si le navigateur supporte le positionnement par ancrage et si la largeur de l'écran est suffisante, évitant ainsi les problèmes d'affichage sur mobile. Meyer envisage d'adopter cette technique pour son blog, car elle offre une meilleure expérience utilisateur et un code plus propre que sa précédente approche.

L'article présente un outil qui vérifie la sécurité d'un paquet npm avant de l'installer : NPQ. Cet outil fonctionne avec les autres gestionnaires de paquet (via une variable d'environnement)

Eric Meyer explore dans ce billet une méthode pour transformer des parenthèses en notes latérales (asidenotes) à l’aide uniquement de HTML et CSS, en s’appuyant sur la fonctionnalité d’ancrage CSS (anchor()). Il explique son approche : marquer le texte parenthétique avec une classe, ajouter un élément pour le marqueur, puis utiliser des styles conditionnels pour repositionner le texte en note latérale dans les navigateurs compatibles. Malgré un résultat visuel satisfaisant, il souligne les limites de cette méthode — notamment la nécessité d’ajouter du balisage superflu et l’impossibilité de supprimer proprement les parenthèses ou de gérer automatiquement la ponctuation finale sans JavaScript. Il conclut que cette solution, bien qu’intéressante, n’est pas viable pour une utilisation réelle, et évoque une approche alternative utilisant des éléments personnalisés et le Light DOM pour une prochaine publication.

Josh W. Comeau explique comment la fonction CSS linear() permet de créer des animations avancées (ressorts, rebonds, etc.) directement en CSS, sans dépendre de bibliothèques JavaScript. Contrairement aux courbes de Bézier traditionnelles, linear() utilise une série de points pour dessiner une courbe d'animation personnalisée, offrant ainsi plus de flexibilité. L'article présente des outils comme Linear() Easing Generator et EasingWizard pour générer automatiquement ces valeurs, optimisant ainsi la création d'animations fluides et naturelles. Cependant, cette approche a des limites : elle reste basée sur le temps (contrairement aux animations physiques réelles), peut mal gérer les interruptions, et nécessite beaucoup de points pour un rendu réaliste. Malgré cela, les tests montrent un impact minimal sur les performances. L'auteur recommande d'utiliser des variables CSS pour stocker les fonctions linear() et de prévoir des alternatives pour les navigateurs non compatibles. Une méthode efficace pour enrichir les animations CSS tout en respectant les préférences utilisateur (comme prefers-reduced-motion).

Ross Wintle explore l’idée que le logiciel peut être « terminé », en proposant une définition simple : un logiciel est fini lorsqu’il est fonctionnellement complet et que rien ne doit y être ajouté, même si des évolutions restent possibles. Il souligne que des changements externes (matériel, plateformes, API, outils de build) peuvent rendre un logiciel obsolète, mais que cela ne dépend pas toujours des développeurs. Plutôt que de viser absolument la « finition », il invite à réfléchir aux leçons que cette approche peut apporter, comme la valeur de la stabilité et de la maintenance contrôlée. Il illustre son propos avec l’exemple du Gameboy, dont le logiciel embarqué fonctionne toujours des décennies plus tard, et rappelle que beaucoup d’entreprises reposent sur des mises à jour continues plutôt que sur des produits figés. Une réflexion stimulante sur la durabilité et les limites du contrôle en développement logiciel.

Ce tutoriel détaille la mise à niveau de Proxmox VE 8 vers 9, une version basée sur Debian 13 "Trixie" et un noyau Linux 6.14, apportant des améliorations majeures : gestion avancée des snapshots, affinité HA, interface web réécrite en Rust/Yew, et mises à jour de QEMU, LXC, ZFS et Ceph. La procédure nécessite de préparer soigneusement le système : sauvegarder VMs/containers et configuration, vérifier l’espace disque (10 Go libres), et mettre à jour Proxmox VE 8.4. L’outil pve8to9 permet de détecter les problèmes (ex : présence de systemd-boot, microcode Intel manquant, GRUB non configuré). Après correction des erreurs, la migration s’effectue en remplaçant "bookworm" par "trixie" dans les sources APT, puis en lançant apt full-upgrade. Un redémarrage finalise l’installation. Points clés : arrêter les VMs avant la mise à jour, corriger les warnings, et consulter la documentation officielle en cas de problème.

Stephanie Booth propose une réflexion sur la « nétiquette » de l’IA générative, soulignant deux usages problématiques fréquents : laisser l’IA parler à notre place sans transparence (comme utiliser ChatGPT pour répondre à un message en faisant croire que c’est soi, ou partager des créations d’IA sans les attribuer) et inonder les conversations de copier-coller d’outputs IA bruts, ce qui charge les interlocuteurs d’un travail de tri et de vérification non sollicité. Elle insiste sur l’importance de la transparence (préciser quand un contenu est généré par IA), de la collaboration réelle avec ces outils (relire, adapter, s’approprier les productions), et du respect de l’interlocuteur (éviter de rompre le contrat social implicite selon lequel on s’adresse à un humain). L’enjeu est à la fois relationnel et cognitif : préserver l’authenticité des échanges et ne pas contribuer à brouiller la frontière entre le vrai et le faux, surtout dans un contexte où les images et textes générés peuvent déformer notre perception du monde. En résumé : utiliser l’IA comme assistant, mais assumer la responsabilité de ce qu’on partage.

Ce billet détaille la migration d’une instance GitLab vers un nouveau serveur, motivée par la fin de vie de CentOS. L’auteur a opté pour AlmaLinux 9, compatible avec les paquets RedHat. La procédure repose sur la documentation officielle de GitLab et s’applique à toute distribution supportée.

Étapes clés :

1. Installation : Installer GitLab sur le nouveau serveur en utilisant la même version que l’ancien, après avoir mis à jour le système et ajouté les dépôts GitLab.
2. Sauvegarde et transfert : Créer une sauvegarde complète de l’instance existante, transférer les fichiers de configuration (gitlab.rb, gitlab-secrets.json) et les backups vers le nouveau serveur via rsync.
3. Restauration : Arrêter les services, restaurer la sauvegarde, puis relancer et vérifier l’intégrité des données avec des commandes comme gitlab-rake gitlab:check et gitlab:doctor:secrets.
4. Finalisation : Mettre à jour les enregistrements DNS ou l’IP, puis effectuer les mises à jour progressives de GitLab pour éviter les ruptures. L’auteur recommande aussi de réinstaller GitLab Runner si nécessaire et de configurer des sauvegardes automatiques régulières.

L’article souligne l’importance de suivre les versions intermédiaires lors des mises à jour pour garantir la stabilité.

Jim Nielsen rappelle dans ce billet les balises HTML essentielles à ne pas oublier pour que vos pages s’affichent correctement dans les navigateurs. Il met en avant quatre éléments clés :

• <!doctype html> : évite le mode "quirks" et garantit un rendu cohérent.
• <html lang="en"> : améliore l’accessibilité, le référencement et les outils locaux (comme la correction orthographique).
• <meta charset="utf-8"> : assure un affichage correct des caractères spéciaux, emojis et symboles.
• <meta name="viewport" content="width=device-width,initial-scale=1.0"> : rend le site responsive et évite un affichage miniature sur mobile.

Un rappel utile pour éviter les pièges courants lors de la création de fichiers HTML basiques ! (via sebsauvage.net)

L’article explique comment adopter une philosophie stoïcienne pour mieux gérer le stress et les émotions au quotidien. Il propose sept étapes pratiques : comprendre que le bonheur dépend de notre interprétation des événements (et non des événements eux-mêmes), maîtriser ses émotions sans les réprimer, développer une discipline quotidienne, se concentrer uniquement sur ce qui est sous notre contrôle, pratiquer la réflexion quotidienne pour renforcer la conscience de soi, accepter l’inconfort comme une opportunité d’apprentissage, et cultiver la paix intérieure en adoptant une perspective plus large. Le stoïcisme moderne, inspiré par des penseurs comme Marc Aurèle et Épictète, encourage à transformer les obstacles en leçons et à privilégier l’action sur la réaction, pour vivre avec plus de résilience et de sérénité. Une approche accessible et applicable à tous les aspects de la vie, du travail aux relations personnelles.

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.