Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
Mega Rails by: Jack Danger Canty Square manages big data, high uptime, secure payment info and large teams in an agile Rails environment. It's hard. Our system has outgrown the patterns of a young Rails app and some of what used to help has started to hurt. It's painful to have your email templates in the same project as your API backend. It's agonizing to use your main datastore for analytics, and it hurts to throw code into ./lib or require unnecessary gems. This talk is about how we've turned individual Rails pieces into separate services and scaled our codebase, data, and integration testing practices to support multiple big teams efficiently.
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
In his talk "Mega Rails" at GoGaRuCo 2012, Jack Danger Canty from Square discusses the challenges and solutions for managing large Rails applications as they scale. The primary theme revolves around the evolution of Rails apps from small beginnings to complex structures that often lead to technical debt and team dissatisfaction. Canty emphasizes two main takeaways: - **Rails Application Growth**: As a Rails app matures, it often becomes a 'monorail'—a large, monolithic codebase that is difficult to manage. He illustrates this growth by describing the transition from a simple application to one with numerous controllers and issues related to slow testing and developer morale. - **Management Issues**: Canty highlights the lack of ownership among developers as a key issue when working with large codebases. With ownership, teams can better manage their products, experience satisfaction from their contributions, and respond to incidents effectively. In discussing specific pitfalls, Canty warns against: - **Tying email templates to the API backend**: This creates a tangled codebase that slows down feature development and complicates the deployment process. - **Using the main datastore for analytics**: It can be detrimental when your primary application database also serves analytics needs, as it affects performance and manageability. - **Over-reliance on Rails defaults**: While Rails is great for rapid development, it often leads to shortcuts that generate technical debt, such as putting too much functionality into controller methods without thinking of long-term maintenance. Canty presents examples from the challenges faced at Square, urging developers to adopt a three-step process to combat these issues: 1. **Build Service Interfaces**: Internal APIs should be established to facilitate easier separation of components as the application grows. 2. **Prepare for Team Scaling**: When the time comes, replicate or clone code to retain functionality without modifying core systems directly. 3. **Manage Data Better**: Split databases for different functionalities to improve application performance and responsiveness. Ultimately, Canty advocates for building conventions around code ownership and modularization to maintain developer happiness and cultivate healthy agile practices in large Rails environments. He concludes by emphasizing the importance of shared experiences among developers to navigate the complexities of large codebases efficiently.
Suggest modifications
Cancel
