My talk on scaling Rails from RailsConf 2016

May 31, 2016

I gave a talk at RailsConf ‘16 called “Can Time-Travel Keep You From Blowing Up the Enterprise”. The talk is really about scaling Rails on a growing team, and attempts to stop the discussion around “monolith vs microservices” by showing how a team can take hold of its destiny.

It’s also the exact way Stitch Fix engineering evolved, and while we have some large Rails apps, none are the monstrosities I’ve seen elsewhere.


Test Behavior, not Configuration

May 23, 2016

I’ve become re-acquainted with the pattern of testing ActiveRecord classes using stuff like expect(parent).to belong_to(:child) and I just don’t understand why anyone would ever write a test like that. It provides no value, and the implementation provided by shoulda isn’t actually testing the behavior. It’s testing configuration.

Announcing Rails 6: An Imagined Keynote

May 17, 2016

Just got back from RailsConf. It was a great Ruby & Rails conference, but I was struck by the dearth of talks about new features of Rails 5—because there just aren’t many. I thought back to what excited me about Rails in the first place—the baked-in conventions, convenience, encouragement of good practices.

Justin Searls gave a talk not about RSpec but about how Rails is losing mindshare, losing favor. Is Rails losing relevance? I hope not, but it’s easy to see how someone less emotionally invested than me might see it that way.

I’m trying to write about this without complaining. This is my fifth attempt. It’s hard not to just rant about Rails’ failings, so I’m going to try to be constructive by outline a fantasy roadmap for Rails 6.

I tried very much to think about this without going against the “Rails Doctrine”, and have written this as if it were an Apple-style keynote. The theme is Progress.

The 'Type Wars' Are Far From Over

May 03, 2016

Uncle Bob penned an interesting piece called Type Wars. It’s ostensibly a history of the fashion around how types are handled in programming languages. It, unfortunately, comes to the conclusion that “TDD and unit tests means you don’t need statically-enforced types”. This is not true.

He initially describes how C had types, but they weren’t enforced at compile- or run-time. This is bad (he says and I agree) and then talks about two ways to enforce type safety (i.e. require that the you are using the correct types). In Java, the compiler requires it or the code won’t even run. In Smalltalk, the runtime requires it only at runtime. And, according to Uncle Bob, the latter is preferable because you have unit tests. This is not true (he also overstates the burden required in having types enforced at compile time—just because Java is terrible doesn’t mean the concept is).

In particular, he creates a false equivalence between unit testing and static type checking:

You don’t need static type checking if you have 100% unit test coverage.

Not true.