There are two ways to fix a problem of inefficiency.

The first, and simplest, is to beat it into the ground with money and hardware.

The second is to fix the inefficiency.

Right now, I'm having a lesson in why the first does not work. We wanted to speed up the site. For business reasons, no one wanted to allocate time to address the problems inherent in a four-year-old system that was originally designed by someone who was relatively new to the language. So, we put the system on two web servers behind a load balancer. There were a few wrinkles, but we were ironing them out one at a time, until we hit a snag. The balancer (which is shared, so we can't reconfigure) has a timeout of 30 minutes. For reasons I won't go into here, we need a minimum of 40 (and a little more for security).

So, now, we either have to address the inefficiency in such a way that we can produce a division of labor (my suggestion) or apply a quick fix that will regenerate sessions if they are routed to the wrong server.

This frustrates me. The whole reason that the higher-ups (I was not part of the decision) went with a load-balancer was to avoid doing work. Now we have to do work to support the load balancer, and it's not even going to fix the original problem.

I just want my site to be well-structured, efficient, and maintainable. Right now, it is none of those. And it stinks.

Time to update my blog code. Time to find out how easy it is!

Edit: Easily enough, if you remember to back up your config files and CSS changes. I did not. Fortunately, I had backups anyway. Yay, good habits. Boo, not planning ahead.

So, I promised some thoughts on OAuth before the holidays, but I got busy. So I'll take some time now to do it.

First, let me point out that I just had my first experience with it, so I'm not an expert.

That said, it seems well thought-out and a good idea. I've never been happy about sites storing my username and password for integration. There have been a number of techniques I've seen for avoiding it, all requiring the exchange of secrets. While OAuth is no exception to that, it does automate the process and provide a unified means for exchanging revokable secrets with minimal user intervention.

I like three things about this.

1) Uniformity. I figured out how to use OAuth to integrate with a company partner. Now, I can use the same libraries in a similar way to integrate with, say, Twitter (which seems to be driving the popularity).

2) It is multistage and can be secured. While not as simple as a single exchange, it provides an added level of security by making it hard(er) to spoof the user. It also requires that the target site provide credentials to the client site/program before any integration can be done at all. While this does add an extra step for the developers, it also allows an entire client application to be deauthorized at need.

3) Minimal. User. Knowledge. I love that the end user only needs to know how to log into the client site, and the server/client archetecture takes care of the rest. Since I always end up doing at least some support on anything I write, the less people have to know, the happier I am.

Now, I've only approached it from a client perspective. I'm thinking, however, about looking into wrapping my next API in OAuth, both to see how it works and because I'm starting to think this is a good idea. It was a little hard to figure out at first, since most tutorials are very Twitter-specific, but once I figured out the language, the client libraries weren't hard to use.

Has anyone else used it? Are there flaws I've not met yet?

Favicon, done. Colors picked, done. StackOverflow flair, done. Layout tweaked, done.

I forgot how fun it can be to muck around with this stuff.