If you’re already using Git, getting a Rails app set up on Heroku is as simple as running these commands:

gem install heroku
cd myapp
heroku create
git push heroku master
heroku rake db:migrate

This standard workflow is great for the early stages of development or for simple applications, but with a large application you’ll probably want to put a few more safeguards in place. Tom Lea and I have recently found ourseveles in exactly that situation, so we’ve written a few Rake tasks to make sure we don’t mess anything up when we’re deploying changes.

What we wanted was:

1. Multiple Heroku remotes: One for staging and one for production.
2. Backups as part of the deploy process, so its easy to roll back mistakes.
3. Automatic tagging of deployments.

I’ll explain how and why we did all of this shortly, but first things first…

The code

Multiple Heroku remotes

The first thing we wanted to do was set up a second Heroku remote where we could preview and demonstrate changes without endangering the production app.

The heroku command usually figures out which application to send commands to by looking at the Git remotes of the current directory and picking the first one it find that points to heroku.com. This isn’t too helpful if you have multiple Heroku remotes, but fortunately there’s an optional --app argument which lets you explicity specify which remote you’re referring to.

To make sure we don’t accidentally run commands against the wrong remote app, we’ve removed the Heroku git remotes altogether.

Now instead of this:

git push heroku master
heroku rake db:migrate

We use this:

git push git@heroku.com:myapp.git master
heroku rake db:migrate --app myapp

Backup before deployment

The second thing we wanted was to be able to roll back quickly if we messed up a deploy. Heroku has a helpful backup feature that allows you to capture, download and most importantly restore a tarball containing the app’s code and database using the heroku bundle command. We capture a bundle immediately before deploying and download a copy of it:

heroku bundles:destroy deploybackup --app myapp
heroku bundles:capture deploybackup --app myapp
heroku bundles:download deploybackup --app myapp

The first command (heroku bundles:destroy) will delete the bundle named “deploybackup” from Heroku. If you are using the unlimited bundles add-on you could skip this step and use a unique bundle name each time instead.

Capturing a bundle takes some time, so you can’t just run these commands one after another in a script but it is possible to see the current state of your app’s bundles using the heroku bundle command, so it’s easy enough to wait while Heroku creates the bundle using a while loop and a sleep.

Tagging deployments

Our final aim was to track what we had deployed and when we had deployed it using Git tags. Exactly how you tag and deploy will depend on how you use Git.

For our project, we have a production branch which we merge our changes into when we’re ready to deploy them, so our deploy tasks are set up to push the head of that branch. For example, if we were deploying on 1st February 2010, the commands we would use would look something like this:

git tag heroku-2010-02-01 production
git push git@heroku.com:myapp.git heroku-2010-02-01:master

If you do something different it should be easy enough to change the scripts to suit.

Fork me

I’ve put the code on GitHub in a gist, feel free to fork and improve it.

Our CSS is now in .spriter files, and using a sprite is as easy as a normal CSS background image:

span.icon {
  -spriter-background: 'icon.png';
}

There’s a Rack middleware that converts .spriter files to CSS and generates the sprite images on request which we use in development, and a few simple methods to create static assets that we use when deploying to production.

If you’re interested you can read more on the Reevoo blog and get the code from GitHub.

You can include it in your Rails app by adding this line to your test environment config file (config/environments/test.rb):

config.gem "georgebrock-assert-microformats", :source => "http://gems.github.com/", :lib => false

Now you can test your microformats using some shiny new assertions.

By default these assertions will look for microformats in Rails’ @response:

test "show view should contain an hcard" do
  get :show
  assert_mf_hcard
end

You can also test the values of microformat attributes:

assert_mf_hcard :fn => 'George Brocklehurst', :url => 'http://georgebrock.com/'

And you can pass in some HTML, which comes in handy when you’re testing view helpers or not using Rails at all:

assert_mf_hcalendar my_html, :summary => 'Birthday party'

The microformat parsing is done using Mofo, so assert-microformats supports all the microformats that Mofo supports.

If you’re interested in how it works, or you want to make any changes, the code is all on GitHub.

I’d also like to thank Tom Lea for looking over the code and making some improvements.

XFN is a microformat that expresses relationships. If a page represents you (for example your blog or your profile on a social network site) you can annotate the links on that page to indicate whether you are linking to another of your own profiles or to a friend, colleague or contact’s page.

The annotations are made using the (X)HTML rel attribute. The HTML 4 specification provides several standard values for the rel attribute include next, prev and contents. In an age of social networks, where URLs often represent people, XFN is a logical extension of this attribute.

Of course, this is open to abuse. I could add a link to this page that points to someone else’s site and uses XFN to claim that it is also my site. This is why the claims made by XFN are generally not trusted unless they are reciprocal. For example, this blog links to georgebrock.com and georgebrock.com links back to this blog. Both pages claim that the other site is about the same person, and because the claim is reciprocal it can be considered trustworthy.

XFN and rev

I’ve recently been building a social networking site, and marking up the user profiles and contact lists using a combination of hCard and XFN. While I was marking this up I found myself reaching not only for the rel attribute, but also the less common rev attribute. The rev attribute specifies the reverse relationship described by the link, for example rel="prev" is equivalent to rev="next".

