Naoki Kurosawa
naoki_kuros****@ybb*****
2003年 7月 6日 (日) 12:47:30 JST
黒澤です。 #お仕事溢れ状態、もうちょっと続きそうです。 L> 次期システムの案は、黒澤さんの案をほぼ全面受け入れて L> まずは、RobocodeRepositoryなど今のシステムに変更を L> 加えなくても良さそうな部分から、手をつけていきましょうか？ 今ちょっとこんなこと考えてます、という話。 ■その1 - バッチシステム Rumble-JPシステムって、一言で言うと 「分散実行可能なバッチシステム(リーグ・シーズン・対戦の実行)と バッチのステータス表示(リーグXX実行中とか)、 バッチ処理結果表示(シーズン結果)を行うシステム」 だと考えられます。 大体こんなフローでシステムは動いています、という図が以下のURL。 #今、明示的にそういう仕組みになってはいませんが。 http://www.geocities.jp/naoki_kurosawa/new-architecture/state-chart.html (次期システムの状態遷移を意識しているので、 結果HTML生成なんていう処理が入っていますが細かいことは気にしない) なんですが、それぞれのビジネスロジックの処理結果や、 ビジネスロジックの処理条件の書き方によって絵のような 状態遷移が実現されている、という現状なので、 こういうフローだ、ということはコードからは容易には読み取れません。 #ドキュメントにも分かりやすくは書いていない で、世の中のバッチシステムによくあるような、 ジョブのフローを定義して、実行を制御する仕組みを Rumble-JPにも組み込めないかなと思っています。 ・絵の中の角なし四角が1個のジョブ。 ・ジョブの流れとそれを実行するクラスをファイルかなんかに書いておく。 ・実行するクラスの定義を差し替えると処理内容を変えられる。 ・ジョブフロー定義そのものも差し替えられるので、 ぜんぜん違う動きも出来る。 ・ジョブは並行実行したり、分岐したりできる。 ・ジョブの開始条件には - 先行ジョブの終了 - 時刻 なんかが設定できる。 という感じ。 そうすると、今までビジネスロジック同士の密接な依存関係によって 実現されていたシステム動作が疎結合になって、 1つ1つのロジックをメンテしやすくなったり、 仕組みを変えたりしやすくなると思います。 ■その2 - ORマップツール導入 SQLを一生懸命書いてJDBCプログラミングしていますが、 いい加減生産性が悪いので、db.apache.orgのTorqueというORマップツールを 使おうか検討中です。 http://db.apache.org/torque/ これを使うとどんな感じになるか、サンプルコーディングをしてみていますので、 少々お待ちください。 -- Naoki Kurosawa <naoki_kuros****@ybb*****>
