magpiebrain

Using a Dilbert cartoon as an example of why your manager is wrong is not an example of good consultancy skills.

Recieved from Amazon on the 7th of November:

Dear Amazon.co.uk Customer,
We’ve noticed that customers who have purchased Hot Fuss by The Killers have also ordered Hot Fuss by The Killers. For this reason, you might like to know that Hot Fuss will be released on November 21, 2005. You can pre-order your copy for just GBP 11.99 by following the link below.

Mind you, I enjoyed it so much the first time around…

…as Civilization IV: has arrived

Good developers create good technical solutions to problems.

Good consultants find that delicate balance between being themselves and not being themselves that enable them to get the job done for the client.

This was driving me nuts for ages – I couldn’t work out how to turn off that annoying beep you got whenever an auto-completion had multiple or no hits. Anyway, it’s a ReadLine configuration (so it’ll apply to any shell using ReadLone) – edit (or create) .inputrc in your home directory, and insert the following line:

set bell-style off 

Finally – peace!

Carlos make a very interesting point concerning my suprise that Flickr haven’t invested in functional testing:

…[not testing can incur] less upfront [costs] and more maintenance costs over time. As a startup (well, before they were acquired by Yahoo, anyway), this makes sense: the whole point of a startup is that you can do riskier things, and they guessed at some point that automatically testing anything but the most significant bits (smoke tests?) wasn’t as important as getting code out the door, fast, and obssessively listening and reacting to user feedback. This probably required keeping insane levels of attention to detail and commitment, which is quite rare I might add, but a great part of what I attribute to their success.

That certainly seems to tally with how the Flickr team went about spending money during their early years (and software is nothing if not expensive) – they only spent money if needed. The problem with developing an application without testing in mind, is that it can make testing at any level other than functional very difficult without restructuring after the fact (whch by definition is harder without lower level tests).

It is certainly possible the Flickr team decided not to test due to the percieved cost of testing – I wonder how many PHP developers back when Flickr was developed were aware of the testing options out there? They certainly didn’t have Selenium, and I doubt FIT was up to much back then. Without such higher-level functional testing aids, the cost of developing in-house functional tools (or bringing in something expensive and complicated like Mercury) may well be prohibitive.

On the other hand, is the average PHP developer interested in testing? Take a look at the testing tools available to the large PHP community – then compare it to the wealth of tools and API’s available to Java. There seems to be nothing like the same demand amongst the PHP crowd for such tools. It may well be of course that PHP projects are on the whole smaller scale and less complex, and therefore have less need for higher-level testing tools.

I’d like to think that the fact that many PHP developers now seem to be trying out Rails (and by extention I expect to see them trying out Django if/when it gets more hype) is a sign that they realise being more rigorus in their development approach is important, and that a more advanced language will make it easier to embrace programming techniques such as OO (even if some of them do think it is insane 🙂 ). But the cynic in me still thinks most of them are being attracted by great Ajax support and the percieved benifits of scaffolding.

Dr Dre and Burt Baacharach have collaborated on a new record

This according to the Observer Music Monthly – as if Jamie Cullum guesting on the latest Pharrell Williams album wasn’t weird enough. I’m bracing myself for the inevitable rise of easy listening crunk.

The Fall’s Mark E Smith to read the football scores on the BBC

This scoop also courtesy of the Observer Music Monthly. I’m sure John Peel would approve.

Samuel L Jackson to star in “Snakes on a Plane”

What is it with people with middle initials this week? Anyway, appalling title aside (and after The Man you’d assume Samuel L Jackson might be looking for something a little more – well, high-brow), the synopsis should say it all:

On board a flight over the Pacific Ocean, an assassin, bent on killing a passenger who’s a witness in protective custody, let loose a crate full of deadly snakes.

Dear god, did no-one learn anything from Anaconda? I have absolutely no hope for Jackson’s Black Snake Moan.

