Tag :Code Retreat

Retour du Code Retreat du 29 Septembre 2012

Samedi 29 Septembre 2012, 8:30 AM, un groupe de personnes se réunit devant le 156 boulevard Haussman. Non, il ne s’agit pas d’une réunion clandestine :). Toutes ces personnes sont là pour participer à une journée de code retreat.

Le principe du code retreat

Ouvert à tous et toutes, le code retreat a été conçu par les développeurs pour les développeurs. Basés sur les principes des Coding Dojo, un code retreat dure quant à lui une journée entière. C’est un événement lors duquel le pair-programming, le design de code, le « beau » code sont mis en avant. Un code retreat peut aussi être l’occasion de découvrir d’autres langages, puisqu’aucune contrainte de langage n’est imposée. Lors de ce code retreat, nous avons codé en javascript, scala, erlang, ruby, haskell et smalltalk.

Un exercice de code est choisi par les animateurs, le plus connu étant « Le Jeu de la Vie ». Tout au long de la journée, les participants en pair-programming codent l’exercice lors de plusieurs itérations de 45 minutes chacune. Chaque itération est suivie d’une rétrospective commune de 15 minutes et d’une petite pause de 5 minutes.

Après chaque itération, les participants sont encouragés à changer de binôme. De plus, le code produit lors de la précédente itération est supprimé afin de repartir à zéro à la nouvelle itération.

En général entre 5 et 7 itérations sont faites dans la journée, avant de terminer par une rétrospective globale.

L’arrivée – les croissants

Les organisateurs, Jean-Laurent De Morlhon et Laurent Bossavit, nous ont accueilli dès 8h30 puis convié à un petit déjeuner très équilibré composé de croissants, pains au chocolats et autres viennoiseries bien nécessaires pour affronter cette matinée.

Après nous avoir expliqué les règles du jeu, Jean-Laurent et Laurent, nous ont invité à  « ouvrir notre esprit », autrement dit :

  • Essayez des choses que vous n’osez pas faire dans le cadre du travail, mêmes si elles ne marchent pas au final. Explorez, tentez, et osez !
  • Variez les binômes,
  • Ne soyez pas timide et osez d’autres langages.

Les premières itérations

Voici les quelques règles de Simple Design que nous avons essayer de mettre en oeuvre lors des différentes itérations:

  • Exécuter d’abord tous les tests et vérifier qu’ils passent,
  • DRY – Don’t Repeat Yourself,
  • Reveal Intent : montrer ses intentions (nommage, 1 méthode = 1 fonctionnalité,…),
  • Faire des méthodes et classes de petite taille.

Pause déjeuner

La pause déjeuner a été l’occasion de nous connaître un peu plus, de partager nos expériences dans nos missions, de revenir sur les algorithmes/solutions trouvés pour implémenter « Le Jeu de la Vie », ou encore de regarder des vidéos geek.

Pizzas et Pause Déjeuner

L’après-midi

Pour les itérations de l’après-midi, Laurent et Jean-Laurent nous ont proposé de rajouter des contraintes : nous avons notamment essayé la technique TDD Ping-Pong à l’aide du plugin eclipse PairHero, rendant au passage le binômage un peu plus ludique.

Quelques exemples de la programmation par contrainte :
  • n’utiliser que des Objets ou que des Types Primitifs,
  • interdiction d’utiliser la souris ou le touch-pad,
  • interdiction de parler avec son binôme,
  • pas de if,
  • pas de while/for,
  • pas de return.
Pour anecdote, un binôme a décidé s’imposer la contrainte de ne pas se parler durant la dernière itération. Le début a bien fonctionné, mais au bout d’un moment les désaccords sont apparus sur la marche à suivre sur un des algorithmes à coder ! Le silence a été brièvement brisé afin de repartir sur de bonnes bases. Au final, le binôme a presque fini l’exercice ! L’expérience s’est avérée être très drôle pour le binôme et surtout pour celui d’en face assistant à ce spectacle où aucun sourire ne transparaissait !!

