どこで何が確認できるか分かってないと結構つらいので。
差し込み口
- C の action 前後の filter ( before_filter, after_filter, around_filter )
- M の validation および create/save/destroy 前後の callback ( create, update, destroy は around もある )
- さらに M の after_initialize, after_find などにも
ここに処理を挟み込むことで C や M のロジックを複雑にしないでデバッグのためにアレコレ仕込んで確認することができる。
cf.
- Ruby on Rails Guides: Action Controller Overview
- Module: ActiveRecord::Callbacks
- Ruby on Rails Guides: Active Record Validations and Callbacks
Controller
- verify
- filter ( before, after, around )
- after は action の実行後、つまり全体では
before_filter
def action; end
after_filter
となっており、before_filter が走る段階で routing などは終わっている。
vefiry は文字通り vefiry しかできないので、処理を挟む余地はない。ただし model の validate をまたずに弾き返すことができるのでたぶん速い。（特殊な before_filter らしい。）
around_filter は before と after および実際のアクションの間に実行される。
- before_filter
- around_filter1
- around_filter2
- def action; end
- around_filter2
- around_filter1
- after_filter
の状態になる。
Model
結構たくさんある。順番に
- before_validation
- before_validation_on_#{CRUD}
validate
- after_validation
- after_validation_on_#{CRUD}
- before_save
- before_create
create ( だけじゃない )
- after_create
- after_save
action が走らないと Model Object は生成されないので、validate の実行タイミングは action の後というか action の中。
確認方法
- rails console で主に model の method の確認
- rails server を立ち上げた terminal で次々に起こることを目視する
- p でそこに情報を吐き出す。(これはログには落ちない)
- とても伝統的。rails server を実行している console に表示される。
- V なら debug を使う
- logger の設定を default から変更して logger インスタンスを起こす。この logger に必要な情報を吐き出す。
- debugger を起動する
1 の rails console はすごく好きなんだけど web server が動いているわけではないので request を扱うことはできない。form の作り方間違えて validation のタイミングでちゃんと値が渡ってきてないんじゃないかしらと思ったら
class Controller
before_filter do
debugger
end
end
とか
class Model
before_validation do
debugger
end
end
しておくと自由に確認できる。単に目視できればいいだけなら p でもいいけど、development のログは結構詳細に出るので簡単に流れていってしまう。多少面倒でも logger か debugger を使うとよい感じ。
4 の debug は Typus の中だとあまり機能しないような気がするので、V ならいつでも debug できるとは思わない方がいいみたい。
5 の logger の設定は思っていたより面倒だった。
6 の debugger は強力なんだけど、いちいち break してしまうのが面倒とも言える。
continue
すれば復帰できるとは言え。
logger の設定と使い方
こんな感じ。
config.logger = Logger.new( File.join( Rails.root,
'log',
"#{Rails.env}.log" ) )
config.log_level = Logger::DEBUG
を config/environments/development.rb に追加した。使う時は
logger.debug( object.to_s )
みたいな感じで。
log_level を上げればいいだけかと思ってたんだけど、なんかどうもできないっぽい。
debugger の設定と使い方
Gemfile に ruby-debug(19)? を追加
group :development do
gem 'ruby-debug' if RUBY_VERSION < '1.9'
gem 'ruby-debug19' if RUBY_VERSION >= '1.9'
end
で、
- rails server -u ( –debugger ) でサーバを起動
- 好きな場所に debugger と書いて止める
cf.
Ruby on Rails Guides: Debugging Rails Applications
request parameters を確認する
request parameter は rails console では確認できないので、今回紹介した console 以外の方法が生きる。
- request parameter を確認するなら C の before_filter で params を見る1
- request 全体は request メソッド
- params は request.parameters, request.headers.parameters の alias
- jpmobile 環境では request.parameters が変更されていて、オリジナルは request.parameters_without_jpmobile
- request.parameters は Http::Parameters オブジェクト
- ヘッダは request.headers
※ 脱線だが request に適用できる filter は request.methods.filter に出てくる parameter_filter, env_filter, parameter_filter_for 辺りか？
こうすると無駄な処理が動かない ↩
ちょっと気になって調べてみた。
| ruby | rss |
| 1.8.5 | 0.1.6 |
| 1.8.6 | 0.1.6 |
| 1.8.7 | 0.2.4 |
| 1.9.0 | 0.2.4 |
ちなみにこの標準添付の rss モジュールは 0.1.8 で atom に対応しているらしい。ということは 1.8.6 以前のバージョンの Ruby で atom を処理したければ別途何かをインストールする必要があるということですな。
cf.
数分や十数分ほど時間が空くときってあると思うんですが、このとき下手に集中を要する作業を始めてしまうと、気づいたときには使える時間をオーバーしてることがありませんか？ 私はあります。例えば湯船を溢れさせちゃったり。
どうにかなんないかなと思いましたがハタと思いつき、terminal で以下のように打ちました。
sleep 300 && growlnotify -s -m '風呂'
これでちょっとの間で twitter や feed、メールのチェックが可能です。
そして読みすぎる心配もない。うむうむ。いい感じ。
Windows でも同じような要領で使える便利ツールないかな。
[2009-03-28 追記]
そうかこれはライフハックなのか。
ports では CGI版と mod_php版が併用できないので別な機械で実験。（すでに mod_php で動いているので。）
結論としてはとりあえず動かすだけならとても簡単。ports で入れたからかどうか分からないけど、lighttpd の設定ファイルに PHP を fastcgi で動かす場合の設定がコメントアウトされた状態で入っていたので、それを外しただけで動いてしまった。
しかも拡張子との関連づけで実行するバイナリが決まっているので
- permission にルーズでいい
- shebang を書かなくていい
という mod_php でのメリットがそのまま生きる。ステキ。肝心の速さはまだよく分かっていない。とりあえず phpinfo を出してみただけ。
PDF reDirect 便利そうだなぁと思いつつ、探してみる。
PDF結合 （ぐだぐだ日記）
なるへそ。
PDFLab 使ってみた。結合した PDF を生成する前に PDFLab 上でプレビューを見れないのがちょっと残念かなぁ。機能的にはそれ以外はあんまり不満はなさそう。（本当はしおりの機能がほしいんだけども、まぁ置いておこう。）
NeoOffice も Pages も表の罫線を破線にできないんだけど、こういう需要ってあんまりないのかしらん。線の太さも 1pt からって太すぎるんだよなぁ。
なんつーか、CSS の方が細かく制御できるじゃんと思う時代がくるとはちょっと想像してなかった。
- デスクトップPCとノートPC、本当に必要なのはどっち？ @ITmedia アンカーデスク
- Linuxか、Windowsか @ただのにっき
近いと感じているのでメモ。自分は基本的にモバイラーでノート歴はすでに、、、えーと、そろそろ10年くらいになるはず。基本的にはメインマシンは B5 12" な状態がもう何年も続いている。
1台よりも2台の構成の方が有利な点は多いと思う。冗長性もあるし、長時間高負荷になるような処理でも2台あればもう1台で他の作業を継続できる。バックアップも HDD to HDD の方が楽だし、これを DVD なんかに焼くときも待ち時間を最小にできる。
このとき、1台はモバイルノートであるというのが、個人的な趣味で確定しているんだけど、その OS はと問われればプロプラな OS でいいと思っている。いや、デフォルトで入っている OS を消して Un*x に入れ直す手もあるんだけど、たいていモバイルノートの場合はプロプラな OS でないとダメな部分が残る。例えば TrackPoint のドライバだったり、省電力機能なんかがそうである。これが譲れる部分ならよいが、譲れない部分だったらお手上げである。また、Un*x の作業環境を整えるのは、伝統的な構成のマシンに比べて新しいマシンの方が難しいし、デスクトップよりノートの方が面倒なことが多い。技術が枯れていないという表現がよく使われるが、要するにモバイルノートは枯れていないのだ。
またサーバ寄りのスキルの方がより多くのマシンの作業環境に影響し、長くノウハウが通じる傾向がある。だから自分のマシンの設定に一生懸命になるよりも、同じ時間でできるならサーバ寄りの方が、少なくとも今の自分は楽しい。（クライアントサイドについてはとりあえずやりたいことはもうできているので。これがサーバ側も一通りやりたいことができるようになったらまたクライアント側に戻ってくるんだろうけど。）
まぁこう思えるようになったのも MacOS がまともな Un*x ベースの OS になったり、cygwin の完成度が上がったからなんだろうけど。実際、今は選択肢も多く、かなりいい状態にあると思う。
openldap の portinstall の間にメシを食ったらすっかりやる気がなくなり、とりあえず手元のアプリを上げてみることにしてみた。（openldap 用に cvsup したのでついでってことで。）
まずは pukiwiki を cvs update. （すでに checkout 済みなので。）そっからちまちまと自分の環境用にファイルをコピーして設定ファイルの書き換え。途中まともに PukiWiki を見れない時間帯も数十分あったんだけど、構うことなしに作業継続。説教講座本番サーバじゃないし、気楽にエラーメッセージ垂れ流しまくり。
openssh は確認したら最新になってたのでなんとなく不満。（なんでだ。）
screen が 4.0 のβになっててこれがずっと起動時にエラーを出してたので 4.00.02 にする。起動時のエラーが出なくなった。
Apache 1.3.27 → 1.3.29 は 1.3.27 を portinstall じゃなくて pkg_add で入れたので予想通り失敗。例によって /var/db/pkg 以下の pkg_info を強制的に削除してから portinstall. apachectl restart は失敗したので改めて apachectl start で。オーケーオーケー。Windows と違って動いてるアプリをガリッと上書きインストールできるって分かってるとストレスなくていいな。システムの再起動も当然不要だしね。
つーかシステムを上げるって話はどこ行った。（実は 5.2.1 待ちだったりするんだな、これが。）
LDAP の管理者ガイドを読みながら調べものをしていたら ldapdns つーものの存在を知る。どうせ LDAP はそのうちマスターする気なので、この djbdns をベースにしているらしい ldapdns は管理しやすさやパフォーマンスを考えるとかなりいい選択肢のような気がしてきた。
家庭内 LAN 用 DNS としてはちょっと大げさかもしんないけど、数百台クラスの社内 LAN 用なら悪くなかんべ。