[python-nl] Coder's Dojo

C.T. Matsumoto c.t.matsumoto at gmail.com
Thu Mar 25 10:05:32 CET 2010


Hello,

Thanks for all the great talks last night at the PUN. It was a great 
time, even though a bit late.

Last night I very shortly presented an idea to try out a Coder's Dojo at 
the ABC space. It was great to meet some other people who are interested 
and as well have already tried out their own Dojo.

Here is the information I've found about a Dojo. After last night I know 
that there are different ways to run a Dojo, but this information has 
two types of Dojo, and rules, so it will be a good starting point that 
we can mix with other people's experience.

For now we've got the space, and it looks like we've got the interest, 
but we haven't got a challenge, and if we try to hold this more often 
challenges.

For me, I'd like to try a Randori style Dojo.

Types of Dojo's
--------------- 
 

 
 

There are two type of Coding Dojo meetings. The first is called Kata 
 

which is a rehearsed choreography of developing a solution for a given 
 

problem. For example someone presents a challenge of implementing a 
 

simple thread application. A member presents a solution in Java and 
 

proceeds to develop it during the session. She or he will have 
 

rehearsed the solution prior to the meeting, but will do all coding 
 

for the solution at the meeting. A previous solution is not imported 
 

into thesession and explained. The presenter actually creates the 
 

solution during the session. During the session, the group comments on 
 

the design and coding style and suggests changes to improve the 
 

solution. The session is very interactive and the group develops, with 
 

the presenter the solution they feel is the best, clearest, and 
 

simplest. There are breaks during the session for short design reviews 
 

where the group discusses the approach to solving the problem. 
 

 
 

The second style is called Randori which is an exploratory form of a 
 

kata where the whole group participates in carrying out an improvised 
 

choreography rather than following a rehearsed sequence of steps. Each 
 

member of the group takes a turn at the keyboard, adding to the 
 

code. For example, if there are six participants, each may have a 
 

seven minute turn as the developer. When the time is up, the co-pilot 
 

who was the other person in the pair programming team takes over as 
 

the pilot and a new co-pilot joins in. 
 

 
 

Rules of Dojo
------------- 
 

 
 

The rules and sample session agenda presented here are preliminary and 
 

will be changed based on the experience gathered from previous 
 

sessions.

   * There is a coding challenge that is announced beforehand. 
 

 
 

   * There is a room with one computer attached to video screen. 
 

 
 

   * The presenter explains the coding challenge and starts the 
 

     coding.The presenter may or may not choose to have a co-pilot. If 
 

     this is a Randori session, a co-pilot is usually assigned so that 
 

     when the switch occurs, the co-pilot takes over for the coder. 
 

 
 

   * One half of the pair is changed every 5 minutes if the session is 
 

     Randori. 
 

 
 

   * The coder should continuously explain what she or he is doing. 
 

 
 

   * The coder should stop when someone from the audience falls off the 
 

     sled (has a question about understanding what the pair is doing) 
 

     -- and only continue when that someone is back on track again. 
 

 
 

   * All coders use TDD (Test-Driven Development). All produced code 
 

     will be made publicly available using the Eclipse Common Public 
 

     License. 
 

 
 

   * The programming language to be used is announced in advance per 
 

     session.

(Coding Dojo http://web.cs.wpi.edu/~gpollice/Dojo.html#MeetingTime)

Cheers,

Todd


More information about the Python-nl mailing list