[Toulouse-pm] Oscon 2006, Mercredi

[Michel Rodriguez]

   Mercredi soir
     Mercredi soir était la traditionelle soirée p5p dans la chambre (ou
     plutôt suite) de Nat. Traditionnellement, bien que n'étant pas sur p5p,
     j'assiste à la soirée.

     C'est vraiment un des aspects d'OSCON que j'aime: je ne cause quasiment
     pas de Perl, mais j'ai droit à une description de zimbra et de leurs
     buts (virer Outlook), de openId, une comparaison de divers téléphones
     portables, je tire sur le hookah de Josh, je vois mon premier canadien
     en colère, c'est une canadienne, et j'admire Portland la nuit (si
     j'avais porté le chargeur de la batterie de mon appareil photo vous
     auriez une photo :--( heureusement, flickr à la rescousse:
     <http://www.flickr.com/photos/80818705@N00/197831169/>

   Jeudi Matin
    Keynotes
     Je me lève un peu en retard, et je rate (comme d'hab apparement!) une
     bonne partie des keynotes.

     J'arrive à la fin du talk de Robert "r0ml" Leibowitz, qui avait l'air
     bien rigolo, comparant Open Source au légumes, et combien de légumes est
     bon pour la santé (RMS est bien sûr un végétarien).

    How SQL RDBMSes Work - D. Richard Hipp
     Par le gars qui fait SQLite, mon SGBD favori (parce que mon sysadmin est
     nul, c'est moi!). Il devrait savoir de quoi il parle!

     Pour lui ill faut penser à SQL comme à un langage de programmation,
     simplement il décrit ce que l'on veut, pas comment le récupérer. Chaque
     instruction SQL est une fonction.

     Il montre un peu de pseudo-code, qui implémenterait une requête typique.
     Puis 3 autres versions, en ajoutant des index à lalgorithme. Juste pour
     nous montrer que même une simple requête peut être traduite de pas mal
     de façon.

     Une requête un peu plus compliquée (waouh! l'auto-complétion de vi
     marche super bieng, c'est un vrai plaisir que de taper req<TAB>). Est-ce
     que ça serait facile d'écrire le code?

     Son talk va surtotu porter sur cette phase, sur la compilation de la
     requête. Pas sur la machine virtuelle et le systême de stockage.

     Différents moteurs génèrent différents formats: MySQL, PostgreSQL
     génèrent une structure de donnée (un arbre), SQLite génère du bytecode,
     d'autres génèrent même directement de l'assembleur. Ca n'est pas
     important, ce qui est important ce sont les principes utilisés.

     Donc il nous montre la structure d'une table: chaque ligne a un id, des
     champs, et l'addresse oû le record est stocké. Puis la structure d'un
     index (valeur de l'index, qui peut être réparti sur plusierus colonnes,
     et addresse du record).

     Pour l'instant c'est pas d'un très haut niveau. Les questions sont
     intéressantes néanmoins, Monty de MySQL et des gens de PostgreSQL sont
     dans le public et participent à la discussion.

     Par exemple si on a une requête sur un champ qui est le second de
     l'index, PostgreSQL et Oracle (et dans le futur MySQL) peuvent quand
     même utiliser l'index. C'est surtout interessant si par example le
     premier champ de l'index n'a que peu de valeurs: le moteur doit faire
     autant de recherches que le nombre de valeurs dans ce champ, mais ça
     peut quand même être plus efficace que de balayer toute la table.

     Si une requête ne doit retourner que des champs de l'index, le systême
     n'a même pas à lire la table, donc ça peut être intéressant d'avoir les
     champs les plus utilisés directement dans l'index. Sa recommendation:
     créer des index avec d'abord les termes du WHERE, puis ceux du ORDER BY,
     puis ceux qui sont retournés (pas en PostgreSQL qui va lire la table
     quoi qu'il arrive).

     Il nous montre comment un OUTER JOIN marche. L'ordre des tables est
     vraiment significatif. Le SGBD optimise l'ordre bien sûr, mais avec
     beaucoup de tables le nombre de combinaisons explose. Alors comment le
     SGBD choisit-il? Il doit s'arrêter, plus de temps! ARRRRGGGHHHH!

     Un bon talk au final, grâce au fait que Richard Hipp fait vraiment
     participer le public. La présentation sera bientôt en ligne.

    What Would Good Programmers Do - Perrin Harkins
     Il recommende d'utiliser perltidy sur le code. Ca évite de s'engueuler
     sur le format du code.

     *Code is always read more time that it is written* : le public (*target
     audience*) du code n'est pas l'auteur 20 minute après l'avoir écrit. Son
     truc: il imagine toujours qu'il va devoir lire le code 1 an plus tard, à
     2 heures du mat, aprés avoir été réveillé par un coup de fil de son boss
     qui hurle au bout du fil.

     Ses principes de base:

     Pourquoi faire compliqué quand on peut faire simple
     Ne pas utiliser la magie quand on peut utiliser quelque chose
     d'implicite ("tie"d variables...)
     Ne pas rendre le code plus compliqué juste pour avoir une certaine
     syntaxe (ex: prototypes)
     Suivre les conventions quand on peut
         Il a un exemple ou il dit que "s/foo/far/" est mieux que
         "s{foo}{bar}" (je ne suis absolument pas d'accord, j'utilise
         _toujours_ la deuxième syntaxe)

     Ne pas utiliser des fonctionnalités obscures de perl (plus risqué, moins
     testées..)

     Il n'utilise _jamais_ les formats, les variables de ponctuations, les
     fonctions import qui n'importent pas (genre "use Catalyst qw/-Debug/;"),
     la vieille syntaxe d'appel des méthodes ("new Class"), ajouter des
     méthodes à UNIVERSAL, re-blesser des objets existants, filtre source,
     "use constant".

     Il recommende aussi de s'en tenir aux objets basés sur des hash
     (curieux... tiens au passage je jette un oeil à Moose
     <http://search.cpan.org/dist/Moose/> qui à l'air sympa).

     Il essaye d'éviter: "DESTROY", "AUTOLOAD", "wantarray" (je suis
     etie`rement d'accord avec celui là, je suis pas assez fort pour toujours
     réaliser dans quel contexte j'appelle une fonction (si j'y pense).

     Il évite de trop utiliser les closures, string "eval", sub attributes,
     coderefs, fonctions exportées par un package (il préfère utiliser des
     classes), "map/grep" enchaînés, opérateur ternaire (? :) pour lui c'est
     juste un if/else plus court (Damian intervient pour dire que l'intérêt
     est que ça force à avoir un else).

     Questions (de lui):

     Est ce que ça rend la programmation chiante? Pour lui non, ça permet de
     se concentrer sur le niveau plus général, on peut s'amuser lors de la
     conception.

     Mais AUTOLOAD est super-cool (*awesome*)! Ouaip, mais pas forcément dans
     un gros projet.

     Pourquoi ne pas utiliser Java? Qui a laissé rentrer ce gars dans la
     salle?

     A part le code: penser au contrôle de conf, utiliser les branches dans
     le systême de versionnement, écrire des tests.

     Un talk un peu bizarre, qui me semble un peu "Perl Best Practices 2001".
     Il refuse pas mal des récents développements dans et autour du langage.

   Jeudi Après-midi
    Perl6: The Final Ascent - Damian Conway, Larry Wall
     Et oui, c'est le talk annuel sur l'état de Perl6, pour la quoi,
     cinquième année consécutive.

     A noter que pendant ce temps Eric et tous les contributeurs à mod_perl
     assistent au talk de Doug MacEachern, qui fait son grand retour aprés
     quelques années d'absence. Il semblent qu'ils ont préparé tout le
     marériel pour jouer les parfaits groupies. Si vous insistez un peu, et
     s'il a récupéré du repas de midi qui, scandaleusement, ne comprenait pas
     de confit de canard, Eric vous racontera peut-être tout ça.

     Larry commence par nous faire un chameau (ok, un dromadaire) en ombres
     chinoises sur l'écran.

     Damian pense que boulot sur la conception du coeur de Perl6 est
     quasiment finit. Il vont parler uniquement de cet aspect, pas de
     l'implémentation.

     Au départ le design du langage etait *annoyance-driven*: répondre aux
     RFC, qui décrivaient pour la plupart les aspects de Perl5 qe les gens
     n'aimaient pas. Ensuite, vint la phase oû ils ont tenté de fondre tout
     ça dans un ensemble cohérent, d'extraire les concepts de base qui
     sous-tendraient Perl6. Maintenant le design est plus basé sur les
     implémentations. Ce sont plus des modifications mineures, sur des
     problèmes révélés par pugs par exemple.

     Donc une liste de nouveautés dans le langage, principalement destinées a
     le rendre plus agréable à utiliser. Ca va vite, donc les titres vont pas
     forcément être traduits.

     Exemples:

     commentaires en ligne #{ commentaire } ou même sur plusieur lignes (on
     peut utiliser d'autres crochets)
     whitespace comments: \ et des espaces fait disparaitre le tout: var\
     .methode
     pipe operators: maintenant il s'appellent *feed* (pour éviter de
     confondre avec |)
     une parenthèse fermante à la fin de la ligne terme l'instruction
           my $sub= sub { return "foo"; } # pas besoin de mettre un ; à la fin de la ligne

         *A tribute to python*

     repeat
           repeat { ... } while condition();
           repeat while condition() { ... }

         *A tribute to Pascal*

     le metaopérateur de négation
           !< ou !> ou !~~ ...

     paires: beaucoup utilisées en perl6
           key => $value

         peut aussi être écrit

           :key($value)

         avec pleins de ruses: on a pas besoin de virgules ":key" est
         équivalent à key(1), ":!key" est ":key(0), " key<Damian" "> est
         "key("Damian")" "key<<Damian is $old>>" est "key( "Damian is
         $old")", et ":$age" est "age($age)" (marche aussi avec tableaux et
         hash.

     captures
         Une liste d'arguments, sans fonction: "\($obj: $pos, $pos2, :opt2)",
         qui est un vrai objet

     ranges
           my @range= $ok ..^ $trop_grand; # ^ marche avant, aprés ou avant et aprés le ..
           my at range = $min..$max :by(2);
           for ^4 { ... } # parcourt la boucle 4 fois

     nombres non-décimals
           my $i=03; # n'est plus un nombre octal
           my $i= 0o05; # octal
           my $i= 2<101001>; # toute base est autorisée

         On peut aussi mettre des fractions

     type *whatever*
         Le sigil est *

           my @endlessly_true = "true" xx *
           @positives = 1 .. *; # 1 .. infini
           @numbers= *..*;
           my( *, $file, *, $name)= func( $arg); # * au lieu de undef

     multi-dimensional qrray and hashes
         indices séparés par des ;

     Conclusion: on y est presque!

    When Interface Design Attack
     Un bon talk sur le design des UI pour le web. Malheureusement c'était
     complet et j'étais en dehors de la salle.

     La présentation devrait être a <http://www.slash7.com>

    The Conway Channel
     Il va présenter 2 modules: List::Maker
     (<http://search.cpan.org/dist/List-Maker>) et Contextual::Return
     (<http://search.cpan.org/dist/Contextual-Return>)

     List::Maker
         Quelques exemples où l'utilisation des tableaux (ou listes) en Perl,
         n'est pas complètement naturelle. Bien sûr Perl 6 a des solutions
         pour tous ces cas.

         Mais en attendant... List::Maker

         En surchargeant la notation pour les file globing (< ... >) il offre
         la syntaxe de Perl 6 pour des listes... en Perl 5.

         Plus quelques extras:"@list= <4d6>;" jette 4 d6 et retourne la liste
         (en contexte scalaire ça retourne le total des 4 jets). On peut
         étendre la syntaxe pour ajouter ses propre délires. La seule
         limitation est que les 2 crochets doivent être sur la même ligne.

         Le module est sur CPAN, mais ne semble pas faire tout ça encore, il
         promet de poster une version complète dans les jours qui viennent.

         Curieusement, Ingy et Audrey on aussi surchargé < ... > pour
         XML::Literal (<http://search.cpan.org/dist/XML-Literal>), qui semble
         aussi diabolique.

     Contextual::Return
         J'en ai déjà parle à l'occasion du tutorial sur les API, donc je
         vais pas trop insister.

         Je suis pas sûr que ça soit vraiment utile en fait. C'est un peu
         trop rusé pour moi. Ca revient à avoir plusieurs fonctions
         différentes... mais avec le même nom. Donc ça veut dire qu'il faut
         se rappeler de ce que fait la fonction dans chaque contexte, sans
         que le nom ne soit une aide.

    The Perl Foundation Auction
     Uri (Guttman), officie à la vente aux enchères traditionelle de la Perl
     Foundation. C'est bien plus calme que celles de YAPC::Europe, des
     livres, pas de trucs stupides, c'est plié en 40 mn.


-- 
Michel Rodriguez
IEEE Standards - Electronic Services