1. モジュールバンドラーとは
2. どんな時に使いたい？
3. 「requireを使える」ということ
4. 様々なモジュールバンドラー
5. browserify を使ってみよう
6. browserify + Grunt で自動コンパイルする
7. まとめ

モジュールバンドラーとは

モジュールバンドラー（module bundler）は、文字通りモジュールをひとまとめにする（bundle）ツールです。 あまり用語として聞き慣れませんが、モジュールバンドラーの代表格のひとつである webpack でも使用されている言葉です。 ひらたく言うと、JavaScriptの依存関係を解決し、それらをインクルードしたひとつのファイルにまとめてくれます。

上の図のように、 require で表現された依存関係を解決してゆき、 コンパイルする際にそれらを全て内包したファイルを作ってくれるのが一般的なモジュールバンドラーの振る舞いです。 require はもともとサーバーサイドJavaScript用に考えられた仕様なので、基本的にブラウザ上では動きません。 それをブラウザ上でも利用可能にするというのが主な目的です。

どんな時に使いたい？

1. JavaScriptファイルを連結したい

旧来JSファイルを連結する際には、まとめたいファイルを指定してシンプルにファイルを繋げていましたが、 この方法には「連結するファイルリストを管理しなければならない」という煩わしさがあります。

一方でモジュールバンドラーの場合はコード内の require を辿って必要なファイルだけを梱包してくれるので、 ファイルリストの管理から解放され、モジュールの取捨選択も一行の追加・削除だけで解決できます。

2. JavaScriptでモジュールのインポートをしたい

他言語で import や require を使っている方は「モジュールのインポートができる」事の素晴らしさも十分にご承知だと思います。 要するに、一行加えるだけで別ファイルに記述された機能がそのファイル内で利用できる様になるのです。

また同時に、コードを見直す際などに依存関係が一目瞭然になるのも大きな利点です。 Webアプリケーションの開発ではJavaScriptファイルが肥大化・複雑化するので、なんとしても欲しい仕組みですね。

3. パッケージマネージャーを npm で一本化したい

bower 等のパッケージマネージャーを利用されている方は一度はその管理に頭を悩ませるでしょう。 bower はそれ自身を npm でインストールして、.bowerrc と bower.json で設定を行って管理するのですが、 「どうせ npm で package.json があるんだからそっちで一本化したい」となるわけですね。

モジュールバンドラーは基本的に node_modules ディレクトリからモジュールを探してインポートするので、 全て npm だけで解決する事ができ、管理が大変楽になります。

4. node.js のモジュールをブラウザ上で使いたい

node.js 向けに作られたモジュールも（一部をのぞいて）インポート可能です。

まとめると

プロジェクトの規模が大きければ大きいほど、より効力を発揮すると言えそうです。

「requireを使える」ということ

node.js に明るくない方の為に簡単に補足をしておくと、 require / exports というのは node.js で使われているモジュールの読み込みの仕組みで、CommonJSなどと呼ばれていたりします。 例えばみんなだいすきjQueryを読み込みたい場合は、まず npm で jquery をインストールします。

$ npm install jquery@1 --save

そしてJavaScript側で require します。

var $ = require("jquery");

これだけで、そのファイル内ではいつも通りに $ でjQueryを参照する事ができます。簡単ですね。

また、「そのファイル内では」という所がポイントで、上の例の記述はグローバルな空間を汚染しません。 つまり、そのファイルのコンテキスト外で jQuery を利用しようとしても、参照出来ないという事です。

ローカルモジュールを組み込む

npm で導入したのではない、自前のモジュールを読み込みたい場合は、そのファイルまでの相対パスで指定します。

var utils = require("./modules/utils");

ここで注意したいのは、相対パスを “./” からはじめている部分です。 これが “modules/utils” だとモジュールの名前だと判断され、 “modules/utils” という名前のモジュールを node_modules から探そうとしてしまいます。

require できるローカルモジュールを作る

モジュールの宣言は exports あるいは module.exports に代入して行います。 まずは exports から使ってみましょう。

// modules/utils.js
exports.foo = function(){ return "foo"; };
exports.bar = function(){ return "bar"; };

このように書く事で、require の返り値がプロパティに foo と bar を備えたオブジェクトになります。 要するに、モジュール内で宣言されている exports オブジェクトを返しているわけですね。

var utils = require("./modules/utils");
utils.foo(); // => "foo"

対して module.exports は、返り値そのものを書き換えたい場合、たとえばオブジェクトではなく関数等にしたい時に有効です。 クラスを返したいケースなどで使えますね。

// modules/foo.js
var Foo = function(){ ... };
module.exports = Foo;

このようにすると、返り値は Foo 関数そのものとなります。

var Foo = require("./modules/foo");
var foo = new Foo();

様々なモジュールバンドラー

browserify

Browserify – http://browserify.org/
Browserify lets you require(‘modules’) in the browser by bundling up all of your dependencies.

• 単機能な方向性で、シンプルで簡単
• Gulpとの相性はイマイチです

webpack

webpack – https://webpack.github.io/
webpack, the flexible module bundler

• JSのバンドルに留まらず多機能ですが、設定が少々ややこしい
• Gruntとの相性はイマイチです
• AMD仕様でのモジュール定義も可能
• browserifyと比較して速度でアドバンテージがある様です

RequireJS という物もありましたが、モジュールの定義がCommonJSではなく本記事に沿わないので割愛します。 browserifyは単機能でシンプル、webpackは多機能という印象です。

browserify を使ってみよう

シンプルな browserify を実際に使ってみましょう。 前提条件として、node.js がインストールされている必要があります。

1. インストール

ターミナル等で browserify をインストールします。環境によっては sudo を頭に付ける必要があります。

$ npm install -g browserify

インストールが完了すれば browserify コマンドが使用可能になります。

$ browserify --help
Usage: browserify [entry files] {OPTIONS}

2. 実行する

適当なJSファイルを用意して、browserify コマンドでコンパイルしてみましょう。

$ browserify test.js -o bundle.js

こちらが基本形です。上のコマンドを実行すると、test.js をコンパイルした結果が bundle.js として保存されます。

browserify + Grunt で自動コンパイルする

browserify コマンドを毎度実行するのは面倒なので、 タスクランナー（Grunt）でファイルの更新を検知して自動的にコンパイルする環境をつくります。 （前述にもありますが、Gulp + browserify は少々手間がかかり説明に不向きなので、ここでは Grunt で説明します）

ファイル構成例

/
├ html/
│ └ assets/
│      └ js/
│           ├ src/
│           │ ├ modules/
│           │ │ ├ mymodule-01.js
│           │ │ └ mymodule-02.js
│           │ └ main.js ... エントリーファイル
│           └ main.js ... コンパイル先のJSファイル
├ node_modules/
└ Gruntfile.js

設定

まず必要なモジュールをインストールします。

