What's it all about, Alfie?

This morning I've come across a real possible good use for a C++ IDE - renaming a namespace in all the places it exists. I realized that when I had the namespace AppKit in another project and wanted to use it in the greek engine project, I couldn't have eng::AppKit because the compiler couldn't tell what to do with:

  AppKit::Message msg;

Is that AppKit on it's own, or in the context of the eng namespace? I knew which one it was, but there wasn't any way I could fine to make the compiler understand that fact.

Also, I knew that the namespace was badly named. I just didn't understand how widely these things would be used. My fault. So I tore into the code with Vim. There's lots to like there, but doing a massive change like this is just not all that easy. It's not hard, it just takes time.

If an IDE could do that, I might have reached for it. But I didn't know one, so I toughed it out.

This morning I wanted to hook my new MacBook Pro up to the existing TimeMachine backup stream that I've had going for quite a while. The problem is that in the past, it's been a someone manual operation, and with the loss of the ACL control app in Snow Leopard, nearly impossible. But I was being silly, wasn't I?

Turns out, that in Snow Leopard, if you just hook up an existing TimeMachine drive to a new machine, it'll ask you if you want to continue with this backup set on the new machine! This is exactly why I love Apple. They think of these things, and plan for them. In the past, it was manual, but now it's automatic.

Gotta love these guys!

This afternoon I got the combined pricing feed for the greek engine working. It's not that hard - just a combination of an existing UDP exchange feed and a receiver of the legacy data with a little NBBO engine thrown in to generate the NBBO quotes for these options. It's nothing that amazing, but it needed to be put together as a unit so that it's a lot easier to use than glueing all those pieces together in the greek engine.

Not glamorous, but it's got to be done.

I looked at the tracking for my new MacBook Pro from Apple and noticed that it was out on the FedEx truck for delivery! I like tracking it from China, but I like even more the idea of getting an amazing new laptop! This guy has the fast i7 processor, with 8GB RAM and the 512GB SSD. I know that my existing Core 2 MacBook Pro will seem very slow in comparison.

Quad core... I've been waiting for that for a long time. And even the memory is faster. This is going to be a major upgrade. I'm really jazzed about it.

This morning I had an interesting little problem - WordPress 3.1.1 was released with a few nice little fixes, so I went to HostMonster to update my installs. The problem was that since that odd little 3.1 double upgrade, I was unable to upgrade to 3.1.1 because SimpleScripts was saying that the version number was wrong. Not cool.

I'd been upgrading every time SimpleScripts instructed me, but the second upgrade to 3.1 didn't seem necessary, but I did it anyway - and everything worked. But it wasn't without consequences, it seems. So I had to cancel that update - which wasn't obvious, but I figured out, and then I had to upgrade to 3.1.1 within the WordPress site, and then try to upgrade in SimpleScripts.

This second (unnecessary) upgrade finally detected that I had the version that I was updating to, and it just updated the version number in SimpleScripts. This was a big "Whew!" on my part, and it's nice to know what my options are in dealing with these updates. So it's all up to 3.1.1 and things are smooth once again.

This morning I saw the tweet that MarsEdit 3.2.1 was out with a few nice little fixes. I hadn't been having any issues, but it's still nice to see Danile make progress. I'm still waiting for that BBEdit/Vim/SubEthaEdit editor in MarsEdit. I think it could really use it.

Another late night trying to get what Joseph calls my Impossible Project done on time. I've finally been able to let the Broker sit for a while, and I'm on to getting the database abstraction layer for the static data we'll need in the greek engine working. I've got a good start on it, and SQLAPI++ really helps, but I wasn't able to really get it nailed down before I had to run for the train.

It's getting a little old - these sprints for the train. But hey... it's part of the job these days. I know it's a nearly impossible timeline, but it's what they've asked for, and I'll do my best to deliver it to them as they asked. That's the deal we all make in a business.

I've got about another hour left on this guy and then my first database table will be done and I can hand it off to someone else for them to work in all the other tables that need to be included in the interface. Once I have all this stabilized, I'll work with the static data vendor group and see about converting these into more generally usable Broker-based data services.

Just for right now, it's enough to get them loaded from the database. We can get the rest done later.

I've been working on the conversion of my Broker code to the new replica set-compatible erlmongo driver. It's not horrible, but the worst part is what the worst part always was - getting the data in and out figured out so I can write the correct matches in the code.

They store the arrays differently, and they don't like the long binary-data strings that I've been using, but after I figured out all the gotchas, it's working again. It's just not easy.

Plus... this is more than half a day shot on something that I didn't need to have done had they not switched the database clustering... and I'm on a week-and-a-half deadline. Not ideal at all.

But it's done.

This morning my newly re-written Broker was not working. Hmmm... so I look at the logs, and it's not too hard to see that there are timeouts on the emongo driver. This was the driver that I used to get from erlang to (and from) the mongo database. Now all of a sudden, it's giving me timeouts. I had no idea.

When the guys that handle the mongo DB arrived today they said that they reconfigured the mongo DB I was using from a single server to a replica set. This is a fault-tolerant mongo DB setup, and in general, I'm a fan of things like this.

But that's not how today went.

Oh no... turns out the API into a mongo replica set is not the same as a single server, and moreover, the emongo driver doesn't support the replica sets. Fantastic!

So now all the work I just finished has to be re-examined in light of a new erlang-to-mongo driver: erlmongo. This guy is capable of dealing with the single server and replica sets modes of mongo DB. This is good, but the API is very different, and most importantly to me, there are no connection pools. If you want to talk to a database, you have to open a connection to the database and then hold onto it.

Given the realities of erlang and persistent state, this isn't really a possibility. We need to have a module that's a connection pooler, and then be able to set that guy up and let him deal with opening the connections, etc.

So here I am, fixing code I just wrote because some other group decided to change the database into an incompatible format. Lovely. It's unavoidable, as it's their group, and their database, but it's a real pain - right on the heels of just getting it done.

This morning I saw that Google Chrome dev 12.0.725.0 was out and the release notes say it all:

All

• Updated V8 - 3.2.6.0
• Spring cleaning in the code, lots of code cleanup and refactoring under the covers

It's nice to see the clean-out of old code. I'm sure there's a lot that's sitting there - like maybe the H.264 decoder... OK, enough of that. In any case, at least they got the icon back. Baby steps.