If you’ve written Ruby, chances are you’ve had to use ruby-debug. You might’ve thought the experience sucked — especially the fact that the debugger defaults to a mode in which you have to use a keyword to get it to evaluate a statement. Lost? Here’s what I mean:

Say you start the debugger here:

Then you want to take a look at the “xml_obj” variable. If this were (for instance) Python’s pdb, we’d just type “xml_obj” and hit return and be done with it. Not so in ruby-debug:

This is because with default settings, the debugger needs a keyword (’p') to get it to actually evaluate your statement as Ruby and not a command to the debugger itself:

That gets really tedious, really fast. The debugger’s help function (’help p’) will helpfully tell you that this is because the “autoeval” option is not enabled. If you’re thick like me, you won’t see this and you’ll just continue doing “p <whatever>” until you get so frustrated you drop what you’re doing one day and go hunt down a fix.

Here is that fix from inside your code:

You can also do this inside the debugger:

Rails already does it via Rack middleware

You might be wondering why the debugging experience is different in Rails than in Ruby you’ve written elsewhere. I did too — remembering that this ‘p’ business isn’t necessary when I run the debugger as an option when I start up Mongrel in a Rails app. So I went digging for the code that Rails uses to set this stuff up. Those settings come from a piece of Rack middleware that lives in lib/rails/rack/debugger.rb. Here’s the class definition:

For more info on how Rails uses Rack, this is a pretty handy page from the Rails guides.

Just because I can never remember this, here’s how to get a new repo source registered in RubyGems – you use the “sources” command — as in this piece for registering GitHub as a source for gems:

gem sources -a http://gems.github.com

There. Now I won’t forget the damn command anymore. Or if I do, it’s here in my other brain…

Note: Since this post originally went up, some of the packages have changed/updated. I’ve kept things pretty well up-to-date, but you might want to double check the latest versions and alter the bash commands accordingly. Be aware that as of this writing, the Ruby team has made 1.9.1 the latest stable and only Rails itself is deemed compatible with Ruby 1.9x. I.e., Rails passes all its own tests on 1.9.1, but most plugins, libraries, etc are likely to give you problems right now. So your best bet is to use 1.8.7 for awhile until your favorite libraries jump on board the 1.9 wagon.       –Trevor (August 17, 2009)

I recently had to roll a new VM for work in order to run Rails and Sinatra apps on Apache/Passenger. My company favors CentOS as the default distro for all our boxes, so I wasn’t able to use all the super-up-to-date packages that Ubuntu makes available, and I ended up building everything from source. For posterity and for anyone else who needs it, here’s a list of what to do and how to do it.

Dependencies

You’ll need several libraries and the MySQL server, and you can use yum to install them all at once. This set includes the gcc compiler, the gcc-c++ compiler, and the zlib development headers for Ruby. Remember: not all libraries are the same — you’re going to need to make sure that you’re compiling Ruby w/ 32 or 64-bit development headers as appropriate for your architecture.

Ruby

Next up is Ruby. We’ll install 1.8.7-p72, the latest stable as of this writing. First, we’ll make a “src” directory in /usr/local to hold everything:

Ok now for a weird thing — you need to remake and re-install Ruby after using it to run a script that helps you make a new makefile. This is so that you can tell it where the zlib headers live:

After all that happens, you should have Ruby installed. Check and see by doing:

You should see something like:

Rubygems

Now that you have Ruby installed, Rubygems is easy — the whole thing is in Ruby so there’s nothing to build/compile.

Rails, Passenger, MySQL and Sinatra

Now that Ruby and Rubygems are installed, you can install Rails, Passenger, and Sinatra as gems:

That will take awhile, as there’s a ton of documentation to build for Rails, and Passenger has to compile some native extensions.

Once that’s done, finish the Passenger installation with their nifty installer tool:

Follow the provided instructions at the end of the installer for adding lines to httpd.conf:

After that, install the MySQL gem, making sure to specify where the config is:

Disabling SELinux

The RedHat family of distros (RHEL, CentOS, Fedora) come with SELinux enabled by default. If you want to learn how to make it work with Passenger, you can try this tip from the Passenger user’s guide. I just turned it off because the box is only going to be used for these apps, and SELinux seems like overkill. Here’s how to shut it down:

First, disable it temporarily:

That’s not a permanent fix though, because the next time the server boots, it’ll be turned back on again. You need to edit the config file and turn it off. Open it with your favorite editor and change one line. You need to be root or running as sudo to edit this file, and I prefer Vim when on remote servers, so it’s:

Change this:

to this:

Restart Apache

You should be able to restart Apache now and have Passenger come up no problem. There are several ways to restart Apache, but I like to use the service way to keep it simple:

Optional: Installing Git

For SCM, there are a lot of reasons why I like Git better than Subversion. It’s got a bit of a learning curve, but once you go Git, you never go back.

And the man pages:

Now you should have Git installed and ready. Prove it:

You should see something like:

And that’s it — you now have a full Ruby stack ready to go on CentOS 5. Much of this tutorial was adapted from the awesome Hivelogic post on installing the stack on OS X Leopard.

Long-as-hell Ruby on Rails RSpec test running times are making you ask “what the deuce?” Specs are taking way too long to run, but the prospect of looking through them all one at a time to find offending external dependencies, net calls that should be mocked, etc is driving you to drink. You just want a read-out of the tests that are taking the longest so you can refactor ASAP.

Sound familiar?

I was in this boat until I found out about the profiling command:

The double “spec” here can be a bit confusing. The first is the command, and the second is the directory (RAILS_ROOT/spec) that you’re running it on. The -f is the format flag. You can see a list of all formats with:

Basically you’re just passing the “profile” argument to the formatting command. It gives you a readout of the 10 most time-intensive specs at the top and then a nicely verbose list of all pending and failed tests. Using this list, I was able to go straight to the most obnoxious offenders and eliminate the external dependencies (these specs happened to be fetching feeds) that were slowing my test suite down. In less than 15 minutes, I had chopped my execution time down to 10% of what it was before I started.

Huzzah!