Please try again. :)
148 karma · joined November 30, 2016
This reads like the infamous Dropbox comment. :)
To me, Sidekiq is the perfect example of keeping something simple. A basic Redis + Sentinel deployment with persistence enabled and multiple read replicas has allowed me to achieve this.
Scaling Sidekiq workers is also incredibly easy. I have dedicated job queues for various categories, and I simply create a new Kubernetes deployment for each category. Each deployment is set to only process a specific queue. This allows me to throttle how quickly each queue gets processed, simply based on replica/pod count.
If you're looking for simple rock-solid mesh WiFi, Eero is what you want.
[1] https://eero.com
1. Go here as a logged in user: https://github.com/actions/docker/blob/master/.github/main.workflow
2. Click Edit on the file (top right corner, pencil icon)
3. Edit existing workflow, or click "Create a new workflow".Also, many don't know this, but you can run and debug AWS Lambda locally with AWS' own tooling. Using this to build out and test Lambda's before creating them with Terraform has been priceless: https://github.com/awslabs/aws-sam-cli
If a developer is using an older buggy version of npm that doesn't respect .npmrc and changes a lock file to point back to npmjs.org entries, we deny the PR and ask for it to be fixed. Right now that check is unfortunately manual, but there are plans to automate it. It can be easy to miss at times though, since GitHub often collapses lock files on PR's due to their size.
For us, the main purpose of using Nexus as a proxy is to maintain availability and to cache/maintain package versions. If you're using Nexus to make things faster, then you probably shouldn't be using it. If you want faster installs, look into using `npm ci`.