All posts by john

Building an Aerographics me163 (komet) free flight model plane

When I was younger I built and flew a couple of radio-controlled (R/C) aeroplanes. These were made from kits and were of a fairly modern style, with foam core balsa-covered wings and covered with heat shrink plastic (attached using a small iron). The two planes I finished used small two stroke internal combustion engines running on glow fuel and had roughly 5′ wing spans. They were fairly sizeable. I found them a bit unnerving to fly as that propellor had quite a lot of force behind it and could easily of taken off a finger or more. I did get my licence to fly (which was mostly to meet the requirements for getting the 3rd party liability insurance the BMFA provided), but after a few crash/rebuilds I lost interest and moved on to other things. It also didn’t help that the nearest club was a fair drive away and I was too young to drive.

This marked the end of my youthful interest in aviation.

Like many children growing up in the 80’s aeroplanes were one of those things that you just seemed to know about. I knew far too many names and details about WW2 aircraft in particular. The TV always showed re-runs of Battle of Britain, 633 Squadron and The Dam Busters. Spitfire, Messerschmitt, Focke-Wulf, Hurricane, Mosquito, Lancaster, Heinkel were household names as far as I was concerned. Airfix kits were a regular fixture too.

I’d always wondered whether I’d get back into aeroplanes. Then when on holiday I happened on a model shop selling free flight balsa planes. I didn’t buy one then, but ended up going to the local model shop a few weeks later and came away with an
Aerographics M.e. 163 Komet kit:

Messerschmitt ME 163 Komet Kit

Much like the real ME 163 this kit could take a rocket motor. I opted to just make it a glider and would launch it with a bungee cord.

Continue reading Building an Aerographics me163 (komet) free flight model plane

Arduino powered, temperature sensing, RGB LED nightlight

About a year ago I started on a project to make a temperature controlled nightlight. I was inspired by seeing these lovely LED lamps styled as mushrooms growing out of pieces of wood. Those mushrooms were made out of glass, which was somewhat beyond my skills. However I then saw some had used translucent sculpey to make mushroom nightlights on instructables. So with that discovery it seemed like it would be rather simple to do…

The first job was to solder up a three colour (RGB) LED (a super bright one from oomlout):

Wires + RGB LED ready for coating in Fimo

I then covered the LED in translucent Fimo:

RGB LED and wires covered in Fimo

Continue reading Arduino powered, temperature sensing, RGB LED nightlight

DIY Canon G10 Camera Remote

I quite enjoy some casual macro photography and am always taking pictures of various projects (which are usually on the smaller scale). For those types of photos you ideally need good light and a steady hand. When you don’t have good light then a tripod helps a lot, but a remote camera trigger is also useful. The main reason is so that you don’t shake the camera body when you press the shutter button.

After seeing a DIY guide to making a remote I thought I’d have a go at making my own. Most of the remotes I’d seen cost about £40. The parts I used to make my remote were only about £10. Of course it helped I already had a soldering iron etc…

The circuit is really simple, it just involves soldering a couple of push button switches to a 2.5mm stereo socket. Both switches connect to ground (the outer part of the socket). Each switch then connects to the other “side” of the socket.

Inside view of simple camera remote Inside view of simple camera remote

Continue reading DIY Canon G10 Camera Remote

Making a chair for a two year old

About a year ago I made a table for William’s birthday. This year I decided to make him a chair to go with the table.

I learnt quite a bit making the table and that coupled with a few other projects (a raised bed and a small phone stand amongst others) meant that I was much more confident with my woodworking skills this time round.

When making the table the wood for the legs was maybe a bit thin for an amateur like myself and meant I had to use screws to hold everything together. This time I chose something a bit thicker, which would make creating “proper” joints much easier.

Pieces cut for chair

Continue reading Making a chair for a two year old

Porting chrss from Turbogears 1.0 to Django 1.3

For the a period of 18 months or so I slowly ported my chess by rss site (chrss) from Turbogears 1.0 to Django. When I started the port Django 1.1 was the latest version. I took so long to finish the port, that Django got to version 1.3 in the meantime! The slowness was mostly due to my then pending and now actual fatherhood. However by slowly toiling away, with the aid of quite a few automated tests I managed to deploy a Django version of the chrss the other week a couple few of months ago.

Python Framework to Python Framework

