MTG-GUILDですが、開発から1年以上たっている割には進捗悪いんです。
余暇を利用して開発しているので、予算0円、納期未定なので、ずるずる進行なのは想定内ではあるのですが・・・。
もうちょっとなんとかしたいので、現状を整理してみました。
トレーディングカードゲーム「Magic:The Gathering」の攻略サイト MTG-Guild の 開発日誌です。 Google App Engine - Python で構築スタート! ・・・どうなることやら
2012年6月9日土曜日
2012年1月12日木曜日
GAE Python 2.7のテスト環境の構築について考えてみる
今のGAEだと、
from google.appengine.ext import testbed
とかからで、必要なスタブを読み込んでいけばいいんですね。
プロダクション環境のビッグテーブルを使ってテストしなくちゃいけないほどハードなテストはしないよていなので、GAETestBaseは移植しないことにしました。
gaeunitみたいな、プロダクション環境でテストを動かす仕組みはあったほうが良い気がしますね。
今の案では、
Python2.7の環境なら、unittestで、かなりいけるはず。noseとかいらないかもしんない。
webtest と BeautifulSoup は リクエストを投げて帰ってくるレスポンスの内容をテストする為にいるはず。
アプリのバージョンでnamespaceを分けるようにすれば、アプリを公開後もプロダクション環境でテストを走らせることは可能なはず。
ただ、そうした場合、バージョン間のデータのコピーとかを簡単にできるように環境を整えるのと、Seleniumのテスト開始時にデータストアを初期化するような仕組みがほしくなりますね。
んー面倒だから、プロダクション環境でのテストは後回しかな。
TDDで開発するには、ローカル環境でテストできれば十分だし。
from google.appengine.ext import testbed
とかからで、必要なスタブを読み込んでいけばいいんですね。
プロダクション環境のビッグテーブルを使ってテストしなくちゃいけないほどハードなテストはしないよていなので、GAETestBaseは移植しないことにしました。
gaeunitみたいな、プロダクション環境でテストを動かす仕組みはあったほうが良い気がしますね。
今の案では、
- ローカル環境:unittest + testbed + webtest + BeautifulSoupでテスト。
- プロダクション環境:Seleniumでテスト
Python2.7の環境なら、unittestで、かなりいけるはず。noseとかいらないかもしんない。
webtest と BeautifulSoup は リクエストを投げて帰ってくるレスポンスの内容をテストする為にいるはず。
アプリのバージョンでnamespaceを分けるようにすれば、アプリを公開後もプロダクション環境でテストを走らせることは可能なはず。
ただ、そうした場合、バージョン間のデータのコピーとかを簡単にできるように環境を整えるのと、Seleniumのテスト開始時にデータストアを初期化するような仕組みがほしくなりますね。
んー面倒だから、プロダクション環境でのテストは後回しかな。
TDDで開発するには、ローカル環境でテストできれば十分だし。
2011年12月10日土曜日
開発進捗(12/10)
Pytho2.5のままだと将来的にきつそうなので、Python 2.7で頑張ることにしました。
(OrderdDictも欲しかったし)
Python2.5のときは、フルスクラッチで フレームワークを作ってました。今回はまた1から作り直しますが、前回とは違って、なるべくwebapp2を利用することにします。
あんまり開発に時間をとれないんだから、些細なことには拘らずに、手早く作ることをめざします。
今のところwebapp2で気にくわないのは、routerのところと、そこから先のハンドラの部分なので、そこをいじればいけるかなと。
htmlのレンダは、昔は日本語のドキュメントがあるフレームワークがみあたらなくてきつかったので、自作してました。でも今はjinja2の日本語のドキュメントあるので、jinja2で良いかな。Sphinxでもjinja2が標準ですしね。
本当は、前の自作のと比べるとimport が重くなりそうなので、jinja2を使うのはちょっと嫌です。でも、動的な遅延インポート+ハンドラのキャッシュで、レンダリングには ほとんどパフォーマンスは要求されないはずなので、手を抜くことにしました。
環境の再構築はだいたい完了。
当面の目標は検索画面の作成ですね。
タスク1:検索先のマスタの作成
そういや、webapp2 についての記事が微妙に人気みたいですね。
googleの検索でひっかかりやすいので、一番ページビューがあります。
webapp2については、googleの公式には日本語のドキュメントがないので、困っている人もおおいのかな?
でも英語わからなくても、Python語がわかるなら、webapp2は頑張れば使えますよ!
(OrderdDictも欲しかったし)
Python2.5のときは、フルスクラッチで フレームワークを作ってました。今回はまた1から作り直しますが、前回とは違って、なるべくwebapp2を利用することにします。
あんまり開発に時間をとれないんだから、些細なことには拘らずに、手早く作ることをめざします。
今のところwebapp2で気にくわないのは、routerのところと、そこから先のハンドラの部分なので、そこをいじればいけるかなと。
htmlのレンダは、昔は日本語のドキュメントがあるフレームワークがみあたらなくてきつかったので、自作してました。でも今はjinja2の日本語のドキュメントあるので、jinja2で良いかな。Sphinxでもjinja2が標準ですしね。
本当は、前の自作のと比べるとimport が重くなりそうなので、jinja2を使うのはちょっと嫌です。でも、動的な遅延インポート+ハンドラのキャッシュで、レンダリングには ほとんどパフォーマンスは要求されないはずなので、手を抜くことにしました。
環境の再構築はだいたい完了。
当面の目標は検索画面の作成ですね。
タスク1:検索先のマスタの作成
- Mechanizeで とりこみたいデータを取り込むようにする
→例外的なところを除けば取り込めるようになった。例外部分は後回しにしよう - 取り込んだデータをもとに、辞書を定義するpythonスクリプトを出力するモジュールを作る
→これから着手
そういや、webapp2 についての記事が微妙に人気みたいですね。
googleの検索でひっかかりやすいので、一番ページビューがあります。
webapp2については、googleの公式には日本語のドキュメントがないので、困っている人もおおいのかな?
でも英語わからなくても、Python語がわかるなら、webapp2は頑張れば使えますよ!
2011年10月25日火曜日
携帯サイトのセッション管理
携帯電話のセッション管理の面倒さは、ドコモの携帯がクッキーに対応していないことに起因している。(他のキャリアについては、パソコンとほぼ同じと考えていい)
新しい機種やスマホは、当然クッキーに対応しているのだけれど、古いドコモを切って良いのかどうかで迷い中。
ぶっちゃけ自分の携帯は、クッキーに対応しているので、古いドコモはとりあえず切って開発しようかな?
うん、そうしよう。
速さを重視して、データストアにまったく値を保存しないで、memcacheでセッション管理したら、memcacheの寿命が短すぎてまいった。端末のcookieにはセッションIDが残っているのですが、サーバ側はセッションIDやそれに紐づけられた変数が数分で消える。
memcacheのエントリの寿命は2週間を指定しているのに、すぐおちるのは、インスタンスが落ちるのと同じタイミングでmemcacheも落ちるということかな?
みんなcookieに保存するのもありだけど、改ざんテストにコストがかかるし、古いドコモに対応させようとするとURLクエリに保存しきれなくてきついはず。
ってことはやっぱりセッション管理にデータストアを使うしかないのかなぁ。
普通でつまらないけど、仕方ないかな。
新しい機種やスマホは、当然クッキーに対応しているのだけれど、古いドコモを切って良いのかどうかで迷い中。
ぶっちゃけ自分の携帯は、クッキーに対応しているので、古いドコモはとりあえず切って開発しようかな?
うん、そうしよう。
速さを重視して、データストアにまったく値を保存しないで、memcacheでセッション管理したら、memcacheの寿命が短すぎてまいった。端末のcookieにはセッションIDが残っているのですが、サーバ側はセッションIDやそれに紐づけられた変数が数分で消える。
memcacheのエントリの寿命は2週間を指定しているのに、すぐおちるのは、インスタンスが落ちるのと同じタイミングでmemcacheも落ちるということかな?
みんなcookieに保存するのもありだけど、改ざんテストにコストがかかるし、古いドコモに対応させようとするとURLクエリに保存しきれなくてきついはず。
ってことはやっぱりセッション管理にデータストアを使うしかないのかなぁ。
普通でつまらないけど、仕方ないかな。
2011年9月7日水曜日
webapp2! の続き
ビジネスロジックはいじらずに、あいかわらずフレームワークをいじってしまってます。
webapp2のハンドラの文字列によるインポートは、ちょっと誤解してました。
ディスパッチャでは別の使い方をしているので、私のフレームワークとは別物ですね。
webapp2は、全体にモジューラルな感じに作られていて、いじりやすそうですが、書き方が冗長すぎる気もします。webapp2を分解してもう少しインテグラルな方に作り直してみよう。
前回webappを分解して自分用フレームワークを作ってみた時は、GAEの仕組みを大分理解できましたので、今回もいろいろ勉強になりそう。
旧フレームワークの改善点:
・requestやresponseを、ハンドラオブジェクトの属性に保存しない(並列実行時にオブジェクトの属性が書き換えられる場合があることを考慮する)
・ディスパッチャからハンドラのgetやpostのメソッドを直接呼ばないようにする(ハンドラ側でセッションIDの管理を行ってから、getやpostを呼ぶようにする)。そうすることで、ハンドラごとにセッションを管理するかどうかを制御できるようにする。
・view部分をもう少し高速化できるようにする。(文字列の結合を減らせるようにする)
最近は仕事で少しだけpythonを使うようになっているのですが、2.7のほうが良いことがおおいので、GAEにもはやく2.7になって欲しいです。
webapp2のハンドラの文字列によるインポートは、ちょっと誤解してました。
ディスパッチャでは別の使い方をしているので、私のフレームワークとは別物ですね。
webapp2は、全体にモジューラルな感じに作られていて、いじりやすそうですが、書き方が冗長すぎる気もします。webapp2を分解してもう少しインテグラルな方に作り直してみよう。
前回webappを分解して自分用フレームワークを作ってみた時は、GAEの仕組みを大分理解できましたので、今回もいろいろ勉強になりそう。
旧フレームワークの改善点:
・requestやresponseを、ハンドラオブジェクトの属性に保存しない(並列実行時にオブジェクトの属性が書き換えられる場合があることを考慮する)
・ディスパッチャからハンドラのgetやpostのメソッドを直接呼ばないようにする(ハンドラ側でセッションIDの管理を行ってから、getやpostを呼ぶようにする)。そうすることで、ハンドラごとにセッションを管理するかどうかを制御できるようにする。
・view部分をもう少し高速化できるようにする。(文字列の結合を減らせるようにする)
最近は仕事で少しだけpythonを使うようになっているのですが、2.7のほうが良いことがおおいので、GAEにもはやく2.7になって欲しいです。
2011年5月27日金曜日
開発進捗(05/27)
mechanize遊びばっかりやってました。
よく調べてみたら、リクエストを出せばgreeの掲示板のコメントは削除できたので、
あんまりjsonは関係ありませんでした。
(コメント削除の結果はjson形式で帰ってくるのですが、あんまり意識する必要はない漢字でした)
本筋のMTG-Guildsのほうは、さっぱりですが、
Wikiの仕様を一部取り込むとメニュー処理を標準化できそうなので、
その方向で検討中です。
・・・いいから、セッションを早く実装しよう。
よく調べてみたら、リクエストを出せばgreeの掲示板のコメントは削除できたので、
あんまりjsonは関係ありませんでした。
(コメント削除の結果はjson形式で帰ってくるのですが、あんまり意識する必要はない漢字でした)
本筋のMTG-Guildsのほうは、さっぱりですが、
Wikiの仕様を一部取り込むとメニュー処理を標準化できそうなので、
その方向で検討中です。
・・・いいから、セッションを早く実装しよう。
2011年1月22日土曜日
開発進捗(1/22)
目立った進捗は無し。
テンプレートを入れ子にしても速度が保てる方法を考えていたのですが、
いい案が思いつかない。
思いつかないんで、携帯サイトの作り方について以下のサイトで勉強しました。
http://kachibito.net/web-service/mobile-site-tips.html
http://dspt.blog59.fc2.com/
xhtmlを使ったほうが良い、という話は参考になりました。
htmlベースにして考えていたので、危なかったです。
それによく考えたら、携帯の画面ではそんんなに複雑なことを表現できないので、
テンプレートの多重化はそんなに気にしなくて良い気がしてきました。
ただ、キャリアによって表示を多少分けたほうがよいので、
うまくそれを吸収しながら遅くならないようにする方法は考える必要がありそう。
selfに持たせていた属性の一部をclassに持たせたほうが良いかもね。
テンプレートを入れ子にしても速度が保てる方法を考えていたのですが、
いい案が思いつかない。
思いつかないんで、携帯サイトの作り方について以下のサイトで勉強しました。
http://kachibito.net/web-service/mobile-site-tips.html
http://dspt.blog59.fc2.com/
xhtmlを使ったほうが良い、という話は参考になりました。
htmlベースにして考えていたので、危なかったです。
それによく考えたら、携帯の画面ではそんんなに複雑なことを表現できないので、
テンプレートの多重化はそんなに気にしなくて良い気がしてきました。
ただ、キャリアによって表示を多少分けたほうがよいので、
うまくそれを吸収しながら遅くならないようにする方法は考える必要がありそう。
selfに持たせていた属性の一部をclassに持たせたほうが良いかもね。
登録:
投稿 (Atom)