There are no plans to release Liaison Profile as an open source project but it’s not out of the question if there is interest in it.

The project has been running for a long time which is probably due to me trying to be ‘agile’ and using the prototype software as the spec. What this meant is that everytime I’ve showed it to the focus group, they have thought of lots of things they’d like it to do differently and we’ve never settled on when the project will be officially ‘finished’. So I’ve had to resort to the old-fashioned and boring technique of writing a requirements specification and seeking agreement on that.

My approach to requirement specs is to try and be workflow oriented so that I’m describing what the users will be trying to do rather than what the software does. In my opinion, this makes the spec easier to read and understand and possibly allows you to identify what the important things are.

I used Wink to make this as I find it pretty easy to use and it is open source. We also have a licence for Adobe Captivate so maybe I will pitch them head to head and put a review here in case anyone is interested.

Usually, the best way to address the addition of functionality in orthogonal domains under a template class is to define an interface for each kind of functionality and inject an instance for each.

Oh well, I’ll have to remember this for Fez 2.0.

• HTML and PHP files can be easily stored in subversion but how do you track changes to your database schema? A way around this is to use a migrations scheme similar to Ruby on Rails which can store your DB changes in a SQL script which can be put under revision control. It requires a lot of discipline but means that in a small team, others can do an svn update and then run the a ‘db upgrade’ script to get the latest database schema and even changes to default config data. Obviously you have to be a bit careful as it’s not simple to do a rollback of your database so it is still suboptimal.
• File permissions on webservers are often important. It’s useful to have a script that you can run after a svn update or checkout to make sure that files are correctly writable by the webserver when they need to be (It’s also good to reduce the need for this in the first place). If the script is under version control then new server writable files can be added to it as needed.
• Using subversion to rollout a live site helps you track exactly which version of the site is running. We use a seperate branch in subversion for the live site as it often has a few little customisations that aren’t in the main development branch. We can tag in subversion each time we do a rollout.
• On a live server, different users might need to update parts of the site at various times but the svn client wants to always set the .svn/entries file to be read only and owned buy the current user. This is a bit annoying especially if you don’t want you svn users to have a root ssh account or ability to change owenership of other users files on the server. One way to get around this is to have a ‘svnuser’ that people can login as to do the updates on the live site. However when commiting from the live site, the real username of the perpetrator is then lost (or you can restrict the svnuser on the live site to svn updates only). So there is extra complexity at this point making use of subversion that little bit hard.
• Which brings me to my last point which is that subversion has a learning curve for new web developers coming to the team – they need to be trained on how subversion is used in your organisation and get used to the habits of remembering to commit schema changes and comment commits appropriately etc… If your programmers have never come across revision control before, at least subversion has an excellent online book which walks through all the concepts.
• WebSVN has proven to be a helpful addon as we can subscribe to the commit messages via RSS and keep in touch with what’s going on. It can also link in with our ticket system if we reference a ticket number in the commit message which in turn puts a link to the WebSVN commit record in the ticket.

Even though we only have a small development team, subversion has allowed us to work in parallel on things, using our own staging areas and databases and still share our progress. We still have to think about how things are going to play for the other programmers when we do a commit but most of the time, the benefits of the RCS far outweigh the overheads of spending extra time to write commit messages, writing schema upgrade scripts and mucking about with subversion’s quirky permissions.

Even though we sit next to each other in the office, our development team has been communicating mostly through campfire lately because we can just cut and paste code and links to each other and still be working on our code in another window and even listening to music. We don’t need to interupt each other when we are trying to concentrate on solving a problem – we can zone in and out of the group chatroom easily.

We have also had a couple of lurkers from other development groups who collaborate with us a bit on the Fez code. It has been good to have the occasional outside comments on what we’re doing and I think it has been helpful for them to know what kinds of bleeding edge development we’re doing.

Fairly early on, we told our manager about the chatroom and invited him in too. I was not sure whether allowing our mangers into the chatroom would be a vibe killer but it has worked out quite well. Obviously this depends greatly on the kind of management you have but in our case I think it has served in two ways – our manager can get that warm fuzzy feeling of seeing the team actually getting things done™. For some of the other staff here who are supporting our actual users, it has meant that at least one of us is paying attention to answer questions (usually) while the others of us might be in full-code-imersion mode. So there is the counterintuitive result of less interruptions.

IA One Sheeters

One-Sheeters are quick and easy marketing tools for information architects. They’re like mini brochures to advertise IA deliverables and promote the IA practice in your company. One-Sheeters help people envision what deliverables you produce and where they fit into a project. They’re quick to produce and easy for anyone to understand.

As a bit of an open source junky, I thought I’d have a go at Paint.net as a lightweight image editor. I opened the icon, created a new layer, selected the two bits of paper with the wand tool, pasted grey onto the top layer and then changed the transparency of the layer until I could see the paper icon underneath. Paint.net was pretty easy to use and it’s free so I recommend if you are just doing simple tasks and don’t want to pay a license for full-on image editing software.