Shorter, simpler code with Forwardable

I often find that visual distractions slow me down. Reading simple code with familiar concepts feels cumbersome when I have to sort through repetition to find the meaning.

Take a glance at this code to see what I mean:

class Person
      def street
        address.street
      end

      def city
        address.city
      end

      def state
        address.state
      end
    end

Although the code is short, you have to think a bit before you realize that all of these methods do basically the same thing.

Ruby has a built-in way to bring the information out of this code: Forwardable.

I touched on using Forwardable in a previous article but we'll look closer at what's happening and why you want to use it.

The code above merely forwards the given method to another object. In this case if you try to get address details from a "Person", it will automatically pass it along to the related "address" object.

Given that the procedure is so simple and common in the code, I'd much rather have a way to read that information faster.

require 'forwardable'
    class Person
      extend Forwardable

      delegate [:street, :city, :state] => :address
    end

With this code, the concept of forwarding a message to a collaborating object is so clear that it reads like configuration.

Good configuration is fast and easy to understand.

Forwardable works essentially the same way that the longform code above does. You can provide a list of methods which should be sent to a particular object. Here's what a simplified version of what Forwardable looks like:

module Forwardable
      def delegate(hash)
        hash.each{ |methods, accessor|
          methods.each{ |method|
            instance_eval %{
              def #{method}(*args, &block)
                #{accessor}.__send__(:#{method}, *args, &block)
              end
            }
          }
        }
      end
    end

The "delegate" method accepts a hash where the keys are the method names to forward and the values are the object names to receive the forwarded messages.

For each item in the hash, it will loop through each method name and define a method using instance_eval and the generated string. Those methods send the message along to the object you specified.

The Forwardable code looks complicated, but it's merely 2 loops over a hash and an array, then the instance_eval. The ultimate result is the equivalent of the original code above. With some simple iteration and dynamically defining methods, Forwardable helps us strip away the unimportant parts and raises the valuable information to the top:

delegate [:street, :city, :state] => :address

This shows us what methods will be sent to which object without any additional code to sort through. What could be simpler or easier to scan and understand?

The tools that are right under your nose

I recently had a fantastic experience giving a presentation at RubyConf called The Secrets of the Standard Library. The slides are available and once the video is up I'll send along a link to that.

There are no secrets in the Standard Library

There are no secrets, of course, because the code is right there for you to read but many developers don't realize that powerful tools like SimpleDelegator and Forwardable are built into Ruby. There's no gem to find and install, just require the file you need and you've got it. It's as easy as:

require 'delegate'
class MyWrapper < SimpleDelegator; end

require 'forwardable'
class MyClass
  extend Forwardable
end

My goal in the RubyConf presentation was to show that these tools are available and to describe how they work. Using the tools is one thing, but understanding them is another.

In previous posts we've been looking at ways to use SimpleDelegator to handle presentation behaviors and there's been a bit of Forwardable too. Once you've got a clear understanding of them, you can be more creative with their use and build your own tools to make your code more habitable.

I find that implementing my own library can be a great exercise in understanding an existing one. It was fun to write two short lines in an attempt to create SimpleDelegator and Forwardable in what would fit in less than 140 characters:

# My SimpleDelegator
class D;def initialize(o);@o=o;end;
def method_missing(m, *r, &b);@o.send(m,*r,&b);end;end
# My Forwardable
module Fwd;def fwd(a,m,n=m);self.class_eval
"def #{n}(*r,&b);#{a}.__send__(:#{m},*r,&b);end";end;end

Expanding those out with more descriptive names reveals a bit more about what they do:

# My SimpleDelegator
class Delegator
  def initialize(object)
    @object = object
  end
  def method_missing(method, *args, &block)
    @object.send(method, *args, &block)
  end
end
# My Forwardable
module Forward
  def forward(to, method_name, alternative=method_name)
    self.class_eval "
     def #{alternative}(*args, &block)
       #{to}.__send__(:#{method_name},*args, &block)
     end
    "
  end
end

In both my simple implementation and the actual implementation one uses method_missing at run time and the other defines methods at compile time.

Knowing this, and seeing how they work, can help you make decisions about when to use one over the other. Defined methods are faster than method_missing but they require a more rigid structure.

When do you use SimpleDelegator and when do you use Forwardable?

I generally follow these simple rules for choosing which library to select:

1. Use SimpleDelegator when you either don't know or don't care which messages may be sent to your object. This excepts (of course) the methods you define in your wrapper.
2. Use Forwardable when you know the messages to forward ahead of time.

Both libraries follow the same pattern that a message to one object will be sent along unaffected to the relevant object. But there are times when building your own gives you a better understanding and more control over when errors occurr.

Building your own SimpleDelegator can be tricky. There's quite a lot of work done for you already to help ensure that your wrapper acts like the wrapped object so do read the code and get familiar with the trade-offs when writing your own.

Errors instead of method_missing

Sometimes you may want more control or restriction on the behavior of objects.

You can build a wrapper with Forwardable, for example, by swapping out the object of concern and instead of everything passing through method_missing, you'll get a NoMethodError.

Here's a short example:

class Person
  attr_accessor :name, :color, :number, :email
end
require 'forwardable'
class Wrapper
  extend Forwardable
  delegate [:name, :color, :number] => :person

  attr_accessor :person
end
wrapper = Wrapper.new
wrapper.person = person1
wrapper.name #=> person1 name value
wrapper.person = person2
wrapper.name #=> person2 name value
wrapper.email #=> NoMethodError

A wrapper like this allows us to specify only the methods we want to pass-through and any others that person may have will raise an error.

How have you used these libraries? How do you decide what to use?

What have you built to do similar things?

Last but not least, I recently wrote about undestanding delegation on my blog and how it helped me create the casting gem.

If you enjoyed this post, sign-up for my newsletter below and get more.

Delegation is Everything and Inheritance Does Not Exist

Sharing behavior among and between objects requires a balanced decision. Will other objects use this behavior? Which ones? Why? Should I make a new class to handle what I need?

Determining answers led me to dive into exactly what delegation is and inevitably led to more research to get a better understanding of inheritance.

Prefer delegation over inheritance goes the standard advice.

It seems that many developers think about inheritance in terms of classes. Classes define everything about your objects so it must be the only way to handle inheritance. We tend to think about delegation in terms of instances of classes as well.

This mental model mostly works well. But then there's always someone who points out a seemingly contradictory phrase...

Delegation is Inheritance

Lynn Andrea Stein argued that Delegation is Inheritance in her 1987 OOPSLA paper of the same name. It's a fantastic read and an important paper in describing the behavior of Object-oriented systems and what the costs and benefits are to different inheritance schemes.

But this title seems to go against a simple mental model of what inheritance and delegation are.

Classes and Prototypes

First and foremost, object-oriented programs tend to have either class-based or prototype-based inheritance.

Sometimes you'll see comments around the web like this

a problem that Javascript is having is people wanting to force OOP on the language, when fundamentally it’s a prototype-based language

It's certainly a good thing to understand the way a language was designed, but there is no dichotomy between OOP and prototypes.

Prototypes are an object-oriented paradigm.

Classes are a paradigm which groups objects by type. Classes generate instances whose abilities are defined by their class. This is a rigid approach to sharing behavior and is the one provided in Ruby.

Prototypes on the other hand share behavior among individual objects. An object's prototype defines behaviors that may be used on the object itself.

Perhaps a problem that people see in JS development is instead forcing a class-based paradigm on their programs. Perhaps not. I'm not venturing into that debate but recognize that prototypes are OO.

Inheritance Through Delegation

Many (most?) OO programmers are familiar with class-based inheritance systems.

You create a new instance of Thing and that thing instance has all of the abilities defined in its class. This concept is easy to grasp.

Prototype-based inheritance, however, seems much more complex. In order to understand the behavior of one object you also need to understand the behavior provided by its prototype which is just another object. A prototype doesn't necessarily act as an umbrella of classification like classes.

It's harder to think in generalizations outside of a class system. The type of an object is a simple mental model but with prototypes, the possibilities are myriad.

But getting back to the point of this section, class-based inheritance uses delegation to share behavior. A message sent to the instance thing is delegated to the class Thing. All of the behaviors are defined in the class, but self is bound to the object that received the message. The behavior is evaluated in the context of the object. That is: self refers to the instance, not the class (where the behavior is defined).

class Thing
  def hello
    self.inspect
  end
end

thing = Thing.new
thing.hello # <-- delegation to its class which defines the behavior

In a case where two objects exist in a prototype-based system, the same rules apply. The keyword self is bound to the object that received the message and any delegated behavior is defined in another object.

Ruby delegates through classes and as a result caches its methods based upon the classes of objects. This class-based approach means that adding new behavior to an object leads to the cache being cleared because as an instance of a particular class the object's behavior changes and needs to be reflected in the method lookup (defined by its class). Charlie Somerville has a great rundown of things that clear Ruby's method cache.

Our class-colored lenses skew our understanding of delegation.

Inheritance Does Not Exist

This brings me around to why reading Stein's argument about delegation being inheritance is important. Most (or maybe just many) programmers seem to misunderstand what delegation is.

Stein's paper made the argument that delegation is inheritance. Her paper is based upon the definition of delegation citing Henry Lieberman's 1986 paper.

