"Where to start?", "What are the issues", and "Main problems". I don't know if we want to continue exploring Selenium and make automated browser testing. If we do, here are some ideas to consider.

I tried SpiderOak for a while last year. While there's a lot of overlap, Dropbox and SpiderOak are different in nature: Dropbox is a simple-to-use file sync service with limited online backup features, while SpiderOak is a complete online backup service with harder-to-use file sync features.

There's a difference to Git and Mercurial (Hg) when it comes to training developers experienced in Subversion (SVN). The basic tools for teaching either system are the same: a system primer, and a cricket bat (or baseball bat if you prefer). However the tools are used in different ways depending on the system being taught.

Daemon does a lot of time and materials work for clients from operational support and maintenance through to feature development. If you're not careful you can die from a thousand cuts as you keep estimating work that folks never follow through with.

Last year the MMORPG, Eve Online, released a patch that had the potential to bugger the operating system install of any Windows user upgrading. This monumental blunder bypassed engineering and QA processes to end up in the hands of tens of thousands of unwitting consumers.

Merging is not all that difficult, but if you are doing it for the first time or you only do it infrequently, you can get a bit knotted trying to work out what you're supposed to be doing. What follows is a little crib sheet for merging. Just happens to be using Subclipse for Eclipse but the same steps apply for any Subversion client.

Recently got back from a great week away at Web On The Piste. Was talking on the topic of Code Management and implementing Subversion. I've included my slides for those that are interested. I've been trying to write up thoughts on version control and the like in the blog, so if you see anything in there that takes your fancy drop me a comment and I'll see if I've got a moment to elaborate.

It’s important to understand that Subversion is a system that records and manages file changes. It’s not a prescribed methodology for managing those files. So while Subversion provides the nuts and bolts for your version control system, you need to agree within your own team how you want to manage your code base. This can be a little overwhelming given the sophistication of Subversion and the multitude of strategies for code management it allows.

Moving to a version controlled build process requires the universal acceptance of key requirements that the development team must adhere to. If any member of the team ignores these requirements, the regime of versioning and its multitude of benefits will begin to break down.

Decentralised development means giving each developer their own workspace: the ability to code in isolation of the rest of the team, to experiment and when their happy, easily share their changes with others in the team. But the fundamental reason for moving to a distributed environment where each developer has their own private workspace is to implement version control. Without version control effective code management is impossible.