Why Ruby is a Good Fit for the Enterprise
The head of technology at an enterprise software company, Coupa Software, tells eWEEK why Ruby is enterprise-ready.
The Ruby scripting language has drawn its share of both proponents and critics. However, Coupa Software, a spend management company that offers a cloud-based suite of financial applications, has standardized on Ruby as its development language of choice. In an interview with eWEEK Senior Editor Darryl K. Taft, David Williams, vice president of technology at Coupa, spells out why Ruby is a good fit for Coupa's enterprise offerings.
Why is Coupa primarily a Ruby and Rails shop?
Rails was the best functional and philosophical fit for what we were aiming to do when we started out in 2006, and it has scaled well with the company. Functionally, we fit the mold of a three-tier model-view-controller (MVC) Web application backed by a normalized relational database, and all of our integration with legacy systems is arms-length rather than at the database level. Given that, we fit the assumptions inherent in Rails' design, and, like any framework, Rails works best when the problem you're trying to solve with it matches what it's designed for. Rails wasn't the only MVC Web framework around at the time, however, so other factors came into play, particularly the philosophy around it and how well the tradeoffs matched what we needed. For us, the choice was mainly between Ruby on Rails and a couple of different frameworks written in Java. Rails' principles of "convention over configuration" and "don't repeat yourself," combined with the "magic" made possible by Ruby's dynamism, meant that with Rails we could build more features faster with fewer developers and less code. Since our whole tech stack was open source, and there weren't that many layers, if there was a problem that cropped up anywhere we could debug it quickly and fix it ourselves. We found that we were writing about one-tenth of the code that we'd need to write to do something similar in Java, and having less code to start with, meant that it was inherently easier to maintain.
I've heard you say that Ruby makes you happy as developers. Why is that? What is it about Ruby that makes you happy as compared to other languages.
Although Randall Munroe may have compared LISP to a light saber in one of my favorite xkcd comics (http://xkcd.com/297/), I feel like Ruby also fits. It's versatile; besides using it for our applications, I use it for shell scripts and one-liners that I might've used Perl for in the past. It's elegant—for example, blocks of code are first-class objects, and there's none of the primitive type vs. object and auto boxing/unboxing of Java. It's concise and expressive, in that it tends to read like English and isn't weighed down with excessive punctuation. It's extendable, both in that it's open source and in that it's easy to dynamically generate your own code or modify pretty much anything. Less concretely, when it surprises you, it tends to be for the better, meaning that as a developer you spend more time and energy on the problems you care about and less on catering to the language's own needs.
You also noted that your Ruby project is fairly large. What is considered large for a Ruby project? If you continue to grow, will that tax the system? What can you do to account for scale?
I haven't found any reliable statistics, so I can't be specific in terms of percentiles, but anecdotally, we're among the larger fairly monolithic Rails apps out there in terms of lines of code (more than 100,000) and number of instances (more than 1,000). The Rails framework popularized the Ruby language here in the US, so while I'm sure there are some large non-Web applications, most of the Ruby applications I'm familiar with are Web apps using the Rails or Sinatra frameworks.
Originally published on eWeek.