I Know I Can, But Should I?
You can use a hammer to drive a screw into wood, but I’d recommend a screwdriver. Why? And when is a hammer the better option? This talk will propose a framework to use when comparing alternative technical choices. I won’t decide for you, but will leave you with a structure to apply in your decision-making process.
The ruby toolbox is vast. While Rails provides a default experience, it leaves plenty of room for alternatives. In learning how to do something, you may uncover different ways to accomplish the same goal. Determine which tool fits best in your situation with these lessons.
The Rails Doctrine frequently speaks to the breadth of options available at your disposal within the framework. There are many sharp knives in ruby that, when used judiciously, can facilitate a great result for your product, your team, and your code. However, knowing in which situations to reach for one tool, technology, or architecture when the framework supports many paradigms is difficult. Having the option to make substitutions is liberating, but imposing.
Some groups or situations may demand rigorous up-front evaluations prior to determining a solution. While those exercises can inform our choices, a lighter-weight approach is more appropriate in most decisions we make on a daily basis as developers. When presented with multiple options that will solve a problem, the following criteria are helpful to consider:
- What impact does this have on the code, the product, and the team?
- What cost and risk will be incurred by introducing this solution?
- How will this be maintained over time?
- Has the team encountered something similar to this before? What was the result?
Not all of these questions may be applicable in all situations, and the relative weight of one over the others will also vary, depending on the context of the team or the problem.
The latest iteration of the slides that accompany this presentation are available here in this repository. The slide deck in this repo is in macOS's Keynote format.
The presentation uses various snippets of code to illustrate how the different criteria proposed for evaluation can be used to determine the relative benefit of one alternative vs. another. All of the code samples in the presentation have been built out as part of a rails app in this repo. Below you can find references to relevant commits that introduced the code used in the presentation.
- Limit access to create resource via conditional
- Limit access to create resource via 3rd party authorization library
- View data collection event date using rails timestamp
- View data collection event date using named attribute
- Warn user about consequences of editing personal information