Moderate Realism

There were sounds of fear and screaming courtesy of Team 1 at the Dojo last night, hosted as ever at Fry IT offices in Southwark — an area whose eclectic mixture of shiningly-new and uncertainly-old architecture I continue to enjoy. We kicked off with the idea, promoted by Bruce (aka @otfrom), of producing the basis of a game to which other London-based Dojos could submit bots. Nicholas (@ntoll) had tweaked an existing PyGame-based game and proposed specific “Dojo Quests” for each team to work on independently.

Which was fine, except for two things. the sheer number of people — just below 30, a record I think, and leaving people perched on tables or even on the floor for want of chairs; and the relative complexity of the code. Very much to its credit, the modules were well-structured, consistently named and fairly well laid-out. But there were layers of complexity in there which meant that, in less than 90 minutes, certain of the teams were struggling to understand enough to start the task, let alone complete it. Including ours.

Fortunately — and with the help of Rene (@renedudfield) — most teams managed to get at least something to show in the “show & tell” session at the end. I think Nicholas was relieved that it came off as well as it did: we’d had a previous bad experience in trying to get to grips with an existing library in the course of a Dojo. Team 1’s Dojo Quest involved adding music & sound effects, which they did with gusto. The end result was a character wandering around a rural landscape with randomly-generated screams and cries of fear filling the air. Never has a walk in a forest been so terrifying.

In addition to helping out generally, Rene also generously provided a bunch of game controllers. And O’Reilly continued their “sponsorship” of the Dojo by providing their XMPP title for our customary raffle… which I won! (The idea is to use XMPP to connect these hypothetical Dojo-generated gamebots).

It was great to see so many people, although it does pretty much illustrate the physical limitations of our venue. I enjoyed it as always, and people I chatted to afterwards did, too. Looking forward to next month.

UPDATE: Forgot to mention that we *really* kicked off with a truly lightning talk from Tom (@tomviner) showcasing Michael Foord’s recent e and oo modules.

We had a blast at the London Python Dojo last night. Food, drink, and location generously provided as ever by Fry-IT (may all their contracts come in on time and under budget!) and a book for the raffle from O’Reilly (may all their titles remain in demand). While the wining and dining (or was that whining and dinning?) was in progress, Nicholas had set up a whiteboard for what-to-do suggestions. When it came to vote, some ideas were thought good but impractical for one evening, and the winner was the original suggestion: Cells.

Well I had misgivings as to whether we could grasp the codebase and get a workable solution in place within an hour and a bit, but it was great. The idea is — within the rules of the game — to pit your agents against the other teams’, trying for a winning strategy combining eating, attacking, moving, and replicating, each of which need, lose or gain energy according to certain rules. The agents can also message others on the same team to communicate, eg, the location of food or enemies. We had four teams, some with agents based on the sample code, others with from-scratch algorithms.

The clear winners were the “white” agents — Team 2 — who’d based their strategy on one of the supplied examples plus an expansion phase which kicked in only once a certain amount of time had passed and involved replicating like mad. On Team 1, we’d gone for a pacifist approach, with some of our agents as “Buddhas”, staying still and eating, the rest “Hungry Ghosts”, eating, moving and replicating. None of them attacked. FWIW, we got wiped out pretty quickly, although that did depend on how far you started from the voracious white team.

The other teams had differing strategies: explorers and eaters; or tribal warfare — which looked hilarious on-screen, as all the yellows suddenly went into warfare mode, sending each other the location of nearby enemies and flocking towards them.

Next Dojo’s in September, but EuroPython’s later this month and I’m sure there’ll be quite a few us there.

Much fun and laughter at the Dojo last night (helped along, as always, by Fry-IT’s generous sponsorship of location, beer & pizza). Despite the name, this month’s was more of a talks session, picking up threads from previous Dojos and a couple of other random things. Went on a bit long as a result, but good fun nonetheless.

I kicked off with a talk about Pyro, which has recently announced a major version alpha release with versions for Python 2.x and 3.x. We’d discussed the possibility of enhancing our desultory Adventure Game efforts with multiplayerness and I’d volunteered to show how Pyro might be used for the purpose. Of course, the last-minute neatening-up and bugfixes I’d made before leaving the office didn’t make it onto my laptop, leaving me scrambling to correct code with minutes to spare. (Let this be a lesson to you: hg commit && hg push). Although I’d prepared a fairly tight series of examples and didn’t hang around, I still ran for 40 minutes with a few questions thrown in. (Coincidentally, as I sat down again, I had an email from Irmen de Jong, the author of Pyro, asking if I’d tried the new Pyro 4.x on Python 3.x yet. As it happens, I’d intended to do a simple comparison as part of my presentation, but I ran out of time).

Dave Kirby followed from the same angle, with a presentation about Twisted. *His* talk was hampered by laptop-to-projector issues which gave us a green screen, then a red screen, then as we were preparing for a blue screen it went green-red before Gaultier kicked the projector and we went back to white. I certainly came out understanding more about Twisted (which isn’t saying much, admittedly) and I can see why people enthuse about it so much. I’m also aware, from comments on the main Python mailing lists, that the Twisted guys have done a lot of work to file away the rough edges which result from getting low-level cross-platform networking code running.

