Today I got a tweet about BBEdit 9.6 being released, and there are a lot of nice features and fixes in this guy. I'm really quite impressed that they keep being able to move the state of the art on editing forward, but then again, so does Transmit. I guess it takes smart guys, and they'll keep the code moving forward.
Anyway, it has some interesting features, and well worth the time to upgrade.
This morning I noticed that the guy(s) at Flying Meat have updated Acorn to 2.6.1 with several fixes. I hadn't run into any problems, but clearly after the 2.6 update, there were a few lingering issues that needed to be hammered out. Glad to see the progress and attention to detail.
Today, after I built the 128-bit integer, I started a massive refactoring of the ticker plant code to swap out the uint64_t "security ID" from the instrument master database with a std::string that is the name of the instrument. The reason really boils down to dependencies, and while it's not perfect, it's better than the uint64_t.
If we have a database that is the sole dispenser of the security ID, then every time I need to make a new one, I have to go to that database. In theory, this is a good idea, but in practice - for a ticker plant, it's a horrible idea. With thousands of ticks a second, not being able to get one means a several second delay in the processing of that one tick in order to get the security ID.
This isn't rocket science, but it's also unnecessary. Every downstream system can get the security ID from the database - or have it make one for them, if they need it. What the ticker plant provides should be a nice, concise, simple, fast data set that is a source of ticks.
The changes are really quite profound. Now, instead of a nice 64-bit integer to use to uniquely identify the security, I have a string. With this string, and the 128-bit integer class I made, I can still use it in most of the same ways, but the speed is taking a hit for certain. I'm just not sure how much until I get everything in and start testing.
Shouldn't take too much longer... I hope.
In the past, I've built UUID classes in Obj-C, Java, and C++, and in the recent project of my ticker plant, I did it again. It's not hard - you put 16 bytes in a union and allow them to be accessed as bytes, or words, and add a few methods and you're done. But today I realized that those 16 bytes could really be much more if I created a uint128_t. Basically, I created a general 128-bit unsigned integer and then subclassed the UUID off that. It wasn't that hard, but I was trying to encode a generic instrument name, and realized that a uint64_t wasn't going to fit, and it made sense to see if I could make it work with the new 128-bit version.
It didn't take me long, and the code was really pretty primed for it's use. The only thing that remains to be seen is the issue of performance. In general, there's going to be a performance edge to the built-in uint64_t because it's an internal CPU type. But exactly how much performance I give up for that doubling I don't know. We'll have to see as I put it into play.
I was watching the ZeroMQ IRC channel today and hear mention of an interesting alternative to Google Protocol Buffers - MessagePack. I'm not making any claims here, but the wealth of the client libraries for MessagePack is quite impressive. Additionally, while Google Protocol Buffers is working really well for Google, the marketing fluff for MessagePack seems to indicate that it's got a few features that Google's offering doesn't.
Also, they are as focused on speed as the Google folks.
I'm not sure what's going to become of this knowledge, but I do know that our in-house Broker is doing a lot of the same things, and it might be time to look at an alternative to the home-grown cross-platform serialization schemes. Maybe.
This morning I noticed that Google Chrome dev 8.0.552.11 is out, and the release notes say the changes are minor - with the standard stability fixes. There is still the graphics rendering issues when scrolling in a zoomed view, and without a fixed zoom level, I'm stuck with 83% as the first zoom level "out" from 100%. I would like to be able to say 85% or 90% - but no such luck.
But I'll keep hoping that someday soon these things will get fixed.
Today was spent dealing with this external data service that's delivering massive data sets to my ticker plant for it's use. It's basically a bunch of look-up tables - 400,000 rows in all. It's massive, and so there's going to be lots of issues with loading and accessing, but also the time required to get it all in-memory and running.
Details. It's all in the details.
I've got it to the point that it all loads, but there are a few things I'm not really happy about. First and foremost, is the asynchronous loading of the data. I had to do a few tricks to make sure that we didn't immediately reload the data after loading it once. When you place a simple lock on the loader, that's exactly what you can get: a back-up of loads. Not ideal.
Then we're left with the idea that the second call to the loader thinks the load is done because someone else has taken care of it. But it's not really done, it's just being done. So data might not be there. It's a non-trivial problem, and I'm going to have to deal with it sooner or later.
Like I said... it's all in the details.
I got another tweet today saying that Acorn 2.6 is out and it's got an impressive list of features. I'm not sure what I'll be using in the new features, but the Quartz Composer filters sounds pretty nice. Plus, there's a lot of nice fixes in the app too. Pretty nice.
Impressive day for the Flying Meat guy.
Today I got a tweet about the release of VoodooPad 4.3.1. The update is pretty surgical with just a few things updated, but the syncing with the VP Reader on the iPhone is nice. Nice to see.
This morning I noticed that Apple updated the Java deployment on OS X to 1.6.0_22 to bring it current with the latest offering from Sun/Oracle. There have been a lot of little improvements and security fixes for the JVM and it's very nice to see them kept up to date on the Mac.
Like it or not, Java is here to stay and it's an important part of my daily life.
UPDATE: This is not a good development:
As of the release of Java for Mac OS X 10.6 Update 3, the version of Java that is ported by Apple, and that ships with Mac OS X, is deprecated.
This means that the Apple-produced runtime will not be maintained at the same level, and may be removed from future versions of Mac OS X. The Java runtime shipping in Mac OS X 10.6 Snow Leopard, and Mac OS X 10.5 Leopard, will continue to be supported and maintained through the standard support cycles of those products.
Now I can understand the "Back to the Mac" idea of not putting Flash on the newly shipping MacBook Airs, but that's easily fixed - just install it if you want. They aren't trying to stop you on your laptop. But this... this is bad news. I've been using Java on the Mac for a lot of years, and it's been a fantastic platform for that. I just don't know why they'd want to ditch it unless it's about the Oracle acquisition or something.
I just have a bad feeling about this...