Que dire de plus, sinon que j'ai déjà beaucoup eu le même sentiment, et que je suis entièrement d'accord.

Série de deux articles (l'autre arrive après) sur la data governance et la data quality chez Criteo, deux sujets qui deviennent de plus en plus important dans les entreprises (notamment dans la mienne). En efft, il ne suffit pas de récupérer plein de données, il faut aussi être sûr qu'elles sont documentées et de bonnes qualités. Sinon vos utilisateurs perdront très vite confiance dedans, ce qui pose pas mal de problèmes.

Un article défendant l'intérêt des bases SQL contre les bases NoSQL. Le SQL-bashing est effectivement quelque chose que j'ai pas mal vu (l'un de mes chefs disait il y a 5 ans que SQL allait mourir. Il a finis par reconnaitre qu'il s'était complètement gouré), souvent pour des mauvaises raisons (trop vieux, pas cassez shiny, trop rigide...). Et c'est vrai que je pensais en partie comme ça pendant un moment, en vantant énormément MongoDB par exemple (j'en suis revenu depuis), notamment pour sa souplesse. Or, par expérience, ce qui fait la souplesse et permet de démarrer très vite devient ensuite un enfer à maintenir. Avoir un schéma de base de données permet effectivement une énorme stabilité, qu'on est obligé de reproduire par plein de bidouille quand on utilise du NoSQL.
Bref, l'article explique bien tout ça, et reflète bien mon avis là-dessus

Présentation d'un outil pour voir les problèmes de qualité de données après avoir updaté un workflow. Pas mal d'idées intéressantes pour pouvoir garder une bonne data quality

Description de Airflow (outil d'orchestration de data) et de ses limites. Assez d'accord sur le fond, Airflow est vraiment un outil qui révolutionne le data engineering, mais qui, comme tout nouvel outil révolutionnaire (tel Hadoop et Docker) soufre de pas mal de défauts. L'auteur recommander prefect, un nouvel outil pour faire ça, mais peut-être encore un peu jeune pour être fiable. À suivre

Même axe que l'article d'avant, mais plus axé sur la comparaison avec l'avènement de la compilation et du versionnage de code, ainsi que sur l'opposition à la data governance.

Un outil open-source pour faire du data-profiling sur votre datalake (validation de schéma, statistiques de base...) Approche vraiment intéressante, car c'est fait en dehors du pipeline de données. Les outils utilisés sont aussi intéressants : Spark, Datadog, et surtout Jupyter + papermill pour piloter ça (solution dont je suis de plus en plus fan même si je n'ai jamais testé encore)

Brève explication de l'utilisation de dbt. En gros, ça permet de pouvoir observer facilement des changements de données dans une base, et de créer un pipeline de récupération et validation de données à partir de ça. Ou comment créer un ETL très facielement à partir de pas grand chose.

Explication visuelle du principe du blockchain. Ne rentre pas dans les détails, mais les bases sont là, et très bien expliquées.

Construction d'un datalake chez redBus, avec des technos full cloud. Assez intéressant de voir les outils et les usages (surtout que je participe à la même chose dans ma boite :))

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.

Comment pouvoir tester efficacement ses pipelines airflow. Pas mal de choses et d'aspect intéressant, et dont je compte bien m'inspirer, travaillant actuellement intensément sur Airflow

Série d'articles expliquant comment compiler soi-même son noyau linux (en désactivant plein de drivers inutiles au passage pour booter plus vite). Bien que ça faille peur de base, ça a pas l'air si compliqué. Faut que je test un de ces 4.

Une bonne description des qualités qu'il faut pour l'auteru pour etre un senior engineer. Où il montre qu'on n'a pas uniquement besoin de techniques, mais surtout de maturité. Et cette maturité passe par la faculté de travailler en harmonie avec les autres (accepter les critiques, rester ouvert à tout le monde et pas seulement à l'IT...).

Série d'articles sur la sécurité avec docker

RGPD (ou GDPR en anglais) arrive. Cette nouvelle loi européenne sur la protection des données arrive, et plein d'entreprises essaient de se mettre à jour. Cet article explique comment bien s'y préparer en 12 points.

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.

Un site pour expliquer argument par argument chaque commande shell que vous lui indiquez. Uniquement basé sur du parsing de man, mais très pratique pour comprendre une grosse commande shell trouvée sur Stackoverflow par exemple (au lieu de l'appliquer betement sans la comprendre, ce que personne ne fait jamais bien évidemment...)

Quelques outils pour partager son écran sur un logiciel à distance sans utiliser teamviewer

Pas grand chose à ajouter franchement. Je retravaille sur windows depuis 8 mois pour ma plus grande peine malheureusement. Sans parler de Azure qui n'est nettement pas à la hauteur des autres cloud (niveau fiabilité, ergonomie et usabilité)

Nombre aléatoire et sécurité en Python, avec quelques conseils pour sécuriser son serveur web.

Explication sur les différents répertoires Linux. À garder

Appel à candidature pour des projets d'utilité publiques proposées par différentes administrations. Ça a honnêtement l'air vachement cool ! Je vous laisse regarder tout ça, mais dommage que je ne sois pas en France pour candidater. Peut-être l'année prochaine.

Petite description de ce qu'est l'auto Machine Learning et des principales librairies pour en faire. Le principe ? Laisser une librairie trouver les meilleurs algorithmes et paramètres pour établir un modèle. C'est une idée à laquelle j'avais déjà réfléchi en tant qu'informaticien s'intéressant à la Data-Science. Pourquoi s'embeter à tester différents paramètres quand on peut automatiser le tout ? Avec, à la clé, un gain de temps pour le data-scientist qui peut passer son temps sur des algorithmes autrement plus compliqués. À voir comment cela évoluera dans le futur.

Petit truc qui m'a bien saôulé ce week-end, du coup je m'explique.
De puis la dernière mise à jour de mon blog sur le jonglage (jonglage.bwatt.eu), les accents des derniers articles uploadés apparaissent bizarrement. En gros, problème d'encoding.
Après un petit test, pas de souci quand je lance le code directement en local, mais sur mon environnement de dev, oui. Point commun avec la prod ? Ça tourne sur Docker. Le code n'est donc pas en cause.
Après avoir fouillé un moment, je me suis aperçu que ma mariadb sur Docker n'était pas en utf8, mais en latin1 ! Et il semble que ça soit la configuration par défaut de mariadb (je ne comprend pas qu'on puisse avoir ça par défaut). Quand on installe par les paquets sur archlinux ou sur Lint, c'est assez intelligent pour mettre en utf8. Mais il semble qu'ils aient oublié de faire ça sur la dernière image Docker...
La solution ? Relancer mariadb avec des flags pour être en utf8 (mysqld --character-set-server=utf8mb4 --collation-server=utf8mb4_general_ci --character-set-client-handshake=FALSE). Ou plutôt en utf8bm4. Car j'ai après dû changer l'encodage de mes tables et database en utf8, et suis tombé sur ceta rticle, expliquand qu'il faut utiliser utf8bm4 et non utf8. Je poste ça donc ici.

Les agriculteurs font de la résistance au Nebraska contre les grandes firmes. Au programmes de celles-ci : verrouillage des logiciels des tracteurs, brevets à gogo, et récupération à tout va de big-date dans le but à terme de remplacer l'humain. Encore une fois où je n'approuve pas l'usage non éthique des big-data, même si c'est mon boulot (quant aux brevets, n'en parlons pas). Assez moche mais au moins les gens essaient de s'organiser contre eux. Affaire à suivre

Autre article sur les Mocks en Python, avec quelques erreurs courantes expliquées.

Description des différents moyens de traiter des streams de manière probabiliste. Les méthodes classiques sont en effet parfois trop lourdes et requiert plus de mémoire. Ici, on ne s'attache pas à l'exactitude des résultats, mais à en faire une approximation. La plus célèbre de ces méthodes étant le bloom filter (déjà évoqué dans un précédent article)

Pourquoi les architectures Big-Data finissent par échouer en général. Un truc que j'avais déjà entendu il y a peu (par Gartner, qui a sorti que 70% des projets échoueront cette année !). C'est vrai que c'est un truc que j'ai souvent vu : des projets qui ne passent jamais l'étape du PoC. À cela plusieurs raisons selon moi :
- qui dit Big-Data dit Big-Architecture. Et donc difficile à maintenir. Un PoC ça va, mais maintenir ensuite demande du temps, des compétences, des gens et de l'argent. Ce que les entreprises ne sont pas prêtes à mettre
- ce qui amène au deuxième point : le manque de formation. Les projets sont en général faits par des externes qui maitrisent le sujet, et il y a peu de passation de connaissance. Que ce soit la faute de l'un ou de l'autre. Du coup, on se retrouve souvent avec des gens qui quand ils doivent s'éloigner d'une procédure établie, où on leur a donnée chaque commande, sont perdus. Le mieux est selon moi d'intégrer un interne lors du développement du projet afin qu'il puisse se faire la main dessus. Et ça, c'est rarement fait (par manque de temps, de budget, et à cause du "on verra bien plus tard" Trop tard souvent)
- les projets sont trop aboutis. La faute au effet hype (avec des articles qui promettent monts et merveille) et des boites qui mettent des étoiles dans les yeux des clients pour réussir la vente. Sauf qu'il faut ensuite réaliser le produit, et que ça s'avert beaucoup moins performant qu'annoncé, ce qui décoit le client. Les prestataires se disent que si elles ne font pas cela, elles n'auront pas de projets, mais c'est faux : une personne technique d'une boite sera toujours rassuré quand on lui dit qu'on va d'abord mettre un truc simple en place pour voir, et qu'ensuite on avisera (et c'est ces personnes-là qu'il faut viser !). C'est selon moi la meilleure façon de procéder : d'abord résoudre un problème que les gens ont, avec un projet simple, ce qui mettra le client en confiance, et lui donnera ensuite envie de signer pour plus gros (et le fidélise donc !). Personne n'a envie de tout changer d'un coup (surtout dans une grande entreprise, qui sont la majorité des clients en Big-Data !), donc l'approche petit à petit donne une chance de réussir, alors qu'un gros changement a toutes les chances d'échouer (quelque chose pour moi qui est très vrai dans beaucoup de situations).

Description des possibilités offertes par systemd, ça a l'air assez intéressant ! J'ai déjà une petite idée de comment l'utiliser. Je sais que systemd a fait couler pas mal d'encre, mais je pense que le débat était un peu inutile, il y a d'autres trucs sur lequels se prendre la tête. Et actuellement, la majorité des distributions l'ont adoptés, c'est donc que ça finit quand même par faire consensus (et init.d avait vraiment besoin d'un rempllaçant).

Librairies de visualisation en Python. Pratique pour du prototypage apparamment. À tester éventuellement (fournis par Pwass : http://www.nicolas-cellier.net/ et shaarli.nicolas-cellier.net)

Description de l'algorithme Raft, permettant de faire du consensus entre plusieurs serveurs (et utilisé par cockroachDB). Similaire à Paxos (que je compté étudier prochainement).

Un article tiré d'un des derniers bigdatahebdo sur spanner, le dernier-né dans la galaxie big-data chez Google Cloud. Il s'agit d'un des papiers blances qu'ils publient régulièrement. Un peu ardu, mais pas trop long pour une fois, donc accessible.
Spanner est un outil voulant réconcilier Big-Data et SQL, avec des possibilités énormissimes. Google a notamment réussi à contourner le fameux CAP théorème, grâce à une alliance de Hardware et de Software. Il n'y a qu'eux pour réussir un truc pareil (il n'y a pas grand monde qui maitrise aussi bien ces deux aspects). Pour la petite histoire, cela s'est notamment fait en installant des horloges atomiques dans leurs datacenters...

Un article sur la manière de conduire un projet pour ne pas perdre trop de temps. Je n'adhère pas à tout, mais il y a des idées intéressantes, qui rejoignent certaines choses que j'avais déjà tirée de ma (modeste) expérience à développer des projets. J'aime bien notamment tout ce qui incite à ne pas en faire trop. C'est vrai qu'en tant que développeur on a tendance à vouloir faire un outil super élégant, modulable et avec pleins de fonctionnalités. Sauf que à la fin le client finit toujours par n'en utiliser que la moitié. Mieux vaut se concentrer sur le périmètre et la documentation, quitte à avoir un outil un moins adaptable, et dont on est moins fier, "codiquement" parlant. Mais ça fait gagner tellement de temps.

Une critique du "tout" logiciel libre, prônant plutôt d'aller vers la gouvernance éthique. Bah oui, vous pouvez avoir une entreprise qui utilise uniquement de l'open source, mais derrière ne dit rien de ce qu'elle fait derrière. Donc ça ne suffit pas (ça rejoint un peu ce que fait Framablog). Sans rejoindre trop le fait de se passer du logiciel libre, c'est vrai que ce n'est plus l'unique objectif. Il faut aussi voir ce qu'il y a derrière. C'est marrant, je tombe de plus en plus sur des "critiques" du logiciel libre en ce moment, ce que je trouve pas mal. C'est ce qui permet de le remettre en question, et ainsi faire évoluer la question. Sachant que si on ne fait pas ça, on tombe dans le fanatisme, ce qui est quelque chose que je déteste (quel que soit la thèse défendue).

Article sur les condensateurs

Une bonne introduction à la programmation asynchrone en Python, avec toutes les nouveautés amenées dans python 3.5 (await et tout ça). Un truc sur lequel il faudra que je me penche sérieusement un jour, ça doit faire gagner pas mal de temps. Je garde ça en tête

Pour comprendre le compromis biais-variance (l'une des choses les plus importantes en Machine Learning).

Ça fait longtemps que je n'avais pas posté une bonne vieille datavisualisation. C'est désormais chose faite avec cette belle carte du vivant réalisée par l'université de Lyon.

Un petit guide bien fait avec bande dessinée à l'appui pour expliquer le fonctionnement de Kubernetes. Même si ce n'est pas trop mon domaine, je suis toujours intéressé par ce qui touche à l'automatisation, et notamment Docker (sur lequel tourne ce shaarli), et je compte bien un jour passer à Kubernetes et faire tourner tous mes conteneurs dedans.

La vidéo de ma présentation sur Python et Big Data à pydata 2016. Ok, mon accent est pas terrible mais c'est ma première présentation dans un évènement de cette envergure !
Pour résumer, j'explique en quelques points pourquoi Python me semble être un excellent langage pour faire du Big-Data.

Une réflexion sur le rachat de LinkedIn par Microsoft, avec les dérives que cela peut entrainer. J'adore mon boulot et tout ce que Big-Data, mais comme toute nouvelle technologie, il ne faut pas oublier les risques de dérive possible...

Un bon flux pour récupérer des news sur ce qui se passe dans le monde du hack. On y trouve pas mal d'informations sur Linux, Docker, Mozilla... Entièrement francophone.

Un évènement portant sur python et la donnée. Au programme : conférences, tutoriaux et rencontres en tout genre. Avec en prime, un talk présenté par votre serviteur sur python et le Big Data !

Dans la même lignée que le dernier lien, un site recensant les nouvelles applications développées par des personnes de l'administration (j'ai vu une conférence d'un des développeurs au Devoxx qui m'a donné envie d'aller voir). En gros, au lieu de mettre 10000 ans à pondre un énorme site mal foutu façn administration, le but est de lancer pleins de mini-projets sous forme start-up pour avoir un prototype en 6 mois, et ensuite consolider si besoin. Au menu : une application pour consulter les droits auxquels on a besoin de manière anonyme, une pour faire une demande de bourse, d'autres pour aider les handicapés ou les retraités... Pour une fois qu'on va dans le bon sens, j'applaudis des deux mains !

Un petit article de notre ami pwasson (mais si, vous savez, j'ai déjà posté des liens qui venaient de chez lui) sur les outils de publication. Plutôt axé scientifique, mais toujours bon à prendre !

Avec l'explosion des outils Big-Data, arrive l'explosion des architectures différentes. Et autant pas mal de gens arrivent à maitriser le batch, autant les autres types (streaming, lambda...) sont encore assez exotiques en dehors de grosses grosses entreprises. C'est là-dedans qu'il y a du boulot marrant du coup :)

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/

Un peu de Hadoop, ça faisait longtemps ! C'est vrai que, travaillant actuellement moins avec cet écosystème, je tombe sur moins d'articles. L'occasion de me rattraper avec un article pointant vers un grand nombre d'autres articles centrés sur des outils de l'écosystème Hadoop. À Consommer sans modération