PEP 374

The Python core developers are currently discussing whether to move away from SVN to a distributed version control system. It’s a worthwhile read for anyone involved in this sort of decision in any capacity. It features hands on examples of each of the contenders (Bazaar, Git and Mercurial), some interesting observations about all of them as well as some benchmarks against a mature codebase. Lots of conversations keep cropping up on Twitter about why bother switching to Git or other distributed systems - this is a good place to start whether you use Python or not.

Sinatra Simple Example

I’ve been playing around with the Sinarta Ruby web development framework recently and building a larger than usual Hello World Example. It’s describes itself as a DSL for quickly creating web-applications in Ruby with minimal effort (what is it about Ruby people and their obsession with calling everything a DSL?). In reality it’s a great little web framework. It deals with a minimal set of the things you really need to do as part of any application - URL handling and routing, HTTP request and response handling, etc. It reminds me of in it’s minimalist approach which is definitely a good thing.

The following example is the hello world given on the site

pre. require ‘rubygems’ require ‘sinatra’ get ‘/’ do ‘Hello world!’ end

Which isn’t a million miles away from a example:

pre. import web urls = ( ‘/’, ‘hello’ ) app = web.application(urls, globals()) class hello: def GET (self, name): return ‘Hello World’ if name == “main“:

The only real difference is the separate mapping of URLs to views in, which is closer to how Rails or Django do things.

Their is quite a bit of documentation already for Sinatra, including the start of a book. The code (as with all good code these days) is on github for your forking pleasure.

As for what I’ve been up to I have a more advanced Hello World example up on GitHub. I’m wanting to get a running application that demonstrates all the basic features (except HAML and SASS support). So far I’ve got a simple bit of Rack middleware, several views demonstrating different url handling techniques, basic erb templates, before methods, configuration settings, error handling, decent unit test coverage, a rake file with a tasks for documentation, code coverage, etc. I’ve also got configuration files for running the application with Thin and using God. I’m going to add some simple database connectivity in at some point (either DataMapper or Sequel, I haven’t decided yet) and play around with writing spec tests and a capistrano recipe file. All in it’s a nice way of learning something new at the same time as producing something that might be useful. Once I have the rest of the bits and pieces I might even right a full tutorial.

I think the sweet spot for these sorts of mini frameworks are small services or little applications that just sit their are run. Both Integrity and IRCLogger both use Sinatra for instance and I think it’s used for the GitHub WebHooks as well. It’s exactly the sort of thing Google AppEngine is useful for in fact and Sinatra would likely be a closer fit that Rails if Google ever feel like adding Ruby support. Although it does depress me a little that the top four items in the public issue tracker are I want my own language.


Jsonpickle is a Python library for serializing any arbitrary object graph into JSON. The advantage over something like simplejson is the arbitrary part, simplejson throws errors when you try and serialize some types of objects. I also prefer the jsonpickle API (encode, decode) over simplejson (dump, dumps, load, loads).

Git Issue Tracking

TicGit looks great. I love command line apps and have been looking for something like this for a while. It’s described as a:

Git based distributed ticketing system, including a command line client and web viewer

pre. #>ti list

# TicId Title State Date Assgn Tags

  • 1 9ebd07 add attachment to ticket open 03/22 schacon attach,feature 2 6ca8be download attached file open 03/22 schacon attach,feature 3 bec8e9 add a milestone resol 03/22 schacon feature,milestone,ne 4 9b83ea general tag management open 03/22 schacon feature,tags 5 94f24e show expanded comments open 03/22 schacon feature,ticket 6 f3dd9b remove a ticket open 03/22 schacon feature,ticket 7 e1629e improved cli support open 03/22 schacon cli,feature

Perfect for my pet projects or working with like minded folk.

In Defence of Apache Ant

I’m a big fan of the Ant build tool. Their I said it. Nearly everyone else I end up talking to about build scripts (more people that you’d think, but OK, it’s hardly the most exciting topic of conversation) either hates it or treats it with disdain.

I’ve been using it for a few years on and off, in several jobs and for personal projects as well. I’ve used it while writing Python, .NET and PHP. It might be somewhat unfashionable (it’s written in Java and you write your commands in XML) but, for me at least, it’s incredibly handy to have around.

Ant is a build tool. It lets you define tasks in a config file (called build.xml) and then execute them via running the ant command line application. It supports dependencies between tasks as well as defining properties that can be used by multiple tasks. It supports a lot of Java specific stuff as well but also has the ability to simply execute commands on the host OS.

As a really simple example of a few tasks I use on more than one project involve simple backups and deployment.

