james mckay dot net

A colleague of mine mentioned to me the other day that I ought to read The Mythical Man-Month by Fred Brooks. I haven’t done so yet, but I was interested to see from the various reviews that it talks about the “second-system effect” — that the second version of a system that you design will tend to be over-engineered, since it has all the features that you thought about for the first version but didn’t implement due to time constraints. It means going from a small, elegant, successful system to something large, feature-laden and bloated. Scope creep, in other words.

I’ve been thinking about this as far as the next version of my Comment Timeout plugin is concerned. The original idea was quite simple: to close comments on your blog entries after a certain length of time. The current version has extended well beyond that remit, with a whole bunch of other features that, while useful and maybe related from a technical perspective, aren’t really related from the end user’s point of view to what the plugin is ostensibly trying to do. I wonder if this is probably a bit confusing for users and making it a bit difficult to determine whether issues are due to bugs in the code itself or people misunderstanding what it’s supposed to be doing.

I think the answer is probably to separate it out into different plugins, each of which concentrates on doing a single thing and doing it well. At the moment, I’m thinking of separating it into three different plugins, perhaps something along these lines:

• Comment Timeout 2.0: a trimmed-down version, which concentrates solely on the job of closing comments on old posts after a certain length of time.
• The Black Hole: the functionality to nuke comments altogether if they contain BBCode, too many hyperlinks, or certain keywords, so they don’t even make it as far as your spam queue.
• Three Strikes and You’re Out: the bit that examines your Bad Behavior logs and spam queue and closes comments to IP addresses that are persistently causing trouble.

I’d be interested to know what people think of this idea. Would it make it easier to understand, or would it just make things a bit more confusing? Leave me a comment and let me know what you think.

Comments closed (6) »

Posted at 08:15 on 26 April 2007.
Tagged: wordpress

One of my tasks this week has been to roll out some changes to a fairly busy web application. Because it is pretty heavily used, when we make changes we need to get it right and minimise downtime.

How do you do this? Script the upgrade process. Ideally, you should be able to simply copy a working build to the production server, hit a button (or run a script) to switch from the old version to the new one, and you’re done.

This particular web application’s upgrade process is very simple. You get the code files from the build that you want to deploy and copy them onto the web server — into a new directory for each version, e.g. “html-3.14″. You change a symbolic link at the web application’s root that points to the version you want to use. You’re done. Rolling back — should things go pear-shaped — is simply a case of changing the symlink back again.

To get this working effectively, I had to streamline the application itself. Some files, such as site configuration, may vary from one server to the next, so I had to separate these out. I partitioned the application into three directories: the code, the configuration files, and dynamic data, such as logs and uploaded files.

Only the code directory changes between versions: its contents are exactly the same whether they are on the developer’s machine, the staging server or the live server, and it has no special requirements in terms of access rights or contents. Files that need to vary between different servers (such as configuration files) are kept in a separate directory and are not changed during a normal upgrade process. This makes the upgrade script very simple.

This explanation is probably a little bit simplistic, although it can easily be extended to take account of extra requirements such as changes to the database schema or addition of new configuration options. Some upgrades will also have much more complex requirements, but the general principle is the same. Script the upgrade process so that it runs in a single step. It’s the same principle as the one Joel Spolsky makes when he asks in The Joel Test, “Can you make a build in one step?” If you have to edit several files and jump through several hoops, the risk increases that you will make a mistake somewhere along the line. Being able to do it all in a single step is much more robust, and mostly seamless from the end user’s perspective, because if all goes well, they will notice no downtime, but only that there are some new features and some irritating bugs have been fixed.

Comments closed »

Posted at 18:06 on 24 April 2007.
Tagged: deployment

The signs in stations on the London Underground direct you to platforms for a particular line heading in a particular direction — for example, the eastbound Circle Line, the northbound Jubilee line, and so on. The different lines are all colour coded — the Circle Line is yellow, the District Line is green, the Bakerloo Line is brown, and so on. With many platforms being shared by two or more lines, one would expect that the trains themselves would arrive indicating primarily which line they are running on, preferably with the same colour coding fairly prominent, right?

Wrong.

The trains themselves, and the notice boards on the platforms, indicate only which station is their final destination. There is no clear indication of exactly which line they are running on. When you are on a platform that is shared by two different lines, this can cause quite a bit of confusion if you are unfamiliar with the routes themselves, and, as is often the case on the Underground, you have only seconds to determine whether the train on the platform is the one you want or not before it closes its doors and heads off into the unknown.

Take what happened with the five of us who went up to MiniBar last night as an example. After some debate on the way back as to whether we should walk to Aldgate East or Liverpool Street station, we decided to head for the latter. At Liverpool Street, you head for the eastbound platform and take a Circle Line train. The Circle Line turns south then west after Liverpool Street and reaches Victoria after a dozen or so stops.

The train on the platform was the one for Barking. Okay, fine, where’s Barking? These trains stop for less than a minute, so rather than find a map and then look for Barking to see if this was the right line or not, we collectively decided to jump onto the train with only seconds to spare, and then ask questions.

We were halfway to the next station before we realised that Barking is, of course, at the end of the Hammersmith and City Line — i.e., heading in completely the wrong direction.

Not to worry, however. You get out at Aldgate East, cross over to the platform on the other side of the tracks, and catch the next District Line train heading west, arguing vigorously all the way about whose fault it was that you ended up on the wrong train in the first place.

The only problem is that you have the same problem on the other side. We had arrived on the platform and were scrutinising the map when a train came along. “Hammersmith via Kings Cross/St Pancras.”

The same individual who led us onto the wrong train in the first place now embarked on this one, and most of the rest of our party would have done so too, but for the fact that two of us had already figured out that this one was also operating on the Hammersmith and City Line, which does not go directly to Victoria, and would merely have taken us back to where we started.

Fortunately we managed to convince them to wait on the platform until we had determined which train was the right one before getting onto it, and eventually we ended up on the right train, but by this time, we were beginning to come to the conclusion that the game of Mornington Crescent bears a lot more resemblance to reality than originally intended.

Comments closed »

Posted at 09:06 on 21 April 2007.
Tagged: miscellaneous