J'ai profité d'une petite soirée à peu près libre pour bidouiller deux-trois choses sur Beer Over IP.

Mais c'est quoi Beer Over IP ?

BeerOverIP est un "protocole" permettant à un internaute d'envoyer une bière virtuelle à quelqu'un d'autre. Pour le remercier, par exemple. Ou étancher sa soif. Pour utiliser ce protocole, c'est facile, il suffit d'envoyer un lien vers beeroverip.org au destinataire, et le tour est joué !

Nouveautés

• Grâce à Victor Stinner (plutôt connu sous le pseudo de *haypo* dans la communauté Python), j'ai rajouté la Leffe Brune et le Picon à la liste des breuvages disponibles.
• La discussion qui a amené aux ajouts ci-dessus m'a rappelé qu'il fallait que je signale que le site était propulsé par Django. Logo rajouté.
• En quelques minutes, j'ai intégré un *flot* RSS, afin que tout un chacun soit informé dès qu'une nouvelle bière est disponible pour le transport via IP. Fais chauffer ton aggrégateur.
• Et pour finir (on garde le meilleur pour la fin), j'ai rajouté la Kro à la liste des bières disponibles. Parce qu'il n'y a pas de raison pour qu'on n'envoie que des bonnes bières via ce protocole. Si tu n'aimes pas quelqu'un, tu peux lui envoyer de la pisse d'âne.

Kronebourg, by gzap, Creative Commons licensed, CC-BY-NC-SA.

BUUUURRRRRP !!!

Contribuer

Si parmi les bières disponibles tu ne trouves pas ton bonheur, tu peux élargir notre catalogue soit :

• en adressant un rapport de bug sur la page Launchpad prévue à cet effet. Pour bien faire, si tu as une photo d'une bière manquante, et que tu peux la publier sous une licence libre, tu peux l'ajouter en pièce jointe à ce rapport de bug.
• tu peux aussi me contacter en m'envoyant le nom de la bière, sa photo et une description, ainsi que la licence choisie pour cette image.

Au Plone 3 Paris Sprint en début d'année j'avais bossé avec Kaï et JF sur collective.buildbot. Du coup j'ai profité du Paris Bobün Sprint pour continuer.

J'ai ajouté une template Paste à collective.buildbot:

buildbot@cecilia:~$ paster create --list-template
Available templates:
  basic_package:  A basic setuptools-enabled package
  buildbot:       A template for collective.buildbot
  ...

C'est assez pratique pour monter un buildbot rapidement et pas se prendre la tête en passant des heures à lire la doc.

C'est relativement simple. On utilise la template qui pose quelques questions:

buildbot@cecilia:~$ paster create -t buildbot gawel.org
Selected and implied templates:
  collective.buildbot#buildbot  A template for collective.buildbot

Variables:
  egg:      gawel.org
  package:  gawelorg
  project:  gawel.org
Enter port (the port to use for internal communication) ['9050']: 6050
Enter wport (the port to use for web interface) ['9080']: 6080
Enter vcs (the vcs type. hg, bzr and git are supported.) ['svn']:
Enter vcs_url (the url to checkout from) ['']: https://svn.gawel.org/gp.fileupload/trunk
Creating template buildbot
Creating directory ./gawel.org
blabla...

Et voilà... On lance 2/3 commandes histoire d'avoir quand même un truc à faire. Sinon c'est un coup à devenir feignant:

buildbot@cecilia:~$ cd gawel.org/
buildbot@cecilia:~/gawel.org$ python bootstrap.py
Downloading http://pypi.python.org/packages/2.4/s/setuptools/setuptools-0.6c9-py2.4.egg
blabla...

buildbot@cecilia:~/gawel.org$ ./bin/buildout -U
Creating directory '/home/buildbot/gawel.org/eggs'.
blabla...
Generated script '/home/buildbot/gawel.org/bin/master'.
blabla...
Generated script '/home/buildbot/gawel.org/bin/cecilia'.

On a maintenant deux script qui correspondent au master et au slave. Si vous ignorez ce qu'est un master et un slave, reporté vous à la documentation buildbot.

Y a plus qu'a les lancer:

buildbot@cecilia:~/gawel.org$ ./bin/master start
blabla...

buildbot@cecilia:~/gawel.org$ ./bin/cecilia start
blabla...

Le tout doit pas prendre plus de deux minutes. Et ça marche. Comme quoi des fois un titre à une signification.

Bien sur, on peut affiner la configuration, utiliser Mercurial ou git, etc. Mais il faut lire la doc.

[via Eric Florenzano ]

Lors de sa présentation durant DjangoCon, Cal Henderson, co-créateur de Ruby on Railsarchitecte de Flickr et codeur PHP a dressé une liste éloquente des points à cause desquels il détestait Django (certains points sont valides, d'autres légèrement plus discutables, mais ce n'est pas le sujet).

L'un de ces points était :

Django n'a pas de mascotte

Certes. Rails non plus, m'enfin.

Saluons quand même cette très audacieuse tentative par Bryan Veloso pour donner à Django une mascotte :

Django, le framework web pour les poneys à pouvoirs magiques

(image sous contrat Creative Commons - BY-NC-ND)

Mise à jour : Le logo possède une version verte

