start new:
tmux
start new with session name:
tmux new -s myname
Latency Comparison Numbers (~2012) | |
---------------------------------- | |
L1 cache reference 0.5 ns | |
Branch mispredict 5 ns | |
L2 cache reference 7 ns 14x L1 cache | |
Mutex lock/unlock 25 ns | |
Main memory reference 100 ns 20x L2 cache, 200x L1 cache | |
Compress 1K bytes with Zippy 3,000 ns 3 us | |
Send 1K bytes over 1 Gbps network 10,000 ns 10 us | |
Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD |
// set-up a connection between the client and the server | |
var socket = io.connect(); | |
// let's assume that the client page, once rendered, knows what room it wants to join | |
var room = "abc123"; | |
socket.on('connect', function() { | |
// Connected, let's sign-up for to receive messages for this room | |
socket.emit('room', room); | |
}); |
#!/bin/sh | |
### | |
# SOME COMMANDS WILL NOT WORK ON macOS (Sierra or newer) | |
# For Sierra or newer, see https://github.com/mathiasbynens/dotfiles/blob/master/.macos | |
### | |
# Alot of these configs have been taken from the various places | |
# on the web, most from here | |
# https://github.com/mathiasbynens/dotfiles/blob/5b3c8418ed42d93af2e647dc9d122f25cc034871/.osx |
A warning occurred (42 apples) | |
An error occurred |
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.
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.
When times get tough and people get nasty, you’ll need more than a killer smile. You’ll need a killer contract.
Used by 1000s of designers and developers Clarify what’s expected on both sides Helps build great relationships between you and your clients Plain and simple, no legal jargon Customisable to suit your business Used on countless web projects since 2008
…………………………
From Meteor's documentation:
In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node. We find the linear execution model a better fit for the typical server code in a Meteor application.
This guide serves as a mini-tour of tools, trix and patterns that can be used to run async code in Meteor.
Sometimes we need to run async code in Meteor.methods
.
For this we create a Future
to block until the async code has finished.
# you can make a text file of request times (in ms, one number per line) and import it here, or you can use a probability distribution to simulate request times (see below where setting req_durations_in_ms) | |
# rq = read.table("~/Downloads/request_times.txt", header=FALSE)$V1 | |
# argument notes: | |
# parallel_router_count is only relevant if router_mode is set to "intelligent" | |
# choice_of_two, power_of_two, and unicorn_workers_per_dyno are only relevant if router_mode is set to "naive" | |
# you can only select one of choice_of_two, power_of_two, and unicorn_workers_per_dyno | |
run_simulation = function(router_mode = "naive", | |
reqs_per_minute = 9000, |