今日、自部屋でniwatoriと開発会議をした。結構生産性の高いミーティングだったと思う。
ま、いろいろ話したので、議事録を残しておく。
とりあえず、一番大事なマスタースケジュールは、「2/16までに中嶋さんにレビューしてもらえるところまでつくり、3/1までに一通り完成させる」ということになった。
詳細は以下を参照のこと。
【プロジェクト管理】
マスタースケジュール
2/4 1st Milestone(M1) core model implementation
2/9 M2
2/16 M3(alpha1) プロトタイプを中嶋さんにレビュー可能にし、中嶋さんとインターフェイス、プロトコルや機能について議論する。
2/23 M4(alpha2)
3/1 M5(beta1) 一通り完成品を提供する
コーディング規約
Sunのjavaコーディング規約にのっとる
テスト計画
一通り完成させてからJUnitでUnitTestを書く(beta releaseの前後)
ソース管理
インターフェイスドキュメント:niwatori
内部機能ドキュメント:鈴木
開発STEP
niwatori
①snapshot(M2)
②shellと簡易プロトコルスタック(M2:setter系,M3:getter系)
③log(M3)
⑤インターフェイスドキュメント、テスト(M5)
鈴木
①リファクタリングしてコードをsourceforge.jpにUp(as soon as possible, maybe in 2/5)
②scheduler実装(M2)
③shellインターフェイス設計(モードオプションも含む)とDBスキーマ設計(M2)
④getter系実装とindex系実装(M3)
⑤修正・拡張とドキュメンテーション、テスト(性能テスト、環境テスト等を含む)(M5)
【機能】
目標性能の確認
中嶋さんとの打ち合わせドキュメントの通り
登録ユーザー数 10万
アクティブユーザー 3万
同時接続ユーザー 3000
トランザクション数 1秒10回
レスポンスタイム 100ms-500ms
結果反映タイム 10分に1回
ポーリングインターバル 3分に1回 = 1秒に平均10人分
複数貨幣対応とマルチスレッド化
複数貨幣に対応できるようにする。
スレッド管理はshellが統合的に行う。DBスキーマも対応させる。
貨幣IDはStringとする。
modelとschedulerはこの点については問わない。
rollback アルゴリズム
snapshot+operation logでlogID単位で完全に状態を再現する。
snapshotはインスタンスをファイルに書き込む
初期はjavaのserializeで行う。
バージョン管理の点で問題が起きる可能性があるが、その場合はうまく回避するか、丁寧にgetを書いていく。
operation logはDBに書く。
貢献度ベクトルの計算と更新をするときのみsnapshotをとる。
非同期アルゴリズム対応
全同期:snapshotの読み込み(書き込みによる性能劣化がはげしい可能性大なので、要検討)→start or not
貢献度ベクトル非同期:spapshotの読み込み→operation logの実行→start or not
評価行列非同期:snapshotの読み込み→operation logのキューへの読み込み→start or not
ロールバックしてstartした場合にそれ以後のデータ保持はどうするのか?(枝分かれ?)
メモリ容量の改善
評価のdoubleのfloat化、int化により4倍のメモリ容量の改善が可能である。これは、別途行う可能性があるが、パッケージ設計の影響等はそのときに別途考慮する。また、int化は分散化の布石でもある。
【設計】
パッケージ設計
【niwatori担当】
org.picsy.kernel.shell
setter
getter
rollback
org.picsy.kernel.repository
spapshot(filesystem)
log(db)
operation log
access log
index log
【鈴木担当】
org.picsy.kernel.model
Currencyクラスのみpublicとする
setter
getter
index
org.picsy.kernel.scheduler
クラス設計
modelは現行のままOKとする
shellはFactoryからつくる
repositoryとプロトコルはinterfaceとする
schedulerにstartとstopを置く