The good thing about moving from Turbogears to Python was that it’s all Python code. This meant that things like the core chess code didn’t need touching at all. It also meant that a lot of fairly standard code could be almost directly ported. Methods on controller objects in Turbogears became view functions in Django. Methods on model objects stayed methods and so on. A lot of the porting was fairly mechanistic. I moved all of the Turbogears code into a folder for easy referral and then built the Django version from nothing back up. Initially most of the work was done at the model/db level where I could copy over the code, convert it to Django style and then copy over and update the automated tests. I used Django Coverage to make sure the code was still all actually getting tested.

I could have opted to exactly match the database from the Turbogears version, but opted instead to make it a more Django like. This meant using the regular Django user models and so on. As Turbogears 1.0 involved a custom user model I had to create a separate user profile model in the Django port. There were a few other changes along these lines, but most of the porting was not so structural.

A lot of the hard work during porting came from missing bits of functionality that had far reaching effects. Testing was very awkward until a lot of the code had been ported already.

Cheetah templates to Django templates

Chrss used Cheetah for templates. Cheetah is not as restrictive with it’s templates as Django. It’s very easy to add lots of logic and code in there. Some pages in chrss had quite a bit of logic – in particular the main chess board page. This made porting rather tricky with Django. I had to put a lot of code into template tags and filters and carefully re-organise things. Porting the templates was probably the hardest part. Automated tests helped a bit with this, but a lot of the issues needed visual verification to ensure things really were working as they should.

One advantage of going from Cheetah to Django’s tempate language was the incompatible syntax. This meant I could simply leave bit’s of Cheetah code in a template and it would serve as quite a good visual reminder of something that was yet to be ported.

The second 90%

A good portion of the site was ported before my son’s birth. It seemed like maybe it wouldn’t take much longer, as it felt like 90% of the work was done. Of course it turned out there was another 90% yet to finish.

Beyond the usual tweaking and finishing of various odds and ends, the remaining work consisted of:

  • Completing the openid integration
  • Migrating the database

For the open id integration I opted to use Simon Willison’s Django OpenID app – hoping to be able to have a nice drop-in app. Possibly due to the slightly unfinished nature of the app and mostly due to my desire to customise the urls and general flow of the login/register process this took a fair while. It might have been quicker directly porting the original OpenID code I used with Turbogears, but it did work out ok in the end.

Of course it turns out that after all that hard work, that hardly anyone seems to use OpenID to login to sites anymore. I might have been better off integrating Django Social Auth instead, for Twitter and/or Facebook logings. However I decided that this would have been too much like feature creep and stuck with the original plan.

The chrss database isn’t very large. The table recording the moves for each game is currently over 70,000 rows, but each row is very small. So the database dump when tar gzipped is less than 3Mb in size. This gave me plenty of options for database migration. I’d roughly matched the schema used for the Turbogears site, but did take the opportunity to break from the past slightly. I created a Python script that used talked to the MySQL database and generated an sql dump in the new format. By using Python I was free to do any slightly more complex database manipulation I needed. The only real tricky part was converting to using Django’s user models.

One wrinkle with the database migrating was a bit disturbing. When I setup the app on webfaction I found some very odd behaviour. Logging in seemed to work, but after a couple of page requests you’d be logged out. The guys at webfaction were very helpful, but we were unable to get to the bottom of the problem. During testing I found that this problem did not happen with SQLite or Postgres, so was something to do with MySQL. This was one of those times when using an ORM paid off massively. Apart from the database migration script no code needed to be touched. If I’d had more time I might have persevered with MySQL, but Postgres has been working very well for me.


Chrss has been running using Django and Postgres for nearly eleven months now and has been working very well. I’ve had to fix a few things now and then, but doing this in Django has been very easy. I was also able to automate deployment using Fabric, so new code could be put live with the minimum of fuss. When you’ve only got a limited time to work with, automated deployment makes a huge difference.

Hopefully now that sleep routines are better established and my own sleep is less interrupted I’ll have a chance to add new features to chrss soon.

Making a table for a one year old

So William is a year old now and to celebrate that fact I decided to make him a table. Now given that my last piece of woodwork was a doorbell, hastily constructed using a coping saw on the doorstep of the previous house, this could have gone badly. Luckily it went pretty well. The table I’ve made has slightly wonky legs, but it’s otherwise sturdy and stable.

Next time I make something like this I’m going to try to do it better (of course). In particular I think I shall try and make some proper mortise and tenon joints, as they’ll help to keep things squarer. I opted to use dowels to pin the legs together, which meant the legs could move around too much before the glue set.

