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