enixdark

while true; do sleep 1; curl http://www.google.com; echo -e '\n\n\n\n'$(date);done

enixdark

# delete all pods
kubectl delete --all pods --namespace=default


# deete all deployments
 kubectl delete --all deployments --namespace=default
 
 # delete all services
 kubectl delete --all services --namespace=default

enixdark

Programming as Theory Building

Peter Naur

Peter Naur's classic 1985 essay "Programming as Theory Building" argues that a program is not its source code. A program is a shared mental construct (he uses the word theory) that lives in the minds of the people who work on it. If you lose the people, you lose the program. The code is merely a written representation of the program, and it's lossy, so you can't reconstruct

enixdark

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
	worker_connections 768;
	# multi_accept on;
}

http {

enixdark

Moved to git repository: https://github.com/denji/nginx-tuning

NGINX Tuning For Best Performance

For this configuration you can use web server you like, i decided, because i work mostly with it to use nginx.

Generally, properly configured nginx can handle up to 400K to 500K requests per second (clustered), most what i saw is 50K to 80K (non-clustered) requests per second and 30% CPU load, course, this was 2 x Intel Xeon with HyperThreading enabled, but it can work without problem on slower machines.

You must understand that this config is used in testing environment and not in production so you will need to find a way to implement most of those features best possible for your servers.

enixdark

using rust with rr

rr is a great debugging tool. it records a trace of a program's execution, as well as the results of any syscalls it executes, so that you can "rewind" while you debug, and get deterministic forward and reverse instrumented playback. it works with rust, but by default if you try it out, it could be pretty ugly when you inspect variables. if this bothers you, configure gdb to use a rust pretty-printer

rr is probably in your system's package manager.

usage

enixdark

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.

enixdark

#!/bin/sh
# This gist contains pre-commit hooks to prevent you from commiting bad code or to the wrong branch.
# There are four variants that I have built:
# - pre-commit: stops commits to "master" and "develop" branches.
# - pre-commit-2: also includes a core.whitespace check.
# - pre-commit-3: the core.whitespace check and an EOF-newline-check.
# - pre-commit-4: only the core.whitespace check.
# - pre-commit-5: elixir formatting check.
# - pre-commit-6: prettier formatting check.
# Set desired version like this before installing:

enixdark

kubectl get pods | grep Evicted | awk '{print $1}' | xargs kubectl delete pod

enixdark

IAM Multi-tenancy Architecture

This article is an overview of IAM implementations, focused on multi-tenancy deployments.

 

Terminology

• IAM User - IAM access account.
IAM Group - A grouping of IAM Users.