Quand j'étais en fac, la qualité logicielle n'était pas vraiment au programme. Plus globalement, les notions d'agilité qui sont chères à bon nombre de programmeurs aujourd'hui, et qui ont été résumées dans un manifeste signé par les plus grands noms des méthodologies modernes de programmation, n'étaient pas très diffusées. Cette diffusion a l'air d'être encore relativement faible de nos jours, même si certaines formations spécifiques commencent à proposer des programmes en ce sens, comme le master I2L (Ingénierie du Logiciel Libre). (La qualité en génie logiciel serait-t-elle réservée au monde des logiciels libre ? ;))

Bref, le développeur a interêt à se former sur le tas, par son expérience bien sûr, mais aussi par des lectures adéquates.

Le problème des livres traitant de méthodologie est qu'ils sont là pour vendre un concept global: un gros sac de RUP, un colis d'UML ou un set de table complet d'XP. Bref les développeurs ont tendance à être noyés dans ces guides, surtout que dans la réalité il est quasiment impossible d'appliquer telle ou telle méthodologie de A à Z.

Le développeur préfère picorer et se forger avec son vécu sa propre méthodologie. C'est peut-être la définition de l'agilité, finalement: réussir à surfer sur la vague des méthodologies.

Dans cet exercice, il y a aussi le problème culturel. Dans les entreprises agile-friendly, qui ont forgé grâce à des champions XP par exemple, une culture de la qualité qui est insufflée à chaque nouvel arrivant, perpetrée et continuellement enrichie par tous, l'adoption et la compréhension ne se posent pas. A contrario, dans les environnements de travail hostiles à l'agilité, où il est par exemple commun d'entendre que "les tests unitaires ca ne sert à rien", le développeur qui souhaite progresser dans la méthodologie a une marge de manoeuvre restreinte et doit parfois se transformer lui-même en évangéliste pour continuer à progresser.

Bon mais pourquoi je raconte tout ça ? J'aurais pu vous parler de politique et vous inviter à prendre contact avec la présipauté de Groland pour préparer votre fuite en tant que réfugié politique si Sarkozy est élu. Non, je vous parle de méthodologie car j'ai trouvé ma bible sur le sujet !

"Practices of an Agile Developer", écrit Venkat Subramaniam et Andy Hunt himself, est un livre issu de la collection de Pragmatic Programmers, célèbre pour le livre "Pragmatic Programmer: from Journey Man to master", entre autres.



En ouvrant le livre et en lisant le sommaire, on se rend tout de suite compte de sa qualité: il est architecturé en conseils regroupés dans des chapitres à thème.

Chaque conseil est présenté suivant ce plan:

• Le conseil, en une phrase très courte. Exemple: "Keep it releasable"
• Un petit logo de diable qui critique ce conseil. Exemple: "On a trouvé un bug bloquant, arrête tout ce que tu fais et corrige-le sans te soucier de la procédure habituelle, on va envoyer un patch vite fait, personne ne le saura"
• Une section qui développe sur le sujet en quelques pages, et argumente contre la critique.
• Un petit logo d'ange qui conclu. Exemple: "soyez sûr qu'à tout moment votre projet est compilable, testable, et déployable"
• Une section "What it feels like", qui résume le gain de l'approche
• Une section "Keeping your balance", qui pondère la règle. Exemple: si vous devez envoyer un patch au plus vite, pensez à faire une branche dans subversion, pour ne pas rendre le système dans un état instable"

La seule chose qui manque pour que le livre soit parfait est une dernière section à chaque conseil, qui propose au lecteur un ou des conseils à lire ensuite, car l'ordre des conseils dans chaque chapitre m'a paru totalement arbitraire. Mais c'est minime.

Pour conclure, "Practices of an Agile Developer" devrait être lu par tous les développeurs, quelle que soit leur expérience. C'est un outil formidable pour progresser, mais aussi pour évangéliser vos amis: toutes les critiques faites à l'agilité sont décortiquées et démontées de manière intelligente, en suivant un argumentaire parfait.

Je lis maintenant "Interface Oriented Design" du même éditeur qui, je l'espère, me donnera autant de plaisir.
   

Ayant besoin de programmer une petite application desktop, je planche sur les toolkits existants en Python pour concevoir les interfaces. La dernière fois que je me suis réelement penché sur le sujet c'est pour en parler dans mon livre.

Un bon toolkit graphique doit posséder les qualités suivantes:

• Etre réelement portable: mise à part la programmation système avancée, et quelques cas précis, il n'y a aucune bonne raison pour qu'un module Python ne soit pas portable.
• Permettre une production simple des interfaces. Les toolkits qui nécessitent de lancer des scripts pour transformer des fichiers de description générés par des éditeurs WYSIWYG en code Python imposent des processus lourds. D'autres ont un cycle plus simple.
  
• Offrir un look'n'feel conforme à chaque plateforme. C'est une extension du premier point. Certains toolkit sont portables mais également universellement moches.
• Etre un minimum pythonique. Les bindings générés avec des outils automatiques donnent un look'n'feel de C++ assez désagréable au code.
  

