440: When we stray from Rails defaults

8 snips

Sep 17, 2024

Joël, a seasoned software developer, and Stephanie, an expert in Rails conventions, delve into when it's necessary to diverge from Rails defaults. They discuss the complexities of customizing Rails and the benefits of using dry-rb objects in projects. Stephanie shares her insights on leveraging callbacks effectively, while Joël reflects on a large-scale refactoring initiative and lessons learned from legacy code issues. The duo also examines the tradeoffs of different testing frameworks and the importance of the ActiveModel ecosystem for better code development.

Ask episode

Chapters

Transcript

Episode notes

Intro

00:00 • 2min

Navigating Project Dependencies

02:17 • 4min

Reflections on Project Improvements and Coding Lessons Learned

05:52 • 5min

Navigating Class Name Changes

10:35 • 9min

Decoupling Rails and React: Best Practices

19:37 • 16min

Exploring the Dynamics of RSpec and MiniTest in Testing

35:53 • 3min

The Value of Rails Conventions and Active Model Integration

38:39 • 4min

When does it make sense to step away from Rails conventions? What are the limits of convention over configuration? While Rails conventions provide a solid foundation, there are times when customization is necessary to meet specific project needs. In this episode, Joël and Stephanie dive into the tradeoffs of breaking away from Rails defaults. They explore the limits of convention over configuration and share their experiences with customizing beyond the typical Rails setup. Joël offers insights from a recent project where the client opted for all dry-rb objects, and they unpack the benefits and potential challenges of this approach. Stephanie talks about why people tend to shy away from certain Ruby features and her lessons regarding leveraging callbacks for code development. Explore different testing frameworks, the situations when following Ruby defaults is better, the benefits of the ActiveModel ecosystem, and more! Whether you are a Rails purist or looking to bend the rules, this episode will help you understand the pros and cons of stepping outside the Ruby on Rails box. Don’t miss it!

Key Points From This Episode:

Joël shares details about a large-scale refactoring initiative he has been working on.
Stephanie’s recent legacy-code production problem and lessons from her experience.
What Joël would have done differently when building his refactoring initiative.
The problems of renaming background applications during code development.
Why the open-close principle is valuable for making class changes to a system.
Reasons that a migration strategy is vital for navigating new and legacy code.
Explore approaches for overcoming synchronization issues between systems.
Learn about the concept of connascence for coupling systems together.
Considerations for using asynchronous tools with a connascence approach.
Practical ways to maintain naming consistency during code development.
The importance of differentiating between web and business-logic layers.
Situations where relying on callbacks for connascence becomes problematic.
Other issues that callback problems can reveal during code development.
Joël unpacks the scenarios where he deviates from the Ruby on Rails standard.
Frameworks for testing code and final takeaways from Joël and Stephanie.

Links Mentioned in Today’s Episode:

'Refactoring Legacy Code with the Strangler Fig Pattern'
Connascence of Name (CoN)
ActiveModel docs
GitHub | activemodel
'Vanilla Rails is plenty'
GitHub | minitest
GitHub | test-unit
Episode 435: Cohesive Code with Jared Norman
Ruby on Rails The Bike Shed
Joël Quenneville on LinkedIn
Support The Bike Shed

Support The Bike Shed