Un renommage qui aurait dû avoir lieu depuis très lontemps ! Pour ceux qui ont du mal à suivre (et ça se comprend), une petite explication de texte : la réécriture de Zope 2, démarrée il y a 8 ans, et qui a longtemps été appelée « Zope 3 », a consisté à créer une architecture modulaire et innovante, la « Zope Component Architecture » (ZCA), puis à découper proprement Zope et une multitude de paquets utilisant cette architecture. Cet ensemble de paquets, cohérents et compatibles entre eux a été nommé tout d'abord « KGS » (Known Good Set), puis renommé courant 2009 en « Zope Toolkit ». Le Zope Toolkit (ZTK) est l'ensemble des bibliothèques Zope, utilisées maintenant par tout l'écosystème Zope : Zope 2, Plone, Grok, etc... Plus de 900 paquets sont taggés « Zope 3 » dans PyPI !

Nous avons donc l'architecture (la ZCA) et l'ensemble des bibliothèques (le ZTK). Mais où est le serveur d'application dans tout ça ? Rappelons que l'idée originale était de réécrire Zope 2, donc il manque quelque chose. Est-ce Zope 3 ? Oui, mais Zope 3 ça ne veut plus rien dire : le concept Zope 3 a été éclaté en morceaux, et même le nom Zope 3 a fini par se noyer au milieu du reste. On avait presque oublié qu'on pouvait créer une application en pur Zope 3. Un coup de zopeproject et c'était parti !

C'était sans compter sur l'initiative de Baiju M., qui a pris le risque de renommer Zope 3 (le serveur d'application) en BlueBream, et de relancer la machine buzz et documentation ! La vidéo fait sourire, mais on ne peut rien lui reprocher, vu l'énergie qu'il déploie actuellement. Globalement son effort a été extrêmement bien accueilli et encouragé par la communauté. BlueBream, en soi, ne contient pas grand chose, c'est un simple template de projet du même genre que zopeproject, grokproject, django-admin.py startproject ou autres zf.sh create project. C'est donc une nouvelle identité, un nouveau logo et une nouvelle dynamique de contribution. Dans BlueBream, il n'y a absolument rien d'autre que les paquets du Zope Toolkit, c'est donc bien du Zope 3 pur. Il n'y a même pas de namespace bluebream et ce n'est pas à l'ordre du jour.

Voici quelques ressources utiles pour s'informer et suivre l'actualité BlueBream :

• Accueil/Documentation
• Liste de diffusion (archives de janvier 2010)
• Twitter
• Blog
• Canal IRC : #bluebream sur freenode.net
• Wiki
• Paquet sur PyPI
• Buildbot

Petit tutoriel de démarrage

La documentation officielle explique ça très bien en anglais, mais je vous en fais une en français.

Création d'une application

Avant tout, assurez-vous d'avoir Python 2.5 ou 2.6 et les bons paquets de développement, sur Debian/Ubuntu ça ressemble à ça:

$ sudo aptitude install python-dev build-essential libxml2-dev libxslt1-dev

On commence par installer la dernière version de Distribute. (Le monsieur t'a dit d'installer Distribute. Si tu n'installes pas la dernière version de Distribute dans moins de 5 minutes, ton chat sera sodomisé par un gorfou)

$ wget http://python-distribute.org/distribute_setup.py
$ sudo python distribute_setup.py

Bon, le chat a évité le pire, maintenant on installe le paquet bluebream (0.1.9 à la date de cet article), qui est minuscule et n'a pour dépendances que Sphinx-PyPI-upload, PasteScript, PasteDeploy et Paste.:

$ sudo easy_install bluebream

C'est tout, maintenant on peut démarrer un nouveau projet BlueBream. Remarquez que la méthode est la même que pour un projet Pylons, BFG, Plone ou n'importe quoi pris en charge par un template Paste. Vous devez répondre au moins à la première question en donnant le nom de votre projet, ce qui aura pour effet de créer un dosser du même nom. Pour tout le reste, vous pouvez appuyer sur Entrée.

$ paster create -t bluebream

Maintenant on rentre dans le dossier, et on construit l'application grâce à Buildout (Je suppose que votre projet s'appelle monprojet)

$ cd monprojet
$ python bootstrap.py
$ ./bin/buildout

Avant de lancer buildout, un bon conseil est de configurer le dossier partagé pour les paquets Python, qui évitera de les re-télécharger dans chaque buildout ou projet : vous devriez avoir un fichier ~/.buildout/default.cfg contenant ça :

[buildout]
eggs-directory = /home/ccomb/buildout-eggs

Si tout s'est déroulé correctement, vous devriez avoir un dossier bin contenant : breampy, buildout, paster, test. (Sinon je plains votre chat. Installez la dernière version de Virtualenv, créez un environnement isolé avec virtualenv --no-site-packages --distribute monprojet, activez le avec source bin/activate et recommencez sans sudo à partir de l'installaton de bluebream.)

