Retour au vert

lundi 11 juin 2007 :: perrick :: Extreme Programming :: 2 commentaires :: aucun trackback

Il y a 17 jours, un bug s'est introduit dans notre suite de tests : impossible à reproduire en local, il faisait planter le système d'intégration continue sur le serveur. Et chaque email en post-commit égrainait la même rengaine Test cases run: 86/86, Passes: 4211, Failures: 6, Exceptions: 0. Une première séance de débogage n'aboutiera pas : les 6 erreurs restent.

Quelques jours plus tard, on inaugure l'ajout des tests de recette automatisés à la sauce unitaire : grosso-modo, un script PHP lance tous les tests unitaires avec SimpleTest; sauf qu'un des scénarios utilise notre dernière contribution SeleneTestCase pour utiliser le serveur Selenium et s'occuper des tests de recette au passage (on en reparlera).

De 6 erreurs, on passe directement à : Test cases run: 86/88, Passes: 4137, Failures: 207, Exceptions: 2517. Quelques réglages plus loin, on retombe rapidement sous la barre des 50 erreurs / exceptions. Ce dernier paquet mettra un temps plus conséquent à se résorber : quand on ne fait que manipuler des dates, ce n'est pas toujours évident d'être synchro dans ses tests ! Encore une après-midi pour éliminer les 6 erreurs du départ (un méchant effet de bord dans la suite) et nous revoilà enfin au Test cases run: 85/87, Passes: 4399, Failures: 0, Exceptions: 0.

Je suis le premier surpris de l'effet purement psychologique : l'impression que le ciel est de nouveau dégagé et qu'on peut reprendre tranquillement et sereinement le fil des développements. Reste à savoir comment d'autres équipes XP gèrent ces passages dans le rouge...

Bientôt un Dojo Développement à Lille

mercredi 6 juin 2007 :: perrick :: Extreme Programming :: aucun commentaire :: aucun trackback

C'est en 2004 que le premier dojo développement a sorti la tête de l'eau sous l'impulsion de Laurent Bossavit et Emmanuel Gaillot. Trois ans plus tard (sans oublier la bière avec Arnaud Bailly : indispensable) le premier dojo lillois point le bout de son nez.

Pour l'instant, il s'agit simplement d'un groupe google... Avis aux amateurs !

nord-agile

Visiter ce groupe

PS : pour ceux qui veulent plus d'infos sur ces dojos d'un autre genre, il y a un site dédié en anglais.

Le remaniement routier

vendredi 11 mai 2007 :: perrick :: Extreme Programming :: un commentaire :: aucun trackback

Une grosse semaine de remaniement vient de se terminer sur opentime : notre plus grosse classe -- celle que j'avais commencé à écrirer il y a plus de 5 ans -- a vu fondre de moitié le nombre de ses méthodes. Une bonne dose de modularité en plus désormais !

Le remaniement est bien sûr une technique de prédilection en informatique : on travaille en continue avec de l'immatériel pur. Et pourtant depuis plusieurs semaines j'ai découvert une autre forme de remaniement... Celui qui s'effectue sur le bithume.

Lors d'un voyage à Venise (une mission économique de la CCI de Lille et du département du Nord), j'ai eu l'occasion d'en parler avec un fonctionnaire : de plus en plus, on aménage les routes. Et vite. Et en mieux. Le plus long reste souvent le temps de la décision politique !

Un nouveau bout de trottoir par ici, une place de parking qu'on supprime pour améliorer la visibilité au croisement, une bande de stop qui se déplace de quelques mètres...

