Archive for London

New place, new time, same great Dojo

Last night, the London Python Dojo were the guests of Mendeley on the Clerkenwell Road. I was pleased to discover while chatting over the pizza and beer that I wasn’t the only one to have wandered round the area a few times before hitting on the right spot. Although I had a map of some sort, I’d forgotten just how cluttered central London is: how many passageways, tucked-away building and unlabelled streets.

But it was worth it. Mendeley have larger offices than our usual host, Fry-IT. And while there were slightly fewer of us than normal (low 20s as opposed to the usual high 20s) it was still great to have a bit of breathing space. Thanks very much to the guys at Mendeley for hosting us (and providing pizza, drinks & snacks).

Jonathan Hartley was making his debut as compere and managed very effectively. Well… fairly effectively. (I shouldn’t laugh: it’s my turn next month). He’d lined up three “lightning” talks to kick off with. First up was Ian — who’d arranged for us to use the place. He explained what Mendeley does (a sort of social network for research students) and how they use Python (mostly as a scripting API) and demo-ed some fairly nifty visualisations and tools which people had built on top of their product. Jonathan himself spoke last to ask for help with a Django concurrency issue. Which he promptly got. In between was Robert Rees who showed-and-told very effectively the recently-added Heroku support for Python. This enlarged into a wider discussion of Heroku itself and of its competitors in the Django/Python world.

Then the Dojo itself. As usual, we had a whiteboard available beforehand for people to propose ideas which were then voted on. The Roman Numeral Calculator remained top of the list of unchosen ideas, but the surprising winner was Robert’s suggestion of an ASCII Art Streetfighter clone. (Chosen only after a second round of voting with a Multiple Transferrable Vote). Once this was settled, it was a simple matter of dividing into teams and hitting the editor.

Or almost. We initially failed to be able to count up to 5 in order to divide into teams. Having finally achieved this intellectual feat, we encountered the opposite problem to the one we normally face at Fry IT. There, the office is so small that you’re squeezing into space. At Mendeley, there’s so much space that you’re wandering around for ages trying to find the best spot. And then you’ve got to find the WiFi (which Ian had considerately explained about). And then you’ve got to manually set your DNS Servers to something (as the DHCP wasn’t handing out DNS). Slightly geekily, the WiFi password is mathematical making it easy to remember but still quite long.

And then, in our case, you had to find the Pygame curses emulation which someone knows exists but can’t quite remember the name of. Having got there (with about 20 minutes left now to do the actual coding) you basically scramble your way through a stunted version of Streetfighter (whatever that is; I have no idea), getting a basic solution on which you layer colour and fonts in the manner of lipstick and pigs :)

Finally, the endgame; and it’s the usual hilarious collection of imaginative approaches, stylishly-designed code, and desperate hackery. We saw: elegant ASCII art; flying bullets; gratuitous use of decorators; and many entertaining attempts to achieve an equilibrium between using classy and best-practice code and actually coming up with a solution within the timeframe!

I don’t know where we’ll be next month, but stay tuned to the python-uk list where stuff is announced.

2nd London Python Dojo & TDD

The 2nd London Python Dojo took place last night, space & food again courtesy of Fry-IT. The format was pretty much the same with the difference that the task was more of a program-y one and less of an API-y one. Which had the result that the audience was far more engaged (read: lots of opinionated backseat drivers) than on the previous week. It was still fun and the proposal that we essentially carry on with the same problem domain (a noughts & crosses game) next time was fairly well received.

What interested me a little more was the differences of approach among the developers present, both those up-front and those in the cheap seats. As I touched on last week, a Test-Driven Development technique was assumed (at least by the organisers). Now, as far as I can tell, while this is a perfectly valid approach to development, it isn’t of the essence of Dojo — ie you don’t need to do TDD for a Dojo to work. The point of a Dojo is rather to code and learn in front of others. Neither does it need to involve pair programming per se.

Now my point is not that I disagree with these techniques, altho’ I’m happily not using them myself in my every day life, but rather that a certain amount of the “suggestions” from the body of the audience was centred on their use. One or two of the coders were clearly not accustomed to working that way, or even aware that you could perhaps, and my own feeling is that this should be perfectly permissible. I’m not saying that anyone was booed off stage for launching in without a test, but there were several strong voices of encouragement in the crowd pointing out that a failing test had not been written (or any test, for that matter) as though True Development were impossible without one!

FWIW, my view on Test-Driven Development is rather like my view on Object-Oriented Development: that it’s an arrow one should certainly have in one’s quiver but that it isn’t always applicable. I realise that the comparison is not the most apt, but go with it for now. I appreciate that the people who were coding were not necessarily in their element and that I may not have been seeing TDD at its best, but there were not a few moments when I felt that a test was being written simply because it should be, according to the Mantra, without any thought to the program, design, goals, structures etc. At one point it was suggested that a particular function should return a string rather than print it to the screen as it would be easier to form a test. Now my view is that if a function needs to print a string then it needs to print a string. The *test* shouldn’t be driving the needs of your program: the requirements should be doing that. (In that case, it could well have been a pragmatic choice since the alternative would presumably have been to construct a mocked sys.stdout but still…).

