それでは中編で棚上げしていた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のセッションがあって、そこではライブコーディングによるデモが行われている。
最近OAuthの勉強をしているのだが、OAuthを使った認証連携を調べるとだいたいはTwitterかfacebookを使ったアプリのサンプルがでてくる。他にもOAuthに対応しているWebサービスはあるだろうけど、とりあえずはTwitterを使って試してみようかと。
OAuthのプロトコルバージョンはOAuth1.0とOAuth2.0があって、OAuth2.0はまだドラフトの仕様になっている（本エントリ執筆時点ではRev.26が最新）。Twitterの開発者向けドキュメントによると、TwitterがサポートしているのはOAuth1.0だ。
サードパーティ製のクライアントアプリがTwitterとOAuthの認証連携をするためには、まずTwitterの開発者向けサイトでアプリを登録する必要があるので、今回はその方法を紹介していこう。
ブログを開設してから1ヶ月ちょっとだが、はてブされるエントリが出てきたので、ブログ内で被はてブ数を表示させるようにしてみる。ブックマーク数を画像で取得するAPIによると、被はてブ数のアイコンを表示させるには
<img src="http://b.hatena.ne.jp/entry/image/エントリーのURL" />
というimgタグを使えばいい。さらに、アイコンを該当するはてブにリンクさせるには
<a href="http://b.hatena.ne.jp/entry/エントリーのURL"> <img src="http://b.hatena.ne.jp/entry/image/エントリーのURL" /> </a>
というaタグで囲めばいい。
まずはここまでを実現するJavaScriptを書いてみる。
Continue reading »
フォームで入力可能な文字種を制限したい場合に使えるjQueryのプラグインを作ってGitHubにアップしてみた。使い方は至って簡単。jQuery本体とjquery.klimit.jsをHTMLに読み込んで、キー入力制限をしたいフォーム（inputタグ）のclass属性にklimit-*を追加するだけ。
プラグインでデフォルトで用意したクラスは以下の通り。
klimit-digit：10進数のみ入力可能klimit-hex：16進数のみ入力可能klimit-lower：英小文字のみ入力可能klimit-upper：英大文字のみ入力可能klimit-alpha：英字のみ入力可能klimit-alnum：英数字のみ入力可能klimit-graph：英数字と記号のみ入力可能klimit-mail：メールアドレスに使用できる文字のみ入力可能klimit-hexやklimit-graphは用途があるか疑問だが…。
1月13日（金）にPalo Altoで行われたJTPAのギークサロンに参加してきた。今回は参加者がラップトップ持ち込みでコーディングしていくハッカソン形式で、会場入りする前までにHadoopが使える環境を自前で用意しておく必要があった。
前編では、Hadoopを使って計算処理をするための準備として、EC2上にHadoopクラスタを構築する方法を紹介した。後編では実際にギークサロンで手を動かしてやったことを中心に紹介していこう。
64ビット版Fedora14にboost-1.48.0の32ビット版バイナリをインストールしようとしたら、結構手こずってしまったので忘れないようにメモ。RPMがあればyumでインストールしてしまいたいが、あいにくFedora14のRPMリポジトリはboost-1.44.0以降、更新される気配がなくなってしまったので（本エントリ執筆時点でFedora16はboost-1.47.0まで公開されていた）、自前でビルドせざるを得なくなった。開発マシンが32ビット環境から64ビット環境に変わっても、32ビット版のモジュールをコンパイルすることはまだあるので、64ビット環境でも32ビット版を一緒にコンパイルできた方がずっと楽だ。
まず64ビット版のboostをビルドするには、Boost Getting Started on Unix Variantsの手順に従えばなんなくビルドできるのだが、バージョンアップを考慮してインストール先のディレクトリをデフォルトから変更してビルドする。