datacook ludeen007

PostgreSQL is Enough

Background and Cron Jobs

🗺🐘 1000+ PostgreSQL EXTENSIONs

This is a list of URLs to PostgreSQL EXTENSION repos, listed in alphabetical order of parent repo, with active forks listed under each parent.

⭐️ >= 10 stars
⭐️⭐️ >= 100 stars
⭐️⭐️⭐️ >= 1000 stars
Numbers of stars might not be up-to-date.

Git Commit Best Practices

Basic Rules

Commit Related Changes

A commit should be a wrapper for related changes. For example, fixing two different bugs should produce two separate commits. Small commits make it easier for other developers to understand the changes and roll them back if something went wrong. With tools like the staging area and the ability to stage only parts of a file, Git makes it easy to create very granular commits.

Commit Often

Committing often keeps your commits small and, again, helps you commit only related changes. Moreover, it allows you to share your code more frequently with others. That way it‘s easier for everyone to integrate changes regularly and avoid having merge conflicts. Having large commits and sharing them infrequently, in contrast, makes it hard to solve conflicts.

Semantic Commit Messages

See how a minor change to your commit message style can make you a better programmer.

Format: <type>(<scope>): <subject>

<scope> is optional

Example

Git Branch Merging Best Practices

After you've selected a feature to work on, create a branch in your local repo to build it in.
- $ git checkout -b calaway/short_description_of_feature
Implement the requested feature, make sure all tests are passing, and commit all changes in the new branch.
Checkout the master branch locally.
- $ git checkout master
Pull down the master branch from GitHub to get the most up to date changes from others. If you practice git workflow as described here you should never have a merge conflict at this step.
- $ git pull origin master
Make sure all tests are passing on master and then checkout your new branch.

$ git checkout calaway/short_description_of_feature

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

System Design Cheatsheet

Picking the right architecture = Picking the right battles + Managing trade-offs

Basic Steps

Clarify and agree on the scope of the system

User cases (description of sequences of events that, taken together, lead to a system doing something useful)
- Who is going to use it?
- How are they going to use it?

	CheckOptions:
	- key: readability-identifier-naming.ClassCase
	value: CamelCase
	- key: readability-identifier-naming.ClassMemberCase
	value: lower_case
	- key: readability-identifier-naming.ConstexprVariableCase
	value: CamelCase
	- key: readability-identifier-naming.ConstexprVariablePrefix
	value: k
	- key: readability-identifier-naming.EnumCase

	#ifndef SIGNALS_H
	#define SIGNALS_H

	#include <functional>
	#include <list>
	#include <memory>

	template <typename... Args>
	class ConnectionItem
	{