Journal
Fleeting thoughts, evergreen articles, and links to intersting stuff from around the web. And it’s all here all in one convenient chronological list. You can also browse by topic if you’re looking for something speciific.
Recently
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.
*, *:hover { cursor: none !important;}
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.
Creating your first custom Rails Generator can feel counter-productive at first, but with a little knowledge and experience, they can become a powerful tool to help you and your team save time.
I’ve long been on the lookout for a search engine that would let me filter out sites that I’ve found to be more noise than signal. After a little over a month of paid use, I’m feeling cautiously optimistic about Kagi.
I built an automated tool to inspect and document all of the available methods in a set of Ruby classes and modules in order to answer questions and provide data and insights that would help explore and recognize patterns and concepts with Rails Generators.
Sometimes, our model columns/attributes are really their own objects in disguise. Frequently, they’re whispering to you that they want to be their own objects with their own tables.
Someone once told me that radio stations never set out to play the best songs. They only want to play the songs that will make the fewest people change the station. He went further and said that they actually use polls for to figure this out. That is,…
Brains and habits are weird. Sometimes even the most insidiously tiny bits of friction deter our best intentions, and it can be worth it to make something just a little bit easier in order to make it happen. Often, it only takes the smallest change in the right place in order to reset and rebuild.
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.