La leçon à retenir: il faut bien entendu communiquer, mais il est également très important d’aller à l’essentiel.

Rétrospective de la journée

Pour conclure cette journée, chaque participant a répondu aux questions suivantes:

  • Qu’avez-vous appris aujourd’hui ?
  • Qu’est-ce qui vous a surpris aujourd’hui ?
  • Qu’allez-vous appliquer dès lundi au travail ?

Rétrospective de la journée

Conclusions

Un code retreat est un très bon moyen d’apprendre à coder proprement, de se confronter à d’autres approches, façon de penser via le pair-programming. C’est aussi l’occasion de tenter ce que l’on n’ose pas dans nos missions et d’essayer d’autres langages.

N’hésitez pas à participer aux prochains code retreat, quelques soient vos connaissances, votre expérience et vos langages de programmation !

Merci à Jean-Laurent De Morlhon et Laurent Bossavit  pour l’organisation de la journée, et pour leurs remarques pertinentes. Merci aussi à Xebia pour l’hébergement.

 

Code Retreat : Mode d’emploi (retour sur le Global Day of Code Retreat 2011)

Duchess au Global Day of Code RetreatLe 3 Décembre 2011 a eu lieu le Global Day of Code Retreat où plus de 2200 développeurs se sont retrouvés le temps d’une journée dans plus de 90 villes du monde , simplement, pour écrire du beau code…

En France, seulement trois Code Retreat ont été organisés à l’occasion de cette journée:
un à Paris dans les locaux de Xébia
un à Bordeaux dans les locaux d’Arpinum
et un à Toulouse dans les locaux de DocDoku

Connaissant déjà les Coding Dojo, j’étais curieuse d’en savoir plus sur les bienfaits d’un Code Retreat que l’on m’avait décrit comme une journée de code composée de 5 ou 6 itérations de 45 minutes ; chaque itération étant consacrée à coder le même problème dans le langage de son choix… et tout cela en prenant bien soin à la fin de chaque itération d’effacer le code écrit et de changer de binôme !
Et c’est surtout ce point qui m’intriguait : effacer et recommencer à coder….mais pourquoi ?

C’est donc, avec une certaine curiosité, que j’ai rejoint dès 8h30 du matin les 15 autres participants de ce premier Code Retreat toulousain. Là, j’ai pu constater qu’un des premiers mérites du Code Retreat avait été de regrouper des habitués de plusieurs User Group toulousains : Toulouse JUGApéro WEB , et les agilistes de la SigmaT

Après un café, Antoine, notre animateur du jour (“facilitator”) nous a présenté le déroulement de la journée, mais surtout le problème à coder qui n’était autre que le jeu de la vie (Game of Life). Le jeu de la vie est un  automate cellulaire imaginé par John Horton Conway en 1970. L’univers du jeu de la vie se déroule sur une grille à deux dimensions, théoriquement infinie. Chaque cellule a 2 états possibles vivante ou morte. À chaque étape, l’évolution d’une cellule est entièrement déterminée par l’état de ses voisines. Les règles suivantes nous ont été proposées :

  • Si une cellule est vivante et a strictement moins de 2 voisines vivantes, elle mourra à l’étape suivante en raison d’une sous-population.
  • Si une cellule est vivante et a strictement plus de 3 voisines vivantes, elle mourra à l’étape suivante en raison d’une sur-population.
  • Si une cellule est vivante et a 2 ou 3 voisines vivantes, elle restera vivante à l’étape suivante.
  • Si une cellule est morte et a exactement 3 voisines vivantes, elle naîtra et deviendra ainsi vivante à l’étape suivante.

Cette journée étant consacrée au code, il était donc fondamental de rappeler également les 4 règles élémentaires requises pour écrire du code de qualité :

  • Faire passer les tests, autrement dit pratiquer du TDD (Test Driven Developpment)
  • Eviter la duplication de code (principe DRY  :  Don’t Repeat Yourself )
  • Faire en sorte que le code soit clair, expressif, autrement dit qu’il révèle l’intention (noms de variables, de méthodes explicites…y compris pour les tests)
  • Ecrire du “petit code”, autrement dit minimiser la longueur des classes et des méthodes.