Lynn Stein was recently very helpful to me and suggested that the original understanding of delegation may have come from "Delegation in Message Passing Proceedings of First International Conference on Distributed Systems Huntsville, AL. October 1979". Alas, I can't find that paper online but it is related to the application of the Actor pattern by Carl Hewitt, Beppe Attardi, and Henry Lieberman.

Stein's work was built against the understanding that delegation has a specific meaning. When methods are delegated, they are bound to the object that received the message. The self or this keywords (depending on the language) refer to the original object that received the message.

Many commenters on my delegation article (and on other forums) claimed that the "delegation" term has changed meaning over the years. Lieberman, critics say, may have coined the term but he doesn't own the meaning.

Some have argued that delegation no longer means what Lieberman, Stein, and other OO pioneers meant. If this is true and delegation means 2 objects forwarding messages, and if delegation is inheritance, then effectively every object sending a message is inheritance. Either that or inheritance does not exist.

Why Care?

I've been working around the limitations of implementing DCI in Ruby and the behavior of objects is a central concern.

In DCI our bare data objects gain behavior inside a context relevant to some business goal. Typically this is either explained through the use of extend to add a module to an object's inheritance lookup:

thing.extend(SomeModule)
thing.method_from_module

The problem in Ruby is that the object's inheritance tree remains the same for the life of the object.

# Before
thing.singleton_class.ancestors #=> [Thing, Object, Kernel, BasicObject]
thing.extend(SomeModule)
# After
thing.singleton_class.ancestors #=> [SomeModule, Thing, Object, Kernel, BasicObject]

The thing object is forever tied to it's new set of ancestors. This may affect your program if you expect your object to lose behavior after executing some procedure inside a DCI context.

There are projects which hack Ruby to add unextend or other like methods, but they are additions to Ruby typically only in one interpreter (like MRI).

What Can Ruby Do?

A new feature of Ruby 2.0 is exciting in the abilities we'll have to build libraries that aid in delegation.

Methods defined in modules may now be bound to objects regardless of their class ancestry.

SomeModule.instance_method(:method_from_module).bind(thing).call

That code is a mouthful, but it shows (in Ruby 2.0) that we can add behavior to objects without extending them.

If we want to implement a delegation technique we could hide all this inside a method.

def delegate(method_name, mod)
  mod.instance_method(method_name).bind(self).call
end

This is an approach I built into casting, a gem that helps add behavior to objects, preserves the binding of self inside shared methods and leaves the object in it's original state.

It's easy to use, but it takes a different view of what delegation is compared to how most Ruby developers seem to think. The delegated method here will preserve the self reference to the thing object and behavior is added without extending the object.

class Thing
  include Casting::Client
end

thing.delegate('some_method', SomeModule)

It's a work in progress and has given me a great reason to explore what Ruby can and can't do.

The Best of Both Worlds

Stein's paper suggested that a hybrid system of both class-based and prototype-based inheritance would provide both rigidity and flexibility when needed.

As I've worked with my code more and researched more for Clean Ruby I've had the desire for a hybrid system. Stein's words ring true:

In order to take full advantage of the potential of such a system, objects must be treated simply as objects, rather than as classes or instances.

Indeed, DCI requires a system where an object gains and loses behavior based upon the context. The behaviors are localized to the context and a hybrid system like the one Stein described would benefit from the advancement of DCI.

This is a challenge to implement in Ruby but I'll be working more on casting in the future.

For now, it's useful to consider the contextual behavior of our objects and think less about the classes that define them and more about the message passing among them.

Focus on the behavior of your system first, use delegation and worry about classes later.

How abstractions encourage good thinking

Many times, as developers, we grow our code in ways we don't intend. We live with quick decisions a little too long and end up with a problem where, well, we don't see the problem. With too much of this, our code becomes our unkempt bedroom or messy desk.

Working against your brain

A few years ago I saw an excellent presentation at Rocky Mountain Ruby by Michael Feathers about a phenomenon he called "code blindness." In that keynote he raised the point that despite the fact developers may know how to, or know why our code should be structured differently, we become used to seeing things the way they are and no longer recognize real or potential problems. We become blind to it.

This type of behavior is a result of how our brains react to visual clutter. As we add more information, more objects, and more variablity to the environment we're creating, our brains will dampen the signals from each part and hide their influences on our attention.

The dampening of each stimulus is a way we cope with too much information. The NIH released a news advisory in 1998 which explained how our brains can counterbalance the dampening effect with focused attention. So what exactly does this mean and how does it apply to programming?

Read the NIH advisory here.

Our programming languages are merely ways of representing concepts. Our brains translate characters to representations of things, to describe iteration, to define decisions and outcomes, and more. The more variation and number of concepts we require our brains to translate, the harder it becomes to maintain focused understanding of any individual concept.

This, of course, leads to the development of ideas such as separation of concerns, the single responsibility principle, and others in which we aim to remove visual clutter form our code and reduce the cognitive load on our brains required to translate stimuli into ideas.

By dampening the effect of stimuli, our brains are able to better focus on the immediate task. The studies at the NIH revealed that by placing effort to focus on a particular aspect of our environments we are able to counteract the dampening feature of our brains. This makes quite a bit of sense: pay attention to something and you're more likely to notice it. But as the NIH points out that while we may only partially cancel-out the effects of nearby stimuli, the amount of the attention required increased in tandem with the amount of visual clutter.

Living with complexity and clutter in our code is often a way we decide to get work done faster now and come up with a better solution later. Unfortunately it is also a decision to create an environment where we'll have to work harder in the future to focus on the right thing.

Working with your brain

The more we have in our environments demanding attention, the more our brains will dampen our attention to them.

Abstractions, such as the presenters we've reviewed in previous articles, are a way we can remove visual clutter and unnecessary stimuli. Separating our programs into layers of responsibility is a way of working with our brains to ensure they'll only need to place just enough effort required to maintain focus and understanding of a particular concept.

The act of building these layers in our programs is how we make decisions to work with our brains' ability to manage focus and prevent the dampening effect from slowing down our work.

This introduces to our program our idea of habitable code. What we consider to be a place where our brains will function well will be expressed in our program code. Often, the place I find the most trouble is with view templates. As a result I work to treat these as much as possible like configuration where logic and number of distinct objects are kept to a minimum.

Transformations of data are often a place where confusing details can cause us to filter out valuable concepts from our minds. View templates which contain multiple objects, transformations of data, control structures such as if/else/unless blocks or iteration are a source of clutter.

Visual clutter can appear all over or merely in a single line.

link_to timeslot.in_time_zone(@timezone).strftime("%l:%M%p"), 
      new_profile_appointments_calendar_event_path(@calendar.profile, @calendar, 
      :event_slot_id => event_id, :timezone_name => @timezone.name), 
      :class => "open", rel: 'nofollow'

When we write code we create the environment in which our brains must function and react. Often, we end up creating these cognitive barriers in our view templates like this. Fortunately, we're able to simplify them with techniques like pushing complexity into a presenter layer.

If you review the code sample above, you'll need to spend quite a bit of time, far more than you should, just to understand what will be output.

It's important to make decisions to remove the parts unimportant to us. The abstractions which we create can remove as much information as we decide. Leaving parts for our brains to compose can be a feature:

link_to time_display, new_event_path, class: "open", rel: "nofollow"

Or creating a small footprint to handle a concept at a higher level allows us to remove visual clutter and removes the need to compose parts.

presenter.new_event_link(class: "open", rel: "nofollow")

These sample bits of code show no implementation, but the great thing about programming is that we get to choose. The choices we make might work with our brains or might work against them. We can push away noisy details like which timezone to use for formatting and how how to

Our divide and conquer approach with abstraction layers helps us to filter out noise from signal. Of course, with too much abstraction we may become mired in the noise created by divided ideas but we get to decide and experience what fits best.

Work with your brain and consider what ideas belong in which places. Write the code you wish to have.

Unleash the Secrets of the Standard Library

RubyConf 2013 was a fantastic experience and I was fortunate enough to give a presentation about learning from the tools in the Standard Library. The presentation was recorded and will be online soon.

While the slides alone don't reveal the value from my presentation, I encouraged the audience to read the ruby source and discover what the standard library has to offer. We looked at how delegate.rb and forwardable.rb can help solve problems and how they are implemented. There's plenty of tricks to pick up in there.

I had a great time having a chat on Ruby5 too.

Update:

My presentation was posted by Confreaks:

Easy Metaprogramming For Making Your Code Habitable

In my last message, I wrote about simplifying the code you write by using the Forwardable library. It allows you to represent ideas with succinct code:

delegate [:sanitize, :link_to, :paginate] => :view

In one short line we're able to show that certain messages and any arguments will be forwarded to another object.

The Presenter class we've been working with also has convenient methods created based upon the name of any inherited classes. A UserPresenter will have user and user= methods mapped to __getobj__ and __setobj__ by an easy to follow convention of choosing a name that makes sense.

These are ways that I've found in my own code to make it more habitable for me and my team. With as little effort as possible, we should feel at home understanding and changing behavior of the system.

Make your own shortcuts

I have had projects where data would be displayed to a user but may have come from multiple different sources. A user record might be imported from a third-party system and have data that needs to be updated. Or a person in a system might have one or more public profiles from which we need to choose to display information.