Table legs/frame

I then had to also add in some braces to the legs, which I fixed using brass screws to provide extra rigidity and strength. One good thing I did learn at this stage though, was that a tenon saw and a mitre block are a wonderful combination! Without them the legs would have been even wonkier.

Once the leg frame was made, next step was the table top. For this I leaned heavily on this guide to building a simple sturdy wooden table on the make blog. Sadly I didn’t have some of the tools used there (e.g. a router) so again made use of dowels to join the separate pieces of the table top together. This got easier once I also invested in a jig to help hold the drill bits steady and at 90°.

Drilling holes for dowels

Drilling holes for dowels

One half of table top with dowels in place

With a fair bit of clamping and strapping the table top came together pretty well. Though there were some small cracks left between the pieces in a couple of spots.

Table top clamped and strapped while gluing

At this point I could then test out the table a bit.

Trying out the table top on frame

The top was a little bit wonky. This was in large part to my poor choice of timber – I failed to check the timber was itself straight. Never the less I soldiered on and clamped the table down after applying some water to one side. After trimming the edges and sanding the table the wonkieness was less evident and things started looking much better.

Rounded corners and sanded down top

Next more holes were drilled and dowels inserted to pin the top to the frame. Then after the application of a whole load of glue more clamping occurred.

Clamping top to legs while gluing

Clamping top to legs while gluing

This final clamping to the table top really helped to reduce the curve of the table top further.

I then applied some wood filler to the cracks in the table top and also sealed off the join between the leg frame and the table top. Then after that was all dried and sanded down a coat of clear indoor varnish was applied to the legs and underside.

Starting to varnish the table

At this point Heather and I decided it would be nice to add some pictures to the table. So we broke out the paints. Heather painted one of William’s pirate toys and I painted an octopus/kraken that was on some of his pyjamas.

Painting a pirate

Pirate colors filled in

Pirate painted on table

Colors painted for octopus

The kraken awakes!

Pirate and kraken on table top

Pirate and kraken on table top

After that the top was varnished as well. We finished doing all of this just the night before William’s actual birthday. I had started with a couple of months ahead, but it always takes longer than you think.

I’m very happy with the final outcome. It was very satisfying making something semi-sizable with my hands. I’m also starting to acquire some better tools and a few more skills, so hopefully future projects will go even better.

The main thing though is that William seems to like the table.

William with the finished table

A Little Sparql

Quite often I’ll get distracted with an idea/piece of technology and mull it over for quite some time. Most of the time I play through these ideas in my head and don’t do anything with them. It’s often just an exercise in learning and understanding. I’ll read up on something and then try to think about how it works, what I could use it for and so forth.

Occasionally though I’ll feel compelled to actually write some code to test out the idea. It’s good to prototype things. It’s particularly handy for testing out new tech without the constraints of an existing system.

The latest idea that’s been running around my head has been triplestores. I’ve still yet to need to use one, but wanted to get a better understanding of how they work and what they can be used for. Having spent a large number of years in the SQL database world, it seems like a good idea to try out some alternatives – if only to make sure that I’m not shoe-horning an SQL database into something purely because I know how they work.

So rather than do the sane thing and download a triplestore and start playing around with it, I decided to write my own. Obviously I don’t have unlimited time so it had to be simple. As of such I decided an in-memory store would still let me learn a fair bit, without being too onerous. Over the past few weeks I’ve been working on this triplestore and it’s now at a point where it’s largely functional:

To be honest writing this has been almost more of an exercise – a coding kata.

A few key points of the implementation:

  • PyParsing for the parsing SPARQL
  • Lots of generator functions to make evaluation lazy
  • Interactive prompt for running SPARQL queries
  • Load triple data from file/stdin (as triples of data in simplified turtle format)

As the data is all stored in memory it’s no good as a persistence store, but for quickly inspecting some triple data it works pretty well. Simple point the script at a file containing triple data and away you go:

$ python birds.ttl
sparql> SELECT ?name WHERE { ?id name ?name . ?id color red }


PyParsing is a great project for writing recursive descent parsers. It makes use of operator overloading to allow you to (mostly) write readable grammars. You can also specify what objects you want to be returned from parsing – so it’s quite easy to parse some code and get back a list of objects that can then execute the code.

