pythonaut_16

What do you despise about their serializers? What would make them better or what would be a better approach for you?

(Genuinely curious as someone who's working on a similar idea in a different language)

This has nothing to do with Computer Science as a major or as a field.

I literally said: > I don't think the difference is enough to justify the price difference

PC components are definitely too expensive right now, for several reasons, including Nvidia's pricing choices

The 4K 144hz you get on the Xbox Series X is almost certainly lower graphics settings than you could run at 4K 144hz on the RTX 4080. I don't think the difference is enough to justify the price difference but comparing resolution and framerates isn't apples to apples.

What we can't do today or what we don't want to do today?

You're proving the parent's point. Electricity is fungible so it will be easier to replace natural gas used for electricity than the millions of homes heated by it.

Because lots of people need more flexibility or lower cost than Apple Silicon. GPU, RAM, storage configurations, etc.

Apple Silicon is great but doesn't serve every need.

They want it to die. They don't want to keep supporting Heroku but they don't want the bad press of killing it outright. Or at least they're pivoting from independent hosting to an enterprise value add for SalesForce.

Or they're really short-sighted.

Yep, this reads like they want Heroku to quietly die off but don't want to make a hard deprecation announcement.

Parent comment seems more focused on the probability/distribution than in the reasons why.

The anecdote seems true from my experience as well; people tend to either break their phones often or very rarely/not at all. Of course it could be that you are far more likely to take notice of someone breaking their phone if it happens often.

Let me tell you about my new Blockchain CorpoCoin... (/s)

The parent's point is that revenue is not equal to value. Determining actual value generated by tech companies is tricky

There's a strong argument to be made that in the American system this is a feature and not a bug.

The whole thing is designed to make it difficult to make big changes, especially unilaterally.

Whether the system is serving us well or needs adjustments is a different matter.

My experience with a 16" M1 MacBook Pro is that the fans don't come on unless I'm running games anyway.

You could likely achieve an essentially "fanless" experience on the 14" M1 Macbook Pro as on the Air.

So Tailwind with more steps

If you're going that far back you might as well bring up the Revolutionary War and the war of 1812 and ask why the US isn't still at odds with the UK.

This is also one of the use cases that Vue targeted specifically and it greatly accelerated its adoption.

Vue positions itself for anything from jQuery replacement all the way to a full SPA and everything in between.

I'm not super familiar with HTMX but lots of people in the Elixir/Phoenix/Liveview world are using Alpine JS for these types of problems.

Liveview(HTMX analog) for anything with data and state that needs to go to and from the server; Alpine JS for client side interactions with ephemeral state like opening a modal.

Consider that for a lot of shops and restaurants demand might be inelastic over the course of the week. If everyone in town is closed on Sunday and consumers don't have convenient access to other options it's likely that demand will simply shift to other days, thus being closed on Sunday would reduce operating costs without significantly affecting revenues.

This is arguably a big factor for both Chick-fil-a and liquor stores that are prevented state-wide from opening on Sundays (in the US)

In many situations unfairness is a form of injustice.

Probably because interviewing is highly subjective. The advice in this article could be used as part of a great interview or part of a terrible one. It depends on how the interviewer uses it.

How to change meta tags:

1. What is the current general standard. 2. Does our site do what we want it to do? -> Yes? Then we don't need more meta tags. -> No? Go to 3. 3. Are meta tags part of how to accomplish what we want? -> Yes? Look up the docs and tags needed and implement. -> No? Implement without touching the meta tags of the doc.

That's why focusing on the first 10 lines isn't very helpful IMO. Most of these are things that are trivial to look up and read the docs on when they become necessary.

If you want to interview around a site's source you'd be better served to have a discussion around the whole document.

When I look at the article two things stand out to me:

1. The author is focusing on the first 10 lines, not the whole document. 2. Their "perfect answers" have the candidate essentially reciting the reference docs verbatim.

That to me reads very differently from reading and discussing the whole HTML file. It reads much more like gotcha questions or an expectation that your candidate has extremely specific, arcane knowledge.

For example, the perfect answer for line 1 includes:

> This was especially annoying because each standard generated a different layout so this tag was adopted to make it easy for browsers. Previously, DOCTYPE tags were long and even included the specification link (kinda like SVGs have today), but luckily the simple <!doctype html> was standardized in HTML5 and still lives on.

So to the author, one should ideally not just know what "<!doctype html>" is for, but also be able to rattle off complaints against the previous revisions of HTML. The whole article just comes off as very verbose and stifling. (For that line he does allow for a more basic, but still verbose, answer)

Is it unreasonable for a senior frontend engineer to rely on references for some of these extremely specific details?

Not to mention they're perfectly referenceable. If I need to set up a new HTML doc and add the meta tags I can easily find everything I need on MDN and a quick Google search for best practices. Anything more specific (like Apple specific tags) is trivial to find as well.

Interviews should be focused on skills and experience because those take time and effort to develop. Not 5 minutes on the internet.

What do you find lacking in the Phoenix docs? I've always been impressed with the docs in the major Elixir and Phoenix libraries.

Isn't that the point of the end of that comment?

I wouldn't call it crap. It certainly has limitations, but for many projects those are an acceptable tradeoff for lower friction. For many projects those limitations cost less than not launching the project at all.

Heroku definitely has a ton more competition these days though. Containerization has really encroached on their main value proposition. Fly.io, AWS ECS and Fargate, Managed Kubernetes, even just Docker on a VPS mostly don't require much more effort than Heroku.

Unless the unsafe parts of self driving only apply to previously unsafe drivers it will still struggle to take off.

Not every human driver has the same risk, but every self driving car will. (Or it will be based on which car you are in rather than how safe you are.) In other words, relatively safe human drivers could actually see their risk levels go up in a self driving car, even it if it statistically safer than all human drivers.

From a code/business standpoint this absolutely makes things easier to report on personal transactions.

My point was the thing stopping Venmo from reporting on your personal transactions is not technical. As soon as the government tells them they need to report, they will comply.

Your second point is possible, but I don't see how this move really gets us closer to that, other than providing data that could be used to make the argument.

How is this different than the transition to requiring online transactions to charge sales tax?

That would constitute tax fraud right? And intentionally bypassing the reporting built into the platform surely increases your culpability.

If you're doing a relatively low volume you might get away with it, but you are committing a crime.