If an updated profile has good information we want to show that, otherwise, we'll show some other imperfect information.

Here's an example of an approach I took recently. I needed a way to specify that my data should first come from a profile and then fallback to the user record if no data was available. This is what it looked like:

class UserPresenter < ::Presenter
  delegate [:profile] => :user
  maybe :full_name, :address, :from => :profile
end

I went with the name maybe but you might find that something else is clearer for you.

Here's how I made it work:

class Presenter < SimpleDelegator
  def self.maybe(*names)
    options = names.last.is_a?(Hash) ? names.pop : {}
    from = options.fetch(:from)
    class_eval names.map{|name|
      %{
        def #{name}
          #{from}.public_send(:#{name}) || __getobj__.public_send(:#{name})
        end
      }
    }.join
  end
end

This creates a maybe class method which looks for a collection of method names and an hash in which it expects to find :from. Next it opens up the class (which would be UserPresenter in this case) with class_eval and defines methods based upon the provided string.

The methods are simple and they are equivalent to something like this:

class UserPresenter < ::Presenter
  def full_name
    profile.full_name || user.full_name
  end
end

Although the full methods are short, using this technique allowed me to simplify the code necessary to handle the concept. Additionally, as I needed, I was able to make changes where a blank, but non-nil value wasn't considered a valid.

Changing the behavior to avoid nil and blank strings was easy:

def #{name}
   value = #{from}.public_send(:#{name})
   (!value.nil? && value != '' && value) || __getobj__.public_send(:#{name})
end

Or if you have ActiveSupport:

def #{name}
   #{from}.public_send(:#{name}).presence  || __getobj__.public_send(:#{name})
end

Beware of indirection

This code made sense in my project, but for yours it might not. If I were to only use this for the full_name and address methods then I'd probably be making my project less habitable. A layer of indirection, especially when woven through metaprogramming, can be a painful stumbling block to understanding the code later. Be careful to think about how or if you need to apply code for a pattern like this.

Get more tips like this by signing up for my newsletter below.

What to code when you know what you want

My last few posts have built up a simple wrapper class that helps to add behavior to an object when we're displaying information to our users.

1. Ruby delegate.rb Secrets
2. The easiest way to handle displaying bad data
3. Simplify your code with your own conventions
4. Formatting collections of objects with SimpleDelegator
5. How to make your code imply responsibilities

We've been using SimpleDelegator which uses method_missing to do its magic. But there's another way of forwarding messages with the standard library Forwardable.

In our presenters, we've been wrapping a main object and a view to handle concerns for the display but there are certain features that we don't want to augment with our wrapper. In Rails we have methods like link_to which help us to create links in our display, and in previous code I showed how we used the view reference in our presenters to handle sanitizing content:

class Presenter < SimpleDelegator
  def sanitize(*args)
    @view.sanitize(*args)
  end
end
class UserPresenter < Presenter
  def bio_html
    sanitize(user.bio)
  end
end

This sanitize method highlights an aspect of handling the behavior of our presenters: sometimes we know exactly what we want to happen, other times we don't know or don't care.

Use shortcuts for forwarding when you know what you want

When building my presenters, we knew that we needed to have the view handle sanitization because it was built into the framework. But writing methods every time we wanted to send a message to the view is cumbersome. This is how we made it even easier:

require 'forwardable'
require 'delegate'
class Presenter < SimpleDelegator
  extend Forwardable
  delegate [:sanitize, :link_to, :paginate] => :view
end

With this simple change, we can use all of these specified methods inside our presenters and they'll automatically be handled by the specified object, the view.

When this Presenter class is loaded, these methods (sanitize, link_to, and paginate) will be generated for us. They'll define the named methods and automatically pass along any arguments.

This allows us to create simpler classes without the need to create method definition blocks ourselves and our other methods end up looking like this:

class ProfilePresenter < ::Presenter
  def social_media_link(options={})
    link_to('Tooter', tooter_url, options)
  end
end

The access to link_to is implicit: we expect it to be there already. Implicit behavior can be dangerous in that it requires that anyone working with the code know to expect the behavior. Your development team should be aware of the structure of your presenter classes and understand that these methods will automatically be forwarded to the view. But this is all a part of finding patterns in your code.

Rails-flavored forwarding

If you're using Rails, you don't need to use Forwardable because every class in your program will already have a delegate method defined by ActiveSupport.

The syntax is similarly easy:

require 'delegate'
class Presenter < SimpleDelegator
  delegate :sanitize, :link_to, :paginate, :to => :view
end

Your code will be more succinct when you use shortcuts provided by Forwardable and other libraries. SimpleDelegator allows us to create objects which act as a pass-through filter for behavior. Because of method_missing, we can treat our wrapper like a replacement for another object but with Forwardable, we must specify our intentions when we design the class.

Try it out and let me know how you handle managing behavior among objects in your wrappers. Everyone on my Clean Ruby mailing list gets regular tips like this. Signup below.

How to make your code imply responsibilities

Readablity is an important aspect of creating code that you or others will need to understand later. Because I often need to communicate purpose to other developers, I opt to avoid using if/else blocks of code, particularly in view templates.

For example, some users of a system might have certain details available to them based upon their role or some particular bit of data. Here's how I simplified my views using presenters.

Where you might have something like this in your views

<%= if profile.has_experience? && profile.experience_public? %>
  
Experience: <%= user_profile.experience %>
<% end %>

There is a better way...

Tell objects to execute blocks, let them decide if they really should

I want my views to handle conditional options, but I want the conditions to be clearer than querying for values.

<%= user_profile.full_name %>
<%= user_profile.bio_html %>
<% user_profile.with_experience do %>
  
Experience: <%= user_profile.experience %>
<% end %>
<% user_profile.with_hobbies do %>
  
Hobbies: <%= user_profile.hobbies %>
<% end %>

Here I specify what I want to display when the user profile has details for experience or details for hobbies. The implementation is simple:

class ProfilePresenter < ::Presenter
  def with_experience(&block)
    if profile.has_experience? && profile.experience_public?
      block.call(view)
    end
  end
end

The sample code is contrived, but what this allows me to do is move the details of what having experience means. Presently the code checks if the profile has_experence? and experience_public?.

This could easily be moved into a separate method for use in the view:

class ProfilePresenter < ::Presenter
  def has_public_experience?
    profile.has_experience? && profile.experience_public?
  end
end

The problem with a method like this is that 1) its name is dependent upon the implementation and 2) its intent is different from the intent used in the view.

Make your code imply responsibilites

First, the name merely combines two values. What will happen when requirements change and we need to ensure that the provided experience includes at least 3 years of activity? The meaning of has_public_experience? will change along with its behavior and lead to surprises for developers unfamiliar with these particular details. It will no longer merely be existince of experience allowed for the pubilc.

This leads us to the second problem: the intent of the method is to display features, not query for values. Were we to stick with a query method like has_public_experience? we would end up considering the content inside the view along with the meaning of the method every time we read this code.

By creating a method which accepts a block, our view template implies that the responsibility for determining display is elsewhere: in the presenter. The view will display what is configured, but determining that is upto the object we're showing. Leaving query methods lying around in your views is just asking for the next developer to change the view code to profile.has_public_experience? && profile.has_3_years_experience?, and then the value of your presenter is lost.

The name with_experience helped us force developers to consider where changes should be made. How do you prepare your code for change? How does your team ensure that resposibilities are well-managed?

Readers of my Clean Ruby newsletter get regular tips like this. Sign-up below.

Formatting collections of objects with SimpleDelegator

Here's a quick tip about how I used my presenters to handle a collection of objects.

Previous posts relevant to this are:

1. Ruby delegate.rb Secrets
2. The easiest way to handle displaying bad data
3. Simplify your code with your own conventions

Working with collections of objects

A common problem when displaying data comes when we display collections of objects that contain collections of other objects.

I solved this for myself in a simple way with my existing presenters.

My application needed to display search results from an event management system and we called this the Agenda. Our agenda had sessions, days, and time slots and we needed a way to handle presentation details for all of them.

All of these items needed their own code, but we only needed to work with them together. From the start, we didn't break these presenters out into separate files.

Here's the structure of how we managed our agenda presenters

module AgendaBuilder
  class ResultsPresenter < ::Presenter
  end
  class DayPresenter < ::Presenter
  end
  class TimeSlotPresenter < ::Presenter
  end
  class SessionPresenter < ::Presenter
  end
end

This kept our related details together and kept us focused in one place.

Custom iterators

When in came to using these in our view templates, we didn't want to leak knowledge of the object classes into the views. From the start, a simple approach would be to initialize the presenters where you need them. Here's what it could have looked like in our ERB files:

<% agenda.sessions.each do |session| %>
  <% session_presenter = AgendaBuilder::SessionPresenter.new(session, self)
   %>
  

    
<%= session_presenter.title %>
    
<%= session_presenter.other_view_method %>
  
<% end %>

This is ugly. The view template has knowlegde of the classes used to implement the objects it needs to display. Instead, it would be far easier to read and handle changes if it looked like this:

<% agenda.each_session do |session| %>
  

    
<%= session.title %>
    
<%= session.other_view_method %>
  
<% end %>

Now that is far easier to grok.

Let's take a look at the code:

