January, 2006

Jan 06

Remapping caps lock in X

Really just posting this so that I can find it again when I need it. I spend most of my day in Vim and never use the caps lock. I finally got round to re-mapping it to the escape button by using xmodmap like so:

xmodmap -e 'keysym Caps_Lock = Escape' -e 'clear Lock'

Just got to re-map my fingers now.

Jan 06


Massive sand dune jump near Thurso

I found a couple of old albums the other day so I scanned and added a bunch of photos from when I was growing up. I reckon they’re pretty cool.

Jan 06

Studio 24 lives!

Woohoo! According to the Evening News, Studio 24 won’t be closing after all – they have been granted an extended license despite a campaign from local residents. Looks like Edinburgh techno might not be totally screwed after all :)

I can’t link to it since I’m not subscribed, but I’d imagine there will be some information on this site soon enough.

Jan 06

See no evil

I went for an eye test the other day because I noticed things like signs were a bit blurry after work. I had assumed that, just like my last eye test three years ago, they’d tell me I was A-OK and that the blurryness was from using a computer all day and my eyes taking a little while to re-focus. Which is why I was gobsmacked when they told me I am short-sighted.

It’s not uncommon for folk in their twenties to need glasses, especially ones who work with computers. It happens all the time – I know that. I just can’t believe that I’m one of them. Arthritis, yes. Back problems, expected. But not my eyes. In fact, all my life I couldn’t picture anyone needing glasses less than me. Which is why my first thought was that the test must be wrong and that I would get another. However, basic “can you read that?” tests with Jason and Karl showed that I’m really not as good at seeing stuff as them.

Fuck. Looks like I’m going to join the speccy twot brigade. Right, time to learn about vision.

Jan 06

Moving targets and the benefits of agile development

I’m working on a site at work that had a reasonably well laid out specification. At face value it seems like a pretty straightforward online shop, but when you delve deeper the complexity just keeps unfolding: different user types, wholesale accounts, special cases and little flags here, there and everywhere… A few weeks have gone by and we’ve made some important decisions about how things are going to work. It was OK though and we’ve got a nice user, products and permissions system in place. Everything was going to plan. Then we met the client again, partly to re-confirm some functionality. The project has undergone a meteoric shift, with most of the important parts having some major changes and more than half of the work so far has been made obsolete. Now, while this is without doubt a change to the original spec (and we can therefore re-spec and re-quote the work) it’s still incredibly frustrating to see wasted time and code.

Such massive spec changes are thankfully pretty rare, but it does highlight the inefficiencies in our traditional approach to developing applications and I’m wondering how much of a difference a more agile approach would make. Would showing initial builds of the application to the client much earlier and more often have caught these changes before now? I believe so. This may sound like we have some real problems with our approach, but I don’t think it’s really all that different to the large majority of other web development companies out there and, for a lot of projects, it works pretty well. Also, while we’re definitely becoming more convinced that it’s a better way to develop, implementing a more agile approach isn’t all that straightforward. It requires a big shift in attitude and process and I’m not sure there’s much value in trying to move over incrementally. Like any large change, there is some risk involved.

While our actual programming processes are improving all the time, one of the next, and possibly biggest, hurdles is getting over the fact that we would need to show clients not just unfinished code, but barely started code – and that’s intimidating! As developers, we’re happy working with a really empty shell of a site, understanding that it actually works much better under the hood than it appears and that making it look really nice is a pretty straightforward job. But would our clients understand that? Or would they just think it’s crap, freak out and get all jumpy? My own opinion is that they’d be quite happy with it, but probably only after having it all clearly explained to them – which makes this a client management problem as well as a technical one. Another aspect I haven’t quite got my head around is how quoting for work fits with the agile approach. Historically, I find accurate quoting difficult at the best of times and I’m keen to learn how it fits with the agile idea of being adaptive and reacting to change rather than predictive.

I’m not sure what I’m saying here other than “I think agile approaches are better and I would like us to move that way, but I realise it’s not as simple as just making a decision”, maybe I’m just thinking out loud.