Links of Interest

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.

This is a really interesting exploration of an idea for a more concise ERb alternative by Kasper Timm Hansen. HAML and Slim have never felt appealing to me because they feel like they blur the lines between markup and back-end code, but a less-verbose approach to ERb sounds fantastic. 

ERB tags <% %> and <%= %> feel so noisy, having to add %> a Ruby line feels as if I’d had to write ; to end my Ruby lines. So what if we had a simpler syntax that can figure out how to auto-close for us.

Even if it never goes anywhere or sees wide adoption, just seeing this kind of exploration and experimentation with fun ideas to make the Ruby ecosystem even more pleasant is exciting and encouraging.

A good post by Matt Brictson showing the resilient approach for broadly handling exceptions in rails apps using rescue_responses instead of handling cases one-by-one closer to where they happen. And as an added bonus, Rails will correctly render either the static error page or an appropriate JSON response depending on the request. 

A bunch of good insights about both Thor and Rake quirks that matches up pretty well with things I’ve been finding as I go deeper into the world of Thor and Rails Generators. 

Stephanie Eckles shares her CSS Day presentation about modern CSS development strategies that are available now and will be broadly available in the near future.  She covers CSS reset additions, nesting selectors, cascade layers, theming, layout utilities, and several other topics that expand on some exciting ideas for organizing CSS by taking advantage of all the modern improvements.

Your app should work in a read-only mode without JavaScript. 

Per usual, Jeremy distills things down to simple and unobjectionable points. So many of the arguments against progressive enhancement seem to follow the the thinking from when we collectively believed that sites should look the exact same in every browser.

Progressive enhancement isn’t either/or. It’s a helpful spectrum where the more functionality that can be accessible without JavaScript the better, but just because it may not be pragmatic to have everything accessible without JavaScript all the time, there’s plenty of ways to ensure information can still be accessible without massive engineering efforts.

A free 15 min daily stretch routine to help desk workers avoid aches and pains 

Getting older and sitting too much has increasingly felt more and more painful. This felt like a great way to remember to take a stretch break and covers most of the stretches I’ve been trying to work into a morning routine. I set it to my home page for new browser windows to see about getting the routine to stick.

I haven’t shared anything about the inner workings of my recent site update, and I’m not planning on it. However, supporting a “Site Fidelity” option inspired by Jim Nielsen is one of the little things I’m more excited about. 

It’s a sort of hybrid “progressive enhancement” demo meets “a perpetual option for CSS Naked” that provides both a handy feature for some visitors and a constant reminder to always keep things as simple and semantic as possible.

Some interesting and fun exploration here by Robin. The Details element is one I haven’t built for with my site update, but there’s certainly some good opportunities to use this more in the future. 

Play is a key component of the arts and aesthetics in myriad ways. Art and play are like two sides of the same coin, with play being a part of artistic expression, imagination, creativity, and curiosity. Though it often gets buried in adulthood, the urge to play exists in all of us. It has been a major part of how we’ve evolved as a species. 

Daniela Baron writes up some great advice and a thorough list for thinking about documentation on a project.   It’s one of those where you find yourself aggressively nodding along, but there’s one that really stuck out because it feels so often overlooked. So often, people focus on well-written code not needing extensive documentation, and that can be partial true in terms of understanding what the code is doing.

Good names and understandable code can’t, however, explain the why of how a certain section of code is written. We talk about making sure code can be intention-revealing, but it’s never going to be able to communicate the state and context of the project at that specific point in time and how that informed the approach.