class ResultsPresenter < ::Presenter
  def each_session(&block)
    presenter = AgendaBuilder::SessionPresenter.new(nil, view)
    sessions.each do |session|
      presenter.session = session
      block.call(presenter)
    end
  end
end

This creates the each_session method which accepts a block that we use for each session in the collection.

The first part of this method may look strange: we initialize a SessionPresenter wrapping nil and providing the view object.

The presenter requires some object to initialize properly and since we're setting the session object later, we can just use nil as a placeholder. But we do this so that we can avoid creating a new presenter with each iteration of the block.

The alternative would look like this:

class ResultsPresenter < ::Presenter
  def each_session(&block)
    sessions.each do |session|
      presenter = AgendaBuilder::SessionPresenter.new(session, view)
      block.call(presenter)
    end
  end
end

While this would work, there's no need to create a new presenter object each time. Our handy session= method does the trick.

Benefits of custom iterators

Providing our own iteration method gave us the ability to change the behavior as we needed. If we merely rely on an Array with agenda.sessions.each, we're tied to that dependecy.

If we decide we don't need a SessionPresenter at all, we don't need to change our view code, we'd only need to remove that from our each_session method.

Following the pattern

We had this need for custom iterators in several places (sessions, days, and time slots) so we have an established pattern. The next step was to move this to our Presenter class so we didn't have to rewrite the same procedure each time.

The only differences between our iterators were the collection of objects (sessions, days, and time slots) and the class of the presenters needed.

All we really want to write is something like this:

class ResultsPresenter < ::Presenter
  def each_session(&block)
    wrapped_enum(AgendaBuilder::SessionPresenter, sessions, &block)
  end
end

With some minor changes to our procedure, we end up with a base wrapped_enum like this:

class Presenter < SimpleDelegator
  def wrapped_enum(presenter_class, enumerable, &block)
    presenter = presenter_class.new(nil, view)
    enumerable.each do |object|
      presenter.__setobj__(object)
      block.call(presenter)
    end
  end
end

We went back to our SimpleDelegator __setobj__ method to avoid knowledge about the domain of the presenter.

Iterating over and presenting items from our collections became so much easier and our views so much simpler. This allowed us to treat our views more like readable configuration. A title method called in the view template could be the actual title from our wrapped object just passing the data through, or, as we change our requirements, could become anything else without requiring changes to our template.

Our view template captured our intent, whereas our presenter captured the requirements and implementation.

Simplify your code with your own conventions

Finding and automating repeated ideas in your code can be a great way to avoid errors and make yourself feel at home. As you build your own software, you and your team can create a framework that makes implementing new features a breeze. Here's how I implemented some changes that helped us do some serious cleanup.

You may recall from my last post about displaying bad data that my presenter looked a bit like this:

require 'delegate'
class UserPresenter < SimpleDelegator
  alias_method :user, :__getobj__
  def initialize(object, view)
    super(object)
    @view = view
  end
end

That leaves out some a custom method, but you get the picture of how it's created. This wasn't a new gem I pulled in to solve a problem, it was built from scratch.

Once I have something that works and feels comfortable, I end up finding a need for it in different ways. Sure enough, I found that I could use presenters in other places. Classes like ProfilePresenter, ShoppingCartPresenter, and others began to appear.

There are a few things I did to make myself feel at home with them and, better yet, make it easier for others to implement their own.

Let Ruby do the work

I don't want to be recreating this same bit of code when I find a new need for a presenter.

One helpful aspect of my user presenter was the user method I had available. It was a name that expressed the object much better than the standard __getobj__ method. If I needed similar methods in other presenters, I'd rather not be writing alias_method over and over again.

The ProfilePresenter should have a profile method and the ShoppingCartPresenter should have a shopping_cart method, and so on.

So I created a starting point that would do this for me.

I decided that I would stick to a simple naming convention using the class name of my presenter to generate the method accessors.

require 'delegate'
class Presenter < SimpleDelegator
  def self.inherited(klass)
    # get the part of the class name we want like "ShoppingCart"
    base_name = klass.name.split('::').last.sub('Presenter','')
    # downcase and underscore (without activesupport) like "shopping_cart"
    wrapped_object_name = base_name.gsub(/([a-z][A-Z])/){ $1.scan(/./).join('_') }.downcase
    klass.send(:alias_method, wrapped_object_name, :__getobj__)
    klass.send(:alias_method, "#{wrapped_object_name}=", :__setobj__)
  end
end

When any class inherit's from that, it'll automatically alias methods based upon the name of the class. It's equivalent to:

class ShoppingCartPresenter < SimpleDelegator
  alias_method :shopping_cart, :__getobj__
  alias_method :shopping_cart=, :__setobj__
  # more custom methods that we need
end

Instead of all that, however, it just looks like this:

class ShoppingCartPresenter < Presenter
  # more custom methods that we need
end

Displaying potentially dangerous data

My UserPresenter had become useful when we needed to display a bio for a user. Our data could contain HTML and a we needed to be careful about what would be displayed. We certainly didn't want arbitrary scripts being loaded from any bio content.

Given that I had a Rails application, we were able to use the standard sanitize method to clean up HTML content. And now that we've got presenters, it gave us a perfect place to tie our objects and views together so that our template files could be simplified.

Originally, our view looked like this

<%= sanitize @user.bio %>

But we had already made some changes to use a @presenter in another place, so we can lean on that to make our view template simpler.

Our presenter initializes with combination of an object and view, so we can handle this behavior inside:

class UserPresenter < Presenter
  def bio_html
    @view.sanitize(user.bio)
  end
end

Then our view template becomes a bit more predictable when moving over to the @presenter:

<%= @presenter.bio_html %>

If we want to provide this ability to all presenters, we can add the behavior to our base class:

class Presenter < SimpleDelegator
  def sanitize(*args)
    @view.sanitize(*args)
  end
end
class UserPresenter < Presenter
  def bio_html
    sanitize(user.bio)
  end
end

A big benefit there is that we had better control over what created our sanitized html. Our code managed the dependency on the Rails sanitization behavior and if, for any reason, we decided to use an alternate strategy for sanitizing our data, we'd have a single place to look to make the change.

Simplified interfaces

Creating our own conventions made using our code predictable and easy. It gave us sensible expectations for how it would work.

Moving the responsibility for creating a sanitized bit of data from the view template into a presenter object helped us to better manage our templates with simpler code. And it helped us stick to a single interface for data display.

Next time I'll cover how I was able to use wrappers while looping over collections of objects and how we removed if/else statements from our views.

How have you used your own conventions to simplify your process?

The easiest way to handle displaying bad data

I've spent time on a few different projects recently where some simple changes helped to clean up some difficult parts of our code. Here's an easy way to simplify your code.

Displaying the wrong thing

On a recent project there was some existing view code that expected to display a link to a person's profile on another site.

But there was a problem where the link just wasn't working properly. Some profiles properly linked to external sites, but some linked to a bad url.

Jim's profile might have had a link like this: http://other.site.com/profile/123

But Amy's profile had a link like this: http://mycompany.com/dashboard/other.site.com/profile/234

Do you see what's wrong there? The link code was generated like this <a href="other.site.com..."> instead of including the important http:// in it.

The problem was that our database stored either value. While we could change the validation of the data on creation, we'd still need to ensure that existing data was handled properly.

Rather than processing all of our data and updating it, presenters are a perfect solution for this.

Clean up with SimpleDelegator

I wrote about delegate.rb secrets in detail on my blog but here's a quick example of how you can use it right now to clean up some code.

Often Rails apps in particular end up with a lot of logic inside the views and this can quickly grow out of control. One way to simplify this is to create a presenter object which brings together the object you need from your controller and the view.

First, let's change the controller.

Down below, we'll go over how this can help you with more complex code, but let's keep it simple for now. Take any of your basic controllers that look like this:

def show
  @user = User.find(params[:id])
end

Change it to:

def show
  @user = User.find(params[:id])
  @presenter = UserPresenter.new(@user, view_context)
end

That's the first small step, but it gives us a lot more flexability. One thing to note is that view_context method is the controller's reference to the view that it will render. Let's walk through the next step...

Building a Presenter

Make a user_presenter.rb file somewhere in your app directory (app/models is fine, and later you may choose somewhere else but this is fine for now).

require 'delegate'
class UserPresenter < SimpleDelegator
  def initialize(object, view)
    super(object)
    @view = view
  end
end

This creates a SimpleDelegator object which wraps (in this case) the @user from our controller. Since the links we displayed were acting incorrectly, let's solve that.

First, I always want to use method names that make sense to me. SimpleDelegator provides the method __getobj__ to refer to the object that you've wrapped, but it's ugly, and you or others may forget exactly what that means. From the start, I provide an alias for myself:

class UserPresenter < SimpleDelegator
  alias_method :user, :__getobj__
end

Now I can use a method that makes things much clearer. So let's get to the link fixing...

