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.
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 Fourierdiscrè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 Fourierdiscrè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.
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
romantexto,
écrit semble-t-il avec une bonne part
d'abréviations SMS.
Dans le même genre, on a les
romansTwitter,
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
1er 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.
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 ».
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 XIXe 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 XIXe siècle et du début
du XXe, 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 XXe 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. »
