Thursday, February 25, 2010

Fudge Messaging 0.2 Release

After I initially announced the first release of the Fudge Messaging project, we've had a lot of feedback on the code and on the specification, and we've been using it in anger quite a bit here at OpenGamma.

We've also been making a lot of enhancements, and are pleased to announce the 0.2 Release of the combined Fudge Messaging project.

While there have been a number of enhancements throughout the code, the primary focus of this release has been on making it easier for you to start using Fudge in your applications. With that focus has come a number of significant new features that you should be aware of:

  • The Fudge Proto sub-project has been released for the first time. Taking our cue from Google Protocol Buffers, we have a .proto file format which can then generate out Java and C# language bindings for automatic conversion of objects to and from the Fudge encoding specification.
  • We've made it substantially easier to build up an Object Encoding/Decoding Dictionary so that if you want to hand-write your mappings between Fudge messages and Objects, you can still access the auto-conversion functionality in the Fudge Proto project.
  • We've built up a number of Automatic Object Conversion systems, so that even if you have nothing other than Java Beans/POJOs/PONOs, you can still automatically convert those to and from Fudge messages.
  • We've developed Streaming Access APIs so that you can consume and write Fudge fields without having to work with an entire message as a bulk operation (we'll be using this for our automatic conversions to and from XML and JSON).
  • A C Reference Implementation has been written. Already tested on a number of different Unix-like platforms and Windows, this will be the foundation of our eventual C++ version. As well, it can be used to support Fudge messaging in your favorite language which allows easy C bindings.

Our next release (0.3), will really be a release candidate release for 1.0. Our primary focus there is to work through any features that have been submitted by the community, and to finalize the one piece of the binary encoding that hasn't been completed (moving from Modified UTF-8 to true UTF-8, which won't affect you unless you want to encode Unicode null or certain high-bit multi-byte Unicode characters).

If you've thought having a self-describing, compact, binary encoding system ideally suited to distributed applications was interesting, but didn't know if we were ready for you to use in anger, don't wait. It's ready.

Tuesday, February 09, 2010

OpenGamma Set To Welcome Stephen Colebourne To The Team

As you can read from Stephen's blog post on the subject, he's coming to join the OpenGamma team in the beginning of March.

On JSR-310

Just to reiterate what he said in his post, one of his first duties at OpenGamma will be to get JSR-310 to at least reference draft status. When we started building our platform we made a very early bet that JSR-310 would be the ultimate future of dates and times in Java. That decision has brought a lot of power on working with dates and times for us (for example, we haven't had to build our own system on top of java.util.Date that every financial firm I've ever worked for has done), but we think that with a strong, concerted effort we (as a community) still have a chance to get JSR-310 as the defacto and dejure future of dates and times in Java.

Stephen mentioned earlier on the mailing list that a lack of time outside work has contributed to the slow-down of JSR-310. We're giving him time and resources during the working day, and waiving ownership of the code that he produces.

We're not hiring him just to work on JSR-310, but it seems obvious to me: financial software probably depends more than other software on having strong tools for working with the multiplicity of date and time rules that proliferate in finance. If giving Stephen the time he needs to finish off JSR-310 gives us those tools in a standardized way that the whole community can benefit from, that's far better than building Yet Another Proprietary Date/Time System.

On Non-Financial Hiring

When I mentioned in passing to a few people that Stephen was joining the team, they were quite surprised, because they thought from my original blog post on OpenGamma hiring that we were only looking for financial industry professionals. That was true at the time I posted it, but it's not true today.

If you take a look at the current OpenGamma Jobs page, you'll see that we put far more prominence on pure programming skill these days than financial industry expertise. Sure, if we have a choice between two candidates, identical in every way and one comes from the financial industry and one doesn't, we'll choose the one from the financial industry. But people are unique. We never see two candidates that are identical in every other respect.

And that's why we're eager to hire people who don't come from finance. We're building software that's complicated enough that we need the best across the entire software development industry. Unlike a common attitude I encountered by recruiters when I first moved to the UK, we're not under some assumption that the only people who are any good are the ones working at a Tier-1 bank or a hedge fund.

We made an offer to Stephen because he's a fantastic software developer and architect that we think will make an immediate and long-term impact on our success. We're thrilled that he's decided to join us.

We're Still Hiring

So if you were on the fence before, or you thought that we only wanted someone with N years of experience at some bank somewhere, think again. We want the best, no matter what their background. Email us your CV.