google

E.D. Kain over at Forbes write a succinct piece on the utility of Google Reader:

Not in the sense that people in Reader are anti-social so much as the point is to harbor a small enclave of carefully selected people and create a safe-haven of sorts where that “carefully constructed human curated” list of shares and insights can flourish. In Reader, you don’t go after as many friends as possible. You certainly don’t see anyone from high school. Nobody shares photos of their kids. The discussions that do blossom are almost always very smart and focused. It’s the internet if the world were a more prefect place.

This neatly sums up my own ( very heavy ) use of Reader with a very short list of people who I use as filters for the wider world. We few merry nerds share constantly and are enriched by each other's subscriptions; we forget conveniently that all this time spent clicking and sharing further deepens Google's understanding of our online lives. Now they want to pull all that into Google+, which all of us are on but none of us actually use.

The thing is, we are probably smart enough to build our own, and I'm pretty sure we aren't alone. If I was going to re-do Reader as a project for my own particular purposes, it would be very simple:

• import opml
• bookmarklets or browser extensions to handle new subscriptions
• share and comment
• some sort of 'friend' discovery using twitter, which I choose because all of the people I share posts with on Reader, I also follow on twitter. In fact, this could just be a twitter list you create, assuming the twitter api provides access to those sorts of things.
• self-hosted. This doesn't need to be internet scale. In fact, it could be unhosted, and an Open Web App.

I've taken a sudden interest in Mozilla's Addons sdk ( otherwise known as Jetpack ). I'm a bit of an old hat with Firefox's extension technology from my time at ActiveState; back then it was a bit painful to author and build package Mozilla extensions and we tried to make it a bit easier with Komodo, both for Firefox extensions and Komodo extensions.

Jetpack is a quantum leap forward in ease of use for building Firefox extensions. I was immediately impressed by the straightforward APIs, extensive docs and great command-line-oriented tooling and debugging. After a few hours of reading the docs, trying out the simple example and fixing a bug ( nitpick, really ) in the SDK, I have implemented a highly derivative Url-shortening extension and posted the code on github. And it works ( on my box )!

The extension has a very simple workflow:

* Hit Ctrl+Shift+u to create a shortened goo.gl Url for the current page.
* The extension will copy the new url to your clipboard and bring up a notification bubble.
* if you click on the notification bubble, Firefox will create open a new Tab with the shortened url.

The one implementation detail that took a bit longer was the actual call to the goo.gl url shortening service. I noted that the Google request to create a shortened url requires a raw json post with a content type of application/json. Typically POST requests have a content type of multi-part/form-data with url-encoded key/value pairs, and so without reading the jetpack docs closely I just implemented a typical xhr-based solution because I knew I could jam raw JSON content into the request:

Yesterday I went back to see if I could get the request working with Jetpack's APIs, and it turns out the solution was pretty simple:

In particular it's really flexible to be able to simply set the content body and content type header directly; given the diverse ways in which different online data providers are implementing their apis it's nice to be able to tie into externals in a simple and flexible way. Jetpack's hjgher-level apis also make it much easier to detect error handling, etc. You can also test asynchronous code like this using Jetpack's test framework:

The async features don't feel quite as slick as qunit's implementation to me, but they're easy to understand and implement. My next target is what seems to be the secret sauce in Jetpack: the ability to create HTML user interfaces and wire them into Jetpack code by posting events back and forth between the DOM code and the extension code.