La page sur le sujet sur python.org date de 2003, (ah tiens, pas relookée non plus au nouveau design du site). C'est ancien mais finalement, en 3 ans, il n'y a pas eu énormément de nouveautés, mise à part l'apparition de QT4, et des améliorations des toolkits majeurs. Le seul grand changement c'est la mort de la plupart des toolkits outsiders, et un livre sur wxPython chez Manning.

Je continue à creuser le sujet, en lisant notamment un tuto de Fab sur GTK, et en gardant en mémoire les qualités que je souhaite avoir dans le toolkit choisi. En attendant un prochain billet sur mes essais, voici un tableau récapitulatif des toolkits à tester, avec quelques critères déjà.

Nom	Toolkit	Windows	Linux	Mac	Site	Remarques
TkInter	Inclus dans Python	X	X	X	http://tkinter.unpythonic.net/wiki/	moche
PyKDE	KDE		X		http://riverbankcomputing.co.uk/pykde	pas portable
PyQT	QT	X	X	X	http://www.diotavelli.net/PyQtWiki	Attention aux licences
PyGTK	GTK+	X	X	X	http://www.pygtk.org/
wxPython	wxWidgets	X	X	X	http://wiki.wxpython.org/	Semble standard
PyObjC	Cocoa			X	http://developer.apple.com/cocoa/pyobjc.html	Accès aux widgets de MacOSX

Message aux pros du domaine: n'hésitez pas à réagir, ou à corriger d'éventuelles erreurs.

Maj 29/10: merci pour toutes les réactions ! En attendant de mettre à plat les commentaires, voici un résumé des idées données:

• Thomas conseille le couple Glade/GTK+, et déconseille PyQT à cause des licences.
• Skateinmars observe que PyGTK s'en sort mal comparé aux autres toolkits.
• Kib rappelle que la doc ne fait pas tout, et que le choix peut être influencé par la réactivité de la communauté. Il présente aussi Gazpacho comme alternative à Glade.
• ToutPT prône pour wxPython, mais trouve que les outils d'édition de QT sont très puissants.

Ma punition pour avoir été en désaccord personnel avec un des responsables de developpez.com a été le retrait de mon livre (présenté avec 2 critiques très favorables) de leurs section livres.

C'est dommage pour les lecteurs de ce site, je pense. J'avais moi même écrit des critiques de livre sur ce site, mais ca ne me viendrait pas à l'esprit de les retirer...

Il en reste une des deux encore accessible par un autre lien ici: http://wpetrus.developpez.com/livres/python/ (mais elle ne va pas faire long feu à mon avis)

Bel esprit pour un site qui se dit démocratique, no comments...

Au même moment sur amazon... étrange coincidence... ;)

Lorsque vous utilisez le TDD (Test Driven Development) pour vos projets Python basés sur un framework (comme Zope par exemple), un temps non négligeable est passé à la conception de Fakes pour rendre le test indépendant de ressources externes.

Les Fakes (c'est le terme que j'ai toujours employé, à tort ou à raison) sont ces classes ou fonctions vides qui permettent de simuler un composant. Par exemple dans le test d'un module qui appel un serveur IMAP, on peut concevoir un faux serveur IMAP qui simule un sous-ensemble des échanges possibles. Cette mise en place permet de tester que le module se comporte comme attendu, dans un environnement vraisemblable.

Ces Fakes peuvent se faire à n'importe quel niveau et l'aspect dynamique de Python permet toute les manipulations. On peut par exemple modifier à la volée une classe d'un module de la bibliothèque standard, à l'insu du code appelé pendant les tests. Un vrai truc d'agent secret quand même...

La contrepartie, c'est que le code de ces Fakes, il faut le taper.. concretement, on créé un fake vide, on lance le test, on rajoute la méthode appelée par le code quand le code la réclame, on relance, etc..

Certains fakes sont presque aussi gros que le code simulé !

