プロトタイプ作成および設計
要求及び仕様で作り込む目標を定めた。ここでは目標をどのように達成できるか試行錯誤し、得られた結論についてまとめ、設計資料としてまとめる。
このプロトタイプ開発はprototypeブランチ上で開発を行う。
結論および設計について
以下の構成及び方法で実装できることが明らかになった。
1. データベース設計
ユーザの認証、送信内容の保存と紐付けなど、今後の拡張性を考えて以下の設計で作成する。
 |
|---|
| データベースのER図 |
上記の設計には以下の目的がある。
- UserRoom中間テーブルとChat中間テーブルを使用することで、rails上で多対多を実現する。
- Chat中間テーブルでChatTextテーブルを外部キーに持つことで、action textの問題を分離しやすくできる。
- UserRoom中間テーブルの導入によって、後からのプライベートチャットとグループチャット実装時の修正を減らす。
上記のER図を参考にモデルの作成を行う。
2. 認証処理
ログインにはBasic認証を導入する。Basic認証はセキュリティ上の問題がある。しかし現在の状況では、プライベートネットワーク内で動作するためセキュリティについて対策する必要性がすくない。そのためBasic認証を導入しても問題ないと考えた。
認証の処理については以下の処理の流れで実行できることがわかった。
 |
|---|
| 認証処理（イテレーション１) |
上記の処理で重要なのは以下の点である。
- ログアウトは無意味な認証情報で認証を成功させる。
- 再ログインのためには、一度認証情報を空にする。
１つ目は、ブラウザが認証情報を保存してしまうための対応である。ログアウトしたいのにブラウザが正しい認証情報を覚えていると問題である。そのため偽認証情報を付与した状態で認証に成功させることで、認証情報を上書きする。これによってブラウザバックしても再ログインできない状態ができる。
２つ目は念の為の処理である。偽認証情報を持った状態で選択画面に移行すると認証が不要な画面に認証情報を持って遷移するといった類のポップアップが表示されるはずだ。再ログインにおいては問題ないが、面倒なのでこの処理を入れている。
上記の処理で認証を実装する。
3. チャットの作成と送受信
チャットの文章を入力しサーバに送信する。チャットアプリであるため送信内容が即時に表示されているブラウザに反映されることを期待する。
これらを実現するにはRailsのコンポーネントを利用することで解決できると考えた。それぞれ以下に示す。
- Action Text
- Action Cable
１つ目のAction Textは簡単に豪華な入力フォームや送信内容を作ることができるRailsのコンポーネントである。これを使用することで短期間で豪華な入力フォームや送信内容の実装が可能になる。
２つ目のAction CableはWebSocketを使用したリアルタイム通信を実現することができるRaislコンポーネントである。これによって送信内容をサーバで処理しページ遷移なしに受信内容をレンダリングでき、それらを比較的単純かつ短期間で実現することができる。
4. ルーティング
上記までの実装に対して、ブラウザからアクセスするためのルーティングについて検討した。部分的にRESTfulなインターフェースとし必要かつ最小限の構成として実装する。RESTfulであることを満たすための実装は優先度が低いとして今回のイテレーションでは省略するとし、以下のルーティングを優先して実装することにした。
| Verb | URI Pattern | Controller#Action | 動作 |
|---|---|---|---|
| GET | / | auths#show | 選択画面を表示 |
| GET | /auths/logout(.:format) | auths#logout | ログアウト画面を表示、 キャッシュを上書き |
| GET | /auths/mypage(.:format) | auths#mypage | マイページを表示 |
| GET | /auths/new(.:format) | auths#new | ユーザの新規登録画面 |
| GET | /auths(.:format) | auths#show | 選択画面を表示 |
| POST | /auths(.:format) | auths#create | 入力情報を元にユーザを作成 |
| GET | /rooms(.:format) | rooms#index | ルーム一覧表示 |
| GET | /rooms/:id(.:format) | rooms#show | ルームの内容を表示 |
上記には、action cableで使用するURIパターンとアクションについて言及していない。今回はaction cableのルーティングの設定については変更せず、デフォルトのまま使用することにする。
5. 画面遷移
上記ルーティングに合わせて作るべき画面と画面の遷移の関係についてまとめた。以下に示す。
 |
|---|
| 画面遷移図 |
実装
実装については、プロトタイプのブランチをマージすることにした。その要因は以下のとおりである。
- 想定していた以上に実装に関する知識が不足していたため非常に時間がかかったから。
- ある程度のプロトタイプに仕上がったから。
- 実装量が多く初めから書き直すメリットが小さいから。
- gitコマンドの練習。
しかし、あくまでもともとプロトタイプであるがゆえに不十分な箇所がある。それらについて追加で実装していく。
追加の実装内容については次項で言及することにする。
試行錯誤の内容
もし上記の結論に至るまでの経緯が必要であればイテレーション1 試行錯誤を参照していただきたい。