In ancient Greece, an individual would act as his own agent in his own behalf, or combine with other people to act together as a team. In a Greek work environment, you bring your tools to work with you, you do your stuff, and then you pack up your tools and take them home. You are an individual—an independent contractor. You are not owned body and mind. You are merely providing a service for compensation.

In Rome, one’s first duty was to the group, clan, class, or faction upon which one depended for status. Known as gravitas, this meant sacrificing oneself for the good of the organization, and giving up one’s individuality and identifying closely with the group. In a Roman environment you go to work, the company hands you your tools, and then it holds you and your mind hostage until you sever your relationship with the organization. You are not an individual: you are owned by the organization body and mind, twenty-four hours a day. There are substantial rewards for this, however. The organization provides you with security, money, and power.

Object Thinking is a book about programming. The dichotomy described above is strikingly similar to the literature describing the differences between collectivism and individualism. I sense a symmetry between the quantity of individuals who are true object-oriented programmers and the quantity of individuals who are truly libertarians.

The statist ideology runs deep. Divide and conquer. Adopt and attempt to override words and their definitions to suit a nefarious purpose. Programmers often think that because they’re employing the word “class” and “instance” that they are programming with objects. I find this similar to the confusion present in the minds of so many individuals regarding the nature of capitalism.

The top-down, command-and-control approach is disgusting, evil and inefficient. It is destined to fall. The lethargy and tragedy of collectivist thought pervades everything.

But I see you, collectivism. So long as there in breath in my lungs and blood in my veins, I will fight you.

After a few minutes he stands up. I know to turn down the music. He whispers into my ear. I nod in agreement and mouth back a response.

Flow understands my frustration with testing individual methods outside any greater context or usage scenario.

RSpec is a beautiful tool. Leaps and bounds ahead of the standard testing framework built into Rails. It does this, I believe, by allowing you to use more natural language. But it can be be misused. Which is actually closer to abuse, because unless you’re paying respect to flow, you’re fucking yourself.

Don’t test methods outside of the context in which they should be used. It doesn’t mean shit to the person reading your code — even if that person is you.

Your program is a play. Your objects are actors. You are the writer and director. You say action! You say cut! You know all the lines, but it’s not your job to voice them. You assign those roles to your actors, and they carry it out much better than your sorry ass ever could.

Context. Acknowledge it. If your tests look like this:

describe 'An InterestList' do
 
  before(:each) do
    @interest_list = InterestList.create
  end
 
  describe 'upon creation' do
 
    it 'should not be a new record'
    it 'should be empty'
    it 'should report having zero Interest objects'
 
  end
 
  describe 'when adding a ProductInventoryPrototype' do
 
    before(:each) do
      @cheese = inventory_prototypes(:cheese)
    end
 
    it 'should answer true'
 
  end
 
  describe 'with one ProductInventoryPrototype in it' do
 
    before(:each) do
      @cheese = inventory_prototypes(:cheese)
      @interest_list.add(@cheese)
    end
 
    it 'should not be empty'
    it 'should report having one interest'
 
  end
 
  describe 'removing a ProductInventoryPrototype' do
 
    before(:each) do
      @cheese = inventory_prototypes(:cheese)
      @interest_list.add(@cheese)
    end
 
    it 'should answer with the item when that item is removed'
 
  end
 
  describe 'after removing a ProductInventoryPrototype' do
 
    before(:each) do
      @cheese = inventory_prototypes(:cheese)
      @interest_list.add(@cheese)
      @interest_list.remove(@cheese)
    end
 
    it 'should be empty when that item is removed'
    it 'should report having zero items'
 
  end
 
end

You’re fucking with the laws of nature, and you will be smitten.

What’s wrong with it? The

#before

code is reinitializing all the steps you’ve just accomplished.

Make it look like this.

