開発進捗（05/27）

mechanize遊びばっかりやってました。
よく調べてみたら、リクエストを出せばgreeの掲示板のコメントは削除できたので、
あんまりjsonは関係ありませんでした。
（コメント削除の結果はjson形式で帰ってくるのですが、あんまり意識する必要はない漢字でした）

本筋のMTG-Guildsのほうは、さっぱりですが、
Wikiの仕様を一部取り込むとメニュー処理を標準化できそうなので、
その方向で検討中です。

・・・いいから、セッションを早く実装しよう。

開発進捗（03/28）

いちおうハンドラを再入可能にしてみた。
要はインスタンスに変数を保存するとダメなんですね。固定部分のみ保存して、それ以外は、request か BigTable か memchachから取得しないといけない。

なんのかんので がんばっていろいろ最適化したところ、スピンアップは100ms～300ms（cpu_msは50くらい）くらいになった。このハンドラを使って、身内用の災害用掲示板を作ってみたけど、無駄に高速でよい感じ。一般に使えるアイデアを練ってます。

あと、mechanizeの使い方を勉強してみた。これは便利だ。
その副産物でSNS（GREE）にアクセスできるようになった。jsonでの通信を組み合わせられれば、なんでも出来るんだけどなぁ。（掲示板のコメントの削除だけは、パソコンではjson経由でないと受け付けてくれない。他はリンクをクリックするアクションでOK）

今後の課題は、セッションの管理かな。
memchachオンリーで良い気がしているんだけど、保存期間的に無理なのかなぁ。

開発進捗（02/04）

メインとなる処理の振り分けのハンドラが出来た。

前は、アップロード前にローカルのスクリプトを実行して、
以下のような定義をメインハンドラのスクリプトに書き込むようにしてました。

from sites.index import requst_handler as sites_index_html
site_tree = {'index.html':sites_index_html}

ただ、こうすると、サイトツリーが大きくなってくると、
最初のインポートの負荷が高くなってしまう。

だから、リクエストハンドラとビューを分離して、
リクエストハンドラが呼び出されたときにビューをimportするようにしてみた。
でも、リクエストハンドラは最初に全部importすることが必要だし、
分離するとわかりにくくなって微妙。


いろいろ調べた結果、結局、urlを文字列変換して動的に
リクエストハンドラをインポートして、呼び出せばよいことになった。
　例）http://hogehoge/index.htmlへのリクエスト
　　urlを解釈して動的にインポート
　　　　a = __import__("sites.index")
　　その後で、
　　　　instance = sites.index.request_handler()
　　　　instance(request, response)
　　みたいな感じ。

ついでに辞書に、"url":リクエストハンドラのインスタンス
という形で保存していけば、２回目以降は アプリケーションキャッシュが残っていれば高速になる。
だいたいこんな感じかな。
　　site_tree = {}
　　
　　def main():
　　　　if url in site_tree:
　　　　　　instance = site_tree[url]
　　　　else:
　　　　　　instance = urlを動的にインポートしてinstanceを作成する処理(url)
　　　　　　if instance is not Null:
　　　　　　　　ファイルが無いよと表示して処理を終了
　　　　　　else:
　　　　　　　　site_tree[url] = instance
　　　　instance(request, response)

最初からサイトツリーを全部構築するのではなくて、
リクエストされたスクリプトを__import__して サイトツリーを育てていくわけですね。


あと、wepbappだと、リクエストがある度に
毎回ハンドラオブジェクトのインスタンスを作成しているのですが、
毎回 作るのは微妙な気がしたので、最初だけつくるようにしてみた。

でもよく考えてみたら、そうした場合、リクエストハンドラが再入可能でないといけない。
今は globalの変数にレンダリング用の文字列を保存し、それを直接更新してレスポンスを作成しているので、現状ではダメ。
なるほどー。だからwebappは毎回インスタンスを作成しているのかぁ。

でもちゃんと設計すれば、毎回作る必要はないはず。
初心者向けのラッピングと判断し、リクエストハンドラを歳入可能にすることにした。

開発進捗（1/22）

目立った進捗は無し。

テンプレートを入れ子にしても速度が保てる方法を考えていたのですが、
いい案が思いつかない。

思いつかないんで、携帯サイトの作り方について以下のサイトで勉強しました。

http://kachibito.net/web-service/mobile-site-tips.html

http://dspt.blog59.fc2.com/

xhtmlを使ったほうが良い、という話は参考になりました。
htmlベースにして考えていたので、危なかったです。


それによく考えたら、携帯の画面ではそんんなに複雑なことを表現できないので、
テンプレートの多重化はそんなに気にしなくて良い気がしてきました。

ただ、キャリアによって表示を多少分けたほうがよいので、
うまくそれを吸収しながら遅くならないようにする方法は考える必要がありそう。

selfに持たせていた属性の一部をclassに持たせたほうが良いかもね。

開発進捗（1/17）

やったこと：
　　ページのhtml部分を別ファイルにして必要になったらimportさせるようにした。
　　htmlの各要素のオブジェクト生成は、import時にのみ実行させるようにした。

結果：
　　全体的にみると、ちょっとだけ速くなっているようだ。
　　起動時間はあんまり変化なし。理論上はほかのページをimportしない分速いはずですが・・・
　　考えられる原因：
　　　　初回のフォームの生成が２重処理になっていることが原因か？
　　　　　　import時に空フォームを生成。
　　　　　　レンダリング時にリクエストの値をフォームに埋め込み
　　　　あとは、ページが少ないので、１ファイルだけimportする恩恵が少ないこともありうる。

　　表記がこなれていないし、オーバーヘッドももう少し抑えられるような気がする。
　　テストコードは全然できていない。

進むべき方向をしらべている場合は、テスト駆動型開発って難しい気がする。
デザインがきっちり決まっていないと、テストコード書いても無駄が多いような？

次にやること：
　　・表記やオーバーヘッドを減らすコードを考える。
　　・リクエストの値を簡単にフォームに埋められるようにしたい。
　　・オブジェクトの生成をキャッシュ化しているけど、
　　　固定文字列を生成するところまでキャッシュ化させられるようにする。
　　・テストコードを整備する。
　　・リファクタリング開始。