Posts in Category "General"

Don’t Live With Broken Windows

I’ve been doing a fair bit of air travel recently, for both internal meetings and for client engagements, and, over time, the experience gets rather repetitive. Invariably, flights get delayed, queues start forming and people get stressed out.

The queues are one thing I have gotten used to, particularly in these days of heightened security, and I usually find my eyes wandering to the area around me. My mind usually follows.

On one such occasion recently, I was in (yet another) queue in Heathrow airport. It was at security this time and, being Heathrow at the busiest time of the day, there was the minimal number of staff requried to man the X-Ray machines.

As I contemplated life, my eye was drawn to pillar holding up the ceiling. Now, the pillar wasn’t particularly interesting (though it was a handy distraction from the tedium of queuing), but what was noticable was the pile of rubbish on the floor around it – coke cans, candy bar wrappers, empty sandwich packets. All kinds of rubbish, just left there, doing nothing (except somehow causing me to write this, I suppose).

Anyway, there was seemingly no logic as to why people had decided to place rubbish there – there were plenty of places prior to that point where people could dispose of items they couldn’t take through security.

So, why was the pile of trash there? I beleive the answer lies in a book called The Pragmatic Programmer, in the section entitled Don’t Live with Broken Windows.

Consider a building with a broken window. If the window is not repaired quickly, the tendency is for vandals to break a few more windows, over time. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters or even do much more damage.

The area I saw in Heathrow airport was the litter equivalent of a Broken Window. On uncaring soul had left one piece of litter by the pillar. Someone else came along and did the same. After a while, the pile of trash started sending out the message: “It’s okay to leave your unwanted rubbish here”.

The experience made me think about how we develop software; do we do enough to ensure that our software doesn’t have any Broken Windows? It’s been 5 or 6 years now since I read the book, but I’ve added it to my list to read again; it is a very good read and contains many good tips that software engineers should always keep at the back of their minds.

So, next time you write some software, either from scratch or make some changes existing code, always be on the lookout for broken windows. Sometime’s they’re so obvious that you see right through them.

Cairngorm 2 Stateless Commands

You may have seen over on Steven Webster’s blog that Cairngorm 2 for Flex 2 Beta 3 has been released.

The main change in this release, compared with previous releases, is how commands are instantiated and used. I’d like to touch on the motivation behind this change.

In Cairngorm for Flex 1.x, a single instance of each command was instantiated by the controller and that one instance is used for each and every invocation of the command.

There are reasons why the original implementation was done in such a manner, mainly historical due to Cairngorm originally being developed for Flash applications, but since the advent of Flex, we’ve wanted to change it. With the API scrub taking place between Flex 1.5 and Flex 2, we see now is a good time to make this change.

Steven explains on his blog the single change you’ll have to make to your concrete front controller because of this API change.

So now, rather than the single instance of the command being used for each command invocation, the front controller now instantiates a new instance of the command on each invocation. There are a couple of implications here:

1) If, in your existing Cairngorm applications, you rely on the same command being used for each command invocation, (eg, if you store state in the command, and reuse that state on the next invocation), you will have to change your implementation. What we’d recommend here is that you store your state in your model, possibly via the ModelLocator pattern.

2) Because a new instance of the command is instantiated on each command invocation, you can now store local state in that command for the duration of its invocation. This is particularly useful for cases where you make server side calls (eg, via RemoteObject). Previously, you’d have to use a pattern such as the Asynchronous Completion Token, but now, you can store your state in a command’s instance variable in the execute() method (for example, you may store the event object), and then retrieve it again in your result or fault handler. We find this useful for cases where you want to update different parts of the model in the result handler, depending on the context of the initial command execution.

So, go get Cairngorm 2 for Flex 2 Beta 3 and let us know what you think.

Welcome

After months of activity (and inactivity) over on the old iteration::two blog I have my own blog now here.

Over the weeks and months ahead, I hope to give you an insight into the world of Adobe Consulting, showing you some of the things we’re doing with the Adobe product set, particularly Flex, and also sharing my thoughts on where I see the Rich Internet space heading.

So, keep tuned and come back soon!