Heroku is a cloud-based solution for deploying Rack applications on top of Amazon's EC2 (Elastic Compute Cloud) service. I decided to give it a go with some smaller apps I had going and thought to write about my experience.

One of the first things that came to mind with Heroku, is that you're actually deploying to a read-only filesystem. This means you'll have to use a third party service, such as Amazon's S3 (Simple Storage Service) to dynamically store media for your app. I find having separate facilities for your application, it's data, and it's uploaded media is a good idea. Heroku's constraints just seem to enforce this way of thinking.

It actually makes a lot of sense. Your application data will more than likely be stored in a relational database, and with your uploaded media being stored elsewhere, your application's source tree shouldn't be changing until you redeploy with some changes anyway, at which point Heroku will recreate it's read-only slug. This makes the actual deployment process on Heroku dead simple. Just do a git push heroku and you're done. If you need to roll back to a specific branch, tag, or even commit SHA, just force the commit with git push -f heroku commit:branch.

So after a good few days of spare time contribution to my Ruby Dopplr API, it is now functional and ready to use. This is pretty much a project I did for fun to put some things into practice, but hopefully someone can make use of it in a mashup or other application. At this point, much of the data is just returned as a hash from the JSON response, but I’ll be adding some deeper functionality in the future for more complex data queries and such.

To use the library, simply create a client with a traveller and city object. You can return some data from each object, or perform a search query.

require 'dopplr'

client = Dopplr::Client.new('token')
mikeric = client.traveller('mikeric')
vancouver = client.city('6173331')

mikeric.info
mikeric.trips
vancouver.info
vancouver.trips
client.search("Montreal", :city)

Basically, the other Ruby implementation uses method_missing for all it's API calls. This works, but it's not the best way in a practical sense. I find that having separate methods for their corresponding objects works nicely, in that you can see available methods for a given object by calling Dopplr::Traveller.methods or Dopplr::City.methods. Also note that method_missing, depending on how it's used, can be noticeably slower.

If you want a simpler but less practical solution, take a look at the “single” branch. It contains all the methods in a single Dopplr class. Check it out, fork it, enjoy.