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.

MySQL Connections Plug-in for Haddock CMS Projects

I’ve extracted some of the code for connecting to MySQL databases from the database module and put it in its own plug-in:

I’ve not changed the code very much (just renamed a few items). There are not very many additions that I want to make to this plug-in. The intention is just to refine what is there and add some automated tests.

This little plug-in should make writing Haddock CMS programs that use a MySQL database simpler. Especially for projects that run solely on the command line.

I’ve not removed anything from the old database plug-in, so do not think that you need to add this plug-in to existing projects.

Tagged db-pages and mailing-list plug-ins for Haddock CMS

I’ve tagged two of the plug-ins from Haddock CMS that are going to get affected by the changes that I’m making to the core of Haddock CMS in

If you have a project that uses the branch of Haddock CMS that has the admin, database, html-tags and public-html modules in the core, e.g.

or (currently)

Then you might need to make references to the following tagged directories in the svn:externals properties of your projects:

The trunks of these two plug-ins are not being updated at this point, so there’s no rush to change the external references. While I’m working on the core of Haddock CMS (removing cruft mainly) in a branch (see above), it does not make sense to change the trunks of any of the plug-ins to work with that branch. Except for the plug-ins that have been moved from the core.

The point is that I’m trying not to mess around with code in the trunks of the core or plug-ins, but code in the trunks cannot be relied upon not to change and production systems should reference external directories in the tags directories.

When to use the trunk directory in SVN?

I’ve been tidying up some of the code in Haddock CMS recently. So that I don’t damage any sites that are using the previous version of Haddock CMS, I copied the trunk of the core to a new branch.

That is, previously people could use

but I’m working on the code at

I realised quite quickly that the changes that I am making to the core would require that I make potentially damaging alterations to the plug-ins so

got copied to


got copied to

I will probably branch a few more plug-ins before I’m done.

The question that I ask myself is when should one use the trunk directory for a project under SVN? When I’m satisfied that the new branches work correctly and they’ve been tested with several projects, they will be copied to the ‘tags’ directory.

For example, if I decided that the db-pages plug-in is stable today (unlikely) I will copy

to somewhere like

and promise to only make minor updates, if any, to that copy of the plug-in. That way people can point to that directory using an external SVN reference and not worry about updates.

The question that I ask is when would I ever go back to using the trunk again?

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

Quercus PHP

I’ve no time to test this with Haddock CMS in the near future, but this seems interesting:

There are some impressive performance benefits to be had:


Why PHP running on the JVM hasn’t gotten more attention has baffled me for a while. Python and Ruby (and gazillions of other languages) have been on the JVM (and .NET for that matter) for donkeys. Of course, there are similar projects:

PHP is (IMHO) lovable because it’s such a mongrel mutt. It tries to take the best from lots of languages and is pretty easy to work with. The benefits of using bytecode on a virtual machine are attractive.

I’m not sure why this isn’t on offer everywhere. There are a billion web hosts selling the traditional LAMP package for $7 per month (or less) with ever increasing amounts of disk space and monthly transfer. I’m not aware of any of them that sell a PHP package on the JVM or .NET. I wonder what the complication is.

Niche Link Aggregators

Having just read:…communities

my interest in working on has been rekindled.

I have to admit that my time has been somewhat taken up recently, what with moving to a new country and starting a new job. Any time that I have been able to devote to computers has been spent on Haddock CMS or Oedipus Decision Maker and a couple of other smaller projects.

The plan with the logical fallacies site is to collect examples of Logical Fallacies.

I’m not sure that I agree completely with the author of the article linked to above. There will probably be a shifting focus for the general purpose link aggregator communities. That’s inevitable because the services that is the most popular is by definition is aimed at the lowest common denominator. This means that the functionality of the software has to be the most limited and general.

I don’t want to use existing software for because I want to tailor the site to the problem of identifying logical fallacies. The case may be that there are no specialised needs of this problem and that a generic sollution (like a forum or a wiki) would be a better solution. If that is the case, then I will have wasted my time. I don’t think this will be the case.

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.


When I first took a look at Ruby on Rails, my first thought was that all the code generation scripts were dangerous. It seemed like cut-and-paste programming on steroids. It also looked very useful and I put some code generation CLI scripts into Haddock CMS almost immediately. I quickly gave up on that as I confirmed my worst fears and realised that I was doing the most inflexible cut-n-paste style programming imaginable.

Over that last few days, I’ve been implementing a delta system for database structure in Haddock. It’s pretty rudimentary at the moment but it’s much better than the lack of a system that we had before. It uses SQLite for keeping track of which delta files have been applied to a particular instance of a Haddock project.

In order to write the CLI scripts to create, apply, list and reset the deltas system, I found it quicker to write a CLI script for creating new, blank CLI scripts. I figured that code generation CLI scripts are safe as long as they only generate 10 lines of code or fewer in a single class of a well defined type. Blank CLI script classes fit this description. Before long, however, I had started to write lots more CLI scripts to generate a lot more classes.

I’m not sure if this is going to save a lot of time or getting me to a bad place in terms of code maintenance really quickly. But for the time being, I like the new code generation scripts.

Check them out.