novemberborn

This Gist documents how to obtain a Let's Encrypt certificate for use with CloudFlare origin servers. For background please see my article on CloudFlare and Origin Servers for the Rightfully Paranoid.

I'm assuming OpenSSL is installed on your machine. You're also going to need Node.js 5.6.0 or above. We'll be using wilee to obtain the certificate from Let's Encrypt.

Prerequisites

novemberborn

Assuming you received the certificate in DER form, saved to cert.der:

openssl x509 -inform der -in cert.der -out chain.pem

Append the content of https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem.txt to chain.pem.

novemberborn

Copy /System/Library/OpenSSL/openssl.cnf to a new file.

Add the following at the end:

[ req ]
req_extensions = v3_req

[ v3_req ]
# Extensions to add to a certificate request

taoyuan

# npm using https for git
git config --global url."https://github.com/".insteadOf git@github.com:
git config --global url."https://".insteadOf git://

# npm using git for https
git config --global url."git@github.com:".insteadOf https://github.com/
git config --global url."git://".insteadOf https://

novemberborn

Changes with .dev domains in mind.

Create /etc/pf.anchors/dev, containing:

rdr pass inet proto tcp from any to any port 80 -> 127.0.0.1 port 8080
rdr pass inet proto tcp from any to any port 443 -> 127.0.0.1 port 8443

novemberborn

Install dnsmasq using Homebrew. Edit the dnsmasq.conf file (Homebrew will tell you where to put it) to contain:

address=/.dev/127.0.0.1
listen-address=127.0.0.1

Then make sure Dnsmasq is running (again follow Homebrew instructions).

Create the /etc/resolver/dev directory (using root) if it doesn't exist yet and create a resolver for .dev:

vvo

You have a nice library published on npm but asking yourselve if you should declare your dependencies as lodash: "3.10.0" (known as "pin" a dependency) or lodash: "^3.10.0"?

As library authors we should not pin dependencies but ask our users to do use npm shrinkwrap in their own app.

Here's why:

Pinning dependencies will result in duplicated code and modules in builds

If you pin your dependencies the issue is that anyone using your module will may not benefit from shared dependencies. If your module user has lodash: "^3.11.0" then since you declared

novemberborn

See http://www.giacomovacca.com/2014/10/removing-all-unused-docker-containers.html.

docker rm $(docker ps -a -q)
docker rmi $(docker images -q --filter "dangling=true")

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

domenic

This article has been given a more permanent home on my blog. Also, since it was first written, the development of the Promises/A+ specification has made the original emphasis on Promises/A seem somewhat outdated.

You're Missing the Point of Promises

Promises are a software abstraction that makes working with asynchronous operations much more pleasant. In the most basic definition, your code will move from continuation-passing style:

getTweetsFor("domenic", function (err, results) {
 // the rest of your code goes here.