PaulKinlan

(function() { 
  var CSSCriticalPath = function(w, d, opts) {
    var opt = opts || {};
    var css = {};
    var pushCSS = function(r) {
      if(!!css[r.selectorText] === false) css[r.selectorText] = {};
      var styles = r.style.cssText.split(/;(?![A-Za-z0-9])/);
      for(var i = 0; i < styles.length; i++) {
        if(!!styles[i] === false) continue;
        var pair = styles[i].split(": ");

gleitz

// Reloading modules from the repl in Node.js
// Benjamin Gleitzman (gleitz@mit.edu)
//
// Inspired by Ben Barkay
// http://stackoverflow.com/a/14801711/305414
//
// Usage: `node reload.js`
// You can load the module as usual
// var mymodule = require('./mymodule')
// And the reload it when needed

FGRibreau

var dummySocket = new ReadWriteNetStream();

// Debug
dummySocket.on('data', function(data){
console.log('write received', data);
});

dummySocket.write('hey !');

aolde

var http = require("http"),
    url = require("url"),
    path = require("path"),
    fs = require("fs")
    port = process.argv[2] || 8888,
    mimeTypes = {
      "html": "text/html",
      "jpeg": "image/jpeg",
      "jpg": "image/jpeg",
      "png": "image/png",

mbrock

javascript:document.addEventListener('DOMNodeInserted',function(e){if(!e.target.setAttribute)return;e.target.setAttribute('data-trace',(new Error).stack.split("\n").splice(6).join("\n").replace(/( +at )|\([^()]+\)/g,"").replace(/\n/g,"/ "));e.target.style.border='1px dotted salmon'});

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.

trevnorris

The prep-script.sh will setup the latest Node and install the latest perf version on your Linux box.

When you want to generate the flame graph, run the following (folder locations taken from install script):

sudo sysctl kernel.kptr_restrict=0
# May also have to do the following:
# (additional reading http://unix.stackexchange.com/questions/14227/do-i-need-root-admin-permissions-to-run-userspace-perf-tool-perf-events-ar )
sudo sysctl kernel.perf_event_paranoid=0

trevnorris

Introduction

Here is a collection of tips and tricks I've picked up about doing performance analysis on Node. Included is a build script that should get a base install of Ubuntu fully functional and ready for all the things we'll be going through.

The script pulls a lot of code from the latest master of each repository. So it's possible that something may fail, but to date I haven't had any issues.

First, go ahead and run the script. Then go take a nice long break. It'll

wintercounter

(function() {
  var MutationObserver;

  if (window.MutationObserver != null) {
    return;
  }

  MutationObserver = (function() {
    function MutationObserver(callBack) {
      this.callBack = callBack;

kachayev

Channels Are Not Enough

... or Why Pipelining Is Not That Easy

Golang Concurrency Patterns for brave and smart.

By @kachayev

Intro