Un des principes du Code Retreat est que chaque participant vienne avec un ordinateur portable sur lequel il a installé au moins un environnement de développement de son choix (comprenant bien sûr une libraire de tests unitaires…).
Les itérations se déroulent ensuite en pair-programming (en binôme) où le ping pong est encouragé :

  • un membre du binôme écrit un test unitaire,
  • l’autre membre doit écrire le code métier qui fait passer ce test,
  • puis avant de repasser le clavier à son collègue, il écrit un nouveau test unitaire, que son collègue doit faire passer,
  • et ainsi de suite…

La présentation terminée, il était grand temps de découvrir les langages du jour. La plupart des participants étaient venus avec un environnement Java, mais il était également possible de développer en C++, Python, C#, Php et même Javascript.
Tout était dit. La première itération de code pouvait être lancée !
Les binômes se sont rapidement formés au hasard et le marathon des six itérations a pu commencer…

Première itération :  Installation & Compréhension du  problème…
Cette première itération sert en quelque sorte d’échauffement pour la suite de la journée.
Après l’installation des binômes et le lancement des environnements de développement vient le temps de la réflexion et de l’analyse du problème donné. On commence alors à s’approprier les règles du jeu de la vie, à griffonner un diagramme d’états, puis le code peut enfin s’exprimer. Dans cette première itération, nous avons choisi d’implémenter l’univers du jeu de la vie de manière très simple (tableaux à deux dimensions) afin de s’intéresser au plus vite aux règles métier. Aucune consigne n’avait été donnée pour cette itération, à part le respect du ping pong. Mais 45 minutes passent très vite (trop vite) et c’est vraiment lorsqu’on commence à être un peu  productif, à rentrer dans le vif du sujet, que l’on doit s’arrêter. Et oui, c’est déjà fini…  Au bout de ces premières 45 minutes, l’application est loin d’être terminée et le code écrit pas vraiment optimisé.
Je dirais que cette première itération sert de défrichage et permet de se mettre dans l’ambiance de la journée.
Chaque itération est ensuite suivie d’une rétrospective de 15 minutes animée par le “facilitator”.
A la fin de la rétrospective, Il faut respecter une des règles d’or du Code Retreat : effacer le code produit au cours de l’itération. Cela est un peu déroutant la première fois. Donc ce n’est pas sans quelques réticences que nous avons supprimé notre code, mais c’est la règle !

Deuxième itération :  Vers une conception Objet mieux pensée …
Chaque itération donne l’occasion de coder avec une nouvelle personne, les binômes devant être recomposés à chaque fois. Il est même possible de changer de langage d’une itération à l’autre …
Avant chaque itération, une nouvelle consigne est donnée par l’animateur afin d’encourager une création différente à chaque fois. La première rétrospective avait montré que la plupart des binômes était partie sur un tableau pour implémenter rapidement l’univers du jeu de la vie. Dans cette deuxième itération, la consigne donnée était donc de penser plus Objet en terme d’Univers et de Cellule…
Dès cette deuxième itération, j’ai pu constaté que l’écriture du code était beaucoup plus fluide, moins hésitante, plus rapide. Le code produit à l’itération précédente était naturellement repensé et optimisé pour la nouvelle itération. Le fait d’effacer le code permettrait-il alors vraiment d’écrire du code différent et plus performant d’itération en itération ?
La consigne étant l’Objet, notre binôme a cependant beaucoup discuté  lors de cette itération sur la manière de prendre en compte le caractère extensible du problème (cellules à n facettes, univers à n dimensions) pour finalement convenir avec l’animateur que nous resterons par la suite seulement dans un espace à deux dimensions. Avons-nous perdu notre temps ? Je ne pense pas car nous avons pu mener une réflexion commune. Et cela fait également partie de la magie du Code Retreat de pouvoir s’adapter immédiatement à son binôme, de pouvoir partager ses points de vue, ses bonnes pratiques de code et ses astuces de programmation.
A la fin de cette deuxième  rétrospective, il n’a pas fallu déroger à la règle de base du Code Retreat qui consiste à supprimer définitivement le code, et cette fois-ci c’est même avec un certain plaisir que chaque binôme a effacé son code !

