Benjamin Smith is a developer at Pivotal Labs. He has a strong passion for TDD, pairing, Agile and using technologies that get out of the programmer's way. When not writing code, he follows his other passions into the outdoors to rock climb, back country snowboard, kayak and surf.
Rails is a great framework for creating web apps... for awhile. What do you do when your codebase grows large? How do you handle large teams of developers? When performance becomes an issue, how do you scale? Most importantly, how do you write code which can easily be refactored later?
This is a story of a real life project built from day 1 with all these questions in mind. Learn about the problems we solved and lessons we learned: how to partition your Rails app into distinct modular engines, how to speed up your test suite by only running code effected by your changes, how to add a layer on top of ActiveRecord to enforce loose coupling, and many other patterns that can be applied to your own Rails apps!
My talk is from the perspective of a brand new Rails app, but all of the patterns and techniques can be applied to existing apps. However, I believe applying them to any and all new Rails app is a bad idea and would be premature optimization.
The app I worked on was... special. It was a rewrite of an existing app, and we had a good idea of the direction we were going to be headed: large codebase, lots of developers, high performance, and easily extensible. We almost coded with the fear of where we'd end up in 6-12 months of zero architecture. As such, we did more architecture up front that I would have ever felt comfortable with otherwise. The result was an extremely well factored codebase that was consistent and easy to work in.
My vision for this talk, is that people would come away with various patterns that they could apply to a new app, or an existing one if they are feeling some pain that the pattern solves. I would strongly suggest not following any of my patterns until you feel the pain of not having it, or are extremely confident that you will experience it in the future.
I will update the abstract to explicitly state that the information from this talk can be applied to new or existing apps. Thanks for the feedback!
I'm really interested in this. I've worked on projects where we've felt the pain of not thinking about how the project will feel in a year or so, but I've also worked on projects where we've felt the pain of thinking too hard from the beginning and getting it painfully wrong. There's loads of theoretical advice out there, but a lack of practical "do this, then do this, don't do that" advice, so if you can ground this talk in advice taken from real-world projects that would be great.
One thing I'm left wondering - am I right in thinking this will be of most use for people when they start their next new rails app? I suspect most people in the audience will probably have an existing app that would benefit from some re-architecting right now; will there be anything for them? There doesn't have to be, but I do think making that explicit in the description would be useful.
Thanks for the feedback. I'm always happy to talk about these topics! If the talk doesn't get accepted, feel free to track me down and pick my brain.
Now, it's super - you got my +1! I find the topic really interesting and I would really like to discuss it in person anyway :)
Using swear words makes the title provocative but not in a positive way. I'm actually put off by it instead of being intrigued. To bad, because the problems with large code bases are real and I would also be interested in your definition of large.
The title of this proposal is using language that's not appropriate for the event. Can you please refine it? If not, we may have to disapprove the proposal and that's a shame cause the topic is rather interesting.