Ylan Segal

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:

require 'rspec'

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

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:

$ 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.

Exercism: Practice Your Coding Technique

Perfect practice makes perfect

I have recently discovered exercism.io, by Katrina Owen of Ruby Rogues fame.

Exercism is a great way to practice your code and get feedback on it from others. You work on one exercise at the time and re-submit for review as often as needed until your code is considered great code. You then move on to the next exercise.

It’s awesome because you get feedback on your code, but also because you get to give feedback on other’s code and get to benefit form seeing others code evolve.

So far, it’s been a really fun experience. Thank you Katrina.

Conway's Game of Life

I recently read a blog post recently about Conway’s Game Of Life: Since I had not written an implementation myself, I decided to give it a go.

It was a fun exercise. I did not use any external library other than ruby’s stdlib and used TDD for most of the classes. The interface uses curses. Not knowing how to test it, I took a page from Gary Bernhardt in Functional Core, Imperative Shell and didn’t test the shell at all :)

Here it is: My Take on Conway’s Game Of Life