class UserPresenter < SimpleDelegator
  def other_site_link
    if user.other_site_link.match(/\Ahttp:\/\//)
      user.other_site_link
    else
      "http://#{user.other_site_link}"
    end
  end
end

This simple change allows our presenter to handle the case where the "other_site_link" doesn't have the "http://" prefix.

Now I can go to my view and change from @user to @presenter.

After that, it's far easier to test that my presenter displays the correct information and handle when the database doesn't.

Other Benefits

This was a very small example. I've seen many controllers with more than just one instance variable to handle data for the view.

A presenter gives you a single object to handle multiple items for your view. Instead of making a new instance variable, why not make a method on your presenter?

Try it out. Often we wait too long to make a new class to handle some behavior and in the case of our views, the code easily becomes unwieldy.

Stay tuned for more updates about handling code growth and business logic. In the meantime, what difficulty are you overcoming with your code?

Simplifying JS function arguments for recursion with this

In a previous post, you read about how to ensure that a deeply nested object structure exists. We wrote a simple function ensure_struct that takes a string, splits it up, and turns it into a nested object.

In the original function it accepted 2 arguments: the string and an optional scope.

We used the optional scope as a way to aid in recursion. The function grabbed the first part of our string and made sure there was an object with that name, then it took the rest of the string and passed that object in as the scope. Down it went through the object structure until there were no more parts of the string left.

The string flamethrower.fuel.fire became the object {flamethrower:{fuel:{fire:{}}}}.

JS is powerful and leaning on the use of the this keyword instead of passing an optional argument makes the function even simpler. Let's look at the final function:

var ensure_struct = function(attributes) {
        if (attributes == '')
            return this;

        var parts = attributes.split('.');
        var first_part = parts.shift();

        if (typeof this[first_part] === 'undefined')
            this[first_part] = {};

        ensure_struct.call(this[first_part], parts.join('.'));
        return this;
    }

This is mostly the same as last time, but what's different is that we're not checking for a value for scope, the optional argument. Last time we had var scope = scope || this; to check if there was a scope given, or just set it to this.

But we can ignore that entirely because the value of this can be set by using either of 2 core functions in JS.

Instead of calling the function and passing the scope, we can set the value of this by using either call or apply.

It's here where that magic happens:

ensure_struct.call(this[first_part], parts.join('.'));

That line takes the function and uses the call function on it. By using call we can pass an object that we want to be the value of this when the function is run. It's the same as just running the function ensure_struct(parts.join('.'); but telling it to use a specific value for this (which is the last object created in our function).

While we're still recursively applying the function to our objects and strings, we no longer need to track an additional variable.

We can do the same thing with apply but the additional arguments we send must be in an array:

ensure_struct.apply(this[first_part], [parts.join('.')]);

Now we can either call our function and set a nested object on our window (what the value of this would be originally) or we can tell the function to apply a specific value to this.

var ensure_struct = function(attributes) {
        if (attributes == '')
            return this;

        var parts = attributes.split('.');
        var first_part = parts.shift();

        if (typeof this[first_part] === 'undefined')
            this[first_part] = {};

        ensure_struct.call(this[first_part], parts.join('.'));
        return this;
    }

    var some_object = {};
    ensure_struct.call(some_object, 'deeply.nested.structure');

Ruby delegate.rb secrets

You've seen SimpleDelegator in action and used it a bit yourself. The delegate library is more than just a fancy method_missing wrapper.

Easy Wrappers

First and foremost, SimpleDelegator is a fancy method_missing wrapper. I know I said the library was more than that, just bear with me.

Here's some sample code:

jim = Person.new # some object

class Displayer < SimpleDelegator
  def name_with_location
    "#{__getobj__.name} of #{__getobj__.city}"
  end
end

displayer = Displayer.new(jim)

puts displayer.name_with_location #=> "Jim of Some City"

That Displayer class initializes with an object and automatically sets it as @delegate_sd_obj. You'll also get both a __getobj__ and a __setobj__ method to handle the assignment of the @delegate_sd_obj.

You may want to alias those methods so they won't be so ugly when you use them: alias_method :object, :__getobj__.

Method Missing

Here's an expanded view of how it handles method_missing:

target = self.__getobj__ # Get the target object
if target.respond_to?(the_missing_method)
  target.__send__(the_missing_method, *arguments, &block)
else
  super
end

The actual code is a bit more compact than that, but it's that simple. SimpleDelegator is so simple, in fact, that you can create your own implementation just like this:

class MyWrapper
  def initialize(target)
    @target = target
  end
  attr_reader :target

  def method_missing(method_name, *args, &block)
    target.respond_to?(method_name) ? target.__send__(method_name, *args, &block) : super
  end
end

That's not everything, but if all you need is simple use of method_missing, this is how it works.

SimpleDelegator Methods

SimpleDelegator adds some convenient ways to see what methods are available. For example, if we have our jim object wrapped by displayer, what can we do with it? Well if we call displayer.methods we'll get back a unique collection of both the object's and wrapper's methods.

Here's what it does:

def methods(all=true)
  __getobj__.methods(all) | super
end

It defines the methods method and uses the union method "|" from Array to make a unique collection. The object's methods are combined with those of the wrapper.

['a','b'] | ['c','b'] #=> ['a','b','c']

The same behavior is implemented for public_methods and protected_methods but not private_methods. Private methods are private, so you probably shouldn't be accessing those from the outside anyway.

Why does it do this? Don't we want to know that the main object and the SimpleDelegator object have methods of the same name?

Not really.

From the outside all we care to know is what messages we can send to an object. If both your main object and your wrapper have methods of the same name, the wrapper will intercept the message and handle it. What you choose to do inside your wrapper is up to you, but all these methods lists need to provide is that the wrapper can receive any of those messages.

Handling clone and dup

SimpleDelegator will also prepare clones and dups for your target object.

def initialize_clone(obj) # :nodoc:
  self.__setobj__(obj.__getobj__.clone)
end
def initialize_dup(obj) # :nodoc:
  self.__setobj__(obj.__getobj__.dup)
end

Read Jon Leighton's post about initialize_clone, initialize_dup and initialize_copy in Ruby for more details about when those methods are called.

Making your own SimpleDelegator

SimpleDelegator actually inherits almost all of this from Delegator. In fact, the only changes that SimpleDelegator makes is 2 convenience methods.

class SimpleDelegator < Delegator
  def __getobj__
    @delegate_sd_obj
  end
  def __setobj__(obj)
    raise ArgumentError, "cannot delegate to self" if self.equal?(obj)
    @delegate_sd_obj = obj
  end
end

Subtracting all the comments around what those methods mean, that's the entirety of the class definition as it is in the standard library. If you prefer to use your own and call it SuperFantasticDelegator, you only need to make these same getter and setter methods and you've got all that you need to replace SimpleDelegator.

Keep in mind, however, that the __setobj__ method has some protection in there against setting the target object to the wrapper itself. You'll need to do that too unless you want to get stuck in an endless method_missing loop.

Using DelegateClass

The delegate library also provides a method called DelegateClass which returns a new class.

Here's how you might use it:

class Tempfile < DelegateClass(File)
  def initialize(basename, tmpdir=Dir::tmpdir)
    @tmpfile = File.open(tmpname, File::RDWR|File::CREAT|File::EXCL, 0600)
    super(@tmpfile)
  end

  # more methods here...
end

This creates a Tempfile class that has all the methods defined on File but it automatically sets up the message forwarding with method_missing.

Inside the DelegateClass method it creates a new class with klass = Class.new(Delegator).

Then it gathers a collection of methods to define on this new class.

methods = superclass.instance_methods
methods -= ::Delegator.public_api
methods -= [:to_s,:inspect,:=~,:!~,:===]

It gets the instance_methods from the superclass and subtracts and methods already in the Delegator.public_api (which is just the public_instance_methods). Then it removes some special string and comparison methods (probably because you'll want to control these yourself and not have any surprises).

Next it opens up the klass that it created and defines all the leftover methods.

klass.module_eval do
  def __getobj__  # :nodoc:
    @delegate_dc_obj
  end
  def __setobj__(obj)  # :nodoc:
    raise ArgumentError, "cannot delegate to self" if self.equal?(obj)
    @delegate_dc_obj = obj
  end
  methods.each do |method|
    define_method(method, Delegator.delegating_block(method))
  end
end

The code is sure to define the __getobj__ and __setobj__ methods so that it will behave like SimpleDelegator. Remember, it's copying methods from Delegator which doesn't define __getobj__ or __setobj__.

What's interesting here is that it's using Delegator.delegating_block(method) to create each of the methods. That delegating_block returns a lambda that is used as the block for the method definition. As it defines each of those methods in the methods collection, it creates a forwarding call to the target object. Here's the equivalent of what each of those methods will do:

target = self.__getobj__
target.__send__(method_name, *arguments, &block)

For every method that it gathers to define on this new DelegateClass it forwards the message to the target object as defined by __getobj__. Pay close attention to that. Remember that I pointed out how you can make your own SimpleDelegator and create your own getter and setter methods? Well DelegateClass creates methods that expect __getobj__ specifically. So if you want to use DelegateClass but don't want to use that method explicitly, you'll need to rely on alias_method to name it something else. All of your automatically defined methods rely on __getobj__.

Lastly, before returning the klass, the public_instance_methods and protected_instance_methods are defined. There's some interesting things going on in those method definitions, but I'll keep the explanation simple for now.

This Tempfile class that we created is actually exactly how the standard library's Tempfile is defined.

If you're not familiar with it, you can use it like this:

require 'tempfile'
file = Tempfile.new('foo')
# then do whatever you need with a tempfile

If you dive into that library you'll see:

class Tempfile < DelegateClass(File)

The tempfile library relies on the delegate library, but not in the way that you might find in the wild. Often I see developers using only the SimpleDelegator class, but as you can see there's a handful of other ways to make use of delegate to handle message forwarding for you.

Ensure nested objects/hashes exist

Recently I was working on someone else's code and found quite a lot of repetition of similar code in their JS files. Here's an example:

if(typeof(flamethrower) === 'undefined'){ flamethrower = {} };
if(typeof(flamethrower.fuel) === 'undefined'){ flamethrower.fuel = {} };
if(typeof(flamethrower.fuel.fire) === 'undefined'){ flamethrower.fuel.fire = {} };

This sort of pattern kept coming up in file after file.

There are 2 things to learn about the project from this code. The first is that there is obviously a loading problem.

The number of files that followed this pattern was a serious indicator that someone either wasn't investigating a load order problem, or that the developer was being overly protective of the code in a particular file to avoid errors. So the first step when encountering this is to investigate dependencies and load order.

But sometimes you may actually need to ensure that some nested structure exists. Your load order may need to be necessarily arbitrary or unpredictable.

To DRY up this code we can write a recursive function and get something as simple as:

app.ensure_struct('flamethrower.fuel.fire')

This makes our code much easier to process and understand. In the first example you see so much code that you are required to slow down and read carefully to ensure you haven't missed anything. A simple typographical error would be very easy to miss and could introduce an unexpected bug.

How can recursion help us here? Let's take a look at the final function first:

var app = {}

app.ensure_struct = function(atts,scope){
  var scope = scope || this;
  if (atts == "") {
      return scope;
  }
  var parts = atts.split('.'),
      first_attribute = parts.shift();

  if (typeof (scope[first_attribute]) === 'undefined') {
      scope[first_attribute] = {};
  }
  app.ensure_struct(parts.join('.'), scope[first_attribute]);
  return scope;
}

We've defined this on an app object but that can be whatever you want. First, what we care about is some string representing the structure that we need. In our example we used "flamethrower.fuel.fire" so that's the first argument that we need to handle.

app.ensure_struct = function(atts){
  var parts = atts.split('.');
}

This gives us an array of parts to turn into objects. We'll also need a starter object to add these items and we can begin to check if they exist or set them.

app.ensure_struct = function(atts){
  var parts = atts.split('.');
  var starter_object = {};

  if(typeof(starter_object[parts[0]]) === 'undefined'){
    starter_object[parts[0]] = {};
  }
}

The problem here is that we have begun by getting the first of the attributes from our array. We still need to address the rest of our attributes. One way to do this would be to loop over the array of parts and add those named objects to the last object we had in hand:

var last_object = starter_object;
var index = 0;
while (index < parts.length) {
  if (typeof (last_object[parts[index]]) === 'undefined') {
    last_object[parts[index]] = {};
  }
  last_object = starter_object[parts[index]];
  index++;
}

You could instead use a for loop to shrink it a bit:

for(var i = 0, o = starter_object, l = parts.length; i < l; i++){
    attribute = parts[i]
    if(typeof(o[attribute]) === 'undefined'){
       o[attribute] = {};
   }
   o = o[attribute];
}

As an alternative, we can use recursion to tackle our needs. This helps simplify the code a bit:

var parts = atts.split('.'),
    first_attribute = parts.shift();

if (typeof (scope[first_attribute]) === 'undefined') {
    scope[first_attribute] = {};
}
app.ensure_struct(parts.join('.'), scope[first_attribute]);

I'm happier with that. Inside our ensure_struct function we reuse what we've already written by joining our leftovers and sending a new to the fuction. Of course, to get this to work we need to change the arguments that the function accepts and check that we haven't sent a blank string in for the attributes. When we hit our last part, the leftover_attributes is an empty array and joining it will return a blank string.

app.ensure_struct = function(atts,scope){
  var scope = scope || this;
  if (atts == "") {
      return scope;
  }
  var parts = atts.split('.'),
      first_attribute = parts.shift();

  if (typeof (scope[first_attribute]) === 'undefined') {
      scope[first_attribute] = {};
  }
  app.ensure_struct(parts.join('.'), scope[first_attribute]);
  return scope;
}

Now, we can set our scope from the outside if we like.

app.ensure_struct('values.one.two', other_object);

And yes, this comes from an actual project named flamethrower.

Searching through your bundled gems

You've probably been working on a project where someone added a feature from a gem which caused an error, but you had no idea where to find the offending code.

For me, that happened yesterday. Someone had removed a database table without diving in to see what code actually required the table. Unfortunately, this is a rescue project which barely has tests.

Here's a quick summary of what you can do:

ag thethingyouneed `bundle show --paths`

I began writing some acceptance tests to cover our asses and found that when I attempted to delete a user, the test blew up. Deleting a user was completely unrelated to what I actually cared about but it coincidentally happened for my test.

The failure was because I was missing a receipts table. The fact that this table was needed was news to me, so I asked other team members to find out what it was.

"Oh, yeah. Have you rebased onto develop? It was removed."

WTF?! Why? Why would anyone remove a table and not make sure to investigate that no leftover code required it? Unfortunately lazy developers make mistakes.

So I began digging. I knew the requirement for the offending table existed somewhere in our project, but there was no direct reference in our application code.

Bundler must have a way to search through it's gems, right? Wrong.

I found a few pull requests related to this need and realized that it was much simpler than relying on bundler to do the job for me.

Bundler can provide you with all the load paths that it creates with

bundle show --paths

And nix tools like grep or ack can take a collection of paths to search through. I really like using the_silver_searcher however, so that's my go-to tool. It's super fast.

All I needed to do was pass that collection of paths to ag and I had what I needed.

ag receipts `bundle show --paths`

Then I was on my way and found that we were using a gem that provided an acts_as_messagable method that expected a receipts table to exist was used in one of our models and was no longer needed.

There are 3 lessons here.

First, you can compose things with unix tools and I don't need Bundler to do the entire job for me.

Second, you really should be writing tests. It's the presence and execution of a test that found this bug for me.

Third, always make sure you properly clean up your project. Consider the impact of your laziness on the rest of the team. An ounce of prevention is worth a pound of cure.

Chubby models are still fat with Concerns. DCI focuses on how things work together

You've seen complicated codebases. You've dug through other people's code without a clue to what's going on or how it all fits together. Perhaps it was your own code or perhaps someone else's but you know how difficult it can be to figure out how this or that aspect of a system implements some required feature.

Often, code organization is a key aspect of aiding communication. Today on the 37signals blog, David Heinemeier Hansson wrote about how ActiveSupport::Concern can really help clean up your code. Rails 4 will even have new concerns directories in the load path by default, making it even easier to use this feature.

He points out that Basecamp has almost 40 concerns that organize features required for multiple models. Giving an example, he says "This concern can then be mixed into all the models that are taggable and you’ll have a single place to update the logic and reason about it."

What's great about this is that single place. To understand something thats "Taggable" or "Searchable" you only need to find that concern and you have all that you need. Making changes is just as easy; it's all right there.

Addressing some of the objections to these fat models, he says:

It’s true that this will lead to a proliferation of methods on some objects, but that has never bothered me. I care about how I interact with my code base through the source. That concerns happen to mix it all together into a big model under the hood is irrelevant to the understanding of the domain model.

I agree with the first part of this. Most of the time an object that has many unrelated methods isn't much of a concern. But when we need to drop into a debugger and look at what the object is and can do, then we are met with far more than we need. Inspecting the runtime object becomes difficult because of the overwhelming features and responsibilities that it has.

Almost 100% of the time, however, we interact with code through the source. This is spot on. We read and write code. But the fact that concerns happen to mix it all together under the hood is not irrelevant to understanding a domain model. It's important how many of these mixins are used and how complicated an individual class can become.

But even more important is how it works. Not how things are mixed in, but how your program works. What is going on?

Why do you care that a model is Taggable? What purpose does it serve and what other actor in the system will have a need for it?

Using concerns can be helpful, but if it's used by many models it may effectively become a fragile base class problem where changes to it have unintended ripple effects through those models that inherit its features.

ActiveSupport::Concerns and Roles in DCI are not the same. Roles in DCI are ONLY defined within a context. Your context represents a use case for your system and is larger than a single procedure. A use case covers success paths, failure paths, and alternate paths to the execution.

I had one reader of Clean Ruby, Drew Ulmer, write to me and say:

As far as putting roles directly into contexts, I can't tell you how much I love this idea. It's fantastic to have all of the logic and model behavior for a specific activity in one place and not have to jump around files. It keeps the models focused around how they are defined and not around what we use them for or how they behave; it keeps the behavior focused and easy to reason about; and it defines a very clear API that must be implemented for a context.

I passed this along to my mailing list and after reading it, I got this response from Anthony Burton saying:

To be honest, reading this I kept thinking "that's just the way things were supposed to be". Nevertheless, I always get so frustrated trying to dig through a project (new or old, right?), and trying to trace the flow of execution and how things fit together. This made me think of a project I worked on a few years back (which thankfully had a substantial logging capability) where I wrote a little perl script that would parse logs files and show how things were linked together. It was a very popular utility with the other devs and I was always curious, 1) why no one had written something like it before me; and 2) why the code wasn't just organized differently.

