DanNorth.net

If you are reading this with Internet Explorer 6 you are at risk

Ok, first things first. If you read this blog using IE6, you should check your machine for malware using Microsoft’s anti-malware tool or your favourite anti-virus suite. You should also consider installing Firefox with its ad-blocking goodness and lack-of-ActiveX-ness.

For several weeks I’ve been unsuspectingly handing out evil in the form of a hidden <iframe> tag, as well as having loads of poker-related links hidden in another article. According to my friend Joe Walnes, the iframe exploit installs a tiny “zombie” service through vulnerable IE6 browsers that hides in your Windows machine awaiting instructions.

I am hugely grateful to “noreply” at Google who mailed me to tell me this was the case – I really had no idea. It turns out Google were prefixing any search results to my site with a big sign saying “this man is a cheesy purveyor of malware”. Good for them – I was! And doubly good for them, they told me. Also thanks to a chap called David who pointed out the poker links.

You can never be too careful

I like to think I run a reasonably tight ship in terms of security. My server is sitting behind a firewall, running a solid Linux distribution with /bin/su disabled (in favour of the more secure sudo), which you can only log into as a non-root user with an ssh key. In other words I could give you the root password and it would be pretty much useless unless you were sitting at the console. I upgrade WordPress whenever they produce a new version. I use mercurial to allow me to roll forward or backward across upgrades, because, well, why wouldn’t you?

However it seems some evil pondscum used an exploit in a file called xmlrpc.php to inject hidden badness into the body of a number of blog posts. I’ve now disabled xmlrpc.php, but anyone using WordPress should be aware that there are lots of exploits some of which are still unresolved, and should lock down their installation accordingly. Naturally something as popular as WordPress is going to be a target for hackers. I certainly learned a lesson about being over-confident.

Next week I’ll be talking about Best Practices, a current favourite topic, at the ExpertZone Developer Summit in Stockholm. Last year I ran a half-day workshop about SOA and gave a keynote with Erik Dörnenburg about simplicity in software, and this year I wanted to do something a little different. So when I heard there was a track called called “People Matters Too” I was keen to get involved.

This talk will be completely non-technical, aimed at anyone interested in how we learn and why we rebel when faced with Yet Another Change Programme.

BDD and DDD at Stockholm Javaforum

As an added bonus – for me at least – I’m going to be talking to the Stockholm Javaforum on Tuesday 8th April at 7pm. When I initially agreed to this I thought it would be a handful of geeks hanging out and talking about Java. It turns out they regularly draw around 200 people. And they’ve sold out. Yikes.

I’ve got an hour to talk about the relationship between Domain-Driven Design and Behaviour-Driven Development. I have no idea how I’ll be able to limit that to one hour but I’m going to try my best. This is timely because I am also working on an article explaining my take on DDD and BDD. Honest.

Last October I was privileged to give a keynote talk at the Øredev conference in Malmö, Sweden. It was a late substitution. The original speaker, testing guru James Bach, had to cancel at the last minute for personal reasons. I felt pretty intimidated stepping into his shoes, especially since the other keynote presenters were Joel Spolsky and Andy Hunt, but I figured since no-one had heard of me I’d probably slip under the radar.

James was planning to talk about best practices, and it seems we have similar opinions about them. I would encourage you to read his wonderful blog article where he rigourously deconstructs the phrase¹, and then just as eloquently picks apart the arguments of anyone who disagrees. So I thought I would do something around the same topic.

I wrote it up as an article and the kind folks at InfoQ published it, and the Øredev team has put up a video of the talk. (For some reason I can’t get it to work in firefox on ubuntu, but I’m pretty sure the guy on the left is me).

¹ I didn’t realise until long after Øredev that he was the author of that article. It made me very happy when I found out.

I’ve been pretty slack at letting people know about upcoming talks. I could blame workload or burnout or any number of other plausible-sounding reasons, but a lot of it is just down to not prioritising very well. I should fix that.

