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 had a team of about 8 junior people. We would do a daily morning sync where we went over open tickets. The main purpose of the meeting was to see who was struggling with something and needed help.
In my experience junior people often wait too long to ask questions when they are stuck on something out of fear of looking bad. But if you are junior it is totally normal to not know a lot of things and thus get stuck frequently. If it is something that can be Google’d, sure let them learn to look, but often it is something internal to the company and they just need someone to point them in the right direction.
I would take note on who was having problems and call them throughout the day to unblock the situation. Sometimes I would invite 1 other person into the call to share some knowledge and preferably have them explain it to each other.
In general I would try to make these calls educational rather than just telling them the solution. You want to build up the team so they become more and more independent.
When major new topics came up (new feature, completely new use-case) I would organise a team meeting to discuss the topic and work out a design. I usually prepared these meetings to the point I more or less knew the design we wanted to go for because the team was very junior. This allowed me to led the team brainstorm and occasionally guide them or point out issues.
The key is that you want to try to facilitate rather than dictate. If you dictate too much they won’t learn or learn slowly.
Second, junior people often say they understand something without actually understanding it. Have them explain it back to you. But don’t be too critical when they get it slightly wrong, that can be demotivated.
Also try to pull involve individual team members into higher level discussions from time to time. I would sometimes invite someone to the architecture review meeting. This helps them gain perspective.
Finally I would do a meeting twice a year to discuss their progress and ask their feedback and how they are feeling in the team etc.
This mostly applies to a team full of juniors. I bootstrapped two junior teams this way.
> We would do a daily morning sync where we went over open tickets. The main purpose of the meeting was to see who was struggling with something and needed help.
Oh no, don't call it a "daily scrum" or the anti-Agile folks will descend on you like a pack of locusts :)
But that really works, it's easier to get people to ask for help or say they're stuck in person than over chat.
> But that really works, it's easier to get people to ask for help or say they're stuck in person than over chat.
Which is completely different from saying "daily syncs make it easier for people to ask for help or say they're stuck".
What you actually need for people to ask for help or say they are stuck is to make them feel safe and comfortable doing it. As a human, not as an agile guru. If one can't get there, maybe one needs to work on their human skills instead of adding bullshit agile processes.
reply