robmiller

#
# Working with branches
#

# Get the current branch name (not so useful in itself, but used in
# other aliases)
branch-name = "!git rev-parse --abbrev-ref HEAD"
# Push the current branch to the remote "origin", and set it to track
# the upstream branch
publish = "!git push -u origin $(git branch-name)"

VerosK

---
- hosts: localhost
  vars:
    facter_blockdevices: sda,sdb,sdc,sdd,sde,sdf
  gather_facts: no
  tasks:
    - name: Separate facts
      set_fact: blockdevices="{{facter_blockdevices.split(',')}}"

    - name: Show the devices

303182519

#参考资料

• http://bbs.et8.net/bbs/showthread.php?t=568472
• http://www.ruanyifeng.com/blog/2011/09/curl.html

###下载单个文件，默认将输出打印到标准输出中(STDOUT)中

curl http://www.centos.org

codexico

# https://gist.github.com/codexico/2a34c0d599f3af93b46f


[color]

    # Use colors in Git commands that are capable of colored output when
    # outputting to the terminal. (This is the default setting in Git ≥ 1.8.4.)
    ui = auto

[color "branch"]

john-doherty

(function () {

    'use strict';

    /**
     * wraps a promise in a timeout, allowing the promise to reject if not resolve with a specific period of time
     * @param {integer} ms - milliseconds to wait before rejecting promise if not resolved
     * @param {Promise} promise to monitor
     * @example
     *  promiseTimeout(1000, fetch('https://courseof.life/johndoherty.json'))

hhimanshu

Overview

These are in no particular order. I found them by researching what methods other developers use to understand codebases that they have not seen before.

Recommendations

• If the codebase has tests, read the tests
• Try to write tests for the part of codebase you are trying to understand. This helps in understanding the behavior and serve as documentation
• Get overview of project. See the overall picture. How many modules it has? What are the name of the modules? Pick one module and do deep dive into it.
• Writing documentation for source code. This is a good practice to understand the codebase. I tend to prefer writing tests over documentation since the source code and tests are truth, documentation decays over time, generally.

tuannvm

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  creationTimestamp: null
  name: test
spec:
  replicas: 1
  template:
    metadata:
      creationTimestamp: null

aradi

#!/bin/bash
################################################################################
# Store this file as .git/hooks/commit-msg in your repository in order to
# enforce checking for proper commit message format before actual commits. You
# may need to make the script executable by 'chmod +x .git/hooks/commit-msg'.
################################################################################
filename="$1"
copy=$(tempfile -p gitco)
cat $filename >> $copy
lineno=0

pierrejoubert73

How to add a collapsible section in markdown

1. Example

Click me

Heading

1. Foo
2. Bar
   • Baz

• Qux

jayphelps

{
  "scripts": {
    "build": "npm run build:es2015 && npm run build:esm && npm run build:cjs && npm run build:umd && npm run build:umd:min",
    "build:es2015": "tsc --module es2015 --target es2015 --outDir dist/es2015",
    "build:esm": "tsc --module es2015 --target es5 --outDir dist/esm",
    "build:cjs": "tsc --module commonjs --target es5 --outDir dist/cjs",
    "build:umd": "rollup dist/esm/index.js --format umd --name YourLibrary --sourceMap --output dist/umd/yourlibrary.js",
    "build:umd:min": "cd dist/umd && uglifyjs --compress --mangle --source-map --screw-ie8 --comments --o yourlibrary.min.js -- yourlibrary.js && gzip yourlibrary.min.js -c > yourlibrary.min.js.gz",
  }
}