An Alternative View on Avdi's Barewords Video

November 21, 2022

Avdi Grimm has created great videos about Ruby called Ruby Tapas, and put up an older one as a video for his new Graceful Dev offering. The video is called Barewords in Ruby and it’s a good demonstration how to make changes to a system without changing a core piece of logic.

While I like how Avdi approaches it, I’d make different trade-offs and make changes that result in code with behavior more easy to predict than code that requires fewer changes. Let’s see.

Your Rails and Ruby Versioning and Gemfile Policy

November 17, 2022

One of the lowest-effort, highest-value practices you can adopt for sustainable development is to keep your dependencies updates frequently. The foundation for doing so is to have a clear and reasonable versioning policy. This post includes one for Rails apps that I have used for years and has served me and my co-workers well. It has some implications for specific procedures you will adopt as well.

In a nutshell: stay no more than 2 minor versions behind Ruby and Rails, and keep everything else as up to date as you can as often as you can.

RSpec Examples are, well, Examples

November 09, 2022

RSpec’s internal DSL allows creating some difficult-to-sustain structures and code, but there is one guiding principle that has helped me avoid making tests that are too weird:

RSpec tests should be examples of how the code under test would be used.

Let’s see a few examples: using subject and avoiding predicate matchers.

Wrap Third Party APIs in Service Wrappers to Simplify Your Code

October 31, 2022

The app I work on has a lot of API integrations. These API calls are often tied into various business processes. By wrapping an adapter around each API, presenting only the features of that API my app needs, I can more easily manage and test my app. It also provides clear documentation about how my app uses each API. I’ve heard this called a service wrapper and it’s incredibly useful.

How I Use Tachyons for CSS

October 28, 2022

I’ve long come to prefer the “functional” style of CSS, where each class represents a single CSS property set to a single value. I learned this from Adam Morse, author of Tachyons, which is a older framework, but it still checks out. I’m not here to advocate for this style (read Adam’s post for that), but to talk about how I use SASS to create higher-level re-usable styles with Tachyons, achieve the best of all worlds when managing CSS, all without some unstable, unfriendly JavaScript toolchain.

Actual Reasons to Use Test-Driven Development

September 06, 2022

Test-Driven Development is often sold as a way to be more productive or produce better designs, but it’s these unprovable claims that make skeptics even less likely to adopt the practice. Instead, TDD should be sold as a tool to reduce the risk of software not working as intended without expending huge amounts of effort and time doing so. Because that’s what it does (yes, it’s about testing).

A Framework for Product Design Beyond the Happy Path

August 15, 2022

Product design—really all of design—is about how the user’s problem is solved. It’s about how it works, not how it looks. Each problem gets addressed in one of five ways: direct support via the happy path, a supported edge case, the customer support team, the engineering team, or oblivion (where it is not actually solved).

Inexperienced designers focus entirely on the happy path, whereas most product designers focus only additionally on edge cases. Even then, the lack of involvement from engineering and customer support can leave the design woefully under-developed.

This post outlines a slightly structured model for thinking through a product design inclusive of the entire user experience, including customer support.

The Four Stages of Testing That Help Your Focus

August 04, 2022

When writing tests, it’s useful to consider that the tests are always in one of four distinct stages, and knowing which stage they are in can direct your next steps. This can make testing a bit less painful than it might otherwise be.

The four stages are:

  1. The code doesn’t compile/build/parse
  2. The tests produce an error (as opposed to a failure)
  3. The tests are failing
  4. The tests are passing