À la suite immédiate du POSS 2019

Un historique de toutes nos réunions

Table des matières

mercredi 13 novembre 2019 (précédent)
mercredi 12 février 2020 (suivant)

Tous les comptes-rendus

mercredi 11 décembre 2019

La voix du secrétaire (Jean)

Présents à la réunion :

Emmanuel,
et moi.

Emmanuel et moi avons mangé exactement la même chose : des nems au poulet, une entrecôte et un fondant au chocolat. En revanche, il a bu un Orangina et moi un mojito.

Il a été question du POSS, et de points divers.

Paris Open Source Summit

La date théorique de la réunion coïncidait avec la fin du POSS 2019 et avec la grève des transports publics. Emmanuel et moi avons quand même décidé de tenir cette réunion pour les raisons suivantes. Évidemment, je parle pour moi, mais je pense que le raisonnement d'Emmanuel était très voisin de ce que j'expose ci-après. Le mardi soir, Emmanuel et moi avons pris l'une des rares lignes en fonctionnement, le tram T3b, qui parcourt le boulevard des Maréchaux jusqu'à la Porte d'Asnières. Il était environ 18 heures et le tram était bondé, autant que la ligne 13 quand elle fonctionne. Le mercredi soir, j'aurais eu en plus le totem à transporter, je me voyais mal retenter de prendre le tram à la même heure. Une autre solution envisageable aurait été de prendre un taxi ou de faire venir un proche en voiture, mais c'était irréaliste, compte tenu des bouchons dus à la grève. Et pour Emmanuel, cela aurait été encore pire, car sa voiture ou son taxi serait passé au voisinage du Parc des Princes, un soir de match de foot-ball. Donc nous avons résolu d'attendre la fin des heures de pointe. Le T3b fonctionnerait-il après 19h30 ? Non. Nous avons donc décidé de rejoindre la ligne 1, la seule avec la ligne 14 à fonctionner normalement et sans restriction d'horaire. La station Reuilly-Diderot n'était la plus proche, mais pas loin, (7,7 km contre 6,3 km pour aller à « Louvre-Rivoli ») donc autant aller à notre restaurant habituel, tenir notre réunion mensuelle et prendre le métro ligne 1 plus tard dans la soirée pour regagner nos pénates respectives.
C'est ainsi que de 17h45 environ à 19h35, nous avons traversé une partie de Paris à pied. Heureusement, il ne pleuvait pas et la température était relativement clémente pour un mois de décembre. J'étais chargé d'un sac-à-dos ne contenant ni PC ni chargeur de PC, d'un sac Booking en bandoulière et du totem de l'association. Avec cette charge, je n'ai pas eu de problème pour faire les 8 km entre les docks d'Aubervilliers et Reuilly-Diderot (Open Street Map et GraphHopper indiquent 7,7 km, mais notre itinéraire n'était pas exactement celui proposé donc j'arrondis par excès). Emmanuel était chargé d'un sac-à-dos avec PC et chargeur de PC, d'une petite sacoche et d'un sac du même genre que les sacs Booking, mais plus gros, sans bandoulière et avec des anses qui menaçaient de craquer à chaque instant. D'où une position beaucoup moins ergonomique et une fatigue accrue. Je ne sais pas si Emmanuel avait des crampes ou des élongations dans les muscles des jambes, mais j'ai vu qu'il était bien content de trouver une chaise à l'arrivée au Philos'off.
J'étais muni d'un livret (éditions Taride ou L'Indispensable) donnant les plans de chaque arrondissement de Paris sur une double-page (ou parfois, la moitié de l'arrondissement sur une double page et l'autre moitié sur la double page suivante). Grâce à cela, nous avons pu suivre un itinéraire assez direct sans détour inutile. Il n'y a que tout à la fin du trajet que j'ai été désorienté, à cause d'une erreur qui dure depuis la première fois où nous sommes allés manger au Philos'Off. Emmanuel avait l'air de situer le restaurant sur le trottoir sud du Boulevard Diderot, alors que je croyais qu'il était sur le trottoir nord. C'est parce que les autres mois, pour venir à la réunion, je prends la ligne 1 dans le sens ouest → est et que, lorsque je sors de la bouche de métro, je m'imagine encore être face à l'est, avec le nord à ma gauche et le sud à ma droite. J'ignore complètement le fait que je quitte le quai du métro par un escalier en queue de train orienté dans le sens inverse de la marche du train et j'ignore complètement le fait qu'en été, lorsque le soleil n'est pas encore couché, il est caché par les immeubles devant moi lorsque je sors de la bouche de métro et non pas par les immeubles derrière moi.
Comme les années précédentes, nous étions à côté du stand Ada France. Ceux qui tenaient le stand ont joué de malchance cette année. Ils avaient prévu de proposer divers fascicules et plaquettes, qui devaient leur être livrés le mardi matin par coursier. La livraison a eu lieu le mercredi à 12h30. Donc, pendant un jour et demi, ils ont dû se contenter d'une demi-douzaine d'affichettes scotchées au mur (dont une célébrant le 204^e anniversaire d'Ada Lovelace, née le 10 décembre 1815) et rien à distribuer. Emmanuel se souvient d'avoir eu le même problème il y a plusieurs années lorsqu'il devait tenir un stand Red Hat. À l'inverse, pour le stand des Mongueurs, tout a été apporté par Emmanuel et moi. À noter qu'Emmanuel était chargé également avec le matériel pour le stand Borsalinux. Il était donc encore plus chargé le mardi matin que le mercredi soir. Certes, il a moins marché le mardi matin que le mercredi soir et les poignées de son sac ne montraient pas encore qu'elles allaient rendre l'âme, mais malgré tout ce déplacement n'a pas été une partie de plaisir.
Compte tenu des problèmes de transport, il y avait beaucoup moins de monde cette année au salon. Quelques associations, en fait assez peu, ont jeté l'éponge. Et je n'ai vu aucun stand inoccupé chez les entreprises payantes. D'un autre côté, peut-être que ces stands professionnels étaient animés par, disons, 3 personnes alors que 5 étaient prévues, je n'ai aucun moyen de savoir. C'est surtout les visiteurs qui ont déserté le salon. J'ai entendu dire que pour la première keynote du mardi, en plus des orateurs, il y avait cinq spectateurs dans l'auditorium. Emmanuel et moi avons eu des échos du salon nautique et du salon du cheval, qui avaient lieu en même temps à d'autres endroits, c'était la même chose, il y avait plus d'exposants que de visiteurs. Cela dit, au moins le mardi, nous avons eu l'impression d'avoir autant de personnes s'arrêtant pour demander des explications ou pour faire un brin de discussion que les années passées. C'est vraisemblablement parce que d'autres exposants n'hésitaient pas à faire un tour dans le salon, faute d'avoir des visiteurs eux-mêmes.
Parmi les visiteurs du mardi, il y en a eu un dont nous nous serions bien passés. Il est arrivé à notre stand, a lu le totem, puis nous adressé la parole à peu près en ces termes :
Ah, Perl fait du SQL ? Perl, c'est nul, il ne sait pas faire du multi-niveau. Alors que la base de données Pick, elle, sait faire du multi-niveau.
Puis il a continué avec une diatribe contre Perl et SQL, mentionnant au passage d'autres bases de données capables de faire du multi-niveau comme Reality ou Universe. La bonne réaction aurait été de répondre en rigolant ainsi
HoH HoH HoH ! LoL !
Mais il n'aurait pas compris le jeu de mots. [ Et si vous, de votre côté, vous avez compris le jeu de mot sans essayer les liens hypertextes, vous pouvez vous dire que vous avez quitté le stade de débutant en Perl. ] Puis, cet individu est revenu à la lecture du totem et a lu « XML » quelques lignes plus haut :
Ah ! Vous faites du XML ? Vous savez peut-être faire du multi-niveau, alors ?
Richard et moi avions l'impression que c'était un homme qui était à la pointe du progrès en informatique jusqu'au début des années 1990 et qui était resté sur place depuis, tout en restant persuadé d'être encore à la pointe. Nous en avons eu la confirmation immédiatement avec la suite de son discours :
JSON, c'est quoi ?
Quand je l'ai raconté à Emmanuel, cela lui a rappelé un ancien collègue qui avait appris PHP4 et qui a ignoré les avancées de PHP5 alors qu'elles lui auraient rendu service.
Cet homme a présenté l'un de ses griefs de cet homme contre SQL, avec la métaphore suivante. Lorsque l'on veut décharger un wagon de riz en utilisant SQL, on effectue le déchargement grain par grain, ce qui n'est pas le cas avec Pick. Je n'ai pas l'impression, parce que selon moi le déchargement se fait par
```
update GRAIN_DE_RIZ
set EMPLACEMENT = 'SILO'
where EMPLACEMENT = 'WAGON'
```
ce qui revient à faire une mise à jour globale en une seule fois et non pas une mise à jour grain par grain. Lorsque j'ai fait cette remarque à Emmanuel, il m'a répondu que ce n'était pas si simple. Certes, il y a un seul ordre SQL pour tous les grains de riz. Mais de façon interne, certains moteurs de base de données pourront mettre à jour les grains de riz en les groupant par lots et en mettant à jour un lot dans la base de données avant de passer au lot suivant, tandis que d'autres moteurs préparent toutes les pages à mettre à jour avant d'effectuer en une seule fois l'invalidation des anciennes pages et la validation des nouvelles.

Divers

Nous sommes en 2019, mais le bug de l'an 2000 est toujours là. Je cite une application qui utilise SQL Server comme base de données. Par convention, dans cette application, la valeur « date inconnue » des champs dates est implémentée avec la valeur « 1^er janvier 1753 » de SQL Server. Et suite à une montée de version de cette application, toutes les valeurs « date inconnue » ont été remplacées par la valeur « 1^er janvier 1953 ». C'est-à-dire, si l'on se place au niveau d'abstraction de l'application, toutes les valeurs « date inconnue » ont été remplacées par la valeur « 1^er janvier 1953 ». En revanche, si l'on se place au niveau d'abstraction de SQL-Server, toutes les valeurs « 1^er janvier 1753 » ont été remplacées par la valeur « 1^er janvier 1953 ». Je ne sais pas ce que vous en pensez, mais pour moi c'est clairement une nouvelle manifestation du bug de l'an 2000.
Sans dénoncer personne en particulier, Emmanuel mentionne les nombreux logiciels qui, il y a 20--25 ans, ont adopté une règle du genre
- Les valeurs de 0 à 20 représentent les années 2000 à 2020,
- les valeurs de 21 à 99 représentent les années 1921 à 1999.
Ces logiciels vont d'ici peu rencontrer de sérieux problèmes.
Un problème avec le bug de l'an 2000 est qu'il y a eu beaucoup d'exagérations à la fin des années 1990. Ainsi, j'ai entendu parler d'une entreprise qui vendait ses services aux grosses boîtes pour ouvrir les faux plafonds, coller un auto-collant « compatible Y2K » sur chaque câble ethernet et refermer le faux-plafond. Nul doute que si cette entreprise était encore en activité il y a deux ans, elle a proposé une nouvelle gamme de services à base d'auto-collants « compatible RGPD ».
Après une brève recherche sur Internet, Emmanuel trouve même une page web où il est question de savoir si des câbles de recharge de batterie sont compatibles Y2K (des câbles qui, vous l'avez compris servent à des transferts d'énergie uniquement, aucun transfert de données).
Nous avons évoqué la visite de Jim Keenan un mois et demi plus tôt. Jim avait expliqué qu'il connaissait un peu le français, entre autres parce qu'il avait côtoyé des « ècheun'z » à New York. J'ai eu du mal à comprendre qui étaient les « ècheun'z ». J'ai tout de suite pensé à la Guerre d'Indépendance de 1776 et à la bataille de Yorktown en 1781, avec les Américains de Washington et les Français de Rochambeau et la Fayette dans un camp, et les Anglais de Cornwallis, ainsi que des alliés allemands dans l'autre camp. Parmi les Allemands, le plus gros contingent venait de Hesse, d'où les « Hessiens », Hessians ou « ècheun'z » en anglais. Mais cela ne colle pas. Pourquoi les Hessiens, dans le camp des vaincus, seraient-ils restés en nombre aux États-Unis ? Pourquoi auraient-ils gardé leur identité culturelle et ethnique pendant plus de 230 ans ? Et surtout, pourquoi cette identité culturelle inclut-elle le langage français et non pas l'allemand ? Et c'est au bout d'un temps assez long que j'ai compris que les « ècheun'z » étaient en fait les Haïtiens (avec en français un tréma sur le « i » pour le dissocier phonétiquement du « a »).
Emmanuel évoque les problèmes d'encodage. Il a été confronté à une migration de MySQL vers PostgreSQL. La base MySQL était définie comme contenant des données alphanumériques encodées en ISO-8859-1. En réalité, l'encodage des données alphanumériques dans cette base est chaotique. Une même colonne peut contenir de l'ISO-8859-1 sur une ligne, du CP-1252 sur une autre et encore autre chose sur une troisième.
Il y a de cela plusieurs années, j'ai été confronté à un environnement de programmation dont la nouvelle version comprenait l'encodage UTF-8. Enfin, presque. Les mots-clés, les opérateurs et les noms de variables étaient en ASCII 7-bits et l'UTF-8 ne concernait que les chaînes de caractères et les commentaires. Sauf qu'il y avait un léger problème avec les commentaires : lorsque l'on lisait un fichier source, les commentaires étaient traités avec l'encodage ISO-8859-1. En revanche, lors de la sauvegarde du fichier source, c'était bien l'encodage UTF-8 qui était utilisé. Un jour, j'ai eu une session se déroulant ainsi.
1. Écriture d'un programme avec, en ligne 400, un commentaire contenant un « é » U+00E9. Disons « planté ».
2. Sauvegarde du programme, « planté » étant sauvegardé sous la forme 70 6C 61 6E 74 C3A9.
3. Test sur un premier jeu de données.
4. Chargement du programme dans l'éditeur de source. Les octets C3A9 sont interprétés « Ã© ». Le commentaire « plantÃ© » n'est pas affiché, l'écran n'affichant que les 50 premières lignes du fichier source.
5. Adaptation du début du source du programme pour effectuer un autre test unitaire, sans avoir besoin de paginer jusqu'à la ligne 400.
6. Sauvegarde du fichier source, le commentaire « plantÃ© » est stocké en 70 6C 61 6E 74 C383 C2A9.
7. Test sur un deuxième jeu de données.
8. Chargement du programme dans l'éditeur de source. Les octets C383C2A9 sont interprétés « Ã⍰Â© » où « ⍰ » représente U+0083, "\n{NO BREAK HERE}". Le commentaire « plantÃ⍰Â© » n'est pas affiché, l'écran n'affichant que le 50 premières lignes du fichier source.
Pas besoin de détailler plus, vous devinez que le « é » d'origine occupe 2ⁿ octets au n^ième cycle. Et après un dizaine de cycles, j'ai eu un plantage signalant une tentative de débordement de yylex.
Parfois, les problèmes d'encodage peuvent avoir des conséquences indirectes bénéfiques. Vous savez qu'un module Perl ne doit pas se terminer par une valeur équivalente à « faux » : zéro, chaîne vide, etc. D'où la tradition de terminer le module par
```
1;
```
Sauf que des esprits rebelles, dont je fais partie, terminent leurs modules par n'importe quelle valeur vraie, sauf la valeur sans originalité
```
1;
```
Cela a donné à Thomas K l'idée d'écrire un module et un site web répertoriant tous ces modules. Il a présenté ce module et ce site web il y a une dizaine d'années à YAPC::EU puis de nouveau cet été à Riga. Suite à cette présentation, j'ai vérifié mes modules. Horreur, DateTime::Event::Easter apparaissait avec la valeur
```
q{
Il reviendra ⍰ P⍰ques, mironton mironton mirontaine,
Il reviendra ⍰ P⍰ques
Ou ⍰ la Trinit⍰.
Ou ⍰ la Trinit⍰...
};
```
où « ⍰ » est la représentation par le navigateur d'un octet ou d'une suite d'octets incompatible avec l'encodage UTF-8, typiquement un caractère encodé en ISO-8859. Suite à cette constatation, j'ai corrigé le module pour utiliser UTF-8. Et j'en ai profité pour ajouter des fonctionnalités que j'avais promises lorsque j'avais repris le module en 2015, mais que je n'avais pas encole pris la peine d'implémenter : intégration correcte avec DateTime::Set, calcul explicite du nombre d'or, de l'épacte et de la lettre dominicale, etc. Tout ceci parce que je voulais que mon module apparaisse avec
```
q{
Il reviendra à Pâques, mironton mironton mirontaine,
Il reviendra à Pâques
Ou à la Trinité.
Ou à la Trinité...
};
```
dans le site de Thomas.
Emmanuel a mentionné la date de l'Assemblée Générale de l'association. Je rappelle que l'idée de la faire coïncider avec les Journées Perl a été adoptée de façon à permettre aux provinciaux d'y assister à l'occasion de leur déplacement pour la conférence. Cela dit, à l'époque où les AG avaient lieu en février à la Maison des Associations du 17^e, nous avions souvent la présence de l'un de deux Sébastien, celui qui habitait à Barlin (et y habite toujours) et celui qui habitait à Antibes (et qui a déménagé depuis).
Emmanuel et moi évoquons les nouveautés de Perl année après année et version après version. Pour nos activités communautaires, au sein de Borsalinux pour Emmanuel et autour du projet DateTime pour moi, nous devons prendre soin de rester compatibles avec d'anciennes versions de l'interpréteur (support de Red Hat 6 et directive de codage du projet DateTime). Quant aux programmes personnels que nous développons sans contrainte de compatibilité, Emmanuel et moi utilisons quelques nouveautés de la v5.10 : say, « defined-or », les variables locales statiques et given when (qui a été retiré du standard pour être relégué au statut « expérimental »). Il y a une nouveauté qui me plaît bien, mais que je n'ai pas eu l'occasion d'utiliser, c'est la substitution s/avant/après/r qui ne touche pas à la chaîne origine mais qui, à la place, renvoie une nouvelle chaîne contenant le résultat. Notons également l'amélioration continue du support d'Unicode. En dehors de cela, je n'utilise pas de nouveautés récentes de l'interpréteur Perl.
Nous évoquons un phénomène connexe à la grève des transports publics, le recours massif au télétravail, dans les entreprises dont l'activité le permet. Ces entreprises ont mis des règles en place, comme par exemple la limite de 24 jours de télétravail occasionnel par an ou l'obligation pour les membres d'une équipe de se coordonner de façon qu'il y ait toujours au moins la moitié de l'effectif présent sur place. Avec la période de grève qui se prolonge, les entreprises ont dû mettre en sourdine ces règles. De plus, elles sont confrontées à une montée en charge des infrastructures de télétravail qu'elles n'avaient pas prévue lors de la mise en place.