Archive for January, 2009

MySQL Connections Plug-in for Haddock CMS Projects

Saturday, January 31st, 2009

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

http://haddock-cms.googlecode.com/svn/plug-ins/mysql-connections/trunk/

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.

The Sum of Human Knowledge

Thursday, January 15th, 2009

On the talk page for the Wikipedia article on the Postliterate Society there is a curious form of a logical fallacy:

Literacy is a particular interest of mine, and I have never heard of this. I would recommend deletion.

This seems to be an odd way of thinking for someone helping to write an encyclopedia: I’m an expert; I’ve never heard of this; this, therefore, cannot exist.

One truth that I am continually confronted with (especially when I visit Wikipedia) is that there are more things that exist than I have heard of. This is especially true in the areas in which I consider myself an expert.

One-liner to SVN delete files that you have already deleted.

Saturday, January 10th, 2009

The following one line shell command allows one to delete files from your file system and then removed them from Subversion.

svn stat | grep '^!' | sed 's/^! *//g' | xargs svn delete

I worry about something like this happening to me every day…

Wednesday, January 7th, 2009

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

Monday, January 5th, 2009

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

http://haddock-cms.googlecode.com/svn/core/branches/remove-modules-from-core/

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.

http://haddock-cms.googlecode.com/svn/core/tags/2008-08-10/

or (currently)

http://haddock-cms.googlecode.com/svn/core/trunk/

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

http://haddock-cms.googlecode.com/svn/plug-ins/db-pages/tags/2009-01-05/
http://haddock-cms.googlecode.com/svn/plug-ins/mailing-list/tags/2009-01-05/

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.

One-liner to make sure svn updates work

Sunday, January 4th, 2009

I’ve been having problems getting Subversion updates to complete reliable of late. I have an enormous working directory called ‘programming-projects’ that is basically a large list in svn:externals. It’s useful to be able to go to the root of that working directory and update everything at once. This is especially useful for checking the development versions of projects that are using the latest versions of Haddock CMS.

However, normally before all the directories have been updated, one of the external servers will return a 502 error (or similar) and the process will die. The best solution that I’ve found so far is to run the following command:

perl -e '$r = 1; while($r) { $r = system("svn up") } '

It simply keeps calling svn up until it is successful. It’s not very elegant, but it works. Is there an argument that you can give to Subversion that will achieve something similar?

Squid … for Seagulls

Saturday, January 3rd, 2009

There are lots of odd ways to advertise foods. One of the strangest, that I see everywhere in Korea, is to have a restaurant which specialises in a particular meat have a cartoon version of the animal that supplies the meat winking and raising an approving thumbs up on a bill board.

This packet of dried squid was a little as the picture on the packet suggests that squid is more suitable for seagulls than for humans.

2009-01-03-Squid-for-Seagulls

Very good it is too.

When to use the trunk directory in SVN?

Saturday, January 3rd, 2009

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

http://haddock-cms.googlecode.com/svn/core/trunk/

but I’m working on the code at

http://haddock-cms.googlecode.com/svn/core/branches/remove-modules-from-core/

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

http://haddock-cms.googlecode.com/svn/plug-ins/mailing-list/trunk/

got copied to

http://haddock-cms.googlecode.com/svn/plug-ins/mailing-list/branches/remove-public-html-from-core/

and

http://haddock-cms.googlecode.com/svn/plug-ins/db-pages/trunk/

got copied to

http://haddock-cms.googlecode.com/svn/plug-ins/db-pages/branches/remove-public-html-from-core/

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

http://haddock-cms.googlecode.com/svn/plug-ins/db-pages/branches/remove-public-html-from-core/

to somewhere like

http://haddock-cms.googlecode.com/svn/plug-ins/db-pages/tags/2008-01-03/

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

Friday, January 2nd, 2009

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


https://haddock-cms.googlecode.com/svn/core/branches/remove-modules-from-core/

and the various plug-ins can be found in

https://haddock-cms.googlecode.com/svn/plug-ins/

New Year’s Eve 2009

Thursday, January 1st, 2009

I had a great New Year’s Eve. My Korean friends all advised me not to go to Bosingak because of the crowds, but I ignored their advice and went anyway and am glad that I did. We did almost get crushed at one point.

2008-12-31-NYE-Seoul