Matt Blodgett

Code Samples From "Programming Ruby" That Made Me Stop, Look Up At the Ceiling, and Sigh Longingly (Part 2)

CHAPTER 4. CONTAINERS, BLOCKS, AND ITERATORS

PAGE 49

def with_title(title)

@songs.find {|song| title == song.name }

end

Code Samples From "Programming Ruby" That Made Me Stop, Look Up At the Ceiling, and Sigh Longingly (Part 1)

CHAPTER 4. CONTAINERS, BLOCKS, AND ITERATORS

PAGE 44

a = [ 1, 3, 5, 7, 9]

a[-1]    -> 9

a[-2]    -> 7

a[-99]   -> nil

IronRuby Caveats

Here are a couple caveats to keep in mind if you're following along with the "How do I get started?" screencast from the official IronRuby site.

1. Use Debug, not ExternalDebug

Near the 1:50 mark, the presenter switches the build configuration to "ExternalDebug" before (re)building the solution. This didn't work for me, as all six projects were skipped every time. I tried a few different build configurations and eventually discovered that the "Debug" configuration worked just fine.

2. No local variables in the console

At around the 2:40 mark, the presenter executes a few simple lines of code in the IronRuby console (rbx) just to show that the build is functional. The only important thing to note in those lines of code is that they're using local variables. It turns out this capability was a temporary hack that the IronRuby team removed shortly before RubyConf 2007. If you're playing around in the console, just use instance variables (like @x) or global variables (like $x).

TDD as Part of Your Marketing Pitch

I just finished listening to my coworker, Chris Woodruff, interviewing Josh Holmes at CodeMash 2008. It's a great interview (if a bit too long, honestly).

One of the things that really grabbed my attention was when Josh mentioned an acquaintance who includes an absolute commitment to test-driven development as part of the marketing message from his consulting company. This acquaintance proudly makes known that all builds at his company automatically fail if the test coverage is less than 100%.

I've heard that before (actually, from a local competitor of ours).

I can't help but think: wouldn't it be fantastic if we could include an absolute commitment to quality, backed by TDD, as part of our marketing message? Competitive advantage, anyone?

Get Your Yegge "Thumbs Up!" T-Shirt

You have no idea how badly I want to make this image into a T-shirt. CafePress anyone?

Seriously, though, go watch this video. Yegge iz god.

Methods Are Not Just a Means of Reuse

I was reading through the "Refactoring--By Example" chapter of Test-Driven Development in Microsoft .NET today when I ran across a tip that really stuck out at me:

When you see a block of code with a comment attached to it, it is often a good idea to extract that code into a method and make sure that the method's name conveys the meaning specified by the comment.

In the past, I tended to think of methods as a way to reduce duplication in code. If you have two or more sections of code that are very similar, you create a method that encapsulates that similarity, remove those sections, and replace them with calls to the new method.

What the above quotation makes clear is that methods are more than just a way to reduce duplication and promote reuse. A method should also be used to logically group lines of code together, even if the method is only called once.

This is an important realization one must come to on the road to producing more readable and maintainable code.

Books

Updated 7/15/2008

I need to unload all this stuff somewhere before my brain bursts. So here is a collection of all the books related to software development that I want to read, have completely read, and have partially read.

Want to read:

Have completely read:

Have partially read: