Ylan Segal

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.

DelayedJob Workers Are Not Thread Safe

I love DelayedJob. It’s my go-to-gem for background processing in Rails, mainly because it works with whatever data store your project already has in place. No need to bring a different dependency just for background processing. However, using Delayed::Worker in threads is problematic.