robertpainsi

Commit Message Guidelines

Short (72 chars or less) summary

More detailed explanatory text. Wrap it to 72 characters. The blank
line separating the summary from the body is critical (unless you omit
the body entirely).

Write your commit message in the imperative: "Fix bug" and not "Fixed
bug" or "Fixes bug." This convention matches up with commit messages

ssippe

const f = (a: any[], b: any[]): any[] =>
    [].concat(...a.map(a2 => b.map(b2 => [].concat(a2, b2))));

export const cartesianProduct = (a: any[], b: any[], ...c: any[]) => {    
    if (!b || b.length === 0) {
        return a;
    }
    const [b2, ...c2] = c;
    const fab = f(a, b);
    return cartesianProduct(fab, b2, c2);

robertpainsi

[branch]
	autosetupmerge = true

[core]
	editor = gedit --wait --new-window
	pager = less -x1,5
	whitespace = trailing-space,space-before-tab,tabwidth=4

[color]
	ui = auto

briceburg

git merge-base --is-ancestor master HEAD

from man git merge-base

A common idiom to check "fast-forward-ness" between two commits A and B is (or at least used to be) to compute the merge base between A and B, and check if it is the same as A, in which case, A is an ancestor of B. You will see this idiom used

vkostyukov

API	Status Codes
[Twitter][tw]	200, 304, 400, 401, 403, 404, 406, 410, 420, 422, 429, 500, 502, 503, 504
[Stripe][stripe]	200, 400, 401, 402, 404, 429, 500, 502, 503, 504
[Github][gh]	200, 400, 422, 301, 302, 304, 307, 401, 403
[Pagerduty][pd]	200, 201, 204, 400, 401, 403, 404, 408, 500
[NewRelic Plugins][nr]	200, 400, 403, 404, 405, 413, 500, 502, 503, 503
[Etsy][etsy]	200, 201, 400, 403, 404, 500, 503
[Dropbox][db]	200, 400, 401, 403, 404, 405, 429, 503, 507

zeusdeux

Vanilla websockets vs socket.io

Note: The points below are a comparison of using vanilla websockets on client and server and using 'em via socket.io and not about why only use socket.io

• Native websockets provide us with only a send method to send data to the server. Send accepts only string input (not too sure about this). Socket.io lets us emit arbitrary events with arbitrary data (even binary blobs) to the server.
• To receive messages on a vanilla websocket you can only assign a handler for the message event. The data you receive is mostly likely to be text (again not too sure about this) and you will have to parse it manually before consuming it. Socket.io lets the server and client both emit arbitrary events and handles all the parsing and packing/unpacking.
• Socket.io gives us both a server and a client. Implementing a vanilla websocket server isn't something that you would want to do per project since it's quite painful. You will have to implement [RFC6455](https://tools.ietf.org/h

oconnor663

EDIT from 2019: Hi folks. I wrote this gist for myself and some friends, and it seems like it's gotten posted somewhere that's generated some (ahem, heated) discussion. The whitespace was correct when it was posted, and since then GitHub changed how it formats <pre> tags. Look at the raw text if you care about this. I'm sure someone could tell me how to fix it, but (thank you @anzdaddy for suggesting a formatting workaround) honestly this is a random throwaway gist from 2015, and someone more knowledgable about this comparison should just write a proper blog post about it. If you comment here I'll hopefully see it and stick a link to it up here. Cheers. @oconnor663

Here's the canonical TOML example from the TOML README, and a YAML version of the same.

title = "TOML Example"

menzenski

; MacOS X: /usr/local/bin/nasm -f macho64 *.s && ld -macosx_version_min 10.7 *.o
; Solaris/FreeBSD/DragonFly: nasm -f elf64 -D UNIX *.s && ld *.o
; NetBSD: nasm -f elf64 -D UNIX -D NetBSD *.s && ld *.o
; OpenBSD: nasm -f elf64 -D UNIX -D OpenBSD *.s && ld -static *.o
; OpenIndiana: nasm -f elf64 -D UNIX *.s && ld -m elf_x86_64 *.o
; Linux: nasm -f elf64 *.s && ld *.o
 
%ifdef  NetBSD
section .note.netbsd.ident
        dd      7,4,1

ericelliott

Essential JavaScript Links

I no longer mantain this list. There are lots of other very comprehensive JavaScript link lists out there. Please see those, instead (Google "awesome JavaScript" for a start).

jobsamuel

Run NodeJS as a Service on Ubuntu 14.04 LTS

With Node you can write very fast JavaScript programs serverside. It's pretty easy to install Node, code your program, and run it. But > how do you make it run nicely in the background like a true server?

• Go to /etc/init/
• $ sudo vim yourapp.conf
• Paste script.conf
• $ sudo start yourapp
• And when you wanna kill the process $ sudo stop yourapp