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.

I’ve been waiting for a while for mainstream Twitter clients to allow keyword or pattern based filtering, and when I realized people were starting to tweet about the 49ers the night before the game, I decided to finally address it myself.

The technique I’m going to describe consists in setting up a proxy to the Twitter API that lives in our computer, powered by Node.JS, that filters back responses based on arbitrary rules we setup. Not only does this give us the flexibility of using JavaScript, but it also means it will work with any Twitter client that leverages the API transparently. Yes, this includes the Twitter website!

The premises

Before we begin, we must fully understand how the majority of Twitter desktop (and mobile) clients work.

1. The app first needs to authenticate the user. Two methods can be used:

   OAuth: relies on the user going to a web page that grants access.
   
   XAuth: asks for user and password. This is the most practical method of authentication for a custom client, and this is the technique that Twitter for Mac uses.

2. Once this authorization is successful, the Twitter client will make HTTP requests to the Twitter API (located at api.twitter.com). In order to make these requests on behalf of the user, it must first sign them. To sign a request means to add an Authorization header that’s created with a token obtained on step 1.
3. Just like any other application that leverages the API, the Twitter client will then exchange content in some format (XML or JSON).

Our plan of action

1. We’ll leverage the internal DNS lookup system (/etc/hosts) to override api.twitter.com and make it point to a Node.JS server hosted locally.
2. Since the Twitter client will attempt to connect to our overridden IP over port 443, we’ll set up a “second” loopback interface 127.0.0.2. This will prevent our Twitter hack from getting in the way of your projects and apps that try to serve traffic on port 443.
3. To bypass SSL security checks in the client, we’ll set up a new root certificate for our computer that validates 127.0.0.2 claims that it is api.twitter.com.
4. We’ll forward all requests to Twitter, but we’ll capture the response of the timeline one to execute our filters.
5. We’ll expose a middleware API for filters to be setup.

Forwarding api.twitter.com

Redirecting api.twitter.com to 127.0.0.2 is as straightforward as editing /etc/hosts:

∞ ~ sudo sh -c "echo '127.0.0.2 api.twitter.com' >> /etc/hosts"
∞ ~ tail -n 1 /etc/hosts
127.0.0.2 api.twitter.com

There’s no place like 127.0.0.2

Our plan is to capture all the HTTPS traffic going to api.twitter.com over port 443, by forwarding it to 127.0.0.2. To accomplish this, we must first make that IP resolve to our loopback interface.

On OS X, we can accomplish this by aliasing it to lo0:

∞ ~ sudo ifconfig lo0 alias 127.0.0.2

As a result, we can now bind to port 443 over distinct IP addresses. As a test, you can run the following Node programs (with sudo):

require('http').createServer(function (req, res) {
  res.writeHead(200);
  res.end('welcome to 127.0.0.1:80');
}).listen(80, '127.0.0.1');

require('http').createServer(function (req, res) {
  res.writeHead(200);
  res.end('welcome to 127.0.0.2:80');
}).listen(80, '127.0.0.2');

Pointing your browser to http://127.0.0.1 and http://127.0.0.2 will yield different responses.

Port 443 or port 3000?

In our previous Node servers examples, binding to port 80 forced us to use sudo, since it’s considered a privileged port. We can skip this every time we need to run our server by forwarding the traffic destined to port 443 over 127.0.0.2 to the unprivileged port 3000:

∞ ~ sudo ipfw add fwd 127.0.0.2,3000 tcp from any to 127.0.0.2 443 in

As a result, we can now run code like this (notice I run listen() with 3000)

function read (file) { return require('fs').readFileSync(__dirname + '/' + file, 'utf8'); };
require('https').createServer({
    key: read('key.key')
  , cert: read('cert.crt')
}, function (req, res) {
  res.writeHead(200);
  res.end('welcome to ' + req.headers.host + ' bound to 127.0.0.2:3000');
}).listen(3000, '127.0.0.2');

