計算数学II 2011年度 15班 Google App Engine

2012/01/06

2012-01-07T16:52:00+09:00

* 欠席 - 仕様により欠席します。バグではありません。 * 作業 - プレイヤーの参加状況を実装した。 - index.html を少し親切にした。 - これらおよび冬休みの作業で発生したバグを取ってデプロイした。

冬休み

2012-01-04T14:10:24+09:00

* 作業 - 大きくなったクラスを整理した。 - 入力の誤り検知を強化した。具体的には、正しい順にソートされていないものや、合計が大幅に狂ったものを弾くようにした。 * コメント #comment()

2011/12/16

2011-12-16T16:19:25+09:00

* 作業データモデルに少し手を加えて使いやすくしつつ完成へ向けて整備: &ref(src.zip) - index.html を書いた。 - 標準的なスコア出力を実装した。 - 個人通算成績を実装した。 - プレイヤー一覧を実装した。 -- プロパティの値が None であってもフィルタをせずに並べただけでは出てくる。 * コメント #comment()

2011/12/09

2011-12-09T16:13:41+09:00

* 作業 - 入力しておいたテストデータを見て、データ入力が正しく行われていることなどを確認。 - 小さなバグをいくつか取った。 - CSSをいじっていた。使えそうな本が1冊しか見当たらず、やりたいこと (table の各列の横幅を固定し、はみ出てしまう部分は表示しないようにする) はできなかった。これはローカル側でやることにするか。 * コメント #comment

2011/12/02

2011-12-09T16:13:20+09:00

* 中間発表 - した。 * 作業 - バッチ関係のバグをとった。つもり。入力部分はこれで完成のつもりなので、データをすべて削除して本番用のデータを入力し始める。つもり、だが、データをすべて (Admin から) 削除するのにも Write を削られる。割り当てをフルに使って数日かかる予定。入力がバグってた関係であまり多くのデータは入ってないから週末にテストできるはず。 -- 入力のバッチ処理を cron で行うようにした。 - 適切なテスト用データを作っておかないと、まっさらな状態に戻したくなるたびに数日かかってしまう。(各プレイヤーが十分なゲーム数をプレイした実際のログを用いているが、全体の試合数が多すぎて入力テストとしては不適切になってしまう。プレイヤー数を抑えたデータを作ろう。) -- 9日の間、各10ゲームずつ、6人のプレイヤーからランダムに4人が選ばれてプレイしたテストデータを作った。 * コメント #comment

2011/11/25

2011-12-02T14:30:52+09:00