$ npm install grunt grunt-browserify grunt-contrib-watch --save-dev

Gruntfile.js を用意します。タスクの設定は下記のような感じにしてみます。

grunt.initConfig({

    browserify: {
        dev: {
            options: {
                borwserifyOptions: {
                    debug: true
                }
            },
            files: [
                {
                    expand: true,
                    cwd: "html/assets/js/src",
                    src: "*.js",
                    dest: "html/assets/js"
                }
            ]
        }
    },

    watch: {
        js: {
            files: ["html/assets/js/src/**/*.js"],
            tasks: ["browserify:dev"]
        }
    }

});

• html/assets/js/src/*.js をエントリーファイルとして、同名ファイルを html/assets/js/ に書き出します
• html/assets/js/src/**/*.js が変更されると、browserify タスクが走ってコンパイルを行います
• browserify に渡すオプションは、browserifyOptions に記述します。 debug を true にするとソースマップを生成する様になります。

準備が整ったら watch してみましょう。

$ grunt watch

無事動きましたか？

まとめ

モジュールバンドラーは昨年（2015年）あたりから流行りだして、 使ってみたところあまりにも効率が良く、今ではもう手放せない存在になりました。 CSSプリプロセッサ、タスクランナーと並んで、近年の素晴らしすぎる発明の一つですね。

SSIについて

SSIそのものについては周知の事と思いますが、 HTMLのコメントノードを使ってサーバ側でコンテンツをインクルードする仕組みです。 例えば、HTML内に次のようなコメントを書いておきます。

<!--#include virtual="/common/header.html"-->

そうすると、サーバ側で自動的に /common/header.html をその部分に読み込んだHTMLを吐き出してくれます。

Apache等のSSIに対応したWebサーバで閲覧すれば良いだけの話ですが、 その為にApacheを用意するのもいささか面倒に感じる事もあるでしょう。

GruntでSSIしてみる

まずは Grunt の grunt-contrib-connect を使ってSSIを再現してみます。 middleware オプションを使ってサーバ側で置換してしまいます。

grunt.initConfig({
    connect: {
        dev: {
            options: {
                base: "html",
                port: 8080,
                keepalive: true,
                /* ↓ これを使います */
                middleware: function(){ ... }
            }
        }
    }
});

まず必要なモジュールを読み込んでおきます。

var fs = require("fs"),
    path = require("path"),
    url = require("url");

middleware の実装は以下のようにしました。

middleware: function(connect, options, middlewares){
    middlewares.unshift(function(req, res, next){
        var pattern, root, file, html;

        pattern = /<!--#include\s+?(virtual|file)="(.+?)".*?-->/g;
        root = options.base[0];
        file = path.join(root, url.parse(req.url).pathname).replace(/\/$/, "/index.html");

        if(/\.s?html$/.test(file) && fs.existsSync(file)){
            html = fs.readFileSync(file, "utf-8").replace(pattern, function(a, key, value){
                var inc = (key === "virtual") ? path.join(root, value)
                : path.join(file.replace(/[^\/]+$/, ""), value);
                return fs.existsSync(inc) ? fs.readFileSync(inc) : "";
            });
            return res.end(html);
        }
        return next();
    });
    return middlewares;
}

1. 拡張子が .html あるいは .shtml の時だけ処理します
2. SSIのパターンを見つけたら、該当ファイルを読み込んで差し替えます
3. 該当ファイルがなければなにもせずに静的ファイルを吐き出します

試してませんが、Gulpでも同じ事が出来るでしょう。

なお、#include のみ処理し、#set や #echo 等の他のコマンドは全スルーしております。 これらも使いたい場合は node-ssi 等を使ってmiddleware内でパースすると良いと思います。 （さすがに exec コマンドはサポートしてなさそうですが…）

SSIが見られるのは主に大きめのWebサイトのテンプレートですが、 経験上 #include 以外が使われているケースはほとんど見られません。

フロントでSSIしてみる

すでにSSIじゃなくなってますが、フロント側（JavaScript）でSSIを再現してみます。 むりやり名前をつけるならばFEI（フロントエンドインクルード）とかになるんでしょうか…。 とはいえ、XHRを使う都合上なんらかのサーバを通して確認する事になります。

先に申し上げておきますと、全くおすすめはできません。 特にJavaScriptも絡んだページ制作では、かなりの悪影響が予想されます。 当然本番で使用するのはもってのほかなので、ただの実験の記録として読み流してください。

パターン1: innerHTMLで強引に

ページ末尾でこのようなコードを実行してみました。

(function(){
    var body = document.getElementsByTagName("body").item(0);
    body.innerHTML.replace(
        /<!--#include.+?(?:file|virtual)="(.+?)".*?-->/g,
        function(key, value){
            var xhr = new XMLHttpRequest();
            xhr.open("GET", value);
            xhr.addEventListener("readystatechange", function(e){
                if(this.readyState === 4 && this.status < 400){
                    body.innerHTML = body.innerHTML.replace(key, this.responseText);
                }
            });
            xhr.send();
        }
    );
}());

innerHTML にはコメントも含まれているので、それらを強引に文字列置換してしまって差し替えています。 やさしさがかけらもない、ひどいコードです。 このコードの最も大きなデメリット（いや、デメリットしかありませんが）は、 要素に結びつけたJavaScriptが全く動かなくなる点でしょう。

document.getElementById("my-button")
.addEventListener("click", function(){
    console.log("click");
});

このような処理が書いてあったとしても、これは全く動きません。 innerHTML を書き換えると同時にDOMを破壊してしまい、上で参照している #my-button という要素とのつながりが断ち切られてしまう為です。

パターン2: DOMインターフェースを使って

ページの末尾で次のようなコードを実行します。

