TJ Holowaychuk

mad(1) node.js pages

Sat, 19 May 2012 13:22:00 -0700

The node.js markdown documentation is now viewable in the terminal via mad(1):

Just use mad list to see which pages are available:

If you already have mad(1) installed simply run mad --update to grab these new pages, and view with mad node.http etc.

Express 3.x alpha reference docs

Wed, 18 Apr 2012 17:47:00 -0700

Since I don’t have the Express 3.x site up yet I thought I would whip up a quick set of markdown docs from the source comments using dox.

To view these markdown docs in your terminal install mad(1):

$ cd /tmp && git clone --depth 1 git@github.com:visionmedia/mad.git && cd mad && make install

Update your mad-pages:

$ mad --update

Profit!

$ mad express

HINT: Press “/”, type and press enter to search. The keys u and n move to the prev / next occurrences:

HINT HINT: There are also mad(1) pages for Jade, HTTP status codes, errnos and others.

Express 3.0.0 alpha1

Sun, 15 Apr 2012 12:21:00 -0700

I just released the first alpha, but beware! the documentation has not been updated. I wanted to defer a release until I had time to re-write the site, but meanwhile people have been using the master branch anyway, so we might as well make it official (and available via npm).

The alpha is by no means complete, some features still need adjusting, though mainly internal refactoring. The wiki contains both the 2.x to 3.x migration guide, and documentation for most of the new features added. It’s worth noting you’ll also gain new features from Connect 2.x as well, which Express 3.x depends on.

There are quite a few new http utilities, better reverse proxy support, and refinements to the view system. Express 3.x is even smaller than 2.x totalling 975 SLOC according to sloc(1), where Express 2.x was around 1300. Most of the effort goes into actually removing and refining code to increase quality, and lots of test coverage (4286 SLOC).

I’ve also started a Express 4.x Roadmap with some details on where things may go in the future.

Contributing

If you’d like to contribute, one of the best ways right now would be to help upgrade the ./examples ! The Express repo has many examples, roughly half of which still use 2.x code and may not work. This time around we have test coverage for these examples, but many still need to be upgraded. To contribute first install the development dependencies:

$ npm install

Then run the acceptance tests:

$ make test-acceptance

Add some tests for an example, write some tests, make sure they work, then open a pull-request :)

That’s all for now! When I have time I’ll be rewriting the site, updating the wiki, and of course finishing the release. If there’s anything you find yourself doing often and think has a home in core let me know!

cheers!

EDIT: If you’re looking for docs we now have some auto-generated docs that you can view in your terminal. View this post.

Going mad(1)

Sat, 14 Apr 2012 12:59:00 -0700

mad(1) is a tiny tool that allows you to view markdown manual pages. I’m a huge fan of man in general, but the format is pretty annoying and often converted from markdown, textile etc anyway. The output man produces is also pretty bad in my opinion, mainly whitespace issues.

This is just a quick 5 minute hack so follow if you’re interested or open an issue if you have some ideas! It would be great to allow customization of colors, formatting, blah blah. Here’s another screenshot:

Mocha 1.0

Sat, 24 Mar 2012 10:58:00 -0700

The Mocha JavaScript test framework has hit 1.0 with a bunch of great contributions from the community, here’s the change log:

Added js API. Closes #265
Added: initial run of tests with --watch. Closes #345
Added: mark location as a global on the CS. Closes #311
Added markdown reporter (github flavour)
Added: scrolling menu to coverage.html. Closes #335
Added source line to html report for Safari [Tyson Tate]
Added “min” reporter, useful for --watch [Jakub Nešetřil]
Added support for arbitrary compilers via . Closes #338 [Ian Young]
Added Teamcity export to lib/reporters/index [Michael Riley]
Fixed chopping of first char in error reporting. Closes #334 [reported by topfunky]
Fixed terrible FF / Opera stack traces

Compiler support

coffee-script out of the box was removed, now you can used the --compilers <ext>:<module>,... flag to map a compiler to the given extension name. For example mocha --compilers coffee:coffee-script. There are simply too many foo -> JavaScript transpilers to directly support, this pushes that back on the author.

Min reporter

First up is the min reporter by Jakub Nešetřil, this tiny reporter works great with --watch, outputting the summary only, though still reporting verbose errors on failure.

