What's it all about, Alfie?

This afternoon I saw that Twitterrific for Mac 4.2 was out with a nice list of features, improvements, and bug fixes. Unfortunately, among them is not my bug with the graphics-mode switching. It seems that this guy is still not smart enough to properly detect this and cope. Kinda depressing. I'm still having to stay on integrated graphics or deal with a broken Twitter client. Not like it's the only one, Twitter's Official client is just as bad.

Sad.

This morning I had a nice, long, talk with one of the developers in the shop about a project he was going to be working on. The problems I saw in his design were significant. The application was non-trivial, I grant you, but that should have been an indicator to him that the simple solution of a few structs in a trie wouldn't really be sufficient. Because of the way the feed is coming from the exchange, we really need a far more complex data structure. It's going to make things much faster, but it's going to take a significant amount of time to build.

He was going to build a train wreck, and I hope we averted it. We'll see. There's a lot that needs to be built. I'm sure this isn't the last time we'll talk about it.

This morning I found myself sitting here with nothing at all to do because one of the systems I depend on wasn't up, and there was no one here who knew how to get it up. That's a common problem for me, and in the past, what I've done is to learn how to get these things up, and then get them up myself. It always reminds me of the line on West Wing I saw so many years ago: People... Problems are solved by people that show up.

I could not agree more. Show up. Solve problems. After the day I wasted yesterday on this horrible double-bug, I'm not one to say bad things shouldn't happen - they do. Period. But it's the showing up that's really the key. If there's a problem, then by showing up, you can help solve them.

And showing up after it's solved is like not showing up at all.

Today I've spent all day tracking down the most devilish bug in my code - yup, right there in my code. And the reason I didn't see it right away is that this code hasn't changed in several days, and it's been working perfectly for quite a while. But the trick was that it unknowingly depended on another bug, that was fixed yesterday evening, and because it was fixed, my bug became a real bug. But figuring this out was a painful, and laborious, task.

The set-up for the way it used to 'work' was that I had two services, on two boxes, and each service was hosted by a Broker:

The client would randomly contact one of the locator services - most likely, it would be the one on the same box as he was running - but there was no guarantee to this. But for the sake of example, let's say it hits the red box. The locator service is asked "can you handle this symbol?" and if it can, it responds to the client immediately. If it can't, then it asks the Broker to list all services that start with the same name, and then proceeds to ask each if they can handle the symbol.

The red locator hits the blue locator, and since it's got to be one or the other, it answers pretty quickly. So where's the bug? Well... the first one is that if there are two services with the same name, we should 'prefer' the service on the same host as the client. This minimizes the network traffic and keeps things "local" as much as possible. You can see it coming, can't you?

With the preference set to local services, the red locator will ask the Broker for all similarly named services and get - you guessed it: itself! This places it in an infinite loop - but with boost asio, there's only one thread to process things, and that one thread can't receive and send at the same time, so we lock up.

So the fix was simple - don't ask for all similarly named services - make sure you exclude yourself! With this simple one-line fix to the code, everything worked again. It was just a complete day trying to figure out where the problem existed in order to figure out that one line that would do the trick. Ick.

Over the lat few days, it's been clear that there's been a problem with Adium 1.4.2b2 and ICQ. Basically, ICQ is saying there's no connection, or the developer ID is wrong - lots and lots of problems. I checked earlier today on the Adium IRC channel to see if they knew this was going to be fixed in an upcoming release. What I found was that ICQ is big in Germany - who knew? Anyway, 'yes', it was going to be fixed in 1.4.2 final, and I just needed to hang on.

I then asked if they had even an estimate on when that might be released - as I'm really tired of all the errors and alert klaxons going off. They said that they hoped to release it today. Very nice!

Sure enough, a few hours later, I got a tweet that Adium 1.4.2 was out, with a pretty nice list of updates. The lone problem was that the version of libpurple (old 'gaim code') had a few nice MSN features, but in three areas, it slipped backward. The Adium developers decided to go for the greatest good for the greatest number, and use the new libpurple, and slip on the three features. Evidently, it made some MSN users less than happy.

I can understand their concern, but at the same time, I can see why the Adium developers did what they did. They didn't write libpurple, and they have to take it as-is and use it. They then just have to decide which version to use, and to them, the greatest good was in moving forward, and the unfortunate consequence was that a few things slipped.

