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.

Snippets of Latin

I’m currently reading Edmund Burke’s Reflections on the Revolution in France.

I find the text very interesting and feel that a lot of the content pertains to open source software. Repeatedly, Burke argues for gradual improvements to existing systems that have been constructed over time and shaped by actual demands rather than sudden revolutions of men of ideas but little experience. At its best, the open source movement offers software that has evolved in the gradual way, with bugs eroded over time. Something that attracts me to free software more greatly recently is that it can’t be taken off the market. Microsoft have stopped selling XP, sort of. I don’t want to be forced to move Vista. The designers of the original UNIX probably never thought that that OS would still be in such widespread use in the 21st century but here we are. Are there better systems? No doubt. Do I want to “upgrade” all my servers to anything else? Not on your nelly.

Of course, many in the open source movement might see themselves more like the revolutionaries, sweeping away a corrupt monopoly and replacing that with a free utopia. Reality doesn’t reflect that. Where the advocates of free software have presented themselves this way, they have succeeded the least.

A problem that I have encountered whilst reading has been translating the frequent quotations in Latin. Although I studied Latin for six years at school, I can’t remember much more than to parrot off “Bellum, Bellum, Bellum”. A typical problem of a language education focussed almost exclusively on syntax. I cut and paste the sentences into google but more often than not the only results returned are other copies of “Reflections” (of which there are plenty).

Does anyone know of a good repository of Latin quotations? It could make quite an interesting CRUD page (e.g. quotation, original text, original author, texts in which it appears, possible translations, votes for translations and so on). But I don’t want to build such a page as I don’t know enough Latin and I’m sure that something similar must exist already.

Niche Link Aggregators

Having just read:


my interest in working on logical-fallacies.net 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 logical-fallacies.net 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.

Common Language Errors

I recently started working as an EFL teacher in Seoul, South Korea. I like this work a lot and I am planning to work as a teacher for the foreseeable future.

However, you can’t go from being a web programmer to another career and leave everything behind. You see possible computer programs wherever you go. I can see the need for Haddock CMS (or RoR or whatever…) projects all over the place. My new employer’s time-tabling system and vocabulary database would be a lot more simple if they were web based system rather than MS Access and Excel based.

Another project that I thought might be quite interesting to start is one to track common written language errors. From marking book reports and tests, I’ve seen quite a few common errors in language already. For example, “The mother was see the child” and variations along those lines are extremely common. I don’t know enough about the Korean language to be able to say why so many of my students should make that mistake but my assumption is that there is probably a grammatical structure similar to that in the students’ native tongue.

If I get time, I would like to start a project that allows EFL teachers to log these sorts of errors on a web site. There are EFL teachers in every corner of the world now and they a grow online community. It would be interesting to see a student’s native language affects his production of English. This might help teachers to decide on which areas of language to focus their classes.

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.

New CLI Script class in Haddock CMS

Haddock CMS has always been intended for running programs at the command line as well as on a web server. Separating the interface from the meat of the program has always been an aim, so where the programs are run shouldn’t matter.

So far, command line scripts have been been contained in .inc files. This has worked quite well but it’s overly complicated and hard to maintain.

CLI scripts are now contained in classes that extend a class called CLIScripts_CLIScript. To run a script, first a set of script object runner scripts are generated. These use the reflection API to run the code in the class.