Our Code Is in 15% of Rails Applications (Roughly)

New Relic just posted some basic statistics on the Rails applications they monitor. They include lists of the top Ruby gems and top Rails plugins installed for each application they monitor. Patrick and I were delighted to discover that our ActiveMerchant code contribution is installed with 15% of Rails applications. We wrote the code for SandwichBoard and Patrick continues to improve upon it for LivingSocial Daily Deals.

Whether or not those 15% are actually using our code for Authorize.Net ARB or CIM credit card charging is unclear; but, it’s cool to know your code is installed with that many applications.

Ruby Method to Block (Lambda)

In Ruby on Rails development, I have been known to use symbol to proc. Recently, I needed to re-use a method as a block.

Here’s a contrived example of what I was doing:

Group.all.sort {|a,b| a.name <=> b.name}

However, I wanted to re-use this sort and ended-up refactoring it to:

def group_sort(a, b)
  a.name <=> b.name
end
Group.all.sort {|a,b| group_sort(a, b)}

Although this allowed me to re-use my sorting mechanism just fine, it seemed verbose. I was able to be succinct by using a lambda like so:

group_sort = lambda{|a,b| a.name <=> b.name}
Group.all.sort &group_sort

(Using a lambda may be obvious to Ruby pros, but I’m not there yet.)

Testing Rails Exception Notification in Production

Every Ruby on Rails project I have been involved in has used the Exception Notification gem. It sends you an email with very helpful debugging information whenever your application breaks in the real world. However, I’ve seen people fail to ensure that it actually works in their production environments–not when they first launch their site, but weeks and months afterward when it really matters. If your production environment changes, your application may fail, but you might not get an email about it because that which broke might have affected email sending. And you’ll think everything is honky-dory. Make sure you have something like this in your application and that you test it periodically to ensure you’re getting exception notification emails.

In config/routes.rb:

  map.connect 'test_exception_notifier', :controller => 'application', :action => 'test_exception_notifier'

In app/controllers/application_controller.rb:

  def test_exception_notifier
    raise 'This is a test. This is only a test.'
  end

I also recommend adding this to a periodic test script and your deploy script so you don’t have to remember to test it.

Rails Refactoring and Deprecation

I’ve been using Ruby on Rails exclusively for over a year now, but have used other web frameworks for longer periods of time (classic ASP, ASP.NET, and J2EE). Rails is unique in many ways, and if look hard enough online, you’ll find its qualities spelled-out for you.

Deprecation is one quality that isn’t spoken of much, but it’s one of my favorites. The Rails core team is adamant about doing things the best way possible. When it sees a better way of doing things, it immediately starts removing parts of the API that don’t meet that standard of perfection. Developers offload deprecated functionality into plug-ins that give teams time to migrate aging code, but the deprecated code doesn’t stay in the main code base for long.

The other frameworks I’ve used have kept deprecated API calls in for extremely long periods of time. Some I don’t think will ever disappear. These other APIs allow developers to continue using inefficient, poorly-designed, and overall bad code however long they want.

Rails isn’t simply doing things the best way possible, it trains its developers to do the same. I like that.

A Demonstration to Remember

A went to Ruby East a little over a week ago with Patrick. We heard several good talks about Ruby and Rails and thought the conference was well-worth the money we spent to attend it. The most valuable presentation for me really wasn’t a presentation at all; it was a demonstration.

Giles Bowkett didn’t put us through an hour of slides. Instead, he spent the time walking us through and demonstrating his .irbrc–his Rails debugging tool set. For those unfamiliar with or new to Rails, Rails has an interactive Ruby shell console called script/console where you can execute arbitrary lines of Ruby code to debug Rails applications. Each time the console is launched, initial settings and functions are defined by one’s .irbrc. His contained many useful tools and hacks, the details of which I will leave to the reader to discover. I just wanted to publish something referencing it since it is so good.

(You can read Giles’s thoughts on his own talk too.)