Published May-13-2020
Last updated March 13, 2024
This Gist explains how to sign commits using gpg in a step-by-step fashion. Previously, krypt.co was heavily mentioned, but I've only recently learned they were acquired by Akamai and no longer update their previous free products. Those mentions have been removed.
Additionally, 1Password now supports signing Git commits with SSH keys and makes it pretty easy-plus you can easily configure Git Tower to use it for both signing and ssh.
For using a GUI-based GIT tool such as Tower or Github Desktop, follow the steps here for signing your commits with GPG.
minikube start --kubernetes-version=v1.7.0 --extra-config=apiserver.Authorization.Mode=RBAC | |
kubectl create clusterrolebinding add-on-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default | |
minikube dashboard |
/* | |
This snippet is an example of backpressure implementation in Go. | |
It doesn't run in Go Playground, because it starts an HTTP Server. | |
The example starts an HTTP server and sends multiple requests to it. The server starts denying | |
requests by replying an "X" (i.e. a 502) when its buffered channel reaches capacity. | |
This is not the same as rate-limiting; you might be interested in https://github.com/juju/ratelimit | |
or https://godoc.org/golang.org/x/time/rate. |
Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.
- Follow standard conventions.
- Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
- Boy scout rule. Leave the campground cleaner than you found it.
- Always find root cause. Always look for the root cause of a problem.
To be clear we continue to run many Redis services in our production environment. It’s a great tool for prototyping and small workloads. For our use case however, we believe the cost and complexity of our setup justifies urgently finding alternate solutions.
- Each of our Redis servers are clearly numbered with a current leader in one availability zone, and a follower in another zone.
- The servers run ~16 different individual Redis processes. This helps us utilize CPUs (as Redis is single-threaded) but it also means we only need an extra 1/16th memory in order to safely perform a BGSAVE (due to copy-on-write), though in practice it’s closer to 1/8 because it’s not always evenly balanced.
- Our leaders do not every run BGSAVE unless we’re bringing up a new slave which is carefully done manually. Since issues with the slave should not affect the leader and new slave connections might trigger an unsafe BGSAVE on the leader, slave Redis processes are set to not automatically rest
$ brew update | |
$ brew install hive |
#Container Resource Allocation Options in docker-run
now see: https://docs.docker.com/engine/reference/run/#runtime-constraints-on-resources
You have various options for controlling resources (cpu, memory, disk) in docker. These are principally via the docker-run command options.
##Dynamic CPU Allocation
-c, --cpu-shares=0
CPU shares (relative weight, specify some numeric value which is used to allocate relative cpu share)
# Ask for the user password | |
# Script only works if sudo caches the password for a few minutes | |
sudo true | |
# Install kernel extra's to enable docker aufs support | |
# sudo apt-get -y install linux-image-extra-$(uname -r) | |
# Add Docker PPA and install latest version | |
# sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 36A1D7869245C8950F966E92D8576A8BA88D21E9 | |
# sudo sh -c "echo deb https://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list" |
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.