Article très intéressant (bien qu'assez long) sur le concept de distributed data mesh : le but est en gros de ne plus faire un datalake monolithique, mais de le séparer entre toutes les teams. En gros, chaque product team devient responsable de la mise à disposition de ses datasets (comme elle l'est de ses APIs), grâce à un data engineer dans sa team et des outils mis à disposition par une autre équipe centrale de data engineer. Le concept est intéressant mais demande un gros changement de paradigme, et n'est utile selon moi que dans les grosses entreprises

Description assez intéressante de la naissance et de la 'mort' du concept de Big-Data, et notamment Hadoop. Bien sûr, le Big-Data n'est pas mort, mais son utilisation en tant que domaine global l'est. Ce concept est maintenant suffisamment implanté pour qu'on utilise des concepts plus spécifiques, comme le streaming, le multi-cloud...
Article que je comprend parfaitement mais qui me rend un peu triste, ayant commencé à travailler comme ingénieur big-data (maintenant plus data-engineer), quand le domaine était encore en pleine expansion (et totalement en mode fare-west). Maintenant les choses se sont un peu stabilisées : c'est à la fois plus simple et moins fun. Enfin, il reste encore de nombreux beaux challenges à adresser !

Deux articles (celui-là et le suivant) sur le principe de DataOps. En gros, l'idée c'est de s'inspirer de la mouvance Devops pour l'appliquer à la donnée. Ça consiste à automatiser un maximum, et donner pas mal de pouvoirs aux utilisateurs qu'il puisse créer lui-même les tables qui l'intéresse. Ça englobe aussi la validation automatique de schéma, la reproductibilité, la simplicité... Pas mal de bon sens mais c'est toujours mieux de le voir expliciter

Brève explication du principe d'idempotence. Notion importante en web, notamment pour les services REST, mais aussi cruciale dans le monde de la data, surtout quand on commence à orchestrer ses jobs (si je relance mon job de la veille, je veux être dans le même état que celui dans lequel il était)

Big list of data-engineer tools, on every interesting domain

Explications du rôle de data-engineer selon Maxime Beauchemin (créateur d'Airflow). Globalement d'accord sur sa vision (me considérant moi-même comme tel), même si je suis réticent sur certains détails.

Comment les data-engineers de quickbook gère leurs problèmes de données, à l'aide de court-circuit pour éviter que la donnée "sale" contamine la donnée propre. Pas mal car catégorise vraiment bien les différents problèmes de données possibles. On retrouve finalement certains mécanismes déjà mis en place (dans ma boite en tout cas), mais de manière plus claire. Bon on voit aussi que le chemin est long pour avoir un truc parfait mais bon, ça viendra !

Article lu il y a longtemps (je n'ai malheureusement pas pu poster de liens pendant longtemps à cause d'un problème de docker). L'auteur expose les différentes étapes pour itérer sur un projet de Machine Learning. Assez intéressant pour avoir une idée de comment procéder de manière logique, plutôt que de se lancer tête baissée sans savoir trop où on va.

Un article décrivant les bonnes pratiques à suivre quand on lance une start-up (spécifiquement une start-up développant un produit informatique B2C). Il peut se résumer en ceci : pensez uniquement à l'instant présent en recrutant un maximum d'utilisateurs et en satisfaisant le moindre de leurs besoins. D'où le titre de l'article : il n'est effectivement pas utile de trop prévoir (et donc de scale up), mieux vaut voir petit. Si vouy avez à scaler, vous verrez en temps utile (et ce sera un bon problème pour vous).
Ca me fait pas mal penser au développement informatique, où une des règles d'or pour moir est : pas de pré-optimisation. Faites un truc petit, mais qui marche bien. Ainsi vous pourrez convaincre rapidement un client. L'optimisation viendra après, si nécessaire, quand vous aurez mieux cerner les besoins nécessaires (car pour moi 90% de la pré-optimisation est ensuite à jetter, car basé sur les besoins supposés du client, tels que vu dans le cahier des charges, et non sur ses besoins réels, qui se voient à l'usage).

Excellent blog que je dévore ces temps-ci (j'en ai déjà posté deux articles ici), avec des nombreux articles, non pas techniques, mais plutot sur la culture informatique dans une boite ainsi que les concepts. L'auteur a été manageur informatique dans différentes boites, et en a tiré de précieuses connaissances sur la manière de gérer des projets informatiques qu'il ressort ici. À consommer sans modération.