(function(){
    var each = function(list, callback){
        return Array.prototype.forEach.call(list, callback);
    };

    var parseSSI = function(nodes){
        each(nodes, function(node){
            var match, xhr;

            if(node.childNodes.length){ return parseSSI(node.childNodes); }
            if(node.nodeType !== 8){ return; }

            match = node.nodeValue.match(/#include.+?(?:virtual|file)="(.+?)"/);

            if(match){
                xhr = new XMLHttpRequest();
                xhr.open("GET", match[1]);
                xhr.addEventListener("readystatechange", function(){
                    if(this.readyState !== 4 || this.status >= 400){ return; }
                    var tmp = document.createElement("div");
                    tmp.innerHTML = this.responseText;
                    each(tmp.childNodes, function(child){
                        node.parentNode.insertBefore(child, node);
                    });
                });
                xhr.send();
            }
        });
    };

    parseSSI(document.getElementsByTagName("body"));
}());

body配下にぶら下がっている要素をすべて走査して、 コメントノード（nodeType === 8）だった場合にパターンと照合して処理します。

こちらのパターンはDOMを破壊しませんが、不完全なHTMLをモジュールとして読み込んだ場合に、それを補完してしまう欠点があります。 例えば次のような部品を読み込んだ場合。 （古き掲示板CGIのテンプレートを彷彿とさせる構成ですね）

<!-- header.html -->
<header>
    <h1>...</h1>
    <nav>...</nav>
</header>
<article>
<!-- /header.html -->

ここにコンテンツがはいります。

<!-- footer.html -->
</article>
<footer>...</footer>
<!-- /footer.html -->

不完全な要素が補完されてしまう為、想定と異なる構成になってしまい、当然見た目も崩れてしまうでしょう。

このような使い方をしなければ、SSIを模した形のモジュールライブラリとして使い様があるか…？とも考えましたが、 DOMを全走査しなければならない為、コスト的にあまり良策とは言い難いですね。 改善策はなくもなさそうですが、「そこまでやる必要がどこにあるのか」と考えてしまったのでそこで放棄いたしました。

まとめ

SSIの環境が必要になるケースは今後もまだなくなりはしないと思います。 そういった案件に限って1ページのみの制作という事もよくある話なので、 出来るだけ手元の環境でさくっと再現してしまいたいですね。

WebSocket

WebSocket は、サーバーとクライアント間の双方向の通信をスムーズに行う為の技術です。 XMLHttpRequest のように都度リクエストを送るのではなく、 一旦コネクションが貼られた後はそのコネクション上でメッセージを送り合ってデータのやり取りを行う為、 よりリアルタイム性が必要なアプリケーション、例えばチャットやオンラインゲーム等での活躍が期待されます。

Socket.io

WebSocket を恐ろしく簡単で使いやすい物に変えてしまうのが Socket.io です。

http://socket.io/
Socket.IO aims to make realtime apps possible in every browser and mobile device, blurring the differences between the different transport mechanisms. It’s care-free realtime 100% in JavaScript.

node.js で楽にWebSocketのサーバが立ち上がるうえ、クライアントサイドでは WebSocket に非対応な環境の為に、 Flash で ActionScript3 の WebSocket API を使用してフォールバックを備えてくれています。

WebSocket サーバの起動

まず socket.io をインストールしましょう。

$ npm install socket.io

そして起動用のスクリプトを書きます。

// server.js
var io = require('socket.io').listen(8080);
io.sockets.on("connection", function(socket){
    socket.emit("hello", {message: "Thanks to connect !"});
});

これは接続したクライアントに “hello” メッセージを送るだけのコードです。

listen メソッドでポートを指定してサーバを起動します。 io.sockets.on メソッドでは、新たにリクエストのあったコネクションを受け取り、 そのコールバックの中で emit コマンドでクライアント側にメッセージを送ります。

node コマンドで WebSocket サーバを起動します。

$ node server.js

これでサーバが立ち上がったと思います。 デーモン化したい時には forever が便利です。

クライアント側の処理

WebSocketとは別に、Webサーバが立ち上がっていると仮定しましょう。 クライアント側では socket.io-client を使って WebSocket に接続します。 socket.io-client は bower でも npm でもインストールできます。

$ bower install socket.io-client

ここではサーバから送った “hello” メッセージを受け取ってみます。

<script src="bower_components/socket.io-client/dist/socket.io.js"></script>
<script>
    var socket = io.connect("http://example.com:8080");
    socket.on("hello", function(data){
        console.log(data.message); // "Thanks to connect !"
    });
</script>

サーバから emit で送ったメッセージは、クライアント側で on で受け取る事ができます。 逆に、サーバ側にメッセージを送る時はクライアント側で emit し、サーバ側で on で受け取ります。

全てのソケットにメッセージを送る

上のサーバスクリプトでは、引数で渡された socket オブジェクトで emit を行っていましたが、 この socket はそのクライアントのみのコネクションです。 接続している全てのユーザにメッセージを送りたい場合は、socket にぶら下がっている broadcast を使用します。

socket.emit("message", ... ); // 自分にメッセージを送る
socket.broadcast.emit("message", ...); // 自分以外にメッセージを送る

broadcast は自分以外のコネクションを指します。

極めてシンプルなチャットの習作

Socket.io を使って極めてシンプルなチャットプログラムを作ってみます。 上で挙げた機能のみを使用して、その場限りのチャットをする事が出来ます。 ルームや認証などは一切省いています。

まずHTMLは、ニックネームとメッセージを入力するインプットと、メッセージログを出力する #log で構成されます。

<!-- HTML -->
<form id="form-message">
    <label>ニックネーム: <input type="text" id="nickname"></label>
    <label>メッセージ: <input type="text" id="message"></label>
    <input type="submit">
</form>
<hr>
<ul id="log"></ul>

次にクライアント側の JavaScript ですが、例をシンプルにする為に jQuery を使用します。

/* クライアント JavaScript */
var socket = io.connect("http://example.com:8080");

socket.on("connect", function(){
    $("#nickname").on("change", function(e){
        socket.emit("set nickname", {
            nickname: this.value
        });
    });
    $("#form-message").on("submit", function(e){
        e.preventDefault();
        var input = $("#message");
        socket.emit("send message", {
            message: input.val()
        });
        input.val("");
    });
});

socket.on("message", function(data){
    $("<li>").append($("<strong>").text(data.nickname))
    .append($("<span>").text(data.message))
    .prependTo("#log");
});

クライアントサイドの JavaScript はこのような働きをします。

• #nickname の内容が変更されると “set nickname” メッセージを送ってニックネームを変更する
• #form-message がサブミットされると、#message から “send message” でメッセージを送信する
• サーバから “message” が届いたら、 #log の中に追加して表示する

最後にサーバ側では、上記の処理をサポートするように記述します。

/* サーバ JavaScript */
var io = require('socket.io').listen(8080);

io.sockets.on("connection", function(socket){
    var anonymous = "名無しさん";
    var nickname = null;
    socket.on("set nickname", function(data){
        nickname = data.nickname;
    });
    socket.on("send message", function(data){
        if(! data.message){ return; }
        var vars = {
            nickname: nickname || anonymous,
            message: data.message
        };
        socket.emit("message", vars);
        socket.broadcast.emit("message", vars);
    });
});

socket オブジェクトには set/get が実装されており、その接続毎のデータを保持する事ができますが、 コールバックを受け取るタイプで少し例が冗長になってしまう為、ここでは単なる変数として nickname を定義しています。

WebSocket の働きが、なんとなく伝わったでしょうか。

その他のヒント

限定されたユーザにメッセージを送りたい

例えばチャットルームのような物が存在していて、その中だけでメッセージをやりとりしたい時の為に、 Socket.io には 「ルーム機能」 なる物があります。 ルームは入室・退室する事ができ、そのルームの中にいるメンバーだけに通知をする事ができます。

/*  サーバ JavaScript */
socket.join("ChatRoom"); // 入室します
socket.leave("ChatRoom"); // 退室します
io.sockets.in("ChatRoom").emit( ... ); // ルーム内のメンバーにだけ emit

ルーム内にメッセージを送るには、io.sockets を in() メソッドで絞り込んで emit します。

また、コネクションからクライアントを切り分ける ネームスペース機能 という物もあります。 “/chat” のようにネームスペースを定義してそこに接続したクライアントだけでデータのやり取りをします。 サーバ側では of() でクライアントを絞り込んで処理をかき分けます。

/*  サーバ JavaScript */
var chat = io.sockets.of("/chat");
chat.on("connection", function(socket){
    socket.on("send message", function(data){
        chat.emit( ... );
    });
});

クライアント側では、コネクション時に “/chat” を足して接続します。

/* クライアント JavaScript */
var socket = io.connect("http://example.com:8080/chat");

また、ネームスペースとルーム両方で絞り込む事もできます。

セッションを管理したい

socket.io のセッションは基本的にその接続限りです。 ページをリロードしたり、新しいタブで開いたりした時点で新しいコネクションが貼り直され、id も更新されてしまいます。 その為、認証などでセッションの保持をしたい場合は少し工夫が必要です。

socket.io の wiki にいくつかその為のレシピやモジュールが公開されていますが、 基本的に express や connect など、node.js ベースの解決策になっているので、 socket.io を採用する場合はWebサーバも express を選択した方が良さそうですね。 （特に他の物を使う理由もなさそうですが）

session.socket.io (SessionSockets)
This tiny node module simplifies your web sockets app when using http sessions from express or connect middlewares. It has no dependencies and can be initialized using any session store and cookie parser compatible with express or connect.

こちらは socket.io でセッションを管理する為の node モジュールです。

参考資料

• WebSocket – Wikipedia
• Socket.IO: the cross-browser WebSocket for realtime apps.
• Home · LearnBoost/socket.io Wiki
• Socket.IO API 解説 – Block Rockin’ Codes
• session.socket.io (SessionSockets)

node-webkit

node-webkit は、HTML + CSS + JavaScript でネイティブアプリケーションを作る事が出来る、 Chromiumをバンドルした node.js ベースのランタイムです。 Mac / Windows / Linux 用にそれぞれビルドする事が可能で、1セットのコードからクロスプラットフォームを実現出来ます。

Titanium Desktop や Adobe AIR 等と似たような存在ですが、 組み込んだ JavaScript からそのまま node.js のモジュールを利用出来るという大きなメリットがあります。 勿論 Titanium や AIR と同じように node-webkit 独自のAPIも提供されています。

アプリケーションを作ってみる (Mac編)

実際にシンプルなMac向けのアプリケーションを作ってみる事にします。

下準備

まず node-webkit をダウンロードしてインストールしておきましょう。 （ビルドする場合には同梱する事になるのですが、開発中はアプリケーションから開いた方が効率が良いと思います。）

Download / rogerwang/node-webkit

上記URLの Download から、各環境向けにビルドしたバイナリが取得できます。 Mac 用のバイナリをダウンロードし、普段アプリケーションをインストールするのと同じように、 node-webkit.app をアプリケーションフォルダにコピーします。

ファイル構成

アプリケーションを立ち上げるのに最低限必要な物は次の要素です。

app.nw/
├ package.json
└ application/
     └ index.html

• app.nw : アプリケーションのルートディレクトリ
• package.json : マニフェストファイルとなります
• application : アプリケーションのリソースを格納するディレクトリ
• index.html : アプリケーション本体です

package.json

package.json はアプリケーションの基本的な情報を書き込んでいきます。 このファイルが無かったり記法が間違っていたりするとアプリケーションは立ち上がりません。 中身は JSON で記述し、アプリケーションの名前やメインファイルのパス、ウィンドウの見た目などを指定する事ができます。

{
    "name": "nw-hello",
    "version": "0.0.0",
    "main": "application/index.html",
    "window": {
        "width": 800,
        "height": 600,
        "toolbar": false
    }
}

“main” で指定したファイルがアプリケーションの本体となります。

設定項目はこの他に沢山用意されています。 項目の詳細については公式のwikiに詳しく記載されていますのでそちらをご覧ください。
Manifest format · rogerwang/node-webkit Wiki

index.html

メインファイルとなるHTMLでは、普段通りのHTML/CSS/JavaScriptを記述していけば良いです。 勿論 js や css ファイル等を外部リソースにしても構いません。

ここでは試しに node.js の機能を少し使ってみます。

<p>
    Hello, <span id="user-name"></span>
</p>
<script>
    var cp = require("child_process");
    var userName = document.getElementById("user-name");
    cp.exec("whoami", function(e, out, error){
        userName.innerHTML = out;
    });
</script>

アプリケーションを立ち上げると “Hello, [ユーザー名]” と表示されます。 ユーザー名を取得する為の whoami コマンドの実行に node.js の child_process を使用しています。

アプリケーションを立ち上げる

はじめにインストールした node-webkit.app を使ってアプリケーションを立ち上げます。 ターミナルで open コマンドを使い、引数にアプリケーションのディレクトリを指定します。

$ open -a node-webkit /the/path/to/app.nw

または、node-webkit をインストールしておくと *.nw に関連付けがされる様なので、 finder から app.nw を叩くか、直接 open コマンドでも開きます。

$ open /the/path/to/app.nw

無事立ち上がりましたか？

Windowsの場合はどうなるか

Windowsの環境でも基本的な開発の仕方はかわりません。 アプリケーションの起動は、ダウンロードしたバイナリ（nw.exe）にアプリケーションディレクトリをドラッグドロップして行います。

（パスを通して引数にディレクトリを渡して起動する事も出来ますが、それをする人は稀でしょう）

パッケージングする （Mac編）

このままではこのアプリケーションは自分の環境でしか動かないので、 他のコンピューターでも使用出来るようにします。 といっても、Macの場合は恐ろしく簡単で、 node-webkit.app を複製してファイルを差し替えるだけで出来てしまいます。

node-webkit.app は finder で見るとファイルのように見えますが、 実際は次のような構造のディレクトリになっています。

node-webkit.app/
└ Contents/
     ├ Frameworks/
     ├ Info.plist
     ├ MacOS/
     ├ PkgInfo
     └ Resources/

この Resources の中にアプリケーションのディレクトリを入れ、 node-webkit.app を hello.app のようにリネームしてあげれば完成です。

hello.app/
└ Contents/
     ├ <省略>
     └ Resources/
          └ app.nw/
               ├ package.json
               └ application/

こんな感じになりますね。

パッケージングする （Windows編）

Windows向けのアプリケーションは、Macのようにディレクトリのままリリースする方法と、 アプリケーションディレクトリを exe ファイルに結合する方法があります。

まずはWindows用のバイナリをダウンロードして zip を展開しておきましょう。これは共通して使用します。
https://github.com/rogerwang/node-webkit#downloads

ディレクトリのままパッケージングする

Macのようにディレクトリのままコピーしてしまう方法も取ることが出来ます。 但し、package.json は nw.exe と同じディレクトリになければなりませんので、 アプリケーションディレクトリの中身をそのままコピーするイメージです。 （その為、アプリケーションのリソースはまとめて application/ 等に格納しておくと管理が楽です）

node-webkit-vX.X.X-win-ja32
├ credits.html
├ *.dll
├ nw.exe
├ nw.pak
├ nwsnapshot.exe
├ package.json
└ application/
     └ index.html

nw.exe はアプリケーションの名前にあわせてリネームしておくと良いでしょう。 ディレクトリ内の dll ファイルや pak ファイルは動作時に必要なので、まとめて同梱して配布しましょう。

結合してパッケージングする

まず、node-webkitのディレクトリの中に、アプリケーションディレクトリを zip 圧縮した物を格納します。

node-webkit-vX.X.X-win-ja32
├ nw.exe
├ <省略>
└ app.zip（zipファイル）

zip 圧縮する際に注意しなければならないのは、zip のルートに package.json がなければならない点です。 多くの圧縮ツールは圧縮時に同名フォルダを中に作ってその中に展開してしまいますが、その構成ではアプリケーションは正常に立ち上がりません。 Git CUI 等にある zip コマンドを使用した方が手っ取り早いかもしれませんね。

結合は、コマンドライン（コマンドプロンプト）で行います。

> copy /b nw.exe+app.zip hello-world.exe

Mac等の環境でシェルコマンドで行う事もできます。

$ cat nw.exe app.zip > hello-world.exe

これで完成です。古い nw.exe と app.zip は削除しておきましょう。

参考資料

• rogerwang/node-webkit
• Home · rogerwang/node-webkit Wiki

つくってみたもの

Imaguria

画像を Data URI に変換する node-webkit 製の単機能アプリケーション。 画像をアプリケーション画面にドロップするか、 コピーした画像をアプリケーション画面にペーストすると、 Data URI が表示されます。

Windows版とMac版をご用意しました。 あまり使い道が思いつきませんが、せっかく作ったのでもしよろしければ。

この内容ならWebアプリケーションで十分用を足せるので あまり良い題材とは言えないかもしれませんが、 なにせ手頃な題材が思いつかなかったので。

おかげでおおまかな開発の流れがわかりました。

作ってみた感想

node-webkit は chronium を内包しているので、Webの技術でデスクトップアプリケーションが作れます。 Adobe AIR や Titanium Desktop 等に似た存在ですね。

強みの一つは、独自のAPIの他に node.js をフロントのJavaScriptから利用できる点で、 require(…) 等してモジュールを利用する事ができます。

node.js がそうであるように、Win / Mac / Linux のいずれでも動くマルチプラットフォームのアプリケーションが開発出来ます。 どの環境でも chronium がベースになるので、 Web開発者が常に悩まされ続けてきたクロスブラウザなどという物に縛られずに新しい技術を使い放題です。 これは結構書いていて爽快ですね。

node.js でローカルのファイルシステムを扱える他、Webストレージや Web SQLなどもサポートしている様です。

ちなみに、開発はMacがダントツでやり易かったです。

参考URL

• rogerwang/node-webkit
• Home · rogerwang/node-webkit Wiki

まとめ

node-webkit でのアプリの作り方はまた別の機会にします。

Webの技術でデスクトップアプリケーションを作るための選択肢が一つ増えました。喜ばしいことです。 これとは別に、Windows8のストアアプリもJavaScriptで開発出来る様ですよ。

1. Gruntってなに
2. Gruntを導入する
3. 使ってみよう
4. どんなタスクがあるの？
5. その他Gruntの魅力
6. まとめ

Grunt ってなに

• GRUNT: The JavaScript Task Runner

Gruntはnode.jsベースで作られたタスクベースのコマンドラインビルドツールです。

ビルドツールってなに

ビルドは、ソースファイル群を元にして、実行出来る成果物を生成するプロセスの事を指します。

cf) ビルド (ソフトウェア) – Wikipedia

