Three less-than-obvious reasons why Ruby is the bomb

Instead of putting out “yet another top 10 list” of superficial, syntactical reasons why I prefer coding in Ruby, I thought I’d touch upon a few lesser-mentioned features that I miss big-time since picking up PHP:

Gems – shiny package management

RubyGems is a simple, easy to use package manager that gives you instant access to over 1500 Ruby libraries (called ‘gems’) via Rubyforge. Compare that to PEAR, PHP’s “Extension and Application Repository”, whose official channel contains less than 200 endorsed packages. It works something like this:

gem install rails --include-dependencies

To be fair, PEAR works very similarly, but it lacks one critical feature I’ve come to love with Gems – the ability to manage multiple versions of the same package. You can pick and choose which gem version to load from inside your app (examples below). This makes life much easier if you’re managing a bunch of different apps on the same machine, all with their own dependencies.

gem ‘rmagick’, '>= 1.1.3' # Only use rmagick with versions >= 1.1.3
gem ‘freshbooks’, '= 0.2' # Version 0.2 only

Did you know: There’s a book dedicated entirely to RubyGems.

Otherworldly code style consistency

Rubyists are staunch defenders of coding standards. After a year of developing with the language, I’ve yet to come across a single library or code example that uses either camelCase naming convention, tabs instead of spaces, or non-standard bracket use. It’s not that I particularly care for one set of rules or the other; it’s just refreshing to see the same familiar coding style every time I step into a new piece of Ruby code.

With PHP, you’re never sure what you’ll get. For example, SimpleXML, PHP5’s standard XML library, uses camelCase function names, whereas most “old school” PHP functions side with underscores (i.e. array_push).

Side note: I just discovered Ruby-SDL provides both Ruby-style method names and their C-style CamelCase equivalents, keeping both Rubyists and old-school SDLers happy. Very cool.

Plugins for everyone

Since you can modify existing classes at runtime in Ruby, adding support for extensions or plugins to your applications is trivial. If you’re writing software in PHP, you need to write hooks ahead of time, or else your users will need to modify the source themselves. The worst example of this is phpbb, whose extension system is a series of insert/remove code statements – yikes!

# my_app.rb
class SomeClass
  def some_method
    do_something
  end

end

# my_plugin.rb
class SomeClass
  def some_method
    do_something_else
  end
end

Looking for more?

If this list seems a little short, feel free to peruse the following fanboy articles:

Bedtime reading: Joyent Connector is now open source

Joyent recently open sourced both Slingshot, their toolset/library for developing offline Rails apps, and Connector, an online suite of collaboration tools for small businesses.

The Connector source code particularly interests me. There’s already plenty of great open source Rails projects out there (Beast and Mephisto come to mind), but as far as I can tell, this is the first instance of a commercial Rails application being open sourced, by a reputable organization like Joyent no less. IMHO, there’s no better way to learn Rails than from finished, deployed software, and Connector is no exception: it’s composed of slick, well-written code.

Here’s a look at Connector in action:

PHP certification: proceed to checkout

What is it with the PHP community and their obsession with certification? The Zend company has one, along with a whole submarket of training materials and courses. Cake PHP, the Rails-like PHP framework, also offers their own certification. There’s even the possibility of Drupal certification.

Me? I’m happy with my MUDCRAP diploma.