Troisième itération :  No For, No if …
La consigne de la troisième itération était de n’écrire  ni boucle, ni test : “No for, No if” devait désormais être notre devise. Je n’avais jamais envisagé avant d’écrire un programme Java sans for, ni if (ni while, ni switch) et je dois dire que cette consigne nous a laissés perplexes pendant un certain temps : pas vraiment évident de respecter une telle consigne …
Certains binômes ont essayé de contourner la contrainte en dissimulant dans leurs instructions des tests via des opérateurs binaires et ternaire (&&, ||,?), d’autres ont évoqué le pattern Visiteur.
La notion de récursivité est également venue naturellement à l’esprit dès lors que les boucles n’étaient pas permises. Mais classiquement, qu’est-ce qui stoppe une récurrence ? Une condition d’arrêt que l’on écrit généralement avec un if !…Et hop, il est encore nécessaire de pousser la réflexion un peu plus loin. Ce test conditionnel peut alors être évité en faisant appel à des notions de polymorphisme. Vincent propose dans son retour un exemple de code pour illustrer cette solution.
Personnellement, c’est l’itération de la journée que j’ai préférée. Ecrire un code sans structure de contrôle est une contrainte qui ne me serait jamais venue à l’esprit…et pourtant au final, on constate que c’est un excellent exercice pédagogique !

A la fin de la troisième itération, il était déjà plus de midi : l’heure de la pause déjeuner.
Le repas fait intégralement partie du concept du Code Retreat : c’est un moment convivial d’échanges entre les participants. Il est donc  important de prendre une vraie pause repas d’environ une heure et demie. Le repas est généralement offert par le sponsor de l’événement. Merci DocDoku !

Quatrième itération :  Tell don’t ask, no primitive obsession …
La consigne de la quatrième itération était de respecter le principe Tell don’t ask. Ce principe de connaissance minimale consiste à demander directement à un objet ce qu’il doit faire, plutôt que de l’interroger sur son état interne afin de prendre des décisions qui mènent à des actions de sa part… Autrement dit, les getters/setters devaient cette fois-ci être bannis de notre code, et les méthodes judicieusement choisies et nommées en fonction de nos besoins.
Le principe Tell don’t ask imposé dans cette itération devait également nous amener à repenser notre code en évitant toute “primitive obsession” c’est-à-dire que nous devions éviter d’utiliser des types primitifs comme attributs (autant que possible).
Durant cette itération nous nous sommes donc plus particulièrement intéressés aux cellules, à leurs coordonnées, et à la notion de voisinage ? La Cellule doit-elle connaître ses coordonnées ?  La Cellule doit-elle connaître ses voisins ? Ne serait-il pas plus judicieux que l’Univers gère lui-même la notion de voisinage ? etc …
De nombreuses questions qui  devaient nous amener à écrire un nouveau code “tout objet”, vraiment très différent de celui de la première itération.

Cinquième itération :  Itération sans parole …
La cinquième itération fut une itération qui se déroula sans bruit, puisque la consigne consistait à interdire aux membres d’un même binôme de parler entre eux. Seuls les tests, écrits de manière expressive, devaient permettre de révéler les intentions de l’un et de l’autre. Sans discussion préalable possible, cette itération, bien plus que les précédentes, demandait de porter une attention particulière à l’expressivité du code  pour que chacun puisse comprendre l’attente de l’autre. Il fut  indispensable de  nommer les méthodes de manière très significative, ce qui nous amena bien souvent à écrire de véritables phrases pour nommer les méthodes des classes de test .
Cette itération fut une itération assez difficile à mener. En effet, arrivés à la cinquième itération de la journée, chacun a avancé dans sa vision du problème en menant au cours de la journée ses propres réflexions avec des binômes différents. Et bien que les contraintes de chaque itération soient communes, les choix de conception et d’implémentation sont parfois bien différents. Ce fut le cas pour cette itération où avec mon binôme nous avions deux approches différentes, ce qui compliqua la tâche mais nous incita doublement à écrire des tests expressifs afin d’essayer de trouver une solution commune.

