johnsbrayton

Unread 5.0 is available. This update adds huge improvements to article list thumbnails, syncing with FreshRSS and Miniflux, and much more.

Unread is an RSS reader with beautiful typography and a variety of color themes. Unread is available for Mac, iPhone, and iPad.

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 in Massachusetts, if that is relevant.

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.

Unread is now available for Mac as well. (Full disclosure: I am the developer.)

BTW feel free to send me feedback directly - [email protected]

I encourage you to try Unread and see if you still feel that way. NetNewsWire is a fantastic app, but the two apps are very different.

Unread is also a free app. Premium features are available with a subscription.

Thank you for trying Unread.

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 am seeing 404s for YouTube’s RSS feeds. I hope this is a temporary bug.

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.