鍋に鶏と野菜とコンソメを入れて煮込んだらポトフが出来るとして、 鍋の役割を担ってくれるのがビルドツールです。（そんな認識であっているかな？） レシピを設定しておくことが出来るので、いつでもすぐに美味しいポトフがお楽しみ頂けます。

具体的には、Web制作では主にJavaScriptファイルを結合・圧縮したり、 Less/Sass/Stylus等のCSSプリコンパイラの結果を生成したり、 画像の最適化などを行い、最終的に動作するWebページにしていきます。

Gruntを導入する

インストール

まずはGruntを導入してみます。node.jsベースなのでまず node.jsをインストールし、

$ npm install -g grunt-cli

等とします。環境によってはsudo等が必要です。

grunt-cli はローカルにインストールされたgruntを呼び出すだけの係の人なので、 別途gruntも入れておく必要があります。プロジェクトルートか、あるいはその親ディレクトリにインストールしておきましょう。

$ npm install grunt

使ってみよう

Gruntfile.js

プロジェクトディレクトリに Gruntfile.js ファイルを用意して設定を記述し、 そのディレクトリで grunt コマンドを実行するとビルドが始まります。

Gruntfile.js の中身は、例えば次のようになります。

module.exports = function(grunt){

    // `loadnpmTasks`で使用したいタスクを読み込んでおく
    grunt.loadNpmTasks("grunt-contrib-uglify");

    // `initConfig` で基本設定
    grunt.initConfig({
        uglify : {
            dist : {
                src : ["assets/js/script.js"],
                dest : "assets/js/script.min.js"
            }
        }
    });

    // `registerTask` でタスクに名前をつける
    // "default" でデフォルトのタスクを設定
    grunt.registerTask("default", ["uglify"]);

};

