# DHH Sounds Out of Touch

I just read Uncle Bob's Test Induced Design Damage?.

I keep fearing the day when Rails messes up and becomes too complicated or poorly maintained or something else, but that hasn't happened. It’s really an impressive solid project that solves common problems and steadily integrates popular solutions to new problems with each . . .

May 01, 2014

# Never use ActiveRecord persistence methods in Rails controllers

### And never, ever use ActiveRecord filters.

Rails controllers are a mess.

An ongoing discussion in the Rails community is how, when, and if to test controllers (and how impossible is is to write tests for controllers that are both thorough and not completely isomorphic with implementation).

There are many dimensions to this problem, and it touches a lot of the . . .

April 19, 2014

# What I would like in Ruby 3

Ruby development is hurtling along these days. In 2012 1.9 finally became the norm, and in 2013 we got both 2.0 and 2.1. All of these versions brought small but steady feature improvements.

Here are some thoughts on how I would like the language to change, possibly appropriate for Ruby 3 or Ruby 4.

January 01, 2014

# Sandi Metz's Rules

In episode 87 of the fantastic Ruby Rogues podcast, Sandi Metz shares these programming rules:

• Your class can be no longer than 100 lines of code.
• Your methods can be no longer than four, maybe five lines of code.
• You can pass no more than four parameters and you can’t just make it one big hash.
• Your Rails . . .

November 24, 2013

# The classic behavior mocking dilemma

We would like our tests to not inappropriately cross over layers of the system (such as accessing the database), and we would like our tests to not be dependent on implementation. Unfortunately, these two concerns are often at odds with one another.

Let's say you are testing this method:

class Foo
def bar
Bar.find( . . .

November 24, 2013

There have been a smattering of solutions offered over the years for getting rid of bundle exec. To me they all have drawbacks -- they either solve the problem at the wrong layer, involve remembering an extra step, require a manually-managed whitelist, or are messy for some other reason.

November 24, 2013

# Why it's a good idea to put a newline at the end of every file

I will today settle one of the great issues of our time: whether or not to always put a newline at the end of a file.There are two reasons why it's a good idea, and zero reasons why it's a bad idea.

Let's consider these files:

https://gist.github.com/4010011

The first reason: when using various command . . .