Moderate Realism

(Yes, that is a deliberately ambiguous title offering two possible interpretations: as a description of what the programming challenge was at last night’s Dojo; or as an imperative to be awed at the might and wonder that is the London Python Dojo. You choose).

Last night was the first time I’ve actually run the London Dojo. For the two and more years since its inception, Nicholas Tollervey (@ntoll to his Twitter friends & acquaintances) has indefatigably turned up every first Thursday to clear up the Fry-IT offices, order the pizza, buy the beer, put up signs, leave out sticky labels, request free books from O’Reilly and then drum up support, keep everyone happy and actually run the show, finishing off by organising everyone to clear up, move chairs, dump the rubbish outside, and finally catch the last train home to Sticksville, Northants. where his wife and children have long ago fallen asleep over their sheet music, having gone da Capo al Segno one time too many waiting for him to return home.

A few months ago, Nicholas asked for volunteers to help out, and a small group of us got together to share the burden. Since then, Bruce, Jonathan, Tom and finally I have taken a turn at organising. And of course it’s not until you have to do it yourself that you realise how much work is involved… I was fortunate because Gautier (who actually works there) and Nicholas himself were both at Fry-IT for the day and were able to do some of the less proximate preparation, including ordering a dozen pizzas and buying three dozen bottles of beer. I was able to make a small contribution in the shape of a pack of sticky labels.

The Dojo itself was very slightly quieter than usual: just under 20 rather than just under 30. That’s not a bad thing in Fry’s offices which are not huge. There was a bit of an introduce-yourself session (which was made even more primary-school-like by the presence of big sticky labels on everyone’s chest with their names or cognomens). And then we had a lightning talk from Martin who has a sort of cut-down Nagios for app developers. (I hope I haven’t done it an injustice). And then a surprisingly straightforward vote on the evening’s programming challenge which gave us… Boggle. (Word game; 8×8 grid of random letters; form words by moving like a chess king).

Four teams; four solutions, all more or less different. Only one team ended up with a working solution at the end of 90 minutes (and they appeared to be optimising by removing all vertical whitespace; or maybe that was an aesthetic choice - who knows?). Our team had visible activity (which is more than Team 1 managed!) but no solution. It’s up to each team how they want to manage their collaboration. We’d gone for the split-team approach, dividing the problem into its eminently decoupled parts: a mechanism to read in a dictionary of words and provide efficient searchability (using a Trie, in case you’re interested); and a structure to hold the board (a dictionary, keyed on coordinates), generate the letters into the grid, and search for all possible words, relying on the dictionary code to indicate success, failure, partial success, or success with more possibilities.

The tweets were still flying this morning as people tried to tweak their solution (or, indeed, get it to work at all) on the train, on their phone or at home overnight. A friend of mine who’s a C++ coder came along mainly because I’d talked so much about the Dojo. He’s not really into Python - in fact he’s not really a programmer: he does medical image analysis. But he enjoyed the atmosphere and made a few small suggestions before simply sitting back and watching the teams get to work.

Look out for the next Dojo at the beginning of January. It’ll be announced on the python-uk mailing list and we’ll tweet about it when we’ve fixed a date.

UPDATE Dirk’s added a blog post of his own:
http://elazungu.wordpress.com/2011/12/02/solving-boggle-with-python/

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.

Well, the West Midlands Python team have been busy… (at least, I assume it’s them). This year’s UK Python conference is taking place over the weekend of the 24th - 25th September in Coventry. (Which is fairly central in England, for those of you reading this in a foreign language). I’ve just booked my place and a night in the hotel. I hope can rustle up a talk or workshop to make it even more worthwhile.

It looks to be a bit more casually organised than other conferences and I’m very much hoping that the always friendly atmosphere will be even more friendly… See you there, I hope!

I blogged previously that I was having a look at the Python Testing Cookbook courtesy of the eager marketeers at Packt Publishing. Well I’ve finished reading it — in installments on the Tube — and I think I’ve come to a conclusion.

The short version is: I’m not mad about the layout; it’s not entirely what I expected from a Cookbook; but I think it does what it does very well.

Since I’m overall positive, I’ll just pick up on the very slight negatives first. In a previous Packt review I commented (adversely) on the style of the layout and so on, and I’m afraid that it hasn’t really changed. Obviously, this is somewhat subjective, but I can’t be the only person who’s subconsciously affected by the font and layout choice. (Bear in mind that I was reading it via PDF which may make a difference). To be clear: it’s not awful; it’s not even bad; it’s just suboptimal.

The other slight negative is hardly a negative at all: that the “recipes” in this cookbook are far broader — in some cases, chapter-length — than I’d expected. Subjective expectation, to be sure. But I was a very little bit surprised.

Ok, that’s the downsides. Now the upsides:

* Nice division of chapters
* The right pacing
* Pretty much one example used throughout
* “Why didn’t you do this?” question sections
* Good re-use or alternative use of previous examples or approaches
* Interesting spread and combination of toolsets

The chapter divisions are: unittest, nose, doctest, BDD, UAT, CI, coverage, load-testing, good habits. In broad terms, each chapter builds on previous ones, but thanks to the reuse of the a simple shopping cart example, repeated in nearly every chapter, you can take a chapter on its own without too much difficulty. In addition, different chapters sometimes offer alternative approaches to the same problem when it makes sense to illustrate one point rather than another. One chapter, for example, walks you through creating a nose plugin to show how to do it; the next chapter introduces you to a ready-made one since the focus of that chapter is not nose plugins.

And that brings me to the variety of toolkits & modules mentioned throughout the text. This is not a book which simply uses stdlib code to perform various tasks (which I had rather thought it might be when I started). It introduces the ideas mentioned in the paragraph above. And puts forward Python modules (such as nose or mock) or external tools (such as Hudson / Jenkins or TeamCity) as best-of-breed or useful tools.

One final point which really put the icing on the cake is the occasional introduction of pull-out sections answering the very question which was occurring to me as a reader: “Why didn’t you use this technique here?” or “How is this different from that?”. Perhaps it’s just me, but I find this smoothes my progress through a book considerably which otherwise would be (mentally) jarred by my wondering “Now why did he do that?”.

I can’t but recommend this book. There’s a sample chapter here if you want to have sniff. As a final note, it’s very slightly unfortunate that the timing of its production precluded the author from picking up on Michael Foord’s magnificent work in producing unittest2 / unittest for 2.7 & 3.2. Perhaps there’s a “missing chapter” opportunity in there for someone…

Thanks to the energetic folks in the Packt Publishing Marketing department, I’m currently looking at the Python Testing Cookbook with Python Web Development waiting in the wings. The copies I have are PDFs which are never my favourite, so I end up printing chunks out to read on the train or elsewhere, but it’s great to get to read other people’s insights and ideas. I’m about halfway through PTC so look out for a review soonish.