← ClaudeAtlas

rails-philosophylisted

Core philosophies, design choices, and tacit knowledge underpinning 37signals-style Rails development
mickzijdel/rails-toolkit · ★ 0 · AI & Automation · score 70
Install: claude install-skill mickzijdel/rails-toolkit
# Rails Philosophy The foundational principles behind this style of Rails development, distilled from 37signals/Basecamp's approach. > "We aim to write code that is a pleasure to read, and we have a lot of opinions about how to do it well. We care about how code reads, how code looks, and how code makes you feel when you read it." --- ## The Principles ### 1. Vanilla Rails Is Plenty **The Belief:** Rails provides everything you need. Resist the urge to add layers of abstraction: no service objects wrapping simple operations, no repository pattern over ActiveRecord, no CQRS for typical apps, no dependency injection containers. ```ruby # Over-engineered class CreateCardService def initialize(board, params, current_user) @board = board @params = params @current_user = current_user end def call Card.create!(@params.merge(board: @board, creator: @current_user)) end end # Just use Rails @card = @board.cards.create!(card_params.merge(creator: Current.user)) ``` **The Test:** If you're adding an abstraction, ask: "Does Rails already solve this?" Usually, yes. ### 2. The Model Is the Domain **The Belief:** ActiveRecord models aren't just database wrappers — they ARE your domain. Business logic lives in models with intention-revealing public APIs (`card.gild`, `card.close`); controllers invoke model methods, they don't orchestrate operations. See [[rails-controllers]] Pattern 8. ### 3. REST Everything **The Belief:** Every operation can be modeled