Feynman

I grew up on Richard Feynman though wasn't really able to appreciate him until I started my physics undergraduate degree. He's definitely a hero of mine. One of the best programs I've watched about him didn't actually concentrate on his deep physics background, but was about his trip to Tuvalu. So it was with pleasure that I came across Project Tuva from our friends at MSFT.

Memories ...

While looking for something else, I came across this old ANSA/Esprit project proposal from about 1989. One of the earliest external project memories I have and a good one too! Then I thought "Oh, that's 2 decades ago! Oh frack!"

SoyLatte

So far my adventures in JDK 1.6 land have been constrained to a 10 year old Windows box, so I decided to upgrade my Mac. Unfortunately the machine I've got isn't 64 bit so the official Apple version doesn't work. Fortunately the SoyLatte distribution seems to work very well. Yet another example of good open source at work.

Scala round 2

I mentioned earlier this year how Mic had pointed me at Scala. I haven't had nearly enough time to play with it (which usually means me implementing a transaction service in the language!) but from what I've seen I'm impressed. It's interesting to read what others think too.

Walking with Dinosaurs

I remember watching Walking with Dinosaurs when it first aired on TV and being impressed with the graphics and story. The rest of my family were equally impressed. So when we heard about the Arena Spectacular version and that it was coming near us, it was something we had to see. I took the day off work to make sure no one could plan anything for me to get in the way and we went to see it: well worth it and I'm extremely impressed! So if you like dinosaurs or your kids do then go and see it if you get the chance. If you don't have any kids then borrow some so you won't look out of place!

Principles of Transaction Processing

I've known Eric as a colleague and friend for a long time, but my first run in with him was with his and Phil's first edition of Principles of Transaction Processing. Along with Jim's book, it has a key place on my bookshelf. Over the years I've probably bought a dozen or so copies for various groups I've worked with. Well it's good to be able to say that they've released a second edition. I was one of the reviewers of the book over the past couple of years so I know this is a solid replacement for the original. Well done!

Supporting performance?

Given my background in fault tolerant distributed systems, performance metrics are something that come up time and time again. I've spent many a happy hour, day, week, month pouring over timings, stack dumps etc. to figure out how to make RPCs go faster, replication to scale and transaction logs to perform. (Funnily enough I was doing the latter again over Christmas!) But this is something we've all had to do when working on Arjuna.

If you've ever had to do performance tuning and testing then you'll know that it can be fun, but often an almost never ending task. Then there's the comparisons between different implementations. This isn't just a vendor-specific area: even in academia there's always a bit of "mine is faster than yours" mentality. I suppose it's human nature and in some ways it's good and pushes you to improve. However, performance measurements need to be taken in a scientific manner otherwise they are useless. It's no good to simply state that you get "X transactions a second" if you don't specify the conditions under which that figure was achieved. This is true for a number of performance metrics, not just in the computing industry: there's a reason world records in athletics have defined conditions, for instance.

Now of course you may not have the same hardware to test and the tests themselves can be notoriously hard to access from one vendor/competitor to another. What tuning parameters they use as well as the general configuration can also be difficult to obtain. This is why Jim Gray and others wrote A Measure of Transaction Processing Power (though the principles in there can be applied much more widely.) This eventually produced the TPPC. But the general principle here is a scientific approach to performance metrics is the right way (though it's still possible to skew them in your favour.)

Whenever I see or hear of performance figures I always want to know the conditions (hardware, configuration, wind conditions etc.) It's not possible for me to take them seriously unless I have this additional data. Giving out the tests themselves is also a good thing. However, performance is not something you can support like you do with, say, transactions, where you either are transactional or you're not. With performance it can be a never ending struggle to keep improving, especially as hardware and software improve and your competitors get better too; you've always got performance even if it's bad! Performance is something that for some users can be as critical as new capabilities, or even more so. But it can't be performance at the cost of reliability or robustness: something that screams along faster than a speeding bullet yet crashes after 24 hours is unlikely to be as useful as something that is half as fast yet able to stay available indefinitely.