タスクについて

Gruntに命令する処理を「タスク」と呼びます。

上の例では”uglify”というタスクに、”dist”という作業を任せています。 “uglify”はuglify.js を使用してJavaScriptの圧縮を行なってくれるタスクで、 “src” にあるファイルリストをひとまとめにして圧縮した結果を “dest” のファイルに保存します。

タスクははじめから入ってるわけではないので、 使いたい物を都度インストールしましょう。

$ npm install grunt-contrib-uglify

ビルドの実行

上の例ではデフォルトのタスクにuglifyが設定されているので、引数なしで

$ grunt

とすればタスクが実行され、assets/js/script.js を圧縮した結果が assets/js/script.min.js として保存されます。

タスクを指定して実行したい場合は、引数にタスクの名前を渡します。

$ grunt uglify # <= uglifyタスクを実行
$ grunt uglify:dist # <= minタスクのdistという名前の作業を実行

どんなタスクがあるの？

以下が代表的だと思しきプラグインです。 （”contrib” とついている物は公式のものです。） 使いたい物を npm install でインストールし、 loadNpmTasks で読み込んで使用しましょう。

• grunt-contrib-concat – ファイルを結合します
• grunt-contrib-uglify – JavaScriptファイルを圧縮します
• grunt-contrib-cssmin – CSSファイルを圧縮します
• grunt-contrib-watch – ファイルの更新を監視して任意のタスクを実行します
• grunt-contrib-copy – ファイルやディレクトリをコピーします
• grunt-contrib-clean – ファイルやディレクトリを削除します

