This is a series of posts about why I recommended the changes I did for Rails 6, in my imagined keynote for Rails 6.

In this one, we’ll explore why I think having explicit support for creating non-model service objects would be a good thing.

This is a series of posts about why I recommended the changes I did for Rails 6, in my imagined keynote for Rails 6.

In this one, we’ll explore why I recommended changes that encourage a more resource-based design.

This is a series of posts about why I recommended the changes I did for Rails 6, in my imagined keynote for Rails 6.

In this one, we’ll explore why I recommended the removal of jQuery, and the change from CoffeeScript to ES6.

This is a series of posts about why I recommended the changes I did for Rails 6, in my imagined keynote for Rails 6.

In this one, we’ll explore why I recommended the removal of per-view CSS and the inclusion of an “OOCSS”-style framework.

In my imagined keynote for Rails 6, I imagined a lot of wacky new features for Rails. My Rails 6 had lots of big changes, and I thought it might be interesting to dig into why I think those changes are useful for Rails.

Getting configuration from the UNIX environment is a hallmark of 12-factor application design, and is a great practice. Problems arise, however, when your code is littered with direct references to it. This is because the UNIX environment is a very poor database, but we need to treat it as a better one.

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.

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.

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.