実践JS サーバサイド JavaScript 入門「パーフェクトJava」発売の時に章ごとの自己評価を書きました。
同じことを「実践JS サーバサイド JavaScript 入門」で書こうと思います。ただ「パーフェクトJava」の時と少し事情が異なります。「実践JS サーバサイドJavaScript 入門」は冒頭の「本書の読み方」でパートごとの簡単な紹介を書いています。要は、既に公式には自己評価に近い内容を本の中に吐露済みです。そんなわけでこれから書くのは裏バージョンです。
1章 サーバサイドJavaScriptの動向
なぜサーバサイドJavaScriptなのかを可能な限り客観的に書いたつもりです。もちろん、サーバサイドJavaScriptの本なので、なぜサーバサイドJavaScriptかの論旨に強引さがあるのは否定しません。そもそも結論ありきの話です。
本を書いたことを差し引いても、JavaScriptがサーバサイドに進出するのはそれなりに確度があると思っています。ただ、JavaScriptがサーバサイド言語の本流になるかと言われると、率直に言ってわかりません。
現時点のサーバサイドのプログラミング言語(環境)は、Java、.NET、PHPが先頭集団、Perl、Ruby、Pythonが2番手集団というの自分の見立てです。プログラミング言語には熱狂的ファンがいるので迂闊に書くと根拠を示せと怒られそうですが気にせず書きます。今後、JavaScriptが2番手集団に入ってもおかしくないと思っています。更にこう書くとファンに怒られそうですが、サーバサイドJavaScriptが侵食(開発者を奪う)するのはPHPではないかと勝手に思っています。
サーバサイドJavaScriptを使う理由は本に書いていますが、ひとつ取り上げると複数のプログラミング言語を使い分けるのが面倒だからという理由があります。クライアントサイドJavaScriptはある前提で、Webアプリ開発で複数のプログラミング言語を使いたくなければ、アプローチは次の3つ考えられます。
- サーバサイドもJavaScriptで書く
- クライアントサイドJavaScriptを書かない(コード生成)
- Web APIだけ提供してクライアントは第三者に書かせる
アーキテクチャとしては最後が一番美しいですし、個人的にはこれがベストですが、これができるのはブランド力か財力のある人だけです。普通の人は簡単にまねできません。最初と2番目の件は本に書いてあるので興味があれば見てください。
2章 サーバサイドJavaScriptに共通APIが必要な背景
本書は、JavaScriptの生まれは拡張言語だというスタンスで書いています。本書での拡張言語の定義は、アプリに組み込んで機能を拡張する言語で、かつエンドユーザが書いたコードを実行できるアーキテクチャを意図しています。同じ意味で、組み込み言語と呼ぶ向きもありますが、組み込み言語と呼ぶと最近は組み込み機器用の言語と間違われるようなので、用語は拡張言語で統一しています。
かつて拡張言語の雄はLisp(系言語)でした。Emacsが一番有名ですが、(知る人ぞ知る)CannaもLisp系言語で設定ファイルを書けました。GIMPのScheme系言語(Script-Fu)も有名です。かつてTclが拡張言語として売り出した頃、rmsがTclをやめてみんなGuileを使え、と全世界に訴えたのは記憶に新しいところです(15年以上前ですが…)。
Lispファンには申し訳ないですが(JavaScript本を書くと色んな言語に喧嘩を売るようで心苦しい)、拡張言語の主流はJavaScriptに移った(移る)と思っています。
3章 標準オブジェクト
リファレンス的な章です。ECMAScript第5版ベースなのが少し目新しいと思います。JSONオブジェクト(ECMAScript第5版にあるネイティブJSONオブジェクト)とE4X(ECMAScript for XML)の解説が希少価値です。
4章 CommonJS
前半の山場です。CommonJSは次のURLをください。たぶんCommonJSを扱っているのは(今のところ)日本で唯一の書です。
– http://www.commonjs.org/
前半の山場の章ですが誤算もありました。ひとつはnode.jsの扱いです。この章でCommonJS実装のひとつとしてnode.jsを取り上げました。本質は触れましたが、もっと書けば良かったかなとは思います。個別のAPIに深入りしても内容が古くなりますが。
もうひとつはCommonJSの規格が思ったより進まなかったことです。2010年の初めの頃からCommonJSのMLを購読しています。流量こそ止まっていませんが、思ったより進展がありません。このまま行くとnode.jsのAPIの後追い規格に成り下がる可能性もあります。何も貢献せずに外野から言うだけは失礼なのでこれ以上は書きません。
5章 JavaのスクリプティングAPI
Java6のスクリプティングAPIです。先日、WEB+DB PRESSにJVM言語の記事を書きましたが、あれが伏線です。興味があれば合わせて読んでください。
6章 アーキテクチャ概論
Webアプリのアーキテクチャとか、MVCアーキテクチャとか、など書いています。今更な感じもありますが、クライアントサイドJavaScriptしかやっていないと、Webアプリの作りそのもののイメージを持っていない人もいるので書きました。
7章 非JVMアプリコンテナ
8章 JVM系アプリコンテナ
7章と8章は各論で、具体的なサーバサイドJavaScriptをいくつか紹介しています。なぜJVMと非JVMで分けたのかと言うと単にページ数のバランスの問題です。非JVMという呼び方は、JVMがやけに偉そうで(JVMが本流みたい)好きな呼び方ではないのですが、他に良い分類がなくて、JVMと非JVMになりました。
9章 CouchDB
10章 MongoDB
知る人ぞ知るサーバサイドJavaScriptが動くCouchDBとMongoDBの章です。NoSQLで想起する一番の特徴の分散処理のことは書いていません。そっち方面は別媒体で書いたので後日紹介します。
本書は主に非RDBの世界のデータ設計について書いたので、その点は特徴的かもしれません。非正規化でどうデータ設計するのかに興味があれば読んでみてください。
CouchDBはサーバサイドJavaScriptの解説がそのままアプリ実行環境としてのCouchDBの解説になります。このため、本書はCouchDB専門書でないですが、結果的にCouchDBの相当部分を説明していると思います。ちなみにCouchDBのMap/ReduceはHadoop等のMap/Reduceと(応用分野として)違う面白さがあるのでその方面に興味があれば読んでみてください。
MongoDBのサーバサイドJavaScriptは、MongoDB全体で見ると、端的に言ってあまり大きな領域ではありません。CouchDBに比べると本書のMongoDB網羅度は高くありません。とは言え、MongoDB本はまだ出ていないと思うので、データの持ち方(データベース、コレクション、ドキュメント)や一連の操作を紙で読みたい人のニーズには合致するかもしれません。
11章 Google Apps Scriptによるクラウドコンピューティング
Google Apps Scriptです。突然、この章だけスクリーンショット満載です。
本の中にも書いていますが、個人的には、本書で取り上げているサーバサイドJavaScriptの中で、Google Apps Scriptが一番最先端だと思っています。
Google Apps Scriptは凄いと思います。凄いのですが(たぶん多くのプログラマには)面白くはありません。ほとんどのプログラマはExcelのマクロにあまり興味がないと思います。もっと低レベルで不細工で愛想のない技術じゃないと萌えません。そんなものです。しかし、Google Apps Scriptが今ここまで来ていることは認識しておいたほうがいいと思います。
12章 アーキテクチャ
13章 設計と実装
Google App Engine for Java(GAE/J)上でRhino載せるアプリの実践です。タイトルが実践JSになったので実践的な何か、というリクエストで書きました。Javaの本かと思うような内容になってしまいました。JavaScript本なのにGAE/Jも学べるお得な本です。
最近のコメント