This version of Vestibule is read only. It represents an archive of the community effort to produce content for Ruby Manor 4.

Think Outside the Framework

updated over 4 years ago; latest suggestion over 4 years ago

Frameworks are designed to solve common problems, not problems specific to the domain of an application. A framework simply is a tool that helps developers to maintain focus on domain-specific problems by providing them with solutions for common problems they encounter when building an application. Solving complex domain-specific problems, however, requires developers to think outside the scope of a framework. Technology can easily be a limiting factor. Poor software design is often the result of trying to fit a solution to domain-specific problem into a framework that was never designed to solve this problem. Clearly knowing the boundaries of the framework in use or more generically the overall technology in use helps developers to build better applications. Good software design is about choosing the right method to solve a problem. This starts with thinking about a problem in terms of its domain and not in terms of the application's technology stack. Using Rails as an example, not everything is a model, a view or a controller.

The Talk

The aim of this talk is to teach developers the mindset required to build well-designed applications. To establish common ground, the talk starts with brief a discussion of the key aspects of good software design. The main part of the talk is about the design of a modular, lightweight, component-based view layer. However, the presented example merely serves as a foundation to explore different object-oriented software design principles. The talk focuses on the following aspects of software design:

  • object collaboration through messaging,
  • loose coupling through well-designed interfaces,
  • single responsibility, and
  • semantic abstraction through layers of indirection.

The overall goal is to show that software design requires developers to think outside the scope of the applied technologies. The talk is meant to encourage creative thinking when working on complex problems.

Suggestions

  • The proposal author responds over 4 years ago

    Thank you, James, for your suggestion. It would indeed be possible to focus on only one of the bullet points. In this case, I would set my focus on semantic abstraction which is the result of good software design. My goal is to motivate fellow programmers to really think about this topic, so I think it would be best to present what you can gain from good software design – how it increases the productivity and mitigates frustration when working on a codebase that has a thought-out design.

  • Acd62030df551952268e84c8fff26a5b James Adam suggests over 4 years ago

    My main concern with this talk is that it feels really ambitious, with a huge scope, and thus very difficult to treat properly in the 30-minutes-or-so slots that are likely at Ruby Manor.

    I wonder if if there's any way to just focus on even one of the four bullet points you've got so far?

  • The proposal author responds over 4 years ago

    There will be a real-world example. Meaning, I will not use cars or bicycles to explain the topic. Instead, I'll present technology that was developed to modularize certain aspects of large Rails applications. Most of this technology is open source, actively maintained by myself and available as a gem. However, not all of the presented ideas have made it into separate libraries. My goal is not to present yet another library you can plug into your Rails application. Instead, I'll focus on the design decisions that have been made during the development of this library and why it has been developed in the first place. Teaching the right mindset to accomplish good design will be at the center of the talk.

  • E257c5fb15b33c01a4c9373ccb549c87 Tim Ruffles suggests over 4 years ago

    This sounds like a good talk - would it be concrete? Architecture/design often feel a bit vague to me without a worked example - especially considering the complexity/verbosity trade-offs inherent in SRP and indirection.