It also includes quite a few extra batteries. One of the most powerful is operatorPrecedence, which makes it a piece of cake to create the classic arithmetic style expressions we all know and love. For example, the operatorPrecedence call in minisparql looks like:

# code removed for clarity    
expr << operatorPrecedence(baseExpr,[
        (oneOf('!'), 1, opAssoc.RIGHT, _unaryOpAction),
        (oneOf('+ -'), 1, opAssoc.RIGHT, _unaryOpAction),
        (oneOf('* /'), 2, opAssoc.LEFT, _binOpAction),
        (oneOf('+ -'), 2, opAssoc.LEFT, _binOpAction),
        (oneOf('<= >= < >'), 2, opAssoc.LEFT, _binOpAction),
        (oneOf('= !='), 2, opAssoc.LEFT, _binOpAction),
        ('&&', 2, opAssoc.LEFT, _binOpAction),
        ('||', 2, opAssoc.LEFT, _binOpAction),

This handles grouping the various operators appropriately. So rather than parsing:

5 * 2 + 3 + 2 * 4

And getting just a list of the individual elements you instead get a properly nested parse tree, that is equivalent to:

((5 * 2) + 3) + (2 * 4)

Where each binary operator is only operating on two other expressions (just as you would expect under classic C operator precedence).

This meant that implementing FILTER expressions was pretty straightforward.


Generator functions are one of my favourite features in Python. I was completely blown away by David Beazley’s Generator Tricks for Systems Programmers. He starts off with fairly simple examples of generators and shows how they can be combined, much like piped commands in Unix, to create extremely powerful constructs. Therefore it was obvious to me that generators were a good fit for minisparql.

The code for the regular, optional and union joins became pretty straightforward using generators. For example the union join looked like:

    def match(self, solution):
        for m in self.pattern1.match(solution):
            yield m
        for m in self.pattern2.match(solution):
            yield m

This simply returns the result of one query, followed by the results of another. The great thing about this is that if we only evaluate the first few values we might not even need to evaluate the second query. The better aspect though is that you can start getting results straight away. A more classical approach would entail building up a list of results:

    def match(self, solution):
        matches = []
        for m in self.pattern1.match(solution):
        for m in self.pattern2.match(solution):
        return matches

This code would always execute both queries – even if it wasn’t strictly necessary. To my eye the generator code is much clearer as well. yield stands out very well, in much the same way as return does. It’s certainly much clearer that matches.append(m) which does not immediately make it clear that data is being returned/yielded from the function.

Anyway, so here’s my silly little bit of exploration. I’ve learnt a fair bit and got to play with a some different ideas.

If I was to take this any further I’d probably want to add some sort of disk-based backend. That way it might be useful for small/medium-sized SPARQL/RDF datasets for simple apps. Much like SQLite for SQL databases or Whoosh for full-text search.

Django User Profiles and select_related optimisation

If you want to associate extra information with a user account in Django you need to create a separate “User Profile” model. To get the profile for a given User object one simply calls get_profile. This is a nice easy way of handling things and helps keep the User model in Django simple. However it does have a downside – fetching the user and user profile requires two database queries. That’s not so bad when we’re selecting just one user and profile, but when we are displaying a list of users we’d end up doing one query for the users and another n-queries for the profiles – the classic n+1 query problem!

To reduce the number of queries to just one we can use select_related. Prior to Django 1.2 select_related did not support the reverse direction of a OneToOneField, so we couldn’t actually use it with the user and user profile models. Luckily that’s no longer a problem.

If we are clever we can setup the user profile so it stills works with get_profile and does not create an extra query.

get_profile looks like this:

def get_profile(self):
        if not hasattr(self, '_profile_cache'):
            # ...
            # query to get profile and store it in _profile_cache on instance
            # so we don't need to look it up again later
            # ...
        return self._profile_cache

So if select_related stores the profile object in _profile_cache then get_profile will not need to do any more querying.

To do this we’d define the user profile model like this:

class UserProfile(models.Model):
    user = models.OneToOneField(User, related_name='_profile_cache')
    # ...
    # other model fields
    # ...

The key thing is that we have set related_name on the OneToOneField to be '_profile_cache'. The related_name defines the attribute on the *other* model (User in this case) and is what we need to refer to when we use select_related.

Querying for all user instances and user profiles at the same time would look like:


The only downside is that this does change the behaviour of get_profile slightly. Previously if no profile existed for a given user a DoesNotExist exception is raised. With this approach get_profile instead returns None. So you’re code will need to handle this. On the upside repeated calls to get_profile, when no profile exists, won’t re-query the database.

The other minor problem is that we are relying on the name of a private attribute on the User model (that little pesky underscore indicates it’s not officially for public consumption). Theoretically the attribute name could change in a future version of Django. To mitigate against the name changing I’d personally just store the name in a variable or on the profile model as a class attribute and reference that whenever you need it, so at least there’s only one place to make any change. Apart from that this only requires a minor modification to your user profile model and the use of select_related, so it’s not a massively invasive optimisation.

Blinking Halloween Spider Eyes Hats using PICAXE 08m chips

For some reason I got seized by the idea of creating some electronics for our Halloween costumes this year. In previous years I have gone as far as dying my hair green for Halloween, but that is just an evening’s work. This year we were having a more sedate affair – it being our first Halloween as parents.

We settled on making spider costumes. Basically black clothing, with extra arms made out of tights. I then decided that as spiders have eight eyes that making some hats with six extra eyes would make sense. After initially thinking I would just hook up some LEDs straight to a battery I decided to massively complicate matters by and try to make them blink periodically (at random).

So for this act of over-complication I chose to use the PICAXE 08m microprocessor. The core circuit (minus ability to program) is essentially just 3AA batteries, the chip itself and two resistors – so at least for a circuit involving a microprocessor wasn’t that byzantine. That is kind of the point of a microprocessor though. To the end-user it hides it’s internal complexity away. I don’t really need to know how many hundreds or thousands of transistors it contains internally. I only need to think about how it fits into my circuit.

I chose to have six LEDs to create pairs of “eyes” that would blink in tandem. This meant the PICAXE chip would turn three output pins on and off at random intervals. With a 4.5V power supply two LEDs wouldn’t need a massive current limiting resistor – 100Ohm would be sufficient. So the circuit consists of the 08m chip, two resistors (10KOhm and 22KOhm) to pull-down the serial-in pin, a 100nF capacitor to even the power supply, six LEDs and three 100Ohm current limiting resistors:

It’s not actually that complex a circuit, but spending several hours soldering it up (twice) for a couple of hours at a party might have been overkill. Still it was good practice. I also got to try out fitting everything into some project boxes and generally making things look “proper”.

Underside of circuit

Finished soldering the LED eyes

Making sure it all fits in project box

I used perfboard for the finished circuit, with some holes enlarged to accept screws for the project box. I also added some extra holes so I could loop the power and LED wires through. This helped to make the connections nice and sturdy.

The chips were programmed using a different circuit, with the serial adapter attached and were then removed from their sockets and inserted into the soldered circuits. The two hats had slightly different programs uploaded to tweak the speed and random nature of the blinking (so they wouldn’t be too similar). The code is viewable at my picaxe08m repository on github (as well as a Fritzing file for the circuit). I did encounter a bug in the PICAXE compiler whilst writing this code. When I started using subroutines (and the gosub call) MacAXEPad would suddenly say “Hardware not found” when attempting to upload. Apparently this problem only affects the Mac version of AXEPad. Luckily there was an easy fix – simply adding a dummy sub-routine at the end of the file:

interrupt: return

The Eye Hat

The finished result looked a bit goofy, but it did work. The main problem though was that it only really worked when the light was low. Not a bad problem for halloween I guess:

£5app – Things we built this summer

Just a quick reminder that it’s the next £5app this Tuesday. We’ve got quite a full line-up and we could have had more – it looks like people have been very busy this summer:

  • Ian on hacking a receipt printer with an Arduino
  • Shardcore on the geekery behind his enlightenment machine
  • Jon on an either digestly (or another app he’s been working on)
  • Emily on her iPhone app “Who’s There?”
  • Kyran with some Javascript visualisation demos using webgl
  • Mike with Tardis Bank: on-line pocket money banking for kids
  • Seb on how to be a gameshow host – making Flashy Fortunes with AIR Wiimotes and iPad
  • Jay on predicting the UK’s General Election with Twitter

I’ll be talking about my ultimate Arduino doorbell. It’ll be a short talk, but I hope to bring along the doorbell to demo. I’ve made sure to add a test mode so that I can trigger the bell without needing the the button too (don’t really fancy having to unscrew the button from the door frame).

Don’t forget to signup on upcoming and/or lanyrd if you are going.