What's it all about, Alfie?

I've been in a lot of meetings all afternoon, but in the end, the good outweighed the bad. These other groups had their own biases, of course, and no one wanted to "just give in" and use the stuff I've been working on, but that's really understandable. After all, a few lifetimes ago, it wasn't until after my ticker plant was proven for the most demanding client (my own risk engine) that other people started to see the value in it. SO it goes... I'm going to have to prove it, and I understand that.

Still... they had several good points:

• If we conflate the messages by type and instrument, how will they know that any conflation happened? It seems reasonable that they should be given some kind of information about the conflation being done.
• They'd like to be able to know what "stream" the message came from. There's 24 OPRA channels, and they'd like to know which one sourced this message. That's fair, but I have no intention of putting that in the message - that's going to be a client-side look-up method to keep the messages small and useful.
• The exchange is an important part of the conflation - meaning they want to have one quote message for the AAPL Jul 350 C per exchange. Yikes! I hadn't planned for that. That's going to make the cache much larger, but so it goes.

Many of these aren't too bad to add, and it's reasonable to get them out quickly, but some of the others are a little trickier, and it might be better to think of the real solution to the problem as a completely different kind of answer. For example, what about having a message with all the exchange prices and sizes for a given instrument. Then, when it's shipped out, the user gets all the prices - at once. It's got possibilities.

It's late and I need to catch a train, but it's a lot to do in the coming weeks.

This morning I've been working more on the lisp-like parser for embedding in my projects, and it's coming along nicely. I realized that I needed to make my collections use pointers if I wanted to really use polymorphism, which just makes the housekeeping a little more, but other than that, it's fine. With that, I'm getting the right messages dispatched to the right instances, and things are moving right along.

I have been adding the function class to the code this morning, trying to get the evaluation of functions going. It's just a lot of little details and lots of writing. The base classes aren't bad, but every time you start another, you're looking at a good bunch of typing. I just need to get the first version hammered out and then I can look and see if I need to make it faster.

The rest of the day is in meetings, but it's nice to get it all moving forward this morning.

One of the many potential next projects for me might be a greeks server - like I've worked on in the past. The difference here is that it's targeted to me a lot more flexible than the old MarketMash system - this one is going to allow for the clients to give it "mutations" to the center state so their numbers can be as good, or bad, as they want. I've fiddled with a lot of different schemes for specifying this kind of mutation - including muParser. But those don't seem right in this context.

The choice for this seems to be a lisp-like language that is in use in some other projects in The Shop, and it would be a natural fit to have a C++ version of this for any C++-based projects. Right now, the only version is a Java-based one, and while that's nice, it's also heavily customized to the application it sits in. What I'm looking for is a simple parser that can have variables, constants, functions all added to it - augmenting a nice set of default capabilities so the user can make of it what they want.

The language isn't really hard. The expressions are really pretty simple:

  (set boo 5)
  (+ boo 10)
  (* 12 5 3)
  (avg (min boo 5) (max boo 5))

stuff like that. Each expression has a function as the first argument, and then a series of items - which can be values or other expressions. I've just decided to make the Item a base class, subclass Value and Expression, and then start the coding.

Today was all the parsing of the input text, and it's pretty nicely compact. I'm pleased with the way it's looking. Tomorrow is the functions, etc.

Seems Google Chrome dev 10.0.612.3, out today, fixes a regression test with the RegEx in the engine, but that last part is an assumption that wasn't explicitly stated in the release notes. In any case, it seems that we have two regression test related fixes in just a few weeks. The engineers at Google are slipping... maybe they've had to lower their standards to get employees?

OK... maybe just sloppy - but which one is the worse explanation, really?

Today was heavy with meetings, but I was able to get some nice work done on my ticker plant - the Java guys were interested in using my security name to 128-bit int converter as it was non-lossy and bi-directional. There are times they want to use a number but not loose the ability to pull out different aspects of the instrument. What I went with was a subclass of my UUID where I added in a lot of nice helper methods:

  tInstType getType() const;
  bool isStock() const;
  bool isOption() const;
 
  std::string getUnderlying() const;
  uint16_t getExpiration() const;
  float getStrike() const;
  bool isPut() const;
  bool isCall() const;

where I've dropped the comments for the obvious nature of these methods. The point is that we aren't going to decode the entire 128-bit stream to get the one bit that's the Put/Call flag, so these guys allow you to get the one piece of data you want without having to convert it all into a string and then parse that.

I got this all in, and the tests were just fine. I even had the operator=(std::string) written so you could do something like:

  msg::ng::secID_t   id = "O:GOOG:110214:74550:C";

and it'd parse the string into the 128-bit number and be ready to go. Should save a lot of time.

Finally, I added this as a possible component of the variant class so that it could be put int he codec for the messages to the Broker. This will really help move things around as we'll be able to handle getting this as a data type in anything coming from, or sending to, the Broker. Very nice.

But then there were more meetings, and some were really draining. Still... it was nice to have a little bit of work under my belt for the day. Made it feel like it wasn't totally spent in meetings.

I noticed this morning that Dropbox 1.0 was finally released. This is a major move for something I've used for quite a while. The story is impressive in what they have done and are now capable of doing. I'm a believer. It's like github for syncing clients. Very exciting to see the 1.0.10 release and start to use it.

This morning Google Chrome dev 10.0.612.1 was released and represents a big jump in the browser, specifically, the new V8 engine (3.0.2.1) is in there, and the new WebKit (534.15) is in there in addition to a mess of other new stuff. I'm interested in seeing how this guy tests out as it should be a significant improvement to what I've had for a while. Exciting times...

I probably missed this by a week, but today I noticed that Apple has updated Xcode to 3.2.5 with the final release of iOS 4.2 development tools. I'm not doing any iOS development (yet), but it's part of the update, and that's a good thing to have. I'm still very anxious about the release of Xcode 4 with the new features like better built-in SCM and history, and the toolset... it's going to be very nice.

This morning I updated iTunes to 10.1.1 from Software Update. The release notes said that there were a few problems with music videos, of which I have none, and something else. Again, I'm not at risk here, but it's a good idea to stay up to date as much as possible with this stuff. You never know when the syncing will depend on the version of iTunes you have.

This morning I see that BBEdit 9.6.2 is out with a pretty extensive list of fixes. I have to say, it's a sweet editor, and I wish it was embedded in MarsEdit, but hey, that's another wish for another day. Still... great editor for the Mac.