Luckily, this time, Twitter seems to have updated its signup page with some nice AJAX that constrains the user’s options, and provides helpful feedback. So, for anyone else who needs this information in the future, here’s the scoop:

1. Letters, numbers, and underscores only. It’s case-blind, so you can enter hi_there, Hi_There, or HI_THERE and they’ll all work the same (and be treated as a single account).
2. There is apparently no minimum-length requirement; the user a exists on Twitter. Maximum length is 15 characters.
3. There is also no requirement that the name contain letters at all; the user 69 exists, as does a user whose name I can’t pronounce.

If you want a regex to match on this, /[a-zA-Z0-9_]{1,15}/ would be nice and safe for use in both POSIX and Perl-style regex syntax. (If you’ve got Perl-compatible regexes, /\w{1,15}/ is quick and easy.)

And yet, here I am with Hummingbird, which is totally dependent on Twitter’s bandwidth. (In my own defense, I can only point out that: a) I wrote it because I needed the functionality; and b) I’m not building a money-making company around Hummingbird. I’m just giving it away.)

In the past couple of weeks, I’ve noticed that Twitter can sometimes take an astonishingly long time to provide an update. Hummingbird works by requesting URLs like http://twitter.com/statuses/user_timeline/kmactane.xml?count=25, and (up until now) it worked on the assumption that Twitter couldn’t possibly take longer than 10 or 15 seconds to respond to such a request.

That turns out not to be the case.

In fact, my recent tests have shown that Twitter can sometimes take over 5 full minutes to finish responding to such a request. This is a problem, because the default installation of Hummingbird tries to update its cached data once every 5 minutes. And since I assumed the request would be fulfilled in, at most, 10% of that time, I didn’t bother building in any concurrency checking.

I’ve just completely reorganized most of Hummingbird’s architecture. The interface that a blog owner sees (in the sense of the configuration variables in hummingbird.php, and the calling syntax for blog pages and cron jobs) is still the same. However, all of the code for retrieving data from Twitter has been spun off into a new hummingbird-cache.php file, which can be launched into the background by the rest of Hummingbird, so that it can patiently take as long as it needs to in order to update the blog’s tweets cache.

The Major Change This Causes

In Hummingbird’s previous incarnations, it would freshen an out-of-date cache before displaying it. The assumption was that every once in a while, someone might have to wait a few more seconds before seeing your blog page. However, everyone would always see an up-to-date record of your tweets. (Where “up-to-date” means “no more than 5 minutes old, absolute tops”. If you tweet so relentlessly that that’s a problem, you probably don’t have enough time to keep up your blog…)

Now that we know that Twitter can take over 5 minutes to give you the data needed to freshen your tweets cache, that design is not acceptable. Instead, Hummingbird is now committed to showing the contents of your tweets cache as quickly as possible, and only then does it fork the cache-update process into the background.

This means that, if you’re not using cron or some other automatic job-scheduling facility to run Hummingbird every 5 minutes, visitors who arrive at your blog after a period of inactivity will see an out-of-date, stale listing of your tweets.

If you have a cron job set to keep Hummingbird fresh, you’ll be fine. (A page view will also trigger an update, so if you get so much traffic that there’s never a 5-minute period during which your page doesn’t get hit, you’ll also be fine.)

Well, now it does.

The change is pretty minimal, but it also incurred some overhead in my web site: the Hummingbird web page needed to be updated to match the new feature. And since that feature meant adding a new CSS class, I had to update the “CSS Styling” section as well as the “Features” section… and add a new “Version History” section…

All in all, it was harder to update the documentary web page than to update the software itself. In a way, that implies that my code was pretty clean. If you want, you can download the new version here.

See, I’m not neglecting everything to work on Palm Prē programming! (I’m also doing some contracting, which is taking up even more time.)

So I decided to get it cleaned up and make a real, distributable software package out of it. That took a few days, especially when I started banging on it, and trying to ensure that it had a prayer of working on anyone else’s server. Plus there was the time involved for writing the docs.

But now that all of that stuff is done, I am pleased to announce: Hummingbird. A lightweight, pretty, and compact gizmo for displaying your latest tweets on a blog or other PHP-powered web page.

* And if you don’t read Coyote Tracks… what the heck is wrong with you? *g*

I started off by getting my /etc, /usr/local/bin and /usr/local/sbin, and /var/named directories under version control. That’s good. Plus I think I’ve got things set up to where I can upgrade WordPress plugins on my local setup, then reliably push the changes through version control to my live site.

Oh, and my Twitter feed importer is a little prettier, in terms of how it displays how long ago a tweet was posted.

But then there’s the Live+Press plugin… I have high hopes that I’ll be able to use that to automatically crosspost from here to my new Dreamwidth account, but for now, it only seems to communicate with Livejournal. Since there’s a feature request open in the project’s wish list to make it work with other LJ-codebase sites, I figure I may as well pick that up and run with it.

Of course, that just slows me down on LJ Content Sieve… *sigh*

Because I don’t have everything done, I feel like I didn’t accomplish much today. That’s silly, but knowing that it’s silly doesn’t chance my feelings much.