Liz Keogh, lunivore

If I want to make a fire, I need a little more than just a spark. Something combustible is usually important, otherwise, when that spark happens, I won’t be in a position to build it into a fire. Opportunity’s the same; if I’m ready for it, then I’m in a position to make the most of it. This readiness is something which most ‘lucky’ people have in common.

“Chance favours the prepared mind” – Louis Pasteur

Sometimes, though, there is no spark. There are two ways in which I can deal with this problem: either I can go where a spark is, or I can work at making one. I can draw on the experience of others where appropriate – perhaps they know where a suitable pair of stones can be found – and I can get them to help me, if they happen to have a lighter on them.

But what should I do if I’m stranded on a desert island, with no flint and steel, no lighter and no magnifying glass?

Time is an opportunity. I shall find bits of wood and rub them together in different configurations until I work out how to make fire.

Time is the most precious of all opportunities. Everyone wishes there was more of it in the day. I drink far too much coffee because I never give myself enough time to sleep in. Other people struggle to find time with their kids, time for their hobbies, time to get their work done, time to breathe.

If there’s really nothing I need to get done with my time, I can prepare for when I will need it. I can refactor code. Learn new things. Tidy my desk. Tidy my brain. Get that boring task that I’ve been putting off for weeks out of the way. Talk to people and find out what’s happening. Eat sensibly. Go to the gym.

Whatever I do – I must not just sit down in front of the TV. That way lies ill-fortune. Every hour I spend watching Eastenders is an hour of my life that I can never get back.

This weekend, I have been mostly trying to make Debian work on my PC.

I should have realised that something was wrong when my boot sector virus scanner picked up LILO as an enemy (it seemed fine with GRUB before). Nine CDs later I logged in. The CDs don’t seem to support my graphics card, or my network card. So no Gnome or X-Windows, and no easy way of updating them. (I tried several installations with different graphics configurations and no success).

I eventually figured that the best thing to do would be to get connected, then apt-get in any updates. I have a Linux network driver. Unfortunately it didn’t like my setup and requested the kernel source so that it could compile an interface for itself. Debian does come with kernel sources, but none of them seem to match the default installation. So I found one of the others and learnt how to compile a new Linux kernel. In that respect, the Debian experiment was a great success; it taught me a lot about Linux and how it works.

Getting my network driver out of its zip on the backup CD was also a mission. I’m afraid I resorted to the use of my Windows partition. Note to self: when backing up Linux stuff, use tar.

The network driver needed another module as well as the source. No idea where the module can be found. I spent 20 minutes looking for this information. Eventually sanity dropped in to point out that I was on the path that leads to the zoo and the shaving of the yak.

20 minutes after that I had Ubuntu up and running, with Gnome at 1280 x 1024, full connection to my LAN and the internet, and my email restored to its usual place.

I hereby apologise to the gods of Ubuntu. I’m sorry that I ever doubted you. Appropriate sacrifices will be made on the altars of chaos next time I play nethack.

My experiments with running Ubuntu Linux have mostly been successful. I’ve certainly learnt a lot about Linux. I love the Debian package management system, and both the Gnome and KDE desktops are great (though anyone thinking of installing KDE be warned: KBounce is mindlessly addictive).

Ubuntu doesn’t feel very mature, though. For instance, last time I upgraded XMMS (a Winamp-like MP3 player) it stopped working under Gnome, though it still works fine under KDE. I still haven’t got my Palm and GPilot / JPilot working properly. Occasionally the entire desktop hangs. I’m sure that at some time in the future Ubuntu will be perfect for newbie Linux users who don’t want to tinker, but at the moment it’s just a little frustrating for those of us who do. It’s impossible to tell whether it’s my setup or Ubuntu itself that’s falling over.

So – I’m ready to move on. Thanks my newly acquired super-broadband-powers, I am downloading the seven CDs required for Debian. I am going to make myself a little media / document server in a Shuttle box (I’ve always wanted one), and reinstall my big tower so that it’s nice and clean. This time round I am not relying on the forums. I have bought a couple of books to help me with the installation.