* 作業 - バッチ処理まわり。 -- 完了。 -- バッチ処理をしてみたら、入力のうち500ゲームも終わらないうちにデータストアの書き込み無料枠 (50000 Writes per month) を使い切ってしまった。[[課金システム>http://code.google.com/appengine/docs/billing.html]] によると Write はガリガリ削られる仕様になっている。100 Writes/半荘だから高くはないがどうしよう。さすがに予算で出ませんよね。 -- バッチ処理をゆっくり行い、1日の割り当てに収まるようにした。バグがいくつか発生し、そのうちのいくつかは取った。 * コメント #comment

2011/11/18

2011-11-19T22:42:35+09:00

* 作業 - 最低限の入力を受付、処理し、結果を表示するプロトタイプの作成。 -- 2011/11/16 完了。現在のソース: &ref(source20111116.zip) -- get() では入力フォームのみを表示。post() ではデータを処理して結果を表示。これらをまとめて1つのアクティビティに1つのハンドラを対応付ける感じで設計・機能追加していく。 -- データストアの使い方を見直した。[a, b, c, d] = G かつ a, b, c, d < 2^20 が成り立つような使い方を想定しているため [a, b, c, d] を List として保存するのではなく a + 2^20 b + 2^40 c として保存し、出力の時だけデコードすることにした。この方が更新も簡単になる。また、ReferenceProperty による逆参照を活用することにした。 &ref(improved_DBusage.lzh) - デプロイしてみた: [[http://mjsmanager.appspot.com/test]] -- 入力: 1位から順に4人のプレイヤーの会員番号、持ち点 -- 出力: 入力されたプレイヤーの通算成績 (表記方法の説明はここでは行わない)。 - フォームからアップロードされたファイルの中身を処理する方法を調べ、機能を実装する。 -- ファイルの取得の仕方からしてわからない。 -- 1つのリクエストで使える時間やデータの読み書きは厳しく制限されている。暇なときに勝手に処理してくれるタスクキューという魔法があるらしいので、これを使えるようにする。 -- これは未着手。中間発表後に取り掛かるか? -- BlobStore を使ってアップロードされたファイルを丸ごと保存し、後で読むことができる。これを使えばよいと思われるが、アップロード URL が存在しないと言われてしまう。 --- アップロード URL の生成ミスだった。パス、スクリプトのファイル名、クラス名がバラバラで混乱していたため、これを整理して命名し直した。アップロードされたファイルの要約を表示し、バッチ処理の開始かキャンセルかを選ぶところまでできた (バッチ処理開始/継続/キャンセルの内容は未着手)。 - フォームで要求されたデータに基づいて処理した成績を見せる機能を実装する。これは特に新しい知識なしにできると考えられる。 -- 完了: [[http://mjsmanager.appspot.com/view_score]]. 各行が1つの成績リクエストとなる。1つの成績リクエストは、コンマで区切られた3つの自然数からなる。プレイヤー番号のみを与えるとそのプレイヤーの通算成績を出力する。2つ組を与えるとそのゲーム数以降の通算成績を出力する。3つ組を与えると後2つがゲーム範囲の指定となる。 --- 整数3つさえ指定してくれれば、適当に解釈してくれる仕組み。 - 他にも色々な面白いデータを取り出す方法を考える。 - 入出力を洗練させる (小数の表示桁数を統一するとか)。 -- 出力はいい感じになった。列の大きさとかは省略。 - (last but not least) たぶん細かいバグがまだあるから取る。 * コメント #comment

2011/11/11

2011-11-16T16:52:46+09:00

* 設計 - 最初のバージョンは複数のコミュニティをサポートせず、ユーザと保持データが1対1対応のもの、または単独 (管理者) ユーザにのみ対応とすることにする。 -- 後々の拡張では大変になるかもしれないが、結局1人で開発する小規模なシステムならこれが近道なのだろう。 * 作業 - とりあえずコードを書いてみる。 * コメント - コメント欄の設置を忘れてました。すみません。 -- 大堀 (2011-11-14 09:30:23) - データモデルを作って処理方法を定義して... という作業だが、テストできなくて辛い。 -- 大堀 (2011-11-14 09:32:46) - ゲームごとの成績を持っておいて必要なときに集計を行うというモデルを考えたが、これでは1回に1000個しかfetchできない制限がネックになってしまう。累積和を持っておけばいつでも区間和が2fetchesでわかる! アルゴリズムすごい! -- 大堀 (2011-11-14 10:19:22) - 2011/11/11 は途中までしか終わらなかったので、その後の結果は [[2011/11/18]] に書いた。プロトタイプ完成。 -- 大堀 (2011-11-16 16:52:18) #comment

2011/11/04

2011-11-11T14:47:22+09:00

* 作業 - Model View Controller と言われるものにしたがって、実装すれば動く (つもりの) コードを書いてみた: &ref(classes.txt). このような設計でよいのだろうか? -- RequestHandler を継承した Output では、 get(), post() をそれぞれ GetReceiver, PostReceiver に委譲する。 -- GetReceiver は ConcreteGetter とテンプレートのパスからなる。 -- ConcreteGetter はデータを取ってくるだけなので、View の一部である。 -- PostReceiver は ConcreteProcessor とテンプレートのパスからなる。 -- AbstractProcessor は自分自身の todict(result), parse(request) を呼び出しているが、これは抽象メソッドであり、ConcreteProcessor で実装される。model.proc は '抽象変数のメソッド' である。 -- ConcreteProcessor はこれらを実装しているが、(データベースへの入力を伴うかもしれない) 実際の処理は ConcreteProcessingModel へ任せてしまっている。 - 実装 (とは言えないレベルのものであるが) してみたら動いた: &ref(source_20111103.zip)! -- 上の設計から、冗長な部分を取り除いたりしてある。 - 主に View, Controller にあたるものを UML のクラス図にしてみた、つもり。'?' は abstract であることを示す。ただし、図の AbstractGetter, AbstractProcessingModel はコードにない。単一の抽象メソッドからなるため実装する意味がないと考えた。こんな感じでよいだろうか? (コードとの一致、および、設計自体の適切さについて) &ref(mjsm_interface.png) * 課題 - やっぱり全体の構造 (必要なクラス集合) を決めるのが最も難しいと感じる。 -- [[2011/10/28]] に書いた「コミュニティ」は管理ユーザ (アプリケーションの管理者と同じとは限らない) と一般ユーザとからなる。ただし管理ユーザの特権は一般ユーザを追加/削除することくらいでよいだろう。複数のコミュニティに所属したいユーザは Google アカウントを複数とってもらうってことでよいと思う (「ユーザ」は成績管理業務を担う人のことであるから、この仮定に無理はないだろう)。 * コメント - 僕もmarathonなどのコンテストに出るときは、こういう図を描いてみたいと思います -- チームK (2011-11-11 14:47:22) #comment

2011/10/28

2011-11-04T14:39:05+09:00

* 作業予定 ** 作業 - スタートガイドを終わらせる。 -- 2011/10/22 完了。ただし[[ユーザサービスの使用>http://code.google.com/intl/ja/appengine/docs/python/gettingstarted/usingusers.html]]は必要になるまで後回し。 ** 仕様の策定 - 課題として作るものを決める。7枚麻雀と麻雀の成績管理との直和をとれば簡単なゲーム CGI になるというのはどうか。前者のみなら、わざわざ Google App Engine を使うまでもない。まずは後者から始め、余裕があったらゲーム部分を作るようにしよう。 * 作業 ** [[テンプレートの使用>http://code.google.com/intl/ja/appengine/docs/python/gettingstarted/templates.html]] (2011/10/22) - クエリ結果の配列に対するループが簡単に実装できた。if などの制御構造もあるらしい。 -- ある程度は Django (← なんて発音するの?) を使えるようにならなければならない。テンプレートの[[マニュアル>http://djangoproject.jp/doc/ja/1.0/topics/templates.html]]と[[リファレンス>http://djangoproject.jp/doc/ja/1.0/ref/templates/builtins.html]]を読む。 --- あんまり複雑なロジックはテンプレートで実装できない。たとえばデータの値の範囲に応じて色を変えるような場合は、Python コード側でデータモデルに属性を追加し、それに応じて HTML 要素の class を指定してあげるのがよいようだ。 ** [[静的ファイルの使用>http://code.google.com/intl/ja/appengine/docs/python/gettingstarted/staticfiles.html]] (2011/10/22) - スタイルシートも簡単。テンプレートにしたがってスタイルシートを切り替えたりするので、静的ファイルも小さいパーツに分割しておいた方がよさそう。 ** 設計関係 - [[Model View Controller - Wikipedia>http://ja.wikipedia.org/wiki/Model_View_Controller]]などを読んだ。最もざっくりとまとめると、入力と処理と出力とを分離するということでよいだろうか。最近の自分が書いたコードを見ると、main メソッドが output(process(input())) みたいになっていることがある。それぞれを異なるオブジェクトに頼めばよい? -- VとCとの結合が少し強めになるのは仕方ない。下に述べる出力例ごとに google.appengine.ext.webapp.RequestHandler を継承したクラスを作り、get() で入力フォーム (これにはログインだけの単純なものもある) の表示を、post() で入力を Model に渡す部分とレンダリングを、それぞれ担当するようにしたらどうか。もうちょっときちんとやるにはこの機能をそれぞれ委譲するのかな。 - 個人で開発する小さなシステムだが、用件定義とか外部設計くらいはきちんとやるべきだろうと思って[[システム開発のノウハウ>http://systemdeveloper.mizusasi.net/]]を読む。 *** システムの目的 - 麻雀 (に限らなくてもよいが) に関する (主に成績の) データを管理する。 -- 取得 (入力) できるデータは限られている。それを分析して「有用なレポート」を引き出す (出力する) ことが目的であるが、具体的な目標があるわけではない。まずは「有用なレポート」の候補を出そう。 *** 用語の定義 - コミュニティ: 麻雀サークルや麻雀店。自分だけで使う分には唯一であると仮定してよいが、より柔軟なものとするために複数の存在を仮定する。 *** 入力 - 各ゲームの行われたコミュニティ(ID)・日付・参加したプレイヤー(ID)・各プレイヤーの評価 (順位・得点など; コミュニティによって異なる)。 *** 出力例 - Cを定数として、各プレイヤーに対して、各コミュニティで自分が参加したうち第 [iC..(i+1)C) ゲームの合計成績。 - 同、第 [0..∞) ゲームの合計成績。 - 各プレイヤーのコミュニティ内レーティング。 - 各プレイヤーの総合レーティング (well-defined な仕様にできるとは思えないが)。 - 各プレイヤーが各コミュニティでゲームに参加する日付と成績の分布 (曜日特性・1日あたり回数の分布・勝敗とゲーム回数との相関など)。 - 各プレイヤーの組が各コミュニティでゲームに参加する日付と成績の分布 (何曜日にはいつも同卓して一方的に勝っている、など)。 * 課題 - 設計に関する資料がほしい。Webサイトでも書籍でも。今まで我流だったので、プログラムに機能を追加するたびに大規模な構造の変更をしてきた。 -- 保留。 * コメント - O'Reilly の GAE 本を注文しました。届くまで今しばらくお待ちあれ -- TA 森 (2011-10-31 16:09:59) -- ありがとうございます! -- 大堀 (2011-11-04 14:38:39) #comment()