Turbogearsを仕事で使った感想

詳細は企業秘密で書けませんが、うちはWEBを作ること自体が仕事ではないのでWEBの技術に関する部分だけはあまさずメモしておきます。
何をどう配置しようかという考えをめぐらせた部分も書いています。

== 背景 ==
最近自分が会社で、コマンドラインから起動するタイプの、とある分析ツールを作った。
* 元々これはある一人の分析担当者のために作ったものだった
* が、これを他の複数名の担当者でいくつもの案件で使いたい。
* これまでのように自分が依頼を受けてコマンドを打って結果を一つ一つ提出するのでは間に合わない。

そこで、この分析ツールをWEBから使えるようにしよう。

== 束縛条件 ==
* 分析の入力は数千行のCSVやタブ区切りファイル複数。（ファイルアップロード機能がいる）
* ユーザーごとに入力データを保持しておき、複数回の分析で使いまわす。
* 分析ツールでの分析は数秒～数分。将来複雑な分析を増やすなら数時間もありえる。

== 使用する技術 ==
* すでにある分析ツールはPython製。

* 画面はTurbogearsで作ろう。
　　* DBはMySQL。SQLAlchemyでDAOを作ろう。
　　* モデルの操作はtgcrudで生成。
　　* ユーザー登録はregistrationで生成。

* 分析ツールはどうしよう。。。
　　* 分析ツールの起動から終了まで、ブラウザの画面で待たせるわけにはいかない。
　　* しかも同時に10も20も分析ツールのプロセスが動くのはマシンの負荷上まずい。
　　* WorkerThreadパターンを使おう。
　　* 処理が終わったらユーザーにメールで結果ファイルを送ろう。(参考資料)
　　* そんなマルチスレッドの時間がかかる処理をTurbogears上で行っていいの？
　　* よく知っているPyroでTGとは別プロセスにしてWorkerThreadをまわすようにしよう。
　　　(PyroはRubyで言うところのdRuby相当の分散オブジェクト環境構築ツールです。）

== 参考にした資料 ==
（前節で挙げたもの以外）
* TGでのファイルアップロード入門
* Pyroのサンプルプログラム（Pyroはこの最初の例をまねるだけで十分！）

== はまったとこ ==
Turbogears-1.0.2.2で最初作って完成させ、それをTurbogears-1.0.3.2で動かしたら、SQLAlchemyのMany-To-Manyで結びついているレコードの生成がうまくいかない部分があることを発見した。
おそらくなんかのバグが潜んでいそうなので、それを明らかにする簡単なコードを書いて調査しようと思う。

SQLAlchemyのどこかのサンプルを写して、lazy=Falseを指定していたが、これはいつでもjoinするという意味だそうだ。（Eager Loading)これをTrueにしたら、レコードの一覧表示が速くなった。

さらに、一覧表示画面が遅くなる原因として、Mapperが毎回全てのフィールドをDAOに取得してきているというものがある。これを防ぐにはSQLAlchemyのMapperのオプションでdeferred設定をするとよいことが分かった。
これを指定すると、特定のフィールドの値を、必要になったときだけDAOに格納してくれるようになる。

== 成果、感想 ==
昨日の夕方に作業を初め、今日の夜には一通り動くものができました。
（もちろん夜は早めに自宅に帰って次の日の昼過ぎに（遅刻して）出社しました。同僚のみなさんすいませんでした。）

その間、会議や各種ミーティング、過去に作ったJAVAのプログラムのバグ修正などもあり、今回のWEB作りだけに集中していたわけではありません。
Pyroには慣れていたのですが、TGはそうでもないので、いろいろ資料を調査しながらの制作になりました。
そんな状況なのに、一通り出来上がってしまって、自分でもとても驚いています。

明日以降は、
* セキュリティ関係の入力値チェックを実装する。(社内ツールとは言っても、やらなければ）
* マスターデータの運用体制、運用スクリプトを作る。
* 担当者とのレビュー作業。
* インストールマニュアル、操作マニュアルなどの作成。
というやや重い作業も残っています。

自分はここ数年WEB開発から離れていました。
数年前はMVCのフレームワークと言ったらStrutsぐらいしか普及しておらず、自分はわりと生のPHPでガリガリ書いているタイプの開発者でした。
そういうWEB開発に造詣のあるわけではない開発者でも、こうして簡単に業務に使えるレベルの画面を作れるとは、ほんとうに開発技術の進歩はすごいと思いました。