Avant de taper sur vos élus (c'est de saison ;-) reste à voir si ce n'est pas cette même question politique qui empêche le temps du refactoring.

Lecture : Practices of an Agile Developer

jeudi 30 novembre 2006 :: perrick :: Extreme Programming :: aucun commentaire :: aucun trackback

Lors de mon dernier voyage à Londres, je suis repassé par la librairie Foyles : c'est un des rares endroits où je peux feuilleter librement un large éventail de livres sur le développement logiciel. Comme par hasard, je n'ai pas pu m'empécher de piocher dans le tas deux bouquins : commençons par Practices of an Agile Developer par Venkat Subramaniam et Andy Hunt.

Je l'avais principalement acheté pour trouver plus de matières à ma conférence sur les pratiques XP et Agile dans l'univers PHP. Au final j'y ai retrouvé les grands classiques : tests automatisés, intégration continue, code simple et communicatif, propriété partagée au sein de l'équipe... Le tout dans un langage clair et engageant : une lecture agréable et facile. Pas assez provoquant à mon goût : j'aime bien être bousculé dans mes convictions logicielles.

Et puis aujourd'hui, je me suis lancé dans la lecture de WordPress avec comme un objectif : en extraire l'éditeur de billet. Je suis alors tombé sur une fonction proche du coeur de l'application : function do_action($tag, $arg = ''). Le commentaire annonce : // The *_action functions are just aliases for the *_filter functions, they take special strings instead of generic content.

Suivent une quarantaine de ligne qui ne font pas que des alias ! On y retrouve en particulier un call_user_func_array qui permet d'appeler une fonction dynamiquement. Voici un brief aperçu de ces fonctions invoquées : kses_init, Multiply, add_management_page, kjgrc_add_options_page, kubrick_add_theme_page.

C'est là que je me suis arrêté dans mon désir de compréhension : ça devient trop pénible de suivre le fonctionnement pas à pas et j'avais trop envie de leur acheter le livre ;-) En particulier le chapitre sur Agile Coding...

PS : il y a aussi une critique sur Slashot.

Comment tester un numéro de téléphone

mardi 27 juin 2006 :: perrick :: Extreme Programming :: 3 commentaires :: aucun trackback

- Je peux l'appeler de ta part ?
- Oui bien sûr, voici son numéro...
La suite de la conversation dépendra souvent du contexte : entre le numéro privé de M. Bond - James Bond, celui personnel de la serveuse du bar des sports et celui de mon frère informaticien au boulot, les variations sont multiples.

Une des plus courantes reste bien sûr de faire répeter le numéro par l'interlocuteur : on vérifie directement qu'il a bien noté le numéro et qu'il pourra le composer sans craindre la fausse manipulation. Rarement on lui demandera de répéter une deuxième ou même une cinquième fois. Et si on détecte un chiffre erroné... on reprend du début.

Et maintenant sur un bout de code, combien de tests faudrait-il pour vérifier qu'il fait bien ce qu'on lui demande ? Ma réponse s'appuie parfois sur ce même exemple du numéro de téléphone : si la réponse est facile, on pourra s'arrêter très vite. Sinon et -- surtout -- à la moindre erreur, on ajoute des scénarii à tester. Et puis la comparaison avec les numéros de téléphone peut aussi nous amener sur d'autres chantiers à explorer.

• à un étranger, on prendra le temps de dicter chaque chiffre séparement : 0-3-2-0-0-6-5-1-2-6
• dans la base classique, on aura tendance à grouper par pair : 03-20-06-51-26...
• ...jusqu'au jour où certains ont commencer à jongler avec ces groupements : si 0800-800-800 fontionne bien, 0320-065-126 n'est pas aussi heureux
• et puis tout se complique avec les numéros plus courts : avant le 11, 12, 18 et désormais la famille des 118-XXX
• avant d'ajouter ensuite les codes pays, +33-3-... ou 00-33-(0)-3-...

A chaque fois, il faut repenser sa stratégie de transmission et de test : pensez encore qu'il soit si simple d'échanger de manière fiable un numéro de téléphone ?

Les "acétates" de ma présentation à PHPQuébec 2006

vendredi 31 mars 2006 :: perrick :: Extreme Programming :: aucun commentaire :: aucun trackback

Juste quelques lignes pour indiquer que mes acétates sont disponibles en ligne : /talks/20060331_phpquebec/pratiques_xp_en_php.

Les fiches bristol du radiateur

vendredi 27 janvier 2006 :: perrick :: Extreme Programming :: 9 commentaires :: aucun trackback

Depuis un peu plus d'un mois, j'utilise des fiches bristol blanches pour savoir ce qu'il reste à faire sur mes différents projets (en interne -- sur openTIME -- ou pour des clients). Souvent on appelle ça un radiateur d'information et ça donne un truc comme :

Sur la droite, les fiches vierges et les celles qui n'ont pas encore été sélectionnées pour passer en production active.

Au milieu, les fiches de la semaine en cours sont divisés en deux sous-ensembles : à faire et fini. Il y a un troisième sous-ensemble : elles sont à côté des ordinateurs (on bosse dessus activement).

En enfin à gauche, les fiches terminées -- en tas.

Pourquoi des fiches cartonnées et pas autre chose ? Parce que c'est facile de : écrire / gommer / raturer / colorer / trier / voir de loin / voir de près / échanger / trier / déchirer.

