In this article I’d like to discuss two concepts that you might not immediately think to compare. I’ve written previously on keeping your stylesheets modular and also on boundaries in object oriented design, so today I bring the two loosely together.
Rules for Stylesheet Modularity
Keeping applications organised takes a lot of work. Furious bursts of development where deadlines are tight can lead to poorer design decisions. The frontend in particular for me is harder to get right when the pressure is on. I’m writing this post in order to clarify my hard and fast rules for writing modular stylesheets in a rush.
An Argument for Immutable Class Design
If you write code you write bugs. It is a fact of life as a developer. The more code you write, the more complicated it gets and the more likely it will contain bugs. Consider this logic:
ActiveRecord Refactoring: Services
Continuing from my previous post, which introduced the idea of concerns to your models, in this post I will be discussing using services to keep your ActiveRecord’s responsibilities toned down.
Boundaries in Object Oriented Design
As responsible programmers we like to write programs to the best of our ability. As our profession has evolved so too have our languages and the tools we use. We identify around concepts, patterns and principles.
Feature testing with RSpec
We love writing tests at Made HQ. They are part of the foundation on which we work to provide our clients with stable deliveries. We work fast and deploy daily so we test vital paths of our applications using feature tests. We also unit test, albeit less, when we need to cover a range of edge cases.
ActiveRecord Refactoring: Presenters
We’ve discussed using Concerns and Services to keep your ActiveRecords as healthy as they can be. These have dealt with repeated logic in models, and logic that could questionably be placed in either a controller or model. In the third and final part of this series we will be looking at presenters.
ActiveRecord Refactoring: Concerns
ActiveRecord provides a lot of power – if not too much. To that power we add our own business logic to create rather large domain models. Here at Made I’ve started looking at various ways to tone down the responsibilities of my ActiveRecord models using various programming patterns.