But still point our browser to https://api.twitter.com, just like the Twitter client will do:

For this example, I used self signed certificates that will trigger a security warning. You can download this example from here.

Hacking SSL

At this point, not only will our Twitter client be unable to make any requests (since we’re not proxying them yet), but it will be refuse to establish any connection at all, due to the SSL checks:

The client is onto us! Stop SOPA!

Thankfully, it’s fairly for us to create a new certificate Root (like VeriSign), then generate a certificate request that we sign our own Twitter certificate with. If we then install the root certificate at the system level, the Twitter client and browsers will recognize it as legitimate.

We start by creating our root. For this, we can leverage a perl script that ships with OpenSSL. We also first create a ~/root directory where all the generated files will be kept:

 ∞ ~ mkdir ~/root
 ∞ ~ cd ~/root/
 ∞ root perl /System/Library/OpenSSL/misc/CA.pl -newca

This will ask a series of questions, most of which you can respond with the default value. Set the passphrase when asked. When it asks for a Common Name, set it to something easily identifiable like “Guillermo”, in case you want to remove the root certificate in the future from your system.

The result will be the creation of a directory called demoCA, which contains the root certificate database.

Now that we rolled our own VeriSign, we want to do what we normally do when we get real certificates for our websites. Generate a key, generate a signing request and sign it ourselves:

 ∞ root openssl genrsa 1024 > api.twitter.com.key
Generating RSA private key, 1024 bit long modulus
....++++++
.......++++++
e is 65537 (0x10001)
 ∞ root openssl req -new -key api.twitter.com.key -out newreq.pem

The second command will again ask a series of questions. The only one that matters is the Common Name. Set it to api.twitter.com

Our friend the perl script can also aid in the process of signing a request file (in this case newreq.pem).

 ∞ root perl /System/Library/OpenSSL/misc/CA.pl -sign

The signature process is very difficult and gruesome and that’s why certificates are very expensive: type in your passcode, write y and press enter.

The signature process will yield a file newcert.pem, which we want to rename to api.twitter.com.crt to easily identify it.

We now have the .key and .crt files that we’ll give to our Node web server. But before we let the Twitter client attempt a connection, we install the root certificate located at ~/root/demoCA by double-clicking it:

Proxying

Let’s try setting up our newly signed certificate and outputting our incoming requests.

require('https').createServer({
    key: read('api.twitter.com.key')
  , cert: read('api.twitter.com.crt')
}, function (req, res) {
  console.error(' - \033[96m%s\033[90m %s\033[39m'
    , req.method, req.url);
  res.writeHead(500);
  res.end();
}).listen(3000, '127.0.0.2');

If we run our server and relaunch Twitter for mac, we should see the requests flowing in:

Our own Twitter client now trusts us! And since we're replying with status code 500, it reflects it:

Our proxying strategy is as follows:

1. We capture all requests.
2. We create new requests (using superagent) that we send to twitter over their IP (since api.twitter.com resolves to our own computer).
3. To avoid dealing with gzip, we want to re-write the responses to not include Content-Encoding. Ideally we'd also re-write the request to exclude Accept-Encoding, but this would invalidate the OAuth signature.
4. When the response comes back, we send it back unless it targets the home_timeline API endpoint.
5. For timeline requests, we parse the XML, we filter or change what we want, we re-encode it and send it back. Since we're changing the response body, some headers will need to be altered, like Content-Length.

Re-writing

To illustrate the rewriting process, consider this example in which we replace all our tweets with the text "haha":

The first thing we want to do is detect the requests for the home_timeline.xml endpoint:

// detect timeline xml request
var filter = /home_timeline\.xml/.test(req.url);

Then, we want to buffer all the request data for the incoming request:

var data = '';
req.on('data', function (chunk) { data += chunk; });
req.on('end', function () {
  // …
});

We finally create our new request, and parse the XML with the excellent libxmljs by Marco Rogers.

