En tant que grand utilisateur et fan du langage de programmation Python, je ne pouvais décemment pas rater la PyConFR de ces 15-16 septembre 2012, à la Cité des Sciences, à la Villette (Paris 19e).
Petit retour d’expérience sur l’événement.

Alors oui, on va me dire que j’ai vu seulement 4 confs sur la 40aine de talks, mais bon, déjà d’une : il y a 3 salles en parallèle, donc de suite, à défaut d’ubiquité, ça limite forcément, et ensuite j’ai assisté à 2 présentations d’1h30 chacune, empêchant ainsi d’assister à 12 autres confs de 30min se déroulant dans les autres salles. Et puis bon, depuis quand a-t-on besoin de justifier une présence irréprochable pour parler d’événements sympas, qui plus est traitant de Python ?
Pour revenir sur la notion de sympa, clairement, c’est le cas tant dans l’esprit que dans la pratique. Faisant fi de toutes bonnes croyances selon lesquelles, en ces temps de crise sans précédent, le moindre démarche un tant soit peu commercialisable doit l’être à outrance, la PyConFR est indécente de gratuité. Pas de ticket d’entrée, du manger (croissants, pains aux raisins, …) et du boire en quantité, un sac de goodies, tout offert ! Certaines rumeurs affirment même que les personnes venant de loin pouvaient demander à se faire rembourser une part non négligeable de leur transport !
Le public est clairement composé majoritairement d’informaticiens professionnels (plutôt des développeurs dans l’ensemble), qui savent de quoi ils parlent, ce qui donne lieu à des échanges très précis et riches en enseignements.

Bon, passons à des choses plus concrètes. Les talks auxquels je suis allé concernaient :

1. le framework Django ainsi que quelques outils qui gravitent autour;
2. le gestionnaire de version Mercurial, qu’on a souvent tendance à opposer à Git;
3. le Test-Driven Development.

Django :

Le framework (Jean-Michel ARMAND)

La toute première conférence était donc dédiée à une présentation du framework Web Django. Le présenter de façon exhaustive sur un blog n’a pas vraiment de sens (et serait au-dessus de mes compétences), mais on peut se permettre d’exposer son fonctionnement global : dans l’idée, Django accompagne le développement d’applications Web notamment au niveau de la génération de pages HTML. Concrètement, le framework utilise les URLs demandées au serveur pour appeler une routine (l’ensemble des routines sont les vues) qui utilise les objets de la base de données, déclarés dans les modèles, pour construire un dictionnaire. Ce dictionnaire est ensuite combiné à un template, soit en gros une page HTML agrémentée d’instructions spécifiques qui seront interprétées par Django (~ c.a.d remplacées par les informations présentent dans le dictionnaire précédemment construit) pour générer la page finale qui répond à la requête initiale.
Ça c’est pour le très basique, par dessus on a encore pas mal de trucs en plus.

• Une abstraction de la base de données : elle est décrite en Python dans les modèles, puis auto-générée (concrètement, c’est Django qui gère la BDD)
• Django peut très bien gérer plusieurs bases de données différentes
• Toujours au niveau de la manipulation de la base de données, les querysets de Django sont un moyen de restreindre les requêtes sur un objet à certain de ses champs (exemple bateau d’un blog : sur la page de garde on ne veut afficher que les titres des articles, pas les contenus)
• Quelques lignes de codes suffisent à générer une page d’administration complète (très utile notamment pour manipuler directement les objets du projet, pour des tests par exemple), facilement personnalisable
• Les URLs déclarées peuvent contenir des variables, du genre « /<type_de_l’objet>/<identifiant>/ », qui sont automatiquement renvoyées à la vue en tant qu’arguments
• Le jeu d’instructions Django est très complet, avec des boucles, des conditions, mais aussi des inclusions de templates (typiquement dans un site Web, le corps change mais la structure globale reste relativement constante, dans ce cas on isole cette structure dans un template à part)
• Django propose son propre serveur HTTP (prévu pour le développement), et s’adapte facilement avec Apache, Gunicorn et Nginx
• Un grand nombre de modules annexes (authentification, gestion des sessions, des cookies, protection contre les injections dans les formulaires, …) sont facilement utilisables et de bonne facture.
• Une multitudes de méthodes automatiques permettent d’accélérer significativement le développement, notamment la prise en compte des erreurs : par exemple une méthode qui fait un appel en base de données et génère automatiquement un page 404 si la donnée n’existe pas (get_object_or_404); des redirections HTML, …

