7 posts tagged “twitter”

Aral Balkan is trying to run the website for his conference on Google App Engine, the same platform that snaptrip uses. In October, he posted twice on Twitter:

Great, you have no control over how Google App Engine caches data requests. Pulling in RSS feeds? Forget about it! (It uses Google Proxy and you can't tell it not to cache a feed or set the cache duration.)

I'd also noticed this, because the snaptrip login page (which does double-duty as an FAQ and news page - maybe I should rename it?) pulls in entries tagged 'snaptrip' from the Atom feed of this very weblog, and after my third post it failed to update for a good half a day. I wasn't that bothered, and didn't bother to double-check the documentation, which does clearly state that

App Engine uses a HTTP/1.1 compliant proxy to fetch the result.

Evidently this is the same problem as Aral has, and as usual, Tom Insam had an answer. It's from a slightly different direction (working with Google's Open Social containers), and as he said, it's what "everyone has done for years to bust caches you don't control": append an incrementing (or random) parameter to each request, which should mean that you're not hitting the cache. Having finally written a new blog post about snaptrip, I can confirm that this approach works. I'm not sure I'll leave it in - it seems a bit rude - but if timeliness is important, you might want to do the same.

It also occurs to me that, if every call to urlfetch is cached for some time, then you may find that repeated calls via API libraries might give somewhat unexpected results (although they're more likely to have changing arguments, anyway). Be careful out there.

Just a quick note to say thanks to all of you who've been using snaptrip today, since it was mentioned on DopplrHQ's Twitter stream. As it says in the questions and answers on the front page, I'm still poking at lots of bits of functionality, and you may see the odd error when I haven't properly caught one of the web services I use failing to send back some text. Despite all that, I can see that the app's been fairly popular, and hopefully it's been useful.

However, I've just spent an evening tightening up some of the text, and also working on how to show that an image already has either Dopplr trip tags or location data. (You've probably noticed there's a link that doesn't work- I didn't expect to be releasing quite so soon- but it might give you a clue as to what's coming next.) I'll try and keep posting fairly regularly, but for now, thanks again.

Above London (and its twin Above SF), a little Hackday London project which warns you of upcoming satellite flybys via Twitter, have been running fairly happily for a month and a half now. (Well, actually, abovesf got accidentally cut out of the crontab for a while, but it's back now). However, they weren't perfect, so here's a couple of tweaks that I've just made.

Firstly, after trying and failing to observe a few passes, candace and I have decided to limit the amount of Iridium flares that trigger a message. Now they'll only be sent through if they're magnitude -3 or brighter. Secondly, the format of messages has been modified. Both now include a bit more useful information, and they're consistent with each other.

As I go through the changes, I'll also describe what each of the bits of information is, since I've come to realise that they're not necessarily that clear. (This example is for a pass over London on Monday 6th of August; if it's clear tomorrow this should be a great one to watch, as it passes almost overhead. If you miss it, though, this week's good for the ISS with plenty of bright evening flyovers.)

ISS Pass: mag -2.4 starts at 22:57:59 from W to E with max elevation 86° at 23:00:51 in direction WNW

This is for flyovers by the International Space Station. The first number is the magnitude- a measure of the brightness of the ISS. For historical reasons, this goes backwards: you want the number to be as low as possible. -2.4 is about as bright as ISS passes get; we'll send notifications for any that we get, but they do drop to magnitude 0, which is pretty hard to spot.

Then the message gives you a start time (22:57:59) and direction (W) to look in. ISS passes are relatively leisurely, and they tend to span the sky; this one will pass from the west to the east.

The maximum elevation (here, 86°) is how high the ISS will get. They range from 20º (our cutoff- below this trees and buildings will almost always be in the way) to 90º (directly overhead). There was a pass today at 68º, which caused me to crane my neck more than I'd have thought. As I said, ISS passes are quite slow, so there's also a time for this part of the transit. Finally, we give a direction in which to look (although if it's high enough the direction isn't terribly useful).

Iridium Flare: mag -6 at 23:59:19 with max elevation 36° in direction 236° (SW) (from Iridium 62)

If you can understand the ISS message, this should be pretty clear now too. Again, it lists the brightness, time, height and direction, and also lists the satellite which is causing the flare.

Obviously, the main thing that's useful as on observer for both ISS and Iridium events is a sense of direction: all of that's no use if you don't know where the southwest is. If you're at home, I'd rcommend using the A-Z to figure out which direction your road's in. Of course, a compass or GPS would work too.

Here's hoping that this reduces any feelings that the Twitter messages were a bit overwhelming, and that you can use them to spot these lovely events. Good skygazing.

Twitter seem to be going through a phase of minor interface tweaks. I mentioned a couple of weeks ago that they'd added a title attribute to the list of messages from your friends, so that you could see if a message was private. The site stayed that way for a week or so, during which time I ran a little Greasemonkey script that looked for that attribute, and changed the background colour of the appropriate entries.

Unfortunately, that change vanished at the end of last week. I'd been intending to redo the script, using an API call to find protected users, but it was a bit too much work for me to do quickly at work, and so I didn't manage. However, yesterday evening I noticed this on the site:

Having an icon is what I'd wanted all the time, but Chris Heathcote mentioned on IRC that there may have been a conflict between the "Favourite" button, which is clickable, and the lock indicator, which isn't. Personally I'm happy to see it, even if there is a slight confusion there.

I don't think this is the only UI change that's been looked at. John Gruber has been following the evolution of the mobile version of the site. Hopefully the site will soon settle down, but it's nice that these things are being taken care of.

This is almost as nitpicking as John Gruber's observations on iTunes source list shading, but I've just noticed a tiny change as part of Twitter's midweek redesign, which saw alternating background table rows replaced with rules separating each entry.

Now, on the page describing what you and your friends are doing, any entries from people whose tweets aren't public have a title attribute: "[Friend's] updates are protected! Please don't share." In most browsers, this means you get a tooltip with that message.

