kai_mactane: (Default)

I’ve released a new version of Hummingbird. This is a bug-fix release, resolving some issues in automatic hyperlinking and in recognition of multiple hashtags in a single tweet. (Yes, this is why I did a couple of tweets hashtagged “#testing” a couple of days ago.)

Downloads are available from the Hummingbird project page, or using these links:

hummingbird-0.67.tar.gz
hummingbird-0.67.zip

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

This is largely a bug-fix release. Tom Clift, of PaperCut print management software, kindly informed me of a few installation issues that my own tests didn’t find. The profusion of configuration options in PHP can make testing everything on a single server quite difficult.

This would be a good time for me to mention that I have the utmost respect for QA people. They deal with all sorts of minutiae that I am really glad not to have to handle, and I’m really glad they’re around. That said, I am not a QA person… and so I occasionally miss the sorts of stuff they’d catch.

  1. It turns out Hummingbird depends on the CLI version of PHP, and the CGI version will not suffice. This requirement is now listed in the appropriate section of the Hummingbird page.
  2. Not all PHP installations have output buffering turned on by default. The latest version of Hummingbird takes account for this.
  3. Various problems that can occur with the data cache file are also now reported more gracefully.

Again, my thanks to Tom Clift for some very useful patches!

You can get the latest version of Hummingbird from the Hummingbird page on my site.

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

I see that I never bothered announcing the v0.61 release. That was a minor bug-fix, resolving an issue where Hummingbird would fail if the XML cache file was empty.

The latest release is one that allows multiple versions of Hummingbird to run on the same machine without conflict, as long as they’re using different Twitter usernames.

In addition, I’ve changed the destination of auto-hashtag links. Since the hashtags.org service is often a bit flaky, or simply returns useless null results, I’ve switched to using Twitter’s own internal search service.

Downloads are available from the Hummingbird project page, or using these links:

hummingbird-0.65.tar.gz
hummingbird-0.65.zip

Originally published at Coyote Tracks. You can comment here or there.

kai_mactane: (Default)

I’ve always questioned the wisdom of building a startup company based around someone else’s platform, like Facebook games or Gmail inbox add-ons. You’re totally at the mercy of the other company. (Many people have found out how silly it was to go up against Microsoft or Apple in just the same way.)

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.)

Originally published at Coyote Tracks. You can comment here or there.

Profile

kai_mactane: (Default)
kai_mactane

July 2011

S M T W T F S
     12
3456789
101112 13141516
17181920212223
24252627282930
31      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 21st, 2017 06:43 am
Powered by Dreamwidth Studios