計算数学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/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/12/02

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

* 中間発表 - した。 * 作業 - バッチ関係のバグをとった。つもり。入力部分はこれで完成のつもりなので、データをすべて削除して本番用のデータを入力し始める。つもり、だが、データをすべて (Admin から) 削除するのにも Write を削られる。割り当てをフルに使って数日かかる予定。入力がバグってた関係であまり多くのデータは入ってないから週末にテストできるはず。 -- 入力のバッチ処理を cron で行うようにした。 - 適切なテスト用データを作っておかないと、まっさらな状態に戻したくなるたびに数日かかってしまう。(各プレイヤーが十分なゲーム数をプレイした実際のログを用いているが、全体の試合数が多すぎて入力テストとしては不適切になってしまう。プレイヤー数を抑えたデータを作ろう。) -- 9日の間、各10ゲームずつ、6人のプレイヤーからランダムに4人が選ばれてプレイしたテストデータを作った。 * コメント #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 の生成ミスだった。パス、スクリプトのファイル名、クラス名がバラバラで混乱していたため、これを整理して命名し直した。アップロードされたファイルの要約を表示し、バッチ処理の開始かキャンセルかを選ぶところまでできた (バッチ処理開始/継続/キャンセルの内容は未着手)。 - フォームで要求されたデータに基づいて処理した成績

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]] に書いた「コミュニティ」は管理ユーザ (アプリケーションの管理者と同じと

2012

2011-10-21T23:18:48+09:00

- [[冬休み]] - [[2012/01/06]] - [[2012/01/13]] - [[2012/01/20]] - [[2012/01/27]]