L'ensemble de la Djangophonie a fait écho de la sortie, le 3 septembre dernier, de la version 1.0 du framework web Django.

Pour ma part, concernant une application développée dans le cadre professionnel, j'ai eu l'occasion de migrer d'un 0.96 à un 1.0. En suivant la documentation qui est d'une absolue perfection, on obtient en quelques minutes une version améliorée d'un modèle simple, pour lequel les tests passent et le fonctionnement général du site est identique. S'il fallait noter un framework sur la qualité de sa documentation, Django obtiendrait sans doute un 10/10.

La partie qui a le plus changé est sans doute le mécanisme de l'API de la base de données, ainsi que la branche "newforms-admin" qui refond totalement la manière de générer l'interface de gestion automatique. La création d'un fichier "admin.py" est d'ailleurs extrêmement facilité par ce snippet qui crée le fichier en scannant le fichier "models.py".

Pour ma part, je regrette quand même la disparition des validateurs, qui permettaient d'obtenir un début de contrôle de données très simplement. Au prix de quelques contorsions, c'est encore possible, mais je préférais définir simplement en deux lignes un validateur personnalisé (genre "un nombre entier qui doit se trouver entre 0 et 100 pour un pourcentage"). Less code is more.

En revanche, la partie "test" est absolument bluffante. Non seulement on peut facilement tester les modèles et leurs méthodes, c'est à dire le fonctionnement "sous le capot" de ton application, mais on peut également tester les vues, et mêmes les vues nécessitant une authentification, pour s'assurer que les pages renvoyées sont correctes. Habituellement, cette partie donnait lieu à des tests manuels (genre, pour une boutique, je me connecte, je crée un panier ou encore je remplis un formulaire d'inscription avec des données bidon, ou invalides, ou correctes...). Là, tout peut être résumé à des tests unitaires complets, lancés aussi régulièrement que possibles.

Franchement, cela ouvre des milliers de possibilités, dont celle de coder un site web sans jamais lancer le moindre navigateur. Si, si, on peut.

La migration de JHLP en Django 1.0 me chatouille ; il faudra que je réfléchisse à la question... Mais à mon avis, si je devais commencer une appli en Django ou migrer une application simple en 1.0, je foncerais sans hésiter.

Pour information, chez mon hébergeur Alwaysdata, Django 1.0 est déjà disponible. Qui parlait de réactivité, déjà ?

C'est au prix de quelques sobres petites soirées que j'ai fini par aboutir à un code minimal pour propulser Beer Over IP dynamiquement, à l'aide d'une petite application Django (0.96).

Pour bénéficier de la toute-puissance de cette application web que le monde nous envie, il suffit d'aller faire un tour sur la liste des bières disponibles. Évidemment, pour le moment, cette liste est assez courte... Mais je suis totalement persuadé que toi aussi, tu peux aider à l'allongement de cette liste en fournissant via l'interface de bug de Launchpad :

• le nom de la bière,
• une photo ou un lien vers cette photo, sachant que ce média doit être absolument libre (license Creative Commons, par exemple),
• les crédits appropriés,

À toi de jouer, bientôt, ta binouze favorite sera accessible à tous et toutes, via l'Internet.

Le code de cette application est publiée sous une double license... Non, pas la license IV, mais presque. L'application est libre, sous license WTFPL et BEERWARE. La première permet de faire ce que tu veux j'en ai rien à foutre, tandis que la suivante pose une condition : tu peux faire ce que tu veux avec ce code, mais si on a l'occasion de se rencontrer dans la vraie vie, tu peux me payer un verre.

Comme annoncé sur la page du projet dans Launchpad et comme le rappelait Florian "tiax" Heinle, PyRoom 0.3.1 a été mis à disposition, et est à présent prêt à être traduit... Déjà quelques langues sont déjà disponibles, mais quiconque avec des bonnes notions d'anglais et d'une autre langue peut aider à rendre PyRoom accessible dans toutes les langues du Monde (voire au-delà).

À noter qu'on peut, sous réserves de quelques opérations légèrement geeks installer directement PyRoom dans Ubuntu en utilisant le dépôt PPA officiel.

A ouais... taper

sudo apt-get install pyroom

Trop bien.

J'étais assez sceptique lors de l'annonce de la roadmap avant l'été mais il faut bien avouer que ça n'a pas chômé pendant ces vacances et que les développeurs sont arrivés à bout des fonctionnalités annoncées. Chapeau bas. Je ne vais pas faire un inventaire exhaustif des nouveautés (je vous laisse consulter la page dédiée) mais plutôt une liste des ajouts vraiment intéressants au quotidien au cours de cette dernière année.

Support complet de l'Unicode

Mergée l'été dernier, le nom de cette branche est assez explicite. Terminés les problèmes de charset/encoding lorsqu'on a des données propres, sinon iconv est votre ami.

Commandes personnalisées

La refactorisation des commandes internes de Django permet depuis un an d'ajouter très facilement des commandes personnalisées à votre projet. Vous pouvez par exemple voir ce que ça donne sur le script qui récupère les flux affichés dans la sidebar de ce site.

Échappement des variables dans les templates

Changement de la politique de sécurité en novembre dernier avec les variables échappées par défaut. Selon les cas, ça peut être pénible pour les mises à jour mais c'était à mon avis utile pour permettre aux débutants de ne pas faire trop d'erreurs à ce niveau. Il est toujours possible de contourner cette restriction via le filtre |safe ou le tag autoescape (great power, great responsabilities, tout ça).

Refactorisation des querysets

Fin avril, un énorme boulot est effectué en interne afin de corriger pas mal de bugs récalcitrants, ça permet (entre autres) d'ordonner plus facilement les querysets, de spécifier les champs couverts par un select_related, d'optimiser la façon de filtrer les résultats, de mettre à jour plusieurs instances d'un coup et surtout, le retour de l'héritage au niveau des modèles !

Modifications dans l'upload de fichiers

Début juillet, ça commence à s'accélérer, il est maintenant possible de lire les fichiers uploadés partie par partie. Ça n'a l'air de rien mais selon les types de fichiers sur lesquels vous travaillez ça peut vraiment faire la différence.

Nouvelle administration utilisant les newforms

C'est LA fonctionnalité qui donne à mon avis à Django une longueur d'avance sur les autres frameworks. Ajoutée mi-juillet, cette branche permet de générer une interface d'administration qui tient compte des droits utilisateurs, qui est vraiment flexible et customisable. L'interface qui était réservée aux personnes de confiance (administrateur) peut maintenant être utilisée pour développer un site complet. Le problème c'est qu'à partir de cette date là, avec les vacances et les commits qui s'accélèrent il devient plus prudent d'attendre la 1.0 et cette fonctionnalité n'a pas eu la promotion qu'elle méritait à mon avis. Cela dit il est temps de tester sa puissance maintenant, je joue avec depuis quelques jours et c'est vraiment du bonheur.

Ajout du support géographique

GeoDjango est enfin ajouté dans les contrib, très beau projet avec énormément de fonctionnalités indispensables lorsque vous commencez à vouloir savoir qui habite près de qui, quelle est la distance parcourue, etc.

Refactorisation des stockages de fichiers

Bon celui là c'est un peu mon chouchou car je l'ai testé à plusieurs reprises pour faire des retours à Marty Alchin et ça m'a mené à partager certains storages utiles pour Django. Il permet par exemple de stocker ses fichiers en local pour du développement et sur S3 pour de la production ou n'importe quelle combinaison possible et imaginable.

Nouveau système de commentaires

Pour finir, ce qui était attendu depuis... toujours, un GSoC est arrivé à terme ! Les commentaires ont été entièrement réécrits, j'utilise une version alpha de cette implémentation et je ne sais pas si je mettrais à jour, peut-être à l'occasion mais elle a l'avantage de ne pas être standard et pour lutter contre le spam on ne fait pas mieux ;-).

Enfin, il y a eu pas mal de ménage de fait sur d'anciennes parties de code (suppression des oldforms/validators entre autres), ce qui le rend plus facilement maintenable et une nouvelle documentation propulsée par Sphinx (l'outil qui mériterait un petit système de tickets pour être tout à fait parfait). Que du bon. De mon côté, on peut pas dire que j'ai vraiment avancé sur mes tickets, j'ai pas mal discuté de l'intérêt de l'utilisation du tag url dans blocktrans et au final la solution est venue presque par hasard ! J'ai pas eu le temps de m'occuper de tout ce qui était relatif à la séparation des tests mais j'ai mis à jour les traductions (ce qui représentait un sacré boulot, heureusement que j'ai eu de l'aide de la team fr).