This is an arbitrary list of strange words and concepts which I’ve come across, so that I remember what I’m doing:

• dyndns : Dynamic hosting. There are some sites around which let you do this for free. With the appropriate setup, you can ssh through the router and into the server on the other side.
• ssh: Not a new concept, but something I’ve never really got to grips with. I have a private key for the first time so that I can commit on the JBehave project.
• LAN: A local network, like the one we have at home. It was set up by a previous lodger. I want to understand this weird creature.
• Wireless: I’m aware that there are some security issues with wireless networks. I need to investigate.
• WINE: Wine Is Not an Emulator. It sits on top of Linux and provides Windows APIs. Microsoft Office already works on WINE. All I need to do is get DataViz’s “DocsToGo” working along with the Palm software, then maybe a couple of games like Doom3, and I will never need to use Windows at home again.

So far I have successfully implemented the Zeroth Rule of Agile:

If you’re not sitting comfortably, rearrange the furniture.

There have been no squeals of dismay from the client. In fact, I don’t think anyone really looked up from their work as I pushed and shoved tables, rearranged power cords, moved filing cabinets and discovered the troves of untouched treasures behind the other filing cabinet which no one knew about.

While doing this, I remembered an incident at the first company which I joined, in which alongside my coding duties I acted as sysadmin. The MD saw me carrying a large monitor along the corridor, and decided that I needed a trolley to move such heavy items. Two trolleys were duly ordered. It helped a lot, I confess, and we were able to shift four monitors at once on the new beasts – but isn’t it strange that the other sysadmins (all male) had managed without them for years?

According to some religions, or denominations of them anyway, there’s a big fiery pit called Hell into which all the damned souls go.

According to some religions, or denominations, damned souls include everyone who’s not part of that religion or denomination.

This has some parallels with the Agile movement. Heaven is a place in which it’s fun to work, in which everyone collaborates to produce effective code that makes the customer happy, where there are parties and laughter and everyone is full of energy and enthusiasm. No one is afraid to speak their mind, everyone is humble enough to accept correction or constructive criticism and has the confidence to debate the merits of others’ ideas. Since everyone owns everything there’s no blame, no possessiveness, no hiding knowledge away to protect your job. It’s a great place to work. You get up in the morning looking forward to the day ahead, and commute into work knowing that everyone else around you feels exactly the same way.

It’s an ideal, but then so’s Heaven. There’s a lot you can do to improve your work environment. Enthusiasm and positive thought go a long way – but if you’re not part of the Agile movement then it’s probably pretty hellish where you work. It won’t be fair. It won’t be your fault. (Unlike eternal damnation, there may be something you can do about it.)

The Ancient Greeks had a place called Elysium, which was full of picturesque landscapes, roaming bands of heroes and plenty of fresh fruit. They also had a place called Tartarus, which is where our word “torture” comes from. You can guess what that was like. They also had a place in between, called Asphodel, where… well… not a lot happened, really. It was just a bit boring. Everyone wandered round as a shadow, wondering where the fun had gone.

Some denominations of Christianity also have a place between Heaven and Hell called Purgatory. It’s a place which is fairly hellish, but you get to leave after a while, once you’ve paid for your sins.

Me? I’m being moved onto the Diagnostics team for a fixed period before hopefully being moved into the Heaven of a more Agile project. On the Diagnostics team I will have the responsibility of tracking down all the customer complaints about bugs. They’ll tell me, “I clicked this button. I can’t remember what I was doing, or what the message said, but it was definitely an error.” It will then be up to me to work out from the logs what exactly it was that happened, and replicate the bug before passing my analysis onto my old team for fixing.

There are two ways that this could go. On the one hand, my old development team might have managed to produce beautiful code of such outstanding perfection that there are no bugs. In that case, my old team are in Elysium, and the diagnostics team are in Asphodel. There will be nothing to do. On the other hand, my old team’s code may be full of bugs and we’ll spend all our time desperately trying to track them down, paying for our sins. In that case, the development team are in Hell and the diagnostics team are in Purgatory. I think the reality is something in between, since the dev team isn’t as Agile as it could be but better than most projects I’ve been on in the past.

