Activities » 履歴 » バージョン 2
バージョン 1 (MIYAZAKI Masafumi, 2016/05/04 01:28) → バージョン 2/3 (MIYAZAKI Masafumi, 2016/05/04 01:29)
h1. 活動履歴（WhiskyExamination）
h2. 第５回＠京都駅周辺（2016.05.01） 第５回＠京都駅周辺（2015.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」の繋ぎ役とする。
□ 出題アルゴリズムの実装
----
h2. 第４回＠京都駅周辺（2015.12.30）
＜活動内容＞
・問題削除機能の実装
・問題編集機能の実装
----
h2. 第３回＠Skype（2015.09.25）
＜活動内容＞
・問題登録機能の実装
----
h2. 第２回＠京都駅周辺（2015.08.09）
＜活動内容＞
・出題の仕組みを実装
----
h2. 第１回＠京都駅周辺（2015.05.04）
＜活動内容＞
・PHPと必要なライブラリの導入
・データベース作成
・ウイスキー検定対策アプリ 仕様検討
----
h2. 第５回＠京都駅周辺（2016.05.01） 第５回＠京都駅周辺（2015.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」の繋ぎ役とする。
□ 出題アルゴリズムの実装
----
h2. 第４回＠京都駅周辺（2015.12.30）
＜活動内容＞
・問題削除機能の実装
・問題編集機能の実装
----
h2. 第３回＠Skype（2015.09.25）
＜活動内容＞
・問題登録機能の実装
----
h2. 第２回＠京都駅周辺（2015.08.09）
＜活動内容＞
・出題の仕組みを実装
----
h2. 第１回＠京都駅周辺（2015.05.04）
＜活動内容＞
・PHPと必要なライブラリの導入
・データベース作成
・ウイスキー検定対策アプリ 仕様検討
----