Sixième itération :  A La Carte …
La sixième et dernière itération était une itération “à la carte” destinée à se faire plaisir où chaque binôme pouvait choisir une consigne parmi les propositions suivantes :

  1. Désaccord  ou  écrire du code pour aller dans le sens inverse du test à vérifier…
  2. Pire code possible
  3. Sans la Souris … pour les spécialistes des raccourcis claviers (1)…
  4. Des méthodes de 3 lignes maximum.

(1) Une discussion a depuis été lancée sur la mailing list du Toulouse JUG !

 

Rétrospective finale
Lors de la rétrospective finale chaque participant a dû répondre aux 3 questions suivantes :

  1. Qu’est-ce que j’ai appris aujourd’hui ?
  2. Qu’est-ce qui m’a surpris aujourd’hui ?
  3. Qu’est-ce que je vais mettre en application dès Lundi ?

Les expériences des participants étaient diverses, mais chacun s’est accordé pour dire :

  • que la journée avait été très riche en échanges et en partage de bonnes pratiques,
  • que les six itérations avaient chacune conduite à la production d’un code bien différent,
  • et que dès lundi les tests bien écrits allaient être (re)mis à l’honneur dans les équipes de développement !

La journée s’est terminée par l’annonce de la création d’une communauté Software Craftsmanship sur Toulouse qui, espérons-le, proposera très prochainement d’autres Code Retreat !

Liens :
http://globalday.coderetreat.org/
http://jduchess.org/duchess-france/blog/resolutions-2011-coding-dojo-code-retreat/
http://coderetreat.com/gol.html
http://c2.com/cgi/wiki?XpSimplicityRules
http://coderetreat.org/facilitating/structure-of-a-coderetreat
http://coderetreat.ning.com/profiles/blogs/how-a-coderetreat-works
http://pragprog.com/articles/tell-dont-ask
https://groups.google.com/forum/#!topic/toulouse-jug/SpOWtYPxJa0
http://antoine.vernois.net/dotclear/index.php?post/2012/01/09/Software-Craftsmanship-%C3%A0-Toulouse

Autres retours sur le Global Day of Code Retreat :
http://blog.genigraph.fr/2012/01/03/code-retreat-de-toulouse-le-03-decembre-2011/
http://blog.r0ly.fr/?p=67

Des Photos du Code Retreat toulousain
https://plus.google.com/photos/116856815308605996307/albums/5682276859165947169

Résolutions 2011 : coding dojo ? code retreat ?

En début d’années on prend des tas de  bonnes résolutions. La résolution de cette année 2011 sur le plan professionnel pourrait être “Et si je m’entraînais à coder” ? OK, je sais déjà coder, mais si je m’entraînais pour m’améliorer ?

Randori

Qu’est ce qu’un coding dojo ?

Une citation de Laurent Bossavit exprime bien l’idée :

Si je veux apprendre le Judo, je vais m’inscrire au dojo du coin et y passer une heure par semaine pendant deux ans, au bout de quoi j’aurai peut-être envie de pratiquer plus assidûment.

Si je veux apprendre la programmation objet, mon employeur va me trouver une formation de trois jours à Java dans le catalogue 2004.

Cherchez l’erreur.

Laurent Bossavit

Le dojo est comparable a un entraînement. Les sportifs, les musiciens s’entraînent pour apprendre de nouvelles techniques et simplement rester au niveau. Les informaticiens sont dans un environnement très changeant en matière de technologie et de pratiques et ont besoin d’apprendre et de se tenir à jour.  Comment  mieux comprendre une technologie, une méthode, des pratiques qu’en les voyant mises en oeuvre dans la résolution d’un problème concret ?

