If you were interested in my eatStatic text file-based blog engine, but thought it was a bit techie/immature to consider using yourself, you may be interested in Kirkby and Scriptogr.am.

I was reminded to today of one of my pet hates - coordinating a site build, or a site rebuild when the CMS you are using keeps content, often containing HTML markup from use of an editor such as tiny mce, in the database.

Consider the following scenario:-

• You have a staging site where the client has been using the CMS to input content
• Meanwhile, you make some changes to the database on your local version and want to push them to staging
• You can use a migration script to push your changes to the live database but you find yourself wanting to also copy the new content back to your local database, so you can work on CSS on real content. You then would probably drop your local database and restore from a backup from staging, losing any test content you put in locally

It's basically a bit of a kerfuffle.

This is one of the scenarios that I hope could be avoided with a CMS based on eatStatic (if I ever develop it beyond a blog engine) - any content-types that contain bodies of text, whether thay are marked up with HTML or not, would be stored on the filesystem. This could be put under version control, so you can selectively synchronise your content with another instance of the site.

I can also see a case for some add-on for any existing CMS - an export function that routinely pushes text content from the db into text files to be kept under version control, and also allows import, allowing instances to selectively sync content.

It would be rubbish to stop a tradition after only two years, so following on from my posts in 2009 and 2010, here is a retrospective for 2010 and my plans for 2011. I'm changing the format this time, by dividing into "achieved", "carried over", "ditched" and "new".

Achieved

• Attend at least one web conference - I had an extremely busy year, so didn't get to any of the generic web conferences, but couldn't turn down the international Plone conference, as it was happening in my own city. Although it was specific to a particular open source web content management system, the talks contained enough generic web technology goodness to keep me geeked up to overflowing.
• Get further than "hello world" with Django - Having collaborated on a django project, i've got further than this now, and i'm also using it for some tools used for managing data and assets for Kudos/ Lightplanet
• Use and understand some technologies that i've been ignoring - I'm going to claim that as achieved, on the basis of the points above - i've learned plenty about Django, and python in general. This bullet point will always be carried over though, as there is always something new to learn.
• More on-site freelancing for agencies - It's always tricky finding a balance with this - I did a fair amount of on-site work, but it often got tricky trying to balance my ongoing client work, with the requirement to be on-site somewhere. I'm still open to this, but the other project work needs to take priority, and as such i've started renting a desk in a shared office again.
• Keep Trading and survive the recession - No shortage of work again, so thanks to everyone who gave me work, but i'll keep my fingers crossed and carry this one over again..

Carried Over

• Launch a web app - so close on this one, but the manic run up to xmas and self-enforced work-free xmas holidays stopped me releasing my pet project, working title: Eat Static CMS. The name, some may have guessed is a tribute to a 90's techno outfit, but also refers to the fact that the app uses text files rather than a database. It's a basic blogging engine with niche appeal, I will make it available as a beta ASAP this year, as soon as i've tidied it up.
• Relaunch Too Old To Skate - The site is still in limbo, and still reflects how little i've skated again, which once again I intend to change
• Attend at least one BarCamp - the Bathcamp BarCamp clashed with Plone conference this year, so I didn't go, but want to get to more grass-roots events this year.
• Better Customer Service (By saying "No" sometimes) - I wanted to put this on the achieved list, but looking back I took on too much again towards the end of the year, and customer service suffered as a result, so once again i'll try to find the balance in 2011

Ditched

• Get to grips with Plone 3 skinning - Plone has moved on and so have I, but this doesn't mean i've given up on Plone, but I don't plan to do any Plone 3 work. Plone 4 skinning/ theming is still on my list, but that's a whole new technology, and a technology that can be used independently of Plone.
• Put up a proper portfolio - I just can't imagine having the time to do this - I think potential clients can find out whether I have the skills and experience they need by looking at this blog and my linked in profile. As i'm more of a programmer than a designer, a visual portfolio is less important to me. Maybe if I run out of work i'll rethink this one?
• Fix on a PHP framework - until someone (me?) builds a PHP framework that is basically identical to Django, with it's production-ready admin forms and API as standard, i'll just use whatever seems right at the time, or no framework at all.

New

• Buy a new Bass Guitar and play the hell out of it - I horrified some of my older friends by selling my one remaining bass last year. I sold it as I had completely stopped playing, and having it hanging on the wall just seemed a waste. Most people i've befriended in the last 10 years don't know I ever played. Playing bass in bands used to be an important part of my life - I've actually been playing bass for over 20 years and was once pretty good (if I say so myself!). I sense a mid-life crisis coming on in the next couple of years, so I need to get back in practice for when I inevitably decide to form another band!
• More "work from anywhere" adventures - I spent 6 weeks touring in Europe with my wife and son this summer, working from my laptop to earn money as I went. It was brilliant, so hopefully more of these adventures, the same or different in 2011
• More blogging! - including some personal blogging. I think i'll need to divide this site into "babble" and "techobabble" - not everyone who reads this site looking for a CSS hack will want to read my self-indulgent drivel and not everyone who reads the site wanting to know how I really feel about the experimental bass playing style of jaco pastorious wants to read about the new python module i've started using, so i'll provide the opportunity to follow from both a techie and non-techie viewpoint, although it will all still be one blog. Looking back through the archives of this blog, i've been doing this over the years anyway, going through phases of techie and non-techie content.

