New TEFL Site

I’ve put together a few pages for a TEFL materials site:

My aim for this site is to be able to produce materials for TEFL lessons more quickly. The first page that I’ve put up generates materials for a missing information game:

I’ve been playing this game for a few weeks in the classroom, but I have grown tired of writing out the cards using MS Word.

As always, I’ve written the site using the Haddock CMS. It’s the first site to make use of the Sky theme plug-in:

The aim of theme plug-ins is to be able to make giving a style to a site simply a case of checking out a plug-in and then getting the HTML page class to extend a class in the theme plug-in directory.

It’s also the first site to make use of the new “Site Texts” plug-in:

This separates all texts from the code of the project. The texts are saved in files in a separate folder to the project-specific code. At the moment they need to be created and edited by hand, but a web interface in the admin section may follow.

Dusting off old code

I’ve started working on a new web based project using Haddock CMS (details to follow later).

This is the first web based project that I have started since I started to remove some of the modules (Admin, Database, HTML Tags, Public HTML) from the core of Haddock CMS, and using those core modules as plug-ins has required commenting out a lot of obsolete ‘require_once’ statements from some really old class definition files. When we started working on Haddock CMS, we decided that there should be one class per file and that each file should be named after the class. Rather like in Java. For a long time, we had to put lots of ‘require_once’ statements at the top of all the class definition files. Eventually, we came up with a way of automatically generating an enormous __autoload function (basically a large switch statement) using a CLI script for each project. That made adding new ‘require_once’ statements unnecessary.

However, we didn’t go through every class and delete those statements unless we got an error message. Because most of the classes have stayed in the same place since they were created, the old ‘require_once’ statements were not doing any harm and were forgotten about.

Moving the core modules to the plug-ins folder caused however a lot of error messages to be printed. There were a lot of ‘require_once’ statements starting ‘PROJECT_ROOT . “/haddock/…”‘ that were asking for files that are now in the plug-ins folder. That meant that I had to go to about 30 class definition files and comment out the offending lines. Not very difficult or dangerous but somewhat tedious.

The thing about all those files is that they were all for the bits of code that have not been touched for ages. All the code that has been worked on a great deal since we created the __autoload creation script had already been updated. I felt a certain amount of nostalgia and despair (is there a difference?) looking at these files. Some were clearly bad ideas that deserved to be consigned to the dustbin of history. Others were good ideas that were made obsolete by other bits of code. I found a few good bits of code that I might try to use again. Some of the code was trying to be too clever for its own good; perhaps that’s a risk that all object oriented code runs. The emotions of looking at code that was started in 2006 that still has not been completed (of looking at ideas that sparked, shone and died) are a mixture of shame, fear, resignation and hope.

If you use the Haddock CMS for a project, the branch where some of the core modules have been moved to the plug-ins folder can be found at

and the various plug-ins can be found in

CLI Script to allow access to a directory in Haddock CMS projects

I’ve added a little script that allows developers to allow access to a directory that is relative to the project root directory of a Haddock CMS project:


I refactored a bit of existing code from:


into an abstract CLI script class:


If you ever need to write a script that does something with a directory that exists and is relative to the project root, then extending this class would probably be a good place to start.

Haddock Sanity Check

I never set out to write a web framework. Haddock CMS has always been just the common elements of a lot of web sites that I’ve written and worked on. It’s taken a lot of time and effort but I think that investment will be returned in the long run. Hopefully 🙂

Part of the advantage of writing a framework by refactoring the elements to common to several sites is that it avoids over engineering features. Nothing in the framework should be there because it solves a general problem when a solution to a specific problem would have been better. That would go against doing the simplest thing that could possibly work.

However, I didn’t have a place where I could check that all of the plug-ins for Haddock CMS worked together. There now is one:

If you check out this to a vhost project root, it’s not a very useful site but a good place to check that everything is still working.

Ad-Hoc Data Serialisation Formats

I’ve been doing a bit of tidying up of the code that goes into the Navigation plug-in for Haddock CMS. An enhancement that I think is quite necessary is to have navigation lists saved in files under version control rather than in DB tables. This makes testing and collaboration much simpler.

The question that any CS student will ask himself is “What format should I use?” I’ve used XML a lot in different parts of Haddock CMS and it is certainly more than expressive enough to be able to store the data for simple navigation lists.

However, it seems like overkill.

Also, I might want to allow users to be able to edit the navigation list specification files in the admin navigation back end.

A simple whitespace delimited data serialisation format springs to mind. This wouldn’t be too difficult to define or implement and I think that users could understand it without too much difficulty.

I started to imagine this language and wrote out a few examples. I started to think about the grammar of the language in BNF. This is definitely an area of programming where the test first approach is very sensible.

It seems that web programmers are very fond of text files and formal languages. I started to wonder about whether there is a version of YACC for PHP and whether such a beast would be a good idea or not.

Haddock CMS site redesign for narrow screens

As promised, I’ve rearranged the divs on the Haddock CMS site to work better on narrower screens.

I made all the edits to the code using Komodo Edit on an EEE PC. The only modification that I’ve made to the EEE PC is to use the full desktop and install Komodo.

Shelling in to my dev and production servers for SVN and to run the various Haddock CLI scripts is not really any different on the small machine. Komodo connects to the dev machine using SCP better on Xandros than it does on Vista (which isn’t hard). phpMyAdmin and cPanel are also fine on the small screen.

While I wouldn’t want to work like this all the time, my main objection is anatomical rather than to do with the performance of the machine. My neck is a little sore.

The only things that I need on the EEE PC at this point are Subversion and TrueCrypt. I’m sure that I can get them working soon enough. Other than that, I would only need the bigger machine for testing what the sites look like other browsers on a larger screen.

Love for my EEE PC

After one factory reset and a bit of an ache in my hand, I’ve grown fond of my new EEE PC.

I have to say that it’s making me rethink web design to some extent. Left navigation bars are hopeless and annoying on a seven inch screen. Perhaps I should shift them to the top of the page? I’ll try moving the DIVs around on

later today to see if it’s much of an improvement. Are sites going to new a stylesheet for iPhone, EEE PC, laptop and wide screen Media Center style machines? We’ll see…

Staring at this small screen and then looking at the 17 inch screen on my Samsung laptop is a bit like teleporting from England to America. Everything is recognisable and similar but noticeably bigger.

CSS Layout Tester

Web designers have got the message about using CSS for the layouts for their pages.

However, web page layouts need to be tested in several browsers and on several platforms before they can be trusted.

If you have an “Edit CSS File” step and a “Upload to server” step in your development cycle, this can be a time consuming process.

I’ve started a Google code project at

that makes testing different CSS layouts a little easier.

To try out a working version of the software, go to:

This is at the very early stages of development so I have had time to implement the whole of the CSS specification but any help with developing this would be appreciated.