Alex Kahn Blog

A Sinatra App Wrapping Flickr, Plus HTTP Caching and Heroku

2010-02-22T00:00:00-05:00

In the last several months, Esther has produced a large number of monotype prints at a local printmaking studio. She’s been sharing her work online by scanning it and posting it to Flickr. Recently she experimented with using Tumblr to create a stylish gallery of this work. But this process — scanning, adding metadata, uploading to Flickr, followed by posting each piece to Tumblr — proved to be laborious. So we sought to streamline this workflow, hoping to eliminate a step or two.

Titles, descriptions, tags and sets are all easy to manage on Flickr. What if there was a way to take advantage of Flickr’s great management interface, taking images and metadata and putting them on an external site? I took on this problem with a Sinatra application that wraps the Flickr API in a warm embrace. The app makes an API request to Flickr asking for all the images from Esther’s printmaking photoset and renders them as thumbnails, each image linking to a page for that image. On the individual image page, the app requests information on an image – title, description, and the next and previous image – and displays this information along with a larger image of the piece. Now, Flickr itself is the CMS and the gallery is just a pretty shell for information already stored on Flickr. No more managing metadata in multiple places. Have a look at the site.

What about performance? Isn’t it slow to make an API request to Flickr for every visit to the site? This is a definite concern: making an API call to Flickr and then responding takes the application about 500ms – respectable but not exactly speedy. But the content of the site is basically static. Once an image is uploaded and described on Flickr, it is unlikely to change. This means I can cache the entire page with a gateway cache¹. To do this, I set Cache-Control headers that say that my pages are allowed to be cached for long time, and the cache, Varnish, serves up a static representation of the page that the app produced. Once a page has been requested once, subsequent requests for that page are lightning-fast – under 100ms. After six hours, the cached representation of the homepage is considered stale, and a new one will be generated. After two days, the cached representation of an individual page is considered stale. This way, updates to the photoset or changes to images do eventually get served to visitors.

I should note that I’m hosting this site on Heroku. It’s been said elsewhere and should perhaps be obvious by now, but I’ll say it again: Heroku is awesome. Their use of Varnish made it so easy to make this gallery app fast. Deploying code with just a git push is seriously great. I recommend hosting an app on Heroku if you haven’t before. It’s easy and, for a simple app like this one, is free.

1: For more on HTTP caching, see Ryan Tomayko’s excellent article Things Caches Do

FakeWeb and Regular Expressions

2009-12-16T00:00:00-05:00

FakeWeb is a great way to speed up your tests and remove dependencies on external web services. Using FakeWeb is simple: specify a URL for FakeWeb to respond to, and give it the response you expect from the request. For example:

FakeWeb.register_uri(:get, "http://www.google.com", :body => "Stubbed Google!")
HTTParty.get("http://www.google.com") # => "Stubbed Google!"

Now FakeWeb will prevent your code from making an actual HTTP request and instead it will return the response you specified. But what if your application makes requests to URLs with query parameters? It would be tedious to register each URL with FakeWeb:

FakeWeb.register_uri(:get, "http://www.google.com/search?q=fakeweb", :body => "Stubbed Google!")
FakeWeb.register_uri(:get, "http://www.google.com/search?q=excited+kitten", :body => "Stubbed Google!")
FakeWeb.register_uri(:get, "http://www.google.com/search?q=ponies", :body => "Stubbed Google!")

Thankfully, FakeWeb has a (slightly underdocumented) solution for this. Instead of passing a string to FakeWeb.register_uri, pass it a regular expression (using Ruby’s %r|| syntax to avoid having to escape forward slashes):

FakeWeb.register_uri(:get, %r|http://www.google.com/search\?q=|, :body => "A bunch of results")
HTTParty.get("http://www.google.com/search?q=tunisia") # => "A bunch of results"
HTTParty.get("http://www.google.com/search?q=vegan+latkes") # => "A bunch of results"

By registering a regular expression, FakeWeb will respond to any HTTP GET request whose URL matches the pattern you’ve supplied. Your test suite can make requests with all different query parameters without having to register each individual URL. This feature adds a lot of flexibility to FakeWeb and makes it feasible to stub out your application’s HTTP requests, even when complex, changing query parameters are involved.

For a general overview of FakeWeb, as well a some far-less-contrived examples of its use, check out Josh Nichols’ post, Stop Net::HTTP dead in its tracks. Also check out FakeWeb on GitHub.

Pretty Feed Items with Facebook Connect

2009-11-06T00:00:00-05:00

At Free Press, when a user signs a petition or shows support for our issues on one of our sites, we want them to spread the word. We want to make it easy for users to share the story they told, or the petition they signed, and to encourage others to do the same. We usually do this with links to Facebook’s sharer.php and Twitter’s status parameter.

But sharer.php left us frustrated with its awkward interface and lack of branding. What about the pretty updates that Facebook applications produce? We wanted a feed item that looked branded, looked good, and compelled a user’s friends to also take action. This is where Facebook Connect comes in.

Using Facebook Connect for this task turned out to be simple. Surprisingly simple. Here’s the routine:

Create a Facebook application
Create a file to allow cross-domain JavaScript communication
Include Facebook’s JavaScript library
Write some JavaScript

Steps 1-3 are fairly well documented in the links above. Step 4 is the interesting part. Take a look at the code below.

var AK = {
  apiKey:  "de24e7cfd602218871fc8e30b3dd8a5f",
  message: "Facebook Connect is easy!",
  attachment: {
    name: "Updating from akahn.net",
    href: "http://www.akahn.net",
    caption: "So cool!",
    media: [{
      type: "image",
      src:  "http://akahn.net/images/shoes.jpg",
      href: "http://www.akahn.net"
    }]
  },
}
FB.init(AK.apiKey, "/xd_comm.html");
FB.ensureInit(function() {
  FB.Connect.streamPublish(AK.message, AK.attachment);
});

What’s going on here? First, I’m creating an object, AK, to store the various pieces of data I need. This includes an API key, the default message that the user will be posting to their feed, along with some other bits of text, and an image.

I then get the API ready, using FB.init, specifying my API key and the location of my cross-domain communication file.

Then I make sure that the API has finished loading, using FB.ensureInit. I pass in a function, to be executed once the API has finished loading.

In the function, I call FB.Connect.streamPublish. I pass in the message and the attachment object that I defined earlier. If the user is logged in on Facebook, they’re presented with a modal popup inviting them to post to their feed. If not, they’re prompted to log in before they are invited to create a feed item. Try it out below:

Post to my Facebook wall!

And that’s it! It takes a lot of setup just to make one little call to FB.Connect.streamPublish. But the smooth user experience and the customized, pretty feed item make it all worthwhile.