A couple of years ago Joe Walnes and I gave a talk at an XP Day entitled “Awesome Acceptance Testing” (blame Joe for the title). We looked at motivations for acceptance testing and discussed various strategies, tools and techniques. But mostly it was an opportunity to get a bunch of people in a room and find out what they thought and what they were up to in the acceptance testing space.

If you didn’t get to see it and it sounds like fun, we’ll be rerunning the session at SPA 2008 in March. I hope to see you there.

I was in a hotel in Stockholm recently and I noticed a bottle opener attached to the wall in the bathroom. There was a bilingual sign under it which got me thinking about the term “bottle opener” itself. (I was giving a talk about BDD the next day so I was already thinking about how language is used.)

It occurred to me that “bottle opener” is a great example of goal-oriented vocabulary. The device itself is actually a cap remover, and it only works on one particular design of metal cap. The reason I use it, however, is to enable me to get to the beer in the bottle. Hence “bottle opener” rather than “cap remover”.

The task is just detail

There is more to this than just linguistic curiosity. If you use task-oriented vocabulary it can cause you to focus on the means rather than the goal, which in turn can limit your options. My favourite example of this is the term “search engine”. Searching is the activity I have to do because I’ve misplaced my keys and I’m locked outside. What I want is a find engine!

Google realises this. When I type something into Google, it guesses what I’m likely to be trying to find, not what I happen to be typing into the box. If I type in “Stockholm map”, I’m likely to be looking for a map of Stockholm (first three results are actual maps – presented as pictures) or some information about the town itself. If I type “hotels Stockholm” I’m probably planning a trip there and voila! lots of useful results for the traveller. Other “search” engines do just that – they search, and produce lists of results. It’s then down to me to sift out the ones I care about to get me closer to my goal.

“Blur” on a problem

We talk about “focusing on a problem” in order to solve it. This is a task-oriented phrase. An alternative would be to stand far enough back that you see the problem in its proper perspective. If anything you are “blurring” on the problem – deliberately losing focus on the detail to see if any larger-scale structure emerges.

I often describe BDD as outside-in development. You start at the outside with an automated scenario, and work inwards, discovering services and collaborators as you go, until you’re done. With a legacy application it can be difficult to remain outside enough, or to get a good enough frame of reference for “done”. Blurring can help with this.

For the last six months I’ve been involved in restructuring and re-architecting a legacy code base. It’s been quite a major undertaking, and has involved a number of false starts and dead ends. (I’m planning to write it up as an experience report at some point, but given my current throughput of things I plan to write, don’t expect it any time soon.) During this project, I’ve often found myself struggling to choose between alternative strategies, or unsure of where to go next. In these situations I’ve found that stepping back and “blurring” gives me enough perspective for one of the alternatives to become “obvious”. In fact a couple of my teammates have picked up on this and will actually suggest it as an activity when we are pairing. “We’re thrashing here – let’s step back and start from the outside again.”

It could be as simple as asking “whose responsibility is this feature?” or “who is the actual client of this method call?”. You don’t need to know the answers – just verbalising the questions can give you enough “blur” to gain a better perspective.

Blur on time as well as space

Linus Torvalds recently gave a talk where he said the problem with source control isn’t branching, it’s merging. Again, by taking a broader perspective – in this case temporal rather than spatial – his insight is that the goal is a successful merge some time in the future, not the task of branching now.

As a final thought, while I was thinking about this I realised the term “behaviour-driven” contrasts with “test-driven” in a similar way. My goal as a developer is to deliver a system that behaves in a particular way. Whether or not it has tests is an interesting metric, but not the core purpose. “Test-driven” development will cause me to have lots of tests, but it won’t necessarily get me nearer the goal of delivering business value through software. So you can use goal-oriented vocabulary in your development process as well as your code to help maintain perspective on what you are trying to achieve.

Props to James Lewis for helping me formulate these ideas. And for being really good at perspective.