5 posts tagged “yahoo”

Launched today at Etech, Fire Eagle is a new Yahoo service that lets apps easily store and retrieve your location. Its big selling point is that it can take almost any input (postcodes, addresses, cities, lat/long pairs) and then give a heirarchal output to apps, with levels of precision that the user chooses.

Unfortunately, while almost all of these levels ("country", "city", "exact") make sense whichever country you're in, there's one that doesn't. In the UK, "postal" will return a full postcode, which locates you to a building (at best) or a street (at worst). In the US, by contrast, it reutrns a five-digit zip code, which covers about 5000 people, and is obviously far less revealing. (I've no idea what it does outside these two countries, but I'd love to know.)

Now, obviously I can work around this in a couple of ways. Firstly, I could be fuzzier about the location I give to Fire Eagle, but this is silly; then nobody gets the better data. Much better, then, to use one of the other choices that are offered, but this begs the question; why have the postal option at all?

Still, it's early days, and as well as looking forward to seeing how the service (and its uses) evolve, I'm hoping there'll be a few tweaks for international consistency within the service itself.

The idea of Hackday London 2007 was, unsurprisingly, to hack. Beforehand I'd had little idea of what to do, but candace managed to come up with a few ideas. Notably, one evening last week she noticed some photos on SpaceWeather.com of the International Space Station, as taken from the Netherlands, and thought that perhaps we'd have a chance of seeing it. We checked Heavens-Above, a venerable satellite tracking/prediction site, and we caught a flyby which included a moment of brightness as the newly-deployed solar panels caught the sun.

Wouldn't it be great, she mused, if it was possible to get messages to your phone when such things were going to happen? As well as ISS flybys, there are also Iridium flares, where the redundant communications satellites reflect sunlight down to the ground, and it'd be nice to be told about those, too. It looked like we had an idea.

Implementing the idea wasn't terribly tricky, either. There are two parts to it. Firstly, there's a scraper for Heavens-Above. We set up a special London account, and wrote a script that authenticates against the site,  and downloads and parses the data tables for the ISS and iridium flares. This goes into a plain text file, with the date and time as one field and the text message to send as the next. Since the data tables list events for seven days in advance, this script doesn't have to run frequently- at the moment it's doing so once a day.

Secondly, there's the sender script, which runs every five minutes. It reads in the data file, parses the date (slightly hackily- I'll need to fix that eventually), and, if the event is within twenty minutes, sends it to Twitter (which we use as it's a simple way of sending SMSes to multiple users). Also - and this is where where the required use of a BBC or Yahoo! API comes in - the script checks the Yahoo feed's "current weather conditions" value, and if it's likely you'll be able to see the event, continues onwards to send it. Otherwise, it doesn't bother (but I do get an email from cron telling me what the weather actually was).

I was able to get all the coding done and put it on my colo before one of the flares that evening, but sadly the weather wasn't quite clear enough and we didn't have visibility in the right direction. Still, we had text messages and a Twitter page that we could point to as proof of a working hack, so we went home. (There's an aside here about the difference between the SF culture and London's more lackadaisical one, perhaps, but it'll have to wait for another day.)

I spent another 30 minutes on Sunday morning tidying up the verbosity of the script (it now only prints, and hence sends email, at the same time it has output to send), and then came the slightly nervewracking presentation, which thankfully seemed to go down well, despite us having nothing really in the way of UI to demo. (One of the best things about Hackday- you don't have to write up yourself...)

That evening I added a feed for SF (and took the chance to comment alongside all the bits of code that needed changing). If you're interested in getting messages for passes Above London or Above SF then get a Twitter account and follow the appropriate user. (Longer-term Twitter users might want to adjust their phone notification settings if they want to get SMSes late at night.)

What's next, then? Well, I've since looked at a Perl module (Astro-satpass) that would have let us cut out Heavens-Above, and possibly opened the door to more customised notifications. In particular, we've made some arbitrary decisions (we don't send flares that don't climb above 20°, for example) and it's really hard to add a new location. It'd be nice to remove those limitations, but doing so introduces a new problem; namely, Twitter is a very easy platform for notifications, although I'm concerned about its reliability and timeliness. Customised messages mean either abandoning it or (ab)using the direct messaging syntax.

It was notable that Twitter was used in a fair amount of the hacks (from the live blog post written during the presentations, at least 10%). I think it'd be a perfect fit for Yahoo, alongside Flickr and del.icio.us, as a developer-friendly site that, perhaps, needs a bit of resourcing behind it to make it truly reliable (and, perhaps, more international; the UK number isn't always cheap). How about it?

Anyway, the two applications/accounts/bots should now run without human intervention (at least until that date hack I mentioned rears its head around Christmas), and hopefully I'll remain inspired to tackle the more complex project of personalised feeds and notifications later in the summer. For now, enjoy spotting satellites.

Everything seems to be a follow-up these days.

It turns out that Pipes (now? always did and I never noticed?) exposes a y:published property, which looks suspiciously like the Perl DateTime object mentioned previously. Having seen that, I've now hammered three of the four feeds I want to aggregate into a single feed.

For the fourth source, Flickr, I need to decide if I'm doing a simple life stream (more on that concept at Jeremy Keith's journal), or something more complex where I can differentiate between a single photo with a narrative or days with many images, in the style of Phil Gyford's home page. Not that I suspect anybody cares much. Doesn't everyone just use RSS these days anyway?

A couple of notes on my previous posts. groupr's had another quick release. Just after cloning it to the live domain last night, I quickly took out the obsolete (and distracting) toggling of group visibility, which Gareth had suggested on Wednesday. Tom persuaded me to clone it across this morning, so there it is. I'm still aiming to fix up the HTML this weekend, if I can get TT style modifiers to work in Trimpath templates.

Tom's also to blame for the other update. Apparently, while playing with Pipes, he observed a stack trace mentioning XML::Feed, the nice Perl module for abstracting RSS and Atom data, which led him to find my observation that there was no nice abstraction even more baffling. Oh well; hopefully that means it'll be easy to fix in a new version.

For the last couple of months I've been sitting on a CGI script that would aggregate all my content for my personal site. Part of the reason is caching: the script doesn't have any, and it turns out that XML::Feed isn't Storable friendly, which knocks out my first approach.

So when I had a think about what Yahoo's Pipes promises, I thought it might be worth a look. I could get the service to do all the heavy lifting, hope they had a sensible caching policy (and if not, well, at least it was Someone Else's Problem), and then just format a single RSS feed locally.

Sadly, there's a major problem. The aforementioned XML::Feed Perl module does a wonderful job of hiding the mess of formats that labour under the acronym RSS and the name Atom. If you want to soft by date, you can do so easily.  (In fact, you get lovely Perl DateTime objects. I can't sing DateTime's praises enough, even if it does look daunting at first.) Pipes, however, doesn't. I can sort my Vox Atom feed by its pubDate property, or my delicious and husk RSS feeds by dc:date, but neither sort has a date format in common, so I can't sort them once they're output.

I had a quick look to see if there was an obvious way of doing a date transformation on an element of an item, but unless I'm missing something it's far from obvious. I could write a small web service and call it, but that's a lot of work, and I might as well do things locally if I'm that bothered. So I've given up, but not before writing this, because it seems like a natural thing to handle in such a high-level environment, and I'm surprised they don't.