nosewheelie

nosewheelie is moving

2006-07-03T20:46:00.000+10:00

After lots of contemplating, I've decided to move my blog over to my main site. I'll be keeping this blog around for posterity (also the Blogger import on Wordpress seems to be broken), but all future posts will be made at the all new nosewheelie, a new feed is also available.

The 7 (f)laws of the Semantic Web

2006-06-13T01:14:00.000+10:00

When it comes to the Semantic Web, you might call me a disillusioned advocate. I’ve been dipping in and out of the technologies for the last 5 years or so, but am increasingly frustrated by the lack of any visible progress.

Source: The 7 (f)laws of the Semantic Web.

Not on my watch!

2006-06-09T13:53:00.000+10:00

Our resident IntelliJ plugin guru Rob has been at it again. For a while we've been dreaming up ways to automate a build breakage notification, so that it's really in your face. Rob's solution?

Will wonders never cease?

Why do they hate us?

2006-06-07T21:17:00.000+10:00

The hypocrisy of the US administration astounds me constantly (and they're not alone unfortunately).

For a textbook example of why we are hated, consider Gaza and the West Bank. There, a brutal Israeli/U.S.-led cutoff in aid has been imposed on the Palestinians for voting the wrong way in a free election.

...

Query: who, besides al-Qaeda and recruiters of suicide bombers, can conceivably benefit from persecuting the Palestinian people like this? Does President Bush or Condi Rice think the Palestinians will respect an America that did this to their children, after we urged this election, called for Hamas to participate, and preached our devotion to democracy?

...

The White House says we don’t negotiate with terrorists. But when we had to, we did. FDR and Truman summited with Stalin at Yalta and Potsdam. Nixon met with Mao in Beijing. Kissinger negotiated with the Viet Cong and North Vietnamese at Paris. Bush I allied with Assad in the Gulf War. Clinton had Arafat to the White House too many times to count.

Source: The Persecution of the Palestinians.

Ruby early return considered harmful (for idiots like me)

2006-06-05T13:17:00.000+10:00

I've been playing with some Rails code at home to support some of the work we do at the day job. I'm building a search tool that detects the kind of input and performs searches based on this type. I've been working with Ruby's regular expression support, and test driving a class to find UUIDs. Here's what I started with (please don't comment that it could be simpler, I was starting simple... :).

class Uuid
  REGEX = /[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}/

  def Uuid.isUuid(fragment)
    if fragment =~ REGEX
      return true
    end
    return false
  end
end

Thinking that this could be simplified be removing the return keyword, I removed it!

class Uuid
  REGEX = /[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}/

  def Uuid.isUuid(fragment)
    if fragment =~ REGEX
      true
    end
    false
  end
end

This caused all sorts of funny problems, which in hindsight are painfully obvious, but at the time are just a pain. Removing the return causes the if to essentially fall-through, always returning false.

Discussing this at work, perhaps I've hit up against a potential maintenance issue with Ruby. I'm hoping this isn't the case (you can do similar stupid things in most languages), but some of the things you can do with Ruby make me a little nervous. I'm holding my tongue for a while (I did the same thing with XP and am hooked) to see where things go, I'm sure it'll all be fine...

Managing Software Developers

2006-05-31T12:42:00.000+10:00

If you're an engineer at a company where becoming a manager is considered a promotion, then you only have three choices: become a manager yourself, or leave, or resign yourself to being a second-class employee. It should be obvious — you can work through the math using three sock puppets — that this is an arrangement that pushes a company inexorably towards mediocrity. The best engineers either leave the company or try their hand at management, often with doubly disastrous consequences: they simultaneously lose the company a great engineer and gain them an awful manager.

Source: (Not) Managing Software Developers (Via Anarchaia).

On project estimation

2006-05-11T08:04:00.000+10:00

Tom writes about How Long is a Piece of String?, which addresses one of my main frustrations with software development; estimates and how project managers' and stakeholders deal with them.

