Sergio Bilello sbilello

Final Review - Comprehensive PR Review & Testing

Step 0: Determine Review Pass

Before starting, check the git history to determine if this is a follow-up review:

git log --oneline -10 | grep -i "Co-Authored-By: Claude"

Based on this blogpost.

To sign Git commits, you need a gpg key. GPG stands for GNU Privacy Guard and is the de facto implementation of the OpenPGP message format. PGP stands for ‘Pretty Good Privacy’ and is a standard to sign and encrypt messages.

Setting up

Install with Homebrew:

$ brew install gpg

Installing `pyenv` on macOS for Zsh using Homebrew

Published May-13-2020

Installation
Basic Usage
Virtualenv

Methods of Signing Git Commits on MacOS

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.

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.

General rules

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.

Design rules

Redis in Production at Smyte

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

#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)

	/*
	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.

	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