Readit News> She's behind the scenes managing resources. Some power is explicitly granted to her, but a lot of her ability to get things done comes from the respect & cooperation of her subordinates.
What a wonderful paragraph. Playful, yet with a deep meaning. It makes the article a joy to read.
This limitation creates numerous headaches. Instead of Deployments, I'm stuck with manual docker compose up/down commands over SSH. Rather than using Ingress, I have to rely on Traefik's container discovery functionality. Recently, I even wrote a small script to manage crontab idempotently because I can't use CronJobs. I'm constantly reinventing solutions to problems that Kubernetes already solves—just less efficiently.
What I really wish for is a lightweight alternative offering a Kubernetes-compatible API that runs well on inexpensive VPS instances. The gap between enterprise-grade container orchestration and affordable hobby hosting remains frustratingly wide.
Out of curiosity, what is so bad about this for smaller projects?
> For the service rate (λ), we can keep things simple and assume that our server can service 10 items per minute with zero variation.
I think it's supposed to be mu and not lambda
Imagine that you are running MAB on an website with a control/treatment variant. After a bit you end up sampling the treatment a little more, say 60/40. You now start running a sale - and the conversion rate for both sides goes up equally. But since you are now sampling more from the treatment variant, its aggregate conversion rate goes up faster than the control - you start weighting even more towards that variant.
Fluctuating reward rates are everywhere in e-commerce, and tend to destabilise MAB proportions, even on two identical variants, they can even cause it to lean towards the wrong one. There are more sophisticated MAB approaches that try to remove the identical reward-rate assumption - they have to model a lot more uncertainty, and so optimise more conservatively.
Out of curiosity, where did you work? In the same space as you.
But overall my ability to design, debug, and maintain code hasn't been dulled by having some of these minutiae stripped away. It actually frees up time and mental effort, so it's easier for me to spend time doing more important things.
I'm not a huge CoPilot advocate and worry a lot about the quality of code that a less-experienced dev is going to produce by leaning on it too much, but having written millions of lines of code by hand, it doesn't make me feel like I'm losing anything valuable.
I'm wondering about the long term effects of not paying attention to such details. Do you miss out on picking up patterns used by a certain library, framework, language or whatever, that you could have used to write your own code better?
- At processing start, update the schedule entry to 'executing', then open a new transansaction and lock it, while skipping already locked tasks (`SELECT FOR UPDATE ... SKIP LOCKED`).
- At the end of processing, set it to 'COMPLETED' and commit. This also releases the lock.
This has the following nice characteristics:
- You can have parallel processors polling tasks directly from the database without another queueing mechanism like SQS, and have no risk of them picking the same task.
- If you find an unlocked task in 'executing', you know the processor died for sure. No heuristic needed