Notesontestabletdiary

testable ブランチの作業のメモ

tDiaryとcgiとrackについて

• rack-legacy は、cgi をそのままRackで実行するためのライブラリ
• rack の cgi mount は、rack アプリを cgi上で動かすためのハンドラ

tdiary のtestableブランチは、現状そのいずれでもない。rackアプリにはなってないし、cgi をそのままrackに載せたいというわけでもない。 rack_legacy で cgi を動かすという作戦はあっても良いかもしれないけれど、それだとユニットテストは書きづらいままなので、testableの目的には反してしまう(まあ、tDiaryをrackに載せたいというだけなら rack_legacy で動かすのを試すという作戦はあるかもしれないけど)

rackに載せると夢が広がるんだけど、testable ブランチの目的そのものは、文字通り tDiary をテスト可能な設計に変えていこうというものなのなので、地道に cgi と rack の両方で動くようにしていくつもり

ちなみに「tDiaryを完全にrack対応した」といえるのは、本体とプラグインが @cgi を使わなくなったときかな。ENV についてはまだよくわかんない。使わなくて済むようになるならそうしたいけど(ENVはテストしづらいので)

testable の今後の作業

TODO

• 簡単に速度を比較できる仕組みを準備しないとなあ(まずは手動でもいいけど。xibbarさんのcgi.rbのabでの速度比較みたいなやつ)

(TDiary::Requestを導入したら)

• configと各commandに @cgi と request を渡すようにする
• dispatcher.rb から @cgi を消したい
• index.rb と update.rb からも @cgi を消したい
• config で @cgi をつかっているところを順次置き換えていく
• dispatcher.rbを整理整頓する(どうするのがいいのかな)
• 他、奥のほうにどんどん進んでいって @cgi を request に置き換えていく(ここはUnit Testが必要)

WIP

• [WIP] TDiary::Request (Rack::Requestっぽいもの)を導入する
  • Hikiのrackブランチからパクる
    • Sinatra からパクって、Rack::Request を継承してはどうか（vendorにrackを入れた上で）
  • TDiary::Application側では簡単そう
  • index.rb と update.rb で(あるいはいdispatcher.rb で?) 、CGI から TDiary::Request への詰め直しが必要な予感(遅くならないか?)

DONE

• TDiary::Response (Rack::Responseっぽいもの) を導入する

メモですよメモ

動作確認のしかた

• rake spec は rack な環境を想定して走っているので、cgi 環境での動作は確認できないので注意(初歩的なミスぐらいは検出できるよ)
• standalone_cgi は webrick の cgi handler をつかって index.rb と update.rb をマウントしてるけど、基本的な動作確認ぐらいかなあ
  • Apache の cgi と動作が同じが確証をもてない……。fcgi についても同様。

テスト書いてないぞ!

• HTTP Headerのテスト(一部はcapybaraのdriverをRack::Testじゃなくてseleniumとかにする?)
• Cookieを使ったテスト

備忘録

• index.rbとupdate.rb と同じディレクトリに置いてつかうプラグインどうしよう ( trackback とか)
• fcgi ってどうなるんじゃろ(さっぱりわからん)
• ディレクトリとかのファイル構成を整理したいのう
• クラウド化に向けたI/Oの抽象化は(個人的には)ちょっと脇に置く(興味あるけど)
• CommandたちとConfigがいろいろやりすぎている気がするので責務を整理したい(とにかく単体でテストしづらい)

ITSに登録する?

• tdiary-theme を、tdiary-core/theme の下にコピーしないでも使えるといいんだけど。sp.path みたいに複数設定できるといいんだけど。