Cet article explore comment les habitudes façonnent l'identité, en s'appuyant sur des principes de neurosciences et de psychologie comportementale. L'idée centrale est que les changements durables passent par une transformation de l'image de soi plutôt que par la simple fixation d'objectifs externes. En adoptant des habitudes alignées sur l'identité souhaitée (comme se considérer comme "lecteur" plutôt que vouloir "lire plus"), chaque action renforce cette nouvelle perception, rendant les comportements automatiques et durables.

L'auteur explique que la clé réside dans la répétition de petits actes cohérents avec l'identité visée, qui finissent par réorganiser les circuits neuronaux. Le cerveau automatise ces comportements, les rendant naturels et sans effort, contrairement aux approches basées sur la volonté qui échouent souvent à long terme. Douze exemples concrets d'habitudes identitaires sont proposés pour illustrer cette méthode.

L'article souligne aussi que cette approche évite les pièges des objectifs temporaires, car elle crée une identité stable et motivante en soi, bien au-delà de la réalisation ponctuelle d'un but.

Proxmox Backup Server (PBS) est une solution de sauvegarde automatisée pour les machines virtuelles (VM) et conteneurs LXC, présentée comme une alternative fiable aux simples snapshots ZFS. L’auteur partage son expérience après avoir perdu des données faute de sauvegardes complètes, soulignant l’efficacité de PBS : sauvegardes incrémentielles rapides (2-3 minutes contre 20 pour un premier backup complet), déduplication des blocs identiques entre VMs, vérification d’intégrité via checksums et stockage distant possible. Un incident matériel (défaillance d’un NVMe) a permis de restaurer l’intégralité des VMs en moins de 10 minutes, illustrant l’avantage d’une solution dédiée.

L’architecture détaillée repose sur une VM PBS dédiée, hébergée sur un nœud distinct des VMs critiques, avec deux datastores NFS : l’un sur un NAS pour les VMs sensibles (rétention longue), l’autre sur un Synology pour les sauvegardes quotidiennes. La VM PBS elle-même est exclue de ses propres jobs de backup pour éviter des blocages, et les sauvegardes sont planifiées en dehors des pics de charge (2h du matin). La configuration inclut des règles de rétention différenciées (quotidiennes, hebdomadaires, mensuelles) selon les besoins.

L’installation de PBS suit celle de Proxmox VE, via une ISO dédiée, avec des prérequis matériels modestes (2 vCPU, 4 Go RAM, 32 Go de stockage système). L’intégration à Proxmox VE se fait via une connexion au serveur PBS, en spécifiant l’IP, les identifiants et le datastore cible. L’auteur détaille aussi le montage d’un partage NFS pour stocker les sauvegardes, étape clé pour une configuration robuste.

Ce dépôt GitHub recense une sélection d'outils axés sur la protection de la vie privée, couvrant divers besoins comme les messageries chiffrées, les emails anonymes, les VPN, le réseau Tor, les gestionnaires de mots de passe ou encore le partage sécurisé de fichiers. Il propose des alternatives open source ou auto-hébergées aux services traditionnels, avec des critères stricts pour évaluer leur fiabilité, leur transparence et leur utilité.

Les outils sont classés par catégories (navigation privée, stockage sécurisé, systèmes d'exploitation, etc.) et incluent des solutions pour particuliers, développeurs ou journalistes. Chaque recommandation est accompagnée d'une brève description et de liens vers leurs sources officielles.

Le projet met en avant des critères de sélection exigeants : amélioration concrète de la confidentialité, maintenance active, absence de téléchétrage ou de modèles économiques douteux, et priorité à l'open source. Aucune affiliation ou placement payant n'est toléré.

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.