Concret certes, mais le but du dojo n’est pas de trouver une solution a tout prix. Le but est de trouver une belle solution, de montrer sa réalisation pas à pas pour la faire comprendre et partager, d’échanger avec le reste du groupe sur les points forts et les points faibles de cette solution. C’est quelque chose qu’on a rarement le temps de faire dans un milieu professionnel où il faut répondre le plus vite possible au problème. Le dojo est un environnement sûr où on peut expérimenter des démarches différentes, apprendre un nouveau langage.

Découvrir, apprendre, et consolider ces connaissances jusqu’à ce qu’elles deviennent des réflexes. Perdre ses mauvaises habitudes de code pas beau. Parvenir à raisonner par défaut avec une démarche pas à pas, vérifiée à chaque étape, c’est à dire TDD (développement dirigé par les tests) et ne pas retomber dans le bidouillage cradouille à chaque fois que l’on fait face à une difficulté. Croyez moi, ce n’est pas facile, la pente du “je fais marcher, on verra après” est assez tentante, et pas mal glissante aussi au bout de quelques étapes.

Mais le dojo est un groupe et il vous rappelera à l’ordre si jamais vous avez quelques tentations. L’organisation en groupe rend cet apprentissage plus intéressant. Il permet de rencontrer d’autres passionnés ou simplement des gens curieux. Mais c’est aussi un moyen de travailler sa technique de travail de groupe : être suffisament discipliné pour ne pas interrompre la présentation à tout bout de champ, savoir expliquer ses arguments sans agressivité, savoir recevoir les critiques et les prendre en compte.

Il faut aussi savoir donner. Il n’y a pas de speaker qui va vous apprendre des choses. Chacun participe d’une certaine manière.

Au final, le dojo se doit d’être ludique pour maintenir la motivation. On ne va pas implémenter des règles de gestion de commandes ou d’attribution de crédit. Les sujets de coding dojo sont en général sans utilité réelle et conçus dans un but ludique.

07-01-02 Randori Camp - Pori FIN (5)

Comment ça se passe ?

Chaque dojo définit des règles de fonctionnement qui lui sont propres.

L’écoute est importante. Les coding dojos commencent souvent par une rétrospective du dojo précédent. Pour partager avec ceux qui n’ont pas pu venir et c’est souvent l’occasion de faire le compte rendu. Le retour porte sur l’exercice,  l’explication dans les grandes lignes de la solution apportée mais aussi sur ce qui s’est bien ou mal passé du point de vue de la démarche : des étapes sautées dans la démonstration qui l’on rendue difficile à comprendre, des gens dissipés, mais aussi une pratique que l’on a bien apprécié et que l’on tr ouve utile. Le débrieffing a froid permet de réduire les tensions et d’avoir envisagé des solutions dans l’intervalle.

Il faut ensuite choisir un sujet. Il n’y a pas de speaker qui vient avec un sujet préparé. Le groupe choisi un des exercices proposés par les membres du groupe.

Il y a deux grands types d’exercices :

  • Le kata préparé : c’est un exercice réalisé par une personne, qui a choisi un problème à résoudre, un langage et a préparé au moins une ébauche de solution. Il peut aussi être réalisé à deux en pair programming, soit en alternant, soit avec un candide qui détaille la démarche
  • Le randori : c’est un exercice collectif dans lequel les membres du groupe vont se succéder en pair programming pour une période assez courte (5 à 10 mn). On remplace une personne à chaque tour pour garder une certaine continuité. Il existe aussi une variante où plusieurs groupes travaillent en parallèle.

Les randori permettent à chacun de mettre les mains dans le code et de s’impliquer. C’est toutefois un peu difficile si les gens ne connaissent pas du tout le langage ou la technologie utilisée. Un autre apport du randori est de travailler sa souplesse. La solution a pu être commencée avec un algorithme qui n’est pas celui que vous auriez choisi. Il faut savoir s’adapter. Il faut aussi savoir remettre en cause ce choix s’il ne mène à rien et le remplacer.

