This morning I noticed that WordPress 3.1.4 was out, so I headed over to HostMonster and upgraded my installs using SimpleScripts. It's almost trivial these days, but that's a major statement of all three groups involved. Amazingly great software wonderfully supported.
Now that things are getting a little more stable mid-day, it's time to start addressing the all-important start-of-day and end-of-day edge cases for my Greek Engine. For example, I really need to add in the code to reset close price, open price, high price and low price for all instruments right before the open. That way, when the trading day (soon) starts, we'll be able to correctly deal with the trades updating these values. If we don't, then we'll get "bleed over" from the previous day, and while I was just trying to get things to work, it was OK, now we're raising the bar and trying to match the existing system more.
At the end of the day we have similar logic for the close price. We need to look at a snapshot of the last trade price at 3:02 pm, and then look for updating information from the summary messages coming from the exchanges. It's pretty simple, and I'll admit not all that complex, but it's necessary as we take the Greek Engine to the next level and really try to make it match the data in the legacy systems.
Nice to get to this level of coding. Not so much about crashing bugs, but nice little tweaks to the logic to make it really nice for the users.
This morning I ran into a nasty little seg fault on my Greek Engine and it appeared to be related to the multiple-producer/single-consumer ring FIFO where it appeared to have gotten a "dead space" in the FIFO, and with that, the head could not advance and so the queue filled and blew up. Again, I say it appears this happened, but I can't be 100% certain. It happened on several boxes, so I'm not ruling out bad input data, as that would be a far more likely issue, but other (slower) boxes didn't have this issue, so it's hard to pin this down.
What I can say is that there's always more than one way to skin a cat, and in truth, the particular queue I was using was overkill for the task at hand. As point of fact, the code only needs a single-producer/single-consumer queue and that's far simpler than the multiple-producer/single-consumer queue. So, taking a cue from my own advice about design, simplifying the code was the right thing to do. So I simply swapped out the one for the other and away we go.
Good advice - use what's needed, not just what's cool or flashy.
I'll admit that I'm a picky developer. I think that code is as much art as science. It's a craft, and needs to be respected as such. So when I have to work with folks, it's important to me that they have come of the same kind of respect, if not the same feeling about the code as I do. It's not required, but it really helps.
Lately, I've been asked to work with a group of guys that aren't really open to the ideas I have for code. I've been working with them for the better part of a year, on and off, and while they are probably fine developers, there's a reason we haven't worked closer in that year. In this latest effort, they are trying to add things to my codebase, and that's where things are getting a little sticky.
I don't mind if you make a mess of your codebase, but don't mess up mine. I plan on using this for a long time, and any crud you throw in there now is just stuff I have to clean up now, because I simply can't afford to let it sit there and rot. I need this to be solid, reliable, code.
So I'm going through the checkins, and I come across a template class that has no business being a template class. It's not even close. It's a horrible hack, but it's there, and I have to deal with a guy that thinks he's right about the template class, and he couldn't possibly be more wrong. Politics.
I try to explain that this really isn't the best way to arrive at this design, and I point out that it's not the first time this has been attempted, only to fail and write it in a more custom (non-template) version. It just doesn't lend itself to a good template. He pushes back, and then talks to his boss, and his boss, and soon it's this "Bob is stopping progress!"
Holy Cow.
What I want to say is "Just stop coding on my stuff. I'm going to change it anyway, so just don't bother." But I can't. I'd really like to, but I can't. So instead, I have to sit and explain myself to my boss, and let him deal with it. Thankfully, he's clear as to what was going on, and thinks I was fine in the email presenting my points in a non-emotional way. It just got out of hand by the other guy.
It's incredibly frustrating to take the time to make a nice, well-thought-out reply to someone you know isn't interested in reading it, only because to not do so makes you look like the "bad guy".
Arrgghh...
This afternoon I took a look at a guy's bug report that wasn't really all that good, but it got me looking at the problem, which was enough, I suppose. The background is that The Broker is an erlang process that has several built-in services as well as a simple means by registering services to The Broker so that clients can get at these guys easily and automatically route the data around. It's pretty nice, and one of the built-in services is the configuration service.
Basically, we have a mongoDB back-end and a simple service that allows the client apps to save and load all kinds of key/value data for all kinds of purposes. Some of my apps (ticker plants, greek engine) use this to hold the start-up configuration and load up this data on start-up and do all kinds of stuff with it. It's pretty nice.
However, there was a problem with a particular data structure coming out of mongoDB:
[{"key" : {"name" : "Bob", "age" : 49}}, {"code" : {"name" : "Boo", "age" : 72}}]
basically, a list of maps where the maps each have only a single key/value pair. It was coming out as a list of four items: key, map, key, map - not at all right. So I started digging into it. The only really useful way to handle this is to log what's coming out of mongo and fix up the erlang matches based on what is as opposed to what you think should be.
With just a few test cases down, we had the matches fixed up, and the outgoing mongo conversion was far cleaner. We totally re-wrote the method because it was just too difficult to follow, and made it a series of function calls, allowing erlang to figure out what version to call based on the data.
Then I went to fix up the ingoing mongoDB function and wham! I hit a wall. I spent quite a while trying to figure out why the conversion wasn't working. In the end, I had to calm down, pull back, and take a slightly larger view of things. Turns out, the original author had sprinkled conversion code in a lot of different places in the module - and the conversion we'd done was complete and needed nothing else. So the "double-decoding" was really one too many.
Once I took those out, things started working like I had expected them to. I was just too close to see that other code in the module was effecting the data we're getting out of mongo. Lesson to self: look larger next time.
This morning I was trying to figure out this very nasty intermittent bug I was having with a client hitting my Greek Engine from The Broker. Very frustrating, because I've been thinking I got this guy at least a half-dozen times before, but every few days it pops up again. The problem was two-fold: first, there was a real bug in The Broker that routed away requests for services that were local, and the fact that I had two machines so the routing could take place. This meant that all the fixes I was making to a service weren't really being uniformly tested because many times they were routing away to a broken service. No fun.
The solution was to fix the bug in The Broker to sort the different instances of the same service properly, and that placed the local services at the top of the list - thus killing the "away routing". The next helpful thing was to drastically simplify the service I was writing to be self-contained. This means that it's not hitting that many other services asking them for data. This keeps the dependencies down, the speed up, and the vulnerability to routing mistakes to a minimum.
Good to get done. Not easy to find, to be sure, but nice to fix.
Today has been spent doing a lot of little things to get a production set-up of my Greek Engine going. The goal has been to get something all up and running by tomorrow afternoon, and I think it's very possible, but it's going to mean getting a few last things figured out.
But today was getting machines going, loading up the accounts, the code, getting a deployment strategy going... all those things that you have to do to get something in The Show. Nothing horribly hard, just a lot of little details.
This morning I saw that Google Chrome dev 14.0.806.0 was out and the big changes (other than breaking the Mac relaunching) is the latest V8 engine - 3.4.6.2. It's nice to see them continuing to make the JavaScript faster and better, even though it's all under the covers, it's becoming a platform for application building, and in that, it's nice that folks are still working on it.
I read a piece this morning about the browser being "done" - and for the feature set it focused on, it pretty much is. Pages render, links work, speed is pretty good, so it's all going to come down to polish. If you can make the JavaScript faster, then more complex things can be done in it, and the "richness" grows. I'm hoping that they keep pushing Apple to improve Safari as well. It's a nice platform to build on.
These GitHub Guys are pretty amazing... already they have released GitHub for Mac 1.0.3 and it's fixed a lot of the issues I had - save two: the ability to set my picture for local repos, and the ability to set the description of the local repos. I've sent these to the GitHub guys, and they say "Not yet, but maybe", and that's good enough for me. Face it, that's about all I could have expected.
It's smooth, slick, everything you'd expect from the GitHub crew - but it's all on my Mac. Love it.
This morning I got a tweet that MacVim Snapshot 58 was out, so I went to get a copy and see what had changed. I was very excited to see the latest Vim source included as well as a "significant" memory leak plugged. I haven't had any real problems with MacVim, but when the guy building it finds something significant, it's nice to know he's looking.
Still one of the best editors on the planet, get it if you're a Vi/Vim user.