I. What's The Big Deal?

If you know what Ruby is, you know it's just a programming language.

If you've used Python, Perl, Java, Lisp, Javascript, or a laundry list of competing languages, you may be of the opinion that there's nothing all that special about this red gem. And in some ways, you'd be right.

II. I Am?

Ruby's most well-known progeny is a web framework called Ruby on Rails. When Ruby on Rails hit the scene in 2005 (ten years after its debut in 1995), Ruby exploded in popularity.

Rails had tools like ActiveRecord, a database interface called an object-relational mapping layer, or ORM. ActiveRecord allowed programmers to treat database queries as objects, simplifying thought processes and helping to crystallize the embrace of the Model-View-Controller architecture for the web.

I learned Ruby thinking that I would primarily apply my newfound knowledge to web application design. I count myself as extraordinarily fortunate that my fate lay in another direction.

III. Not A Rails Fan, Then

It's not you, Rails. It's me. You drew me in with your shallow learning curve and copious videos on the internet showing me how you worked. I embraced your convention-over-configuration philosophy, and enjoyed the generators and bootstrap scripts that allowed me to go from zero to CRUD application in moments with Heroku.

At some point, we just drifted apart. The tasks I needed to solve were less web-oriented and more systems-oriented. The constraints I had to work within became less restrictive along some axes (server environments can be consistent in a way that web browsers usually aren't) and more restrictive along others (building applications with tons of dependencies makes them brittle and insecure.)

IV. Wasn't This Essay About Loving Ruby?

Rails is fine and well for what it is. These days, however, I'm much more likely to reach for Sinatra and Sequel when I'm putting together a project that absolutely has to have a web interface or a database.

Ruby's main advantages to me are that it is very pretty, making coding in it a joy in itself; that its hybridized form gives me some of the best of both the Object Oriented and Functional Programming paradigms' shorthands; and that the Ruby community have embraced the Unix Philosophy: build tools that do one thing, and do them well. (I'm looking at you, Sequel and Sinatra.)

Most of the time, I'm building things out of smaller pieces than I used to. I'm relying on Ruby's core libraries more than the RubyGems ecosystem. I like to think I'm becoming a more capable and better-informed programmer. Without question I'm a better systems administrator.

IV. A Library By Any Other Name

Much as I avoid dependencies, dependency management is a necessary and important part of any serious programming project. It's here that Bundler really shines. The Gemfile contains a list of the dependencies your project needs.

Then you run bundle install and two important things happen. The first is that the dependencies listed in the Gemfile all get installed. The second is that a new file, Gemfile.lock is created. This new file serves an important purpose: it version locks the project. That is to say, every dependency's version is recorded so that so that when the finished code goes into production, updates to the dependencies can be reviewed before they introduce potentially-breaking changes.

Ruby's community is very Git-aware, and the commitment to version control shows here. The Gemfile.lock file is designed to be tucked into version control, a reproducible record of the developer's success while building and testing the project.

Gems can be installed and configured manually and on a per-user basis, just as with other software libraries. The amount of groundwork the Ruby community undertook is not to be underestimated, however. RVM, the widely-beloved Ruby Version Manager, can maintain separate named gemsets for different projects. With rvmrc files, project-specific gemsets become easy to maintain in development or production. RVM's list of recommended software is an excellent read that really brings home the synergy (ugh I said it again) that Ruby gems have.

V. What Do You Even Do With It Though

These days, the majority of the code that I write is for maintenance or deployment with Chef. Chef consists of configuration management software and a Domain-Specific Language (DSL) specialized for things like package installation, file configuration, and service management. Those tools enforce a model, making it simple to convert infrastructure to code, thereby making it reproducible, easily-modifiable, and prone to automation.

Ruby also has excellent REPLs; Pry is a featureful REPL that can be invoked from within one's script, and the default REPL, IRB is no slouch either. It's really nice to be able to take any given snippet of code, test drive it, customize it, and drop it right back into a script.

Combine that with tmux and Vim, and you have a heady brew for a systems engineer looking for a great way to manage a bunch of Linux servers. My workflow is pretty, I am happy, and I find it easy to reason about the problems I work on for a living.

VI. I Couldn't Have Done It Without You

What more could I conceivably ask for? Thank you, Yukihiro Matsumoto. You have enriched my life immeasurably. As have you, _why the lucky stiff.

May your beards grow ever-longer.


# In fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters.

-Yukihiro Matsumoto