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.
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 prioritizing very well. I should fix that.
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”.
Apologies if you are looking for any articles or trying to post a comment and you are getting 404 errors, or if you wondered where jbehave.org or behaviourdriven.org had gone. Over the last few days I’ve managed to completely hose my server running Debian testing distribution, and I’ve had to downgrade to Debian stable. This involved some rsync backups and a complete reinstall of the virtual server.
Apologies especially to the lovely people whose blogs I host and who have been extremely patient with me over the last few days.
So it’s that time of year again. I’ve got a number of conferences and workshops coming up, ranging over all sorts of topics. I just popped over to Martin Fowler’s site (I’m doing a talk with him this week) and noticed that he has a much more organized setup than me. All his events are in a sidebar and there is a handy link if you want more details. Another idea to go on my to-do pile.
This is the first of an occasional series of posts about Linux systems administration. I’ve been an on-off Linux sysadmin for about, well, my first Linux was Slackware on a stack of 3.5" floppies. Every now and then I do something “fiddly” and I want to capture these episodes in case I ever need to do it again, or in case someone else wants to and they find this useful.
During the past few years, service-oriented architecture (SOA) has become a mainstream approach for designing and developing enterprise software. As with most new technologies, the adoption of SOA has been led by software vendors and shaped by their particular tools and sales targets. Naturally it is in the vendors’ interest to emphasize the complexity of SOA and then provide a timely and profitable solution. This leads many systems architects into a technology-centric view of SOA, when, in fact, the most important criteria for a service-oriented architect—before tackling the technology—should be a keen understanding of the business.
Earlier this year I wrote an article to introduce service-oriented architecture to non-technical people. It was published in the May 2007 issue of Better Software magazine.
The kind folks at Better Software have allowed me to provide a PDF version of the article, complete with retro 1950s graphics. You can also read it as a single html page.
Please post any comments here, because I’ve disabled comments on the page itself.
How about that? You wait ages for a BDD framework in .net and then two come along at once! Ok, to be fair NSpec has been around for a while. However I’m talking about describing application behaviour in terms of stories and scenarios, to complement NSpec’s description of interactions between objects. (As a side note, I would love to see NSpec adopt rspec’s describe/it vocabulary rather than using contexts and specifications.)