Names are important

I think one of the most important things with creating new computer systems is the names for things. The thing that prompted me to write this is that I've just opened a directory called "datafiles". That name was decided long ago, before I came along. I'm not quite happy with it because it's too general. Most of the files in the whole directory tree are datafiles, not just those in this directory. The trouble is that to change the name I would have to change a whole lot of things - not just programs and macros, but procedures as well. And people would struggle for months and years to come to remember where what they wanted had moved to. Several years ago Blackbaud did a major change to Raiser's Edge moving the interface to a more Windows 95 style away from a Windows 3.1 style of interface. One of the things they did was to move the setting up of usernames and passwords from the "configuration" section to the "administration" section. I still have to pause for a second or two to work out where I'm going when I want to add a user.

When I worked for Logica many years ago I worked on a project which had a number of subsystems, and each of those had further sub-subsystems. The subsystems had three letter abbreviations and the sub-subsystems a further three letters. So, for example, IOSHAN was the HANdler part of the Input Output Subsystem.

The next project I worked on used the same idea and we thought carefully about the names before we started. And of course variable and routine names followed this convention.

In the rush to get going it's easy to stop and not name things carefully, but it reduces frustration if you think about it from the start.

Bible Translation is bigger than you think

A good post on what's involved in Bible translation from a new blog by Dave G.

Just in case you think Bible Translation is a back-room activity for the seriously academic, here is a blog from a Bible-translation type who thinks otherwise.

New Wycliffe UK blog

I'm back from Canada and in the meantime we have the Wycliffe UK blog has been launched.

Linux Language software development

While I'm in Calgary I took the opportunity to visit the SIL team doing language software development for Linux. I got my first look at an OLPC running Bibledit. This has great potential for translation teams, as they don't need expensive laptops to get work done. In fact part of the reason for putting effort into Linux development is because you don't have to pay the overhead of getting legal copies of Windows and the other tools for the work (Office, Publisher, Photoshop). They're a nice bunch and they've even been so kind as to release some of their work which has general use - a library to help getting COM based Windows software to work under Linux.

View from the window

I'm in meetings at Wycliffe Canada working on our internal personnel system. This is the view from the meeting room window.


I'm working hard, but this view is good to look at.

Using volunteers to write programs

I'm assuming that you're in a small charity/non-profit. You don't have any programming staff, but you do have a volunteer who's offered to write a little program to solve a problem. Maybe they're going to write an Excel macro, or create an Access database for you.

However once they've finished and gone away, suppose it goes wrong, or you want something changing. How you can you prevent yourself getting stuck? The thing to do is make sure that you've sorted out a few things before they start:

• What programming language are they going to use? Have you heard of it? Do you know anyone else who's heard of it? If it's something obscure then the chances are you won't be able to find anyone else to maintain it.
• (You are going to need to maintain it. Even if it works now something will change in the future that will stop it working. Maybe the name of a server changes, or you rearrange the directories on your server, or you get a different printer, or you use different letters for your network drive, or it stops working when you upgrade to Windows 2010, or something else.)
• They are going to document it aren't they? You need to have something written down about how it works so that should you need something changing then assuming you can find someone who knows about Excel Macros, or Access, or whatever, they will be able to find out enough about how it works that they can do it easily.
• What should the document contain? Well, for a start, for all those things that might change - the drive letters, directories that it uses etc. - where do you change them in the program.
• The document also needs to describe how you install the program on a new PC.

That should be enough to get you started.

More automated web testing

I have progressed in my work with Selenium.

It now runs on a server, checks several of our websites hourly, and then emails me and sends a message to twitter if it fails. Twitter sends me an SMS message, so I can check it out if I'm near a PC (and my phone is on).

For the twitter bit I used this script, and hacked it a bit to remove the skype stuff.

Very sweet.