kmatt

# Based on https://gist.github.com/kmatt/71603170556ef8ffd14984af77ff10c5
# prompt ">" indicates Powershell commands
# prompt "$" are Linux shell commands

# https://docs.microsoft.com/en-us/windows/wsl/install-win10

> dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
> dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

# install https://wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msi

jsumners

Ocassionally, someone will start a pull request and, for various reason, not see it through. Later, someone else may wish to finish that work. Even though the original author was unable to finish their work, we should still include their efforts in our project's history. To do so, the person wishing to finish the original pull request should start their new pull request using the original as the base.

The simplest workflow to accomplish this is:

$ # For the project on GitHub to your account and then:
$ git clone 

getify

What Hiring Should Look Like

This is definitely not the first time I've written about this topic, but I haven't written formally about it in quite awhile. So I want to revisit why I think technical-position interviewing is so poorly designed, and lay out what I think would be a better process.

I'm just one guy, with a bunch of strong opinions and a bunch of flaws. So take these suggestions with a grain of salt. I'm sure there's a lot of talented, passionate folks with other thoughts, and some are probably a lot more interesting and useful than my own.

But at the same time, I hope you'll set aside the assumptions and status quo of how interviewing is always done. Just because you were hired a certain way, and even if you liked it, doesn't mean that it's a good interview process to repeat.

If you're happy with the way technical interviewing currently works at your company, fine. Just stop, don't read any further. I'm not going to spend any effort trying to convince you otherwise.

nathggns

function curry(fn, ...args) {
	if (args.length === fn.length) {
		return fn(...args);
	}

	return curry.bind(this, fn, ...args);
}

function add(a, b) {
	return a + b;

devster31

Mac OS X

Using homebrew

1. brew install syncthing
2. Follow the info to autostart syncthing using launchctl. At the moment this is done using this command: launchctl load ~/Library/LaunchAgents/homebrew.mxcl.syncthing.plist.

Without homebrew

Download syncthing for Mac: https://github.com/syncthing/syncthing/releases/latest.

staltz

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

---

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

---

branneman

Better local require() paths for Node.js

Problem

When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:

const Article = require('../../../../app/models/article');

Those suck for maintenance and they're ugly.

Possible solutions

kagemusha

version: grunt-cli v0.1.8


1. Install node-inspector globally (-g)

    npm install -g node-inspector

2. Add debugger statements to your code

3. Run your grunt task in debug mode

rgbkrk

#!/usr/bin/env python
# -*- coding: utf-8 -*-

'''
Wrote this very fast to quickly mirror nodejs's dist directory, which nvm
(the node version manager) uses to pull releases of node.

If nodejs.org provided rsync access (or other means), I would have
just mirrored it that way.

dlecocq

# Environment
#
#     export HOSTNAME=...
#     export CLUSTER=...
#     export RACK=...
#     export ESDIR=
#     export AWS_ACCESS_KEY=...
#     export AWS_SECRET_KEY=...

# Packages