##Rails Tutorialの第14章にある拡張機能について
Rails Tutorialをの第14章には、Tutorialを完了した人向けに、自分で機能を拡張するお題がいくつかあります。
最初のお題である、返信機能に挑戦しています。まだ作成途中ですが、できたところまで投稿します。

###作る要件を確認し、仕様を作る

要件は以下のように書かれています。

Twitterには、マイクロポスト入力中に@記号に続けてユーザーのログイン名を入力するとそのユーザーに返信できる機能があります。このポストは、宛先のユーザーのフィードと、自分をフォローしているユーザーにのみ表示されます。この返信機能の簡単なバージョンを実装してみましょう。具体的には、@replyは受信者のフィードと送信者のフィードにのみ表示されるようにします。

仕様のヒントも書かれています。

これを実装するには、micropostsテーブルのin_reply_toカラムと、追加のincluding_repliesスコープをMicropostモデルに追加する必要があると思います。

要件を具体的にブレークダウンします。

・@replyが表示されるのは、以下の3者
replyの受信者
replyの送信者（自分）
replyの送信者のフォロワー

上記以外のユーザーには表示されない

・マイクロポストの先頭に「@reply ユーザーのログイン名」を入力したときに、このポストをreplyと判定

###仕様を深堀する、例示されているtwitterを参考にするため調べる

Tutorialの「6.2.5 メールアドレスの一意性」を読み返したところ、大文字と小文字の区分けをするか書いてありました。
ユーザー名に大文字と小文字で区分けをすべきなのか、TaroとTAROを違うものとするかどうかです。
twitterはどうなのかネットで調べます。

内部では同じだが、入力時に区分けはするという記事が多かったです。ズバリ書いている記事が見つからなかったです。
メアドと同じ仕様で作ることにします。

この大文字小文字の機能は、最初からではなく後で追加することにしました。後から追加するのが簡単そうに見えたためです。

###どういう機能を作るか、以前に追加した機能に似ているので読み返す

以前に追加した機能に似ているので、どの機能と似ているか読み返します。

13章のマイクロポストの機能に似ている
6.7章のユーザー登録の機能に似ている
6.2.5　一意性を検証する　
　　メールアドレスの一意性

その結果をもとに、以下のような機能を考えました。

・replyで表示する／しないの判定ができる機能をmodelに追加
　このpostはreplyかどうか
・@replyの入力を判別する機能をviewまたはcontrollerに追加
・ユーザー名がユニークになるように、modelとviewに追加

最後の「ユーザー名がユニーク」の機能は、最初からではなく後で追加することにしました。まずはユニークなテストデータだけで動くものを作ってみて、後からユニークにする制約の機能を付け加えればよいと考えたためです。

###機能を詳しく設計する　モデル
14章の14.1.1を再度読みます。id間のrelatoinのことでした。

micropostsテーブルのin_reply_toカラムと、追加のincluding_repliesスコープをMicropostモデルに追加する必要があると思います。

をヒントに、modelをどう変更するか考えます。

microposts

列名	属性
id	integer
content	text
user_id	integer
in_reply_to	integer
created_at	datetime
updated_at	datetime

in_reply_to の列を追加するとして、型は何になるか？どのユーザーか特定するのだから、idと同じでintegerと考えました。

###機能を詳しく設計する　メソッド
micropostのメソッドを追加するか、既存のメソッドを変更するか。
表13.1を参考にします。
user.micrposts 　 Userのマイクロポストの集合をかえす既存の変更
user.microposts.build(arg) userに紐付いた新しいMicropostオブジェクトを返す既存の変更
user.microposts.find_by(id: 1) userに紐付いていて、idが1であるマイクロポストを検索する既存の変更

replyのメソッドを追加するか、考えます。
user.microposts.create(arg,reply:user2) user2へのreplyのマイクロポストを作成する
既存のcreateメソッドを変更することにします。

###機能を詳しく設計する　ビュー
画面は主に2つ修正、replyを入力するところと、replyを表示するところです。

入力項目は増やす必要がない、なぜなら、contentの先頭に@replyと記入するからと考えました。

出力でreply専用の画面が必要か？　
Twitterを調べます。replyは元Tweetをクリックすると別画面に移ってreplyの一覧を表示しています。replyの親子のTweetを一覧で表示しています。

ちょっと複雑なので今回はそこまではやらず、元Tweetと同じ画面に表示することにします。

画面のイメージは、モックを作るのは面倒なのでテキストだけです。
comment box　:　@reply michael Cum aspermatur ..

Feedの表示イメージ
@reply michael Cum aspermatur ..

###機能を詳しく設計する　ビューの入力エラーチェック

user_idが見つからないときは、親切な設計なら入力時にエラーを表示します。createするときにチェックするはずなのでエラーを表示することにします。

postをした後で、user_idが削除されたケースはどうするか？
このmicropostを削除するべきか。もういない人にreplyしたmicropostだけが残っているほうがよいと考え、micropostは削除しないと考えます。

###所要時間
9/27から10/1までの3.0時間です。