$ docker
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.
var express = require('express') | |
, http = require('http') | |
, connect = require('connect') | |
, io = require('socket.io'); | |
var app = express(); | |
/* NOTE: We'll need to refer to the sessionStore container later. To | |
* accomplish this, we'll create our own and pass it to Express | |
* rather than letting it create its own. */ | |
var sessionStore = new connect.session.MemoryStore(); |
When hosting our web applications, we often have one public IP
address (i.e., an IP address visible to the outside world)
using which we want to host multiple web apps. For example, one
may wants to host three different web apps respectively for
example1.com
, example2.com
, and example1.com/images
on
the same machine using a single IP address.
How can we do that? Well, the good news is Internet browsers
Sublime Text 2 ships with a CLI called subl (why not "sublime", go figure). This utility is hidden in the following folder (assuming you installed Sublime in /Applications
like normal folk. If this following line opens Sublime Text for you, then bingo, you're ready.
open /Applications/Sublime\ Text\ 2.app/Contents/SharedSupport/bin/subl
You can find more (official) details about subl here: http://www.sublimetext.com/docs/2/osx_command_line.html
var WebSocketServer = require('ws').Server; | |
var wss = new WebSocketServer({port: 8080}); | |
var jwt = require('jsonwebtoken'); | |
/** | |
The way I like to work with 'ws' is to convert everything to an event if possible. | |
**/ | |
function toEvent (message) { | |
try { |
// Use: var tree = new OST(); tree.select(4); tree.insert(key,value) | |
var OST = function () { | |
// Order statistic tree node | |
var Node = function (leftChild, key, value, rightChild, parent) { | |
return { | |
leftChild: (typeof leftChild === "undefined") ? null : | |
leftChild, | |
key: (typeof key === "undefined") ? null : key, | |
value: (typeof value === "undefined") ? null : value, | |
rightChild: (typeof rightChild === "undefined") ? null : |
#!/bin/sh | |
# http://download.redis.io/releases/ | |
# Usage: sh compile-redis-portable.sh | |
VERSION="4.0.6" | |
INIT_PATH=`dirname "$0"` | |
INIT_PATH=`( cd "$INIT_PATH" && pwd )` |
tl;dr I built a demo illustrating what it might look like to add async rendering to Facebook's commenting interface, while ensuring it appears on the screen simultaneous to the server-rendered story.
A key benefit of async rendering is that large updates don't block the main thread; instead, the work is spread out and performed during idle periods using cooperative scheduling.
But once you make something async, you introduce the possibility that things may appear on the screen at separate times. Especially when you're dealing with multiple UI frameworks, as is often the case at Facebook.
How do we solve this with React?
// handy method to create a Higher Order Component out of a | |
// Render Prop Component (like a Context.Consumer). | |
// handles, statics, displayName, refs, and value forwarding | |
function createHOCFromRenderProp({prop, Consumer}) { | |
return Component => { | |
function Wrapper(props, ref) { | |
return ( | |
<Consumer> | |
{value => <Component {...{...props, [prop]: value, ref}} />} |