At Python Glasgow we organise Python Coding Dojos. The format we follow is based on the London Python Dojo. This document is an attempt to outline that process so we can follow it each time and evolve it as required.
For the venue, this is the list of ideal requirements. The more of these we have the smoother things will go, however, only the first two are really essential.
- Plenty of chairs and tables for laptops and developers to huddle round.
- Lots of power sockets and possibly extensions.
- WiFi (less of a requirement as people can easily use 3G/4G).
- A projector or large screen to present results.
- Food and drink - provided by the host or a sponsor.
Some things that need to be done in the run up to a dojo.
- Announce the Dojo three or four weeks in advance, on all the relevant mailing lists, Twitter etc.
- Ticket the event - probably free tickets on Eventbrite.
- A week before, send an email round to get people thinking about ideas. Potentially collect ideas on a wiki at this point.
This is a rough playbook for the event, in part to help me remember to follow each step.
- On a whiteboard or flip pad start recording ideas. Get people to add Dojo ideas as everyone mingles a bit, drinks and eats.
- After most people have arrived, gather everyone together and do a round the room introductions. Who you are, what you do etc.
- Start the voting process - an initial show of hands for each idea, everyone can vote as many times as they like. Take the top ideas (2 to 4) depending how the distribution looks. Then another show of hands, this time you can only vote once. If there is a tie, repeat the process.
- Divide the room into groups of around 4 people. Make sure there is an experienced Python developer in each team - so take a volunteer to "lead" each team and then round robin around the room to assign everyone else to teams.
- Give everyone one to two hours to then go and work on the voted problem in their teams. This will depend when you started and how long you have in the venue.
- Towards the end, go round and let everyone know how much time is left. A warning to wrap things up.
- Take each team one at a time and have them present their code. Giving a briefly giving a demo and discussing their approach to the problem.
Try to collect the code from everyone at the Dojo on GitHub. This typically requires badgering people until they remember.
Some common questions come up when the Dojo is promoted. This is an attempt to cover those that have come up so far.
Essentially, our interpretation is, that it is a place for developers to practice and learn in groups while solving fun or interesting problems in a welcoming environment. Hopefully all participants should have fun, socialise with other developers, learn something and be offered some free drinks and pizza.
Any! It's a great way to learn as we make sure that all teams in the Dojo have at least one experienced Python developer. Therefore you can learn from what is being produced and contribute ideas or suggestions about how you might tackle the problem.
Dojo problems are typically algorithmic, don't require lots of set-up and don't require knowledge of a specific library. There are however exceptions to this.
So, for example - some good examples are:
- A maze generator
- Game of life
- Roman Numerals Calculator
Some bad examples may be:
- Doing X with Twitter or another API. Getting setup and learning API's can be a pain and takes up lots of the time.
- Using a public set of data to do X. You require the internet to be stable/ fast and most teams will spend half the time downloading and becoming familiar with the data.