具体的な設定例等は、各リポジトリのREADMEをご覧ください。 また、その他にも多くのタスクがあるので使えそうな物があったらピックアップしてみるといいでしょう。

• Plugins – Grunt: The JavaScript Task Runner

その他Gruntの魅力

なんといっても、JavaScriptベースである為にプラグイン開発が非常に身近にある点だと思います。

cf) Creating tasks – Grunt: The JavaScript Task Runner

JavaScriptに心得のある人ならば、自分が使いやすいようなタスク・プラグインを自前で開発して、 自分好みの開発環境を構築していく事が出来ます。 また、その為に便利なインターフェイスも十分整備されています。 有用なプラグインが書けたら、npmにパブリッシュしておけばいつでも使えますね。

まさにnode様様といったところです。

まとめ

Grunt の概要をざっくり紹介しました。

これだけではそこまで有用と思われないかもしれませんが、 多くのコーダーさんにとって威力を発揮するのは、やはりCSSプリコンパイラのビルドだと思います。 後編ではそのあたりを紹介してみます。

Bower とは

BOWER – THE BROWSER PACKAGE MANAGER html, css, and javascript

Bower is a package manager for the web. Bower lets you easily install assets such as images, CSS and JavaScript, and manages dependencies for you.

---

BowerはWeb開発向けのパッケージマネージャーです。画像・CSS・JavaScriptといったリソースを簡単にインストールする事ができ、依存関係を管理してくれます。

新しいプロジェクトをスタートする度に毎回jQuery等のリソースを複製して設置するのは面倒です。 そこでBowerを利用する事で、コマンドラインから簡単に最新のパッケージを、依存リソースと一緒にインストールする事ができます。

また、プロジェクトの設定ファイル（bower.json）を作成して依存リソースを記しておけば、 コマンド一発で全てダウンロード、あるいはアップデートする事ができます。 プロジェクトに必要なライブラリがチームメンバーにとって一目瞭然になるのもメリットですね。

見ての通り、Twitter開発陣プレゼンツのリソースです。 リリース当初小耳には挟んでいたのですが、実用するまでには至らず。実際使ってみたら大変便利でした。

インストール

まずは Bower をインストールします。必要に応じて、sudoなどしましょう。 （node.jsを先にインストールしておく必要があります）

$ npm install -g bower

Windowsユーザーの場合は、Gitがコマンドプロンプトから呼べないと上手く動作しないそうです。 公式にあるように、msysgitインストール時に “Run Git from the Windows Command Prompt”のチェックを入れるか、 あるいは Git CUIの環境でnode.jsへのパスを通しておけば使えます。

cf) 公式ドキュメント参照 (“Windows users”の項)

簡単な使い方

パッケージをインストールする

まずはコマンドラインからパッケージ単体をインストールしてみます。”install” コマンドでパッケージ名を指定します。

$ bower install jquery

すると、カレントディレクトリに「bower_components」ディレクトリが作成され、その中にパッケージがインストールされます。 こんなかんじに。

ProjectRoot/
└ bower_components/
    └ jquery/
         ├ jquery.js
         ├ jquery.min.js
         ├ component.json
         └ composer.json

デフォルトの名前が”components”から変更になっています – 2013/09/05

パッケージ名を連記する事で複数のパッケージを一度にインストールする事もできます。

$ bower install jquery modernizr mustache

バージョンを決め打ちしてインストールするにはシャープ記号で区切って指定することができます。

$ bower install jquery#1.8.2
$ bower install jquery#1.8.x
$ bower install jquery#1.8
...

パッケージをアップデートする

インストールしたパッケージは “update” コマンドでアップデートできます。

$ bower update

欲しいパッケージを探す

欲しいパッケージがBowerに登録されているかどうかは “search” コマンドで探すことができます。

$ bower search mustache

    - mustache git://github.com/janl/mustache.js
    - grunt-mustache git://github.com/jonschlinkert/grunt-mustache.git

欲しいパッケージが見つからないんだけど？

Bowerに登録されていないパッケージをインストールするにはいくつかの方法があります。 例えば、headjsをインストールしたい場合。

$ bower install https://github.com/headjs/headjs
$ bower install headjs/headjs
$ bower install https://raw.github.com/headjs/headjs/master/dist/head.js
$ bower install ../../the/path/to/head.js

それぞれ次の物を指定してインストールしています。2番目が楽でいいですね。

1. GitHubのリポジトリURL
2. GitHubのショートハンド
3. リソースの直接URL
4. リソースのローカルパス

“register” コマンドでパッケージを新規登録する事も出来ますが、特定の条件が必要になる為、ここでは詳しく触れないでおきます。

プロジェクトを作成する

プロジェクトの設定ファイル “bower.json” を作っておく事で、 必要なパッケージを一括してインストール・アップデートする事ができます。

プロジェクトのルートディレクトリに”bower.json”を作成し、次のような要領で入力します。

設定ファイル名が”component.json”から変更になっています – 2013/09/05

{
    "name" : "My Awersome Project",
    "version" : "1.0.0",
    "dependencies" : {
        "jquery" : "1.8",
        "modernizr" : null,
        "mustache" : null
    }
}

基本的に “dependencies” に必要なリソースを追加していく形になります。 見ての通り、キーにパッケージ名、値にバージョンを記載するオブジェクトリテラルになっており、 バージョンが “null” になっている場合は最新版をインストールします。

後は、引数なしで “install” コマンドを実行するだけで、依存リソースが一括してダウンロードされます。便利。

$ bower install

また、「見つからないパッケージ」をインストールするためには、バージョンの代わりに前述の例のようなURLあるいはパス等を入力します。

"dependencies" : {
    ...
    "headjs" : "headjs/headjs"
}

インストール先ディレクトリをカスタマイズする

Bowerは “.bowerrc” というファイルでカスタマイズする事ができます。

例えば、パッケージのインストール先を “bower_components” ディレクトリから他の場所に移したい場合、 プロジェクトルートに “.bowerrc” ファイルを作成して次のように入力しておきます。

{
        "directory" : "assets/vendors"
}

また、 “.bowerrc” を自分のホームディレクトリに置いておく事で、自分が作る全てのプロジェクトにカスタマイズを適用する事ができますが、 そのプロジェクトを誰かと共有する際に問題が生じそうなので、基本的にはプロジェクトに同梱しておいた方が良いと思います。

