活動履歴(WhiskyExamination)

第5回@京都駅周辺(2016.05.01)

<活動内容>
・今後の取り組みについて検討
・出題アルゴリズムの検討
・アカウント管理機能の実装

<今後の取り組みについて検討>
 実際にアプリケーションを開発したものの、試験対策としてあまり活用できなかったため、その原因を分析。
 現状、問題の得意/不得意に関係なく無作為に出題しており、学習効果が見込めないと感じて活用に至らなかったよう。
 そのため「正答率によって出題傾向を調整する」ことによる学習効果の向上を提案。
 これに先立ってユーザ識別の仕組みを必要と考え「アカウント管理機能の実装」を開始した。

<出題アルゴリズムの検討>
 参考:https://jukus.jp/help/algorithm
 → 詳しくは DatabaseSpecification の項「問題抽出アルゴリズム」を参照。

<アカウント管理機能の実装>
 <テーブルの新設>
  アカウント管理を実現するにあたり、以下のテーブルを新設。
  ・Account - ユーザ認証情報の管理
  ・Trend - ユーザの解答傾向の管理
  ・History - ユーザの解答履歴の管理
 <Trendテーブルの扱いについて>
  Trendテーブルは、ユーザ数×問題数 のレコードが存在する。
  レコードの生成タイミングについて討議した結果、
  新規ユーザ登録や新規問題登録をトリガーに、Trendテーブルへのレコード作成(整合化)を行なうことにした。
  → SQLによる問合せの複雑化を避けるため。
 <新設テーブルへのアクセサ(***DB.php)の実装>
  新設テーブル 'Account' および 'Trend' に対するアクセサを実装中。
 <ログイン画面の実装>
  今のところユーザIDのみで識別を行なう。パスワード認証は後回し。
  ユーザインタフェースは実装済み。ユーザ認証やユーザ新規登録の処理は未実装。

<残タスク>
 □ 新設テーブルへのアクセサ(***DB.php)の実装(途中)
 □ ログイン画面の実装(途中)
  → ユーザ認証やユーザ新規登録の処理を実装する必要がある。
 □ リファクタリング(神クラス 'Questioner.php' の二層化)
  → 現状の設計では Questioner.php は責任過大となる見込み。二層化することで責任分担(役割分担)を行ない、神クラス化を防ぐ。
   → [第1層] Questioner.php は「JSON - Object」の繋ぎ役とする。ユーザ(クライアント)からの要求に対して応答する。
   → [第2層] Questioner.phpとDB周りの間に新設するクラスは「Object - DAO」の繋ぎ役とする。サーバ上の別プログラム(画面プログラム等)からの要求に対して応答する。
    → 各DBのインスタンスを保持し、やりとりの仲介を行なう。その構造の都合上、一つのクラスにまとめる予定。(DBごとにクラスを分けたりはしない。)
   → [第3層] ***DB.php は「DAO - DB」の繋ぎ役とする。"自身に対応する第2層" からの要求に対して応答する。
 □ 出題アルゴリズムの実装


第4回@京都駅周辺(2015.12.30)

<活動内容>
・問題削除機能の実装
・問題編集機能の実装


第3回@Skype(2015.09.25)

<活動内容>
・問題登録機能の実装


第2回@京都駅周辺(2015.08.09)

<活動内容>
・出題の仕組みを実装


第1回@京都駅周辺(2015.05.04)

<活動内容>
・PHPと必要なライブラリの導入
・データベース作成
・ウイスキー検定対策アプリ 仕様検討