Oddly, I’m looking forward to both new experiences, having already spent some years in Hell. I think as long as I have a notebook and a pencil, I won’t be bored even in Asphodel. There’s too much going on in my head which I want to write down. If it turns out to be Purgatory, then I can have some fun firefighting.

Either way… roll on Heaven. I see the light.

At GeekNight last night, I spent a lot of time discussing JBehave’s story runner, and how it affects checkins.

When you parse a story and produce the template classes, they’re initially empty. Gradually they get filled in with mock objects. So, for instance, my Hellbound class’s main story, “As a Hellbound player, I want to play games so that I can improve my score”, starts with a scenario “Given that Hellbound is running, the game panel should appear when the game selection button is clicked.”

I mock the gui, and put a simple event handler in the Hellbound class that deals with a new game request by returning a new game report.

Next scenario: “Given the first scenario, a new shape should appear when I start the game.”

Now I need a real game, but I can manage with a mock shape factory. I need a real game factory. This is the point at which things get complicated enough to use PicoContainer. I’m still mocking stuff – the gui, and the shape stuff. I decide I need an event handling queue to manage thread issues between the gui and the engine. It doesn’t affect the story, but every class I create gets its own associated behaviour class.

Next scenario: “Given that I move the shape right, then rotate it, then drop it, then move the next shape left, then drop it, then rotate the next shape, then drop it, the line should be filled.” Well, JBehave doesn’t quite support this yet (give us time). I can start to use a real gui, though. I don’t have a gui shape component; that’s still mocked. Yet I don’t have any failing tests.

This is JBehave’s “amber bar”. Tests haven’t been written with real objects – they’re still using mocks. The story hasn’t been completed. It’s still OK to check in the code – no one else’s stuff has been broken. “That’s wrong,” one of the GeekNighters says. “You shouldn’t be able to do that. Red bar, green bar I understand… what’s with this amber bar?” The green bar is represented by a ., the red bar by F for fail, and the amber bar by M, meaning you’re still using mocks.

Well, the amber bar means that you haven’t finished implementing the story yet.

You get that in non-JBehave design too. You just don’t get to see it so clearly. Normally, the only place you keep track of how much of a design you’ve implemented is in your head, or in the number of task cards you’ve marked as complete, or in the amber bar of some kinds of XP planning software… oh, wait. Now it all makes sense.

When I started contracting, it was by accident – the company at which I had applied for permanent employment after moving to London suffered a recruitment freeze. Two six-month contracts later I had had enough of a very long commute each day (my descriptions of the Piccadilly line are still recorded for posterity, if any foreigners out there want to learn some imaginative uses of the foulest English swear words ever heard this side of the Thames). After abandoning that I did a little stint in the city. After that I remembered another company which had turned me down two years previously. Would they be interested again, now that I had more experience?

They were. I’m here.

Working in a consultancy is very different to working as a contractor. Contracting is a lonely existence. There’s no support, and it’s hard to be emotionally involved in the projects with which you’re working. You have to be responsible for your own training, and you’re never allowed to admit that you don’t know something. You have to fight for your jobs. It’s a lot of work, and not that much fun. Also, I hate doing VAT returns each quarter.

In a consultancy, it’s not you who’s being hired – it’s your firm. You’re part of a greater whole; privy to all the benefits that the company can offer you. They sort out the jobs, and tell you where to go. They support you, giving you training, advice and tutelage (ideally in the form of pairing). You’re allowed, even encouraged to admit that there are gaps in your knowledge base, and although you’re still responsible for your own motivation, the opportunities are provided for you. If you don’t know about a certain type of architecture you can ask which book you should read. If you want to do a project on the side there are people around to help you, with no one fearing that it might detract from your day job. You have colleagues, fellow employees, lunchtime companions, even friends.

However, the biggest difference is in your reputation.

