Rails Hurts → Painless Rails

Rails itself doesn't do anything to help programmers organize code in large applications.

If you don't do anything as well, you're screwed up - everything gets intertangled and fragile. The development process, previously agile, becomes clunky.

…but we're aware!

Most of us are aware of the problem and take actions to resist:

  1. We have empirically figured out that certain features of Rails should be avoided, but we're not sure why are they so harmful
  2. We keep our controllers skinny, but this rule turns our models into junk drawers :(
  3. We read about SOLID principles and design patterns, but they barely give any answers. It is not even clear if they are applicable to Ruby and Rails at all
  4. We look for salvation in OOP. Assuming we don't know it enough, we read books from recognized gurus of the industry. But resulting solutions appear to be bulky and not as beautiful as we expect
  5. We introduce additional abstractions to beat complexity, but they bring unwanted overhead and complicate our code

The worst is that everyone has a different approach. Therefore, where you expect to see a more or less unified approach, everyone comes up with its own solution.

Rails community is like ancient Babylon – everyone speaks its own language

This contradicts the central idea of engineering - to develop a single optimal solution for every problem, and to stick to it.

What if there is a simple consistent approach which solves maim problems of Rails applications growth, and it brings almost no overhead?

Painless Rails approach

I am writing a book called "Painless Rails", where I describe such an approach. It has some quite interesting characteristics:

This book is here to help you achieve these things:

  1. Identify and fix most harmful flaws in your current Rails application
  2. Establish a solid foundation for your next Rails project
  3. Learn to look beyond code and realize how to organize concepts, not classes and methods

Meet the book:

Book

Table of contents*

Chapter 1: Controversial smoothness of Rails way approach

  1. Masking complexity with callbacks and conditional validations
  2. Mixing internal with external
  3. Ignoring layers in Rails
  4. Mixing Application Logic and Business Logic
  5. The time-bomb effect

Chapter 2: Painless Rails foundation

  1. Shapes
  2. Services
  3. Mutators
  4. Repositories
  5. Domain Models

Chapter 3: Painless Rails frame

  1. Hierarchy of models
  2. The key part of REST
  3. Hierarchy of controllers
  4. Testing
  5. Service Locator

Chapter 4: Painless Rails approach in practice

* The book structure and titles might differ in the final version

Who is this book for?

  1. You know that vanilla Rails is not enough for big projects
  2. You have tried multiple alternative approaches
  3. You are still not happy with what you get

If all of the above applies to you, then you will not regret buying this book.

Buy it

Button

What do I get?

Expected outcomes

This book is going to help you to:

Samples

1 2 5 3 4

Meet the author: Ivan Nemytchenko

Inem

The roots of the Painless Rails approach

The author of the approach described in the book is Kirill Mokevnin - CTO of Hexlet.io - a major online-learning platform for programmers (not only) in Russia.

Their platform is a six years old Rails application with:

Kirill has managed to develop an efficient approach to web development using Rails, so that through the whole life of the project there were only 1-2 active developers.

I learned about that approach three months ago. The most enchanting discovery for me was that you don't have to fight against the framework. Even if you're introducing additional abstractions.

I was so impressed that I decided to share it with those who love Rails but are not satisfied with what it suggests out of the box today.