Ce tutoriel explique comment sauvegarder un Raspberry Pi pour éviter de perdre des mois de configuration en cas de corruption de la carte SD. L’auteur propose une solution combinant deux outils : rsync pour sauvegarder les fichiers vers un NAS via le réseau, et rpi-clone pour cloner le système vers un disque physique (clé USB, SSD, etc.) de manière bootable. La méthode permet ainsi de disposer à la fois d’une sauvegarde réseau avec historique et d’un clone immédiat pour une restauration rapide.

L’article détaille d’abord la configuration de rsync avec un partage NFS sur un NAS Synology, incluant les étapes de montage manuel et automatique via le fichier fstab. Il souligne l’importance des options comme soft et timeo pour éviter les blocages en cas de déconnexion réseau. Ensuite, il aborde rpi-clone, limité aux disques locaux, mais idéal pour une duplication exacte et bootable du système.

L’approche hybride vise à couvrir tous les scénarios de restauration, que ce soit pour récupérer des fichiers spécifiques ou relancer le système en quelques minutes.

L’article analyse les UserNamespaces dans Kubernetes, une fonctionnalité présentée comme révolutionnaire mais souvent mal comprise. L’auteur souligne que ces espaces de noms réduisent l’impact d’une évasion de container en mappant l’UID 0 (root dans le container) vers un utilisateur non privilégié sur l’hôte, limitant ainsi les dégâts en cas de compromission. Cependant, il critique les promesses exagérées des infographies, qui présentent cette fonctionnalité comme une solution miracle contre les risques de sécurité, alors qu’elle ne couvre qu’un scénario spécifique (l’escape de container).

L’auteur détaille les cas d’usage concrets des UserNamespaces, comme l’exécution de builds sans privilèges (Buildah, Podman rootless) ou la gestion de legacy systems (Postfix, Dovecot) nécessitant des UID fixes. Il rappelle aussi que cette fonctionnalité ne remplace pas les bonnes pratiques de sécurité, comme le multi-tenancy ou la gestion des vulnérabilités kernel, et que son efficacité dépend d’une configuration rigoureuse. Les UserNamespaces sont utiles, mais leur adoption doit s’inscrire dans une stratégie globale.

Enfin, l’article met en garde contre une confiance excessive dans cette fonctionnalité, soulignant que les risques de sécurité applicative (mauvaise configuration, secrets exposés) ou opérationnelle (mauvaise gestion des ressources) restent critiques. L’auteur conclut que les UserNamespaces sont une avancée, mais qu’ils ne doivent pas occulter les priorités réelles en matière de sécurité Kubernetes.

L'article aborde une troisième stratégie d'héritage dans Doctrine, souvent négligée au profit des approches binaires STI (Single Table Inheritance) et CTI (Class Table Inheritance). L'auteur propose la Mapped Superclass, une solution intermédiaire qui permet de partager des propriétés et méthodes entre classes PHP sans imposer de contrainte de stockage unique ou de jointures coûteuses. Contrairement à STI (une table commune avec un discriminant) ou CTI (tables séparées liées par clé primaire), cette méthode crée des entités autonomes tout en conservant une structure de code cohérente.

L'auteur illustre son propos avec un cas concret : une classe abstraite AbstractContent marquée comme #[ORM\MappedSuperclass], héritée par des entités comme Post, Page ou Category. Chaque enfant bénéficie des propriétés communes (titre, slug, statut, métadonnées SEO) sans partager une table physique, évitant ainsi les inconvénients des deux autres méthodes. STI aurait entraîné des colonnes inutiles ou nulles, tandis que CTI aurait alourdi les requêtes avec des jointures systématiques.

Enfin, l'article souligne que cette approche offre un équilibre entre modularité et performance, en s'affranchissant des compromis des stratégies classiques. La Mapped Superclass est présentée comme une solution pragmatique pour des hiérarchies de modèles complexes, où la réutilisation du code prime sur les contraintes de persistance.