As I say, I’m sure I wasn’t seeing TDD at its best and brightest. I would genuinely welcome a Masterclass Dojo (or whatever they’re called) where someone walks through a test-driven development to show how it might be done. As it was, I felt that the need to invent a test for something before you did anything about it left you seeing only the trees and failing to get a grasp of the wider wood. My 2.5d-worth.

London Python Code Dojo last night

Went to the advertised London Python Code Dojo last night. Not quite sure what to expect (altho’ Nicholas Tollervey, the front man, had done a readable write-up beforehand). It was great. About 30 people, some faces familiar to me from previous London Python meetups, others not. Beer & Pizza kindly supplied by the hosts, Fry-IT.

Altho’ a few people had attended other code dojos before, most of us were first-timers so there was an amount of feeling-the-way going on. Nicholas hooked his Mac up to a projector (with *both* kinds of editor available :) ) and people came up in pairs to code — pilot and co-pilot — for 10 minutes before handing over to a new co-pilot with the old co-pilot taking over the controls. The target app was a GraphViz graph of Twitter contacts, so the first 5 minutes was spent simply trying to set up a Twitter account with a name and email address which had not already been used!

Altho’ there were small issues — people using an unfamiliar environment, keyboard, editor etc — the 10 minute turnaround on each pair created a dynamism which kept the thing active. There is, apparently, an alternative approach where one guy stands at the front and talks through what he’s doing, but that doesn’t seem to me to have the same appeal.

There were several suggestions at the end as to what might be improved. The scaffolding code which Nicholas had already put in place to generate graphs given an edge-list was ideal since it made it feasible to actually create a solution within the 2 hours we were working. But some people thought more time was spent learning the Twitter API than was really useful. For my part I didn’t have a problem with that: it’s all part of the learning experience. The size of the group meant that people at the back of the room were less engaged. There were suggestions of two parallel groups competing, but I think it was decided to hold off till later on that.

What was interesting from my perspective was the way that different people approached the — admittedly loosely-specified — problem. There was an unspoken assumption that test-driven development was de rigueur, a discipline I don’t entirely share but am happy to go along with. What surprised me the most was that no-one fired up the interpreter to see what the Twitter API was doing. There were tests being written without (I think) knowing what the API was going to return. I’d just have started the interpreter, logged on, and retrieved a list of friends — or whatever — to see what I was getting back. But everyone’s different.

I don’t know if this is the idea, but one thing you do get is a kind of audience participation effect. Altho’ you have the pilot & co-pilot up front, verbalising their thought processes, you have a room full of back-seat drivers all giving advice at different times. Vastly entertaining.

Just a couple of suggestions from the point of view of a big group: maybe have the pilot / co-pilot hooked up to head-mics pushed through speakers; and have a slave laptop at the far end, projecting a VNC Viewer of the master onto a nearer screen/wall so people can see/hear what’s going on.

[I was the final co-pilot, for those who don’t know me :) ]

Disabled badges

I work in Camden Town in the north of London, a mecca for youngsters shopping for the more outlandish kinds of outfit, and one of the most difficult places in the known universe to park in. Jamestown Road, just off the Camden High Street, is a popular spot for parking with a good view of the pay-and-display machine. Of course, if you’re entitled to a disabled person’s badge then you or your driver can park without paying (within certain restrictions). Now there’s obviously nothing to prevent someone who’s disabled in some way from being the owner of a fast and expensive sports car. But when you see three or four of them a day parked along the road, proudly sporting their Blue Badge, you stop and wonder…

… and sure enough, there are periodic newspaper reports of a thriving black market in Blue Badges. Obviously, there are greater threats to humanity, but you do wonder whether the veritable swarm of traffic wardens which Camden Borough appears to employ for no better purpose than to maximise their income from parking revenues might not be employed to better effect by standing by Blue Badged cars and waiting with a video camera for the entirely able-bodied driver to show up!


Warning: this post will mean nothing to you unless you live or have lived in London. It may — and this is entirely the point — still mean nothing to you even if you do!

It boggles me how many people — including, apparently, professional sign-writers — still think that London is divided into two telephone codes: 0207 and 0208. Having lived through the 01/081/0181/020 debacle, I entirely understand where the misunderstanding comes from. But it’s been nearly ten years. And there are otherwise intelligent people of my acquaintance who refuse to accept my explanation that all London numbers are eight digits long and have the exchange 020.