I am at RubyConf PT for the week and one of the things that ends up happening is having (insightful) bike shed like conversations with others. I enjoy these conversations because I end up learning something new or recalling some past experiences.

Throughout one of the discussions I was wondering about some coding related epiphanies I’ve recently had. By epiphanies I mean, occasions when I discovered a new perspective I hadn’t considered regarding a problem/process I regularly encountered.

Here are a couple of them.

Learning that I actually don’t need to use let in RSpec

I don’t find let and let! useful to helping me write clear RSpec tests, therefore I don’t use them. The reasons for that choice would require me to write a longer post but the following content (1, 2, 3, 4) was what lead me to reconsider the usefulness of these constructs.

Using rich objects as a method result

It is not uncommon to have methods which return true or false on success/failure, but I prefer to return objects instead. These objects can then be used to have an API more related to the domain concept (e.g result.order_processed?, result.error_messages). I got this from this article.

Learning about the transformational priority premise

Time and time again I’ve realized that the easiest to way to program is to find a solution to the simple use case and progressively solve the more complex use cases. This helps me focus and helps me not feel overwhelmed. This idea and how it ties to TDD is better explained in this post. But I find it useful not only when programming Ruby but also when building UIs.

Injecting the current object as a dependency of another object

I got this idea from Objects on Rails. It is particularly useful when I need to extract a behavior from a controller/view into a separate object. The key constraint being that the extracted behavior requires invoking a method that resides on the controller/view. The key advantage of the approach being that you have the opportunity to extract more code from controllers/views and test it independently.

A simple example:

class PostPresenter
  def initialize(context)
    @context = context
  end
  
  def title
    "Post"
  end
  
  def path
    @context.posts_path
  end
end

class PostController
  def show
    presenter = PostPresenter.new(self)
    render "show", locals: { title: presenter.title, path: presenter.path }
  end
end

Closing thoughts

These were some of the epiphanies I had. I frequently have them when I get to work with others and get to discuss choices/trade offs (reading helps too).

Often I wonder if I share some of these epiphanies as often as I should. Some of these don’t seem that special, but when I discovered them they constituted a profoundly different approach to something I took for granted. The things we learn don’t have to be big ideas in order for them to be valuable. These simple things, that one might inadvertently pick up in a pair programming session, or an aside comment during a podcast, might matter, a lot.