joelverhagen

using System.Globalization;
using System.Net.Http.Headers;
using System.Text;
using System.Text.Json;
using System.Text.Json.Serialization;
using CsvHelper;
using CsvHelper.Configuration;
using CsvHelper.Configuration.Attributes;
using CsvHelper.TypeConversion;

kyanny

• Docker on Vagrant
• minikube for Kubernetes cluster

Vagrant

• Vagrantfile
  • Memory: more than 2048 RAM
  • Docker - Provisioning | Vagrant by HashiCorp to install Docker

rverst

#!/usr/bin/env bash
# https://gist.github.com/rverst/1f0b97da3cbeb7d93f4986df6e8e5695

function chsv_check_version() {
  if [[ $1 =~ ^(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)(-((0|[1-9][0-9]*|[0-9]*[a-zA-Z-][0-9a-zA-Z-]*)(\.(0|[1-9][0-9]*|[0-9]*[a-zA-Z-][0-9a-zA-Z-]*))*))?(\+([0-9a-zA-Z-]+(\.[0-9a-zA-Z-]+)*))?$ ]]; then
    echo "$1"
  else
    echo ""
  fi
}

luismts

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.

mort3za

# Generate a new pgp key: (better to use gpg2 instead of gpg in all below commands)
gpg --gen-key
# maybe you need some random work in your OS to generate a key. so run this command: `find ./* /home/username -type d | xargs grep some_random_string > /dev/null`

# check current keys:
gpg --list-secret-keys --keyid-format LONG

# See your gpg public key:
gpg --armor --export YOUR_KEY_ID
# YOUR_KEY_ID is the hash in front of `sec` in previous command. (for example sec 4096R/234FAA343232333 => key id is: 234FAA343232333)

Eng-Fouad

Steps to generate self-signed PKCS#12 SSL certificate and export its keys:

1- Create PKCS#12 keystore (.p12 or .pfx file)

keytool -genkeypair -keystore myKeystore.p12 -storetype PKCS12 -storepass MY_PASSWORD -alias KEYSTORE_ENTRY -keyalg RSA -keysize 2048 -validity 99999 -dname "CN=My SSL Certificate, OU=My Team, O=My Company, L=My City, ST=My State, C=SA" -ext san=dns:mydomain.com,dns:localhost,ip:127.0.0.1

• myKeystore.p12 = keystore filename. It can with .pfx extension as well.
• MY_PASSWORD = password used for the keystore and the private key as well.
• CN = commonName, it will be shown as certiciate name in certificates list.
• OU = organizationUnit, department name for example.

exAspArk

openssl genrsa -out CAroot.key 2048
openssl req -new -key CAroot.key -out CAroot.csr # CN should be different from the certificates below
openssl req -x509 -days 1825 -key CAroot.key -in CAroot.csr -out CAroot.crt
cat CAroot.crt CAroot.key > CAroot.pem

openssl genrsa -out mongod.key 2048
openssl req -new -key mongod.key -out mongod.csr
openssl x509 -req -days 1825 -in mongod.csr -CA CAroot.pem -CAkey CAroot.key -CAcreateserial -out mongod.crt
cat mongod.crt mongod.key > mongod.pem