To be mad or not to be mad

Avec les équipes avec lesquelles je travaille, ou parfois juste tout seul, le CheckIn m’aide à me sentir mieux. « Me sentir mieux » : mieux comprendre comment je me sens.

***

Il y a quelques temps j’étais sur l’autoroute et j’avais peur d’être en retard. Je prends ma sortie et me voilà sur une petite route de campagne derrière une voiture qui roulait incroyablement doucement. Je commence à m’énerver dans ma voiture : « Mais vas-y avances », « Nan mais c’est pas vrai », « Y m’énerve ! »


ProtocolCheck:

   Dear Master,

   I think you're breaking commitment #2 of the CheckIn protocol
       "State feelings only as they pertain to yourself"
   Doing so might hide something more useful for you

   Forever yours,
   Your brain

This code is latency-free hyper-fast brain code
It can be used safely anytime
even when driving 😉

Toujours derrière cette voiture, je suis cette idée : qu’est-ce qui m’énerve au juste ? Quelle phrase puis-je poser qui commencerait par « Je suis énervé parce je … » ?

Probablement ce qui m’énerve c’est d’être parti en retard. Cela donne « Je suis énervé parce que je suis parti en retard ». C’est vrai mais ce n’est pas très utile pour moi à ce moment là. Je sens que j’ai besoin de creuser plus.

Ce qui m’énerve c’est ma situation actuelle, c’est d’être bloqué derrière cette voiture avec ce conducteur qui se traine et que j’ai traité de tous les noms le pauvre. Cette personne a sans doute les meilleures raisons du monde de rouler doucement sur cette route de campagne. Et honnêtement dans quatre minutes tout au plus je serai arrivé de toutes façons.

« Je suis énervé parce que je suis bloqué derrière cette voiture ». « Bloqué » ? Je pourrais doubler. Ligne blanche, route cabossée, passage à niveau dans 200 mètres. Mmm non.

« Je suis énervé parce que je me sens bloqué ». C’est mieux.

« Je suis énervé parce que je subis des conditions imprévues auxquelles j’ai l’impression de ne pouvoir échapper ». Je crois que je le tiens. Je me sens mieux, je me sens même content. Je subis encore le même problème mais plus calmement, … et sans insulter personne. Je suis content d’avoir pris ce temps pour trouver ce qui m’énervait. Cela s’avère effectivement plus utile pour moi. Je suis encore énervé mais cela consomme moins d’énergie. Plus du tout énervé contre quelqu’un d’autre, je me fatigue moins. Content d’avoir eu cette réflexion, je me sens en meilleure forme, plus serein.

***

Catégories :Journal, The Core Protocols Étiquettes : ,

Vacances :)

22 juillet 2012 3 commentaires

En traversant en ferry depuis l’île du Prince Edouard vers la Nouvelle Ecosse, il y avait le wifi. J’ai trouvé ça trop fun. Emporté par mon élan je me suis mis à coder pour préparer une session que je voudrais proposer aux conférences d’automne. M’aideriez vous à la paufiner en me donnant votre avis sur ce qui suit ?

Je voudrais reprendre l’idée du kata classique de la décomposition en facteurs premiers en l’enrichissant d’un accès web à la décomposition. Mon intention est de rendre plus palpable l’intérêt du tdd en prenant un cas simple que probablement tout le monde connait; et en le mettant dans ce qui pourrait ressembler à une vraie application.

Je pourrais dans cette session illustrer les points suivants.

  • outside-in vs. inside-out tdd
  • architecture hexagonale
  • build unique avec tests JUnit et Jasmine
  • gestion de sources avec Mercurial

Dans ce ferry donc, j’ai juste le temps de poser deux tests différents pour illustrer le premier point. J’ai commencé par le coeur dans une branche inside-out. Le départ ci-dessous n’est pas vraiment le départ classique du kata mais le kata en question n’est pas mon sujet ici.

Puis, dans une autre branche, je repars à zéro et je pose un test web plus ambitieux que le précédent.

Je me retrouve ainsi avec deux débuts d’histoires différents. La seconde histoire a le mérite de partager mon intention cible qui est de donner un accès web la décomposition. Ces deux approches ne sont pas obligatoirement opposées. Il peut arriver que l’on ait besoin d’explorer un domaine, juste pour en apprendre un peu plus et sortir du brouillard.

Je ne pense pas écrire tout le code pendant la session mais plutôt arriver avec un répo Mercurial qui contient les deux histoires, qui fusionnent à un moment d’ailleurs, et de passer les histoires en accélérée en sautant d’une révision à l’autre pour illustrer les points listés plus haut. Comme on le voit dans les descriptions ci-dessus, je prévois de sauter d’un test rouge à l’autre, le point n’étant pas de faire passer les tests mais d’illustrer que les tests nous guident ; les tests rouges bien sûr !

