# Monitoring connection quality of Amtrak wifi vs. phone tethering

Kudos to Amtrak for having free Wi-Fi. But the network quality is dependent on a mobile data connection, which varies throughout the trip. Meanwhile, I also have tethering on my phone.

One might guess that the connection quality would be pretty much identical between the two, since they both rely on similar or the same networks over . . .

July 18, 2014

# 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 02, 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( . . .

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.