Archive for June, 2007

Show Env Script

Tuesday, June 26th, 2007

I’ve been tied up with setting up several new machines for the last few days. Each machine had several virtual machines running on VMWare Player. It got a little hectic remembering exactly what I had put where at points. Luckily, I had perl to help me. This little script was especially useful.

Alt Tags for Accessability

Friday, June 15th, 2007

As a web designer, one always has to ask oneself “How do other people see my pages?”. It’s important to make sure that all the users of the site can achieve their goals with the site.

Images in web pages can provide additional information for blind or partially sighted users (or, indeed, users of command line browsers) in the form of IMG ALT tags.

This little perl script allows a designer to check that all the images on a page have set an alt tag.


$ ./


This means that on that page, 16 imgs were found that set the alt tag and none were found without.

SVN Project to CSV

Thursday, June 14th, 2007

Here’s a little perl script which I wrote to help me kept track of projects that are under Subversion control.

Branching and tagging are useful techniques for keeping track of large projects. Sometimes, it’s difficult to remember exactly which branch you worked on on which date. This script take a folder name as an argument and searches in that folder. It expects to find the “trunk” directory and any “branches” or “tags” of the project. It then aggregates the information from each of these working directories and saves that information in a CSV file. This CSV file can be opened in Excel, OpenOffice or similar and played around with there.


Wednesday, June 13th, 2007

After getting back from Hadrian’s wall, I found a great program called Autostitch. Luckily, I did take one set of pictures for a panorama (although I wasn’t sure how I was going to merge them at the time):

I’ve taken a few more photos from the garden of my parents’ house and the nearby fields.

Autostitch from Woodlands

I really like the program and regret not taking more photos while I was on the wall.

The folks who make the program say that ILM have been granted a commercial license to use the program for film production. I’m not quite sure how that would work. Would you need to build some enormous rig with 10 – 15 RED cameras somehow frame-synchronised and pointing in different directions? The computer processing power and hard drive space for dealing with 25 fps at 4K from 15 cameras would be sickeningly large. I’m sure that the results would look pretty amazing, though.

Hadrian’s Wall

Monday, June 11th, 2007

I’ve just returned from a week long hiking holiday in Northumberland and Cumbria. A friend from school and I walked the from Whitley Bay on the East coast of Northumberland, along Hadrian’s wall to Bowness-on-Solway on the West Coast of Cumbria.

The scenery up there is beautiful:

Hadrian’s Wall June 2007

We walked to raise money for the Parkinson’s Disease Society. If you would like to make a donation, please go to:

Everyone that we met along the way was very friendly. I should also thank:

Virgin Trains for giving us free, first class train tickets up to Newcastle and back from Carlisle.

Les Gibson at the Old Repeater Station hostel for letting us join you for you birthday dinner. The pheasant was delicious.

Maureen and Michael Miller at the Old Chapel in Bowness-on-Solway for lending me a fiver for the bus. Having walked all the way from Carlisle, I doubt that I would have enjoyed walking all the way back.

How important for speed is the language?

Friday, June 1st, 2007

I watched a video about a funky new interface today:

It looks kinda fun but I’m yet to be convinced.

When people think about innovation in interface design, too often, they focus on items with a “wow” effect like that board. While there’s no doubt that these objects are clever and might work their way into our homes and offices, they only really succeed if they allow us to achieve our goals more quickly and with less frustration and RSI.

An area of interface design that has advanced in leaps and bounds in recent decades (and which is often not seen in these terms) is that of programming languages. In one sense, all programming languages are equal because one could translate any program in any language into a state diagram for a Turing machine and from that into code in any other language. However, when it comes to the day-to-day realities of writing programs, language choice is an important issue.

I write most of my code in very high level “scripting” languages. A lot of thought (and trial and error) goes into developing these languages so that a programmer’s job is easier. The syntax of a language is an extremely important interface between the programmer and the machine. It’s much more important that any GUI IDE for writing the code.

If, as a programmer, you want to save yourself headaches, you’ll use a language that’s been designed by people who are interested in human computer interaction. I used to write programs in Java but was frustrated by it’s clunkiness. I worked on a project in Java that took a little more than three months. When we reached the end of the project, all the developers and I said to each other “if only we’d done this in perl, we would have finished it in less than a week.” Perhaps we were indulging in a little “the grass is always greener on the other side” thinking but I don’t think that we were too far off.

An example of the sort of thinking that has gone into Java’s development can be found on an official bugs page:

Programmers had asked for multi-line strings but the official response was “This is yet another request for a syntactic sugar to save some user from typing. It’s not worth it.” I wish I could get away with saying things like that my customers. “No, I’m not going to add a form to your ecommerce site. Your customers can add the variables as GET vars in the address bar. Why should I save some user from typing?” I’d finish my websites in next to no time. No interface designer should get away with this sort of attitude. The aim of the job is save the users from as much work as possible.

A particularly good example of a language that is in tune with the way humans think is Ruby. Alas, I’m yet to write any professionally but I have played around with it. It seems to have quite neatly poached some of the best bits from lots of other languages.

Critics of very high level languages say that they are not as fast as languages like C or Assembly. This is true but it seems to be premature optimisation (the root of all evil, according to Donald Knuth).

As an example, consider writing a function to raise a real number to an integer power. Admittedly, this is not something that one normally needs to write as most languages have a built-in function or a library function to do this. But as a simple problem to demonstrate my point, it will serve.

Please take a look at:

To run this program, you’ll need to install ruby. On windows, try the One-Click Ruby Installer.

I have to admit, I have been a bit of a hypocrite. The interface to this program isn’t as intuitive or bullet proof as one might hope.

Unpack the zip file and open the command line in the new folder.

To find 2 to the power of 10 000, type:

ruby compare-exponentiation.rb 2 10000 p

If you don’t want to wade through screen length after screen length of numbers, omit the “p” (for “print”) from the command.

I’ve implemented three different functions to solve our problem.

The first is just a wrapper around Ruby’s built in function.

The second is a naive approach using a loop to multiply the base by itself “exponent” times.

The third implements the Exponentiation by squaring algorithm.

The code is very simple and (thanks to Ruby) I hope readable.

In my tests, I found that the different implementations had very different performances. This is particularly apparent with very large numbers like 2 to the power of 100 000. This difference in performance is hard wired into the mathematics of the algorithms. No language, no matter how arcane and close-to-the-metal its syntax is, will perform quickly if the wrong algorithms are being used.

A good interface allows users to think about their problem in terms that are relevant to the problem that they are trying to solve. When it comes to program speed, the most important thing to consider is the choice of algorithm. Even if you’re not working on something mathematical, it’s vital that your program completes its tasks in the most direct way. Very high level languages allow programmers to focus on the problem in hand and therefore, they should write more efficient code.