Liz Keogh's blog

Following pointers from my last post, I have scoured the net for clear definitions of JavaSpaces, tuplespaces and Grid Computing (ie: I typed the phrases into Google).

I have a better understanding of the subject as a result.

I still haven’t found a clear definition of a grid. Damian has suggested that the things I wrote about good grids are needed for a grid to be called a grid at all. Ian, who led the talk yesterday, has said that there are many definitions of what constitutes a grid, and that even vendors of Grid Computing software have their own definitions of Grid Computing. Add “confusion” to the Google search and see what comes back.

The definitions of Grid Computing which I found were so wide, so varied and so unclear that I gave up and wrote my own.

Today we had a lunchtime talk about JavaSpaces, which is a form of grid computing (this is a new thing for me, so if I get anything wrong, yell).

Grid computing is when a lot of computers are used to split up processing of a hard task. The SETI screensaver uses your CPU at home to form a big grid. If you want to draw a Mandlebrot fractal, you can parcel out the various bits to nodes in a grid to calculate (this is so easy that everyone uses it as an example). There are lots of ways in which grids can be implemented, and some implementations are better than others. Some of them push tasks out from an orchestrating machine. Others have nodes which pull their tasks out of memory space.

JavaSpaces uses this latter technique, and also shares the memory space amongst several different computers. While we were learning about this, we asked a lot of questions and began to form a picture of how a really good, robust grid would work.

1. A good grid has redundancy in its memory store, so that if one node goes down another has the necessary information to continue.
2. Some really good grids have nodes which work out when they’re being polled for information too often, and find another node which isn’t being used so much to share it with.
3. A good grid will work out when a given task is killing nodes too often, and flag the task as something which needs fixing.
4. A good grid will look for high-priority tasks to run first.
5. A good grid runs transactionally, so that if a node fails to complete a task, it doesn’t break the grid. Instead the task stays on the list.
6. Some really good grids accept that their nodes aren’t perfect (for instance, floating point arithmetic may differ from one hardware base to another). These grids use a voting system, so that the result of one machine is checked by others.

Can you see where I’m going with this?

There are a lot of parallels with Agile Development and collaboration between Agile developers.

1. A good team will communicate, so that everyone knows what’s going on.
2. On a good team, developers are encouraged to share information instead of hoarding knowledge. This reduces the bus factor.
3. A good team will spot problems which kill their velocity and sort them out.
4. A good team will take on the tasks which the customer has decided have the highest business value.
5. On a good team, members won’t check in stuff that breaks the build. They’ll use version control so that if they do accidentally do something which breaks the build, they can roll back their changes and try again.
6. On a good team, developers ask for help and accept it from other developers. They will pair together, and discuss possible solutions until they have an idea of which solution is best.

I wonder – is Agile naturally suited to this kind of development work? Does splitting things into manageable chunks lead to easier, more even development? Would developers communicate better if we were coding for a distributed system? If we developers lend out our brains, will we discover life beyond our world?

• Use IntelliJ to refactor a class so it’s easier to test.
• Add a suitable mock object jar to the library.
• Add unit tests for the class which we’re about to change. Make sure all functionality is covered.
• Write new test method which falls over.
• Make unit test pass.
• Write new test method which falls over.
• Make unit test pass.
• Check in new tests, new functionality, and all the tools required to do this again tomorrow.
• Sit back, look at the lovely, tidy(ish) code and smile.

There’s just something about that green bar. I remember why I love this job.

I need to invent a green bar for housework.

At some point I’m guessing that the SheepImpl I’m looking at was an implementation of a Sheep interface, which extended the Animal interface. There’s also an AnimalImpl class. The Impl classes are generated by persistence layer stuff, so there’s some logic there.

(Why couldn’t we just have called it PersistedSheep, or GeneratedSheep, or HibernatingSheep? Would that have been too obvious, perhaps?)

There are other unrelated uses of Impl as implementations for interfaces – GrassImpl for the Grass interface, MangerServiceImpl for MangerService – you get the picture. It seemed reasonable to assume that the animals followed the same daft convention.

Assumptions are dangerous. Conventions are dangerous, especially when they are conventions in sheep’s clothing, so to speak. I should have read the code more carefully.

Sheep is now also a class with its own functionality, and is extended, not implemented, by SheepImpl. Sheep itself extends Animal (also a class) but not AnimalImpl. It’s taken me half an hour to work this out, and now my head hurts. Partly from unravelling spaghetti this late on a Friday, but mostly from doing this:

*Bangs head on table repeatedly*

Note: The actual code is in a retail application and has nothing to do with sheep. Thinking about things in terms of sheep, however, is helping me to be less stressed about this. One sheep. Receipt for one sheep. Special offer: two sheep for one! I would like four sheep, please. I’m sorry, Sir, we only have three sheep in stock, but I can order a fourth sheep for you.

Dreaming of electric sheep. Hmm.

Well, more accurately, I broke X-Windows while trying to get Doom III to work.

X-Windows works (I think) by using one of the many available X-Servers in combination with some front end stuff and information about your hardware. Some time during the Warty release of Ubuntu, they switched from using XFree86 to XOrg as their X-server of choice. I couldn’t get Doom III (and the ATI drivers) to work with XOrg, though, so I tried to reinstall XFree86. Unfortunately, some change or other I’ve made prevented this. So I tried to reinstall XOrg. I think my attempts at XFree86 installation may have stopped that from working, too. So now I have no X-Windows at all.

