Howdy, and happy Friday.

I’m very bullish on the potential of feature flags, but I’d be remiss not acknowledging that they also introduce potential issues that require caution. I even got tripped up with a small oversight, but these are the kinds of mistakes that help reinforce that some basic guardrails can help. Fortunately, that’s precisely what we’ve been working on. 

Having spent a non-trivial amount of time tuning a less-than-perfect solution for sidenotes here on this site, I love Eric’s solution for anchored positioning of sidenotes. All of the techniques he’s shared from building The Effects of Nuclear Weapons have been some of my favorite pieces of writing about front-end development in the last couple of years. 

Lots of solid improvements to Rails coming down the pipe. While there are some larger improvements, the little improvements help make several common patterns less tedious. The authenticate_by method provides protection against common timing attacks. The generates_token_for declaration streamlines the process of managing single-use tokens. And has_secure_password can now automatically verify the current password when performing updates by providing a password_challenge attribute on updates. 

We recently finished up a moderately-sized improvement to Flipper that likely would never have seen the light of day if we couldn’t have easily thrown it behind a feature flag. Being able to test drive it in production and work on iteratively helped ensure it kept moving along even though it was on the back burner in terms of priorities. 

Wrote up some details about how we used feature flags to add the Free Cloud option (a large, far-reaching change) to Flipper over the course of about 20 pull requests and releases. 

…feature flags are about letting teams separate the process of releasing new features from the process of shipping code. When shipping code, frequent small changes reduce risk dramatically, but for features, we often need a large amount of code to change all at once. With these two elements at odds, de-coupling one from the other enables better workflows at every step of the process.

It helped maintain steady momentum at at time when none of us were working full-time on Flipper. We were able to catch smaller issues earlier, and once it was finished, we even flipped the switch on a Friday afternoon without any major problems.

I’ve been working part time with John, Brandon, and Steve on Flipper Cloud the last few months, and then we decided to make it a full-time thing. We’ve been working on a ton of stuff to make feature flags more powerful and less painless to manage, and cutting 1.0 and offering a free plan for Cloud is just the first step. 

Good post by Jim Nielsen about accessibility and disability. Even as an amputee, there’s days where it doesn’t limit me at all, and there’s days where it destroys me. It’s a spectrum and constantly shifting.   And Cindy’s quote has always hit hard both before and after amputation…

We’re all just temporarily abled.

The most fundamentally confusing thing about teams overlooking accessibility in software is that good accessibility is fundamentally good design. It’s not purely about inclusion—although that is certainly a key element.

It benefits everyone both directly and indirectly to varying degrees throughout our lives.

A good overview of autoloading in both Ruby and Rails that goes into just enough detail to help it all make sense without getting bogged down in the deeper inner workings. It’s definitely one of those features that easy to take for granted until trying to build something in a language or framework that doesn’t offer autoloading.   If you’ve ever wondered about the differences between Classic autoloading and Zeitwerk, the second part does a great job explaining the differences.

Adrian Roselli puts together a thorough and insightful examination of how various screen readers announce some of the common patterns used for marking up blockquotes. I’ll definitely be revisiting my approach to blockquotes here on the site based on his findings and reasoning.  

What works for you may be different. However, I definitely recommend against using <figure> with <figcaption>. Enough that I adjusted the advice for <blockquote> at MDN. It is unnecessarily verbose in NVDA, JAWS, Orca, and macOS VoiceOver.

I found it particularly interesting that the cite attribute can be skipped entirely due to the fact that no screen readers use it and JAWS creates more noise by reading the URL out loud. I also learned there’s no meaningful connection between the cite attribute and the <cite> element.

Terence Eden gives us a thought-provoking experiment on making a site accessible only by keyboard. 

Now, should you do this? No. It is silly. Reducing accessibility like this is never a good idea. But it is a fun experiment.