はてなブックマーク

Overview Influenced by the experiences I’ve had last over many years of building and maintaining Rails applications, combined with my experiences using other technologies, I’ve developed some ways of structuring Rails applications that have worked out pretty well for me. Some of my organizational tactics follow conventional wisdom, like keeping controllers thin. Other of my tactics are ones I have

What service objects are Service objects and Interactors are fashionable among Rails developers today. I can’t speak for everyone’s motives but the impression I get is that service objects are seen as a way to avoid the “fat models” you’re left with if you follow the “skinny controllers, fat models” guideline. If your models are too fat you can move some of their bulk to some service objects to th

In the model-view-controller pattern that Rails is built on, it’s pretty clear what views and controllers are, but models are a little less clear. In my years with Rails I’ve had the opportunity to come across a number of different conceptions regarding what models are. These conceptions often overlap but often don’t share the same exact contours. Our conception of what a model is is super importa

Reasons to Dockerize a Rails application I had to hear Docker explained many times before I finally grasped why it’s useful. I’ll explain in my own words why I think Dockerizing my applications is something worth exploring. There are two benefits that I recognize: one for the development environment and one for the production environment. Development environment benefits When a new developer joins

Note: I no longer endorse this post, which was a rough first attempt to convey my thoughts on service objects. For my newer take on service objects, see my other post, How I code without service objects. The good and bad thing about Active Record models In the early stages of a Rails project’s life, the pattern of putting all the model code into objects that inherit from Active Record works out pr