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.
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 organised 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.)
Morgan Persson first spoke to me about writing a .net version of JBehave at the beginning of 20071, so I am delighted that he has just announced his first public release of NBehave. It mixes C# and VB.net in a lovely it’s-all-about-the-CLR way. So the examples are in C#, extending VB.net framework classes.
It turns out that having a day job can play havoc with your blogging activities. I’m posting a round-up of recent activities, in no particular order, with the intention of expanding on each of these topics in the coming weeks. But we all know what happens to intentions.
This is mostly a brain dump to make me feel guilty enough to write some of it up, so feel free to skip it if you’re busy. That FaceBook page isn’t going to update itself you know.
RBehave is a framework for defining and executing application requirements. Using the vocabulary of behaviour-driven development, you define a feature in terms of a Story with Scenarios that describe how the feature behaves. Using a minimum of syntax (a few “quotes” mostly), this becomes an executable and self-describing requirements document.
BDD has been around in the Ruby world for a while now, in the form of the excellent RSpec framework, which describes the behaviour of objects at the code level. The RSpec team has focused on creating a simple, elegant syntax and playing nicely with other frameworks, in particular Rails and the Mocha mocking library.
I’ve got a number of tutorials, conference sessions and keynotes coming up over the next few months that I’m very excited about. My themes for this year are behaviour-driven development, SOA for human beings and understanding what simplicity really means. Looking at these, there is an overarching theme about getting different kinds of people talking to each other in plain English (for some value of English).
QCon is the London version of the excellent JAOO conference in Denmark, which has become my favourite technology event of the year (apart from phone upgrade time). They attract world-class presenters to provide sessions varying from the deep technical through to people and process topics, and they’ve done the same with QCon. What’s more, they have managed to resist the lure of the sales-pitch session, which means you get to hang out with other geeks without people trying to sell you stuff. The London event is being run in conjunction with the common-sense guys at InfoQ, and I’m lucky enough to be speaking there.
So I was hanging out with a bunch of geeks in Switzerland, having one of those late night conversations, and an idea sort of emerged, and the more I thought about it, the more I liked the idea. And then I was thinking that a) I’m useless at following through on ideas and b) I would love someone to take this forwards. So here it is.
Our premise was that the value of automated testing is in its repeatability and low investment (in terms of human effort). However, running the same tests all the time just verifies that the system does a small number of well-known activities.
At a recent software architecture workshop, I was discussing the ideas behind BDD with a great group of people (more about that soon). One theme that kept coming up was the fact that I needed to write much more about BDD as an entire methodology, and to address the current perception that it is just a repackaging of test-driven development (which, to be fair, is where it started).
As I was describing the workings of BDD, I discovered that I had made the assumption that everyone knew what a Story was, in the agile sense of defining a requirement. It turns out that there’s a whole world outside of my little bubble that use all sorts of different processes for identifying and defining requirements, and in particular they don’t know what I mean by a Story, nor why they should care.
Ok, so I’ve been blog-tagged. Twice in fact, by Patrick Kua and Mats Helander. Apparently the rules are that I have to tell you five things about me that you probably didn’t know, and then I have to tag a bunch of other people.
Except that this is the Interweb, blog-tagging is exponential and I’m usually the kid who gets picked last, so there are probably only about 4 people left on the planet who haven’t been tagged.