backlogをMySQLで動かしてみる
GTDなツールであるbacklogを試してみようと思ったところ、PostgreSQLでの利用を想定しているようでちょっと困った。
困ったといえばgemでインストールするんだー!とドキュメントにあるのだけれども、当然gemスペックはruby-postgresに依存するよう書かれていたりする。でもって、そのgemをインストールしようとするとヘッダファイルが見付からないよエラーが出る。extconf.rbに--with-pgsql-include=/usr/include/postgresqlを加えてやればいいだけなんだけれどなあ。gem的にどうするのが正しいのかよくわからないけれど、gemspecのs.extensionsを%w{extconf.rb}から%w{gem_extconf.rb}に書き換え、gem_extconf.rbをsystem 'ruby', 'extconf.rb', '--with-pgsql-include=/usr/include/postgresql'という内容で作成してgem buildし、できたgemをローカルでインストールした。
同じような話が、やはり依存gemであるrmagick gemでもあって、こちらはなにがなんでも/usr/share/RMagickにHTMLドキュメントを書き出そうとする。当然のごとくgemのインストールに特権なんて使っていないから書けなくてエラーになる。出力を先を何かで指定できれば…… というよりも$GEM_HOME/doc以下に書き出すのがスジなんじゃないのかと思ったりもするのだが、gemの中身を見てまわったところgem install時に--no-rdocを付ければHTML出力をしなくなることが分かり、そのようにした(--no-rdocっていうのもどうなんだ……)。
ともあれbacklog gemのインストールはできたので動かそうとして、ドキュメントにある通りbacklog setup_unixを実行した。するとsuが動いてパスワードの入力を求められるではないか。
まあ、ドキュメントにもsudoを使えみたいな感じで書いてあるのでそういうものなんだろうけれども、ちょっと試すのにそれもイヤなんでスクリプトを見てみた。内容はPostgreSQLのデータベースを作ってうんぬんという感じ。PostgreSQLを動している環境ではないので(というか、ここら辺でPostgreSQLしか想定していないぽいことに気付いた)それはいただけないなと手動でセットアップしてみることにした。
config/environment.rbをMySQL用に設定して、rake db:migrateを実行する。と、エラーが。どうも外部キー制約まわりの扱いの違いによるらしくMySQLのerrno 150なエラーが出てしまう。あれやこれやを試してみて、あっているのかどうか分からないがMySQLでdb:migrateするためのパッチをでっちあげ、ともかくdb:migrateが最後まで動くところまでこぎつけた。
それではscript/serverで動してみて、アクセスしてみる、と、……一応動いているっぽい。ドキュメントにあんまり記述がないのでよく分からないのだけど、管理者的なものはないのかな? 誰でもアカウントを作れて誰でも使える? トップページからアカウントを作って適当にいじってみたが、なんとなく動いているっぽかった。もう少しいじってみるつもりだったんだけど、ここまでくるのにだいぶ疲れたので、続きはまた今度。
追記: スクリーンショットでもとってみるかと、もう一度アクセスしてログインしようとしたらエラーになった。やっぱ場当たり的な対処じゃダメかなあ。パッチは間違っているかもしれないけど、一応残しときます。
「Railsのセキュリティ」 2
WASフォーラム第五回カンファレンスで前田さんが担当された「Railsのセキュリティ」のスライドを読んだ。おもしろい。
スライドの90枚目「protected」に「多くのRailsコードは間違い」とあるのだけど、これってどういう話だったんだろう。
mod_ruby on rails
Rails 1.2.3をmod_ruby 1.2.6で動かしてみようとしたところエラーがいろいろ出たのでその記録を少し。前提として、Railsはrails.debを使った。
まずApache HTTPサーバ側の設定について。これは、前田さんの日記やapache/rails-dispatcher.rbにある通りにした。RubyGemsを使わないのでRubyRequire rubygemsは不要。
RubySafeLevel 0
RubyRequire apache/rails-dispatcher
Alias /foobar/ /path/to/foobar/public/
<Directory /path/to/foobar>
AllowOverride All
SetHandler ruby-object
RubyHandler Apache::RailsDispatcher.instance
RubyTransHandler Apache::RailsDispatcher.instance
RubyOption rails_uri_root /foobar
RubyOption rails_root /path/to/foobar
RubyOption rails_env development
</Directory>
さて、これでinvoke-rc.d apache2 reloadするどうなるかというと、こうなった。
[error] mod_ruby: failed to require apache/rails-dispatcher [error] mod_ruby: error in ruby [error] mod_ruby: /usr/lib/ruby/1.8/apache/rails-dispatcher.rb:50:in `require': no such file to load -- initializer (LoadError) [error] mod_ruby: from /usr/lib/ruby/1.8/apache/rails-dispatcher.rb:50 (略) [error] mod_ruby: (eval):50: (eval):50: uninitialized constant Apache::RailsDispatcher (NameError) [error] mod_ruby: from (eval):50:in `value'
apache/rails-dispatcher.rbの中のrequireでコケている。それもそのはず、同ファイルではRails関係のライブラリを読み込もうとしている。実はこれはRubyGemsのRailsを使っていれば問題にならないのだが、なんだかそれもなあって感じなので回避策をとる。以下を設定に加える。
RubyAddPath /usr/share/rails/actionmailer/lib RubyAddPath /usr/share/rails/actionpack/lib RubyAddPath /usr/share/rails/actionwebservice/lib RubyAddPath /usr/share/rails/activerecord/lib RubyAddPath /usr/share/rails/activesupport/lib RubyAddPath /usr/share/rails/railties/lib
invoke-rc.d apache2 reloadをかけてエラーが出ていないことが確認できた。それではアプリケーションにアクセスしてみると、こうなった。
[error] [client 127.0.0.1] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
ははん。public/.htaccessでRewriteEngine Offにしておく。再びアクセスしてみる。と、今度はこうなった。これはRailsのログ。
NoMethodError (undefined method `recognize!' for #<ActionController::Routing::RouteSet:0xb65d4e98>):
/usr/lib/ruby/1.8/apache/rails-dispatcher.rb:152:in `dispatch'
内部のメソッドが変更になったというか、recognize!がなくなったようだ。これはapache/rails-dispatcher.rbの当該行のrecognize!をrecognizeにすれば回避できそうだ。で、次。
DEPRECATION WARNING: server_settings has been renamed smtp_settings, this warning will be removed with rails 2.0 See http://www.rubyonrails.org/deprecation for details. (called from send at /usr/lib/ruby/1.8/apache/rails-dispatcher.rb:203) DEPRECATION WARNING: server_settings is deprecated and will be removed from Rails 2.0 (It's now named smtp_settings) See http://www.rubyonrails.org/deprecation for details. (called from send at /usr/lib/ruby/1.8/apache/rails-dispatcher.rb:237)
こんなのがApache HTTPサーバのエラーログにたくさん記録される。今のところ実害はないのだと思うのだけど、うるさい。いまいちうまい回避方法が分からないのだけど、こんなことをしてみたところエラーが記録されなくなった。ただ動作に影響がないかどうか、いまいちこころもとない。
--- rails-dispatcher.rb.orig 2006-10-18 02:14:11.000000000 +0900
+++ rails-dispatcher.rb 2007-06-20 13:34:40.000000000 +0900
@@ -217,10 +217,11 @@
def self.get_configuration_methods(target_class)
re = Regexp.new("\\A(" + NON_CONFIGURATION_METHODS.join("|") + ")\\z")
- return target_class.singleton_methods.collect { |m|
+ methods = target_class.singleton_methods
+ return methods.collect { |m|
m.slice(/(\w+)=\z/n, 1)
}.reject { |m|
- m.nil? || re.match(m)
+ m.nil? || re.match(m) || methods.include?("#{m}_without_deprecation")
}
end
ここにきて、ようやく、ていうほどでもないかもしれないけどHello World!的アプリケーションの動作が確認できた。よかったよかった。mod_rubyのMLに投げとこう。
ところで、設定をあれこれ変えている途中で以下のエラーにしばし悩まされたことがあった。
[error] mod_ruby: error in ruby [error] mod_ruby: /usr/lib/ruby/1.8/apache/rails-dispatcher.rb:102:in `file?': Insecure operation - file? (SecurityError) [error] mod_ruby: from /usr/lib/ruby/1.8/apache/rails-dispatcher.rb:102:in `handler'
もちろんRubySafeLevel 0は書いている、のだがなあと、しばし。気付けば単純なことで、<Directory>や<Location>などの中での設定を記述した後の、メインサーバ部分に書いていたのだった。こうしてしまうとディレクトリごとの環境が先に作られてしまい、その中の$SAFEがその時点でのデフォルト値で設定されてしまう。デフォルト値というのは1であり、設定後にメインサーバでの値、つまりデフォルト値を変えてみてもしょうがないというわけ。たまにやるApache HTTPサーバの設定でよくひっかかる。
ついでにRubyGemsのことを少し。RubyGemsをシステムレベルで使いたくないっていう人は少なくないわけで、限定的に使用するためにGemホームを別の場所に作って運用するということがしばしば行われる。そういったとき、通常は環境変数GEM_HOMEにその場所を設定して運用する。ところが、mod_rubyのRubyRequireを使おうとすると、その種の回避策がとりずらい。というのもRubyRequireでスクリプトが読み込まれるのはmod_rubyの初期化時だからで、RubyPassEnvやPassEnvなどで渡そうとしてもうまくいかない。何か手はないかとmod_rubyの初期化ハンドラを書いて〜とかいうのも考えたが、結局はENV['GEM_HOME'] = '/path/to/gemhome'とだけ書いたスクリプトを用意し、それをRubyRequire rubygemsよりも前にRubyRequireしてしまうのがお手軽なんじゃないかということになった。
追記(2007-06-26): mod_rubyへのパッチは両方とも取り込んでもらえた。さてさて、もう少し遊んでみるか。
追記(2007-07-26): mod_ruby 1.2.6のapache/rails-dispatcher.rbはネストしたクラス・モジュール定義に対応していないので、たとえばEnginesを使おうとするとエラーになるみたい。これは上述の問題とはまた別の話で、すでにtrunkでは修正されているようなので、trunkから同ファイルを持ってきて置き換えるのが良さそう。修正されているのに気付かずに1.2.6上でデバッグしてしまった。
追記(2007-08-02): 単純なテストでは分からなかったのだけど、gemを使っているなど、いくつかの条件の下ではうまく動作しないことがあるみたい。時間をとれたら追いかけてみようかなと思っているけど、とれるとしてもしばらく先になりそう。
CruiseControl.rbを試す
各所で見掛けたCruiseControl.rbを試してみた。
といってもtarballを展開してcruise addやった程度で動いちゃったんだけど。いや、最初、w3mでアクセスしようとしてて、同梱のRailsが1.2系で、やっぱり406にひっかかったんだった。どうしたものでしょうねえ、とは思いつつも適当に回避してしのぐだけにした。
project.build_commandあたりの設定をもう少し柔軟にできると良いなとか、プロジェクト間で依存関係を設定できると面白そうだなとか、出力に対する整形なりフィルタなりがあると良いなとか思った。
tracみたいなツール
Ruby on Railsで書かれたtracみないなプロジェクト運営ツールを二つばかし試してみている。retrospectiva(r121)とdevalot(rel/0.1)。Colaboaの開発が再び行われるようになっているらしいのだけど、今回は試さず。
retrospectivaはtracにblog機能をくっつけた感じ。trac的マクロとかそういうのはないかもしれない(まだそういうとこまでは見てない)。最初、MySQLの encoding関係の設定をする前にデータベースとか作りはじめちゃったせいで文字化けに悩んだけど、それ以外はすんなり動いてくれた。
devalotはまだsvnサポートがないし検索もない。マイルストーンとかもない。よって機能的にはretrospectivaよりも見劣りする。ただ、Point Based Moderation Systemとかちょっと面白げな機能もある。こっちもすんなり動いてくれたが、migrateした後でscript/setupを動かすのを忘れてて一分ほど悩んだ。
ちょっとさわってみた感じだと、機能面をおくとしてもretrospectivaのほうが良くできてる。devalotはたとえばwikiなんかのプレビューがなかいとか、ちょっと不便。その一方でajaxっぷりはdevalotのほうが進んでいたりする。ま、現時点ではretrospectivaだろうなあという印象。devalotはこのまま開発が続けば面白いものが出てくるかもなって気はするんだけど、やっぱりまだまだかな。
retrospectivaの問題を挙るとすると、blogやwikiの標準スタイルがtextileもどきっだっていう点。たとえばリンクの書き方とか日本語には、というよりも空白区切りのない言語にはいまいちなじまないんじゃないかと思う(空白区切りを強制される)。Markdownとかも使えはするんだけど、サポートに消極的っぽい感じもあるようで、その辺がひっかかる。
Rails 1.2.1とw3mの組み合わせで406エラー
scaffold_resourcesしてできたコードをscript/serverで動かして、w3mでアクセスすると406なレスポンスになるような。
Accept: text/*に対応するMIMEタイプの処理が登録してないからのよう。Mime::Type.register "text/*", :text_allとかやっていちいち書くのがスジなんだろうかと思いつつ、:htmlへの指定を上書きしてみたり、Mime::HTMLの@synonymsに"text/*"を加えてみたりしたんだが、これだとContent-Type: text/*なレスポンスが返ってくるという。
結局、下のようにしてみたんだけど、うーん、何か呪文があるだろうか? (そもそも何か勘違いしてそうな気もするんだが……)
Mime::HTML.instance_eval { @synonyms << "text/*" }
Mime::LOOKUP["text/*"] = Mime::HTML
Web家計簿小槌を動かしてみる
ふと思い立って、RailsアプリケーションであるWeb家計簿小槌を動かしてみた。ドキュメント類がうまく見付けられなかったので、こんな感じかなーとさぐりながら。
まず、コードを入手する。配布物があるかどうか分からないがSubversionのリポジトリがあるのでその中のtrunkから取り出す(tagがふってあるのでそっちから取ったほうが良いのかもしれない)。このときのリビジョンは1063であった。
$ svn export http://svn.labs.drecom.jp/aor/kozuchi/trunk kozuchi
次にconfig/database.ymlを環境に合わせて編集する。手元ではMySQLを使うように設定した。
続いてconfig/environment.rbを編集する。特にLoginEngineで使うメールアドレスを変更しておく。:saltも変更しておいたほうが良いのだろう。
module LoginEngine config :salt, "ここ" config :email_from, "ここ" config :admin_email, "ここ" ... end
データベースの初期化を行う。migration用のファイルがあるが、今のところは準備中という感じのようであるのでdb/schema.sqlを用いることになる。ただし、その内容もMySQLに合うようにはできていないのでMySQLでエラーにならないようにする程度の変更を加えてから実行した。
$ mysql -u user -p database < db/schema.sql
LoginEngine用のデータベース設定もしておく。
$ rake engine_migrate
準備はこれでできたのだが、ユーザ登録直後に「高度な設定」をしようとするとエラーになるようなので手元では回避策をいれておいた(エラーにならないようにしただけなので正しいかどうかは分からない……)。その上でサーバを起動する。
$ ruby script/server
http://localhost:3000にアクセスしてユーザ登録画面に移り、必要な情報を入力して登録申請すると、先程設定してメールアドレスからメールが飛んでくる。それを受けて登録を済ませると家計簿に記録できるようになる。
グラフを描かせたい場合にはもう少し設定が必要となる。まずgdchartをインストールする(RAAにあるruby-gdchartではない)。gdchart-0.0.5.tar.gzを入手し、展開し、setup.rbを使ってインストールする。システムにインストールしない場合には$RAILS_ROOT/libにでも置くようにする。
$ tar xvfz gdchart-0.0.5.tar.gz $ cd gdchart-0.0.5 $ ruby setup.rb config --rbdir=$RAILS_ROOT/lib --sodir=$RAILS_ROOT/lib $ ruby setup.rb setup $ ruby setup.rb install
gdchartから使用するフォントファイルはハードコードされているので、必要に応じて変更しておく。app/controllers/graph_controller.rbのGRAPH_TT_FONTである。
class GraphController < ApplicationController GRAPH_TT_FONT = '/usr/share/fonts/truetype/vlgothic/VL-PGothic-Regular.ttf' ...
まだちょこっと動かしてみただけだけど、複数ユーザのデータをさばけることもあって、ユーザ間の関係を作れるようになっているのはなかなかおもしろそう。ぱっと思いつくところでは予算設定できるようになっているとよいかな、と思う。あと備考というかメモを入れられるようになっているとよいかな。
コード側にはラインセンスの記述がないのでちょっと躊躇したのだが、アワードのサイトを見るとGPL2となっているのでそうなんだろう。ここ数か月は動きがないようなんだけど今後も開発は続けられるのかな。続いてほしいな。
Ruby on Rails入門—優しいRailsの育て方
出版ラッシュと言えなくもない状況になりそうなRails本。数ある中からAr-さんのおすすめにしたがって
優しいRailsの育て方を購入しておいた。実際に読むのはしばらく先になるだろうけど手元に置いておきたいなと。
購入した書店の店頭ではRails本たちが並んで平積みになっていて、他方、某Debian本は影も形もなく…… うう。
追記(2006-08-21): Ar-さんのおすすめ → ARAKI notes
追記(2006-08-25): もうちょっと読むのは先になるはずだったのだけど、ざっくりとだけ読んでみた。その印象はAr-さんの記述と同じ。実用的な内容になっていると思けど、その分、この本が最初に読むRails本だとするとちょっと手強いかも。前田さん監訳の本を読むなりチュートリアル的なものをいじってみるなりして、おおまかにでもよいからRailsの雰囲気をつかんでから読むと入りやすくて良いと思う。もっとも、私自身はうんと前(1.5年くらい前?)に他の人が作ったRailsアプリケーションをいじったことがある程度なので、「この本を最初に〜」とはいってみたけど、まあ、そういった程度での印象。
