\ay diary

Passenger 1.0.1の動作はなんとなく分かった気分になってきているのだけど、実際のところコードのほうはひいきめに見ても半分くらいしか見ていないかな。もう少しきちんと読んでおきたいところだが。

ざっとドキュメントを読んでみたところでは、アプローチとしてはFastCGIと似ているみたい。つまり、Railsアプリケーションのために起動されるプロセスを永続化させることで速度を得る。

ただ、FastCGIと違う点が(もちろん)あって、その一つはフレームワークのコードと、フレームワークのコード-アプリケーションの組み合わせに応じてコードをキャッシュする(プロセスを確保しておく)ということのようだ。フレームワークのコードというのは、アプリケシーションが利用しているRailsのことで、コードの所在やgemのバージョンなどに応じてプロセス(framework spawn server)が作られる。その先にアプリケーションのコードまでを読み込んだプロセス(application spawn server)が作られ、そこから具体的なアプリケーション実行プロセス(インスタンス)が生成される。

これらキャッシュまわりのプロセスのツリーの構築はpassenger-spawn-server(spawn server)が行うのだが、その他の制御はmod_passengerが行う。つまり、しかるべきプロセスに対してアプリケーションを動作させるためのプロセスを生成させ、それをコントロールするのはmod_passengerの仕事となる。ただ、実際には、framework spawn serverとapplication spawn serverについてのタイムアウト処理については、それぞれspawn serverとframework spawn serverが行っているようだ(個々のインスタンスのタイムアウトはmod_passengerが処理する)。

他にはconfig/environment.rbのオーナーの権限でアプリケーションを動させること(ただし特権では動作せず、RailsDefaultUserの権限になる)や、リクエストURIとRailsアプリケーションのマッピングの簡略化なども特徴といえるようだ。

Mongrelなどに対しては、ヒマしてるプロセスを長居させなくてすむといった利点が挙げられている。また、「Ruby Enterprise Edition」を使うことでcopy-on-write的な点でメモリ効率も上げられるよーというようなことが書いてある気がするが、肝心のRuby Enterprise Editionが何ものなのかはまだ資料が出来ていないようでよく分からない。

複数のアプリケーションを同居させるときのマッピングの指定方法やmod_aliasとの相性問題(?)など、ドキュメントをながめただけでは詳細が分からない点もあるが、前述のことも含め、実際に動かしてみてみよう。

追記1: ソースを読んだりしてもう少し様子が分かった。RailsBaseURIというのはLocation+SetHandlerみたいなものなのね。

追記2(2007-04-16): mod_aliasとの相性というか、要するにDocumentRoot以下の構造とリクエストURIのパス部分の構造が一致しているのを想定しているということのようだ。なので、Passengerが動作するバーチャルホストでmod_aliasを使うとすぐにアウトということでもない。もう少しがんばれそうだが、今後どうにかしていくのかな?

少しだけど実際に動してみることでもう少し分かったので、先の記事を少しだけど書き換えておいた。

他に気付いた点として、passenger-spawn-serverにはSIGHUPでリロードがかかるような感じのコードがあるのだけど、シグナルハンドラを設定する親クラスのコードではSIGHUPを常に無視するようになっていて、結局のところSIGHUPには無反応になっているようだというのがある。もうちょっと確認したほうが良さそうだけど、その通りだとすればどっちが位図した挙動なのか気になる。SIGHUPでリロードしてくれたほうがうれしいように思う。

あと、spawn server系を外部から、つまりkillコマンドとかで終了させると、しばらくはエラー表示が出るようになる。しばらくというのはアイドル時間をすぎるあたりまでということだと思うが、詳しくは見ていない。関連して、運用時にはエラー出力用のテンプレートを調整しておいたほうが良さそうだ。そのままバとバックトレースとか出ちゃう。

運用に際してといえば、たとえば高負荷時の挙動だとか、前述のプロセスが予期せず死んだときの挙動だとか、そういった部分での検証は必要ではあるものの、単に動かすという意味ではインストールさえできればわりとすんなりと動いてくれる。Apache HTTPサーバ2.xでなければならず、今のところprefork MPMにしか対応していない(と書いてある)点が少々ひっかかるが、それがすごく問題ということもないだろう。Mongrelなんかよりも手間はまずまず少なくてすむように思える。

もうちょっと調べてみてはいるので、いずれ期会があればまとめてみる気になるかもしれない。が、そんな機会はないかもしれない。メモだけなら簡単なんだけどねえ ;-)

とりあえずインストールだけ。fastthreadがいるらしい。

/usr/lib/apache2/modulesに書き込めることをチェックするわりに、インストールスクリプトを実行しただけではその場所にインストールしてくれないようだ。rake apache2:installで/usr/lib/apache2/modulesにコピーされる。gemでの運用を前提にしてるのかな?

さて、実際どんなことをやってくれるかは…… そのうち見ておこう。

先日、Amazon/Ecsを使ってiCalデータを生成する方法を書いたところ、Flinker.jpというサイトを教えてもらえた。

そんな面倒なことしなくても、 Flinker.jp 使えばいいのに。

[Hexenkesselより引用]

Flinker.jpは自動で検索／更新してくれて、ファンの人が情報の妥当性をメンテナンスしてくれる著作一覧を実現するためのサービスだそうだ。

ざっと見たところでは、Amazonから得られる情報に対して必要な修正をユーザが加え、その結果をユーザ間で共有するというもののようだ。ユーザが登録した著者についての情報を引っぱっているらしい。最近目立つようになってきている検索しにくい名前(ひらがな二文字とか、漢字一文字とか)にも何らかの対応が行われているように見える(検証したわけではないので、実際には違うかも)。