So, how long is a piece of string? ... It's a pretty silly question, isn't it? But would you believe that questions like that are asked all the time regarding IT projects? And what is even more amazing is that people actually give answers to such vague questions and then they make important business decisions based on them.

Far too often I see people wondering around in disillusionment as estimates are not hit. This can sometimes be exaggerated on agile projects as management get more feedback than they're used to, and some panic.

Immediate feedback is a key element to exceptional performance

2006-05-10T20:16:00.000+10:00

Matt tells us of the importance of instant feedback, and hightlights A Star Is Made. Very timely considering the time our build takes...

How to make programming hard for yourself

2006-05-06T13:56:00.000+10:00

Reg Braithwaite post about How to make programming hard for yourself. He makes several interesting comments that ring true with me. I've worked with several people who meet the "people that consider my hard problems to be recreational diversions" comment, and though they are phenomenally smart and can indeed tackle the hardest of the hard problems, (I feel that) they find it hard to produce code that is of a high quality consistently. Then, there are those people, who are naturally smart enough to tackle the hard problems yet are also able to produce good quality code on a day-to-day basis. There would only be about 5-10% of developers who fall into this bucket, and getting the chance to work with them is mind blowing. There is nothing better for your career development than to be thrown in the deep end with a bunch of people that know more about everything than you do. Indeed Dave Hoover's Be The Worst apprenticeship pattern embodies this idea. I'm currently working on a project with several people that fall into this category. There's nothing like a dose of reality to keep an ego in check!

On a similar note, Damien Katz shows us the Signs You're a Crappy Programmer (and don't know it). I don't agree with all of these, the 20 lines of code one especially. We spoke about this at work today, and while they're all "magic" numbers, they really force you to think hard about your design. I heard a podcast by David Heinemeier Hansson once that talked about how being under constraints you may not like forces you to be creative (he was referring to Rails). I think length is one of those occasions.

Mac Backup Software Harmful

2006-04-29T07:46:00.000+10:00

Paradoxically, copying a file and being sure that all information has been copied is not easy under Mac OS X. I analyzed a variety of file copying engines, most of them command-line tools, and demonstrated how they fare in preserving file metadata.

Source: Mac Backup Software Harmful

This is quite interesting as I've never felt the need to move from Carbon Copy Cloner to something else, as I've successfully managed upgrades using it from Jaguar to Panther & Panther to Tiger.

Subversion

2006-04-24T21:05:00.000+10:00

Andrew asked me to take a look at some JRDF work he's been working on. As I've been slack lately, I needed to check out the code to take a look, and he's recently moved it over to Subversion. I've dealt with svn before from within IntelliJ, but I usually like to check out my projects from the command line, to get a feel for what's going on. So my running commentary for all today is information on getting svn going for CVS wannabes.

Gotta love the blame/praise command!

Samurai

2006-04-11T12:14:00.000+10:00

If anyone ever needs to analyse Java thread dumps, Samurai is the Beez Neez. No more squinting at less.

Cannot Delete

2006-04-10T13:22:00.000+10:00

The ever helpful error message, from a colleague's interactions with a remote server.

SPARQL-a-go-go

2006-04-07T08:03:00.000+10:00

Via Dave: The DAWG (the WG I once sat on) has just released three SPARQL specifications as W3C Candidate Recommendations! This is great news for the semweb community, even if some of the decisions made are not ones I agree with. The potential upside of semweb is huge, hopefully it can be another one of those overnight success stories, 10 years in the making.

Firing squad

2006-03-29T08:20:00.000+10:00

I think we should take the “Web Services” label into the jailyard, strap on a blindfold, give it a last cigarette, and shoot it. It doesn’t mean much any more, and to the extent that it does, it’s misleading: WS-* doesn’t have much of the Web about it. I don’t have a proposal for a new name for the WS-* style; sorry, but I just don’t care.

From Tim Bray, Styles: Beyond WS and REST.

The Wrong Questions

2006-03-24T20:54:00.000+10:00

