Dave McDermid

Here at Headscape we’re quite keen on XML, in fact our CMS is heavily based on it, to the point of ignoring a few relational (normal form) database rules. This gives us a lot of flexibility, along with a number of interesting problems. This will no doubt be the first in a series looking at how we tackle these issues, and why.

First off, a brief introduction to how we manage our data. Fragments of data that are used to build a web page are stored as XML in separate records in one table and associations are stored in another. That’s the basics. Meta data (such as created dates, published flags etc) are fields in the table, but the page data itself (title, category, body) is stored in a single XML field. To generate a web page, the required XML is collected, nested, transformed, and returned. Simple.

This allows us to deploy a generic database for a website and customise the fields that the user wants to use in XML schemas that we define. We have a nifty CMS that reads our XML schemas and provides the user with the forms to manipulate the data. The XML schemas are file system based, so are easily source controlled and transferred between projects.

When it comes round to styling the front-end site we transform the data in whatever format is required. We can create HTML, RSS, Atom or bespoke pages by defining new transforms. The hidden benefit here is that the XML, regardless of content, follows consistent patterns across our sites, allowing developers to switch between projects with ease.

I’m a .NET developer, that’s my job. I work with Windows Vista, it’s convenient for building .NET applications. At home I have a MacBook, and use OSX 10.5 (Leopard). Why do I do this? It’s not just because of software or compatibility, even though these are good reasons, they just don’t make for interesting reading.

1. Ignorance hurts only ourselves

Because although we all have our preferences, ignorance hurts only ourselves. As convenient as it would be for the whole world to switch to a single perfect OS, or at least the best available, it just ain’t practical, or sensible.

2. Opportunity

Clever chaps who can still program in assembly languages are never short on jobs, if anything their prospects increase as their skills become rarer. Large companies with an existing code-base often can’t afford the time or resource to rewrite systems from scratch to keep up with the latest trends in programming.

While Vista tends to frustrate me, so does Leopard from time to time. We learn to deal with it. If I decided, as so many do, to pick an OS and announce that all others confound me, I’d be limiting my career, my skills, and my friends.

3. Versatility

I’m in 2 minds over this one. On the one hand consistency helps us work faster, on the other hand versatility keeps our brains ready for change. And change is good. I rarely have a problem with Ctrl+C / Cmd+C, or with the location of close window buttons, my brain seems to happily switch contexts. Most people work hard to carve patterns and routines into their minds, and resist change like the devil. Change necessary, it is good to learn to deal with it.

4. Competition

Everyone knows competition is good, it drives business. As long as I don’t directly work with either Microsoft or Apple, I can happily encourage the use of both. While building GetSignOff we found competing products inspired us, and spurred us on to build a greater product.

5. Make friends & Alienate people

I love being able to talk knowledagbly with Mac fans and Windows fans alike, despite often being accused by both sides as a traitor. Making friends is great, and ridiculous comparisson based arguments are fun, being a regular on both sides of the game makes life more interesting. And life just ain’t worth it if it ain’t interesting.

What does everyone else think? I’m not the only one, why do other people? Other than, ‘I have to’, of course.

Over the years, Headscape has built and worked on a lot of websites, probably somewhere in the hundreds, no-ones counting. I, on the other hand, have been with Headscape for just 16 months. Currently we have 4 full time developers plus a contractor. Usually we are all working on different projects, each with their peculiarities and oddities. Often a client requires us to make changes to an old site, upgrade hosting or change the way features work, and without knowing the history of a project, this can be a minefield.

So we needed a solution. Turn’s out wiki’s are quite nifty at this.

We tried out a few, and being a .NET company, experimented with a few free or open source options, but ended up settling on MediaWiki. It’s easy to setup and get started, reliable, and there are heaps of plugins floating around. The hardest part is content population, but once a couple of us got excited about the idea, we soon had the foundations of a knowledge base.

The benefits of a wiki are clear, being able to link information together and categorise it is invaluable, and the principle of quick editing is ideal. This allows us to gradually build up the fragments of information that hold a project together. Projects that are linked by a technology or hosting platform can be easily referenced, enabling a developer to solve problems faster and track down solutions smarter. Eventually, maybe. The experiment is too early to see how well it’s going to work, but it should be interesting.

The downsides to this approach are learning curves and structure. MediaWiki is designed for managing large numbers of isolated pages, so naming conventions are crucial to finding information and avoiding confusion. Fortunately, wikipedia has already developed conventions ready for adoption, so this is a good starting point.

Before installing MediaWiki, I had little experience with wikis, so it took some learning to get up to speed with formatting, but it soon came naturally. This can be a stumbling block for others, so the next step is to ensure everyone has a basic understanding of editing a page. Having knowledge of wiki editing is a skill in it’s own right, so the time spent learning is worth it.

We’ll see how things pan out.