Thu, 24 May 2012

Why I put it on the list:My memory is terrible, I rely on writing things down for most everything.

What I did: I used a combination of phonetic association and temporal association to create absurd comic images in a particular journey through the house, long enough for 100 digits, and then I tested myself with retaining that for a week.

What next: Keep on using my memory. It would be great to memorise the phone numbers in my phone's address book for example.

Why I put it on the list: Driving is really useful. Earlier in my career, I could get away without it, but as I relied more and more on partners and friends who could drive, it was time to sort it out.

What I did: I did a one-week Intensepass course with Rob Watson at UKDrive.net, and I passed first time back in November 2011. Since then, I've done loads of little trips, a few big ones like a big trip to France and back, and I even took the car in for its MOT.

What next: This one seems thoroughly done, although there's always room for improvement. Maybe an advanced course one day, or a track day type affair. Plus, I'm sure I'll end up with a hire car in some foreign country one of these days...

Why I put it on the list: I've always liked learning languages, and the couple of times I interacted with deaf people, it turned out they could sign really well and I just made a fool of myself like a typical hearing person.

What I did: I did an introductory course, but there was a point where I needed to revise and take a test, and the instructor was becoming unwell. In the end, the course never finished. I switched to an introductory Mandarin course at the University instead as I had lots of Chinese colleagues. It was pretty good fun and taught me that I can pick up most things quickly.

What next: I'm a little busy for language learning at the moment. I think I get enough exposure through work trips to various countries.

Wed, 09 May 2012

Today's the end of my Day Zero challenge. Suffice to say, I haven't finished everything. But I don't regret it for a moment. It forced me to do a whole bunch of things that worked out pretty well, and apart from several bouts of extended illness, the things that distracted me from the challenge were all most welcome: moving in with my girlfriend, getting a new job, buying a car, buying a house, all wonderful positive things. Some time soon, I'm sure, I'll go through and update the actual final status of the challenge and muse on the whole thing some more.

Sun, 22 May 2011

Well, it's been a while, but I finally got my website staging to a vaguely usable condition. Upshot of this is, it makes it easier for me to update the more static content of the site. I've redone a huge chunk of the Portfolio, do pop by and have a look when you get a chance.

Sat, 07 May 2011

A quick update, now that I have a slightly more awesome website updater system (which could break at any moment!) - I wrote a little Lego challenge chooser thingy in JavaScript. Just set the difficulty you want, the themes and constraints you want, and what brick sets you can support with your collection, and then click "Choose your game" and the random chooser will choose your game for you. Simple!

Sun, 19 Dec 2010

I'll just leave this code here - my solution to a problem posed earlier on today.

#include <stdio.h>

 * Calculate the square root of a number with the following restrictions:
 * - only use integers
 * - no division, just multiplication and addition
 * - no function calls, just do it all in main

#define TEST_RANGE_HIGH 1000

