Feature

You Used Ruby to Write WHAT?!

Deciding when to use any language--including Ruby--depends on the appropriateness to task and the amount of yak shaving necessary. Zed Shaw explains when Ruby's MRI or JRuby is the best language for the job, and when it really isn't.

What Ruby Makes Easy...and Hard

The original Ruby is called Matz Ruby Interpreter (MRI). It is a classic interpreter, similar to Perl, but it doesn't use any byte code as do Lua, Python and Java. MRI is written mostly in C (too much C for some) and is the gold standard in the Ruby world. With the MRI, some tasks are incredibly easy to do, and some are insanely difficult.

Systems scripting and automation. Ruby has the same capabilities as does Perl for regular expression processing, file crunching and system automation. Ruby has the added advantage in that its syntax is more impervious to obfuscation. That's not to say a rogue sysadmin couldn't craft something heinous, but you have to try to do something evil in Ruby. Perl developers have to try to write good, readable code. MRI also starts up quickly and uses fewer resources than JRuby so it's more suitable for short-lived cron jobs, long-running monitoring and other system-management tasks.

Web programming, sometimes. Ruby on Rails (RoR) is the latest silver bullet for Web programming. Hopefully, you know about RoR and are evaluating it for a future project. RoR is potentially a huge cost-saving framework for developing Web applications. Complex applications are measured in thousands of lines of code rather than 10- or 100-thousands of lines. Advanced JavaScript libraries and hundreds of active developers building cohesive components also make it much easier to build low- to medium-complexity applications.

The caveat on Ruby for Web programming is that Rails is better suited for building Web applications. I've seen many projects attempt to create a WebDAV server or a content management system (CMS) with Rails and fail miserably. While you can do a CMS in Rails, there are much more efficient technologies for the task, such as Drupal and Django. (In fact, I'd say if you're looking at a Java Portal development effort, you should evaluate Drupal and Django for the task instead.)

Simplified APIs for nonexperts. Ruby's main strength is metaprogramming. You can make little languages (domain-specific languages, or DSLs) that don't look like Ruby. In the hands of an expert, this can turn future problems into simple implementations. (However, in the hands of an idiot, this can kill a project dead, so read my caveat against this later.) Ruby on Rails is in fact built like this, as more a DSL for doing Web applications.

Gluing C APIs together. MRI has a very good C binding API, and newer Ruby VMs like Rubinius will make this even easier. I've developed full wrappers to many complex C libraries in a few days. These C bindings have an object-oriented design and handle garbage collection with little fuss. It's trivial to take parts of a Ruby application that don't perform well and move them to a small C library, and using a system like Ruby2C or Ruby Inline, you can do this almost on the fly.

Prototyping network protocols. Ruby is a "good enough" language for writing simple servers and clients because of its simple threads, multiple I/O event libraries and protocol libraries for network protocols, including HTTP, SSH, SMTP and many others. It's also relatively easy—thanks to Ruby's very nice string handling—to create complete protocols in a short amount of time. When combined with advanced parsers like Ragel, you can make the protocols very robust for the majority of use cases, and then switch to C or another language for the heavy lifting.

However, Ruby's I/O, garbage collection (GC) and threads suffer from serious design flaws and performance problems.

Deploying Ruby in any IT department is also a painful experience because of its open-source nature, but see below for why that's more of a social problem.

Web application testing. Among Ruby's strengths are the tools that help a development team make sure the software runs as designed. Two Ruby libraries, Watir and Selenium, automate testing a site's user interaction. Combined with a test automation system like RSpec, Watir can produce complete reports of each test case and failure output, and write the tests in a nice readable format.

Telephony applications. Jay Philips has a framework called Adhearsion that gives you an amazingly slick syntax for the Asterix telephony platform. Using Adhearsion, you can write very complex yet clean telephone-based applications; you also can connect them to Web applications, databases and anything else Ruby can talk to. If you're doing any telephone work, it's worth the few days' time to try out Asterix and Adhearsion.