ce-dhh-rails-style

Core Philosophy

• Rich domain models over service objects
• CRUD controllers over custom actions
• Concerns for horizontal code sharing
• Records as state instead of boolean columns
• Database-backed everything (no Redis)
• Build solutions before reaching for gems

• devise (custom ~150-line auth instead)
• pundit/cancancan (simple role checks in models)
• sidekiq (Solid Queue uses database)
• redis (database for everything)
• view_component (partials work fine)
• GraphQL (REST with Turbo sufficient)
• factory_bot (fixtures are simpler)
• rspec (Minitest ships with Rails)
• Tailwind (native CSS with layers)

• Ship, Validate, Refine - prototype-quality code to production to learn
• Fix root causes, not symptoms
• Write-time operations over read-time computations
• Database constraints over ActiveRecord validations </essential_principles>

1. Controllers - REST mapping, concerns, Turbo responses, API patterns
2. Models - Concerns, state records, callbacks, scopes, POROs
3. Views & Frontend - Turbo, Stimulus, CSS, partials
4. Architecture - Routing, multi-tenancy, authentication, jobs, caching
5. Testing - Minitest, fixtures, integration tests
6. Gems & Dependencies - What to use vs avoid
7. Code Review - Review code against DHH style
8. General Guidance - Philosophy and conventions

references/controllers.md

references/models.md

references/frontend.md

references/architecture.md

references/testing.md

references/gems.md

Naming Conventions

card.close

card.gild

board.publish

set_style

card.closed?

card.golden?

Closeable

Publishable

Watchable

Cards::ClosuresController

• chronologically

  ,

  reverse_chronologically

  ,

  alphabetically

  ,

  latest

• preloaded

  (standard eager loading name)

• indexed_by

  ,

  sorted_by

  (parameterized)

• active

  ,

  unassigned

  (business terms, not SQL-ish)

REST Mapping

POST /cards/:id/close    → POST /cards/:id/closure
DELETE /cards/:id/close  → DELETE /cards/:id/closure
POST /cards/:id/archive  → POST /cards/:id/archival

Ruby Syntax Preferences

# Symbol arrays with spaces inside brackets
before_action :set_message, only: %i[ show edit update destroy ]

# Private method indentation
  private
    def set_message
      @message = Message.find(params[:id])
    end

# Expression-less case for conditionals
case
when params[:before].present?
  messages.page_before(params[:before])
else
  messages.last_page
end

# Bang methods for fail-fast
@message = Message.create!(params)

# Ternaries for simple conditionals
@room.direct? ? @room.users : @message.mentionees

Key Patterns

Card.joins(:closure)         # closed cards
Card.where.missing(:closure) # open cards

belongs_to :creator, default: -> { Current.user }

class User < ApplicationRecord
  def can_administer?(message)
    message.creator == self || admin?
  end
end

Domain Knowledge

references/

references/controllers.md

references/models.md

references/frontend.md

references/architecture.md

references/testing.md

references/gems.md

• Controllers map to CRUD verbs on resources
• Models use concerns for horizontal behavior
• State is tracked via records, not booleans
• No unnecessary service objects or abstractions
• Database-backed solutions preferred over external services
• Tests use Minitest with fixtures
• Turbo/Stimulus for interactivity (no heavy JS frameworks)
• Native CSS with modern features (layers, OKLCH, nesting)
• Authorization logic lives on User model
• Jobs are shallow wrappers calling model methods </success_criteria>

• LLM-generated guide - may contain inaccuracies
• Code examples from Fizzy are licensed under the O'Saasy License
• Not affiliated with or endorsed by 37signals </credits>