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