First I set up a few properties including details of where my site files live and the SSH access details for the remote site.


The first example task simply runs a backup of everything in the target directory using scp.


If I make local changes and want to push them to the live site I have another simple task which shells out to rsync.


I know some people hate this separate arguments as individual elements. Yes it’s excessively XML but it makes everything incredibly clear to anyone who might sneak a look. And build scripts change little compared to project code so the verbosity never bothers me overly. If you really want you can put everything on one line, but I find that harder to follow and maintain.


For bigger projects I tend to create more complex backup and deployment tasks, or more often than not add in various dependencies. But you hopefully get the idea. Even for simple commands like this that would be a single line bash script I tend to use ant. I find by putting things together into a build script I’m more likely to add useful functionality to it later, and to remember and therefore run the commands more often.

A good reference for finding out more than is in the manual is the Apache Ant Wiki. More than anything it features real examples that you can learn from which with Ant is definitely the best way to discover new tricks.

I know their are a number of other tools in languages I like more. On occasion I use Rake, Fabric and Capistrano. I’ve looked at Vellum and good old make. I know others who swear by just writing simple bash scripts or using straight Ruby, PHP or Python (or not writing build scripts at all and doing everything by hand. But I like having my build scripts separate and simple. It might not be pretty or fashionable, but Ant does almost perfectly what I want it to do.

Django Testing Presentation at DJUGL

The second Django User Group (DJUGL) meeting was last night and was a great success as far as I could tell. Our boardroom at work was chock full of budding Django developers and interested parties - 70 people or so in all. Good work by Rob to get everything back on track at the start of the year and the next event is already planned for the back end of February so I hear. More news soon on the mailing list hopefully.

Rather unfortunately Simon had to pull out at the last minute and I stepped in to do a quick 20 minutes or so talk on writing tests for your Django applications.

I was rather surprised that only about a third of the people coming along were using Django in some work related capacity, and when I asked who was writing tests for their code a few more hands went down. Very few of the people not using Django at work are writing tests which is unfortunate (and contrasts rather interestingly with my experiences of the Ruby community).

For a presentation done in less than a day while at work I felt it went OK. testing is a hard sell at the best of times and trying to talk to both those without experience of writing tests and at the same time trying to get in a few of the more interesting things we’ve done at work was maybe a bit of an ask.

It not being a blog post round here these days unless I include a link to GitHub I did mention a small project last night in the talk - Django Test Extensions. It’s more just a collection of useful common testing code: additional assertions, custom test runners, etc. Thanks to Ross for the last minute patch with a couple of bug fixes as well.

The other two presentations went great. Andrew talking about the South migrations system and Aral talking about real world Google App Engine were both up my street of things I’m interested in. We have video of all the talks as well so hopefully that will make it out into the wild at some point once it’s been edited.

A Simple Python Jabber Bot

I’ve been knocking together various little instant messaging bots recently, partly as a way to play around with XMPP. As well as using the low level xmppy and XMPP4R-Simple libraries I’ve been having lots of fun with the JabberBot framework.

Jabberbot lets you write simple bots incredibly quickly, using simple conventions to determine what commands the bot exposes. It’s easier to explain with a simple example. The following bot lets you send the command time to it and returns the current time on the server on which the bot is running. The magic is in the name of the method bot_time. Any methods that start bot_ are automatically exposed as commands for the bot to accept.

You’ll need an xmpp server for the bot to connect to but you could always just register an additional google account and use it over gtalk if you wanted to. Personally I’m running ejabberd on a local Ubuntu VM as well for testing.

pre. from jabberbot import JabberBot import datetime class SystemInfoJabberBot(JabberBot): def bot_time( self, mess, args): “”“Displays current server time”“” return str( username = ‘[email protected]’ password = ‘my-password’ bot = SystemInfoJabberBot(username,password) bot.serve_forever()

The JabberBot site has a few more examples as well with fancier features. At the recent hackday I spent a bit of time knocking together a bot which talks to the API (using the PyLast library for the API backwards and forwards.) I did this mainly as a demonstration of how simple it can be to create a useful command line interface to your API using an instant messaging client.

The code for LastBot is on GitHub. It has a few limitations and doesn’t intent to cover anywhere near all the API. When up and running you should be able to talk to it with your IM client. Simply send the user specified in the settings file a message like so:

pre. search {query}

So if you wanted to search for “astley” you would type:

pre. search astley

Which would probably give you:

pre. you probably mean Never Gonna Give You Up by Rick Astley Richard Paul Astley (born February 6, 1966) is an English dance-pop singer, songwriter and musician. He was born in Newton-le-Willows, St Helens, Lancashire, England. Astley currently resides in Richmond, Surrey with his Danish girlfriend, Lene Bausager, and their daughter, Emilie. In 1985, Astley was playing the club circuit as a singer with a soul band named FBI, when he was seen by the record producer Pete Waterman and persuaded to come to London to work at the PWL recording studio.

If the first result that comes back isn’t the one you wanted you can ask for the next result by simply sending next in another message. You can use prev as well to come back through the set.

pre. next

You can always send it a call for help at any time which should return the instructions to you via an IM message.

pre. help

Which should return something like:

pre. Personal LastFM search bot. Useful for looking for tracks you can’t remember the full name of. Or for findind out who sung a track. search: do a search for tracks prev: get details about the previous track in the list next: get details about the next track in the list

More instructions, and the code behind the bot, can be found in the README.

As developers we spend a lot of time using command line interfaces - mainly for speed and because you can cram a lot of functionality into a small amount of screen real estate. We’re increasingly spending time debugging API calls as well and exposing your API calls for use by instant messaging clients has the potential to make development easier. Think of the Python interactive shell or of IRB, but for APIs.

Are XMPP and offline processing coming to Google App Engine?

Google just announced that, once the port of Jaiku to App Engine is complete they will be Open Sourcing the code and stopping official development. I only used Jaiku sporadically in the heady days when everyone had to sign up for a new web 2.0 service every week or be mocked by their colleagues. What really interests me about this move though is what it means for App Engine.

If memory serves Jaiku had an instant message interface. Does that mean App Engine is going to get an XMPP interface?

I’m also presuming the original Jaiku application had at least some features powered by offline processing or used a message based architecture behind the scenes? Or used scheduled batch jobs for reporting or data mungling?

All of these issues are high up on the App Engine issues list and solutions to these two outstanding problems would move App Engine, in my opinion, to being very cool to being very useful. I’ve been impressed with the simple, well designed and well documented current set of APIs and I’d love to see a few more added for XMPP and offline processing. If the Jaiku code is open source but relies on Google only APIs it would seem a little odd.

So does anyone have any more information on this? Any passing Googlers who can get us an answer?

Localbuilder on GitHub

One of several little projects I have up and running on GitHub at present is LocalBuilder. It’s a pretty simple little script which watches for changes in a given directory and when they occur runs a given command. I knocked it together to use to trigger the running of a test suite each time I save files in a project. It’s written in Python but you could use it to run commands in any language you like.

It’s all pretty simple Python really and is hopefully reasonably commented and tested so if you’re interested you can follow along with the code. If you just want to use the damn thing then:

<code>./localbuilder --path /path/to/watch --command /command/to/execute</code>

It turns out Ruby has a much nicer tool to do this and more in autotest, part of the ZenTest suite of testing tools. I’m finding more and more very nice bits of code written in Ruby of late, but that’s probably a whole different blog post.

Speaking at Bamboo Juice

It’s the start of another year so that means it’s time to start thinking about conferences.

I just found out at the end of last week (via Twitter no less) that I’ve been confirmed as one of the speakers for Bamboo Juice. Thanks to Jon and Rich for having me. I’m really looking forward to that as it’s a new event outside London (at the rather fabulous looking Eden project in Cornwall), which should hopefully mean a chance for a new set of people to go along to what looks like a decent event. I’ll have more information about what I’m going to be talking about some time between then and now I would imagine, but the emphasis is on practical learnings for working developers and designers.

Apart from that the only other conference I’ve confirmed I’l be attending so far is Thinking Digital in May. It was great last year even if I spent the majority of the time running round organising barcamp, moving house or leaving Newcastle. This time I’m not involved in any organising (sorry Andy) so I plan on making the most of the talks and general experience. Rumour has it that their will be another barcamp as well so I’ll look forward to that too. It will be good to get back up to Newcastle and see people again.

I’m also looking forward to what Patrick is up to for @media. It was the conference that started this whole thing rolling in the UK back in the day and now it appears it might be set for a change.

Time to finalise the line-up and web site for a very different (and lower price!) @media ‘09

As well as these three I’ll be keeping my eye out for any news about Xtech, The Highland Fling and any other new upcoming conferences. If you know of anything else leave a comment. I didn’t find out about Think Visibility until it had sold out but I like the idea of smaller, specialised events.

Overall it already looks like being a good year for conference goers in the UK. I’ll be on the lookout for barcamp style events as well but I do like a good formal conference as well. Hopefully see a few people at some of these events?