Links of Interest

A really handy site by Paul Robert Lloyd that provides a variety of tactics and considerations to help when naming something. He also shared the back story on how the site came about. 

Even being aware of this and actively trying to avoid it, I’m sure I still make this mistake all of the time.  

If someone’s been driven to Google something you’ve written, they’re stuck. Being stuck is, to one degree or another, upsetting and annoying. So try not to make them feel worse by telling them how straightforward they should be finding it. It gets in the way of them learning what you want them to learn.

Pretty sure it can’t be said enough. Hopefully this is a reminder that sticks and helps me remember to trim all that garbage out of my writing.

Josh Collinsworth provides a very reasoned view of the Tailwind debate. And the MarioKart smart-steering analogy kind of nails it. As someone who originally loved the theory of Tailwind, using it in practice simply wasn’t for me. I’m simply more comfortable navigating CSS directly. Tailwind isn’t inherently bad, but it’s not my jam. 

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.