Les Fibers, introduites dans PHP en novembre 2021, sont une primitive bas niveau permettant un mécanisme de stack switch coopératif, souvent comparé à une suspension d'appel téléphonique où l'état complet (variables, pile d'appels) est préservé. Contrairement aux generators, elles permettent à n'importe quelle fonction, à n'importe quelle profondeur d'appel, de suspendre l'exécution via Fiber::suspend(), sans nécessiter une propagation manuelle du yield. Cette caractéristique est cruciale pour les bibliothèques asynchrones comme Amphp ou ReactPHP, qui encapsulent les Fibers pour offrir une API synchrone à l'utilisateur final, évitant ainsi le problème des colored functions.

Bien que souvent associées à tort au multi-threading ou à l'asynchrone pur, les Fibers restent mono-threadées et ne gèrent pas elles-mêmes les opérations d'entrée/sortie. Leur rôle se limite à fournir un outil de contrôle d'exécution précis, laissant aux bibliothèques le soin de gérer les attentes (sockets, timers, etc.). Leur minimalisme et leur explicitement en font une solution puissante mais peu visible dans le code applicatif classique, où elles opèrent en coulisses.

L'API des Fibers, volontairement épurée, repose sur quelques méthodes clés : Fiber::__construct(), Fiber::start(), Fiber::suspend() et Fiber::resume(). Cette simplicité reflète leur nature de mécanisme brut, conçu pour être intégré dans des couches d'abstraction supérieures plutôt que directement utilisé par les développeurs. Leur adoption discrète dans des frameworks comme Symfony s'explique par cette philosophie de conception.

Le billet du Google Testing Blog explique comment optimiser l'accès aux structures de données comme les maps ou dictionnaires pour éviter des opérations redondantes. L'idée principale est de regrouper la vérification d'existence et la récupération de la valeur en une seule opération, plutôt que de les effectuer séparément. Par exemple, en Python, utiliser employees.get(employee_id) au lieu de employee_id in employees suivi de employees[employee_id] évite un double accès à la structure.

L'article illustre cette optimisation avec plusieurs langages, comme Go (via l'idiome comma ok), C++ (map.find()) ou Java (computeIfAbsent()), qui permettent de combiner vérification et récupération en une seule passe. Cela améliore non seulement les performances, mais réduit aussi les risques de conditions de course dans des environnements multithreads.

Enfin, le texte aborde des cas courants comme l'initialisation de valeurs par défaut ou l'incrémentation, en recommandant des approches idiomatiques propres à chaque langage (comme defaultdict en Python ou les default-constructed values en C++). L'objectif est d'écrire un code plus propre, efficace et robuste, surtout à grande échelle.

L’auteur, consultant Cloud Native Infra, partage son expérience avec Mise, un outil de gestion de versions d’outils, variables d’environnement et secrets pour plusieurs projets. Il explique comment Mise simplifie la gestion de contextes multiples (versions d’outils, configurations Kubernetes, secrets) en remplaçant un mélange d’outils comme asdf, direnv ou sdkman, avec une activation automatique par répertoire via des fichiers TOML.

Son setup repose sur une arborescence hiérarchique où chaque niveau (global, projet parent, environnement spécifique) définit des configurations adaptées. Par exemple, les variables globales gèrent des éléments comme un proxy WireGuard, tandis que les fichiers mise.toml des projets parents et environnements ciblent des paramètres comme les endpoints OVH ou les adresses de Vault pour les secrets.

L’outil, écrit en Rust et rapide, permet d’éviter les erreurs courantes (comme exécuter une commande sur le mauvais cluster) grâce à une activation contextuelle transparente. L’auteur mentionne aussi une présentation récente à Devoxx France 2026 et des slides disponibles pour approfondir.

