@Podman_io@Docker I didn't raise one yet for the another one: Mounting the Docker Socket in the child containers of GitLab Runner with Docker Executor results in access to the socket being denied.
Both issues seem to be related to the permissions of mounted files/volumes.
I gave it a try, but uninstalled @Podman_io Desktop today as it is not the drop-in replacement it claims to be. Too many issues that cost too much time to work around while it just works with @Docker Desktop.
"Microservices first" indicates that the person advocating that idea isn't thinking like an architect. No single architectural pattern is appropriate in all contexts. An architect will first identify the essential system characteristics and then pick an architectural pattern with pros and cons that match the characteristics. Microservices are fault-tolerant, highly elastic and scalable, incremental-development friendly, and support hot deploys into running systems. They are also slow, complex, and network-based (I see that as a huge negative). Use the pattern if those characteristics (pros and cons) work for you. If they don't, use a different pattern. There's also a third choice. A very simple microservice system can run as threaded components in a monolith, thereby giving up the elasticity but also lowering the complexity quite a bit by getting rid of the network issues. In other words, you can meld patterns to create new patterns. It's all about identifying characteristics and choosing (or inventing) appropriate patterns.
In software development, complexity is very often admired. It's not uncommon to see overly complex architectures chosen for trivial apps.
In the long run, simplicity and flexibility are the safest bet as they allow you to better evolve your project based on future technical and non-technical requirements.
Protip: If you want to become a better software developer, you should study the source code of the frameworks you are using.
Not only will you get a better understanding of how they work, but you're also going to learn how design patterns are applied in practice.
Design Patterns is a wonderful book. Yes, I know, it's thirty years old. Yes, I know it uses older languages. But it's still great.
Some folks have said that the concept of Design Patterns is out of date -- that those patterns were just workarounds for the bad languages of the day.
What a load of Dingoes Kidneys! The Patterns described in the book are timeless and well worth the effort to learn. They are crystalized applications of old and well worn principles.
You _will_ use them, one way or another, because they are common solutions to common problems. If you don't know them already, you'll work them out for yourself.
The benefit of learning the patterns from the book is that it gives those common solutions canonical names, and canonical forms. When others who know those names and forms see them in your code, they'll know exactly what to expect.
TIL about @testcontainers JDBC.
What a nifty solution! 🪄
When combined with the powers of @springboot configuration sources, it keeps your test classes clean, no more dealing with containers. See 👇
https://t.co/pCTLOPakzc
@svpino There is a difference between stupid-simple code and clever-simple code, in between there is complex and cumbersome, as @wilddueck has written in his book
Apparently some people are surprised that you can run a 13 year old self-contained Jar on the latest JVM. And thinking about other language ecosystems, it is actually pretty freaking amazing and not something that we talk about enough.
@svpino I'm using the K860 and it has the same issue as yours for me: the keys left to the space key are not the same as on my Mac that has four keys on the left: Fn, Ctrl, Opt, Cmd while the keyboard has Fn on the right. That causes some friction when switching to the Mac's keyboard.
The most important advice you'll ever get:
There's No Free Lunch.
When you write software for a living, you must understand that you always make trade-offs. There's no unqualified "best" language, library, or algorithm. Your decision will always give something away. You give some, and you gain some.
Smart, senior people know this. Immature people don't.
Everyone has opinions. Few can justify them. Even fewer will explain them in a way that makes sense.
The difference between those who know and the clueless ones is their ability to think critically about their decisions.
@INNOQ Ich habe mich auf deine Vorträge gefreut und auch die Podcasts mit dir gerne gehört. Ich hätte mich gerne noch öfter mit Dir unterhalten, du warst ein Vorbild. Welch ein Verlust! Gute Reise, @stilkov!