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?

If they have a clone of an intranet gateway, I would have to agree that the phishing attempt is a bit more advanced, so calling it sophisticated is not too far fetched.

Maybe the possibility of compiling and running on different platforms?

For managed products, upgrades are often automatic and there is almost no maintenance that needs to be done. At least that is my impression when running stuff in GCP. For example:

* CloudSQL Postgres, automatic minor/patch upgrades, they working on seamless major upgrades. Automatic disk increase. You would only need to make sure that you have enough resources in terms of CPU/Memory. * PubSub, no maintenance or updates required.

It is more work to keep java and the related dependencies up to date. We use renovatebot to help us automate things like that.

In my experience it is very easy to change and setup the managed products, I declare them in code using terraform and then I don't have to do much at all. This is what is so awesome with the cloud managed products.

If you are trying to be cloud agnostic, then you are just treating the cloud as another datacenter, and then you don't really get any of the benefits of using cloud specific managed products. Then you need a professional to keep maintaining your infrastructure.

I don't see how your example of querying elasticsearch has anything to do with the above. I do agree that it requires the developer to at least understand the basic concepts of kubernetes, if you are running your application in kubernetes.

I rather like to think of it that certain things that was handled by other professionals are now managed or automated with cloud technology. Take Google PubSub for example, a message bus with pretty much zero operational overhead. You simply create your topic and subscriptions and it just works. Compare that to running and maintaining a system like Redis or Kafka on your on-premise hardware.

As a developer you still need to understand the interfaces of the products you are working with, regardless if it is a database, a messagebus, a REST api or kubernetes.

What would the role of the DBA be if you are the one creating tables, tuning indexes and optimizing your queries?

I don't think it has ever been enough to JUST look at the java. You said you were pretty good at SQL, so you must think about the performance of your queries, what indexes you use and such.

You can try to improve your java performance as much as you want, but if your database can't handle the load, then you need to look at the database. In my opinion it is NOT enough to look at just the code, you need to look at all of the parts of the system.

Just declaring that you want a database instance in code, using something like terraform should not be an overwhelming thing. Most of the management would be handled by the cloud vendor, you would just need to make sure that it has enough cpu/ram for example. There are probably even easier products where you just store data with some kind of API and you don't even need to bother with the performance of the data store.

But if you just want to write your java code and not care about anything else... Then yeah, maybe the direction of the industry is not aligning with the direction you want to go.

You feel depressed about the direction of the industry, but how do you feel about the direction of Java? I think Java and spring boot has improved by A LOT the last couple of years. And I enjoy that direction.

We are still running java+spring boot, even though we are moving from on-prem datacenters to GCP. We are moving from VMs to kubernetes/containers, still using java. We are using SQL, but managed CloudSQL databases from google. We are also moving to more asynchronous programming using events with google PubSub.

The developers are now responsible for setting up their databases using terraform, aiming for more DevOps. We used to throw things over the fence, but now the developers create their own infrastructure instead of relying on other teams. They create their own metrics and alerts and have a lot better insight and overview of their applications.

To me, as a java developer, I think it has grown more interesting, and I feel like I am in more control of my environment. The majority of development is still in java, the business logic is in the java. That won't go away.

I'm not sure if my comment is helpful, but I actually like the direction where we are going. Maybe you can try to find the nice parts and focus on those?

They wouldn't need to. From the article: "Oblivious Target Resource: The resource that is the target of an encapsulated request. This resource logically handles only regular HTTP requests and responses and so might be ignorant of the use of oblivious HTTP to reach it"

Sami people is another example: https://en.wikipedia.org/wiki/S%C3%A1mi#Discrimination_again...