Ce tutoriel explique comment publier un blog généré avec Hugo sur Gitlab Pages, en s’appuyant sur l’automatisation via Gitlab CI. L’auteur détaille les prérequis nécessaires, comme la maîtrise de Git, un compte Gitlab avec une clé SSH configurée, ainsi qu’une installation fonctionnelle de Hugo. Le processus commence par la création d’un dépôt Gitlab nommé selon des règles spécifiques pour obtenir une URL accessible, comme pseudo.gitlab.io, facilitant ainsi la publication du site statique.

L’article guide ensuite l’utilisateur dans la configuration minimale d’un site Hugo au sein du dépôt, puis aborde l’automatisation de la compilation et du déploiement via Gitlab CI. L’auteur souligne que, bien que le tutoriel puisse paraître long lors de la première utilisation, les étapes suivantes deviennent rapides et simplifiées, permettant une mise à jour en moins de dix minutes. Une attention particulière est portée au nommage du dépôt pour optimiser l’accès au site final.

L’article souligne l’importance pour les développeurs de tester eux-mêmes leurs fonctionnalités avant livraison, plutôt que de se reposer uniquement sur des tests automatisés ou des équipes QA. Il illustre ce point par un exemple concret où une page fonctionnait techniquement mais était inaccessible aux utilisateurs standards, révélant un problème de permissions non détecté par les tests. L’auteur insiste sur le fait que les tests automatisés valident le code, mais c’est l’usage réel du produit qui en valide la pertinence.

L’auteur met en lumière l’effort supplémentaire que représente ce test manuel, nécessitant de se mettre à la place de l’utilisateur, d’explorer des parcours complets et d’anticiper des scénarios inattendus. Il critique la tendance à déléguer ces vérifications à d’autres équipes, ce qui crée une distance nuisible entre le développeur et le produit final, et retarde la détection de problèmes évidents.

Enfin, l’article défend l’idée que le travail d’un développeur ne s’arrête pas à l’écriture du code : il doit s’assurer que ce qu’il livre fonctionne réellement pour le client. Tester soi-même permet d’améliorer l’empathie produit, d’accélérer les revues de code et de réduire les coûts liés aux bugs visibles plus tard dans le cycle de développement. Les tests automatisés restent essentiels, mais ne remplacent pas une validation fonctionnelle manuelle.

L’article met en garde contre la pratique dangereuse curl | bash, souvent présentée comme une méthode d’installation simple, notamment dans des documentations officielles. Cette méthode, qui consiste à télécharger et exécuter directement un script depuis Internet, expose à des risques de sécurité majeurs. En effet, le script exécuté peut différer de celui consulté, car le serveur peut adapter sa réponse en fonction du contexte (navigateur, curl, adresse IP, etc.), exploitant ainsi les particularités du pipeline Unix où bash commence à exécuter le script avant même qu’il ne soit entièrement téléchargé.

L’auteur souligne que même l’utilisation de HTTPS ne protège pas contre cette menace, car il garantit uniquement l’intégrité du transport et l’authenticité du serveur, mais pas l’honnêteté du contenu servi. Un serveur malveillant peut ainsi fournir un script inoffensif lors d’une visualisation directe, tout en injectant un code malicieux lors d’une exécution via curl | bash. Des techniques comme la détection du comportement typique d’un pipeline (par exemple, en insérant une commande lente comme sleep) permettent à un serveur de distinguer une exécution directe d’une exécution via curl | bash, renforçant ainsi le risque d’exécution de code non désiré.

L’auteur présente Zensical, un nouveau framework de documentation créé par Martin Donath, ancien développeur de Material for MkDocs, en réaction à l’attitude jugée hostile du projet MkDocs. Zensical se veut une alternative moderne, 100 % libre et bien documentée, remplaçant avantageusement la combinaison MkDocs + Material for MkDocs, tout en offrant une base solide malgré son statut alpha.

Le tutoriel détaille l’installation via un environnement virtuel Python, la création d’un projet et son initialisation, illustrant le processus pas à pas. L’auteur souligne la simplicité des commandes et la régularité des mises à jour, tout en précisant que Zensical est déjà fonctionnel pour des projets de documentation technique.