I'm sure it'll be updated soon to 1.4.3 with a new libpurple, and that's OK too. It's what the group needs to do. I just don't see people getting that upset about it. But then again, I don't see a lot of things...

This afternoon, while I was watching my Greek Engine just hum along as pretty as you please, I decided it was time to get busy on some of the lesser projects that needed to be done. One of the first was an exchange feed recorder. Basically, we needed to just take all the UDP datagrams, tag them with the time they arrived, and write it all out in some manner that makes it not too horribly difficult to read and subsequently process.

Interestingly enough, this wasn't that hard. The hardest part was doing the writing of the file. The basics were already there for me in what I'd done already, and I just had to spend a few hours to get everything cleaned up and ready to go.

Now all I need to do is test it. Pretty nice.

This morning I was looking to see if anyone had updated the Gist Vim plugin to support the other functions that I haven't yet gotten time to check on. I found the someone had put it up on GitHub, and checked to see if their repo had the fix I made to the plugin yesterday. He hadn't. But that got me to thinking - Why don't you fork it, and fix it yourself? So I did.

I've now got a repo at GitHub for my fork of the Gist Vim plugin that does a few things that the original didn't:

• Pulling a Gist doesn't split the window - it takes the whole buffer
• Pulling a Gist works with the new API v3 GitHub spec

I pushed it up - worked like a charm, and now I've got a place to keep this bad boy up to date. I still haven't had time to look at the other functions, but I will, and I'll fix them, if needed. The scripting language is pretty nice, and I can't imagine I'd need anything it doesn't support.

It's silly, but this is my first fork on GitHub, and I'm really pretty giddy about it. Jazzed, even.

This morning I have a pretty stable Greek Engine going, so it's time to try and set up the second machine to handle the second-half of the market. After all, we need to cover all of it, and two boxes is pretty cheap in comparison to the existing hardware footprint.

Thankfully, I've recently received the machines that were ordered for just this purpose. SO I had to check on them - make sure they had the iODBC configuration set up, the FreeTDS config - all the things my processes are going to need. Didn't take long, but it was also the right time to get my home directory set up with the SSH keys, etc. Just to make things clean on the boxes.

After that, it was time to get into the configuration of the start-up scripts in the code and the crontab on the new box. It's not all that hard - by design, thank you, but it's something that I really needed to do.

In the end, I have the entire market on two boxes. Not bad, considering what it's replacing.

Today I was trying to use the Gist Vim plugin and noticed that it was a bit broken. In fact, it wasn't even close to working. I was getting HTML redirection messages, and that's not good. So I decided to take a few minutes and see if I could get it back working again. I looked at the site and noticed that it hadn't been updated recently, so it was going to be up to me.

What I figured was that it was in the URL for getting the Gist from GitHub. That's in this code:

function! s:GistGet(user, token, gistid, clipboard)
  let url = 'https://gist.github.com/'.a:gistid.'.txt'
  let winnum = bufwinnr(bufnr('gist:'.a:gistid))

and after a bit of time reading the GitHub API site, and fiddling around with the URL, I was able to see that the correct URL is really:

function! s:GistGet(user, token, gistid, clipboard)
  let url = 'https://raw.github.com/gist/'.a:gistid
  let winnum = bufwinnr(bufnr('gist:'.a:gistid))

So I changed that in my copies, and I'm good to go. For a while.

Today I did a lot more interaction with the UI developer that's putting a beautiful web interface on my Greek Engine. Really, he's using the Greek Engine as a support service to a project that the business is really hot to get into production. It's nice, and pulling from a lot of services registered in The Broker. It's just that he was starting to try and hit my service for data, and not getting anything, and I was not really logging what was happening.

What was happening was he was misspelling the command component, and I was doing exactly what I'd told the system to do - which is nothing, and then return nothing. Clearly, I needed to handle mis-behaving clients a lot better.

What I did was to simply add in a check to see if the client's request was going to cause me to do anything. If not, then I logged it, and sent him back an error. That should make it a lot clearer what is going on for malformed requests. With the logging, this allows me to know what's up with the clients as well. Much better.