Fortunately it’s pretty easy, even from a basic terminal, to back up everything that’s important onto my lovely server. Rather than trying to fix all the X stuff which I know nothing about, I’m just going to reinstall the Ubuntu partition on my PC.

Hopefully if I use a fresh installation of the latest release (Hoary) then I can work out what I did wrong. If I can get Doom III running it’s another link severed in the chains that bind me to Windows.

Obie wrote a post on the benefits of IM.

Marco asked, “What about the problems that an IM will bring to the company? [ I ] know that people tend to lose some time just chatting with friends, girlfriend, whatnot.”

I have a controversial theory: IM brings no problems at all to a company. If a company’s staff don’t care enough about the company to make it succeed, then not having IM won’t make a lot of difference.

This is analagous to XP explained, which suggests that XP cannot save a project where the staff don’t care about the project. Nothing can save a project where the staff don’t care about the project. Except, perhaps, things which make the staff care more, such as the joy of unfettered access to IM, and the sense of pride one feels at being trusted to use it responsibly.

is now up and running. At the moment it’s just a file server; no web or ftp yet.

It’s bizarre. It’s just a shuttle box with a power cord plugged in the back.

It doesn’t need a network cable, because it’s got a wireless ethernet card.
It doesn’t need a monitor, because I can use SSH for remote administration.
It doesn’t need a keyboard, because it’s so quiet and cool that it’s hardly ever going to get rebooted.
It doesn’t need a CD reader or floppy drive, because I can apt-get everything I need off the web.
It doesn’t need a zip disk, because I’m running RAID 1 so everything’s automatically backed up.

It’s the most stripped-down little machine I’ve ever had, beating even my Palm T3 for minimal functionality. It’s wonderful to be able to access my documents, code and music from both Ubuntu (PC) and Windows partitions. I love it. I am in newbie Linux heaven.

I thought this was worth reposting from the comments of my previous IFoo post.

IFoo is used because someone thought of a Foo class and created an interface to go with it. That kind of thinking doesn’t lead to clean code in the first place.

Here’s an example, using the IFoo interface notation:

I create a Gui class and an IGui interface, so that the Gui can listen to the events from the Engine, which implements the IEngine interface.

Because of threading issues, I decide to create an EventQueueHandler, which can manage the events passed between one and the other. To enable it to talk to both it now has to implement both the IEngine and the IGui interface.

The EventQueueHandler is neither an Engine nor a Gui.

This is what I’m trying to avoid by cursing the use of IFoo. It’s pretty easy to see that this is wrong, but in more complex code the roles can be lost amidst the functionality. What the EventQueueHandler’s actually doing is listening to the ReportEvents fired by the Engine and the RequestEvents fired by the Gui, so it should be implementing RequestEventListener and ReportEventListener, which should also be the interfaces used by the Engine and the Gui respectively.

Call them IRequestEventListener and IReportEventListener if you absolutely have to, as per the comments on my previous IFoo post, but please consider blazing a new trail of code convention in your chosen language. If you really, truly can’t allow developers to call them anything other than IGui and IEngine then you won’t want me on your team anyway.

The reason I can come up with this example is because I actually did this (with a different naming convention that was easier to hide). I only realised my mistake when I plugged the EventQueueHandler in. I am, as a result of these thoughts, also convinced of the evils of DefaultFoo, and, in fact, of the use of “Foo” in example code. Foo is meaningless. It’s a point which was made to me before and I didn’t listen.

I was chatting to Darren over the partition this morning about this blog, and how much fun I was having starting arguments; about our company newsletter, the article I wrote for it, and whether I should submit my blog entry, Contracting vs. Consulting, for those who hadn’t read it. I’d heard rumours that some people in the London office liked it.

“Did you see the discussions that post started?” Darren asked (see here and here).

I hadn’t. I was quite surprised to read them, but it confirms something which I’ve been suspecting for a while: I really am being watched. I thought perhaps that given recent debates, and the treatment of my blog and particularly that post, that it might be worth a word.

I am not an authoritative voice on anything except my own experience, which is limited – growing, I hope, and nurtured by a great deal of enthusiasm and idealism – but to take anything I say as gospel truth would be dangerous. I like to provoke; I like to start discussions; I love to be told that I’m wrong, and even if I argue that I’m right until you and I are both blue in the face, I have never yet had a debate which didn’t open my mind a little and start me thinking.

I’ve come to realise that the interest in my blog, and presumably in the other blogs on the same feed, far outreaches the scope of the company feeding it; that my company is itself at the forefront of Agile, XP and the open-minded approach to software engineering; and that a large number of people are looking to it as an authoritative voice, and by extension to everyone in it. This realisation is simultaneously humbling and uplifting. To see something I’ve written being discussed by experienced, talented individuals around the world is very flattering, but also suggests a certain level of blog responsibility which I didn’t previously know I had.

Well, now I know.

There are a few things which I’m going to try to do differently as a result. Not many, but a few.

Please, if you discuss a post of mine or see that someone else has – stick a comment in and let me know! I love that people read and talk to me about the things I write, and I love to get other points of view. It’s useful to know when I’m wrong, useful to know if I’m right, and even more useful to realise that there is no spoon.

IFoo as an interface for Foo. It’s short and ugly, it’s only come into being because no one thought it through at the time, and everyone thinks poorly of it even though they may not say so.

If you’re the one doing this, you gotta think – what does it say about you?