A résumé in the form of a Rails3 app
Ruby CoffeeScript JavaScript
Switch branches/tags
Nothing to show
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


I’m Andrew Horner, and this is my résumé.

Let’s face it: writing résumés can be exceedingly frustrating. I’m unsure why anybody would want to work somewhere that wants to reduce them to a series of bullet points, and I’m only slightly more understanding of why a company might want to hire a person based solely on a list of credentials.

But writing a résumé is frustrating work for another reason—unless you’re applying for a job as a professional résumé-writer, the act of composing a résumé reflects very little about your ability to do the job you’re applying for.

It was this series of thoughts that led me to a realization: I could create a compelling résumé not only by highlighting my achievements and successes, but by highlighting the creation of the résumé itself as an achievement.

So here we are. In three days, I wrote a Rails app to frame my job experience and educational background.

The design for the site (and a good deal of the functionality) was inspired heavily by kongregate.com, a flash game site that rewards various in-game accomplishments with “badges”. I liked the idea of having my achievements highlighted as badges which could be attached to various jobs and schools.

In the spirit of selling myself, here are some of the more interesting bits of this app’s development:


I have a few habits when working with models in Rails:

  • attribute_normalizer to deal with user-entered values
  • paperclip for handling file attachments
    • paperclip’s post-processors can do a lot of work, from encrypting documents to (in this case) making greyscale images
  • annotate to add schema descriptions to model and spec files—non-essential, but handy


For this particular app, I wrote a basic (but robust) tagging system. The heart of the system is a polymorphic taggable association on the Tag model, in conjunction with a Taggable module that any other model can include to dynamically access and generate tags.

The user interface for tagging was important to me, so I kept it simple: each taggable model gets a tag_list attribute, and that attribute takes a string of comma-separated tag names. Intelligently adding and destroying tags based on the content of that string is all handled by the module.


Of course, tagging is pointless if you can’t pull up a list of all the items that share a common tag — so tags belong_to a Category model, which is responsible for grouping together all the taggable models into easy-to-access associations. Ensuring that there’s only one Category for any distinct tag name is, again, taken care of by the Taggable module.

To plop the cherry on the sundae, I wrote a Categorizable module to be included in any controllers that want to categorize their models on #index. It grabs all the @categories that have been tagged to objects of the relevant model, and if a :category_id is present in the params, it limits the returned records to only those in the proper category.


Some preferences when working with Rails views:

  • Haml to stand in for HTML/ERB templates. The nesting and whitespace make perfect sense to represent a tree structure.
    • heavy use of partials to abstract out page structure—a common layout can use relative partials for any controller-specific view components
  • Sass over SCSS
    • I write style rules myself, and I do it much faster without braces and semicolons
    • mixins to DRY out repeated style blocks (cross-browser compatibility rules, I’m looking at you)
  • RedCloth (textile) for rendering blocks of copy
    • copy is stored in locale files for easy modification and potential localization (though I don’t expect I’ll be translating this particular site)
    • allows basic styling for user-entered text without users having to know HTML at all


And of course, I’m particular about how I like my specs written:

  • RSpec to describe the behavior of controllers, models and views
    • test setup belongs in before(:each) blocks, not in the individual tests
    • shared_examples_for various Modules to abstract out the description of their functionality
    • shoulda matchers for terse description of associations and validations on models
  • factory_girl to generate model fixtures
  • autotest to run tests automatically while writing and refactoring