惭辞箩辞濒颈肠颈辞耻蝉::尝颈迟别を使ってみよう
- 1. Mojolicious::Lite を使ってみよう February 19, 2011 Hokkaido.pm #4 Kenichi Ishigaki (charsbar) はじめに Hokkaido.pm #4 の午前の部では Mojolicious::Lite を使って簡単なウェブアプリケーショ ンをつくってみます。わからないことがあったら遠慮なく質問してください。また、ある 程度わかっている方はどんどん先に進んでいただいて結構です。 なお、今回の講習ではほとんどの作業をコマンドプロンプト／シェルから行います。みな さんご存じと思いますが、Windows をお使いの方はスタートメニューから「すべてのプロ グラム」などと書かれたメニューを開き、「アクセサリ」の中に入っている「コマンドプロ ンプト」（または「Windows PowerShell」）というアプリケーションを、MacOSX を含む Unix 系の方はターミナル、端末等々の名前がついているアプリケーションを起動してくだ さい。以下、コマンドプロンプトから実行するコマンドについては、下記のように表記し 「>」は Windows のコマンドプロンプトです（Unix 系 OS をお使いの方は適宜読み ます。 替えてください）。 ? (コマンド名) (引数...) Mojolicious(::Lite)について Mojolicious(::Lite)は、Perl 界でもっとも有名なウェブアプリケーションフレームワークの ひとつである Catalyst の原作者ゼバスティアン?リーデル(Sebastian Riedel)氏が 2008 年 から開発しているウェブアプリケーションフレームワークです。過去の経緯については gihyo.jp の特集記事、連載記事にまとめてありますが、これらはすでに古くなっているので 参考程度にとどめてください。 http://gihyo.jp/dev/feature/01/mojo http://gihyo.jp/dev/serial/01/modern-perl/0022
- 2. いま Mojolicious(::Lite)を使う理由としては、たとえば次のようなものがあげられます。 - インストールが簡単 - 昔の CGI スクリプトと同じく、簡単なサイトならファイルひとつで配布可能 - Mojolicious そのもののインストールも外部依存がないので簡単 - Windows 環境でも問題なくインストールできます - 小規模サイトなら Apache などの外部サーバも必要ありません - サイトの成長にあわせて Mojolicious::Lite から Mojolicious に移行可能 - 簡単なことは簡単にできますし、複雑なことにも対応できます - ドキュメントも少しずつ充実してきました - http://mojolicio.us/perldoc - https://github.com/kraih/mojo/wiki - http://wiki.livedoor.jp/mojolicious/ - ウェブ標準に敏感で、最近の仕様にもわりと早く追随してくれます - WebSocket とか HTML5 とか 一方で、このような批判もありました。 - 開発中の仕様変更やファイルの再配置が多かった - 連載記事などのサンプルコードには半年ともたず古びたものもありました - バージョン 1.0 になったので、今後極端に大きな仕様変更は減ると期待されます - それでもリーデル氏の過去の言動から安定性を不安視する人はいるのですが… - 遅い - まだ十分な最適化が行われていない場所はあるかもしれません - 必要に応じて外部モジュールで高速化することはそうむずかしくありません - そもそもどのくらいの速度が必要ですか？ - 独自モジュールが多く学習コストが高い - 既存の古いモジュールの置き換えがひとつの目的なのである意味仕方ありません - 必要に応じて外部モジュールを利用することはそうむずかしくありません この原稿を書いている現在、Mojolicious の最新版はバージョン 1.1 です。お手元のバージ ョンが古い場合、細かな挙動が異なる可能性がありますので、なるべく最新版に更新して ください。
- 3. 今回つくるアプリケーションについて 今回は自宅でも手軽に利用できるものとして、Wiki っぽいアプリケーションをつくってみ ます。時間も限られていますので、最初は特定のディレクトリ配下のファイルの内容をブ ラウザ経由で表示?更新できるだけのものをつくり、そこから順に発展させていくことに しましょう。 初期の要件は以下の通りとします。 - 指定したディレクトリ配下のファイルとサイトの URL が一対一対応するものとします - 「http://.../html/(ファイル)」でファイルの内容を表示してください - 「http://.../html/(ファイル)/update」で内容を更新したいです - 「http://.../html/(ファイル)/delete」でファイルの削除 - 「http://.../html/(ファイル)/create」で新規ファイルを作成 - 「http://.../html/(ディレクトリ)」の場合はファイル一覧を表示しましょう 時間に余裕があったらこのあたりまで対応できるといいですね - もちろん見栄えはよくしておくにこしたことはありません - 静的ファイルをいくつか追加しましょう - POD や markdown テキストが含まれていたら HTML にレンダリングした方がよいかも - 知らない拡張子の場合は更新できないようにした方が無難でしょう - バイナリとしてダウンロードさせる手もありそうですが - 特定のユーザのみ閲覧?更新可能なページがあるといいかも - ファイルのパーミッションも確認しましょう（読み込み専用コンテンツ） - 「http://.../api/...」にアクセスしたらコンテンツを JSON で返してほしいです - 検索もできるにこしたことはありません - Wiki というなら更新履歴や差分もほしいところでしょう - ディレクトリをまるごと git 管理してみましょうか - 更新時の衝突回避はどうしましょうか - XSS や CSRF の対策は十分ですか - cf. Mojolicious::Plugin::CSRFDefender (https://github.com/shiba-yu36/p5-Mojolicious-Plugin-CSRFDefender)
- 4. Perl と Mojolicious のインストール Windows をお使いの方で Perl のインストールが済んでいない方は下記サイトから ActivePerl ないし Strawberry Perl をインストールしてください。 ActivePerl: http://www.activestate.com/activeperl/downloads Strawberry Perl: http://strawberryperl.com/ Mojolicious(::Lite)は CPAN からダウンロードできます。コマンドプロンプトから以下のコ マンドを実行してください。 ? (sudo) cpan Mojolicious また、公式サイトから tarball をダウンロードすることもできます。 http://latest.mojolicio.us/ 最新の開発版は github からチェックアウトしてください。 ? git clone git://github.com/kraih/mojo ひな形をつくる Mojolicious のインストールが済んだら、適当なディレクトリに移動して、以下のコマンド を実行してください。myapp.pl の部分はお好きな名前に変えていただいて結構です。 ? mojo generate lite_app myapp.pl # カレントディレクトリのファイル一覧を表示して、myapp.pl というファイルができてい ることを確認してください。
- 5. ブラウザで確認してみよう Mojolicious::Lite アプリケーションには標準でウェブサーバ機能が用意されています。コマ ンドプロンプトから以下のコマンドを実行してください。 ? perl myapp.pl daemon # ウェブブラウザを起動して、実際にサイトが表示できるか確認してください。 http://localhost:3000 サーバを止めたい場合はコマンドプロンプトで Ctrl＋C などを入力します。 Plack をインストール済みの方は以下のコマンドも実行してみましょう。 ? plackup -a myapp.pl # こちらもウェブブラウザを起動して、実際にサイトが表示できるか確認してください。 http://localhost:5000 ひな形アプリケーションのお役立ち機能 ひな形アプリケーションを起動したあと、下記の URL に移動するとインストール済みの Mojolicious のドキュメントを読むことができます（古い Perl をお使いの方は CPAN から Pod::Simple の最新版をインストールする必要があるかもしれません）。 http://localhost:3000/perldoc この機能はおもに Mojolicious::Plugin::PodRenderer のなかで実装されています。今回のサ ンプルアプリケーション作りの参考になりそうですね。 確認が済んだら、pod_renderer というプラグインを読み込んでいる行は消してしまってく ださい。
- 6. ふたつの道 ここから先はふたつの道があります。 目で動作確認しながらでないと落ち着かない方はディスパッチャの設定からしてしまいま しょう。仮テンプレートの作成などが必要になるのでいくらか余計に手間はかかりますが、 実際に動いているのが確認できるので、不慣れなうちはこちらの方が楽しく書けますし、 上司や顧客が相手でも途中経過を見せやすいです。ただし、こちらの道を通ると、なまじ 目チェックが入るせいで、特に異常時のテストがおろそかになりがちですし、どうしても ウェブの事情を優先してしまいがちなので、あとで拡張に苦労することも多くなります。 また、バグが出たときに問題の切り分けがややむずかしくなります。 ある程度開発に慣れている方ならモデルを書いていく方が早道です。関心を分離しながら の作業になるので、最終的に表示部分を作るまで人には見せられないのが難点ですが、こ のモデル部分はウェブの表示以外にも使えますから、自動テストはもとより、データの収 集や加工用のスクリプトなどが必要な場合にも対応しやすくなります。 ディスパッチャ（ルータ）を用意する Mojolicious::Lite のディスパッチャについては、Mojolicious::Lite のドキュメントのほか、 Mojolicious::Guides::Routing というドキュメントによくまとまっています。ごく基本的な 構成は次の通りです。 get (または post、any など) '/(対象となるパス)' => sub { ... }; パスにはさまざまなプレースホルダを利用できます。今回の例ではいちばんゆるいワイル ドカード型のプレースホルダを利用するのが楽でしょう。サブルーチンの中身はひとまず 最初に用意されていた「/welcome」のものをコピーしておいてください。 get '/html/(*path)/create' => sub { ... }; get '/html/(*path)' => sub { ... }; なお、このように変化しない共通の部分がある場合は under コマンドを利用すると便利で
- 7. す。 under '/html'; # 以下のパスはすべて /html 配下になります。 get '/(*path)/create' => sub { ... }; get '/(*path)' => sub { ... }; また、特にワイルドカード型のプレースホルダを使う場合、条件のゆるいルートを先に書 いてしまうと、後続のパスが無視される結果になることがあります。設定の記載順には注 意してください。 必要なパスの設定が済んだら、コマンドラインから以下のコマンドを実行して、ルートが 正しく設定されているか確認しましょう。期待通りの正規表現が表示されていますか？ ? perl myapp.pl routes ルーティングの際に受け取ったパスは、stash、あるいは param から取り出せます。index テンプレートに手を入れてどんなパスを受け取ったか確かめてみましょう。 @@ index.html.ep % layout 'default'; % title 'Welcome'; Welcome to Mojolicious! <%= stash 'path' %> Mojolicious::Lite のテンプレートについては、Mojolicious::Lite のドキュメントのほか、 Mojolicious::Guides::Rendering というドキュメントによくまとまっています。基本的には 必要なところに「<%= (Perl の変数、式) %>」を埋め込んでいくだけですが、条件文など、 より複雑な式を書く場合は、行頭を「%」で始めると、その行はそのまま Perl として解釈 されます。また、stash をはじめ、Mojolicious の標準テンプレートにはヘルパーコマンド が い く つ か 用 意 さ れ て い ま す 。 詳 し く は Mojolicious::Plugin::DefaultHelpers と 、 Mojolicious::Plugin::TagHelpers をそれぞれ確認してみてください。
- 8. Mojolicious の テ ン プ レ ー ト に な じ め な い 方 は 、 MojoX::Renderer::TT や MojoX::Renderer::Xslate といった代替品もありますが、なかには最新版に対応していない ものもあるかもしれません（TT の最新版は Windows だとテストに失敗するようです）。 ディスパッチャのテストを書く ディスパッチャを書いたら、期待通りの動作をしているか、テストしてみましょう。先ほ どのようにサーバを起動してブラウザで確認してもかまいませんが、Mojolicious に同梱さ れている Test::Mojo を使うとあたかも人間が実際にアクセスしたかのようなテストコード を書くこともできます。試しに myapp.pl と同じディレクトリに test.t というテストスクリ プトを用意してみましょう。 use strict; use warnings; use Test::More; use Test::Mojo; require 'myapp.pl'; my $t = Test::Mojo->new; $t->get_ok('/html/foobar')->status_is(200); done_testing; ここではまだステータスコードの確認しかしていませんが、Mojo::DOM の機能を使うと CSS セレクタを利用して HTML の中身を細かく調べることもできます。詳しくは Test::Mojo と Mojo::DOM をそれぞれ確認してみてください。 モデルをつくる モデリングの仕方にもさまざまな流儀がありますが、ここではあまり細かなことは考えず、 モデルの適切なメソッドに「/foo/bar」のようなパス情報（と、必要に応じて更新用のデー タ）を渡したら、該当するファイルの内容を取り出したり、更新したりできるようになっ ていればよしとしましょう。
- 9. また、テストのしやすさを考えて、表示?更新に使うファイルを格納するディレクトリは オブジェクト作成時に変更できるようにしておくのが無難です。 本当に小さなアプリケーションで、モデルクラスもそれほど大きくならないことがわかっ ている場合は、myapp.pl スクリプトと同じディレクトリに MyApp.pm のようなモジュー ルを用意してもかまいませんが、ここではいずれほかのモジュールも追加することになる ことが予想できますので、CPAN モジュールで一般的に使われているレイアウトにあわせ ることにしましょう。lib ディレクトリを掘って、lib/MyApp.pm というファイルを用意し ます。 package MyApp; use strict; use warnings; use File::Spec; sub new { my $class = shift; bless {@_}, $class; } sub home { shift->{home} || '.' } sub read { my ($self, $path) = @_; my $file = File::Spec->catfile($self->home, $path); open my $fh, '<', $file or die $!; local $/; return <$fh>; } sub create { my ($self, $path, $content) = @_; my $file = File::Spec->catfile($self->home, $path); open my $fh, '>', $file or die $!; print $fh $content; } 1;
- 10. モデルをテストする モデルが書けたらテストもしましょう。CPAN のレイアウトにあわせてテストファイルは t ディレクトリ以下に置くことにします。t/model.t というスクリプトを用意してください。 use strict; use warnings; use FindBin; use lib "$FindBin::Bin/../lib"; use MyApp; use Test::More; my $testdir = "$FindBin::Bin/test"; mkdir $testdir unless -d $testdir; my $m = MyApp->new(home => $testdir); $m->create('foo', 'foobar'); is $m->read('foo') => 'foobar'; done_testing; Mojolicious::Lite アプリにモデルを組み込む 最後に Mojolicious::Lite アプリからモデルを呼び出せるようにしましょう。 まずは myapp.pl の先頭の方にこのようなコードを追加します。 use lib 'lib'; use MyApp; my $model = MyApp->new(home => app->home); app->helper(model => sub {return $model});
- 11. これで app->model からモデルを呼び出せるようになりました。正しくファイルが読み込め ているか確認しましょう。 get '/(*path)' => sub { my $self = shift; my $content = app->model->read($self->param('path')); $self->stash(content => $content); $self->render('index'); }; @@ index.html.ep % layout 'default'; <%= stash 'path' %> <pre> <%= stash 'content' %> </pre> この変更を加えたことで、先ほど書いたディスパッチャのテストが通らなくなったはずで す。ファイルが存在している場合、していない場合等々、さまざまな条件を考慮したテス トを書いてみましょう。また、モデルの設計として、最初はあっさり die させておきました が、本当にこれでよかったでしょうか？ Mojolicious はデフォルトのままだと utf8 が前提になっているため、このままだと、環境に よっては日本語を含むファイルなどが文字化けします。Encode や Mojo::ByteStream を利 用して文字コードまわりの対応も強化する必要があるはずです。また、utf8 以外の文字コ ードを利用するなら Mojolicious::Plugin::Charset を組み込む必要もあるでしょう。 今回は時間がたりず、紙の資料はここまでしか用意できていませんが、このセッション内 でも、そのあとでも、わからないことがあったら遠慮なく質問してください。 Happy Hacking!