describe 'When working with an InterestList,' do
 
  before(:each) do
    @interest_list = InterestList.create
  end
 
  describe 'it must first be created.' do
 
    it 'It should not be a new record.'
    it 'It should be empty.'
    it 'It should report having zero Interest objects.'
 
    describe ' After which you can add a product.' do
 
      before(:each) do
        @cheese = inventory_prototypes(:cheese)
      end
 
      it 'To which it should answer true.'
 
      describe 'It now has one product in it.' do
 
        before(:each) do
          @interest_list.add(@cheese)
        end
 
        it 'It should not be empty.'
        it 'It should report having one interest.'
 
        describe 'Now we remove a ProductInventoryPrototype.' do
 
          it 'It should answer with the item when that item is removed.'
 
          describe 'After removing a ProductInventoryPrototype,' do
 
            before(:each) do
              @interest_list.remove(@cheese)
            end
 
            it 'it should be empty when that item is removed.'
            it 'it should report having zero items'
 
          end
 
        end
 
      end
 
    end
 
  end
 
end

Of primary importance is a subtle point. I didn’t illustrate it in the two examples above, but I will now:

Before:

describe 'When working with an InterestList,' do
 
  before(:each) do
    @interest_list = InterestList.create
  end
 
  describe 'it must first be created.' do
 
    it 'It should not be a new record.'
    it 'It should be empty.'
    it 'It should report having zero Interest objects.'
 
    describe ' After which you can add a product.' do
 
      before(:each) do
        @cheese = inventory_prototypes(:cheese)
      end
 
      it 'To which it should answer true.'
      it 'It should not be empty.'
      it 'It should report having one interest.'
...

After:

describe 'When working with an InterestList,' do
 
  before(:each) do
    @interest_list = InterestList.create
  end
 
  describe 'it must first be created.' do
 
    it 'It should not be a new record.'
    it 'It should be empty.'
    it 'It should report having zero Interest objects.'
 
    describe ' After which you can add a product.' do
 
      before(:each) do
        @cheese = inventory_prototypes(:cheese)
      end
 
      it 'To which it should answer true.'
 
      describe ' At which point' do
 
        it 'it should not be empty.'
        it 'it should report having one interest.'
...

On the surface it’s just another level of nesting. After meditation, you realize you are first testing the object’s answer to your message. Second, you are testing the state of the universe after that action is made. The difference is subtle, but important. If you don’t understand the importance, recall the indifference you felt when you first saw RSpec: it’s Rails’ standard test framework with different words thrown in.

You were wrong then and you’re wrong now.

Words offer the means to meaning, and for those who will listen, the enunciation of truth. – V

If an object’s answer to the message passed violates expectations, flow stops. You know, not that a method is broken, but that flow is broken.

Of secondary importance is that your

#before

methods are no longer redundant.

The result of running your tests now looks like:

When working with an InterestList, it must first be created. It should not be a new record. (Not Yet Implemented)
When working with an InterestList, it must first be created. It should be empty. (Not Yet Implemented)
When working with an InterestList, it must first be created. It should report having zero Interest objects. (Not Yet Implemented)
When working with an InterestList, it must first be created. After which you can add a product. To which it should answer true. (Not Yet Implemented)
When working with an InterestList, it must first be created. After which you can add a product. It now has one product in it. It should not be empty. (Not Yet Implemented)
When working with an InterestList, it must first be created. After which you can add a product. It now has one product in it. It should report having one interest. (Not Yet Implemented)
When working with an InterestList, it must first be created. After which you can add a product. It now has one product in it. Now we remove a ProductInventoryPrototype. It should answer with the item when that item is removed. (Not Yet Implemented)
When working with an InterestList, it must first be created. After which you can add a product. It now has one product in it. Now we remove a ProductInventoryPrototype. After removing a ProductInventoryPrototype, it should be empty when that item is removed. (Not Yet Implemented)
When working with an InterestList, it must first be created. After which you can add a product. It now has one product in it. Now we remove a ProductInventoryPrototype. After removing a ProductInventoryPrototype, it should report having zero items (Not Yet Implemented)