I think Tom Dunham’s presentation was the best of the night (altho’ I’d had a glass of wine by then, which probably helped). A few dojos ago, one team had used Divmod’s Reverend implementation of a Bayesian classifier as a way to have more flexible parsing / analysis of the user input. It had worked at first, but had soon fallen apart in spite of some ingenious (read: desperate) attempts to “trick” the classifier into giving the desired result. Tom had gone away to investigate how we’d misunderstood the way in which such a classifier works. He came back with a presentation which skipped the maths (fortunately for most of us, I suspect!) and focused on the internals of the classifier, showing how our approach was hopelessly overloading the classification pools to the point where it would classify “the moon is cheese” and “the” in exactly the same way.

Jon Ribbens followed with a demo of his — now quite mature — jon.py web framework, built before almost all the other ones in common use today but still offering remarkable value for (no) money.

In spite of the late hour (gone 10pm before he started) Nicholas Tollervey, our brave organiser, gave a Lightning talk on FluidBD, which answered at least some of the questions we had about it (such as: what is it?), although it left me with the impression that it could be a Brave New World or a Interesting Curiosity.

Next time we’ll probably go back into Dojo mode proper, and with a new project to replace our slightly tired Adventure Game.

Just saw a tweet from Rene saying that he’d enjoyed last night’s Dojo at Fry-IT. I did, too, and for much the same reasons: the small group format makes for a more engaged, friendlier evening. We were carrying on with our not-so-spectacular text adventure game built in previous weeks. Altho’ there had been discussion about different groups working on separate pieces which would then come together, I think our eventual choice for all groups to work on the same thing was the right one. As Nicholas — Dojo organiser and former teacher :) — pointed out (correctly): if you’ve all been working on the same piece of code and the same structures, it’s much easier to follow the show-and-tell at the end.

In the spirit of previous Dojos, which had been very much led by TDD-aware people, I’d got all test-y in our group and we spent way more time in generating meaningful tests than launching into functional code. (As well as reworking the crufty parser which everyone had to cope with). As far as I can tell, *none* of the other groups were testing. Just goes to show… testing really does slow you down for no nett gain ;)

It was definitely interesting to see the different styles & approaches adopted by the different groups. As well as their attitude to the source material: most were “respectful” of the descriptions and objects supplied (by Bruce & John) but others simply hacked them about to suit their requirements. And one off-the-wall group simply made up their own thing, generating random monsters doing random things. As far as I could tell.

Although this format worked well, I think varying from time to time is good — as we have been doing — not least because different approaches suit different people and we want people to keep coming! Thanks as always to Nicholas and Fry-IT for organising / hosting / feeding. Pictures are up here. (Apparently that site’s Django driven, in case it makes you any more likely to click on the link…)

My first Dojo of 2010 yesterday, as I missed the January one (which is a shame as it sounded like fun). This was a return to the conventional Dojo style with pair-programming at the front, the task being to merge the Adventure Game efforts from the previous month’s team-by-team effort. But first, a commercial break… Jonathan Hartley advertised the upcoming PyWeek competition and demonstrated his team’s previous effort as well as the amusingly literal Murder of Crows entry.

Meanwhile, back at the Dojo… Nicholas started off partly to set things up for people (like me, his co-pilot) who hadn’t been there the month before. As we moved through the programming pairs, we did manage to get a working codeset together by merging the location-parsing code from one team with the cmd-based loop from another. But it was clear that things were moving slowly and that the audience was somewhat disengaged…

So we finished off with a broad discussion of ways ahead, of what might work better, and of whether the artificial nature of the Dojo setting meant that people couldn’t “show off”, so to speak, their natural coding style — and ability. Michael G and others made a few cogent suggestions to the effect that smaller teams would work better but with some kind of DVCS (git seemed to be the front-runner) to assist the teams in collaborating. And it seemed that at least one team should be creatives, rather than coders.

I enjoyed it, as ever, but it _is_ difficult to keep 20+ people in a medium-sized room totally engaged. Even with the best will in the world, it’s hard to read code on a screen from some distance back. This was one of the reasons why a team-based approach met with broad approval. Also it is a little dispiriting when you’re doing your best up front but half your “audience” is otherwise engaged.

The point about how “natural” you should be in the Dojo was interesting. Everyone has a different way of coding, of approaching a problem, of looking for information and so on. Dave[*], the last pilot, mentioned that he’d normally take much longer sizing a problem up but that having a time limit forced him into action sooner. But you’re up there with a limit of 10 minutes, probably on someone else’s machine, maybe on an “alien” operating system. You’re fumbling with running up a command prompt; you’re not sure how to bring up the Python docs; the keyboard shortcuts which your fingers remember don’t work — or worse, do something else entirely! We did discuss each person bringing up his own laptop, although that has obvious drawbacks of getting the projector to switch smoothly and so on. It was out of this discussion that the move towards a team-based approach next time arose.

TJG

[*] Dave, incidentally, was the programmer of the BBC version of the Graphics Adventure Creator — did you know that?