The Fugue

One of the oldest and most universally useful tools we have is gnuplot. It is also one of the least understood and most underutilized tools we have.

I can hear you now. "What do I need gnuplot for? I don't make graphs." Well that's exactly the problem. Everyone who works with data should be making graphs, and lots of them. Do you write programs that manipulate data? You need gnuplot. Do you want to evaluate performance or traffic on your website? You need gnuplot. Do you want to impress your friends with cool graphs of the growth rates of yeast and bacteria in sourdough or your weight loss and percent body fat? You need gnuplot.

I've been using gnuplot for years. I scraped up enough gnuplot skillz to make basic graphs and it has been invaluable. But I knew gnuplot could do more than I knew how to make it do, and whenever I tried to do something advanced it was only with great pain that I succeeded. Often I failed. Let's face it, gnuplot can be a bear to learn. Why? Well, mostly because of the documentation. Not that there isn't any, almost the contrary. There's a lot of documentation, but it's very much reference documentation. What the world has been lacking is a good introduction to gnuplot that isn't afraid to get nitty-gritty where it needs to, but doesn't just parrot the abundant but obscure documentation that's already out there.

We no longer need to wait. The book is called Gnuplot in Action by Philipp Janert, and it is an absolutely fantastic book. Really, I can't say enough good about it.

Janert walks the fine line between cheesy tutorial and dense reference with the skill of a circus acrobat. The writing is approachable, yet chock full of useful information. Nothing is rushed, but it doesn't plod. The text is sprinkled with beautiful graphs that expand your imagination and open your eyes to the possibilities of gnuplot.

In chapter 2, "Essential Gnuplot", the impatient reader is given a whirlwind tour of gnuplot basics. After just 11 pages you will know everything you need to know for 90% of the graphs you will ever need to create. In fact, you'll know more than I knew when I began reading it—I learned a couple things that I kick myself for never having discovered on my own.

Chapter 3 goes into more detail on dealing with data, and in that chapter I learned a ton. Several of the things I learned in this chapter have saved me numerous hours this semester alone. Chapter 4 picks up the remaining miscellany.

In part 2, all those nagging questions of polish are addressed. This is where I used to spend the most time banging my head against the wall, searching, plodding through various newsgroup threads. "How do I get this or that to look just right?" These types of questions are hard to find answers to in search engines. Janert takes us by the hand and explains each and every question I've ever had and a few I hadn't yet dared to have. Truly beautiful graphs are now within my grasp. What's more, it no longer seems like an exercise in pain but a simple recipe for success. After Janert explains these techniques they seem plain as the nose on your face, yet he's not condescending.

Part 3 dives into the deep dark secrets of gnuplot. 3D plots, color, multiplots, different coordinate systems, fitting, terminals, and a dozen other things you didn't even know that you didn't want to know. No doubt you'll skim this section the first time and come back to it when you need those dark magic tidbits.

Part 4 is arguably the most important part of this book, or perhaps second after part 1. Part 4 is a crash course on graphical analysis. What kinds of graphs you can create, when you should and shouldn't use them, how not to lie with graphs (and how to pick out people lying with graphs), and most importantly, how to go from raw data that you don't understand to organized data that you do understand and have pretty graphs to demonstrate to boot. All with practical examples that you can tweak for your own use.

Finally, there's a gnuplot reference in the appendix. This is a deluxe package and has everything you need to become a gnuplot guru. I am thrilled that this book is coming to dispel the darkness surrounding gnuplot.

I really have no cons to speak of, other than the prerelease PDF I had access to had some minor problems—the sort of problem I would expect to be resolved in the final stages of editing. I don't have experience with other Manning books, but having seen prerelease versions of other books from other publishers I'd say the current copy is par for the course. I'm certain they'll fix those things up and have an outstanding PDF in the end. I recommend springing for the dead tree version though, as I expect the reference at the end of the book and the examples throughout will be more accessible next to your computer instead of on the screen. (You already use quite a bit of real estate running gnuplot and/or editing a gnuplot file and displaying graphs.)

Sorry, one more post on the topic of fitness and fat loss. I picked up ($4 with shipping) and reread Total Fitness in 30 Minutes a Week by Laurence Morehouse, Ph.D. and Leonard Gross, and it's as good as I remembered. For various reasons I didn't follow through with the plan laid out in this book last time I read it years back, but the principles I picked up stuck with me, and influenced my search for my custom and sustainable fitness program. I had a question that I thought was answered in this book, and so I picked up a copy and started reading. I'll give you a synopsis and review, then I'll divulge my (finally) finished custom plan.