Une année riche en nouveautés qui montre le dynamisme du framework, la 1.0 n'était qu'une étape nécessaire permettant de partir d'une base saine. Il y a encore 2/3 choses qui méritent d'être remises à plat pour la 1.1 mais sinon c'est clairement positif. Avec de telles fondations, il devient de plus en plus facile de développer son projet parfait, en tenant les délais ;-). Il ne manque plus que la sortie de Starcraft 2 pour faire le grand chelem...

PS : ça sort dans quelques heures, un peu de patience, je le publie maintenant suite à une petite erreur de ma part. En attendant qu'est-ce qui vous pousse/retient d'utiliser cette version ?

[edit du soir] : bon finalement ça commence par une faille de sécurité qui sera suivie d'une RC1.

[edit du 4 septembre, 1h47] : sortie de la version 1.0. Enfin.

La page officielle de migration est un bon début si vous n'êtes pas à jour.

L'ami Gilles Fabio, me dit de te dire qu'en ce premier septembre 2008, il rouvre un site perso, propulsé par Django et au code source publié sous licence GPL v2+.

En attendant que le contenu débarque en masse, on peut tout de même se réjouir et appeler ça une très bonne nouvelle.

Décidément, 2008...

Je viens de releaser gp.fileupload 0.5 qui fournis un ensemble de middlewares WSGI pour gérer l'upload de fichiers.

On pensait que la saison avait un fort impact sur le recrutement, mais il arrive qu'on soit détrompé.

La société pour laquelle je travaille, Interface IP, cherche à recruter un développeur web "agile". Nous travaillons quasi-exclusivement en utilisant le framework web Django, et c'est en priorité ce type de profil que nous recherchons, mais nous n'excluons pas d'étudier les candidatures de développeurs ayant suffisamment de curiosité intellectuelle pour avoir envie de découvrir de nouvelles technologies...

