(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.)
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.
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).
Comments
Ooh, this is relevant to my interests.
(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.)
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.
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).
Dear makandra: I bought the book on account of this comment. Read about half of it and love it already.
But why is this the first time I heard about the book?
Hey Lorenz. Really glad you're enjoying the book!
We're just starting to get a some visibility internationally, which might explain why this is not all over Reddit and HN already.