Hardscrabble 🍫

By Max Jacobson

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:

ruby-build

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

chruby

This is how I switch between versions of ruby.

setup

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.

Yosemite…

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 

sleep timers

07 Sep 2014

Falling asleep is one of the weirdest things that everyone does every day. Many people struggle to do it all. They experiment and develop workflows that help cope with this necessary evil. Here’s mine.

If I’m very exhausted I simply lie down, close my eyes, and shortly thereafter I fall asleep. This isn’t very often due to my sedentary lifestyle, so I’m often lying in bed wondering what I’m supposed to be doing with my arms and/or mind. The recourse I usually take to is to play a podcast. Many would argue that listening to a podcast is counter-productive to the goal of falling asleep. I don’t completely disagree, but I like to do something to fill that time, even if doing nothing would mean less time falling asleep, podcasts make the longer time pass quicker, so it evens out.

One problem is that podcast clients often autoplay, such that when one episode ends, the next begins. If you combine this feature with the auto-download feature, this creates the risk that I will go into an infinite loop of listening to podcasts literally forever.

If I could somehow fall asleep while people were talking, I would wake up to hear them still talking, potentially about anything at all, which I imagine to be extremely disorienting.

To mitigate these risks, I’ll apply a sleep timer, which means that I’ll tell the podcast to stop playing after a specified number of minutes has passed. Here are the steps I take:

  1. I press play on a podcast
  2. I apply a sleep timer of 5-15 minutes depending on how sleepy I feel
  3. I listen to the podcast while relaxing my body and mind
  4. I sense the impending timer running out and a curious tension fills me
  5. The podcast fades out and stops and I immediately fall asleep

If I don’t fall asleep, I start over, maybe with a shorter timer. I never fall asleep before the sleep timer runs out. If I do that, I’ll miss part of the podcast, which I would hate.

It’s essential to my bedtime workflow that I have fine control over how many minutes the sleep timer will run, because I believe that I can predict how long it will take me to fall asleep based on my current level of sleepiness. It’s also important that the audio fades away because that signals my internal systems to prepare to do that last, most important step (falling asleep).

This is my main complaint about the otherwise terrific new podcast app Overcast which does offer a sleep timer, but one that can only be set in crude chunks of 5 minute increments, and which stops with no fade out at all. I won’t be switching back to Downcast, which set the standard for sleep timers for me, but I suspect my sleep will suffer.

How do you fall asleep?