This is easier to read and understand than a series of isolated tests. You’re made aware of the context in which each test is being run, which is priceless when you’re attempting to understand the system from a high level.

Congratulations. You are no longer a moron coding outside the realm of the context in which your code lives.

I am an abstract class. My objects represent things that are discrete and map to a number line. My instances can be compared with < and >.

The documentation is written from the perspective of the object. Brilliant.

It sounds epic, poetic and a little corny, but it’s how I think. And it’s how I program. I don’t like solving complicated tasks. I like breaking complicated tasks into many smaller, manageable tasks and solving those. Once each smaller task is solved, I script a dialog between them to achieve the desired effect.

Imagine a movie in which there was only one actor. That actor would have to play the good guy, the bad guy, the dame, all supporting characters and the director’s cameo. Such a movie would have to be classified as a psychological thriller, because it would take an insane person to be able to keep everything together. While the move may have been fun to make (for a sadist), few members of the audience would be able to follow the movie all the way through.

So as your audience leaves the theater, as your programmers leave your project, you realize that being clever and complicated may not have been the best choice.

No, I don’t think I’m a bad programmer. I think I’m a programmer with taste, my own style and a little class. Instead of banging the keys for eight hours, I spend an hour drawing with a pen and paper. Then I spent twenty minutes staring at the wall. I get up, walk around and stretch my legs. I take a piss. When I come back to the computer I have an intricate web of many, simple objects with obvious names and well-defined behaviors. At the end of the day I’m proud of the code I wrote.

And most importantly, I don’t dread coming back to it the next day.

Notice: This is part two of a two-part post. Read the first post if you haven’t already.

All right! We’re taking the experience we gained from our last endeavor, and we’re putting it on rails.

First off, let’s think about our goal — what are we trying to accomplish? How does it flow? What does it look like? In this case it’s pretty simple. It should probably look something like this:

1

product.evaluate('cost')

That’s concise, and it looks good. But it’s not the whole story. So let’s think some more.

We know we have products, as shown above. We have rules, presumably shown above as the argument to the evaluate method. What about variables? I don’t see those in the code above.

Before we go any further, let’s hash out a quick drawing to show our understanding of our objects and their relationships. … Done!

Pretty basic right now, but let’s talk about it.

Rules have many products have many variables. Interesting. When you say it like that, it almost doesn’t make sense. A rule has many products? What would that look like code-wise?

1
2
3
4
5

class Rule
 
  has_many :products
 
end

Hmm… looks perverted, (a rule has products?) but let’s keep going with some pseudo code.

1
2

product = rule.products.create(:name => 'Cheese')
product.variables.create(:name => 'cost', :value => 2)

I dig the second part:

1

product.variables.create(:name => 'cost', :value => 2)

So let’s keep that in mind as we progress.

But what about rule.products? Our first line of code tells us that products should be able to evaluate rules, so there’s gotta be some connection between the two. What do we know least about? I’d probably say the rule objects themselves right now, so let’s take a stab at designing one.

What are rules? Well, let’s look at a real-life example.

1

(x + y) * z

What do you see? … You could say you see a simple math formula. Perhaps, if you recall David West’s explanation of self-evaluating objects, you see an array of operators and variables. Before I tell you what I see, I’d like to say that what I see is based off my previous experience handling self-evaluating objects. That said, I see a string.

That’s it. A simple string.

1

"(x + y) * z"

It’s so simple it’s obvious. And obvious things are often the most difficult thing to see. Now that we know what a rule is, let’s try and define it using object parlance. What can a rule do? What’s it comprised of? What are its responsibilities? Who must it collaborate with to get its job done?

The first thing I see is a definition. Every rule has a definition. I suppose also, that a rule could have a name; it would certainly make distinguishing one rule from another easier.

