RicDan

> The routing of just load balancing is much simpler than the routing of exectution jumping between many microservices

Not necessarily at all, i.e. using GRPC it's all self discovered.

> I agree, but a microservice architecture starts you out at a higher complexity.

Definitely

> That can also be done by having that business logic live in its own library.

That's true, having it in it's own library is certainly a possibility -> but then it's also not that far off micro/macro services anyway, except you deploy it as one piece. And basically this is my argument: If you're having it all as libraries, and you all work in a mono repo anyway, the only real difference between micro/mono is the deployment, and that with micro you _could_ independently scale up whatever the current bottleneck is, which we've used plenty of times

Which is perfectly fine - 100 million concurrent users aren't the same for app x and app y, as the business logic the backend run isn't also the same.

Not saying it can't handle everything as well. Just saying the modularity of microservices makes it, in my pov, easier to handle large complex real time systems.

Maybe that's also something that comes with experience - as a rather "newish" guy (professional SE, so one level above Jr), it makes it easier to work on our project.

So you have to take care of routing etc.

I see how it works, and I completely agree that to start out, so going from PoC to first business implementation, a monolith is the way to go (unless the goal from the start is 100 million concurrent users I guess).

But after that initial phase, does it really matter if you use one or the other? You can overengineer both and make them a timesink, or you can keep both simple. I do agree on things like network latency adding up, but being able to completely isolate business logic seems like a nice gain. But Im also not talking about real micro level (i.e. auth login and registration being different services), but more macro (i.e. security is one, printing another(pdf,csv,word etc), BI another one

I see, so basically we are applying scaling, but instead of scaling the bottleneck as its own part we scale everything.

I somewhat fail to see how that saves much effort; routing setup sounds like a hassle.

What we‘re using at my work is just a mono repo with all services in it, which works pretty well, and we‘re like 7 BE devs

Please elaborate on that. Without spawning a new monolith, how do you scale it. Add more resources?

> managed kubernetes > engineering effort medium

eh, about that…

Yes you can. Our tests are layered as follows: - unit tests - mocking tests - integration tests (i.e. service + db) - system tests (full api to db level)

integration starts providing flaky tests already sadly, i.e. with kafka on our end… (i.e. calling the listener twice or thrice even tho it should only once..)

Yes. These actions just give me more fire as argument against every using something that is done by google. Be it GCP, Firebase or anything else, really.

This is a great use of AI! Im tasked with building a new platform and honestly one of my main head aches has been how to use the current AI power to facilitate development and maintenance. Whilst one use case is the automatic generation of edge cases for testing, another one was something like this, great to see it working! Any motivations to maybe add REST support?

Problem with this is that it leads to the algorithm targeting outputs that sound good for humans. Thats why its bad and wont help us, it should also incorporate „sorry dont know that“, but for that it needs to actually be smart

And people only looking at the ISS as a "science experiment" are seriously misunderstanding the social impacts as well, especially when it comes to operations that span multiple countries and the relations between them. It's a public spot of cooperation that helps us not only when it comes to science, but when it comes to agree with each other.

I find it fascinating that people in 2023 argue with „resource constraints“ when talking about scientific projects. Those guys working on that are experts, they wouldnt do much else, the money spent on this is comparatively a joke in comparison to other spendings with much more questionable reasoning, and starting to question the gain of a project in the scientific space is never really an argument; it lies within the basic idea of science to question and reach out of our comfort zone

Pretty cool! not the same but for flyway + java I have a simple github action that on push to develop checks the diff for any *.sql files and mails them to the DA team, as they dont have access to our repo

Because communist history has always had a fascist element in it.

Don't disagree, the wing doesn't matter, both can still apply fascist strategies

Do you have examples of ridiculous ideas? Maybe I'm in an isolated position, but I don't see anything ridiculous

Not sure what storming, disturbing and leading to the cancellation of an event that describes historical occurrences else is. A normal hobby? Surely not.

Whilst n = 170 is not bad, this would still need bigger testing group. But seems promising?

Hello everyone!

Last year I started my job as a Jr. SWE after working several years in different markets.

After constantly encountering features and implementations at my workplace that I find very interesting, I decided to start writing about them all. On one hand, this is for me personally: I want to figure out how it is done, why it was done and what the results are. On the other hand, I want to make sure I actually understand it to a level where I can explain it, or repackage it so it's interesting for others to read.

So, if you have any feedback, I'm happy to receive it!

Resources most likely. Training data, training a proxy that trains the real model, hardware, time, money. Managing such an open source project by itself would be terribly hard, considering the nature of model training, training data collection etc.

Completely agree on this point. I've worked over half a decade with smart home systems, and it's just so much easier (and cheaper!) to integrate well documented, open APIs (and please make them secure, I have nightmares of all the open, unencrypted UDP based alarm systems) that is purely local. This means we would highly recommend these products even tho we made zero money off them, and customers would actually prefer them as well - it's well beyond the time of people naively buying this stuff, and they know that clouds can just "go offline".

What also can't be underestimated is the tinker community. Many people in the smart home business are tinkerers themselfs; create a great product for them and they will inevitably try to use it at their job. But this really isn't only applicable to integrators, really.

Whilst I agree on it, this is partially true. shielded cables can create current flows between switches, have seen it previously, and had to fix it as it was inducing problems on the traffic over that cable

> Or „IBM Quantum Systems“?

Hey hey now. Quantum Systems is actually a free to use (up to certain qubits) cloud platform which you can use qiskit, their open source python lib, to interact with. Its super cool to use it to get some insights into quantum computing and actually evaluate stuff.

So Id take that out of the equation if I were you

There are plenty of examples that already run on simulators. One example would be QAOA that can be used to solve combinational problems like MQO.

Then there is also research that compares the performance of classical ML algorithms to Quantum Based variants, not only simulated but on real, IBM quantum hardware. Not only does the quantum equivalent outperform it (in pure terms of accuracy, as time to train cannot yet be compared), but also in complexity - iirc ~67k parameters for a NN and 16 for a QNN.

This is not to say that it is all set in stone - its still highly unclear which approach and design is the best for what when it comes to quantum circuits.

There is also a problem that noise suppression and error correction need even bigger quantum computers, so we‘re still a way off.

In the words of a Roche ML/Research presentation, who also already tried QC: They tried it and it didnt offer the expected results due to hardware limitations. But they are still actively pursuing it, because in terms of QC you have to be prepared, as otherwise you might be playing an endless catching up with those who were ready.