My first Coding Dojo happened right after my first contact with the Python language at college. A class mate (Dirley) that had back from Python Brasil conference where he discovered the concept of Coding Dojo and was excited to put that to practice. That was a realy fun day and probably the most important moment that started a spark on me to learn more about Python.
In the same way as that brought me to Python and after to the community, Coding Dojo can be an entry door to a lot of people to programming.
Just like on martial arts the dojo is an environment for learning and this concept must be reinforced to everyone that are participating on it.
Besides that it's an environment where we apply the concepts of Test Driven Development (e.g. TDD), Pair Programming and baby steps to solve a challenge given by the dojo master.
The challenge resolution isn't an obligation to call it as a successful dojo, the main goal is to be a fun experience to everyone.
This video illustrates briefly how it works (its in Portuguese, but you can turn on the caption auto translation):
A dojo can be done remotely, but the face-to-face one is where the magic happens.
To make a dojo you don't need much:
The flow of a coding dojo is pretty much like that:
It has cycles of 5 to 7 minutes, which can be changed, but for beginners it's recommended that the cycle don't be too big to avoid someone getting stuck at some logic and also to invite more people to go to the computer to code (I personally like it to be of 5 minutes).
The pilot is the only one who codes and can't be interrupted by the audience during a cycle, where the pair programming is happening with the co-pilot, which is the only person allowed to give opinions about the code.
The audience remains quiet until the end of each cycle. Some people like to make some quick pauses when the tests are passing to discuss something with the audience which is fine, but when the tests are failing any interaction of the audience with the pilot and co-pilot is not allowed.
On the break of each cycle both pilot and co-pilot share its toughs of what they are doing with the audience, the pilot goes back to audience, the co-pilot goes to the pilot seat and someone from the audience (preferably who not coded yet) assumes voluntarily the co-pilot seat.
That will repeat all along the dojo until the challenge being solved or the dojo time is up (something around 40 minutes to one hour and a half).
Pair Programming is a technique used at the dojo and at programming environments to improve team work and share knowledge. It is basically two people working together at a computer to solve a problem by talking about it giving opinions on the implementation, helping to remember how to do something and collaborating as team towards the solution.
Another essential technique used on a coding dojo is Test Driven Development (e.g. TDD). It is about writing tests before the real implementation, you write tests that proves your business logic first, then you write code to make it pass.
When the tests passes it's time to write more tests that covers another aspect of the business logic and so forth.
To write code using TDD can be a real challenge for beginners, people try to test the hole business logic at first to comeback to the "real coding". The problem here is that you get an awful first impression about TDD getting stuck for hours at complex tests.
That's why at a dojo we use another technique called babysteps where you break your problem at smaller pieces as possible and start to write tests for this tiny bits of logic until reach the big picture. It's easier to your co-pilot and the audience to understand where you are trying to go with the code besides, you only have 5 to 7 minutes to the next pilot assume the control.
At the end of e dojo it's a good practice to get all pros and cons about that experience and also to get suggestions about what can be done to improve the next dojo session.
All the participants gets their names at the dojo list and the code and the feedback are posted in a public repo to inspire others to make their own dojos.
To help improve the dojo experience there are some tools that I like to use:
I am a VIM user and I love to use it but, that is not a good tool to present a dojo to beginners, unless you are making a VIM dojo.
On a Python dojo I like to use for tests Python's standard library unittest in conjunction with nose test runner to keep configuration as low as possible and to use Python's batteries included feature.
To write a test with unittest you must create a class that extends
import unittest def increment(x): return x + 1 class MyTest(unittest.TestCase): def test_increment(self): self.assertEqual(increment(3), 4)
The example above creates a test that tests a function called
increment checking if we call the function passing
3 as parameter we will receive
4 as result.
To run de tests with nose we call:
$ nosetests file.py
It will look into the file for classes that extends
unittest.TestCase and will run all of its methods that have
test prefix automatically.
To keep everyone aware about if the tests are passing we will need to run the test command at each change to the code but, we can improve that and run the tests automatically and with a good visual feedback using a tests semaphore called dose created by Danilo Bellini:
It works with python and another languages too.
To run our tests with nose just call:
$ dose nosetests file.py
At the dojo the most important thing is to learn and have fun learning, this was just some tips by my experience at Coding Dojos. Feel free to adapt, create and subvert everything that was written here and go back to tell me what was your experience, things that worked, things that not much and so forth at the comments bellow.
If you want some reference of dojo I have some but they are in Portuguese but with some help with google translator you can get along: