This post originated from an RSS feed registered with Ruby Buzz by Jeremy Voorhis. Original Post: The Tooling Post: Ruby and Rails Feed Title: JVoorhis Feed URL: http://feeds.feedburner.com/jvoorhis Feed Description: JVoorhis is a Rubyist in northeast Ohio. He rambles about Ruby on Rails, development practices, other frameworks such as Django, and on other days he is just full of snark. Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Jeremy Voorhis Latest Posts From JVoorhis

A common complaint against Ruby is its lack of tooling support for developers. Amidst the influx of new and potential Ruby and Rails developers, there is a demand for something more. For those of you still putting your development environment together I’ll describe the tools that I am currently using that have proven themselves indispensable.

Automation

Learn Rake. Learn everything there is to know about it. Learn to make your own task libraries. You’ll be ready for anything. This article by Martin Fowler was useful to me.

Likewise, learn Capistrano for deployment. You should implement your deployment recipe before any of the core functionality of your application. Doing so gives you the advantage of writing code that is easy to deploy.

Testing

Take Rcov – Ruby’s coverage tool – for a spin. A good coverage tool provides you with detailed information about the kind of exercise your code is getting. You should strive for 100% test coverage, but also keep in mind that Rcov has no opinion about the quality of your tests.

begin
  require 'rcov/rcovtask'
  Rcov::RcovTask.new do |t|
    t.libs << 'test'
    t.test_files = FileList['test/{unit,integration,functional}/*_test.rb']
    t.verbose = true
  end
rescue LoadError
  puts 'Rcov is not available. Proceeding without...'
end

Learn to use mocks and stubs. I use Mocha for a mocking library. When used properly, mocks and stubs eliminate external dependencies from your tests – including the database. Eliminating external dependencies makes your test suite more robust to change, easier to understand and as a side-effect, it will run much faster. Here is an example of how to use Mocha to stub a web service client.

def test_get_avatar_from_flickr
  flickr_user = Flickr::User.new()
  flickr_user.stubs(:id).returns("30798076@N00")
  flickr.any_instance.stubs(:users).with("jeremy@jvoorhis.com").returns(flickr_user)  
  assert_equal "http://www.flickr.com/buddyicons/30798076@N00.jpg", @user.avatar
end

Editor/IDE

When I first began programming Ruby for profit, I was a devoted emacs user. Its keyboard shortcuts came natural to me – maybe something to do with my classical training on the piano. The basic emacs commands also work almost everywhere on OS X. Safari has a kill ring; while you can copy and paste normally, you can also use -k to kill highlighted text and -y to yank it back. The killed text doesn’t go to the clipboard either. Try it!

After using OS X for a while, I gave TextMate a try. It renders fonts beautifully and had many of the commands I commonly used in emacs, such as recordable macros. It is also very easy to automate – I even had a TextMate bundle for automating my book.

Since resigning from Planet Argon, I’ve had to turn in my shiny company PowerBook and have fallen back to involuntary ubuntu. I’ve tried going back to emacs, but couldn’t adjust to the jaggy fonts. I also tried compiling emacs with the Xft library for font anti-aliasing, but succumbed to the mysterious segfault. After deciding that it wasn’t worth spending any more time setting up a work environment on my home workstation, I decided to tackle the problem from the other direction and give Eclipse a chance.

For the past month, I have been using Eclipse with the Ruby Development Tools , RadRails and Subclipse plugins. It’s proven itself to be a reasonable platform.

Pros

• The test runner gives me a visual representation of all passing and failing tests that is far easier to scan than console output.
• Double clicking on the stack trace of a failed test moves my editor to the offending line of code, when applicable.
• Subclipse’s diff browser is among the best.
• The built-in RI browser is nothing to write home about, but is far easier to get in and out of than the html docs for Ruby’s core and standard libraries.
• Subclipse displays the current revision of each file in the filesystem tree view.
• I hate to admit it, but the outline view is just plain useful in large files.

Cons

• Eclipse doesn’t have recordable keyboard macros.
• My Subclipse installation chokes while committing to svn+ssh:// repositories.

There are other Ruby IDEs available as well, such as FreeRIDE and Komodo. It is also interesting that sun has hired the JRuby team and given them a mandate to think about developer tools. The refactoring support of Java IDEs may some day extend to Ruby. Of course, you, the savvy reader, will find something that works best for you.