Ruby

Fleshed out Ruby conventions further, with sections on Rails and Bundler. [fixes #2]
No, I meant based on the ['A Healthy Bundle'](http://robots.thoughtbot.com/a-healthy-bundle) article.

Basically my workflow is:

1. Update Rails by changing the version in `Gemfile` and then running `bundle update rails` whenever a new version is announced. I review the release notes and make sure the tests are all passing. Obviously this process takes on more gravity depending on the degree of the release (major/minor/patch).
2. Typically I'll just run `bundle update`, (which seems scary, but it's trivial to revert `Gemfile.lock`) and see what got updated. I'll run tests and review release notes and just generally check for stability.
3. If anything is unstable, or if an API has changed, or a deprecation has been introduced that I don't feel like dealing with right away, I'll lock it as pessimistically as possible, document why (usually just a link to a GitHub issue) and `bundle update {gem_name}` to get the right version.

Periodically I'll also check on gems I have locked to see if issues have been resolved and I can update to the latest and release the lock. I think this article also informed this view (it's been a while): http://prioritized.net/blog/embracing-promiscuous-gemfiles/. I used to pessimistically lock _everything_ but at a certain point I realized it was just adding noise to the `Gemfile` and not gaining me anything.

Either way, I'm not necessarily promoting this approach as much as pointing out that I *have* been thoughtful in adopting it.