Markdown reporter

I added a markdown reporter which can be used to display your tests as documentation in a Github wiki page, or simply a markdown file in your repository that you can link to. For example here are the Connect markdown test docs.

I’m not super happy with how much padding Github adds, so the TOC looks pretty messy, but all of these document-style reporting mechanisms make you think twice about how clean and organized your tests are.

JavaScript API

A new JS API was added, which mocha(1) now utilizes. This higher-level JS API will make it easier for those who want to script the testing process with Mocha. I have yet to document this API but it looks like this:

var Mocha = require('mocha');

var mocha = new Mocha;
mocha.reporter('spec').ui('bdd');

mocha.addFile('test/suite.js');
mocha.addFile('test/runner.js');
mocha.addFile('test/runnable.js');

var runner = mocha.run(function(){
  console.log('finished');
});

runner.on('pass', function(test){
  console.log('... %s passed', test.title);
});

runner.on('fail', function(test){
  console.log('... %s failed', test.title);
});

amysteen: Maru being Maru.

Sat, 24 Mar 2012 10:43:49 -0700

amysteen:

Maru being Maru.

Redis Lua scripting is badass

Wed, 14 Mar 2012 18:23:00 -0700

Roughly a year ago Salvatore Sanfilippo the author of Redis wrote a blog post discussing the inclusion of Lua as a scripting language. I finally decided to try this out, and let’s just say it’s pretty badass.

Lua is a great fit for Redis, they have similar philosophies, being simple, small, and fast. Suppose for example you have 200,000 jobs, each represented in Redis as a hash, and you want to map/reduce the job duration, the new scripting capabilities make this really easy!

Here’s the node setup script to generate these jobs:

  var redis = require('redis')
    , db = redis.createClient();

  var n = 500000
    , pending = n
    , ms;

  while (n--) {
    ms = Math.random() * 200 | 0;
    db.hset('job:' + n, 'duration', ms, function(){
      --pending || process.exit();
    })
  }

Next here is what you might consider scripting in your host language without the new Redis scripting feature, manually reducing the value:

  var redis = require('redis')
    , db = redis.createClient();

  var n = 200000
    , start = new Date
    , pending = n
    , ms = 0;

  while (n--) {
    db.hget('job:' + n, 'duration', function(err, n){
      if (err) throw err;
      ms += ~~n;
      --pending || (function(){
        console.log('%d minutes spent processing jobs', ms / (1000 * 60) | 0);
        console.log('took %ds', (new Date - start) / 1000 | 0);
        process.exit();
      })();
    })
  }

On my Air this took roughly 7s, not too great, keep in mind that there is no throttling here I’m just plastering it with 200k commands. Now let’s try it with Lua! The following script is ad-hoc, but it’ll do the trick. To signal an error all you have to do is return a table with the err slot. redis.call() is effectively the public Redis API exposed to your Redis script, so you can use it just like you would your host language Redis bindings or redis-cli(1).

   local sum = 0
   for i = 0, 200000, 1 do
     local key = "job:" .. i
     local ms = tonumber(redis.call("hget", key, "duration"))
     if ms == nil then return { err = key .. " is not an integer" } end
     sum = sum + ms
   end
   return sum

Here I’ve embedded it in the JS script, but you could of course generate these, load them from files etc (beware of redis-injection?).

   var redis = require('redis')
     , db = redis.createClient();

   var script = '\
   local sum = 0 \
   for i = 0, 200000, 1 do \
     local key = "job:" .. i \
     local ms = tonumber(redis.call("hget", key, "duration")) \
     if ms == nil then return { err = key .. " is not an integer" } end \
     sum = sum + ms \
   end \
   return sum';

   var start = new Date;

   db.eval(script, 0, function(err, ms){
     if (err) throw err;
     console.log('%d minutes spent processing jobs', ms / (1000 * 60) | 0);
     console.log('took %dms', new Date - start | 0);
     process.exit();
   });

After running the script with the new EVAL command what previously took several seconds dropped to ~850ms, much better. EVAL and EVALSHA are actually a lot more flexible than I’ve explained here, accepting keys and arbitrary arguments.

Check out antirez.com/post/an-update-on-redis-and-lua.html for more.

Mocha string diffs

Thu, 01 Mar 2012 15:29:00 -0800

