Well, after a number of people have suggested that I start blogging, here is the first attempt. I really have little idea what I am going to talk about, but I guess day to day life will provide that.

The first thing that is needed (and this applies to just about anything in life) is a goal, or as it would be known in a software (or any other product) development environment, a specification and a plan to implement it. Without knowing what I want to achieve, I would be staggering around in the dark and might if I am lucky just bump into it, but chances are that even if I did, I would probably stagger on past it.

So, this first blog is effectively the beginning of a spec and plan for starting blogging.

Step 1 - Why blog? (market research / project justification)

The market research for a project provides much more than just a commercial (or in this case personal) justification for doing the project. I believe that is is also fundamental in providing motivation. If there is a good reason for doing something then the whole team can buy in.

Ok - so I'm doing this on my own and want to keep myself reminded of why I am spending many hours of my precious free time doing this. In a commercial environment things aren't that different, it's just that money (or a form of it: time of the people on the team) is involved. To maintain the justification for the cost of the project, I think market research is vital.

At a senior management (not project management) level, people need to know that the project is worth keeping alive. Sadly, in my experience, very few people in senior management have much understanding of development processes. This gets worse when it is something where the massive amount of work that can go into a project is not directly visible (eg. software, IC and electronic design, blue sky R&D, commercial arts like photography or design, system administration etc.). I have to admit that sometimes I have my doubts after a project has started, and my background is in these sorts of fields. I can understand the management who don't have my background finding it extremely difficult. No information is bad news - in the absence of justification, the assumption is negative to anyone other than those who have the skills and understanding to take the justification for granted.

At a project team level, the expertise are different - researchers, developers, designers, testers and all the other vital roles who make up the team that will implement the project. These people take other stuff for granted: how to architect a database, how to attract people's attention, how to make all the components work together and much more. In my experience, good people are more than willing and completely self motivating if they know that what they are doing is worth while. Management often seem to take this for granted and not ensure that the market research gurus pass on their information. I am strongly in favour of all project information being visible to all those with connections to the project.

The fact that these people with the information we need at this stage do take their information for granted is another problem: they don't understand why it is important that they share this information, nor appreciate what information everyone else needs to know. At the same time, the project team often doesn't provide good feedback on the progress of the project which results in jitters among the senior management and ultimately canned projects. I think it is vital that everyone on a team makes ensure that they make the information they have available to all the others on the team in a way that everyone can understand it.

At the end of the day I believe it comes down to one major failing in growing companies as they move beyond a few people: COMMUNICATION. At a small size a company (or team) automatically communicate. The moment it grows beyond a few people this rapidly deteriorates (everyone can't know everything that is going on any more), and management need to ensure that the right conditions are put in place to make this. Now most managers will probably think that I mean enforcing communication, and to some extent this may be necessary (eg. regular project meetings), but I think that encouraging good team dynamics and a little nudging in the right direction is all it takes.

Assuming anyone has bothered reading this far, the one thing I have neglected to say so far is why I am going to blog.... that was after all the whole point of this section!

There are many reasons I am going to blog, but some main ones are:

It forces me to think things through

I have many thoughts and ideas all the time. Trouble is that few of them go anywhere because they are just in my head and I am quickly distracted by other thoughts. Blogging provides a way for me to complete the process, thing through things to their conclusion and write it down where it can be kept and shared with other like minds.

It allows me to share with like minded people

All my thoughts and ideas are going to be of far more value if they can be shared with others. An idea that never sees the light is worthless.

Shameless self publicity

I am brilliant! I am going to let the world know that I am! The world will no doubt beat me back down to size.

Step 2 - Setting up the site (specification)

After some looking at blog software like b2evolution and various other blog packages, I gave up and decided to write my own.

The fundamental problem I have with all of the platforms that I have looked at is that they are just way too complicated, and orientated towards blogging sites, rather than just the odd stand-alone blog. I only need a single-user blog, and right now just a consistent way of presenting basic pages.

The options are almost endless. Just bashing out static pages didn't appeal to me since it makes globally changing the presentation difficult (before some smart ass says - yes I have heard of CSS, but CSS doesn't allow the whole structure and wrapping of the content to be easily changed), and if I want to add stuff like a comments section, RSS feeds and the like, well it just doesn't hang too well with static pages.

I like simple solutions. My requirements are very simple and I want to keep the layout and everything else equally simple. So the solution I decided on was to generate static html pages, but deliver them via a basic php framework that I would write myself. The aim is to end up with some php libraries which can be included into a single php file for the blog, with a single CSS file to deal with look and feel. Changing the presentation is simply a case of changing those 2 files. The php includes provide components which can be dropped into the page as needed which means that the blog can be completely customised with reusable components.

The delivery of the content is really simple - the content is just a .html file in a directory named with a time stamp. The php code strips the wrappings (head, other tags) of the .html file and adds style classes to the tags. That means that the article style can be done through the CSS separately to the page CSS.

This keeps the first stage really simple. I can start publishing stylish pages the moment the initial back-end php components have been written, and then as I go, I can roll more components into the page to add functionality like RSS, comments, pingbacks, statistics etc. Better yet, I can open source the system and hopefully encourage others to develop those components. Maybe I can just start a blog component repository for others developing blogs.

Once I have built up a load of blogs, the next problem will be indexing them. The solution I am doing is going to mean initially that the pages are parsed and indexed every time they are loaded which is clearly not a scalable solution. As the pages grow, this becomes are large overhead and performance is going to suffer badly. I could move everything into a database, but what I would rather do is keep things simple and introduce a simple caching mechanism.

I like the FogBugz solution: a heartbeat URL which is called by a small daemon (or even just a CRON job to run wget under unix). This allows me to leverage all my existing php components to do the maintainance and caching simply by calling a maintainance URL. The maintainance URL can update the caches and any other maintainance tasks for anything else I may want to add in the future.

Now I think I might have done enough of a user / functional spec for the initial implementation, but no doubt I will have more to say for future releases. At the same time, I have also created the first piece of test data to use during development. I told you that I was brilliant! :)