As a contractor, you’re hired to do a job. It’s never been part of my contract to point out that the customer might be wrong – my feeble suggestions in the past that “there might be a different way” have been summarily dismissed. You have the weight of one voice, and not always a well-respected voice at that. Permanent employees hate you because you earn more than they do, with no concept that you spend the time between contracts chewing your fingernails, worrying about the rent and trying to get your accounts together. Other contractors are too busy protecting themselves against the hatred of permanent employees to back you up, if they agree, and they don’t want to endanger their chances of a contract renewal any more than you do.

As a consultant, you’re part of a company which has often been hired in acknowledgement that the consultancy knows more than the customer does. Your opinion is respected. You can say things like, “Hey – these functional tests aren’t green-barring, and I think it’s more important to ensure that previous fixed bugs aren’t creeping back into the system than it is to fix your new ones.” You can say, “PicoContainer does what you want, and is very lightweight.” And the customer listens, because your company has made a success out of recruiting people like you. You have the weight of your company’s reputation.

That weight of reputation rests solidly on your shoulders. It’s important to carry it well.

Yesterday I tacked a quick gui harness prototype onto my copy of JBehave (seemed like an appropriate place to put it). I used a thing called a QueuedMiniMap – a cut-down map which, when you get an item by key, will wait until that item is added before returning. It can also throw a timeout exception. I added a listener to window open and close events on the AWT thread which puts or removes the windows to or from the map. I’m keying the window on title (for JFrames and Dialogs), then name, then class string, depending on which one is non-null first.

I now have a mechanism for grabbing hold of AWT / Swing windows as they open – easily adapted to grab anything asynchronously. Cute. Abbot does actually do something similar – it keeps track of all the open windows in the same way – but the method which tries to get the windows from its list just keeps looping, requesting repeatedly until it gets the window or times out (the ‘child in the back seat’ method). All I’ve done is find a way to make the child go to sleep until we arrive.

I’m sure that when I go to click the buttons on the window I’ll find out that I’ve missed something (most of Abbot’s vast functionality, for a start) – but it’s fast. Very fast. Very small.

@todo next: button clicking, text entry, window visibility, focus, make sure it works in Linux too.

(Also wondering about better ways to key the windows in the map – suggestions welcome.)

(Anyone got any tips for making Eclipse work under Debian-based Linux? It says it can’t find the blatantly present startup.jar … and where do you normally keep things like Eclipse in the filesystem? I think I could use a pointer to a suitable newbie site and a good book!)

For some reason, our functional tests fail because they time out. Screens which ought to be appearing in a timely manner aren’t visible. Buttons which are enabled when the screen is populated are still disabled when the test tries to click them. I’ve been attempting to get to the bottom of this problem with limited success.

This has prompted me to look at the way in which Abbot is getting hold of the window. As far as I can tell, when a test waits for a window to appear, Abbot loops, checking periodically (once every 10 ms) to see if it’s there, until it times out.

To me, this is the behaviour of a small, bored, annoying child sitting in the back seat of a car, asking “Are we there yet? Are we there yet? Are we there yet?” until the CPU driving is so distracted that it forgets where it was trying to go in the first place. This may have something to do with our mysterious timeouts; I’m not sure. Putting a longer wait in our test fixtures has definitely improved my chances in the fight for the green bar.

Is there a reason why Abbot was implemented this way? Is there no way to, say, attach a listener to events such as a window opening? Can Swing tell us, “Get out; we’re here,” instead of us having to ask repeatedly?

If there are no sensible reasons, and no one objects to a harness which hammers slightly less on my poor little CPU, I may give it a shot. Another optional package for JBehave, perhaps. I’ve always wanted a harness which waits for arbitrarily selected events anyway; there are plenty of threaded test scenarios in which I could use it.

I will be attending GeekNight London next week. I intend to bring my laptop, complete with some kind of working copy of JBehave and Hellbound. I think Ade wants to discuss all JUnit alternatives, including TestNG, and whether they’re ready for the mainstream yet.

If you want to find out more about JBehave and see it in action, or you just want to meet that weirdo who writes poetry about Lotus Notes, this is your opportunity.

Update:Tell us you’re coming here!