Mocha 0.14.0 adds a single feature - string diffs! This is a small but very handy feature for some. When the strings are small, Mocha will use a character diff, when consisting of several lines a line-numbered “gutter” is added and a word diff is used as shown in the following image:

This is very useful when authoring things like template engines, transpilers, and other string-based libraries. For example the Stylus test suite is comprised of nothing but acceptance tests, the input file is compiled, and the resulting CSS is checked using actual.trim().should.equal(css);. In combination with Mocha’s BDD interface I can now simply iterate through the files and define test-cases as shown here:

  var stylus = require('../')
    , fs = require('fs');

  // test cases

  var cases = fs.readdirSync('test/cases').filter(function(file){
    return ~file.indexOf('.styl');
  }).map(function(file){
    return file.replace('.styl', '');
  });

  describe('integration', function(){
    cases.forEach(function(test){
      var name = test.replace(/[-.]/g, ' ');
      it(name, function(){
        var path = 'test/cases/' + test + '.styl';
        var styl = fs.readFileSync(path, 'utf8');
        var css = fs.readFileSync('test/cases/' + test + '.css', 'utf8');

        var style = stylus(styl)
          .set('filename', path)
          .include(__dirname + '/images')
          .include(__dirname + '/cases/import.basic')
          .define('url', stylus.url());

        if (~test.indexOf('compress')) style.set('compress', true);

        style.render(function(err, actual){
          if (err) throw err;
          actual.trim().should.equal(css);
        });
      })
    });
  })

Now if something were go to wrong, you get a nice diff!

Assertion library authors

To support this feature all you have to do is populate err.expected and err.actual with their respective values, Mocha will take care of the presentation.

NOTE: I just toggled the colors, green is now the expected color

Connect 2.0

Mon, 27 Feb 2012 19:18:00 -0800

Connect 2.0 is here with new core middleware, miscellaneous improvements, and some new docs.

var app = connect()
  .use(connect.logger('dev'))
  .use(connect.static('public'))
  .use(function(req, res){
    res.end('hello world\n');
  })

 app.listen(3000);

HTTP and HTTPS

Previously connect.Server inherited from Node’s core net.Server, this made it difficult to provide both HTTP and HTTPS for your application. The result of connect() (formerly connect.createServer()) is now simply a JavaScript Function. This means that you may omit the call to app.listen(), and simply pass app to a Node net.Server as shown here:

var connect = require('connect')
  , http = require('http')
  , https = require('https');

var app = connect()
  .use(connect.logger('dev'))
  .use(connect.static('public'))
  .use(function(req, res){
    res.end('hello world\n');
  })

http.createServer(app).listen(80);
https.createServer(tlsOptions, app).listen(443);

Body parsers

The bodyParser() middleware is now nothing but a short-hand for adding the json(), multipart(), and urlencoded() middleware. Each of these populate req.body with an object containing the parsed values, multipart() provides req.body and req.files for uploads.

Core compression

As of Node 0.6.0 fast, native compression capabilities are available, so now we have the compress() middleware supporting deflate and gzip.

Cookie parser

The cookieParser() middleware now supports signed cookies, and accepts a secret. This replaces the need to pass session({ secret: string }) to the session() middleware. Signed cookies are available via req.signedCookies, and unsigned as req.cookies.

Error delegation

Previously a few of the core middleware would respond to error situations directly, these have been changed to simply next(err)-them along. This change allows you to specify customized behaviour by adding an error-handling middleware:

app.use(function(err, req, res, next){
  if (4 == err.status / 100) {
    // render a client-error page
  } else {
    // render a server-error page
  }
});

Session

As mentioned session() no longer requires a secret. The cookie .maxAge has been defaulted to null, meaning that it will be a browser-session cookie, expiring once the visitor closes their browser.

Third-party middleware

Third-party middleware should remain perfectly functional. This release of Connect is not compatible with Express 2.x, Express 3.0 is coming soon.

Changelog

The following significant changes were made, as well as several others that do not impact public API, such as a full rewrite of the tests using Mocha.