First, this book is older than I am (1975). Naturally, that means we've learned some things that Dr. Morehouse (a Ph.D. in exercise physiology at UCLA) didn't know. On the other hand, most of what he did know back then, especially the basic foundation on which the program is based, is just as true now as the law of gravity remains. The book shows its age, but in ways inconsequential to successfully losing fat and/or gaining fitness. Indeed, it worked for people in the 50s, 60s, and 70s and there's no reason why we should be any different now.

And not just any people. Dr. Morehouse worked for NASA on exercise programs for the astronauts. Thanks to him astronauts on extended missions were able to walk (if a little shakily) rather than be carried on stretcher when returning to Earth. Low gravity is worse than sitting in front of a computer when it comes to atrophying muscle.

If I had to boil this whole book down into one paragraph, this would be it: Eat balanced meals, exercise with a balance of simple equipment-free strength training and aerobic exercise 3 times a week for a total of 30 minutes a week, live a bit more actively (take the stairs, etc.), and take note of and respond to feedback to stay on track. To get into shape (generic good shape, not athletic shape), that's all you need. To lose fat, you chart your course of 1 lb a week on a piece of graph paper. If you're above the line that day, you eat a little less (skip that piece of pie or extra helping). If you're below, you eat normally.

The book and method are very straightforward. There's no gimmicks here. It won't get you ready to run a race or climb Mount Everest. There's no confusion here between being an athlete and just plain getting in shape. The book is a little wordy, and could be half as long and just as informative. But that may be because I'd already convinced myself of most of the points he drives home in this book and didn't need the persuasive arguments.

This book is very much along the same lines as the Hacker's Diet I reviewed the other day, except it emphasizes exercise much more (for its own sake, primarily, not as a primary means for losing weight). Both use the simple view: calories in and calories out. Both emphasize the importance of feedback and the realities of measurement. Both give you a sustainable and easy-to-follow program (this one is easier than hacker's diet since you don't have to count calories).

So combining these two books and everything I've read from the web (everything from fat-loss zone heart rate cardio training to the bodybuilder mantra "cardio is useless for fat loss"), I have come up with my own personal plan. Time will tell if it works.

If I'm going to exercise, it's going to be swimming. I told myself that many many times over the years, and I meant every word. So I go swimming 3 days a week. There's my cardio. It's also part of my strength training, when doing intervals. The other part is on the other 3 days when I do some simple equipment-free strength training (5-10 minutes). I'm basing my exertion on the combination of perceived exertion (primarily how hard I'm breathing) and heart rate. I aim for staying aerobic and jumping the lactate threshhold on the hard intervals.

