Matrix278

Scaling your API with rate limiters

The following are examples of the four types rate limiters discussed in the accompanying blog post. In the examples below I've used pseudocode-like Ruby, so if you're unfamiliar with Ruby you should be able to easily translate this approach to other languages. Complete examples in Ruby are also provided later in this gist.

In most cases you'll want all these examples to be classes, but I've used simple functions here to keep the code samples brief.

Request rate limiter

This uses a basic token bucket algorithm and relies on the fact that Redis scripts execute atomically. No other operations can run between fetching the count and writing the new count.

Matrix278

Effective Go Summary

The link to Effective Go documentation

Package Names

When importing a package in Go, the package name becomes the access point for its contents. It's recommended to use short, concise, and evocative names to facilitate ease of use. Package names are typically lower case and single-word to minimize typing. If there's a naming collision, importing packages can locally rename them to avoid conflicts. Package names derive from the base name of their source directory, like "encoding/base64" imported as "base64".

Example:

Matrix278

Title:
Incident date:
Owner:
Peer-review committee:
Tags:
Summary:
Supporting data:
Customer Impact:
Incident Response Analysis:
Post-Incident Analysis:

Matrix278

Merged from https://github.com/joelparkerhenderson/git_commit_message and https://chris.beams.io/posts/git-commit/

General Rules

• Commit messages must have a subject line and may have body copy. These must be separated by a blank line.
• The subject line must not exceed 50 characters
• The subject line should be capitalized and must not end in a period
• The subject line must be written in imperative mood (Fix, not Fixed / Fixes etc.)
• The body copy must be wrapped at 72 columns
• The body copy must only contain explanations as to what and why, never how. The latter belongs in documentation and implementation.

Matrix278

PostgreSQL is Enough

• Simplify: move code into database functions
• Just Use Postgres for Everything
• PostgreSQL is the worlds’ best database
• Hacker News discussion

Background and Cron Jobs

• https://github.com/citusdata/pg_cron

Matrix278

## Unity ##

*.cs diff=csharp text
*.cginc text
*.shader text

*.mat merge=unityyamlmerge eol=lf
*.anim merge=unityyamlmerge eol=lf
*.unity merge=unityyamlmerge eol=lf
*.prefab merge=unityyamlmerge eol=lf

Matrix278

How to update the Go version

System: Debian/Ubuntu/Fedora. Might work for others as well.

1. Uninstall the exisiting version

As mentioned here, to update a go version you will first need to uninstall the original version.

To uninstall, delete the /usr/local/go directory by:

Matrix278

https://superuser.com/questions/1397199/how-to-ignore-a-tracked-file-in-git-without-deleting-it

Adding the file / directory to .gitignore only is not enough, but git will allow you to manually "ignore" changes to a file / directory:

git update-index --assume-unchanged <file>

And if you want to start tracking changes again, you can undo the previous command using:

git update-index --no-assume-unchanged

Matrix278

Learning links

1. https://www.theodinproject.com
2. https://www.udemy.com
3. https://www.freecodecamp.org
4. https://www.sololearn.com
5. https://learngitbranching.js.org
6. https://portswigger.net/web-security/learning-path
7. https://web.dev/secure/#understand-security-basics
8. https://www.codecademy.com

Matrix278

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

1. Follow standard conventions.
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
3. Boy scout rule. Leave the campground cleaner than you found it.
4. Always find root cause. Always look for the root cause of a problem.

Design rules