Good points, but I'm not sure "push", "pull", "user", or "owned" were particularly well described at the beginning.
I've always found that thinking about "static" vs "dynamic" content to be the most useful breakdown. Services often produce a mix of static and dynamic, i.e. it's not all "owned" just because it comes from the service. Similarly "push" and "pull" are a little tricky to reason about, but "upload via a web form" and "deploy via a build pipeline" are much clearer to me.
"static" and "dynamic" leads to an easy definition too – if it's in the codebase it's static, and if it's in the database (or referenced by it) it's dynamic. The same rules as in this blog post apply though, high cacheability on static and lower TTLs on dynamic content.
In systems of a certain scale this stuff starts to blend together (e.g. if your company runs an internal CDN then everything is dynamic from the perspective of the CDN), but in my experience, static/dynamic and deployed/uploaded is a good place to start that allows for good caching behaviour.
Same. I felt that the article generally got his point across, and kept a good balance between "straight to the point" and flavor text.
And while I don't want profanity present in all the articles I want to read, I find this kind of tone way more appealing than the dry, PR-approved blog posts where the only kind of levity found are "2010 internet humor" cat pictures, and "Corporate Memphis" illustrations.
> Conveying frustration (…) sometimes requires profanity
Agreed, but that’s unrelated to what your parent comment says:
> using profanity is a lousy way to explain things
Explaining something and conveying frustration are not the same thing. So you’re not really disagreeing, you talked about something orthogonal. For all we know, the parent commenter agrees with you. It’s not contradictory to think profanity is a good medium to convey frustration but a bad one to explain a concept.
> and if you can't deal with that then grow up
That was uncalled for. Please be mindful of the guidelines. HN aims for civil discourse, not needlessly judging others.
I couldn't be bothered to assess the quality of the content when the presentation is so childish -- performative aggression, cussing like a 12-year-old boy who thinks it makes him sound cool, etc., it's all totally unnecessary and actively detracts from communicating whatever possibly useful information he might have had to share.
That's the writing style and tone that they wanted to put out. They went to a coffee shop to get what one gets at a coffee shop some coffee and some food and they were using some sort of a internet connected thing that frustrated them because of the coffee shop's poor internet connection.
I think they did a perfectly good job and this is good writing and it's not indicative of their intelligence or maturity.
Haven't you ever got frustrated at something where you just are constantly cursing inside. That seems to be what spurred this on, simple as.
Recall that in Game of Thrones the young Arya (she/her) grabs a light fencing stabbing weapon with two hands and flails it about like a 12 year boy playing with a pretend broadsword.
Syrio, her teacher, proceeds to correct her and teaching the beginning fundamentals of swordplay.
The GP has used a simile cussing like a 12 year boy and could perhaps instead used braying like a donkey, bellowing like a sea lion, cursing like a sailor, etc.
The use of a simile does not imply that the subject of the simile is a 12 year old boy, a donkey, a sea lion, a sailor, etc.
It doesn’t seem like your parent comment is referring to the “12-year-old boy” part of its parent comment, but the “(…) information he might have (…)” part (near the end).
One of the first web projects I worked on involved a dozen iframes and calling postMessage to pass around data, it was chaos. Still remember the senior dev of the project did a pull request, the variable was called “cacheMeOutside” I chuckled and approved.
I've always found that thinking about "static" vs "dynamic" content to be the most useful breakdown. Services often produce a mix of static and dynamic, i.e. it's not all "owned" just because it comes from the service. Similarly "push" and "pull" are a little tricky to reason about, but "upload via a web form" and "deploy via a build pipeline" are much clearer to me.
"static" and "dynamic" leads to an easy definition too – if it's in the codebase it's static, and if it's in the database (or referenced by it) it's dynamic. The same rules as in this blog post apply though, high cacheability on static and lower TTLs on dynamic content.
In systems of a certain scale this stuff starts to blend together (e.g. if your company runs an internal CDN then everything is dynamic from the perspective of the CDN), but in my experience, static/dynamic and deployed/uploaded is a good place to start that allows for good caching behaviour.