I wonder how hard it’d be to make a PWA and host it on GitHub 🤔 Maybe this would be a good yet-another-hobby-project-ill-never-complete to pick up

I figured it was a micro transaction game. This shit should be covered under right-to-repair.

you’re only allowed to have fun if we control it

It was the other company CEO with dubious ties.

Wait… Who is “it” in “it’s CEO”??? Which CEO has ties?

I guess I’ll have to actually read the article.

We both have issues. But as I said, at least I have a modicum of self-awareness.

I don’t expect you to go back and check, but I think you know that’s not how the hostility started.

Anyways, I’ll lay off now unless you ask a question or say something wildly out of line, but I’d like to part with this: your take here doesn’t seem to align with other things you’ve said in your (public) comment history on your (public) profile. We’re all forced to play the capitalist game, but you’re not going to be rewarded for this kind of devotion to your boss.

Sorry for catching you in your hypocrisy? 🤷

How do you reconcile what you’re saying here with your anti-billionaire stance on your other comments? Sometimes someone needs to hold up a mirror.

Only to fascists and bigots.

You talk like a bootlicker. At least I have a modicum of self-awareness.

No, you’re right. Being fun at a party of techbros is totally a sign of superiority and not at all a sign of sociopathy 🤮

Tbf you’re probably not a terrible person, but that is a bad take. Rejecting someone based entirely on education, and not allowing for other factors (as is implied), is just bad for both your company and society.

Let me rephrase, to make myself crystal clear, because you didn’t get the tactful approach: that’s a shitty filter. By excluding people without a degree, you’re saying that ability to afford university for 4 years is more important than skill, experience, or knowledge.

It shows that you’re ignorant. It shows that your company has a toxic workplace.

It’s probably one of the dumbest flexes I’ve ever seen.

I have a bachelor’s of computer science, but some of the best coders I met just did a 2 year community college diploma.

I don’t think that spending lots of money on education is really a great litmus test, it’s just one minor indicator.

My comment about JWT wasn’t that it complicates the current problem, but that it complicates the design in general.

The alternative is to do it the traditional way, with DB records associated with the user, rather than pushing everything to the client. It wont solve the problem you’re describing, but it might make working on a solution easier.

The feature you’re describing is just a slight tweak of the standard shopping cart, so the standard tried-and-true shopping cart design would serve you well, barring extenuating circumstances like some kind of significant DB limitation. DB tables for the items, and for the shopping cart itself. When the user goes to check out the cart, you make an offer on the cart, which is basically just a clone of the shopping cart into a new table with all the item prices denormalized (and therefore locked in). Add a field for the offer expiration date and you’ve got a working design that is very similar to the standard well-worn design, and without any complicated JWT stuff. You still need the client to retry with a new offer if the current offer has expired, but adding retry logic to clients is a pretty normal thing for clients to have.

It’s a pretty significant departure from your current design, so it’s probably not actually a useful answer, but this is what I meant about the JWT making things more complicated in general.

From an API perspective I agree with you. From a UX perspective I agree with them.

In the end, you’re writing software to benefit users, so user benefit is top priority.

Luckily, you can have it both ways. Keep the API pure and simple, returning a meaningful error to the client, and the client then procures a new JWT completely transparently to the user, and retries.

I suspect you’re overcomplicating things by using a JWT, but that kind of decision screams “confounding factors” that affect design decisions that you haven’t/can’t elaborate on. It’d just take some minor tweaks of the standard “shopping cart” API/DB design to get what you want, so I assume there is a reason you haven’t gone that route.