Les dix ans de Paris.PM

Un historique de toutes nos réunions

Table des matières

mercredi 11 mars 2009

La voix du secrétaire (Jean)

Présents à la réunion, par ordre d'arrivée.

moi,
Théo,
Julien,
Nicolas,
Laurent (G),
Romain, son frère,
Stéphane,
Richard,
Patrick, un nouveau,
Nils,
Camille, un collègue de Nils,
Franck, un autre collègue de Nils,
David (L),
Olivier (M),
Kai,
et Chantal.

Nous avons mangé des andouillettes, des pavés, une côte de porc et une assiette de fromage. Je suis parti avant que les derniers présents commandent leur dessert. Nous avons bu de la bière Petrus, Kronenbourg, Orval, Guinness, Martins (brassée en Belgique selon un procédé anglais ou brassée en Angleterre selon un procédé belge ?), un pastis et une vodka.

La réunion a eu lieu au Maldoror. Nous avons commencé sur la rangée de fauteuils le long de la baie vitrée, mais comme le nombre de participants devenait trop important, nous nous sommes redéployés vers le fond de la salle. Malgré cela, nous étions encore tassés.

Nous avons parlé de Perl, d'Internet en quelque sorte, d'informatique et de points divers.

Perl

Cela fait 10 ans que le groupe Paris.PM existe. Si la première réunion date d'avril 1999, David et Éric avaient déjà commencé à organiser le groupe sur Internet quelques semaines auparavant. On peut remarquer que parmi les nombreux participants à la réunion, il y en a quatre qui étaient déjà là en 1999 : David le fondateur, moi qui ai participé à la première réunion, Kai qui s'est trompé de date pour la première réunion mais qui est venu à la deuxième et enfin Stéphane qui est arrivé en septembre.
Comme Patrick est un nouveau-venu à nos réunions, je lui résume l'historique du groupe. Nous avons commmencé par nous retrouver dans un café Internet, le Web-bar. Un jour, ils nous ont refusé l'entrée, car c'était réservé pour une soirée d'entreprise. Nous nous sommes alors rabattus vers la Taverne République qui se trouvait à quelques minutes de marche et que certains connaissaient déjà. Et c'est là que nous avons tenu la majorité de nos réunions pendant les 7 années suivantes. Puis la Taverne République a fermé et pendant un an, nous avons essayé divers cafés et restaurants, avant de nous fixer sur le Maldoror, que d'autres connaissaient également.
Patrick ayant évoqué le rendez-vous du samedi 14 février dernier, je lui précise que le groupe Paris.PM est distinct de l'association « les Mongueurs de Perl », même si l'on y trouve des membres communs et même si l'un des rôles de l'association est de faciliter la vie des groupes locaux. D'ailleurs, il existe d'autres groupes locaux, à Lyon, sur la côte méditerrannéenne (Marseille et Sophia-Antipolis), et à Toulouse-Albi. Parmi les autres activités, il y a la rédaction d'articles pour GNU-Linux magazine et l'organisation de conférences comme les Journées Perl Francophones.
Justement, à propos de ces Journées Perl, Kai est venu avec Chantal, qui a réalisé les affiches pour la prochaine édition des Journées Perl Francophones. Patrick demandant ce que signifie la mention « FPW », je lui explique que c'est le nom anglophone de la conférence, French Perl Workshop, dans la lignée des Belgian Perl Workshops, des Nordic Perl Workshops, des Italian Perl Workshops et autres, sans oublier les précurseurs, les German Perl Workshops. Le graphisme de l'affiche plaît à tout le monde, mais il y a un hic dans le texte d'accompagnement. Il y est marqué :
un lieu de rencontre où vous y trouverez...
nous sommes nombreux à penser que le « y » est superflu, car il désigne le même lieu de rencontre que « où ».
À son arrivée, Julien nous a demandé si nous avons lu les questions sur les expressions régulières qu'il a posées le jour-même sur la liste. Comme il n'y avait que Théo et moi à ce moment-là et qu'aucun de nous deux n'avions vérifié notre messagerie avant de venir, nous n'avons pas pu discuter de ce sujet. Ainsi donc, Julien a posté un message sur la liste pour raconter qu'il a lu deux articles différents, l'un expliquant que Perl était plus rapide que sed, l'autre expliquant que Perl était moins rapide que grep. Dans le premier cas, cela semble s'expliquer par une mauvaise allocation de tampons mémoire dans sed. Le second cas est plus intéressant. L'article décrit que Perl, ainsi que de nombreux autres interpréteurs et applications, utilise un automate à états finis indéterministe (NFA ou Non-deterministic Finite-state Automaton) tandis que grep utilise un automate à états finis déterministe (DFA ou Deterministic Finite-state Automaton). Cela dit, Julien s'est emmêlé les pinceaux en parlant d'automate à états infinis là où il était question de DFA.
Il a été question d'environnements de développement pour Perl. Outre l'habituel coloriage syntaxique, l'un des rôles d'un environnement intégré consiste à donner la liste des variables et noms de fonction visibles à tel ou tel point du programme. Pour ce faire, il faut que l'environnement de développement intégré (IDE) sache reconnaître le début et la fin d'une portée syntaxique (scope), ainsi que les déclarations package. Et même ainsi, ce n'est pas forcément fiable, à cause des eval. Il a été question également de Devel::PerlySense, mais je n'ai pas retenu les détails.
Il a été question également de Glade, un générateur d'applications graphiques sous GTK. D'après les bribes de conversation que j'ai entendues, Glade a un avantage sur les autres générateurs du même type : vous pouvez créer une application avec Glade, puis y insérer du code, puis de nouveau la modifier avec Glade, il saura « retrouver ses petits ». Avec les autres générateurs, une fois que vous avez commencé à coder, c'est fini, vous ne pouvez plus modifier la structure graphique de votre appli via le générateur.
Lorsque Patrick évoque l'abondance de modules sur CPAN, j'explique que j'ai l'impression que dans certains cas, une personne A envoie un module sur CPAN parce qu'il existe un module d'une autre personne B qui l'intéresse, mais auquel il manque juste une fonctionnalité. Et le module de A consiste juste à ajouter cette fonctionnalité au module de B, alors qu'il aurait été plus judicieux que A envoie un patch à B pour l'ajout de cette fonctionnalité.
Pour réduire un peu l'accumulation de modules sur CPAN et ne garder, on l'espère, que les modules intéressants, Camille a un moyen simple et relativement efficace : laisser tomber tous les modules en version 0.01 ou 0.02.
Concernant la répartition entre modules du core et modules de CPAN, certains font remarquer qu'il est anormal que CGI figure dans le core, tandis que DBI, nettement plus utilisé, n'y est pas. La raison est en fait très simple. CGI est dans le core depuis la version 5.4, à l'époque où il n'y avait pas d'autre module pour faire du CGI. Et pour des raisons de compatibilité ascendante d'une distribution à l'autre, CGI reste diffusé dans le core.
En généralisant à d'autres modules que CGI, on peut remarquer que de nombreux modules alternatifs reprennent le nom du module primaire en ajoutant le suffixe ::Simple ou le suffixe ::Lite. À YAPC::Copenhague, j'ai assisté à une présentation sur les modules ::Tiny (sauf que j'ai dit ::Lite lors de la réunion, c'était une erreur). Ces modules doivent répondre à des critères rigoureux. Ils doivent couvrir 80 % des fonctionnalités du module de base, ils doivent avoir la même API pour les fonctionnalités communes et ils doivent tourner nettement plus rapidement que le module de base (quel gain en performance, je ne m'en souviens plus).
Le Belgian Perl Workshop vient de se tenir à Leuven et Camille y a assisté. L'un des événements marquants de cette conférence a été l'exposé de Matt Trout. Le sujet prévu pour cet exposé était : Catalyst and Amazon Services. En fait, Matt a clamé
Don't trust the cloud!
puis :
The cloud is not your friend!
Pourquoi des affirmations si véhémentes sur un sujet différent ? Matt s'occupait d'une application gratuite hébergeant, je crois, 1 500 utilisateurs. Cette application « résidait » sur le cloud. Puis il y a eu un gros problème technique et l'application a cessé de fonctionner. Matt avait bien des sauvegardes, mais il ne pouvait pas les utiliser sur une machine locale. Il a été obligé d'interrompre le service qu'il fournissait à ses 1 500 utilisateurs. Moralité : prévoyez toujours une solution pour faire fonctionner votre application sur un serveur que vous maîtrisez. À la fin de l'exposé, quelqu'un a demandé à Matt : « Et Catalyst ? » Matt a répondu d'une phrase : « C'est simple, il suffit de l'installer et ça fonctionne. ».
Impressionné sans doute par ma factorisation en nombres premiers par le calcul mental ou par mes souvenirs du programme de math de terminale, Richard m'a demandé si je m'y connaissais en mathématiques. Puis il m'a demandé si je savais comment programmer en Perl le calcul de la FFT. Hélas non, je n'ai pas étudié la transformée de Fourier discrète. Quant à la transformée de Fourier continue, j'ai eu du mal à l'assimiler et, corollaire, je l'ai rapidement évacuée de ma mémoire, à part quelques bribes éparses. Le but de Richard est de détecter un signal noyé dans du bruit. En plus de la Transformée de Fourier discrète, il s'est intéressé aux formats WAV avec un « s » à « formats », car certains fichiers ont un seul canal tandis que d'autres en ont plusieurs entrelacés, parce que le niveau de sortie n'est pas encodé de la même manière dans tous les fichiers et ainsi de suite.
Nicolas arrive à installer RT en 10 minutes. Parmi les astuces utilisées pour accélérer cette installation, il y a la suppression de tous les tests. D'autre part, il s'agit uniquement de l'installation. Après, il y a la configuration, dont le temps n'est pas compris dans les 10 minutes. Et finalement, il pourra être utile de faire du tuning de base de données, car certaines opérations telles que la fusion de deux tickets peut prendre du temps avec une base de données mal ficelée.

Internet

Nils est venu avec deux collègues de RTGI (réseaux, territoires et géographie de l'information). Ils nous ont expliqué l'activité de leur société. RTGI est issu d'un projet de recherche de l'université de Compiègne. Leur activité consiste à cartographier le web, notamment les sites communautaires, pour savoir dans quelles « régions » il est question de tel ou tel sujet. RTGI se contente juste d'analyser les endroits où le concept recherché est évoqué, il ne cherche pas (pour l'instant) à savoir si l'on en parle en bien ou en mal. Cela ressemble un peu à un moteur de recherche, avec des robots (ou spiders) pour parcourir le web, suivi de web scrapping, d'indexation des résultats puis finalement de mise en forme. Les premières étapes utilisent Perl, tandis que la mise en forme utilise PHP pour la partie texte HTML et Flash pour la génération des graphiques. À la différence d'un moteur de recherche comme Google, RTGI n'est pas tenu de répondre immédiatement à une requête. Cela ressemble plutôt à une commande traitée dans un délai de plusieurs jours pour mettre en place le suivi d'un concept, puis de quelques heures pour livrer des rapports successifs montrant l'évolution de ce concept. Parmi leurs problèmes principaux, il y a celui de l'encodage des pages web. Il arrive fréquemment que l'en-tête HTTP annonce de l'ISO-8859, que l'en-tête HTML annonce de l'UTF-8 et que l'on se retrouve avec du codepage 1252.
Quelqu'un a parlé d'un roman texto, écrit semble-t-il avec une bonne part d'abréviations SMS. Dans le même genre, on a les romans Twitter, basé sur le respect de la contrainte de 140 caractères par chapitre de Twitter. Dans un autre domaine, il y a ceux qui écrivent un vrai roman sur leur téléphone portable, au risque d'avoir des problèmes d'usure des doigts impliqués. [ J'aurais dû évoquer une expérience assez similaire de Gilles Perrault. Il a écrit un roman d'espionnage, entièrement composé de notes de service, de circulaires, de comptes-rendus de filature, de transcriptions d'écoute, d'inventaires établis lors de fouilles clandestines, de rapports d'audit de sécurité et autres paperasseries bureaucratiques. Ce roman s'appelle le Dossier 51. D'autre part, après la réunion, ou plus précisément le 1^er avril, j'ai appris par Slashdot que la presse quotidienne se mettait elle aussi à Twitter. ]
Patrick me demande si je sais quelle est la proportion de spams dans le courrier électronique. J'ai avancé la proportion de 90 %. J'étais encore en-deçà de la réalité, Patrick m'annonce que c'est plutôt de l'ordre de 94 ou 95 %. Je lui signale que lorsque Orange a décidé en juin 2007 de fournir le filtrage de spams à tous ses abonnés, cela m'a fait tout drôle la première fois que j'ai relevé mon courrier électronique. L'adresse qui correspond à mon compte CPAN figure, comme tous les autres auteurs de modules, sur une page visible pour tout le monde, y compris les robots collecteurs d'adresses électroniques. Donc, avant juin 2007, lorsque je vérifiais mon courrier deux fois par jour, j'avais fréquemment dans les 200 messages par demi-journée pour cette adresse. Puis l'antispam gratuit et automatique est arrivé et soudain, je n'avais plus que des messages légitimes ! Depuis, de nouveaux spams ont pu éluder le filtrage mais le niveau est encore largement en dessous de 200 par demi-journée.
Quelqu'un a parlé d'une jeune cousine, qui est allé passer quelques jours de vacances à la campagne. La question que cette personne a posée avant de partir a été de savoir s'il était possible de se connecter à MSN sur son lieu de villégiature.

Informatique

Patrick est un architecte-urbaniste de systèmes d'information. Même si je conçois bien le rôle d'un architecte de SI, j'ai du mal à me représenter ce qu'est un urbaniste de SI (déjà que j'ai du mal à comprendre en quoi consiste le travail d'un urbaniste du monde réel).
Nils utilise Emacs. Il est content d'apprendre qu'il n'est pas le seul, moi aussi j'utilise Emacs. Et, me demande-t-il, quelles sont les principales fonctionnalités que j'utilise ? J'utilise, bien sûr, les tampons multiples et le multifenêtrage, c'est tellement évident que j'ai oublié de le dire à Nils. Sinon, j'utilise abondamment le mode « dired », la comparaison de fichiers avec Ediff, l'édition en passant par les registres et la recherche incrémentale. En revanche, j'ai horreur du coloriage syntaxique et lorsque je ne sais pas le supprimer par défaut, je repasse tous les buffers en « mode fondamental ». Finalement, il existe un certain nombre de fonctions pour passer le temps, comme mpuz qui vous propose une multiplication où les chiffres sont remplacés par des lettres et où il faut retrouver les chiffres. Exemple :
```
     D B F
                   Number of errors (this game): 0
    x  B C
   -------
   F F D I
                        Number of completed games: 0
 D A F F
 ---------              Average number of errors: 0.00
 D C E E I
```
qui quelques minutes plus tard donne :
```
     6 9 5
                   Number of errors (this game): 0
    x  9 8
   -------
   5 5 6 0
                        Number of completed games: 1
 6 2 5 5
 ---------              Average number of errors: 0.00
 6 8 1 1 0
```
Ou bien il y a Tetris. Ou encore, un démineur ou un « Le compte est bon » que j'ai écrits moi-même à l'époque où j'avais suffisamment de courage pour écrire des programmes moyennement gros en E-lisp.
Les collègues de Nils le brocardent en prétendant que le démarrage d'Emacs consomme tant d'énergie que le réchauffement climatique induit provoque la mort d'au moins trois ours polaires. Heureusement, une solution est en vue. Dans la version 23, Emacs fonctionnera en mode daemon. Donc, sur une machine multi-utilisateurs, chaque fois que quelqu'un demandera à éditer un fichier sous Emacs, il se connectera au daemon Emacs, sans démarrer de tâche lourde.
Richard continue à assurer des cours d'informatique. L'école où il exerce a besoin d'autres personnes pour des cours et pour encadrer des travaux dirigés. Donc, elle recrute et Richard nous transmet l'information.
Un participant à la réunion évoque l'informatique blanche, l'informatique grise et l'informatique noire. Cela correspond au degré de maîtrise que l'administrateur peut exercer sur ces différents domaines. L'informatique noire est présentée par deux anecdotes. Dans la première, un service devait déménager d'un étage à l'autre du bâtiment. Des personnes de ce service ont alors demandé comment ils allaient faire pour déménager leur serveur. Et c'est ainsi que les administrateurs du réseau ont découvert qu'il existait un mainframe qui était toujours en service, alors que plus personne n'avait la compétence pour l'administrer. Les utilisateurs connaissaient le strict minimum, à savoir, comment le redémarrer après un arrêt brutal.
L'autre anecdote concerne une période où une partie du réseau était très lente. Les utilisateurs ont envoyé des demandes d'assistance en expliquant en termes assez neutres que « le réseau semble présenter quelques problèmes de temps de réponse » et les administrateurs n'ont pas prêté attention à ces problèmes, ils avaient d'autres chats à fouetter. Les temps de réponse ont tellement empiré que les utilisateurs en sont venus à échanger leurs fichiers par disquette, ça allait plus vite !
Richard a lui aussi entendu parler d'applications tournant sur un mainframe, même si dans son cas ce n'est peut-être pas de l'informatique noire, ni même grise. L'une de ces applications utilise une base de données hiérarchique pour gérer les périodes de chômage, ce qui correspond à un chômeur, une date de début et une date de fin. C'est dire si cette base de données est peuplée ! Je pense que cette base de données est du DL1, car c'est la seule base de données hiérarchique que je connaisse.
Nicolas et quelques autres évoquent la méthodologie de projet, notamment la méthode CMMI. Ce n'est pas une méthode concurrente de ITIL, car cette dernière est un recueil de bonnes pratiques pour un système déjà en exploitation, tandis que CMMI concerne les projets de développement. Le genre de question que l'on doit se poser avec cette méthode est :
- le document X a-t-il été rédigé ?
- le document X a-t-il été validé ?
- les personnes qui ont validé le document X avaient-elles les compétences nécessaires pour le comprendre et le valider ?
Nicolas évoque deux autres méthodes utilisables lors d'un projet de développement et lors de l'exploitation d'un logiciel : la méthode GBS et la méthode PGC. La première est la méthode « Gros Bon Sens » et l'autre la méthode « Papier, Gomme, Crayon ».

Divers

Romain, le frère de Laurent, n'a rien à voir avec l'informatique. Il est élagueur. Je n'ai hélas pas suivi suffisamment ses explications. Dommage, car j'aurais pu caser dans la conversation le terme technique pour les branches descendantes et celui pour les branches montantes.
On a remarqué que plusieurs participants, plus nombreux qu'à l'accoutumée, étaient en costard, voire en costard-cravate. Laurent justifie cela par le fait que le costume donne une image assez neutre pour un nouveau venu dans un projet ou dans une équipe. Il y a, comme toujours, des exceptions. On cite notamment un individu qui était arrivé dans un service où le jean est de rigueur et qui était habillé d'une chemise bleue, d'un costume d'une autre nuance de bleu et d'une cravate rose.
Une polémique a failli se développer pour savoir quelle est la ligne la plus bondée : RER A ou ligne 13 ? Si l'on prend la ligne 13 à 9h30, les rames sont toujours bondées, mais au moins, on peut prendre la première rame qui passe, on n'est pas obligé d'en laisser passer une ou deux pour pouvoir entrer dans le wagon.
David et Richard ont parlé de l'extraction et des réserves de pétrole. À une époque, Richard avait appris de ses collègues travaillant dans l'industrie pétrolière que l'on découvrait chaque année plus de nouvelles réserves que ce que l'on extrayait. David rétorque que cela ne prouve pas que l'approvisionnement soit assuré pour l'avenir. En effet, certains gisements sont si profonds ou si peu commodes d'accès que l'extraction d'un baril de pétrole nécessite la dépense de plus d'un baril. Richard pense que l'on finira bien par trouver de nouvelles méthodes d'extraction plus performantes, David est plus pessimiste.
Richard pense que cela va également provoquer des changements dans nos habitudes quotidiennes, comme par exemple, moins chauffer les immeubles pendant l'hiver. David montre qu'une autre habitude, la facilité de déplacement, serait très dure à remettre en cause. Pour déplacer une tonne sur un kilomètre, il suffit d'une faible quantité de carburant, dit-il en montrant sa canette de bière. Et cette quantité relativement faible coûte juste un euro. Comment remettre cela en question et revenir à l'énergie musculaire pour les transports de marchandises et de passagers ? [ On ne va pas chipoter sur les valeurs numériques précises, les ordres de grandeur sont valides. ]
Pour les transports, Richard suggère de revenir à la machine à vapeur, plus efficace que les moteurs Diesel et quatre temps, dont l'effet principal est de chauffer les pistons et les culasses, au lieu de produire du mouvement. Je fais part de mon étonnement, compte tenu de mes vagues souvenirs de thermodynamique, où il était dit que le rendement thermodynamique théorique dépend de la différence de température entre la source chaude et la source froide. Le professeur nous avait expliqué que dans les machines à vapeur du XIX^e Siècle, la source chaude était de la vapeur à 140 ou 150 degrés, tandis que dans les moteurs à quatre temps, c'était des gaz brûlés à 300 ou 400 degrés, donc le rendement était meilleur pour les moteurs à quatre temps. Mais le calcul donnait le rendement théorique, tandis que Richard parle du rendement réel. Et si les machines à vapeur ont laissé la place aux moteurs à combustion interne, c'est parce que ces derniers sont moins lourds et plus compacts. [ Lors des contacts que j'ai eu avec Richard pour la préparation de ce compte-rendu, j'ai compris que nous ne parlions pas exactement de la même chose. Pour moi, les machines à vapeur sont les engins du XIX^e siècle et du début du XX^e, que l'on voyait dans les gares de chemin de fer, sans oublier également les machines fixes qui existaient dans les usines de la même époque. Tandis que Richard incluait les machines à vapeur de la fin du XX^e siècle, telles qu'il en existe dans les centrales nucléaires. Ces nouvelles machines à vapeur utilisent des pressions et des températures nettement supérieures à leurs ancêtres, d'où un meilleur rendement. D'autre part, peut-être Richard savait-il également que le rendement du cycle de Carnot n'est pas le rendement maximal, moi en tout cas, je ne le savais pas avant la préparation de ce compte-rendu. ]
Richard nous explique que l'on retrouve la même question avec la comparaison entre les TGV et les trains japonais. Les trains japonais utilisent un système magnétique implanté dans la voie, ce qui permet des économies de masse pour le moteur installé à l'intérieur du train. Il n'est pas possible d'alléger de la même manière les TGV, car la totalité du moteur se trouve à bord du train. Donc, le TGV ne pourra pas obtenir les mêmes gains de performance que les trains japonais.
Pour continuer sur la discussion du mois dernier sur les problèmes de vie privée associés aux passes Navigo, quelqu'un [ Je ne me souviens plus qui, je l'appelle « Albert » dans la suite ; n'y voyez aucun sens caché ] montre un passe « Navigo Découverte », composé de deux cartes : le passe proprement dit, avec une puce RFID à l'intérieur et une carte où figure le nom et le prénom du titulaire de la carte. Mais il n'y a pas de lien entre les deux éléments, donc la collecte automatisée des informations sur le passe ne permet pas de pister le titulaire. Nicolas demande à Albert comment il a payé son passe Navigo Découverte. « Par carte bleue ». Et voilà, on a retrouvé le moyen d'associer le passe Navigo Découverte 123456 à la carte bleue 8765-4321-0001-0002, donc à Albert ! Sauf que, comme le rappelle quelqu'un il est interdit de faire le rapprochement entre les fichiers des banques et d'autres fichiers. Nicolas reformule cette interdiction en : « Le rapprochement entre des fichiers ne doit pas comporter le numéro INSEE. »