On the 28th and 29th of November, XP Day 2005 will be held in London. Organised by the local Extreme Tuesday Club, XP Day (tag line: “More than XP, more than one day”) will be hosting multiple tracks for beginners, journeymen and experts alike. I really encourage any of you interested in agile development to come along – it’s surprisingly good value.

This year, I’m happy to be presenting the Lego XP game which I developed as a teaching aid for our company. Unlike the more traditional XP game (which introduces some of the central tenants of XP and agile development with the help of balloons, playing cards and dice) the lego version makes a clearer link with the development of software, introducing such concepts has regression bugs, refactoring and technical debt. Expect a fuller writeup after the event.

It was with some disbelief that I sat through Cal Henderson’s otherwise highly entertaining (and to be recommended) Building Flickr Workshop, to hear that automated testing didn’t feature highly in their list of priorities (as an interesting aside, Cal also considers object oriented programming to be ‘insane’, which all ‘sane’ code existing in the space between one-giant-function programing and OO). “Testing web applications” Cal said, “is hard”. This is a common misconception. Like any type of application, if you structure it for testability, testing is easy. And if you invest in testing tools written specifically for testing web applications (FIT and FITnesse, Selenium are good examples) even those applications written without testing in mind have no excuse for going without.

But with Flickr being such a high profile and successful application I assumed there would be a more mature approach towards automated testing. Is this laissez faire approach to automated testing common?

Lets look at this another way. If you don’t have automated tests, you either have to test manually (which means longer time to release) or you don’t test. If you are in the business of delivering quality products, it probably means you do end up performing lots of manual tests which could otherwise be done quickly, automatically and even if you want on every checkin.

The architecture of the web makes it idea for an agile release early, release often process. With the web, the only destination environment you have to worry about is your server and the client’s browsers. Pushing out a release really can be as simple as the one-click deployment Flickr uses. With a mature testing framework, releasing directly to your user can be managed multiple times a day if required.

Testing might not seem like fun – but once you realise it means you can release cool functionality to your users more often, and you’ll spend less of your time fixing bugs, perhaps we can all start to love writing tests just that little bit more.

Nowadays, creating a webservice can be fairly simple. Axis has finally got to a point where creating a SOAP interface requires the minimum amount of chicken slaughtering and dark incantations, and .NET makes it ridiculously easy (no wonder Java 6 is aping .NET-style ease of use(magpiebrain – Sun on Mustang (J2SE 6.0) – squaring up to .NET?) for webservices). Both Djano and Rails make it easy to create REST-style apps (Django’s URL’s are RESTful out of the box). The problem is creating a webservice shouldn’t simply be a case of placing a language-agnostic HTTP-based interface (be it REST, XMP-RPC or SOAP) in front of your application.

The word ‘service’ in webservice should represent more than the programmatic interface between the server and clients. It should represent a contract between two parties – the maintainer and user of the service – on more levels that what methods can be called, and what types are defined.

As a developer of a service you must be able to commit to (and document if required) a level of service – in terms of uptime, throughput and handling support. You need to have a versioning strategy that allows clients to not only test against new versions of your service, but also gives them time to upgrade once a new version goes live. You need to establish agreed communication channels between yourself and clients. This applies equally if the service is for use inside a team, a department, a company or even between businesses.

As a user you need to give the service some indication of current and future load – giving them a chance to scale if required, throttle your traffic, or look at optimising your current use. You also need to be proactive in testing against new versions of the webservice – not only so you migrate to the latest and greatest version as soon as possible, but also so you can aid the developers and feedback bugs.

As sappy as it sounds it’s about being nice to each other. Webservice developers need to understand that their service doesn’t exist in a vacum – sure your lives would be easier without users, but without them the would be no need for your service. Clients need to understand that the developers need your help to do their job. I’ve seen first hand what can happen when the communication between the two groups of people break down – and that within the same department. Understanding what is involved in creating and maintaining a webservice will make everyone’s lives easier.