Enfin, l’article annonce une série de guides pratiques pour exploiter Zensical, notamment pour publier des HOWTOs sur GitLab Pages, avec des sections dédiées à la configuration, à l’ajout de logos ou d’icônes, et à l’organisation du menu.

L’article explique les bases des filtres SVG, un outil permettant d’appliquer des effets visuels avancés. L’auteure, Ana Tudor, partage son expérience en découvrant ces filtres par nécessité technique, malgré son profil plutôt orienté logique que design. Elle souligne l’importance de structurer correctement un filtre SVG en le plaçant dans un élément <svg> masqué et hors du flux de la page, puis en le référençant via son identifiant unique.

L’article détaille les attributs essentiels comme id et color-interpolation-filters (souvent nécessaire pour garantir la cohérence des résultats entre navigateurs). Il explique aussi comment chaîner plusieurs filtres, que ce soit entre eux ou avec des filtres CSS, pour combiner leurs effets. Enfin, il mentionne la possibilité de définir une zone de clipping pour limiter l’application du filtre.

Les sub-agents de Claude Code permettent d’optimiser les workflows en isolant des tâches spécifiques dans des conversations dédiées, évitant ainsi la saturation du contexte principal. Ils offrent une meilleure gestion des informations en limitant la perte de détails critiques, souvent compressés dans les échanges longs. De plus, ils permettent de choisir des modèles adaptés à chaque sous-tâche et de paralléliser des opérations pour gagner en efficacité.

Concrètement, un sub-agent agit comme un collaborateur autonome : l’agent principal lui délègue une mission (recherche, analyse, correction) via un outil dédié, et ne reçoit en retour qu’un résumé des résultats, sans encombrer son propre contexte. Cette approche réduit la complexité des commandes et améliore la précision des réponses.

Cependant, leur utilisation nécessite une bonne compréhension de leurs limites, comme la gestion des dépendances entre tâches ou la nécessité de structurer clairement les instructions pour éviter les malentendus.

Cette page présente les Scroll-Driven Animations, une nouvelle API CSS permettant de créer des animations déclenchées par le défilement, sans JavaScript. L’idée centrale est d’associer des animations existantes (comme @keyframes) à une progression de défilement plutôt qu’à une durée fixe, simplifiant ainsi les effets visuels dynamiques. L’auteur, Josh W. Comeau, illustre ce concept avec des exemples concrets et détaille son fonctionnement, tout en mentionnant les limites actuelles, notamment un support partiel des navigateurs (85 % selon Can I Use, avec Firefox nécessitant un flag).

L’article s’adresse aux développeurs familiarisés avec les animations CSS et explore des fonctionnalités avancées comme les timelines liés ou les plages d’animation personnalisées. Il aborde aussi les pièges à éviter et propose des solutions de contournement, comme un polyfill imparfait. Malgré un support encore incomplet, l’auteur encourage son adoption pour des améliorations cosmétiques, anticipant une généralisation prochaine, notamment dans Firefox.

Enfin, la page s’inscrit dans un contexte plus large, avec une mention de la sortie récente d’un cours de l’auteur sur les animations, bien que le contenu principal se concentre sur l’API elle-même. Les exemples interactifs permettent de tester les possibilités offertes par cette technologie émergente.

L’article explore les limites de l’open source comme solution pour réduire la dépendance de l’Europe aux géants technologiques américains, malgré son potentiel théorique. L’auteur compare cette situation à une fuite économique, où l’Europe dépense 264 milliards d’euros et perd un million d’emplois chaque année en important des services numériques, tout en subissant des pressions géopolitiques et des risques d’espionnage ou de manipulation. L’open source est présenté comme une piste envisagée, mais son efficacité est remise en question, notamment en raison de sa gouvernance souvent contrôlée par des acteurs américains ou de ses dépendances à des plateformes comme GitHub.