Qu’en pensez-vous ? Devrais-je proposer cette session ? Que devrais-je améliorer ou modifier pour proposer une session de ce type ? Avez-vous besoin d’en savoir plus pour avoir un avis ?

 

Catégories :Journal, TDD Étiquettes :

TDD & SQL

La semaine dernière j’animais une PSD et certains participants ont profité de l’occasion pour jouer avec le kata des chiffres romains. Hasard ou rappel inconscient, c’était justement le kata de février de notre ami 12meses12katas.

Bref, j’ai joué aussi et comme l’ambiance s’y prêtait bien, j’ai ressorti ma doc de mysql. Un petit guard dans un coin pour avoir mon autotest et hop c’est parti. J’ai fait une petite vidéo du début pour vous partager de quoi ça peut avoir l’air et démystifier un peu le tdd avec le sql. Dans la session la semaine dernière nous avons pris l’option de ne pas utiliser de framework « sur étagère », histoire de bien comprendre ce qui se passe en refaisant juste ce dont nous avions besoin. C’est cette option que j’ai repris ici.

Catégories :Journal, TDD Étiquettes : ,

Remove comments

1 février 2012 7 commentaires

Aujourd’hui j’ai vu du code qui ressemblait à celui ci-dessous. Bien sûr ce n’était pas vraiment ce code mais l’idée est là.

Nous avons discuté de l’idée de supprimer ces commentaires. Une décision pas facile à prendre dans l’état car, pour plusieurs personnes présentes, le dessin du commentaire a beaucoup de valeur. En effet, il résume le cas qui nous intéresse de façon très claire.

Cela devient pourtant une décision facile à prendre si tout simplement on décide de reproduire ce dessin dans le code. Après un peu de tuyauterie, je suis récompensé : ma fille comprend mieux le code. Ci-dessous un exemple de ce que cela peut donner.

Bien sûr il reste à ranger tout ça plus proprement mais vous voyez l’idée. Notez que dans la bataille on est passé de 2 tests à 1 seul. Là c’est parce que on a fait du ADD. C’est ma fille qui vient d’inventer ça ce soir : le développement piloté par l’esthétisme. Elle trouve ça plus joli comme ça.

Et vous, vous faites comment ?

Catégories :Journal, TDD Étiquettes :

Scrum Master vs. Scrum trainer

19 décembre 2011 2 commentaires

Bonjour,

Depuis l’été dernier j’ai changé un truc qui me semble significatif dans mes formations Scrum et je voulais aujourd’hui le partager.

La version courte : pendant mes cours PSM, j’utilise maintenant le terme Scrum trainer en lieu et place de Scrum Master.

La communauté agile a largement, il me semble, décrit les inconvénients du nom « Scrum Master », et surtout de cette étiquette « Master ». J’ai donc souhaité chercher une alternative. Et comme je souhaitais surtout essayer autre chose et mesurer sur le terrain ce que cela changeait, je n’ai pas attendu le résultat d’un éventuel long débat pour faire un essai.

Voici ce que j’ai cru mesurer:

  • L’étiquette « trainer » véhicule mieux la partie « enseignant de Scrum » du rôle
  • L’étiquette « trainer » supprime toute relation de hiérarchie avec l’Equipe

La façon dont je mesure ces améliorations est fort simple : d’une part les discussions pendant le cours ne sont plus les mêmes. D’autre part, une proportion beaucoup plus grande de participants me semblent comprendre comment tirer le plus avantage de ce rôle, et au delà du rôle, de l’ensemble de Scrum.

Un exemple ?

Avant, j’avais systématiquement la question « Est-ce que le Scrum Master fait les burndown charts ? « , et nous débattions un long moment sur les conséquences de le faire ou non. Maintenant cette question n’apparaît plus en ces termes et les participants explorent plutôt les conséquences pour une équipe de faire un burndown d’itération ou non.

Un autre exemple ?

Avant, nous débattions longuement autour de l’idée que le Scrum Master, vous savez, « removes impediments ». J’avais coutume d’insister sur le fait que nous parlons ici de blocages mentaux liés à la compréhension de l’étendue des responsabilités de PO et d’Equipe (de dev comme on dit maintenant). Cette idée avait du mal à se frayer un chemin dans les cerveaux tant le vocabulaire ne nous aidait pas. Maintenant c’est beaucoup plus simple et il n’y a presque plus de point dure dans cette discussion.