So now we have named rules with definitions. Let’s see some potential code.

1
2

rule = Rule.new(:name => 'Product cost')
rule.definition = '(cost * tax) + cost'

Looks pretty clean. What next? Oh, that’s right, the obvious: a rule can evaluate itself. Ah, there’s the meat. Now we have a new, non AR-inherited responsibility: evaluation. Let’s take a look..

1
2
3
4
5
6
7

class Rule < ActiveRecord::Base
 
  def evaluate
    eval(definition)
  end
 
end

That’d be nice if that’s all we had to do. Unfortunately it’s not. Executing that as is will raise an error. If we think back to our earlier work, we did simple string replacement to get the proper values into our definitions.

1
2
3

def evaluate
  definition.gsub('uh oh!', "we're missing something")
end

Things just got interesting. Our rule doesn’t have access to the variables needed for substitution in its definition. Hmm… let’s stop and think for a moment.

Rules, products and variables. Products have variables for use in rules. A rule’s definition must have its variables substituted out for actual values. What does that look like?

1
2

rule = Rule.new(:name => 'Product cost', :definition => '(cost * tax) + cost')
rule.evaluate(product)

Hmm… that could work. A rule requires a product be passed to it to gather the contents of its variables.

Let’s try that.

1
2
3
4
5
6
7
8
9
10
11

class Rule < ActiveRecord::Base
 
  def evaluate(product)
    product.variables.each do |variable|
      definition.gsub!(variable.name, variable.value)
    end
 
    eval(definition)
  end
 
end

Not bad. A rule can evaluate itself in the context of a given product’s variables. This will work provide the product passed has all the variables required of the rule, and vice versa.

Of course, this model doesn’t look like our original diagram, and that’s okay. Things rarely go according to plan. Let’s review what we’ve done so far.

Rule objects stand alone. They are named mathematical definitions that evaluate in the context of a given product. (In reality, ‘product’ could be any object that responds to a variables method.)

So our end result is now:

1

rule.evaluate(product)

That’s the opposite of what I originally proposed (product.evaluate(rule)), and I’ll be honest; it feels weird. On the bright side, this solution is much simpler than my original Rails version. However, I still like the feel of:

1

product.evaluate(rule)

But hey, whatever works, right? There’s just one more thing… rules within rules. Ah, interesting. What would that look like?

Well, actually, it shouldn’t look any different than what we have now:

1

rule.evaluate(product)

The above should still give us a single number. So it’s not the end-result (API) code that will be changing, it’s our internal code that will change. But how? Let’s take a look at our definition.

1

(cost * tax) + cost

The part in parentheses represents the tax of our product. So we’re really saying:

1

tax + cost

But now we’ve run into a problem. Is tax a rule or a variable? Currently there’s no way to know the difference. How can we solve that? We need to be able to differentiate between rules and variables. Or at least, I think we should.

We could not, and simply perform blind string replacement, replacing everything in our definition with every match in our variables method. The result is a definition where the only non-numeric or operator characters must be rules. But that sounds pretty flimsy. I can easily see there being a tax variable and a tax rule. So let’s make clear the difference between rules and variables.

1

r:tax + v:cost

Heh, that works. It changes our replacement around a bit, but not too much.

1
2
3
4
5
6
7

def evaluate(product)
  product.variables.each do |variable|
    definition.gsub!('v:' + variable.name, variable.value)
  end
 
  eval(definition)
end

Okay, so we can still evaluate our variables. But what about other rules? What do we do when we encounter another rule? Let’s try scanning the string for instances of r:xxx, do a find for that rule name, and then call evaluate on it…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

  def evaluate(product)
    # Operate on a copy of the definition so the original is open to variable
    # changes.
    evaluated_definition = definition.dup
 
    # Recursively evaluate any rules in the definition.
    evaluated_definition.scan(/r:\w+/) do |match|
      evaluated_definition.gsub!(match, Rule.find_by_name(match[2, match.length]).evaluate(product).to_s)
    end
 
    # Replace variables in the definition with values provided by product.
    product.variables.each do |variable|
      evaluated_definition.gsub!('v:' + variable.name, variable.value.to_s)
    end
 
    # Evaluate the fully-substituted string.
    eval(evaluated_definition)
  end

