L’auteur, utilisateur de GNU/Linux depuis 1999, explique comment il a surmonté ses appréhensions pour contribuer au noyau Linux, malgré un parcours non traditionnel en programmation. Il détaille son expérience avec des noyaux personnalisés pour smartphones (comme Dora sur un OnePlus 7 Pro), où il a d’abord modifié des modules existants avant de corriger des bugs, comme celui affectant le haut-parleur d’écoute (earpiece) sur un OnePlus 6 sous postmarketOS.

Son approche pragmatique montre que des contributions au noyau ne nécessitent pas une expertise avancée en électronique ou en programmation bas niveau, tant que l’on évite de toucher directement au matériel. Il illustre cela par la correction d’un compteur de référence mal géré dans le module wcd934x, résolvant un problème persistant après un mois de débogage.

Enfin, il partage ses corrections ultérieures de traces dans les logs du noyau, tout en reconnaissant que certains bugs, comme un crash aléatoire au démarrage, restent à résoudre. Son récit souligne que la contribution au noyau Linux est accessible, même pour des profils non experts, à condition de s’appuyer sur des outils comme les logs et les commits communautaires.

Cet article explique comment déployer une application Symfony avec Docker et FrankenPHP, une alternative moderne à l’architecture traditionnelle Nginx/PHP-FPM. L’auteur souligne les avantages de Docker pour garantir un environnement reproductible entre développement et production, évitant ainsi les problèmes de configuration manuelle. FrankenPHP, basé sur Caddy, simplifie l’architecture en servant directement les applications PHP, réduisant la complexité des conteneurs.

L’auteur détaille une configuration avec deux services principaux : FrankenPHP pour exécuter Symfony et MariaDB pour la base de données, orchestrés via Docker Compose. Le projet suit une structure classique Symfony, avec un Dockerfile pour l’environnement PHP et un fichier compose.yaml pour définir les services. Cette approche permet une mise en œuvre flexible et adaptable selon les besoins du projet.

Ce site est un carnet de cuisine personnel, intitulé Cooking Notebook, qui recense les recettes et expériences culinaires de l'auteur depuis 2020, avec 37 entrées à ce jour. Il couvre principalement des plats (sauces, viandes, accompagnements) mais inclut aussi quelques boissons, comme des cocktails. Les entrées sont datées, allant de mai 2020 à août 2026, et certaines recettes sont revisitées ou perfectionnées au fil du temps.

L'auteur, Josh Nesbitt, partage ses découvertes et techniques, avec une approche parfois technique (comme le Reverse-engineered Ragu ou la préparation du homard). Le site reflète une passion pour la cuisine, avec des recettes variées, allant des classiques (comme la baguette parisienne) à des créations plus audacieuses (comme le Burnt Corn Sea Bream Tartare).

Le blog est également lié à un compte Instagram, suggérant une approche visuelle et communautaire pour partager ses expériences culinaires.

La migration d’un projet Symfony utilisant Webpack Encore vers Vite avec Reprise a permis de réduire significativement les temps de build, passant de 75–100 secondes à une quinzaine, tout en supprimant 583 packages npm. Reprise, successeur officiel de Webpack Encore, agit comme une interface entre Symfony et Vite, déléguant la majorité des tâches de build à Vite, qui gère nativement des fonctionnalités comme Sass, TypeScript ou React.

La migration mécanique a été simplifiée grâce à la rétrocompatibilité offerte par Reprise, avec des étapes comme la suppression du bundle Webpack Encore et l’ajout de Reprise via Composer, ainsi que l’intégration de Vite. Les configurations complexes de Webpack, souvent longues de centaines de lignes, ont été réduites à une cinquantaine de lignes dans Vite, où les loaders et plugins sont désormais gérés par défaut.

Cependant, la migration a révélé des défis liés aux dépendances implicites du projet avec Webpack, comme des comportements spécifiques au runtime ou des "webpack-ismes" difficiles à anticiper. Malgré cela, l’adoption de Reprise a permis d’améliorer l’efficacité du développement, notamment avec la mise en place du hot reload dans une stack Docker, tout en préparant le projet à une évolution future plus stable.

L’auteur décrit son expérience pour déployer VS Code Web et Codex sur son serveur via un navigateur, afin d’accéder à son environnement de développement à distance sans installation locale. Après plusieurs essais infructueux avec des solutions conteneurisées comme Kasm ou des images Docker inadaptées, il a finalement opté pour une approche plus directe : exécuter VS Code en dehors de Docker tout en utilisant Nginx Proxy Manager comme reverse proxy pour sécuriser l’accès via HTTPS et une authentification basique.

Le projet visait à reproduire l’expérience fluide de Remote SSH avec Codex, en permettant l’édition de fichiers réels, l’utilisation d’un terminal intégré et l’analyse de l’infrastructure serveur (Docker, systemd, logs) directement depuis le navigateur. L’auteur souligne l’importance de distinguer une interface web native d’un simple bureau distant (comme Kasm), ce dernier étant limité par des contraintes techniques (VNC, presse-papiers peu pratique) et ne répondant pas à ses besoins d’intégration système. La solution finale combine donc VS Code en local sur le serveur, Codex pour l’analyse automatisée, et Nginx Proxy Manager pour exposer l’interface de manière sécurisée.

L’article explique comment implémenter un chiffrement au niveau des champs dans une application Symfony/Doctrine pour se conformer au RGPD, en évitant de polluer le domaine métier. L’auteur souligne que le chiffrement transparent des données (TDE) ne suffit pas, car il ne protège pas contre les accès internes malveillants ou les failles comme les injections SQL. La solution proposée consiste à chiffrer les données sensibles (emails, numéros de téléphone, etc.) avant leur stockage en base, en utilisant soit un type DBAL personnalisé, soit un lifecycle subscriber, sans modifier les entités.

Le type DBAL personnalisé, comme EncryptedStringType, s’intègre naturellement entre PHP et la base de données, chiffrant les données lors de l’écriture et les déchiffrant à la lecture, sans que le domaine n’ait à gérer cette logique. Cette approche maintient une séparation claire des responsabilités, où le chiffrement reste une préoccupation d’infrastructure. L’article détaille l’implémentation technique, notamment l’injection des dépendances et l’enregistrement du type dans Doctrine.