What's it all about, Alfie?

This morning I finished up on a nice simplification that I saw in the Time and Sales service: the temporary structure I was using to hold the data from the Option and the Print was really a new message - the OptionPrint message. This is exactly what we need to send out to the new clients, and a version of this can easily be made to send out to the legacy clients.

So I gutted all the code in the service and made the new message in the old messaging codebase, and then retrofitted it into the new service. In all, it took me about half a day - finishing up this morning. But it's worth it.

Now, all the pieces fit again - if we wire up a transmitter to the service, it'll automatically send the messages out the proper channel - be that legacy or new. It also makes it very memory-friendly as the same structure that's hold the temp data is the message we'll be sending out. That means there's no conversion to a message - we just ship what we have.

It takes no more to create, and it's far more efficient to use. Sounds like a win to me.

This morning for the second time in about as many weeks, another group in The Shop decided to update their Mongo database, and it's going to cost me most of the day to fix my code because of the change. They say their java client to mongo was not allowing them to use larger than 4MB documents, but I've been storing 16MB+ docs in the database with the erlang driver. But they didn't ask me before they did it. They just told me they were doing it.

In going from 1.6 to 1.8, it turns out that there's now a hard and fast rule about docs being less than 16MB - so I get messed over. I am going to have to look at how all my documents are created and make sure that no one gets too big because the failure will hang my process. It's ugly - really ugly.

I think when I'm done with this, I'll try to put something into the configuration service that errors out if you send it a payload that's more than 16MB. This way, it can't let you save something too big, and erroring out is better than locking up every time.

Still... it's these "detours" that are really getting annoying - and quite avoidable. They could put up a dev environment and we can test, and then work out solutions before doing it to the staging install. That's what they should be doing. I've no reason to believe they will, however.

Seems the Google Chrome guys are busy - today it's 12.0.742.9 with the release notes calling it a release candidate. Interesting. If they are planning on moving the 12.x branch to 'beta', then they'll soon be bumping the 'dev' channel to 13.x - which is an interesting number to say the least. I wonder if anyone is superstitious? In any case, they are trying to polish up this version for the release, and that's always good news as it means a better experience for everyone.

Today I did a lot of work helping people get focused on what we should be doing. For my part, we needed a Time and Sales Service where each option trade sent to us by the exchanges needs to be captured, a few implied volatilities calculated, and then shot out to the waiting clients. This is really orthogonal to the rest of the greek engine, so I wanted to tackle that so it doesn't slow down other people, or divert them from the primary goals.

The design is going to be very simple: a service that takes an Option and a Print message and queues it up to be calculated and sent out. Very simple. The design is pretty simple: have a struct (object) that will hold all I need from the two incoming arguments, fill it on entry, queue that, and return. All this should be very fast as it's all just ivar calls to the base objects.

Then the queue has a processing thread, and will take these off one by one, calculate the values, and then generate the messages in the legacy and new formats so that we can feed both the old and new systems. Pretty simple.

This morning I had an interesting talk with my manager about the greek engine and what we might want to focus on in this first release. Rather than think about the general case of handling the entire market, which certainly needs to be done, let's focus first in the idea that the largest percentage of clients of the engine will be looking at a single family, and wanting to manipulate that one family to see different what if scenarios. In the end, we'll need to make an uber environment with all the instruments ticking, but that's a limit case, and will be able to be extended from this initial one-family case.

In addition to the what if work, the engine needs to handle the explicit requesting of options so that the client can say "show me everything between the Dec 150 and Dec 250 expirations". This "windowing" is done all the time to minimize the data traffic, and building it into the server means that it doesn't have to be built into all the clients. They just have to be able to pass the request to me, and then update the window with me as the scrollable region changes. Pretty neat.

In the end, I think this is a much more useful direction to go, as this is going to really change how we move data around the organization. No longer will clients have to take "the market" to get a few things. Now, they'll be able to ask for just what they want. Nice.

This morning I'm really having a hard time with a lot of things. Questioning a lot about who I am, how I approach things, how I react to things and people... and it's not at all fun. Not in the least. I'm wondering if my passion about things is really nothing more than my little rationalization for my actions. Does anyone really care?

Which reminds me of the great line in 1776 when Abigail is talking to John Addams and says:

Have you forgotten what you used to say to me, I haven't. Commitment, Abby, commitment. There are only two creatures of value on the face of this earth - those with a commitment and those who require the commitment of others. Do you remember John?

When I think of that I realize he's right, and so am I. OK... maybe neither of us are right, but I'd rather be wrong - like that, than sit around thinking there's nothing that can be done, or nothing that matters. Life matters, if only to me.

I don't expect a lot of people to agree with me, but then again, as Cher said, This life isn't practice for anything.

This morning I saw that Google Chrome dev 12.0.742.5 is out and the release notes say that this fixes a regression bug with sync and a few other bugs. OK, seems they rushed the last release, and this guy makes up for it. Sounds like a plan.

Today among the many little things I had to do for my greek engine project, I added the ideas that for each tradable instrument, there really was a traded volume per exchange, and for the Option, there is a quote per exchange. These are going to come in very handy when we have to look at the volume sliced and diced across different exchange sets, and when the consumers of this data need to see the latest quotes for an option across every exchange.

I was pretty happy that these both went into the design very well, and I spent probably a little too much time adding nice features to the basic data, but I think in the end, it'll be a better way to present the data, and it'll certainly make a solid example for the rest of the team as to how to do it well.

Besides this, it was a lot of helping others along with problems, and I realize that it's something I should be doing - even though it's not my favorite thing to do.

This morning I saw that Google Chrome dev 12.0.742.0 was out with "stability and performance fixes". Sounds like polish to me - nothing wrong with that. Keep making it better, and while you're at it - throw back in the H.264 will ya?

Today I got around to writing the iterators on my thread-safe Instrument list - hadn't done that before, and it was actually fun. Geeky, yes. But fun nonetheless. I just needed to get the style of the header right, and a first cut at the basic iterator and they were coming pretty quickly.

I wrote a simple test program as well to make sure that they were working, and it was pretty impressive (to me) that they worked right away. No problems. Sure, they weren't all that hard, but still - for not having done any in the past, it was a treat to get them done so quickly and done well.

There's a ton more testing that these guys need in order to be sure they are going to perform under load, but I can pass that off to a junior developer that's got a decent eye for details and he'll expand the test app to be a testing monster.

Sweet!