Let’s run this! (You’ll need to download the complete Rails app and follow the directions in doc/readme.)

1
2
3
4
5
6
7
8
9
10
11
12

rule = Rule.new(:name => 'Product cost')
rule.definition = 'r:tax + v:cost'
rule2 = Rule.new(:name => 'tax')
rule2.definition = '(v:cost * v:tax)'
rule.save
rule2.save
 
product = Product.new(:name => 'Cheese')
product.variables.create(:name => 'cost', :value => 10)
product.variables.create(:name => 'tax', :value => 0.05)
 
rule.evaluate(product) # => 10.5

Scha-weet! But wait! Do I see a recursive function in there? I sure do! Let’s deconstruct it.

We have a rule. We scan its definition for strings that look like r:xxx. Once found, we perform a global string replacement on it, using r:xxx as the pattern match, with the substitute string being the return value of calling evaluate on the rule referenced by r:xxx.

Was that confusing? Don’t worry if it was. Recursion can be pretty difficult to wrap your head around, especially if you didn’t write it. If you’re determined to understand, I suggest reading it several times, line by line, very slowly. It may also help to add some puts messages in there and run it a few times in IRB. That way you can “watch” the recursion magic.

Anywho, just know that it works, and will go as deep as you need it to.

So there we have it! A fully Rails-based self-evaluating monster that will slay accountants everywhere! Okay not really, but it’s pretty cool nonetheless, right?

As excited as you may be, don’t lose yourself. It still only works in console. If you choose to use a solution like this you’ll still need to build an interface for people to use it. There are some other small issues, too. Rule names, for instance. The way the evaluate method is written, you can’t have multiple rules with the same name. Well, you could, but you’d only ever be able to access the first one. There’s also the rigidity of relationships. Product specifically defines its relationship to variables, and there’s still the (I consider) perversion of calling rule.evaluate(product). I’d love to see product.evaluate(rule).

That, however, is an exercise I leave to you. ;)

Oh, before I go, here’s the complete code listing:

rule.rb

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

class Rule < ActiveRecord::Base
 
  # Answers with a BigDecimal after recursively solving rule definitions,
  # performing variable replacement and finally evaluating a flat formula.
  #
  def evaluate(product)
    # Operate on a copy of the definition so the original is open to variable
    # changes.
    evaluated_definition = definition.dup
 
    # Recursively evaluate any rules in the definition.
    evaluated_definition.scan(/r:\w+/) do |match|
      evaluated_definition.gsub!(match, Rule.find_by_name(match[2, match.length]).evaluate(product).to_s)
    end
 
    # Replace variables in the definition with values provided by product.
    product.variables.each do |variable|
      evaluated_definition.gsub!('v:' + variable.name, variable.value.to_s)
    end
 
    # Evaluate the fully-substituted string.
    eval(evaluated_definition)
  end
 
end

product.rb

1
2
3
4
5

class Product < ActiveRecord::Base
 
  has_many :variables, :dependent => :destroy
 
end

variable.rb

1
2
3
4
5

class Variable < ActiveRecord::Base
 
  belongs_to :product
 
end

schema.rb

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

ActiveRecord::Schema.define(:version => 3) do
 
  create_table "products", :force => true do |t|
    t.column "name", :string
  end
 
  create_table "rules", :force => true do |t|
    t.column "name",       :string
    t.column "definition", :string
  end
 
  create_table "variables", :force => true do |t|
    t.column "product_id", :integer
    t.column "name",       :string
    t.column "value",      :decimal, :precision => 8, :scale => 2
  end
 
end