Tellement d'accord avec ce qui est dit. Tellement de conflits, de problèmes pourraient être résolus si nous avions être pu éduqué à gérer nos angoisses, nos peurs, à savoir utiliser notre outil le plus précieux, c'est à dire notre cerveau (et pas dans un sens que rationnel, mais aussi émotionnel).
J'en profite pour dire que l'orientation des articles qui vont être publiés ici risque de changer radicalement, vu que je suis en train de petit à petit quitter l'informatique pour entrer dans le domaine de l'hypnose et de l'accompagnement.

Le deuxième article

Un article intéressant et complet sur les différents moyens de répliquer la donnée dans les bases de données distribuées, avec avantages et inconvénients de chaque approche. Pas mal pour choisir quelle base on veut, et permet de préciser des concepts dont on a parfois connaissance, mais sans une vue exhaustive.

NEw framework in python to manage configuration. Small thing, but in general you always finish by develop your custom tool when your project increase in complexity, so this could be very useful.

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.

Serie d'article sur la cyberguerre actuelle, traitant à la fois des cas politiques, économiques, législatifs... Vraiment très complet et extrêmement intéressant

Le futur système pouvant potentiellement (je ne suis pas devin) remplacer la lambda architecture. En gros, la lambda architecture permet d'une part d'envoyer en streaming des données dans une base finale, qui peut-elle être utiliser pour faire du batch et vous renvoyer des analytics rapidement. On a ici le meilleur des deux mondes : streaming et batch. Le problème c'est que cela implique beaucoup de contrainte, pouvant être potentiellement résolues par l'ALT.

Utiliser plusieurs environnements virtuels directement dans Jupyter, peut toujours être utile

Sèrie d'articles sur les algorithmes génétiques (fait de générer des solutions à un problème, puis croiser les meilleures d'entre elles pour arriver à une solution qui, après plusieurs générations, se rapproche de l'optimum (car oui on utilise ca en général pour des problèmes NP-complexe où la calcul de la solution optimale prendrait trop de temp)). Ne pas avoir peur du nombre d'articles, chacun d'entre eux décrit une étape de l'algorithme. Assez intéressant pour comprendre ce que c'est.

Astuces pour refaire pousser des légumes à partir de vos déchets. Une pratique que je fais depuis fort longtemps (à un moment, étudiant, j'avais un oignon et une patate qui poussait en même temps). Actuellement, j'en suis à une carotte et un avocat. À suivre !

Introduction à l'outil terraform, dédié à l'abstraction de la construction d'une infrastructure sur différents cloud provider. Faut vraiment que je teste un de ces quatre (promis Crichon)

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

Un autre excellent blog sur les manières de travailler en informatique (très souvent cité par Codeahoy, le précédent blog shaarlié) mais aussi avec quelques pans plus techniques, écrits par l'un des deux fondateurs de stackoverflow. Un de ses meilleurs articles porte notamment sur 'The Joel test' (https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/), un test établi afin de trouver les entreprises qui ont selon lui la meilleure culture informatique (les entreprises qui postent des offres sur Stackoverflow doivent notamment y passer). À lire absolument pour avoir une idée du bonhomme (surtout vu que l'erticle renvoie vers pleeeeeeeeeeeeins d'autres articles intéressants).

Qu'est ce que le Continuous Delivery et comment ca marche. Bon article qui m'a exactement fait comprendre pour le première fois la différence entre Continuous Integration, Continuous Delivery and Continuos Deployment :)

Une dataviz classifiant tous (enfin; un bon nombre) les genres de musique par proximité, avec des extraits musicaux pour chacun. On est ou pas d'accord, mais c'est clairement un travail très intéressant effectué informatiquement.

Quelques recommandations sur comment sécuriser informatiquement son entreprise. Arriver à un niveau pareil peut-être difficile, mais il est selon moi important de faire quelque chose à son niveau (il vaut mieux quelques règles simples que rien du tout). Cet article donne de bonnes idées là dessus

Cheat sheets sur plein de trucs en Python. Peut servir

Un portfolio de projets (simples ou moins simples) à faire pour se perfectionner en Python. Peut se faire avec un autre langage.
From Pwass: shaarli.nicolas-cellier.net.

Ou pourquoi Azure pourrait battre AWS dans la guerre des Cloud. Articles qui se focalisent uniquement sur les aspects non techniques, ce qui est intéressant (car meme si j'ai beaucoup bossé sur Azure et peu sur AWS, ce dernier est pour moi largement supérieur niveau technique). Mais on sais tous que ce n'est pas forcément l'aspect technique qui est primordial pour le choix d'une technologie dans un contexte de grande entreprise...
Après il n'y a pas vraiment de 'gagnant', ni de 'guerre'. Tout domaine informatique évolue très vite, on l'a toujours vu, et une technologie qui semble en monopole à un moment peut toujours etre remplacé (bon, ok, à paart windows pour le moment). C'est d'autant plus vrai pour moi qu'avec le Cloud, il est beaucoup plus facile d'avoir la main sur son infra, et donc de la changer rapidement, ce qui est moins le cas pour un infra on-prem.

Retour intéressant sur la journée sur Docker organisée par D2SI, SSII sur Paris. Les expériences sont vraiment intéressants. Bon par contre, moi qui veut me mettre plus là-dedans, ça me montre que j'ai encore des trucs à apprendre... Bard, ça viendra