La curiosité c'est bien, mais l'expérience, c'est encore mieux : évidemment, il faut posséder une bonne culture Web et maîtriser au moins un framework web de type MVC (rails, symfony, turbogears, DJANGO) mettra ton CV sur le dessus de la pile. Si en plus tu es familier d'un gestionnaire de révisions (mercurial, bzr, git, svn...) et que tu pratiques le développement dirigé par les tests (TDD), alors c'est le summum.

Notre société est basée à Bayonne, France, et si nous acceptons une dose de télétravail, il est plus facile pour nous d'avoir quelqu'un sur place.

Contacter Sébastien Guibert, en adressant CV + petit mot gentil à recrutement arobase interfaceip point fr

(il n'est pas nécessaire de parler basque pour répondre à l'annonce)

On peut dire que c'est une sorte de "release" : les slides (format S5) et le code source de Baguette on Snails sont disponibles.

J'ai choisi la license WTFPL pour publier le code. D'abord, parce qu'elle est libre, qu'elle est compatible avec elle-même, et qu'elle correspond tout à fait avec le contenu de cette vaste blague.

En attendant la vidéo...

En ce moment je bosse sur une application en Pylons. J'adore ce petit framework, mais y a un truc que je pouvais pas encadrer, c'est de faire des tests avec des TestCase. Je préfère de loin les doctests.

Me voilà donc partit à la recherche de docs pour pouvoir écrire mes tests comme j'aime les écrire. Pylons utilise nose comme framework de test. Je découvre alors avec joie que nose fournit un plugin pour parcourir les doctests. Chouet !

Le problème, c'est que ce plugin est carrément rudimentaire. En gros, il choppe vos doctest et les initialise ultra basiquement. Comprendre: impossible de passer des options telles que optionflag, setUp ou tearDown. En bref, ça pu. Comment je fais pour initialiser mon framework Pylons pour mes tests moi ? Hein ?

J'ai finalement trouvé une solution en surclassant la classe doctest.DocFileCase afin de faire ce que je veux. Voici le code en question. Il suffit de le placer dans le fichier tests/functional/test_docs.py de votre application Pylons:

# -*- coding: utf-8 -*-
import os
import doctest
import mypylonsapp
from mypylonsapp.tests import *

optionflags = (doctest.ELLIPSIS |
               doctest.NORMALIZE_WHITESPACE |
               doctest.REPORT_ONLY_FIRST_FAILURE)

dirname = os.path.join(os.path.dirname(mypylonsapp.__file__), 'docs')


def build_testcase(filename):
    name = os.path.splitext(filename)[0]
    path = os.path.join(dirname, filename)

    class Dummy(doctest.DocFileCase, TestController):
        def __init__(self, *args, **kwargs):
            # init pylons stuff
            TestController.__init__(self, *args, **kwargs)

            # get tests from file
            parser = doctest.DocTestParser()
            doc = open(self.path).read()
            test = parser.get_doctest(doc, globals(), name, self.path, 0)

            # init doc test case
            doctest.DocFileCase.__init__(self, test, optionflags=optionflags)

        def setUp(self):
            """init pylons stuff and make app available in doctest
            """
            TestController.setUp(self)
            test = self._dt_test
            test.globs['app'] = self.app

        def tearDown(self):
            """cleaning
            """
            TestController.tearDown(self)
            test = self._dt_test
            test.globs.clear()

    # generate a new class for the file
    return ("Test%s" % name.title(),
            type('Test%sClass' % name.title(), (Dummy,), dict(path=path)))

for filename in os.listdir(dirname):
    if filename == '.svn':
        continue
    name, klass = build_testcase(filename)
    exec "%s =  klass" % name

# clean namespace to avoid test duplication
del build_testcase, filename, name, klass

Vous admirerez la ruse qui est de générer une nouvelle classe pour chaque fichier trouvé dans le répertoire contenant les doctests.

On peut ensuite créer un fichier texte dans docs/ et y écrire des tests du genre:

>>> response = app.get(url_for(controller='main', action="index"))
>>> print response
Response: 200
...

Ce qui est tout de même vachement plus convi qu'un test classique.

J'aurais pu titrer "money for nothing" ou autre, mais bon.

Toujours est-il que la Django Software Foundation ayant été fondée il y a peu - le jour de mon anniversaire, c'est trop gentil, merci, elle a évidemment besoin de fonds. Comme l'indique la FAQ :

How will my donation be used?
The main focus of the Django Software Foundation is direct support of Django's developers. This means:
- Organizing and funding development sprints so that Django's developers can meet face-to-face — we're far more productive that way.
- Helping key developers attend these sprints and other community events by covering travel expenses to official Django meetups and sprints.

Traduction possible:

Comment mon argent sera-t-il utilisé ?
L'objectif principal de la Django Software Foundation est le soutien direct au développeurs de Django. ce qui signifie :
- l'organisation et le financement de sprints de développement, afin que les développeurs puissent se rencontrer face à face et soient plus productifs de cette manière,
- aider les développeurs-clés à participer à ces sprints et à d'autres événements communautaires en couvrant leurs frais de déplacement à ces rencontres et sprints Django officiels.

Allez, par ici la monnaie !

Mise à jour du 16 juillet 2008, 23:32 :

J'ai donné à Django