Added cookieSession() middleware for cookie-only sessions
Added compress() middleware for gzip / deflate support
Added session() “proxy” setting to trust X-Forwarded-Proto
Added json() middleware to parse “application/json”
Added urlencoded() middleware to parse “application/x-www-form-urlencoded”
Added multipart() middleware to parse “multipart/form-data”
Added cookieParser(secret) support so anything using this middleware may access signed cookies
Added signed cookie support to cookieParser()
Added support for JSON-serialized cookies to cookieParser()
Added err.status support in Connect’s default end-point
Added X-Cache MISS / HIT to staticCache()
Added public res.headerSent checking nodes res._headerSent until node does
Changed basicAuth() req.remoteUser to req.user
Changed: default session() to a browser-session cookie. Closes #475
Changed: no longer lowercase cookie names
Changed bodyParser() to use json(), urlencoded(), and multipart()
Changed: errorHandler() is now a development-only middleware
Changed middleware to next() errors when possible so applications can unify logging / handling
Removed http[s].Server inheritance, now just a function, making it easy to have an app providing both http and https
Removed .createServer() (use connect())
Removed secret option from session(), use cookieParser(secret)
Removed connect.session.ignore array support
Removed router() middleware. Closes #262
Fixed: set-cookie only once for browser-session cookies
Fixed FQDN support. dont add leading “/”
Fixed 404 XSS attack vector. Closes #473
Fixed HEAD support for 404s and 500s generated by Connect’s end-point

Mocha test coverage

Thu, 23 Feb 2012 21:30:00 -0800

The latest release of Mocha adds two new reporters, now totaling 13 packaged with the library. The two new ones are “json-cov” and “html-cov”, the latter inherits from the former in order to produce a single-page test coverage report.

If you’re curious what a live example looks like, check out this page.

Setup

With Node’s require.paths array out of the picture there’s a bit of boiler-plate involved in setting up test coverage for your project, but it’s pretty minimal. First you’ll want to install the jscoverage executable, this program parses your source code and spits out an instrumented version, effectively a bunch of lines that look like this:

  $_jscoverage[filename][line]++;

This enables libraries like Mocha to execute the code as they normally would, however we can then extract this coverage information and generate fancy reports. jscoverage takes the input directory, and an output directory, I usually calls this “lib-cov”:

 $ jscoverage lib lib-cov

Typically when testing your library you’ll use relative require() calls that look like this: var express = require('../'), and the library entry point is ./index.js. Normally this file might look something like below, or you may not have an ./index.js file at all.

  module.exports = require('./lib/express');

By using ./index.js we can then alter this statement to conditionally export the instrumented version when the EXPRESS_COV environment variable is present:

 module.exports = process.env.EXPRESS_COV
   ? require('./lib-cov/express')
   : require('./lib/express');

Then all you need to do is invoke mocha with --reporter html-cov and redirect the stdout to a file such as coverage.html. Line 25 the test-cov target of the Express Makefile illustrates how I typically handle this but depending on your setup it may vary.

That’s it! remember to add “coverage.html” to your .npmignore and .gitignore files ;)

Stylus gets @extend

Wed, 11 Jan 2012 13:41:23 -0800

@extend is a great little feature which originated in SASS, and now finds a home in Stylus. If you’ve ever written CSS like this, you know it can become quite the pain to maintain large lists of selectors:

.message,
.warning,
.error {
  font-size: 14px;
  padding: 5px 10px;
  border: 1px solid #eee;
  border-radius: 5px;
}

.warning {
  color: yellow;
}

.error {
  color: red;
}

@extend makes this process flow naturally, and even supports inheritance. In Stylus you may use @extend or @extends, I prefer the latter personally but that’s up to you! Using this feature you would define .message on it’s own, and simply __@extend_ it from within the other rulesets:

.message {
  font-size: 14px;
  padding: 5px 10px;
  border: 1px solid #eee;
  border-radius: 5px;
}

.warning {
  @extends .message;
  color: yellow;
}

.error {
  @extends .message;
  color: red;
}

Taking this even further with inheritance:

.fatal-error {
  @extends .error;
  font-weight: bold
}

Would yield the following CSS:

.message,
.warning,
.error,
.fatal-error {
  font-size: 14px;
  padding: 5px 10px;
  border: 1px solid #eee;
  border-radius: 5px;
}
.warning {
  color: #ff0;
}
.error,
.fatal-error {
  color: #f00;
}
.fatal-error {
  font-weight: bold;
}

