title: ★ Conférences Django pour PyCon fr
slug: conferences-django-pour-pycon-fr
date: 2008-05-21 02:57:53
type: post
vignette: images/logos/django.png
contextual_title1: ★ L'élitisme de la curiosité
contextual_url1: 20090313-lelitisme-de-la-curiosite
contextual_title2: Sortie de Django 1.0, une année de nouveautés
contextual_url2: 20080902-sortie-de-django-10-une-annee-de-nouveautes
contextual_title3: ★ Astuces et bonnes pratiques Django
contextual_url3: 20080211-astuces-et-bonnes-pratiques-django
J'ai eu le privilège de présenter Django lors des [journées](http://fr.pycon.org) organisées par l'[afpy](http://www.afpy.org). 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](http://media.larlet.fr/david/conferences/django/) 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](https://larlet.fr/david/biologeek/archives/200763-django-fr-enfin-en-ligne/), 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](https://larlet.fr/david/biologeek/archives/20070117-definition-et-avantages-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](http://www.djangobook.com/en/1.0/chapter19/) 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](http://stuffthathappens.com/blog/2008/03/31/the-right-tool-for-the-job/) 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](http://jehaisleprintemps.net/blog/fr/2008/04/27/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 insuffisant parfois. Lorsqu'on arrive sur des gros projets, il est quasi illusoire de vouloir s'en tenir à des données normalisées. Ne serait-ce que pour le nombre d'items, il faut avoir recours à des champs dénormalisés. Django dispose de [signals](http://code.djangoproject.com/wiki/Signals) pour gérer ça de façon automatisée.
De nombreuses choses peuvent être faites en asynchrone (envoi de mail, préchargements de widget coûteux, etc), AJAX peut ici prendre tout son sens.
Il faut bien faire la différence entre ce qui est imputable à Django et ce qui concerne l'architecture de votre projet, un bon admin sys et/ou DBA peut faire des miracles. Il ne faut pas oublier non plus que les [performances css/js](http://performance.survol.fr/) jouent un rôle important à ce niveau...
Une petite astuce propre à Django, l'utilisation du tag **{% with %}** pour créer des alias dans les templates lorsqu'une méthode coûteuse est évaluée dans une boucle par exemple.
Le traitement des performances se fait de manière itérative, essayez de toujours identifier le facteur limitant de la réactivité de votre application.
Un résultat est important, que ce soit un échec ou pas (le scientifique reprend le dessus), pensez à documenter vos essais, que ce soit pour votre équipe ou de manière publique (blog, [djangosnippets](http://www.djangosnippets.org/), etc).
Un autre titre jemelapètegrave.
La pérennité d'une application web est toute relative, l'évolution technologique est telle qu'il est difficile d'être pertinent à plus de 3 ans. Ça veut dire qu'il faut quand même rester évolutif jusque là !
Les règles qui s'appliquent ici sont les mêmes que pour un projet Python, il est impératif de tester les différentes fonctionnalités grâce aux unittests et doctests. Django dispose d'[un module entier consacré à ça](http://www.djangoproject.com/documentation/testing/), il est temps de s'en servir. Un client spécifique aux tests permet même de tester les différentes vues et le résultats des appels (GET, POST, etc).
En découplant les différentes applications de votre projet (lire à ce sujet l'[excellent post de James Bennett](http://www.b-list.org/weblog/2007/nov/09/projects/)), vous allez pouvoir vous constituer (ou [récupérer](http://code.google.com/hosting/search?q=label:django)) un bibliothèque d'applications web réutilisables dans plusieurs de vos projets.
On ne mentionnera jamais assez à quel point la documentation d'un projet est importante. Normalement les doctests doivent permettre de « raconter une histoire », développez vos talents d'écrivain !
Cerise sur le gâteau, Django vous permet de générer automatiquement la documentation à partir du code dans l'interface d'administration, ce qui s'avère très pratique si vous travaillez avec une équipe de plusieurs personnes dont certaines s'occupent exclusivement du html/css/js.
Exemple d'itération sur l'implémentation des URL.
Utilisation assez naïve avec la construction d'URL à la main, c'est une mauvaise pratique car vous devez modifier les URL à de nombreux endroits si vous décidez de changer votre schéma.
La seconde méthode s'appuie sur une méthode du modèle (différente ici du bien connu **get\_absolute\_url** car on veut accéder au profil et non à l'utilisateur), c'est déjà mieux mais il faut encore modifier l'URL à deux endroits en cas de modification.
Enfin la bonne méthode est d'utiliser [les URL nommées](http://www.djangoproject.com/documentation/url_dispatch/#naming-url-patterns), qui permettent de ne dupliquer la création des URL à aucun endroit, si vous modifiez celle dans **urls.py** ça va impacter sur l'ensemble des URL de votre site. Cela est permis grâce au décorateur **permalink**.
Ces différentes pratiques vous permettent d'opérer des refactoring important de code tout en étant serein et de vous concentrer sur d'autres fonctionnalités.
Je voulais terminer sur un point qui me semble capital pour améliorer la qualité d'une application (pas forcément Django).
L'idée m'est venue en consultant la [présentation de Cameron Moll](http://www.cameronmoll.com/archives/001266.html) et plus spécifiquement le slide comparant le *bon designer* au *super designer*.
J'en suis arrivé à la conclusion qu'un *bon développeur* est **consciencieux**, il connaît ses outils et sait parfaitement obtenir un résultat satisfaisant avec. Qu'est-ce qu'il lui manque alors ?
Bien souvent **la curiosité**, celle de fureter pour finalement trouver une solution plus adaptée ou un module qui fait déjà ce qu'il a mis une semaine à coder, celle d'aller à des conférences, de lire des livres, d'essayer de comprendre pourquoi certaines choses ont été faites ainsi. Cette qualité vous permet de vous épanouir quotidiennement dans votre travail.
Bon avec tous ces conseils, vous allez forcément faire une appli qui va conquérir le monde, faire chuter l'action Google et sauver la planète.
Les crédits, merci ! (complètement illisibles, il faut que je trouve un moyen simple de formater ça)
### Bilan personnel
Je suis beaucoup moins satisfait de ma seconde prestation, j'ai remis en question chaque concept présenté au fur et à mesure, doutant de l'intérêt pour quelqu'un s'intéressant peu à Django. Du coup j'étais un peu hésitant et je pense que ça s'est ressenti.
Au final, j'ai un peu le sentiment que ceux qui connaissaient pas trop ces problématiques se sont ennuyés et ceux qui y étaient confrontés aussi car je ne suis pas allé assez loin...
Concernant Keynote (ça vaut pour les deux confs) : aucun problème au niveau des images, par contre je n'ai pas pris le temps de configurer l'écran pour voir le slide suivant + le temps sur l'écran et c'était un tort car ça aide beaucoup.
## Conclusion
Il y a probablement des formats plus appropriés pour aborder les problématiques de performances/qualités comme des tables rondes ou des séances de questions/réponses comme me le suggérait [Fabien](http://fabien.schwob.org) par mail. Pour montrer la rapidité de développement de Django et donner envie d'essayer, rien ne vaut un atelier avec un petit projet de mise en bouche. Autant de pistes qu'il faudra explorer lors des journées 2009 !
### Vous y étiez ?
**Votre avis m'intéresse énormément**. J'aimerais vraiment pouvoir progresser à ce niveau et vous êtes le mieux placé pour m'aider. J'ai déjà eu des retours par blog (merci [Sunny](http://sunfox.org/blog/2008/05/19/pycon/)), par email et sur irc mais si vous avez un peu de temps, n'hésitez pas, je prends le bon mais aussi et surtout le mauvais. N'ayez pas peur d'y aller trop fort, j'encaisse derrière :-).
**[Edit]** : [les vidéos sont en ligne](http://dl.afpy.org/pycon-fr-08/videos/) ! Merci l'AFPy.