De plus, les fakes ne fournissent pas de feedback sur les appels qui ont reçus. (ce que j'appel les reversed-test)

La solution pour minimiser le code à taper, et pour enrichir les reversed-tests, c'est les objets Mock.

Ces objets, en plus d'avoir un nom très hype ;), sont des mutants à mémoire. Ils acceptent tous les  appels et les enregistrent.

Le testeur peut ensuite vérifier quels appels ont étés émis, et faire des assertions dessus. Il peut également étendre les Mock lorsqu'il souhaite que le Fake renvoi des valeurs.

Il existe une implémentation en Python, qui se trouve ici : http://python-mock.sourceforge.net/

Exemple tiré du site:

class PersistanceTestCase(unittest.TestCase):
    def testPersistData(self):
        #set up the mock objects
        mockCursor = Mock()
        mockDB = Mock( { "cursor" : mockCursor } )
        #call the function to be tested
        persistData(testData, mockDB)
        #test the correct calls were made on the database
        objects mockDB.mockCheckCall(0, 'cursor')
        mockCursor.mockCheckCall(0,
                                 'execute',
                                 '...some SQL...',
                                  someData)
        mockCursor.mockCheckCall(1,
                                 'execute',
                                 '...more SQL...',
                                  moreData)
        mockDB.mockCheckCall(1, 'commit')
        mockDB.mockCheckCall(2, 'close')

Dans cet exemple, on vérifie dans le mock que le code a bien appelé execute, commit et close, dans cet ordre précis.


A utiliser sans modération, donc.

Pour les fans il y a même un blog dédié...

Suite à l'abandon de Zope par Nuxeo, j'ai arreté le projet Zope 3 cookbook, car il nécessitait trop de travail pour rester à flot.

Le travail va être a priori récuperé et injecté par le wiki de Baiju, mais il a pour l'instant simplement recopié les recettes dans un coin de son wiki. A suivre...

Ce travail a été très interessant car il a nécessité la mise en place de techniques de documentation agiles, que j'ai décrites l'été dernier à Europython.

Pourquoi une telle mise en place ?

Car le développement de Zope 3 évolue enncore trop vite pour pouvoir écrire un livre "classique".

En souvenir ;), et pour me rendre compte du travail effectué, j'ai généré un pdf qui regroupe toutes les recettes. La mise en page est spartiate mais c'est lisible.

Le voici:

• En français
• En anglais

Il peut être intéressant pour les gens qui découvrent Zope 3, car il présente:

• des recettes transverses dont l'objectif est de réaliser des fonctionnalités concrètes
• des méthodes de travail, utilisées par les développeurs Zope

Si ce livre vous a été utile, faites le moi savoir !

Mon ami Gwen me dit que les clichés que j'ai pris ne présentent pas joliment les tshirts. C'est vrai qu'il a fait de bien belles photos à la dernière réunion de l'Afpy.

En attendant qu'il fasse de bien beau clichés, voici le TShirt





Très bientôt à la vente en ligne, stay tuned...

C'est un peu difficile de faire la promo de Python dans mon blog anglais en ce moment, avec ce gros écusson bleu 'on passe à java' à droite. :)

Pour clarifier les choses, j'ai créé un nouveau blog, "Carpet Python" dans lequel je posterais en anglais sur Python

C'est là: http://tarekziade.wordpress.com/

Et franchement, wordpress c'est de la balle, même si programmation-python commence à bien tourner niveau soft.

Ce blog en français reste celui ou j'écrirais le plus.

Certification MySQL, Certification Ubuntu, PHP, etc..

Mettre en place un programme de certification pour une technologie me semble être un pas de plus vers la voie de son industrialisation et de sa reconnaissance.

Le buzz créé autour de ce genre de standardisation n'a que des effets bénéfiques: les entreprises commerciales de formation, pour recruter des étudiants et gagner plus d'argent, deviennent des promoteurs actifs de la technologie.

Un post (pas très récent) de Dan York, sur les programmes de certification Linux, explique très bien ce phénomène.

Alors, à quand une certification Python ?

Il y a eu dans le passé quelques tentatives de mise en place de certifications Python. Mais le site Python in business qui devait regrouper ces initiatives est mort, certainement parce que l'échelle de Python dans l'écosystème des développeurs est encore trop petite.

Pourtant, c'est un sujet qui me paraît essentiel, et nombre d'entreprises francophones dispensent des formations Python, ici, là ou encore là . (ordre google)

Ne serait-ce pas le rôle de l'Afpy d'imaginer une table ronde avec tous ces acteurs pour mettre en place un standard commun ?

A la dernière AG, un groupe de travail s'est formé pour étudier les rapports de Python avec les entreprises, je pense y proposer la mise en place de ce chantier prochainement.

Maj 17/10 : j'ai lancé la même réflexion sur le blog anglais, beaucoup de retours intéressants, à lire.

Maj 24/10: en attendant d'avoir un fil de commentaires plus visible (il faut que je change ce code) voici un résumé des idées postés sur cette entrée:

Cyril PIERRE de GEYER, qui a participé à l'élaboration de certifications PHP, conseille d'utiliser des QCM, en faisant valider un pool de 500 questions par un comité

Labadie, soutient l'idée du QCM, mais propose aussi de proposer des programmes buggués Python à corriger, à la manière de RedHat qui fourni des systèmes cassés
à réparer pour sa certif.

Un petit tutoriel comme on les aime, pour la prise en main de Django

http://www.sitepoint.com/article/build-to-do-list-30-minutes

Le coup de feu que l'on vit lorsqu'on corrige les dernières erreurs dans un article, et qu'on fini par valider au bout de 5 allers-retours avec l'éditeur dans la même journée, fait que l'on oublie forcément quelque chose.

Pour création d'un site de publication avec Zope (3), j'ai oublié de remercier Olivier Grisel à la fin de l'article pour son aide au niveau des relectures.

Merci Olivier ;)