Vous pouvez maintenant démarrer votre application:

$ bin/paster serve deploy.ini

Puis accéder à la page par défaut sur http://127.0.0.1:8080/

Vous pouvez aussi démarrer en utilisant debug.ini, ce qui active divers outils de debug, dont un middleware WSGI très utile, pour afficher le traceback dans le navigateur et même inspecter les variables de manière interactive.

Quelque chose de nouveau par rapport à Zope 3.4, il y a une commande shell qui permet de se retrouver dans l'environnement de l'application, et d'accéder directement à la racine de base de données pour l'inspecter (objet root). Cette commande shell est l'équivalent du debugzope ou zopectl debug des versions précédentes de Zope 2 ou Zope 3.:

$ bin/paster shell debug.ini
>>> root
<zope.site.folder.Folder object at 0x46319b0>

On voir que l'objet racine de la ZODB est maintenant pris en charge par un nouveau paquet zope.site. On a aussi accès à un objet debugger ou app (c'est le même), provenant de zope.app.debug, et permettant de simuler une requête ou d'avoir accès à l'objet DB. Par exemple si vous voulez vider l'historique de la ZODB (ce qu'on appelle faire un « pack »), il suffit de taper ça dans le shell de debug:

>>> app.db.pack()

Modifier la page d'accueil

Pour comprendre d'où vient la page d'accueil que vous voyez sur http://localhosts:8080 , il suffit de regarder dans le dossier src/monprojet/main/. Dans le fichier configure.zcml, une vue est configurée :

<browser:page
   for="zope.site.interfaces.IRootFolder"
   name="index"
   permission="zope.Public"
   class=".views.RootDefaultView"
   />