Dans les deux cas, celui qui présente son kata ou est dans son tour de randori doit avoir l’attention de tous. Il ne doit pas être interrompu pendant qu’il présente sa solution et met en oeuvre une étape de sa résolution, jusqu’à la barre verte. La barre verte est l’affichage de la plupart des outils de test unitaire pour montrer que tous les tests passent. Lorsque la personne réfléchi à sa solution et l’implémente, on la laisse se concentrer. Lorsque la barre est verte, on peut discuter des choix réalisés et si nécessaire les remettre en cause. Bien sûr, si la personne est en difficulté, elle peut être aidée à tout moment.

L’exercice dure environ 1h.

Le TDD est indispensable dans ce genre d’exercice car il permet de rendre la main régulièrement  au groupe pour avoir un retour. Les langages sont souvent des langages nouveaux et fonctionnels (Ruby, Scala, Haskell, …) car ils sont plus motivants.

Vous pouvez imaginer des problèmes amusants qui peuvent être résolus en 1h environ. Écrire un convertisseur de chiffres romains est un bon exemple de défi raisonnable. Si vous manquez d’imagination, des sujets types sont présentés sur ces deux sites :

On part d’une page blanche en général  car le but est de tout expliquer pas et pas. La recopie de gros bouts de code amenés dans ses cartons se prête mal à l’exercice. Il existe toutefois des variantes où on part d’une situation donnée issue d’une séance précédente ou dans le but de s’exercer à faire du refactoring.

La session se termine par un debrieffing rapide sur ce qu’on a fait.

Coding Dojo July

Les coding dojos en france (et pas loin)

Et maintenant, il vous faut trouver un groupe près de chez vous :

Si vous connaissez d’autres coding dojos actifs, n’hésitez pas à nous tenir au courant.

Dojo Sticker I

De quoi j’ai besoin ?

Il n’y en a pas et vous voulez vous lancer ?

Pour que tout se passe bien :

  • une salle pour une dizaine de personnes,
  • une machine avec l’environnement de développement requis (IDE ou traitement de texte avec le support du langage, les outils de test, le compilateur)
  • un vidéo-projecteur pour que tout le monde puisse voir le code
  • configurer les affichage pour que tout le monde puisse lire le code confortablement
  • un minuteur pour les tours de randori (on trouve ça sur la plupart des smartphone, sinon un minuteur de cuisine fait aussi l’affaire)
  • une mailing list ou un site de gestion de communauté pour vous mettre d’accord sur les dates et lieux

Et probablement qu’au début vous aurez à fournir vous même beaucoup des sujets pour qu’il y en ait au moins un ;-)

Meteora (I)

Et si j’en veux encore plus ?

Arrivera un jour où votre entrainement hebdomadaire ne suffira plus. Vous aurez envie d’aller plus loin.

Une heure c’est un peu court. On n’a pas vraiment le temps d’explorer différentes solutions ou de mener jusqu’au bout certains exercices.

Cette année on voit apparaître des “code retreats“, des retraites dans un lieu sympa, entre développeurs pour coder une journée entière ou un Week End entier selon les formules.

C’est l’équivalent des stages complémentaires pour les gens qui pratiquent un sport, l’occasion de rencontrer un peu plus longtemps les plus motivés, de rencontrer des experts.

Le premier code retreat a été organisé à Grenoble par l’AlpesJUG le 21 Janvier. Il a été dédié à l’implémentation par plusieurs équipes du jeu de la vie un classique des coding dojos.

D’autres suivront probablement, soyez attentifs.

KataArgs

Les références

J’ai utilisé différentes sources pour réaliser cet article :

Vous pouvez aussi regarder ces documents :

Merci à Isabelle Blasquez pour la relecture et les informations complémentaires.

En continuant à utiliser le site, vous acceptez l’utilisation des cookies. Plus d’informations

Les paramètres des cookies sur ce site sont définis sur « accepter les cookies » pour vous offrir la meilleure expérience de navigation possible. Si vous continuez à utiliser ce site sans changer vos paramètres de cookies ou si vous cliquez sur "Accepter" ci-dessous, vous consentez à cela.

Fermer