The basic premise is that with one command you can stream your terminal to the world, and record it as a video for later. You can make lessons interactive by streaming and chatting at the same time.

Check it out: http://codestre.am!

To leverage it you just need to require('console-trace') and prepend a flag:

console.trace.error('Test');
console.t.log('Test'); // shorthand

You can learn about a few other options in the GitHub repository.

I’m very proud to announce JSConf.ar, the first of its kind in South America! Check out our website and sign up to learn when the first tickets will be on sale (follow us on Twitter as well!).

We’ve confirmed a gorgeous venue that will host our 2-day event on May 19th and 20th. Expect to not just learn from the best international and local speakers, but to take home an unforgettable experience. We are bringing all the excitement and energy from JSConf US and JSConf EU here to Argentina.

I want to thank Chris Williams, Mikeal Rogers & the whole JSConf gang for encouraging me and helping me take this event to my home country. On this end, none of this would have come together without Vulsai, a great local media agency who met this idea with great enthusiasm and reached out to help.

Nos vemos pronto!

curl -s -F page=@file.md http://mantastic.herokuapp.com > file.1

In my computer and slow connection at home, it took 1 second to run this task as measured by time(1). Not bad for something that was already in my computer (curl), that prevented me from needlessly having to run the easy_install/npm/gem/brew/package manager of the day.

As a matter of fact, while installing a Python CLI utility the other day, I pressed tab to autocomplete and was met with a few options:

∞ easy_install
 easy_install      easy_install-2.5  easy_install-2.6  easy_install-2.7

The reality is that a lot of the tools we use or could be using in our terminals could be run somewhere else, and their installation could consist in setting up an alias in your bash profile. Do you need to do syntax highlighting but don’t care for installing a bunch of things?

alias pygmentize="ru pygmentize"

My suggestion here is the creation of a ru command (codename remote unix) whose job would be to provide the same interface as the original command, but execute it remotely. If you pass it -h to get help, it takes that to the web service and outputs its response.

Other examples of potentially useful cloud-run tasks include any text compilers (eg: mantastic, markdown, textile), file type conversion and manipulation (eg: png2gif, trimage), and more.

I developed a Chrome extension you can install to visualize SPDY support in your address bar. Source on Github.

Install Chrome Extension

For those who haven’t heard of SPDY, it’s a new protocol being developed by Google to transport the existing HTTP protocol more efficiently (up to 50% faster). You can read more details in the official Chromium page.

Detecting SPDY

Chrome exposes a flag called wasFetchedViaSpdy as part of the loadTimes object:

if (window.chrome.loadTimes().wasFetchedViaSpdy) {
  // SPDY!
}

The Chrome extension uses a background page that communicates to a content script that checks for the existence of this flag as soon as it can.

If the value for this is false, the plugin will display a gray icon instead:

Update: version 0.2.0 was released with an option to disable the gray state, and the icon was improved. Special thanks to Ehren Kret!

For example, it considers all your arguments to be the search phrase without needing quotes:

And it turns on case-sensitive search if you include an uppercase letter:

The aim of the utility is to be useful and straightforward for the majority of searches. Hence, its options will always stay limited and the codebase brief. You’re also encouraged to fork it and modify it to your liking!

Go to the GitHub project page for download, examples and the up-to-date project.

Socket.IO 0.9.0 has been released, and it’s packed with bug fixes and performance/stability enhancements on both the server and client codebases.

Please refer to the mailing list announcement thread for a detailed changelog.

This also puts us in the last sprint to Socket.IO 1.0! Stay tuned in the coming weeks for the appropriate announcement.

Up 0.1.5

When you use the up CLI for zero-downtime HTTP reloads, you can already leverage --watch to reload your server while developing based on configuration file changes.

However, sometimes things change that are not captured as easily, like configuration files, caches, environment, etc. For this, you can now press ctrl + R in the comfort of your terminal to trigger a quick reload.

 ∞ hello-world (master) up server.js
  up-cli starting cluster with 1 workers on port 3000
  up-cli `kill -s SIGUSR2 76715` or ctrl + r to load new code
  up spawning 1 workers from master 76715
  up worker 76716 created
  up worker 76716 listening on port 60995
  up-cli ctrl + r detected - reloading
  up reloading - spawning 1 new workers
  up spawning 1 workers from master 76715
  up worker 76718 created
  up worker 76718 listening on port 60997
  up worker 76718 spawned - removing old workers
  up telling worker 76716 to exit in 500ms
  up worker 76716 exited

WebSocket.IO 0.1.6, Distribute 0.1.4

Maintenance releases for these two modules.

The Node.JS websocket server with support for all protocols and parsers gets a maintenance fix for 0.4. WebSocket.IO powers the upcoming Socket.IO realtime core, Engine.IO.

