Apress - Ruby For System Administration

Introduction
It turns out that writing a book is pretty easy. Writing a book that is relevant to anyone but yourself— now that’s far more difficult than I’d imagined. I love the elegance, simplicity, and power of Ruby, and I use it every day to make systems function at the ISP where I work. You would have thought that this combination of facts would make it straightforward to distill a few salient chapters on the matter. It doesn’t. Indeed it took me nearly a month of trying to build a skeleton structure for the book before I realized that the problem was one of context.

You see, the target audience for this book is obviously system administrators, but that’s about as helpful in narrowing the focus as asking a telephone company to connect you to Bob in Venezuela. We are an incredibly diverse bunch unified by a few common traits (if Slashdot is any measure). We are geeky, by which I mean that we love technology and structure for their own sake and get a kick out of problem solving. We always have too many plates spinning and not enough time to tend to them properly. We are asked to do everything from retrieving a lost e-mail to building a bespoke CMS from scratch, and it’s always needed yesterday, such that this sort of thing happens far too often:

It’s 8:52 on Monday morning and Jo comes running in. Before she’s halfway into the room she’s already blurting out, “The MD needs content mirroring on our mail servers implemented by close of business today or we’re all getting sued!” It’s in situations like this that it hits you: who in the name of sanity is Jo, and how does she keep getting past security?

Looking at our jobs from an engineering perspective, the notion of rapid deployment is so deeply ingrained in the daily routine that many if not most system administrators learn an interpreted language in short order. The question is, which one should you choose? I used and trusted Perl for a good few years before I switched to Ruby. The reason I switched was inadvertently summarized by Shakespeare (thanks, Will). While the Bard was talking about life, he might well have been describing any of my nontrivial Perl scripts when he referred to a tale told by an idiot, full of sound and fury, signifying nothing.

Programs should be beautiful, not give you retina-detaching levels of eyestrain. As Eric Raymond put it, “Ugly programs are like ugly suspension bridges: they’re much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code.”

In short, administrators need a language that is as easy to think in as possible, is terse without being cryptic, has a syntax that usually makes the “right” way to build something the same as the “rapid” way to do so, and reads like executable metacode. Let’s face it—these criteria leave only two mainstream languages standing: Ruby and Python. For my money, Python comes very close but only Ruby hits the mark.