L’auteur partage son expérience avec les ORM (Object-Relational Mappers) et conclut qu’ils sont plus nuisibles que bénéfiques, recommandant d’apprendre SQL directement. Il souligne que les ORM masquent des problèmes complexes comme la gestion des identités d’entités, les schémas duaux ou les requêtes inefficaces, tout en encourageant des pratiques problématiques comme l’accumulation d’attributs ("attribute creep") ou l’usage excessif de clés étrangères, qui alourdissent les requêtes.

Il explique que les ORM poussent souvent à des pratiques comme l’utilisation de SELECT *, ce qui génère des transferts de données inutiles et des ralentissements. De plus, des fonctionnalités avancées comme les fenêtres SQL (window functions) deviennent difficiles à implémenter avec un ORM, obligeant à transférer des données massives vers l’application plutôt que de les traiter directement dans la base.

En résumé, l’auteur défend l’idée que maîtriser SQL permet d’éviter les pièges des ORM et d’écrire des requêtes plus performantes, tout en simplifiant la maintenance du code.

Selon l’article, toute personne ayant au moins un grand-parent européen descend directement de Charlemagne, un ancêtre commun récent (MRCA) dont les liens généalogiques se multiplient exponentiellement à mesure qu’on remonte dans le temps. L’auteur explique que cette réalité, bien que contre-intuitive, s’explique par l’effondrement généalogique : dans une population finie, les ancêtres apparaissent plusieurs fois dans un même arbre, réduisant drastiquement le nombre d’individus uniques à chaque génération.

L’exemple québécois illustre ce phénomène, où quelques milliers de fondateurs coloniaux, comme Zacharie Cloutier, se retrouvent des dizaines de fois dans les généalogies locales, voire dans celles de célébrités contemporaines comme Madonna ou Céline Dion. Cette consanguinité généalogique, loin d’être exceptionnelle, est une conséquence mathématique des limites démographiques passées et de la survie inégale des lignées.

L’article souligne que cette logique s’applique à l’échelle mondiale, où tous les humains descendent d’un point des ancêtres identiques (IAP), remontant à quelques milliers d’années seulement. Ainsi, l’humanité forme une seule famille interconnectée, un constat qui dépasse les simples calculs généalogiques pour toucher à la génomique et aux statistiques.

L’article explore l’application des principes du Domain-Driven Design (DDD) pour structurer une architecture front-end plus claire et alignée sur les besoins métiers. L’auteur, Othniel Visky, partage son expérience sur un projet de refonte d’une application de calcul de charge explosive, où le DDD a permis de créer une base de code plus compréhensible et évolutive. Le DDD résout notamment le problème de l’organisation chaotique des composants front-end, souvent classés de manière arbitraire (comme dans Atomic Design), en les regroupant par domaine métier, reflétant ainsi leur fonction réelle.

Le cœur du DDD repose sur deux concepts clés : le modèle (représentation des règles métiers) et le langage ubiquitaire (vocabulaire commun entre développeurs et experts métiers). Ce dernier évite les malentendus en standardisant la terminologie, facilitant la collaboration. Par exemple, dans le projet cité, le DDD a permis de structurer le code autour des concepts spécifiques au calcul de charge explosive, rendant les discussions avec les experts métiers plus fluides et les implémentations plus précises.

Enfin, l’auteur souligne que le DDD ne se limite pas à l’architecture technique : il transforme la façon dont les équipes conçoivent et maintiennent un produit. En adoptant cette approche, les développeurs front-end gagnent en clarté sur les attentes métiers, tandis que les experts non techniques voient leurs besoins mieux traduits en solutions logicielles. Une méthode particulièrement utile pour les applications complexes où la compréhension du domaine est cruciale.