[Toulouse-pm] [ppm] YAPC::Europe::2003 (2) (fwd)

[Michel Rodriguez]

Michel Rodriguez
Perl & XML
http://www.xmltwig.com

---------- Forwarded message ----------
Date: Tue, 29 Jul 2003 02:24:27 +0200
From: "[ISO-8859-1] Sébastien Aperghis-Tramoni" <maddingue at free.fr>
To: Paris.pm <paris-pm-list at pm.org>
Subject: [ppm] YAPC::Europe::2003 (2)

Jeudi 24 juillet

* Robin Berjon - Introducing PerlSAX
     Robin nous expose dans ce talk l'intérêt d'utiliser l'API SAX par
     rapport à DOM.

     Il commence en expliquant que les APIs basées sur les arbres
     sont bien, car contrairement à DOM elles ne nécessitent pas de
     tout charger en mémoire.

     Il oppose ainsi les APIs "push" (SAX) aux APIs "pull" (DOM) en
     indiquant que le contrôle que le programmeur croît conserver par
     l'utilisation d'une API pull (où le programmeur va extraire les
     données) est une illusion.

     Dans le cas d'une API push, les données sont fournies au
     programme au fur et à mesure de la lecture du document XML,
     qui ne voit donc ces données que par fragments. On parle
     alors plutôt de filtre. L'intérêt est qu'on peut alors facilement
     chaîner plusieurs filtres les uns à la suite des autres, comme
     on peut chaîner des commandes Unix dans un pipe (ça c'est
     la comparaison qui m'a permit de comprendre le fonctionnement
     général, c'était bien vu Robin).

     Le gros avantage de cette programmation événementielle est
     qu'un filtre est plus facile à écrire car on peut ne conserver que
     la partie qui nous intéresse, en laissant tomber le reste. Reste
     qui pourra être traité par le filtre suivant.

     Robin présente ensuite XML::SAX::ParserFactory qui permet de
     sélectionner automatiquement le "meilleur" parser SAX disponible
     sur le système, avec en dernier recours un parser en pur Perl.
     Pour comparer, c'est un peu comme si on pouvait faire du DBI
     sans devoir indiquer le driver de base de données.

     Il présente enfin XML::SAX::Machines, qui est un module
     comprenant quelques filtres bien utiles comme les étonnants
     XML::Filter::Tee et XML::Filter::Merger qui permettent
     respectivement d'envoyer des événements SAX à plusieurs
     processeurs et de fusionner plusieurs flux SAX en un seul !


* Uri Guttman - Better Perl code in 65 minutes
     Ce talk consiste principalement en un ensemble de règles de
     bon sens de développement.

     Le code doit être écrit pour le mainteneur, car c'est le mainteneur
     (que ce soit soi-même ou une autre personne) qui devra relire le
     code six mois plus tard pour corriger d'éventuels bugs ou ajouter
     des fonctionnalités. En conséquence, Uri recommande de nommer
     les choses (variables, fonctions, objets, etc) de manière
appropriée,
     de sorte que ce soit compréhensible. Éviter donc les $foo, @bar et
     autres $pipo{$machin}.
     Il donne aussi le conseil suivant sur les commentaires : les
     commentaires doivent indiquer *pourquoi* le code fait telle ou
     telle chose. Écrire
         $a += 1; # add 1 to $a
     est inutile et ne sert à rien.

     Il indique aussi que programmer du code spaghetti aboutit à la
     confusion et recommande donc de programmer du code lasagnes !
     En effet le code est organisé en couches réalisant des
fonctionnalités
     spécifiques et communiquant par des interfaces.

     En résumé :
      - Code is for People, not for Computers
      - Code is for Others, not for Yourself
      - Code is What, Comments are Why

     Uri présente ensuite quelques exemples autour des contextes
     d'exécution. Il fait un rappel sur wantarray et montre qu'outre les
     contextes scalaire et de liste, elle renvoie aussi undef en contexte
     vide. Il conseille d'utilise Want.pm, qui offre plus de possibilité
que
     wantarray.

     Il y a aussi toute une discussion autour de l'utilisation des here-
     documents. Uri essaye de convaincre quelqu'un dans le public
     qui pense que les here-docs c'est pas bien que, oui, les here-docs
     c'est bien.


* Peter Sergeant - Virus detection with Perl
     Ce talk est comme son nom l'indique consacré à la détection de
     virus en Perl.

     Il présente d'abord File::Scan, un module qui permet de scanner
     les fichiers et d'y détecter d'éventuels virus. Pour Peter, le
module
     est sympa mais est insuffisant en production puisque les signatures
     de virus ne sont disponibles qu'une ou deux semaines après la
     publication de ces signatures chez les éditeurs commerciaux. Et
     évidemment il ne dispose pas d'un support commercial.

     Il présente ensuite SAVI qui est un module s'interfaçant avec le
     logiciel Sophos Antivirus via la bibliothèque libsavi. L'intérêt est
     que Sophos est disponible gratuitement en version d'évaluation
     pour une large variété de systèmes (Windows, Unix, Linux, Mac,
     VMS, etc). Si on achète la version complète on dispose alors d'un
     support commercial. (Néanmoins je connais des personnes qui
     refusent d'utiliser Sophos parce que le PDG de cette boîte serait
     un scientologue).

     Il explique ensuite les méthode de base pour écrire son propre
     anti-virus pour emails en exposant les principaux mécanismes de
     fonctionnement de ces virus. En effet les virus de mails sont pour
     la plupart basés sur l'exploitation de failles dans les logiciels.
Bien
     que les virus doivent forger des mails semblant valides, ils
     contiennent nécessairement l'exploit en clair dans le corps de
     l'email, qu'on peut donc intercepter grâce à Perl.

     A vrai dire ce talk était un peu décevant car il a juste présenté
des
     techniques assez générales, connues depuis longtemps et sans
     montrer d'exemple en Perl.


* Marty Pauley - Test-driven Perl development
     Marty nous présente en trois slides une méthodologie de
     développement basée sur le système suivant : *avant* d'écrire
     le code, quand on sait ce qu'il doit faire, on écrit les tests
     correspondants, seulement *ensuite* on écrit effectivement le
     code, et on exécute make test pour vérifier que cela fonctionne.
     Le principe est donc que les tests constituent le design fonctionnel
     du code. L'écriture du programme est terminée quand tous les
     tests réussissent.


* Philip Newton - Building an RFC 1086 simulator using ithreads
     Dans ce talk Philip nous expose un cas d'utilisation de Perl
     comme simulateur de RFC 1086.

     Il explique d'abord ce que c'est : une passerelle TCP/IP - X.25.
     Sa boîte avait un logiciel en C++ qui marchait au-dessus de X.25
     et qui envisageait d'utiliser un système de ce genre. Pour tester
     quels changement il aurait à effectuer dans le code C++, il a
     décidé d'écrire ce simulateur.

     La difficulté résidait dans le fait qu'il devait gérer trois
connexions
     simultanément.
  _____________                       _______________
|             | <------------------ | <--\     /--> |
|             |    incoming data    |     \   /     |
| X.25 based  |                     |      (X)      |
| application | ------------------> |     /   \     |
|             | control connection  | <--/     \--> |
|             |                     | TCP-IP / X.25 |
|             | ------------------> |    gateway    |
|_____________|    outgoing data    |_______________|

     Il a alors décidé d'utiliser les threads de Perl 5.6, et montre
quelques
     unes des fonctionnalités offertes par Perl.

     Il montre d'abord comment on peut partager des données (ici
     des variables) entre threads grâce à threads::shared :
         use threads::shared;
          my $data : share;

     Il montre ensuite comment créer une queue "thread-safe" avec
     Thread::Queue : on peut ainsi ajouter des données dans cette
     queue depuis un thread et en lire depuis un autre :
         use Thread::Queue;
         my $queue = new Thread::Queue;
         # thread A:
         $queue->enqueue("hello the world");
         # thread B:
         print $queue->dequeue;

     Il montre enfin comment créer un sémaphore avec
     Thread::Semaphore.
         use Thread::Semaphore;
         my $sem = new Thread::Semaphore;
         # create threads...
         $sem->down;
         # do stuff....
         $sem->up;

     Il conclue enfin en expliquant que son simulateur n'a servi à rien
     car sa boîte a finalement décidé d'utiliser une autre solution, mais
     il était content car il avait pu découvrir les threads en Perl.