var proxy = request[req.method.toLowerCase()]
  ('https://199.59.149.232' + req.url)

if (data) proxy.send(data);

proxy.end(function (apiRes) {
  // delete content-encoding
  delete apiRes.headers['content-encoding'];

  // parse xml
  if (200 == apiRes.status && filter) {
    var doc = libxml.parseXmlString(apiRes.text);
    doc.find('//text').forEach(function (node, i) {
      node.text('haha');
    });
    proxy(doc.toString());
  } else {
    proxy(apiRes.text);
  }

  function proxy(text) {
    // rewrite content-length
    apiRes.headers['content-length'] = text.length;
    res.writeHead(apiRes.status, apiRes.headers);
    res.end(text);
  }
});

This is a slightly over-simplified example. In reality, in order for the OAuth signature to stay valid we need to proxy the headers exactly as we receive them. Node.JS unfortunately lowercases all headers, and drops the original strings. I performed the following replacement to try to restore them to their originals based on convention:

for (var i in req.headers) {
  var h = i.replace(/^[a-z]|-[a-z]/g, function (a) {
    return a.toUpperCase();
  });
  proxy.set(h, req.headers[i]);
}

In part II I’ll describe the creation of the API that lives on top of the proxy to ease on the tweet re-writing and filtering process exposed to the end user through a NPM module.

The problem boils down to the usage of {} as a data-structure where the keys are supplied by untrusted user input, and the mechanisms that are normally used to assert whether a key exists.

Consider the example of a simple blog created with Express. We decide to store blog posts in memory in a {}, indexed by the blog post slug. For example, this blog post would be posts['an-object-is-not-a-hash'].

We start writing the route /create, which takes a few POST fields like “title” and “slug” and passes it to a Post constructor.

var posts = {};

app.post('/create', function (req, res) {
  if (req.body.title && req.body.slug) {
    // avoid duplicates
    if (!posts[req.body.slug]) {
      posts[req.body.slug] = new Post(req.body);
      res.send(200);
    } else {
      res.send(500);
    }
  }
});