Here’s another example:

form
  button
    padding: 10px
    border: 1px solid #eee
    border-radius: 5px

ul
  li a
    @extends form button

Yielding:

form button,
ul li a {
  padding: 10px;
  border: 1px solid #eee;
  border-radius: 5px;
}

And of course you may utilize the alternative Stylus syntax if you prefer:

.message
  font-size: 14px
  padding: 5px 10px
  border: 1px solid #eee
  border-radius: 5px

.warning
  @extends .message
  color: yellow

.error
  @extends .message
  color: red

.fatal-error
  @extends .error
  font-weight: bold

Grab Stylus 0.22.4 for these goodies!

hahaha awesome

Sun, 08 Jan 2012 19:53:05 -0800

hahaha awesome

Why Stylus is the most CSS-like high-level stylesheet language

Sun, 11 Dec 2011 09:09:00 -0800

Why Stylus is the most CSS-like high-level stylesheet language:

This short Vimeo screencast illustrates why Stylus is the most like CSS as a stylesheet “preprocessor”. More on Stylus here.

node "debug" module

Mon, 28 Nov 2011 19:56:00 -0800

node "debug" module

Connect 1.8.0 - multipart support

Thu, 17 Nov 2011 15:47:00 -0800

Connect 1.8.0 is a tiny but substantial release because it adds multipart/form-data support via Felix Geisendörfer’s fantastic multipart parser formidable, it’s great and chances are you’re already using it!

The bodyParser() middleware now unifies multipart, json, and x-www-form-urlencoded parsing, providing the req.body object containing the parsed data. For security purposes the files are placed in a separate object, req.files, however just as accessible. A constant struggle that I’ve seen in the community is the concept of “missing” request data events so this will prevent further confusion. The downside to this is that if you wish to report upload progress, or access files and fields as the request is streamed, you will have to use formidable directly.

Before this addition your use of formidable might look something like the following (with Express):

  app.post('/someform', function(req, res, next){
    var form = new formidable.IncomingForm;
    form.parse(req, function(err, fields, files){
      if (err) return next(err);
      // do something with files.image etc
    });
  });

With the new bodyParser() all you need is:

  app.use(express.bodyParser());

  app.post('/some-form', function(req, res){
    // do something with req.files.image
  })

The middleware takes the same options that are mentioned on formidable’s GitHub repo page, so you can specify things like size limits, retaining extensions, the upload directory etc.

  app.use(express.bodyParser({
    uploadDir: '/tmp/uploads'
  }));

That’s it! but I think this will cover well above the 80% use-case and prevent a lot of headaches that people have with the previous the inconsistencies.

Batman vs Pedophile (vigilante justice)

Wed, 16 Nov 2011 20:38:56 -0800

Batman vs Pedophile (vigilante justice)

Jade & Stylus 0.16.0 released

Mon, 26 Sep 2011 12:56:00 -0700

Jade 0.16.0

This release of Jade adds quite a few new features such block support for include, and template inheritance!

Extended grammar

Jade currently allows you to use JavaScript all over the place, rather than restricting a subset, or implement its own grammar. While this is flexible it tends to make templates look less like … templates! In an effort to make Jade more declarative I’ve added literal support for if, unless, while, until, iteration, assignments and others.

For example I consider it bad practice to define vars in a template, however if you must, you may have previously done something like this:

  - var items = ['foo', 'bar', 'baz']

Jade now allows for assignment, where the right-hand operand is still a regular javascript expression:

   items = ['foo', 'bar', 'baz']

As mentioned if and unless and friends are supported, so the following:

 - if (!(foo && bar))
   p stuff

May now be defined as:

  unless foo && bar
    p stuff

This rule applies to else[ if] as well:

  if something
    p foo
  else if somethingElse
    p bar
  else
    p baz

And finally iteration where each and for are interchangeable:

 - items.forEach(function(item){
   li= item
 - }) 

each item in items
  li= item

for item in items
  li= item

each item, i in items
  li #{i}: #{item}

each val, key in obj
  li #{key}: #{val}

Include blocks

The include directive now supports blocks, so for example one could have head.jade defined as the following:

  head
    script(src='/javascripts/jquery.js')

Allowing you to either include the file as-is:

  html
    include head
    body
      h1 Title

