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.