This addresses a minor, but serious, complaint I had about that page, namely that there was no indication that a user wanted (or didn't want) his updates shared. It's not quite as obvious as Flickr's privacy "traffic lights", but it's a lot better than nothing, so I thought I'd mention it, even if it is a very small change.

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.

Although I now realise I first saw Twitter a week ago (when the news that Dunstan Orchard had moved from Apple to Flickr broke), I only really properly noticed it when I got back from a largely blissful weekend away from computers. My first reaction was pretty much nailed by Phil Gyford in the introduction to the first of two insightful posts on the back of the service:

If you hate blogs because you think they’re full of people rambling about pointless details of their mundane lives you’ll hate Twitter, which makes it as easy as possible to post snippets to the web (and your friends’ phones and instant messengers) letting everyone know exactly what you’re doing RIGHT NOW.

Nonetheless, as is my wont, after a first burst of hating the idea, I thought I'd better try it, inspired mainly by Chris posting his design. I started with a very minimal list of users- unlike on Flickr, where I don't mind a stream of photos by people I don't know well but who's work I like- and it was OK, although I suspect it's meant to be used for things more profound than me saying how many cups of tea I manage a day.

The point- yes, I've finally reached it- that annoyed me this morning, though, was that, when looking at the friends of friends, I see lots of entries saying "I'm only giving updates to friends. Add me." Why do this? It smells of "I'm at a fab party but you can't come", an attitude that really annoys me. Why not just not show that user? Or, perhaps, collect a list at the bottom: "you also missed three updates by Matt Jones", or something.

The flipside of this is that other people have noticed me on my friends pages and now want to be added. Generally I'm allowing them, but what happens when someone I don't really know starts poking around? Oh, the social.

Another thing that I've noticed during the writing of this post is that the app seems to be suffering somewhat from its expansion. Perhaps a clue to this is given by the error message "Rails application failed to start properly". Oh.

I expect I'll keep poking at it for another few days, but I expect this to rapidly vanish from my life until (unless?) someone comes visiting London and finds it more convenient than IRC and SMS to arrange nights out.

* by the way, I disagree with Gruber's comment: "Hopefully Flickr will just hand him the keys to their design car — Orchard could give them a serious injection of awesomeness." Flickr is already awesome in a really nice, understated way; they're designed but they don't look it. The last thing they need is page furniture that detracts from the photography. That's not to say that there's not stuff to do, but more that there's no need for a vast revamp.