L’auteur souligne que l’open source ne garantit pas une souveraineté numérique, car de nombreux projets majeurs sont financés ou contrôlés par des entreprises américaines, et leur licence ouverte n’empêche pas des décisions unilatérales défavorables à l’Europe. Les risques incluent l’exclusion des écosystèmes dominants, l’introduction de portes dérobées ou l’inadéquation avec les réglementations locales, comme la protection des données. Créer une alternative européenne nécessiterait des ressources colossales pour maintenir et auditer des projets, tout en rattrapant un retard technologique déjà important.

Enfin, l’article mentionne des initiatives comme la fondation Eclipse, seule grande fondation open source européenne, mais dont les principaux contributeurs restent majoritairement américains. L’écosystème global, dominé par des acteurs extérieurs, limite fortement la marge de manœuvre de l’Europe, illustrant que l’open source seul ne suffit pas à briser cette dépendance sans une stratégie plus large combinant innovation, régulation et investissement local.

Cet article de JoliCode présente une méthodologie pour migrer vers Tailwind CSS v4, en détaillant une approche progressive et peu douloureuse. L’idée principale est de remplacer les anciennes solutions CSS basées sur Sass (comme Bootstrap v4 ou des frameworks maison) par des technologies plus modernes, en s’appuyant sur le CSS natif et les fonctionnalités de Tailwind v4, qui ne nécessite plus de dépendances comme Sass. La migration se fait en deux phases clés, la première consistant à convertir les variables et fonctions Sass en variables CSS natives et en syntaxes modernes.

