Bryan Helmkamp

OpenID has been hot lately, and the largest news has been that AOL has become an identity provider. This means if you use AOL (or AIM), you already have an OpenID that you can use to login at any OpenID consumer-enabled websites.

It’s easy to see why AOL would be interested in doing this. Now, instead of just being able to track your activities on their own web properties, AOL will also know what other sites you are using and when. (The OpenID authentication process requires sending information about the consumer site to the provider.) And this is valuable information to a seasoned web marketing machine.

So the big guys are interested in providing our identity, but what’s been disturbing me lately is a distinct lack of news that the big guys are working to become OpenID consumers. While acting as an OpenID consumer is not required for identity providers, I believe it’s the right thing to do for users. Let them BYOI (Bring Your Own Identity).

If the Big Four aren’t interested in being involved in a truly open identification system, it’s not too difficult to imagine a future where AOL will encourage their customers to use their AOL OpenID to login everywhere except at AOL’s own web properties, where we’ll have to login with a screenname and password.

We’d be forced to maintain a separate identity with each of the Big Four, and, with the increased privacy considerations, we might be worse off then when we started.

I’m late to the party on this one, but I think this news is worth repeating.

About a month ago, OpenCongress launched with a stated goal of bringing “together official government information with news and blog coverage to give you the real story behind what’s happening in Congress.”

I’m always thrilled to see people leveraging technology to close the gap between voters and elected officials.

On the other side of the pond, the MySociety project has been doing great work in this area, and we Americans have some catching up to do.

As an added bonus, they built the site in Ruby on Rails. Congrats on the launch!

Did you know that you could call toSource() on a JavaScript method object to see the source code? An example using a random method on my Google personalized homepage:

1
2

>>> _xsetp.toSource();
"function _xsetp(a) {ig_s.push(a);if (!ig_t) {ig_K();}}"

toString() is even better. It formats the code for human consumption:

1
2
3
4
5
6
7

>>> _xsetp.toString();
"function _xsetp(a) {
    ig_s.push(a);
    if (!ig_t) {
       ig_K();
    }
}"

This is especially useful when using FireBug to inspect a website to see how it works. Use the “Inspect” feature to look at the onClick handler, then call toString() on the method in the FireBug console to see the source.

JavaScript (as defined by ECMAScript) is really a great dynamic language. It’s too bad so many developers can’t shake the bad taste in their mouths left from poor and inconsistent browser support.

I thought pretty much everyone had seen this, but since no one in my office had, I must’ve been wrong.

“Roll the dice to see if I’m getting drunk.”

The late Steve Irwin, Crocodile Hunter, was an expert at handling dangerous animals. Occasionally, even Steve get bit.

After a bite, Steve was always quick to point out that it was not the animal’s fault. An animal, of course, is a dangerous predator, but it’s not able to understand the consequences of its actions.

On the other hand, It is the animal handler’s responsibility to ensure the animal is never given the opportunity to bite a person. Because, when given the opportunity, a predator will always do what nature and instinct has taught it to do.

As software developers, we must take the role of the animal trainer. Our clients are like the crocodiles. If the client causes you harm (by changing requirements or deadlines, for example), you cannot blame the client, as it was just acting on its instincts.

Photo by maggie_p_au licensed under Creative Commons BY.