Ancient Rails
summary
Aging Rails apps grow from ~20k lines in 2008 to >300k by 2015, with 43% of code older than a year and one third of 2009 code still running, so decisions haunt projects. Real failures include a monkey‑patched Hash/key_grep and a symbol/map extension that collides with Ruby upgrades, a method_missing importer DSL that breaks currying, and a temporary BT flash hash monkeypatch during a Rails upgrade. Favor deliberate patterns and commit-based documentation; build frameworks only after real, cross‑service need.
AI-written summary · about
chapters (14)
- 0:00Start
- 12:32Why is this problematic?
- 14:21Other insufficient reasons
- 19:12What is a good reason?
- 20:41Mitigating Risk
- 23:17Design Stamina
- 23:57Too Soon, Too Late
- 27:43Dealing with Complexity
- 29:54Interface Design
- 32:55Interface Segregation
- 34:41The Sad Tale of Prairie Form
- 37:56Frameworks in a Nutshell
- 40:53Implications
- 41:23Choose Patterns Deliberately
related talks
41mExploring the History of a 12-year-old Rails Application
09mMicrotalk:A House of Cards - The Perils of Maintaining a 7-Year-Old Codebase
32mBuilding HUGE Web Apps: Rails at 1,000,000 Lines of Code
35mTen years of Rails upgrades
32m2000 engineers, 2 millions lines of code: the history of a Rails monolith
01h 05mLegacy Rails Q&A
26mKeeping the Rails Magic Alive After 18 Years
36mWorking Compassionately with Legacy Code