* Paul Johnson - Code coverage - Tales from the trenches
     Ce talk est destiné à nous présenter le module Devel::Cover, dont
     le but est de déterminer de manière pratique la couverture de code.

     La couverture d'un code est la partie du code qui est exécutée au
     cours d'un ensemble d'instances d'exécution. En clair, ce module
     permet de vérifier si le code contient des parties mortes ainsi que
     de vérifier quelles sont les parties les plus exécutées (utile pour
     déterminer quelles sont les parties à optimiser). Cela ressemble
     donc un peu à Devel::DProf mais en utilisant un système de profilage
     différent (basé sur la surcharge des ops de l'interpréteur Perl) et
     surtout en fournissant en sortie un rapport en HTML permettant de
     suivre l'exécution du code par ligne, par branche et par boucle.

     L'utilisation de Devel::Cover est aussi simple que ça :
         $ perl -MDevel::Cover program.pl
         $ cover -report html

     Un aspect dommage est que Paul a tendance à traîner en longueur
     sur son exemple alors que plusieurs personnes (dont moi-même et
     Arnaud) trépignent d'impatience en se demandant s'il va montrer le
     Makefile.PL permettant de lancer un make test avec Devel::Cover
     (ce qui constitue une technique fabuleuse pour vérifier que les
tests
     font s'exécuter tout ou partie du code).
     Il s'excuse en disant qu'on lui avait déjà posé la question à
Munich,
     qu'il n'avait pas pu la fournir et que là il avait oublié ce qu'il
fallait
     ajouter à Makefile.PL pour avoir "make cover".

     Il parle après de CPANCover, un projet dérivé de ça qui consiste à
     exécuter un make cover sur tous les modules du CPAN.


* Jos Boumans - 20 things you may not know about Perl
     Pour certaines raisons, ce talk a attiré beaucoup de personnes qui,
     venant en avance, ont débarqué dans celui de Guillaume Rousse
     "Yet another Perl biology toolkit". Désolé Guillaume.

     Jos a en effet présenté vingt modules (ou pseudo-modules) en
     prenant comme thème de présentation le Seigneur des Anneaux :
         Neuf furent donnés aux Hommes mortels,
         Sept aux Nains avides d'or,
         Trois furent protégés par les Elfes,
         Et l'Unique, le Maître Anneau, forgé par Sauron.

     Les modules n'ont en réalité pas grand-chose à voir avec les Elfes
     ou les Anneaux, mais l'idée est amusante et surtout Jos était un
     bon orateur.

     Sur tous les modules qu'il a présenté au pas de charge, je n'en ai
     retenu que quelques uns :
     - Devel::Peek qui permet de voir les structures internes de
l'interpréteur Perl;
     - File::Chdir qui permet de gérer automatiquement le répertoire
courant;
     - Config::Auto, un module de gestion de fichiers de configuration;
     - Hook::Scope qui permet d'avoir l'équivalent de BEGIN et END
       mais au niveau scope (c'est-à-dire au niveau des blocs);
     - Hook::LexWrap, un module de Damian Conway qui fait quelque
       chose de similaire mais au niveau des fonctions si j'ai bien
compris;
     - Scalar::Utils qui permet de stocker plusieurs valeurs différentes
       (un entier ET une chaîne) dans une même variable;

     Je crois que dans ce talk aussi Nick Clark a réussi à parler de
Acme::Buffy :-)


Sébastien Aperghis-Tramoni
  -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ]
-
Paris Perl Mongueu(r|se)s  => http://paris.mongueurs.net/mail.html