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.

The 5th London Python Dojo

After several mishaps trying to get to the last few dojo’s having only made the very first I arrived cold but safe to Fry-IT‘s office and in time for beer and pizza.  Showed off the N900 to anyone who would listen (I really do love that phone can you tell?).

People were invited to add ideas to a whiteboard but I couldn’t think of anything specific myself.  I did think it would have been good to somehow use the recently announced London Datastore but the website’s pagination didn’t appear to be working to view the full list of data packages available. We voted on the ideas, the winner being a text based adventure game that we plan to use as a basis for future dojo’s.  I was a bit sceptical at first but what a great idea it turned out to be!

Dave Kirby then gave a talk on CRC cards prior to the dojo proper.  I like the idea of having a small lightening talk before the dojo especially if it’s to suggest something to be taken and attempted in the dojo itself.  Maybe we could have been encouraged more to use the technique ourselves especially if we had been split into groups with at least one member being one of those that had admitted using them previously.

Then we were split into 5 teams, our team having five members. Something I didn’t think about at the time but should have been our first task was naming our team, so for posterity I’ll name us The Octopodes.

We sat down at first and started hashing a few ideas such as using the Cmd module from the python standard library as the main game engine.  We made a half hearted attempt to use the CRC cards but we only came up with one class which was Room. We split into a two man creative team and a 3 man dev team with the plan of changing places at regular intervals.  We didn’t quite manage this as we lost track of time but everybody did manage to be on both the dev and creative teams even if they didn’t get to drive in both.

After an hour, time was called and we finished up ready to watch the other teams present.  In fact we added a few bits of polish as the other teams were presenting (shh don’t tell anyone).  Our game plot was a roughtly Jules Verne-esque sea voyage complete with giant octopus allowing you to ‘look’ and ‘go’ as Cmd commands with the default action being to go.  The game ended with the command ‘win’ which at some point someone had tacked on a space invaders pygame. Completely random, didn’t have a clue about it but got the biggest laugh of the night when we presented.

Our code:

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

Notable points of the various solutions:

• Two of the other teams also used the Cmd module as their game engine
• One used a custom file format to describe their game environment whereas we just used a standard Python dict
• One team (or were there more) practised TDD (we decided not to, due to time constraints)
• One team was unable to present much due problems caused by an early design decision
• Only one include a space invaders game (and giant octopus)

After the presentations we discussed the format for the next dojo which we decided to have as a traditional randori dojo to integrate all of the solutions into a common base to use in the next dojo or if we have time later that same evening.  Hopefully we’ll integrate as one big group and then use the many small teams method for the next step which will be adding objects and interactions as I really enjoyed the slight competitive angle.  Smaller teams definitely give you more opportunity of a voice for those of us who don’t quite have the presence of Bruce.

I was a little gutted not to win the Google App Engine O’Reilly book as it would have come in handy for my current project, a post on that will be forthcoming once I’ve got it up and working.

We then moved on to the Dogget for an ale or two where Bruce cajoled me into announcing the next London #pyssup which will be on Wednesday 20th January at the Ye Olde Cheshire Cheese on Fleet Street.