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

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

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.

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

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

Assumptions

1. You have a web-accessible server where you put your development .ipk files.
2. You can ssh into your Prē.

Download

You can download the script at http://kai.mactane.org/software/libraries/download/homebrew.sh.

Installation

Just drop the shell script into your home directory and make it executable. If you want to be able to use the "my" argument, you'll also need to edit the three configuration variables at the beginning: MY_HOSTNAME, STDPATH, and STDVERSION.

Usage

For most purposes, you'll just want to install your own package that you've been working on. Assuming you've set the config variables correctly, you can just type ./homebrew.sh my appname, where the appname is the base name of your package.

If you're installing multiple .ipks and you don't need to restart the GUI manager for each one, you can use the "skip" command on all but the last:

./homebrew.sh skip my foo
./homebrew.sh skip my bar
./homebrew.sh skip my baz
./homebrew.sh my quux

You can also supply a complete URL: ./homebrew.sh http://forums.precentral.net/spe_attachment/download-23971-com.palm.net.precoder.fcoaster_1.0.2_all.ipk will download and install fileCoaster, so you won't have to mess with my script any more.

What It Does

It automates the process of installing homebrew apps with a rooted Prē, as described on the webOS Internals wiki. Basically, it remounts the root partition in read-write mode, wgets your .ipk file, installs it, does the "Good Housekeeping" backup, remounts the root partition in read-only mode again, and then restarts the GUI manager.

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

The story is simple: I was tired of seeing “failed password” messages from sshd cluttering up my logs. I was also annoyed at the constant flow of dictionary attacks, even if I knew they’d never get in. So I whipped up a quick Perl script that acted as some glue between Swatch and iptables, and which would also give me some amount of reporting and history on who and what it was blocking.

Then I posted about it in my online journal, and a friend said it sounded useful. So I started getting it ready for release as a package that anyone could use…

And promptly realized that doing a decent, professional job of it would take more time than I had available. Fast-forward to now, when I’m unemployed and can only spend so many hours per day job-hunting — the result is that the world gets more software!

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*

It’s really tempting to completely refactor some of that stuff, but I haven’t got the time. I actually have at least one more software project that I should really package up and publish — a thing that might be helpful for system administrators who are being annoyed by SSH dictionary attacks.

Writing something that works on your own machine is one thing. Making a full release? That’s quite different! It needs documentation, and that documentation needs to explain all the things that you “just know”. It needs some kind of install mechanism, or else it needs to explain how to install the stuff manually — and you need to make absolutely sure that you haven’t forgotten any of the things you wrote, changed, or tweaked while you were making it work!

root@finrod:~# pecl install pecl_http
pecl/pecl_http can optionally use PHP extension "iconv"
downloading pecl_http-1.6.3.tar ...
Starting to download pecl_http-1.6.3.tar (Unknown size)
................................................................................
................................................................................
.........................................done: 1,015,808 bytes
71 source files, building
running: phpize
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20060613
Zend Extension Api No: 220060519
ERROR: `phpize' failed
root@finrod:~#

The error is actually caused by a bug in PHP itself (filed in PHP’s bug database as of 2004, and currently marked “Won’t fix”): If your installation of PHP was compiled with the --enable-sigchild flag on, then the return value from a pclose() call can’t be trusted. One of PEAR’s components, called PEAR::Builder, uses pclose() as part of the package installation process, to try to determine whether a given operation succeeded or not.

Even though the operation succeeds, pclose() returns -1, signaling a failure, and the rest of PEAR then takes pclose() at its word.

Is This Affecting Your Installation of PHP and PEAR?

If you’ve gotten an “ERROR: `phpize’ failed” message when trying to run a “pecl install” or “pear install” command, try running phpinfo() — if you see --enable-sigchild in the “Configure Command” section near the very top, then you’re most likely being bitten by this bug.

Potential Fixes and Workarounds

The PHP dev team recommends recompiling without the offending flag.

However, you may not be able to do that, for any of various reasons. (You may have installed from a binary package, for instance — like most people these days.) Or it may simply seem like an excessive hassle. I offer the following patch as-is, without any guarantee or support.

First, ensure that you have the latest version of PEAR::Builder. Look in your PEAR/Builder.php file — On most Linux and Unix installations, this is likely to be in /usr/lib/php/PEAR/Builder.php, or possibly /usr/local/lib/php/PEAR/Builder.php.

On Windows systems, PHP might be installed nearly anywhere, but supposing it’s in c:\php, then the file you’re looking for will be in c:\php\PEAR\PEAR\Builder.php (yes, that’s two PEARs in a row).

Check the “@version” line in the big comment block at the beginning of the file; the line you want should be around line 19 or so. If says it’s less than version 1.38 (the latest one, at the time I’m writing this post), then try upgrading. Running “pear upgrade pear” should work. Then you can install this patch file:

patch-pear-builder-1.38.txt

Download the patch file and place it somewhere on your machine. Log in and cd to the PEAR directory that contains the Builder.php file. Then run the patch command. In the following example, I’ve placed the patch file in root’s home directory:

root@finrod:~# ls
loadlin16c.txt loadlin16c.zip patch-pear-builder-1.38.txt
root@finrod:~# cd /usr/lib/php/PEAR
root@finrod:/usr/lib/php/PEAR# cp Builder.php Builder.bak.php
root@finrod:/usr/lib/php/PEAR# patch -p0 < /root/patch-pear-builder-1.38.txt
patching file Builder.php
root@finrod:/usr/lib/php/PEAR#

Naturally, if the patch file doesn’t work for some reason, or it breaks things, you can just cp the backup file back into place.

Please let me know if this patch works for you — or if it fails horribly, for that matter.

[Updated 2009-06-03: Minor edits for clarity]