Tag Archives: Mashup

Update: Moved instalicious to GitHub. The main change I made since posting this was to stop items reappearing in Instapaper once you’ve deleted them; the sync process was causing them to be pushed from Delicious again. The script now changes the “toread” tag to “instaliciousd” (configurable name), so “toread” items will only be pushed once.

Instapaper lets me read stuff later – I hit a bookmarklet when I’m reading it and I can see it later on my browser or in iphone, or print articles in a newspaper format. The problem is, I’d rather add that stuff to my Delicious stream so I have a permanent record, others can see it, and it plays nicely with in mashups.

So I decided I want a way to bookmark things in Delicious as normal, but still have them appear in Instapaper. Here’s the script repo:

Instalicious is a little Python script that plucks out items tagged “toread” – or some other configurable tag – and pushes them to Instapaper. Fortunately, both services have easy APIs (Instapaper API; Delicious API), and in the case of Delicious, there was even a pleasant Python binding to the API. Also, the Instapaper API happily doesn’t create duplicates when you send it something you’ve already sent…so Instalicious doesn’t have to remember what it sent. It just dumbly polls Delicious and sends it over to Instapaper.

I recently attended Rewired State with several fellow Osmosofties. Our group (Simon, Fred, Jeremy, Robbie and myself) developed a little mashup called Moving There (and a couple of other things not described here).

After the demos, our mashup was mentioned by a representative from DirectGov as one of several projects they’d like to work with, perhaps to sponsor further work.

The idea was to overlay government-related data on property listings sites. I’ve been moving house right now, so this is very much an itch which I’d very much like to scratch.

There’s a lot of things they don’t show you too, like upcoming building works, local schools, crime stats, vandalism. All these things are available in one form or another on websites, some operated by the government and others by third parties.

One part of our work involved taking in a postcode and producing useful info about it, so we came up with a little library for that. We also made some attempt to normalise these metrics, so we came up with a “coolness factor” between 0 and 1. This is very crude, but we feel it’s useful when comparing stats to say “schools have a coolness factor of 0.3 and crime prevention is 0.6” rather than “schools have an average pass rate of 48% and there are 142 crimes per week”. In other words, a standard coolness factor measure goes some way towards helping you compare apples with oranges.

But the real product concerned itself with mashing up a properties listing site. After entering a location, you get back listings as well as charts showing the “coolness” factor according to the various stats. Well, that’s the theory; in this case, it’s just one stat (fixmystreet local incidents, e.g. vandalism) per property. And the UI isn’t particularly slick either! I’m just presenting where we got to when the time ran out on the day!

A few notes on the technology. We made use of JQuery for the usual infrastructural stuff. We used Google’s geo-coding API to map street name and suburbs into a postcode. The postcode info demo and the final mashup are actually a file-based web app, i.e. it runs off a file:// URI. We debated several models for the mashup’s architecture; in retrospect, we spent a lot of time re-building the property search’s UI and it might have been better to go with a Greasemonkey overlay, at least for proof-of-concept.

A Little Music

As I was playing around with the new layout of this blog, I added a Last.FM widget to the sidebar. It looks like this:

(May not render if you’re reading this from a feed reader.)

Great. Now I can listen to trance from the blog. Trance is good for coding. So that’s ace. But I couldn’t stop there, could I?

Widgets, Widgets, Everywhere!

I made this page with 30+ gadgets in all sorts of genres. This is good for those times when I’m not coding and want to listen to something else. Being in the cloud, it means I can easily listen to whatever I feel like when I’m in an internet cafe or the such like. So even more ace.

Make Your Own Jukebox

In the spirit of sharing, you can easily make a page containing your own favourite music. The URL for the default music page resolves to something with a ridiculously long list of genres:

… which means you can hack the URL and make your own jukebox with your own genres and bookmark it and it will work and live on in the cloud and you too will be able to listen to your favourite music anywhere you go.

For example, you might be a more passionate fan of contemporary Japanese music than myself, in which case you would concoct the following URL and save it to your delicious bookmark manager to enjoy many years of musical gratification:

Add A Player on the Fly

One other feature is that you can add a new player on the fly. This again is great for travelling around as it will let me easily listen to any genre I care for without even having to edit the URL.

(Unamusing trivia: I actually caused a bug at first by using “gray” as the colour name here. I’m used to working with American spelling for programming of course, but then last.fm is a UK company and the name you want is actually British spelling, i.e. “grey”.)

Obligatory Wishlist I’ll Not Really Get Around to Implementing But it’s Cathartic to Braindump it Anyway

If I was going to do more work on this, I would:

Make it into a widget-like portal which lets you add/remove/layout etc and save settings within a hackable URL (using Unique URL. You could argue the whole thing is useless as you could achieve the same thing in iGoogle/Shindig, but sometimes a specialised interface, tucked neatly inside a separate tab, works best.

Provide more flexibility on layout

Add support for bands, not just tags

Run it on a separate page without the blog layout

Keep the loldog

Share this:

It’s often a requirement for an Ajax app to “bust the cache”, i.e. call a service and ensure its response comes direct and not from a cache. For all the talk of fancy header techniques, the easiest way to do it is by appending an arbitrary parameter, typically a random number and/or a timestamp i.e. call service.com/?random=39583483. I use this pattern not just as an Ajax programmer but also as a user; when I suspect my wiki page or blog is cached, I just add an arbitrary parameter and usually get the most recent result.

With Digg API, that’s impossible. I just tried it and discovered you get an unrecognised argument error if you pass in a parameter they weren’t expecting. This is well-intentioned as it will give early failure advice to callers who mistype or misinterpret parameter names. But unfortunately, it has the major downside of breaking this convention and thus breaking compatibility with a large number of toolkits that exploit this pattern.

I discovered this as I was writing a Google Gadget to show Digg stories and when you fetch content with the Google API _IG_FetchContent("http://digg.com/....", callbackFunc, { refreshInterval: 60 }) – the refresh option apparently leads to Google tacking on an arbitrary parameter called “cache” (it’s impossible to be sure as it’s proxied via Google, but the argument to that proxy is the Digg URL with “cache=” on the end). Net effect: I can’t update Digg stories any more than once per hour. The only way I could do it would be to write my own proxy and cache. A lot more work than the one-liner _IG_FetchContent call! Yeah, like that’s gonna happen.

For the Digg API, perhaps they need to introduce an optional “strict” parameter like a compiler offers to give extra debug info. If it’s off, then let anything through.

Share this:

G’Day

Welcome to Michael Mahemoff's blog, soapboxing on software and the web since 2004. I'm presently using HTML5 and the web to make podcasts easier to share, play, and discover at Player FM. I've previously worked at Google and Osmosoft, and built the Ajax Patterns wiki and corresponding book, "Ajax Design Patterns" (O'Reilly 2006).
For avoidance of doubt, I'm not a female, nor ever have been to my knowledge. The title of this blog alludes to English As She Is Spoke, a book so profoundly flawed it reminded me of the maturity of the software industry when this blog began in 2004. I believe the industry has become more sophisticated since then, particularly the importance of UX.
Follow @mahemoff