Sinatraを利用する局面

それでは，現状のフレームワークとしてのSinatraが持つポテンシャルとして，どういったものの開発利用が考えられるでしょうか。

画面遷移数が少ないWebアプリケーション

一番利用が考えられるのが，画面遷移数が少ないWebアプリケーションです。個人的に作成して公開する，TwitterのAPIを利用したサービスなどがこのパターンで，もっともSinatraが力を発揮できる開発規模でしょう。

あくまで個人が中心の開発であれば，"Modular"スタイルを用いるまでもなく，ささっとトップレベルに書き捨ててしまうのが筆者の好みです。

商用利用であれば，企業のキャンペーンに利用されるような，画面遷移がせいぜい10くらいまでで，フォーム利用が少しあるくらいの規模のWebサイトも，Sinatraでの開発に適していると言えるでしょう。

このアプリケーションの例としては，筆者が講師をさせていただいた「第3回東京RubyKaigi」で，O/RマッパーにDataMapperを用いた簡単なTwitterクローンアプリケーションを作成するワークショップを行いましたので，参考にしてください。(コードはこちらから)

また，Sinatraで作られたScantyはO/RマッパーにSequelを用いた例なので，Sequelを好まれる方には参考になるでしょう。

ツールのWebインターフェース

Webインターフェースの例としては，Integrityがあります。

gitでのコミットとともにソースコードをビルドし，テストを実行するこのツールの管理画面の開発にSinatraは利用されています。

製品の主軸となる機能、Integrityの場合はサーバですが，その結果を閲覧したり，処理を実行するためのランチャーであったり，あくまでサポートの機能として，小規模なアプリケーションを付属させたい場合，Sinatraは適していると言えるでしょう。

WebAPI

GoogleやTwitterの例を出すまでもなく，HTMLをレスポンスとして返さないWebアプリケーション，つまりWebAPIは一般的になりました。ソーシャルアプリ／ゲーム開発など，実際の現場でも案件が多くなってきた印象を受けますが，SinatraはこうしたWebAPIを短期間に開発するのに非常に適しています。

Sinatra自身のAPI設計との相性が良く，今後主軸になる可能性が一番ある利用法とも言えるかもしれません。

Sinatraを利用する規模感

どの利用法にせよ，テンプレートを除いたSinatraアプリケーション本体のソースコードが，100～500行くらいで1ファイルに収まる程度の規模までが適しているというのが，筆者の感覚値です。

それ以上で，ファイル構成を考えざるを得ないくらいの規模になったときは，Sinatraの利用が妥当であるかどうか，一度考え直してみるタイミングかもしれません。

開発上のTips

次に，筆者の経験上から，いくつかの開発時のTipsを紹介します。

開発環境

Sinatra本体の開発は，Herokuの資金的サポート（※1）を受けています。それもあって，Herokuを利用しての開発はかなりスムーズです。

Herokuでは，既にSinatraと，Sinatra周辺でよく利用されるであろうライブラリの多くは既にサーバにインストールされています。また，.gemsファイルに明記することで任意のSinatraのバージョンやライブラリを利用することも可能です。

商用で利用するのは，EC2のパフォーマンス的に，またクラウドという特殊性からもなかなか難しいと思いますが，個人利用や開発環境での利用は積極的に検討するべきでしょう。

※1

http://www.sinatrarb.com/about や http://www.infoq.com/jp/news/2010/04/sinatra-10 を参照。

ファイル構成

SinatraはRackアプリケーションですので，Rackの標準的なファイル構成に従うのがよいでしょう。特にPassengerで動かす場合などにスムーズです。

lib/の直下に{アプリケーション名}/でディレクトリを配置させるやり方は，"Modular"スタイルを適用させる場合に有効です。その場合，以下に注意点を列挙します。

• config.ruのファイル名はなるべくそのままが良い。
• {アプリケーション名}.rbファイル単体でテスト可能なように保つ。そのためconfig.ruなどに設定などをあまり書かない方が良い。
• {アプリケーション名}.rbファイル内で関連ファイルをロードするようにし、アプリケーションの記述は別ファイル(ここではapp.rb)に分離する。
• ヘルパーメソッドは膨らみがちなので，別ファイル(ここではhelper.rb)に分離し，helpersメソッドで読み込む。
• {アプリケーション名}/ディレクトリ配下にアプリケーション関連のファイルを配置する。
• {アプリケーション名}でモジュールを定義し，名前空間として用いれば良い。

+-- config.ru
|
+-- view/
|
+-- public/
|
+-- test/
|
+-- lib/
        |
        +-- {アプリケーション名}.rb
        |
        +-- {アプリケーション名}/
               |
               +-- app.rb
               |
               +-- helper.rb

書き捨てのアプリケーションの場合は，テンプレートも含めすべてを1ファイル内に記述するスタイルのほうが良い場合もあるためこの限りではありませんが，config.ruとアプリケーションは分けたほうがテストしやすいので，おすすめです。