[Toulouse-pm] OSCON (5)

[Michel Rodriguez]

=head2 Keynotes

2 keynotes:

Tim O'Reilly, philosophise sur ce qui lui semble inte'ressant aujourd'hui.
Au passage, dans le sac qu'on rec;oit quand on s'inscrit, on a un petit
livre "Tim O'Reilly in a Nutshell" qui recueille ses discours. Ca fait
beaucoup rire, on organise des sessions de lectures ou` on e'tudie
religieusement sa bonne parole ;--)

Puis un speech rigolo de Robert Leftkowitz intitule' I<The
Semasiology of Open Source>, ou` il conclut que le source n'est pas
force'ment le plus important, que souvent ce sont les documents de spec
qui le sont. Particulie`rement inte'ressant: la partie ou` il explique
l'effet des pratiques comptables (et comment elles ont change'es) sur
la cre'ation de software.


=head2 Perl6

I<Damian Conway>

Apre`s ce talk, promis, j'essaye d'aller voir d'autres speakers que Damian!

Donc les nouvelles de Perl 6 en vrac, au moins les trucs que je savais pas.

C<slurp> va e^tre dans le core (pour lire tout le contenu d'un fichier d'un
coup). Il de'crit brie^vement les formats (c;a sera un module). Le nouveau
C<sort> acceptera non seulement une routine pour trier, mais aussi un bloc
qu donne simplement la fac;on de calculer la cle' de tri.

Une description simplifie'e (par rapport a` l'apocalypse!) du system objet
de Perl 6, qui reste perlien dans le sens que beaucoup de chose sont cre'e'es
par de'faut,mais on peut les changer si ne'cessaire. Donc au de'part on peut
e'crire du code tre`s simple et compact, mais on peut de'tailler si on veut,
pour avoir des attributs ou me'thodes prive's par exemple.

J'aime bien que . puisse e^tre utlise' comme mutateur: C<$obj .= method()>,
qui
fait la me^me chose que C<$obj = $obj.method()>. Il explique les ro^les, mais
comme je tape bien plus lentement que Damian ne parle il faudra que vous
alliez sur L<http://dev.org>.

=head2 Enterprise Perl

I<James Duncan>

James bosse pour Fotango, et de'crit comment ge'rer Perl dans le contexte
de gros projets. Il a deja` fait cette pre'sentation l'an dernier et elle
a eu beaucoup de succe`s, donc je suis la` en session de rattrapage.

Damned, c'est pas le me^me talk que l'an dernier, c;a va e^tre a` un niveau
plus pratique. Bon, c;a me va quand me^me.

Il commence par dire qu'il de'teste le mot "Enterprise". Mais bon, pour lui
c;a veut dire que c'est un outil pour la boite, pas un produit qu'elle va
vendre. Autrement dit "les gens se mettent en cole`re si c;a ne marche pas".

Dans ce contexte, ses recommendations:

=over 4

=item -

utiliser la programation objet

=item -

ne jamais re'pe'ter du code (si on doit corriger un bug c'est quand me^me plus
facile de le faire a` un seul endroit)

=item -

Il prefe`re des me'thodes simples
et courtes, qui imple'mentent 1 seul concept. Oops, je suis pluto^t du genre
a` avoir des fonctions super longues. Le contenu d'une boucle devrait quasi
toujours e^tre un appel a` une me'thode.

Ne pas assigner une variable plus d'une fois dans la me^me me'thode.

=item -

Les constantes doivent e^tre cre'es
1 fois seulement. Notament les constantes qui ont une porte'e de plus d'un
module doivent e^tre regroupe'es. Ceci dit il de'teste les fichiers de config
(a` quoi je re'ponds que tant qu'ils sont en XML, tout va bieng).

=item -

tracer a` un niveau approprie' (pas trop, mais assez)

=back

Il nous montre un exemple, re'el

Il admet que tout c;a pre^te lege`rement a` controverse.

Maintenant il passe a` la partie vraiment controversiale (?) du talk!

=over 4

=item -

utiliser les exceptions (il explique comment mais je suivait pas)

=item -

penser au donne;es de manie`re plus large que simplement leur type de
donne'es.
Surtout penser en termes de messages et de comportmenent. Au lieu de baser le
de'veloppement juste sur l'analyse des donne'es, penser en terme de "qui doit
communiceravec qui". Ne pas non plus penser en terme d'I<etat> (state), cela
conduit a` des syste`mes a forte de'pendance entre les composants. Mais bon,
les "stateless systems" ont le me^mes proble`mes! Le secret est de trouver un
bon compromis.

=item -

son conseil: ne pas avoir les noms des classes en dur, c'est plus difficile
de changer si on change une autre partie du syste`me.

=item -

ne JAMAIS mettre d'arguments dans les constructeurs, appeler des me'thodes
apre`s la cre'ation pour initialiser l'objet. Et tester dans les
me'thodes qui utilisent l'objet qu'il est dans un e'tat valide (initialise')
On peut faire c;a en surchargeant la booleanisation de l'objet.

=item -

retourner quasi-syste'matiquement l'objet lui-me^me (sauf quand la me'thode
doit retourner un attribut e'videment!). Ca permet de chai^ner les appels
de me'thodes (ca j'aime!) Class::Accessor::Chained fait c;a

=item -

au lieu d'utiliser les structures de bases de Perl, souvent il a une classe de
base (Array ou Hash) qu'il sous-classe pour pouvoir ajouter des comportements
differents, au lieu d'utiliser arrays ou hashes.

=item -

de plus en plus ose': il n'aime pas les C<if>, ca rend le code confus!
Il explique comment faire pour e'viter beaucoup de conditions en utilisant
2 classes, C<True> et C<False>... et c;a va trop vite pour que je tape,
de'sole', Le'on devra comple'ter pour moi.

=item -

utiliser les I<singletons> (mais perl ne fait pas c;a tre`s bien).

=back

En conclusion, programmer c'est le plus souvent parler a` d'autres
programmeurs, pas a` une machine. Ne pas se re'pe'ter est le plus important.