This is a valuable lesson for communicating what your software is supposed to do. You not only need to read the code, but you need to understand how different pieces work together. DCI is a great way to organize code and achieve better communication.

Here's a dumb example of what your context might look like:

class SwappingDetails
      def initialize(source, recipient)
        @source, @recipient = source.extend(Source), recipient.extend(Recipent)
      end

      def swap
        # trigger the appropriate methods
      end

      def other_trigger
        # trigger alternate behavior
      end

      module Source
        # some related methods here
      end

      module Recipent
        # some related methods here
      end
    end

Those modules represent the methods required for an object playing the role. With concerns, you must understand more about the classes of objects ahead of time whereas within a DCI context you'd focus only on roles and their interaction. When using concerns, you understand less about what will trigger the action, what other objects are necessary, and what roles those other objects play.

Concerns can be useful, but just like anything else they can be done poorly. Thinking in terms of interacting roles is not the same as abstracting related behaviors into a module.

Regardless of what you do in your application, communicating it's purpose is key to managing change. The better others can understand how something works, the easier it will be to make necessary changes.

$15,000 in Income From an eBook, How I Did It

Over less than 6 months I've made more than $15k in revenue from Clean Ruby. It's an unfinished book and I've been working to polish it up and get new content out to my customers but I wanted to take a step back and review where I am.

