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.

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’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.

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.

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 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.

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.

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é.