Bon nombre de gens utilise python pour faire de petits scripts. Le problème c'est que pour les distribuer, ensuite, c'est pas le top.

Heureusement il y a distutils !!

distutils est un paquet inclus dans les distributions python permettant de créer des paquet python.

Le principe est simple. On englobe un module python dans un paquet contenant un fichier setup.py

Le plus simple est d'utiliser paste pour créer son paquet. Renseignez bien les information demandées. Elles seront visible si vous décidez de distribuer votre paquet par la suite. Donc:

$ easy_install -U PasteScript
$ paster create monscript
$ cd monscript
$ ls
monscript/ monscript.egg-info/ setup.cfg setup.py

Ceci nous créer un répertoire monscript contenant un setup.py et un sous répertoire destiné à recevoir le code python.

Nous devons maintenant créer un point d'entrée pour notre script. Pour cela, nous allons modifier monscript/__init__.py pour qu'il ressemble à ça:

def main():
    print 'Yeah !'

Ensuite, en modifiant le fichier setup.py, nous pouvons associer ce point d'entrée à un véritable script qui sera installé à l'installation du paquet. Modifiez la section entry_points du setup.py pour qu'il ressemble à quelque chose du du genre:

entry_points="""
# -*- Entry points: -*-
[console_scripts]
mon_super_script = monscript:main
""",

Voilà, le tour est joué. Alors, pourquoi tout cela pour un simple script ? C'est simple. Vous pouvez maintenant aisément le distribuer.

Voici les principales commandes qui vous serons utiles:

• créer un tarball:

  $ python setup.py sdist
  

• créer un egg:

  $ python setup.py bdist_egg
  

• rendre le paquet disponible sur pypi:

  $ python setup.py sdist bdist_egg register upload
  

Un utilisateur lambda pourra ensuite l'installer simplement:

• via le tarball:

  $ wget http://exemple.com/monscript-0.1.tar.gz
  $ tar monscript-0.1.tar.gz
  $ cd monscript
  $ python setup.py install
  

• via pypi:

  $ easy_install -U monscript
  

Moralité, distutils rends la vie plus facile.

• Fait hier présentation devant une vingtaine de personnes.
• Piles de la télécommande nazes à cinq minutes du début.
• Piles qui ont réssucité après le retour à la maison
• 35°C à Mont-de-marsan ; punaise c'est délirant
• Conf en ligne.
• détails sur cette page dédiée

Maintenant, la conf du Lugradio Live...

Juste en passant, pour rappeler que mardi prochain, 1er juillet, à 14h, je donnerai une conférence intitulée "J'adore Django", dans le cadre des Rencontres Mondiales du Logiciel Libre (le lieu indiqué est RT/COURS RT - IUT... je ne sais pas du tout où est-ce que ça se trouve dans le dispositif... on verra bien).

Djangonaute ou pas, vient qui veut.

[via les forums Ubuntu-fr ]

Dans la série "une découverte Python par jour", voici Py2Deb.

Empaqueter des programmes est une tâche indispensable pour diffuser le plus largement possible des applications. Toutes les distributions Linux ont un système de paquets permettant d'installer / désinstaller sans soucis une application, en s'assurant par exemple qu'elle disposera de toutes les bibliothèques de fonction indispensables à son bon fonctionnement. Pour Ubuntu, basée sur Debian, le format des paquets est .deb. Il existe de nombreux tutoriaux, il y a même eu pas mal de cours sur IRC à ce sujet présentant la marche à suivre pour publier un .deb installable sur une machine "debian-based". Y'a même des vidéos.

Et un "je ne sais quoi" me freinait. Je construit de plus en plus d'applications (ou de jeux de scripts) plus ou moins complexes en Python, et la question du paquet se pose toujours à un moment ou un autre. La manière "pythonnienne", c'est d'utiliser les outils de la bibliothèque distutils, et de publier sur le Python Package Index, mais elle nécessite quelques opérations en ligne de commande pour que le commun des mortels puisse installer l'application et s'en servir. Je pense que ce mode de fonctionnement est plus efficace pour une bibliothèque, pour des gens qui savent ce qu'ils font quand ils lancent :

easy_install machin_chose

Un utilisateur lambda voudra télécharger un "machin", et double-cliquer dessus pour que le programme s'installe "tout seul". Et tant que le paquetage à la Debian n'est pas arrivé dans les dépôts (officiels ou officieux), difficile de passer par Synaptic ou Adept.

Py2Deb pallie à la difficulté de concevoir et produire un paquet .deb. Le programme est bien entendu disponible sur le site officiel via un paquetage .deb (à installer avec GDebi, par exemple), et il permet en quelques lignes de python de produire un paquet qui m'a semblé (j'ai pu le tester avec un "hello world" tout con) correct. Ça s'installe, ça se désinstalle, et paf.

Pour ceux que ça intéresse, je leur propose d'aller à la pêche aux infos dans la doc officielle.