Les principaux enseignements de cette présentation étaient surtout des rappels toujours utiles : ne pas hésiter à utiliser des librairies/modules déjà existant, ne pas hésiter à arpenter les forums, chan IRC, etc. dédiés à Django (et il y en a) et plus largement à Python (puisque Django peut naturellement bénéficier de tous les avantages de ce merveilleux langage), …

Bref, une belle (et méritée) promotion du framework et de sa communauté.

Les outils (Xavier ORDOQUY)

Le talk suivant présentait 3 outils indispensables gravitant autour de Django :

Django Debug Toolbar

Petit module à rajouter à Django et accessible via le navigateur, très pratique pour (évidemment) déboguer mais aussi optimiser notre application. Il permet notamment un suivit complet des requêtes, avec leurs contextes, leurs temps d’exécution, leurs stacktrace, etc. Au niveau des templates affichés, là aussi beaucoup d’informations utiles, par exemple un affichage des informations envoyées à la page, le contexte, …

South

Utilitaire centré sur la gestion de la base de données, notamment la migration. Typiquement, Django sait générer une base de données, au mieux rajouter une table, par contre si vous lui demandez d’ajouter un champ à une table existante, ça va mal se passer. South permet (de ce que j’ai compris) une sorte de « versionnement » de la base de données : il auto-génère des scripts de migration pour un update de la base mais est aussi capable de revenir à des états précédents, en conservant les données.
Apparemment stable et digne de confiance, le speaker conseillait son usage en toute circonstance.

Sentry

De nouveau un module de débogage, mais la philosophie est totalement différente. Django Debug Toolbar a sa place en développement, tandis que Sentry est définitivement prévu pour les plates-formes de production. L’idée est que lorsque des bugs sont remontés par des utilisateurs, les informations sont souvent très lacunaires (description peu précise, contexte absent, …).
Un client Sentry tourne sur Django, et dès qu’il détecte un problème, envoie toutes les informations qu’il peut gratter (contexte, stacktrace, stats, session …) à un serveur, qui peut recevoir des remontées de log de plusieurs plates-formes Django, et qui présente les caractéristiques de base d’un bugtracker (date-heure/infos/état du bug, etc.).

Mercurial (Pierre-Yves DAVID et un compère anonyme) :

La présentation sur Mercurial était divisée en 2 parties, je n’ai assisté qu’à la 2nd. Les speakers ont adapté le contenu aux attentes de l’auditoire, c’est à dire plutôt des fonctionnalités avancées. C’était cool leur part, dans la mesure où ce n’est pas forcément évident de modifier à la volée une présentation, et que parfois les intervenants se contentent de venir dérouler leurs notes sans considération pour le public.
Je n’ai pas envie de reprendre les commandes basiques de Mercurial, au niveau de l’usage minimal c’est assez similaire à Git. Venons-en directement aux commandes et mécanismes exposés durant le talk :

• hg log, on l’utilise tout le temps, mais on ne sait pas forcément qu’il est possible de personnaliser de façon assez fine l’affichage de la commande, au point de pouvoir écrire des templates spécifiques, ou d’utiliser des styles pré-déterminé.
• hg clone -r X [blabla], permet de récupérer une version X d’un dépôt, beaucoup plus souple que d’abord cloner puis changer de version en local.
• hg commit –amend servira certainement beaucoup aux personnes qui commitent un peu trop rapidement, puisqu’il permet de corriger/compléter le commit précédent.
• hg annotate [file], qui affiche pour chaque ligne d’un fichier le numéro de la révision responsable du dernier changement (ou encore le changeset, la date, …). Un grand nombre de filtres existent (notamment temporels), ne serait-ce que pour pouvoir identifier d’anciennes modifications
• hg bisect, commande totalement géniale, utile pour tester automatiquement différents états d’une application au cours du temps. En gros la commande reçoit un exécutable et un intervalle de révision, et va tester cet exécutable sur chacune de ces révisions. L’exemple de base est de lancer un grep sur un mot pour voir à quel moment il apparaît (ou disparaît), mais on peut évidemment lancer des demandes plus complexes, comme faire tourner des tests par exemple.
• revset (revision set) est en gros le langage de requête de Mercurial, utilisable avec la plupart des commandes du moment qu’elles s’appliquent sur un ensemble de changesets. Il permet de faire des filtres très précis, sur un intervalle, une liste de changesets, sur un ancêtre, selon le nom, la date, l’utilisateur, … bref un peu tout. Les opérateurs OR et AND sont aussi présents.
  À noter l’existence de fileset, qui sert à la même chose avec des fichiers.
