Monday, January 17, 2011

JQuery 1.5 promises a better future.

One of the new features of the unreleased JQuery 1.5 is a new $.ajax module.

Apart from many bug fixes, the most interesting, and useful part for me is that it now uses promises. Those familiar with python and twisted, or the JavaScript library mockikit, Dojo Deferred, or java.util.concurrent.Future might know these as deferreds or futures. jQuery is using promises, and not futures. They are similar but slightly different. It's a very commonly used technique in concurrency libraries now - so it is good that jQuery has hopped on board.

Since jQuery always returns a promise, you can now add callbacks even after you have done the call... or even change the callback later.
jQuery.getJSON( url ).error( errorCallback )

Pluggable ajax lets us test more easily

The other great thing(from a testing perspective) is that jQuery now allows you to use plug in mock implementations. This lets you make a fake ajax implementation for your unit tests more easily.

This pluggable architecture could also lead to people making other plugins that act the same as the ajax interface. Which could come in handy if you had a strange requirement, or you want to develop an alternative communication method - and be able to reuse much of the jQuery code.

Subclassing jQuery object

Another new area where jQuery helps extensibility, is the ability to subclass the jQuery object, and override methods - without it breaking the public interface to jQuery.

This is useful if you want to make a plugin that changes a few parts of jQuery for it's own uses, and not be worried that it will break 17 other plugins.

(function(globaljQuery, $) {
// private functions
$.fn.privateFunction = function(){ };

// overwrite an existing function without breaking other plugins
// which use the global jQuery function.
$.fn.popularExistingFunction = function(){ };

// Expose some public functions
globaljQuery.fn.myPublicFunction = function(){ };

})(jQuery, jQuery.subClass());

You can try the jQuery 1.5 beta 1 yourself if you want to have a play. I'm sure they will appreciate any bug reports.

Friday, January 14, 2011

London python dojo pygame write up.

Last night I went to the London python dojo at the Fry IT offices.

The night started with pizza, beer, and nerdy chats with everyone.

Then two lightning talks. The first by @tomviner (Tom), on some funny and useful python modules. `pip install oo && python -moo` Python goes moo (dad joke). `pip install e && python -me 1+2`

Next up was @otfrom (Bruce). He has a cunning plan to work on an engine that could be used later in a cross language dojo to display a game world. @otfrom is trying to see if other language dojos in london are interested in having a bot war tournament in the future. So far the clojure dojo, and perhaps the scala dojo are interested in participating.

@otfrom also announced the London dojos mailing list at: A group for people interested in programming dojos in london (not just python).

Then 30 of us took an open source game from, forked it and hacked on it!

I brought along a big bag of joypad controllers - 30 of them. The idea was to hand out one to each person who turned up. Unfortunately, they were two controllers joined together with one USB cable. Which meant that not everyone got a controller, but 15 people got two!

But first let's rewind to the night before... [[insert tape rewinding sound]] where @ntoll and I were discussing what to do... continue on with the xmas card demo we made last time? Or instead, hack on something a bit more complete?

The more complete game chosen is an over head dungeon crawller type game. It's not at all finished, and is a work progress one. @ntoll selected it from the thousands on It seemed to have fairly clean modular code, and be roughly what we were aiming to build.

As is usual of the london python dojos, we split up into groups. Five teams of six people this time. 'Pair programming on steroids - and not in a good way' is how the london python dojo has been described. The room was packed, and most teams split up into two groups of three, with 2-4 laptops per group - some laptops hooked up to larger screens so people a bit further away could have a look.

At the beginning we each got 'Quests', which were little tasks made up by @ntoll.

  1. Add NPC characters that walk randomly around the world
  2. Add music and sfx for particular events
  3. Allow the maps to be pre-defined rather than (as is the case) randomly generated each time.
  4. Add static objects to the game world such as gold or food that get added to the players inventory/energy/score/whatever when they bump into them...
  5. Two player mode (sharing the same keyboard or with two controllers)
  6. Menu system (Start Game, Help, Set-up, Quit)
Each group took their Quests, and got stuck into it. I had the pleasure of going around to each group to see how they were going, and to help out where I could with work arounds for pygame issues. I spent a time with most groups... but couldn't work my way into to where one group was, as they were surrounded by other people completely... and I would have had to climb over the top of people.

After coding stopped (@ntoll had to turn the lights off a few times to try and get people to stop)... the groups presented their work. It's a time for reflection and to show off what you did.

Each group managed to accomplish something. However some tasks were a bit harder than others - and they turned into reverse engineering tasks.

So by the end, we had:
  • joypad control of the main character, starting the game and exiting it.
  • A start on multiple player abstraction, from single player. With a small issue that the second player was not displayed on screen for some reason. A separate image is loaded and everything... it's just not displayed.
  • An Non Player Character (NPC), that could move and change direction (currently in two separate code bases).
  • A start on collision detection of the main character with things on the ground (like mush rooms). As this group was demoing their work, they 'lived coded' up some missing parts of the solution.
  • Music, which is different for the main menu screen and the in game music.
  • Sound effects, for different actions in the game... and some 'ambient' screams of FEAR and TERROR as the character walks through the forrest.
  • Loading and saving of maps into a text based format. Originally the maps are randomly generated, so this needed reverse engineering to figure out how that worked too.

A bloody good result really. Especially since it was code no one there had seen (except ntoll, and me a tiny bit), and the groups only had an hour and a half to hack on things, groups with people they never worked with before, using unfamiliar libraries that some hadn't even installed until the dojo (eg, pygame).

I think some people were a little frustrated with their tasks, especially some which were more of a challenge than others. But most seemed to enjoy it.

Overall I think this Dojo was about something which the organiser didn't intend. It was about quickly figuring out a code base, and modifying it. Reading, and modifying other peoples code is a great skill to master - and if nothing this Dojo gave us some experience with that, and let us see how other people do that too.

I saw some people using class browsers I hadn't seen, some using an API from the interpreter, others weilding their custom made code search scripts - to hunt down variables.

At the end of the dojos we usually decide on what we do next. We decided to continue on with the game idea in future dojos - so we can use it in a cross language dojo bot war. We also decided that 'someone' would try and merge all our bits of code together, and that @tjguk (Tim) would present an over view of the code base if he has time at the next dojo.

Unforuntately I couldn't go to the pub afterwards - hopefully next time.

* Tim wrote about the dojo on his blog too.
* @r4vi uploaded some videos

Monday, January 10, 2011

Pyramid does 22, but how do you do zero lines of python?

There is an article talking about how in a certain configuration the Pyramid python framework uses 22 lines of python for a hello world app.

How would your python web app run zero lines of code for a hello world? By pre-generating the html at startup - or at deploy time, and serving the generated data.

Beat that Pyramid! ;) 6 minute Abs.

This is a silly blog post - but also slightly serious. Uploading static data to serve is a very valid approach for a web framework. It's performance, security, and complexity benefits are quite big.