hardscrabble 🍫

By Max Jacobson

Psst. Check out my RubyConf 2017 talk, There are no rules in Ruby.

blog posts

ruby-build, chruby, and yosemite

19 Oct 2014

A few months ago I stopped using rvm to install and manage my ruby installations on my computers. I don’t have a great reason, other than reading that Steve Klabnik uses something else and I felt like trying it one day.

What I use now:


This is how I install rubies:

  • brew install ruby-build – get ruby-build
  • mkdir ~/.rubies – this is where rubies and gems will go
  • ruby-build --definitions – shows you a list of all the available rubies. When new ones come out, you should be able to just brew update and brew upgrade ruby-build to get access to those new definitions
  • ruby-build 2.1.3 ~/.rubies/2.1.3 – first argument is the name of the definition from the previous step, and the second argument is where to install all the code
  • watch it install


This is how I switch between versions of ruby.


The instructions in the readme are good. The gist is that you install a script and then source it from your ~/.bashrc so it will be included in your shell sessions. This exposes a chruby bash function, which you can thereafter reference from the shell to switch between rubies (eg chruby 2.1.2) or even later in your ~/.bashrc, to choose a ruby immediately upon starting a shell session. This will look in the ~/.rubies folder by default, which is why I install my rubies there.


So this all stopped working on my laptop yesterday when I upgraded to Mac OS X 10.10 (Yosemite). I couldn’t run bundle install without getting a nasty error, and I became convinced that I needed to rebuild all of my rubies. So I thought “OK, I know how to do that” and ran rm -rf ~/.rubies and set about following those steps under “ruby-build” above.

It didn’t work, so I went to sleep.

Long story short, this fix worked: https://github.com/sstephenson/rbenv/issues/610#issuecomment-58804829

Where before you would have run ruby-build 2.1.3 ~/.rubies/2.1.3, now (until ruby-build makes a fix) you can run CC=clang ruby-build 2.1.3 ~/.rubies/2.1.3.

I don’t know if rvm had this problem. I wouldn’t be surprised if they did, and it was fixed quickly. But like. It’s kind of cool to use smaller tools sometimes.

the cop and the hound

28 Sep 2014

As a rails developer I keep hearing about Thoughtbot’s cool projects. A fairly recent one is Hound, a tool that comments on your GitHub pull requests and points out code style violations. I think consistent style is a nice ideal to strive for, so I want something like this.

Setting up Hound is easy, but it only reviews the code that is added in a pull request, not the existing code base. Which, in theory, is fine. Except, if you’re the kind of obsessive compulsive who wants a style guide, it’s probably not.

So I managed to make Hound review the full code base but it took some tricky git branching and pull requesting. So I made a screeny1 to share:

Setting up Hound CI to comment on my full code base from Max Jacobson on Vimeo.

I didn’t want this video to be too long, so I stopped when I managed to get the full codebase analyzed. But here’s my plan to continue:

  1. I’ll need to learn how to configure Hound to more accurately reflect my tastes. Under the hood it uses rubocop, pre-configured with Thoughtbot’s style rules. I’ll add my own configuration and push again, which will hopefully refresh the comments.
  2. Then I’ll fix all the code style violations and keep pushing them up until all of the comments go away. Then I’ll merge the second pull request. At that point my first pull request will (hopefully) have a diff that shows exactly what I want: new configuration and style fixes.
  3. I’ll squash that branch to have just one commit and merge it.
  4. Then I’ll merge that pull request into master and be nicely set up for a future of consistent style.

1. configuring rubocop

These are the default “cops” for rubocop. If I were starting fresh with rubocop (and not using Hound), I would start with this configuration file and start disabling specific cops. In fact, this is exactly what Hound does. Their tweaks are available because Hound is open source.

Here’s what I came up with: https://github.com/maxjacobson/film_snob/blob/hound-it-up/.rubocop.yml (if that link is dead, it’s probably because I merged the PR and deleted the branch, in which case the file can be access here).

Maybe I’ll change it over time but it seems good right now.

2. fixing all the violations

Done: https://github.com/maxjacobson/film_snob/pull/46

Being consistent feels good :smile:.

It’s actually not that hard to use rubocop directly without Hound. I also added rubocop to my Travis CI configuration, so even if I didn’t have Hound, pull requests would consider style guide violations, because the build would fail. There’s no commenting, which decreases the visibility. But it’s OK because Hound double-comments if you push the same problem twice, so maybe the comments aren’t that great? It’s also much more strict. If you have an 81 character line, it’s a complete no go, the build fails, you can’t merge that.

I’ll try that.

  1. I call them screenies because the app I use to make screenies is called Screeny