Nettuts+ のチュートリアル動画

A RequireJS, Backbone, and Bower Starter Template

Nettuts+ によるチュートリアル動画です。 Bowerの基本的な使い方に加えて、RequireJSとBackboneによるスタートアップについて解説しています。 参考に、是非。

まとめ

node.js が出てから、JSベースの便利ツールが沢山出て来ましたね。 有り難りつつも、しっかり楽をさせてもらいましょう。

2013/09/05

bowerバージョンアップによる設定ファイルとディレクトリ名の変更について記載

スタイルガイドについて

ざっくり言うとスタイルシートのドキュメントです。

自分一人で完結するその場限りのページなら良いのですが、 複数人のチームで組み込んでいたり、メンテナンス担当が他の方だったりする場合、 プロジェクトのCSSをドキュメント化しておく必要が出てきますね。例えば、

• どのような命名規則や方針で書かれていて
• どこになにがあり
• どのようなモジュールがどこで使えて
• そのモジュールはどうするとどのような挙動を起こすのか

等をまとめておく文書になると思います。 規模によってはかなり骨な作業になりそうです。

StyleDoccoとは

• StyleDocco

StyleDocco generates documentation and style guide documents from your stylesheets.

スタイルシートを読み込んで、自動的にドキュメンテーションを生成してくれるツールです。

その為の記法に従う必要がありますが、 基本的にはCSSの記述の前に、コメント（ /* */ )で、概要文とプレビュー用のHTMLを書くだけです。 もちろんそのままCSSとしても機能します。

インストール

早速インストールをしてみます。 node.jsで動作するので、先に導入しておきましょう。

node.jsが入ったら、npmコマンドを叩くだけです。
※環境によってはsudoや管理者権限が必要だったりします。

$ npm install -g styledocco

使い方

CSSの書き方

前述の通り、ドキュメントの生成にはその為の記法に従う必要があります。

/*
# ボタン

基本的なボタンスタイル。

    <button class="button">ボタン</button>

*/

.button {
    border-radius:4px;
    border:1px solid #ccc;
    background-color:#f9f9f9;
}

• 概要文はMarkdown記法に対応しています。
• プレビュー用のHTMLにはインデントが必要です。
  
  （タブでもいけましたが、一応公式によれば4スペースとの事です。）

生成コマンド

インストールすると styledocco コマンドが使用出来るようになります。 以下は、「css」ディレクトリの中のファイルを元にドキュメントを生成する例。 出力先はデフォルトで「docs」ディレクトリになります。

$ styledocco -n "My Project" css

使いそうな引数オプションはここらへんでしょうか。

• –name -n プロジェクト名（ドキュメントタイトルになります）
• –out -o 出力ディレクトリ（デフォルトはdocs）
• –preprocessor 使用するプリプロセッサ（Sassとかlessのコマンドを渡します）

例えば以下は「My Project」というタイトルで、「styles」フォルダのソースを元に「mydocs」へ出力をし、 プリプロセッサには「lessc」コマンドを使用する事になります。

styledocco -n "My Project" -o mydocs --preprocessor "lessc" styles

cf) StyleDocco – Usage

gruntで自動化など

gruntでwatchして自動化したい場合は、grunt-styleguide等を利用します。 （諸事情により私は使いませんでした）

• indieisaconcept/grunt-styleguide · GitHub

あるいは grunt-shell でシェルコマンドを書いたり、 自分でタスクを書くなどして、うまいこと楽をすると良いでしょう。

その他、細かい使用感など

ページのはじめに謎の空白のボックスが？

ちょっとハマった箇所ですが、ページの一番はじめのセクションで謎の空白ボックスが生まれてしまいました。

概要文のコメントの先頭に改行を挟んでしまうとこうなります。

