Pelargir

Musings on software and life from Matthew Bass.

January 30th, 2007

Montastically cool

I have a web site I’ve been working on that tends to go down at odd times during the night. It’s an issue with the web host, and due to financial constraints my client is not willing to relocate the site anytime soon. So I’m stuck with having to log in and reset everything whenever the site goes down. It only happens once a month or so, but since the site receives a small amount of traffic it often takes several hours (sometimes several days) for anyone to inform me that it’s down. Enter Montastic.

It’s rare that a free service comes along that is dead simple to use, works the first time (and every single time after that), and is ad-free. Montastic scores 110% on all counts. It’s a web-based monitoring service written in Rails that delivers notification via e-mail or RSS when a monitored site goes down.

Montastic’s UI is very straightforward, some might say even elegant. Sign-up took a few seconds. Logging in, a few more. Adding my site was a breeze (it only asks for the URL, amazingly enough). I subscribed to my feed and was off and running.

Montastic has already proven useful by alerting me to a server that went down just a few hours prior to writing this review. My sleep is that much easier knowing that Montastic is out there, ready to sound the alarm if my sites so much as twitch.

Go ahead, try it out.

January 30th, 2007

Dave’s EuroRailsConf keynote

Dave Thomas’ keynote from last year’s EuroRailsConf is now online. It’s about 45 minutes long and well worth watching. Dave discusses terrorism, risk, and how it relates to Rails. This really scratched an itch for me because I’m in a work situation right now where I’m dealing with a great deal of risk. The funny thing about risk is that it’s something that can’t be fully avoided, yet many people delude themselves into thinking that it can.

January 29th, 2007

Rails test results without the cruft

Ever notice the cruft you get when running Rails tests from the command line? It’s horrible, especially if your project has more than a dozen test files:

/opt/local/bin/ruby -Ilib:test "/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader.rb"
"test/unit/activity_test.rb" "test/unit/address_test.rb" "test/unit/application_helper_test.rb"
"test/unit/course_calculations_test.rb" "test/unit/course_test.rb" "test/unit/course_type_test.rb"
"test/unit/credit_hour_test.rb" "test/unit/email_test.rb" "test/unit/exam_test.rb" "test/unit/gender_test.rb"
"test/unit/grade_test.rb" "test/unit/level_test.rb" "test/unit/notifier_test.rb" "test/unit/numeric_test.rb"
"test/unit/obfuscator_test.rb" "test/unit/order_test.rb" "test/unit/school_test.rb" "test/unit/string_test.rb"
"test/unit/student_test.rb" "test/unit/transcript_test.rb" "test/unit/user_test.rb" 
Loaded suite /opt/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader
Started
..................................................................
Finished in 2.509903 seconds.
 
66 tests, 140 assertions, 0 failures, 0 errors

M@ McCray recently posted a hack to the Terralien Campfire that gives you a nice, clean summary instead:

Loaded suite /opt/local/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader
Started
..................................................................
Finished in 2.855885 seconds.
 
66 tests, 140 assertions, 0 failures, 0 errors

Want to start enjoying this super slim summary yourself? Just stick this code in your project’s Rakefile right before the require 'tasks/rails' bit:

Rake::TestTask.class_eval do
  alias_method :crufty_define, :define
  def define
    @verbose = false
    crufty_define
  end
end

Much better! We’re both surprised something like this isn’t already available in Core.

January 21st, 2007

Port of the Ocadia theme to Mephisto

Ocadia PreviewI began poking around the intriguing Rails-based Mephisto blogging engine this weekend. While the app itself looks quite promising, there is a noticeable absence of themes for it. I’m sure this will change, but in the meantime I thought I’d make my own contribution. The particular blog I’m converting originally ran on Becca Wei’s excellent Ocadia theme for WordPress so I went ahead and ported it to Mephisto. If you’re interested in using it on your own blog, download a copy and check out the README for installation instructions. Enjoy!

Update: Ocadia now has a home on GitHub. This means you now have the ability to check out the source code like this:

git clone git://github.com/pelargir/ocadia_mephisto.git
January 19th, 2007

Don’t leave empty test fixtures in your Rails projects

A friendly word of advice: don’t leave empty test fixtures in your Rails projects. In some situations, it can cause unexpected test failures that are quite nasty to track down.

January 16th, 2007

Bad Bailey


This is something funny that I think you might enjoy. My brother David and I had some spare time over Christmas to do something we’ve wanted to do ever since we saw Scary Mary on YouTube: edit together a horror trailer for Frank Capra’s classic film It’s a Wonderful Life. This is what we came up with. Enjoy.

January 2nd, 2007

Introduction to rcov, code coverage for Ruby

Do you routinely test your code? Are you using rcov to run code coverage reports for your tests? If you aren’t, you should be. rcov is a code coverage tool for Ruby that is available as a Gem or a Rails plugin. It can generate text or HTML reports outlining what percentage of your code base is being exercised by your tests. The HTML reports even allow you to drill down and see exactly which lines in your code are being touched. If you’ve ever used a tool like Cobertura for Java, you’ll know exactly what to expect with rcov.

Using rcov on a regular basis will enable you to isolate parts of your codebase that aren’t being tested very well (if at all). For example, the first time I ran rcov on one of my projects, it reported that the tests written against my Rails models touched 87% of the code. Not too shabby! However, my Rails controllers only had 45% coverage. Where do you think I concentrated my testing efforts after rcov was kind enough to inform me of these facts?

Installing and using rcov with an existing Rails project is a cinch. Let’s get started:

gem install rcov

Now move to the root of your Rails project and type:

script/plugin install http://svn.codahale.com/rails_rcov

Voila! Installation complete. Don’t you just love Rails? Now let’s fall in love with Rake:

rake test:units:rcov
rake test:functionals:rcov

Running these tasks will generate a text-based report of your project’s code coverage. The percentage of each class covered is listed, along with a total for the entire set of tests (unit vs. functional). Rcov also creates a /coverage directory beneath the root of your Rails project. Inside this directory, you’ll find some beautiful HTML-based coverage reports.

Want to report on just your model classes? What about controllers? Easy enough:

rake test:units:rcov SHOW_ONLY="app/models"
rake test:units:rcov SHOW_ONLY="app/controllers"

Delightful. Now I’d be set if only rcov integrated with Zen’s autotest to display a coverage report that automatically updates every time I change some code. One other minor nitpick is that, much as it seems like rake test:rcov should work, it doesn’t. Something else to add to a future release, I suppose.

Are you in a team environment? Hook rcov up to a continuous integration system and catch Jonny slacking off on his tests… a full half hour before the morning stand-up meeting.

For the price, you can’t beat what rcov provides. It won’t tell you if you’re tests are logically correct, but it sure as heck will scream at you if you’re not writing them to begin with.