graylistにひっかかってしまったせいで登録が完了しておらず、Flinker.jpの全機能を確認することはまだできていないが「会員登録するとブックマークした著者のすべての新着情報をICAL形式で受信でき」るようになるらしい。Googleカレンダーに登録するリンクもあって簡単そうだ。著者リストを登録しなければならないのは少々気になるが、それでもどんなものか試してみたい。

ところでこのサイト、Ruby on Railsで構築されているのだそうだ。ホント、いろんなところで目にするようになったなあ。

開発環境には、日本製プログラミング言語のRubyを利用したWebアプリケーションフレームワーク、「Ruby on Rails」を全面的に採用しています。

開発スピード／テスト効率性において、大変素晴らしい開発環境です。

[Flinker.jp 初めての方へより引用]

なお、そう思えるような書き方だったかもしれないけれど、他の何かに比べて「そんな面倒なこと」というほどの気持ちはない。トライ&エラーはあったけれど、すごく時間がかかったわけでもないし。ちょっとしたことでもやったことがあるかどうかは違うものだし。それとFlinker.jpではDVDとか任意の検索条件とかに対応しているわけではないようなので…… というと、まあ、他にもサービスはあるのだろうけど。

追記: データのない著者名は登録申請により登録する必要がある。そして短い名前でヒット数が1,000以上だと登録申請できないようだ。残念。

追記(2008-03-21): 実際にいくつか登録申請をしてみたのだが、ヒットしすぎる名前についてのケアは特にないようだった。関係のない本を除外したり、ヒットしない本を追加したりはできるけれど、多数の本がヒットするようだとメンテナンスを続けるのが大変そう。

Mongrel_clusterのmongrel_cluster/recipes.rbをcapfileから読み込ませると、Capistranoのバージョンに合わせてmongrel_cluster/recipes_2.rbが読み込まれるはずのところが、なぜかmongrel_cluster/recipes_1.rbが読み込まれてしまう。

Capistrano::Configuration#requireによるとレシーバがCapistrano::Configurationオブジェクトになるのだと書いてあるっぽいのだが、実際の動作ははそうならず、respond_to?(:namespace)がfalseになった結果として上述のようになるようだ。

とりあえずはmongrel_cluster/recipes_2.rbを直接読み込んでしまえば回避できるのだけど、もう少し追いかけてみたほうが良さそうかな。

たいへんありがたいことにRailsによるアジャイルWebアプリケーション開発 第2版の献本をいただきました。関係者の方々、ありがとうございます。

実は必要にかられて、数か月前に英語版をPDFで購入し、ぼちぼちと読んでいたりもするのだが、読んでみてなおさら日本語版が待ちどおしくなっていたのだった。まだ出ないか、早く出ないか、と待ち続けていた。

同書第1版はRails 0.13ベースだということもあって、現在のRails 1.2.xでは変わってしまっているところがいろいろある。たとえばscript/generateなんてところからしても変化があるわけで、全体としてみると機能面でもずいぶんと変わっている。そういうわけで、Railsのソースをバリバリ読んでしまうような人は別としても、多くのRailsユーザ(特に1.2.xのユーザ)にとっては(改めて)第2版を手元に置いておく価値が十分にあるだろうと思う。

ところで、あまり関係ないのだけど、最初のおどろきは薄さだった(紙一枚一枚の薄さね)。第1版から厚さすえおきなのに100ページ増なものだから、うわっ、と :-)

Rails 2.0が近付くなか、1.2.3の(ごく一部の)コードを読んでみたときのメモを置いときます。

メモのままで、編集的なことはまったくやっていないのでかなり読みにくいと思う。動作検証をあまりしてなかったりするし(してるところもある)、思い込みとか間違いとかいろいろあると思うのでコメント歓迎——といっても基本的に自分以外が読めるものじゃないので無茶言ってる感じもしますが。ま、読んでもらえるようならってことで。

あ、あと、RD形式だけどrd2通らないと思う。

気が向いたらまた更新するかも。

backlogに負けぎみなのは置いといて、ActionBoxとTracksをほんの少しだけ試してみた。これらはMySQLでもすんなり動く。

ActionBoxを動かすためにはHatena::API::Authが必要で、Hatena::API::AuthにはJSONライブラリが必要だった(後者はlibjson-ruby1.8を使った)。あとは通常通り、config/database.ymlを書いて、rake db:migrateして、アクセスすればOK。

ただ、サービスサイトでもそうだったんだけど、手元のLinux上のFirefoxからは操作メニューが下にずれてしまっていて、白地に白字になってしまう。うーん、最初のタスクを入れたはいいが、そこからどうすりゃいいんだろう、などとしばし悩んでしまった。Safariだと問題ない。

Tracksは昨年からリリースされてないので止まっているのかと思ったらリポジトリではバリバリ動いているようだった。こちらはconfig/database.ymlを書いて、さらにconfig/environment.rbを書いてからrake db:migrateをする。両ファイルともサンプルがあるので、それを使うとよい。

久しぶりに動かしてみると(trunkでは)いろいろ強化されている様子。UTF-8だけどモバイル用のビューがあったり、ステータスを表示するためのflashを生成してくれたり(生成処理がすっごい重いけど)。

どちらもマルチユーザ対応なのだけど、ちょっと見た感じではユーザ間でタスクを共有するとか投げ合うとか、そういう機能はないみたいだった。この点ではbacklogが良さそうか(MySQLで動かしたいなあ)。

おっ、いよいよ来月か: RailsによるアジャイルWebアプリケーション開発 第2版