To effectively use any abstraction, you must—eventually—have a solid understanding of what it’s abstracting. I’m calling this the Katz Conjecture because Yehuda Katz made this statement in a conference talk (that I cannot find and hope actually existed). The conjecture has two implications: any abstraction that doesn’t sufficiently simplify what it’s abstracting makes everything worse, and any abstraction you don’t understand is a risk to your project.

iOS has a feature on any website called “Save to Home Screen”, which creates an icon that then goes to that site. If you craft your website a certain way, this will launch the site in an app-like mode that is often referred to as a “Progressive Web App” or PWA. iOS does not support many features of PWAs that are available on Android or ChromeOS, but it supports some. This post will document exactly what you need to do, because it’s not documented very well.

This is a bit of a long post describe the custom toolchain I created—and philosophy behind it—for the books that I’ve self-published. It was created to solve a problem that plagues technical books: keep them updated as libraries and programming environments change. My current solution completely automates all code samples, command-line invocations, screenshots, and many of the diagrams.

Jason Swett asked on Twitter if anyone has an app with 2000+ tests that does not have a severe flaky test problem. I have two such apps, and I want to share the lengths I’ve gone to to make the tests not flaky.

In a nutshell, you have to build and design for testability at all levels, plus ensure your tests are clear about what is the cause of a failure.

Avdi Grimm has created great videos about Ruby called Ruby Tapas, and put up an older one as a video for his new Graceful Dev offering. The video is called Barewords in Ruby and it’s a good demonstration how to make changes to a system without changing a core piece of logic.

While I like how Avdi approaches it, I’d make different trade-offs and make changes that result in code with behavior more easy to predict than code that requires fewer changes. Let’s see.

One of the lowest-effort, highest-value practices you can adopt for sustainable development is to keep your dependencies updates frequently. The foundation for doing so is to have a clear and reasonable versioning policy. This post includes one for Rails apps that I have used for years and has served me and my co-workers well. It has some implications for specific procedures you will adopt as well.

In a nutshell: stay no more than 2 minor versions behind Ruby and Rails, and keep everything else as up to date as you can as often as you can.