Présentation au Cerdecam : Pratiques XP en PHP

mardi 24 janvier 2006 :: perrick :: Extreme Programming :: 6 commentaires :: aucun trackback

Le vendredi 20 janvier, j'ai eu l'opportunité d'effectuer une conférence sur Les pratiques XP en PHP au Cerdecam (Bruxelles en Belgique-. Les supports de la présentation sont disponibles en ligne. Au passage un grand merci aux deux équipes (iCampus à Louvain et Cerdecam) de Claroline pour avoir organisé cette rencontre.

Il ne me reste plus qu'à peaufiner la session et surtout à la condenser : j'ai eu droit à 3h à Bruxelles. Ce sera beaucoup moins à Montréal. Et d'ici là peut-être aura-t-on droit à quelques photos, pistes sonores ou vidéos ?

Session XP : stratégies de gestion des délais

vendredi 6 janvier 2006 :: perrick :: Extreme Programming :: aucun commentaire :: aucun trackback

Il y a quelques temps, j'avais proposé une session intitulé Stratégies de gestion des délais à l'équipe organisatrice des premiers XP-Days à Paris. C'est avec joie que ma session a été acceptée : j'ai commencé à prendre des contacts pour effectuer un premier tour d'horizon des pratiques existantes.

Je recherche des projets informatiques de toutes les tailles et de toute nature. Parmi les combinaisons possibles : le développement spécifique pour un grosse entreprise et par une équipe répartie sur plusieurs prestataires, le logiciel propriétaire largement diffusé et géré par une personne toute seule, le produit Open Source avec 50 développeurs derrière lui dont la moitié est bénévole.

Et parmi les pistes que je voudrais explorer :

• Comment définir une date de livraion ?
• Quel process (automatisé ou non) pour la livraison ?
• Comment faire un compte-rendu pertinent de l'avancement en cours ?
• Quelle stratégie face à un bogue au début / au milieu / en fin de projet ?
• Quelle est la place des tests et des testeurs ?
• etc.

Vous avez d'autres questions qui vous passent par la tête ? Vous avez mis en place des pratiques originales ? N'hésitez à laisser un commentaire ou à m'envoyer un email directement : perrick AT noparking POINT net. L'avancement de mes réflexions sera posté ici de temps en temps avant le Jour J : ce sera le 24 mars 2006.

Métaphore pour le remaniement

dimanche 11 décembre 2005 :: perrick :: Extreme Programming :: aucun commentaire :: aucun trackback

Aujourd'hui je me suis attelé à une grosse tâche de remaniement. Le genre de spécification qui a beaucoup évolué au cours du temps : d'abord un cas unique pour tout le monde. Ensuite deux cas spécifiques suivant le type d'utilisateur. Ajoutons encore un début qui peut être différent pour chacun. Et une valeur initiale qu'un adminitrateur peut modifier. Le cas classique dans une application intranet : les cas se multiplient, le code attend urgemment son remaniement.

Et quand je dis que j'aime ça -- parce que j'ai une batterie de tests conséquente -- on me regarde avec les yeux tout ronds. J'ai donc tenté une métaphore. Imagine un jeu pour enfants : celui où il faut faire passer des pièces de formes différentes à travers les trous qui correspondent.

Au départ la matrice (avec ses trous) et les pièces sont évidentes. Puis la matrice se complexifie. Et au lieu de répondre par des pièces toujours plus précises et plus fragiles, je préfère diminuer la taille des pièces et les relier par des élastiques solides.

Tester une application web avec SimpleTest et TestGen4Web

mardi 1 novembre 2005 :: perrick :: Extreme Programming :: un commentaire :: aucun trackback

Harry Fuecks a repris du service chez SitePoint en plus de remettre PHPatterns sur les rails et déjà une chouette découverte : le projet TestGen4Web. Il s'agit d'une extension Firefox (1.5 beta 1 minimum) qui permet d'enregistrer dans un fichier XML toutes les actions effectuées dans une application web via Firefox : remplissage dans un champ texte, choix dans menu déroulant, clic sur un lien, etc... Ensuite un traducteur est fourni pour convertir ce fichier en scénario de tests pour l'émulation de navigateur dans SimpleTest et quelques autres (que je n'utilise pas ou peu). Idéal pour automatiser la rédaction de tests de recette.

J'avais déjà vu passé un tel outil (mais pour Windows uniquement et basé sur le moteur d'Internet Explorer) sur la mailing-list de SimpleTest. Là les linuxiens vont aussi pouvoir en profiter. Surtout qu'il s'agit d'un projet Open Source. Et au passage je découvre -- encore -- une nouvelle licence : Open Software License 2.1.

