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.

I couldn’t find a plugin, and thought it would be very web 2.0 to have my current location on my blog, so decided to write a plugin. Turns out it’s much easier than I anticipated, location is pulled from the published XML and stuck into a static Google map. Easy.

Seeing as it was so straight forward, I went the extra step further and made it customisable from the plugin admin section. If it’s of any interest to anyone, here it is:

Download iBrightKite

Update: The plugin has been approved by Wordpress. Success.

Update: I’ve made some changes, the plugin should now be compatible with PHP4 (in theory) and locations can now be cached. If it didn’t work before, please try again.

Following Future of Web Apps I felt inspired to start blogging properly. By properly, I’m not gonna start writing novels, or even short stories. Just short notes, about things that interest me. Starting with things that interested me from FOWA London 2008.

Where we are today with Web Apps.

Right now we are at a point where we all regularly use web applications, not just for novelty, but as a system we rely on. While Google docs doesn’t even come close to Microsoft Office, and Splashup ain’t no Photoshop, the way these site are built are like applications, not websites. 280Slides is a classic example of a web app that looks and behaves like a desktop app, and with newer browsers running javascript faster and following more CSS rules, exciting times are ahead.

What was really interesting was a comparison between Combo VCR / DVD recorders and Silverlight / Adobe AIR. Adobe AIR takes the web app to the desktop, so web designers can build websites that run like desktop apps, is this bridging the gap between your desktop and the web? It’s kind of a backward step to help bring people forward, if that makes sense. If everyone was always online, and web apps shared and co-operated better, we wouldn’t have such a need for a desktop. Eventually. There is a lot of buzz about ‘Web only operating systems’ and most of this is naive or rubbish, but people are slowly changing their perspective. We just need to build the tools.

Good times / Bad times

At the moment, there is much talk of the crunch. Tim Bray made some interesting comments about surviving, most memorable for me was being flexible. If you’re a Ruby developer, learn PHP. If you’re already a multi-talented developer, learn CSS, or photoshop. If people have to be let go, the 1-trick-ponies will be the first. It never hurts to learn a new skill.

The importance of an online presence was also heavily stated, first thing many prospective employers do is Google your name. If you have a blog, twitter, or contribute to open source projects etc. you will appear more interested in the web and a stronger candidate. This is partly why I’m blogging (interest in the web, not because I’m looking for a job!!)

The importance of networking

I was genuinely surprised by how many people had heard of Headscape, the company I work for. Paul Boag has been busy. As a result, Craig & did meet a number of interesting people, and had an awesome time. Networking is vital in an industry as competitive as web design / development.