• hg graft permet de merger un ensemble de changesets d’une branche vers une autre. Cela peut être extrêmement utile lorsqu’un seul changeset nous intéresse dans une branche, et pas ce qui le précède (donc impossible de merger). Ce mécanisme est aussi connu sous le nom de cherry-picking.
• hg rebase permet quand à lui de déplacer des branches. Dans le résultat on se rapproche d’un merge, à cela près que les changesets seront placés en bout de la branche de destination -il ne restera donc plus qu’une branche- au lieu que les deux branches fusionnent.

Test-Driven Development (Boris FELD) :

Comme 99% des informaticiens, je suis convaincu de l’utilité fondamentale des tests automatiques dans un process de développement, et comme 80% des informaticiens, je n’en écris aucun… Mais il n’est jamais trop tard pour changer, et c’est pourquoi, j’ai assisté à cette présentation, ne serait-ce que pour être au courant des bonnes pratiques.

Pour ce qui est de la forme de cette présentation, on commence avec environ 30min de slides d’introduction suivit d’un atelier où on met directement les mains dans le cambouis.
Personnellement, je ne suis pas très convaincu par ce genre de fonctionnement; certes manipuler soi-même est la meilleure façon de comprendre, mais – c’est un avis personnel que tout le monde ne partage pas – une conférence n’a pas réellement à nous faire comprendre quelque chose, mais plutôt à nous présenter des concepts/outils d’une façon suffisamment séduisante pour qu’ensuite on se mette spontanément dedans.
Un atelier, du fait qu’on avance lentement pour une foule de raison (différences de niveaux, écriture de code, installations de logiciels, …), a un peu l’effet inverse puisqu’on ne peut aborder (à moins d’avoir énormément de temps) que des choses assez superficielles et pas forcément sexy, et qu’on peut passer pas mal de temps à attendre ou tracer le TP sans vraiment comprendre se qu’on fait..

Au niveau du fond, on ne peut enlever à Boris d’avoir une vision claire et un bon recul sur ce qu’il présente. L’introduction est bien menée (utilité des test, hiérarchie, conseil sur un environnement de tests, …). La partie pratique permet de piocher plusieurs noms d’application intéressantes : Unittest, très pratique pour automatiser les tests (oh?), python-coverage qui calcule la « surface » d’une application traversée par un exécutable (par exemple et totalement au hasard : des tests), Selenium pour tester une interface Web, Jenkins-ci et Travis-ci qui sont des outils d’intégration continue (en gros dans notre contexte, qui font régulièrement tourner une batterie de tests sur un dépôt), … qui permettent de se faire une idée d’un environnement de développement complet pour ce qui est des tests (et autre d’ailleurs, puisque plusieurs de ces outils ne se limitent pas qu’à ce domaine du développement).
On a aussi accès à des petites techniques/conseils : éviter les boucles dans les tests, ne pas hésiter à faire des bouchons ou des mocks pour éviter des accès à des parties sensibles ou vide de l’application (exemple : base de données) sans pour autant arrêter de tester, avoir une couverture de tests d’au moins 90%, que chaque bug corrigé possède son propre test, etc.

Pour revenir au fond du fond, qui est tout de même le Test-Driven Development, c’est à dire le développement par le test, c’est à dire de coder des tests avant même de développer une fonctionnalité, on est d’accord que dans la théorie, c’est merveilleux : non seulement on assure une couverture de test maximale et on donne à l’application un maximum de crédibilité, mais en plus le test est une belle façon de déterminer un besoin, de façon bien plus compréhensible pour un développeur qu’un cahier des charges verbeux et inepte au possible.
Mais si on excepte les gros projets, avec des équipes importantes de développeurs, etc. etc., bref si on parle de tous les projets qui se développent à 4-5 personnes, le TDD semble quand même incroyablement chiant à supporter… Ce qui doit certainement expliquer pourquoi, même en sachant que les 2/3 du temps d’un développeur passe dans le débogage, cette méthode de développement ne sera sans doute jamais largement utilisé.