Les tests mordent

vendredi 3 juin 2005 :: perrick :: Extreme Programming :: aucun commentaire :: aucun trackback

Hier pour accélerer l'exécution de la batterie de tests en lien avec la base de données. Nous -- en binôme -- avions mis un paquet d'entre eux en commentaire. Et puis le commit a eu lieu. Et puis un autre...

Ce soir je me rends compte que les commentaires sont toujours présent dans le code source. Et bien sûr un des tests ne passe plus. Rageant. D'autant plus que je ne retrouve pas si facilement d'où vient l'erreur. Encore un exemple du pouvoir du dévéloppement piloté par les tests. Et rappel pour moi-même : ils doivent passer tous, tout le temps. Y renoncer temporairement peut causer des dégats au moral et au début de week-end.

Les avantages de la programmation en binôme

mardi 5 avril 2005 :: perrick :: Extreme Programming :: 3 commentaires :: aucun trackback

Avec les scéances qui s'enchaînent, le temps passé en hack mode ou dans la zone s'allonge régulièrement. Le plus impressionant reste la facilité avec laquelle on revient dans cet état si précieux. Pendant une pause pipi, l'autre continue à écrire des tests ou à en faire passer : la synchronisation est très rapide. La télépathie s'y approche à grand pas. Blague à part, je me demande si certains ont vécu de telles sensations. Pour tous les autres avantages, un papier assez complet existe (mais en anglais) : It Takes Two to Tango.

Note à soi-même : surtout ne pas se laisser tenter par les emails qui arrivent au fil de l'eau. Non seulement la plupart sont du spam mais en plus ils n'intéressent pas le binôme. Depuis que j'ai récupéré mon portable avec une nouvelle carte mère et que le PC de développement ne sert qu'à ça, la différence est flagrante.

Les inconvénients de la programmation en binôme

jeudi 31 mars 2005 :: perrick :: Extreme Programming :: 4 commentaires :: aucun trackback

Depuis que le stagiaire -- T. -- de No Parking est arrivé, j'ai enfin pu me mettre à la programmation en binôme de façon systématique. Avec d'un côté l'auteur de 35 KLOC (la version en production d'openTIME) et de l'autre un étudiant en école d'ingénieur, le degré d'intimité avec le code existant est évidemment très mal réparti et donc les réflexes qui vont avec.

Par contre il y a un paramètre qui peut compenser la balance très rapidement : la fatigue ou plus simplement l'envie-de-rien-foutre-isme. Certains appelent cela plus prosaiquement le developer's block.

D'où ma question : comment faire comprendre à son binôme qu'un jour on a du mal à coder ?

Note : je ne dis pas ça pour aujourd'hui. On vient de faire passer tous nos tests pour générer l'affichage d'un calendrier (avec -- entre autres -- le plusieurs rendez-vous sur une même journée et en même temps pour une seule personne dont nous sommes particulièrement satisfaits ce soir : on verra demain si ça tient encore la route ;-).

Pendant que le vernis sèche, une ballade XP

dimanche 13 février 2005 :: perrick :: Extreme Programming :: aucun commentaire :: aucun trackback

Ce n'est pas souvent que je viens au bureau le week-end. Encore plus rarement pour y travailler à l'ordinateur : le plus souvent c'est pour du bricolage. Aujourd'hui c'est une nouvelle -- et grande : 2.50m de long par 1.8m de large -- table que je suis en train de vernir. Etant donné que j'accueille un stagiaire d'ici quelques semaines, il était grand temps de supprimer les simples "planches sur tréteaux". Les photos arriveront le jour où je me décide à acheter un appereil photo numérique...

En attendant je vous conseille d'aller faire un tour dans d'autres bureaux d'équipe de développement logiciel : Rachel Davies propose quelques retours intéressants sur des pratiques off-line de développement agile.

Et dans le baluchon de cette promenade dominicale et bloguesque, une phrase que j'aime beaucoup : Everybody on an XP team should feel like an idiot regularly. de Ken Auer et Roy Miller dans Extreme Programming Applied: Playing to Win via Red Squirrel.

1 2 >>