2011-03-20
post/3982380612
(Source: tominsam)
2010-12-24
Flickr API Corners: ID to URL
If you have the URL of a Flickr photo, and want the URL of the page containing that photo, here are two ways, one on the website, and one using the API.
(Why would you want to do this? Well, people seem to be good at breaking the terms of service and not linking back to Flickr with a photo. Perhaps it’s been through ffffound or tumblr, or it’s been used on a blog. If that happens, but you want to find out who posted it, carry on.)
Firstly, using the website. Say your URL is http://farm5.static.flickr.com/4031/4497550401_11d8d708a7_z.jpg. Select up to the number behind the final slash and replace the text with http://flickr.com/photo.gne?id=. You’ll be redirected to a page containing the photo. (It’s possible that the photo will be private, but you’ll still be told who the uploader was.) Note you don’t need to trim things from the end of the URL; Flickr’s smart enough to do that for you.
Secondly, through the API. Open up the API explorer and look at flickr.photos.getInfo. Again, look after the last slash, and copy the number there (in this case, 4497550401) into the “ID” field. Once you call the method, you’ll see a variety of information about the photo, including (at the bottom of the XML) a URL.
It’s possible, if you don’t sign the call, or if the photo’s private, that you’ll need the second (hex) string, in this case 11d8d708a7, in the “secret” field. Providing this grants a little more access to a photo than the ID alone, but you may still find that the photo is private.
There you have it: two ways to get from a Flickr photo ID to the URL of the page containing it.
Flickr API Corners: flickr.photos.getAllContexts
This is inspired by Matt Jones’ Hello Little Fella Flickr group. We wanted to do the scoring based on whether you’d added your photo to the group, but it turns out that Flickr doesn’t provide that information in the API very easily.
Actually, that’s not true: you can do one call per photo to gets every pool and set a photo is in. However, the name is arguably part of the reason so few people know about it. The call is flickr.photos.getAllContexts.
The best way to explain the name is to look at the sidebar on any Flickr photo page. Underneath the user’s info, you’ll see a block for their photostream, and often then identical blocks for every set or group that the photo is in. Each of these blocks is a “context”, and each has its own order for going back and forth.
The API call returns a very short data structure, which contains <set> elements (for the user’s set that the photo is part of) and <pool> elements (for, unsurprisingly, the group IDs of the pools the photo has been posted to). If you know the ID of a pool (say, 796605@N25, for Hello Little Fella!) then you can easily find out if the photo is a member.
(It turns out that the Toms were actually aware of this, but it wasn’t easy for them to add this to the noticings data gathering flow. Still, I think this is worth dragging from the drafts folder and publishing.)
In Flickr’s terminology, a group contains one or more users, zero or more discussions and has a pool containing zero or more photos. Only users are allowed to add photos to a pool, or to contribute to a discussion (except for invited photos).
2010-02-01
Rich Feeds for Tumblr Blogs
benw:
the RSS output from Tumblr stinks. I assume it’s an evil incentive to use the Dashboard.
So, I’ve written a feed script. It’s called Tumblfeed, which sounds like tumbleweed… which I suppose is a metaphor for the semantic desolation of the Tumblr RSS feeds… or something. It was an accidental rhyme.
This looks good. I may even start offering feeds of my stuff through it.
2009-12-01
post/265305205
Give Retweets a Chance at the Tweetie support site.
This post succinctly sums up the advantages to “proper” (as opposed to “folk”) “retweets”, and they rest on one thing: metadata. As with replies, doing so using Twitter’s API methods gives users the metadata they need to do useful things: in the case of retweets, collapse repeats, and hide or ignore retweets. Not doing so deprives them of it, forcing them to scrape for data (or just put up with things). Don’t do that.
2009-08-05
post/156424512
I’ve probably left it so late that nobody cares, but here’s my tuppence on the front page redesign.
Firstly, I hate that the sign in form is now hidden by default; it stops Keychain filling in the password. The old login page is still available and works, but for how long?
Secondly, obviously in pulling search to the forefront Twitter are continuing to build on the Summize acquisition and the value they (and others) see in trends.
Thirdly, it looks like trending topics now get a description written. It’s fairly obvious this is being done manually. For one thing, they take a while to show up. For another, topics that are evidently referring to the same thing can have somewhat different descriptions.
Fourthly, it’s annoying that logged-in users have no way to access the historic trending topics or the descriptions of them. The former is a bit tricky to fix, but a title attribute on the links in the trending topics sidebar would be nice. (The descriptions would also be useful via the API.)
Generally, for all I share the suspicion that trending topics aren’t particularly insightful, they probably do work as a hook into the service.
2009-07-21
Twitter, @replies and in_reply_to
benw:
Existing conversation trackers don’t work with this. The
@@replies get left out of threading tools. That’s a shame, but that’s the reality of new behaviour. It takes time to be recognised and supported. That as much as anything is why I’ve documented@@here, as a reference and explanation for you to use as you advocate the practice, and to encourage everyone to settle on the@@syntax in preference to the many that currently circulate.
There’s a reason that conversation trackers don’t get @@replies, but it’s quite longwinded to explain. However, since Ben has a fairly longwinded explanatory section to his post, and because I’ve wanted to get this down anyway, what the hell; let’s go with it.
Once upon a time Ev invented Twitter. And people saw it was good, and started using it, and as Ben says, came up with what became formalised as a way of replying to a named user: @replies. (I’d love to know where that convention started, by the way. Presumably some web forums, but which, and when? Not that anyone is likely to care enough to dig through terabytes of text to establish it. Anyway.)
And Twitter saw that their users were doing this, and that it might be useful to make it clever, so they started marking up @user with links to twitter.com/user. Furthermore, they came up with a heuristic: if a post started @user (or, in Perlish,
if $post =~ m/^\@user/
except Twitter’s front end is in Ruby, but it’d be similar) then you’d assume that the person was replying to user’s latest post.
All well and good, except… when it wasn’t true. So, some time last year (again, I don’t care to trawl; someone else might) Twitter added the “swoosh” link to the web interface. Clicking this didn’t just populate the post field with @user at the front: it set a bit of metadata saying “this post I want to create is an reply to this exact post ID here”. Technically, and unsurprisingly, this is the in_reply_to field.
There’s rules attached to this, both from the front end and from third-party clients via the API, though. For the in_reply_to argument to be honoured, the post must start with the @user the in_reply_to post is by. In fact, it has to match the regular expression above. Add a space? Add the letters “RT” or the recycle symbol? No in_reply_to metadata for you, buddy.
It also means that if you come to see a post that you want to reply to and just put @user without using the swoosh, or your client has a brainfart and drops the in_reply_to argument, your post also lacks the in_reply_to metadata. The upshot? Anyone coming along more than, say, a day later to your post has no idea which of @user’s posts you’re actually responding to. If you’re lucky it’ll be clear. If not, well, tough. “This was the previous behavior and was changed because of user complaints over false positives.” WONTFIX.
So, what have we learnt?
- in_reply_to is a relatively late change to Twitter
- in_reply_to is only available if you start your post @user
- in_reply_to is reliant on the user and client explicitly responding to a post
- in_reply_to is absent for retweets, @@replies, and the like
- in_reply_to is implemented as is because Twitter believe false negatives are better than false positives
2009-07-10
post/138976951
(via atsween)
Dean Allen seems upset. Unfortunately, I find favrd is as shitty as the newcomers tweetorites and favstar.fm, because my stream is private, so none of them can be persuaded I exist. At least the otherwise appalingly garish favstar tells me why I am apparently so unpopular.
Now, I’ll admit that, as with Microplaza, supporting private users is tricky, but it’s possible - set up an account associated with the site and follow private users so you can see what’s going on.
Fundamentally, though, the whole model that all these sites work on is a monstrous hack. Unlike Flickr¹, Twitter has no public mechanism to find out which of your posts have been marked as a favourite, so all these services pull down RSS for many users, looking to see which status updates get marked. Naturally, this isn’t exhaustive; if someone they’re not tracking (like a private user, sigh, or someone new) adds something, it’s ignored. Of course it’s also horrifically inefficient.
It’s even more annoying to find that a few select users do actually have this feature within Twitter itself, but it’s not exposed. Here’s an example.
Hopefully one day Twitter will stop growing stupidly fast and their engineers can spend some time, you know, adding features. Features like exposing favourites (which might even help eliminate the scourges of “retweeting” and trending topics). I’m not holding my breath, though. In the meantime, it’s tempting to take my account public just so I can use all the third-party apps that don’t cater for private users.
¹ Flickr’s Recent Activity shows you favourites. It doesn’t have an API method, but I can live with that when the site shows it.
2009-06-16
post/124785177
Jonathan Zittrain: Could Iran Shut Down Twitter?
This reminds me of something tangential I’ve been meaning to say for a while. I’ve more experience writing apps that work with Flickr, and while I’ve had some people using apps that are hosted on external sites, I always had the impression that fidding around within the site using Greasemonkey scripts was a far more common approach for adding functionality.
By contrast, Twitter has a huge ecosystem not just of client applications, from the basic to the complex, but also a range of websites. Because the core website is so minimal, users almost expect to have to look elsewhere for functionality that any other service would have built in (link expansion, archives, tracking favourites; heck, even search was originally a third party, and it still (sort of) lives on another domain).
In a way, this is annoying, because Flickr users are so hard to get off the site. On the other hand, I think I’d rather use a service that bothered to build things itself.
