Not enough info. What are you trying to actually accomplish here? If you’re stress testing and trying to measure how fast a server can process all those requests, use something like jmeter. You can tell it to do 100 concurrent threads with 10000 requests each, then call it a day.

People make microservices way too small sometimes. Then you have the opposite problem with people trying to cram everything into one system. You need to recognize when some functions are related and should go together, or when something has a weird dependency and should just be separate.

As long as you’re following the manifesto and the principles, you’re good. You’ll notice this doesn’t talk about scrum or kanban or safe or whatever, those are processes that try (sorta) to follow these. But if you’re ever in a situation where somebody says “this is the process we’re supposed to do” hit them with the manifesto.

1. Teams should be self sufficient. Team A shouldn’t depend on Team B. Coordinating across teams takes up so much time.
2. Teams should be flexible and change organically. If you suddenly need the expertise of another person, they should be able to join your team without filing a bunch of paperwork. If you’re no longer needed on your team but another team could use you, same deal.
3. Product doesn’t get to solution. I know, everybody should get to have an idea and voice it. But devs have to actually build and deal with the thing. Product can make requirements but don’t get to say “you have to use bigquery” or something.

Edit: I almost forgot the two statements that I put in every team working agreement.

1. You’re number one objective is to not burn out. Limit your number of hours. Schedule a week of vacation for every two months at least. Work a 4 day week if you can. Work the hours that make sense to you. You can have some core hours where everybody should overlap on most days, but the goal is to deliver something not sit at a desk from 9-5.
2. You are allowed and encouraged to make mistakes. This is how we learn. You will only get in trouble if we, as a team, keep making the same mistakes.

For every distro there will be a group of package maintainers that handle this. The original authors will usually provide it in their own repo or a container build. But they (probably) won’t have permission to host that on the official repo of every distro cause that’s dangerous. You’d have all sorts of stability issues and dependency problems.

Yes, she literally did more commits than 347 other people. (every other maintainer this year)

They fluxuate wildly between short and informative messages like “fixed regex validation on property A” and “I fucking hate prettier” when the build pipeline fails because I had a line that was 2 characters too long.

I think only on certain models (not the home arm systems).

Which Synology NAS? Is it one of the ARM based ones or an Intel based one? You’ll need to compile targeting the right arch.

For the actual scheduling, you can schedule jobs through the web UI. Control panel > task scheduler. I have a few scheduled jobs on mine, but they’re just bash scripts.

Very rarely. But I organize my code in ways that avoid it. Ex: if I make an API project, I make one router that dynamically forwards the request to the designated handler rather than registering every route in one file.