活動履歴（WhiskyExamination）¶

第５回＠京都駅周辺（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層" からの要求に対して応答する。
　□ 出題アルゴリズムの実装

---

第４回＠京都駅周辺（2015.12.30）¶

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

---

第３回＠Skype（2015.09.25）¶

＜活動内容＞
・問題登録機能の実装

---

第２回＠京都駅周辺（2015.08.09）¶

＜活動内容＞
・出題の仕組みを実装

---

第１回＠京都駅周辺（2015.05.04）¶

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

---