Maintainable Ruby on Rails
summary
Rails apps near a decade of production and slow down because past design decisions create maintenance drag; concrete remedies include preferring convention over configuration, avoiding runtime code generation, deleting unused features, and paying down technical debt continuously with the Boy Scout rule. Tests act as sensors for coupling and slow/fragile tests point to problematic design. Watch for tight coupling to a specific DB (raw SQL, ActiveRecord specifics), weigh RSpec vs Test::Unit costs, and apply SOLID/object‑oriented patterns.
AI-written summary · about
chapters (18)
- 0:00Intro
- 0:43Presentation
- 3:49Pacman
- 5:41Rails Apps
- 8:20Status Quo
- 8:51Craftsmanship Movement
- 12:21Steve Simmons
- 15:54Templates Views
- 17:49Convention Violations
- 19:56Generating Code
- 20:59Users
- 21:46Technical Debt
- 23:24Listen to your tests
- 24:13Design patterns
- 24:59Coupling
- 25:43ObjectOriented Design
- 26:04Rails Book
- 26:22Outro
related talks
01h 05mLegacy Rails Q&A
44mBuild to Last...
09mMicrotalk:A House of Cards - The Perils of Maintaining a 7-Year-Old Codebase
35mA Tale of Two Codebases
28mRESCUE SQUAD: Rails Edition!
31mAn Optimistic Proposal for Making Horrible Code... Bearable
42mThe world runs on bad software
29mUpgrading Rails at Scale