int main(int argc, char *argv[])
  int result;
  int n;
  int sqrtOfNumber;
  int offset;
  int previousOffset;

  for (n = 1; n < TEST_RANGE_HIGH; n++)

    sqrtOfNumber = 1;
      if (  (sqrtOfNumber * sqrtOfNumber <= n)
         && ((sqrtOfNumber+1) * (sqrtOfNumber+1) > n)
      offset = 1;
      previousOffset = 1;
      while ((sqrtOfNumber + offset) * (sqrtOfNumber + offset) <= n)
        previousOffset = offset;
        offset *= 2;

      sqrtOfNumber += previousOffset;

    printf("%d -> %d\n", n, sqrtOfNumber);

  return 0;


I think this is a reasonable compromise between simple and efficient.

Wed, 10 Nov 2010

I've been messing about with emacspeak on an old laptop, originally as part of a plot to do without screens for a week, but now just to be kind of geeky. Here's a breakdown of what I ended up doing:

  1. Remove the graphical login
    The OS installed is Ubuntu Desktop 10.04. To disable the graphical login, I simply renamed /etc/init/gdm.conf to /etc/init/gdm.disabled.
    sudo mv /etc/init/gdm.conf /etc/init/gdm.disabled
    Then I proceeded with a fairly standard install of emacspeak, which needed a little bit of low-level tweaking (that I've now tragically forgotten about) to make it work.
  2. Remap the CapsLk key to be a Ctrl key
    On this system, the magical incantations appear to be in /etc/default/console-setup. I changed the settings here to include:
    file /etc/default/console-setup:
    and then redid the setup with:
    sudo dpkg-reconfigure -phigh console-setup
  3. Auto-start emacspeak on boot-up
    This one was a little tricky, but after some reading about autologins on the console, I came up with a solution with minimal impact. Firstly, I wrote a little shim to patch into getty:
    New file emacspeakzoe.c:
    #include <unistd.h>
    int main() {
      execlp("su", "zoe", "-c", "'emacspeak'", NULL);
    Compiled up with:
    cc -o emacspeakzoe emacspeakzoe.c
    and finally installed with:
    sudo cp emacspeakzoe /usr/local/sbin
    Then I modified upstart's /etc/init/tty1.conf to read:
    file /etc/init/tty1.conf:
    exec /sbin/getty -n -l /usr/local/sbin/emacspeakzoe 38400 tty1
    Took the machine down, brought it up again, and up it pops.

Now, all I need to do is make the time to really get stuck into using emacspeak for real...

Tue, 08 Jun 2010

My good friend Haegin posted an article about finding free space at the commandline. I was asked if it contained anything too zsh-specific; my response was of course to rewrite the whole thing. After a couple of iterations, here's what we ended up with:

2>/dev/null df | awk '
  total=0; join=0;
NF < 3 {
!join && NF >= 3 {
join && NF >= 3 {
  print int(total / 1024 / 1024) " MB"

The main changes are to accommodate the output format from df better and to move most of the processing into awk. This should make the whole thing a little more portable to other shells in the sh family.

Wed, 28 Apr 2010

We deal with two-dimensional coordinate systems and vectors all the time when we're working with computer systems. Documents are two-dimensional, using a physical representation of the page. The screen is two-dimensional, and us regular mouse-users move the mouse in two dimensions. By and large, when we look at the horizontal movement, we count from the left across to the right - this is how the ruler on your favourite word-processor or graphics system is typically set up. It kind of makes sense given the prevalence of Western influence in mathematics and engineering; our writing is written left-to-right and so we write the numbers on our rulers this way. It's pretty difficult to escape from the left-to-right paradigm, even if you're left-handed. When it comes to the vertical, however, the rules are less fixed.

Sometimes the vertical axis is numbered from bottom to top; positive values above the origin, negative values below. I don't really know where this convention comes from, but it's easy to understand. When I want to say how far away something is from me, chances are I'll say that it's a certain distance in front of me. If I denote that on a piece of paper and then hold it up, I find that the further away something is, the higher up I place it on the paper.

Things that measure up the page:

  • Maps
  • x-y plots
  • Plans and elevations
  • Chessboards (from white side)

Sometimes, however, we measure from top to bottom. Imagine the process of writing on a piece of paper. You're probably imagining something that starts from the edge furthest from you, and coming towards you. Why do we go this way? One reason is that if you start close and move away, there's more chance of smudging what you've already done as you reach over it to write the next line. (It's the same as the process of filling up the auditorium for a lecture, a play or a film. You ought to start in the least accessible places and work outwards, rather than perching on the end of the row and forcing everyone to go past you to get to their seats.) If you start counting lines down the page, why not measure distances that way as well?

Things that measure down the page:

  • Framebuffers
  • Text lines
  • CRT beams (most of the time)
  • Chessboards (from black side)

Different computer systems follow different conventions. For laying out graphics on a page, you often find the origin in the lower left and the Y-axis increasing upwards. For writing text, the Y-axis is more naturally oriented increasing downwards. I've just checked in my current install of Office 2007; Word measures distance down the page, and Visio measures it upwards.

Is this ever a problem? Well, it depends if you're likely to be referring to coordinate positions a lot. If you're writing code that manipulates graphics, you'll need to know which way the vertical axis is measured. Have you memorised which way up the vertical axis is in LaTeX picture environments? Matlab plots? HTML 5 canvases? ImageMagick -draw commands?

The take-home message here is never to assume that you know what the vertical axis direction is. Always check - it may even be configurable, in which case you may have made an incorrect assumption about it. The message extends out to angles (which axis is zero? Is positive clockwise or anticlockwise? Are you measuring in degrees or radians?) and into three (and more) dimensions. It's best to make sure, and perhaps think now and again on where these discrepancies come from.