Small tidbits

• Continuous Integration Server Feature Matrix
• Quartz Composer Samples
• Taking Stock of Web Service Description

Trolltech Secures $6.7 Million in Series B Investment Led by Index Ventures

This is great news: Trolltech Secures $6.7 Million in Series B Investment Led by Index Ventures.

Trolltech®, provider of leading technologies for Linux and cross-platform software development, today announced the completion of a $6.7 million Series B round of financing led by Index Ventures. Existing investors Teknoinvest and Northzone Ventures also participated in this round. The funding will be used to fuel Trolltech's global expansion as it capitalizes on the growing markets for embedded Linux and cross-platform desktop applications.

Not least they have an office in Brisbane, where I've thought of applying for work in the past. Scott Collins has additional information.

vi Reference Mug

Finally, these appear to have come back on the market. PI had a couple of these years ago, but both were dropped and broken.

Backups with Burn Folders

I have a two step backup strategy for my Mac, 1) I create a complete bootable clone of my hard disk to an external FireWire disk using Carbon Copy Cloner and 2) I create smaller backups of important data to DVDs. I've used a bunch of different methods to create the backups and burn them, including the built-in command line tools to manipulate disk images. However, I've never found any technique that I really like, or is quick enough for me to create these regularly and automatically (my core data is usually around 10Gbm so a lot of manual deletion is usually in order).

Tiger however includes the new Burn Folders, which are essentially a folder full of symlinks to stuff you want to burn. Fill it up, check its size (Command-I) and burn!

New kinds of databases

The ACM is hosting an article about forms of databases other than SQL: Beyond Relational Databases. Tucana dealt with this issue for a few years, so the point that "relational" databases may not be the only answer is not new, howeve this article gives it good treatment.

Web Services are easy

Oh dear... After my recent experiences with a auto-generated web services from MS-land, this article really worries me. What worries me the most, is that people will think creating web services are easy, and then harass poor developers when they don't build a service in a few minutes.

To repeat, for anyone who hasn't heard, web services are not hard to create, what is hard is getting them right, removing the squidginess and making them integrate. They're not a panacea for integration woes...

Semantics in action

Dave Wood is in action in his new role at the MIND lab. Read the interview. Quite a high level overview of the semantic web, but quite good.

Code Formatting

Some links to keep in mind while reading the code standard of my new workplace.

• Why Your Code Sucks
• /** no comment */
• Write Sweet-Smelling Comments

Dictionary.app

It appears that the dictionary used in applications (within text fields, etc.) for spell checking is not the same as the "dictionary" used by Dictionary(.app). The word "preemptively" is flagged as being incorrect, the suggestion is "pre-emptively". However, a quick search in Dictionary shows:

preemptive
adjective
serving or intended to preempt or forestall something, esp. to prevent attack by disabling the enemy : preemptive action | a preemptive strike.
• relating to the purchase of goods or shares by one person or party before the opportunity is offered to others : preemptive rights.
• Bridge denoting a bid, typically an opening bid, intended to be so high that it prevents or interferes with effective bidding by the opponents.
USAGE See usage at peremptory.

(I like the example of a preemptive strike, quite topical considering the news coming out of the US on Iraq.)

Also, the Command-Control-D shortcut for invoking Dictionary doesn't like hyphenated words. And another thing, double clicking on a word in the full dictionary (i.e. the app not the popup) takes you to the entry for that word, very nice. Seems like it's using WebCore for the rendering, a copy and paste to get the definition above gave me some words in lowercase, even though they're in uppercase in Dictionary, my guess is CSS to the rescue.

Axis 1.2 RC1

OK, this release of Axis is worse than we previously thought. We're in the process of changing the name of an operation, and thought the easiest way to manage the change was to bring in another operation (being the new name), switch the tests over to the new operation, then remvoe the old operation. Simple.

Turns out Axis doesn't like two operations on the same port (my teminology may be wrong) with the same parameters. It generates code just fine, but ignores the SOAPAction header, selecting the first operation defined in the WSDL, instead of the one specified by the action header.

Nice one.

Update: Turns out that the I cannot reproduce this again on a different machine. We've changed the WSDL subtely (namespaces and element names), again which scares me.

A better WSDL

The project I'm currently working on is using Web Services as the integration point between itself an the outside world. After using it on a few previous projects, I once had no problems with WS, but have now come to look at it in a new light. There's a good adage that we've adopted, "if you have a problem and you pick XML as a solution, you now have two problems". I think the same sentiments can be levelled at WSDL.

