Avec Alex d'Open Food Facts

Un historique de toutes nos réunions

Table des matières

mercredi 14 février 2024

La voix du secrétaire (Jean)

Présents à la réunion, en fonction de la disposition autour de la table :

Laurent (B),
moi,
Emmanuel,
Sébastien,
Laurent (R),
et Alex.

Nous avons mangé des pizzas calzone, au thon, Santa Maria et au fromage, des pâtes (je ne sais plus lesquelles) des crèmes brûlées, des tiamisus et une mousse au chocolat. Nous avons bu un Kir, de l'Orangina, de la bière, du rosé et du café (déca ou ristretto), ainsi que de l'Amaretto et du Lemoncello offerts par la maison.

Nous avons parlé de Perl, Internet informatique et points divers.

Perl

Le samedi précédent, c'était l'Assemblée Générale de l'association. Alex avait prévu d'y venir. Il est arrivé à 14h pile à la porte de la Fondation pour le Progrès de l'Homme et a trouvé porte close. En fait, les participants à l'AG étaient au restaurant Cuba Compagnie Café ou en chemin entre les deux lieux. Alex a donc renoncé.
Un autre problème pour Alex est que la date donnée sur le site web de l'association était « mercredi 10 février 2024 ». La date était incohérente. Fallait-il lire « samedi 10 février 2024 » ou « mercredi 14 février 2024 » ? [ Voici l'explication de cette incohérence. En 2021 et en 2022, les AG ont eu lieu un mercredi soir en téléprésence. Pour l'occasion, la page de notre site indiquait « aura lieu le mercredi 24 février 2021 en téléprésence ». En 2023, nous sommes revenus à la formule précédente, une réunion en présence physique un samedi après-midi. Nous avons adapté la page web pour indiquer « 11 février 2023 » et « à la FPH », mais nous avons oublié de changer « mercredi » en « samedi ». Le même oubli a eu lieu un an plus tard pour l'AG du samedi 10 février 2024. ]
Laurent R a assisté à l'AG en téléprésence. Il nous signale que la transmission du son était très mauvaise. Sébastien pense que cela vient du fait que la FPH est une fondation suisse avec le siège à Lausanne et un établissement à Paris et que leur connexion Internet en est le reflet. Donc lors de notre AG, les paquets quittaient Paris pour aller à Lausanne, puis revenaient vers le datacenter en région parisienne hébergeant notre serveur Discord pour être acheminés jusqu'au domicile de Laurent. Pour une téléconférence, ce fonctionnement n'est pas idéal, loin de là.
Habituellement, je rédige le compte-rendu dans les jours qui suivent et je le diffuse sur le dépôt SVN de l'association. Après validation par les autres membres du CA, je convertis le CR en L^AT_EX, je l'imprime et, lors d'une réunion au restaurant, je le fais signer par les membres présents du CA. Cette année, cela ne sera pas nécessaire, car il n'y a eu aucun changement au CA ni au bureau, donc pas de déclaration à faire à la banque ou à la Préfecture de Police. Il y aura juste un exemplaire à coller dans le registre des AG à la Maison de la Vie Associative et Citoyenne du 17^e arrondissement et je ne pense pas que ce soit nécessaire de faire signer ce CRAG par plusieurs personnes. Donc ce soir-là il n'y a pas eu de séance de signature (de plus c'était vraiment trop proche de l'AG) et il n'y en aura pas non plus lors des prochaines réunions.
La présence d'Alex fait suite à notre rencontre au salon Open Source Experience 2023 où il tenait le stand d'Open Food Facts. Nous avions alors convenu que nous pourrions organiser des actions communes sur le logiciel. Il nous décrit sommairement l'organisation du logiciel et les points à traiter. Parmi ces points, j'ai retenu :
1. régorganiser les CGI pour que ce soit plus clair,
2. éventuellement, utiliser un module moderne tel que Dancer2 ou Dancer2 + PSGI,
3. documenter les hashmaps, nombreux dans le logiciel, en expérimentant avec une technologie récente comme Corinna (le calcul du Nutriscore v2 peut être un bon module pour cette expérimentation),
4. améliorer l'utilisation des outils de l'écosystème Perl sur le projets (code coverage, debugger, intégration codium).
Alex précise que certains points (ceux ci-dessus ou d'autres) seront traités par un stagiaire dans le cadre du Google Summer of Code.
Quelles dispositions pratiques pour ces actions sur Open Food Facts ? Pour la date, compte tenu des contraintes professionnelles de la plupart des participants, cela serait plutôt un samedi et un dimanche. Alex créera un sondage sur Framadate pour savoir ce qui convient le mieux à chacun. Pour le lieu, nous avons pensé à la FPH, mais un ennui est que depuis peu, la FPH interdit les réunions le dimanche, pour ne pas gêner les habitants des immeubles voisins. Ou bien la Cité des Sciences et de l'Industrie, où nous avons tenu les Journées Perl à plusieurs occasions par le passé. Un inconvénient est que la Cité des Sciences impose que l'événement soit ouvert au grand public. On peut résoudre cet inconvénient en installant un stand Open Food Fact dans une salle et en réservant une autre salle pour les développeurs. Une troisième possibilité est d'utiliser Les Arches Citoyennes, où Open Food Facts dispose d'un local pour encore quelques mois.
Alex évoque un problème dans le développement d'Open Food Facts. Pour évaluer la qualité des scripts de tests, il utilise Devel::Cover. Hélas, mod_perl s'intègre mal avec Devel::Cover. En effet, mod_perl lance des processus et les arrête, ce qui ne permet pas à Devel::Cover de rassembler comme il faut ses statistiques d'exécution.
Pour le débugage, la situation est un peu meilleure. Alex utilise le débugueur en ligne de commande et il est à l'aise avec ce débugueur. Néanmoins, il pense aux éventuels stagiaires et nouvelles recrues qui préféreraient disposer d'un débugueur graphique. Est-ce qu'un programme fonctionnant sous mod_perl peut être analysé par un tel débugueur ?
Était-ce à l'occasion de la question précédente ou pour tout autre chose ? Laurent B a demandé si les environnements de développement pour Perl étaient toujours maintenus, à commencer par Padre.

Internet

Laurent B a apporté une épreuve pour la nouvelle version des cartes que nous distribuons dans les salons. Cette carte contient un QR code pointant vers notre site web. Enfin, théoriquement. Car Laurent a utilisé un générateur de QR code qui lui a accordé une période d'évaluation gratuite de 15 jours. Que se passera-t-il dans 15 jours ? Les QR codes déjà existants seront-ils encore valides ? La question se pose, car il est fort possible que le QR code ne pointe pas directement vers notre adresse web, mais vers un « raccourcisseur d'URL » qui redirige vers notre adresse et qui en profite pour accumuler des données sur les utilisateurs du QR code et leurs habitudes de navigation. En fait, comme le souligne Sébastien, il vaudrait mieux utiliser un logiciel hors-ligne générant des QR codes, idéalement un module Perl.

Informatique

Nous avons évoqué le passage à la version majeure suivante dans le cas de certains langages de programmation : Perl 5 → 6, Python 2 → 3 et Ruby 1 → 2. Dans ces trois cas, la transition s'est mal passée. Dans notre cas, l'annonce de Perl 6 au début des années 2000 a incité le grand public à penser que tout nouveau développement sur Perl 5 était arrêté. Par ailleurs, Perl 6 a mis du temps à sortir et ce même grand public a pensé que cela ne valait pas le coup d'attendre. Peut-être aurait-il fallu renommer Perl 6 en Raku dès le début. Cela n'aurait pas changé grand-chose pour l'impression que Perl 6 / Raku était du vaporware, mais au moins cela aurait montré que Perl 5 continue à évoluer.
Dans le cas de Python, la communauté Python 2 comportait schématiquement deux catégories d'individus, les scientifiques et les développeurs web (appelés ensuite « webeux » pour faire court). L'annonce du développement de Python 3 a été chaudement accueillie par les webeux, mais l'accueil par les scientifiques était plus tiède. Il était prévu un utilitaire de conversion 2to3 (tout comme il était prévu un utilitaire 5to6 pour Perl). Cet utilitaire a-t-il donné les résultats escomptés ? Peu importe, les webeux ont abandonné Python 2.6 et ont réécrit en Python 3.0 tout ce qui les intéressait. Les scientifiques, adeptes du « Si c'est pas cassé, faut pas réparer. », ont continué à utiliser leurs bibliothèques écrites en Python 2.6 et à les maintenir. Ultérieurement, il y a eu une version 2.7 développée par les scientifiques pour les scientifiques, tandis que les webeux passaient à la 3.1, puis la 3.2 jusqu'à, pour l'instant, la 3.12. Toujours est-il que Python a moins souffert que Perl de son changement de version majeure.
En revanche, Ruby a beaucoup plus souffert de son passage de la version 1 à la version 2. La machine virtuelle de la version 2 avait de gros problèmes de fiabilité. Également, la politique d'évolution de Ruby pose quelques problèmes : les versions mineures sont publiées à date fixe et cette date de publication est fixée au 25 décembre de chaque année. Peut-être que cette date ne pose pas de problèmes au Japon, pays d'origine de Ruby, mais dans le reste du monde, cela correspond à un ralentissement de l'activité, sauf dans les domaines directement liés à Noël. Moralité de tout cela, Ruby a presque totalement disparu de la scène.
Un langage qui n'a pas eu de problème, c'est PHP, qui est passé de la version 5 à la version 7 en abandonnant la version 6 sans tambours ni trompettes et sans faire parler de lui en termes négatifs.
Il a été question des logiciels de gestion de parc ou de déploiement de machines. Comme c'est un domaine éloigné de mes préoccupations, je le connais mal, j'ai donc retenu assez peu de détails. Il y a :
1. cfengine, le premier de tous,
2. Ansible,
3. Chef, un logiciel dans lequel les configuration ne sont pas écrites en utilisant un DSL (langage dédié) mais directement avec du code Ruby,
4. Salt.
Salt se base sur la métaphore des mines de sel. Les participants de notre réunion qui l'ont essayé ne comprennent pas du tout le rapport entre la gestion de configuration d'un parc informatique et l'extraction du sel gemme. À l'inverse, Chef se base sur une métaphore culinaire, avec des ingrédients et des recettes. On voit très bien le rapport entre une recette et une procédure d'installation. Quant à Ansible, son nom évoque un système de communication instantanée, imaginé par Ursula Le Guin et repris ensuite par Orson Scott Card.
Nous avons rappelé deux règles de programmation destinées à nous décourager d'utiliser des astuces de programmation et à nous encourager à faire simple. Il y a la règle zéro de Perl Best Practices,
Codez toujours comme si le type qui maintiendra un jour votre code est un psychopathe dangereux qui sait où vous habitez.
et il y a une règle due à Brian Kernighan et reprise en exergue du chapitre 18 de PBP
Le débogage est deux fois plus dur que l'écriture du code ne l'a été. C'est pourquoi si vous écrivez du code aussi intelligent que possible, vous n'êtes par définition pas assez intelligent pour le déboguer.
Quelqu'un a entendu à son travail la discussion entre deux collègues :
-- J'ai lancé un git push sur la branche master et j'ai un message d'erreur.
-- Réessaie avec git push --force.
Il y a de quoi avoir un sentiment d'horreur, ou au moins de mauvais pressentiments.
Git est un gestionnaire de versions. Ce qui n'empêche pas que l'on trouve quelques utilitaires qui n'ont rien à voir avec la gestion de versions de fichiers ou la gestion de versions de logiciels. Ainsi, il existe une commande git column qui permet de formatter des données sous forme tabulaire, avec des colonnes bien alignées.
Il a été question un peu de PostgreSQL et de l'utilisation de JSON dans cette base de données. On peut même créer des index sur des données stockées dans un champ JSON.

Divers

Ce soir-là, il y avait un match de foot-ball. Contrairement à notre réunion de décembre, il n'y avait personne au restaurant qui soit intéressé par le foot-ball. En revanche, Laurent B a rencontré de nombreux spectateurs se rendant au Parc-des-Princes pour assister à ce match. Laurent ne savait pas quelles étaient les équipes en présence. Il a cru deviner que les spectateurs dans son métro parlaient en espagnol (c'était le cas) mais d'un autre côté, un autre détail lui laissait penser que c'étaient des grecs (ce n'était pas le cas).
Puisqu'il était question d'espagnols, rappelons que l'Espagne a une frontière commune avec le Royaume-Uni.
Cela fait donc deux frontières terrestres entre le Royaume-Uni et l'Union Européenne, puisqu'il faut tenir compte aussi de la frontière entre l'Irlande du Nord et la République d'Irlande. Cela dit, cela pose quelques gros problèmes, car il était convenu que la frontière entre les deux Irlande serait très perméable. Donc, pour instaurer une frontière économique entre le Royaume-Uni et l'Union Européenne, il a fallu imaginer une frontière fictive en Mer d'Irlande. Les marchandises passent sans aucun encombre de la République d'Irlande à l'Irlande du Nord ou inversement, mais elles subissent des contrôles douaniers lors de la traversée d'Irlande du Nord vers l'Écosse ou vers le nord de l'Angleterre. Un vrai casse-tête !