or append to the last block defined, adding additional script tags:

  html
    include head
      script(src='/javascripts/caustic.js')
      script(src='/javascripts/app.js')
    body
      h1 Title

Template inheritance

Jade now supports template inheritance via the block and extends keywords. A block is simply a “block” (indented) of Jade that may be replaced within a child template, this process is recursive.

Jade blocks can provide default content if desired, however optional as shown below by block scripts, block content, and block foot.

// layout.jade
html
  head
    h1 My Site - #{title}
    block scripts
      script(src='/jquery.js')
  body
    block content
    block foot
      #footer
        p some footer content

Now to extend the layout, simply create a new file and use the extends directive as shown below, giving the path (with or without the .jade extension). You may now define one or more blocks that will override the parent block content, note that here the foot block is not redefined and will output “some footer content”.

// index.jade
extends layout

block scripts
  script(src='/jquery.js')
  script(src='/pets.js')

block content
  h1= title
  each pet in pets
    include pet

It’s also possible to override a block to provide additional blocks, as shown in the following example where content now exposes a sidebar and primary block for overriding, or the child template could override content all together.

// funky-layout.jade
extends layout

block content
  .sidebar
    block sidebar
      p nothing
  .primary
    block primary
      p nothing

For the rest of the changes and bug fixes check out the changelog.

Stylus 0.16.0

Fewer changes than the latest Jade however still some good ones!

:= operator

This new operator is an alias of ?= operator, because I think ?= is difficult to read in large quantities for configuration etc:

grid-columns ?= 16
grid-column-width ?= 40px
grid-gutter-width ?= 20px
extra-space ?= 40px

grid-columns := 16
grid-column-width := 40px
grid-gutter-width := 20px
extra-space := 40px

Adjusting color lightness

While the lighten(color, amount) and darken(color, amount) BIFs are still available, the + and - operators now provide the same functionality when used with percentages as illustrated below:

  lighten(black, 50%)
  // => #808080

  black + 50%
  // => #808080

fade-in() & fade-out() BIFs

These small built-in functions are defined in stylus as the following to adjust the opacity:

  // decerase opacity by amount

  fade-out(color, amount)
    color - rgba(black, amount)

  // increase opacity by amount

  fade-in(color, amount)
    color + rgba(black, amount)

For example:

