Le deuxième article

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)

Un article par le créateur de Flask sur comment implémenter une politique de retry dans une application multi-micro-services, pour éviter que la mise à jour d'un deux fasse tomber toute l'application. Un article que j'aurais bien aimé avoir sous la main pour certains de mes anciens projets... Mais mieux vaut tard que jamais !

Une description du concept d'artisan développeur : l'auteur fait une analogie entre le métier d'artisan de son père et de son grand père et son propre métier de développeur. On y voit que développeur n'est pas forcément si un métier à part que ça. Entre outre, cela fait une bonne description de ce qu'est un bon développeur selon moi.

L'évolution des technos big-data en fonction des différents bottlenecks rencontrés. C'est ultra-intéressants de voir les différe,ts problèmes et les solutions trouvés.
Prochain problème à régler : le fameux Grabage Collector. Un autre article là-dessus pour ceux que ça intéresse : http://blog.octo.com/la-mort-prochaine-du-ramasse-miettes/

Une bonne explication simple du Machine Learning en démontant quelques idées reçues. Et oui, bien que Big Data et ML sont deux domaines très liées, ils sont quand même bien séparées et indépendants (la preuve, mon école enseignait du ML depuis plus de 10 ans, soit avant l'apparition du Big Data en tant que tel).
Merci à Aurélie pour le lien

Tout est dans le titre. Après je ne suis pas tout à fait d'accord avec leur définition du data-scientist : pour moi, cela se réfère surtout à de l'exploration mathématique des données, sans tout l'aspect autour (visualisation récupération, stockage...). Quelqu'un amené à gérer tout ces aspects (comme je le fais actuellement) est plutôt un data engineer, qui sait manipuler la donnée sous toutes ses formes et dans toutes ses opérations. À ce titre il est amené à faire de la data-science (mais sans être data-scientist), de l'admin-sys (mais sans être admin-sys), du réseau (mais sans être admin-réseau), de la base de données (mais sans être DBA...). C'est ça qui me plait autant dans mon job, cette capacité de toucher-à-tout.
Après la majeure partie des définitions que je vois ne font pas cette distinction. Peut-être vais-alors finir par vraiment me considérer comme un data-scientist.

Pourquoi Google abandonne petit à petit Map-Reduce... C'est sûr qu'il y a pas mal de limitations dans le concept, mais ça a permis de développer des tonnes de trucs au dessus. Là-dessus, Hadoop est un peu comme R : c'est pas hyper fiable, y a des bugs, mais ça permet d'introduire de nouveaux paradigmes et façons de faire qui vont pouvoir être développés et améliorés jusq'uà ce qu'on n'ait plus besoin de la base. En tout cas, on n'est pas près d'en voir la fin je pense.