I’m reading ??Beautiful Code and it’s very good indeed. However, you have to feel sorry for Tim Bray - his chapter, “Finding Things” is excellent, as you’d expect. The only problem is, he’s following Jon Bentley, author of that perennial classic, Programming Pearls. It’s been a while since I (re)read anything by Bentley and I’d forgotten how good his prose was.

• Reification
• Notation
• Reticence
• Lucidity
• Intent

Learn ’em. Live by them.

What did I miss? Which ones don’t belong on the list. What am I talking about?

A few days ago, Obie Fernandez:

<typo:flickr img=“430323096” size=“small”/>

commented on the advert found in the current Linux Journal which features a photograph of an attractive woman with the slogan “Don’t feel bad, Our servers won’t go down on you either.” Obie threw together a mock ad for a document management company which showed a bunch of latinos being harrassed by a US Customs and Immigration patrol with the slogan “Don’t worry. We’ll keep all your documents in order.” which made his point rather well I thought.

One of the handy tools that Ruby makes available to us Domain Specific Pidgin builders is instance_eval. With instance_eval you can take a block that was created in one context, with all its lovely closed over local variables, and evaluate it in the context of an instance of an arbitrary object. Which means that any references to instance variables and calls to methods are made as if your block were a 0 argument method of that class. It’s really potent, but at the same time, a little frustrating.

So, I’m busily writing an article about implementing an embedded little language in Ruby. It’s not something that’s going to need an entirely new parser, it borrows Ruby’s grammar/syntax but does some pretty language like things to the semantics and ends up feeling far more like at declarative language than the usual Ruby imperative OO style.

I’ve been following Adam Turoff’s excellent Haskell tutorial and he’s just reached the part where he explains Monads.

To listen to a lot of people, Monads are the bit of Haskell that breaks their brains. As they’re usually described, Monads are the part of Haskell that allow you to write code that has side effects. You know, stuff like reading a file or generating a random number.

Fixtures suck! Mocks rock! Don’t you dare let your tests touch the database!

Well… yes… I suppose. Except, mocking can be a complete pain in the arse too (made slightly less of a pain in the arse if you use the null object options) - it’s awfully easy to end up with huge long setup methods that spend all their time faking out a mock object and about two lines testing what you need.

Back when I was still programming Perl, one of the common mistakes that you’d see when people wrote lazily initialized object accessors was code like:

Mmm… back from Scotland with a chunk of reading done:

Harry Potter And The Deathly Hallows. Mmm… top notch stuff. Wraps up the series perfectly.

The bags are packed, there’s a pile of reading matter (mostly the classics, Turing’s papers, The Dragon Book…), the iPod is charged and we’re off to Scotland for a week with no connectivity.

Have you noticed the difference between Good Clever and Bad Clever?

For instance, I recently spent a couple of hours working out to make a Genre model which acts_as_nested_list work in such a way that when ask one of the trunk genres for its tracks it finds all the tracks associated directly with the trunk or with any of the genre’s sub genres. It’s made doubly complicated by the fact that the genre is related to its tracks through a relationship model, and triply complicated that we’re going to want to be able to be able to search within the basic set of results (because, usually, we don’t want 300 tracks on a page…)

<typo:flickr img=“632526335” size=“small” />

A few years back, we got dad a place on a coracle building course as a birthday present. He had a great time and came back with a half finished coracle that he never quite got round to finishing. Until now, it seems.

As far as I can tell, one of the Smalltalk optimizers’ mottoes is “Cheat all you want, but don’t get caught”.

Well, this morning, I caught Squeak with its hand in the till.

There’s something enormously liberating about writing an RSpec description that starts like:

describe ArticlesController, "feeds:" do
before do
`the_mock = mock('everything', :null_object => true)
    ActiveRecord::Base.stub!(:find).and_return(`the\_mock)
end

it "/articles.atom -> atom feed" do
get :index, :format => 'atom'
response.should render\_template('\_atom\_feed')
end

...
end


The `:null_object` flag to rspec's `mock` function is remarkably potent.The resulting mock will return itself from any method call that hasn't got some other expectation set up. When I'm testing that my index methods render the appropriate views for the format, I don't care that all the various variables have been set up correctly - I've already tested that in another description - I just want to get to the point where I'm about to render a template.

What this does is decouple my tests. I can change the way that the index method fetches its stuff from the database and I'm only going to have to change the innards of the specs that test that.

I tend to think of this as being analogous to the object oriented pattern of trying to write your methods at a single level of abstraction. Within a given spec, I should only be setting up expectations that are directly related to what I'm testing.
    

So, I just pushed the first step of what I’m thinking of as the Great Typo Controller Reorganization to the typo repository and updated things here. It’s always scary when I do that - local testing’s all very well, but running on a live site is a different matter.