Note : le présent article n'a pas été publié sur le Planet Ubuntu-fr pour deux raisons : d'abord parce que je m'interroge depuis quelques temps sur mon implication dans PUF, ensuite, parce qu'il parle de l'installation d'un paquetage ne se trouvant pas (encore) dans les dépôts officiels, et qui plus est, le programme décrit permet même de faire des paquetages.
Ce genre d'article a fait partie de moult polémiques sur la liste de diffusion du PUF ou ailleurs, et ça m'emmerderait assez que cette publication provoque une nouvelle vaguelette (dans le verre d'eau).

Pour ceux qui auraient les jetons, j'ai regardé le code source de Py2Deb ne fois installé : il n'y a guère qu'un script Python... Globalement inoffensif.

Cette après-midi, j'ai retrouvé mon collègue de geekerie, Olivier. Pendant que lui tentait de faire apprendre à rêver à son cher Dr Gumby, je me suis atteler à faire fonctionner django avec paste. Pas une mince affaire à priori. J'avais vu une tentative pour faire un paste.django qui semblait évoluer péniblement. Mais bon, je suis plein de courage.

J'ai finalement été assez surpris. Déjà, on trouve dans le trunk de django un WSGIHandler. C'est la fête ! Il ne reste plus qu'as l'associer à paste. Bon, je me lance.

La première chose que j'ai faites a été de transformer l'application en egg. Je comprends pas que ce ne soit pas fait de fait dans la template django... Soit, un simple setup.py et mon application peut-être intégrée dans mon buidlout.

Ensuite, première tentative pour utiliser ce précieux handler: créer une usine qui renvois le WSGIHandler tel quel. Échec. Forcément, django attends son fameux module de settings. Soit, avec un peu de chance, en le plaçant dans l'environ utilisé par l'usine, on vas y arriver. Re-échec.

Pourquoi ? Tout bêtement parce que django vas chercher cette valeur dans os.environ. Et là, c'est le drame. Enfin non, c'est à moitié le drame. En effet, en initialisant correctement la variable qui vas bien, on arrive finalement à utiliser ce handler.

Second problème, les url générées par l'application sont toutes erronées. En effet, un bug fait que django ne tiens pas compte de la variable SCRIPT_NAME. C'est bien dommage, mais un bon vieux hack permet de fixer le problème relativement facilement. Il suffit d'initialiser le PATH_INFO en le précédent du SCRIPT_NAME et le tour est joué.

Voici le résultat:

# -*- coding: utf-8 -*-
import os
from paste.deploy.config import ConfigMiddleware
from django.core.handlers.wsgi import WSGIHandler

def factory(global_config, **local_config):
  os.environ['DJANGO_SETTINGS_MODULE'] = 'jobsafpyorg.settings'
  conf = global_config.copy()
  conf.update(**local_config)
  app = ConfigMiddleware(WSGIHandler(), conf)
  def django_app(environ, start_response):
    environ['PATH_INFO'] = environ['SCRIPT_NAME'] + environ['PATH_INFO']
    return app(environ, start_response)
  return django_app

On peut ensuite se servir de cette usine comme point d'entrée et l'utiliser dans un fichier de configuration paste. Notez que le ConfigMiddleware est indipensable. Le handler de django semble renvoyer des choses peu ordinaire de type class, parfois. Le middleware permet de corriger tout cela.

Problème, si on veut plusieurs instance django dans un seul environnement wsgi, ça devient problématique. Comment initialiser plusieurs configuration avec une seul clé du dictionnaire environ... Je me le demande.

Cela dit, c'est un problème auquel je vais être confronter car j'aimerais fair cohabiter les deux applications django qui ont été faites pout l'AFPy. Donc, la suite au prochaine épisode.

Il y a peu, c'était Pycon FR, la récompense annuelle des efforts fournit dans cette belle association qu'est l'AFPy. Grande réussite de mon point de vue. La richesse et la diversité des conférences s'améliore, le public est plus nombreux. Python a de beaux jours devant lui.

J'y ai fait une conférence sur le WSGI. Ça à au moin eu le mérite de me faire réaliser que j'étais un bien piètre orateur. Probablement que l'AFPYro de la veille n'as rien fait pour arranger les choses, hin hin. En tout cas, j'espère que ça suscitera quelque vocations.

Je suis personnellement convaincu de l'intérêt de cette norme. Et j'ai maintenant un exemple concret à fournir. En effet, je bosse depuis plusieurs mois sur la nouvelle interface de gestion des membres de l'AFPy. Une petite application en Pylons qui permet d'administrer les utilisateurs de notre annuaire ldap et les inscription dans le Zope et les listes de diffusions. Elle est ici, pour ceux que ça intéresse. J'avais aussi fait une petite application compatible WSGI pour pouvoir afficher les photos avec un tag AFPy que les gens posent sur flickr. On avait aussi besoin d'un nouveau WIKI dans le cadre de la refonte du site. Le but était donc de brancher tout ce petit monde dans le site actuel. Heureusement, il y a findus^WWSGI.

Le paquet wsgi.afpy.org était né. Ça donne un petit fichier de configuration sympa qui dessers ces trois applications via un urlmap. Bien sur, le tout est géré avec zc.buildout, ce qui permet d'avoir un environnement python avec les paquets qui vont bien et de faire de l'administration ldap dans un shell python. Un exemple:

>>> from afpy.core import ldap
>>> user = ldap.getUser('gawel')
>>> user
<User dn:uid=gawel,ou=members,dc=afpy,dc=org>
>>> user.email
'gawel@afpy.org'
>>> ldap.getMembersOf('bureau')
[u'tarek', u'ogrisel', u'gwen', u'gawel', u'jpcw2002', u'ccomb']

C'est quand même super fun !!!

J'en connais qui vont se gausser en lisant ce post, mais bon, tant pis. Je dis toujours que le problème n'est pas dans le media, il est dans le message. Ça pourrait faire une belle phrase de conclusion, ça. Bon, donc, je la copie-collerai dans la fin de cet article, ça fera pas de mal.

J'ai eu le privilège de présenter Django lors des journées organisées par l'afpy. C'était vraiment un weekend exceptionnel, une organisation exemplaire, des conférences de qualité, des discussions de geek, que du bon. Je me suis enfin décidé à mettre les slides en ligne, en attendant les vidéos.

Historique

J'avais déjà présenté Django l'année dernière et j'avais vraiment eu l'impression de passer à côté de ma conf. Outre le fait que j'étais bien crevé d'avoir mis en ligne django-fr, j'ai relevé 3 gros défauts :

• je voulais que la présentation serve aussi pour les personnes souhaitant la consulter en ligne, au final c'est beaucoup trop verbeux et le code distrait à mon avis l'auditoire qui vient à une conférence pour s'enrichir d'une expérience et non pour une lecture de code ;
• je voulais faire plaisir à tout le monde en partant de la base pour aller vers des techniques plus avancées et au final personne n'y trouve vraiment son compte ;
• je voulais garder le public connecté et j'ai le sentiment d'avoir été plutôt ennuyeux : c'était long et ça manquait tout simplement de vitalité (sans compter quelques soucis avec S5).

Partant de ce constat, j'ai essayé cette année de :

• faire des slides minimaliste, l'objectif était qu'ils soient tout simplement inutiles sans moi (d'où le besoin de les enrichir pour vous les présenter maintenant, pas sûr que ce soit bon pour moi ça :p), c'est à mon avis le seul moyen de se focaliser sur l'expérience du présentateur et donc sur le message à faire passer ;
• scinder en deux sessions débutant/avancé pour laisser le choix au visiteur de n'assister qu'à la conférence qui l'intéresse ;
• trouver un moyen de rendre les confs plus vivantes (et utiliser Keynote).

Alors pari réussi ? Mon retour personnel après chaque conférence ci-dessous. J'essaye de retrouver ce que j'ai dit de tête, ça sera forcément différent des vidéos qui devraient arriver plus tard : moins de stress, davantage de temps pour étoffer et des liens en bonus.

Pourquoi Django ?

Je n'ai jamais eu de cours de marketing et je hais les commerciaux donc c'est vraiment une épreuve pour moi de « vendre mon produit ». J'ai surtout voulu aller à l'essentiel pour pouvoir ensuite en débattre pendant les questions/réponses.

Avant de parler de Django, il est bon de rappeler les intérêts d'un framework web face à l'approche plus traditionnelle par applications fonctionnelles toutes prêtes. Qu'est-ce qui a pu suscité un tel engouement ?

On connaît tous des projets qui commencent avec un projet tout simple (je prends souvent l'exemple du blog car il est assez parlant). Il existe des trillions de moteurs de blog et il est donc aisé d'en prendre un tout fait :

Mais bien (trop) souvent, un projet évolue en cours de route et l'ajout de fonctionnalités (galerie de photos, paiement en ligne, inclusion de vidéos) aboutit finalement à un cahier des charges ressemblant plutôt à :

Si vous êtes parti d'un simple moteur de blog rafistolé, il est très probable que vous arriviez à un résultat de piètre qualité :

La solution est de partir d'une approche plus bas niveau : la caisse à outil qui va vous permettre de construire vos propres briques fonctionnelles et de réaliser un projet de manière cohérente et évolutive.

De cette façon, vous allez énormément gagner en agilité, la clé de voûte de la qualité (du projet), de la sérénité (du développeur) et de la satisfaction (du client).

Maintenant que vous êtes convaincu du bien fondé des frameworks web, il est temps de passer au plat de résistance : pourquoi Django ?

Django est écrit en Python et vous permet d'écrire du Python, il n'y a pas de fichiers de configuration en xml (ai-je besoin de rappeler que ce format est fait pour les machines ?).

Django est très facile à prendre en main, il suffit de quelques heures (même sans connaître initialement Python) pour avoir une première application qui tourne et en comprendre les principaux concepts.

Face aux deux approches : framework glue vs. réinvention de la roue, Django a choisi la seconde ce qui apporte une cohérence à tous les niveaux (documentation, code, aide, etc) au détriment de sa modularité intrinsèque.

La documentation est un réel atout, surtout lorsqu'on débute. C'est l'une des meilleures documentation technique que je connaisse et elle est en train d'être encore améliorée !

Je suis assez mal placé pour parler de rapidité de développement avec la refonte de ce blog qui a pris... du temps. Néanmoins, pour l'utiliser quotidiennement, je peux affirmer que le développement avec ce framework permet de concrétiser plus rapidement des projets. L'un des atouts est par exemple de prototyper des applications en des temps records, après bien sûr les détails prennent plus de temps, comme partout.

L'interface d'administration auto-générée est vraiment utile et participe à l'« effet Wow !© » initial. Difficile de s'en priver ensuite.

L'échappement des caractères html par défaut peut être un élément important pour une personne débutant en développement web. Ce choix est une réelle sécurité si vous ne maîtrisez pas vraiment toutes les failles possibles d'un code (même s'il serait bon de vous renseigner à ce sujet si c'est le cas !).

Django est simple, autant dans ses concepts que dans leurs mises en application, si vous connaissez Python, vous pouvez même sans peine plonger dans le code de Django et découvrir quelques pépites.

La maturité est souvent un facteur décisif d'un point de vue professionnel, après 5 ans de développement, le framework est devenu stable et à énormément gagné de son ouverture en Open-Source (pour ceux qui se demandent ce qu'une litière pour chat vient faire ici, c'est un jardin zen, j'ai pas trouvé mieux).

Quelques chiffres issus de la présentation de l'année précédente, on voit bien la progression en terme d'utilisateurs et donc de contributeurs potentiels.

Enfin, l'avantage d'avoir des outils à sa disposition est de pouvoir laisser s'exprimer sa créativité, le plus important est ce que l'on fait avec ses outils. Vous pouvez prendre le meilleur des frameworks, ça ne vous assurera pas une application à succès. Ça serait bien trop facile sinon ;-).

Après avoir vanté autant de qualités, voyons pour quels projets cette caisse à outils s'applique.

Il n'y a pas d'outil miracle, notre métier est un éternel compromis et il faut savoir faire avec. L'avantage de Django est qu'il permet de couvrir un très large périmètre d'applications mais si vous voulez construire un gratte-ciel il va peut-être falloir penser à autre chose.

Cela dit, il y a un très faible pourcentage de projets web qui doivent en arriver là et il sera toujours temps de changer certaines parties ou d'améliorer les performances le moment venu.

On termine avec un peu de teasing...

On ne l'attend plus mais Django 1.0 arrive ! (si si, je vous assure) La première branche importante (queryset-refactor) a été mergée au trunk.

Et la suivante (newforms-admin) est en cours de finitions actives. Ce n'est plus qu'une question de ... (mettez ce qui vous semble le plus crédible et votez sur whendjangowillreleaseonepointzero.com).

Des fois que le message n'ait pas été assez clair (j'adore les photos de gens qui sautent dans les présentations, je trouve ça kitsch au possible ;-)).