Il me semble aujourd’hui logique qu’une nouvelle approche ait besoin d’être apprise. Nous disons toujours que Scrum s’apprend en se pratiquant. Logique alors que Scrum prévoit un prof embarqué.

Catégories :Journal, Scrum Étiquettes : ,

Refactoring de tests

13 octobre 2011 10 commentaires

Salut 🙂

Je faisais remarquer aux participants d’une PSD le mois dernier que l’on passe énormément plus de temps à lire du code qu’à en écrire. C’est pour cette raison, entre autres, que je leur conseillais d’investir dans la lisibilité du code. Une façon de faire ça qui fonctionne bien pour moi c’est d’écrire l’intention du test en langage naturel, puis de m’arranger pour faire compiler et passer ce que je viens d’écrire.

Un exemple ? Allez, un exemple… 😉

Considérez le test suivant. Sans doute vous trouverez que j’exagère de montrer autant de choses qu’il ne faut pas faire, mais c’est pour l’exemple.

Le défaut de ce test qui m’intéresse aujourd’hui c’est que beaucoup de gens vont le lire plusieurs fois pour bien comprendre son intention. Si j’essaye de me concentrer sur l’intention du test, en tentant d’activer mon meilleur anglais, cela me donne envie d’écrire les choses plutôt comme ci-dessous.

A partir de là, je dis souvent aux participants « il ne vous reste plus qu’à placer les parenthèses et les points où cela vous arrange pour faire compiler tout ça ». Il y a bien sûr plusieurs façons de le faire et je ne vais pas m’étendre sur ce point. Juste mentionner que pour ma part j’aime bien le pattern builder et, en Java, les imports statiques. Cela peut par exemple donner le résultat ci-dessous.

C’est plus clair non ?

Catégories :Journal, TDD Étiquettes :

Un rêve étrange

Incroyable mais vrai, j’ai revé de Git cette nuit. Et « forcément » comme je rêvais de Git, il y avait aussi @dgageot et @samidalouche.

Sami m’a dit un jour quelque chose comme : « oublie les branches, pense graph ». Sur le coup j’ai compris intellectuellement cette phrase mais pas l’utilité pratique. Le temps passe et voici qu’un nouveau défi Git se présente à mon cerveau – c’est assez fréquent. Hier soir j’aurais exprimé le défi comme ça : je voudrais bien faire un cherry-pick d’un commit précédent dans ma branche, pourrais-je faire un merge et non un cherry-pick ? Un merge d’une branche sur elle-même ? Je m’endors là dessus et j’entends Sami de nouveau : « oublie les branches, pense graph ». Et cette fois ça me parle ! Et cela me pose une autre question : « What if… » je ne connaissais pas le commit en question mais uniquement son effet. David cette fois me parle à l’oreille : « bisect ». Cela fait plusieurs années il me semble que David me « rabâche » les oreilles en conférence avec ce bisect qui permet enfin de faire mieux que d’utiliser Git en première vitesse.

Je me réveille et là plus possible de dormir, il faut que j’essaye ça.

  1. Merger une branche sur elle-même
  2. Rechercher un commit

Merger une branche sur elle-même

Je conserve ce titre « merger » mais ce terme me semble de plus en plus inapproprié.

Donc, j’ouvre mon terminal préféré et je me lance :

  1. Créer un nouveau répertoire suivi par git.
  2. Repérer un commit en particulier. En pratique un code chat, du genre 3a68fd32ca3b16547c5abb2da52fdf7aed290ee3
  3. Contredire le commit héros de cette histoire
  4. git cherry-pick 3a68fd32ca3b16547c5abb2da52fdf7aed290ee3
  5. Et là, « magie » 🙂

Bien sûr un git merge est sans effet puisque ce raccourcis de plusieurs commandes git se censure lui-même. Comme souvent quand on sait faire, la solution à mon problème d’hier soir semble triviale. Je le note quand même dans un petit blog pour pas oublier ;).

Rechercher un commit avec git bisect

Maintenant, j’imagine que je ne connais pas le commit que je cherche. En pratique dans mon exemple le commit en question ne fait que créer un fichier. Je veux trouver un commit qui crée ce fichier.

  1. Créer un fichier shell qui teste si mon fichier existe.
  2. initialiser git bisect. Je prends l’intervale le plus large : [HEAD premier-commit]
  3. lancer le run: git bisect run search.sh

Et là c’est juste E-norme ! J’ai trouvé des tas de blogs sur bisect qui finissent comme ça : c’est E-norme. A croire que dans la vie d’un utilisateur de Git c’est une étape mentale qui mérite d’être criée au monde. Je ne résiste pas à l’envie de vous partager la copie d’écran du retour de git.

Catégories :Journal, Non classé