Ylan Segal

The REPL: Issue 1

Today, I am starting a new feature for this blog. I am calling it The REPL. It’s pretty much a link page of interesting reading I have done around the web in the last week (or, more than likely, since the last issue). Of course, this is not a new idea, but I still think there might be some value to it. I will try to avoid this becoming an echo chamber and instead I will try to focus on material that has got me thinking about software engineering.

The Circuit Breaker Pattern

Martin Fowler explains the circuit breaker pattern. Coincidentally at work, we have been discussing using something like this for building in fault tolerance in our interactions with other services. Netflix has a library (in java) for this sort of thing and has blogged about it’s use. Embracing that failure will happen and properly preparing for it turns how you design your code on its head.

Using Interactors To Clean Up Rails

The fellows at Grouper explain how they are using the interactor gem to extract business logic from controllers and models. Again, this is a pattern that we adopted at work not too long ago. DHH gave it some flak on the hacker news comments, but it has given our team a convention on where and how to code business logic.

Store Data Not Types

A cautionary tale on why it’s important to set clear boundaries between your system and the libraries and frameworks that you use.

2014 LA Ruby Conf

Last Saturday I had the pleasure to attend LA Ruby Conf for the first time. The conference has two days of workshops, which I did not attend and one day of single-track talks.

I had a great time and think the organizers did a great job. The talks were varied and interesting, with enough breaks to also take advantage of the “hallway track”. It’s always great to talk to the other developers.

Confreaks taped videos of the talks, but they are not yet available.

See you next year, @larubyconf

Sandi Metz' Revised Rules

I previously wrote about Sandi Metz‘ proposed rules. I had the pleasure of hearing her talk about them last week at the monthly SDRuby meeting.

It turns out that she misspoke in the original Ruby Rogues Podcast Episode and has since revised them to be:

  • No More Than:
    • 100 lines per class
    • 5 lines per method
    • 4 (or even better 3) parameters per method (each hash key counts)
    • 1 instance variable per view
    • 2 class names per controller (1 business object, 1 presentation object)

The main difference from the previous rules, as mentioned on the podcast is that each controller can know about 2 class names: This is pretty significant. I have been trying to adhere to the original rules for a long time. However, no matter how hard I tried, I could not get a controller action that just talked to 1 object, because that meant coupling the view to the business object, which just felt wrong. In the end, I just let it be and created a business object, which was later decorated by another object for the view. After hearing Sandi’s revised rules, I feel vindicated!

This reminds me of the dispensation: You can break any of the rules, as long as someone else on the team agrees.

Code draws code like it

Sandi Metz

I really enjoyed hearing Sandi talk. The SDRuby taping is not yet available, but it looks like Sandi gave the same talk elsewhere.

Ruby Block Precedence: An Rspec Gotcha

Recently I came across a spec that didn’t seem to be executing the assertion block passed in to the raise_error expectation. Leaving the bare essentials for the example:

1
2
3
4
5
6
7
8
9
require 'rspec'

describe 'Block Precedence' do
  it 'expecting this spec to fail' do
    expect { raise 'Opps'}.to raise_error do |error|
      1.should == 2
    end
  end
end

We raise an exception, assert that it was raised and the try to assert something about the exception. In this example, 1.should == 2 should clearly fail. However, when we run this:

1
2
3
4
$ rspec rspec_example.rb
.

Finished in 0.001 secon

It would seem that the block is never being executed.