Cette déclaration signifie : « J'ai une vue disponible pour l'objet racine (celui fournissant l'interface IRootFolder). Cette vue est gérée par la classe RootDefaultView, la vue a pour nom « index », qui sera le nom visible dans l'URL, et cette vue est publique (permission zope.Public). »

La vue est une simple classe Python visible dans le fichier views.py, et on peut voir que la vue renvoie elle-même la page HTML, sans même utiliser de langage de templating :

class RootDefaultView(BrowserView):

    def __call__(self):
        return """\
<html><head><title>Welcome to BlueBream!</title></head><body>
<h1>Welcome to BlueBream!</h1>
<ul>
(...)

Dans cette page d'accueil, on peut déjà s'authentifier en cliquant sur login, avec le mot de passe admin/admin. On peut ensuite cliquer sur Add a sample application pour ajouter une Sample Application. Cette SampleApplication n'est rien d'autre qu'un conteneur qui sera ajouté à la racine de la ZODB. Elle est définie dans le fichier app.py:

class SampleApplication(BTreeContainer):

  implements(ISampleApplication)
  name = u""
  description = u""

Tout ceci fait penser un peu à l'interface d'accueil de Grok qui permet d'« ajouter une application ». Ça ne sert pas à grand chose, à part montrer un exemple simple de formulaire, et d'ajout de contenu hiérarchique dans la ZODB. Si vous créez votre propre application, vous pouvez supprimer ces classes d'exemples, redéfinir la vue pour l'objet racine, de préférence en utilisant le templating par défaut de Zope : le ZPT.

Pour remplacer cette page d'accueil, commencez par supprimer la méthode __call__ de la vue RootDefaultView, car cette méthode surcharge celle de la classe parente (BrowserView). De cette façon on bénéficie à nouveau de la méthode de publication par défaut de BrowserView, qui peut faire appel à un template configuré en ZCML.

Dans view.py :

class RootDefaultView(BrowserView):
    pass

Et dans configure.zcml :

<browser:page
   for="zope.site.interfaces.IRootFolder"
   name="index"
   permission="zope.Public"
   class=".views.RootDefaultView"
   template="accueil.pt"
   />

Ensuite évidemment il faut créer le template pour l'accueil (fichier accueil.pt) :

<html><body>

<h1>Accueil</h1>

<p>Bonjour, la classe de l'objet racine (le contexte de cette vue) est :
  <span tal:content="python: context.__class__.__name__" style="color: blue">
  nom de la classe
  </span>
</p>

<p>
  Le user-agent de mon navigateur est :<br/>
  <span tal:content="python: request['HTTP_USER_AGENT']" style="color: blue">
  contenu de la requête
  </span>
</p>

</body></html>

La vue étant un double adaptateur sur le contexte (qui dans ce cas est l'objet racine) et sur la requête. Ces deux objet sont donc disponibles dans la vue en Python via self.context et self.request. Ces deux objet sont même transmis par défaut au template via les variables context et request. De cette façon, on peut accéder à l'objet racine et connaître le nom de sa classe (voir la capture d'écran), et à l'objet requête ce qui permet de récupérer entre autres le User-Agent, ou d'autres informations liées à la requête, comme l'utilisateur authentifié.

C'est tout pour aujourd'hui.

• Les premières Rencontres Django francophones viennent d'être annoncées par David et auront donc lieu les 24-25 avril à Marseille. Dans ma TODO, on ajoute : transport (SNCF, c'est minimum 7h20 de train - Avion, c'est Ryanair avec des dates moyennement intéressantes - voiture c'est hypra-galère à l'aller encore pire au retour) et logement (les organisateurs y travaillent).
• Le prochain OggCamp, l'événement open-source qui succède au Lugradio Live aura lieu à Liverpool... le week-end d'après (2-3 mai). Impossible que je le manque celui-ci non plus. Donc, dans la TODO : transport (une des propositions d'Air France table sur un voyage de plus de 24h - Y'a bien EasyJet, mais c'est moyen - Y'a pas Ryanair, ils desservent Biarritz/Liverpool que l'été) et logement (les organisateurs y travaillent aussi).
• Les prochaines RMLL... J'hésite... En même temps, c'est à Bordeaux, donc pas loin. Faudra voir en fonction des intervenants / ceux qui y seront que je connais, etc.

À savoir que pour mon plus grand bonheur, pour les Rencontres et pour OggCamp, on a réussi à me convaincre de préparer une intervention. Donc, dans la TODO : talk for OggCamp et conférence Django.

À part ça, je dois encore écrire et publier le troisième et dernier épisode de "Maux de passe" pour Polar-Geek. Je sais pas quand j'aurai le temps.

Qui a dit que les chômeurs étaient inactifs ?

Si je souhaite extraire toutes ces archives, je devrais aller trouver chaque archives dans son répertoire, taper la bonne commande pour pouvoir les extraire, les réparer au besoin et ainsi de suite... Plutôt fastidieux non ?

Sur ce constat m'est venu l'idée de easy_extract, un script écrit en Python qui va analyser récursivement les répertoires à la recherche d'archives ou de collections d'archives pour les extraire et les réparer automatiquement si elles sont corrompues.

Pour cela, il suffit de lancer le script de la manière suivante par exemple :

$> easy_extract -r mes_archives/

Pratique et le gain de temps est évident, car une fois le script lancé, vous n'avez plus à vérifier que l'extraction s'est bien déroulée pour ensuite passer à la suivante, donc a scotcher devant votre terminal. Victoire une tâche fastidieuse de plus automatisée.

Pour l'installation, il est nécessaire d'installer les paquets suivant avant :

• par2
• unrar-free
• 7zip-full

Ensuite l'installation du script se fait grâce à easy_install :

$> easy_install easy_extract

Bien sûr le code est open-source, donc si vous voulez contribuer, forker ou juste critiquer, le code se trouve à l'adresse suivante : http://github.com/Fantomas42/easy-extract

Bonne décompression et bon leech.

J'y intègrerai progressivement des liens vers les textes qui me parviendront, soit par email, soit via le compte @polardeuxzero (cf. la page "à propos").

Comble du bonheur geek, on y trouvera un flux RSS.

Au pire, si tu veux contribuer mais que tu n'as pas de blog ou d'espace d'expression électronique, tu peux également m'adresser le texte par e-mail et je tâcherai de lui trouver une place dans mon maaaaaagnifique gestionnaire de contenu révolutionnaire (cough).

d'ailleurs, à propos de magnificence, si un designer passe par ici et a envie de bénévoler au secours de mes maigres talents graphiques, qu'il n'hésite pas à se faire connaître. mais je serai pas vexé si tu veux pas bosser gratuit.

Et allez ! contribuez ! contribuez ! contribuez !

Tout d'abord, il faut dire que j'allais à cette formation avec un a priori plutôt négatif sur Perl de part ce que j'avais pu en entendre ici ou là. Il faut dire que j'ai plutôt été agréablement surpris par certains cotés.

Match perl vs bash :

• Perl peut être vue comme une bonne alternative / un bon complément à des scripts bash. Plutôt que de vous casser la tête à apprendre à utiliser grep/sed/awk, vous pouvez faire la même chose mais uniquement en perl. Parce que bon, franchement awk, c'est peut être super puissant mais je trouve ça inabordable et loin d'être évident.
• Je compte ainsi revoir certains scripts bash qui ne me satisfont pas pour voir si Perl ne me permettrait pas d'atteindre l'objectif souhaité.

Match perl vs python : avantage Python

• Pour le coup, le langage avec des des $, %, et même @ devant les types de données, des accolades pour les débuts/fin de bloc qu'on ne sait jamais à quel niveau positionner pour rester lisible de bout en bout et des ; en fin de ligne, j'ai du mal. Surtout maintenant que je me suis habitué à la syntaxe python que je trouve infiniment plus lisible et moins source d'erreur.
• Dans la même veine, les syntaxes sont pas des plus évidentes : ainsi dire que $tab est un scalaire, @tab un tableau, %tab un tableau associatif et que si on met un "antislash" devant on parle alors d'une référence vers le scalaire/tableau/tableau associatif, ça aide pas l'écriture d'un script

Par ex en perl :

if ( $toto == 2)
{
    print "Toto vaut : $toto\n";
}

et en python :

if toto == 2:
    print "Toto vaut %s" % toto

• Perl fonctionne de façon beaucoup trop implicite/facultative contrairement à python. Python impose un certain nombre de conventions et c'est bien. Le "There is more than one way to do it" de Perl peut être séduisant mais aussi contre productif, surtout en entreprise.

Exemple pour parcourir un tableau en perl :

#! /usr/bin/perl -w
 
# Tableau simple
@tab = ("fraise", "abricot", "goyave", "pamplemousse");
foreach (@tab)
{
    print "Valeur : $_ \n";
}
 
# Tableau associatif
%hash = ("France" => "Paris", "Allemagne" => "Berlin", "Angleterre" => "Londres");
foreach (keys %hash)
{
    print "Pays : $_ , Capitale: $hash{$_}\n";
}

Le $_ est appelé scalaire par défaut. Il est conseillé de vivement l'utilisé plutôt que d'initialiser une variable. De prime abord, ça surprend. Il existe aussi un @_ dans les fonctions et qui correspond à un tableau d'arguments passés à la fonction.

Dans ce cas les parenthèses sont implicites. On peut bien sur écrire :

foreach(keys(%hash))

alors qu'en python :

tab = ["fraise", "abricot", "goyave", "pamplemousse"]
for fruit in tab:
    print "Valeur : %s" % fruit
 
hash = {'France' : 'Paris', 'Allemagne': 'Berlin',  'Angleterre' : 'Londres'};
for key, value in hash.items():
    print "Clé : %s Valeur %s" % (key, value)

Dans les deux cas, nous aurons :

Valeur : fraise
Valeur : abricot
Valeur : goyave
Valeur : pamplemousse
Pays : France , Capitale: Paris
Pays : Angleterre , Capitale: Londres
Pays : Allemagne , Capitale: Berlin

Si on rajoutait un tri en perl, en implicite cela peut aller jusqu'à :

foreach (sort keys %tab)
{
}

Difficile de s'y retrouver à mon humble avis.

• Perl n'a pas de "prompt" intégré : Franchement pouvoir taper "python" dans un shell et ensuite codé en direct son script et le retoucher, que de temps gagné. Il y a certes perl -pe "commandes perl" mais c'est bien en deçà de ce que peut offrir python.
• Mettre /usr/bin/perl -w en début de script permet de lever les warnings et corriger les éventuels bugs
• Python propose le module "re" pour les expressions régulières. Pas besoin donc de se mettre spécifiquement à Perl s'il y a des besoins de RegExp
• J'ai l'impression que la doc python est de meilleure qualité même si apparemment Perl rattrape petit à petit son chemin...
• Globalement, Python et Perl doivent permettre de faire les mêmes choses, donc je vais considérer le périmètre des langages comme ex-aequo.
• Même si cela m'a troublé de prime abord avec les listes en python, les listes en perl sont sympathiques :

@tab = ("un", "deux", "trois");
($t1, $t2, $t3) = @tab;
 print "t1 vaut $t1\n";
 print "t2 vaut $t2\n";
 print "t3 vaut $t3\n";

Contrairement à ce que l'on pourrait croire de prime abord, cela n'est pas un tableau mais juste un "panier" de variables. On peut donc utiliser $t1 & co.

• La notation objet est plus claire en Python. Je n'adhère toujours pas au $titi->dosomething(); (comme en PHP en fait)
• La prise en main de python est beaucoup plus immédiate (aux listes / tuples (grosso modo des listes non modifiables) / dictionnaires (tableaux associatifs) prêt )
  • D'ailleurs, les listes en python correspondent aux tableaux en perl et les dictionnaires python au hash (tableau associatif) perl.
  • Sauf erreur, il n'y a pas d'équivalent des tuples en perl
  • Les listes en perl n'ont donc rien à avoir avec les listes en python (cela m'a pas mal dérangé durant la formation)

Ce qui fait qu'au final, je rejoins tout à fait David sur "Pourquoi Python & Django". A titre personnel, mon langage de prédilection va donc rester python et je vais voir dans quelle mesure je peux encourager python au boulot. J'y ai déjà glissé une appli Django après tout

Perl a malgré tout été une bonne surprise, je m'attendais à pire. Il convient par contre dans un contexte d'entreprise je pense de rendre le code le plus verbeux possible pour facilité sa reprise et sa maintenance.

Après l’achat (sur un coup de tête) de tshirtman.fr, je me suis dit que j’allais faire blog.tshirtman.fr et sérieusement ce coup ci… on (mon chef au boulot, plus connus sous le pseudo ccomb) m’avait conseillé zine qui à l’avantage d’être en python et de bonne facture, j’ai un peu galéré avant de trouver la bonne méthode d’installation (un buildout sur pypi bien sur >_<) mais en tout cas c’est propre et sympa…

Comme j’utilise apache pour les virtualhost, zine tourne en user normal via paster, sur un port quelconque, et apache lui renvoit les requetes via mod_proxy, c’est simple et efficace.

Je viens de finir d’importer les billets du pybloxom, j’aurais bien aimé retrouver les billets de mon vieux vieux blog, mais il semble que google n’ai pas daigné en garder du cache, que archive.org n’ai pas en la présence d’esprit de remarquer la contribution importante qu’ils représentaient… que je n’ai pas d’accès immédiat à mon serveur de l’époque (présentément eteinds), et que donc, je soit incapable, et sans doute pour un certain moment, de les récupérer.

Life’s life ^^.

sinon en ce moment je lis “the pragmatic programmer” qui contient une foule nombreuse de sages conseils sur le développement, reste à avoir l’intélligence de les mettre en application…

On utilise un outil pour son usage, on peut faire des trucs super chiants aussi avec Python ou Django. Partant de là, comment parler des usages possibles, facilités par ces outils ? Ou reformulé un peu différemment, qu'est-ce qui me motive pour utiliser ces outils dans mon quotidien ?

Une lecture dont vous êtes le héros : soit vous voulez visionner l'intervention dans son intégralité (25 minutes) et je vous conseille de ne pas lire la suite avant (mais de sauter à la fin), soit vous continuez la lecture et vous pourrez vous rattrapper plus tard.

J'ai choisi d'explorer 2 axes un peu inhabituels : les vacances et le fun !

Vacances et productivité

Si on veut pouvoir partir en vacances confortablement, il va en fait falloir être plus productif, et ça la productivité ça parle à tout le monde et ça fait pro :-).

Apprentissage

L'apprentissage de Python est l'un des plus rapides qui soit, on peut l'enseigner aux enfants, aux élèves, aux développeurs, il suffit de quelques heures pour en maîtriser les bases. Avec quelques bases, on peut hacker son premier programme en quelques minutes. Vraiment.

Rapidité d'apprentissage signifie aussi facilité à intégrer de nouvelles personnes dans une équipe ou à transférer des compétences sur un projet (ce qui est plutôt utile pour partir en vacances tranquille).

Agilité

Agilité : vaste programme car on en arrive à mettre tout et n'importe quoi derrière ce terme. En quoi Python vous fait gagner en agilité ? Il y a bien sûr l'usage des tests dont je parle ensuite qui rendent les refactorisations moins douloureuses, évitant les régressions inévitables autrement. Mais c'est surtout à l'usage que l'on se rend compte à quel point le langage est flexible et puissant.

Réutilisation

La philosophie de Python et d'être batteries included, c'est à dire de proposer une bibliothèque standard complète permettant d'effectuer les tâches courantes avec le langage de base sans avoir à installer des bibliothèques tierces. Ceci favorise le code portable et réutilisable entre plusieurs projets.

Fun et qualité

La relation entre le fun et la qualité ? Une équipe qui prend du plaisir à développer va introduire de la qualité dans son produit.

Conventions

Python repose sur des conventions de codage fortes qui favorisent la compréhension du code par un autre développeur. Ça paraît anodin énnoncé ainsi mais c'est pourtant capital pour la réutilisation et la maintenabilité du code. Lorsque vous prennez un code en main, bibliothèque externe ou code de votre collègue, vous n'allez pas être perdu grâce à une normalisation familière. C'est un gain de temps considérable à l'usage.

Tests

Python encourage l'usage des tests qui sont indispensables à la pérennité d'un code. Je ne vais pas me répéter sur ce point, c'est juste la représentation du capital de votre application, ce qui fait finalement sa valeur à long terme.

Élégance

Ici aussi, je vous renvoie sur le billet l'Artiste qui sommeille en chaque geek, la part d'élégance que vous pouvez trouver dans votre code dépend de vous, de votre sensibilité et de la vision que vous avez de vos créations.

En conclusion, grâce à une productivité accrue et à la qualité de son code, on gagne en séreinité et en confiance.

Django

Je ne vais pas réexpliquer la boîte à outils qu'est un framework web, vous pouvez aussi consulter une ancienne présentation sur Django si vous souhaitez aller plus loin.

Applications réutilisables

C'est aujourd'hui LE point fort de Django : un écosystème d'applications développées par la communauté de très bonne facture. Vous cherchez une application pour faire de l'OpenID, gérer des droits finement, pousser vos média sur S3, etc etc c'est possible et facilement intégrable à votre projet.

Cohérence

Le framework ayant été pensé dans sa globalité, on retrouve une cohérence et une qualité constante sur les différents points du framework. Et l'une des grandes forces de Django c'est la cohérence de sa documentation et son excellente qualité. Allez faire un tour dessus, ce n'est pas une légende :-).

Rapidité

Enfin un dernier argument en faveur de Django, c'est la rapidité de développement rendue possible grâce aux nombreux outils mis à disposition par le framework permettant d'éviter les tâches fastidieuses et répétitives. Vu la vitesse à laquelle les sites évoluent, c'est un point essentiel à prendre en compte au lancement d'un projet.

Démonstration et code

Suite à la théorie, j'ai réalisé une démonstration live de ce que l'on pouvait avoir en pratique qui a également été filmée. Et je viens de rendre le code accessible pour que vous puissiez continuer/hacker/etc, c'est un twitter-like qui reprend pas mal des concepts Django. J'ai ajouté un peu de code pour que vous puissiez aller plus loin, pour repartir de la présentation il suffit de prendre la révision qui va bien. N'hésitez pas à poser des questions ici au besoin.

Formation

Suite à cette intervention était prévue une formation qui malheureusement a été reportée faute de participants. C'est vraiment dommage car j'étais bien motivé et j'espère qu'il y aura davantage de curieux lors de la prochaine session. Si vous êtes intéressé, n'hésitez pas à me contacter ou à contacter Stéphane, en plus le cadre est vraiment unique !

En conclusion, j'ai eu des retours assez positifs et j'espère avoir convaincu ou au moins donné envie à certaines personnes présentes d'essayer de nouveaux horizons :-). Si l'agilité vous intéresse (et ça devrait), je vous encourage également à aller consulter les vidéos de Claude Aubry.

Voici la traduction du livre de Baiju Muthukadan sur la Component Architecture de Zope 3, (la ZCA). Cette traduction avait été commencée il y a deux ans par Stéphane Klein (que je salue et remercie au passage) et j'ai enfin trouvé le temps de la terminer.

La Component Architecture, qu'est-ce que c'est ?? C'est juste une paire de paquets Python complètement indépendants de Zope, qui vous permettront de rendre votre application vraiment modulaire, là où c'est nécessaire (inutile d'en abuser). Le principe est excellent, et basé sur des motifs de conception éprouvés et utilisés de manière intelligente. Cette architecture est utilisée dans plusieurs frameworks ou applications comme Zope 2, Zope 3, Grok, Repoze.BFG, Twisted, le Launchpad de Canonical, ou le gros CMS Plone. Je l'ai utilisée dans plusieurs projets comme l'Eztranet (un extranet pour agences de production vidéo), le site relief.fr, ou pour SOS_Epidemio, un logiciel de tracé épidémiologique pour SOS Médecins.

$ sudo aptitude install bzr

$ bzr branch lp:~baijum/zcadoc/book

$ bzr branch lp:~ccomb/zcadoc/book-fr

Samedi dernier (le 28nov), c'étaient les JM2L 2009. Le même genre de journées que les RMLL ou les JDLL, mais à Sophia Antipolis et organisé par Linux Azur. La concurrence fut rude car au même moment se tenait l'Ubuntu Party 9.10 de Paris qui, boostée par la présence de Mark Shuttleworth, a accueilli 5000 visiteurs sur deux jours (une progression de 25% par rapport à 2008). Je suis arrivé samedi matin par le train de nuit, et reparti samedi soir avec le même train. Entre les deux j'ai réussi à improviser un stand AFPY, à suivre la présentation du langage Lisaac et d'Isaac Os par Benoît Sonntag (impressionnant), et à présenter la façon de faire du développement web par composants.

Voici ci dessous les slides au format PDF et directement en ligne. C'est une concaténation des deux présentations faites pour OSDC FR 2009, avec une courte introduction sur Python. Le but de la présentation était d'expliquer comment découper proprement une application web, d'abord à haut niveau grâce à un assemblage WSGI, mais aussi au niveau des classes et des composants métiers en utilisant la Component Architecture de Zope 3.

[PDF] Le web par composants (en Python)

Your browser does not support iframes.

Merci encore à René Mages et à Linux Azur pour l'accueil et l'orga !

On va voir aujourd'hui comment grâce au module imPacket réalisé un man in the middle en utilisant la méthode de l'arp poisoning.

Qu'est-ce quele man in the middle ?
C'est une attaque qui a pour but d'intercepter tous les paquets transitants entre A et B .

Et l'arp poisoning ?
C'est une technique utilisant le protocole ARP  qui va faire en sorte que A envoit ses paquets à C au lieu de B.
Du coup, si on utilise aussi l'arp poisoning sur B, C peut écouter tous les paquets qui transitent entre A et B : c'est le man in the middle.
Il existe plusieurs méthodes, on va utiliser celle qui consiste à envoyer des réponses ARP aux cibles (A et B), et vu que le protocole ARP ne vérifie pas si une requête ARP a été faite au préalable, on va pouvoir modifier la cache ARP des cibles sans difficulté.

C'est parti.

La topologie de mon réseau éthernet dans lequel j'ai réalisé le script (simple&court) est on ne peut plus basique :
2 ordinateurs(A et C) directement reliés au routeur(B).
Je suis C et, je veux écouter tout ce qui se passe chez A.

Tout d'abord, il faut activer le routage :

Maintenant, il faut connaitre les IP de A,B,C ainsi que leurs MAC.
un petit coup de nmap -v -Sp 192.168.1.0/24 | grep "up" et de arp -v résoudra tout (ajustez le sous réseau).

Et voici le script :

N'oubliez pas de changer les valeurs des variables des lignes 7 à 15.
Je n'explique pas le script, tout est commenté et devrait suffire ?

Un petit coup de wireshark et vous verrez les paquets de/vers A.

PS : pour toute question envoyez-moi un mail (cf la page "À propos"), j'ai désactivé les commentaires à cause du trop gros nombre de spams.

Pierre de Rosette

Lors des deux articles précédents, j'avais à la fois évoqué la méthodologie "développement dirigé par les tests" et montré un exemple d'implémentation en Python. Mais nous avions aussi constaté que ces tests, très utiles au développeur, ne disaient généralement rien dire au "client" ou à la personne pour laquelle l'application est faite (utilisateur). On pourra raconter ce qu'on voudra à Monsieur Lambda, il ne comprendra pas ces classes et ces méthodes, que ce soit écrit en Python, en Java, en C, en Intercal...

Il manque une Pierre de Rosette entre le technicien et le non-technicien. Cette Pierre de Rosette existe, sous un formalisme "humainement lisible" :

Feature: Addition
    In order to avoid silly mistakes
    As a math idiot
    I want to be told the sum of two numbers

    Scenario Outline: Add two numbers
        Given I have entered 2 into the calculator
        And I have entered 3 into the calculator
        When I press add
        Then the result should be 5 on the screen

C'est en anglais, certes. Mais on peut remarque qu'il y a une certaine "structure" dans ce texte.

[Feature:] Addition
    [In order to] avoid silly mistakes
    [As] a math idiot
    [I want to] be told the sum of two numbers

    [Scenario Outline:] Add two numbers
        [Given] I have entered 2 into the calculator
        [And] I have entered 3 into the calculator
        [When] I press add
        [Then] the result should be 5 on the screen

Les mots encadrés sont facilement repérables en tant que "mots-clés". Il est assez facile de fabriquer un programme qui repère les phrases commençant par "Given" ou "I want to" et de déterminer le comportement du programme. Tiens, si on l'écrit en Français, c'est encore mieux :

Fonctionnalité: Addition
       Pour éviter des erreurs idiotes
       En tant que nul en maths
       Je veux qu'on me donne la somme de deux nombres

Plan du Scénario: Ajouter deux nombres
       Soit le nombre 2 entré dans la calculatrice
       Et le nombre 3 entré dans la calculatrice
       Lorsque j'appuie sur ajout Alors le résultat doit être 5 à l'écran
   

On a là un document lisible pour le péquin moyen, le client lambda. Un document en Français, qui décrit le comportement de l'application dans une langue que peut comprendre un "non-ordinateurien". Et comme il a une structure, et que cette structure est "facilement" analysable par un programme informatique.

Ce programme, tu t'en doutes, il existe :

Cucumber

Cucumber est un outil écrit en Ruby, qui implémente le formalisme décrit ci-dessus. Comme indiqué sur le site de Cucumber, on peut écrire des spécifications en langage "naturel", qui sont ensuite traduites en tests en Ruby, et on peut alors procéder aux cycles classiques du TDD (cf. l'article précédent), à savoir : écriture du test qui doit échouer, implémentation jusqu'à ce que le test passe au vert.

Youpi ! Formidable !

Ça veut dire que, durant la phase "d'analyse" (ou de préparation à l'implémentation), le client ou son représentant peut rencontrer l'équipe de développement, se mettre autour d'une table et parler un langage commun. On imagine bien la rédaction commune de ces documents de spécification, qui peuvent utiliser le langage métier du client et que l'équipe de développement peut rapidement transformer en tests que le programme va devoir faire passer.

Seulement... Il y a une chose qui me dérange, personnellement. Le langage de développement que je privilégie, c'est Python. Et faire fonctionner Cucumber avec Python, c'est peut-être possible, mais ça nécessite l'installation de RubyPython, etc... je me suis dit qu'il devait y avoir une autre solution. Analyser la structure d'un texte en Python, c'est une chose très accessible, il y a des dizaines d'outils qui savent faire ça.

J'ai cherché et j'ai trouvé une implémentation 100% en Python, appelée Freshen.

Freshen s'installe comme plugin à l'exccccccellent Nose (j'en ai parlé là déjà). Tout développeur Python qui se respecte et qui pratique TDD se doit d'utiliser Nose, déjà. Lancer nosetests, c'est comme un réflexe. Normalement, tu devrais même avoir un alias pour lancer cette commande plus vite, plus souvent. Voilà.

Freshen n'est pas parfait, loin de là. Certaines fonctionnalités de Cucumber ne sont pas implémentées. Certes. Mais une chose m'embêtait plus que les autres : les fichiers de spécification doivent être écrites en anglais. Ça fait même plus que m'embêter : ça emmerde aussi n'importe quel "non-ordinateurien" qui ne parlerait pas anglais. Ça fait un paquet de monde. Il faut imaginer un demandeur, un décideur, qui n'a pas forcément besoin ou envie de parler l'anglais, faire confiance à une spécification écrite en anglais. Pour lui, le bénéfice de cette méthode, c'est zéro : autant lui filer l'impression d'un code Perl, ça aura autant d'intérêt pour lui.

Mais... s'il est en Python, je peux le comprendre. Si je peux le comprendre et que sa licence le permet, c'est que je peux l'adapter pour qu'il puisse causer Français. Et Espagnol. Et Basque. Et Espéranto. Et même Klingon !

J'ai donc fait (du mieux que j'ai pu) un clone du dépôt sur GitHub et adapté Freshen pour qu'il puisse causer la langue de Molière.

Désormais, on peut lancer nose avec les arguments suivants :

$ nosetests --with-freshen --lang=fr

et les fichiers de "features" (fonctionnalités) sont interprétés dans la langue de son choix.

Les langues disponibles sont strictement identiques à celles implantées dans Cucumber, puisque j'ai poussé le vice en "empruntant" le fichier de langues de Cucumber (qui définit les mots-clés anglais et leurs traductions) pour alimenter les traductions de Freshen. Y'en a 40. Pas mal non ?

Ceux et celles qui veulent tester ce Freshen qui fleure bon désormais le camembert, la paëlla et le gloubiboulga, la branche s'appelle "i18n" et les retours sur cette implémentation sont les bienvenus.

Voici un article de 3 pages dans Programmez n°124 (nov 2009), rédigé pendant mon temps de travail chez Alter Way Solutions. Voici l'intro :

Un langage de programmation est un moyen, pas une fin. Pourtant, le choix d'un langage peut avoir des conséquences non négligeables sur la vie d'un projet, aussi bien au niveau technique qu'humain. Souvent, ce choix n'est d'ailleurs pas discuté : le langage est imposé, que ce soit par le développeur, le chef de projet, le projet lui-même, le client ou tout autre raison. Pourtant ce choix mérite qu'on s'y attarde un moment, étant donné la très grande diversité des langages existants. L'évolution des langages suit des modes à court terme et des tendances à plus long terme. On peut établir des classements selon de nombreux critères comme la syntaxe, le typage, le mode d'exécution ou le paradigme de programmation. Ces critères doivent vous guider lors de votre choix.

Je peux pas en mettre plus ici, mais vous pouvez télécharger un PDF (le minimag) qui contient les deux premières pages. Et si vous achetez le magazine, vous découvrirez en troisième page un magnifique classement qui place Python 1er, C++ 2ème et Haskell 3ème ! De quoi s'agit-il ? ;)