Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
RubyConf AU 2015: http://www.rubyconf.org.au Starting with the assumptions that, first, we’re all building and maintaining complex applications, because Rails has made that relatively easy, and, second, that application complexity isn’t limited to Rails, this talk walks through a few practical case studies of identifying (or misidentifying) modern application complexity. We’ll delve into my personal anti-pattern goldmine for examples of yesterday’s architecture trend becoming today’s legacy headache, and also look at examples of creative, workable solutions to application complexity!
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 her talk "Service Oriented Disasters," Rachel Myers addresses the complexities involved in building and maintaining modern applications, particularly in the context of Ruby on Rails and service-oriented architecture (SOA). The presentation begins with an overview of code complexity, emphasizing that while starting a Rails application may be straightforward, as it grows, complexities arise that developers must confront. Myers highlights the importance of understanding these complexities fully, especially when making architectural decisions that can lead to sustainable maintenance and scalability. **Key Points Discussed:** - **Importance of Code Complexity:** As applications mature, addressing code complexity is essential. Myers references Sandy Metz’s principles for managing this complexity, such as adhering to the single responsibility principle and refactoring code for readability and reusability. - **Misunderstandings of SOA:** Myers contrasts the popular perception that SOA is a blanket solution for managing application complexity. She emphasizes that uncritical adoption of SOA can lead to its own complications, such as difficult-to-maintain services and inter-service dependencies. - **Case Studies:** - The first case study revolves around "Hats for Spacedogs.com," where attempts to extract a feature related to hat voting led to unmanaged complexity and a failure to properly separate functionalities. This illustrated the dangers of extracting services without fully grasping the existing code. - The second case study involved building an identity service. Here, the service ended up entangled with the main application, creating a situation where both had to remain operational, leading to a single point of failure. - Finally, the dangers of a monolithic application without proper separation of responsibilities are discussed, showcasing how such systems can quickly become problematic. **Conclusions and Takeaways:** - The presentation concludes with the recognition that while SOA can provide benefits, it is not always the ideal solution for managing code complexity in applications. Instead, understanding the code and making informed architectural decisions based on situational needs is crucial. - Myers encourages developers to be wary of over-architecting solutions and to focus on simplicity where possible, reflecting on her experiences and the lessons learned from each case study presented.
Suggest modifications
Cancel
