Archive for General

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.

Python 3: print or print()

There’s a thread over on the Python list which started a week ago as I write and is still running. The OP titled his post the provocative “I strongly dislike Python 3″ but what it really comes down to is “I strongly dislike print()”. Various people have come in on both sides of this well-worn argument.

Now, I don’t really mind futile discussions, and this clearly is one: Python 3 isn’t going to switch back, no matter how many people weigh in on the print-as-statement side. I’m in that camp myself, and when the matter was first up for discussion I had a to-and-fro with Alex Martelli on the subject which I backed away from fairly quickly. I continue to enjoy and benefit from Python regardless; I contribute to its development very slightly and very rarely; and even were I the most prolific contributor on the planet, I don’t believe that would give me any particular right to dictate design decisions of this sort. You take the rough with the smooth.

I think the side of the discussion which irks me the most is from those who are defending the print-as-function decision. Clearly there are cogent and persuasive reasons why print should be / should have been a function. No-one’s pretending that this was a decision taken randomly and for the sake of change. Or even for the sake of a foolish consistency. But if someone’s working practice involves using print a lot — perhaps in the interpreter rather than in a code editor — then the switch to the function version is clearly a burden. It may be more or less of a burden, but it involves having to do something which you didn’t have to do before. Being told that you should have been using logging or pdb or sys.stdout.write — all of which are valid tools to use in the proper place — doesn’t really make your life any easier.

So while Python 3 is now the default interpreter on my shortcut keys and I’m trying to write new code against 3.2, I still find it a pain to overcome the very long habit of, eg, print ad.find_user ().sAMAccountName. Obviously if Python 1.5.2 had had print () as a function originally, I wouldn’t find is so hard now. ;)

(As an aside I did wonder at first whether the American or some other non-UK keyboards had the brackets in some more convenient spot, but it doesn’t appear so…)

Poppy Day again…

It was quite a while before I realised that using Poppies to commemorate Remembrance Sunday (and the fallen of wars in general) wasn’t universal. I don’t know if it’s practised anywhere outside the UK, in fact. But here it’s pretty much the only one of the many collections-for-good-causes which has widespread appeal, partly because it’s a tradition which long precedes pretty much every other save-the-something collection. Partly, I think, because we’re all human and who can argue with collecting money for such a cause?

As it happens I haven’t seen many poppy-sellers around where I work in Camden Town. But I knew that today — Saturday before Remembrance Sunday — the local cadets would be out in force (and in fatigues) around Ealing where I live, armed with Poppies and collecting tins. And they didn’t disappoint. I am, for several reasons, not a great fan of cadets and school OTC outfits. But, at least where I live, this is pretty much the only example of seeing groups of young people on the street doing something for the good of others. The Scout movement has reinvented itself as a training scheme, as far as I can see; and in any case, it’s been years since anyone would have been seen dead on the street in a Scout uniform.

So I bought my poppy from a young man in army outfit who looked a little lonely at the side of the main Shopping Centre square. And I hope you’ll all do the same.

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 :) ]