Henning Koch is the founder and CTO of makandra, a Rails development shop in Germany. In the rest of world, makandra is mostly known for Rails LTS, a commercially supported fork of Rails LTS. After increasingly failing to stay out of a management at makandra, Henning secretly moonlights as a developer for hollyapp.com.
In this talk we want to propose a humble way to scale Rails codebases. Instead of introducing new patterns or service-oriented architecture, we will show how to use discipline, consistency and code organization to make your application grow more gently. Instead of using new gems we will use the tools built into Rails to accomplish our goal. The tools you already know and love.
When you started doing Rails some years ago, it all seemed so easy. You saw the blog-in-ten-minutes video. You reproduced the result. ActiveRecord felt great and everything had its place.
Fast forward two years. Your blog is now a full-blown CMS with a hundred models and controllers. Your team has grown to four developers. Every change to the application is a pain. Your code feels like a house of cards.
You turn to the internet for assistance, and many solution seem to be available. You should move away from fat controllers, it says. But do avoid fat models. And use DCI. Or CQRS. Or SOA. As you cycle through patterns, your application is becoming a patchwork of different coding techniques. New team members are having a hard time catching up. And you're beginning to question if all those new techniques actually help, or if you're just adding layers of indirection.
You start missing the early days, when everything had seemed so easy and every new piece of code had its place. You actually liked ActiveRecord before it drowned you in a sea of callbacks. If only there was a way to do things "the Rails way" without having it fall apart as your application grows.
This talk will try to show such a way by proposing three guidelines:
Where we propose a universally applicable default design that maps any human-faced interaction to CRUD and ActiveModel. By being consistent in your design decisions we can reduce the cognitive overhead required to follow your code.
Where we show how to organize your code in a way that encourages the creation of new classes. By isolating screen-specific concerns from a slim core model we can reduce the side effects that models can have on other parts of your application.
Where we suggest using before/after code comparisons to avoid being sidetracked by the design fad of the day. We will make a case for adopting new technologies and patterns with care, and take full responsibility for those techniques and technologies you do choose to adopt.
The talk will contain short code samples from actual production code. No bank account examples (promise).
This talk has not been given before, although small parts have been shown to a local Ruby user group.