likis

I thought the rules were clear and it depends on how the word is pronounced, with a vowel or consonant sound.

I have only heard people say H T T P, as specific letters when pronouncing HTTP, and thus the a or an should be based on how one would pronounce the letter "H". And H would be pronounced as "aitch". Starts with an a -> vowel sound -> should be "an".

But I'm a non native english speaker, so I'm happy to be proven wrong.

10k outgoing emails per week it NOT a lot.

Just imagine a weekly newsletter with 100k subscribers.

Maybe I interpreted it differently, but playing an RPG where every NPC is essentially its own agent/AI with its own context would be very interesting. In most RPGs, NPCs are very static.

I think they would just pay the taxes but increase their prices so their bottom-line looks about the same. In the end it would be the consumers in Germany that paid the price.

What LLM is it using? Is it something local? Or does it call out? It wasn't obvious from the docs, and I didn't want to dig through all of the code to figure it out. Should probably be clearly stated on the front page.

But the project looks interesting, I have been looking for something similar.

You posted your opinion without any kind of accompanying argument, and it was also quite unclear what you meant. Whining about being a target and being downvoted is not really going to help your case.

I initially understood your first post as: "Let's not try to make the internet faster"

With this reply, you are clarifying your initial post that was very unclear. Now I understand it as:

"Let's not try to make existing protocols faster, let's make new protocols instead"

Agree, and he even mentions in the article "If you process less than 10k requests per second, you’re not Google nor are you Facebook."

There is a huuuuuge gap between services handling 10k req/s and Google/Facebook.

I think one big upside with JWT that he doesn't mention is that if you have some services geographically distributed, then having decentralized auth with JWTs is quite nice without having to geographically distribute you auth backend system.

So, yes, if you have a monolith or services colocated, or have some kind of monolothic API layer, then no, perhaps JWT does not make sense. But for a lot of distributed services, having JWTs makes perfect sense.

And you don't have to introduce JWT revocation for logout, if you have short token expirations, you can accept the risk of token leakage. If the token is valid for like 30 seconds or 1 minute, you would probably never be able to notice that a token has been leaked anyway.

But the point is that you don't have to look at the source data if you have an actual specification and defined format, right?

It seems like you missed the conclusion in the article. If users want CSV exports, let them have it.

If you have important data being shuffled around systems, pick something with a specification instead.

Did you actually read the conclusion at the end of the article?

"Of course, we can't conclude that you should never export to CSV. If your users are just going to try to find the quickest way to turn your data into CSV anyway, there's no reason why you shouldn't deliver that. But it's a super fragile file format to use for anything serious like data integration between systems, so stick with something that at the very least has a schema and is more efficient to work with."

I very strongly disagree. Having "integration" tests are super powerful, you should be able to test against your interfaces/contracts and not have to spin up an entire environment with all of your hundreds of microservces, building "integrated" tests that are then dependant on the current correctness of the other microservices.

I advocate for not having any integrated environment for automated testing at all. The aim should be to be able to run all tests locally and get a quicker feedback loop.

We have been using all those GCP products and more without any significant problems.

But I do agree, there are some gotchas. PubSub examples: Duplicated messages, shitty DLQ implementation (in my opinion), some developers had improper error handling which lead to to infinite resends of messages (because they nacked message on error), etc..

However, I think the scaling and setup weighs up for all of that. You just need to specify a topic and subscription, and then you don't really have to care about resources or scaling at all, and that is SUPER nice. Also, PubSub is stupidly cheap in comparison to any other similar product, at least that I know of.

Only the first one will be treated as a boolean in JSON. The second one is a number, and the third is a string.

I agree to an extent, but I don't really see the problem either. If I book a meeting or something through any calendar application, the timezone will be fixed to the local timezone. Let's say I book it for 13:00 in my calendar, it will show up as a meeting at 14:00 in their calendar if they are +1 from me.

So whenever I specify a time with someone that could be in a different timezone, I would either make sure that I am using some application that solves it for me, or I would AT LEAST include the timezone.

Maybe I'm just not encountering the same problems that you do.

> "Having some sort of agreed upon world timezone would be neat though ..."

Don't we already have that with UTC / Zulu time?