I'm convinced you can't lose weight in a reasonable amount of time without adjusting your diet, unfortunately. The numbers just don't add up otherwise. Every pound of lean mass you add burns some 10-20 kcal a day, and you're a lucky bodybuilder if you can add 1-2 pounds a week. That gets you no closer to burning off that extra pair of twinkies than the hour of jogging. Exercise alone, in the sense of that thing you do for an hour in the morning, is not enough to raise your energy usage enough to create a calorie deficit without adjusting your diet (especially since if you have too much fat you've probably been eating a calorie surplus). No, you have to adjust your diet. That doesn't mean you have to starve, it just means you need to be conscious.

Exercise does, however, apparently act as an appetite suppressant, and it will make you feel better and so you'll be a hair more willing to walk instead of ride, stand instead of sit, etc. Water is apparently another appetite suppressant, and it is important to drink plenty for other reasons especially when losing fat, so drink plenty. If for no other reason than because it fills your stomach partially, water can suppress your appetite if you drink it before a meal. So on my above-line days I'll be drinking a couple glasses before meals.

Dr. Morehouse says not to lose more than 1 lb a week. The consensus on the web is similar, but says 1-2 lb a week. I'm a little too impatient for 1 lb a week, but probably too lazy for 2 lb a week, so I'm aiming for 1.5 lb a week. I shall have lost my goal 40 lb by mid April.

To recap, I'm watching feedback (heart rate and weight) to fine-tune my eating and exercising in order to stay on track for a reasonable goal. No starving. Only the exercise I like. Reasonable and sustainable. Why don't you play along at home?

I’m still swimming. This may be the longest I’ve stuck with any exercise program (excluding things thrust upon me like basketball practice or getting out of bed). Naturally, being the technical sort that I am, I want to make sure I’m using this exercise time efficiently, so I picked up Total Heart Rate Training by Joe Friel at the bookstore (and put it down before I left—reading it over several visits while my son played with the Thomas trains). This is an informative book with lots of information, but it’s not for the weak of heart—literally or figuratively. The book is written by and for obsessive-compulsive athletes (the most common variety is known as triathlete). You have to be absolutely bonkers to follow this book religiously. But it can be useful to the thinking fitness swimmer, with a grain of salt.

The first problem with this book is precision. Not a lack thereof but an overabundance and misunderstanding of it. In physics, or any practical math, you can get in trouble by giving more significant digits than your measurements warrant. You can fool yourself and others into thinking you have more precision than you do, which leads people to jump to incorrect conclusions and make silly and/or dangerous decisions. Heart rate monitors will give you absurdly accurate heart rate measurements. But I posit that you can’t measure how that maps to your body’s metabolism (the zones) with anywhere near that accuracy, at least not while exercising. What’s more, as a swimmer anyway, you can only check the monitor during rests at the end of the pool, where it’s just as convenient to take your pulse with the pace clock (it takes 6 seconds to get ±5 bpm). The heart rate charts in the appencides are what really give it away, though. Running, Biking, Swimming, etc. each have their own 2-page chart with some 60-odd entries on where the zones begin and end, to the nearest bpm. If that doesn’t sound absurd by itself, take a look at this graph I made from the swimming chart:

They say a picture is worth a thousand words. Notice how the relationship is almost completely linear. I’m no exercise scientist, but how much do you want to bet the body is not so perfectly conformant? I bet it varies depending on the day, conditions, what you ate, etc. There might even be some nonlinearities. So we have a chart with a bunch of numbers and no graph, that is overly precise.

That wouldn’t be so bad on its own, but the author actively disparages traditional measures and formulas for being too inaccurate, when of course the reason they are too inaccurate is that they are too precise. The most obvious example is that your maximum heart rate is 220 minus your age. This gives you a bpm, but really it’s only good to within 10 or 20 bpm. He rightly says that this is not accurate. But he says it’s as likely to be way wrong as not, because it’s a statistical measurement. i.e. it’s a bell curve. Hello, 95% confidence of being within 2 standard deviations hardly qualifies as “as likely as not” to be outside. If he really wanted to convince me he would have stated the confidence intervals and said just how far off from that number you are likely to be. Then he would have compared that error with the error in pinpointing the zones in exercise. I think we’d find that maximum heart rate, while not perfect, isn’t as bad as all that.

While being absurdly precise and complicated (to the delight of obsessive compulsive triathletes everywhere), this book is also somewhat lacking in rigor and logic. Besides the examples above, there’s an issue I blogged about previously: the so-called fat-burning zone. As you may recall, the fact is that your body burns more fat per calorie when in an aerobic metabolism. This leads people to call the aerobic zone the fat-burning zone. People get lazy and forget to put in the disclaimer that you have to work longer to burn as many calories, which leads to confusion. Trainers and self-righteous OC athletes retaliate by pointing out that you burn more calories per time unit by working out harder—up into anaerobic, and so “the fat-burning zone is a myth”. Well it’s not a myth, it’s perfectly valid if you’re willing to work out longer. Instead of elucidating the topic with clarity and stating both sides of the issue without bias, the author falls squarely, if not extremely, on the myth side.

Still, there is a lot of good information in here on how the body works, what’s going on in the various zones, in which zones you can best spend your exercise time in order to achieve your goals (the information for a fitness swimmer is in there, if a bit hidden behind the triathlete-like goals). Numbers that are useful if you take into account that they are too precise, etc.

I’ll give you an oversimplified summary of what I learned in the book. Referring to that graph above (by the way, I had no control on which colors were used—they’re just GNUPlot’s default colors), notice that the x axis is the lactate threshold. He claims that LT is a better base point than maximum heart rate, because you can directly observe it without killing yourself. Sounds good to me.

At the border of zones 1 and 2, aerobic respiration accounts for almost all of the energy produced. Aerobic respiration primarily uses fat and is much more efficient, but less powerful, than anaerobic respiration. If you’re fit you can stay in zone 2 all day long.

At the border of zones 4 and 5, enough anaerobic respiration is happening that various easily-observable changes occur, and the exercise benefits change too (especially those related to heart). Oversimply put, training above LT will train for speed in shorter (non-endurance) races, and also do various good things for your heart.

At the border of zones 5b and 5c, almost no aerobic respiration is occuring—it’s all anaerobic. This is because you’re demanding more power than aerobic respiration can keep up with. Anaerobic respiration is done not from fat stores but from stuff stored in the muscles themselves (for immediate access and powerful energy). There’s only so much of this fuel, so you run out of steam quickly above LT, but especially up here. This is sprinting stuff, and you can rarely keep it up long enough to even measure heart rates much into zone 5c.

For me, I am going to aim at increasing my LT and staying mostly in zones 2 and 4, (apparently zone 3 is a waste—little more benefit than zone 2 but requiring a lot more recovery) but doing interval training shooting up into the above-LT zones, mostly for the heart benefits. I figure that will meet my goals best, i.e. I will enjoy the exercise more and not leave the pool exhausted, I will burn more fat per calorie, and the interval training will give me enough edge to keep things interesting and improve my cardiovascular health (not to mention increase LT—doing intervals with sufficient rest to “cycle” the heart rate from low to high and back to low is one good way to do that). And I’m going to do it by taking my pulse with the pace clock periodically, and paying attention to how my body feels and how hard I’m breathing.

Of course, the most important thing is to keep on just doing it, and that’s going well because I’m enjoying learning the Total Immersion swimming method, and I’m finaly getting into the more interesting drills. It won’t be too long until I graduate to swimming again, at which point I’ll review that book. I’m looking forward to seeing if I can swim a 500m in under 10 minutes with ease. That’s something I had to do regularly as a lifeguard and even though I was more fit then (or at least less fat) I always struggled with swimming 500m non-stop, and my times were usually 10-12 minutes. If I can swim a 500m with ease in under 10 minutes in my current shape, it will be a testament to the TI method. Stay tuned!

This is a casual review of the seventh Harry Potter book, and to a lesser extent the entire series. Spoilers herein, so don't follow that "read more..." link unless you've read it.

First I'll say that I have enjoyed reading the books and watching the movies. They're good entertainment. I remember as a kid reading some childrens books about (good) witches and wizards at school—basically the same premise as this series. I don't remember what they were other than the protagonist was a little witch with chronic bad hair or something. (Gee, no matter what I do I can't seem to describe this without implying that Rowling lifted the idea, which even if she had doesn't reduce the originality or legitimacy of the Potter series in my eyes). It was and still is a wonderful premise. I think that I like the premise so much because what I love in a story more than anything else is new and complicated familiarity. Magic school: new. How the magic world and the real world coexist: complicated. School kids with normal school kid problems: familiar. Oh, and I'm a sucker for anything British.

On the other hand, there were a number of things about the Potter series in general that just did not work for me. I found the constant abuse of literary devices tiring, annoying, even insulting. Snape good, Snape bad (but over the entire series the Snape line was excellent). Lupin bad, Lupin good. Sirius bad, Sirius good. Perhaps the most sickening instance of this is the shrieking shack scene where Sirius and Lupin are talking about Pettigrew but Harry thinks they're talking about them. This is not how people do things—even people as distracted as Sirius and Lupin were are not going to say things that sound so blatantly threatening to Harry in front of his face without at least mentioning in passing "Oh by the way, Harry, we're not talking about you. We'll explain later." This came off particularly badly in the movie. I do not like my chain being yanked for emotional effect. I like emotional responses that are earned. That's my biggest beef with the whole series.

That said, I can happily report that chain-yanking has been kept to an absolute minimum in this book. Although there are several reversals, there is very little chain-yanking. Reversal itself is not to be abhored, just its abuse. The one exception is some gratuitous killing. I accept that fighting evil can have casualties, and not every agreeable character can or should survive. But I think the members of the Order would be more likely to survive in an all-out battle situation like we had in this book, yet many die. Disproportionately many, I think. But really, I'm just mad that Fred had to go, probably because the Weasleys, and Fred and George in particular, are my absolute favorite characters, and killing Fred is in essence killing both Fred and George. George goes on alone (and monophonic), but he would have to completely reinvent himself without his twin. Had he died doing something important, or even something characteristically Weasley, it might have been ok. But he just keels over in impersonal crossfire, and you know that it's just Rowling yanking chains again. That's not the kind of emotional response you want—you don't want your readers blaming you for killing off their favorite character; you want them mad at the villains for doing it.

Now you know what I like and don't like about the series in general. I found this book to be a very good read. I missed Hogwarts and the other children and teachers, and seeing them in battle at the end did little to assuage that. But I can't really kid myself into thinking Harry could go to Hogwarts and be safe, so it's fine. Ron leaving was silly, doubly so when the chain was yanked that he'd have come back right away if it hadn't been for those pesky bounty hunters. Harry wasn't as insanely stupid as he has been in the past, though there was a bit of that with the attempted chain yanking about Dumbledore. The whole Dumbledore thing was interesting, in spite of knowing she was trying to yank Harry's chain, if not our own. Character depth and motivation can be very interesting, and it's nice to see some more depth to Dumbledore.

I might be cynical, and of course I recognize this is a children's book, but can we really be expected to believe that Ron and Hermione would be together 24/7 and sleeping in the same tent and never so much as tell the other his or her feelings for several months? I was glad to see them finally figure it out, and I know teenagers can be confusing and confused about that sort of thing, but in my experience if you throw any 2 teenage boys and a girl in a 24/7 alone situation for a few months, someone's going to fall in love (or get a crush, or whatever). Still, I felt it was handled well, with Ron implementing what he learned in the book and Hermione crying and being mad when he returned. Aside from the slow pace it was fully believable and a good culmination of the romance. Harry handled the Ginny situation pretty well, too. At the end of the last book his decision to cut it off felt dumb and pointless, but it made sense in this book (and could have been left for the birthday scene here, but she probably just couldn't resist yanking that chain at the end of book 6). I wish they would have wrapped it up at the end though. 19 years later, "Oh by the way they're married" doesn't have quite the same drama.

I still remember when I first realized that Star Wars was really about Anakin, not Luke (before the prequels). The whole thing instantly took on a new and deeper meaning, and it was thrilling. In a similar vein, this whole series may almost be as much about Snape as it is Harry and Riddle. The reversal in Chamber of Secrets where Snape was supposedly the bad guy but ends up being the good guy was dumb, but otherwise the complexity of Snape and never knowing what his motivations and loyalties were was very interesting. It all comes to a heroic and satisfying end in this book, and all in all I'm more pleased with the Snape storyline than any other. However I do wish we'd had more Snape exposure in this book. He, even more than Hogwarts and the kids, is just a backdrop. So much more could have been done with him, but as so much already had been in previous books, it's not so bad.

So there you have it. A few days after I finished reading it, and the most salient thoughts that come to mind are that I enjoyed it, I plan on reading the series again (probably with my kids), and she really shouldn't have killed Fred off.

Oh, and I almost forgot. I really despise the Americanization of these books. Next time I read them, we will have bought the original British edition.

I love Ruby, and I use it whenever I can for all kinds of tasks. When I was working as a professional system administrator, I put it to good use a few times there too. But using ruby always left me feeling a little guilty, because whoever came after me would probably curse my name for using a "nonstandard" language. It didn't help that Ruby was rarely installed, if even available, by the popular server distributions of the day. But all that has changed in the past two years, and using Ruby is often acceptable even in the conservative world of system administration.

You can imagine my interest then, in a book titled "Practical Ruby for System Administration" by André Ben Hamou. The title is telling; Ruby is known for being recommended by The Pragmatic Programmers because, well, it's a pragmatic language. System administration is all about pragmatism, above all else. Doing things right is important, but doing them now is more important. I knew all along that Ruby was an excellent tool for the enlightened sysadmin; now there's a book to back me up.

The book starts out with why you would want to use Ruby, and nips the counterarguments in the bud. Hamou does a good job on both counts, though as I already know Ruby I can't say whether the language introduction is sufficient of its own accord to get started with actually writing Ruby, or whether you'll need to refer to other sources (which are available online).

In chapter 2 he discusses one-liners. One-liners are the staple of many sysadmins, but I never fell for them. I'd rather write a throwaway script than try to cram it all on one line, or if it can really be done well on one line it can probably be done even more concisely with shell script and UNIX tools. However, the chapter does discuss a lot of fascinating switches that the ruby executable takes. I can see myself using many of these, and I was ignorant of most of them. You might learn the same from a careful study of the man page, but Hamou presents it in an easier-to-digest format. It's not always easy to inject humor into a book while maintaining concise brevity, but Hamou does a decent job of that. I found myself laughing aloud more than once, and yet I feel that the book is concise enough to serve as a reference, and that the jokes won't get annoying after a few readings of a section.

This book is not only a great book for the sysadmin hoping to use Ruby, but also an excellent book for any sysadmin who may not even be interested in Ruby. Although not even pretending to be a book on system administration best practices, there are many gems in here that will leave you saying "Why didn't I think of that?" and "I really need to implement that. It will be so helpful and it's astoundingly simple to do with Ruby!"

Chapter 3 gives you not only a quantitative feel for the speed of Ruby versus other performance-oriented languages (i.e. C), but it teaches you when to be concerned with execution speed, when to be concerned with implementation speed, and makes you think twice about your own feelings about performance. "Ruby is slow" is one of the favorite counterarguments against Ruby, but it's rarely a good one. This is even more true in system administration, where the sysadmin's time is much more important than whether the script runs in 1/10 second or 3 seconds.

Chapter 4 discusses "metaprogramming". I found myself at odds with Hamou most in this chapter, but it was all academic differences in terminology. He's fairly sloppy with the term metaprogramming and other terms (e.g. "macros") in this chapter, but the content is nonetheless a useful and vital part of making the most out of Ruby. I even learned a thing or two. He discusses domain-specific languages (DSLs) in Ruby, but mostly at the level of recognizing one when you see one. I think the world needs a paper or book on rapidly making your own DSLs, something sysadmins could really leverage if it were truly easy to do. I've written a DSL in Ruby, and while easier than I could possibly have imagined it's still not at the level of "easy and completely generic" that I feel DSLs can one day reach.

Chapter 5 is where the fun really begins. With the basics of the language under our belts we can really look at specific examples. This is where the book really shines, both as a tool for applying Ruby and as a minefield of good sysadmin practice. We learn to read and write files, with examples for the most common ones. I don't mean we discuss IO.open and IO.close in detail, I mean we talk about the concepts that apply across all kinds of file reading/parsing and generation, including issues of locking.

In chapter 6 we explore the storage and retreival of data, in a variety of approaches including inspect, marshalling, YAML, and ActiveRecord. Most interesting to me was the section on memcached. I think he ought to also have introduced SQLite (perhaps in the context of ActiveRecord) and DRb.

Chapter 7 is dedicated to dealing with "enterprise data". You know that of which we speak. XML, CSVs, protocols like XML-RPC, SOAP. Most valuable to me in this chapter was a coherent discussion of what REST is (finally!) and how to do it in Ruby.

Chapter 8 discusses network, including writing simple clients and servers. One tendency Hamou has in this book is to use pure Ruby and steer clear of system and backticks. This tendency sticks out in this chapter, where much time is spent discussing that which could be acheived better with a shell script, or at least a Ruby script with judicious use of system or backticks. The general argument for doing things in pure Ruby is portability, and to a lesser extent performance. Neither of these is the first concern of a sysadmin, who is generally not going to write a script that must work on more than one platform (even if it runs on several different Linux/UNIX distributions, which have the same GNU tools).

Chapter 9 deals with that task which we all hate: network and log monitoring. He has some gems of wisdom herein, but all in all we're left feeling about the same as when we went in: we can do it (now we can do it with Ruby) but it's a pain. The gains are not as great here as they are in other areas. This isn't Ruby's fault, nor Hamou's, it's just that nobody's really come up with a good and general way to attack this problem yet.

Chapter 10 discusses RubyGems. I think it's fitting that such a chapter be at the end of the book, and that's all I have to say about that today.

Chapter 11 discusses testing. You should do it in some form and he discusses a few forms. Nothing earth-shattering here, from where I sit. Chapter 12 talks about the future of Ruby, and will probably cause you to salivate.

All in all, an excellent book on using Ruby as a sysadmin. Go ahead, come out of the closet. Ruby is not only OK, it's often the best choice.