« Getting Creative With Images in Long-Form Content » (CSS-Tricks) explore comment les images, souvent reléguées à un rôle purement illustratif, peuvent dynamiser et enrichir l’expérience de lecture des contenus longs. L’article propose des techniques créatives pour intégrer les images de manière expressive : briser la grille classique pour attirer l’attention, jouer avec les formats (full-bleed, modular grids), utiliser les CSS Shapes pour un habillage de texte plus organique, ou encore repenser les légendes et l’espace blanc pour renforcer l’impact visuel et narratif. L’objectif ? Transformer les images en éléments actifs qui rythment la lecture, guident le regard et renforcent l’émotion, plutôt que de simples interludes visuels. Une approche inspirante pour les designers et rédacteurs qui veulent donner plus de personnalité à leurs articles, rapports ou études de cas.
Symfony, Doctrine et les triggers SQL sont souvent en tension : les triggers offrent une robustesse et une atomicité inégalées pour des logiques critiques (audit, validation, compteurs), mais leur gestion dans un projet Symfony reste complexe, car leur code SQL est souvent perdu dans des migrations ou invisible pour les développeurs. Le Trigger Mapping Bundle propose une solution élégante en permettant de déclarer les triggers directement dans les entités via des attributs PHP, les rendant ainsi visibles, versionnables et gérables comme le reste du code. Le bundle offre des commandes pour intégrer, créer, valider et mettre à jour les triggers, tout en facilitant la transition depuis un projet existant. L’objectif ? Réconcilier la puissance des triggers SQL avec la philosophie de Symfony et Doctrine, en choisissant le bon outil selon le besoin : trigger pour l’intégrité des données, listener Doctrine pour la logique applicative. Une approche qui réduit la dette technique et améliore la maintenabilité.
Gérer les dépendances Python avec pip freeze permet de capturer l’état exact des bibliothèques installées dans un environnement virtuel, en générant un fichier requirements.txt via la commande pip freeze > requirements.txt. Ce fichier liste toutes les dépendances (et leurs versions précises), assurant la reproductibilité du projet sur d’autres machines ou en production. Pour installer ces dépendances, il suffit d’exécuter pip install -r requirements.txt. Cependant, cette méthode ne distingue pas les dépendances directes des dépendances transitives, ce qui peut poser problème en cas de conflits de versions. Pour des projets plus complexes, des outils comme pip-tools ou Poetry offrent une gestion plus fine et structurée des dépendances, en générant un fichier de verrouillage cohérent. L’usage d’un environnement virtuel reste indispensable pour éviter les conflits entre projets. Lire plus.
L’article réfléchit sur l’auto-hébergement à domicile, une pratique qui consiste à gérer soi-même ses services (site web, mails, stockage, etc.) plutôt que de les confier à des prestataires externes. L’auteur rappelle que le cloud et le web reposent sur des machines physiques gérées par des tiers, ce qui soulève des questions de compétence, de sécurité, de souveraineté et de dépendance politique (exemples : incendie du datacenter OVH à Strasbourg, surveillance étatique). Bien que des solutions comme Yunohost ou OpenMediavault facilitent la mise en place d’un serveur domestique, l’auteur souligne les risques (pannes, attaques, perte de données) et la complexité de maintenir un service fiable et sécurisé 24/7. Il distingue l’auto-hébergement "pour jouer" (projets personnels, tests) de l’hébergement professionnel, qu’il préfère déléguer à des experts, même chez les GAFAM, pour des usages critiques (mails, site à fort trafic). Il partage son expérience avec un serveur Ubuntu hébergeant Nextcloud et MiniDLNA, mais conclut que l’auto-hébergement reste un loisir technique, réservé à des usages non essentiels et assumés en conscience des limites et des risques.
Une superbe adaptation des Misérables de Victor Hugo à notre époque. Comme le souligne Gee, cette oeuvre a vraiment peu vieilli à tous les niveaux : la misère et les misérables sont 'toujours bien là, en France, en 2025".
Comment bien scaler les code reviews (et éviter les pièges)
À l’origine, une petite équipe peut se permettre de merger directement dans la branche principale, mais dès que le projet grandit, les code reviews deviennent essentielles pour maintenir la qualité du code. Pourtant, mal gérées, elles ralentissent les équipes (délais serrés, feedbacks sur des détails mineurs), génèrent des conflits (préférences personnelles, ton toxique) et favorisent les incompréhensions (revues asynchrones, PR trop volumineuses). Pour y remédier, auteurs et relecteurs doivent adopter des bonnes pratiques : PR petites et ciblées, feedback constructif et documenté, respect du temps de chacun (réponse sous 24h, slots dédiés), et automatisation (CI, outils comme CodeRabbit pour les checks routiniers). L’objectif ? Améliorer la qualité sans bloquer la vélocité : privilégier le "bon assez" plutôt que la perfection, utiliser des checklists, et résoudre les désaccords en direct. Les outils modernes (GitHub/GitLab, AI comme CodeRabbit) optimisent le workflow en détectant les bugs tôt et en résumant les changements, libérant les humains pour des revues plus stratégiques. En résumé : des revues rapides, bienveillantes et outillées pour un code sain et des équipes motivées.
L'auteur détaille sa migration d’infrastructure en 2025, marquée par l’abandon de Proxmox au profit d’Hyper-V, principalement pour des raisons de performances et de gestion des sauvegardes : ZFS et PBS (Proxmox Backup Server) étaient devenus inadaptés à ses besoins, avec des vitesses de backup limitées à 100-150 Mbps contre 2 Gbps avec Hyper-V et Veeam, essentiel pour ses 7-8 To de données quotidiennes. Son infrastructure repose désormais sur deux serveurs sous Windows Server 2022 : un Supermicro X10SDV-4C-TLN4F (stockage NVMe et HDD en RAID 1) pour l’hyperviseur et un vieux HP MicroServer Gen8 (mis à niveau réseau et stockage) pour les backups, le tout protégé par un UPS APC reconditionné. Les VM, majoritairement sous Debian 12, incluent Ansible (avec Semaphore), LibreNMS, Home Assistant, Paperless-ngx, Jellyfin, Passbolt, Proton-backup, Wazuh et un serveur web. Le réseau est entièrement en 10 Gbps (catégorie 6 STP), avec un firewall OPNsense sur un NUC Intel N100. L’automatisation via Ansible/Semaphore gère mises à jour, backups (local, disques externes rotatifs, Backblaze B2 chiffré) et monitoring, respectant la règle 3-2-1. Il évoque aussi son wiki technique (xWiki) et son désengagement partiel du blog, critiquant l’impact des IA (comme Gemini) sur la visibilité des contenus humains, tout en reconnaissant leur utilité ponctuelle pour la veille ou l’écriture de scripts. Enfin, il souligne la désaffection des blogs au profit des réseaux sociaux et de l’IA, sans pour autant fermer son espace.
Encore un texte passionnant de Ploum qui fait réfléchir (et sourcé, toutes les sources lui permettant d'alimenter sa réflexion).
L'espionnage de masse est bien pire que ce que l'on imagine mais l'Europe protège un tout petit peu ses citoyens.
On est saturés d'indignation sans rien faire mais il y a quelques actions très concrètes (comme supprimer Whatsapp) : il faut accepter la difficulté, l'inconfort et le fait que ces actions ne seront jamais reconnues ou applaudies.
La merdification est à l'oeuvre de partout, même sur des applications qui paraissaient sûres puisque les fondateurs s'y étaient engagés... jusqu'à l'arrivée d'un gros chèque. Seul le logiciel libre peut lutter, à condition de ne pas chercher l'ajout de fonctionnalités superflues.
Ploum nous encourage aussi à ralentir et prendre du recul (cf son dernier échange avec Chris Brannons)
Enfin il nous encourage aussi à faire du vélo, comme symbole d'indépendance et de liberté.
L’article explique comment transformer sa to-do list en un outil efficace et anti-stress, en s’appuyant sur la psychologie du cerveau (effet Zeigarnik, dopamine) et 7 règles clés. L’idée centrale : le cerveau est obsédé par les tâches inachevées, ce qui génère du stress et réduit la concentration. Pour y remédier, il propose de planifier le matin (après avoir vérifié ses mails), de commencer par les tâches faciles pour créer un élan de motivation (« boule de neige »), de découper les projets en actions concrètes (règle des 25 minutes), et de regrouper les tâches similaires (« batching »). Autres astuces : noter chaque soirée les tâches accomplies (« Done List ») pour analyser son temps réel, gérer les imprévus en notant la prochaine micro-étape avant de s’interrompre, et choisir un outil simple (comme Google Tasks) qui permet de déléguer la mémoire à un système externe. L’objectif n’est pas de tout retenir, mais de libérer son esprit pour se concentrer sur l’essentiel.
Une méthode pour passer de la surcharge à la sérénité !
L’article propose un exercice simple pour identifier et réduire la charge mentale au travail, souvent source d’angoisse et de fatigue invisible. L’idée est de noter pendant une semaine toutes les petites contrariétés du quotidien (tâches répétitives, interruptions, demandes hors périmètre) sans les juger, afin de dresser un « relevé brut » de ce qui grignote temps et énergie. À l’issue de cette observation, trois questions clés permettent d’agir : automatiser les tâches répétitives, déléguer ce qui ne relève pas de son expertise, ou supprimer ce qui n’est plus nécessaire. L’objectif n’est pas une solution miracle, mais une prise de recul concrète pour reprendre le contrôle et alléger son quotidien, en se concentrant sur l’essentiel plutôt que sur l’accumulation de détails épuisants.
Un outil utile pour ceux qui se sentent débordés sans raison apparente !
Le 17 août 2025, le blog de l’auteur a subi un incident informatique : environ 179 000 requêtes web en 14 heures, ciblant uniquement trois fichiers sitemap.xml, provenant de 168 000 adresses IP uniques (majoritairement IPv4). L’attaque, jugée naïve et peu sophistiquée, a permis à l’auteur de réviser ses connaissances sur nftables et fail2ban. Après avoir bloqué l’accès aux fichiers ciblés via Apache, il a tenté de filtrer les requêtes avec fail2ban, mais a dû ajuster sa stratégie face à la charge : bannissement par grands blocs d’IP (/8 puis /16 en IPv4), limitation du trafic entrant, et enfin blocage par pays (sauf France). Malgré des erreurs initiales (rechargement intempestif de fail2ban, lecture complète des logs), l’incident a été maîtrisé en combinant ces outils et en nettoyant les logs pour éviter d’alourdir les sauvegardes. L’auteur souligne l’importance de bien connaître ses outils avant un incident et partage des commandes utiles pour nftables et fail2ban.
Un retour d’expérience technique et pédagogique sur la gestion d’un flux massif de requêtes indésirables.
Ce tutoriel détaillé explique comment mettre en place une solution de supervision complète de vos serveurs avec Prometheus (pour la collecte et le stockage des métriques système) et Grafana (pour leur visualisation sous forme de tableaux de bord interactifs).
Il couvre l’installation et la configuration de Prometheus et Grafana via Docker sur un serveur dédié, ainsi que le déploiement d’exporters comme node_exporter (métriques système), cAdvisor (métriques containers Docker), process_exporter (métriques processus), et blackbox_exporter (tests de disponibilité des services). Le guide aborde aussi la sécurisation des interfaces, la création d’alertes, et l’intégration d’Alert Manager pour la gestion des notifications. Idéal pour surveiller en temps réel l’état de votre infrastructure et recevoir des alertes en cas de dépassement de seuils, avec des exemples concrets et des tableaux de bord Grafana prêts à l’emploi.
Un super outil à auto héberger qui permet de convertir des fichiers dans plein de formats
Ce tutoriel explique comment déployer Longhorn, une solution de stockage distribué, sur un cluster K3s (Kubernetes léger).
Il détaille les prérequis (Kubernetes 1.28+, 2 Go de RAM, open-iscsi installé), la préparation d’un dossier dédié (/opt/longhorn), puis l’installation via un manifest YAML personnalisé pour spécifier le chemin de stockage. Après déploiement, il montre comment vérifier l’état des pods, corriger une mauvaise configuration via un patch, et tester le stockage avec un PVC de 1 Go. Des astuces pour la mise à jour, la vérification de l’état du service et le redimensionnement des volumes sont aussi partagées. Idéal pour ajouter du stockage persistant et résilient à un cluster K3s avec peu de ressources.
Ce guide explique comment optimiser le chargement des polices web pour éviter de ralentir un site : privilégiez le format WOFF2 (le plus efficace et universel), hébergez vos polices vous-même pour améliorer les performances et la vie privée, et utilisez font-display: swap pour afficher immédiatement un texte de repli avant le chargement de la police personnalisée. Pensez à pré-charger les polices critiques avec <link rel="preload" as="font" ...>, à sous-ensembliser les polices (unicode-range) et à éviter les formats obsolètes (TTF, OTF, etc.). Intégrez les déclarations @font-face directement dans le <head>, choisissez des polices de repli système bien adaptées, et utilisez size-adjust ou font-size-adjust pour limiter les décalages de mise en page (CLS). Enfin, testez sur des réseaux lents et surveillez l’impact des polices sur les performances, en limitant le nombre de variantes et en évitant les polices d’icônes au profit des SVG. L’objectif : allier design et rapidité sans compromis.
L'auteur montre qu’il n’est pas nécessaire de migrer vers TypeScript pour bénéficier de sa rigueur : PHP 8.1+, couplé à des outils d’analyse statique (Psalm, PHPStan) et à des bibliothèques idiomatiques, permet d’obtenir des garanties similaires en typage, validation et maintenabilité. L’article détaille des équivalences concrètes : DTOs (classes typées + validation runtime), énumérations (PHP enums + match), génériques (via docblocks et analyse statique), métadonnées (attributs PHP), validation (Symfony Validator), gestion des erreurs (objets Result ou exceptions), et asynchrone (queues ou Fibers). L’approche est incrémentale, avec des exemples prêts à l’emploi, et met en avant les forces de PHP (écosystème mature, performances) tout en comblant l’écart avec TypeScript sur la sécurité et l’ergonomie. À retenir : combiner typage statique, validation aux frontières et design explicite pour un code PHP aussi robuste et maintenable qu’une base TypeScript, sans tout réécrire.
L’article explique comment gérer la traduction de contenu statique (menus, titres, boutons) dans Symfony à l’aide du composant Translation. Il détaille les étapes clés : installation via symfony composer require translation, configuration des locales dans translation.yaml et routes.yaml, utilisation de clés (ex: about_us) dans des fichiers YAML par langue (messages.en.yaml, messages.fr.yaml), et intégration dans Twig avec le filtre |trans et un sélecteur de langue dynamique. Il aborde aussi le débogage avec debug:translation et l’extraction automatique des clés manquantes, tout en évoquant l’option d’utiliser des services externes comme Crowdin pour une gestion collaborative. Une approche simple et efficace pour internationaliser une application Symfony.
L’article explique la différence fondamentale entre les DTO (Data Transfer Object) et les Entities dans Symfony, deux concepts clés pour structurer proprement une application. Les Entities représentent les objets métiers persistés en base de données, liés à Doctrine et souvent chargés de logique complexe, tandis que les DTO sont des objets légers, dédiés au transfert de données entre les couches (API, formulaires, services), sans logique métier ni persistance. Utiliser des DTO permet de découpler la validation, la sérialisation et la manipulation des données des Entities, améliorant ainsi la maintenabilité, la sécurité (en évitant d’exposer directement les Entities) et la clarté du code. L’auteur souligne que les DTO sont particulièrement utiles pour gérer les entrées/sorties des contrôleurs ou des services externes, tandis que les Entities restent le cœur du modèle de données. En résumé, bien distinguer les deux optimise l’architecture et réduit les risques d’incohérences ou de fuites de données sensibles.
L'auteur partage son parcours personnel et professionnel avec Kubernetes, soulignant qu’il n’existe pas de réponse universelle. Il a découvert l’orchestration via Docker Swarm, puis Kubernetes à travers des services managés comme AKS (Azure) et GKE (Google Cloud), avant d’expérimenter des solutions plus légères comme K3S et Talos Linux. Chaque approche—services managés, déploiements "the hard way", ou outils simplifiés—offre des avantages et des limites, selon le contexte et les besoins. L’important est de choisir la méthode qui suscite la curiosité et permet d’apprendre en pratiquant, car Kubernetes et son écosystème évoluent constamment, offrant de multiples angles d’entrée. L’essentiel reste d’oser explorer et comparer, sans crainte de se tromper.
Un analyste confronté à une requête lente sur une table de 150 millions de transactions (2 minutes d’exécution, parfois des timeouts) a optimisé son code en utilisant une CTE (Common Table Expression) avec WITH. Au lieu de joindre d’abord les tables puis de filtrer, la CTE filtre d’abord les transactions récentes (20M de lignes au lieu de 150M), réduisant le temps d’exécution de 127 à 11 secondes. En allant plus loin et en agrégeant directement dans la CTE, il a même descendu ce temps à moins de 6 secondes. La clé ? Filtrer tôt pour alléger la charge de jointure, clarifier la logique, et exploiter les optimisations des moteurs modernes (PostgreSQL 12+, BigQuery). Attention toutefois : les performances varient selon le SGBD (risque de matérialisation en tables temporaires sous MySQL ancien). Une leçon simple : une requête bien structurée = des gains de performance majeurs.