fade-out(#eee, .5)
// => rgba(238,238,238,0.50);

fade-out(fade-out(#eee, .3), .5)
// => rgba(238,238,238,0.20);

Check out the changelog for the other bugfixes and additions.

Stylus 0.15.1 - new property reference & @keyframes fabrication features

Thu, 01 Sep 2011 17:35:08 -0700

Stylus 0.15.x adds a bunch of cool new functionality as well as some important bug fixes.

@keyframes fabrication

The new keyframes fabrication support automatically duplicates your @keyframes definitions to support vendor prefixes. Note that this is only a default, as shown below:

@-moz-keyframes foo {
  0% {
    color: #000;
  }

  100% {
    color: #fff;
  }
}
@-webkit-keyframes foo {
  0% {
    color: #000;
  }

  100% {
    color: #fff;
  }
}
@keyframes foo {
  0% {
    color: #000;
  }

  100% {
    color: #fff;
  }
}

one can tweak this functionality using the vendors list as shown in the following snippet which will only expand to the -webkit- vendor prefix.

vendors = moz official

@keyframes foo {
  from {
    color: black
  }
  to {
    color: white
  }
}

The vendors property may be utilized more in the future, and perhaps in frameworks like “nib” to unify configuration.

Property reference

The syntax @<property> has been introduced to reference values of existing properties. For example if you want to re-use values, you may typically do something like below instead of typing the value several times, also allowing you to use functions with w.

.button
  width: w = 50px
  height: w

The new property reference syntax allows you to treat properties as variables, which can also be accessed within mixins:

.button
  width: 50px
  height: @width

Comment compilation

When the compress option is true Stylus will not output single-line nor multi-line comments, which are commonly found used for licensing in stylesheet frameworks etc, so it’s useful to strip these out however you can now force output with the ! character /*!.

New built-in functions

The math functions cos() and sin() were added, as well as exposing PI.

Bug fixes

Fixed @import on windows

Connect 1.7.0 - fast static file memory cache and more

Thu, 01 Sep 2011 16:02:00 -0700

Be sure to update Connect to the latest release 1.7.0 for the following goodies!

staticCache() middleware

1.7.0 now provides a new middleware named staticCache(), acting as a memory cache on top of the regular static() middleware. Older versions of Connect used to provide memory caching, however it was baked right into static(), bloating the middleware more than necessary.

Benchmarks

The test file for these benchmarks is a small 4kb readme:

$ du -h Readme.md 
4.0K    Readme.md

and the following ApacheBench command:

$ ab -n 5000 -c 50 -k http://local/Readme.md

First up we have Connect static(), which does not perform any caching, performing disk I/O each request, serving ~2400rps.

connect()
  .use(connect.static(__dirname))
  .listen(3000)

Next up we have node-static one of the other popular node solutions, serving ~3800rps

var static = require('node-static')
  , file = new static.Server(__dirname);

http.createServer(function(req, res){
  file.serve(req, res);
}).listen(3000);

Then we have the new staticCache() middleware paired with static() serving ~5000rps, a 24% increase over node-static (which also performs memory caching), and ~52% over static() alone.

connect()
  .use(connect.staticCache())
  .use(connect.static(__dirname))
  .listen(3000)

staticCache() is configurable, allowing you to specify the maximum number of cache objects to store, and the maximum size allowed, so you can cap resources appropriately. The middleware implements a Least Recently Used algorithm to prioritize popular files, knocking less popular objects out of the cache.

res.headerSent

Node core has a private flag named res._headerSent, allowing you to check if the header has been written or not, this is extremely useful in some cases, so Connect has publicized this property as res.headerSent until Node core does (if ever), using a getter to reference the private property.

logger() immediate option

The logger() middleware now provides { immediate: true }, as by default this middleware will log the response of a request, not when the request is first received, allowing logging of response-times etc.

Game prototyping with JavaScript & CSS3

Sun, 28 Aug 2011 17:13:00 -0700

I wanted to share a quick few-hour game prototype to hopefully inspire a few people! The industry let-alone browser-based games seem very lacking in imagination and storytelling, or maybe I’m just not looking hard enough ;) but I miss games like Grim Fandango.

Below is a screenshot of the demo, consisting of several DOM nodes to represent parts of the main character, the birds, and the scene. Most of the animation is performed with CSS transitions / animations, some of which are dynamic and use the move.js library.

I have yet to profile anything but it runs quite smooth on my machine, and there are many aspects that could be optimized, and some simple ones like ditching jQuery.

iPhone gaming

Back to the original plan, roughly two years ago before the Ipad came out, I was writing an Objective-C iPhone game with Cocos2d and Chipmunk physics, two really wicked libraries. The iPhone seemed too small, and at the time the resolution was not great either, not to mention the image size restraints that Apple enforced, so I gave up after a few prototypes, and one full-screen PC prototype.

Browser gaming

With the advent of modern browsers, browser gaming is already a lot less shitty than a year or two ago, and it’s only about to get much better with all the work browser vendors are putting into making sure canvas and friends run smooth as butter.

The first prototype I wrote was written entirely with Canvas. One of the main benefits of this is a certain level of control that you obtain, it’s extremely easy to implement features like pausing, to apply post-processing, or ad-hoc features that are difficult with the DOM.

At first I was pretty happy with the result, until I wrote the prototype using CSS3 and HTML, the performance impact was pretty significant (though I had not implemented dirty rects etc). Certain aspects of gaming are significantly easier using the DOM, for example leveraging z-index and CSS transitions, however contrasting canvas pausing and post-processing are more of a problem. At least with the currently state of browser technologies, it’s a good idea to mix and match. You can build a large portion of your game using the DOM, and canvas for aspects like particle emitters, or perhaps even WebGL shaders like this awesome demo.

Demo

The video below shows off some of the interactivity, as well as the tiny scene building tool.

The demo consists of ~200 lines of js and ~200 lines of CSS, using CSS for transformations, animations and obviously for styling, while the js performs some basic interactions like the eye-ball targeting, and randomized cat walk routine. The demo also has a small toolkit for creating scenes, but it’s certainly nothing robust.

Source

You can grab the source on Github. Ping me of you come up with some cool prototypes!

Concepts

Some more concepts: