Yes, exactly. It works great. But it is not cookie cutter enough for most orgs to adopt which is what led to Scrum, SAFE and what else. And then organisations take those frameworks (often change them to get even more agility out) and adopt them like it is gospel.
I have worked at an org where team members were not allowed to create tickets because that was the scrum master's job and the product owner had to approve all tickets etc. Who can even think that is a good idea??
Not sure what the solution is. There might not be any.
I am unfamiliar with Wero. Can you explain why it is an engineering fiasco?
Side note: Looking at their job listings I don't see any engineering positions (with the exception of a security engineer which is a grey area in a bank IMO), only managers and business roles.
what ever "money extraction business" means - wero is a real thing people (me included) are already using and developed jointly by many european banks.
Old Dutch banks and their Belgian suckers, mostly. You can see a list on their website.
I am not deep into this, but I heard multiple times that the choice of the pan-european payment system was largely political and technnically suboptimal. Old Europe pushed for the aging iDEAL against a much more advanced Blink, so Eastern European banks led by Poland left the consortium.
In the end, iDEAL rebranded as Wero was dead on arrival because a successful system needs to be supported by everyone.
I have no idea what you are talking about. I have been using Wero for a while in France and it works just fine and is completely free.
It's basically instant bank transfer without any fee or limitation on how many you can do.
I can recommend doing this! It really is not hard to learn the basics of electronics and you will have a better understanding of how the things around you work.
It supports docker swarm, but I've never used it like that.
As I may need multi node in the future, I was asking the question to see if it would make it 'easy' to orchestrate multiple containers.
The simplicity of Dokku is hard to beat, however.
edit: Well, it would appear that the very maintainer of Dokku himself replied to the parent comment. My information is clearly outdated and I'd only look at this comment[0] to get the proper info.
Dokku is multi node. It supports docker-local (single node) and k3s (multi-node) as schedulers, with most features implemented as expected when deploying to k3s.
I read the “The Art of Multiprocessor Programming” and I don’t recommend it. It is very theoretical. There is no mention of practical performance considerations on real hardware.
Large parts of the theory focus on lock-free and wait-free data structures. Which, while interesting, are not necessary for beginners.
I find it "amusing" that FB (or well, a lot of phone apps) can see how your relationship with people ebb and flow.
E.g. for a dating situation: new WhatsApp contact, growing frequency of texts, growing frequency of WhatsApp calls, culminating in a night where both phones were connected to the same SSID / locatable in one geo-location throughout the whole night, without their users checking them.
When that happens it'd be time to show them ads with the text "Your new love interest is highly interested in these products"...
It'd also be "amusing" to big-data the whole thing and get the computer to spit out the answer to the question "Where is this relationship going?"
It definitely uses connection IPs as some heuristic.
I exclusively used Facebook for family (years ago before deleting it) and received recommendations of otherwise socially-unconnected roommates who habitually accessed FB through house wifi.
OTEL always seems way too complicated to use to me. Especially if you want to understand what it is doing. The code has a lot of abstractions and indirection (at least in Go).
And reading this it seems a lot of people agree. Hope that can be fixed at some point. Tracing should be simple.
Go with OTel is, unfortunately, known to be challenging ergonomics-wise. The OTel project doesn't really define an ergonomics standard, and leaves it up to the groups for each sub-project (e.g., each of the 11 language groups) to define how they package things up, what convenience wrapper APIs they offer, etc.
In Go, currently it is a deliberate choice to be both very granular and specific, so that end-users can ultimately depend on only the exact packages they need and have nothing standing between them and any customization of the SDK they need to do for their organizations.
The main thing people sometimes struggle with at this point is threading context through all their calls if they haven't done that yet. It's annoying, but unfortunately running into a limitation of the Go language here. Most of the other languages (Java, .NET, Ruby, etc.) keep context implicitly available for you at all times because the languages provide that affordance.
I have worked at an org where team members were not allowed to create tickets because that was the scrum master's job and the product owner had to approve all tickets etc. Who can even think that is a good idea??
Not sure what the solution is. There might not be any.
reply