What's it all about, Alfie?

This morning I saw another very interesting graphical equation editor for the Mac from chocomoko. I had used something like this back in my days at Auburn, and it was very nice, but Brisk seems to really be a step above what I had used. To be fair, that was 20 years ago, and on Mac OS System 7, but at the time it was awesome. I looked up the package a few months ago to see if they had been keeping up, and in a sense they were - but not in the UI - just the platform.

Brisk is a different way of doing it, and I have to say, it's an interesting take on the same problem. It's using LaTeX (I believe), but it's also completely drag-n-drop for the graphical editing, so it's possible to get into this easily and then use the LaTeX out of it for papers, etc. Not a bad idea. But it retains the complete Mac GUI with pasteboard access, etc. Nice touches.

If I have to write papers again, this is something I'm going to look into to be sure.

This morning I saw that Google Chrome dev 12.0.742.30 was out and the release notes say the only difference in this release is that they updated to the latest version of Flash. I'd forgotten that Chrome was using an embedded Flash, and dropping the embedded H.264 decoder. Two sad points, but it's their choice to include it or not. I wonder if there's a plugin that does the H.264? Anyway, still polishing up the product.

For the second day in a row I'm leaving on the last express out of the city. Man... these are long hours. I can't remember working this hard, but it's the weekend, and I can't work at home because I can't take it with me, and I have no remote access (yet). So it works out that I have a little 2-day vacation.

I need to get some sleep...

This morning I saw that Google Chrome dev 12.0.742.12 is out and it's still basically a polish release, but there's one rendering bug in the Mac version that's fixed as well. That's nice to see, but I hadn't hit that issue - yet. I'm guessing they are only a week or so away from releasing 13.0, and calling 12.0 the 'beta' release.

Progress.

We're making progress, but it's still a long way to go. This "Developer Day" project is turning out to be a lot more than a day. No question. But hey... with this part done we'll be ready to really deliver something really great. I just have to make it happen. Gotta hold out.

It's been a lot of work, and we have a little more than a week to go, but I think we can make it. I'll be close.

This afternoon I saw that Acorn 3.0.1 was out with quite a nice list of fixes and new features. It's pretty amazing, but I guess when you're on a roll, the ideas are there from all the suggestions, and you have a solid codebase to work from, so things should be a little easier. Still, it's nice to see the improvement.

This morning I saw a tweet that Twitterrific for Mac 4.1 was out, and hoped that they had done something to make the graphics switching problem I was having a thing of the past. Alas, no. But they did fix quite a few other things, and that's nice - for the day I'll be able to actually use it.

I like the new font rendering as I think it'll allow me to go back to the 'dark' color scheme and still read things. It's just a shame that I can't use it with my MacBook Pro yet.

This morning I was working on some code and it was getting a little frustrating working with the mongoDB replica sets - after all, they are meant to be able to switch the PRIMARY as will. Fair enough, but that makes it hard if you have to target the primary in your mongo command-line shell:

  $ mongo --host xchi43mongo:32018

where we might have a replica set of xchi43mongo and xchi44mongo. Seems they should make the third box in the set be the one to talk to - but I don't write it, so I have to try one and then another if I'm wrong. Kinda frustrating.

So this morning I decided to figure this out, and sure enough, mongoDB allows for referencing it's replica sets:

  $ mongo --host dapool/xchi43mongo:32018,xchi44mongo:32018

and it picks up the name of the replica set from your command as well as the machines in the set. Nice. I can see this - it's an alias now, and I can pretty easily deal with this.

Not bad, mongoDB.

This morning, once again, I'm getting timeouts hitting the mongoDB replica set in staging at The Shop. I know mongoDB is supposed to be this amazing piece of software, but I'm seeing it right now as a major pain in the rear. I'm looking at a database whose size right now is less than 10GB, and it's a major source of grief. We are having replication issues, and the erlang drivers had to be changed, and then retrofitted. The Java drivers had to be updated to get document sizes greater than 16MB.

But those are the known issues. It's these gotchas that are really annoying. I'm trying to get a single document from it and it's timing out. I get no idea why. One box it's fine, another box it times out. Same mongoDB, but different boxes. This worked yesterday, so what's changed overnight?

Arrggghh... I'm really beginning to hate this software.

UPDATE: it turned out to be the socket buffer size on the default socket for erlang. It was at something like 1kB and I was moving MB through. Very inefficient. When we got the socket options set right, the speed wasn't too bad. Not fantastic, but not bad.

Today was spent in a few meetings, and helping get a few developers on the right track, but when I had the time to do a little coding, I was working on getting everything glued together for the greek engine. Specifically, the first part of the engine will be a Broker service that will do all the what if scenarios for the users. This is something that the folks have wanted for a long time, and it makes a lot of sense to deliver this first, with the large-scale, center-state, reliable multicast, greek engine put together from these same components once we get this guy up and running so we know how much hardware to spend on the problem.

This phase of the project is nice in that it appears to be making a lot of progress in a very short time, but in reality, it points out where you made mistakes in the design up to this point. If you have a good design, then it indeed goes together pretty quickly. But if you missed something, then you have to go back and fix or retro-fit that, and then put things together.

Interestingly enough, I had a little of both today. My general Source and Sink objects needed to have locks provided on their lists, but that's because I was starting to violate the assumptions that had been made in their original design. I could go back and implement a lockless list, but that's a little overkill, I think at this point. If we need it, I know how to do it, I just need a little time to actually do it.

It's not done by any means, but it's getting there. Slowly, but surely.