gregory

docker-machine create -d virtualbox cluster-store                                                  
CLUSTER_STORE_IP=$(docker-machine ip cluster-store)

docker $(docker-machine config cluster-store) run -d \
    --restart="always" \
    --publish="2379:2379" \
     microbox/etcd:2.1.1 \
    -name etcd0 \
    -advertise-client-urls http://${CLUSTER_STORE_IP}:2379 \
    -listen-client-urls http://0.0.0.0:2379 \

gregory

# This file is used by Rack-based servers to start the application.

# GC_FREQUENCY = 8
# require "unicorn/oob_gc"
# GC.disable # Don't run GC during requests
# use Unicorn::OobGC, GC_FREQUENCY # Only GC once every GC_FREQUENCY requests

# # Unicorn self-process killer
require "unicorn/worker_killer"

gregory

# add something like this to config.ru
# see https://github.com/kzk/unicorn-worker-killer

if Integer(ENV['UNICORN_KILLER'] || 0) != 0
  require 'unicorn/worker_killer'
  # Max memory size (RSS) per worker
  use Unicorn::WorkerKiller::Oom, (350*(1024**2)), (400*(1024**2)), 30, true
end

gregory

# A little Meteor CheatSheet about Iron-Router. (updated on a weekly basis)
# Check our Studio: https://gentlenode.com/


meteor add iron:router
meteor update iron:router


# Iron Router > Configuration

gregory

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.

Basic async

Sometimes we need to run async code in Meteor.methods. For this we create a Future to block until the async code has finished. This pattern can be seen all over Meteor's own codebase:

gregory

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.

---

gregory

# benchmark immutable.js with my transducers lib: https://github.com/jlongster/transducers.js

% node bench/immut.js
Immutable map/filter (1000) x 5,497 ops/sec ±2.63% (91 runs sampled)
transducer map/filter (1000) x 7,309 ops/sec ±0.73% (100 runs sampled)
Immutable map/filter (100000) x 62.73 ops/sec ±0.85% (67 runs sampled)
transducer map/filter (100000) x 80.15 ops/sec ±0.48% (71 runs sampled)

gregory

Just a Handy Nylas client based on curl

curl https://gist.githubusercontent.com/gregory/3c98a10cc009ae9f333cd0018523afc5/raw/40917888cd1e903bbd9ab0cbe33d6863728bcf4b/nylas.sh --output /usr/local/bin/nylas
chmod +x /usr/local/bin/nylas
/usr/local/bin/nylas

gregory

var http = require('http');
var express = require('express');
var router = express.Router();

/* GET users listing. */
router.get('/', function(req, res) {
  var request = require('request');

  var url = req.query.url;

gregory

Intention

As Nylas customer, we experienced quite some issues with distinct emails getting merged under the same thread. By documenting the use cases hopefully this will help understand that the algorithm is flawed for some common use cases & need to be addressed ASAP.

Context: