NoviceDuke

function nvm
    bass source /usr/local/opt/nvm/nvm.sh --no-use ';' nvm $argv
end

artizirk

NB: This document describles a 'Old-School' way of using Yubikey with SSH

Modern OpenSSH has native support for FIDO Authentication. Its much simpler and should also be more stable with less moving parts. OpenSSH also now has support for signing arbitary files witch can be used as replacement of gnupg. Git also supports signing commits/tags with ssh keys.

Pros of FIDO

• Simpler stack / less moving parts
• Works directly with ssh, ssh-add and ssh-keygen on most computers
• Simpler
• Private key can never leave the FIDO device

Cons of FIDO

weihanglo

【譯】Rust vs. Go

本文譯自 Julio Merino 2018 年七月撰寫的 Rust vs. Go 一文。Julio Merino 是 G 社僱員，在 G 社工作超過 8 年，無論工作內外，都接觸開發不少 Go 語言，並撰寫 [Rust 點評][rust-review]系列文，來聽聽他對 Rust 與 Go 的想法吧。

Thanks Julio Merino for this awesome article!

---

cablespaghetti

#!/bin/bash

# Get directory of script
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

if [[ $# -ne 1 ]]
then
    echo "ERROR: This script expects the namespace name to be given as an argument"
    echo "e.g. ./ecr-cred-updater.sh my-namespace"
    exit 1

kevinkindom

Python Socket 编程详细介绍

Python 提供了两个基本的 socket 模块：

• Socket 它提供了标准的BSD Socket API。
• SocketServer 它提供了服务器重心，可以简化网络服务器的开发。

下面讲解下 Socket模块功能。

Socket 类型

karenyyng

Table Of Content

Skip to the relevant sections if needed.

• 2-min tutorial to do it the quick-and-dirty-way
• Concepts for resolving Git conflicts
• Setting up different editors / tool for using git mergetool
  • Finding out what mergetool editors are supported
• mergetool simple code example for vimdiff
  • Resolving conflict from a Git pull
• Other great references and tutorials

supermarin

# ZSH / BASH users
# Add this to your .env, .bashrc, .zshrc, or whatever file you're using for environment

man() {
	env \
		LESS_TERMCAP_mb=$(printf "\e[1;31m") \
		LESS_TERMCAP_md=$(printf "\e[1;31m") \
		LESS_TERMCAP_me=$(printf "\e[0m") \
		LESS_TERMCAP_se=$(printf "\e[0m") \
		LESS_TERMCAP_so=$(printf "\e[1;44;33m") \

jarvys

• create a new redis .conf file

$ cp /etc/redis.conf /etc/redis-xxx.conf

• edit /etc/redis-xxx.conf, illustrated as below

...

zsup

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.

XVilka

THIS GIST WAS MOVED TO TERMSTANDARD/COLORS REPOSITORY.

PLEASE ASK YOUR QUESTIONS OR ADD ANY SUGGESTIONS AS A REPOSITORY ISSUES OR PULL REQUESTS INSTEAD!