ruby

RVM gives you three things:

• an easy way to use multiple versions of multiple Ruby VMs
• the ability to manage multiple indpendent sets of gems
• more sanity

First, let’s install RVM:

• gem install rvm
• rvm-install
• follow the directions to integrate with your shell of choice

Now, let’s install some Rubies:

• rvm list known will show us all the released Rubies that we can install (more on list)
• rvm list rubies will show which Rubies we have locally installed
• rvm install ree-1.8.7 gives me the latest release of the 1.8.7 branch of Ruby Enterprise Edition
• rvm install jruby will give me the default release for JRuby
• rvm use jruby will switch to JRuby
• rvm use ree will give me Ruby Enterprise Edition
• rvm use ruby-1.8.6 will give me an old and familiar friend
• rvm use system will put me back wherever my operating system left me

The other trick that RVM gives us is the ability to switch between different sets of installed gems:

• Each Ruby VM (JRuby, Ruby 1.9, Ruby 1.8, REE) has its own set of gems. This is a fact of life, due to differing APIs and, you know,
  underlying languages.
• rvm use ruby-1.9.1 gives you the default Ruby 1.9 gemset
• rvm use ruby-1.9.1%acme gives you the gemset for your work with Acme Corp (more on using gemsets)
• rvm use ruby-1.9.1%wayne gives you the gemset for your work with Wayne Enterprises
• rvm use ree%awesome gives you the gemset for your awesome app
• You can export and import gemsets. This can come in handy to bring new people onboard. No longer will they have to sheepishly install
  gems on their first day as they work through dependencies you long
  since forgot about.

Some other handy things to peruse:

• Some workflow examples
• CLI options

I also promised you some extra sanity:

• RVM knows how to compile things, put Rubygems and rake in place, even apply patches and pull from specific tags. You can do more important things, like watch The View or read an eleven part series on pre-draft analysis for the Cowboys.
• RVM lets you isolate different applications you’re working on. Got one app that doesn’t play nice with Rails 2.x installed? No problem, create a gem environment for that! Stuck in the spider-web of Merb dependencies? Isolate it in its own environment.
• RVM makes multi-platform testing and benchmarking easy. You can easily run your test suite or performance gizmo on whatever Rubies you have installed.
• RVM makes it easy to tinker with esoteric patchlevels and implementations. For instance, feel free to tinker with MagLev or the mput branch of MRI.

A couple other things RVM tastes great with:

• Using homebrew to manage packages instead of MacPorts
• Not using sudo to install your gems
• Managing your dotfiles on GitHub

I’m a little conflicted about how and if one should write test code for declarative code. Let’s say I’m writing a MongoMapper document class. It might look something like this:

class Issue

  include MongoMapper::Document

  key :title, String
  key :body, String
  key :created_at, DateTime

end

Those key calls. Should I write a test for them? In the past, I’ve said “yes” on the principle that I was test driving the code and I needed something to fail in order to add code. Further, the growing ML-style-typing geek within me likes that writing tests for this is somewhat like constructing my open wacky type system via the test suite.

A Shoulda-flavored test might look something like this:

class IssueTest < Test::Unit::TestCase

  context 'An issue' do

    should_have_keys :title, :body, :created_at

  end

end

Ignoring the recursive rathole that I’ve now jumped into, I’m left with the question: what use is that should_have_keys? Will it help someone better understand Issue at some point in the future? Will it prevent me from naively breaking the software?

Perhaps this is the crux of the biscuit: by adding code to make certain those key calls are present, have I address the inherent complexity of my application or have I imposed complexity?

I’m going to experiment with swinging back towards leaving these sorts of declarations alone. The jury is still out.

Remember when you first started programming? Those early days when you’d take some code out of a book or article, type it out, and then try to make it print silly things or draw funny pictures?

The thing I remember about those days was the temptation to blame the compiler for all the ills of my code. Something doesn’t work right and you can’t figure out why? Blame the compiler! Of course, this was never right. The compiler is very rarely incorrect.

My goal today is to bring back the joy of blaming the compiler. Of course, Ruby doesn’t have a compiler (yet!), so we have to play tricks. But that’s part of the fun!

Let’s blame the compiler.

See, all you have to do is extend BlameTheCompiler. And then you’ll find yourself with one chance in every three executions to say “Hmm, I’m sure I defined that method. Something must be wrong with Ruby.” Just like those early days of programming, you’re half right. The other half is that you’ve got a little prankster running in your application.

It’s a fun parlour trick. I would not, however, recommend sending code including BlameTheCompiler in as a bug report to the JRuby or Rubinius folks. They wouldn’t find it as funny as you or I.

I’ve been finding this little snippet extremely useful lately:

$ irb -Ilib -rmy_library

If your Ruby app or library follows the idiom of requiring all the files for your app in a file named after the library, this will load everything up. If you’re being clever, you may need to invoke said cleverness before you can really get started poking around.

Anyone doing something similar?