I get that they make it hard to find, so we also buy different stuff. But if I can't find what I'm looking for too often, I won't come back anymore.
Sometimes I really want/need something, and I have all the stores close by. But I still decide to buy it online, and accept waiting a few days, because stores/malls are such a bad experience.
Supermarkets are maybe a bit different, they are hard to avoid.
But I dislike malls so much, that I only get new clothes for example once it's really necessary. If it was more pleasant to shop there, I would probably buy more stuff.
I guess there are some people who fit into that environment, their tactics work well on them, and the shops/malls just ignore customers like me.
I really hate shops, malls and supermarkets. I'm not easily overwhelmed and can handle being there fine. But it's just horrible there. Way too loud, bright and often too warm. Completely full of chaos and way too many useless products.
When I have to go I try to be out there as quickly as possible. I always thought that's weird, shouldn't those shops be designed in a way that makes me want to explore them, look at all the things they have, instead of just hunting down exactly what I need and leave as quickly as possible.
Keycloak is awesome, but whenever I used it the documentation gave me too little guidance. On how to use it in the right way, without having to customize it too much.
Is it about the license? I see less and less new projects using GPL, and a lot of MIT(ish) licenses.
Most complex open source projects like Linux for example have a lot of contributions by corporations. The GPL kind of forces them to participate in open source, instead of just creating internal forks.
GPL and even LGPL are tricky for libraries though.
The message is written to the outbox table in the same transaction as the database changes. Only if the transaction completes, the message is actually created, and other tables are updated.
In a second step the message is taken from the outbox and gets sent to the queue/broker. Only after it was sent out, the message is removed from the outbox. If the sending fails, it stays in the outbox and is retried. If the deletion of the message from the outbox fails after sending, it's getting re-sent later. So you can get a duplicated out-message.
Message brokers usually don't de-duplicate messages, they don't have a database that keeps messages, the receivers need to do that. Either with idempotency, or by tracking message ids. Event sourcing brokers can de-duplicate, because it can stores all messages.
If you never delete messages from the outbox, then they are re-sent all the time. You are going to notice such a bug really quickly.
Inbox pattern works very similarly, but the other way around.
With an inbox/outbox pattern it's possible. The incoming message might be processed more than once, and an outgoing message might be sent more than once. That's the limitation, and the system needs to be able to handle it.
If you can't de-duplicate messages it's not possible, that's true.
I don't drive the best car available on the market. I don't own the fastest and best PC/Laptop/Smartphones available. I don't live in the best house in my city. I made reasonable choices that balance my needs and my available budget.
I never ran into that. I always ask the recruiters to include my GitHub account in the summaries they submit to the technical teams reviewing applications. But they never do.
I see one big difference: with email it was always about sender reputation based on email servers (IPs), maybe about domains. But never about individual users. It's the organizations running the email server, who make sure users behave. So they don't get blacklisted and lose sending privileges for hundreds or thousands of users.
Duplication is often less harmful than abstraction.
Duplications can often be cleaned up over time, bad abstractions can quickly become a bottleneck, that severely slow down everyone working on the project.
I always try to design in a way, that using abstractions/shared logic is optional.
I've worked in too many projects, where every new feature needs to be built on top of existing abstractions, that often lead to severe restrictions if something slightly different is required. I always try to create reusable units/components, that can either be used as intended or replaced by something that behaves slightly different if needed.
Components are not necessarily frontend components, this extends also to backend logic.
I guess you can test that on hypotheticals. Ask about things after the knowledge cut off that never happened. Or ask things that are genuinely unsolvable.