Walking around the office this last week, I've begun to notice some things I've forgotten about large bureaucracies built around IT projects. Everyone has great answers, but they're answering the wrong questions.

A couple of examples. We're collocated within a division who manage the development and deployment of large projects within the company. Walking through the office last week I saw a large poster of the "Rational Unified Process - Process Made Practical". Now I've never developed under any Rational process (or tools for that matter), but the idea of something that calls itself the "Unified Process" (complete with caps) struck fear in my heart.

In a previous role, we had the experience of receiving several functional requirements specifications that were not suitable to develop from. They missed several key requirements, did not accurately describe the current system and contained lots of diagrams that were nothing more that pretty pictures. One of these specs was a 30-odd page Word file that when distilled contained a page and a half of requirements in bullet point form.

Now, from a business point of view I'm sure these specs were of value, but for their intended purpose they were of little. The problem was, the documents were produced within a process that did not take into account their value to development, only on their adherence to documentation standards. In one case, the requirements had not been gathered from the customers, and the touch points with the function and capabilities of the current system had not been checked with those who knew it best. The document was derived in complete isolation, from a higher level document alone.

Now I don't think that anyone truly believes that we know how to develop software. Those of us who practice XP would like to think that agile is the way and the light. I believe it's a great step forward - and a step that practices self review and the infamous continuous improvement - but it may not be the best way to develop all software.

All in all I have the sinking feeling that there are lots of people are all busy doing a wonderful job that contributes little to the effective delivery of a software project. There are lots of great answers, but the questions being asked are not the ones that should be.

You know you have problems when...

2006-03-14T21:17:00.000+10:00

Your classes are over 5000 lines long.
You compare your class to three JDK classes.
You incorporate transaction management, path management, file management, connection & URL semantics in a single class.
Your class-level javadoc is 100 lines long.
You use a version of commons httpclient that has bugs parsing URLs with ports & is incompatible with the latest release.

Also known as WebdavResource. Why this sort of code continues to be written is bizarre.

Update. As James has pointed out in the comments, editing your blog over a modem when you cannot spell is not good. I've never had a good experience with slide, and none of my recent experiences is any better.

The C guru

2006-02-23T10:17:00.000+10:00

We have the pleasure of inheriting an application written in C that wraps a GDS API. I've been in the process of upgrading the API to the latest version and ran into a few stumbling blocks. In typical fasion, I'm posting the resolutions them here so I can find them again.

ldd - Lists shared library dependencies
nm - Lists symbols from object files
objdump - Displays information from object files. This is like nm on steroids, and apparently also lists symbols for file that have had their symbols stripped.

BTW, the title of this post does not alude to me, but rather a label I've been throwing around at work for kicks, only it hasn't stuck to someone yet!

Continuous Integration

2006-02-02T14:54:00.000+10:00

Was having lunch today with a friend of mine and one of his colleagues when the topic of my current work came up. I told him that I was working on a new feature of our product and had spent the last chunk of time integrating it with the existing codebase. Greg commented that if I was performing continuous integration I wouldn't have run into this problem. My reply was that we were and I went on to explain why I was having problems.

On the walk back to the office however, I thought some more about the question and it struck me that I'd misinterpreted it. On reflection I think that perhaps there are two ways that we could have completed this work and continuous integration means more than just good tests running in a continuous build environment.

Separate Implementation Method

