Comments URL: https://news.ycombinator.com/item?id=48960473

Points: 4

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=48706490

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48689135

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=45465065

Points: 3

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=41902942

Points: 14

# Comments: 16

Some feed readers have "scraping" support where they request each article's URL internally and figure out how (or can be configured with CSS selectors) to extract the article's text content and display it in the reader, though it can be pretty hit or miss whether that can work for a given site.

As for formatting, there are a couple possible explanations--the reader could be ignoring or mangling HTML tags in the content when it's displaying it, or the site itself may be generating its RSS feeds with mangled or missing formatting elements. In my experience both possibilities are equally likely.

I can't imagine this working. The plain text section would probably something like "Upgrade your email client to view this message" 90% of the time and be completely pointless.

Maybe it's an unpopular opinion but if I were rebooting email I'd forego HTML entirely and either say it's strictly plain-text, or use some Markdown-like formatting spec that looks fine even when viewed as plain text (email clients could provide WYSIWYG editors for less technically-inclined email authors). The evils of HTML in email (phishing, impersonating companies, and other scams) far outweigh the benefits (none, as far as I'm concerned).

Turns out he actually was from the bank and he did cancel the loan application.

I've got a couple Vizios right now that are basically just glorified monitors because they stay offline, and they work just fine for me.

My main gripe was that I like to listen to music and podcasts while I walk, and the LP2's apps for that are rather lackluster (nearly to the point of unusability for me). It drove me back to my smartphone a few times (a OnePlus something-or-other), which would usually last a few weeks before I'd go back to the LP2 again because the smartphone was too distracting (like I'd pop open a web browser to look up an actor while watching a movie, then getting sucked down a rabbit hole and missing the whole movie before I realized it was happening).

I'm trying a new experiment now--I've got a smartphone again but it's a super tiny one (a Jelly Star which has a 3 inch screen). It's very annoying to actually use for typing or reading because it's so small. It's only been a month or so, but so far I'm finding it's a very nice compromise. I can listen to all my podcasts and music using my normal Android apps, and I can fire up a web browser in a pinch, but it doesn't suck up my attention because it's so uncomfortable to use for any period of time.

The way I set everything up, there's one schema containing just the bare tables and data, and then everything else (stuff that PostGraphile generates and all of our stored procedures with business logic) are in a separate schema. That way the migration process is a shell script that essentially 1. drops the entire non-table schema, 2. runs through all of the SQL files that define the application (there's some custom logic to control dependencies by looking for a `-- PRIORITY N` comment on the first line of the source files), 3. attach all the triggers to the tables (since they live in the schema that was dropped). It means we didn't have to worry about figuring out what all needs to be dropped to make a change because literally everything is dropped and recreated from scratch each time we deploy a new version.

I'm speaking in present tense because this application still exists, we've just (more or less) frozen the code base and are slowly migrating all its functionality piecemeal into a ASP.NET Core WebAPI project.

That being said, I do fully agree that things like Redis, ElasticSearch, RabbitMQ, and Kafka are probably unnecessary in a large number of projects that decide to add them to the stack if those projects are also already using PostgreSQL as a database.