Really informative and interesting article about CMS use over at Boagworld. (Hugely trivialised) summary: Content Management Systems don't kill websites - people do.

When it comes to Content Management Systems (CMS's), i've been "round the block a few times" so to speak, having spent the last ten years mostly working on CMS driven sites - starting with bespoke classic asp/ MS Access (shudder) back in 1999, before moving onto bespoke php/mysql systems, wordpress, drupal, zope/plone and dabbling in countless others. My conclusion: there is no holy grail, because the people developing and maintaining the code and content vary, and there are other important factors. Therefore I always take time to decide on the best approach for each project.
It is rare that I get a "greenfield" project where I am free to start from scratch. Without getting right down to weighing up the pros and cons of individual systems, here are some of the factors that help me (and my clients) make a decision:-

• Will I be starting from scratch or building on something else?
• Am I working alone, or with one or more other developers?
• Does the client have a preferred technology i.e. if they already have an intranet written in a particular technology, it makes sense to use the same for their website. (Unless of course they hate their other systems - it might be a good bargaining point to go a different direction altogether!)
• What's the content like? - is there a large amount of text content, categories and pages or is it "snippets" of text that need to be editable, amongst otherwise highly graphical content?

Commercial Content Management Systems I'm not going to talk about the "big" commercial CMS's - the only people they are useful to are the people who's job it is to go and buy a CMS license, companies who own or sell the software and companies who have made the investment to become specialists in such systems. That counts me out, and as i've never heard a developer, designer or content manager singing the praises of such a system (entirely the opposite), i'm going to presume they are all overpriced rubbish, and talk about what I know! I know that sounds flippant, but I refuse to believe that any of the vendors of the expensive, closed commercial systems have solved problems that a community of thousands of people working on competing open source systems haven't. Also money saved on an expensive license can be spent on support, maintenance and customisation of a system with no license costs. Which brings me onto...

Off-the-Shelf open source CMS's One obvious route is to use one of the mature, all singing and dancing systems like Plone (zope/python) or Drupal (php/mysql). They are easy to install and have a comprehensive feature list, but usually one other thing in common - voodoo. By voodoo I mean a whole load of essential code deep down in the architecture that your average web developer (counting myself here) isn't supposed to touch, and can spend hours/ days working out how to hook into it to make seemingly simple changes. For someone who becomes an expert in the system, they have full access to the code, so become familiar with the hooks and this isn't a problem. For the charity/ company/ organisation where the development budget has run dry, it can be tricky finding anyone (available) who can work on it. If the content maintainer likes the admin interface these can work out really well, if they don't it can be a ton of reverse engineering to make it "work" for the content manager.

Bespoke CMS's On the other extreme you have a bespoke CMS written from scratch giving the developer fine grained control over everything they need to do, and easily picked up by another developer, provided that it is sensibly written. However, as developers usually have their own way of doing things, it may take another developer time to learn how the system works before they can make changes, or they may want to re-write it altogether! The downside of any bespoke system is that it can take months to build features that you get for free in an off the shelf system. I often build a bespoke CMS where I need to bolt new functionality onto an existing system, where there isn't enough budget to start from scratch.

Bespoke CMS built on a framework In between are bespoke systems built on a framework (such as Cake PHP, Ruby on Rails, Django), so much of the repetitive coding work (such as user management and admin forms) is handled for you, but it's still a bespoke system. The downside of these is that you need a developer who already knows, or is willing to take the time to learn the framework. The upside is that new functionality can be added quickly and in a consistent manner by someone familiar with the framework.

"In-House" CMS
By which I mean a bespoke CMS which isn't written from scratch each time, but a mature "tried and tested" bespoke CMS built and maintained by an agency or developer, then reusued or repurposed for each new project. The advantage of this is that the developer/ agency have a high level of familiarity with the system, so are able to make fine-grained changes as required, that they may not be able to make with other systems. The disadvantage is that these can be the trickiest systems to be picked up by another agency or developer, and their may be IP issues (see below)

Intellectual Property / licensing I've already said that i'm not going to talk about the commercial CMS's, but one consideration when choosing which way to go, particularly with a bespoke CMS, is what happens if you were to move to another developer or agency? Will the source code and database files for your CMS be handed over along with the website or are you going to have to license it /buy it/ start again? Also what would happen if you wanted to sell the website and CMS on at a later date?

Standalone vs Retrofitting This refers to the last of my bullet points above - not all websites are the same. Some (like news or university websites) are text-content heavy, with hundreds or maybe thousands of pages and categories, and some websites have highly designed (as in graphic design) content.

In the latter scenario it is often better to build the site as static HTML first and retrofit a simple CMS later. The bulk of the work in building such a site will be in getting it looking and behaving correctly, and their may need to be lots of fine tuning to the layout, which is easier if you aren't reverse engineering a theming system. Moreover, the text content may be confined to small snippets of text, or a simple news blog, which can easily be plumbed in later.

The former scenario would suit an off-the-shelf system that works standalone - i.e. one that allows content editors to start populating content before the templates are finished, which are then applied as a skin/theme later - it may even be the case that the site can't really be designed properly until the architecture and content are in place.