Skip to content

Instantly share code, notes, and snippets.

View agosto-calvinbehling's full-sized avatar

Calvin Behling agosto-calvinbehling

View GitHub Profile
@StevenACoffman
StevenACoffman / Docker Best Practices.md
Last active November 9, 2024 17:19
Docker Best Practices

Mistakes to Avoid: Docker Antipatterns

Whichever route you take to implementing containers, you’ll want to steer clear of common pitfalls that can undermine the efficiency of your Docker stack.

Don’t run too many processes inside a single container

The beauty of containers—and an advantage of containers over virtual machines—is that it is easy to make multiple containers interact with one another in order to compose a complete application. There is no need to run a full application inside a single container. Instead, break your application down as much as possible into discrete services, and distribute services across multiple containers. This maximizes flexibility and reliability.

Don’t install operating systems inside Docker containers

It is possible to install a complete Linux operating system inside a container. In most cases, however, this is not necessary. If your goal is to host just a single application or part of an application in the container, you need to install only the essential

@chrismccoy
chrismccoy / gitcheats.txt
Last active October 16, 2024 15:36
git cheats
# alias to edit commit messages without using rebase interactive
# example: git reword commithash message
reword = "!f() {\n GIT_SEQUENCE_EDITOR=\"sed -i 1s/^pick/reword/\" GIT_EDITOR=\"printf \\\"%s\\n\\\" \\\"$2\\\" >\" git rebase -i \"$1^\";\n git push -f;\n}; f"
# sort list of git repos with gh cli
gh repo list --limit 300 --json name -q '.[].name' | sort
# count total commits in a repo
git rev-list --all --count
@chanks
chanks / gist:7585810
Last active September 17, 2024 11:55
Turning PostgreSQL into a queue serving 10,000 jobs per second

Turning PostgreSQL into a queue serving 10,000 jobs per second

RDBMS-based job queues have been criticized recently for being unable to handle heavy loads. And they deserve it, to some extent, because the queries used to safely lock a job have been pretty hairy. SELECT FOR UPDATE followed by an UPDATE works fine at first, but then you add more workers, and each is trying to SELECT FOR UPDATE the same row (and maybe throwing NOWAIT in there, then catching the errors and retrying), and things slow down.

On top of that, they have to actually update the row to mark it as locked, so the rest of your workers are sitting there waiting while one of them propagates its lock to disk (and the disks of however many servers you're replicating to). QueueClassic got some mileage out of the novel idea of randomly picking a row near the front of the queue to lock, but I can't still seem to get more than an an extra few hundred jobs per second out of it under heavy load.

So, many developers have started going straight t

@datagrok
datagrok / gist:2199506
Last active August 22, 2024 14:21
Virtualenv's `bin/activate` is Doing It Wrong