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
_______________________________________________
Python-nl mailing list
Python-nl@python.org
http://mail.python.org/mailman/listinfo/python-nl
