7月20日に催されたJTPAギークサロン「青木淳氏とNode.js/Herokuを体験する」にボランティアのテクニカルサポートスタッフとして参加してきた。JTPAでのハッカソンは、Hadoopで始める並列データ解析以来。参加者は各々ラップトップを持ち込み（参加者の9割がMacというのがシリコンバレーらしい）、ガイドに従いながらプログラムを書いていくわけだが、Hadoopの時と同様に参加者のプログラミングスキルはバラバラ。自分でWebサービスを作ったことがある人もいれば、プログラムを書いたことがないという初心者もいたけれど、ホスト役の青木氏の素晴らしいファシリテーションで、時間内に全員が「heroku上でMySQLを使ったnodeアプリを動かす」というゴールに辿り着くことができた。
.vimrcなどで自分専用のVim環境を作っていると、文字色や背景色の色指定をctermbgなどの数値で設定する際に、色と数値の対応表がほしくなることがある。そんなときに使えるPerlスクリプトを書いてみた。
それでは中編で棚上げしていたsyncメソッドを提供するAPIの実装を書いていこう。
Sequelizeのサンプルを見てもわかるように、syncメソッドはimportメソッドによってインスタンス化されたモデルオブジェクトに対する呼び出し（Project.sync）と、Sequelizeオブジェクトに対する呼び出し（sequelize.sync）の2パターンある。モデルオブジェクトに対してsync()を実行すると、対応するテーブル定義だけが構築される。 Sequelizeオブジェクトに対してsync()を実行すると、データベース全体が構築される。また、sync()の引数に{ force: true }を渡すと、既存のテーブルを一旦削除（DROP）してゼロからテーブルを作り直す（再構築）。
前編では、Sequelizeをインスタンス化するために自前でdbconnモジュールを作って、app.jsはこんな感じにシンプルに書けるようになった。
var express = require('express')
, resource = require('express-resource')
, config = require('config')
, sequelize = require('dbconn')(config)
, app = module.exports = express.createServer();
app.resource('users', require('./routes/users'), { id: 'id' });
実際にSequelizeを使ってDBに対するCRUD操作を行うAPIの実装を書く以前に、まだDBすら存在しないのでmysqlコマンドでDBだけ作っておく。
MVCアプリケーションを作る際、コントローラ（C）とビュー（V）は前回紹介したexpress-resourceが面倒を見てくれる。REST APIの場合はビューと呼ぶほどのものではないが、APIの出力形式をXML、JSONと複数対応するにはコンテントネゴシエーションが強力なビュー機能を提供してくれると言える。
さて、今回はモデル（M）に相当する部分を作る際に欠かせないSequelizeを紹介しよう。 Sequelizeを使うと、DBのスキーマやデータを、node.jsアプリケーション内でJavaScriptオブジェクトとして扱えるようになる。いわゆるO/Rマッパーを実現してくれる。MySQL、SQLite、 PostgreSQLと主なオープンソースのRDBMSはサポートされており、RDBMS毎に微妙に異なるSQLの方言などを吸収してくれるので、仮に開発過程でRDBMSを乗り換えることがあったとしても、アプリ側のコードに大掛かりな修正が生じなくて済む。
「node.jsを使って簡単にWebアプリが作れる！」みたいな記事で紹介されているサンプルコードは、だいたいそのまま使いものにならないことが多い。実際のアプリ開発では、いろいろなモジュールをNPMでインストールして、ソースコードツリーの階層なんかにも気を配ったりするものだ。DBへのアクセスも一元化して、O/Rマッパーも使えるようにしたい。国際化対応も考えなければならない。デバッガも必要だ。アプリを作りながら後付していくのもいいが、最初の段階である程度は固めておきたいと思う人も多いだろう。
すべてを一気に紹介すると相当長くなりそうなので、今回はREST APIを作る上で欠かせないexpressとexpress-resourceに焦点を当てる。node.jsとNPMをまだインストールしていなかったらnvmでインストールしておこう。
SenchaのAPIリファレンスサイトであるSencha DocsがExt JS 4を使って実装されているのは知っていて、Ext JS 4をガシガシ使っているところを見ると、Senchaの中で作られたクローズドなフレームワークなんだろうなと思い込んでいた。しかし、つい最近TitaniumのAPIリファレンスを見たら、まったく同じ構成をしていることに驚いて、オープンソースのフレームワークなのか!?と思い、Xenophyの@kotsutsumiさんに訊いたら「JSDuckのことですね。」と教えてくれた。
開発したのはやはりSenchaの中の人なんだが、GitHub上でソースが公開されていた。去年のSenchaCon 2011でもJSDuckのセッションがあって、そこではライブコーディングによるデモが行われている。
Suffusionにテーマを切り替えてまず最初に目についたのが、サイドバーに置いているAdSenseがウィジェットに収まりきっていないところ（右図）。AdSenseの広告の幅が300pxなのに対して、ウィジェットの幅は260pxしかないので、サイドバー全体の幅を拡張してやる必要がある。
ダッシュボードの「外観／Suffusion Options」をクリックすると（何度見ても「DON’T PANIC!!」というメッセージに面食らうw）、CSSを書き換えずにテーマのスタイルを変更できるようなUIが出てくる。配色とかレイアウトとか、かなり細かく設定できるようになっているようだ。Skinningのタブは、配色とかアイコンセットとかを変更するがわりかし直観的だったのだが、いざサイドバーの幅を広げようと思ったら、Layoutsタブの下にあるDefault Sidebar Layoutや1 Right Sideber、Sidebarsタブの下にあるSidebar 1と、同じような設定があちこちにあって大混乱。あちこちのWidthを変えてみたものの、なかなか期待した表示にならなかったり。
WordPressのテーマをSuffusionに乗り換えて気持ちもなんだかリフレッシュしたところで、さっそくスタイルのカスタマイズに着手していこう。スタイルシートは「外観／テーマの編集」から編集することができるが、一般的には、スタイルとかをカスタマイズするには子テーマを使うのが定石らしい。そうしないと、（iFeatureでしくじったように）テーマをアップデートしたらカスタマイズしたスタイルが消えてしまう。子テーマの作り方はWordPress Codexに詳しく書かれているが、この辺の面倒な作業を代わりにやってくれるOne-Click Child Themeという便利なプラグインがあったのでインストール＆有効化。ダッシュボードに追加された「外観／Child Theme」というメニューをクリックする。
ブログ開設当初はWordPressのテーマにiFeatureを使っていたのだが、カスタマイズしていく上でいろいろ不便なところがあったのでSuffusionに乗り換えることにした。iFeatureの何がイケてなかったかというと、CSSをちょこっと変えたいといったときに、メインのstyle.cssにスタイルを書き加えてもまったく反映されないところ。WordPressのダッシュボードから、「外観／テーマの編集」をクリックして、右側の一番下にある「スタイルシート（style.css）」を選択すると、一般のテーマではグローバルなスタイルを変更できるのだが、HTMLのソースを見てみるとiFeatureはどういうわけかstyle.cssを読み込んでいないのだ。