/*

# これはダメ



/*
# こうしましょう

プレビューHTML前の改行

概要文とHTMLの間は基本的に1行空いていればいいのですが、 概要文がMarkdownのリスト等になっている様な場合は2行以上あけないとプレビューが正常に表示されません。

/*
# ボタン

* リスト
* リスト


    <!--こういったケースは2行あけましょう。-->

プリコンパイラも併せて使うと重たい？

私の携わったプロジェクトではSass+bootstrapで実装をしていた為、 Sassの重さとbootstrapのボリュームが相まってcss自体のジェネレートに少々時間を要しました。 それに加えて、StyleDoccoのドキュメント生成もある程度時間がかかるため、合わせ技で相当遅くなります。 gruntで自動化をしなかったのはその為です。

ただ、ファイル数やボリュームにも因る所が大きいので一概には言えません。 また、逆に最適化をする機会にも繋がるとも言えますね。

ナビゲーションの生成について

ドキュメントのヘッダナビゲーションには、 スタイルシートのファイル毎にメニューが生成されます。 また、フォルダでファイルを分けている場合は、プルダウンメニューになります。

例えばこのような構造にしてあった場合

css/
  ├ common/
  │   ├ foo.css
  │   ├ bar.css
  │   └ baz.css
  ├ components/
  ├ widgets/
  └ README.md

このような感じに出力されます。

ただし、Macでは問題なかったのですが、当方のWindows環境ではサブフォルダを全て無視されてしまいました。 Issueに投げてみたので、何か反応があったらお伝えします。

ドキュメントページのパフォーマンス

生成されたドキュメントページで動作がもたつくな、と感じたので中身をみてみました。

StyleDoccoのドキュメントページは、ページ毎にひとつのHTMLになっています。 CSSやJavaScriptなどの外部リソースはありません。完全にひとつのファイルです。

プレビューの出力はどうやっているのかというと

1. iframeを動的に生成して、そこに自分自身を読み込む
2. 読まれたHTMLでプレビューを生成し、描画する

という処理をHTMLファイルに記述されたJavaScriptで行なっているようです。

JSで動的に生成している関係上、物とボリュームによっては描画や目次の生成などの動作がもたつく場合があります。 が、「単一ファイルでいきたい！！」というポリシーがひしひしと伝わってくるので、これはこういう物だと思って割り切りました。

まとめ

自前のテンプレートでスタイルガイドを書く手もありますが、 うまく用途にマッチするのであれば、こういうツールを使って楽をしていきたいですね。

testem ってなに

testem

• testem via GitHub : airportyh/testem

Unit testing in Javascript can be tedious and painful, but Testem makes it so easy that you will actually want to write tests.

要するに、面倒なJSのユニットテストをより快適にしてみんなでハッピーにテスト書こうよ！というツールです。 testem自体はnode.jsベースで動作し、Jasmine/QUnit/Mochaに対応しています。（デフォルトはJasmine）

test’em は“Test them”の省略形でしょう。 どんなテストもまとめて引き受けますよ！という事だと思います。

具体的になにしてくれるの

例えばJasmineで「基礎的で面倒なテストの開始の仕方」をした場合、

1. Jasmineのコードをとってきて設置し、
2. SpecRunner.html を編集し、
3. ブラウザでそのHTMLを開き、
4. テストを書いてブラウザをリフレッシュする

と、こんな感じの作業をプロジェクトの度に繰り返す事になります。

これが、testemでは

1. 設定ファイルを書く
2. testem コマンドを叩く

だけでテストが始まります。

インストール

もしnode.jsが既にインストールされている環境ならば、npmコマンドだけで簡単に導入できます。 （node.jsがまだ入っていないのであれば、まずそちらを先にインストールしましょう）

$ npm install -g testem

正常にインストールできませんでしたか？ 環境によってはsudoが必要になるかもしれません。

$ sudo npm install -g testem

これでtestemコマンドが使えるようになったはずです。 ヘルプでも覗いてみましょう。

$ testem -h

テストをしてみよう

早速テストをしてみようと思います。仮に、次のようなディレクトリ構造にしてみましょう。 scripts/.js がテスト対象のライブラリ、tests/.js がテストです。 testem.json が設定ファイルになります。

./
├ scripts/
│   └ foobar.js
├ tests/
│   └ test-foobar.js
└ testem.json （設定ファイル）

設定ファイルを書く

設定ファイルはJSONで記述します。必要最低限の設定は、こんな感じになります。

{
    "framework" : "jasmine",
    "src_files" : [
        "scripts/foobar.js",
        "tests/test-foobar.js"
    ]
}

• 
  

  framework
  
  使いたいテストフレームワークを書きます。デフォルトはJasmineなので、Jasmineを使う場合は省略できます。

  
  
• 
  

  src_files
  
  読み込むソースファイルを配列で記述しておきます。

  
  

テストを開始する

testemコマンドを叩けばテストは開始されます。

$ testem

実行すると次のような画面が表示されます。

表示されたURL（http://localhost:7357）を、テストしたいブラウザで開きます。すると…

ブラウザにはJasmineのテスト結果が。

ターミナルにもテスト結果が表示されます。

ファイル更新を検知してくれる

ソースファイルあるいはtestem.jsonを編集すると、更新を検知してブラウザとターミナルを自動的にリフレッシュしてくれます。 わざわざブラウザをアクティブにして更新する必要はありません。後はひたすらテストを書いていくのみです。

実行時に自動的にブラウザを開く

わざわざURLをコピーしてブラウザのアドレスバーに貼り付けるのが面倒！ そんな人の為に、“launch_in_dev”という設定項目があります。 設定ファイルにこれを追記する事で、testemコマンド実行時に自動的に、指定したブラウザでURLを開いてくれます。

{
    "launch_in_dev" : [
        "Chrome"
    ],
    ...
}

使えるブラウザのリストは、次のコマンドで知ることができます。

$ testem launchers

Windows環境ならIE7,IE8,IE9等も表示されますね。 公式のREADMEによれば、IE9のモード切り替えでのテストだそうです。

ただし、この設定はテスト開始時に新しいウィンドウを開いてしまいます。 その開き方が好きでない方は、大人しくブックマークに登録しておきましょう。 （私はそうしました）

Nettuts+ のチュートリアル

基本的な部分は上で紹介していますが、CofeeScriptのコンパイルを挟んだりなど、 もう少し突っ込んだ使い方はNettuts+のチュートリアル動画でわかりやすく解説されていました。 英語ですが、作業画面見ているだけでも参考になると思います。

Make JavaScript Testing Fun With Testem – YouTube

cf) Make JavaScript Testing Fun With Testem | Nettuts+

まとめ

面倒な部分を全部任せられるので、快適にテストをはじめられますね。 テストフレームワークだけでも有難いのに、至れり尽くせりで幸せです。

nave.shの導入

isaacs/nave – GitHub

私はノートのUbuntuで導入してみましたよ。
nave.shはGitに乗っかっているのでcloneしてくれば良いです。
導入先は、俺々ルールに則った~/opt/に。

cd ~/opt/ git clone http://github.com/isaacs/nave.git

とりあえず最新版のnode.jsを入れてみる

cd ~/opt/nave/ ./nave.sh install latest

基本的にnave.shに引数を渡して実行するだけです。
上のコマンド例は、最新版（latest）をインストール（install）してるわけですね。
極めてシンプル。使い方に迷ったら、黙って「./nave.sh help」。

つまづくかもしれないポイント

まず、nave.shの動作自体にcurlが必要らしいので、
入ってないのなら導入しておきましょう。

sudo apt-get install curl

他には、g++やopensslなどが要求されますので、こちらもインストール。

sudo apt-get install g++ sudo apt-get install libssl-dev

他にも不足している物があったら、エラーをみて都度導入してあげましょう。

全ての環境が完了するとインストールが始まります。
少々時間を要するので、正座して待ちましょう。

使用するnode.jsを選択する

インストールが完了しても、まだnode.jsは使えません。
useコマンドを使ってどのバージョンを使用するかを選択する必要があります。

./nave.sh use latest

これで、最新版のnode.jsへのパスが通り、
nodeコマンドが使用可能になります！おめでとう！

ただし、一度ログアウトすると未選択に戻ってしまい、毎度useしてあげないといけません。
煩わしい場合は.bashrcにでも書いておくか、usemainコマンドを使ってみるか。

注意点としては、”use latest”した時に最新版が未だインストールされてないと、
長～いインストールが開始されてしまいます。
なので、.bashrcとかに書く場合はバージョンを決め打ちしておいた方が良い気がします。

./nave.sh use 0.4.1

すでにインストール済みのnode.jsのリストは、”nave ls”で見られます。

./nave.sh ls

ついでにnpmも入れておく

npm – Node Package Manager

npmというのは、node.js用のパッケージマネージャ。
せっかくなので入れておきましょう。
公式いくとワンラインインストールのコマンドが書いてあるので、それで瞬殺です。

curl http://npmjs.org/install.sh | sh

テストする

node.js公式にあるスクリプトでHello,Worldしてみましょう。

var http = require('http');
http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('Hello World\n');
}).listen(8124, "127.0.0.1");
console.log('Server running at http://127.0.0.1:8124/');

このスクリプトを「example.js」等に保存して次のコマンドを入力。

node example.js

あとはWebブラウザで「http://127.0.0.1:8124/」にアクセスして
「Hello World」が表示されれば成功です。
たったこれだけでWebサーバが立ち上がっちゃうなんて素敵ですね。

巷で話題のnode.jsを入れて、ちまちま弄ってみてます。
一体どんな事が出来るようになるのか、イベントドリブンとやらに期待が高まりますね。

ちなみに、「nvm」（Node Version Manager)なんてのもあるみたいです。
» creationix/nvm – GitHub