This is the approach we took. Basically, we came up with a high-level approach, decided where we were going to hook it in, then built up the code to match the existing functionality (using a bottom-up TDD approach). We then (this is the situation I'm in now) tried to hook it into the exising code base, where I discovered we did not currently have access to required details.

Integrate Always Method

Using this approach we would break the system up front by integrating our new code directly into the existing code base. The more code we had written, the closer the system would be to completion. We wouldn't need to perform after the fact integration and we'd more easily know when we where finished.

Summary

In hindsight, we could have taken option 2 and saved ourselves the hassle. One problem with it is as we are working on a production system, we cannot break current functionality as maintenance releases are frequent and business often changes priority by pulling us off and on "sub-projects" according to their need. For us, this approach requires access to a separate source branch (which we have) in order not to break the system. To me this highlights some lessons I've obviously forgotten...

jMock ordering

2006-01-24T11:17:00.000+10:00

In case anyone (i.e. me next week) needs to specify explicit method ordering in jMock, here it is. This code specifies the order of a chain of method calls (it came from testing a wire protocol implementation - don't ask...), rather than just expecting all calls to come after a single call. In particular note the ordering of the id() and after() calls, once again IntelliJ saves the day.

Mock mock = mock(RedstripeSocketTransport.class);
mock.expects(once()).method(METHOD_OPEN).id("CallOpen");
mock.expects(once()).method(METHOD_WRITE).with(eq(seededRequest))
    .after("CallOpen").will(returnValue("foo")).id("CallWrite");  
mock.expects(once()).method(METHOD_READ).after("CallWrite")
    .will(returnValue(seededResponse)).id("CallRead");
mock.expects(once()).method(METHOD_CLOSE).after("CallRead");
return (RedstripeSocketTransport) mock.proxy();

Note that that write() does not actually return a value in the production code, it's in the post to help me remember ;) Apologies to Andrew if he's posted this already, I thought he had, but google does not know about it...

Vlad has made a good suggestion in the comments, that statements have the method name given to them as ID by default. I'd seen this as an error message but wasn't sure what it meant.

Closures for Java

2006-01-23T12:36:00.000+10:00

Danny's been talking about Closures in Java. We did a similar thing in JRDF for testing.

AssertThrows.assertThrows(RuntimeException.class, new AssertThrows.Block() {
    public void execute() throws Throwable {
      somethingThatIExpectWillThrowAnException();
    }
});

All in all the syntax is ugly and nowhere near as neat as Ruby's, however such constructs can significantly cut back on duplication.

Up yours

2006-01-19T08:44:00.000+10:00

Now this is priceless: Mac OSX. Mac OSX Up Yours T-Shirt.

Exception messages

2005-12-21T09:49:00.000+10:00

I've been spending a lot of time working on legacy code lately and apart from everything else, the thing that sticks out is good exception handling. Doing this has firmed my belief in handling exceptions as close to the source as possible (or alternatively where you have the most context) and wrapping them in RuntimeExceptions (or subclasses of). It also highlights the importance of placing decent messages into exceptions. The usual "Cannot do X" is next to useless. In our bookings engine you have all sorts of good context, booking numbers, flight details, site codes, etc. that allow you to track down problems in code that a stack trace doesn't always allow.

What prompted this post was the above image from TheServerSide.com with a wonderful message.

Software Quality

2005-12-15T14:00:00.000+10:00

I've been meaning to write about the cost of writing software for a while (unfortunately it's sitting as a draft), but the recent Tokyo Stock Exchange fiasco highlights the true cost of not making the effort to write software correctly. When will people (i.e. the management with the money bags) learn that the cost of maintenance and also mistakes are orders of magnitude higher than the costs of doing it properly the first time (and doing it once). Creating quality software is not rocket science, there are well known methods for doing this. What I find amazing is how many organisations baulk at paying slightly more initially, but will happily pay bucket loads down the track.

IntelliJ and Eclipse

2005-11-30T08:30:00.000+10:00

Well I thought I'd never stoop so low as to enter into this flame war on my blog, but Patrick's Eclipse Live Templates post is worth keeping, so I may as well document my feelings also...

As everyone knows, Eclipse is the best IDE out there, it's the only choice right? Very wrong. Sure, Eclipse has the market share, has more plugins, and widepsread industry support, but is it really a better IDE? My take on it is no. Yes I can use it, but it feels like the difference between riding a hardtail vs a dually. Sure they both get you from A to B, but one is much nicer to ride and doesn't hurt your ass as much. Another analogy I like to quote is that Eclipse feels like using Word, it tries hard, but in the end you end up fighting the editor just to get work done.

I've been using Eclipse a lot lately (by a lot I mean a couple of days solid) as we're merging between branches and IntelliJ does not support this (as far as I can tell anyway). I've also had a lot of people ask me for my opinion on IntelliJ as we've got some spare licences floating around and most of the guys are using Eclipse.

Eclipse does have some good things going for it.

Better CVS support. Eclipse seems to have re-thought the entire revision control experience, making it easy to work with. This does have it's downsides, like Eclipse only developers who don't understand CVS or Subversion fundamentals (and cannot operate outside of Eclipse) or with CVS gurus who cannot understand Eclipse's naming of operations and its workflow.
Better use of screen real estate. The tree in the Package Explorer is a good example of this. Eclipse seems to use much less horizontal and vertical space in the tree view, allowing more classes to fit in a given screen size.
Eclipse looks nicer (by default) to me, perhaps owing to its SWT heritage vs IntelliJ's Swing. Its window management is a bit more advanced also.
Eclipse's debugger is apparently better, I say apparently as I haven't noticed it myself. It supports threaded apps in a more logical way, by sticking to a single thread and not jumping threads when breakpoints are hit in these threads.

So what are the bad things?

Eclipse requires you to save all the time. This gets very annoying when you're used to IntelliJ. Say for example you make a change to a test and you want to run it, why wouldn't I want to save the test file. This stuff should just happen without the need to prompt the user. File management should be taken care of. IntelliJ does a good job of this and allows it to be configurable (the save timing that is), to the point where you forget about it altogether. If you want an older version, it's in CVS (cause you're doing tight spinning when writing new code) or in the local history.
When comparing files (select two projects, right click, Compare With -> Each Other), copying all changes from one file to another (called "Copy All Non-Conflicting Changes From Right to Left"), Eclipse does not warn you that you need to save the file (I'd been using a different form of merging/diff - the Compare With -> Another Branch or Version... - where this change is automatically saved). So I'd been happily chugging along all morning, when Eclipse crashed, losing a few hours of work. On the plus side, when you do hit save, it quickly shows you the "file has changed" symbols, saves the file, then removes them. Very helpful.
Eclipse has serious usability issues in graphical diff (Java Source Compare) screen. 1) When merging differences, Eclipse continues to highlight changes, even though they've been applied. Whereas IntelliJ will remove the coloured background and border from changes that you've already applied. This provides an easy visual clue that you've complete a merge. Also, the little buttons for merging are too small, have icons that look the same (probably a result of them being too small, you can see the differences if you look closely) and are in the wrong position. IntelliJ gets this right, by placing the the icons (a cross for delete or directional arrow for merge) at the point of difference, allowing you to clearly see the affect clicking will have.
Like Word, Eclipse wants to own your files and wants you to make all your changes through it (I assume so it can keep its caches up to date). So if I change a file on the file system (say to back out a change because Eclipse won't undo), Eclipse continuously reports that the file is out of sync with the filesystem. Why on earth it doesn't just sync it and be done with it is beyond me. Now I have to a) remember where I am in my merging, then b) get out of the view, c) re-sync the project and d) re-compare the projects and e) go back to where I was. Again, a little thing that really gets in the way of productivity.
Eclipse's two ways of comparing do not give the same result. CVS differences (select a project, right click -> Compare With -> Another Branch or Version...) show less files than a straight file system difference (select two projects - representing different branches - right click, Compare With -> Each Other).

By now I think everyone knows my view on the matter, but my short summary is that while Eclipse is fully featured, everything is done in such a half-arsed way that I really don't know how people can use it on a day-to-day basis. I think I'd prefer to go back to using a straight text editor than be forced to work around its inadequacies. And why is IntelliJ better? It just feels right. That's the best way I can put it. Like any tool it takes a while to get used to it, its keyboard shortcuts, etc., but once you learn these you'll never willingly go back. It seems to know what you want to do and will suggest things to improve the way you work all the time. Everyday I find a new thing to like about it. Its smarts are not the Word breed of smarts however. You always have control and it does not bend you into its way of working. It's a tool that works with you rather than against you.