Our first stab for trying to avoid duplicates is checking whether the key exists in our object.

    if (!posts[req.body.slug]) {

Normally this would work fine, but let’s consider that the user could pick any of the keys that are present in any JavaScript object as a name:

 __defineGetter__       __defineSetter__          valueOf
 __lookupGetter__       __lookupSetter__
constructor             hasOwnProperty
isPrototypeOf           propertyIsEnumerable
toLocaleString          toString

If the user wanted to, for example, name his blog post "constructor" our program would behave incorrectly. We therefore change our code to leverage hasOwnProperty, which will allows to check whether the property has been set by us:

  if (!posts.hasOwnProperty(req.body.slug)) {
    posts[req.body.slug] = new Post(req.body);
    res.send(200);
  }

Most JavaScript programmers are already familiar with hasOwnProperty, since in the browser world it’s the standard way of writing libraries that work well in environments where Object.prototype is modified, so this addition should come to most as no surprise.

The hasOwnProperty trap

Our program, however, is still susceptible to potential misbehaving. Let’s say our user decides to call his blog post "hasOwnProperty". The first time our check executes, everything will behave correctly, since the check will return false:

 ∞ ~ node
> var a = {};
> a.hasOwnProperty('hasOwnProperty')
false

Our code would therefore set the hasOwnProperty value in our object to the Post instance, which is an object. We can now simulate what would happen if the user tries that again:

> a.hasOwnProperty = {}
{}
> a.hasOwnProperty('hasOwnProperty')
TypeError: Property 'hasOwnProperty' of object #<Object> is not a function
    at [object Context]:1:3

As a result:

• Our code would throw a (potentially) uncaught exception.
• Execution of our /create route would be aborted and response would not be sent to the user.
• The request would be left hanging until it times out on both ends.

The solution to this problem is to avoid relying on the “hasOwnProperty” provided by the object we’re dealing with, and use the generic one from the Object.prototype. If we execute it on our test subject, true will be returned after we set it as expected:

> Object.prototype.hasOwnProperty.call(a, 'hasOwnProperty')
true

Conclusions

The first conclusion from this experiment is that from the moment we decide to use a JavaScript object as a general-purpose hash table we can no longer rely on any of its inherited properties, specially hasOwnProperty (which we’re normally bound to use). This oversight, as a matter of fact, afflicted the Node.JS core querystring library in the past.

If your code relies heavily on data structures where the possibility for collisions like this exist, you might want to consider having a has utility around:

function has (obj, key) {
  return Object.prototype.hasOwnProperty.call(obj, key);
}

And use it as follows:

  if (has(posts, req.body.slug)) { }

As a side note, you should generally stick to this method in the browser environment as well. Host objects such as window in older Internet Explorer versions do not have hasOwnProperty, leading to potentially inconsistent behavior in your code.

As correctly pointed out by different comments and tweets, another possibility surfaces in Node.JS:

  var posts = Object.create(null);

This will yield an object with a null prototype, which therefore does not inherit any methods, and would simplify our code to look like the original example:

    if (!posts[req.body.slug]) {}

Finally, a hashing scheme such as a prefix could do the job as well:

    if (!posts['posts-' + req.body.slug]) {
      posts['posts-' + req.body.slug] = new Post(req.body);
    }

// A:
function myFunction () {
  if (somethingWrong) {
    throw 'This is my error'
  }
  return allGood;
}

and

// B: async Node.JS-style callback with signature `fn(err, …)`
function myFunction (callback) {
  doSomethingAsync(function () {
    // …
    if (somethingWrong) {
      callback('This is my error')
    } else {
      callback(null, …);
    }
  });
}

In both cases, passing a string instead of an error results in reduced interoperability between modules. It breaks contracts with APIs that might be performing instanceof Error checks, or that want to know more about the error.

Error objects, as we’ll see, have very interesting properties in modern JavaScript engines besides holding the message passed to the constructor.

The stack property

The fundamental benefit of Error objects is that they automatically keep track of where they were built and originated.

The mechanism of how this happens is specific to each JavaScript engine and/or browser that implements it.

V8 (Node.JS)

The way that V8 handles this, which directly affects us who develop in Node.JS is described by the StackTraceApi document.

We can test its behavior by simply initializing a Error object and inspecting its stack property:

// error.js
var err = new Error();
console.log(typeof err.stack);
console.log(err.stack);

∞ node error.js
string
Error
    at Object.<anonymous> (/private/tmp/error.js:2:11)
    at Module._compile (module.js:411:26)
    at Object..js (module.js:417:10)
    at Module.load (module.js:343:31)
    at Function._load (module.js:302:12)
    at Array.0 (module.js:430:10)
    at EventEmitter._tickCallback (node.js:126:26)

As you can see, even without throwing or passing it around, V8 is able to tell us exactly where that object was created, and how it got there.

By default, V8 limits the stack trace size to 10 frames. You can alter this by changing the Error.stackTraceLimit during runtime.

Error.stackTraceLimit = 0; // disables it
Error.stackTraceLimit = Infinity; // disables any limit

Custom Errors

If you wanted to extend the native Error object so that stack collection is preserved, you can do so by calling the captureStackTrace function. This is an example extracted from the Mongoose ODM

function MongooseError (msg) {
  Error.call(this);
  Error.captureStackTrace(this, arguments.callee);
  this.message = msg;
  this.name = 'MongooseError';
};

MongooseError.prototype.__proto__ = Error.prototype;

The second argument passed to the captureStackTrace prevents unnecessary noise in the stack generation by hiding the MongooseError constructor calls from the stack.

Beyond stack strings

As you might have noticed in my previous code example, I purposedly printed the typeof of the stack property. As it turns out, it’s a regular String with a format optimized for readability.

V8, much like Java, allows complete runtime introspection of the stack. Instead of a string, we can access an array of CallSites that retain as much information as possible about the function call in the stack, including the object scope (this).

In this example, we override the prepareStackTrace function to access this raw array and examine it. We call `getFileName` and other methods on each CallSite (all the available methods are described here)

function a () {
  b();
}

function b () {
  var err = new Error;

  Error.prepareStackTrace = function (err, stack) {
    return stack;
  };

  Error.captureStackTrace(err, b);

  err.stack.forEach(function (frame) {
    console.error(' call: %s:%d - %s'
      , frame.getFileName()
      , frame.getLineNumber()
      , frame.getFunctionName());
  });
}

a();

This is an example of the output this script produces:

∞ node error-2.js
call: /private/tmp/error-2.js:3 - a
call: /private/tmp/error-2.js:23 -
call: module.js:432 - Module._compile
call: module.js:450 - Module._extensions..js
call: module.js:351 - Module.load
call: module.js:310 - Module._load
call: module.js:470 - Module.runMain
call: node.js:192 - startup.processNextTick.process._tickCallback

All this functionality would of course be non-existent if we were to pass around strings, therefore drastically shrinking our debugging panorama.

For real-world usage, restoring the original prepareStackTrace after overriding it is probably a good idea. Thankfully, TJ Holowaychuck has released a tiny callsite module to make this painless.

Browsers

Like the V8 document states:

The API described here is specific to V8 and is not supported by any other JavaScript implementations. Most implementations do provide an error.stack property but the format of the stack trace is likely to be different from the format described here

• Firefox exposes error.stack. It has its own format.
• Opera exposes error.stacktrace. It has its own format.
• IE has no stack.

A very interesting solution to this is provided by javascript-stacktrace, which attempts to normalize a printed stack trace across all browsers.

On IE (and older versions of Safari), for example, it uses a clever method: it recursively looks for the caller property of a function, calls toString on it and parses out the function name.

var currentFunction = arguments.callee.caller;
while (currentFunction) {
  var fn = currentFunction.toString();
  var fname = fn.substring(fn.indexOf("function") + 8, fn.indexOf('')) || 'anonymous';
  callstack.push(fname);
  currentFunction = currentFunction.caller;
}

Conclusions

• When doing async I/O (in Node.JS or otherwise), since throwing is not a
  possibility (as it results in uncaught exceptions), Errors are the only way to
  allow proper stack trace collection.
• Even in non-V8 browser environments, it’s probably a good idea to still initialize
  Errors. The API exists in all browsers, and the extended API facilities that V8
  provides are bound to be available to most engines in the future.
• If you’re throwing or passing around strings for errors, consider switching today!

The examples in the beginning of the post can thus be rewritten this way:

// A:
function myFunction () {
  if (somethingWrong) {
    throw new Error('This is my error')
  }
  return allGood;
}

and

// B: async Node.JS-style callback with signature `fn(err, …)`
function myFunction (callback) {
  doSomethingAsync(function () {
    // …
    if (somethingWrong) {
      callback(new Error('This is my error'))
    } else {
      callback(null, …);
    }
  });
}

Some of the new features that I’m excited about:

• Clearly defined post types: article, code snippet, video, photo and quote.
• Cool dynamic filtering and Twitter-like pagination. (#hash and pushState to come soon)
• Projects page that highlights my past and present work
• CSS3 animated sidebar with links to social networks & bio
• Commenting through DisqUS customized to my needs

As far as my old posts, they’re hidden from the main view so that I can focus on my current topics of interest:

• Open Source development
• Node.JS and JavaScript as the ubiquitous dynamic language
• “NOSQL” Databases and scalability
• Server administration
• User experience & design
• Startups

I have many articles lined up for you guys, so please look forward to my updates. Also, keep in mind certain things still need tweaking and are likely to change or improve over the next few days.

Remember to stay in touch through Twitter or RSS!

I’m excited to announce that my company has raised a seed round of $975K from several leading angels and venture capital firms. Our VC’s are Bessemer Venture Partners, Charles River Ventures, RRE Ventures, and Atlas Ventures. Our angels include Naval Ravikant, Bill Lee, James Hong, Othman Laraki, Karl Jacob, and several other fantastic angels. We’re thrilled this entire group of investors share LearnBoost’s vision for developing free and amazing software for schools.

In early August, LearnBoost will release our free, easy-to-use, and beautiful application built on the powerful technology we’ve developed. LearnBoost completely replaces other gradebook providers, both free and paid. Our accounts give teachers a free gradebook to manage their classroom, as well as integrated software to create and manage lesson plans, track attendance in a list or innovative visual format, maintain schedules, import and integrate Google calendars, “tag” standards to assignments and lesson plans, and much more. If you are a teacher, or know a teacher, they can use our software for free — please tell them to get on our free account list.

We’ll be using this funding to move towards developing the best student information system on the market, in addition to the free teacher software we’ll be releasing in August. We’re aiming right at Blackboard, Pearson, and other slow legacy software providers with our free, wonderful offerings. We closed our financing a few months ago, so we already have a team in place to reach our goals. That said, we’re always looking for more talent; if you are a developer or designer and want to be part of a fast-growing team dedicated to education and open source software, please check out our jobs page.

So what’s next? If you’re a teacher or know a teacher, tell them about LearnBoost and make sure they get on the free account list. Our free and amazing software can be used by any teacher and in our test phase we’ve gotten lots of praise already. I’m excited for our release in early August and to continue to share our open source releases and developments.

Guillermo Rauch
LearnBoost CTO

As I was glancing the list of files, I notice one called close.gif, which specially intrigued me: when I released the initial version of my project TextboxList (MooTools, jQuery), that’s exactly what I had called the sprite image which contained the normal, hover and active states of the boxes close buttons.

But there was a small problem: in the entire GitHub repository, I couldn’t find a single mention of my name or my website.

The early days of TextboxList

Around January 2008, I announced the first open source widget released under the MIT license intended to mimic the behavior of the Facebook tokenizer.

The header of the source file, still up today, contains two interesting bits:

Credits:
  - Idea: Facebook + Apple Mail
  - Caret position method: Diego Perini 

I included credit for the ideas and sources of inspiration, and for a relevant key piece of source code which had been written by another developer.

The second interesting bit is my copyright message:

/* Copyright: Guillermo Rauch  - Distributed under MIT - Keep this message! */

When I started writing this project, I was a 16-year-old high school student trying to seek some recognition for a piece of work given away for free. Today, with the message formatting unchanged we can find:

/* Copyright: Emposha.com  - Distributed under MIT - Keep this message! */

The problems

1. The file close.gif was copy-pasted

2. The stylesheet was entirely copy-pasted.

   For the first release of the project, I wrote an article about the thought process behind the creation of the widget.

   One of the core ideas emphasized in it is that you should start by having the markup and CSS be as bullet proof as possible, as you don’t want to hinder the JavaScript development with debugging related to style, positions, floats, and you don’t want to solve problems within JavaScript that CSS alone can solve. Years later, this is still a design principle I live by for the creation of web applications

3. At 550 lines of code, it has considerably less features than my very old version at 350 lines of code. Namely, no keyboard navigation of the boxes, one of the premises of the original Facebook tokenizer.

   Since my first release, the entire codebase was re-written, with full documentation and many more characteristics. This version wasn’t released under MIT. However, hundreds of people are using it for free, others have chosen to willingly contribute (as I have no mechanisms to prevent unfair use), and special licenses were given to open source projects, companies with dozens of subdomains and very well known web application makers.

4. Many parts of the code show a striking resemblance, which of course is not coincidental.
5. Even the JSON data used to feed autocompletion values, which is a collection of my favorite argentinean writers, has been blatantly reproduced. Quite interesting considering the author seems to be from Israel, and I’m sure he wasn’t just including it out of passion for good foreign literature.
6. Under these conditions, it managed to sneak dozens of commits from people in the community, including Chris Williams. It’s left for me to wonder if they ever learned of all the effort that took me to research this particular problem and execute its solution, now shown to the world under a very intriguing brand.

Update: special thanks to Chris Williams who updated his fork to reflect proper copyright

Alex Russell – “Google Chrome Frame”
Post: http://alex.dojotoolkit.org/
Slides: http://alex.dojotoolkit.org/10/jsconf/gcf.html

Francisco Tolmasky – “Socratic: Documentation Done Right”
GitHub: http://github.com/tolmasky/socratic
Slides: ?

Aaron Newton – “Programming To Patterns”
Slides: http://www.slideshare.net/guest2ee5e2c/programming-to-patterns-presentation (not up-to-date)

Jed Schmidt – “A (fab) approach to web apps”
GitHub: http://github.com/jed/fab
Slides: http://www.flickr.com/photos/tr4nslator/sets/72157623883700702/show/

Dmitry Baranovskiy – “Raphaël the Great”
Slides: http://www.slideshare.net/Dmitry.Baranovskiy/raphal-js-conf

Douglas Crockford – “Really, JavaScript?”
?

Tobias Schneider – “Flash is dead, long live Flash!”
GitHub: http://github.com/tobeytailor/gordon
Slides: http://www.slideshare.net/ConfEcho/flash-is-dead-long-live-flash

Makinde Adeagbo – “Primer: Facebook’s 2k of JavaScript to power (almost) all interactions”
Slides: http://www.slideshare.net/makinde/javascript-primer

Steve Souders – “The Best of Steve”
Slides: http://www.slideshare.net/souders/jsconf-us-2010

Jenn Lukas – “JavaScript and Web Standards Sitting in a Tree”
Slides: http://www.slideshare.net/JennLukas/javascript-and-web-standards-sitting-in-a-tree

Ryan Dahl – “Less is More in Node.js”
Slides: http://nodejs.org/jsconf2010.pdf

Billy Hoffman – “JavaScript’s Evil Side”
Slides: ?

John David Dalton – “All you can leet”
Slides: http://www.slideshare.net/johndaviddalton/jsconf-all-you-can-leet

Aaron Quint – “Making Bacon / Making Code”
GitHub: http://github.com/quirkey/sammy
Post: http://www.quirkey.com/blog/2010/04/20/making-baconmaking-code-jsconf-2010/
Slides: http://swinger.quirkey.com/#/preso/aq-jsconf/display/1
Video: http://bit.ly/9j7u3L

Dion Almaer, Ben Galbraith, and Matt McNulty – “The mobile web”
Slides: http://www.slideshare.net/dion/the-mobile-web-2010-jsconf

With code as simple as this:

socket = new io.Socket('localhost');
socket.connect();
socket.send('some data');
socket.addEvent('message', function(data){
    alert('got some data' + data);
});

you’ll be leveraging:

• WebSocket
• Adobe Flash Socket
• ActiveX HTMLFile (IE)
• Server-Sent Events (Opera)
• XHR with multipart encoding
• XHR with long-polling

And on the server side, things are equally simple. This is a chat application written in Socket.IO-node, the Node.JS backend implementation:

var buffer = [], json = JSON.stringify;

io.listen(server, {

	onClientConnect: function(client){
		client.send(json({ buffer: buffer }));
		client.broadcast(json({ announcement: client.sessionId + ' connected' }));
	},

	onClientDisconnect: function(client){
		client.broadcast(json({ announcement: client.sessionId + ' disconnected' }));
	},

	onClientMessage: function(message, client){
		var msg = { message: [client.sessionId, message] };
		buffer.push(msg);
		if (buffer.length > 15) buffer.shift();
		client.broadcast(json(msg));
	}

});

As usual, head to GitHub to experiment with the code.

The new Google Chrome Beta for mac and the alpha 1Password extension work perfectly together!