This is the markup that I came up with:

 <h3>1 user wants to be your friend</h3>
 <ul>
   <li class="vcard">
     <a rev="friend" class="fn url" href="…">
       Tom Smith
     </a>
   </li>
 </ul>

 <h3>Waiting for confirmation from 1 user</h3>
 <ul>
   <li class="vcard">
     <a rel="friend" class="fn url" href="…">
       Dick Jones
     </a>
   </li>
 </ul>

 <h3>Friends with 1 user</h3>
 <ul>
   <li class="vcard">
     <a rel="friend" rev="friend" class="fn url" href="…">
       Harry Taylor
     </a>
   </li>
 </ul>

I’ve also considered using some of my own link types (with an accompanying XMDP document, of course). For example, if you have asked to be friends with someone and they haven’t yet confirmed the relationship that could be made more explicit using rel="friend" rev="unconfirmed" on your profile and inverse on their profile: rel="unconfirmed" rev="friend".

Pros and cons

There are a few things about this that I really like:

1. The markup is more semantically rich that it would be if only using rel. It expresses not only all the claims that a user has made, but also all the claims that have been made about that user, even if they are not (or not yet) reciprocal.
2. Having all the relationship information about a given user in one place makes it incredibly easy to extract very specific information with a tool like YQL or GRDDL without having to rely on specific knowledge of the page structure.

There are also a few things that I don’t like:

1. The rev attribute isn’t often used and is commonly misunderstood (although I’m not sure why, the specification is very clear on what it means). Because of the lack of understanding the microformats wiki strongly discourages the use of rev.
2. It has been suggested that using rev instead of rel for XFN link types is tantamount to creating a whole new microformat.
3. The reason reciprocal claims are trustworthy is that they are made by both of the pages involved. This markup claims reciprocation without involving the other page. While this makes sense in this specific case (the links are between profiles in the same site and are being automatically generated based on the same set of data) it would not be good in the general case to assume that just because a link has both rel and rev it is reciprocal and therefore trustworthy.

What do you think?

I’ve not previously seen the link types defined in XFN used with the rev attribute, so I’m curious what other developers, and particularly those in the microformats community think of this?

Screenshot of XFN profile discovery

Yahoo hosted another of their Open Hack events in London this weekend. I took the opportunity to play around with YQL, the Google Social Graph API and the XFN microformat and built a Greasemonkey script that recognises when you’re on a social network profile and finds other social network profiles belonging to the same person.

If you want to try it out, just follow these simple steps:

1. Get Firefox and Greasemonkey.
2. Visit this page to install the plugin: georgebrock.com/openhack2009/xfndiscovery.user.js
3. Go to a profile page (like a Twitter page, or even this blog) and you’ll see a “more user profiles” link in the rop right corner of the page

If you’re more interested in how it works, you can find the source code on GitHub.

It starts by looking for links that use rel="me" (XFN’s way of saying “this link points to another page about the same person as this page”). If it find any it uses YQL (and a clever bit of XPath magic from Brian Suda) to find more rel="me" links on those page and so on until it runs out of profile links. To make sure nothing’s been missed it’ll bundle together all of the URLs that it’s found and pass them to the Google Social Graph API. If the SG API finds any new unique URLs they are parsed with YQL too. The combination of YQL and the SG API means that the script gets good coverage for most people, whether or not they have deliberately made use of rel="me".

One fun thing about building this hack was finding my own profiles on sites that I’d forgotten about (it turns out I have a soup.io account).

So here it is, Lastify in all its glory:

Lastify adds a drawer to the bottom of the Spotify window

Update: Lastify now supports tagging and has a much prettier user interface.

If you want to try Lastify you’ll need to install SIMBL first and everything else you need is hosted over on GitHub.

It’s a quick-and-dirty hack, and so all the usual caveats apply.

I spent the day playing around with SIMBL, Spotify and, of course, the Last.fm API trying to build a Spotify Scrobbler.  Progress was slower than I would have liked and I spent most of the day trying to figure out Spotify’s internal APIs and following various dead-ends (reverse engineering compiled software is tricky), but it was good to learn how to write SIMBL bundles and by the end of the day I’d managed to hack together a working plugin that was aware of when a new track started and what the track and artist names were. It seemed a shame to leave it half done, so I spent some time when I got home adding scrobbling capabilities, and you can now find a working Spotify Scrobbler over on GitHub (if you want to use it you’ll find instructions in the read-me file).  It’s not particularly polished, but I’m pretty pleased with how it turned out. All in all, a good first Hack Day.

Update: As of 18th December 2008 Spotify has built-in scrobbling support.

A script that automatically transforms links to Technorati’s events service into a useful little menu allowing events to be downloaded or added to various online calendar services. If you want to see it action check out this live demo.

It’s a bit rough around the edges (there’s a list of issues below). It uses Dan Webb’s Sumo microformats parser to extract event details (some online calendar services don’t support iCalendar import, so the details need to be passed directly) and JQuery to manipulate the page.

Files

The latest version of the script is kept in a public repository on GitHub

How to use

1. Mark up your events using hCalendar
2. Add a link to Technorati’s events parsing service. For example, the link for this page would be http://technorati.com/events/http://blog.georgebrock.com/projects/enhanced-hcalendar-downloads
3. Add all the relevant Javascript files to your page (Sumo’s microformat.js and hcalendar.js, JQuery and enhanced-hcalendar-downloads.js)
4. That’s all you need to do, but you might want to add some CSS rules to make the menu prettier (start here: enhanced-hcalendar-downloads.css)