gnublade

So another month another London Python code dojo.  I missed last months due to being away for work, and although what they did (refactoring the code from the previous dojo) sounds like it wouldn’t have been as good as the team based approach, I would still have like to have been there and been involved.

There were no talks this month just the usual networking/catching up over pizza and beer (thanks Fry-IT).  This month we split into teams again, 5 groups of 4/5 and one group of 2 (the creative team), this time with @ntoll attempting to split the veterans and py-curious evenly between the teams.  We agreed to all work on the same goal to add objects and interactions to the one true adventure with Bruce and Nick.

My  own team, team 2, was a group of 5 which on my suggestion based on the 1st adventure dojo, we then split into a two and a three.  Myself and Matt huddled around my wee netbook (running ubuntu if nobody had guessed).  The plan was, as with the first time, to rotate members of each group giving everybody the chance to drive.  This didn’t quite work out though as we spent far too long initially just getting the refactored version to work.  We also had issues trying to sync our code between the two groups.. this is where bzr’s mdns repository sharing would come in handy, no doubt there’ll be something like it for git but we just resorted to syncing to a usb stick.

The other team worked away on parsing the new datafile to which objects had been added.  We worked on giving locations the ability to host objects and extend the ‘look’ action so that you could get a description of the object.  When we pulled this all together which we only did fairly near the end we had conflicts due to me having changed the fileformat from dos to unix so that the shebang would work. We wasted plenty of time with this and I have no idea where the rest of the time went.

Right at the end, with only a few minutes remaining we were all asked to do a pull from upstream to get the latest changes to the datafile.  This introduced another problem as our parsing group had assumed that the datafile first contained locations and then objects, but the new file had those interspersed.  We only had seconds remaining so we weighed the idea of changing the code to remove that assumption or the simple solution of reordering the datafile, queue much yanking and pasting.

Time was called and team one got up to present, at that point a couple of us put our heads down and feverishly coded quickly adding pickup and drop actions to the game class and adding an inventory to the player.  We tested and it worked, just as we were called up to present.  Sorry to team #1 as I didn’t see or hear a single part of their demonstration which apparently had the most complete implementation.

Glad to say that my netbook hooked up to the projector without any problems and the presentation went without a hitch.

The code (yes I know it has bugs) is here: 

http://github.com/ntoll/code-dojo/tree/master/adventure/week3/team2/

Some thoughts:

• This time the splitting into groups didn’t work well for us.
• We spent far too long discussing how to implement actions and data structures when the correct answer is the-simplest-thing-that-works.
• I hogged the driving seat in my group (sorry about that), next time I’ll take the back seat after all the dojo should be more about the newcomers.
• If we’re starting from a single codebase, we should make sure it runs out of the box cross-platform.
• Each group being able to push to a single repository would be handy and then the code would be available immediately.

It’s suggested that next time we chose one codebase to work from, and maybe add aspects from others (monsters from the last team to present).  A couple of variations on this might be for some people to offer to refactor the code ahead of the next dojo using just code as it is, not adding any new functionality, or maybe we could just pick up from where we left off this time, each team being assigned a solution at random.

I’m not a fan of the custom datafile format as it means that we have to parse the file before processing it, whereas if we had stuck with a standard format such as the game data stored as a Python dict we’d get the parsing for free.  Alternatively parsing might be an interesting problem for the dojo to solve, but I think Pyparsing would make light work of it.  Also I think the Cmd module is underrated and would like to continue using it.

Afterwards some of the hardcore headed to the Dogget for debrief over bevvies. For anyone as geek about their beer as me.. they had Brew Dog – Trashy Blonde on tap (Brew Dog are my favourite brewery, not necessarily for the quality of the beer though).

All in all, another good dojo.  Hopefully we’ll see more of the same faces at the next #pyssup.

Share this on

Tags: dojo, geek, london, Python

This entry was posted on Friday, March 5th, 2010 at 2:17 pm and is filed under Python. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.