Although I’d delved into the world of AIR before, I hadn’t really had a proper reason to create something. Our idea was simple, a site watcher. All it had to do was fire off requests to various sites and check the response code. Easy. We could build this with HTML and Javascript no problem. Throw in JQuery and you’re laughing.

The great thing about writing for AIr is that you’re coding for one rendering engine, and it’s webkit. This means writing webkit specific CSS rules completely guilt free. Rounded corners and RGBA can make your design pretty without many images. JQuery’s AJAX library is fantastic, it takes the pain out of requests and helps the code stay clean and readable. Within an hour we had a simple app running.

So we kept going. Using a plugin for JQuery the list became sortable, and the list of sites to watch was imported from an XML file. We created a private twitter account to keep a history of changes, and allow notifications via any standard twitter client. We also added a notification window so the app could be run in the background.

The experience was quite enjoyable, and relatively pain free. The only minor annoyances are having to develop CSS / JS without Firebug, but we managed. Aptana studio made for a competent IDE, and it’s code assistance is handy. Would definitely recommend giving it a whirl if you’re at all interested.

The AIR app is now available to download form Boagworld.com: Download site watcher AIR application

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.

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.