Ooh, this is relevant to my interests.<p>(So for those of you who don't know, this is the team behind RailsLTS. I like them a lot but didn't know this was coming down the pipe.)<p>One thing which I've been regretting recently is that I only have exposure to 2 Rails codebases other than the Rails project itself, and as I'm the sole engineer on them, they're... well, awful. I hit the wall somewhere in the 10k or 20k LOrubyC region, and all the "A place for everything and everything in its place" pre-baked Rails architecture decisions started... I don't know if breaking down is the right word, but it became increasingly obvious that I was doing things the software did not want me to do. To avoid certain controllers having 100+ methods I broke them into subcontrollers, used metaprogramming magic to route them all together, etc. I've got about a dozen mix-ins in my Account class (with "helpful" names like Subscriptions, Analytics, Status, etc, such that I can never remember where Account#is_terminated_for_nonpayment? resides). I use way too many hacks to get e.g. a change to app/models/accounts/analytics.rb to re-run both the account and analytics tests.<p>Looking forward to this book, and to any other resources from teams which built Rails applications that started to do a bit of heavy lifting. My experience at my old company is a lot of it is just organic knowledge at places which have 10+ engineers working on the codebase for 5+ years, but unfortunately I've never been in that sort of environment in a Rails shop (and, ahem, may never have that opportunity).