Grand Plan Gone Wrong

I already had a product idea, I just needed help getting it going. Or so I thought.

I asked Eric Davis, who wrote Refactoring Redmine what he thought of Amy Hoy's 30x500 course. For him, it was an absolutely positive experience and he let me know that when you take it once, you can keep taking it.

I was cautious about the cost of the course, but with that reaction I decided it would be a good investment to finally make my CMS hosting service, Solar System a reality.

When the course began, I was super eager. I already had a leg up because I had most of my product put together. I just needed to figure out how to market it.

And the first thing I learned was that my product was dead, would remain dead, and was a waste of further time and effort. I fundamentally had begun in the wrong place and needed to first find what people wanted.

For me, it was like building a shop in the middle of nowhere. I chose a place that seemed like it would be great for a trainload of customers to pass through. After the course however, I knew how to look for existing tracks first and then listen for the train approaching.

How I Chose My Product

I started with this Recurring Revenue Roundup and wish I had built that product first, given some of the problems I had accepting some people's money in my initial launch.

But I was really distracted from this course by a new idea called DCI. If you're not a programmer, don't worry. It's a new and challenging way of thinking about programming. That's all you really need to know.

I was trying to build my other product, but was instead constantly, and eagerly, distracted by DCI. I read about it. I wrote notes. I tried out simple ideas in code. I started applying what I learned to my daily work. "Damn it!" I thought. I want to build a product but I can't focus on that.

This DCI idea is new. There were practically no places it was being discussed. I thought that would preclude me from using it to make a product. Who cares about it? I have no idea, I can't find them.

I write on my blog from time to time. Not often enough. I planned a blog post because the idea is important and powerful. Someone should be blogging about it.

So I wrote my first post and decided just before I published it that I would add an email sign-up form. http://www.saturnflyer.com/blog/jim/2011/09/28/4-simple-steps-extending-ruby-objects-the-tip-of-the-iceberg-with-dci/

I rarely get comments on my blog. I still don't get many, but within a few short hours I had 0 comments, but 12 people on my mailing list!

WTF!?

Apparently people will give your their email sooner than they will make a comment. I didn't quite do customer research the way she teaches, but I went fishing. Little did I know, but I wrote what Amy calls an E-Bomb (for Education Bomb).

Finding the Ears to Listen

The thing about programmers (aside from the fact that some are strangely offended by that term and prefer "developers") is that they really enjoy technical stuff.

But most people don't do technical stuff because it's there and it's technical. They read, write, and study because it gets them to some greater goal.

That is what Clean Ruby does.

It's not a book about DCI. It's a book that will help you better manage your development effort to reflect your business. It's a book about thinking.

I noticed that despite great developers being great, they often overlook things. There is a lot to consider when developing an application and seemingly small things can fall through the cracks.

I took great inspiration form both Lean Architecture and Clean Code. Both of these books are about thinking too. These aren't books about patterns or code wankery, they teach you to slow down and do things properly.

Encouragement and Support

I'm thankful to have the support of many people. I've been fortunate to have guidance and understanding on programming concepts by Jim Coplien and Trygve Reenskaug. They have been both critical and supportive exactly where I need it. And I've been lucky enough to get a deeper understanding of things like delegation by asking David Ungar and Henry Lieberman directly.

I'd asked Alistair Cockburn for his opinion about my book. In an email I mentioned that "I'm often the developer who spends the most time thinking about method, class, or variable names. And I often take the time to go back and clarify when I've met a misunderstanding somewhere."

He replied with this: "I got in trouble at a small co in 1983 cuz I wrote that way in Radio shack TRS-80 assembler. One of the obscure coders said I was the worst programmer he'd ever seen. Wonder what he's doing with his life these days."

All this and more is leading me to create a book that will be a long-lasting, helpful product. There are plenty of people working on their own products in the 30x500 group who help keep me focused: Noah Gibbs, Brennan Dunn, Alex Korban and more.

Revenue

With all my research, thinking, experimenting, questioning, and daily work going on I've been selling books.

I was very nervous to launch the book. I've never written a book before and I was planning to release it before it was done. I actually chose to do that because I'd gotten pressure from anxious people waiting to become customers.

My pre-launch sales have been fantastic; much better than I expected.

The initial spike of sales was a total surprise to me. I began collecting comments from Twitter about my book and was happy to see my book called "long-awaited".

I was building a product that people wanted. I wasn't wasting time figuring out how to market something that I thought possibly could be useful like my CMS hosting. My book is actively helping developers take a second look at their applications and think harder about the real business value of what they do.

After a tip from my friend Roy Tomeij (who is also writing a helpful book) I gathered comments and relevant info in a story so I wouldn't lose that feedback and encouragement.

After less than 6 months, this is how it looks.

But my sales have dipped as my personal life has been turned upside down. I've gone through the process of buying a new home, having a tree fall on it hours after we signed the deed, had a daughter born a day after that (my 4th child), found mold in the basement and had it removed, found plumbing problems, electrical problems, and finally more mold.

Despite all that, I feel great. I'm now selling a product that doesn't require my time for every dollar. Hourly consulting is great, but it requires hours. Building a product completely removes me from needing to provide hours for money. This is a life-changing experience.

I am eager to get back to my research and finish the book and my customers are eager to get it.

The book has helped getting my name out for my consulting work as well. A broader audience now sees that I know how to help them build software in large systems and how I can train them to do the same. What's great about writing this book is that the small companies and individuals who can't afford that kind of consulting are able to learn from the book for a fraction of what they charge for an hour's worth of work.

Buy Clean Ruby and learn to write Ruby applications that better reflect your business. And let me know what you think.

The Gang of Four is wrong and you don't understand delegation

The Gang of Four got it wrong. Ruby's standard library has it wrong. Rails has it wrong.

Is it still wrong if everyone is doing it?

Yes.

The Gang of Four book Design Patterns gives us common vocabulary to understand basic patterns in Object-oriented programming. It helps all of us use the same terms when discussing our software and prevents confusion.

Sadly, this book seems to cause a whole hell of a lot of confusion.

They say "prefer composition over inheritance." That's great, there's good reason for that.

They say to use "delegation." That's great. Although there's not a single example of delegation in their book.

Delegation is a technique often cited as a way to create flexibility in your programs. That is to say, delegation is often given as the way to composition.

But delegation isn't what you think it is. The Gang of Four have lead you astray.

Worse still, almost every reference you'll find for "delegation" shows you examples of just object collaboration with message forwarding. They are examples of plain old method calls and not delegation.

Now imagine what your mentor would say about understanding basic programming concepts...

Don't have a mentor? That's ok. Imagine that you do. Now imagine what your mentor would say about understanding basic programming concepts...

You should probably understand them correctly, right?

So what is Delegation?

Delegation is easy to understand but we're so used to hearing and reading it in reference to something else. Let's fix that.

Henry Lieberman coined the term "delegation" in Using prototypical objects to implement shared behavior in object-oriented systems released with the OOPLSA '86 Conference proceedings on Object-oriented programming systems, languages and applications. That content is behind a pay wall, but you can read similar and updated content on his website

In there, you'll find exactly what delegation is, but I'm not sending you away to pore over another long article; I can simplify it for you. When you have time, however, go read Lieberman's own words.

Lieberman discussed this in terms of a GUI drawing tool. Here's the key idea behind delegation:

When a pen delegates a draw message to a prototypical pen, it is saying "I don't know how to handle the draw message. I'd like you to answer it for me if you can, but if you have any further questions, like what is the value of my x variable, or need anything done, you should come back to me and ask." If the message is delegated further, all questions about the values of variables or requests to reply to messages are all inferred to the object that delegated the message in the first place.

In short, when you send a message to an object, it has a notion of "self" where it can find attributes and other methods. When that object delegates to another, then any reference to "self" always refers to the original message recipient. Always.

The other inheritance