Distribute 0.1.4 adds a guard to aids with the debuggability of a “double-callback” situation that can result in calling next twice within a middleware.

I decided to put together a little list of tips and tricks related to NPM you might not know about, that come from my experience working with it daily, in both production and development.

Dev dependencies

Make sure packages that only need to be installed while developing your module, like test frameworks, are included as devDependencies:

"devDependencies": {
   "module": "0.1.0"
}

Introspecting package.json

Starting with Node 0.6, since require() can read and parse JSON files automatically, you can leverage it to easily introspect package.json:

// considering the module lives in lib/module.js:
exports.version = require('../package').version;

If you want to access package.json for other modules, you can do it like this:

require('my-module/package').name

Linking

Sometimes you’re developing two or more modules at once, and at least one of them depends on the other. And often times, in order to be able to publish the module to NPM, you need to ensure the modules that depend on it work OK prior to publishing.

You can leverage npm link to generate a global reference to a module, and then run npm link <package>
to install it in other modules. Consider the following example, in which moduleB depends on the version of moduleA you’re currently developing, and moduleB specifies "moduleA" as a dependency in its package.json

$ cd moduleA/
$ npm link
$ cd ../moduleB

# if moduleB package.json is pointing to a yet-unpublished
# version of moduleA, npm install will fail:
$ npm install

# this will install your local version of moduleA
$ npm link moduleA

# since moduleA is now installed, npm install will ignore it:
$ npm install

Production flags

When deploying, you want npm install to be as fast as possible. To make sure NPM doesn’t waste time installing devDependencies, use the --production option:

$ npm install --production

If you’re logging its output, you also want it to only output the absolutely necessary.

$ npm install --loglevel warn

Git dependencies

If you haven’t published a certain package to the NPM registry, or you can’t because it’s a private module, you can point to a git:// URI instead of a version number in your package.json:

"dependencies": {
    "public": "git://github.com/user/repo.git#ref"
  , "private": "git+ssh://git@github.com:user/repo.git#ref"
}

The #ref portion is optional, and it can be a branch (like master), tag (like 0.0.1) or a partial or full commit id (thanks @Roman for pointing this out). I recommend you use git tags as references to ensure npm install always keeps the module up to date.

Local binaries

Sometimes you need to reference a bin from a module you depend on. It’s not uncommon to have Makefile tasks that leverage a certain node program to perform a compilation or run tests.

Make sure you avoid referencing globally installed binaries like this:

test:
  mocha mytest.js

Instead, point it to the local node_modules, which installs the binaries in a hidden .bin directory:

test:
  node_modules/.bin/mocha mytest.js

Make sure the module (in this case "mocha") is in your package.json under devDependencies, so that the binary is placed there when you run npm install.

If you don’t care for Makefiles, you can also leverage npm run-script by defining the scripts namespace in your package.json:

"scripts": {
    "test": "mocha mytest.js"
  , "build": "uglify mycode.js
}

You can run them like this:

$ npm run-script test
$ npm run-script build
$ npm test # shortcut for `run-script test`

Finally, you can also leverage $PATH and add the relative path ./node_modules/.bin/ to your profile. Then, every time you cd to a module you can type in the scripts directly!

Private repositories

If you never intend to publish a certain module, and you want to avoid accidental publication, make sure to set private like this in your package.json:

"private": true

If you have many private repositories, you might want to consider setting up your own registry, in which case the configuration would look something like this:

"publishConfig": { "registry": "https://yourregistry:1337/" }

Shrinkwrapping

NPM has great support for semantic versioning through the usage of wildcards and expressions in dependencies definitions:

"dependencies": {
    "some-module": "1.0.x"
  , "some-other-module": "<=2.0.0"
}

This, however, can lead to unexpected failure when running npm install over time. At one point your app might work fine, and the next time you deploy, errors can be introduced without changing anything in your code base, due to the introduction of a new version of a dependency with errors. To better understand this problem refer to this blog post.

The shinkwrap NPM command solves this situation rather elegantly. Running

$ npm shrinkwrap

will generate a snapshot of the dependency graph suitable for deployments. For more information about the inner workings of this command, read this article by Joyent.

#include <iostream>
#include "http.h"
using namespace native::http;

int main()
{
    http server;
    if(server.listen("0.0.0.0", 8080, [](request& req, response& res){
        res.set_status(200);
        res.set_header("Content-Type", "text/plain");
        res.end("C++ FTW\n");
    })) std::cout << "Server running at http://0.0.0.0:8080/" << std::endl;

    return native::run();
}

Why is a C++ port of Node.JS exciting?

