Autoblog de sametmax.comhttp://sametmax.com/http://sametmax.com/ Que sont les websockets et à quoi ca sert ?https://sametmax.com/?p=26http://sebsauvage.net/streisand.me/sametmax/index.php?20221209_114759_Que_sont_les_websockets_et_a_quoi_ca_sert__Fri, 09 Dec 2022 10:47:59 +0000 Comment synchroniser les freeplugs (adaptateurs réseau CPL de Free) ?https://sametmax.com/?p=20http://sebsauvage.net/streisand.me/sametmax/index.php?20221209_113953_Comment_synchroniser_les_freeplugs___adaptateurs_reseau_CPL_de_Free____Fri, 09 Dec 2022 10:39:53 +0000 Comment utiliser les générateurs et les yield en Python ?https://sametmax.com/?p=16http://sebsauvage.net/streisand.me/sametmax/index.php?20221209_113443_Comment_utiliser_les_generateurs_et_les_yield_en_Python__Fri, 09 Dec 2022 10:34:43 +0000 Comment décompresser sous Linux en ligne de commande ?https://sametmax.com/?p=13http://sebsauvage.net/streisand.me/sametmax/index.php?20221209_112956_Comment_decompresser_sous_Linux_en_ligne_de_commande__Fri, 09 Dec 2022 10:29:56 +0000 Qu’est-ce que Javascript et à quoi ça sert ?https://sametmax.com/?p=6http://sebsauvage.net/streisand.me/sametmax/index.php?20221209_112428_Qu___est-ce_que_Javascript_et_a_quoi___a_sert__Fri, 09 Dec 2022 10:24:28 +0000 Le blog fermehttp://sametmax.com/?p=25357http://sebsauvage.net/streisand.me/sametmax/index.php?20190905_100531_Le_blog_fermeThu, 05 Sep 2019 08:05:31 +0000J’ai envie de passer à autre chose. Max ne s’en occupe plus depuis longtemps. Du coup je mets sametmax.com en berne. Vu le rythme de publication de 2019, ça ne fera pas une grosse différence de toute façon.

Évidemment, il restera en ligne, avec tout son contenu. 0bin.net aussi. Rappelez-vous que vous pouvez télécharger tout le blog pour le consulter hors ligne avec un petit:

wget -m -k -p -c -E http://sametmax.com

Max, pour le moment, veut bien maintenir à flot le multiboards et a même fait un peu de modération sur indexerror.net donc pour le moment, les services restent up.

J’avais déjà laissé tomber le reddit et le mastodont, mais le compte Twitter restait très actif. J’ai fait une demande de twitter pour télécharger tous les tweets pour avoir un historique. Je pense le mettre en lecture seule.

Ca a été un plaisir d’écrire les plus de 1000 articles de ce blog, avec la participation d’auteurs invités en prime, et les commentaires super sympas. Il y en a presque autant de pas publié, dont certains articles invités que je fais trainé depuis super longtemps. Désolé !

Même si Max n’a pas beaucoup écrit ces dernières années, c’est un pote en or et j’ai de la chance de l’avoir à mes côtés au quotidien. C’est vraiment hilarant d’aller à une conférence ou chez un client et d’entendre parler de nous: “tu connais sametmax ? – oui, très bon blog :) :) :)”.

Bonne pythonade à tous, et mettez un préservatif.

P.S: je rouvre les comments pour quelques jours.

]]>
Lancer correctement python et ses commandes cousineshttp://sametmax.com/?p=25303http://sebsauvage.net/streisand.me/sametmax/index.php?20190608_200002_Lancer_correctement_python_et_ses_commandes_cousinesSat, 08 Jun 2019 18:00:02 +0000python depuis la ligne de commande, ainsi que les commandes qui lui sont liées: pip, venv, etc.]]>Si j’avais su, j’aurais écrit cet article il y a 5 ans. Je pense que tellement de monde aurait évité des heures de frustration. Mais ça prend du temps de réaliser que des choses qui vous paraissent simples sont des obstacles pour d’autres.

Mieux vaut tard que jamais j’imagine.

Dans cet article, on va voir comment lancer python depuis la ligne de commande, ainsi que les commandes qui lui sont liées: pip, venv, etc.

Sous Windows

Vous avez installé Python, c’est certain. Vous lisez votre premier tuto, qui vous dit de lancer cmd.exe, et de taper python, mais impossible de le faire marcher. Des messages du genre ‘python’ is not recognized as an internal or external command apparaissent. Ou alors le mauvais Python se lance.

Déjà, premièrement, désinstallez Python, et réinstallez-le (en utilisant l’installeur officiel si possible), mais sur la toute première fenêtre de l’installeur, vérifiez bien que la case “Add Python to PATH” (ou son équivalent français) qui est tout en bas est cochée. Sans cela, le dossier d’installation de Python ne sera pas trouvable par le shell au moment de taper la commande. Je sais, ça devrait être coché par défaut. J’ai signalé ça plusieurs fois sur la mailing-list, et ils n’en ont rien à foutre.

Le clitoris de l'installation de Python

Le clitoris de l’installation de Python

Alternativement, si vous ne voulez pas désinstaller Python, ou si vous n’utilisez pas l’installeur de Python standard, cherchez le dossier où vous avez installé python. C’est un dossier qui doit contenir python.exe et un dossier appelé Scripts. Très souvent on le trouve à C:\users\[votre nom d'utilisateur]\Local Settings\Application Data\Programs\Python\Python36. Ajoutez ce chemin dans le sys PATH, ainsi le chemin vers le sous-dossier Scripts.

Redémarrer votre console. Vous devriez au moins pouvoir taper python -v.

Maintenant, sachez que vous ne devriez pas taper la commande python.

Whaaaaaaaaaaaaat ?

Vous entends-je me hurler suavement à l’oreille.

Non. Sous Windows, vous devriez utiliser la commande py -X.Y. La commande py permet en effet de spécifier la version de Python à lancer. Par exemple py -2.7 pour lancer Python 2.7, ou py -3.6 pour lancer Python 3.6, s’ils sont installés sur la machine, bien entendu.

Pourquoi utiliser la commande py ? Et bien parce que sinon, python lancera le premier python.exe qu’il trouve. Si vous avez plusieurs versions de Python installées sur votre machine, ce qui est souvent le cas sur les machines de dev, des fois à son insu, vous allez avoir des problèmes.

En fait, quand vous lisez un tutoriel sur Python, si vous lisez quelque part “tapez python”, remplacez-le mentalement par “tapez py -X.Y”. La commande marche strictement pareil que la commande python traditionnelle. Elle prend les mêmes arguments, et lance le shell de la même façon.

Aussi, rien à voir, mais n’utilisez pas les terminaux de cmd.exe ou powershell.exe. Ils sont à chier. Prenez le temps de télécharger cmder, et si vous le pouvez, faites le cmder.exe /REGISTER ALL en admin tant que vous y êtes.

Aussi petite astuce bien pratique: si vous maintenez shift et que vous faites un clic droit dans l’explorateur de fichier ou sur le bureau, un menu contextuel différent de celui habituel s’ouvre. Il contient des actions fort utiles:

  • “Ouvrir fenêtre de commande ici”, qui vous ouvrira la console, immédiatement dans le bon dossier.
  • “Copier en tant que chemin d’accès”, qui vous permettra de mettre le chemin de n’importe quel fichier dans le presse-papier.

Sous Unix (Max, Linux, etc)

N’utilisez pas la commande python, mais utilisez une commande suffixée pythonX.Y. Par exemple, pour lancer Python 2.7, tapez python2.7, ou pour lancer Python 3.6, tapez python3.6.

En fait, quand vous lisez un tutoriel sur Python, si vous lisez quelque part “tapez python”, remplacez-le mentalement par “tapez pythonX.Y”. La commande marche strictement pareil que la commande python traditionnelle. Elle prend les mêmes arguments, et lance le shell de la même façon, mais comme on a souvent plusieurs versions de Python installées sur une machine (sans parfois même sans rendre compte), c’est important de le faire.

Pour les linuxiens seulement

Pip et virtualenv sont fournis quand on installe Python sous Mac et Windows, mais souvent pas sous Linux ! Assurez-vous de toujours les installer avec votre gestionnaire de paquet, et ce pour chaque version de Python que vous avez.

Exemple: yum install python3.6-pip ou apt install python3.6-venv.

Tous OS confondus

Quand vous utilisez une commande écrite en Python, mettez python -m devant. C’est un cheat code.

N’appelez-pas pip, mais python -m pip.

N’appelez-pas venv, mais python -m venv.

N’appelez-pas black, mais python -m black.

Si vous lisez dans un tutoriel “tapez pip install”, remplacez-le mentalement par “tapez python -m pip install”.

-m ne marche pas avec toutes les commandes (python -m jupyter console a un bug, snif) car cela suppose que le développeur de la commande y a pensé, mais c’est le cas de la plupart des outils modernes.

Or -m va vous éviter tout un tas de problème de PATH, de droits et de version de Python.

Donc, si on combine tous les conseils, n’utilisez pas pip, mais py -3.6 -m pip ou python3.6 -m pip.

Je sais, c’est plus long a taper, mais ça va bien vous aider.

pip install

Certains outils doivent s’installer en global. On voit souvent des conseils comme faire un sudo pip install ou un sudo easy_install. C’est mal. Ceci va pourrir les paquets système de Python, et peut avoir des conséquences indésirables. Notez que parfois, rien ne marche, et je le fais quand même du coup.

Mais la plupart du temps, ce qu’il vous faut, c’est --user, suivi de -m. Par exemple, ne faites pas:

 
sudo pip install black 
black mon_fichier.py 

Mais faites:

 
python3.6 -m pip install black --user 
python3.6 -m black mon_fichier.py 

Notez le --user, ainsi que les deux usages de -m.

Ceci va installer black localement, pas au niveau du système. On s’assure qu’on n’utilise bien Python3.6, à l’installation et à l’usage de black. Et comme on n’utilise -m, on a pas à se demander si la commande black est bien sur le PATH (pas besoin de trifouiller son .bashrc ou le sys PATH de Windows.)

Mais c’est trop chiant !

Absolulement, c’est aussi pour cela qu’on utilise des environnements virtuels.

Utilisez des virtualenvs. Abusez-en. Un virtualenv par projet. Un autre pour les tests rapidos. Un pour maman, un pour papa, et un pour le fun. Ils ne coûtent rien que quelques Mo sur votre disque dur, donc lâchez-vous.

Car dans un virtualenv, non seulement vous êtes isolés des autres installations de Python, mais en plus… tous les conseils ci-dessus ne sont plus nécessaires !

Vous pouvez taper juste python et juste pip, plus de py, plus de suffixes, plus de -m et --user. Joie !

Moralité: les rares fois où vous êtes hors virtualenv, suivez les conseils des autres parties de l’article (py -3.6 -m pip install --user ou python3.6 -m pip install --user). Et des que vous le pouvez, pouf, virtualenv, et tout va pour le mieux.

]]>
Stack Python en 2019http://sametmax.com/?p=25193http://sebsauvage.net/streisand.me/sametmax/index.php?20190203_161021_Stack_Python_en_2019Sun, 03 Feb 2019 15:10:21 +0000Débuter avec Python en 2019, je me suis dis qu'il serait bon d'en rajouter une couche. Après toutes ces années, qu'est-ce que j'utilise pour mes projets Python ?]]>Suite au très bon billet Débuter avec Python en 2019, je me suis dit qu’il serait bon d’en rajouter une couche.

Après toutes ces années, qu’est-ce que j’utilise pour mes projets Python ?

D’abord, Python 3.6, partout

Pas la 3.5. Pas la 3.7.

La raison est que la 3.6 est un millésime exceptionnel, dans laquelle culminent des années de fixes et goodies. Malgré celà, sortie fin 2016, elle est facile à installer: ça prend quelques minutes sur même une centos 7 via les EPEL, ou sur une ubuntu 16.04 en utilisant le ppa deadsnake.

La 3.7 n’est non seulement pas aussi aisée à déployer, mais elle ne contient pas encore autant de correctifs, et surtout fige les mots clés async / await, créant des surprises. J’admets volontiers que breakpoint(), les dataclasses et asyncio.run() sont très tentants, mais je peux vivre sans.

Donc Python 3.6.

(P.S: django et numpy droppent le support de la 3.4)

Pour déployer, pex et nuikta

Quand j’ai scripts rapides mais pleins de dépendances , fini les virtualenvs et pip install en prod. Je package tout avec pex. Un fichier .pex est un format conçu par twitter l’équivalent d’un .war, que la présentation de Brian Wickman expliquera mieux que moi.

Mais en gros, en très gros, c’est un zip qui contient tout le virtualenv. On fait python mon_projet.pex et ça lance tout. Pas besoin de déploiement compliqué. scp, et c’est prêt. Je ne le recommande pas pour un gros projet web par contre. Mais pex rend le scripting Python merveilleux, et presque trop facile: plus besoin de s’interdire une dépendance par peur que le serveur ne l’a pas, ou par flemme. Du coup, même le script le plus simple à la puissance de feu de tout pypi, et ça m’a permis de faire des one-shots très complexes en deux coups de cuillères à pot.

Quand je dois livrer un programme chez un client qui ne soit pas Web, je compile tout avec nuitka. Je me fends même parfois d’un installeur nsis au besoin. Demander à autrui d’installer la VM est source de beaucoup de problèmes, et Python est un détail d’implémentation pour beaucoup d’utilisateurs de toute façon.

Gestion de projet: pew et setup.cfg

J’aime poetry, mais la compatibilité avec setuptools est importante à mes yeux. Tout l’écosystème supporte setuptools, tout est bien testé, c’est robuste et sans surprise. J’attendrais que poetry soit stable, testé, bien intégré et surporté. Évidemment, il faudra que pyproject.toml soit suffisamment mature également, et vu l’usage de sections custo pour tous les outils qui l’utilisent, on en est encore loin.

pew est très basique, mais il ne s’occupe que du virtualenv, laissant la gestion de mon projet à mes soins. Il est rapide, et sans chichi, de plus personne dans mon équipe n’a besoin de savoir que je l’utilise.

Après quelques essais, j’ai laissé tomber pipenv, qui a trop de problèmes, et dont l’auteur met des années avant d’entendre raison sur des choses essentielles, sur lesquelles il revient par ailleurs sans mine de repenti. Ça n’en retire rien à Kenneth Reth le mérite des ses travaux, mais j’ai des deadlines.

Outillage

À moins d’avoir été sourd et aveugle, vous avez du noter un certain engouement de la communauté pour black, que je vous ai déjà dis avoir adopté.

Les conséquences sont multiples sur la stack: j’ai viré flake8, et j’ai allégé de nombreuses règles ma configuration pylint, qui est du coup mon seul linter. Faudrait que je fasse un article dessus d’ailleurs.

Mypy étant maintenant stable et utilisable, je l’active par défaut. Ça ne veut pas dire que j’annote tout mon code. Parfois je n’annote rien. Parfois juste quelques fonctions. L’énorme avantage de mypy réside dans le fait que son utilisation est parfaitement progressive, et s’adapte à l’engagement et l’effort que vous voulez y mettre.date mypy est une des rares choses que j’upgrade à tout bout de champ, car chaque update amène une vraie qualité de vie en plus.

J’intègre tout ça dans mon éditeur, et en l’occurence VSCode rend l’opération très facile.

Pour le lanceur de tests, je reste sur pytest, pour des raisons déjà exposées. Honnêtement je ne connais pas de bonnes raisons de ne pas utiliser pytest. J’utilise faker pour générer des fausses données de test. Je n’arrive toujours pas à utiliser hypothesis. J’essaye, mais je n’arrive jamais à l’appliquer sur autre chose qu’un exemple joujou. J’espère y arriver un jour, car je suis certain que c’est excellent.

Pour lancer tout ce bordel, j’utilise tox, mais je ne l’utilise pas sur tous mes projets: seulement les gros avec certaines exigences.

Je n’ai pas de template de projet type. J’ai beaucoup lorgné depuis des années du côté de cookiecutter, je n’arrive pas à me motiver à l’utiliser sérieusement.

Enfin, j’installe toujours jupyter pour tester vite fait mon code, bien que j’utilise plus la console que le notebook. Et sphinx pour la doc.

Frameworks Web

Django (souvent avec django-rest-framework).

J’ai parfois des clients qui exigent flask, et donc je fais du flask. C’est toujours à regret.

Il n’a rien que flask me permette que je ne puisse faire avec Django, mais il y a une tonne de trucs à réimplementer à la main à chaque fois. À documenter. À tester. Tout ça pour changer de projet flask, et tomber sur un nouveau loustic qui a fait les trucs à sa sauce et tout recommencer.

Les projets flask ne sont bien faits que par ceux qui savent déjà très bien mener un projet Web, ce qui n’est pas la majorité des gens qui l’utilisent: en effet, il attire les utilisateurs par la simplificité de son API, et leur donne l’illusion d’être à la hauteur.

flask reste un excellent produit pour l’éducation, ou pour un petit projet vite fait, ce pour quoi je le choisis avec plaisir. Mais la majorité des projets flasks sur lesquels j’ai travaillé n’ont guère le niveau de qualité qu’on rencontre en moyenne dans les projets Python. C’est qu’on s’habitue, à force.

J’essaye aussi d’aimer SQLALchemy, dont je reconnais la flexibilité et la puissance. Mais son ergonomie est pénible, et la gestion des sessions suffisamment tortueuse pour se tirer une balle dans le pied si on cligne trop des yeux. Si j’ai des problèmes de perfs, je fais du SQL à la main de toute façon et j’utilise du cache en masse. Je reste donc sur SQLA seulement si flask, ou hors Web. Et encore, des fois je peeweese.

L’ORM de Django est une aberration en bien des points, sauf un seul. Il est éminemment pratique. Et je sais jusqu’où je peux le pousser: loin, très loin. Max va se gausser en lisant ces lignes, mais je me lasse de la beauté du code et de la pureté (ta gueule mec, arrête sourire, je te vois).

Bref, Django pour les seniors. Django pour les juniors, même si ça prendra plus de temps que flask, mais au moins le framework leur évitera de faire de la merde comme au temps de PHP à la main.

Question async, j’utilise aiohttp mais aussi fais du asyncio à là main, en faisant bien attention aux goto.

Non, je n’utilise pas les trucs du genre sanic, growler, vibora, quart, etc. Si ils sont toujours activement développés dans 3 ans, on en reparle.

Bonne nouvelle ceci dit, la doc d’asyncio est enfin potable, si vous voulez vous y mettre. Mais ça mérite quand même un article.

Ceci dit, les occasions de faire de l’asyncio sont rares. REST reste (hu hu) quand même l’option reine, HTTP2 peut se déployer via proxy et les threads assurent le plus souvent des perfs suffisantes. Pour être parfaitement honnête, j’utilise plus asyncio pour des scripts, daemon, et autres tâches de fond :)

En parlant de tâche de fond, je reste sur du celery, surtout depuis que je sais qu’on peut l’utiliser avec presque zero config. C’est le moins pire des systèmes. De toute façon j’ai presque toujours un redis sous la main, c’est bien trop facile et pratique pour s’en passer.

J’ai pas encore mis en prod django channels, ou aWSGI, mais je ne suis pas du tout convaincu par ces solutions, donc j’attends de voir.

J’ai eu l’occasion d’utiliser crossbar un peu plus. L’outils est toujours excellent, mais l’API a changé sans pour autant s’améliorer. Ils se recroquevillent dans l’illusion qu’un produit spécialisé dans l’IoT est une bonne stratégie, mais c’est une voie de garage à mes yeux. Le vrai potentiel est dans le Web. Je me fais à l’idée que le projet n’attendra jamais son potentiel tant que personne n’écrit une surcouche, et que ce ne sera pas tavendo qui le fera.

Libs

Les libs changent constamment, partant et venant selon la nécessité des projets. Au mieux puis-je vous dire ce que j’irais chercher si j’avais cette problématique.

Dates: pendulum.

Validation de données: marshmallow.

cli: click. Ça me fait mal de le dire, car je suis pas fan du style des APIs d’Armin (l’objet request global de flask, sérieux…), mais quand il fait un truc, on est sûr que ça marche. J’ai eu trop de limitations avec les alternatives.

Gestion du pognon: money.

Lib graphique: wxPython. Je fais du QT sur demande client, mais c’est trop gros pour des projets de moyenne taille.

Encoding: toujours chardet et unidecode.

Manipulation d’images: pillow.

Calculs numériques: numpy. À mon niveau je n’ai jamais besoin de scipy ou pandas.

Pour le parsing de conf je fais de plus en plus de toml, mais j’ai pytoml est pas terrible. Je vous ferai un retour sur contoml qui, si tout se passe bien, devrait être mon futur default.

Pour convertir du code Python 2 vers Python 3, python future et backport.

Pour faire du templating, jinja2.

Pour l’internationalisation, babel.

Hors de Python

Git. Vue. Webpack. Ubuntu.

J’évite docker comma la peste, même si certains clients le veulent à tout prix. Je fais du react, généralement sous la torture.

Pas grand-chose à dire de plus.

Ah si, j’ai laissé tombé zsh et fish pour revenir à bash. Le ROI me convient pas.

]]>
Le type bytes n’est pas du textehttp://sametmax.com/?p=25125http://sebsauvage.net/streisand.me/sametmax/index.php?20190111_123010_Le_type_bytes_n___est_pas_du_texteFri, 11 Jan 2019 11:30:10 +0000je craque. Mais je me soigne, globalement j'ai récupéré plein de temps, et ça se voit sur mon quotidien. Et ce craquage, et bien il est cette fois dû à une totale mécompréhension des types de texte en Python 3.]]>J’ai beau essayer très fort de ne pas répondre en ligne, des fois je craque. Mais je me soigne, globalement j’ai récupéré plein de temps, et ça se voit sur mon quotidien.

Et ce craquage, et bien il est cette fois dû à une totale mécompréhension des types de texte en Python 3.

Mais c’est bien normal: Python 3 ne gère pas le texte de la même manière que la grande majorité des langages de programmation, justement à cause de la débâcle qu’on a eue en Python 2. Du coup, de nombreux programmeurs arrivent avec leur expérience d’ailleurs, et tentent de l’appliquer tel un utilisateur de SVN migrant sur git. En surface ça semble coller, malheuseuement à l’usage, ça fait faire des erreurs.

Donc un peu d’explications.

En informatique, tout est une histoire de convention. On dit que tel mot clé a tel effet. Que tel nom suppose telle chose. Que tel code de retour implique telle erreur. Que tel schéma XML représente tel type de document.

Essentiellement, tout cela est arbitraire: des gens ont décidé qu’il en serait ainsi. Impossible de deviner que ce que fait yield ou with si vous n’avez pas d’expérience similaire avant. Impossible de savoir que le code 0 en bash ou 200 en HTTP signifie tout va bien sans qu’on vous transmette l’information, ou faire de nombreux tests.

Quand je dis arbitrairement, évidemment je ne veux pas dire complètement sans raison. Il y a des raisons techniques, politiques, économiques, et parfois esthétiques à ces conventions. Cela n’en retire en rien l’aspect parfaitement artificiel de ces choix.

La convention la plus omniprésente, et pourtant aujourd’hui la plus masquée dans un monde où on utilise massivement des langages de haut niveau comme Javascript, Ruby, PHP et Python, est celle de l’organisation des octets.

Musique !

…je vois même plus le code : tout ce que je vois, c’est des blondes, des brunes, des rousses.

Tout ce qui passe par nos ordinateurs n’est qu’une suite de zéros et de uns, que nous avons groupés par paquets de 8:

Seulement la grande révélation, le “aaaaaaahhhhh okayyyyyyy” qui arrive un jour dans toute vie de dev, c’est que ces paquets de 8 ne veulent rien dire. Rien. C’est nous qui avons décidé, arbitrairement encore une fois, de leur signification.

Vous voyez ce moment dans les films et séries où un personnage arrive à “lire du binaire” ?

Evidement, "c'est une representation binaire ASCII de coordonnées WGS 84 Web Mercator" est plus dur à caser dans un dialogue

Evidement, “c’est une representation binaire ASCII de coordonnées WGS 84 Web Mercator” est plus dur à caser dans un dialogue

C’est de l’enculage de dauphin.

Le binaire n’est pas un langage, pas plus que les lettres “abcdefghijklmnopqrstuvwxyz”. Vous pouvez utiliser ces lettres pour représenter certains mots italiens, français, anglais, un nom propre (sans langue), le label d’un immeuble (sans langue encore) ou un chiffre latin.

Que veut dire “les gosses” ? Pour la même combinaisons de lettres, cela signifie “les enfants” avec la convention française européenne, et “les couilles” avec la convention québéquoise.

Pour le binaire c’est pareil, ce que veut dire un octet dépend de la convention que vous avez choisie.

Par exemple, que signifie cette suite d’octets ?

1100001 1100010 1100011 1100100

Bah rien. Mais on peut lui donner un sens en lui appliquant une convention.

Je peux lui appliquer la convention ASCII, et donc supposer que c’est un texte dans un certain format. Voici ce que ça donne en Python:

     
>>> data = bytearray([0b1100001, 0b1100010, 0b1100011, 0b1100100])     
>>> print(data.decode('ascii'))     
abcd 
Les processeurs modernes ne comprenent pas nativement l'american apparel

Les processeurs modernes ne comprenent pas nativement l’american apparel

Ou je peux lui appliquer une autre convention, et decider de lire ces octets comme si ils étaient le dump d’une structure C. Interprettons en Python ces octets comme un entier non signé en big-endian:

     
>>> data = bytearray([0b1100001, 0b1100010, 0b1100011, 0b1100100])     
>>> import struct     
>>> struct.unpack('>I', data)     
(1633837924,)

Même suite de bits, mais selon la convention choisie, elle veut dire les lettres “abcd” ou le nombre “1633837924”. Et oui, comme il n’y a pas une infinité de combinaisons de 0 et de 1 qui tiennent dans un espace mémoire limité, différentes conventions vont utiliser les mêmes octets mais décider que ça veut dire quelque chose de différent.

En fait, même des conventions pour le même type usage ne veulent pas forcément dire la même chose. Par exemple, prenez l’octet:

11101001

Un octet somme toute sympathique, de bonne famille. Il ne paie pas de mine, mais c’est un membre utile de la société.

Et maintenant, quelqu’un vous donne un indice, il vous dit que cet octet représente… du texte.

Super !

Oui, mais du texte avec quelle convention ? Car les pays du monde entier ont créé leur propre convention pour représenter du texte.

Avec la convention “latin-1”, utilisé par 0.7% de tous les sites Web du monde ?

 
>>> bytearray([0b11101001]).decode('latin-1') 
'é' 

Avec la convention “cp850”, utilisé par la console DOS ?

 
>>> bytearray([0b11101001]).decode('cp850')
'Ú'

Vous voulez rire ? Le premier à remplacé presque partout le second parce qu’ils contiennent les mêmes lettres. Elles ne sont juste pas représentées par la même combinaison d’octets.

Et cet octet, que veut-il dire avec la convention “utf8”, qui est aujourd’hui le standard international recommandé pour représenter du texte ?

 
>>> bytearray([0b11101001]).decode('utf8')
Traceback (most recent call last):
File "", line 1, in 
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 0: unexpected end of data 

Il n’a pas de correspondance. Cet octet n’est pas de l’utf8 valide.

Si vous voulez représenter ces lettres en utf8, il faut utiliser une convention différente, en utilisant non pas un seul octet, mais une séquence d’octets:

 
>>> list(map(bin, 'é'.encode('utf8')))
['0b11000011', '0b10101001']
>>> list(map(bin, 'Ú'.encode('utf8')))
['0b11000011', '0b10011010']

Vous pourriez croire que puisque le texte est particulièrement compliqué, c’est normal d’avoir des conventions qui divergent. Mais non, c’est juste la nature des conventions. Puisqu’elles sont arbitraires, l’une n’est pas plus “la vérité” qu’une autre. On retrouve la même chose avec les nombres:

>>> struct.unpack("h", bytearray([0b11101001, 0b11101001]))
(-5655,)
>>> struct.unpack("H", bytearray([0b11101001, 0b11101001])) 
(59881,)

La même suite d’octets peut représenter deux nombres totalement différents, selon que je décide de les lire comme des “short”, ou des “unsigned short”.

Et l’inverse est aussi vrai.

Ben oui, si quelque chose peut être interprété de plusieurs façons, on a aussi le fait que deux représentations différentes peuvent être interprétées … pour aboutir au même résultat.

Par exemple, le nombre des doigts de ma main peut être représenté de plein de façons différentes:

  • décimal: 5
  • français écrit: cinq
  • chiffre latin: V
  • anglais écrit: five
  • espagnol écrit: cinco
  • base deux: 101
  • structure C d’un signed short en little-endian avec Python: bytearray([0b101, 0b0])

Que de manières différentes, pour le même concept ! En plus, il y a confusion possible: V est une lettre également. cinq, five et cinco utilisent le même alphabet, mais pas les mêmes symboles spécifiques, pour représenter la même chose. Et le plus confusionant, 101 est une représentation binaire, mais bytearray([0b101, 0b0]) aussi.

Bref, voilà toute la complexité de la différence entre la donnée, un concept abstrait qui n’existe pas, et sa représentation, une convention humaine concrète qui nous permet de communiquer entre nous.

Donc, pour lire “du binaire”, ou faire n’importe quoi en informatique, il faut connaitre la convention utilisée. Mais pas juste en informatique: pour lire le journal, il faut connaitre la convention des symboles imprimés sur les pages, pour conduire sans se faire tuer, il faut connaitre la convention des panneaux, et pour parler, il faut connaitre la convention de la compression des molécules d’air émise par l’appareil buccal et respiratoire d’un individu qui vient rencontrer votre système auditif.

Vous êtes un être très conventionnel au fond.

Évidemment on trouve la même chose en Python. Par exemple vous pouvez utiliser plusieurs conventions pour demander à Python de créer le même nombre en mémoire:

>>> 245 # base 10
245
>>> 0xF5 # hexadecimal
245
>>> 0b11110101 # binaire
245
>>> 245 == 0xF5 == 0b11110101
True     
>>> type(245)     
     
>>> type(0xF5)     
     
>>> type(0b11110101)     
 

Inversement, "1" et 1 paraissent similaire, mais ils ont différents buts. Le premier est un outil destiné à l’affichage, qui matérialise le caractère représentant le chiffre arabe après le zéro. Il est stocké en interne avec une séquence d’octets similaire à:

>>> bin(ord("1"))
'0b110001'

Tandis que que le second est un outil fait pour faire des calculs avec la plus petite valeur positive entière non nulle. Il est stocké en interne avec une séquence d’octets similaire à:

>>> list(map(bin, struct.pack('l', 1)))
['0b1', '0b0', '0b0', '0b0', '0b0', '0b0', '0b0', '0b0']

Je simplifie bien entendu, en vérité la representation interne des nombres et du texte en Python est plus complexe que cela, et dépend de l’implémentation choisie, du type de processeur, de la taille de la donnée et de votre configuration.

Retour sur le type bytes

J’ai soigneusement évité d’utiliser le type bytes durant cette démonstration, le remplaçant techniquement inutilement (mais pédagogiquement brillamment, car je suis génial) par bytearray.

En effet, toute cette leçon est là pour arriver à la conclusion que bytes ne représente pas du texte, mais si je vous avais montré tout ça avec lui, voilà qui vous aurait interloqué:

     
>>> bytes([0b1100001, 0b1100010, 0b1100011, 0b1100100])     
b'abcd' 

“Heu, mais c’est du texte !” me dirait alors un lecteur ayant diagonalisé l’article.

Mais bien entendu que non.

bytes ne présente pas du texte, c’est une structure de données dont le but est de permettre de manipuler une séquence d’octets ordonnée, et ce manuellement. N’importe laquelle.

Or, il se trouve que beaucoup de langages de programmation représentent le texte comme un array d’octets, et y attachent quelques opérations de manipulation. C’est le cas du C, ou de Python 2 par exemple. Les gens ayant eu cette expérience pensent donc que b'abcd' représente du texte, allant parfois jusqu’à aller lui donner l’appellation de “byte string”.

Il n’existe rien de tel en Python 3.

En Python 3, vous avez deux types pour manipuler des séquences d’octets: bytes et bytearray. Ils sont équivalents, à ceci près que bytes est non mutable (non modifiable) alors que bytearray est mutable (modifiable).

Ces types peuvent contenir n’importe quels octets, et nous avons vu ensemble qu’une même séquence d’octets pouvait être interprétée différemment selon la convention choisie pour la lire. Évidemment il est préférable de la lire avec la même convention qui a été utilisée pour la produire, sans quoi on ne comprendra pas ce que le producteur de la donnée à voulu dire.

Sauf que…

Beaucoup d’outils en informatique utilisent les conventions ASCII et hexadécimale pour symboliser les valeurs des octets. Si vous lancez Wireshark pour regarder les paquets d’un protocole réseau ou si vous ouvrez un PNG avec xxd, on va vous représenter le contenu avec un mélange de ces conventions.

Pour des raisons pratiques, Python fait donc la même chose, et permet ainsi de visualiser (ou produire) le type bytes à l’aide d’une notation ASCII:

    
>>> print(b'abcd'.decode('ascii'))     
abcd     
>>> struct.unpack('>I', b'abcd')     
(1633837924,)

Ou d’une notation héxa (ironiquement, l’héxa est representé par une combinaison de caractères ASCII \o/) si les valeurs ne tiennent pas dans la table ASCII:

     
>>> "é".encode('utf8')  # hexa C3 A9   
b'\xc3\xa9'     
>>> struct.unpack('h', b'\xc3\xa9')    
(-22077,)

Donc bytes, bien qu’il puisse contenir des octets interprétables comme du texte, n’est pas particulièrement fait pour manipuler du texte. Il peut contenir n’importe quoi. Mais pour des raisons pratiques, sa représentation dans le terminal est faite avec une convention familière. Après tout, il faut bien l’écrire en quelque chose pour l’affiquer à l’écran.

Si on veut manipuler du texte en Python 3, il faut utiliser le type str, qui est l’outil spécialisé dans la representation et la manipulation textuelle. Si vous savez qu’un type bytes contient des octets qui representent du texte, alors utilisez la méthode décode() avec la bonne convention (appelée “charset”), pour récupérer un str:

     
>>> print(b'P\xc3\xa8re No\xc3\xabl'.decode('utf8'))
Père Noël 

On a un très bon article sur l’encoding en Python sur le blog, d’ailleurs.

Toute cela n’était bien entendu pas vrai en Python 2. En Python 2, le type str était un array d’octets, rendant tout cela bien confus, et amenant à plein d’erreurs. L’introduction lors de la version 2.0 de l’objet unicode pour pallier le problème, bien que très utile, n’a fait que rajouter à l’incomprehension des nouveaux venus.

Or le monde extérieur, lui, n’a pas d’abstraction pour le texte. Faire des abstractions, c’est le rôle du langage de programmation. Si vous écrivez dans un terminal, ou lisez depuis un terminal, un nom de fichier, le contenu d’une base de données, une requête AJAX, etc., ce sont évidemment des octets qui sont échangés, et il vous faut la bonne convention pour faire partie de la discussion.

Le type bas niveau bytes est un outil qui sert donc à communiquer avec le monde extérieur, tandis que les types haut niveau (str, int, list, etc.) sont des outils qui font l’abstraction de ces conventions, pour vous permettre de manipuler confortablement un concept général (du texte, un nombre, une collection ordonnée) à l’interieur des murs de votre programme.

]]>
Ecouteurs bluetoothhttp://sametmax.com/?p=25112http://sebsauvage.net/streisand.me/sametmax/index.php?20190110_113117_Ecouteurs_bluetoothThu, 10 Jan 2019 10:31:17 +0000Je mets une fortune dans mes casques, que j’abime et perds en plus très souvent. Or, j’ai toujours eu une relation mitigée avec les écouteurs Bluetooth (et le BT en général d’ailleurs…), et je suis assez froissé par la tendance à supprimer les jacks.

Le fil d’un ami m’a fait pourtant tester les airpods, et j’ai été surpris par la qualité du son et la facilité d’usage. J’ai cherché un concurrent.

Après enquête, j’ai tenté les Jabra Elite 65T. Après des mois d’usage, voici ce que je peux en dire…

Les plus:

  • Le son est excellent, particulièrement pour la taille sur du sans-fil, y compris sur du
    classique, et les basses ne sont pas sur amplifiées comme c’est souvent le cas pour plaire à la masse;
  • C’est confortable. Je les porte des heures;
  • 5h d’autonomie + 5 de secours avec le boitier. Je suis arrivé au bout seulement 2 fois
    malgré des mois d’usage, donc pas un problème. Mais c’est vrai que les airpods font le double.
  • La synchro Bluetooth est parfaite avec portable récent (donc le messie bt5): rapide,
    sans galère. Quand on ressort les écouteurs du boitier, le pairing est automatique et transparent.
  • Le boitier de transport / chargeur / batterie de secours fonctionne à merveille.
  • L’attache dans l’oreille est excellente. On peut se faire secouer, courir, faire du
    yoga… Ça bouge pas.
  • On peut écouter avec une seule oreille, mais seulement la droite.
  • Les appels sont limpides, on a du mal à croire que ce petit micro marche si bien.
  • Après la perte inéluctable des deux écouteurs, j’ai fait une demande au SAV. 40 Euros,
    et reçu en 2 jours. Beau. Resyncro instantanée une fois placée dans le boitier.
  • De vrais boutons qui permettent de contrôler pleinement la lecture, et pas juste 3
    tapotements limités et difficiles en mouvement.
  • 3 tailles embout. Et choisir les bons a un gros impact sur le confort. Les
    intra-auriculaires à taille unique, ça m’a toujours laissé perplexe.
  • Bonne isolation du son extérieur.
  • Retirer un écouteur coupe la musique.
  • Zéro latence. J’ai eu des écouteurs BT moins cher, et regarder des films avec était un
    enfer. Là c’est fantastique, avec VLC ou Netflix dans le train, on se fait plaisir.

Les moins:

  • 180 euros à l’achat. Bam.
  • Le boitier est trop gros. Contrairement à celui des airpords, le mettre dans la poche n’est
    pas aussi discret qu’une boite d’allumettes.
  • Il y a un mode pass-through si vous êtes en vélo et que l’isolation sonore est dangereuse,
    mais il est pas ouf. Mieux vaut reste sur une écoute d’une oreille.
  • Certains comportements sont contre-intuitifs: retirer l’écouteur gauche coupe la musique,
    mais en fait on peut la relancer sur un seul écouteur en pressant le bouton principal. On peut aussi désactiver ce comportement via une app pour partager le son avec son voisin. Parfois l’écouteur gauche se met en veille quand il reste trop longtemps éloigné du droit, alors alors il faut une pression longue dessus pour le réveiller: le web est plein de gens qui croient que leur écouteur ne marche plus. Rien n’indique ces manipes sans un bon vieux RTFM.

Finalement, ces petits joujoux m’ont réconcilié avec le sans-fil, et je n’ai presque plus touché à mes écouteurs ou mes baffles Bose. Certes, je n’écoute pas du flac, donc même si la qualité est bonne pour du mp3, j’imagine qu’un audiophile confirmé y trouvera à redire.

Ok, ok. Dans ces conditions, virez le jack… quand l’USB-C sera supporté partout.

]]>
Le don du mois: Libre Officehttp://sametmax.com/?p=25104http://sebsauvage.net/streisand.me/sametmax/index.php?20190108_095456_Le_don_du_mois__Libre_OfficeTue, 08 Jan 2019 08:54:56 +0000Microsoft Office est un bon produit. Voilà, je l’ai dit. Je peux ne pas apprécier Microsoft en tant qu’entreprise, reprocher de nombreux défauts à ses bébés, mais être objectif sur certains points: Excel, malgré ses bugs, reste la meilleure expérience de tableur au monde, .Net est une technologie très propre, et VSCode est un superbe éditeur que j’ai par ailleurs adopté.

Seulement voilà, je n’ai nullement l’intention de soutenir des formats propriétaires, l’obsolescence programmée, et l’abus de position dominante. Au contraire, je préfère soutenir le logiciel libre, les standards ouverts et le partage.

Et c’est là que Libre Office entre en jeu.

Je l’utilise donc au quotidien, pour faire des rapports, des lettres, des calculs, etc. Bien que je sois très à l’aise avec ma machine, j’utilise des fonctions relativement peu avancées, et ce logiciel comble donc tous mes besoins.

Malheureusement, Libre Office souffre de gros problèmes d’ergonomie, et pire encore, de fiabilité. Sa stabilité est douteuse, et en plus de la frustration liée au plantage, il m’arrive de perdre du travail, chose qui me rend furieux.

Je comprendrais donc parfaitement que quelqu’un choisisse de ne PAS utiliser Libre Office, pour toutes ces raisons.

Personnellement, j’ai la politique inverse, et j’utilise Libre Office pour les soutenir, et je vais donc reporter les bugs et autres problèmes quand j’en ai le temps. J’ai peu de temps en ce moment, donc je choisis de contribuer par don, ce qui j’espère aidera les auteurs à dépasser ces hics. Un jour peut-être.

Un peu comme Firefox que j’ai gardé pendant des années alors qu’il était inférieur à Chrome, jusqu’à ce que, soudain, il redevienne non seulement aussi rapide, mais rajoute des fonctionalités inédites comme les tab containers que n’a pas la concurrence.

Et voici donc un don de 50 euros pour cet excellent projet, qui derrière ces soucis, permet quand même à peu de frais de faire des choses absolument incroyables, le tout dans le respect de la communauté humaine.

Bien entendu, je vous invite à faire de même.

]]>
Vive setup.cfg (et mort à pyproject.toml) !http://sametmax.com/?p=25060http://sebsauvage.net/streisand.me/sametmax/index.php?20181206_110748_Vive_setup.cfg__et_mort_a_pyproject.toml___Thu, 06 Dec 2018 10:07:48 +0000Après un long débat sur hackernews, qui n’est que le reflet de toutes les conversations que j’ai déjà eues à ce sujet sur twitter, github, et divers mailling lists, il est grand temps de faire un article. Urgent même.

Est-ce que vous savez quel chemin de croix on a vécu avec le packaging Python durant ces 15 dernières années ?

D’abord on a distutils, setuptools, distribute, and distribute2 qui ont tous été à un moment les “standards” recommandés pour packager une lib. Ensuite on a eu l’époque des eggs, exe, et autres trucs que easy_install allait chercher n’importe où dans la nature en suivant aveuglément des liens sur PyPi. Sans compter les machins qu’il fallait compiler à tout bout de champ. Et puis rien n’était chiffré au download, pip n’était pas packagé avec Python, il crevait sur des erreurs stupides type encodage mal géré…

À ça se rajoute que virtualenv était un truc à part, avec plein de concurrents, et linkait les packages système par défaut. Sans oublier qu’on avait pas Python -m.

Bref, le packaging Python, ça a été vraiment la merde. Avec en plus une doc de merde.

Aujourd’hui, le standard wheel a énormément amélioré la donne. On a des tutos corrects (ex: notre tuto sur comment créer son package avec setup.py). ensurepip fait qu’on a une version récente du truc presque partout.

En gros, notre situation est stable, saine. Améliorable de bien des façons, certes, mais un bon socle sur lequel s’appuyer.

Arrive setup.cfg

En 2016, l’équipe de setuptools, la lib utilisée par à peu près tout le monde pour créer des packages en Python aujourd’hui, a créé le format setup.cfg, un fichier INI dont le but est de remplacer setup.py.

Le problème de setup.py c’est que c’est du code Python exécutable, et en plus dépendant de la lib setuptools. Cela empêche non seulement l’interfaçage avec des outils externes, mais aussi freine l’émergence de nouveaux outils.

En effet, il y a un désir de continuer à améliorer la situation du packaging en Python, comme on peut le voir avec des projets comme pipenv ou poetry (je recommande d’ailleurs fortement ce dernier, et je vous invite à voter sur cette issue pour enfoncer le clou).

setup.cfg est la suite logique de tout ça, un format en texte brut, facile à manipuler pour le reste du monde.

Et ça a été bien fait:

  • setup.cfg marche out of the box. Il n’y a rien à faire de particulier : si vous aviez un setup.py, vous pouvez juste le convertir en setup.cfg. Si vous avez un nouveau projet, vous pouvez juste écrire le setup.cfg. Il n’y a pas de piège. Ça marche depuis… 2016. Ouais.
  • setup.cfg a une documentation décente. Si, si. C’est très améliorable, mais mieux que tout ce qu’on a jamais eu pour les premières années de setup.py
  • setup.cfg couvre la plupart des cas de figure que setup.py faisait et se permet de rajouter des goodies très cools. version = attr: src.__version__ inclue la version depuis __init__.py, "options.data_files" remplace le MANIFEST et "license = file: LICENCE.txt" injecte le corps de la licence depuis un fichier texte. Tous les hacks à la noix de setup.py ? Fini.
  • C’est simple à utiliser. Voici quelques projets pour démontrer le bouzin: exemple 1, exemple 2, exemple 3, exemple 4. Ça se comprend même sans lire la doc !
  • C’est compatible avec tous les outils legacy. En fait, il suffit de créer un fichier setup.py avec une seule ligne dedans (import setuptools; setuptools.setup()) et pouf, tout le worflow d’avant marche: python setup.py develop, python setup.py sdist upload, etc. Du coup, tout ce qui comprenanait setup.py (c’est à dire le putain de monde entier en Python) marche avec setup.cfg.

Donc setup.cfg, malgré des lacunes, c’est sympa.

Setup.cfg, ou es-tu ?

“Attend une minute, si c’est si bien que ça, pourquoi j’en ai jamais entendu parler ? Moi on m’a dit que setup.cfg il servait à rien…”

Je ne vous le fais pas dire !

Je n’ai aucune idée de la raison pour laquelle cette information ne circule pas plus. La seule raison pour laquelle je l’ai trouvée c’est parce que je passe des heures à faire de la veille informationnelle en Python, et que je suis tombé dessus au détour d’un carrefour, dans une ruelle sombre du Web. Et que j’ai pris le temps et le risque de le tester sur un de mes projets pour vérifier que oui, ça marche comme prévu.

Même la doc Python vous fait croire que setup.cfg c’est un artéfact vaguement utile pour une pauvre option monoligne.

Et merde, j’ai déjà écrit 900 articles sur ce blog, je ne peux pas mettre à ma charge d’avertir tout le monde pour chaque truc à savoir sur Python.

C’est comme pour le # -*- coding: utf-8 -*-. Un jour un mec utilisant Emacs a écrit un tuto avec ça, et tout le monde a copié-collé les hiéroglyphes alors qu’en fait # coding: utf8 est parfaitement valide. Ou comme nuikta, qui permet de compiler de Python de manière fiable, et que personne ne connait. Combien de temps doit-on gâcher avec des trucs comme ça ?

pyproject.toml vient foutre le bordel

Maintenant, figurez-vous que nous avons un groupe de personnes chargées de faire évoluer la situation du packaging, la Python Packaging Authority, ou PyPA.

Une très bonne initiative, vu que le free-for-all du passé ne nous avait pas trop réussi. Et un succès puisque la situation actuelle en packaging Python est maintenant beaucoup plus propre.

Et on en a besoin. En effet, setup.cfg doit être amélioré car il a certains défauts. Le format n’est pas parfaitement standardisé. Seule la doc fait figure de description, et pour l’instant setup.cfg, c’est whatever configparser comprends, sachant que configparser parse les trucs au motoculteur, et selon la version de Python. C’est pas gravissime, et ça n’a pas vraiment été un problème jusque là, mais pour la pérennité de la chose, une consolidation est nécessaire. On doit avoir une spec solide, un parseur robuste et stable, etc.

Sachant la purge qu’a été l’historique du packaging en Python, on s’attend donc a ce que la PyPA fasse le choix de standardiser setup.cfg, qui marche depuis 2 ans, fait le job, est compatible avec l’existant et résout déjà le problème de permettre au reste du monde de manipuler les données du package en texte brut. Puis, comme un bon groupe de décision sage, elle va proposer des solutions incrémentales aux défauts de setup.cfg et son écosystème.

Un exemple possible serait de s’allier avec l’équipe de setuptools pour figer le format setup.cfg, clarifier les edge cases de ce INI en particulier, et si besoin, créer une alternative a configparser (ou figer configparser) afin d’obtenir une implémentation de référence irréprochable pour parser le format. Puis désigner ce format comme le nouveau standard, en version 1 implicite, et le documenter puis en faire la promotion afin que tous les nouveaux outils puissent l’utiliser. Ensuite, ayant identifié des limitations, on crée le successeur de ce format, qui aura le même nom, mais un header de version qui lui sera explicite afin de permettre aux parseurs de s’adapter. Et on fait en sorte que cette nouvelle version soit plus propre, plus belle, super green. Et on l’introduit aussi progressivement et en douceur qu’un sex toy anal.

Bref, on s’attend à ce que la PyPA nous amène vers une totale liberté de pensée cosmique vers un nouvel âge réminiscence.

Sauf que non.

Ces ânes ont décidé… de créer un nouveau format et ignorer tout l’existant.

Fuck. That. Je hais que ce dessin de XKCD puisse être d’actualité encore et encore, chaque mois que l’humanité passe:
Le packaging en Python, c'est une forme de solidarité masochiste avec la communauté JS

Je ne comprends pas cette décision, et leurs justifications sont d’une grande faiblesse, pour ne pas dire insultante pour une communauté qui en a marre de payer le prix de l’égo des gens qui ont envie d’avoir leur nom sur la nouvelle barre de fer officielle.

C’est d’autant plus étrange que la PyPA n’est pas composée de cons. Non. On a Brett Cannon (core dev, qui fait un travail exceptionnel avec Python VSCode), Nathaniel Smith (qui nous a révolutionné l’async avec trio) et Kenneth Reitz (l’auteur de Python requests).

Comment ce pet de cerveau a-t-il pu émané de ces brillantes personnes, je ne le sais.

Mais je vous invite tous à non seulement utiliser setup.cfg en masse, mais aussi à activement contester cette décision sur tous les mediums à votre disposition.

Parce qu’évidemment je l’ai faits, et comme d’hab, ils font la sourde oreille. Et on va en payer le prix. Mais bon, depuis le temps, vous avez l’habitude. C’est pas comme si j’avais pas déjà annoncé que redux et dockers étaient overkill pour la plupart des projets, que le NoSQL allait avoir un retour de baton, que vue était génial, flask PAS pour les débutants, bitcoin intéressant, pipenv –three stupide, python parfait pour l’enseignement… des années avant. Pour les consultations de boule de cristal, c’est uniquement le mardi à 15h.

N’est-ce pas trop tard ?

Au contraire, c’est exactement le bon moment. Le format le plus utilisé actuellement n’est ni le setup.cfg, ni le pyproject.toml, mais toujours le bon vieux setup.py. En fait, n’en déplaise aux defenseurs de pyproject.toml qui veulent nous faire croire que le projet est bien plus populaire et avancé qu’il ne l’est vraiment, il vaut l’équivalent d’un draft de proposal en beta testing. Une simple recherche github retourne:

De toute façon la transition sera longue, et les outils commencent à peine à supporter le nouveau format. En fait, ils ne sont même pas d’accord sur comment l’utiliser. On n’a pas de standard pour le lock file (pipfile semble se dégager, mais n’est pas enterriné) et les outils utilisent pyproject.toml en créant une section custo dedans au lieu des champs standardisés (poetry), voire pas du tout comme pipenv. De plus, setup.cfg est déjà utilisé dans la nature (voir les exemples plus haut).

Par ailleurs, extraire les données de setup.cfg plutôt que de pyproject.toml n’est pas très compliqué, les outils de packaging n’ont qu’une toute petite partie de leur code dédié à la gestion du fichier, le reste c’est la logique de management des dépendances, le téléchargement, la command line, le virtualenv, etc. Ils peuvent par ailleurs tout à fait supporter les deux pendant la transition.

Vu que c’est nous qui allons nous coltiner les conséquences du choix pour les 10 prochaines années à venir, autant élever la voie. D’autant que, surprise, ça ne coûte quasiment rien à la majorité des projets de migrer ou commencer avec setup.cfg. Tout marche déjà, et on peut produire de jolies wheels. On ne peut pas dire autant de pyproject qui demande d’adopter des outils tout neufs et qui doivent encore faire leur preuve. Aussi, bonne chance pour faire marcher votre toolchain de CI avec, j’ai essayé, et croyez moi c’est relou.

Maintenant, j’aime que le packaging avance. J’aime même les nouveaux outils comme poetry. Mais la suite n’est pas inéluctable, et on peut concilier modernité avec sanité.

]]>
Programmation par contrat avec asserthttp://sametmax.com/?p=24956http://sebsauvage.net/streisand.me/sametmax/index.php?20180908_214011_Programmation_par_contrat_avec_assertSat, 08 Sep 2018 19:40:11 +0000Le mot clé assert est populaire en Python essentiellement grâce à la lib pytest, dont on vous a parlé dans le dossier sur les tests unitaires.

En dehors de ce cas d’usage, personne ne comprend bien son utilité.

Déjà, dans les tutoriaux, on vous signale de ne pas l’utiliser pour faire des vérifications importantes, à cause d’une particularité d’assert: il peut disparaitre à tout moment !

En effet, si vous lancez Python toutes voiles dehors avec l’option -o (pour “optimize”), les lignes contenant ce mot clé sont ignorées.

Alors, mille millions de mille sabords, pourquoi se faire chier à avoir ajouté ce truc ?

A quoi un machin qui peut disparaitre à tout instant peut-il bien servir ?

Well, it’s not a bug, it’s a feature, my dear.

Voyez-vous, on connait souvent le premier effet kisskool d’assert:

    assert condition

Et si la condition est fausse, on se tape une exception AssertionError.

En revanche, ce que les gens savent moins, c’est qu’il existe une seconde forme, beaucoup plus utile:

    assert condition, "Message en cas d'erreur"

Qui fait tout pareil, mais permet de donner un feedback a qui tombe sur l’erreur susnommée.

Et c’est là que c’est intéressant: parce que ça vous permet de mettre des vérifications complexes dans le code, qui vont permettre aux devs d’éviter les âneries. C’est ce qu’on appelle un contrat.

Imaginez une fonction qui prend en paramètre une valeur, qui est la clé d’un dictionnaire:

    ARTIBUSES = {
        'truc': 1,
        'bidule': 1,
        'machin': '2',
        'chose': '3',
        'chouette': '3',
        'foo': '4',
        # ...
    }
    
    def souquer_les_artibuses(artibuse):
    
        target = ARTIBUSES[artibuse]
        # un code de souquage professionnel s'ensuit

Si quelqu’un utilise votre code, et insère la mauvaise artibuse (le vil flibustier !), notre fonction va (s’)échouer sur une KeyError. Ceci va obliger le contrevenant (le perfide faquin !) à regarder dans le code source et comprendre le code pour trouver la source de son désarroi. Quelle perte de temps pour notre dev (le fils de pute !).

Une solution est alors de mettre:

    def souquer_les_artibuses(artibuse):
        if artibuse not in ARTIBUSES:
            raise ValueError(
                f"'{artibuse}'' n'est pas une artibuse valide. "
                f"Utilisez une valeur parmi: {', '.join(ARTIBUSES)}"
            )
        target = ARTIBUSES[artibuse]

Et c’est certes une bonne solution, claire et explicite.

Mais elle a un défaut majeur: à chaque appel, on rajoute le poids d’un test qui n’a aucun intérêt pour le fonctionnement normal du programme. En fait, la majorité des appels de cette fonction se feront avec les bonnes valeurs (logique sinon le code planterait), et donc notre test est un poids superflu.

Ce problème se cumule quand les tests deviennent plus nombreux, plus complexes, et plus lourds, tandis que la fonction est appelée de plus en plus de fois.

Comment concilier donc son besoin impérieux d’aider son prochain, qui est probablement soi-même un vendredi à 3h du mat après un push qu’on n’aurait pas du faire en fin de semaine, et éviter ce gâchis de ressource ?

Ventre-saint-gris de sa race ! Avec assert bien entendu !


    def souquer_les_artibuses(artibuse):

        assert artibuse in ARTIBUSES, (
            f"'{artibuse}'' n'est pas une artibuse valide. "
            f"Utilisez une valeur parmi: {', '.join(ARTIBUSES)}}"
        )

        target = ARTIBUSES[artibuse]

En dev, ou quand on debug en production, on obtient toutes les vérifications et infos nécessaires. Le contrat à remplir avec notre fonction est vérifié. On peut mettre autant de clauses à notre contrat qu’on le souhaite, aussi lourdes qu’on veut !

Quand on est prêt à relancer la prod en mode propre, on exécute tout avec -o

Les vérifications faites en amont d’une fonction sont ce qu’on appelle des pré-conditions dans le jargon de la programmation par contrat. Ce sont les plus faciles à comprendre et les plus courantes. On peut néanmoins faire également des vérifications à la fin de la fonction, qui permette de vérifier qu’on est bien dans un état cohérent à la sortie de celle-ci.

C’est ce qu’on appelle des post-conditions: c’est moins courant, et moins facile à écrire, mais très puissant car on se souci d’un état final (est-ce que mon résultat est > 3 ?), et non de comment on y arrive. Un moyen bien plus souple d’attraper des erreurs plutôt que de chercher toutes les combinaisons de ce qu’on peut mal faire.

Effets secondaires de -o

Le saviez-vous ? Python vient aussi avec une variable magique, __debug__, qui est à True par défaut. Utiliser -o met cette variable a False. Plus fort encore, toute condition sur __debug__ sera retirée du code !

if __debug__:
    un_dump_log_de_porc()

Pouf, avec -o, plus de dump.

Il existe même -oo pour retirer en plus les docstrings, et économiser un peu de mémoire.

Le problème avec assert

Le problème avec assert, c’est vous. Enfin je dis vous, le vous du passé, celui qui ne savait pas. En effet, plein de devs vont utiliser des assert dans leur code sans penser à mal. Et vous arrivez avec votre -o, et boom, le code est tout cassé. C’est bien con de ne pas pouvoir stripper ses assert à soi sous prétexte qu’une dépendance est codée par un connard Bachi-bouzouk.

Or assert est très souple, et permet de tester littéralement n’importe quoi. Du coup, cela demande un peu d’expérience pour savoir quand l’utiliser, et quand ne pas le faire.

Le concept général est: si votre erreur concerne la fonctionnalité fondamentale de votre fonction, levez toujours une exception. Si en revanche vous testez si les valeurs des paramètres correspondent à quelque chose de sain, et qu’une erreur n’aurait pas d’effet de bord, vous pouvez (ce n’est pas du tout obligatoire, une exception normale reste un usage correct) utiliser assert.

Donc, n’utilisez pas assert pour tester la logique de votre programme, ni pour protéger l’intégrité de vos données face à une erreur.

Une dernière chose: n’utilisez pas assert pour fournir un contrat basé sur les types (comme par exemple, appeler isinstance()), puisque mypy et les types hints le font déjà et qu’ils sont maintenant très agréables à utiliser.

]]>
Sam ne répondra plushttp://sametmax.com/?p=24942http://sebsauvage.net/streisand.me/sametmax/index.php?20180904_031835_Sam_ne_repondra_plusTue, 04 Sep 2018 01:18:35 +0000Si vous nous avez écrit un email, vous savez qu’on a tendance a être lents pour répondre. En fait, parfois plus d’un an :)

Mais que ce soit sur twitter, reddit, indexerror, mastodon, les commentaires du blog ou par email, on finit par répondre à tout le monde. Les ratés existent, mais ils sont rares. La seule catastrophe étant notre bug tracker, parce que j’en fais suffisamment au boulot pour ne pas avoir le courage de le faire sur mon temps libre.

Gérer toute cette communauté, ça a un coût. J’y ai joyeusement participé pendant toutes ces années, parce que j’aime profondément aider les gens.

Notez que je ne me prends pas pour mère Thérésa, à moins qu’elle ai déjà fait du SM et vendu du viagra illégalement. Mais donner un coup de main a toujours été quelque chose d’important pour moi.

C’est la raison pour laquelle j’aime donner des formations. Parfois gratuitement. Parfois dans le cadre associatif.

C’est la raison pour laquelle je me déplace à des confs bien loin pour donner des talks même si personne ne sait que c’est moi. Parfois je discute avec un groupe de gens enthousiastes de ce super site NSFW. C’est vrai qu’il est bien. Vous l’avez connu comment ?

C’est la raison de la qualité des articles du blog également. Je passe un temps déraisonnable à me demander comment je vais pouvoir aider au mieux le lecteur avec une explication. Il m’est arrivé plusieurs fois de passer une journée entière sur un seul article compliqué, aux dépens d’un client que j’aurais pu facturer. Si on devait chiffrer le coût de ce site, je pense que ça me paierait un joli tour du monde.

Alors oui, ça a un prix, et je l’ai payé avec plaisir. Mes amis, qui m’ont entendu cracher sur les réseaux sociaux, ont même été étonnés de voir mon investissement sur Hacker news ou Twitter, au fil des années.

En cette fin 2018, je vais changer mon implication. J’ai envie de récupérer du temps libre, diminuer la tentation des interruptions et renforcer ma capacité d’attention, ce qui veut dire trancher dans le gras des distractions. Moins de surf sans but, moins de streaming, et moins de présence en ligne.

J’ai pensé à arrêter complètement le blog, mais soyons honnête, je n’écris plus au dixième du rythme de ses débuts, donc ça ne me prend pas si longtemps. Et un article de temps en temps, c’est thérapeutique. Je pense que j’ai besoin de mon troll JavaScript annuel pour des raisons de santé.

Ce qui me prend du temps par contre, c’est tout ce qui est autour des articles.

Donc, à partir de cette semaine, je vais arrêter de répondre sur Twitter, le subreddit (qui n’a de toute façon jamais pris) et indexerror. Twitter en particulier sera donc de nouveau en sens unique, comme à nos touts débuts: je poste, et je ne réponds pas.

Pour les commentaires du blog, j’ai fermé la création de compte, et j’ai autorisé les commentaires uniquement à ceux qui avaient déjà un compte. Je ne répondrai pas pour autant, et je sais que la communauté existante ne foutra pas le bordel, tout en leur permettant de glisser les corrections des mes coquilles débiles.

Pour mastodon, je vais fermer le compte complètement. Enfin le passer en privé et l’oublier car framapiaf ne permet pas la supression. L’expérience est réussie, je pense que c’est une bonne plateforme, mais le ratio taff/retour est trop bas pour mes nouveaux objectifs.

Quant aux mails, pour le moment je garde le canal ouvert. Ce qui devrait me permettre du coup de répondre beaucoup, beaucoup plus rapidement.

Je vous aime quand même, hein.

]]>
La débâcle de async en 3.7http://sametmax.com/?p=24891http://sebsauvage.net/streisand.me/sametmax/index.php?20180807_151440_La_debacle_de_async_en_3.7Tue, 07 Aug 2018 13:14:40 +0000async et await ont été introduits en Python 3.5, tout le monde a trouvé l'idée formidable. D'ailleurs, ça a été intégré à JavaScript. Malheureusement, introduire des mots clés dans un langage est une opération très délicate.]]>Quand les nouveaux mots clés async et await ont été introduits en Python 3.5, tout le monde a trouvé l’idée formidable. D’ailleurs, ça a été intégré à JavaScript.

Malheureusement, introduire des mots clés dans un langage est une opération très délicate.

Limites et contournements des mots clés

En Python les mots clés ont une caractéristique importante : on ne peut pas les utiliser pour quoi que ce soit d’autre.

Par exemple, class est un mot clé, donc je ne peux pas créer une variable, un attribut, ou une fonction appelé class. Ceci lève une erreur:

>>> class = 1
  File "", line 1
    class = 1
          ^
SyntaxError: invalid syntax
>>> class Foo: pass
... 
>>> Foo.class = 1
  File "", line 1
    Foo.class = 1
            ^
SyntaxError: invalid syntax
>>> 

Pour cette raison, quand on veut qu’une variable contienne une classe en Python, on la nomme cls:

>>> class Bar:
...     @classmethod
...     def wololo(cls):
...         print(cls, 'wololo')
... 
>>> 
>>> Bar.wololo()
 wololo
>>> 

C’est aussi pour cela que vous voyez parfois des variables nommées truc_. Souvent from_ par exemple, parce que from est un mot clé.

(pro tip: plutôt que from et to, utilisez src et dest)

Quand en Python 2 on a introduit True et False, un gros problème s’ensuivit: soit on en faisait des mots clés, et on pétait tout le code précédent qui utilisait ces mots, soit on en faisait des variables globales.

Le choix a été de garder la stabilité jusqu’à la prochaine version majeure, et c’est pour cela que:

  • On peut faire True = False en Python 2. Ouch.
  • Python 3 casse ce comportement, et donc ça fait une chose de plus à laquelle il faut penser quand on migre.

Pour la 3.5, on avait donc ce même problème, avec une cerise sur le gâteau: la lib standard utilisait elle-même la fonction asyncio.async.

Le choix a donc de faire de async / await des variables globales, et de les transformer en mot clé en 3.7.

En 3.6, un warning a été ajouté pour rappeler aux gens de migrer leur code.

C’est un sacré taf, et ça comporte des risques comme nous allons le voir plus loin. C’est pour cette raison que l’ajout d’un mot clé dans Python est une des choses les plus difficiles à faire passer sur la mailling list python-idea.

Arrive la 3.7

La 3.7 est sortie avec tout un tas de goodies. Youpi. Mais aussi avec le passage de async/await de variables globales à mots clés, cassant la compatibilité ascendante. Quelque chose de rare en Python, et que personnellement j’aurais réservé pour Python 4, ne serait-ce que pour respecter semver.

Le résultat, tout un tas de systèmes ont pété: des linux en rolling release, des gens qui ont fait l’update de Python à la main, des gens qui maintiennent des libs compatibles 3.5 a 3.7…

D’autant que la 3.5 a asyncio.async, mais 3.7 considère ça une erreur.

Petit exemple avec l’impact sur debian.

Comment on aurait pu éviter ce merdier ?

D’abord, il aurait fallu ne pas introduire asyncio à l’arrache. Dans mon “au revoir” à Guido, je disais que je trouvais que les dernières fonctionnalités majeures de Python avaient été mises en oeuvre de manière précipitée.

Cela se vérifie encore et encore avec asyncio, dont il faudra que je fasse un article pour dire tout ce qui a mal tourné.

Casser la compatibilité ascendante dans une version mineure n’est pas acceptable, même si les dégâts sont limités et qu’on y survivra très bien.

Le fait qu’asyncio soit une API marquée comme “provisional” n’a jamais empêché quelqu’un d’appeler ses variables async. Après tout on utilise les threads depuis bien longtemps.

L’autre problème vient de l’amateurisme qui se glisse de plus en plus dans le dev.

C’est une bonne chose, parce que ça veut dire que la programmation est de plus en plus accessible et accueille de plus en plus de monde.

Mais cela veut dire aussi qu’une grosse part la population de programmeurs est aujourd’hui constituée de personnes qui n’ont ni les connaissances, compétences ou ressources pour faire les choses correctement.

On le voit particulièrement dans le monde JavaScript, ou c’est l’explosion (là encore, ça mérite un nouvel article). Mais l’exemple de la 3.7 nous montre que la communauté Python n’est pas immunisée, et je pense que le problème va s’amplifier.

Que veux-je dire par là ?

Et bien il y a 30 ans, cela ne serait pas venu à l’esprit de la plupart des devs de compiler quelques choses sans mettre les flags en mode parano pour voir ce qui allait péter. Après tout, quand on code en C, on sait que tout peut imploser à tout moment, alors la prudence est une question de culture.

Aujourd’hui par contre, la majorité des devs des langages haut niveau écrivent du code, font quelques tests à la main, et publient ça. D’autres les utilisent. Font des mises à jour en masse. Aucun ne prennent le temps ne serait-ce que d’activer les warnings les plus basiques.

Comme tout est facile à première vue, et c’est quelque chose dont on fait la promotion pédagogiquement parlant, car ça incite les gens à se lancer, on oublie la complexité inhérente à la programmation.

Mais il y a une différence colossale entre avoir un code qui marche une fois sur sa machine, et un code prêt pour la production.

Par exemple en Python, vous pouvez demander l’activation des warning pour chaque appel avec:

python -Wd

En 3.6, ça implique ceci:

>>> def async():
...     pass
... 
:1: DeprecationWarning: 'async' and 'await' will become reserved keywords in Python 3.7

L’info a toujours été là. Prête à être utilisée.

Mais alors pourquoi ne pas afficher tous les warnings, tout le temps ?

Et bien si je le fais:

python -Wa

Voilà ce que ça donne quand je lance juste le shell de python 3.6:

Voir le code sur 0bin.

Vous comprenez donc bien que ce n’est PAS activé par défaut. En fait, originalement le message était dans le corps de l’article, mais j’ai du le mettre sur 0bin parce que ça faisait planter WordPress. Si.

A chaque upgrade, il est important de vérifier les warnings pour préparer ses migrations futures.

Oui, c’est du boulot.

En fait…

La programmation, c’est BEAUCOUP de boulot

Même si on arrive maintenant à extraire une frame vidéo en gif en une ligne de commande.

Surtout maintenant qu’on y arrive en fait, car on multiplie les agencements hétérogènes de boites noires pour créer nos merveilleux programmes qui font le café.

Alors on prend des raccourcis.

Et puis aussi, parce qu’on ne sait pas. Qui parmi les lecteurs du blog, pourtant du coup appartenant à la toute petite bulle des gens très intéressés par la technique, connaissaient le rôle des warnings et comment les activer ?

Mais ce n’est pas le seul problème. Il y a clairement une question d’attentes et de moyen.

L’utilisateur (ou le client) final veut toujours plus, pour moins cher, et plus vite !

Et le programmeur veut se faire chier le moins possible.

Comme la complexité des empilements d’abstractions augmente, cela conduit à ignorer ce sur quoi on se base pour créer ce qui doit combler notre satisfaction immédiate.

J’ai parlé d’amateurs plus haut.

Mais je ne parle pas simplement de mes élèves. De mes lecteurs.

Je parle aussi de moi.

Prenez 0bin par exemple.

Il n’est plus à jour. Il n’a pas de tests unitaires. Il a des bugs ouverts depuis des années.

Ce n’est pas pro du tout.

Sauf que je ne suis pas payé pour m’en occuper, et c’est bien une partie du problème: nous sommes de nombreux bénévoles à faire tourner la machine a produire du logiciel aujourd’hui. Donc si je n’ai pas envie, fuck it !

Vous imaginez si l’industrie du bâtiment ou celle de l’automobile tournaient sur les mêmes principes ?

La moitié des dessins industriels faits par des bloggers, des étudiants, des retraités, des profs de lycées, des géographes, de biologistes et des postes administratifs ?

Des immeubles et des voitures dont des pièces sont fabriquées par des potes qui chattent sur IRC et s’en occupent quand ils ont le temps ? Gratuitement. Y compris le service après-vente.

Alors que les usagers veulent toujours plus: des normes sismiques et de la conduite autonome. Tout le monde le fait, alors la maison de campagne et la fiat punto, c’est mort, personne ne l’utilisera.

Difficile de maintenir la qualité à cette échelle.

Il y a tellement de demandes de dev, jamais assez d’offres, de ressources toujours limitées.

Et ça grossit. Ça grossit !

Aides techniques

Ceci dit, à l’échelle de la PSF, ça aurait dû être évité.

Avant d’aborder les aides techniques, il serait bon d’arrêter les conneries. Je me répète, mais c’était une vaste dauberie de faire passer async/await en mot clé avant Python 4.

J’ai parfaitement conscience du besoin de faire progresser un langage pour ne pas rester coincé dans le passé. Je suis pour async/await, très bonne idée, superbe ajout. Mettre un warning ? Parfait ! Mais on respecte semver s’il vous plait. Si vous avez envie de faciliter la transition, mettre un import __future__, et inciter les linters à faire leur taff.

En attendant, pour la suite, Python va faciliter le debuggage.

Par exemple, depuis la 3.7, les DeprecationWarning sont activés par défaut au moins dans le module __main__. Donc un développeur verra ses conneries bien plus rapidement.

E.G:

Imp est déprécié en 3.6, mais sans -Wd, on ne le voit pas:

$ python3.6
Python 3.6.5 (default, May  3 2018, 10:08:28) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import imp

En 3.7, plein de modules importent imp, mais les DeprecationWarning ne sont pas montrés, car ça arrive dans des codes importés. En revanche, si dans le module principal, vous importez imp:

$ python3.7 
Python 3.7.0+ (default, Jun 28 2018, 14:08:14) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import imp
__main__:1: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses

Ça donne une info importante, sans foutre un mur de warnings à chaque lancement.

Une autre aide est l’apparition, toujours en 3.7, du mode développement de Python avec -X dev qui active tout un tas de comportements aidant au développement:

  • active -Wd
  • appelle PyMem_SetupDebugHooks
  • active faulthandler
  • active le mode debug de asyncio
  • met sys.flags.dev_mode sur True

Évidemment, tout ça ne sert pas à grand-chose si on ne sait pas ce qu’il faut en faire. Et ça demande du temps et du travail, ce que l’amateurisme ne permet pas forcément.

Enfin je dis ça. La plupart des employeurs s’attendent à tout, tout de suite également. Donc au final, n’est-ce pas la culture générale de notre industrie qui est en train de virer dangereusement vers le vite fait mal fait ?

Même si il y a clairement une question de compétence (un prof de maths est généralement compétent en maths, alors que j’attends toujours de rencontrer un prof d’info qui est capable de mettre quelque chose en prod), la pression du marché a créé des attentes impossibles…

L’informatique n’existe comme secteur économique que depuis quelques décennies, contre des siècles pour la plupart des autres disciplines scientifiques. Pourtant on exige d’elle le même niveau de productivité. Il a bien fallut rogner quelque part, et c’est la fiabilité qu’on a choisit.

Quand il y 20 ans, on rigolait en comparant le debuggage de Windows a la réparation d’une voiture, et la punchline sur le redémarrage, ce n’était pas grave: un peu de virtuel dans un monde plein d’encyclopédies papier, de cabines ou bottins téléphoniques et autres cartes routières.

Aujourd’hui que notre monde entier dépend du fonctionnement de nos conneries codées à l’arrache, c’est plus emmerdant. Et ça explique aussi pourquoi le téléphone de ma grand mère fonctionne toujours mieux pour faire des appels que mon putain de smartphone a 600 euros. Mais je peux draguer une meuf par texto en faisant caca à l’aéroport. Tout a un prix.

]]>
Guido van Rossum s’offre “des vacances permanentes” 19http://sametmax.com/?p=24844http://sebsauvage.net/streisand.me/sametmax/index.php?20180712_225603_Guido_van_Rossum_s___offre____des_vacances_permanentes____19Thu, 12 Jul 2018 20:56:03 +0000BDFL (Dictateur Bénévole À Vie) et créateur du langage Python vient d'annoncer qu'il laissait son bébé à la communauté.]]>Le BDFL (Dictateur Bénévole Bienveillant À Vie) et créateur du langage Python vient d’annoncer qu’il laissait son bébé à la communauté.

Sans quitter son rôle de core dev, et en suggérant qu’il passe plus de temps en tant que mentor de ses collègues sur le projet, il abandonne néanmoins son pouvoir de décision absolu sur le langage et son rôle de validateur ultime de chaque introduction de nouvelles fonctionnalités.

Dans son email, il ne passe pas le pouvoir à qui que ce soit ni n’invite à un mode de direction particulier. Il suggère que l’équipe actuelle des core devs, les développeurs ayant les droits de commit sur le repository du langage, choisisse le format qui leur convienne le mieux pour diriger à présent le projet.

Un moment important dans la vie de Python, mais aussi un événement qui demande beaucoup de remise en contexte.

Python-idea, Python-dev et les PEP

Durant les dernières années, les décisions de modification du langage passaient généralement par plusieurs phases.

D’abord, la proposition faite sur la mailing list python-idea. Cette liste est publique. Tout le monde peut y participer et y donner son avis.

Après débat, si le climat n’est pas hostile (ce qui est une notion TRES subjective), un des core devs suggère généralement à l’auteur de l’idée d’écrire un PEP.

Le PEP (Proposition d’Amélioration de Python) est l’équivalent d’une RFC pour Python. C’est un document formalisant une proposition d’amélioration du langage et de son écosystème. Le plus connu est bien entendu le PEP 8.

S’ensuit encore plus de débats, et des modifications itératives du PEP, jusqu’à, soit l’abandon du projet par l’auteur, soit l’oubli, soit le verdict de Guido.

Ce dernier est définitif: le PEP est approuvé ou rejeté. Dans le premier cas, il sera appliqué. Dans le second, il part à la poubelle.

Quelque part à la fin de ce processus, les implémenteurs du PEP discutent en plus petit comité, sur la liste python-dev, de la réalisation.

Guido a toujours, jusqu’ici, été donc la dernière étape de filtre de cet enchaînement. A la foi gardien de sa philosophie du langage, et goulot d’étranglement.

Il y a eu quelques améliorations, comme la nomination ponctuelle de BDFL délégués pour certains sujets, mais le format reste quand même globalement le même.

Pride and prejudice

Ce système a l’avantage d’être très ouvert. Tout le monde peut participer. Peu de personnes le font pourtant, par rapport à la masse d’utilisateurs de Python, mais c’est déjà beaucoup si on considère l’inertie que ça implique.

Le mail est un format très accessible, décentralisé, ouvert et standard. Son austérité évite l’effet réseau social qu’on voit trop souvent sur les outils plus modernes.

En contrepartie, le processus est très flou. Il n’y a pas de vote a proprement parler. Les threads s’enchaînent un peu n’importe comment. Les nouveaux venus ne sachant pas comment utiliser l’outil le font imparfaitement. Et le media ne permet pas facilement de suivre la continuité à court terme et à long terme de grand-chose, ni en termes de flux, ni en termes de référence, ni en termes de recherche.

Mais c’est aussi l’aspect social qui est problématique. Il n’y a aucune organisation claire dans la liste, et tout le monde semble “au même niveau”. Or ce n’est pas absolument pas le cas. La réputation et les participations passées, ainsi que les caractères des participants et leurs relations jouent énormément sur le processus. Le timing également.

Ça parait équitable sur le papier, mais c’est une illusion, et en prime cela implique des frictions qui pourraient être évitées. Par exemple quand un étudiant demande à Larry Hastings de l’aider à faire ses devoirs ou qu’un auteur de PEP cite le Zen of Python à Tim Peters. Inversement, quand vous proposez une idée, et que tout le monde vous envoie péter, mais que 6 mois plus tard, Brett Cannon dit que c’est intéressant et que tout le monde crie au génie, ça fout les boules.

Ajouté à cela, la qualité du débat qui peut varier du tout au tout : du caprice à la revue technique, en passant par le mail à côté de la plaque, la crise d’égo, l’appel au calme, le récap qui aide tout le monde, les idées brillantes, les suggestions étonnantes, les redites, et le spam.

Et évidement, la réponse par défaut est toujours non.

Se faire entendre là dedans est très difficile. Garder son calme l’est souvent aussi. Mais surtout, persévérer à travers le processus durant le temps nécessaire pour l’aboutissement de celui-ci est une épreuve épuisante, irritante, et ingrate. Surtout quand 9 fois sur 10, elle se finit par un rejet.

Un rejet cependant, n’est pas la mise à mort d’une idée. L’année suivante on peut relancer le débat, et ainsi de suite, comme un politicien à l’assemblée qui veut faire passer son projet de loi. Et comme au Parlement, la même idée présentée par une nouvelle personne, ou avec un autre timing peut avoir un résultat radicalement différent.

Un anus pour les rassembler tôt

GvR, bien qu’au sommet de cette pyramide, n’est pas isolé de tout cela, bien au contraire. Il est une des rares personnes qui doit trancher sur presque tout, et donc se coltiner une bonne partie des débats. Et des réactions quand il rejette l’idée d’autrui.

À ceci se rajoute sa présence sur les bugs trackers, et bien entendu son activité de développeur.

Un rôle difficile, fatigant, et un vrai sacerdoce pour quelqu’un qui pourrait dire “allez tous vous faire foutre, j’ai pondu ce langage utilisé par des millions de personnes tout seul, je sais mieux que vous” au lieu de prendre en considération l’avis du public.

Un rôle, je vous le rappelle, qu’il tient depuis plus de 20 ans.

Depuis la 3.4, on sent le poids commencer à peser sur ses épaules. A 62 ans, et toujours avec un travail à plein temps chez Dropbox (qui heureusement lui laisse le loisir de travailler sur Python), on peut imaginer l’énergie nécessaire pour s’impliquer encore autant.

Cela se ressent particulièrement dans ses mails et ses tickets. Une sorte de lassitude. Et une retenue qu’on devine de plus en plus difficile.

Honnêtement, je ne sais pas comment il a fait pour ne pas exploser sur quelqu’un. Dans certains échanges que j’ai eus avec lui sur la liste ou sur github, si nos rôles avaient été inversés, j’aurais sans aucun doute été bien moins diplomate.

sys.exit() maintenant, avant que la charge ne devienne trop pesante, est à mon sens un acte de grande classe.

Comme un comédien, un musicien, un metteur en scène ou un écrivain qui fait ses adieux au sommet de son art. J’aurais aimé que Lucas, Spielberg et Besson aient su en faire autant.

Mais pour bien comprendre à quel point cette décision de laisser sa place demande du courage, il faut réaliser une chose: il laisse son enfant dans les mains des autres. L’œuvre de sa vie. Une réalisation colossale qui plus est, qui a généré des centaines de milliers d’emplois, fait tourner des milliers de projets.

Moi, j’ai du mal à m’imaginer arrêter d’écrire ce misérable petit blog. Et pourtant j’y ai pensé souvent.

L’étincelle qui a fait déborder la moutarde, c’est bien entendu le débat sans fin sur l’expression d’assignation, et la critique vigoureuse de son acceptation. (C’est vrai que c’était chaud)

Guido en a eu ras le cul, quoi.

So what now ?

Personnellement, j’accueille la nouvelle avec un mélange d’espoir et de mélancolie.

Python n’aurait jamais été ce qu’il est aujourd’hui sans la constante vigilance de son BDFL.

Dire “non” est la partie la plus importante pour sculpter une expérience. C’est ce qui fait la différence entre Gates et Jobs, Van dam et Lee, Hitler et… heu… non.

C’est ce qui fait qu’on n’a des lambda bridées et pas d’opérateur pour ajouter un élément dans une liste. Qu’on le veuille ou pas.

Et c’est ce qui fait qu’un langage né en fucking 1985 (avant Java !) tient toujours la route aujourd’hui. A gardé sa lisibilité. Sa facilité de prise en main. Et continue d’être utile.

C’est un travail de titan !

Néanmoins je ne peux m’empêcher de noter que les dernières fonctionnalités majeures de Python ont été introduites de manière brouillonne. Je pense notamment au type hints et à asyncio, que Guido a bdfl -f sans donner le temps de mûrir leur design. Elles ont mis plusieurs versions à ne serait-ce qu’être utilisables, et méritent encore du travail.

Je pense aussi que Python est prêt pour des ajustements, et espère que passer le flambeau à l’équipe de core dev va apporter du renouveau au langage.

En effet, il est peu probable qu’un nouveau BDFL s’installe, et bien qu’il soit trop tôt pour faire une prédiction, la mise en place d’un quorum semble plus probable. Dans ce cas, il faudra sans doute un vecteur de vote. Et de là, qui sait, naîtra peut-être un complément ou replacement à python-idea.

Je l’espère en tout cas.

Sortir de l’usage de la mailing list pour un outil plus encadré, mettant les propositions en avant, avec un système de sondage, des procédures plus claires, des références plus faciles au passé, et une distinction explicite du statut des personnes qui s’expriment.

Bref, faciliter l’accès au processus, tout en permettant une gestion plus saine. On ne voudrait pas que Victor ou Yuri nous posent leur dem dans les 6 mois pour cause de pétage-de-cablite aigue.

Également, qui sait, peut-être reviendra-t-on – pour le meilleur ou pour le pire ? – sur des BanDFL tel que:

  • le pattern matching
  • les exceptions sous forme d’expression
  • pathlib.Path dans les builtins
  • le mot clé lazy
  • et bien d’autres

Difficile de croire que le débat ne sera pas relancé maintenant que Cerbère ne garde plus les Champs Élysées.

Évidemment, il est logique qu’il y ait un temps de flottement. D’abord par respect pour le père de Python. Ça ferait un peu GoT d’enchaîner quand même. Ensuite parce qu’il va falloir qu’un nouveau mode de fonctionnement émerge, et prouve son efficacité.

Quoi qu’il arrive

Merci à Guido Van Rossum pour ce cadeau immense.

On va essayer de ne pas trop l’abîmer.

]]>
L’expression d’assignation vient d’être acceptée 20http://sametmax.com/?p=24766http://sebsauvage.net/streisand.me/sametmax/index.php?20180703_111547_L___expression_d___assignation_vient_d___etre_acceptee_20Tue, 03 Jul 2018 09:15:47 +0000python-idea (mailing list sur laquelle, je vous le rappelle, tout le monde a le droit de participer), Guido a validé la PEP 572. (foo := bar) sera donc un code valide en Python 3.8.]]>Après des mois de débats sur python-idea (mailing list sur laquelle, je vous le rappelle, tout le monde a le droit de participer), Guido a validé la PEP 572. (foo := bar) sera donc un code valide en Python 3.8.

Je n’avais pas vu de feature plus controversée depuis les f-strings. Et je gage que, comme les f-strings, après un temps d’adaptation, la communauté va se demander comment on a vécu sans auparavant.

Un peu d’histoire

Il existe deux grandes catégories d’instructions dans les langages de programmation. Les déclarations et les expressions.

La déclaration, en anglais “statement”, est une action indépendante formulée sur une ligne. C’est une unité syntaxique, et une déclaration ne peut être contenue dans une autre déclaration sur la même ligne.

Ex:

import os

est une déclaration. Un import est tout seul sur sa ligne et ne se combine pas avec d’autres instructions.

L’expression, elle, est une combinaison de littéraux, variables, d’opérateurs et d’appels de fonctions qui retournent un résultat. Les expressions peuvent contenir d’autres expressions, et elles peuvent être contenues dans une déclaration.

Ex:

1 + 1 

est une expression. On peut, en effet, assigner le résultat de ce code à une variable, le passer à une fonction en paramètre ou le tester dans une condition.

Les langages, comme le COBOL, qui privilégient le style impératif utilisent majoritairement des déclarations. Les langages, comme LISP, qui privilégient le style fonctionnel, utilisent majoritairement des expressions.

Très souvent néanmoins, les langages populaires font largement usage des deux. L’expression est plus flexible et plus puissante. La déclaration force une opinion sur la structure du programme et évite les divergences de style. Selon la philosophie que l’on souhaite donner à son bébé, un créateur de langage va donc s’orienter plus vers l’une ou l’autre.

Python est multiparadigme et soutient le style impératif, fonctionnel et orienté objet. Il possède donc non seulement des expressions et des déclarations, mais également souvent les deux versions pour une même instruction.

Ex, les déclarations:

squares = []
for x in numbers:
    squares.append(x * x)

def mean(x):
    return x * x / 2

if is_ok:
    print(welcome)
else:
    print(error)

ont des expressions équivalentes:


squares = [x * x for x in number]

mean = lambda x: x * x / 2

print(welcome if is_ok else error)

Parfois Python choisit d’orienter le style du programmeur, non pas évitant de fournir des expressions, mais par le biais de la grammaire imposée. Ainsi il oblige à indenter, et n’autorise pas les lambdas à contenir de déclaration. C’est une autre stratégie pour imposer une philosophie au langage. Pour Python, la philosophie est que la capacité à s’exprimer doit rester riche, mais pas au détriment de la capacité à comprendre le code.

Une particularité de Python, c’est que l’assignation, c’est-à-dire le fait d’associer une valeur à une variable, est une déclaration. Ex:

a = 1

Comme les déclarations ne peuvent contenir d’autres déclarations, cette syntaxe interdit:

if a = 1:  

Ce n’est pas le cas dans de nombreux langages populaires, comme le C, PHP, le JS… Exemple en Ruby:

if (value = Settings.get('test_setting'))
  perform_action(value)
end

Ici, non seulement on assigne le résultat du get() à la variable value, mais en plus, on teste le résultat du get() avec le if.

Actuellement ceci est impossible en Python, et le même code serait:

value = Settings.get('test_setting')
if value:
  perform_action(value)

Ce n’est pas une erreur, c’est un choix de design. En effet une source de bug très courante en programmation est de vouloir faire une comparaison, mais de taper une assignation.

Ainsi, quelqu’un voudrait faire:

while reponse == "oui":
    ...
    reponse = input('Voulez-vous continuer ?')

Mais ferait:

while reponse = "oui": # erreur subtile et difficile à voir
    ...
    reponse = input('Voulez-vous continuer ?')

Ce qui ne compare pas DU TOUT la variable. Et en plus change son contenu. Dans ce cas précis, le résultat est une boucle infinie, mais parfaitement valide et qui ne provoquera pas d’erreur.

Pour éviter ce genre de bug que même les programmeurs aguerris font un jour de fatigue, la syntaxe a tout simplement été interdite en stipulant que l’assignation était toujours une déclaration.

La PEP 572

L’absence de cette fonctionnalité a eu d’excellents bénéfices. Je le vois régulièrement dans mes salles de classe, ce bug. La SyntaxError qui résulte de cette faute en Python permet de l’attraper avant qu’il ne fasse le moindre dégât.

Car c’est tout le problème de cette erreur: si la syntaxe est valide, le bug est silencieux, le code tourne, il ne fait juste pas du tout ce qu’on lui demande. C’est la plus pernicieuse des situations, avec des conséquences qui peuvent ne se déclarer que bien plus loin dans le code et une séance de débuggage des plus irritantes.

A mon sens, c’était une excellente décision de design.

Pourtant la PEP 572 revient dessus, en proposant, comme pour lambda, la boucle for ou la condition, un équivalent sous forme d’expression.

Pourquoi ?

Et bien Python doit aussi satisfaire les programmeurs chevronnés, qui en ont marre de se retrouver avec des situations comme :

match1 = pattern1.match(data)
if match1:
    print(match1.group(1))
else:
    match2 = pattern2.match(data)
    if match2:
        print(match2.group(2))

Certes, ce code est clair et facile à comprendre, mais il est très verbeux. On doit faire avec une indentation artificiellement induite par la limite de la syntaxe, et non par la logique du raisonnement qui est ici parfaitement linéaire.

Comment donc réconcilier le désir d’éviter le fameux bug tout en satisfaisant les besoins d’expressivité, légitimes une fois qu’on quitte le nid des débutants ?

La solution proposée est triple :

  • Ajouter un nouvel opérateur dédié, permettant l’assignation sous forme d’expression.
  • Forcer l’usage des parenthèses pour encadrer cette expression.
  • Rendre les deux opérateurs d’assignation mutuellement exclusifs.

Le nouvel opérateur choisi est := et il ne peut exister qu’entre parenthèses. Il peut être utilisé là où un simple = ne serait pas autorisé. Mais, il ne peut PAS être utilisé là où on peut utiliser =. Le but est de ne jamais mettre ces deux opérateurs en concurrence: une situation permet l’un ou l’autre, jamais les deux.

= ne change pas. La seule différence, c’est qu’à partir de Python 3.8, vous aurez le droit de faire:

if (match1 := pattern1.match(data)):
    print(match1.group(1))
elif (match2 := pattern2.match(data)):
    print(match2.group(2))

L’opérateur := permet donc bien, dans des situations très précises, d’obtenir un code plus cours et élégant, sans introduire pourtant d’ambiguïté et donc de bug potentiel. Il autorise une nouvelle forme d’expressivité, mais sa syntaxe est très marquée: impossible de le confondre avec son frère, et les parenthèses l’isolent du reste du code.

On ne se pose pas non plus la question de quand choisir = et := puisque:

a = 1

est valide, mais pas:

a := 1

Bien que:

(a := 1)

soit valide, personne n’aura envie d’utiliser vainement cette forme plus lourde.

L’usage de := est donc marginal, et cantonné à des cas particuliers.

Une opinion, c’est comme un trou du cul…

Personnellement j’étais mitigé sur l’idée. De plus, j’aurais préféré l’usage du mot clé as, puisqu’on l’utilisait déjà dans les imports, les context managers et la gestion des exceptions.

Chaque ajout d’expression rajoute également la possibilité d’abus. Si vous avez déjà vu ces horreurs à base de lambdas imbriquées ou d’intensions sans fin, vous savez de quoi je parle.

Avec :=, on peut vraiment se lancer dans du grand n’importe quoi:

Pour reprendre l’exemple de la PEP:

while True:
    old = total
    total += term
    if old == total:
        return total
    term *= mx2 / (i*(i+1))
    i += 2

est très clair.

En revanche:

while total != (total := total + term):
    term *= mx2 / (i*(i+1))
    i += 2
return total

Est une abomination qu’il faut purger par le feu.

Mais par expérience, j’ai rarement vu en 15 ans de Python beaucoup d’abus de ses fonctionnalités avancées. Les bénéfices ont toujours dépassé le coût d’une large marge. Pourtant entre les décorateurs, les dunder methods et les meta classes, il y a matière à messe noire.

Par ailleurs j’avoue que je suis ravi de pouvoir enfin faire:

while (data := io.get(x)):

Et:

[bar(x) for z in stuff if (x := foo(z))]

La PEP mentionne aussi un exemple que je n’avais pas prévu, et qui souffle le chaud et le froid:

diff = x - x_base
if diff:
    g = gcd(diff, n)
    if g > 1:
        return g

Peut devenir:

if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
    return g

Comme l’auteur, j’approuve le fait que la première version est inutilement verbeuse, mais contrairement à lui, je trouve que la seconde est bien trop complexe pour être scannée d’un coup d’œil.

En revanche:

diff = x - x_base
if diff and (g := gcd(diff, n)) > 1:
    return g

est tout à fait à mon goût.

Ceci démontre bien qu’il va falloir un temps d’adaptation avant que la communauté trouve l’équilibre entre Perl et BASIC. Quoi qu’il en soit, on n’aura pas à s’en soucier avant l’année prochaine, et même d’ici là, peu de code pourra en faire usage avant que la 3.8 soit largement installée.

De mon côté je m’attends à ce qu’on ignore majoritairement cette fonctionnalité, jusqu’au moment où elle apparaîtra dans un coin de l’esprit le temps d’un besoin ponctuel et local, pour être oubliée à nouveau jusqu’à l’occasion suivante. Comme Dieu Guido l’aura voulu. D’ailleurs, côté enseignement, je ne compte pas introduire l’opérateur dans mes cours, ou alors dans une section bonus, à moins qu’un participant ne pose la question.

Aller, vous pouvez râler en commentaire maintenant :)

]]>
Le don du mois: mobx 7http://sametmax.com/?p=24750http://sebsauvage.net/streisand.me/sametmax/index.php?20180702_124128_Le_don_du_mois__mobx_7Mon, 02 Jul 2018 10:41:28 +0000Mobx, c'est que le projet déchire. Et il déchire malgré le fait qu'il soit codé en JS.]]>Si vous avez suivi un peu les différents dons du mois au fur et à mesure de la vie du blog, vous avez du vous rendre compte de 2 choses:

  • Le don du mois n’est pas mensuel. Il est juste limité à un par mois. Ça m’évite la pression d’être un bon samaritain. Sauf que du coup, j’oublie parfois pendant trèèèèèèès longtemps :)
  • Il n’y a pas beaucoup de projets JS dans le lot. Ahem.

En fait le seul et unique projet JS supporté a été VueJS. C’est dire que la barre est haute, étant donné la qualité exceptionnelle de ce projet.

Donc quand je vous dis que j’ai donné 50 balles à Mobx, c’est que le projet déchire. Et il déchire malgré le fait qu’il soit codé en JS.

Mobx permet, en gros, de surveiller les modifications à une structure de données. Vous posez un marqueur sur la structure, et un sur les fonctions utilisant la structure, et c’est tout:

class TodoList {
    @observable todos = []; // dire à mobx de surveiller
}

...

@observer // dire à mobx de tenir à jour
class TodoListView extends Component {
    render() {
        return 
    {this.props.todoList.todos.map(todo =>)}
}

C’est là la brillance du système: malgré sa simplicité, mobx va récursivement réagir à toute modifications, même sur des données complexes imbriquées; Et calculer toutes les dépendances de chaque fonction pour ne les appeler qu’au meilleur moment.

C’est facile à utiliser, et étonnamment rapide à exécuter.

Le résultat ? Quand un client me force à utiliser ReactJS, je saute redux, et je met Mobx à la place. Ca donne presque l’impression d’utiliser Vue: le code de manipulation d’état est simple à comprendre, gentil sur le CPU et les mutations d’état restent courtes et élégantes. Le reste est toujours moche, mais ça on y peut rien.

Bref, mobx est ce qui rend react acceptable. Et tout ce qui peut apaiser la douleur du dev en front-end n’a pas de prix.

J’ai regardé le code source, et la popote interne est bien complexe. Mais à chaque fois que je veux l’utiliser je me dis que ça ne pourra pas être si simple… et si.

La page de don, c’est par là.

]]>
Python 3.7 sort de sa coquille 20http://sametmax.com/?p=24711http://sebsauvage.net/streisand.me/sametmax/index.php?20180628_185441_Python_3.7_sort_de_sa_coquille_20Thu, 28 Jun 2018 16:54:41 +0000La 3.4 était la première version 3 à valoir le coup, et a donc été le déclencheur de la migration 2->3 qui trainait depuis si longtemps.

La 3.5(.3) a rendu asyncio utilisable, incluant async / await et corrigeant le bug abusé de get_event_loop().

La 3.6 est mon chouchou. Sa meilleure intégration de Pathlib et les f-strings en font un plaisir total à utiliser. En plus black ne tourne que dessus. Je suis autant que possible en 3.6, je l’ai même installée sur une vieille centos 7 chez un client.

Alors que vaut cette 3.7, et est-ce qu’il faut migrer ?

Et bien avec des améliorations de perfs partout et une syntaxe simplifiée pour les classes, c’est une belle release. La 3.6 va être bien plus facile à avoir sous linux pendant un bon bout de temps et suffit amplement, donc je ne vais pas forcer le pas. Mais bon je l’ai quand même compilée par acquis de conscience.

Regardons ce qu’il y a au menu.

Les data classes

Clairement la feature phare de la release, les data classes sont une manière plus concise d’écrire des classes, s’inspirant de la bibliothèque attrs dont elles n’implémentent qu’un sous-ensemble.

Une très bonne nouvelle, car je n’installais jamais attrs: dépendre d’une lib juste pour ça, m’embêtait et pour la sérialisation/validation j’utilise marshmallow.

Par exemple:

from dataclasses import dataclass

@dataclass
class Achat:
    produit: str
    prix: float
    quantite: int = 0

Ce qui va générer une classe toute ce qui a de plus normale, mais dont le __init__, __repr__ et __eq__ sont automatiquement créés. Vous pouvez bien entendu ajouter les méthodes que vous voulez, comme d’habitude.

Il ne reste plus qu’à faire:

>>> print(Achat("foo", 2))
Achat(produit='foo', prix=2, quantite=0)

Toute la magie est sélectivement désactivable, et une méthode __post_init__ est ajoutée à la classe qui fait exactement ce que vous pensez que ça fait.

En prime, on a aussi dataclasses.field qui permet de fournir une factory pour un paramètre (typiquement list, tuple, dict…).

Puis, comme un bonheur ne vient jamais seul:

>>> from dataclasses import asdict, astuple
>>> print(asdict(Achat("foo", 2)))
{'produit': 'foo', 'prix': 2, 'quantite': 0}
>>> print(astuple(Achat("foo", 2)))
('foo', 2, 0)

C’est récursif sur les dicts, lists, tuples et dataclasses \o/

Enfin, pour finir:

>>> from dataclasses import replace
>>> a = Achat("foo", 2)
>>> b = replace(a, quantite=3, prix=1)
>>> print(a, id(a))
Achat(produit='foo', prix=2, quantite=0) 140275795603296
>>> print(b, id(b))
Achat(produit='foo', prix=1, quantite=3) 140275775561456

Ouai ça déchire.

P.S: y un backport pour la 3.6

asyncio++

Much love to asyncio dans cette version.

Déjà, un truc qui aurait dû être là dès le début, la nouvelle fonction asyncio.run(), qui masque le setup de l’event loop pour vous.

On passe de :

loop = asyncio.get_event_loop() 
loop.run_until_complete(coro)

à:

asyncio.run(coro)

Juste ça, ça fait vachement moins peur aux gens. Et en prime ça évite qu’ils commencent à chercher la merde avec un setup custom de loop.

asyncio.current_task() retourne la tâche dans laquelle on est. D’ailleurs, un détail, mais on a maintenant l’équivalent de thread local, mais pour la coroutine en cours.

asyncio.get_running_loop() retourne la boucle courante, mais seulement si elle existe. Elle lève une exception plutôt que de créer une loop comme get_event_loop() si aucune loop n’est présente.

StreamWriter.wait_closed() permet d’attendre qu’un stream se ferme. Les gars de aiohttp doivent être contents.

Task.get_loop() retourne la boucle de la tâche. Pour le multi-threading avec plusieurs loops, c’est cool.

loop.create_server() a maintenant un argument start_serving qui contrôle si on veut le lancer immédiatement. J’ai toujours du mal à croire que des dev qui sont capables de participer à la stdlib ont pu commiter un code qui instancie et enchaine sur un effet de bord. Heureusement c’est corrigé.

Les handlers retournés par loop.call_later() retournent leur ETA avec .when() et ont une méthode .cancelled().

Les intensions acceptent maintenant async/await.

Et enfin, les exceptions des tâches annulées ne sont plus loggées. Parce que forcément quand on crashait tout, le log devenait un peu chargé…

Bon, asyncio était déjà très utilisable en 3.6, n’exagérons pas. L’important étant d’utiliser le mode debug, gather() et run_until_complete(), ce qui devrait être écrit en gros, en rouge dans la doc.

Mais toutes ces modifications sont bienvenues.

Ah, oui, les perfs ont été aussi améliorées… Mais c’est le cas partout.

Des perfs

Le focus sur les perfs de Python augmente doucement. La 3.6 avait amorcé la tendance, et ça se confirme. J’attends d’avoir des retours sur des mises en prod un peu serieuses pour savoir si ça a payé.

Le temps de démarrage de Python est d’ailleurs pas mal pointé du doigt. Certes, on est pas au niveau de loutre sclérosée que constitue nodejs au réveil, mais c’est pas une référence. Donc, des choses sont mises en place. Notamment python -X importtime qui va afficher le temps que prend chaque import.

Des aménagements ont aussi été faits pour accélérer le module typing, maintenant que l’usage des type hints pour les annotations est entériné. Un side effect sympa est que les classes que vous allez écrire seront plus rapides à instancier, et les méthodes plus rapides à résoudre.

D’ailleurs, les type hints sont maintenant résolus paresseusement, à la fois pour améliorer la vitesse de chargement et pour faciliter l’auto-référencement.

breakpoint()

breakpoint() est techniquement un alias configurable à import pdb; pdb.set_trace(). Ça a l’air de rien, mais c’est super:

  • C’est dans les builtins, donc plus facile à découvrir. Les débutants utilisent très peu pdb alors que c’est un outil formidable.
  • Plein de gens oublient cette incantation mystique ou font des fautes de frappe.
  • C’est facile à spotter dans le code, on peut l’highlither différement.
  • C’est uniforme. Si on veut utiliser un autre débuggeur, on le plug. Mais on utilise toujours la même fonction. On peut même désactiver cette fonction pour éviter de balancer un break point en prod.
  • C’est clair. Les débutants n’ont aucun mal avec debugger en JS parce que c’est simple de comprendre ce que ça fait au premier coup d’oeil.

Ça vient, bien entendu avec une variable d’environnement et d’un hook dans sys pour custo le comportement.

Quelques détails

Dicts ordonnés

La spec garantit que les clés vont garder leur ordre d’insertion. C’était déjà le cas en 3.6, la 3.7 rend juste la mesure officielle.

Ne jetez pas OrderedDict à la poubelle pour autant, car il préserve l’ordre des clés après suppression également.

async/await sont des mots clés

Et ne peuvent donc plus être écrasés par erreur. C’est juste l’application de l’annonce faite à l’introduction de ces mots clés.

Des sœurs pour __getitem__ et __getattr__

On va pouvoir définir un __getattr__ sur les modules (surtout utile pour le lazy loading) et un __class_getitem__ pour pouvoir faire MaClass[] sans utiliser de metaclass.

Traduction de la doc

Le processus pour avoir des docs dans d’autres langues est maintenant officiel. Pour l’instant le jap, le koréen et le kokorico

DeprecationWarning plus visibles

La connerie de les cacher a été corrigée. Qui a pensé que c’était une bonne idée ? Mais seulement pour le script principal, ce qui va permettre aux dev des libs de les voir sans faire chier les utilisateurs.

Debug mode

python -X dev va devenir votre nouvel ami, activant tout un tas de fonctions de debug coûteuses en production. Notamment plus de warning, asyncio debug mode, le faulthandler qui dump la stacktrace en cas de catastrophe, etc.

Des pyc reproductibles

Un même fichier donnera maintenant toujours un même .pyc. C’est pour les packagers et les amateurs de sécu.

Meilleur ImportError

L’exception va maintenant afficher le nom du module et son __file__ path si from ... import broute. Ça va rendre les imports circulaires, la plaie des gros projets Python, plus faciles à debugger.

packaging

Introduction de importlib.resources, un remplacement pour le détestable pkg_resource qui va rendre sans regret mon article obsolète.

Autre ajout notable: README.rst est maintenant reconnu et ajouté automatiquement quand on fait son paquet cadeau. Puisque maintenant pypi accepte le markdown, ça aurait été cool de le faire avec les .md également.

time est plus précis

Sensible à la nanoseconde. Perso je m’en bats les steaks mais je me suis dit que je ferai passer l’info.

unittest -k

Copieurs.

namedtuple supporte les valeurs par defaut

Rien à ajouter, si ce n’est qu’entre SimpleNamespace et les dataclasses, je crois qu’on a de quoi voir venir. Même si j’aimerais avoir un literal pour les namedtuples sous la forme de (foo=1, bar=2) mais ça a été refusé.

Ajouts à Contexlib

Quelques outils en plus, dont un context manager qui ne fait rien (rigolez pas, c’est super utile !), et des contexts managers async.

lifting pour subprocess

Ok, plutôt bottox. C’est cosmétique, mais c’est bienvenu: des aménagements pour rendre les appels un poil plus courts, notamment dans le cas de la capture des stdx.



Et encore plein d’autres mini trucs.

C’est dispo en DL pour windows et mac. Pour linux, comme d’hab, soit on attend la mise à jour des depôts/ppa/etc, soit on compile à la main (étonnamment facile, si on se rappelle de faire make altinstall et pas make install), soit on utilise l’excellent pyenv et pyenv install 3.7.

]]>
Super article invité sur Trio que l’auteur a oublié de titrer 11http://sametmax.com/?p=24605http://sebsauvage.net/streisand.me/sametmax/index.php?20180614_093952_Super_article_invite_sur_Trio_que_l___auteur_a_oublie_de_titrer_11Thu, 14 Jun 2018 07:39:52 +0000Ceci est un post invité de touilleMan posté sous licence creative common 3.0 unported.

C’est bon vous avez cédé à la hype ?

Après un n-ème talk sur asyncio vous avez été convaincu que tout vos sites webs doivent être recodé dans cette techno ? Oui, surtout celui de la mairie de Gaudriole-sur-Gironde avec ses 50 visiteurs/jour, Django ça scalera pas et vous aurez sûrement besoin de websockets à l’avenir.

Et puis là pan ! En commençant à utiliser asyncio on se rend compte que ça va pas être aussi marrant que ce que vous a vendu l’enfoiré de hipster dans son talk avec son exemple de crawler web en 20 lignes :

  • la doc de asyncio fait 50 putain de pages, même les plus grands déclarent ne rien y comprendre
  • pdb est aux fraises, un step-over sur un await vous envoi à perpet’ dans l’event loop
  • il faut passer l’event loop en tant qu’argument à chaque fonction, évidemment vous n’allez pas le faire et utiliser get_event_loop() à la place. Et ça va merder sévère à un moment (typiquement quand vous ajouterez des tests non triviaux), et vous allez devoir corriger tout votre code.
  • régulièrement une stacktrace d’une coroutine ayant crashé dégueule de stdout sans que le programme ne bronche, autant de je m’en foutisme on se croirait revenu en PHP !
  • parlons-en de la stacktrace ! Impossible de savoir d’où vient la coroutine, encore une fois on nous renvoi dans les méandres de l’event loop.
  • Et pour initialiser/finaliser proprement votre système alors là c’est la fête totale

Je ne parle même pas des soucis ceinture-noir-2ème-dan du genre high-water mark qui vous tomberons dessus une fois l’appli en prod.

Lourd est le parpaing de la réalité sur la tartelette aux fraises de nos illusions…

1 – Pourquoi c’est (de) la merde ?

Pour faire simple asyncio a été pensé à la base comme une tentative de standardisation de l’écosystème asynchrone Python où chaque framework (Twisted et Tornado principalement) était incompatible avec les autres et devait re-créer son écosystème de zéro.

C’était la bonne chose à faire à l’époque, ça a eu beaucoup de succès (Twisted et Tornado sont maintenant compatible asyncio), ça a donné une killer-feature pour faire taire les rageux au sujet de Python 3 et ça a créé une émulsion formidable concernant la programmation asynchrone en Python.
Mais dans le même temps ça a obligé cette nouvelle lib à hériter des choix historiques des anciennes libs : les callbacks.

Pour faire simple un framework asynchrone c’est deux choses :

  • une grosse boucle infinie (la fameuse « event loop ») qui a configuré les appels d’IO au kernel en mode non-bloquant et qui poll ceux-ci en continu
  • un mécanisme pour garder trace de quel bout de code exécuter quand une IO donnée aura été terminée

Concernant le 2ème point, cela veut dire que si on a une fonction synchrone comme ceci :

def listen_and_answer(sock):
    print('start')
    data = sock.read()
    print('working with %s' % data)
    sock.write('ok')
    print('done')

Il faut trouver un moyen pour la découper en une série de morceaux de codes et d’IO.

Il y la façon « javascript », où on découpe à la main comme un compilo déroulerai une boucle :

def listen_and_answer(sock):
    print('start')

    def on_listen(data):
        print('working with %s' % data)

        def on_write(ret):
            print('done')

        sock.write('ok', on_write)

    sock.read(on_listen)

Et là j’ai fait la version simple sans chercher à gérer les exceptions et autres joyeusetés. Autant dire que quand un vieux dev Twisted vous dit le regard vide et la voix chevrotante qu’il a connu l’enfer, ne prenez pas ses déclarations à la légère.

Sinon la façon async/await si chère à asyncio :

async def listen_and_answer(sock):
    print('start')
    data = await sock.read()
    print('working with %s' % data)
    await sock.write('ok')
    print('done')

C’est clair, c’est propre, la gestion des exceptions est totalement naturelle, bref c’est du Python dans toute sa splendeur.
Sauf que non, tout ça n’est qu’un putain d’écran de fumée : pour être compatible avec Twisted&co sous le capot asyncio fonctionne avec des callbacks.

Vous vous souvenez de cette sensation de détresse mêlée d’hilarité devant une stacktrace d’un projet Javascript lambda d’où vous ne reconnaissez que la première ligne ? C’est ça les callbacks, et c’est ça que vous avez dans asyncio.

Concrètement le soucis vient du fait qu’une callback n’est rien d’autre qu’une fonction passée telle qu’elle sans aucune information quant à d’où elle vient. De fait impossible pour l’event loop asynchrone de reconstruire une callstack complète à partir de cela.
Heureusement async/await permettent à python de conserver ces informations de fonction appelante ce qui limite un peu le problème avec asyncio.
Toutefois en remontant suffisamment haut on finira toujours avec une callback quelque part. Et vous savez qui a l’habitude de remonter aussi haut que nécessaire ? Les exceptions.

import asyncio
import random

async def succeed(client_writer):
    print('Lucky guy...')
    # Googlez "ayncio high water mark" pour comprender pourquoi c'est
    # une idée à la con de ne pas avoir cette methode asynchrone
    client_writer.write(b'Lucky guy...')

async def fail(client_writer):
    raise RuntimeError('Tough shit...')

async def handle_request_russian_roulette_style(client_reader, client_writer):
    handlers = (
        succeed,
        succeed,
        succeed,
        fail,
    )
    await handlers[random.randint(0, 3)](client_writer)
    client_writer.close()

async def start_server():
    server = await asyncio.start_server(
        handle_request_russian_roulette_style,
        host='localhost', port=8080)
    await server.wait_closed()

asyncio.get_event_loop().run_until_complete(start_server())

Maintenant si on lance tout ça et qu’on envoie des curl localhost:8080 on va finir avec:

$ python3 russian_roulette_server.py
Lucky guy...
Lucky guy...
Task exception was never retrieved
future:  exception=RuntimeError('Tough shit...',)>
Traceback (most recent call last):
  File "ex.py", line 18, in handle_request_russian_roulette_style
    await handlers[random.randint(0, 3)](client_writer)
  File "ex.py", line 9, in fail
    raise RuntimeError('Tough shit...')
RuntimeError: Tough shit...
Lucky guy...
Task exception was never retrieved
future:  exception=RuntimeError('Tough shit...',)>
Traceback (most recent call last):
  File "ex.py", line 18, in handle_request_russian_roulette_style
    await handlers[random.randint(0, 3)](client_writer)
  File "ex.py", line 9, in fail
    raise RuntimeError('Tough shit...')
RuntimeError: Tough shit...

Le problème saute aux yeux: asyncio.start_server gère sa tambouille avec des callbacks et se retrouve bien embêté quand notre code remonte une exception. Du coup il fait au mieux en affichant la stacktrace et en faisant comme si de rien n’était. C’est peut-être le comportement qu’on attend d’un serveur web (encore que… si aviez configuré logging pour envoyer dans un fichier vous êtes bien baïzay) mais il existe des tonnes de usecases pour lesquels ça pose problème (et de toute façon on n’a vu que la partie émergée de l’iceberg d’emmerdes qu’est la programmation asynchrone).

Bref, si vous voulez en savoir plus, allez lire ce post, d’ailleurs allez lire tous les posts du blog, ce mec est un génie.

2 – Trio, une façon de faire de l’asynchrone

Ce mec en question, c’est Nathaniel J. Smith et il a eu la très cool idée de créer sa propre lib asynchrone pour Python: Trio

L’objectif est simple: rendre la programmation asynchrone (presque) aussi simple que celle synchrone en s’appuyant sur les nouvelles fonctionnalités offertes par les dernières versions de Python ainsi qu’un paradigme de concurrence innovant. Cette phrase est digne d’un marketeux, vous avez le droit de me cracher à la gueule.

Concrètement ce que ça donne:

# pip install trio asks beautifulsoup4
import trio
import asks
import bs4
import re


# Asks est un grosso modo requests en asynchrone, vu qu'il supporte trio et curio
# (une autre lib asynchrone dans le même style), il faut donc lui dire lequel utiliser
asks.init('trio')


async def recursive_find(url, on_found, depth=0):
    # On fait notre requête HTTP en asynchrone
    rep = await asks.get(url)
    print(f'depth {depth}, try {url}...')

    # On retrouve le corps de l'article grace à beautiful soup
    soup = bs4.BeautifulSoup(rep.text, 'html.parser')
    body = soup.find('div', attrs={"id": 'mw-content-text'})

    # On cherche notre point Godwin
    if re.search(r'(?i)hitler|nazi|adolf', body.text):
        on_found(url, depth)

    else:
        async with trio.open_nursery() as nursery:
            # On retrouve tous les liens de l'article et relance le recherche
            # de manière récursive
            for tag in body.find_all('a'):
                if tag.has_attr('href') and tag.attrs['href'].startswith('/wiki/'):
                    child_link = 'https://en.wikipedia.org' + tag.attrs['href']
                    # On créé une nouvelle coroutine par lien à crawler
                    nursery.start_soon(recursive_find, child_link, on_found, depth+1)


async def godwin_find(url):
    results = []

    with trio.move_on_after(10) as cancel_scope:
        def on_found(found_url, depth):
            results.append((found_url, depth))
            cancel_scope.cancel()

        await recursive_find(url, on_found)

    if results:
        found_url, depth = results[0]
        print(f'Found Godwin point in {found_url} (depth: {depth})')
    else:
        print('No point for this article')


trio.run(godwin_find, 'https://en.wikipedia.org/wiki/My_Little_Pony')

L’idée de ce code est, partant d’un article wikipedia, de crawler ses liens récursivement jusqu’à ce qu’on trouve un article contenant des mots clés.

Au niveau des trucs intéressants:

async with trio.open_nursery() as nursery:
    for tag in body.find_all('a'):
        if tag.has_attr('href') and tag.attrs['href'].startswith('/wiki/'):
            child_link = 'https://en.wikipedia.org' + tag.attrs['href']
            nursery.start_soon(recursive_find, child_link, on_found, depth+1)

En trio, une coroutine doit forcément être connectée à une nurserie. Cela permet deux choses:

  • Rattacher la coroutine à sa coroutine parente, de cette façon (et vu que trio est implémenté intégralement en utilisant async/await au lieu de callbacks), on a donc une stacktrace claire et une exception sera toujours propagée jusqu’à la racine du programme si il le faut.
  • Borner la durée de vie de la coroutine. La nurserie est un context manager asynchrone, une fois qu’on arrive à la fin du async with, la nursery bloque tant que toutes les coroutines qu’elle gère n’ont pas terminé. Si une coroutine raise une exception, la nursery va pouvoir cancel les autres coroutines avant de re-raise l’exception en question (cf. le point précédent)

Quel intérêt à borner la durée de vie des coroutines ? Si on avait voulu écrire un truc équivalent en asyncio on aurait sans doute utilisé asyncio.gather:

coroutines = [recursive_find(link) for link in links]
await asyncio.gather(coroutines)

Maintenant on fait tourner ce code avec une connection internet un peu faiblarde (au hasard sur la box Orange de Sam ces temps ci…) les ennuis auraient commencé dès qu’une requête http aurait timeout.
L’exception de timeout aurait été récupérée par asyncio.gather qui l’aurait relancé sans pour autant fermer les autres coroutines qui auraient continué à crawler wikipedia en créant des centaines de coroutines (oui recursive_find est un peu bourrin).
De fait si on se place dans le cas d’un code tournant longtemps (typiquement on a un serveur web qui a lancé notre code dans le cadre du traitement d’une requête entrante) on va avoir bien du mal à retrouver l’état ayant mené à ce bordel.

Du coup en trio la seule solution pour avoir une coroutine qui survit à son parent c’est de lui passer une nursery en paramètre:

async def work(sleep_time, nursery):
    await trio.sleep(sleep_time)
    print('work done !')
    # Je vous ai dit qu'une nurserie contient automatiquement un cancel scope ?
    nursery.cancel_scope.cancel()

async def work_generator(nursery):
    print('bootstrapping...')
    await trio.sleep(1)
    for sleep_time in range(10):
        nursery.start_soon(work, sleep_time, nursery)

async def stop_a_first_work_done():
    async with trio.open_nursery() as nursery:
        await work_generator(nursery)
        print('Waiting for a work to finish...')

Un autre truc cool:

with trio.move_on_after(10) as cancel_scope:
    def on_found(found_url, depth):
        results.append((found_url, depth))
        cancel_scope.cancel()

    await recursive_find(url, on_found)

Vu qu’en trio on se retrouve avec un arbre de coroutines, il est très facile d’appliquer des conditions sur un sous-ensemble de l’arbre. C’est le rôle des cancel scope.
Comme pour les nursery, les cancel scope sont des contexts managers (mais synchrone ceux-ci). On peut les configurer avec un timeout, une deadline, ou bien tout simplement les annuler manuellement via cancel_scope.cancel().

Dans notre exemple, on définit un scope dont on sortira obligatoirement au bout de 10s. Pour éviter d’attendre pour rien, on annule le scope explicitement dans la closure appelée quand un résultat est trouvé.
Vu que les nurseries définies à chaque appel de recursive_find se trouvent englobées par notre cancel scope, elles seront automatiquement détruites (et toutes les coroutines qu’elles gèrent avec).

Pour faire la même chose avec asyncio bonne chance:

  • soit on passe un argument de timeout à notre appel pour récupérer la requête HTTP, mais dans ce cas pour peu que chaque requête soit individuellement plus courte que le timeout on ne s’arrêtera jamais
  • soit on gère à la mano le temps à coup de time.monotonic() en passant le temps restant autorisé aux coroutines filles. Bonjour la gueule du code.

En plus comme en parlait un mec (décidemment !), la gestion du timeout dans une socket tcp est foireuse, il suffit de recevoir un paquet (et une requête entière peut contenir beaucoup de paquets !) pour que le timeout soit remis à zéro. Donc encore une fois pas de garanties fortes quant à quand le code s’arrêtera.

3 – Eeeeet c’est tout !

Au final la doc de l’api de trio pourrait tenir sur l’étiquette de mon slip: pas de promise, de futurs, de tasks, de pattern Protocol/Transport legacy. On se retrouve juste avec la sainte trinité (j’imagine que c’est de là que vient le nom) async/await, nursery, cancel scope.

Et évidemment maintenant, l’enfoiré de hipster qui vous vend une techno à coup de whao effect avec un crawler asynchrone de 20 lignes c’est moi…

Remarquez si vous préférez la version longue je vous conseil cet excellent article de Nathaniel (je vous ai dit que ce mec était un génie ?).

4 – L’écosystème

C’est là où on se rend compte que asyncio est malgré ses lacunes une super idée: il a suffit d’écrire une implémentation de l’event loop asyncio en trio pour pouvoir utiliser tout l’écosystème asyncio (ce qui inclus donc Twisted et Tornado, snif c’est beau !).

Allez pour le plasir un exemple d’utilisation de asyncpg depuis trio:

import trio_asyncio
import asyncpg


class TrioConnProxy:
    # Le décorateur permet de marquer la frontière entre trio et asyncio
    @trio_asyncio.trio2aio
    async def init(self, url):
        # Ici on est donc dans asyncio
        self.conn = await asyncpg.connect(url)

    @trio_asyncio.trio2aio
    async def execute(self, *args):
        return await self.conn.execute(*args)

    @trio_asyncio.trio2aio
    async def fetch(self, *args):
        return await self.conn.fetch(*args)


async def main():
    # Ici on est dans trio, c'est la fête

    conn = TrioConnProxy()
    await conn.init('postgresql:///')

    await conn.execute('CREATE TABLE IF NOT EXISTS users(name text primary key)')

    for name in ('Riri', 'Fifi', 'Loulou'):
        await conn.execute('INSERT INTO users(name) VALUES ($1)', name)

    users = await conn.fetch('SELECT * FROM users')
    print('users:', [user[0] for user in users])


# trio_asyncio s'occupe de configurer l'event loop par défaut de asyncio
# puis lance le trio.run classique trio_asyncio.run(main)

En plus de ça trio vient avec son module pytest (avec gestion des fixtures asynchrones s’il vous plait) et Keneith Reitz a promis que la prochain version de requests supporterait async/await et trio nativement, elle est pas belle la vie !

]]>
Go to (in asyncio) considered harmful 26http://sametmax.com/?p=24534http://sebsauvage.net/streisand.me/sametmax/index.php?20180607_093129_Go_to__in_asyncio__considered_harmful_26Thu, 07 Jun 2018 07:31:29 +0000Trio, une stack toute neuve concurrente d'asyncio, lui a fait écho 50 ans plus tard, ça a beaucoup discuté sur les mailing lists et les bugs trackers.]]>Dijkstra était un intellectuel pédant, mais quand il a écrit cette lettre célèbre, il a comme souvent mis le doigt sur un truc fondamental. Et quand l’auteur de Trio, une stack toute neuve concurrente d’asyncio, lui a fait écho 50 ans plus tard, ça a beaucoup discuté sur les mailing lists et les bugs trackers.

Nathaniel J. Smith, le dev susnommé, en a profité pour introduire une nouvelle primitive, actuellement surnommée la nursery, pour répondre au problème. Une idée visiblement tellement bonne que notre Yury préféré a décidé de la porter à asyncio. La boucle d’événements est bouclée, si je puis dire.

Mais une autre chose intéressante en découle : on a mis en lumière la présence d’un goto dans asyncio, et qu’il y a de bonnes pratiques, validées par Guido himself, pour coder avec cette lib pour éviter les douleurs.

What the fuck are you talking about ?

Le problème du goto, c’est que l’instruction permet d’aller de n’importe où à n’importe où. Cela rend le flux du programme très dur à suivre. Pour éviter cela, on a catégorisé les usages clean du goto: répéter une action, changer de comportement en fonction d’un test, sortir d’un algo en cas de problème, etc. Et on en a fait des primitives : les if, les while, les exceptions… Dans les langages les plus modernes, on a carrément viré le goto pour éviter les abus et erreurs. Joie.

Dans asyncio, le “goto” en question se trouve quand on veut lancer des tâches en arrière plan, comme ceci :

import asyncio as aio
loop = aio.get_event_loop()
aio.ensure_future(foo())  # GOTO !
aio.ensure_future(bar())  # GOTO !
loop.run_forever()

Le problème d’ensure_future() est multiple:

  • Comme son nom l’indique, cette fonction retourne un objet… Task. Ca n’a rien à voir, mais je tenais à dire à quel point c’était con de l’avoir nommé ainsi (même si techniquement, Task hérite de Future).
  • Cette ligne ne garantit en aucun cas que foo() ou bar() seront terminées à une zone précise du code. Tout au plus que tuer la boucle tue les taches. Leur flux d’exécution est complètement freestyle et décorrélé de tout le reste du programme, ainsi que de l’une de l’autres. Si ces coroutines font des await, on peut basculer de n’importe où du programme vers elles et inversement à tout moment. goto
  • Cette ligne schedule le démarrage de foo() et bar() dès que la boucle peut les lancer. Ici la boucle ne tourne pas encore. Plus le programme est complexe, plus il va devenir difficile de savoir à quelle étape logique les coroutines vont démarrer.

En prime run_forever() est un piège à con, car les exceptions qui arrivent dans la boucle sont logguées, mais ne font pas crasher le programme, ce qui rend le debuggage super rude, même avec debug mode activé (dont de toute façon personne ne soupçonne l’existence).

La solution asyncio

import asyncio as aio
loop = aio.get_event_loop()
loop.run_until_complete(aio.gather(foo(), bar())

En plus d’être plus court, les exceptions vont faire planter le programme, la loop s’arrêtera quand les coroutines auront fini leur taff, leur flux a un début et une fin encapsulés par le gather(). Ceci est encore plus visible si on met le même code à l’intérieur d’une coroutine à l’intérieur d’une coroutine à l’intérieur d’une coroutine plutôt qu’à la racine du programme. En effet dans un exemple si simple, on se borne au démarrage et à l’arrêt de la boucle. Mais je suis paresseux.

Donc, c’est la bonne pratique, mais tout le monde ne le sait pas.

Pardon, correction.

Tous les devs Python ne connaissent pas asyncio. Parmi ceux qui connaissent asyncio, une petite partie comprend comme ça marche.

Dans ce lot rikiki, un pouillième sait que c’est la bonne pratique.

En fait, gather() est probablement la fonction la plus importante d’asyncio, et pourtant elle apparaît à peine dans la doc. C’est la malédiction d’asyncio, une lib que tout le monde attendait pour propulser Python dans la league des langages avec frameworks modernes, mais qui commence à peine à devenir utilisable par le commun des mortel en 2018. Et encore.

Il ne faut jamais utiliser ensure_future() à moins de vouloir attacher un callback à la main dessus, ce qui n’est probablement jamais ce que vous voulez à cette époque merveilleuse ou existe async/await. ensure_future() est un goto, gather() est un concept de plus haut niveau.

Mais deux problèmes demeurent…

Contrairement au goto banni de Python, ensure_future() est là, et va rester. Donc n’importe quel connard peut dans un code ailleurs vous niquer profond, et en tâche de fond.

ensure_future() (ou son petit frère EventLoop.create_task()) reste le seul moyen valable pour lancer une tâche, faire quelque chose, lancer une autre tâche, puis enfin faire un gather() sur les deux tâches:

async def grrr():
    task1 = aio.ensure_future(foo())
    # faire un truc pendant que task1 tourne
    task2 = aio.ensure_future(bar())
    # faire un truc pendant que task1 et task2 tournent
    # On s'assure que tout se rejoint à la fin:
    await aio.gather(task1, task2)

Et puis, faire une pyramide de gather() dans tout son code pour s’assurer que tout va bien de haut en bas, c’est facile à rater.

La nursery : la solution de trio

Une nursery agit comme un scope qui pose les limites du cycle de vie des tâches qui lui sont attachées. C’est un gather(), sous stéroide, et avec une portée visuellement claire:

async def grrr():
    async with trio.open_nursery() as nursery:
        task1 = nursery.start_soon(foo)
        # faire un truc pendant que task1 tourne
        task2 = nursery.start_soon(bar)
        # faire un truc pendant que task1 et task2 tournent

Les taches sont garanties, à la sortie du with, de se terminer. Le ensure_future() n’a pas d’équivalent en trio, et donc aucun moyen de lancer un truc dans le vent sans explicitement lui passer au moins une nursery à laquelle on souhaite l’attacher.

Résultat, on ne peut plus faire de goto, et le flux du program est clair et explicite.

Notez que, tout comme if et while ne permettaient rien qu’un utilisateur soigneux de goto ne pouvait faire, la nursery ne permet rien qu’un utilisateur soigneux de ensure_future() ne peut faire. Mais ça force un ensemble de bonnes pratiques.

Évidemment, on peut ouvrir une nursery dans un bloc d’une autre nursery, ce qui permet d’imbriquer différentes portées, comme on le ferait avec un begin() de transaction de base de données. Or, une exception à l’intérieur d’une nursery bubble naturellement comme toute exception Python, et stoppe toutes les tâches de la nursery encore en train de tourner. Alors qu’avec asyncio vous l’avez dans le cul.

En définitive, c’était la pièce manquante. La moitié du boulot avait était faite quand on a introduit un moyen de gérer des tâches asynchrones qui dépendent les unes des autres, en remplaçant les callbacks par un truc de haut niveau : async/await. Il restait la gestion des tâches en parallèle qui se faisait encore selon les goûts et compétences de chacun, mais la nursery va remplir ce vide.

Cela devrait être intégré à asyncio en Python 3.8, soit une bonne année et demie pour ceux qui ont la chance de pouvoir faire du bleeding edge.

Comme certains ne voudront pas attendre, je vous ai fait un POC qui vous montre comment ça pourrait marcher. Mais cette version ne sera jamais utilisée. En effet, elle intercepte ensure_future() (en fait le create_task() sous-jacent) pour attacher son résultat à la nursery en cours, évitant tout effet goto, et ça péterait trop de code existant. Mon pognon est plutôt sur un gros warning émis par Python quand on fait une gotise.

Dernier mot: s’il vous plaît, allez voter pour change le nom de nursery. C’est beaucoup trop long à taper pour un truc qu’on va utiliser tout le temps.

]]>
Once you go black, you never go back 19http://sametmax.com/?p=24513http://sebsauvage.net/streisand.me/sametmax/index.php?20180606_131612_Once_you_go_black__you_never_go_back_19Wed, 06 Jun 2018 11:16:12 +0000PEP8 sont pour moi deux features fondamentales de Python, limitant énormément la quantité de code illisible qu'on trouve dans la communauté.]]>L’indentation obligatoire et l’existence du PEP8 sont pour moi deux features fondamentales de Python, limitant énormément la quantité de code illisible qu’on trouve dans la communauté.

Malgré cela, le reformatage de code reste une tache courante, et nécessaire, mais un gâchis énorme de temps. D’abord il faut décider comment on va formater, ce qui en équipe veut dire débat sur le pire sujet qui soit: le goût. Ensuite il faut mettre en place des configurations de linter (flake8, pylint, etc), et potentiellement l’infra qui va avec (tox, hooks git, CI…).

Pour cette raison, de nombreux outils de formatage automatique ont vu le jour. Le premier a été autopep8, et plus tard yapf de Google.

Mais ces deux outils ont quelques soucis:

  • Pas facile à faire marcher ou à configurer.
  • Ne résout pas l’éternel débat du formatage préféré qui revient dans un meeting chaque année.
  • Parfois ils ne marchent pas.
  • Parfois ils changent le sens du code (arg!).
  • Ils vous font des git diff bien velus.
  • Ne marche pas avec toutes les versions de Python.

Le monde du langage Go a choisi une stratégie différente: la technique du “ta gueule”.

Et aussi: ta gueule

Et aussi: ta gueule

Cette technique subtile et raffinée s’est incarnée dans l’outil Gofmt, qui est fourni par défaut avec go, et n’a AUCUN réglage.

Le résultat, tout le monde a fermé sa gueule et a adopté l’outil.

Est-ce que le formatage est parfait ? Non.

Est-ce qu’il plaît à tout le monde ? Absolument pas.

Est-ce qu’il fait fermer sa putain de gueule à tout le monde afin qu’on puisse enfin retourner à des choses plus importantes comme coder ?

Yes !

Gofmt produit un formatage suffisamment clair et pragmatique, et comme il est fortement ancré dans la communauté, tout le monde est à la même enseigne. Passer d’un code à un autre est facile. Pas de temps perdu à discuter du style ou à tweaker ses linters. Tout le monde lance go fmt (aka go ferme ta …) et on passe à autre chose.

Dernièrement facebook a décidé de faire pareil, et à pondu en open source black (en référence à Henry Ford), un outil de formatage en Python, qui n’a que 2 réglages. Il suit le PEP8, mais évidemment sa propre interprétation, et ne propose rien d’autre.

Black a aussi l’avantage de fournir des diffs assez petits, et surtout, vérifie si l’AST change après un reformatage, et annule le cas échéant, garantissant que le sens de votre code n’est pas altéré.

Est-ce que j’aime toutes les règles de formatages de black ? Non.

Est-ce que regarder sa sortie me donne parfois envie de me bouffer les couilles parce que franchement, qui pense que c’est une bonne idée d’aligner les choses comme ça ? Parfois.

Mais c’est good enough.

Et du coup, l’adoption de black a été très rapide dans la communauté, et il a été appliqué à heroku, requests, tablib, envoy, clint, fabric 2 et pytest. 4000 stars sur github.

Installation

Évidemment, ça se pip install, mais uniquement sur Python 3.6. Black peut checker du code 2.7, mais il lui faut du 3.6 minimum pour exister, donc on l’installe en parallèle. Évidemment, on peut l’intégrer à ST, Vim ou VSCode. Si votre projet utilise un Python different, il faut donc dans les options faire pointer l’exécutable vers l’installation séparée.

Résultat

Dans l’esprit du lien partagé par Seb, créons un générateur de titre de film porno:


import random

subject_qualifiers = ( "shy", "mature", "busty", "hot", "horny", "ebony", "quiet", "excited", "naughty", "bad", "cheating", "beautifull", "gorgeous", "drunk", "emo", "fat", "chubby", "goth", "lingery wearing", "latex enthousiast", "placid", "energic", 'slutty', 'sweaty', 'curvy', )

subjects =(
    'teen',
    'doll',
    'brunette',
    'blonde',
    'midget',
    'milf',
    'bitch',
    'babe',
    'sister',
    'step-mom',
    'vixen',
    'secretary',
    'real estate agent',
    'teacher',
    'student',
    'schoolgirl',
    'cheer leader',
    'asian tourist',
    'babysitter',
    'ex girlfriend',
    'nurse',
    'squirtter',
    'model',
    'granny',
    'furry',
)

actions = (
        "recieves anal",
        "get busted",
        "driven to bukakke",
        "taught double penetration",
        "fucked hard",
        'gently chocked',
        'punished',
        'forced into blow job',
        'pounded',
        'creampied',
        'ass raped',
        "eaten",
        "get her pussy wet",
        "shamed",
        "get an orgasm for the first time",
        'lead to loud climax',
        'offered best sex of her life',
        'worn out',
        'cured from boredom',
        'warmed up',
        'loved in and out',
        'generously oiled',
        'shocked and impressed',
        'decieved into giving it',
        'woke up roughly',
        'get sexy massage',
        'ridden to exhaustion',
        'turned into a lavish slave',
        'never submit to torture',
        'rebels against abuses',
        'taken in every possible way',
        'enjoy the 10 inches provided',
)

actors = (
        "pawn shop owner",
    "corrupted cop",
    "dirty plumber",
    "big ass nigga",
    "sport coach"
    "her boss",
    "twisted psychiatrist",
    "ripped doctor",
    "crispy fire fighter",
    "smug playboy",
    "skinny geek",
    "eccentric millionaire",
    "airplane pilot",
    "movie star",
    'football team',
    'her big brother',
    'security guard',
    'hairy beast',
    'wasted guitard player',
    'hung indian immigrant',
    'a guy twice her size',
    '17 guys in a row',
    'her ideal man',
    'her secret prince charming',
    'weirdo albinos',
    'muscle giant',
    'the worst cook ever',
    'cable man',
    'more men that she can count',
    'two friendly brothers',
    'enrike strongsteel'
)

contexts = (
    "on the beach","in a cheap motel","in the back of a van",
    "in airplane toilets", "for hours", "to pay back her depts",
    "for a stupid mistake", "and it gets better", "and ask for more",
    "because she could", "in exchange for a favor",
    "right next to her boyfriend", "as a reward",
    "hopping to get him back", "caught on security cam", "every monday",
    "in a barn", "but that's not all", 'but she has a secret',
    "and she has a dick too", 'before inviting her friend over',
    'while her father is watching', 'with her ', "while auditing for a role",
    "to get her job back", "for an interview", "in exclusive sex tape",
    "again and again", ", begging to stop", "for a change", "for chrismas",
    "in public", 'in a back alley', "during a concert", 'on her death bed'
)

punctuation = ('','!','!!','...')

def get_title(subject_qualifiers, subjects, actions, actors, contexts) :


    qualifier = random.choice(subject_qualifiers)
    subject = random.choice(subjects)
    action = random.choice(actions)
    actor = random.choice(actors)
    context = random.choice(contexts)

    return f"{qualifier} {subject} {action} by {actor} {context}" .capitalize()


if __name__ == "__main__":
    print(get_title(subject_qualifiers = subject_qualifiers, subjects=subjects,
                    actions=actions, actors=actors, contexts=contexts))

Usage:

$ python3.6 porn_title_generator.py
Chubby model loves bukakke by skinny geek during a concert
$ python3.6 porn_title_generator.py
Busty bitch rebel against abuses by security guard but she has a secret
$ python3.6 porn_title_generator.py
Lingery wearing student creampied by weirdo albinos on the beach
$ python3.6 porn_title_generator.py
Horny bitch offered best sex of her life by hairy beast in airplane toilets
$ python3.6 porn_title_generator.py
Emo blonde punished by airplane pilot on the beach
$ python3.6 porn_title_generator.py
Quiet squirtter lead to loud climax by wasted guitard player while auditing for a role
$ python3.6 porn_title_generator.py
Emo babysitter get her pussy wet by football team caught on security cam
$ python3.6 porn_title_generator.py
Busty asian tourist taken in every possible way by muscle giant and she has a dick too
$ python3.6 porn_title_generator.py
Placid milf ass raped by muscle giant in a back alley
Je soupçonne un coup des frères Markov

Je soupçonne un coup des frères Markov

On applique black, zero réglage, usage simplissime:

$ black . # appel recursif, modification in place par défaut

Le résultat.

import random

subject_qualifiers = (
    "shy",
    "mature",
    "busty",
    "hot",
    "horny",
    "ebony",
    "quiet",
    "excited",
    "naughty",
    "bad",
    "cheating",
    "beautifull",
    "gorgeous",
    "drunk",
    "emo",
    "fat",
    "chubby",
    "goth",
    "lingery wearing",
    "latex enthousiast",
    "placid",
    "energic",
    "slutty",
    "sweaty",
    "curvy",
)

subjects = (
    "teen",
    "doll",
    "brunette",
    "blonde",
    "midget",
    "milf",
    "bitch",
    "babe",
    "sister",
    "step-mom",
    "vixen",
    "secretary",
    "real estate agent",
    "teacher",
    "student",
    "schoolgirl",
    "cheer leader",
    "asian tourist",
    "babysitter",
    "ex girlfriend",
    "nurse",
    "squirtter",
    "model",
    "granny",
    "furry",
)

actions = (
    "recieves anal",
    "get busted",
    "driven to bukakke",
    "taught double penetration",
    "fucked hard",
    "gently chocked",
    "punished",
    "forced into blow job",
    "pounded",
    "creampied",
    "ass raped",
    "eaten",
    "get her pussy wet",
    "shamed",
    "get an orgasm for the first time",
    "lead to loud climax",
    "offered best sex of her life",
    "worn out",
    "cured from boredom",
    "warmed up",
    "loved in and out",
    "generously oiled",
    "shocked and impressed",
    "decieved into giving it",
    "woke up roughly",
    "get sexy massage",
    "ridden to exhaustion",
    "turned into a lavish slave",
    "never submit to torture",
    "rebels against abuses",
    "taken in every possible way",
    "enjoy the 10 inches provided",
)

actors = (
    "pawn shop owner",
    "corrupted cop",
    "dirty plumber",
    "big ass nigga",
    "sport coach" "her boss",
    "twisted psychiatrist",
    "ripped doctor",
    "crispy fire fighter",
    "smug playboy",
    "skinny geek",
    "eccentric millionaire",
    "airplane pilot",
    "movie star",
    "football team",
    "her big brother",
    "security guard",
    "hairy beast",
    "wasted guitard player",
    "hung indian immigrant",
    "a guy twice her size",
    "17 guys in a row",
    "her ideal man",
    "her secret prince charming",
    "weirdo albinos",
    "muscle giant",
    "the worst cook ever",
    "cable man",
    "more men that she can count",
    "two friendly brothers",
    "enrike strongsteel",
)

contexts = (
    "on the beach",
    "in a cheap motel",
    "in the back of a van",
    "in airplane toilets",
    "for hours",
    "to pay back her depts",
    "for a stupid mistake",
    "and it gets better",
    "and ask for more",
    "because she could",
    "in exchange for a favor",
    "right next to her boyfriend",
    "as a reward",
    "hopping to get him back",
    "caught on security cam",
    "every monday",
    "in a barn",
    "but that's not all",
    "but she has a secret",
    "and she has a dick too",
    "before inviting her friend over",
    "while her father is watching",
    "with her ",
    "while auditing for a role",
    "to get her job back",
    "for an interview",
    "in exclusive sex tape",
    "again and again",
    ", begging to stop",
    "for a change",
    "for chrismas",
    "in public",
    "in a back alley",
    "during a concert",
    "on her death bed",
)

punctuation = ("", "!", "!!", "...")


def get_title(subject_qualifiers, subjects, actions, actors, contexts):

    qualifier = random.choice(subject_qualifiers)
    subject = random.choice(subjects)
    action = random.choice(actions)
    actor = random.choice(actors)
    context = random.choice(contexts)

    return f"{qualifier} {subject} {action} by {actor} {context}".capitalize()


if __name__ == "__main__":
    print(
        get_title(
            subject_qualifiers=subject_qualifiers,
            subjects=subjects,
            actions=actions,
            actors=actors,
            contexts=contexts,
        )
    )

L’indentation est revue et normalisée vers 4 espaces, les espacements et sauts de ligne sont rééquilibrés (limite de caractères à 88 ), les quotes deviennent toutes ‘”‘. C’est lisible. Le code marche toujours.

Problem solved.

]]>
Je fais mon coming out 47http://sametmax.com/?p=24447http://sebsauvage.net/streisand.me/sametmax/index.php?20180529_134823_Je_fais_mon_coming_out_47Tue, 29 May 2018 11:48:23 +0000J’utilise VSCode

J’ai vraiment du mal à m’en remettre, et j’ai des proches qui utilisent Vim et ne sont pas toujours encore à l’aise avec l’idée. J’ai refusé d’utiliser Visual Studio à de nombreuses reprises, alors tester son petit frère était déjà un pas osé. Un truc Microsoft. Un truc écrit en Javascript.

Mais bon, j’aime ça, et il faut pas avoir honte de qui on est.

Le fait que ce soit libre et multiplateforme pour un produit Microsoft est surprenant, néanmoins c’est le maintien continu de l’excellent comportement de la team derrière qui est le plus bluffant: respectueux, proche des utilisateurs, sans bullshit…

Le fait que ce soit facile à installer et utiliser pour un projet javascript est surprenant, néanmoins c’est l’excellente performance du produit qui est le plus bluffant: temps démarrage, réactivité du scroll, gestion de gros projets…

Alors j’ai continué à le garder sous le coude, en parallèle à Sublime Text.

Et quelque chose de subtil a changé, chaque jour, sublime dont j’ai pourtant payé la licence, me faisait de moins en moins bander. Je sollicitais de plus en plus VSCode. Jusqu’à ce que ça devienne mon éditeur par défaut.

Oh, ST et moi on se voit toujours. Pour ouvrir un petit fichier vite fait, taper un article, tester un truc.

En revanche dès que c’est un projet, j’ai un éditeur Electron made in Redmond pour ça, et il me rend heureux.

L’ergonomie de la bestiole

Les auteurs de VSCode ont pompé tous les éditeurs les plus populaires, goulûment. Ils ont optimisé le temps de démarrage à mort, et même si on n’a pas la vitesse d’un ST ou d’un Vim, ça reste moult fois plus rapide que la vaste majorité de la concurrence. Pas de splash screen à rallonge et ce moment de doute où on n’est pas sûr d’avoir vraiment cliqué sur le bouton. J’aime bien Jetbrain mais le startup de PyCharm me fout les boules à chaque fois.

Côté apparence, on retrouve des lignes épurées avec peu de boutons, des tabs, la fameuse bird view du code de ST, un Head Up Display, une statut-bar très riche et le “go to anywhere” que tout le monde adore depuis Mate.

La force de VSCode c’est l’expérience de son équipe : ils ont bien compris ce que les utilisateurs faisaient le plus souvent, et l’ont mis à porter de main. Un clic pour faire un split view ou afficher le terminal intégré. Mais pas de fonction “Imprimer”. Une barre latérale donne l’accès à 4 autres modes, un pour la recherche dans tout le projet, un pour git (et rien d’autre), un pour le debuggeur intégré, et un pour installer des extensions.

Une foule de choses sont configurables, avec une interface qui mélange fichiers de config et aide à la saisie. C’est étrange la première fois qu’on met le nez dans “paramètres de l’utilisateur” ou “ouvrir les raccourcis clavier”. Ni vraiment une fenêtre avec des formulaires. Ni vraiment un JSON à éditer à la main. Un peu des deux. Et c’est super bien fait.

Ceci dit, comme les réglages par défaut sont assez sains, un junior n’aura pas à s’en soucier et pourra tout de suite commencer à introduire des bugs dans votre projet.

L’éditeur

Aucune innovation. Aucune tentative de faire différent de la concurrence. C’est du classique, c’est propre, et ça marche. On peut bien entendu choisir entre plusieurs mode de saisie (mode VI, Emarcs, Sublime, etc), mais perso je reste avec le mode original et quelques raccourcis custo.

Derrière, toutes les fonctionnalités modernes sont là: multi-curseur, sélection/recherche incrémentale, snippets (emmet inclus !), complétion des mots les plus utilisés, navigation par symbole, hot exit. L’avantage, c’est que comme VSCode joue la carte de l’interface minimaliste, on n’a pas besoin de connaitre tout ça, et on peut juste commencer à taper, tout en apprenant chaque feature au fur et à mesure de ses progrès. C’est un excellent éditeur pour débutant en ce sens. Mais les powers users qui aiment malgré tout la souris et les onglets y trouveront leur compte.

La coloration syntaxique est irréprochable (heureusement), mais on voit qu’ils ont du faire des concessions. Par exemple au démarrage, seule la partie de votre viewport est colorée. Il faut attendre une à deux secondes sur les gros projets pour que le reste du fichier le soit, histoire de pas freezer tout le bouzin.

Le bon côté de ça c’est que c’est très fluide. Bon évidemment j’ai 8 coeurs et 32Go de RAM. J’ai tenté l’aventure sur une VM avec 2 de rames et un tout petit coeur, et c’est pénible. Au repos avec quelques tabs ouverts, le truc s’engouffre quand même ses 700Mo de mémoire vive. N’oubliez pas que c’est du V8 derrière.

En comparaison ST en bouffe 300, et Vim, heu, LOL.

Intégration Git

L’intelligence de cette feature, c’est qu’ils se sont limités aux opérations simples et courantes. Permettre de naviguer dans l’espace temps ou de lancer son merge --rebase, c’est dur à faire correctement. Donc VSCode n’essaye pas.

Il affiche juste la liste des fichiers qui sont modifiés et/ou en staging, permet de les bouger de l’un à l’autre ou annuler les modifications, et de faire un commit rapidement. Un clic sur un fichier l’ouvre en mode diff avec HEAD. C’est tout.

C’est pas 1% de ce que permet de faire Git.

Mais c’est facilement 69% de mon usage de Git. Du coup c’est super pratique. Combiné avec le terminal intégré, et vous pouvez gérer presque tout le repo sans sortir de l’éditeur.

Le debuggeur

Je ne l’utilise jamais et je préfère ipdb. Pour le moment, en Python, il est trop lent. Les devs JS en disent du bien, vu qu’apparemment il est capable de se connecter directement au navigateur et comprend TypeScript de manière transparente.

La recherche

Rien à dire. C’est rapide. Ça marche. Ça supporte les trucs les plus importants: case insensitive (activé par défaut), regex, in sélection, dans tous les fichiers, filtrés par extension, et tout le bordel. Cliquer sur le résultat ouvre le fichier à la bonne ligne. Pas de modale qui bloque l’UI.

Pas de surprise, donc. Mais pas de mauvaises surprises.

L’indexage est configurable par projet, ce qui est indispensable dès que vous avez quelque chose d’un peu complexe.

La recherche de fichiers par nom est absente puisque ferait doublons avec “Go To Anywhere”.

Intégration des langages

Là, on attaque la partie intéressante. VSCode est neutre dans son traitement des langages, et toutes les features avancées se font donc via des extensions. L’astuce, c’est que l’équipe supporte officiellement certaines extensions, et elles sont donc d’excellente qualité.

Le support de Python est phénoménal. C’est simplement le meilleur après celui de PyCharm (et de pas beaucoup), ce qui n’est pas peu dire, vu que Jetbrain fait probablement des messes noires et des sacrifices à Quetzalcoatl pour obtenir ce résultat.

Python est notoirement difficile à outiller de par son très grand dynamisme.

Mais là, c’est beau.

Pylint est activé par défaut, et flake8 ainsi que mypy sont optionnellement activables. Leurs préréglages sont de bonne qualité, particulièrement celui de mypy qui est normalement inutilisable out of the box. L’éditeur vous prompte pour l’installation quand il détecte qu’ils sont absents, et lance tout ça pour vous.

Tout est configurable par projet, et donc si vous spécifiez un virtualenv pour votre projet (ce qui vous devriez toujours faire), VSCode va détecter que les outils ne sont pas dedans, vous proposer de les installer, et le faire pour vous.

Du coup, bénéficier des types hints, de la détection des erreurs de syntaxes, des variables non déclarées et des imports manquants ou inutiles est beaucoup plus facile que sur n’importe quel compétiteur. Ok, sauf PyCharm. Mais personnellement je l’appelle PyChiderme.

Si VSCode ne supporte pas nativement un outil, il existe probablement une extension pour ça. Par exemple, il y a une extension pour black, qui est à Python ce que Gofmt est à Go, et que j’installe donc maintenant à chaque nouveau projet.

L’intégration de ces outils est excellente :

  • Les linters de Python sont naturellement lents, mais VSCode les lance en asynchrone et ça ne ralentit pas son UI.
  • L’affichage des erreurs est claire, mais discret. Ça limite l’effet sapin de Noël.
  • à côté du terminal intégré existe une fenêtre qui liste toutes les erreurs par fichier. On peut ainsi parcourir son projet erreur par erreur.

VScode m’a même surpris à détecter mes tests unitaires, m’a proposé d’installer pytest puis de lancer tout ça.

Cependant, pour vraiment parler de l’intégration de Python dans VSCode, il me faut mentionner IntelliSense. C’est un terme marketing inventé par MS pour caractériser toutes les fonctionnalités autour de la compréhension que l’éditeur à du code, et des opérations qu’il propose dessus.

Ok, ok, c’est un mot 100% bullshit.

Mais bordel, ça marche.

La complétion du code est excellente, et marche sans aucun réglage. Avec la lib standard bien entendu, mais aussi avec votre code, et toutes les libs installées dans votre virtualenv (si vous avez précisé le chemin vers ledit env dans les settings du projet, of course, il est pas devin).

VSCode affiche les docstrings, les params et propose d’aller à la définition de n’importe quoi en un clic.

Et si comme moi vous avez passé un temps fou à essayer d’obtenir le même résultat sous ST/Vim/Whatever en chargeant what mille plugins et en changeant 600 valeurs de configs, vous comprendrez que c’est juste, topissime.

Quelques infos

Les réglages de VSCode de base sont bons. C’est vraiment une partie de ce qui fait la force du projet: moins de bordel à faire soi-même. Mais comme il est bien configurable, il ne faut pas s’en priver. Quelques trucs que je fais toujours:

Installer une police avec des ligatures

Genre Fira-Code.

Et activer les settings:

    "editor.fontFamily": "'Fira Code', 'Droid Sans Mono', 'Courier New', monospace, 'Droid Sans Fallback'",
    "editor.fontLigatures": true,

Exclure plein de fichiers

J’ai pas du tout envie que “Go to anywhere”, la recherche des fichiers ou l’indexage git charge des trucs inutiles. Donc j’ai des settings de base de nazi:

    "files.exclude": {
        "**/.git": true,
        "**/.svn": true,
        "**/.hg": true,
        "**/.DS_Store": true,
        "**/dist": true,
        "**/build": true,
        "**/env/**": true,
        "**/venv/**": true,
        "**/virtualenv/**": true,
        "**/node_modules": true,
        "**/bower_components": true,
        "**/vendors": true,
        "**/__pycache__": true,
        "**/**/*.pyc": true
    },
    "files.watcherExclude": {
        "**/.git/objects/**": true,
        "**/node_modules/**": true,
        "**/build/**": true,
        "**/dist/**": true,
        "**/env/**": true,
        "**/venv/**": true,
        "**/virtualenv/**": true,
        "**/bower_components/**": true,
        "**/vendors/**": true,
        "**/__pycache__": true,
        "**/**/*.pyc": true
    },

Mes settings par projet sont généralement encore plus restrictifs.

Je change les params de zoom

 "window.zoomLevel": 2,
 "editor.mouseWheelZoom": true,
 "editor.fontSize": 10,

Je vire la télémétrie

Je suis pas sous Windows 10, merde.

    "telemetry.enableCrashReporter": false,
    "telemetry.enableTelemetry": false,

Je mets des barres verticales

    "editor.rulers": [
        79, # PEP8
        88, # Black
        120 # Javascript
    ],

Ergonomie perso

    "editor.renderWhitespace": "none", # overridé par projet
    "editor.renderIndentGuides": true,
    "editor.minimap.enabled": true,
    "editor.minimap.renderCharacters": true,
    "editor.autoIndent": true,
    "window.restoreWindows": "all",
    "window.openFoldersInNewWindow": "on",
    "editor.acceptSuggestionOnEnter": "off",
    "editor.tabCompletion": true,
    "emmet.triggerExpansionOnTab": true,

Pour un Python heureux

    "python.venvPath": "~/.local/share/virtualenvs/",
    "python.linting.mypyEnabled": true,
    "python.linting.enabled": true,
    "python.pythonPath": "/usr/bin/python3.6", # je l'override dans les settings de projet
    "black.path": "/home/user/.local/bin/black", # black a besoin de Python 3.6
    "python.formatting.provider": "none", # pour black
    "editor.formatOnPaste": true,
    "files.associations": {
        ".pylintrc": "ini"
    },
    "python.linting.flake8Enabled": true,
    "python.unitTest.pyTestEnabled": true,
    "python.linting.pylintEnabled": true,

J’installe généralement ces extensions

  • Python. Logique.
  • Color highlight pour que les code hexa soient surlignés avec la couleur qu’ils représentent.
  • Black, parce que je ne veux plus jamais reformater du code manuellement de ma vie.
  • Django template et jinja, pour un meilleur support des templates django et jinja en coloration syntaxique.
  • Editor config parce que j’ai toujours un .editorconfig à la racine de mes projets.
  • gitignore, systemd-init-file, restructured text afin d’avoir la coloration syntaxique pour eux aussi
  • path intellisense, comme ça j’ai la complétion sur les chemins de fichier.
  • Rainbow CSV, qui affiche chaque colonne d’un CSV dans une couleur différente.
  • git history pour afficher l’historique d’un fichier ou d’une ligne.

Astuces utiles

VSCode vient avec les raccourcis traditionnels des éditeurs graphiques: ctrl + F pour rechercher, ctrl + shift + f pour rechercher dans le projet, ctrl + d pour la sélection incrémentale, ctrl + p pour le “go to anywhere”, ctrl + shift + p pour le head up display, ctrl + s pour sauvegarder, ctrl (+shift) pour se balader (sélectioner) de mot en mot, etc.

Il possède aussi quelques trucs sympas dont on parle moins dans les tutos:

  • clic milieu active la sélection verticale
  • Dans un shell, code -r ouvre un fichier dans la fenêtre en court, et code -n dans une nouvelle fenêtre. code --diff foo bar ouvre les deux fichiers en mode comparaison.
  • Dans un projet, le fichier .vscode/tasks.json contient la configuration des taches à lancer. Compilation, tests unitaires, debuggage, serveur… On peut lui faire faire n’importe quoi.
  • “Join line” n’a aucun shortcut par défaut. C’est une opération courante, donc je vous conseille de la mapper. Perso je la mets sur ctrl + j.
  • Ctrl+Shift+ O permet de se déplacer vers n’importe quel symbole. C’est pratique, mais personne ne s’en souvient jamais. Plus facile à retenir: faire un “go to anywhere” (ctrl + P) et commencer la recherche par @. Ou @: pour regrouper les symboles par nature (classes, fonctions, etc). Le “go to symbole” marche sur tout le projet avec Ctrl + T, mais c’est lennnnnnnnnnnnt.
  • De la même manière, on peut aller à un numéro de ligne avec Ctrl+ G. Mais c’est plus facile de faire un “go to anywhere” puis de taper :. Ou depuis un terminal code file.ext:numligne
  • Ctrl+ U, aka “putain nooooooooooooooon, j’ai fais un ctrl + d de trop”.
  • Ctrl + k + ctrl + f appliquer le formateur à la sélection. Pour les gens qui ont des TOC.
  • VSCode a une preview pour le markdown. Facile à lancer depuis le HUD
  • Une fois que vous avez pris l’habitude d’utiliser “go to definition” dans le menu contextuel, sachez que ctrl + clic fait pareil :)

Un snippet perso que je rajoute également (dans $HOME/.config/Code/User/snippets/python.json):

   "wrap_in_try_except": {
        "prefix": "try",
        "body": [
          "try:",
          "\t${0}${TM_SELECTED_TEXT}",
          "except ${1:Exception}:",
          "\t${2:import pdb; pdb.set_trace()}"
        ],
        "description": "Wrap in try/except"
    },

Ça permet de sélectionner un truc, de taper try puis tab et avoir le tout wrappé dans un try/except.

Le futur

Depuis sa sortie, l’éditeur est en constante amélioration. Les mises à jour sont toujours une excellente surprise, avec des tas de goodies, y compris dans les extensions.

Mais là, dans la dernière version instable (qui a la bonne idée de ne pas overrider la stable à l’installation), VSCode vient avec une preview de l’édition collaborative. Genre Google doc, mais pour le code, et dans tout l’éditeur.

La partie chiante, c’est qu’il faut un compte (Microsoft évidemment), et donc que ça passe par leurs serveurs.

La partie amazing par contre, c’est que ça envoie du poney nucléaire. L’ouverture des onglets, l’écriture, le scroll… Tout se synchronise proprement. Si on décide de faire sa vie, VSCode désynchronise la navigation, et permet à tout le monde de travailler en parallèle sur le projet (et même optionnellement donner accès à son terminal). Si on veut de nouveau voir la navigation de l’autre, on peut demander de le suivre à nouveau, et pouf, on suit ce qu’il fait en live.

Testé avec des clients à des milliers de borne. C’est bluffant.

Vous l’avez compris

]]>
Trier un CSV de 5 Go 15http://sametmax.com/?p=24323http://sebsauvage.net/streisand.me/sametmax/index.php?20180514_102612_Trier_un_CSV_de_5_Go_15Mon, 14 May 2018 08:26:12 +0000un célèbre post de Guido sur la réponse à la blague "comment trier un million d'entiers avec 2M de Ram", j'ai réalisé 2 choses:
  • Le contenu de l'article est génial.
  • Le contenu de l'article est incompréhensible.
]]>
Marrant, j’ai jamais eu autant de RAM, et j’ai jamais eu autant de problèmes de RAM. On est en train de faire un bon dans inefficacité des programmes, et ça va pas aller en s’arrangeant entre docker, electron et nos chers navigateurs. Une grosse app Python peut devenir assez velue aussi niveau mémoire, même quand on n’est pas un boulet comme moi.

Et justement, en relisant un célèbre post de Guido sur la réponse à la blague “comment trier un million d’entiers avec 2M de Ram”, j’ai réalisé 2 choses:

  • Le contenu de l’article est génial.
  • Le contenu de l’article est incompréhensible.

Or c’est un peu ma raison d’être, si vous voulez, de prendre les trucs cools mais imbitables et les rendre utilisables.

Aujourd’hui, donc, on va trier un CSV de 5Go en Python. Ça parle plus qu’un fichier de nombres, et puis ça évite d’expliquer le module array qui est juste une optimisation.

J’ai pris mes petites mimines, et j’ai pondu un CSV qui contient 63Mo de:

A,01/02/2016,2
A,13/07/2011,1
B,24/01/1996,3
C,30/12/1999,1
D,13/07/2011,3
D,01/02/2016,5
E,24/01/1996,4
F,30/12/1999,1
G,13/07/2011,4
H,01/02/2016,4
I,01/02/2016,5
I,13/07/2011,2
A,01/02/2016,2
A,13/07/2011,1

En copier/coller.

Puis j’ai lancé un script pour dupliquer le bébé et jusqu’à atteindre 5,9 Go de taille:

with open('data.csv') as infile:
    with open('data2.csv', 'w') as outfile:
        for x in range(100):
            outfile.write(infile.read())
            infile.seek(0)
Si jamais vous doutiez que je vous aime...

Si jamais vous doutiez que je vous aime…

395366400 lignes. Jusqu’ici tout va bien.

Maintenant, supposons qu’on veuille trier sur la date. Si vos souvenirs en Python sont exacts (ou si vous avez lu notre super article sur Ordonner en Python), vous savez que la solution naïve est de loader le fichier cash pistache, puis d’appeler dessus sorted() avec le paramètre key.

D’abord, il faut choisir le callback à passer à key, c’est à dire la fonction qui va être exécutée pour chaque ligne pour extraire la date de la ligne et permettre ainsi à sorted() de comparer avec les autres dates.

>>> str_date = "A,01/02/2016,2".split(',')[1] # récupère la date uniquement
>>> str_date
'01/02/2016'
>>> ''.join(str_date.split('/')[::-1]) # on inverse la date avoir une valeur ordonnable
'20160201'

On en fait une fonction:

 
def extract_date(ligne):
    str_date = ligne.split(',')[1]
    return ''.join(str_date.split('/')[::-1])

Ensuite on a juste à ouvrir le fichier, trier les lignes, et sauvegarder tout ça dans l’autre fichier:

with open('data2.csv') as infile:
    with open('sorted_data.csv', 'w') as outfile:
        # on fait le tri
        sorted_lines = sorted(infile, key=extract_date)
        # on ecrit les lignes triées dans le nouveau fichier
        outfile.writelines(sorted_lines)

Easy money, double poney.

Enfin avec un fichier de quelques Mo. Parce que si vous faites ça dans un fichier de 5,9 Go, votre RAM va vomir comme une pom pom girl anorexique.

sorted() sur un disque complet, illustré

sorted() sur un disque complet, illustré

Comment résoudre ce problème ?

Et bien en faisant tout pareil, mais avec des petits morceaux !

import heapq

from tempfile import TemporaryFile
from itertools import islice

# On garde notre fonction key
def extract_date(ligne):
    str_date = ligne.split(',')[1]
    return ''.join(str_date.split('/')[::-1])

# Liste de tous les fichiers temporaires avec les lignes triées
sorted_temp_files = []

with open('data2.csv') as infile:
    progress = 0
    while True:
        # On lit seulement 3000000 lignes sur 395366400 à chaque tour de boucle
        lines = list(islice(infile, 3000000))

        if not lines:  # plus de ligne ? On sort
            break

        # On affiche où on en est
        print("{:.2f}%".format(progress))
        progress += (3000000 / 395366400 * 100)

        # On tri les lignes, comme avec sorted() mais sur place. 
        # Ça évite de dupliquer les données en mémoire.
        lines.sort(key=extract_date)

        # On crée un fichier temporaire qui va contenir les 3000000 lignes
        # triées
        f = TemporaryFile(mode="r+")
        f.writelines(lines)

        # On rembobine le fichier pour pouvoir relire le contenu plus tard
        f.seek(0)

        # On balance le fichier dans la liste des fichiers triés
        # L'objet fichier hein. Pas le chemin du fichier. C'est pour ça qu'on
        # a fait .seek(0) avant. On va en avoir besoin plus bas.
        sorted_temp_files.append(f)

    # Toute la magie se fait là.
    # On utilise heapq.merge(), qui prend en paramètre plein de trucs qu'on 
    # vient de trier, et permet de se balader dedans comme si c'était un seul
    # gros truc trié, mais sans tout charger en mémoire.
    # En gros il regarde les premières valeurs de tous les itérables, les compares,
    # puis fait retourne un générateur qui yield tout dans l'ordre 
    with open('sorted_data.csv', 'w') as outfile:
        for ligne in heapq.merge(*sorted_temp_files, key=extract_date):
            outfile.write(ligne)

Au lieu de charger les 5 Go en mémoire, on plafonne à 400 Mo. Une raison de plus d’apprendre à utiliser les générateurs.

Sametmax, c'est de la bombe

Sametmax, c’est de la bombe

Alors évidemment, c’est long. Y a genre 40 minutes de traitement. Moins si on utilise pypy et qu’on accepte de up la conso RAM. On code pas en Rust :)

Si vous avez besoin de perfs et que Python reste votre outil de prédilections, 3 solutions restent à votre disposition:

– Prétraiter le fichier en lui rajoutant une première colonne qui contient un timestamp. Ca c’est super rapide à trier.
– Utiliser un truc de numpy ou pandas comme np.memmap().sort(kind=’merge’). C’est du C, donc ça speed.
Acheter de la ram et tout trier en mémoire avec la solution 1.

EDIT:

Un lecteur m’a alpagué sur twitter pour me dire qu’on peut faire ça plus vite et plus facilement avec sort. Oui, évidement.

L’exercice est académique, il est simplifié pour vous permettre de comprendre heapq.merge(). En réalité, on aura vraiment besoin de ça que pour un cas complexe. Exemple, vous lisez un flux de log une socket et vous checkez les adresses IP d’abord pour filtrer celles de la liste noire, puis pour les faire matcher une zone géographique et vous triez tout ça et vous le passez à la suite du pipeline. Et le tout doit marcher sous Linux et Windows Server avec juste la lib standard parce que diab est de mauvais poil.

Évidement que si vous voulez juste trier un CSV vous n’allez pas coder un script python de 30 lignes.

]]>
13558 Go de rames 25http://sametmax.com/?p=24187http://sebsauvage.net/streisand.me/sametmax/index.php?20180315_070104_13558_Go_de_rames_25Thu, 15 Mar 2018 06:01:04 +0000J’ai une tache celery qui me génère des données de test. Elle est lancée toutes les 5 minutes pour simuler le crawling d’un site qui popule une base de données, le tout piloté par l’ORM django, puis dumpé dans redis.

Jusqu’ici tout va bien.

Mais après un certain temps, ma machine rame, puis se frise.

Et j’ai du mal à y croire. J’ai 8 coeurs, un 32 Go de mémoire vive, un SSD d’un putain de To. On va pas me la faire à l’envers, c’est pas un def tout moisi qui va me faire trembler les genoux. C’est forcément un de ces cons de wallets que j’ai laissé ouvert, encore codé par un nantais ça !

Mais après une enquête minutieuse, qui a consisté en subtilement killer tous mes processus un par un avec echo "douceur" | sed s/c/l, le constat est là.

Eukekaca

Eukekaca.

Cette fonction est responsable:

def generate_fake_stats(x=1000):

    cur_stats = {
        s.currency.short_code: s
        for s in CurrencyMarketStatsFactory.build_batch(x)
    }
    
    mn_stats: Dict[str, MNMarketStats] = {
        s.masternode.coin.short_code: s
        for s in MNMarketStatsFactory.build_batch(x)
    }

    stats = []

    for code, mns in mn_stats.items():

        cstats: CurrencyMarketStats = cur_stats.get(code)

        if not cstats:
            continue

        dollar_value = float(cstats.dollar_value),
        collateral = mns.masternode.collateral

        stats = {
            'created': int(mns.created.timestamp()),
            'name': cstats.currency.name,
            'code': code,
            'title': f'{cstats.currency.name} ({code})',
            'marketcap': dollar_value * cstats.supply,
            'dollar_value': dollar_value,
            'change_rate': cstats.change_rate,
            'volume': float(cstats.volume),
            'supply': cstats.supply,
            'roi': mns.roi,
            'mn_worth': collateral * dollar_value,
            'node_count': mns.node_count,
            'required_coins': collateral,
        }

    RedisClient.get_instance().jset('marketstats', stats)
    return stats

Il m’a fallu une bonne heure pour trouver ma connerie. J’ai changé plein d’options, mis DEBUG sur False, limité la mémoire de Redis, etc.

Mais non, c’était mon code. Qui générait au bas mot 847390982*1000*16 octets de données, soit 1,355825571×10¹³ pour mes objets Python.

J'ai un nouveau mapping clavier qui permet de n'utiliser qu'un doigt

J’ai un nouveau mapping clavier qui permet de n’utiliser qu’un doigt

Il y en a un peu plus madame, je vous le mets quand même ?

Nan parce que 13 To pour une pov liste de dicos, c’est la boucherie.

Alors, sachant que je vous ai éliminé la recherche des causes parallèles et que vous savez que le bug est de ma (grande et stupide) faute, saurez-vous trouver dans ces lignes le d20 qui tombe sur un 1 à tous les jets ?

Si vous ne trouvez pas, la réponse dans quelques jours.

Explain all the humans !

Explain all the humans !

EDIT pour la réponse:

Comme plusieurs personnes l’ont compris, c’est la virgule sur:

    dollar_value = float(cstats.dollar_value),

Qui est responsable de tout ce malheur.

En effet plus loin on fait:

    'mn_worth': collateral * dollar_value,

Ce qui, au lieu de multiplier un entier par un float, multiplie un entier par un tuple. En python, c’est légal, et ça donne ça:

>>> 10 * (7808979.8989,)
(7808979.8989, 7808979.8989, 7808979.8989, 7808979.8989, 7808979.8989, 7808979.8989, 7808979.8989, 7808979.8989, 7808979.8989, 7808979.8989)

Si collateral est élevé, ce qui est ici mon cas, ça fait de très gros tuples, et le tout dans une boucle.

]]>
Do you rotate ? 2http://sametmax.com/?p=24161http://sebsauvage.net/streisand.me/sametmax/index.php?20180305_042927_Do_you_rotate___2Mon, 05 Mar 2018 03:29:27 +0000le log de debug du wallet de la coin smartcash, ça peut prendre par surprise.]]>L’explosion de la taille des logs a tué plus d’un serveur. Il est amusant de se dire que c’est du texte qui peut mettre à genoux un serveur de streaming vidéo avec 32 coeurs, 2To de SSD et 64 Go de RAM. Mais un bon access log non contrôlé sous nginx ou même le log de debug du wallet de la coin smartcash, ça peut prendre par surprise.

Le module logging de Python a d’excellentes options pour gérer la taille des logs, notamment le RotatingFileHandler.

Sous Linux, c’est logrotate qui fait le boulot pour le système. C’est performant, ça marche super bien, c’est hyper simple à utiliser, et c’est dispo partout.

Bref, en prod, un petit vi sur /etc/logrotate.d/ton_projet et pouf, on peut demander une rotation en 10 lignes:

/var/www/ton_projet/*.log
{
    size 100K
    daily
    rotate 5
    missingok
    notifempty
}

Y a rien à activer, un cron lance déjà logrotate tous les jours.

Par contre, si votre process utilise systemd pour démarrer, inutile de logger manuellement. Tout ce qui est sur la sortie standard est automatiquement loggué avec rotation et accessible avec un petit journalctl -u ton_process.service --since today.

Bref, attendez encore un peu avant de rajouter logstash à votre stack.

]]>
Introduction aux extensions Python avec CFFI 16http://sametmax.com/?p=24059http://sebsauvage.net/streisand.me/sametmax/index.php?20180207_225849_Introduction_aux_extensions_Python_avec_CFFI_16Wed, 07 Feb 2018 21:58:49 +0000Ceci est un post invité de Realitix posté sous licence creative common 3.0 unported.

Préambule

Vous avez réalisé une analyse de votre code et vous avez un bottleneck ?
Vous souhaitez utiliser une bibliothèque bas niveau (C/C++/Rust) ?

Pas de problème, dans cet article, je vais vous expliquer les différentes solutions et pénétrer en profondeur dans la plus charmante d’entre elles, son petit nom: CFFI.

Sam&Max me faisant l’honneur d’accepter mon article, je vais suivre la guideline du site avec un langage détendu et beaucoup d’exemples.

Qu’est-ce qu’une extension Python ?

Guido, pendant l’acte créateur, n’a pas oublié une chose importante: les extensions Python !
Une extension Python est un module compilé pouvant être importé dans votre code Python.
Cette fonctionnalité est très puissante: cela vous permet d’utiliser un langage bas niveau (et toutes ses capacités) pour créer un module Python.
Vous utilisez très probablement des extensions Python dans vos projets sans le savoir.
Par exemple, si vous souhaitez embarquer la bibliothèque de calcul physique Bullet, vous pouvez le faire au sein d’une extension Python.

Il y a deux points à différencier:

  • Importer une bibliothèque tierce
  • Améliorer les performances de son code

En y réfléchissant bien, créer un code performant revient à créer une bibliothèque tierce et l’importer au sein de l’interpréteur.

Ça laisse rêveur, alors comment fait-on ?

Plusieurs solutions:

  1. L’API C de CPython. Y’en a qu’ont essayé, ils ont eu des problèmes…
    En utilisant cette méthode, vous aurez accès à tout l’interpréteur Python et vous pourrez tout faire… mais à quel prix ?
    Je ne vous recommande pas cette approche, je me suis cassé les dents pendant 4 mois dessus avec un succès mitigé.
  2. Cython est une bonne solution mais plus orienté sur l’optimisation de code.
  3. CFFI: le saint Graal, alléluia!

CFFI: Première mise en bouche

CFFI va vous permettre de créer des extensions Python mais pas que…
Tout comme le module ctypes, il va permettre d’importer une bibliothèque dynamique au runtime.
Si vous ne savez pas ce qu’est une bibliothèque, c’est par ici.

CFFI va donc vous permettre:

  • D’importer une bibliothèque dynamique au runtime comme ctypes mais avec une meilleure API -> Mode ABI -> Pas de compilation
  • De réaliser une extension Python compilée comme `cython` ou comme avec l’API C de CPYTHON -> Mode API -> Phase de compilation

Par rapport à ctypes, CFFI apporte une API pythonic et légère, l’API de ctypes étant lourde.
Par rapport à l’API C de CPython… Ha non! Je n’en parle même pas de celle-là!

J’ai dit qu’il y aurait beaucoup d’exemples, alors c’est parti !

D’abord, on installe le bouzin, il y a une dépendance système avec libffi, sur Ubuntu:

sudo apt-get install libffi-dev python3-dev

Sur Windows, libffi est embarquée dans CPython donc pas de soucis.
Ensuite, on conserve les bonnes habitudes avec le classique:

pip install cffi

Je vous conseille d’utiliser un virtualenv mais ce n’est pas le sujet!

Les trois modes

Il y a trois moyens d’utiliser CFFI, comprenez bien cela car c’est la partie tricky:

  1. Le mode ABI/Inline
  2. Le mode API/Out-of-line
  3. Le mode ABI/Out-of-line

On a déjà évoqué les modes ABI et API, mais je n’ai pas encore parlé de Inline et Out-of-line.
CFFI utilise une phase de “compilation” pour parser les header C. Ce n’est pas une vraie compilation mais une phase de traitement qui peut être lourde.
Le mode Inline signifie que ce traitement va être effectué à l’import du module alors que Out-of-line met en cache ce traitement à l’installation du module.

Evidemment, le mode API/Inline ne peut pas exister puisque le mode API impose une phase de “vraie” compilation.

Le mode ABI/Inline

# On commence par import le module cffi qui contient la classe de base FFI
from cffi import FFI
 
# 1 - On instancie l'object FFI, cet objet est la base de cffi
ffi = FFI()
 
# 2 - On appelle la méthode cdef.
# Cette méthode attend en paramètre un header C, c'est à dire
# les déclarations des fonctions C qui seront utilisées par la suite.
# CFFI ne connaîtra que ce qui a été déclaré dans le cdef.
# La puissance de CFFI réside dans cette fonction, à partir d'un header C,
# il va automatiquement créer un wrapper léger.
# A noter: le code dans cdef ne doit pas contenir de directive pré-processeur.
# Ici, on déclare la fonction printf appartenant au namespace C
ffi.cdef("""
    int printf(const char *format, ...);
""")
 
# 3 - On charge la bibliothèque dynamique
# dlopen va charger la biliothèque dynamique et la stocker dans la variable nommée cvar.
# L'argument passé est None, cela demande à cffi de charger le namespace C.
# On peut ici spécifier un fichier .so (Linux) ou .dll (Windows).
# Seul ce qui a été déclaré dans cdef sera accessible dans cvar.
cvar = ffi.dlopen(None)

Comme vous pouvez le voir dans ce bout de code, CFFI est très simple d’utilisation, il suffit de copier le header C pour avoir accès aux fonctions de la bibliothèque.
A noter: si les déclarations dans le cdef ne correspondent pas aux déclarations présentes dans la bibliothèque (au niveau ABI), vous obtiendrez une erreur de segmentation.

Le mode API/Out-of-line

Pour bien comprendre ce mode, nous allons implémenter la fonction factorielle.

# Comme pour le mode ABI, FFI est la classe principale
from cffi import FFI
 
# Par convention, en mode API, on appelle l'instance ffibuilder car le compilateur va être appelé
ffibuilder = FFI()
 
# En mode API, on utilise pas dlopen, mais la fonction set_source.
# Le premier argument est le nom du fichier C à générer, le 2e est le code source.
# Ce code source va être passé au compilateur, il peut donc contenir des directives pré-processeur.
# Dans l'exemple, je passe directement le code source mais en général, on va plutôt ouvrir le fichier avec open().
ffibuilder.set_source("_exemple", """
    long factorielle(int n) {
        long r = n;
        while(n > 1) {
            n -= 1;
            r *= n;
        }
        return r;
    }
""")
 
# Comme pour le mode ABI, on déclare notre fonction avec la méthode cdef.
ffibuilder.cdef("""
    long factorielle(int);
""")
 
 
# Enfin, on va appeler la méthode compile() qui génère l'extension en 2 étapes:
# 1 - Génération d'un fichier C contenant la magie CFFI et notre code C
# 2 - Compilation de ce fichier C en extension Python
if __name__ == "__main__":
    ffibuilder.compile(verbose=True)

Après éxécution du script, voici ce que l’on voit dans le terminal:

generating ./_exemple.c  -> Étape 1: Génération du fichier C
the current directory is '/home/realitix/test'
running build_ext
building '_exemple' extension  -> Étape 2: Génération de l'extension
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g -fdebug-prefix-map=/build/python3.6-sXpGnM/python3.6-3.6.3=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/home/realitix/venv/py36/include -I/usr/include/python3.6m -c _exemple.c -o ./_exemple.o
x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-Bsymbolic-functions -specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -g -fdebug-prefix-map=/build/python3.6-sXpGnM/python3.6-3.6.3=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 ./_exemple.o -o ./_exemple.cpython-36m-x86_64-linux-gnu.so

Et vous pouvez trouver l’extension Python `_exemple.cpython-36m-x86_64-linux-gnu.so`.
Étudions le module généré, dans un interpréteur Python:

>>> from _exemple import ffi, lib
>>> dir(ffi)
['CData', 'CType', 'NULL', 'RTLD_DEEPBIND', 'RTLD_GLOBAL', 'RTLD_LAZY', 'RTLD_LOCAL', 'RTLD_NODELETE', 'RTLD_NOLOAD', 'RTLD_NOW', '__class__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'addressof', 'alignof', 'buffer', 'callback', 'cast', 'def_extern', 'dlclose', 'dlopen', 'errno', 'error', 'from_buffer', 'from_handle', 'gc', 'getctype', 'init_once', 'integer_const', 'list_types', 'memmove', 'new', 'new_allocator', 'new_handle', 'offsetof', 'sizeof', 'string', 'typeof', 'unpack']
>>> dir(lib)
['factorielle']

Les modules générés par CFFI contiennent 2 objets ffi et lib.

  • ffi: Les fonctions de l’API CFFI ainsi que les typedef et structs
  • lib: Toutes nos fonctions C, ici, il n’y a que factorielle

Ça vous dit d’utiliser notre extension avec un petit test de performance ? Allons y !

import time
from contextlib import contextmanager
 
# On import lib qui contient notre fonction factorielle
from _exemple import lib
 
# On créé l'équivalent de notre fonction C en Python
def py_factorielle(n):
    r = n
    while n > 1:
        n -= 1
        r *= n
    return r
 
# Un petit contextmanager pour mesurer le temps
@contextmanager
def mesure():
    try:
        debut = time.time()
        yield
    finally:
        fin = time.time() - debut
        print(f'Temps écoulé: {fin}')
 
def test():
    # On va réaliser un factorielle 25 un million de fois
    loop = 1000000
    rec = 25
    # Version Python
    with mesure():
        for _ in range(loop):
            r = py_factorielle(rec)
    # Version CFFI
    with mesure():
        for _ in range(loop):
            r = lib.factorielle(rec)
 
if __name__ == '__main__':
    test()

Le résultat sur ma machine:

Temps écoulé: 1.9101519584655762
Temps écoulé: 0.13172173500061035

La version CFFI est 14 fois plus rapide, pas mal !
CFFI permet de faire vraiment beaucoup de choses simplement, je ne vous ai montré que la surface afin de vous donner envie d’aller plus loin.

Où trouver des ressources

  • La doc de CFFI est vraiment bien, un bon readthedocs classique: cffi.readthedocs.io
  • Une de mes présentations à PyConAU, la version EuroPython est moins bonne: ICI
  • Mes projets CFFI:
    1. vulkan: Mode ABI ICI
    2. Pour les curieux, la version en utilisant l’API C de CPython ICI
    3. vulk-bare: Mode API, un module très simple ICI
    4. PyVma: Celui-là est très intéressant, mode API qui étend le module vulkan qui en mode ABI, c’est un très bon exemple

A savoir que CFFI a été créé par Armin Rigo et Maciej Fijalkowski, les deux créateurs de Pypy.
Toutes les extensions créées avec CFFI sont compatibles avec Pypy !

Conclusion

J’espère que cette introduction vous a plu. Si les retours sont bons, je pourrai m’atteler à un tuto plus conséquent.
Vive Python !

Si vous avez des remarques, n’hésitez pas à me le faire savoir: @realitix sur Twitter

]]>
Les critiques des ORM sont à côté de la plaque 38http://sametmax.com/?p=23967http://sebsauvage.net/streisand.me/sametmax/index.php?20171229_113105_Les_critiques_des_ORM_sont_a_cote_de_la_plaque_38Fri, 29 Dec 2017 10:31:05 +0000En ce moment, y a deux modes. Dire que les cryptomonnaies c’est génial, et dire que les ORM c’est de la merde.

Durant les derniers articles, je pense qu’on vous a assez parlé de crypto, donc on va parler des ORM.

Ou ORMs. Je sais jamais si les acronymes s’accordent.

Rappel: qu’est-ce qu’un ORM ?

Si vous avez lu le titre de l’article et que votre sang n’a fait qu’un tour, vous pouvez passer tout de suite à la partie suivante, puisqu’on va commencer par les révisions.

Un ORM, pour Object-relational Mapping, est une bibliothèque qui permet de décrire son modèle de données, et d’utiliser cette description pour faire le lien entre votre application et une base de données relationnelle. Dans sa forme la plus courante, l’ORM fournit les outils pour générer des requêtes SQL – sans écrire du SQL – et les exécuter, mais présente également les résultats sous forme d’objets du langage dans lequel il est écrit.

Par exemple, en Python, je peux faire de la base de données à la mano (sans ORM):

import sqlite3
 
# Création de la base
with sqlite3.connect('db.sqlite') as conn:
 
    # On se positionne sur la base
    c = conn.cursor()
 
    # Créer la table
    c.execute('''
        CREATE TABLE product (
            name text,
            price real
        )
    ''')
 
    # Insertion de données en base
    c.execute("INSERT INTO product VALUES ('Pizza', 5000)")
    c.execute("INSERT INTO product VALUES ('Love', 150)")
    c.execute("INSERT INTO product VALUES ('Nessie', 3.5)")
 
    # Sauvegarde des changements
    conn.commit()
 
    # Lecture de toute la base:
    for row in c.execute('SELECT * FROM product'):
        print(type(row), ':', *row)

Ce qui va me sortir:

python3 db.py
< class 'tuple' > : Pizza 5000.0
< class 'tuple' > : Love 150.0
< class 'tuple' > : Nessie 3.5

Et voici la même chose avec l’ORM peewee (apres pip install peewee :)):

import peewee as pw
 
# On créé la base
db = pw.SqliteDatabase('product2.db')
 
# Description de la table.
class Product(pw.Model):
 
    name = pw.CharField()
    price = pw.FloatField()
 
    class Meta:
        database = db
 
# Connection et création de la table
db.connect()
db.create_tables([Product])
 
# Insertion de données en base
Product.create(name='Pizza', price=5000)
Product.create(name='Love', price=150)
Product.create(name='Nessie', price=3.5)
 
for p in Product.select():
    print(type(p), ':', p.name, p.price)
 
db.close()

Ce qui sort:

python3 db.py
< class '__main__.Product' > : Pizza 5000.0
< class '__main__.Product' > : Love 150.0
< class '__main__.Product' > : Nessie 3.5

A priori, c’est la même chose, mais avec un style différent. Le premier exemple favorise l’écriture du SQL à la main, fait les requêtes explicitement et récupère les résultats sous forme de tuples. Le second a une surcouche, l’ORM, qui implique que tout est décrit en Python. Le SQL est généré sous le capot, et on récupère les résultats sous forme d’objets Product.

Il existe de nombreux ORM en Python, les plus populaires étant Peewee (pour les petits besoins), SQLAlchemy (pour les gros projets) et l’ORM de Django (ben, si vous utilisez Django ^^). Évidemment le concept des ORM n’est pas particulièrement lié à Python, et on en retrouve dans tous les langages, avec des variations de styles et de fonctionnalités.

Que reproche-t-on aux ORM ?

Avant de répondre aux détracteurs, listons d’abord leurs arguments.

  • C’est un niveau d’indirection de plus, avec de l’implicite et de la magie.
  • L’ORM va générer des requêtes non optimisées, voire lentes.
  • SQL est un excellent DSL spécialisé dans les requêtes. Au lieu d’apprendre une API de plus, autant aller à la source.
  • SQL marche pareil d’un client à l’autre, donc la connaissance est réutilisable, contrairement à celle de son ORM.
  • C’est une béquille pour ne pas apprendre le SQL, et par ailleurs va amener tot ou tard les ignorants à se tirer une balle dans le pied.
  • Les ORMs ne peuvent pas permettre l’usage de toutes les fonctionnalités de sa base de données, et donc limitent la puissance qu’on en tire.
  • Ça ne scale pas. Les gros sites, comme Instagram qui est écrit en Django, on tous finit par virer leurs ORM.

Et vous savez quoi ?

Ils ont raison.

Heu ?

Toutes ces critiques sont parfaitement justifiées.

Sauf qu’elles passent complètement à côté de la problématique.

Les ORM ne servent pas à éviter d’écrire du SQL.

Ça, c’est vaguement un effet de bord.

Ils servent à créer une API unifiée inspectable, une expérience homogène, un point d’entrée unique, un socle de référence explicite et central, pour le modèle de données.

Une fois qu’on a passé pas mal de temps à faire des projets, on note toujours la même chose: certaines parties du logiciel sont réécrites encore et encore. Si un projet commence à parler à une source de données à la main (API, base de données, crawling, fichiers, etc), tôt ou tard, quelqu’un dans l’équipe va commencer à écrire une abstraction. Celle-ci va grossir, et finir par implémenter au bout de nombreux mois, pour l’accès à la base de données, un semi ORM dégueulasse, mal testé / documenté.

Mais, si les requêtes SQL à la main c’est si bien, alors pourquoi ça arrive ?

Simplement parce que tout projet qui grandit a besoin d’une forme de gestion de la complexité. Ca passe par avoir un point, et un seul où sont décrites à quoi ressemblent les données, leurs accès, leurs garanties, leurs contraintes, et leurs validations. Ca passe aussi par permettre aux autres parties du projet d’utiliser automatiquement ces informations pour leur code métier, ainsi que la logique associée.

L’exemple de Django

L’ORM Django n’est pas vraiment le projet Python le plus propre. Il a plein de limitations et bizarreries, et son principal concurrent, SQLAlchemy est probablement une des meilleures libs au monde dans cette spécialité.

Mais !

Il est au coeur de ce qui a fait autant le succès colossal de Django.

Parce que Django est organisé autour de son ORM, il peut proposer:

  • Des validateurs générés automatiquement qui permettent de valider toute saisie de données, et sauvegarder les changements en base de données. Si besoin, il peuvent générer des formulaires HTML afin de proposer une saisie utilisateur automatiquement contrôlée et nettoyée, avec messages d’erreurs pre-traduits.
  • Des vues pour lire, lister, mettre à jour et supprimer les données, générées automatiquement. Y a plus qu’à mettre du HTML autour.
  • Une admin de base de données autogénérée. Un backend gratos et customisable pour votre projet.
  • Une pléthore d’outils pour gérer les données: signals, getters, auto-castage en objet natifs, validation avancées, etc.
  • Des points d’entrées pour étendre la manipulation de ces données de manière générique (fields, managers, etc).
  • De l’outillage pour les migrations.
  • Un worflow d’authentification, d’identification, de session, de cache et de permissions.
  • La normalisation automatique des valeurs: encoding, fuseaux horaires, devises, format de textes et nombres. Et les points d’entrées pour écrire les siens pour plugger ceux de quelqu’un d’autre.

A cela se rajoute le fait que tous les projets Django se ressemblent. Il est très facile de passer d’une équipe à une autre, d’un projet à une autre. La formalisation du schéma devient une documentation, et la seule source de la vérité à propos des données, et pas juste celle de la base. Et qui est commité dans Git. Pour savoir ce que fait un projet Django, il suffit de regarder urls.py, settings.py et models.py, et c’est parti.

Mais ce n’est pas tout. L’ORM ne fait pas que définir un point central inspectable et des outils réutilisables. Il donne aussi une base commune sur laquelle tout le monde peut compter.

Et pour cette raison, l’écosystème Django est très, très riche en modules tierces partis qui se pluggent en 3 coups de cuillère à pot:

La cerise sur le gâteau ? Parce que tout ça utilise l’ORM, tout ça est compatible ensemble. Votre authentification social auth va produire un objet user qui pourra se logger, consulter un dashboard qui contiendra le résultat d’un sondage sur un produit de la boutique.

Et ça marche avec MySQL, Oracle, SQLite ou PosgreSQL, comme l’intégralité du framework, gratos.

Ce n’est pas l’apanage de Django hein, RoR fait pareil.

Maintenant prenez un projet NodeJS. Pour le coup, pas parce que “JS ça pue” mais parce que la culture de l’ORM n’est pas très présente dans cette communauté. Non pas que ça n’existe pas, mais il n’y a pas de Django du monde du Javascript. Même les gros framework type Meteor n’ont rien d’aussi intégré.

Vous allez devoir réapprendre toute la mécanique de gestion de données si vous changez de projet, car ça sera fait différemment à chaque fois. Vous allez devoir former des gens.

Et surtout vous allez devoir réécrire tout ça.

Oh bien sûr, vous aurez une bibliothèque pour chaque chose, mais elle sera écrite différemment. Vous n’aurez pas d’objet User sur qui compter. Votre moyen de traduire le texte ? Pas le même. Vous utilisez Oracle mais l’auteur PostgreSQL ? Pas de bol. Vous voulez générer quelque chose à partir de votre modèle de données ? Ah, pourquoi vous croyez que facebook a créé GraphQL ! Une petite migration ? Vous avez le choix de l’embarras. Bon, maintenant vous allez gérer les dates, et 4 de vos bibliothèques les sérialisent différemment et une utilise l’heure locale au lieu d’UTC.

Évidemment, on sait que votre équipe ne testera pas tout ça, et ne documentera pas tout ça. La suivante non plus.

Donc non, l’ORM, ce n’est pas parce que “mais heu SQL c’est dur”.

C’est parce que ça permet de créer un monde autour.

Objection !

On a des abstractions qui ne sont pas des ORM…

L’important est d’avoir un modèle central, pas un ORM. Mais les ORM font ça particulièrement bien.

Il existe des abstractions (ex: LINQ) qui font un excellent travail pour masquer la source de données. Mais elles ne sont pas un remplacement pour un modèle introspectable central listant nature et contraintes.

Une bonne lib propose les deux.

Par exemple SQLALchemy propose un ORM, mais en vérité l’API de base est fonctionnelle et composable. Pour cette raison, on peut utiliser toutes fonctionnalités avancées de sa base de données avec SQLAlchemy car on a cette alternative à l’ORM à tout moment, et qui est compatible avec l’ORM.

Mais les perfs !

D’abord, on optimise pour les humains. En chemin, on optimise pour la machine. Quand ton ORM arrête de scaler, c’est un BON problème à avoir. Ca veut dire que le projet a atteint un certain succès, et qu’on peut investir dans la séparation avec l’ORM.

De plus, aucune technologie n’est faite pour être utilisée partout, tout le temps, pour tout le projet.

Google a connu ses débuts de succès en Python, et avec sa taille, a réécrit une partie en Java, C puis Go. C’est logique, on ne commence pas avec un langage bas niveau directement, c’est trop lent à écrire. Mais on ne garde pas un langage haut niveau pour tout quand ça monte dans les tours. Enfin les tours… Là on parle de centrifugeuse cosmique hein.

Car gardez en tête que vous n’êtes PAS Google. L’immense majorité des projets deviennent viables, rentables, puis pleins de succès, sans jamais atteindre l’échelle qui amène aux limites de l’ORM.

Quant à l’idée que votre stagiaire peut écrire une boucle avec une requête à chaque step… Il peut tout aussi bien écrire une requête SQL sans se protéger correctement l’injection de code. C’est con un stagiaire, faut le surveiller. C’est le principe, sinon il aurait un CDI.

Mais les fonctionnalités !

Les ORM bien faits n’empêchent pas d’utiliser toutes les fonctionnalités de son système. Et tous permettent d’écrire du SQL à la main si besoin. C’est comme les blocks unsafe de rust: on empêche pas, on isole.

L’idée c’est de garder ça pour le moment où on en a vraiment besoin. SQL est à la base de données ce que l’assembleur est à la machine. On n’écrit pas tout en assembleur de nos jours, ça n’est pas utile.

Root of all evil, tout ça.

Mais on ne change pas de base de données souvent !

L’argument “l’orm supporte plusieurs bases” n’est pas destiné à la migration de données d’un projet existant d’une base de données à une autre.

Pas. Du. Tout.

C’est pas que ça arrive jamais. Ça m’est déjà arrivé 2, 3 de fois.

Mais ce n’est pas le cas courant. Le cas courant c’est la réutilisation du code d’un projet précédent dans un nouveau projet utilisant une base de données différente. C’est la création d’un écosystème de modules qui ne sont pas dépendants de la base de données.

Si vous faites une “app” Django, vous pouvez la publier et elle sera utile pour toutes les bases de données supportées. Et c’est pour ça qu’il y autant d’outils.

Mais on pourrait avoir un modèle central sans ORM !

Oui, mais toutes les formes ne se valent pas.

Par exemple, Doctrine permet d’écrire son modèle dans un fichier YAML, et Hibernate dans un fichier XML.

Au final on écrit son modèle dans un langage moins complet, moins expressif, moins facile à débugger et avec moins de tooling. On perd encore plus en faisant ça qu’en passant de SQL à un ORM, sans autant de gains.

En prime, on peut vouloir de la logique de validation très complexe ou des choses à faire hors validation (signals, génération dynamique de modèle, etc), et là, pouet.

Une alternative, ça serait de se servir d’une lib de pur modèle (ex: l’excellent marshmallow) et de tout dériver de là. Une approche intéressante qui pourrait satisfaire tous les camps, mais que je n’ai jamais vu poussée jusqu’au bout dans aucun framework. Si vous cherchez un projet pour vos week-end :)

Lib VS framework

C’est un peu le vieux débat du découplage VS intégration qu’on retrouve dans la critique des ORM (ou dans vi VS vscode, POO vs fonctionnel, ta femme vs ta mère…).

Et comme d’habitude on retrouve toujours les meilleurs programmeurs du côté de ceux qui veulent le plus de liberté (vive SQL!) parce qu’ils ignorent complètement les problématiques qui vont plus loin que leur fichier de code. Faire fleurir un écosystème, gérer une communauté, favoriser la productivité, facilité l’intégration des membres de ses équipes… Tout ça sont des problématiques moins funs que de faire la requête parfaite avec le tout nouveau champ hyperloglog de PostGres.

Difficile de convaincre des gens qui sont non seulement excellents, mais qui sauront, seuls, être très productifs sans ORM. Surtout quand les gros projets qui atteignent des centaines de millions d’utilisateurs par jour finissent toujours par se séparer de leurs abstractions initiales.

Mais voilà, il ne faut pas perdre de vue que 2 projets sur 3 en informatique, échouent. Quasiment jamais pour des raisons techniques. Généralement la cause est humaine. Et l’ORM est là pour soutenir l’humain en créant un pivot sur lequel il peut compter, quitte à investir plus tard pour s’en passer.

C’est un excellent outil et une très belle réussite de l’informatique moderne. Si on sait l’aborder sans dogmatisme.

]]>
Monter son master node Interzone (ITZ) 21http://sametmax.com/?p=23944http://sebsauvage.net/streisand.me/sametmax/index.php?20171221_135247_Monter_son_master_node_Interzone__ITZ__21Thu, 21 Dec 2017 12:52:47 +0000Acheter et vendre des cryptomonnaies, tout le monde comprend le principe. J’achète un truc, j’attends, je le revends. Si le prix a monté, je gagne du pognon, s’il est descendu, j’en perds.

Mais il existe d’autres formes d’investissement. L’une d’elles est le master node, et on va apprendre à en monter un.

Attention, ça demande de savoir administrer un serveur linux. Le tutoriel n’explique pas bash, apt, ssh ou make et suppose que vous êtes à l’aise avec ces outils. Si ce n’est pas la cas… pas de bol.

C’est quoi déjà ?

Bitcoin n’est plus la seule crypto, il y en a maintenant des centaines, et certaines essayent de se distinguer technologiquement.

Quelques-unes ont le concept de master node, des machines dont les propriétaires ont acheté un certains nombre de coins, et les bloquent. En échange de quoi, le réseau donne à la machine le droit de faire certaines opérations en plus, opérations qui rendent service au réseau (rendre les exchanges anonymes, accélérer les transactions, etc).

Le but des master nodes est double:

  • Avoir toujours plein de wallets répartis dans le monde et avec plein de propriétaires différents. Ça renforce le réseau.
  • Forcer les gens a acheter plein de coins et donc faire monter le cours, faisant gagner du pognon aux créateurs de la monnaie qui en ont généralement préminé une partie.

Mais pour le propriétaire du master node, qu’est-ce qu’on y gagne ?

Et bien tous les jours, une cagnotte est répartie équitablement entre tous les masternodes en récompense de leur service.

Par exemple, j’ai monté la semaine dernière un master node Vivo. Il a couté a l’achat 3200 euros. Tous les jours, il génère 5 vivos, soit actuellement 20 euros. En plus de cela, le vivo a augmenté de prix depuis l’achat, et le master node vaut maintenant 5000 euros si je décide de revendre les coins qui sont bloquées. Mais ça voudrait dire fermer mon master node.

Choisir un master node

Tous les master nodes ont des coûts et une rentabilité différents. Il existe des listing qui permettent de se faire une idée de la question.

Aujourd’hui je vais vous faire un tuto sur le master node Interzone, car il est très peu cher à l’achat: moins de 300 euros. Évidemment, il ne rapporte que 2 euros par jour.

Mais si vous voulez apprendre à faire des master nodes, c’est plus simple que de débloquer 5000 balles pour du vivo. Ou pire, un million pour un node dash :)

Interzone est aussi un wallet très basique, et donc simple à monter.

Acheter les coins

D’abord, il faut acheter les coins. Le nombre de coins à acheter est différent pour chaque type de node. Pour Interzone, c’est 5000 à bloquer, et donc on va en acheter 5001 pour les frais de transaction.

Pour se faire, il faut d’abord acheter une monnaie plus populaire sur une plateforme d’achat. Par exemple, vous pouvez acheter du Bitcoin sur Bitstamp.

Ensuite, faite un virement (withdrawal) vers une plateforme d’échange.

Tout ça se fait en plusieurs étapes.

D’abord, ouvrir des comptes sur ces sites, et faire les putains de vérifications de sécurité. Ouai, si vous vouliez trader anonymement c’est raté. Et parfois c’est long. Très long. Par exemple pour les achats par carte bancaire, Bitstamp m’avait demandé une photo de moi tenant mon passeport. Je sais pas si ils le font toujours, mais c’est over chiant.

Je vous laisse vous occupez de tous ça, on se revoit dans quelques jours.

Ça y est, de retour ?

Ok.

D’une part on va aller sur un exchange voir le cours de l’Interzone pour savoir combien de BTC acheter.

Par exemple à cet instant je vois que je peux acheter un ITZ pour entre 0.000002699 et 0.000007300 BTC. En regardant les cours, je vois que j’ai suffisamment de vendeurs pour avoir 5001 ITZ à 0.000002990 BTC, donc 0.0149529900 BTC. On rajoute les fees de l’exchange (0.0000373824750 BTC) et on prend en compte les fees de transactions de la block chain bitcoin (0.00265914 BTC).

Total: 0.017649512 BTC, soit 281.57 euros sur Bitstamp.

Parfois c’est plus, parfois c’est moins. Ça fluctue beaucoup.

On achète ça. Ça prend encore du temps…

Quand on a tout, on fait le virement sur son autre wallet, celui sur l’exchange.

Depuis l’exchange, on achète enfin son Interzone.

Monter son master node

En théorie on peut faire ça avec un client, mais en pratique ils ne marchent jamais. En plus il faut que ça reste allumé tout le temps et il faut avoir une IP statique.

Donc on va le faire sur son propre serveur linux.

Le plus pratique est d’avoir un serveur à soi qui tourne quelque part, ou de louer un VPS au prix minimal. En effet un master node, ça consomme que dalle en ressource et vous pouvez le mettre sur un raspberry pi si ça vous chante.

Parce que je suis pas maso, je vais expliquer que pour une distro, car il va falloir compiler. On va donc faire ça pour une Ubuntu 16.04.

D’abord on s’assure d’être toujours à l’heure:

sudo apt-get install ntp ntpdate
sudo update-rc.d ntp enable

On installe la tetrachiée de dépendances:

sudo apt-get install build-essential software-properties-common nano libboost-all-dev libzmq3-dev libminiupnpc-dev libssl-dev libevent-dev   libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils libboost-all-dev

Ensuite, on a besoin de downgrader une lib, donc, ppa:

sudo add-apt-repository ppa:bitcoin/bitcoin
sudo apt-get update
sudo apt-get install libdb4.8-dev libdb4.8++-dev

On download les sources:

wget https://github.com/projectinterzone/ITZ/archive/master.zip
unzip master.zip

Et on compile:

cd ITZ-master 
./autogen.sh
./configure
make

Vous pouvez aller boire un coup, pisser, faire la sieste. Ça prend pas mal de RAM, donc si vous serveur en a pas assez, faites les sur un ordi local avec la même version de linux.

Une fois tout ça terminé, le résultat est que dans le dossier ITZ-master/src vous avez deux executable:

  • interzoned (le daemon qui va servir de master node)
  • interzone-cli (le client qui va vous permettre d’envoyer des ordres au master node)

C’est ce qu’on va utiliser. Si vous avez compilé en local, uploadez les n’importe où sur votre serveur.

Maintenant, on se place sur le serveur, dans le dossier qui contient interzoned et interzone-cli, et on va créer un fichier de config.

Pour le fichier de config, il vous faut l’adresse IP du serveur. On peut la choper avec:

$ dig TXT +short o-o.myaddr.l.google.com @ns1.google.com | awk -F'"' '{ print $2}'
xxx.xxx.xxx.xxx

Le port, lui, est toujours 55675 (soyez sur de pas le bloquer).

Puis on choisit un mot de passe pour le client:

$ tr -cd '[:alnum:]' < /dev/urandom | fold -w30 | head -n1
BjHQ2T95Og2VNxsVDQ5qcFBU1eVNHP

On ouvre le fichier:

mkdir .interzone
vi .interzone/interzone.conf

Et on écrit dedans:

bind=:55675
rpcuser=interzone
rpcpassword=BjHQ2T95Og2VNxsVDQ5qcFBU1eVNHP

Puis on lance le daemon:

./interzoned -daemon -reindex

Si vous êtes consciencieux, ajoutez un service qui le démarre quand votre machine boot.

Au premier lancement, il va télécharger toute la block chain, mais ici c’est seulement 140Mo car interzone est tout jeune encore. Donnez-lui 30 minutes pour être tranquille.

Au bout de quelques minutes, votre client pourra déjà se connecter au master node et voir le progrès avec:

$ ./interzone-cli getinfo 
{
...
    "blocks" : 92477,
...
}

Il est temps de loader votre master node avec du pognon ! On se fait une adresse:

./interzoned getnewaddress MN1
1MKDs1yNze7VEr4zWHTKbiV3T3fBTwtxZ4

Et là vous allez sur votre exchange où vous avez acheté vos coins, et vous faite un transfert d’EXACTEMENT 5000 coins sur cette adresse (la votre, pas 1MKDs1yNze7VEr4zWHTKbiV3T3fBTwtxZ4, bande de moules). Pas un sou de moins. Pas un sou de plus.

Vous attendez que les coins arrivent. Ça peut prendre quelques minutes. Vérifiez avec:

./interzone-cli getbalance
5000.00

Si ça dit 5000, c’est bon.

Il est temps de démarrer notre master node.

D’abord, on arrête le daemon:

./interzone-cli stop

Ensuite, on se génère une clé privée pour notre master node:

./interzone-cli masternode genkey
EHLKJHoYfNaeziVMAtLs5678G9Em861r3456xtYh1TEotpY1

Ensuite on rouvre notre fichier de config, et on le met à jour pour contenir ça:

bind=:55675
rpcuser=interzone
rpcpassword=BjHQ2T95Og2VNxsVDQ5qcFBU1eVNHP
masternode=1
masternodeprivkey=EHLKJHoYfNaeziVMAtLs5678G9Em861r3456xtYh1TEotpY1

Ne soyez pas con, n’utilisez pas la clé que je poste dans ce tuto.

On va aussi chiffrer son waller, maintenant qu’on a des sous dessus, pour éviter de se le faire tirer. On génère un nouveau mot de passe, et on encrypt:

$ tr -cd '[:alnum:]' < /dev/urandom | fold -w30 | head -n1
efFMgBGFpVhlQ0j8o8N4TaC5XdASyG
$ ./interzone-cli encryptwallet "efFMgBGFpVhlQ0j8o8N4TaC5XdASyG"

Faites un backup de votre wallet avant et du mot de passe. Si vous perdez ça, vous êtes niqué de chez niqué.

Vous pouvez déverrouiller le wallet avec:

./interzone-cli walletpassphrase efFMgBGFpVhlQ0j8o8N4TaC5XdASyG 120

efFMgBGFpVhlQ0j8o8N4TaC5XdASyG étant à remplacer avec votre mot de passe fraichement généré et 120 est le nombre de secondes pour le garder débloqué.

Il est temps de relancer le daemon:

./interzoned -daemon

Et finalement, le passer en master node:

./interzone-cli masternode start

C’est good.

Vous pouvez vérifier que ça a été accepté par le réseau avec:

./interzone-cli masternodelist | grep PUBLIC_IP

Toutes les 24h, vous pourrez joyeusement contempler le chiffre fourni par ./interzone-cli getbalance qui augmente. Et vous pouvez envoyer vos coins où vous le souhaitez (par exemple pour les revendre) avec un joli:

./interzone-cli walletpassphrase <votre password> 120
./interzone-cli sendtoaddress

Sécurité

Votre master node est ici configuré en mode “hot wallet”, c’est-à-dire que vos coins sont sur le serveur. Il existe une méthode, plus complexe, plus longue, mais plus sure, qui permet de le configurer en “cold wallet”. Vos coins sont alors sur votre machine, et un lien est fait enter votre machine et votre master node.

Si la sécurité vous importe, je vous invite donc à étudier la question.

Renforcer la configuration du firewall aussi est une bonne idée, puisque maintenant vous êtes une cible d’attaque potentielle.

Enfin, n’oubliez pas de vider tout l’historique bash en partant, histoire de pas avoir tous les trucs en clair dedans:

cat /dev/null > ~/.bash_history && history -c && exit

Et backupez comme des porcs aussi.

Profit ?

J’espère pour vous que tout ça va fructifier (et pour moi aussi). Si c’est le cas, vous savez ce qu’il vous reste à faire: envoyez-nous une carte postale de votre ile deserte. Ou des ITZ à 1AChuSLWAHQgmkGa84AHqBRCs1Z1cxHjnU. Ça marche aussi.

Si vous avez tout perdu, sachez que c’est la faute de Max. Je peux vous donner son adresse.

Et pour tous ceux qui n’ont pas la foi de faire tout ça, je pense que je vais monter un service qui permet de cliquer et acheter des masternodes automatiquement.

]]>
Le point sur les crypto-monnaies 36http://sametmax.com/?p=23913http://sebsauvage.net/streisand.me/sametmax/index.php?20171219_113250_Le_point_sur_les_crypto-monnaies_36Tue, 19 Dec 2017 10:32:50 +0000Max est arrivé, il a posté, puis il est reparti.

Miner du Bitcoin Gold n’a pas été rentable du tout, ni pour vous, ni pour la team de GoldenShower. Et NiceHash s’est fait hacké. Mais au moins c’était fun.

Cela dit ce n’était que la partie émergée de l’iceberg, et avec tout le bordel actuel, vous avez peut-être envie d’un petit topo pour remettre tout en contexte.

Il y a 5 ans, je vous parlais du Bitcoin, un projet qui expérimentait avec l’idée de créer une monnaie décentralisée, non dirigée par les banques ou les états.

Le système Bitcoin a introduit les bases d’un système novateur:

  • Tout le monde est égal, et peut créer un compte Bitcoin sans aucun prérequis. C’est ce qu’on appelle le wallet. Les techniques modernes de chiffrement permettent à chaque wallet de s’identifier, et de déclarer des transactions.
  • Personne ne possède ses propres bitcoins, mais chaque personne dans le réseau peut télécharger tout l’historique des transactions depuis la création du Bitcoin. Cette base de données est ce qu’on appelle la blockchain. Ainsi le système sait exactement qui peut dépenser quoi.
  • Chaque personne peut participer à la création de la monnaie. C’est ce qu’on appelle le minage, et en gros on demande à son ordinateur de résoudre un problème mathématique complexe. On obtient la monnaie quand on peut donner la preuve qu’on a résolu le problème. C’est ce qu’on appelle le “proof of work”.

Bitcoin est un peu le prototype de la roue, taillé dans la pierre: révolutionnaire, mais vraiment super lourd.

  • Tout est public. Les wallets sont anonymes, mais toutes les transactions sont en clair. Les premiers marchés noirs (remember the silk road ?) se sont fait tej assez vite.
  • Les transactions irréversibles et la complexité technique pour sécuriser son portefeuille ont amené de nombreuses attaques.
  • La nature de la production du BTC a amené des gens à se regrouper en grosse communauté afin de miner plus facilement, empêchant les individus seuls de participer de manière significative. C’est ce qu’on appelle les pools. De plus, les gros capitaux ont investi dans de grosses fermes d’ordinateurs pour miner en masse. Une grosse partie est en Chine, et ils ont une énorme influence sur le Bitcoin qui n’est donc plus autant décentralisé.
  • La blochain est devenue énorme. Plus de 150Go et ça va continuer à grossir. Héberger un noeud complet sur son téléphone n’est plus faisable. Du coup les gens utilisent des wallets légers, qui font confiance à un service externe. Bitcoin perd encore plus son bénéfice de décentralisation.
  • Les transactions sont lentes. On plafonne à quelques échanges par seconde. Pour le monde entier !
  • Bitcoin a déjà vu deux forks, le Bitcoin Cash et le Bitcoin Gold, à cause de toutes ses limitations.

Malgré ça, de par le nom célèbre et la robustesse technique du système, Bitcoin reste la référence de la cryptomonnaie. En quelque sort “l’or”, la valeur refuge. Amusant quand on connait sa volatilité. Le cours a explosé (plus de 15000 euros), la bourse de Chicago ouvre les vannes de la spéculation officielle et on peut même en acheter avec sa CB de nos jours (ce qui n’était pas le cas au début).

En gros, Bitcoin est légitimé.

Et c’est ironique, car cette légitimation passe par la négation du projet original. Bitcoin n’est plus du tout une monnaie alternative aux mains du peuple, mais un instrument spéculatif de plus.

Les cryptomonnaies actuelles ont une valeur aberrante, sans rien derrière. C’est du vent total.

Alors qu’est-ce qui se passe maintenant ?

Et bien d’abord les cryptomonnaies alternatives ont fleuri. Il y en a des centaines. La plupart sans aucun projet, avec des teams branlantes et l’espoir de “mooner” (que le cours monte jusqu’à la lune).

Certaines cryptos sont très intéressantes néanmoins:

  • Ethereum a montré la voie des smart contrats, et permet de glisser des programmes dans la blockchain que chacun peut exécuter en dépensant des ETH.
  • Dash a popularisé le concept du master node: certains wallets immobilisent du capital (par exemple 1000 dash), et en échange obtiennent la confiance du réseau pour effectuer des tâches (accélérer les transactions, anonymiser les échanges, etc) contre des prélèvements (fee) qui s’ajoutent à leur pécule.
  • Monero est devenu célèbre parmi les créateurs de virus (et de mineurs JavaScript) car il permet de miner sur le CPU et est anonyme.
  • VTC a promu l’idée d’être ASIC resistant, c’est-à-dire de rendre difficile d’acheter du matériel spécialisé pour le minage pour créer une grosse ferme.
  • Ripple est préminé (toutes les pieces existent déjà) et soutenu par les banques et les GAFAS.
  • Electroneum (Max l’appelle “electroscam”) veut créer du ‘fake mining’ et permettent aux gosses de la cour de récré de générer du cash depuis leur téléphone.
  • duniter mise sur l’aspect social: mineur est un status qu’il faut obtenir et maintenir en convainquant 5 humains de voter pour soi, tous les 2 ans.

Du coup il y a une vraie exploration technique, et ça va donner des choses intéressantes. Même les états s’y mettent.

Néanmoins soyons honnête, l’utilisateur moyen s’en bat les couilles (oui les couilles, l’utilisateur moyen n’est clairement pas une utilisatrice pour le moment) et veut juste avoir de l’argent qui rentre en espérant que plus d’argent sort.

Pour répondre à cette demande, de nombreuses places de marché ont vu le jour. On peut échanger des trucs obscurs tels que le Wyvern, l’ObamaCare, le Satancoin, le CheeseCoin, le Marijuanacoin, le GirlsToken ou le CharlieChaplinCoin.

J’aimerais vraiment vous dire que je plaisante. Mais non.

Et puis tout ça va finir en bulle. Et ça va péter. Et des tas de gens vont tout perdre. Dans 6 mois ? Dans 2 ans ? Dans 10 ans. Aucune idée. Personne ne sait. On sait juste que ça va arriver. On est pas dupe, ces monnaies de singe ne valent rien: pas d’atout technique, pas de projet social, pas de team de ouf, pas de gros backers… Rien pour compenser l’absence de garantie par l’Etat qu’une vraie monnaie a.

Le petit secret, c’est que la plupart des ces cryptos sont des forks des projets principaux (Btc, eth, dash, etc) avec juste un logo différent. Ou pire, juste un smart contract sur ETH et même pas de blockchain, quand on est vraiment paresseux et doué en com, pourquoi se faire chier.

Une minorité, mais bien réelle, deviendront ancrées dans la société après la crise. Après tout la possibilité de stocker une valeur et de l’échanger sans contrôle et rapidement est trop intéressante. Le jeu du chat et de la souris avec les institutions va continuer. Il va y avoir législation. Et au bout d’un temps, acceptation sous certaines conditions.

De plus, les innovations techniques autour de la blockchain vont produire des choses vraiment utiles, et on les utilisera.

Mais la plupart des monnaies actuelles vont disparaitre au son des pleurs. Tout le monde le sait, mais tout le monde s’en fout. On espère tous que ce sera le voisin, et que nous nous on sera riche. Les gens s’identifient beaucoup plus souvent au début du “loup de wall street” qu’à la fin de “the big short”.

Déjà que je regrette la centaine de BTC que j’ai vendu avant que ça monte, alors j’imagine le sentiment quand tout s’écroule après l’achat…

Et comment je fais du pognon moi alors ?

Ben si je savais comment faire de la thune a coup sûr, je le ferais et je ne le vous le dirais pas, bande de guignols.

Mais avec Max, on essaye de profiter de la situation.

Déjà, pour le moment, acheter les cryptos les plus célèbres (Bitcoin, Ethereum, Monero, Dash, Litecoin…), a été une stratégie gagnante puisque ça monte énormément.

Ensuite il y les investissements alternatifs. Par exemple notre bande de potes investis dans des master nodes (particulièrement le Vivo, le CRC, l’interzone, etc). Comme le dit Max “20k en assurance vie m’a rapporté 200 euros en 5 ans. Sur un masternode, 7k me rapporte 40euros par jour”. Évidement…

Enfin il y a la stratégie “pendant la ruée vers l’or, vends des pelles”.

Max essaye de mettre en place un système de bot facile à scripter pour spéculer sur toutes les plateformes de manière uniformisée, et les louer.

Moi je monte un système pour gérer les master nodes des gens en échange d’une part des gains. C’est que c’est chiant à monter et maintenir ces petites bestioles.

Si vous comptez mettre du pognon là dedans, n’oubliez pas de ne jouer dans ce grand casino bordélique et immoral que ce que vous pouvez perdre.

Mais la vérité ?

En tant que dev, on s’était pas autant marré depuis les débuts du Web, quand on bricolait des services pourris en PHP pour se faire une place.

]]>
GoldenShower sera coupé, faute de miners 11http://sametmax.com/?p=23894http://sebsauvage.net/streisand.me/sametmax/index.php?20171207_154353_GoldenShower_sera_coupe__faute_de_miners_11Thu, 07 Dec 2017 14:43:53 +0000Slt les gens,

 

On va couper le pool Goldenshower, car ça coûte en hébergement et qu’il n’y a plus de miners pour espérer choper un block. C’est la loi du “transvasationnagement” des liquides. Si vous voulez continuer l’aventure essayez les pool btgpool ou suprnova. Je vous encourage d’ailleurs à vous intéresser aux crypto-monnaies dans l’ensemble, ça fait pas de mal ^^

 

On remercie tous ceux qui ont participé à l’aventure en espérant que vous aurez appris au moins autant que nous. Pour info on a rien gagné, les coms de la pool ayant payé l’hébergement du serveur et quelques NiceHash (qui s’est fait hacker au passage…)

Possible qu’on monte un autre pool mais l’expérience nous a appris que c’est pas facile sans une forte concentration de miners.

Je pense vous faire un tuto sur les Masternodes bientôt pour voir les cryptos sous un autre angle.

Passez de bonnes fêtes!

Max,

 

]]>
NiceHash – Pump up your power, à quoi ça sert et comment ça marche ? 8http://sametmax.com/?p=23832http://sebsauvage.net/streisand.me/sametmax/index.php?20171114_120559_NiceHash_____Pump_up_your_power__a_quoi___a_sert_et_comment___a_marche___8Tue, 14 Nov 2017 11:05:59 +0000Alors c’est quoi ce « gentil hachis » dont vous parlez sur Telegram, c’est un truc de cuisine ?

« Nicehash » c’est un service de location de puissance de « hash », en gros avoir le plaisir de posséder l’équivalent de 25000 cartes graphiques pendant un moment pour miner de la cryptomonnaie.
C’est un peu la Smartbox (vous savez celle où on peut faire 200 bornes pour conduire un R8 pendant ¼ d’heure) de la crypto, mais sans sortir de chez soi, moins de plaisir, mais plus de rendement.

D’un côté Nicehash propose aux mineurs (ceux qui ont des machines qui chauffent leur maison toute la journée) de mettre ces machines en location, et d’un autre on peut participier à des enchères pour louer la puissance (additionnée) de plein de mineurs d’un coup pour devenir un moment un gros mineur bien velu.
On voit bien sur ce graphe ce que ça donne là quand un gars s’est un peu énervé pendant ½ heure

un ptit coup de nicehash ?
Sur le chan de Goldenshower.io on a l’histoire d’un gars qui a réussi à lancer ¼ d’heure de nNicehash au tout départ du BitcoinGold et en a ramassé une bonne grosse poignée à ce moment là, mais sinon de notre expérience avec le service, il est possible de faire un 10-25% de bénéfice (on achète du hashpower en BTC, on mine une monnaie, qu’on revend ensuite, et ça fait 10-25% de BTC en plus pour recommencer ).

Allons-y “gayment”! Rendez-vous sur https://www.nicehash.com/

 

On créer un compte, on valide tout ça et on passe aux choses sérieuses. Le tuto suivant décrit la méthode pour lancer un NiceHash sur la crypto Bitcoin Gold, qui est basé sur l’algo Equihash, pour d’autres cryptos il faudra choisir l’algo approprié mais pour le reste il n’y a rien à changer.

 

  1. On va dans le marketplace (place de marché)
    On sélectionne  market place
  2. On sélectionne l’algo approprié à la crypto que l’on va miner, ici pour BTG (Bitcoin Gold) on sélectionne Equihash.
    Equihash est l'algo que l'on va utiliser pour miner du BTG (Bitcoin Gold)
  3. La partie la plus importante, Il va falloir envoyer notre puissance de calcul louée sur un pool, ici sur goldenshower.io. Pourquoi celui-là et pas un autre ?
    Parce que c’est celui de Sam&Max (et des potes) , qu’on est les plus beaux et qu’on a besoin de tunes pour aller aux putes régulièrement et vous mijoter de jolis articles tous mignons.
    PArtie la plus important, setup du pool Pool Name: Golden Show (le nom de votre pool, mettez ce que vous voulez, c’est pour le reconnaître par la suite dans la liste.)
    Stratum hostname ou IP: btg.goldenshow.io
    port: 3870
    User: là il faut mettre votre addresse de Wallet BTG que vous aurez créé en suivant notre tuto précédent ici

  4. On place son Order (et oui comme à la bourse) qui va consister à acheter de la puissance de Hash à un prix fixé par vous.
    ATTENTION! Avant de placer un order il faut créditer son compte Nicehash avec des BTC (Bitcoins), car tout se paie en BTC.
    Sur la figure suivante j’ai placé un order à 0.01258 BTC.

    PRICE: par défaut un prix est suggéré , il faut regarder dans la liste des ordres à côté que vous êtes dans les bonnes valeurs, un prix trop bas et votre ordre ne passera jamais.
    LIMIT: sert à limiter la puissance de calcul envoyée dans le temps, pour les premiers essais il vaut mieux mettre une faible valeur (attention si vous mettez 0 nicehash va envoyer toute la puissance d’un coup) en cas de mauvaise configuration du pool, ça serait con d’envoyer toute la puissance sur un truc qui mine pas :)
    AMOUNT: le budget que vous voulez allouer, là aussi au départ une petite somme pour tester l’artillerie, une fois que vous êtes sûr que ça marche, vous pouvez placez un ordre plus important.

    on achète des gigoWatts Doc !!

  5. Et C’est tout ! La puissance de calcul louée sur Nicehash va être transmise au pool goldenshow.io et c’est comme si vous aviez une ferme de GPU qui mine. Elle est pas belle la vie ?
    6_MiningStart

Si vous voulez racheter de la puissance de calcul vous éditez votre order dans la liste et vous changez les valeurs appropriées.
8_If_Need_Change_Price_or_refill
Vous l’aurez compris, Nicehash permet d’avoir l’équivalent d’une immense ferme de GPUs sans les inconvenients. Pratique pour miner à la sortie d’une crypto sans avoir à setup grand chose et pour se rendre compte immédiatement de la rentabilité de minage de la monnaie concernée.
A savoir qu’en général quand une monnaie sort la difficulté est faible donc ça vaut le coup de se lancer dessus et le Nicehash est la solution la plus rapide.

Rendez-vous sur goldenshow.io, votre pool préféré pour miner (pas exclu qu’on rajoute d’autres cryptos soon ^^ )

Les précédents Tutos:

http://sametmax.com/de-la-thune-avec-un-mining-pool-de-btg/

http://sametmax.com/tutorial-pour-miner-du-bitcoin-gold-btg/

]]>
Tutorial pour Miner du Bitcoin GOLD – BTG 49http://sametmax.com/?p=23823http://sebsauvage.net/streisand.me/sametmax/index.php?20171113_123822_Tutorial_pour_Miner_du_Bitcoin_GOLD_____BTG_49Mon, 13 Nov 2017 11:38:22 +0000ça y est le pool est open, tout devrait marcher !

Comment on utilise un mining pool :

Dans peu de temps (ou depuis peu de temps c’est selon), le mainnet (blockchain de prod) de BTG est en ligne, du coup, yahoo on peut commencer à miner. Avec des potes on s’est marrer à monter un pool de minage sur lequel vous pourrez vous connecter. http://goldenshower.io, avec un nom pareil on s’es fait ban du listing du site officiel :) du coup on a pris goldenshow.io mais les 2 ndds marchent pareil.

 

Une bonne douche dorée de BTC ^^

Une bonne douche dorée de BTC ^^

Pour ceux qui ont loupé la 1ère partie c’est ici.

 

Petit tuto rapide, mais j’espère clair :

1) Créer un wallet BTG

https://btgwallet.online/ ou là https://mybtgwallet.com/
Notez bien dans un endroit sécurisé tout ce qu’ils disent de noter (si si c’est important, sinon tous ces beaux Bitcoin Golds seront perdus à jamais). Vous obtiendrez votre adresse que nous nommerons bitcoin-gold-address dans la suite.

2) Installer un logiciel de minage, selon votre système d’exploitation et la marque de votre carte graphique :

Sur ces deux repos se trouvent les versions Linux et Windos (pas encore de miner pour OSX)

Si vous avez une carte graphique NVIDIA:
EWBF v0.3.4b (NVIDIA) –  https://github.com/poolgold/ewbf-miner-btg-edition/releases

Si vous avez une carte graphique AMD:
ClaymoreZcash v12.6 (AMD) – https://github.com/poolgold/ClaymoreBTGMiner/releases

Il est possible que votre antivirus se plaigne, mais ces liens sont légitimes et utilisés par plein plein de gens sans problème.
Ces logiciels contiennent des fonctions cryptographiques (ce qui fait hurler les antivirus) parce que justement c’est leur boulot en tant que mineurs.

3) Configurer le mineur avant de le lancer :

Sous Windows:
* EWBF (les carte nvidia) : miner –server btg.goldenshow.io –user bitcoin-gold-address.worker –pass x –port 3857

* Claymore (les cartes AMD):
Editez le fichier start.bat et mettez ça :

set GPU_FORCE_64BIT_PTR=1
set GPU_MAX_HEAP_SIZE=100
set GPU_USE_SYNC_OBJECTS=1
set GPU_MAX_ALLOC_PERCENT=100
set GPU_SINGLE_ALLOC_PERCENT=100

Editer le fichier config.txt

-zpool stratum+tcp://btg.goldenshow.io:3857
-zwal bitcoin-gold-address.worker
-zpsw x
-allpools 1

et lancer ZecMiner64.exe

4) Pour les plus pointus d’entre vous, il y a quelques variantes :

ports :

3857 = PC standard à quelques GPU
3860 = petite ferme (10-15 GPU ou plus)
3870 = nicehash ou mega fermes ( + 150 gpus)

Pour linux c’est la même chose mais en créant un fichier bash à la place du .bat.

Si vous rencontrez des problèmes (et vous allez en avoir) on a un chan Telegram.

Happy mining !

]]>
Le miner pool BTG est ready: voici comment faire 9http://sametmax.com/?p=23817http://sebsauvage.net/streisand.me/sametmax/index.php?20171113_010352_Le_miner_pool_BTG_est_ready__voici_comment_faire_9Mon, 13 Nov 2017 00:03:52 +0000ATTENTION !!! Article posté par erreur, BTCGOLD ayant pris un low kick frontal par une DDoS de gniaks, ils ont tout niqué. C’est en train de sync le mainnet, on en est à 50%, je pense que ce sera fini demain matin. Je vous posterai un article/tuto quand ils seront up.

Max s’est bien marré et pour miner du bitcoin gold, nous a pondu le site http://goldenshower.io/.

Qui s’est fait insta banné des listing et donc on a du mettre un alias http://goldenshow.io. On garde l’autre pour la postérité :)

Toutes les instructions sont dessus.

Mais en résumé, vous créez un wallet sur un site type https://btgwallet.online/.

Ca donne un truc comme ça:

Non c'est pas le mien bandes de bananes

Non c’est pas le mien bandes de bananes

Sauvegardez tout ça.

Installez le miner pour votre os et carte graphique tel que listé sur http://goldenshower.io/.

Les windowsiens peuvent avoir un probleme de dll. Dans ce cas y a un truc de plus à installer:

https://superuser.com/questions/1163409/msvcp120-dll-and-msvcr120-dll-are-missing

Si vous avez un doute, essayez en premier https://www.microsoft.com/en-us/download/confirmation.aspx?id=40784

Ensuite, vous votre miner depuis le terminal et on attend :)

]]>
De la thune avec un « Mining Pool » de BTG 25http://sametmax.com/?p=23805http://sebsauvage.net/streisand.me/sametmax/index.php?20171112_082947_De_la_thune_avec_un____Mining_Pool____de_BTG_25Sun, 12 Nov 2017 07:29:47 +0000ça fait quand même 5 ans qu'on vous parle du Bitcoin sur le blog... Aujourd'hui le Bitcoin est à quelques milliers d'euros, et des centaines de monnaies concurrentes sont arrivées sur le marché. Les opportunités pour faire de l'argent (et en perdre of course) sont décuplées, et Max, ainsi que deux potes à nous, se sont lancés dans un petit montage sympa. Potentiellement, si vous avez une bonne carte graphique, y a moyen de se faire du pognon sans trop d'effort. Plus on a de lecteurs qui participent, plus la thune arrive. Je leur laisse la parole dans un article invité de Tic, où ils vous expliqueront ça mieux que moi ]]>C’est pas parce que vous entendez plus trop parler de Max qu’il est mort. En ce moment, il est à fond sur les cryptomonnaies. Mais si, rappelez-vous, ça fait quand même 5 ans qu’on vous parle du Bitcoin sur le blog… Aujourd’hui le Bitcoin est à quelques milliers d’euros, et des centaines de monnaies concurrentes sont arrivées sur le marché.

Les opportunités pour faire de l’argent (et en perdre of course) sont décuplées, et Max, ainsi que deux potes à nous, se sont lancés dans un petit montage sympa. Potentiellement, si vous avez une bonne carte graphique, y a moyen de se faire du pognon sans trop d’effort. Plus on a de lecteurs qui participent, plus la thune arrive.

Je leur laisse la parole dans un article invité de Tic, où ils vous expliqueront ça mieux que moi


Avec une bande de zozos, on est en train de monter un mining pool sur le Bitcoin Gold. Rien que cette phrase je me demande comment j’ai pu l’écrire.

Je ne suis pas du genre à me baigner dans du charbon, donc je vais préciser les choses :

Certaines cryptomonnaies (Bitcoin, Ether, Monero, mon préféré Electroneum …) reposent sur une blockchain dont la sécurisation (ie gravure des transactions et informations dans le marbre de la blockchain, vérification qu’il n’y a pas de fraude) est réalisée par une armée de machines capable de réaliser des tonnes d’opérations mathématiques : les mineurs.

Pour valider un block de la chaine chaque mineur essaye des foultitudes de combinaisons mathématiques liées à ce block, jusqu’à ce qu’un trouve la bonne combinaison et Bingo il touche la cagnotte, le salaire (versé dans la cryptomonnaie associée) lié à la validation de ce block et ainsi de suite, jusqu’à presque l’infini.

Du coup, soit les mineurs travaillent tout seuls dans leur coin pour choper le gros lot, soit ils s’associent dans un « pool » et mettent leur puissance (et leur chance, car il s’agit bien de chance) en commun pour gagner plus souvent une plus petite partie de la mise.

Un peu comme jouer au loto, soit on fait sa grille tout seul dans son coin pour gagner en moyenne 2 millions avec une probabilité de 1/19 Millions, soit on a 1 000 « amis » avec qui on s’associe pour gagner en moyenne 2000 euros avec une probabilité de 1/19000. On gagne beaucoup moins, mais on a beaucoup plus de chance (au sens probabiliste) que ça arrive au moins dans une vie.

Sauf que pour miner, pas besoin d’acheter un ticket. Il suffit d’avoir une carte graphique sur son ordi.

Et avec un pool, on a un serveur sur lequel chaque mineur se connecte pour lui demander du travail, sa feuille de route au niveau calcul pour les secondes à venir. Chacun fait ses calculs aussi vite qu’il peut et renvoie ses résultats, et si un des mineurs du pool trouve la combinaison gagnante, le pool redistribue les gains selon la quantité de travail (pour la plupart dans le vent, mais c’est le jeu qui veut ça) fournie par chacun. Par chacun, on parle d’un PC (presque) de base à une ferme de minage comprenant plusieurs dizaines (ou centaines) de cartes graphiques.

Sinon j’ai parlé de BTG en titre, c’est le Bitcoin Gold (il y a le silver et surement un jour le copper à venir, mais on va rester sur le Gold). Le BTG c’est une nouvelle cryptomonnaie qui sort officiellement le 12 Novembre à 19h UTC. Donc ce soir. Pour faire court et simple (et pas trop m’embrouiller), le BTG est basé sur la blockchain du BTC (The Bitcoin), c’est un « fork » qui veut redonner le pouvoir au peuple dans la mesure où la sécurisation de la chaine Bitcoin originale est devenue tellement difficile que seule une poignée de gros acteurs basés dans l’Empire du milieu (bref des chinois) détient la quasi-totalité de la puissance. Pour la sécurisation décentralisée de la chose, on repassera. Le bitcoin gold tend à redonner la voix au peuple en proposant une chaine sécurisable par des cartes graphiques et seulement des cartes graphiques, du coup la démocratisation est plus plausible, car il suffit de 1000 PC de gamers disséminés n’importe où pour égaler (et contrebalancer) la puissance d’une ferme entière cachée au fin fond de l’Oural ou de la Mongolie.

Du coup voilà, on est en train de monter un mining pool de BTG.


Maintenant la partie fun.

Quand une nouvelle cryptomonnaie arrive, le début du minage est plus facile. Ce soir, Max et Tic & Tac vont donc ouvrir leur mining pool, et on va poster un tuto sur le blog pour que vous puissiez vous connecter dessus.

Afin qu’on fasse de la thune tous ensemble, dans la joie et la bonne humeur.

]]>
Protégé jusqu’à la mort 14http://sametmax.com/?p=23755http://sebsauvage.net/streisand.me/sametmax/index.php?20171102_072835_Protege_jusqu___a_la_mort_14Thu, 02 Nov 2017 06:28:35 +0000Ce matin là, comme dans toutes les démos importantes avec un client, rien ne marchait. D’abord la multiprise, puis la prise Ethernet physique, puis la connexion elle-même. Pour faire bonne mesure, j’avais moi aussi un bug dans le code que je n’ai pu résoudre qu’en changeant de bâtiment (ne cherchez pas…).

Un moment merveilleux de communion avec tous les dev du monde qui ont connu cette expérience spirituelle de destruction de moral et de crédibilité.

Après quelques blagues et une utilisation de la partie du service qui marchait qui m’ont permis de garder la face, un nouveau problème fit son apparition.

Un fichier .odt que je générais était corrompu au téléchargement.

God left

And he’s right

Pourtant, ça marchait, j’en étais certain.

Aucune erreur. Rien. Tout était nickel de bout en bout. Sur ma machine, tout va bien. Sur les leurs, plantage direct de Libre Office.

Je change de navigateur sur mon laptop ou leurs tours. Queud.

Je change d’OS. La même.

Avec CURL ? Zob.

Et puis je note un truc étrange : la taille du fichier n’est pas la même sur leur machine. Elle change à chaque putain de téléchargement.

Je reste un instant interloqué. Et par “un instant interloqué” j’entends 2h surcaféine à trafiquer sur 3 machines différentes toutes les hypothèses tordues possibles, frénétiquement, et la bave aux lèvres.

Quand soudain l’idée me vint. La grâce divine.

Jesus saves

Jesus saves. For later.

Je désactive leur antivirus.

Miracle, ça marche.

Karspersky protégeait leurs machines jusqu’à la mort.

Je ne sais pas ce qui se passait dans sa petite tête, mais il lobotomisait de quelques Ko tous les documents, en mode frappe préventive américaine. Peu importe, leur admin n’aurait de toute façon pas été capable de corriger le problème.

La solution est de se passer des forces de l’ordre et faire justice soit même : tout foutre en SSL pour que le petit salopiot arrête de mettre son nez dans mes paquets. Ils sont sur un intranet. Avec un VPN. Mais fuck, ils seront bien protégés.

Something queer this way come

Also, openssl -days 10000000

]]>
pipenv, solution moderne pour remplacer pip et virtualenv 17http://sametmax.com/?p=23691http://sebsauvage.net/streisand.me/sametmax/index.php?20171008_174416_pipenv__solution_moderne_pour_remplacer_pip_et_virtualenv_17Sun, 08 Oct 2017 15:44:16 +0000pipenv sous le nez, et j'ai donc redonné sa chance au produit. Surprise, l'outil est maintenant très stable (plus de 2000 commits !) et mes propositions avaient même été intégrées. ]]>Kenneth Reitz, l’auteur de requests, tente régulièrement de nous refaire le coup du projet star. Ca n’a malheureusement pas très bien marché, et beaucoup de ses projets comme maya, records, crayon, tablib ou awesome n’ont pas vraiment connu de succès.

Entre alors pipenv, que j’ai testé il y a presque un an, et qui au départ montrait un beau potentiel, mais n’était pas encore très utilisable. J’ai fait quelques suggestions d’amélioration, comme permettre de choisir précisément la version de Python, et je me suis fait envoyé bouler. J’ai donc laissé l’auteur s’enterrer dans sa recherche de gloire passée.

Le hasard de reddit m’a remis pipenv sous le nez, et j’ai donc redonné sa chance au produit. Surprise, l’outil est maintenant très stable (plus de 2000 commits !) et mes propositions avaient même été intégrées.

Après ces 3 paragraphes vous vous demandez sans doute quand est-ce que je vais rentrer dans le vif du sujet, donc:

pipenv reprend les idées de pip, virtualenv, pew et même quelques trucs de npm, yarn, cargo, et essaye d’appliquer tout ça à Python. L’article suppose que vous savez ce que sont ces mots barbares, donc suivez les liens si ce n’est pas le cas.

pipenv permet donc d’installer des packages Python, d’isoler cette installation et de la rendre reproductible. Mais sans effort.

En effet, contrairement à la concurrence:

  • La gestion du virtualenv est automatique et transparente
  • Les paquets installés sont sauvegardés dans des fichiers de config, encore une fois de manière automatique et transparente.
  • Les fichiers de config distinguent les dépendances de prod et de dev, et incluent les versions des sous-dépendances.

Installer pipenv

Contrairement à pip et virtualenv, pipenv n’est pas fourni avec une installation standard de Python, bien que l’outil soit maintenant recommandé par la doc officielle. Il va donc falloir l’installer. Or pipenv se base sur une version récente de pip, donc il faut d’abord être sûr d’avoir pip à jour.

Du coup:

# mise à jour de pip, mais juste au niveau utilisateur pour 
# pas casser le  system
python -m pip install pip --upgrade --user

Puis:

# installation de pipenv
python -m pip install pipenv --user

A moins d’être sous une Debian like type Ubuntu (qui demande un apt install de python-pip avant), tout le monde a pip installé avec une version moderne de Python.

Voilà, vous devriez avoir la commande pipenv disponible, ou pour ceux qui ont un système mal configuré, python -m pipenv.

Usage

Dans le dossier de votre projet:

pipenv install nom_du_package

C’est tout.

Si un virtualenv n’existe pas il sera créé. Sinon il sera utilisé. Les fichiers de configs sont gérés automatiquement, il n’y a rien à faire.

Si vous voulez lancer une commande dans le virtualenv:

pipenv run commande

Exemple:

pipenv run python

Va lancer le Python de votre virtualenv.

Si vous voulez que toutes les commandes soient dans le virtualenv:

pipenv shell

Et vous êtes dans un nouveau shell, dans le virtualenv. Ainsi:

python

Lancera celui de votre virtualenv.

On sort du shell avec Ctrl + D.

Vous pouvez arrêtez de lire l’article ici, c’est l’essentiel de ce qu’il y a à savoir.

Astuces

Si vous lancez pour la première fois dans un dossier pipenv avec:

pipenv --python x.x

Le virtualenv sera créé avec la version de Python x.x, pourvu qu’elle existe sur votre système. Setter la variable d’env PIPENV_DEFAULT_PYTHON_VERSION a le même effet.

Installer un package avec pipenv install --dev le marque comme dépendance de développement uniquement, et permet une installation séparée.

Vous pouvez aussi obtenir quelques infos utiles comme:

  • pipenv --venv: ou est le dossier du virtualenv
  • pipenv graph: un graph de toutes vos dépendances
  • pipenv --py: chemin vers le Python en cours.

Enfin pipenv utilise pew, donc la magie de pew reste dispo, y compris la gestion de projets :)

Usage avancé

Si vous créez un fichier .env dans le dossier de votre projet tels que:

FOO=1
BAR=wololo

pipenv exécutera toutes ses commandes (y compris shell), avec FOO et BAR comme variables d’environnement.

La commande:

pipenv lock

Va créer un lock file. Ce fichier contient toutes les dépendances, et recursivement, les dépendances des dépendances, installées, avec leurs versions. On peut réutiliser ce fichier en prod pour installer une exacte copie de son setup local avec pipenv install. Sans ce fichier, pipenv install se comportera comme pip install.

Il y a plein d’autres trucs mais on va en rester là.

]]>
Regrouper ses fichiers de settings avec stow 15http://sametmax.com/?p=23681http://sebsauvage.net/streisand.me/sametmax/index.php?20171006_102403_Regrouper_ses_fichiers_de_settings_avec_stow_15Fri, 06 Oct 2017 08:24:03 +0000.machins. Par exemple le .bashrc pour la config du bash, le .mozilla qui contient toutes vos données Firefox, le .ssh avec toutes vos clés privées, le .local/share/virtualenvs avec les envs virtuels Python créés par pew ou .config/sublime-text-3 pour la configuration de Sublime text, etc.]]>Sous Linux, le dossier utilisateur est blindé de fichiers de configuration. Les fameux .machins. Par exemple le .bashrc pour la config du bash, le .mozilla qui contient toutes vos données Firefox, le .ssh avec toutes vos clés privées, le .local/share/virtualenvs avec les envs virtuels Python créés par pew ou .config/sublime-text-3 pour la configuration de Sublime text, etc.

Au final, voici tous les fichiers de conf qui sont importants pour moi de près ou de loin:

├── .autoenv
├── .bashrc
├── .config
│   ├── autostart
│   ├── Code
│   ├── copyq
│   ├── fish
│   ├── gtg
│   ├── liferea
│   ├── pulse
│   ├── stremio
│   ├── sublime-text-3
│   ├── transmission
│   ├── user-dirs.dirs
│   ├── user-dirs.locale
│   ├── variety
│   ├── VeraCrypt
│   ├── Zeal
│   └── zim
├── .django-completion.bash
├── .editorconfig
├── .git-aware-prompt
├── .git-completion.bash
├── .gitconfig
├── .gitignore
├── .git-prompt.sh
├── .git.scmbrc
├── .jupyter
├── .lastpass
├── .liferea_1.8
├── .local
│   └── share
        ├── gtg
        ├── keyrings
        ├── liferea
        ├── omf
        ├── TowerFall
        ├── virtualenvs
        └── Zeal
├── .mozilla
├── .netrc
├── .oh-my-zsh
├── .openambit
├── .pypirc
├── .scmbrc
├── .scm_breeze
├── .sshplus
├── .vscode
│   └── extensions
└── .zshrc

Quand on bidouille, on les change souvent. On les backup aussi, pour pouvoir les porter d’un laptop à un autre, les synchroniser, les uploader sur un serveur ou les récup lors d’une réinstallation. Parce que quand on a tuné ses terminaux et éditeurs aux petits oignons, on a pas envie de recommencer à poil.

Pour bien faciliter les choses, ils sont éparpillés un peu partout, dans des sous-dossiers différents.

Et je sais pas quel vil individu a suggéré une fois que faire une partition séparée pour /home était la solution de Skippy à tous les soucis, mais perso, ça me cause plus de bugs qu’autre chose quand on change de versions d’OS.

Bref, laissez tomber vos vieilles croyances issues de charlatans de sectes. Moi, j’ai vu la lumière (lien de don bitcoin en bas à droite de la page), et elle s’appelle GNU stow.

Stow est un vieil utilitaire (donc sagesse millénaire des anciens, vous pouvez avoir confiance, prenez ce cristal aussi il est en promo), qui est grosso merdo un ln -s récursive. C’est-à-dire que ça fait des symlinks des fichiers et des dossiers que vous lui passez.

On peut l’utiliser pour plein de choses, mais l’usage sacré implique le sacrifice d’une vierge à Max, puis de déplacer tous les fichiers de settings qu’on souhaite gérer dans un seul dossier.

Par exemple, moi j’ai:

/home/user/church/settings/

    ├── .autoenv
    ├── .bashrc
    ├── .config
    │   ├── autostart
    │   ├── Code
    │   ├── copyq
    │   ├── fish
    │   ├── gtg
    ...

Au lieu de les avoir éparpillées partout, toutes les brebis sont maintenant regroupées dans une seule église.

Il est très important de garder l’organisation des dossiers et des sous-dossiers d’origine. Ici vous voyez que j’ai le dossier Code, qui est le dossier de settings de VSCode. Mais il est DANS un dossier .config, car avant mon regroupement il était dans /home/user/.config/.

En revanche, il n’est pas du tout nécessaire que .config contienne tous les dossiers qu’il avait précédemment. Seuls ceux qui vous intéressent. Le reste peut rester à sa place initiale, dans le /home/user/.config/.

Donc je résume:

  • Listez les fichiers et dossiers de settings qui vous intéressent.
  • Déplacez les tous dans un dossier commun en gardant une arborescence similaire.
  • Laissez les fichiers qui ne vous intéressent pas là où ils sont.
  • Priez (une bonne pratique avant toute opération informatique).

Arrive le messie, Stow.

D’abord, il faut l’installer, mais comme c’est un outil vénérable, il est dans les dépôts. Sous Ubuntu, le psaume “apt install stow” fera l’affaire.

Ensuite, on prêche. Je me perds dans mes propres paraboles, mais les voies du seigneur sont impénétrables, contrairement à celles d’Abella Anderson. Bref on demande à stow de traiter récursivement tout le contenu du dossier settings qui est dans /home/user/church afin de le linker vers /home/user/:

stow -d /home/user/church -t /home/user/ settings

Stow va prendre récursivement tous les dossiers qui sont dans /home/user/church/settings, et les comparer à ceux dans /home/user. Si ils existent, il va ne rien faire, mais si ils n’existent pas, il va créer un lien vers chacun de ceux manquants. Pour les fichiers, si ils n’existent pas, il va créer un lien, sinon il va vous afficher une erreur, afin de ne pas écraser quelque chose d’important et vous signalez qu’il y un souci.

Le but de tout ça ?

Pour votre système et tous vos logiciels, ça ne change rien. Ils vont tomber sur les liens et avoir l’impression que tous les fichiers de configs sont à leur place et vont continuer à fonctionner dans la joie et le gospel.

Et pour vous, ben vous avez un seul endroit où tous les fichiers importants sont regroupés. Plus besoin de les chercher. Facile à backuper et à restaurer. On peut même tout foutre sous Git.

Loué soit le sauveur.

Vive moi.

]]>
Jouer l’asticot sous les talons-aiguille, nouvel eldorado érotique 2http://sametmax.com/?p=23629http://sebsauvage.net/streisand.me/sametmax/index.php?20170917_160909_Jouer_l___asticot_sous_les_talons-aiguille__nouvel_eldorado_erotique_2Sun, 17 Sep 2017 14:09:09 +0000Allongé de tout votre long par terre, encordé, saucissonné, enveloppé dans un drap ou du papier film alimentaire, vous allez découvrir que jouer le vers de terre ou l’asticot, ça fait autant de bien que de se l’astiquer. "ErotiQ LombriQ", un jeu à pratiquer bien sûr sous les ordres de sa chère et tendre. Entre documentaire animalier et art ménagé. ]]>Ceci est un post invité de Emma posté sous licence creative common 3.0 unported.

Préambule

Allongé de tout votre long par terre, encordé, saucissonné, enveloppé dans un drap ou du papier film alimentaire, vous allez découvrir que jouer le vers de terre ou l’asticot, ça fait autant de bien que de se l’astiquer. “ErotiQ LombriQ”, un jeu à pratiquer bien sûr sous les ordres de sa chère et tendre. Entre documentaire animalier et art ménagé.

Avant toute chose : nous sommes tous d’accord pour admettre que le plaisir de l’humiliation fait désormais parti du lifestyle de l’époque. A l’heure des déclarations vexatoires de Trump et des nouilles dans le slip de Hanouna, le sm est devenu un truc de Bisounours dans la mesure où là, tout est consenti.

Quel équipement ?

Pas de panoplie très élaborée. 2 ou 3 cordes achetées chez Bricorama suffiront amplement pour se faire saucissonner dans un premier temps. Vous pouvez aussi utiliser un drap dans lequel il faudra s’enrouler, façon rouleau de printemps. Il y aussi le wrapping, technique sm très en vogue en ce moment chez les dominas pro. Il s’agit de se faire immobiliser, envelopper intégralement de papier film, le même que celui qu’on utilise pour recouvrir un reste de spaghetti bolognaise à mettre au frigo. Seule la tête reste libre. Petit détail qui a son importance, lors de l’enroulement, le sboub doit-il être comprimé vers le haut ou vers le bas ? C’est à votre copine de trancher.

Pour toutes ces techniques, inutile que votre nana maitrise le bondage sur le bout des doigts même s’il faudra qu’elle ait envie d’être un zest directive ce soir là, nous y reviendrons.

Jouer le lombric, quel intérêt pour le mec ?

De prime abord, on s’imagine une pratique pénible, ramper façon entrainement militaire ou Koh Lanta, un mauvais bizutage ou une reconstitution flippante d’un Faite entrer l’accusé avec cadavre retrouvé enroulé dans le tapis persan de la grand-mère… Élargissez votre horizon, la « vers de terre attitude », c’est bien plus profond que ça.

figurine-de-collection-pixi-spirou-enroule-dans-un-tapis-6569-2015L’époque nous a transformé en robots multitâches, pressurisés comme jamais, chaque minute doit être rentable, chaque objectif rempli en temps et en heure, et plus vite que ça ! Il faut réussir sa life dans tous les domaines : être un king dans le taf, avoir pleins d’amis réels et virtuels, s’afficher en papa modèle et enfin assurer comme une bête au pieu, la bite à la main, toujours prêt (le mec n’a pas le droit de dire « non »). Au regard de ces constats, admettez que devenir une larve, une limace dénuée d’énergie, de cerveau, de bras, de jambes, de membres, peut s’avérer séduisant. Si les filles ont le droit de faire l’étoile de mer, les gars eux, ce sera donc le vers de terre.

Immobiliser ou presque, inutile de réfléchir, impossible de décider, d’agir, de contrôler, de faire des choix, c’est le grand soulagement, les vacances forcées, l’immense plaisir de la contrainte qui libère. Alors, vous pouvez philosopher : « je ne suis plus rien, je suis le lombric du monde ». Le lâcher-prise engendre le fameux subspace, cet état de conscience modifié procuré par les endorphines, bref, de quoi économiser quelques joints.

01Au raz du sol, vous ondulez avec vue imprenable sur les Bouboutin de votre meuf, ses jambes, ses bas-couture. Même le grand Bashung l’avait fantasmé dans sa chanson J’ai longtemps contemplé (album Chatterton)

“J’ai longtemps contemplé
Tibias, péronés
Au ras des rez-de-chaussée
Ces cités immenses
Où je ne rutilais pas
J’arpentais des tapis de braise…”

Mais attention, ce n’est pas le Club Med pour autant. Il va falloir essayer de bouger un peu, de se tortiller, avancer centimètre par centimètre, bref ramper tel un nuisible, pour atteindre le ridicule absolu ! Votre douce complice peut vous motiver en semant par terre des lombrics gélifiés trouvés au rayon Haribo, ou disséminer dans toute la pièce ses culottes sales ou encore des lignes de coke. Mais être saucissonné sous cocaïne, c’est un peu comme boire un Pétrus juste après s’être lavé les dents avec un dentifrice mentholé, c’est gâché !

Après vous avoir fait mordre la poussière, la meuf va vous obliger à jouer l’aspirateur à cunni. D’un coup de talon, la miss vous fera rouler sur le dos. Elle ne résistera pas à l’envie sadique de retirer son string histoire de vous faire admirer sa moquette, juste au dessus de votre tête. Toujours impossible de bouger un doigt, vous êtes à sa merci, et on dit merci qui ? « Merci Maîtresse ! » Dans sa grande mansuétude, elle se servira de vous comme d’un vulgaire sextoy en s’asseyant sur votre tronche, pour un facesitting d’anthologie. Attention tout de même à l’asphyxie, car enfoui sous ses fesses, difficile de bafouiller un safe word audible ou de faire un signe de secours, vu que vous n’avez plus de bras. À moins de se tordre comme un appât à deux doigts d’être accroché à l’hameçon de la pécheresse.

ver-une-caricature-stupide-fou-tee-shirts-t-shirt-hommeFaire mordre la poussière à son partenaire, quel intérêt pour la nana ?

Si les mecs ne peuvent pas échapper aux bimbos à plat ventre au détour d’un spam, d’un kiosque à journaux ou d’une pub dans le métro, pour les femmes, profiter de mecs dans le même état d’abandon, c’est beaucoup plus rare. Mais il y a quand même deux professions masculines où les filles ont la chance d’admirer quasi systématiquement un gars à quatre pattes voir à plat ventre, raie du cul apparente : plombier et dépanneur informatique. Ces derniers passent sous le bureau et se retrouvent nez à nez ou plutôt nez à pieds avec les escarpins aux talons parfois vertigineux.

Avoir un homme à ses pieds, lui demander n’importe quoi sans avoir à lui dire merci, ça peut être très excitant. C’est aussi une bonne façon de se foutre de sa gueule, de régler des vieux comptes, lui faire manger les acariens à ce vaurien, depuis le temps qu’il repousse le moment de passer l’aspi. « Les plates excuses, c’est fini ! Tu n’es qu’un insecte rampant. Ce soir, ce ne sera pas « baisons » mais baygon vert ! » (contre insectes rampants, cafards, fourmis, action immédiate et longue durée, comme dit la pub.)

Il peut être très plaisant de faire rouler le vermisseau sous ses pieds, un peu comme pousser un gros boudin, ça rappelle l’émission culte Interville. Et puis, comme expliqué plus haut, la demoiselle ou la dame pourra utiliser l’asticot tel un objet sexuel, en bonne entomologiste zoophile. Elle peut faire un trou dans le drap ou le papier film, juste au niveau du zboub.

353-0Mais votre amour propre est sauf, elle ne pourra pas vous traiter de « bite sur patte », puisque vous n’en avez plus, des papattes. Reste pour elle à s’empaler gaiement sur votre appendice. Concentrez-vous uniquement sur votre érection. Le reste n’a plus aucune importance vu le ridicule dans lequel vous êtes vautré, plus rien à réussir, plus d’objectif à atteindre, le nirvana post productiviste en somme.

 De notre contributrice Emma du blog Paris Derrière, blog sur les frasques du Paris érotique.

logo6

 

]]>
La course du bus de l’innovation sur le chemin de la croissance 6http://sametmax.com/?p=18765http://sebsauvage.net/streisand.me/sametmax/index.php?20170722_221046_La_course_du_bus_de_l___innovation_sur_le_chemin_de_la_croissance_6Sat, 22 Jul 2017 20:10:46 +0000Ceci est un post invité de 01ivier posté sous licence creative common 3.0 unported.

Bonsjours à toutes et à tous,

Dans un sursaut de patriotisme, je me suis dit qu’il me fallait, moi aussi, participer à l’effort national et promouvoir le savoir-faire technologique français. Partant du constat que, de nos jours, proposer quelque chose de nouveau semble suffisant pour être innovant, j’ai fait comme tout bon startupeur, je ne me suis pas embarrassé à concevoir quelque chose d’utile. À vrai dire, ce n’est même pas nouveau. Mais je suis français et j’ai un compte Twitter, je crois que c’est amplement suffisant pour prétendre au label #CitizenOfTheFrenchTechNation.

 
frenchtech

 

Où le bus l’innovation va tout droit.

Parce que je suis bien conscient de l’influence que cet article va avoir dans le monde du jeu vidéo, je vais détailler les différentes étapes de la réalisation de ce projet bouleversant.

Tout d’abord, j’ai fait en sorte que le bus de l’innovation aille tout droit sur un chemin de la croissance qui est tout droit.

#-*- coding: utf-8 -*-
 
# On importe de quoi dormir
from time import sleep
 
# On définit le graphisme en accord avec l'équipe de designers
chemin = " " 
arbre = "A"
bus = "B"
 
# On définit la qualité de l'image après avoir consulté les experts en GPU du Digital-Agile-Open-Tech-Lab-Responsive.IO
largeur_ecran = 70
 
# On définit l'état initial conjointement avec la team level design.
# (elle-même ayant sollicité au préalable le narrative designer, bien entendu)
largeur_chemin = 15
position_chemin = 28
position_bus = 35
 
while 1:
 
    # On place la première portion d'arbres dans le paysage
    paysage = arbre * position_chemin
    # On place le chemin
    paysage += chemin * largeur_chemin
    # On remplit le reste du paysage par la deuxième portion d'arbres
    paysage += arbre * (largeur_ecran - len(paysage))
    # On place le bus sur notre paysage
    paysage = paysage[:position_bus] + bus + paysage[position_bus:]
 
    # On affiche le tout
    print(paysage)
 
    # On dort un peu
    sleep(0.2)

bus_innovation_droit

Oui. Il est effectivement possible d’arriver plus simplement au même résultat, mais, mes qualifications ne m’offrent pas le loisir d’être incompétent. J’anticipe donc les futurs mouvements du bus de l’innovation ainsi que les inéluctables virages du chemin de la croissance.

Ce doit être un peu déroutant pour vous, j’en conviens, mais c’est l’expérience qui parle.

Faites-moi confiance.

 

Où le bus l’innovation va tout droit mais en bien plus beau.

Parce que l’on n’est jamais assez exigent sur l’apparence d’un produit de luxe, j’ai voulu changer le rendu des arbres en remplaçant le “A” par un “█” bien plus raffiné. Voici le résultat que j’ai obtenu :

bus_innovation_droit_arbre

Diable comme le succès est semé d’embûches !

En effet, un petit…

>>> len("█")
3

… m’a appris que le “█” comptait pour trois caractères, faussant mon ingénieuse gestion des positions.

Mon talent m’avait permis d’anticiper les mouvements et autres virages mais pas ça. Damned. Qu’allais-je faire ?

Un petit replace() bien placé et le tour était joué. Sans compter que je pouvais désormais me permettre de mettre de la couleur.

La classe internationale.

#-*- coding: utf-8 -*-
 
from time import sleep
 
chemin = " " 
arbre = "A"
#On définit un arbre classe et vert en utilisant les codes ANSI
arbre_classe_et_vert = "\33[32m█\033[0m"
bus = "B"
 
largeur_ecran = 70
largeur_chemin = 15
position_chemin = 28
position_bus = 35
 
while 1:
 
    paysage = arbre * position_chemin
    paysage += chemin* largeur_chemin
    paysage += arbre * (largeur_ecran - len(paysage))
    paysage = paysage[:position_bus] + bus + paysage[position_bus:]
    # PAF ! On remplace l'arbre ridicule par un arbre classe et vert après avoir géré la position des différents éléments.
    paysage = paysage.replace(arbre, arbre_classe_et_vert)
 
    print(paysage)
 
    sleep(0.5)

BIM !

bus_innovation_droit_arbre_vert

 

Où le bus de l’innovation va tout droit mais sur un chemin de la croissance qui tourne.

Pour faire tourner le chemin de la croissance je fais un petit +2/-2 sur sa position avec un randint(), et zou.

Par contre, pour forcer le chemin de la croissance à rester dans l’écran, j’ai été surpris de ne pas trouver de fonction prête à l’emploi pour contraindre un nombre dans un intervalle donné. Je suis donc passé par une “astuce” pécho sur Stack Overflow que j’ai trouvée élégante. On classe par ordre croissant le nombre donné avec les bornes de l’interval et on récupère le deuxième élément.

position = sorted(position_min, position, position_max)[1]

Si vous avez mieux, ça m’intéresse.

#-*- coding: utf-8 -*-
 
# On importe de quoi choisir des nombres au hasard
from random import randint
 
from time import sleep
 
chemin = " " 
arbre = "A"
arbre_classe_et_vert = "\33[32m█\033[0m"
bus = "B"
 
largeur_ecran = 70
largeur_chemin = 15
position_chemin = 28
position_bus = 35
 
# On définit une position maximale pour le chemin de la croissance
position_max_chemin = largeur_ecran - largeur_chemin
 
while 1:
 
    # On calcule la nouvelle position du chemin de la croissance
    # Un peu plus à droite, un peu plus à gauche ou un peu plus tout droit...
    position_chemin += randint(-2, 2)
 
    # En s'assurant qu'il ne déborde pas de la largeur de l'écran
    position_chemin = sorted([1, position_chemin, position_max_chemin])[1]
 
    paysage = arbre * position_chemin
    paysage += chemin * largeur_chemin
    paysage += arbre * (largeur_ecran - len(paysage))
    paysage = paysage[:position_bus] + bus + paysage[position_bus:]
    paysage = paysage.replace(arbre, arbre_classe_et_vert)
 
    print(paysage)
 
    sleep(0.5)

bus_innovation_chemin_virage

 

Où le bus de l’innovation crache des flammes.

Avant de me pencher sur les mouvements du bus de l’innovation, j’ai pris le temps de le tuner un peu.

Déjà, direct, je l’ai peint en rouge, rapport au fait que le bus de l’innovation, c’est un peu la Ferrari de l’entrepreneuriat.

Et puis, je me suis dit qu’il fallait qu’il n’y ai vraiment absolument aucun doute sur le fait que c’était bel et bien le bus de l’innovation. Je lui ai donc fait écrire “LE BUS DE L’INNOVATION” sur la route. Je m’en remets à vous pour me dire s’il reste une ambiguïté.

Accessoirement, le “A” utilisé pour placer les arbres est devenu un “a“, pour ne pas être confondus avec le “A” présent dans “INNOVATION”. C’est un détail, mais les générations d’ingénieurs qui liront ça dans deux cent ans seront bien contents de trouver cette explication.

#-*- coding: utf-8 -*-
 
from random import randint
from time import sleep
 
chemin = " " 
arbre = "a"
arbre_classe_et_vert = "\33[32m█\033[0m"
 
largeur_ecran = 70
largeur_chemin = 15
position_chemin = 28
position_bus = 35
 
# On définit le texte écrit par le bus de l'innovation
texte_du_bus = "LE BUS DE L'INNOVATION "
# On récupère le nombre de caractères dans le texte écrit par le bus de l'innovation
nb_caractere = len(texte_du_bus)
# On initialise un compteur pour gérer la succession des caractères
compteur = 0
 
position_max_chemin = largeur_ecran - largeur_chemin
 
while 1:
 
    position_chemin += randint(-2, 2)
    position_chemin = sorted([1, position_chemin, position_max_chemin])[1]
 
    paysage = arbre * position_chemin
    paysage += chemin * largeur_chemin
    paysage += arbre * (largeur_ecran - len(paysage))
 
    # Dans le texte écrit par le bus de l'innovation, on prend le caractère 
    # indiqué par le compteur modulo le nombre de caractères possibles
    caractere = texte_du_bus[compteur%nb_caractere]
    # On peint le caractère en rouge Ferrari
    bus = "\33[31m{0}\033[0m".format(caractere)
    # On incrémente le compteur pour avoir le caractère suivant au prochain tour
    compteur += 1
 
    paysage = paysage[:position_bus] + bus + paysage[position_bus:]
    paysage = paysage.replace(arbre, arbre_classe_et_vert)
 
    print(paysage)
 
    sleep(0.5)

Magnifique.

bus_innovation_flamme

 

Où l’on cherche à faire tourner le bus de l’innovation.

Je ne vais pas vous mentir, la course du bus de l’innovation sur le chemin de la croissance n’est pas vraiment une nouveauté vidéoludique. Nous, c’est à dire La Labomedia, l’avons déjà présentée à Toulouse lors du THSF 2014 ainsi qu’au PSESHSF 2016 de Choisy-le-Roi dont il existe même une vidéo de la Master Class.

Sur cette photo spectaculaire, vous pouvez découvrir la pertinence de notre ingénieuse interface biologique imputrescible nourrie aux anti-biotiques NF.

busdelinnovationsurlechemindelacroissance

Mais, non seulement j’avais perdu totalement le code initial mais en plus l’installation s’appuyait sur l’excessivement chère MakeyMakey qui, par ailleurs, telle qu’elle est vendue, impose à l’utilisateur d’être relié à une masse.

Pour sa résurrection, je lui ai donc préférée la Capacitive Touch HAT pour RaspberryPi conçue par Adafruit et qui fonctionne direct au simple touché.

(Il va de soit que les natural chicken flavor interfaces n’ont, elles, pas été remises en question.)

Voici le code minimal pour utiliser le Capacitive Touch HAT une fois la librairie d’Adafruit installée :

import Adafruit_MPR121.MPR121
from time import sleep
 
interface = Adafruit_MPR121.MPR121.MPR121()
interface.begin()
 
while 1:
 
  # Si la patine numéro 0 est touchée
  if interface.is_touched(0):
      print("GAUCHE !")
 
  # Si la patine numéro 10 est touchée
  if interface.is_touched(10):
      print("DROITE !")
 
  sleep(0.1)

Qui devient ceci quand on instaure un seuil de détection pour tenir compte de la conductivité des pattes de poulet.

import Adafruit_MPR121.MPR121
from time import sleep
 
interface = Adafruit_MPR121.MPR121.MPR121()
interface.begin()
 
seuil = 100
 
while 1:
 
  # Si la patte de poulet reliée à la patine numéro 0 est touchée
  if interface.filtered_data(0) < seuil:
      print("GAUCHE !")
 
  # Si la patte de poulet reliée à la patine numéro 0 est touchée
  if interface.filtered_data(10) < seuil:
      print("DROITE !")
 
  sleep(0.1)

On ne peut pas dire que ce soit très compliqué. À noter tout de même la nécessité d’activer l’I2C et de lancer le script en root. Une formalité pour celles et ceux qui ont de l’ambition dans la Vie.

Une fois intégré dans notre formidable simulation de sport mécanique extrême, le script ressemble alors à ça :

#-*- coding: utf-8 -*-
 
# On importe la librairie d'Adafruit
import Adafruit_MPR121.MPR121 as MPR121
 
from random import randint
from time import sleep
 
# On instancie l'interface...
interface = MPR121.MPR121()
# ... et on la démarre.
interface.begin()
 
chemin = " " 
arbre = "a"
arbre_classe_et_vert = "\33[32m█\033[0m"
 
largeur_ecran = 70
largeur_chemin = 15
position_chemin = 28
position_bus = 35
 
texte_du_bus = "LE BUS DE L'INNOVATION "
nb_caractere = len(texte_du_bus)
compteur = 0
 
position_max_chemin = largeur_ecran - largeur_chemin
 
seuil = 100
 
while 1:
 
    # En fonction des patines touchées,
    # on déplace le bus de l'innovation vers la droite...
    if interface.filtered_data(0) < seuil:
        position_bus += 1
 
    # ... ou vers la gauche.
    if interface.filtered_data(10) < seuil:
        position_bus -= 1
 
    position_chemin += randint(-2, 2)
    position_chemin = sorted([1, position_chemin, position_max_chemin])[1]
 
    paysage = arbre * position_chemin
    paysage += chemin * largeur_chemin
    paysage += arbre * (largeur_ecran - len(paysage))
 
    caractere = texte_du_bus[compteur%nb_caractere]
    bus = "\33[31m{0}\033[0m".format(caractere)
    compteur += 1
 
    paysage = paysage[:position_bus] + bus + paysage[position_bus:]
    paysage = paysage.replace(arbre, arbre_classe_et_vert)
 
    print(paysage)
 
    sleep(0.5)

bus_innovation_tourne

 

Où le bus de l’innovation est tenu de rester sur le chemin de la croissance.

Écoutez, que les choses soient bien claires, moi aussi je trouve cet article beaucoup trop long, mais c’est du rayonnement de la France dont il est question. Dois-je vous le rappeler ?

Voici donc comment j’ai tenu compte des sorties du chemin de la croissance par notre bus de l’innovation :

#-*- coding: utf-8 -*-
 
import Adafruit_MPR121.MPR121 as MPR121
 
from random import randint
from time import sleep
 
interface = MPR121.MPR121()
interface.begin()
 
chemin = " " 
arbre = "a"
arbre_classe_et_vert = "\33[32m█\033[0m"
 
largeur_ecran = 70
largeur_chemin = 15
position_chemin = 28
position_bus = 35
 
texte_du_bus = "LE BUS DE L'INNOVATION "
nb_caractere = len(texte_du_bus)
compteur = 0
 
position_max_chemin = largeur_ecran - largeur_chemin
 
# On définit un booléen qui rendra compte de l'état du bus de l'innovation
le_bus_roule = True
 
seuil = 100
 
while 1:
 
    if interface.filtered_data(0) < seuil:
        position_bus += 1
 
    if interface.filtered_data(10) < seuil:
        position_bus -= 1
 
    # Si le bus roule...
    if le_bus_roule:
 
        position_chemin += randint(-2, 2)
        position_chemin = sorted([1, position_chemin, position_max_chemin])[1]
 
        paysage = arbre * position_chemin
        paysage += chemin * largeur_chemin
        paysage += arbre * (largeur_ecran - len(paysage))     
 
        # Si le bus sort de la route, à gauche ou à droite...
        if position_bus <= position_chemin or position_bus >= position_chemin + largeur_chemin:
 
            # On change l'apparence du bus (qui devient une croix verte)
            bus = "\33[32mX\033[0m"
            # On change l'état du bus de l'innovation
            le_bus_roule = False
 
        # Sinon, on affiche le bus comme précédement défini
        else:
            caractere = texte_du_bus[compteur%nb_caractere]
            bus = "\33[31m{0}\033[0m".format(caractere)
            compteur += 1
 
        paysage = paysage[:position_bus] + bus + paysage[position_bus:]
        paysage = paysage.replace(arbre, arbre_classe_et_vert)
 
        print(paysage)
 
        # Si, entre temps, le bus de l'innovation s'est arrêté de rouler
        if not le_bus_roule:
 
            # On affiche un message sympathique après avoir sauté une ligne
            print("\nIl n'est pas exclu que le bus de l'innovation se soit pris un arbre...")
 
        sleep(0.5)

bus_innovation_crash

 

Où la course du bus de l’innovation sur le chemin de la croissance va pouvoir enfin commencer.

Afin que le public intègre bien le défi collectif que représente la relance de l’économie par le financement et le développement d’innovants nouveaux projets novateurs avec de la technologie à la pointe de la technologie, j’ai fait en sorte d’afficher la croissance totale que l’ensemble des joueurs auront fait parcourir au bus de l’innovation.

Ainsi, n’y a-t-il jamais un individu qui perd, mais toujours un collectif qui gagne.

Quelque chose entre la victoire éternelle et le succès permanent.

Une véritable leçon de Vie.

#-*- coding: utf-8 -*-
 
import Adafruit_MPR121.MPR121 as MPR121
 
from random import randint
from time import sleep
 
interface = MPR121.MPR121()
interface.begin()
 
chemin = " " 
arbre = "a"
arbre_classe_et_vert = "\33[32m█\033[0m"
 
largeur_ecran = 70
largeur_chemin = 15
 
# On met en place un système d'initialisation des positions
# du chemin de l'innovation et du bus de la croissance
init_position_chemin = 28
init_position_bus = 35
position_chemin = init_position_chemin
position_bus = init_position_bus
 
texte_du_bus = "LE BUS DE L'INNOVATION "
nb_caractere = len(texte_du_bus)
compteur = 0
 
position_max_chemin = largeur_ecran - largeur_chemin
 
seuil = 100
 
le_bus_roule = True
 
# On déclare des variables qui vont nous permettre de rendre compte
# des quantités de croissance parcourue par le bus de l'innovation
croissance_parcourue_totale = 0
croissance_parcourue = 0
 
# On définit un petit texte à formater pour présenter les quantités en question
texte_crash ='''
Bravo !
Tu t'es pris un arbre mais tu as parcouru {0} mètres de croissance !
 
Pour ton information, le Bus de l'Innovation a parcouru {1} mètres
de croissance depuis son départ.
 
Pour le faire redémarrer, appuie sur la cuisse de poulet du milieu.
La France compte sur toi !
'''
 
while 1:
 
    if interface.filtered_data(0) < seuil:
        position_bus += 1
 
    if interface.filtered_data(10) < seuil:
        position_bus -= 1
 
    # On met en place un moyen de reprendre le chemin de la croissance
    # si le bus de l'innovation s'est pris un arbre
    if if interface.filtered_data(5) < seuil and not le_bus_roule:
        le_bus_roule = True
        croissance_parcourue = 0
        position_chemin = init_position_chemin
        position_bus = init_position_bus
        compteur = 0
 
    if le_bus_roule:
 
        position_chemin += randint(-2, 2)
        position_chemin = sorted([1, position_chemin, position_max_chemin])[1]
 
        paysage = arbre * position_chemin
        paysage += chemin * largeur_chemin
        paysage += arbre * (largeur_ecran - len(paysage))     
 
        if position_bus <= position_chemin or position_bus >= position_chemin + largeur_chemin:
 
            bus = "\33[32mX\033[0m"
            le_bus_roule = False
 
        else:
            caractere = texte_du_bus[compteur%nb_caractere]
            bus = "\33[31m{0}\033[0m".format(caractere)
            compteur += 1
            # On incrémente la croissance parcourue à chaque tour
            croissance_parcourue += 5
 
        paysage = paysage[:position_bus] + bus + paysage[position_bus:]
        paysage = paysage.replace(arbre, arbre_classe_et_vert)
 
        print(paysage)
 
        if not le_bus_roule:
 
            # On calcule la croissance totale parcourue
            croissance_parcourue_totale += croissance_parcourue
            # On formate notre petit texte pour informer le joueur de sa 
            # performance individuelle et collective.
            print(texte_crash.format(croissance_parcourue, croissance_parcourue_totale))
 
        sleep(0.5)

bus_innovation_arcade

]]>
Le pattern strategy version gastronomique 9http://sametmax.com/?p=23520http://sebsauvage.net/streisand.me/sametmax/index.php?20170714_211106_Le_pattern_strategy_version_gastronomique_9Fri, 14 Jul 2017 19:11:06 +0000Allez, un petit article de POO un peu avancée pour faire marcher ses neurones ce WE.

Le design pattern strategy, qui consiste à déléguer une partie du comportement d’un objet à un autre objet, est probablement l’un des motifs de conception les plus utiles en programmation. Trop souvent les gens utilisent l’héritage là où la composition serait plus adaptée, et une injection de dépendance bien faite permet de gagner beaucoup en qualité de code.

Si vous ne vous souvenez plus de ce qu’est le pattern strategy, vous pouvez faire un saut sur le chapitre qui en parle dans le guide de la POO :)

Mais comme un petit rappel ne fait pas de mal, en très court, strategy ressemble à ça :

class MonObjet:
    def __init__(self):
        self.strategie = MaStrategie()
 
    def foo(self):
        return self.strategie.foo()

Ce qui permet à une sous-classe de changer la strategy ou non :

class MonSousObjet(MonObjet):
   def __init__(self):
        self.strategie = MonAutreStrategie()

Ou de changer la strat dynamiquement :

hop = MonObjet()
 
hop.stategie = SuperNewStrat()

Mais si vous vous en tenez à ce design, les utilisateurs de la classe vont très vite rencontrer des limitations.

D’abord, une bonne stratégie peut avoir besoin de contexte. Dans ce cas, donnez lui le choix d’avoir une référence à l’objet parent:

class MonObjet:
    def __init__(self):
        # Passer self permet à la stratégie de connaître son contexte. 
        # Le désavantage est l'introduction potentiel d'un couplage entre 
        # les deux objets, et potentiellement des effets de bords supplémentaires. Cela reste 
        # néanmoins souvent une bonne idée.
        self.strategie = MaStrategie(self)   
    ...

Ensuite, une stratégie devrait pouvoir être passée à la création de l’objet :

class MonObjet:
    def __init__(self, strategie=MaStrategie):
        # On donne la priorité à l'objet passé en paramètre. Si il n'y en a 
        # pas on crée la stratégie par défaut.
        self.strategie = strategie(self)  
    ...

Cela permet d’overrider la stratégie pour les usages plus avancés, tout en permettant aux débutants de ne pas se soucier de cela car il existe quand même une valeur par défaut.

truc = MonObjet(UneStrategieDifferente)

Comme le travail dans un init est souvent assez redondant, avoir un endroit pour permettre aux sous-classes de facilement overrider la stratégie est une bonne pratique. En Python il est courant d’utiliser les variables de classes pour cela :

class MonObjet:
 
    # On appelle souvent cet attribut "strategy_class" ou "strategy_factory"
    strategie_par_default = MaStrategie
 
    def __init__(self, strategie=None):
        self.strategie = strategie(self) if strategie else self.strategie_par_default(self) 
    ...
 
class MonSousObjet(MonObjet):
    # Et boom, overriding de la stratégie par la classe enfant en une ligne.
    # Django fait ça par exemple avec les classes based views et l'attribut 
    # model
    strategie_par_default = MonAutreStrategie

Une fois que vous avez fait tout ça, vous avez déjà fait mieux que 90% des programmeurs. Néanmoins si vous voulez vraiment mettre la petit touche pro à votre API, vous pouvez aussi permettre la création dynamique de la stratégie:

class MonObjet:
 
    strategie_par_default = MaStrategie
 
    def __init__(self, strategie=None):
        self.strategie = strategie(self) if strategie else self.build_strategy() 
 
    def build_strategy(self):
        return self.strategie_par_default(self)
 
    ...

Wow, ça en fait des self et des factories :) En fait, ça fait la même chose qu’avant, c’est à dire que le tout premier exemple de code tout simple qu’on a vu en début d’article marche toujours ! C’est la beauté de la chose.

La différence, c’est que maintenant une classe enfant peut overrider build_strategy() et créer des stratégies à la volée, en fonction du contexte d’exécution. Par exemple créer une stratégie différente en fonction d’une valeur de base de données. C’est rare que ça arrive, et c’est vraiment de l’usage avancé. Mais quand vous avez ça, vous êtes certains que votre code est prêt à être utilisé par autrui. Car si cet autrui n’est pas content, il peut faire une profonde coloscopie à votre code et y insérer ce qu’il veut, quand il veut.

Être dev après tout, c’est être un peu poète.

]]>
Le don du mois: Framasoft (bis) 7http://sametmax.com/?p=23501http://sebsauvage.net/streisand.me/sametmax/index.php?20170711_091538_Le_don_du_mois__Framasoft__bis__7Tue, 11 Jul 2017 07:15:38 +0000déjà donné à Framasoft il y a 2 ans alors que je n'utilisais plus vraiment le site. Plutôt en remerciement de tout ce qu'ils ont fait pendant que j'étais encore sous Windows à bricoler avec Phoenix, CloneCD et WinAmp. ]]>J’ai déjà donné à Framasoft il y a 2 ans alors que je n’utilisais plus vraiment le site. Plutôt en remerciement de tout ce qu’ils ont fait pendant que j’étais encore sous Windows XP à bricoler avec Phoenix, CloneCD et WinAmp.

Depuis 2001 cet excellent portail a fleuri pour devenir un hébergeur de nombreux services, particulièrement:

Pour l’instant je suis très content de l’agenda qui est une instance nextcloud avec une jolie UI, offrant plusieurs calendriers en parallèle, des partages et exports et tout le tintouin. Donc j’ai thunderbird linké dessus sous Ubuntu, et Solcalendar sous Android (avec pulse sms pour pouvoir taper les sms confortablement sur l’ordi, rien à avoir mais j’en suis content alors je plug).

Bref, cet outil arrive à point pour être bien productif. Reste plus qu’à trouver une alternative à GTG qui est lent comme une grand-mère asthmatique. Si vous avez des suggestions…

Néanmoins, héberger des services comme ça, ça coûte cher. Et framasoft les propose gratuitement.

Donc, don de 30 euros à l’asso. Merci messieurs-dames, vous déchirez.

Pour vous aussi faire un don, c’est par ici.

]]>
Caldigit et USB-C 13http://sametmax.com/?p=23488http://sebsauvage.net/streisand.me/sametmax/index.php?20170710_134139_Caldigit_et_USB-C_13Mon, 10 Jul 2017 11:41:39 +0000Mon rêve d’avoir un setup tri-écran, ethernet, casque-micro et chargement avec un seul câble est enfin devenu une réalité.

Et ça a pas été de la tarte.

J’ai un Dell XPS 15 qui a un port USB-C avec thunderbolt. J’ai acheté un dock USB-C caldigit qui propose une entrée micro, une sortie casque, un port HDMI, un display port et un port ethernet, le tout avec un seul branchement via USB-C.

Inutile de dire que ça n’a pas marché. L’USB-C est une vraie jungle, vous connaissez aussi mon avis sur les finitions du XPS 15 et puis la vidéo, ça fait partie de ces trucs qui sont toujours galère en 2017.

Mais…

Après avoir:

  • Mis à jour tous les drivers du XPS et flashé le bios et le controller USBC (sic).
  • Téléchargé le driver ethernet linux de caldigit (sympas !).
  • Avoir acheté les bons câbles (USB-C respectant le standard, convertisseurs HDMI actifs, etc).
  • Flashé le dock avec l’outil caldigit en ayant les bons câbles branchés.
  • Et bidouillé avec la config d’affichage d’Ubuntu pendant pas mal de temps.

Ca marche.

Pas plug and play pour deux ronds. Mais j’ai enfin un seul câble qui charge l’ordi, m’envoie un débit fibré et étend mon affichage, automatiquement au boot, sous Linux et Windows.

Joie.

Si j’écris l’article, c’est pour dire que:

  • C’est possible.
  • C’est chiant.
  • Le dock caldigit est le seul que j’ai trouvé qui marche avec le XPS (qui suce un max de Watts). Et j’en ai essayé des bidules.
  • Les câbles et adaptateurs sont le nerf de la guerre. Et ils sont dans le camp ennemi.

Mais surtout pour signaler que le support de caldigit a été fantastique, ce qui est assez rare pour le souligner. Ma première interlocutrice via chat a répondu vite et posé les bonnes questions. Identifiant qu’elle ne pouvait pas résoudre le problème, elle m’a redirigé vers le niveau supérieur du support en faisant suivre correctement tout le dossier. Niveau supérieur très technique qui a permis, mail après mail, détail après détail, à faire marche le bouzin. Pas une question à la noix. Pas besoin de me répéter 15 fois. Pas de remise en cause de ma bonne foi ou de prise pour un gogole. Quand les gens font leur boulot ça étonne toujours.

]]>
Alternative au do…while en Python 21http://sametmax.com/?p=23459http://sebsauvage.net/streisand.me/sametmax/index.php?20170703_172510_Alternative_au_do___while_en_Python_21Mon, 03 Jul 2017 15:25:10 +0000do..while en python, on fait donc généralement une boucle infinie suivie d'un break sur une condition.]]>De nombreuses instructions ont été volontairement écartées de Python. Le goto bien entendu, mais aussi le switch, unless et le do...while.

Le but est de limiter le nombre de mots clés à connaitre afin de comprendre le langage. Les créateurs ont choisi donc de mettre de côté des mots clés trop souvent mal utilisés, pas assez utilisés, ou qui possèdent des alternatives suffisantes.

La boucle while est rarement utilisée en Python, en tout cas beaucoup, beaucoup moins que sa petite soeur la boucle for. Avoir besoin d’un do...while est encore plus rare, et donc ne peut faire partie du club très fermé des mots clés réservés.

Si l’on souhaite obtenir l’effet du do..while en python, on fait donc généralement une boucle infinie suivie d’un break sur une condition. Exemple:

import random
 
choix = random.randint(0, 100)
 
while True:
    reponse = int(input('Devinez le nombre: '))
    if reponse < choix:
        print('Plus grand')
    elif reponse > choix:
        print('Plus petit')
    else:
        break
print('Bravo')

Le défaut de cette technique est qu’elle ne rend pas clair dès le début la condition de sortie de la boucle. Aujourd’hui en parcourant la mailling list python-idea, je suis tombé sur une idée pas conne:

import random
 
choix = random.randint(0, 100)
 
while "L'utilisateur n'a pas encore deviné le nombre":
    reponse = int(input('Devinez le nombre: '))
    if reponse < choix:
        print('Plus grand')
    elif reponse > choix:
        print('Plus petit')
    else:
        break
print('Bravo')

Ca marche car les chaînes non vides sont toujours vraies en Python, et ça documente le code :)

]]>
Les plus grosses roues du monde 15http://sametmax.com/?p=23443http://sebsauvage.net/streisand.me/sametmax/index.php?20170630_145808_Les_plus_grosses_roues_du_monde_15Fri, 30 Jun 2017 12:58:08 +0000L’avantage d’avoir quelques années de programmations dans les pattes et un certain nombres de projets à son actif, c’est qu’on arrive à identifier des motifs communs qui se dégagent encore et encore.

Par exemple, quand j’étais en tout début de carrière, j’ai ouvert l’excellent bouquin “Head first design patterns” et je n’en ai pas retiré grand chose car je n’avais pas la matière pour pouvoir identifier l’utilité des solutions proposées. Bien plus tard, en le relisant, je me suis aperçu que j’avais en fait rencontré moult fois chaque chapitre IRL, base de code après base de code.

La vie apprend les design patterns bien plus efficacement que les écrits. Mais ces derniers ont l’avantage de mettre de l’ordre dans ses idées. Ils mettent des mots sur des pensées floues, et tracent des contours qui délimitent pragmatiquement les concepts.

Aujourd’hui néanmoins, nous n’allons pas parler de design pattern, bien que faire un dossier dessus serait une bonne idée. Mais ça fait des mois que je dois finir le dossier tests unitaires, alors je vais pas commencer un nouveau dossier.

Non, aujourd’hui, nous allons parler d’outils dont on a besoin dans quasiment tous les projets importants et qu’on réinvente, ou rapièce, presque à chaque fois.

Dispatching

Que ce soit parce que vous avez un observer, du pub/sub, un système de routing ou des events internes, votre projet finira par avoir besoin d’un système de dispatching. Le dispatching c’est la propagation/distribution de l’information et de son traitement.

Ils ont toujours la même chose en commun:

  • Des points centraux qui prennent les entrées et les dirigent vers les bonnes sorties.
  • Un système d’enregistrement des points d’entrées (hooks) et des points de sorties (endpoints).
  • Une logique de résolution qui permet de faire transiter les données depuis une entrée, vers une ou plusieurs sorties, parfois aller-retour.

Par exemple:

  • Le pub/sub de redis ou crossbar.io.
  • Le routing URL d’un framework Web comme Django ou Rails.
  • Les events d’un UI comme le addEventListener en JS ou connect() en QT.
  • La remontée hiérarchique des messages de logs dans le module Python logging.

Ce sont tous des implémentations spécialisées d’un système de dispatching. Le hello world du dispatching est le design pattern observer, qui minimalement ressemble à ça:

>>> class Dispatcher:
...     def __init__(self):
...         self.registry = {}
...     def on(self, event, callback):
...         self.registry.setdefault(event, []).append(callback)
...     def trigger(self, event):
...         for callback in self.registry[event]:
...                 callback()
... 
... hub = Dispatcher()
... 
... hub.on("j'arrive", lambda: print('coucou'))
... hub.on("j'arrive", lambda: print('salut'))
... 
... hub.trigger("j'arrive")
... 
coucou
salut

En fait, à moins de faire uniquement des scripts, vous avez utilisé plein de systèmes de dispatching sans le savoir.

Bien que pour qu’ils soient utiles il faut des versions spécialisées pour chaque usage, c’est un problème générique et il est ridicule que nous devions réimplementer à chaque fois ce truc. Un bon système de dispatching est utile dans tout gros projet. Vous voulez permettre à quelqu’un de lancer du code quand votre système s’initialise ? Créer une logique de plugin ? Bam, il faut du dispatching.

Il faudrait donc un framework en Python qui permette de fabriquer son propre système de dispatching. Il devra bien entendu inclure des implémentations spécialisées au moins pour les cas les plus courants sinon ça fera comme une lib zope et ça prendra la poussière.

Le but étant qu’au bout de quelques années, tout le monde base son implémentation sur cette brique, robuste et documentée, plutôt que de créer son propre système.

En effet, un bon système de dispatching doit pouvoir gérer les cas suivants :

  • Mono directionnel ou bi-directionnel.
  • Un ou plusieurs endpoints.
  • Middlewares.
  • Algo de routing custo.
  • Passage de paramètres à l’ajout d’un enpoint.
  • Passage de contexte à l’appel de l’endpoint.
  • Appel synchrone ou asynchrone des endpoints.
  • Enpoints locaux ou remotes.
  • Gestion de plusieurs dispatchers en parallèle.
  • Interconnexion de plusieurs dispatchers.
  • Adapters pour les dispatchers courants déjà existants.

Le tout bien entendu avec des backends pour chaque partie qu’on puisse swapper.

Configuration

La conf, c’est l’exemple exacte de la fragmentation dans notre métier. C’est l’usine à roues (carrées) réinventées.

Sérieusement, entre le parsing des arguments de la ligne de commande, les fichiers de config, les services de config (etcd anyone ?), les configs sauvegardées en BDD, les API de conf, les variables d’environnement, etc. c’est un bordel sans nom.

Tout le monde a fait son petit fichier params.(ini|yml|xml|json) ou sa table SQL settings dans un coin. Et la validation. Et la génération. Et les valeurs par défaut. Et l’overriding des envs. Ca change à chaque projet, à chaque framework, à chaque foutue lib.

C’est que le but est simple, mais le problème est complexe. Mais on en a tous besoin, et il n’y a rien, mais alors rien qui existe de générique.

Une bonne lib de conf doit:

  • Offrir une API standardisée pour définir les paramètres qu’attend son programme sous la forme d’un schéma de données.
  • Permettre de générer depuis ce schéma les outils de parsing de la ligne de commande et des variables d’env.
  • Permettre de générer depuis ce schéma des validateurs pour ces schémas.
  • Permettre de générer des API pour modifier la conf.
  • Permettre de générer des UIs pour modifier la conf.
  • Séparer la notion de configuration du programme des paramètres utilisateurs.
  • Pouvoir marquer des settings en lecture seule, ou des permissions sur les settings.
  • Notifier le reste du code (ou des services) qu’une valeur à été modifiée. Dispatching, quand tu nous tiens…
  • Charger les settings depuis une source compatible (bdd, fichier, api, service, etc).
  • Permettre une hiérarchie de confs, avec une conf principale, des enfants, des enfants d’enfants, etc. et la récupération de la valeur qui cascade le long de cette hiérarchie. Un code doit pouvoir plugger sa conf dans une branche de l’arbre à la volée.
  • Fournir un service de settings pour les architectures distribuées.
  • Etre quand même utile et facile pour les tous petits scripts.
  • Auto documentation des settings.

Pas évident non ? Ça change de “ah bah je vais dumper tout ça dans un settings.py et on verra bien” :)

Les bénéfices d’avoir un bon système de settings sont énormes. D’abord, si il est largement adopté, plus besoin de fouiller dans la doc de chaque projet pour savoir comment l’utiliser. Les problèmes difficiles comme les “live settings” sont réglés une fois pour toute. Plus besoin d’écrire pour la millième fois le code de glue entre son schéma marshmallow + ses params clicks + son parser yml qui sera forcément bricolé. Et une expérience utilisateur bien meilleure avec de la doc, des messages standardisés, des checks de sources de données que d’habitude personne ne fait, etc.

Logging

Oui, je sais, je sais, Python a un excellent module de logging, très riche et polyvalent. Et puis ce ne sont pas les projets de logging qui manquent. Il y a celui de twisted, il y a logbook, logpy… En fait j’ai même pondu devpy.

Malgré ça, force est de constater que tous ces projets sont loin d’être une bonne solution pour convenir à tous.

Le module logging Python manque de configuration par défaut, n’a pas de gestion multiprocessing, aucune facilité pour générer des logs structurés ou binaires, etc. logbook et logpy sont des surcouches qui améliorent, mais sans aller assez loin, l’expérience. Twisted comme d’hab fait le café mais est indigeste. Logpy n’est bien que pour les cas simples.

Un bon module de logging devrait:

  • Etre compatible avec la stdlib, et avoir des adaptateurs pour les systèmes les plus courants (comme twisted).
  • Gérer le multiproccessing, particulièrement le locking des fichiers ou avoir un process central dédié aux logs.
  • Proposer une UI user friendly de consommation des logs.
  • Avoir des pré-configurations prête à l’usage hyper simple et rapide à utiliser pour les cas les plus simples, comme le scripting.
  • Gérer des formats avancés: json, binaires, nesting, logs structurés, etc. Avec des recettes toutes faites pour les cas courants.
  • Avoir une bonne intégration avec les systèmes de logs natifs de l’OS sans besoin de trifouiller.
  • Proposer des outils d’analyse de logs.
  • Offrir des solutions pour les cas simples (console, fichier, coloration, post-mortem, etc.) ou complexes mais courants (mail, logstash, sentry, log sur serveur distant, etc).

Au fait, aviez-vous noté que le cœur d’un système de log est un dispatcheur ? :)

Lifecyle

Dès que vous créez un projet, il a un cycle de vie. Il s’initialise, charge les paramètres, load les plugins si il y en a, lance son processus principal, puis finit par s’arrêter, ou foirer, ou les deux.

Si c’est un petit script, ce n’est pas très important, on ne s’en rend même pas compte.

Si c’est un gros projet, vous allez vouloir que le code du reste du monde puisse interagir avec ça. D’ailleurs, tous les gros frameworks vous permettent de réagir au cycle de vie. Django a le fichier appconfig.py par exemple pour lancer du code au démarrage du framework, et des middlewares pour intercepter les requêtes et les réponses. Twisted permet de dire “lance ce code dès que le reactor est en route”. Pour comprendre Angular ou une app Android, la moitié du boulot c’est de piger les différentes phases du cycle de chaque composant.

Le cycle de vie est en fait un système de dispatching (surprise !) couplé à une machine à état fini, et concrétisé dans un processus métier. La bonne nouvelle, c’est que des libs de state machines en Python on en a un max, et des bien fournies. La mauvaise, c’est qu’avec la popularité grandissante d’asyncio, on a de plus en plus besoin de gérer explicitement le cycle de vie de ses projets et qu’on a rien de générique pour ça alors la cyclogénèse envahie la communauté.

En effet, dès qu’on a une boucle d’événement comme avec asyncio/twisted/tornado, on a un cycle de vie complexe mais implicite qui se met en place puisque la loop démarre, s’arrête, est supprimée, est remplacée, est en train d’exécuter une tâche, une tâche qui peut générer des erreurs… Et très vite le cycle dégouline de partout, et on commence à coder ici et là pour gérer tout ça sans se rendre compte qu’on crée petit à petit un énième framework de lifecycle. Pas vrai Gordon ?

C’est l’histoire de la viiiiiiiiiiiiiiiie. C’est le cycle éterneleuuuuuuuuuh. De la roue infinieeeeeeee. Codée à la truelleuuuuuuh.

Structure de projet

Bon, imaginons que vous ayez une lib de life cycle, qui charge vos settings avec votre super lib de conf, logge tout grâce à votre géniale lib de logging, le tout powered par une lib de dispatching que le monde vous envie. Le perfide.

Je dis “imaginez” parce que dans votre projet vous avez plutôt un tas de crottes retenues par un cornet de glace que vous avez codé pour la énième fois à la va vite en utilisant 30% de libs tierce partie, 30% d’outils de votre framework du jour et 40% de roux (du NIH sans âme quoi…).

Donc imaginez ça. Et maintenant vous voulez mettre en place un moyen de diviser votre projet en sous parties. Peut être des apps, ou pourquoi pas des plugins. Mais vous voudriez que tout ça soit gérable par un point d’entrée principal, ou individuellement. Que ça se plug dynamiquement. Que ça joue bien avec votre système de conf et de lifecyle. Diantre, vous voulez qu’un code externe puisse être découvert et pluggé au système. Choisir si ça tourne dans des threads ou des processus séparés. Mais communiquer entre les parties. Et que tout ça soit découplé bien entendu ! Sauf qu’il y a une gestion de dépendances des plugins…

Pas de problème, vous prenez un bus de communication, un système de plugin, un graph de résolution de dépendances, vos super libs ci-dessus et vous gluez tout ça avec de la logique de chez mémé et de la sueur. Une mémé si ronde qu’elle a un pneu autour de la taille. Et un essieu.

Django a ses apps. jQuery a ses plugins. L’app d’un de mes clients avec un hack à base d’importlib et ctype qui loadait une dll pour charger les drivers de leur matos. Ca roule Maurice, ça roule à mort.

Il nous faut une lib de référence qui permette:

  • De diviser son projets en plus petites unités tout en gardant un point central pour faire le lien.
  • De découvrir, charger et décharger ces unités.
  • Permettre de répartir ces unités dans des threads, multiprocess, machines.
  • Les faire communiquer.

Et dans les ténèbres les lier

Une fois qu’on a tout ça, il faut bien entendu un gros framework qui permette de faire le lien entre tout ça et coder un projet automatiquement intégré.

Imaginez… Imaginez pouvoir faire un truc comme ça:

from super_framework import projets, config
 
# Tout est configurable et réassemblable, mais le framework offre des réglages 
# auto pour les usages simples
project, app, conf = projets.SimpleProject('name')
 
# Fichier de conf automatiquement créé, parsé et vérifié. Valeurs exposées en 
# CLI et overridables.
@config.source(file="foo.tml")
class Schema(config.Schema):
    foo = config.CharField(max_len=30, live=True)
    bar = config.DateField(optional=True, local=True)
    baz = config.TextField(
        verbose_name="Basile", 
        default="Je sers la science et c'est ma joie"
    )
 
# Lancé automatiquement à la phase d'init du projet
# Des events comme ça sont lancés pour chaque app, et chaque phase de vie de 
# chacune d'elles.
@project.on('init')
async def main(context):
    # un log sain automatiquement fourni
    app.log('Début du projet. Verbosité:', conf.log.level)
 
# Démarre l'event loop. Parse la ligne de commande et les 
# variables d'env, puis le fichier de conf. Mais seulement si le module n'est 
# pas importé (comme __name__ == "__main__")
# Print le fichier de log automatique dès le démarrage du programme
project.cmd()

Et imaginez que de ce petit script, ça scale sur 20 plugins qui peuvent communiquer, un système de settings live, de gestion d’erreurs et de logs aux petits oignons.

Imaginez que l’api bas niveau soit suffisamment flexible pour que les plus grands frameworks puissent réécrire exactement la même API qu’ils ont déjà en utilisant cette fondation. Imaginez que tous vos projets futurs soient du coup compatibles entre eux.

Vous pouvez imaginez longtemps, car ça n’arrivera jamais. Mais j’avais du temps à l’aéroport alors j’ai écrit cet article.

]]>
Accepter un ID mais retourner un objet pour les liens de Django Rest Framework 13http://sametmax.com/?p=23385http://sebsauvage.net/streisand.me/sametmax/index.php?20170608_095000_Accepter_un_ID_mais_retourner_un_objet_pour_les_liens_de_Django_Rest_Framework_13Thu, 08 Jun 2017 07:50:00 +0000DRF est une des perles de Django. De Python même. Comme marshmallow, requests, jupyter, pandas, SQLAlchemy ou l’admin Django. Python a tellement d’outils extraordinaires.

Mais aucune n’est parfaite, et une chose qui m’a toujours emmerdé avec celle-ci, c’est que si j’ai un modèle du genre:

class Foo(models.Model):
    name = models.CharField(max_length=64)
    bar = models.ForeignKey(Bar)

Et le serializer:

class FooSerialize(serilizers.ModelSerializer):
 
    class Meta:
        model = Foo

J’ai le choix entre soit avoir que des ID…

En lecture (chiant) :

GET /api/foos/1/

{
    name: "toto",
    bar: 2
}

Et en écriture (pratique) :

POST /api/foos/
{
    name: "tata",
    bar: 2
}

Soit avoir que des objets.

En lecture (pratique):

GET /api/foos/1/

{
    name: "toto",
    bar: {
       // tout l'objet bar disponible en lecture
    }
}
Et en écriture (chiant) :

POST /api/foos/
{
    name: "tata",
    bar: {
       // tout l'objet bar à se taper à écrire
    }
}

Il y a aussi la version hypermedia où l’id est remplacé par une URL. Mais vous voyez le genre : mon API REST est soit pratique en lecture mais relou à écrire, soit pratique en écriture (je fournis juste une référence), mais relou en lecture, puisque je dois ensuite fetcher chaque référence.

GraphQL répond particulièrement bien à ce problème, mais bon, la techno est encore jeune, et il y a encore plein d’API REST à coder pour les années à venir.

Comment donc résoudre ce casse-tête, Oh Sam! – sauveur de la pythonitude ?

Solution 1, utiliser un serializer à la place du field

class FooSerializer(serilizers.ModelSerializer):
 
    bar = BarSerializer()
 
    class Meta:
        model = Foo

Et là j’ai bien l’objet complet qui m’est retourné. Mais je suis en lecture seule, et il faut que je fasse l’écriture à la main. Youpi.

Pas la bonne solution donc.

Solution 2, écrire deux serializers

Ben ça marche mais il faut 2 routings, ça duplique l’API, la doc, les tests. Moche. Next.

Solution 3, un petit hack

En lisant le code source de DRF (ouais j’ai conscience que tout le monde à pas la foi de faire ça), j’ai noté que ModelSerializer génère automatiquement pour les relations un PrimaryKeyRelatedField, qui lui même fait le lien via l’ID. On a des classes similaires pour la version full de l’objet et celle avec l’hyperlien.

En héritant de cette classe, on peut créer une variante qui fait ce qu’on veut:

from collections import OrderedDict
 
from rest_framework import serializers
 
 
class AsymetricRelatedField(serializers.PrimaryKeyRelatedField):
 
    # en lecture, je veux l'objet complet, pas juste l'id
    def to_representation(self, value):
        # le self.serializer_class.serializer_class est redondant
        # mais obligatoire
        return self.serializer_class.serializer_class(value).data
 
    # petite astuce perso et pas obligatoire pour permettre de taper moins 
    # de code: lui faire prendre le queryset du model du serializer 
    # automatiquement. Je suis lazy
    def get_queryset(self):
        if self.queryset:
            return self.queryset
        return self.serializer_class.serializer_class.Meta.model.objects.all()
 
    # Get choices est utilisé par l'autodoc DRF et s'attend à ce que 
    # to_representation() retourne un ID ce qui fait tout planter. On 
    # réécrit le truc pour utiliser item.pk au lieu de to_representation()
    def get_choices(self, cutoff=None):
        queryset = self.get_queryset()
        if queryset is None:
            return {}
 
        if cutoff is not None:
            queryset = queryset[:cutoff]
 
        return OrderedDict([
            (
                item.pk,
                self.display_value(item)
            )
            for item in queryset
        ])
 
    # DRF saute certaines validations quand il n'y a que l'id, et comme ce 
    # n'est pas le cas ici, tout plante. On désactive ça.
    def use_pk_only_optimization(self):
        return False
 
    # Un petit constructeur pour générer le field depuis un serializer. lazy,
    # lazy, lazy...
    @classmethod
    def from_serializer(cls, serializer, name=None, args=(), kwargs={}):
        if name is None:
            name = f"{serializer.__class__.__name__}AsymetricAutoField"
 
        return type(name, (cls,), {"serializer_class": serializer})(*args, **kwargs)

Et du coup:

class FooSerializer(serializers.ModelSerializer):
 
    bar = AsymetricRelatedField.from_serializer(BarSerializer)
 
    class Meta:
        model = Foo

Et voilà, on peut maintenant faire:

GET /api/foos/1/

{
    name: "toto",
    bar: {
       // tout l'objet bar disponible en lecture
    }
}

POST /api/foos/
{
    name: "tata",
    bar: 2
}

Elle est pas belle la vie ?

Ca serait bien cool que ce soit rajouté officiellement dans DRF tout ça. Je crois que je vais ouvrir un ticket

]]>
Dell XPS 15 : une succession d’échecs 53http://sametmax.com/?p=23369http://sebsauvage.net/streisand.me/sametmax/index.php?20170601_110704_Dell_XPS_15___une_succession_d___echecs_53Thu, 01 Jun 2017 09:07:04 +0000J’aimais beaucoup mon Samsung 9 series, mais quand on utilise à outrance sa machine il faut la remplacer régulièrement. J’ai opté pour un Dell XPS 15, une version 15 pouces du modèle phare de la marque, puisque le XPS 13 a tant d’excellents retours. Ça faisait des années que je traînais sur un 13 pouces, et je voulais voir si coder sur un 15 allait vraiment rajouter au confort.

Le XPS 15 a plusieurs atouts. D’abord un écran superbe, quasiment sans bord, donc plus large que les 15 pouces traditionnels. Ensuite une carte nvidia intégrée. Et surtout, un port USB C thunderbolt avec lequel on peut théoriquement charger le PC, brancher ses écrans, faire passer de l’Ethernet, bref la promesse du monocable sur mon bureau malgré mon setup encombrant de 3 écrans et la fibre.

Marchant très bien avec un dual boot W10/Ubuntu, j’en ai profité pour lui plugger 32Go de Ram et 1To de SSD. La bestiole est donc supposée être un monstre de guerre qui devrait pouvoir avaler du travail de dev dans des conditions féeriques.

Après quelques mois d’utilisation, je peux vous affirmer que le produit n’est pas du tout à la hauteur du prix, à savoir plus de 2000 boules.

Bien que l’écran soit effectivement très confortable, et que les applications de tous les jours tournent sans soucis, l’intérêt du XPS 15 s’arrête là.

D’abord, il est lourd, le chargeur est énorme, et la batterie tient en moyenne 3h, pitoyable de nos jours. Ce n’est donc pas le meilleur ami du voyageur.

Mais surtout, il ne marche pas correctement. Et c’est bien ça le problème.

Pendant un mois les baffles ont tout simplement arrêté de produire un son cohérent, vomissant tel un métalleux bourré sans son micro la moindre note. Puis c’est revenu, sans explication, à la normale.

Un autre mois des écrans bleus incessants m’empêchaient tout simplement d’utiliser Windows jusqu’à ce que je tombe sur un thread de forum de support Dell que la marque a ignoré pendant longtemps. Un des utilisateurs recommande de downgrader le firmware du BIOS pour remédier au problème. Effectivement, ça marche.

Mais la réaction de Dell ? Désolé d’avoir niqué votre machine à un SMIC et demi ? Naaaa. Un mec poste laconiquement une vidéo YouTube d’un utilisateur sur internet d’une solution qui n’a pas marché pour moi. Et c’est tout. Le logiciel d’update DELL continue de suggérer des mises à jour qui refont planter tout le système.

Le port USB-C ne tient aucune de ses promesses. Parfois la charge s’arrête en cours de route sans prévenir. L’Ethernet n’a pas marché pendant plusieurs mois pour soudainement s’activer, mais uniquement sous Windows. Le triple écran qui marchait parfaitement sous Ubuntu et Windows a cessé de fonctionner sans prévenir. Maintenant au mieux je fais du dual screen sous Windows uniquement.

Si vous lancez un jeu, le laptop décide de temps en temps de faire tourner soudainement le CPU en mode éco, tuant les FPS et vous faisant perdre. Il se trouve que la machine chauffe trop, ce que vos doigts auraient pu vous signaler de toute façon. A croire que les ingés qui l’ont conçu n’ont jamais testé l’engin.

La solution ? Beaucoup de recherches (parce que j’ai que ça à faire, pallier aux erreurs de Dell sur une machine que j’ai payé cher pour gagner du temps dans mon travail) pour atterrir sur un autre thread du support Dell. Quelqu’un suggère de désactiver dans le BIOS Intel step. Ça marche, mais bouffe plus encore la maigre autonomie de la batterie.

Ce n’est pas la qualité de produit qu’on peut attendre d’une marque comme Dell, ni d’un modèle à ce prix. Mais surtout, l’absence totale de communication de Dell sur la question, le manque de réaction de leur part laisse à penser qu’ils ont fait une grosse erreur sur ce produit et espèrent que ça passe en faisant le mort.

Sinon j’ai aussi acheté un téléphone One Plus à la même époque, qui lui est toujours formidable pour un prix avantageux. Histoire de finir sur une note positive…

]]>
Vue, j’l’avais pas vu 50http://sametmax.com/?p=23281http://sebsauvage.net/streisand.me/sametmax/index.php?20170514_151042_Vue__j___l___avais_pas_vu_50Sun, 14 May 2017 13:10:42 +0000(Pour Max: je t’ai mis un exemple de code tout fait en bas de page car je sais que ça va te saouler de tout lire)

Elle était facile, mais ça fait des années que le blog est up, je peux pas avoir de l’inspiration tout le temps.

Dans le dernier article, je vous offrais votre dose maintenant obligatoire de bashing de l’écosystème JS. En l’occurrence en suggérant que React était un bouquet de roses avec plus d’épines que de pétales.

Mais bon, si les gens utilisent React, ça n’est pas QUE parce que c’est la mode. C’est parce que cette techno répond à un besoin de plus en plus impérieux en dev front end : avoir un outil valable pour créer des GUI avancées en JS.

Parce que le combo jQuery + moteur de template, ça nous a mené loin, mais on arrive au stade où ça scale plus.

Pas mal de tentatives ont été faites pour répondre au problème : knockout, angular 1, polymer, etc.

La nouvelle génération (react, riot, vue, angular 2+, etc) est beaucoup plus mature et performante, et offre des fonctionnalités très sympas:

  • DOM virtuel qui permet de faire des mises à jour fréquentes sur de très nombreux objets à l’écran sans freezer le browser.
  • Découplage très élégant des données et de leurs représentations.
  • Facilité de manipulation des éléments HTML, des events et du cycle de vie de tout le bordel.
  • Création de composants graphiques isolés et réutilisables.

En gros, partout où on faisait avant $(selecteur).trucmuche(element), on peut maintenant faire ça plus facilement, plus rapidement et plus proprement. (Par contre Vue/React/etc font pas l’AJAX, tournez-vous vers axios ou gardez jQuery sous le coude).

Bon, si ils offrent TOUS ces éléments là, pourquoi diable est-ce que j’ai une préférence pour Vue.JS plutôt que Riot, Angular ou React ?

Souvenez-vous, je reprochais essentiellement ceci à React:

  • Grosse courbe d’apprentissage. Ce qui impacte la productivité de tout nouveau dans l’équipe.
  • Mauvaise ergonomie du JSX qui du coup s’écrit, se lit et se debug lentement.
  • Mauvaise foi totale de la communauté qui prétend qu’on peut utiliser React sans la tonne de nutella autour, ce qui est comme argumenter qu’on peut faire du Java sans IDE.
  • Nutella sus-nommé qui est blindé d’huile de palme et de vidange.
  • Globalement une API inélégante et peu intuitive.

Mais alors, qu’est-ce que Vue.js fait de mieux ?

Ben tout, mes amis. Tout.

Légèreté

A l’heure où les codeurs hypes de la vibe du flex ont tous un fichier de conf webpack de 3 km, mais déjà obsolète et qui pétera à la prochaine upgade, Vue offre un point de vue rafraîchissant sur la question.

TOUTE, j’ai bien dit TOUTE, la puissance de vue.js est accessible avec une simple inclusion de balise script.

Vous en avez marre des pages de 3Mo ? Minifié et gzippé, Vue.js pèse moins de 30ko.

Dans un monde où il faut soit faire un site Web, soit faire une SPA (aux chiottes l’amélioration progressive !), Vue permet de ne remplacer que quelques bouts de vos pages si vous n’avez pas envie de tout transformer en un monstre de JS.

La doc, très bien faite, vous permettra de prendre l’outil en main en une après-midi. En buvant du thé.

Le tout, sans besoin d’aucun écosystème particulier. Aucun. Rien. Ca marche out of the box.

En gros, là où tout le monde vous vend du scale up, Vue vous permet de scale down.

Puissance

Malgré cela, Vue reste parfaitement adaptée aux gros projets. En fait, elle a été créée pour et par l’équipe du site du géant chinois, alibaba.com. Alors oui, c’est sûr, c’est pas Facebook et son milliard d’utilisateurs, mais comme mes projets ne servent pas 10 millions de pages par jour, contrairement à Alibaba, je pense que je suis ok.

Dans la pratique, qu’est-ce que ça veut dire ?

Et bien d’abord, Vue est plus rapide que React. Ouais ça fait mal au cul de lire ça quand on vient de finir d’optimiser son pipeline de rendu JSX, surtout que la techno a été créée pour la vitesse. Mais voilà, c’est le cas.

Vue supporte aussi parfaitement l’inclusion dans un écosystème plus gros si le besoin s’en fait sentir :

En gros, Vue peut faire absolument tout ce que les autres font. Mais ne vous oblige pas à commencer en sortant le bazooka. Vue est ce que React aurait dû être depuis le début.

Notez qu’on peut remercier les devs de React pour avoir popularisé de nombreux concepts que Vue utilise. Standing on the giants’ shoulders et tout, et tout. Vue n’aurait jamais existé sans React. Mais maintenant que Vue est là, on peut laisser React en paix.

Elégance

De par son design, Vue vous permet donc de commencer doucement, en ajoutant 30ko à votre projet et en l’utilisant un peu ici et là. Puis quand vous en avez besoin, vous pouvez commencer à utiliser des fonctionnalités avancées.

Par exemple, vous pouvez comme avec Angular 1 balancer toutes vos variables et binding dans le HTML de votre page en vrac. Et plus tard tout refactoriser en composant comme avec React. Tranquille.

L’API de Vue est petite, et surtout, facile à comprendre car tout est bien nommé, et bien rangé. Voyez plutôt:

Vue({
  el: "#app", // l'élément sur lequel attacher la vue
  created: function(){
    // code lancé au démarrage
  },
  mounted: function(){
    // code lancé quand la vue est attachée à la page
  },
  updated: function(){
    // code lancé quand la vue est mise à jour
  },
  destroyed: function(){
    // code lancé quand la vue est détruite
  }
  data: {
    // ben ici y a vous données statiques
  },
  methods: {
    // ici les fonctions à rendre disponibles dans le HTML
  },
  computed: {
    // ici on met les données à recalculer à la volée
    // à chaque refresh
  }
})

Voilà vous avez là 50% de l’API de Vue. Very hard indeed.

On sent partout que les devs ont apporté des soins à des petits détails comme:

<!-- Lance truc() juste au premier click.
Appelle preventDefault automatiquement. -->
<a v-on:click.once.prevent="truc()">Foo</a>

D’une manière générale, tout template Vue est du HTML valide, ce qui fait qu’il est très facile d’insérer du Vue sur un site existant.

Un petit bout de vue

Mais alors, pour tous ceux qui en sont restés à jQuery et handlebar.js, à quoi ça ressemble tout ça ?

Ben un todo ressemble à ça en Vue:

<!DOCTYPE html>
<html>
<head>
  <title>Todo</title>
  <script src="https://unpkg.com/vue"></script>
</head>
<body>
<!-- Cette partie va être contrôlée par la vue -->
<div id="app">
 
<!-- Quand on soumet le formulaire, on ajoute la tâche -->
<form v-on:submit.prevent="addTask(newTask)">
  <!-- L'input est maintenant lié à la variable newTask -->
  <p><input v-model="newTask"> <button>Ajouter</button></p>
</form>
 
<ul>
  <!-- Créer un li pour chaque tache dans mon array 'tasks' -->
  <li v-for="task in tasks">{{task}}</li>
</ul>
 
</div>
 
<script type="text/javascript">
app = new Vue({
  el: "#app", // j'attache cette vue à l'élément avec l'id App
  data: {
    tasks: [], // mes tâches seront stockées dans l'array 'tasks'
    newTask: "", // ce que contient l'input du formulaire
  },
  methods: {
    addTask: function(task){
      this.tasks.push(task); // on ajoute la tâche dans l'array
      this.newTask = ""; // on vide l'input
    }
  }
})
</script>
 
</body>
</html>

(Vous pouvez littéralement copier-coller ce code dans un fichier todo.html et ça marche. Essayez de faire ça avec React…)

Comme avec Angular/React/Riot on a séparé complètement la logique de manipulation des données de celle de l’affichage qui est mis à jour automatiquement quand les données changent.

Contrairement à React, on n’est pas obligé de créer un arbre complexe de composants qui transforme toute sa page en soupe de JS(X). Mais contrairement à Angular, on n’est pas obligé de rester sur cet exemple simple, et on peut créer une hiérarchie de composants.

Un composant peut complètement isoler le JS, le HTML et le CSS (qui n’affecte alors que le composant):

Et pour que ça marche, pas besoin de préprocesseur, pas besoin de ES6, ES7, typescript, babel, webpack, npm… Vous pouvez les utiliser. Sur un gros projet je me fais chier à setup ce qui vaut le coup. Mais vous n’êtes pas obligé.

La communauté

La communauté est importante pour un projet, et celle de vue est très agréable. Ce sont des gens polis, humbles, et compétents. Ils pensent aux petits détails. Regardez par exemple cette page pleine de jolis schémas.

En comparaison, la communauté React est criarde. Les confs des devs de Facebook sont faites par des présentateurs tout droit sortis de South Park. Quand on critique react, on se fait insulter personnellement sur twitter par les fan boys plutôt que de tenter de discuter, preuve systématique de l’absence d’arguments.

Enfin les seuls éléments donnés pour combattre les critiques sont les raisons des problèmes, un rappel de la taille des utilisateurs et des “moi j’aime” laconiques.

Mais faites un test. Prenez 3 dev, un react, un jquery, un vue. Faites leur faire un agenda CRUD avec recherche et autocompletion qui tape en Ajax dans un backend Django/Rails/Whatever. Donnez leurs des machines vierges. Et sortez le pop corn.

Pour le moment, React possède encore deux avantages: react native, et la masse (fb, les utilisateurs, le nombre de plugins, etc).

Mais honnêtement ? Il y a très peu de bénéfices à utiliser React plutôt que Vue sur la plupart des projets pur Web. Et un coût garanti d’être élevé.

Angular 1 est en train de mourir de l’abandon de Google. Après la sucette de l’incompatibilité d’Angular 2, je n’ai aucune confiance en la techno et ne compte donc pas réinvestir de billes dedans. De plus Angular 2+ souffre du même problème d’obligation d’installer la terre entière avant de commencer à coder.

Riot est une meilleure alternative, mais l’obligation de passer par des composants est un no-go IMO. Créer des composants pour moi est l’exception, pas la règle. Je le fais en dernier, à la phase de refactoring.

Donc ne vous emmerdez pas, prenez quelques heures pour jouer avec Vue, ça coûte pas cher, et c’est chouette.

————-

On me signale dans l’oreillette de linker dans la doc française.

]]>
Réaction à ReactJS 33http://sametmax.com/?p=23244http://sebsauvage.net/streisand.me/sametmax/index.php?20170510_203923_Reaction_a_ReactJS_33Wed, 10 May 2017 18:39:23 +0000Grand utilisateur de jQuery, formateur Angular et maintenant adorateur de VueJS, vous vous demandez sûrement ce que je pense de React. Si, je le sais, mon avis est pour vous comme un phare dans la nuit sombre du frontend engluée dans le brouillard de JavaScript.

Après tout, Facebook est codé avec cette techno pixel par pixel, et ils servent des milliards de pages chaque jour. Ça ne peut pas être mauvais. Ce ne sont pas de cons quand même.

Et puis tout le monde en parle, les asticots gigotent autour des restes du gigot d’ordre que les devs des GAFAS tentent de mettre au menu dans leur régime sans sel et sans typage.

Alors merde, quoi, react, keskeçavo ?

Je vais passer peut être pour un réact (hashtag lol), mais franchement le gigot au brouillard, c’est pas mon plat préféré.

Taillons un peu JS, ça m’avait manqué.

Mon royaume pour un hello world

React est tellement chiant à setuper que la doc officielle vous propose le hello world dans un code pen histoire de pas vous faire fuir tout de suite.

En fait, si pour vous installer un module avec npm/yarn/bower (plutôt que de copier le truc directement ou d’utiliser un CDN) est déjà un truc qui vous fait grogner, vous êtes loin derrière.

Il va vous falloir un outil de build (gulp, grunt ou l’usine à Vespene Webpack) et la série de recettes obsolètes customisées trouvées sur un coin de github pour connecter tous les bouts de votre pipeline. React bien sûr, mais aussi Babel pour transformer le JSX en JS.

Babel suit la left-pad philosophie, à savoir que tout est configurable et éclaté en centaines de petites dépendances et settings. C’est tellement chiant que des packages existent, appelés “presets”, dont l’unique but est de configurer Babel pour une tâche particulière.

Une fois que vous avez tout ça up, vous vous allez à la pêche au tuto, seulement pour remarquer que tout le monde code en ES6, voir ES7, et vous rajoutez donc un peu plus de plugins à tout ce bordel. Allah vous garde si vous tentez d’utiliser TypeScript.

Et vient alors le moment tant attendu pour faire coucou de la main programmatiquement. Ça foire, bien entendu. Le debugger vous pointe sur un bundle.js de plusieurs Mo, et vous apprenez que le support des sources maps est inégal d’un navigateur à l’autre.

Bienvenue.

Le X c’est pas toujours excitant

Une fois passée la douloureuse expérience de mettre en place votre environnement de travail, vous trouvez un certains confort. L’autoreload de la page est franchement pratique, et pouvoir utiliser l’unpacking (pardon le spread), les valeurs de paramètres par défaut et les arrow functions sans vous soucier de la compat du navigateur c’est quand même cool. Avec un webpack tout bien huilé avec amour (et douleur), vous pouvez faire des imports en JS et on a presque l’impression d’utiliser un langage de programmation.

Et puis le JSX, de loin ça à l’air pas mal ! Du HTML directement dans le JS ça parait un peu bizarre mais on vous le vend comme un avantage : finis les langages de templates limités, vous pouvez utiliser la pleine puissance (hum…) du langage JavaScript pour créer vos balises.

Sauf que non, le JSX, ça pue du cul.

D’abord, il y a le fait que toutes les structures sont à faire en JS. Les conditions, les concaténations et bien entendu, les boucles. Donc vous avez une liste de noms et numéros de téléphone, en VueJS, vous faites:

<ul>
    <li v-for="pers in persons" v-if="pers">
        <strong>{{ pers.nom }} </strong>: {{ pers.tel }} 
    </li>
    <li v-else>
        <em>Nobody's here!</em>
    </li>
</ul>

Mais en React, vous allez faire péter une expression ternaire et une fonction anonyme en plein milieu rien que pour l’occasion:

<ul>
    {
      (this.state.persons)
        ? this.state.persons.map((pers) => (
            <li><strong>{ pers.nom } </strong>: { pers.tel } </li>
        ))
        : (
            <li>
                <em>Nobody's here!</em>
            </li>
        )
    }
</ul>

Vous la sentez bien la puissance de JavaScript là ?

Et attention à ces boucles, car dedans vous guette cette erreur qui va vous poursuivre jusque dans vos cauchemars:

SyntaxError: Adjacent JSX elements must be wrapped in an enclosing tag

Babel vous signale gentiment que ne pouvez pas produire un snippet de JSX qui contienne plus d’un élément à la racine. Donc il faut TOUT wrapper dans un container. TOUT. Vous allez avoir vite des DIVs et des SPANs inutiles partout, juste pour faire plaisir à React. C’est absurde. C’est à vomir. Ca nique votre CSS et remplit vos sessions “examinez un élément” de tendinites dues aux clics pour déplier tout l’arbre des emballages cadeaux de vos balises. Et aussi, nique la sémantique.

Pour éviter ça vous allez tenter d’inliner un maximum de trucs dans une seule expression JSX ou tout foutre dans des arrays. Car je ne l’ai pas précisé ? Les arrays de JSX sont automatiquement et magiquement convertis en sous-éléments. Et du coup vous pourrez profiter au maximum des qualités de lisibilité de JS.

JSX est bourré de petits trucs comme ça, pour faire plaisir. Par exemple, j’ai un bouton, quand je le clique il delete la personne de la ligne de mon agenda. Je mets aussi une classe pour tous et une selon que la personne est importante ou non. Un prevent default pour éviter que le browser recharge la page si je suis dans un form.

En Vue, je passe un objet qui dit quelle classe afficher ou non. Le click handler contient une instruction prevent qui me permet d’appeler preventDefault automatiquement. Et j’appelle deletePerson tout naturellement :

<button class="{'delete-person': true, 'important-person': pers.isImportant}" 
        v-on:click.prevent="deletePerson(pers)">
    Delete
</button>

En react, on ne peut pas passer de paramètre à son handler. Il faut le passer dans une closure. Mais alors la closure va recevoir l’objet event, qu’on doit donc faire suivre à notre handler, afin qu’il puisse appeler preventDefault à la main. A noter aussi que class s’appelle className. Et n’accepte que des strings donc la concaténation se fait à la mano.

// plus haut on appelle preventDefault dans handleDelete
 
<button className={'delete-person ' + (pers.isImportant ? 'important-person': '')}
        onClick={(e) => this.deletePerson(pers, e)}>
    Delete
</button>

Ce n’est pas juste chiant à lire, c’est surtout hyper chiant à trouver, à taper et à debugger.

Un peu de nutella sur votre confiture ?

React, c’est verbeux, il va falloir vous y faire. Il suffit de comparer le code nécessaire pour faire une TODO en react avec les autres frameworks.

Mais ce n’est pas juste ça qui est lourd.

Non, le vrai truc qui est super pesant, c’est que react est un cancer. Quand il est utilisé, il contamine tout.

Par principe, une fois que vous utilisez react, il faut mettre TOUTE VOTRE PAGE en react. Pas juste un petit bout. Par là j’entends que 90% de votre HTML va devoir migrer dans le code JSX. Votre beau code HTML bien propre, converti en cette monstruosité de mélange entre le langage le plus dégueulasse du monde et un monstre mimic qui essaye de se faire passer pour du HTML pour vous bouffer.

Or, toute l’idée c’est de faire des composants, de diviser votre pages en plus petits bouts. Mais voilà, React n’a rien prévu de simple pour la communication. Pour passer des données des composants enfants, il faut les passer via les attributs de balise HTML (appelés les props, pour faciliter la rechercher Google). Si vous avez 5 niveaux d’imbrications, vous vous tapez ça 5 fois.

Plus amusant, il n’y a aucun mécanisme pour passer des infos de l’enfant aux parents. La méthode standard est d’écrire puis passer manuellement un callback du parent à l’enfant, via props, et appeler ce callback dans l’enfant avec la valeur que le parent utilise ensuite. POUR. CHAQUE. PUTAIN. DE. VALEUR.

Passer des callbacks, ça va 5 minutes. Et ça ne résout pas un problème de communication entre composants parallèles, c’est à dire ni parent, ni enfant. Du coup tout le monde finit par utiliser une lib supplémentaire type EventEmitter pour servir de bus de communication.

Quand vous entendez les gens se plaindre de la difficulté d’utiliser l’écosystème de react, les fans répondent souvent que l’écosystème n’est pas obligatoire. On peut très bien s’en passer sur un petit projet.

Sauf que react est absolument inutilisable sans. Sans un bus d’event, un transpiler ES6 + JSX, un builder et un hot reloader au mininum, le projet ne dépasse jamais le stade du prototype.

Mais bon soyons franc, beaucoup de projets react tout court ne dépassent jamais le stade du prototype. On parle de codeurs JS là.

Etat

Les props ne doivent jamais changer. Seul l’état d’un composant react peut changer, ce qui trigger un nouveau rendu du composant.

Mais l’état lui-même est en read-only. On est supposé uniquement créer un nouvel état à chaque fois et remplacer l’ancien.

Au début on le fait à la main, mais JS n’est pas vraiment fait pour faire de l’immutabilité, et ça devient uber chiant très vite. Changer la propriété d’un objet qui est lui même dans un array demande de recréer tout l’array et l’objet. A chaque fois.

On se tourne alors vers des libs (encore une) type immutable.js qui fournit des listes et maps qui sont immutables et permettent de faire ces opérations sans y laisser ses jours de congé.

Une fois de plus, les connards qui vous disent qu’on peut faire du react sans la tonne de boiler plate qu’on voit dans les tutos ne le font jamais eux-mêmes. Parce que oui, on peut faire Paris-Amiens à pied en théorie, mais bon…

Des décisions à la con

Clairement, react a été fait pour créer des UI. Mais au bout d’un moment, les utilisateurs se sont réveillés et ont voulu une encapsulation pour des composants non UI. Mais react ne sait pas faire. Quand vous avez donc un composant non UI, par exemple la déclaration de votre routing, vous le déclarez… en JSX:

  render((
      <Router history={browserHistory}>
        <Route path="/foo" component={FooView}/>
        <Route path="/bar" component={BarViw}/>
      </Router>
  ), document.getElementById('app'))

Votre app va devenir très vite une pyramide de composants, certains qui s’affichent, d’autres non, tous se passant en cascade des données les uns aux autres.

Et au passage, quel est l’abruti qui a décidé des noms des méthodes des cycles de vie comme getInitialState, componentWillMount et componentDidMount ?

Surtout que vos méthodes et les méthodes héritées de la classe du component sont dans le même espace de nom.

Le bonheur des stores

Un truc dont on peut vraiment se passer par contre, ce sont les stores. Flux, redux, vuex, etc. On peut utiliser n’importe quelle solution pour stocker l’état de son projet côté client.

Mais si vous voulez profiter des promesses de react, comme le time travel et la concurrence parfaite, il vous faudra un store.

“store” c’est le nom huppé que react donne à ses modèles. Je ne vais pas rentrer dans les détails, et vous laissez décider par vous même du truc. Voici, comment la doc vous recommande d’ajouter une personne dans une liste d’un agenda avec redux, la store la plus populaire:

// Les imports
import React from 'react';
import { render } from 'react-dom';
import { createStore } from 'redux';
import { Provider } from 'react-redux';
 
// creation du store
const initialState = {'agenda': []};
 
function reducer(state=initialState, action){
  switch (action.type) {
    case 'ADD_PERSON':
      return {
        'agenda': [..., action.object]
      }
    default:
      return state
  }
}
 
const store = createStore(reducer);
 
 
// creation de l'action d'ajouter un objet dans le store
 
function addPersonAction(obj){
    return {
        'type': 'ADD_Person',
        'object': obj
    };
}
 
 
export function addPerson(Person){
    store.dispatch(addPersonAction(Person));
}
 
 
// composant qui affiche le form de l'agenda et la liste des personnes
var Agenda = React.createClass({
 
  handleAdd: function(){
      addPerson({
        "name": this.refs.name.value,
        "tel": this.refs.tel.value
      })
  },
 
  render: function(){
 
    return <form onClick={this.handleAdd}>
        <p><input ref="name" /><input ref="tel" /><button>Add</button></p>
    </form>
 
    <ul>
        {
            this.store.agenda.map((pers) => (
                <li><strong>{ pers.nom } </strong>: { pers.tel } </li>
            ))
        }
    </ul>
  }
 
 
});
 
 
// adapter qui permet de passer le store à l'agenda
const AgendaContainer = connect(function(state){
    return {'agenda': state.get("agenda")};
})(Agenda);
 
 
// affichage du bouzin
render((
<Provider store={store}>
  <AgendaContainer>
</Provider>
), document.getElementById('app'))

Vous imaginez bien que trouver ça tout seul a été un bonheur. Parce que oui, la doc est absolument à chier, dans la longue tradition des stacks JS modernes.

]]>
Le don du mois : vue.js 16http://sametmax.com/?p=23211http://sebsauvage.net/streisand.me/sametmax/index.php?20170501_103743_Le_don_du_mois___vue.js_16Mon, 01 May 2017 08:37:43 +0000Le pognon rentre à nouveau et c’est donc le retour du don du mois.

Ça ne fait que quelques temps que j’utilise Vue.js, mais globalement c’est déjà mon outil par défaut pour toute UI en JS.

J’ai encore des demandes de formations et projets pour Angular 1 et React, mais si j’ai le choix il n’y a aucune hésitation.

J’ai essayé quelques alternatives, comme Riot, mais on arrive jamais à cette combinaison parfaite de simplicité, légèreté, puissance et performance. Ce projet est un petit bijoux du monde de l’open source. Un truc rare en Javascript.

Bref, c’est bien beau de cracher toujours sur JS, mais ça résout pas le problème. Il faut aussi aider, et c’est donc pour ça que je fais un don de 50 €, par ici.

Et si vous regrettiez l’époque de la simplicité de jQuery mais que vous avez envie de quelque chose qui automatise bien plus comme un framework moderne, vous savez ce qu’il vous reste à essayer :)

]]>