Bilan personnel

Difficile d'enchaîner une nuit trop alcoolisée courte (il faut croire que c'est une malédiction) et d'insuffler suffisamment de vitalité. Je suis néanmoins assez satisfait car je pense avoir bien fait passer le message qui était tout simple : essayez Django !

L'exemple initial était assez fort pour capter directement l'attention, la liste des avantages était assez claire. Bon par contre je suis conscient qu'il y a du progrès à faire au niveau de la conclusion car je n'ai pas assez insisté à l'oral sur l'intérêt d'avoir une simple caisse à outils pour laisser s'exprimer sa créativité et je voulais insister là-dessus.

Je me suis permis quelques trolls un peu douteux sur Zope 3 (un peu la chance d'avoir assisté à la conf dessus la veille, un peu car on en a parlé une bonne partie de la nuit), je suis pas vraiment sûr que ça avait sa place. Quoi qu'il en soit, les éléments de comparaison cités dans la discussion qui a suivie étaient intéressants.

Django : performances et qualité

J'ai eu beaucoup plus de mal à préparer cette présentation car elle était très dépendante du public. Je voulais éviter de ne m'adresser qu'à une poignée de personnes et j'ai donc choisi au final une approche plus généraliste sur les bonnes pratiques web, appliquées à Django.

Un rapide sondage m'a montré que ce choix était pertinent et que me craintes étaient fondées. Moins d'un quart de la salle avait déjà essayé Django, et une poignée sur de gros projets. Adaptation à chaud : il valait mieux passer du temps sur les aspects pas trop pointus... quitte à décevoir ceux qui étaient venus pour l'intitulé de la conf !

Un rappel préalable sur le coût de la qualité et des performances s'impose. C'est un investissement dans une logique qui s'inscrit dans la durée, ce n'est pas forcément adapté à tous les projets et ça doit être mis en place d'un commun accord entre les acteurs du projet (les tests sont très difficiles à facturer).

Un titre qui claque, je suis sûr qu'en anglais ça rend encore mieux.

Il existe de nombreux outils de détection, du simple module logging à ceux permettant de stresser votre application et votre architecture.

Avant d'optimiser, il faut bien évaluer la situation, il ne sert à rien d'optimiser un site qui ne rencontre pas de problèmes de performances, privilégiez plutôt l'expérience utilisateur (ergonomie, etc). Si vous n'avez pas le temps d'optimiser, vous pouvez toujours avoir une expansion horizontale dans un premier temps (plus de serveurs) si vous disposez des fonds nécessaires. J'ai oublié de parler de l'évolution vers les clouds pour gérer ce type de problématiques.

On entre dans le vif du sujet.

Le cache est l'élément le plus simple à mettre en œuvre et il existe différents niveaux avec Django (page, fragment, vue, queryset, etc) qui permettent d'avoir la modularité nécessaire. Attention, il ne faut pas oublier d'avoir des mécanismes d'invalidation du cache ! (pas comme sur ce blog par exemple...)

Le cache est bien pratique mais insu