Howdy, and happy Sunday.

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.