I distrust Cloudflare so much. I have been trying to get my RSS reader on their Verified Bots list for years, but their application form appears to go nowhere.
This is interesting. But I’ve never once even noticed a police officer touching my car’s tail lights when I have been stopped. I am wondering if I was just oblivious or if it does not happen everywhere.
I am sure there are rewrites that were necessary or beneficial. But I think it’s fair to say that usually they are a mistake.
And a lot of “bad code” comes from starting to write clean code and then coming across a variety of assumptions that prove incorrect, and real-world considerations that add complexity.
I am considering an option to use system standard fonts.
Unread respects night mode, and lets you set one theme for light mode and another for dark mode. I do not have plans for a Mac default theme.
The handling of summary-only feeds: Unread can retrieve the article from the webpage and show you webpage text. You can switch between feed text, webpage text, or both for any article. Unread lets you make that change apply to all articles from that feed. Unread even tries to figure out which feeds are summary-only, and sets the default display mode to webpage text when it is.
I do squash merges but keep the feature branches. So after determining that I made a change as part of a big pull request, I can then look at the commit/blame history for the pull request source branch if necessary.
I wish I did. My approach is that I have a ruby script that runs every five minutes and does a bunch of tests. The script takes a couple minutes to execute. It connects to servers via SSH to check things out, does end-to-end-tests, then it writes its result to a JSON file.
It runs on a Linode instance with a webapp whose sole responsibility is to respond to Pingdom requests. There are two URLs that Pingdom looks for: one that returns a 500 if the JSON file indicates an issue that warrants texting me. A second that returns a 500 if the JSON file indicates an issue that warrants emailing me for a lower priority issue. Pingdom is configured accordingly.
If for any reason the JSON file has not been written in the past 10 minutes (?) or cannot be read and parsed, both URLs return a 500.
The script has a log file, so when I get an alert I can check the log file to determine what is wrong.
This is likely atypical, but it works really well for me. My scripts do the work of monitoring the heck out of everything. I only need Pingdom (or a service like it) to monitor two URLs and do the texting/emailing.
But my overall approach is to think of monitoring like unit tests or integration tests: when I think of something that could go wrong, I try to make sure there is monitoring that can detect it and alert me. When possible, before it becomes urgent. And when something does go wrong that is not automatically detected, it's a high priority to add monitoring around that.
Great article. While it mentions monitoring, it took me a long time to appreciate how beneficial it is to do monitoring really well. Things like:
• Knowing when disk space, inode usage, or memory usage get high, long before it’s an emergency.
• Automated monitoring of SSL certificate expiration dates, letting you know days before a certificate expires. Whether or not you use something like certbot, have a separate process that automatically tells you a certificate is close to expiration.
• Automated periodic end-to-end testing of moving parts. Like if you run an email server, a process that sends something from your server to a gmail.com address, and then checks the gmail.com inbox to find the message.
• Automated periodic testing that unexposed ports remain unavailable from outside the device or private network.
• Automated checking that a Linux instance is successfully checking for and installing security updates, and is not waiting for a reboot.
• Automated checking that backups are working as expected. You might not be able to automate periodic restore testing, but at least check that backups do not appear to be silently failing.
• Separating out low priority alerts from high priority alerts. You want to get woken up when necessary, but not for an issue that can wait until you are at your desk.
Ballot boxes that scan ballots are auditable because they keep the paper ballots.
In my state, election workers have to ensure that the number of ballots is the same as the number recorded by the ballot box on election night - although we don’t recount who voted for who. The ballots are preserved.
If you aren’t already doing this: keep customer support email out of your personal/business email.
I access customer support email via Fastmail’s web interface. I check it several times a day, but only from my computer (not my phone) and only when I am in the right frame of mind. This helps me a lot.
I mostly nodded as I was reading your advice. I particularly appreciate that you recommend including full article content in feeds, not changing entry IDs, and adding discovery `link` elements to HTML pages.
I have some complex logic to find a hero image that is sometimes in a feed entry outside the HTML, and prepend it to the top of the article -- but only if there is not another reference to that image in the article. It is complicated because sometimes there will be hero-image.jpeg in the article and hero-image-1200x500.jpeg outside the article, and I have to judge whether the images are the same.
I am in favor of embedding the image into the HTML, and not adding it elsewhere.
I am not sure I agree with this for complex webapps. But I do see many brochure websites and news websites that incorporate megabytes of JavaScript and CSS to display text — and I wonder why all that client-side code is necessary.
Most also only ever go through a small number of real estate transactions in a lifetime. If it’s your first or second purchase or sale, the agent is worth it. On your third or fourth maybe not — but how many buy more than two or three properties in a lifetime?