Don’t assert when you mean to assert_equal

Pop quiz: which of these test assertions will pass?

    assert true
    assert true, true
    assert true, false
    assert true, 'false'
    assert 'true', false
    assert 'true', 'true'
    assert 'true', 'false'

You might be surprised to learn that every single one of these assertions pass successfully. From the documentation, you can see that assert() takes 2 arguments: a boolean and an optional message. In each of the above cases, you’re passing a true value as the first argument and then an (unintended) optional message.

What you probably meant to do is use assert_equal(). This method takes 3 arguments: 2 boolean values and an optional message. This is the one you need when you intend to compare 2 values against each other.

[RubyConf 2007] Evan Phoenix – “Rubinius”

John Lam from Microsoft started off the day talking about IronRuby.  I have a ton of respect for John, but I thought the talk was lackluster.

Charlie Nutter and Thomas followed up with a great JRuby talk.  Lots of technical detail, especially surrounding their focus on performance optimizations.  JRuby is looking really great, and I expect it to broaden Ruby’s footprint in Java-entrenched enterprises significantly.  Badass.

Evan Phoenix then totally rocked the house with his talk on Rubinius.  Yes, he was a witty guy with a great presentation style (highly conversational).  Yes, he had some clever slides.  He totally shone, though, in the Q&A…

This guy is crazy smart.  I guarantee that some of the geeks in the room developed their first man-crushes on hearing how he borrowed “spaghetti stacks” from Smalltalk to trivialize continuations.

All in all, the level of technical detail he got into was *awesome*.  I think his mastery of the topic and his passion for the project was felt throughout the room; I’m totally excited now about Rubinius and will be following it’s progress closely.

[RubyConf 2007] Marcel Molina: “What Makes Code Beautiful?”

Great first talk from Marcel Molina. The net:

There are 3 components to beauty:

• proportion (relative size of parts),
• integrity (does it suit its purpose?), and
• clarity (is it simple/clear?).

Apply these principles to software. Good software = beautiful software. Code built to accomplish the task should be proportional to the size of the task. It should be concise while being readable.

Fortunately…

Ruby is optimized for beauty.

• Try to imagine better modes of expression.
• Violations of beauty rules reveal mistakes.
• Do that enough and you will innovate.

Highlights:

• 9:54 Marcel slide-bombs the conference with a pic of someone afflicted with hand gigantism. On-topic, interestingly.
• 10:15 In response to a question from the audience: “Please reiterate. I have no idea what you are talking about.”

Stylistic note: Marcel indents all private methods one additional level to offset them from the rest of the file. Interesting.