# Baby's first screencast

Written by Piers Cawley on

If you follow the Ruby blogs, you will probably have seen a bunch of programmers attempting to do something akin to Haskell’s maybe, or the ObjectiveC style, message eating null.

Generally, by about the 3rd time you’ve written

 
if foo.nil? ? nil : foo.bar
...
end


you're getting pretty tired of it. Especially when foo is a variable you've had to introduce solely to hold a value while you check that it's not nil. The pain really kicks in when you really want to call foo.bar.baz. You can end up writing monstrosities like (tmp = foo.nil? ? nil : foo.bar).nil? ? nil : tmp.baz (actually, if you were to write that in production code, you probably have bigger problems). One option is to just define NilClass#method_missing to behave like its Objective C equivalent, but I've never quite had the nerve to find out how that might work. I wanted to write



if maybe { foo.bar.baz }
...
end


and have nil behave like an Objective C nil for the duration of the block, but no longer. So I wrote it. Then I thought about how to present it. I wrote the thing test first using rspec and the whole thing just flowed, but writing up a test first development process for a blog entry is painful, so I've made a very rough (but blessedly short) screencast of the process instead.