We've found the technology we're using (Castor/Axis/XSD/etc.) to be "squidgy", such that it sometimes works and sometimes doesn't, failing silently sometimes, working other times when it should fail (for example allowing an operation to be invoked with no message, when the WSDL clearly states otherwise). We've taken steps to sure it up (such as hooking payload validation into the backend, but we're constantly butting heads with it, so much so, that we've developed a mini-methodology for working with changes to the WS interface (no such method required for Java integration points, they have their own niceties :).

I have no problem with WS in theory, sending XML across HTTP seems like a great way (albeit heavyweight) to do integration, what I do have a problem with is the current state of the standards and the tools (thankfully most are OSS so they can be improved readily).

Yes, we could have used a REST-based Web Service, but unfortunately bigger organisational issues prevented us from doing so. Still, it's not really the transport mechanism that is broken, much comes down to the way you declare your service, typically done using WSDL.

So it didn't really strike me as a surprise when I found that Tim Bray is also replacing WSDL with something better. He poses two options, his own SMEX-D and another, NSDL. Now, I'm yet to read either, but they both sound quite promising.

Update: XINS - XML Interface for Network Services seems to be another candidate in this simplification effort.

FileVault

Tim Bray is telling us that FileVault slows down your system 4x on writes... Hmm, not good, I'd just decided to give it a go on the new Tiger install on my PowerBook. After confirming the comments that I'd heard about IntelliJ being faster on 1.5 - I'm obviously not getting an apple-for-apple comparison - it seems it would be faster still if FileVault were turned off. Most of the observed slowness is in compilation before running tests, which writes quite a few files to the file system.

Test before vs. test driven

I've been seeing a lot of articles lately about "test driving" code when developing software. This has appeared most lately in an article on ADC, but also - as I've been looking for work recently - during interviews. Companies I've worked for have always written tests before they write code (or at worst, just after). This is often passed off as test driven code. However, it isn't. Test driving means writing a very simple test first, that forces you to write the simplest code that will pass the test.

So for example, suppose you want to create a class called Xxx. To do this, first create a class called XxxUnitTest. Add a method called testCreate():

public void testCreate() {
  assertNotNull(new Xxx());
}

What this does, is force you to write the implementation class. You can follow the same simple pattern for driving out member methods, the test doesn't need to stay the same, it can change dynamically.

public void testCreate() {
  Xxx x = new Xxx();
  assertEquals(“bar”, x.foo());
}

We've now driven out the method foo(). Repeating this process, we can drive out all the implementation, safe in the knowledge that we have pretty good test coverage.

If you always write the simplest code to pass the test, sometimes you end up needing to triangulate to drive out the desired behaviour. So for example consider the following:

public void testFoo() {
  assertEquals(“bar”, new Xxx(“bar”).foo());
}

This code implies that the constructor will store the string passed in a member field, then return it when getFoo() is called. However the simplest code that will pass this test is something like:

class Xxx {
  Xxx(String bar) {}
  getFoo() {
   return “bar”;
  }
}

This code passes the test, however, it doesn't express the intent implied in the unit test. So now, you need to include a new test that checks a different argument.

public void testFoo() {
  assertEquals(“bar”, new Xxx(“bar”).foo());
  assertEquals(“baz”, new Xxx(“baz”).foo());
}

So the simplest code that will pass the test will store the parameter passed into the constructor, and return it when getFoo() is called. Of course, this test lends itself nicely to a little refactoring to reduce the duplication in the test...

If we were to test before we wrote this class, we would potentially build up a large chunk of test code, that will contain a lot of compile errors, meaning the code is a long way from being complete at any point in time. We may also decide, once we write the code, that the test is not correct, as we learn something by writing the code that we didn't know beforehand. By keeping the tests and the code in tight sync, you minimise the amount of time spent in the wilderness, and ensure good test coverage.

This approach lends itself nicely to pairing. The pair can work off each other, one writes the failing test, the other does the simplest thing to make it pass, and the cycles continues. This shares the keyboard around, and introduces some good natured competition, usually producing better code than the traditional pairing approach of driver and navigator.

Up and racing

Well, after several months of being offline, due to the international move, my blog is now back. I shall be retrofitting all the old content again (for posterity) sometime soon, with more to come. Still not sure about this hosted blog thing, but seems to be all the rage...