La première phase se concentre sur la migration des feuilles de styles CSS, notamment en remplaçant les variables Sass par des custom properties (variables CSS) définies dans :root. Par exemple, $color-primary: [#f7d325](https://raphael.salique.fr/liens/./add-tag/f7d325); devient --color-primary: [#f7d325](https://raphael.salique.fr/liens/./add-tag/f7d325);. L’article souligne l’importance d’adopter dès cette étape la nomenclature de Tailwind CSS v4 pour faciliter la transition. Les fonctions Sass comme darken() ou les calculs mathématiques (math.div()) sont remplacées par des équivalents natifs, comme hsl(from var(--color-primary) h s calc(l - 15)) pour les manipulations de couleurs.

Enfin, l’article aborde un piège courant : l’imbrication des sélecteurs (& en Sass) et les conventions comme BEM. Il met en garde contre les sélecteurs trop imbriqués, qui compliquent la migration, et recommande de simplifier la structure CSS pour éviter les conflits. L’objectif est de rendre le code plus maintenable et compatible avec les standards modernes, tout en préparant le terrain pour une adoption plus large de Tailwind CSS v4.

Cette page explore la paléontologie à travers une collaboration avec des chercheurs comme Antoine Souron et Raphaël Hanon, spécialistes des faunes anciennes et des comportements humains préhistoriques. L’auteure, Marion Montaigne, s’appuie sur leurs travaux pour évoquer des sujets comme le cannibalisme chez les homininés ou l’étude du fossile de Bodo, illustrant ces recherches par des références culturelles, dont une émission culinaire des années 1980.

Les sources citées incluent des vidéos et articles accessibles, comme une conférence sur les Suidés ou des études publiées sur The Conversation, offrant des pistes pour approfondir. L’humour et les anecdotes, comme la référence à l’émission La cuisine des mousquetaires, rendent le sujet accessible tout en soulignant l’évolution des pratiques scientifiques et sociétales.

Le billet mêle vulgarisation scientifique et ton décalé, typique de la série, tout en remerciant les experts ayant inspiré le contenu. Les commentaires des lecteurs, bien que peu nombreux, réagissent à l’aspect parfois choquant ou nostalgique des références historiques.

Maintenir un cerveau performant repose largement sur des facteurs modifiables du mode de vie : une part importante des risques de déclin cognitif (jusqu’à 45 % selon certaines analyses, voire plus de 70 % selon d’autres études) est liée à des éléments comme l’activité physique, l’alimentation, le sommeil, la santé cardiovasculaire, la stimulation intellectuelle et les interactions sociales.

L’approche proposée insiste sur l’idée que le cerveau doit être régulièrement stimulé et challengé : apprendre de nouvelles compétences, varier les activités, sortir de la routine et éviter la sous-stimulation, qui peut être aussi délétère qu’un excès de stress. La curiosité, l’effort cognitif et l’exposition à des environnements nouveaux contribuent à entretenir la plasticité cérébrale.

Enfin, la prévention est centrale : corriger les déficits sensoriels (vision, audition), limiter les traumatismes et les facteurs de risque métaboliques, maintenir des liens sociaux et gérer la santé mentale sont autant de leviers concrets pour préserver les fonctions cognitives sur le long terme, avec un accent sur la constance plutôt que sur des interventions ponctuelles.

L’article explique la migration d’un outil de génération de PDF, wkhtmltopdf, vers Gotenberg dans une application Symfony legacy, en évitant de perturber les endpoints existants. L’idée principale est de découpler la génération de PDF du conteneur API pour améliorer les performances et la maintenabilité, car wkhtmltopdf consommait trop de ressources CPU et reposait sur des dépendances locales (fichiers, polices, images). Le processus a nécessité de refactoriser l’architecture pour externaliser le rendu HTML vers un conteneur dédié, tout en gérant les différences de rendu entre les moteurs (problèmes de polices, de mise en page ou de chemins d’accès).

La migration a révélé des défis techniques, comme la gestion des chemins de fichiers (remplacement des références locales par des URLs accessibles) et les écarts de rendu entre wkhtmltopdf et Chromium (Gotenberg), entraînant des modifications de mise en page inattendues. L’approche adoptée a consisté à migrer progressivement, type de document par type de document, pour limiter les risques et permettre des ajustements fins. L’objectif était de préserver la compatibilité des endpoints tout en améliorant l’infrastructure.

L’article propose une solution pour tester efficacement le JavaScript dans Symfony Asset Mapper, souvent confronté à des erreurs comme ERR_MODULE_NOT_FOUND en raison de l’incompatibilité entre l’importmap.php de Symfony et les outils Node.js. L’auteur suggère d’utiliser des liens symboliques pour faire correspondre les fichiers Symfony (dans assets/vendor ou vendor) avec la structure attendue par Node.js dans node_modules, évitant ainsi de dupliquer ou modifier les imports.

Un script PHP automatise la création de ces liens symboliques en analysant l’importmap.php, permettant à Node.js de résoudre les modules comme en production. Cette méthode s’intègre via un pretest dans le package.json, exécutant le script avant chaque test. L’approche privilégie le test runner natif de Node.js (depuis la version 20) pour sa simplicité, sa rapidité et son absence de configuration complexe, tout en testant les fichiers réels utilisés en production.

Twig 3.24.0, sorti avec Symfony 7.4, introduit des fonctionnalités avancées pour simplifier la création de composants UI réutilisables, répondant aux besoins des systèmes de design modernes et des frameworks comme Tailwind. Parmi les nouveautés, la fonction html_attr, la stratégie d'échappement html_attr_relaxed et les opérateurs null-safe améliorent la gestion des attributs HTML et des données dynamiques, réduisant ainsi la complexité des templates.

L'article explique comment abandonner les tableaux non structurés pour des DTOs strictement typés et validés, combinés à des attributs PHP 8.x et à Symfony 7.4's #[MapRequestPayload], afin de transmettre des données propres et validées directement aux templates Twig. Cela renforce la robustesse des applications tout en maintenant une bonne expérience de développement.

Pour utiliser ces fonctionnalités, il est nécessaire d'installer les packages twig/html-extra, symfony/serializer et symfony/validator, et de vérifier que Twig 3.24.0 ou supérieur est bien installé. L'article détaille également la configuration requise et présente un exemple concret de création d'un composant Button avec des DTOs stricts.