51 karma · joined December 27, 2012
Unread is an RSS reader with beautiful typography and a variety of color themes. Unread is available for Mac, iPhone, and iPad.
I am in Massachusetts, if that is relevant.
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 also a free app. Premium features are available with a subscription.
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.
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.
• 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.
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.
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 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.
That said, the title could have been chosen more carefully.
The guidelines I outlined don't work well if retrieving the CSS requires a subsequent DNS lookup. One could argue that serving CSS from the host that serves the HTML is a good idea, but there are other tradeoffs involved.
It would be better to do the following:
1. Have only one or two external CSS files per page.
2. Serve CSS compressed when possible.
3. Ensure that CSS does not require any server-side processing or compression, that the server just spits out a .css or .css.gz file when the CSS is requested.
4. Ensure that the CSS files are relatively small.
5. Serve the CSS files with a very long cache time and with a version/hash string in the object name.
6. If feasible, make CSS changes relatively relatively rare.
If you do all of these things, adding the style into the web page will clutter your HTML and slow things down for frequent visitors. Yes, it might also increase perceived performance for some users who have not visited the site since the last change to the CSS.
You can download CloudPull from: http://www.goldenhillsoftware.com/
CloudPull is free for a single account. For $9.99, you can upgrade to get premium features including support for up to ten Google accounts.
John