1. The language has seen the addition of a large number of features designed to improve the usability of the language. In particular, anonymous functions are part of node.native’s “Hello World” (seen above) and used throughout the codebase.
2. The interoperability with the existing C/C++ library ecosystem and tooling, combined with enhanced usability make C++11 very appealing. Projects like node.native prove the additions can translate into real-world APIs that could not be as straightforward otherwise.
3. Successful companies like OKCupid have written entire codebases for networked applications (Node.JS’s niche) in C++. According to its co-founder, the main reason for this decision was performance, which we’re setting out to briefly look at for C++0x in this article.

The stage

The benchmarks were run on a Macbook Air laptop running OS X 10.7.2, with a 1.8 GHZ Intel Core i7 processor and 4 GB 1333 MHZ DDR3 memory.

• JavaScript: Node v0.6.10
• LuaJIT: Luvit v0.1.5 – LuaJIT v2.0.0-beta9
• C++: node.native-117ed2 – GCC v4.6.2

The code that powers each server is found in this gist. All servers should behave in almost the exact same way. They all produce a “Hello World” 200 text/plain response.

The tests are run with “ab” with the following settings:

 ∞ ~ ab -c 10 -n 1000 http://127.0.0.1:8080/

In order to compile node.native on OS X I installed GCC 4.6.2 separately from XCode’s, and I removed the linking to librt unavailable on the mac.

The results

The clear winner of the simple benchmark is node.native, followed by Luvit and Node.JS, being almost 40% and 80% faster respectively.

Keep in mind this should be used as a vague reference and ongoing experiment, rather than a benchmark study to make actual decisions from.

It’s still interesting to see the application of libuv and the Node.JS model to other languages and the performance differences of the implementations, none of which in my opinion significant enough so far to dethrone JavaScript as the one language to rule them all.

Update: following node.native’s author advice, compiling node.native with the right optimization flags has yielded a drastic performance increase! The benchmark results have been updated to reflect this.

This “problem” is rooted of course in significantly different architectures. In the case of, for example, PHP applications we traditionally separate the role of the web server and request handler. The monolithic web server maps incoming requests to the execution of particular files in the file system, which become our handlers.

In most setups, the web server is mostly limited to inspecting two pieces of a HTTP request: the resource (like /test.php) and the Host header (like www.mydomain.com) for virtual hosts (vhosts) support.

GET /test.php HTTP/1.1
Host: www.mydomain.com

With this in place, it’s up to the execution of the “test.php” file to handle the work and produce the response. If we change this file, even while other requests are ongoing, subsequent requests will be handled by our new code.

In Node.JS, this separation is not part of the core design. You write your web server and requests handlers as part of the same unit. This of course is the result of a tradeoff: Node.JS offers complete control over how the entire system operates, allowing programmability of aspects beyond the execution of a request. This includes for example, control over the connections that trigger the requests, easy awareness of other connections/requests, and other details that made the development of software like Socket.IO possible.

var server = require('http').createServer(onRequest);
server.listen(80);

function onRequest (req, res) {
  res.writeHead(200);
  res.end('Hello world');
});

The need for seamless code reloads extends into the realm of production deployment as well: one needs to be able to serve new requests with fresh code immediately, without breaking existing ones (such as file uploads or content transfer).

The up solution

Over at LearnBoost, we’ve solved these problems with two small projects: distribute and up.

In order to reload code without dropping requests, no changes to a codebase are needed other than ensuring that there’s a file that exports a http.Server as a module (let’s call it server.js).

  var server = require('express').createServer();
  // … code
  module.exports = server;

Then, during development you can leverage up from the CLI:

$ up --watch --port 8080 server.js

The --watch flag will watch the working directory for changes. up will start workers to handle the requests, and reload them seamlessly. Alternatively, one can also do this programmatically. In the following example I listen on the SIGUSR2 signal to trigger a reload, which allows for easy interoperability between components.

var up = require('up')
  , master = http.createServer().listen(8080)

var srv = up(master, __dirname + '/server');

process.on('SIGUSR2', function () {
  srv.reload();
});

The power to distribute

The server returned by up builds on top of another LearnBoost project called distribute, which leverages node-http-proxy by NodeJitsu

The idea is simple: we can handle requests to be proxied in a middleware-style API. This allows us to solve, for example, the lack of multiple VHosts:

var httpServer = require('http').createServer()
  , srv = require('distribute')(httpServer);

httpServer.listen(80);

srv.use(function (req, res, next) {
  if ('blog.learnboost.com' == req.headers.host) {
    next(3500); // port 3500
  } else {
    next(3000); // otherwise port 3000
  }
});

And since it’s possible to re-use and chain multiple middleware functions together, it provides a proven foundation for code re-usability. In fact, it’s possible to leverage existing Express/Connect middleware like query string or cookie parsing, should a certain proxying function need it.

Head to GitHub for the projects, or find them on NPM as distribute and up. And stay tuned for an upcoming distribute middleware component release.