Why not YAML?

In a comment on my post about fixtures, Alistair Holt comments that it’s really not that hard to learn YAML. True enough. But as I replied there, I want to err on the side of picking fewer tools and learning them with great depth, rather than knowing a little bit about lots of tools.

For example, here are a few tools I feel intermediate or expert in, and tricks or gotchas I’ve picked up over the years:


select * from users order by (first_name = 'Francis') desc limit 10

will select up to 10 users, first by putting all users named Francis at the top, and then filling in with other records if there are less than 10 Francises in the table. That’s because booleans can also be evaluated as integers, as in an order clause.


You can press Ctrl-R at any time which will give you a search through your recent history, and hit Enter to execute the command you find. For example, if you recently did git rebase origin/master, you can type Ctrl-R-r-e-b-a-s until it finds the command. Assuming of course you don’t have a lot of other rebase commands in your bash history. You can also hit TAB to dump that command into your command line, and then edit it before hitting Enter.


<a href="http://www.search.com/?q=foobar&lang=en">foobar</a>

validates as HTML, but not as XHTML. This is because that & is a reserved char in XML, and the correct way to escape that is

<a href="http://www.search.com/?q=foobar&amp;lang=en">foobar</a>

I think all browsers unescape that by default, and will send you to http://www.search.com/?q=foobar&lang=en when you click on that link.

Ruby regular expressions

You can delimit Ruby regexes with %r and any delimiting character (|, [], :) instead of using /. This comes in handy for example if you’re regexing a URL, so instead of

str =~ /http:\/\/www.mysite.com\//

you write

str =~ %r|http://www.mysite.com/|

And regexes are objects, which comes in handy sometimes:

matching_regexes =
    [ /this/, /that/, %r|http://www.mysite.com/| ].select { |regex| regex.match(str) }


If you’re using either of these formats in a systems integration sort of way, you have the initial vs. incremental problem, in which you’d ideally have one way to first sync 6,000,000 records, and then a way going forward to add one or two records as they come in. At Diversion, we’ve followed the cue of the Feed Paging and Archiving RFC, which recommends simply putting next and previous links in the header of the document:

<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Example Feed</title>
  <link href="http://example.org/"/>
  <link rel="self" href="http://example.org/index.atom"/>
  <link rel="next" href="http://example.org/index.atom?page=2"/>

This way, whoever is downstream doesn’t need to know anything about your pagination scheme. They just save a link and hit it the next time. There are a few edge cases when you do this sort of thing (I keep meaning to write it up more fully), but it’s been pretty good for us overall.

Ars Longa, Vita Something

The point of this is not to prove to you that I’m a hacker genius and that you should do everything I say. I’m not, and you shouldn’t. It’s just to point out a few things that I wouldn’t know unless I had spent a lot of time with the tools in question.

And there are also a number of tools that I’m sort of noobish about: Git, Javascript, CSS. More time will make me better with those, of course. But it’ll help if I’m not distracted by other non-essential things.

So when it comes to new tools I run a little conservative. Sometimes it works out to my detriment. I was late to the Git party, but now that I’m using it, I’m a little annoyed at myself that I didn’t start using it six months before. On the other hand, I didn’t spend any time learning Erlang, or wrestling with the Rails implementation of REST, and I feel fine about that stuff.

Let’s say you know a butcher down the road. People tell the butcher that he could expand his store into more of an overall grocery store, but maybe he just wants to focus on being a great butcher and doesn’t want to bother with all the trouble of figuring out what breakfast cereal people want to buy. What would you say about that butcher? Maybe you’d say “He’s a sap, he’s missing out on all this other business”. Or maybe you’d say “Motherfucker really knows how to cut beef.” Me, I’d probably say the latter, though I might be concerned about his business anyway.

YAML: good, but maybe not great

So back to YAML: The main reason I’m not crazy about it is because I don’t see any big problems that it solves for me, or for the majority of Rails programmers, that are worth the trouble of memorizing one more syntax. Yeah, for database config it’s slightly more terse than just writing a hash in Ruby. But I don’t think that’s worth the trouble. Then if I want to, say, repeat a DB config, there’s a way to do that in YAML, but I can never remember it. If the DB config was just a Ruby array of hashes or whatnot, I could do that in my sleep.

There are some special cases where I could see a strong case for YAML. If you’ve got non-programmers who need to edit config files for some reason, they’ll have a much better time editing YAML than Ruby. Also, if you’ve got some side tools that can’t dig into the Rails environment for whatever reason, and maybe they’re not even in Ruby, then YAML’s good because it can be parsed by other languages as long as you don’t get too crazy with its object marshaling magic.

But in general, I’d rather have Ruby configuration, like what Adam Keys describes as a replacement for database.yml in Rails:

config.active_record.connection.configure do |db|
  db.adapter  = 'mysql'
  db.encoding = 'utf8'

Seems to me that if you’re a computer programmer, you want to pick one Turing-complete language that you use for, say, 90% of your work. For me, obviously that’s Ruby, though who knows, in ten years, it might be PythErlang 5.1. Whatever it is, I’d rather look at many problems using that language unless the language is completely wrong for it. Ruby might not be the most optimized way to express database configuration data, but it’s close. And if it comes down to a choice between writing some completely concise YAML, or writing some Ruby that’s maybe got 5% more keystrokes, I’m going to write Ruby. Ruby’s my main thing and I want to keep writing that as much as possible, if for no other reason than to continue the process of imprinting Ruby syntax into every nook and cranny of my brain, ‘til I see Ruby in my sleep and use it to write my diary. Well, maybe not that far, but you get the idea.

blog comments powered by Disqus
Tagged: ruby

« Previous post

Next post »