Class-based inheritance isn't the only game in town. Prototype-based inheritance is another way to structure your objects for behavior sharing. One approach sets behaviors in an abstract location (the class) and another sets it on instances (the objects).

Self is a programming language which implements what Lieberman defines. Self has objects which contain slots. Each slot can contain a method, or a reference to a prototype object in a parent slot. If an object received a message it didn't understand, it could delegate to an object in its parent slot.

This is prototypical inheritance, not class inheritance. It is similar, although not the same, as saying that an object has a class (like Ruby objects) which contains additional behavior.

Self giving us objects with a parent slot is he equivalent of JS giving us an object with a prototype reference.

JS is the most popular prototype-based language and is much easier for you to try, so rather than teach you Self, we'll look at JS. You can even open up your browser's console and try this out right now.

In JS we can assign a prototype: the equvalent of the parent slot in Self.

function Container(){};
Container.prototype = new Object();
Container.prototype.announce = function(){ alert("these are my things: " + this.things) };

function Bucket(things){this.things = things};
Bucket.prototype = new Container();

bucket = new Bucket("planes, trains, and automobiles")
bucket.announce() // alerts "these are my things: planes, trains, and automobiles"

In delegation parlance the bucket object is the client which forwards a message to the delegate.

In the above example, you can see that the evaluation of this.things was done in the context of the client object. When we called the announce function, it was found on the delegate object. When the function was evaluated, this refered to the client.

When a JS object's prototype contains a functon, the function is evaluated as if the object has that method. The first example showed that this (which is just self in JS) always referred to the original message recipient.

What about Ruby?

First, understand forwarding. Forwarding is passing a message from one object to another. The Ruby standard library forwardable is aptly named and allows you to forward messages from one object to another.

Now, let's take the poorly named delegate library from the Ruby standard library which also allows you to forward messages from one object to another.

require 'delegate'

# assuming we have a Person class with a name method
person = Person.new(:name => 'Jim')

class Greeter < SimpleDelegator
  def hello
    "Hi! I'm #{name}."
  end
end

greeter = Greeter.new(person)

greeter.hello #=> "Hi! I'm Jim."

What happens inside that Greeter is that when the greeter instance is initialized it contains a reference to the person. When an unknown method is called, it is forwarded to the target object (which is person). Remember, we're still looking at the delegate library, which helps us forward messages... Confused? Yeah, I was too. So, it seems, is the rest of the world.

Forwarding is just the passing of a message to an object: a method call.

The difference between this and delegation is that these libraries allow you to easily forward messages to additional objects, rather than executing the method of another object in the context of the first like we saw with prototype-based inheritance in JS.

We are often barely aware of this because Ruby's method_missing power does the trick in SimpleDelegator. We think about methods automagically going to the object we want.

Even though our Greeter method refers to self, the message is forwarded to the other object and handled there when, of course, the method is missing on the client.

If we want to share behavior without extending an object with additional methods, then method_missing and/or SimpleDelegator can do the trick nicely. This works well for simple uses. It does, however, break references to an object's class.

Suppose, for example, we want to reference the client object's class with some new kind of greeting. And instead of the normal greeting, let's make it say "Hi! I'm the esteemed Person, Jim."

We don't want to completely rewrite the method, so we'll rely on super to get whatever is implemented in the regular Greeter.

class ProperGreeter < Greeter
  def name
    "the esteemed " + self.class.name + ", " + super
  end
end

proper_greeter = ProperGreeter.new(person)

proper_greeter.hello #=> "Hi! I'm the esteemed ProperGreeter, Jim."

Hmmm. That's not what we expected. What we wanted to see was "the esteemed Person".

This is a simple illustration of the fact that we have two objects and is an example of self-schizophrenia in Object-oriented design. Each object has its own identity and notion of self. We can fix that by changing the reference to use __getobj__ (the way SimpleDelegator expects) instead of self, but this is an illustration of how self does not refer to what we want. We must explicitly work with two objects and our mental model always requires that we think about two objects interacting when we only really care about altering the behavior of one.

This is not delegation. This is always two objects collaborating. Despite the numerous books, articles, and software libraries telling you otherwise. The Gang of Four got Delegation wrong, but that's OK because now you know better.

Whatever, I'll call it what I want

Who cares. Let's not rock the boat. Everyone is doing it.

Yeah, Design Patterns showed examples in C++. And C++ can't do delegation. So is that a valid argument for rewriting the meaning of a term?

If the language you use can't provide it, don't just call what the language can do "delegation."

Get the concepts right

Developing an application requires that you understand not only your business domain concepts, but also understand many tools and approaches to your design. Software design patterns are common ways to solve common problems. Understanding what they are and when to use them is a key part of being an efficient developer.

The Design Patterns book is often lauded for giving names to commonly used software design patterns. This helps all of us use the same terms when discussing our software and prevents confusion.

Of course, as I began research for Clean Ruby I picked up the Design Patterns book for some clarity. "Surely this book will help guide the discussion and understanding of how to approach different patterns," I thought. Sadly, it contains a glaring mistake that has been repeated and codified in numerous books, articles, and software libraries. Again and again I've read the same description of a behavior sharing and object composition pattern in software that is almost always given the wrong name.

The Design Patterns book is great for having pushed the idea of "composition over inheritance." In fact, so many developers seem to love this phrase that you'll probably be hit over the head with the term the next time you argue for setting up class-based inheritance. Thankfully, Sandi Metz defends class-based inheritance for its logical purposes in Practical Object Oriented Design in Ruby.

Design Patterns is often praised, not for innovation but, for its consolidation of terms. It guides us in the language that we use to understand and discuss different ways of approaching problems. It named for us common patterns so that we could better communicate with each other about what we are creating.

That praise, however, falls a little flat when you try to understand delegation.

My book, Clean Ruby, dives into understanding delegation and explores ways to keep your projects well origanized, maintainable, and loosly-coupled, giving you ways to share behavior and avoid cognitive overhead. Get it now and get your concepts straight.

How to preserve idioms in Ruby subclassing

Ever wonder why you call new on a class but define initialize? Let's take a look.

Leaning on inheritance is a great way to solve related problems in our applications while allowing for some variation in behavior. Inheritance is simple and easy to implement.

Here's a quick example of where developers often stumble by writing classes that require too much knowledge about their subclasses.

Let's make a simple class that we'll use to say hello:

class Greeter
  def initialize(args)
    @name = args.fetch(:name){ 'nobody' }
  end

  def greet
    "I'm #{@name}."
  end
end

Here we have a Greeter class and when you initialize an object from it you'll be able to tell it to greet with an introduction:

greeter = Greeter.new(:name => 'Jim')
greeter.greet
=> "I'm Jim."

We later find that in some cases we need a variation of this with something more formal. So let's make a class to support that:

class FormalGreeter < Greeter
  def greet
    "I am your servant, #{@name}."
  end
end

With this FormalGreeter class we have a different introduction:

greeter = FormalGreeter.new(:name => 'Jim')
greeter.greet
=> "I am your servant, Jim."

Adding Default Behavior During Initialization

Later you decide that your FormalGreeter really ought to do something special during the greeting.

greeter = FormalGreeter.new(:name => 'Amy', :movement => 'curtsy')
greeter.greet
=> "I am your servant, Amy."
greeter.action
=> "curtsy"

Here our FormalGreeter is the class that will move during the greeting. So we can just define initialize:

class FormalGreeter < Greeter
  def initialize(args)
    @movement = args.fetch(:movement){ 'bow' }
    super
  end

  def action
    @movement.to_s
  end
end

All you have to do for everything else to work is to remember to call super.

But having to remember things can be a stumbling block in your code. Humans forget things.

One way to do this would be to setup a special initialize method to be called in the base class. There you could define your own behavior in the subclasses:

class Greeter
  def initialize(args)
    @name = args.fetch(:name){ 'nobody' }
    special_initialize(args)
  end

  def special_initialize(args)
    # hook for subclass
  end
end

This is better because we don't need to remember in what order we should run our code. Does my code go first and then super? Or do I call super first and then do what I need? Now, we don't need to mentally recall the procedure.

This simplifies our initialization process, but we still have the need to remember that instead of calling super within our initialize method, we need to define our special_initialize method.

Humans forget things.

This should still be easier.

Instead of needing to remember things, you can hook into your initialization in a way that requires less thinking during the development of your subclasses. Fallback to standards like defining initialize.

Here's how you protect idiomatic code:

class Greeter
  def self.new(args)
    instance = allocate # make memory space for a new object
    instance.send(:default_initialize, args)
    instance.send(:initialize, args)
    instance
  end

  def default_initialize(args)
    @name = args.fetch(:name){ 'nobody' }
  end
  private :default_initialize

  def initialize(args)
    # idiomatic hook!
  end
end

Now our subclasses have the benefit of being able to use their own initialize without the need for us to remember super nor a custom method name.

class FormalGreeter < Greeter
  def initialize(args)
    @movement = args.fetch(:movement){ 'bow' }
  end

  def action
    @movement
  end
end

Now you have some insight into the way that Ruby uses your initialize method.

Wroclove.rb Presentation

I was very fortunate to present some ideas to a group of developers in Wroclaw, Poland at http://wrocloverb.com/

Slides always leave out interesting things (and they should) but I'll post the video as soon as it's available.