友達つながり機能(フォロー機能)の実装1つのテーブルを2つに見立てて実装する多対多アソシエーション1対1のメッセージ機能実装ワイヤーフレーム(外観)とテーブル設計(内観)に分けての要件定義validates_uniqueness_ofメソッド外部キー制約(foreign_key:)scopeメソッドの定義strftimeメソッド感想Ajaxをかじってみました。Ajaxは通信技術の一つ。通常はHTMLがレスポンスとして返却されるのに対し、Javascriptがレスポンスとして返却される。非同期通信で画面の一部だけを更新する事ができる。レスポンスでJavaScriptを使う事ができる通信技術って事だよな。これを使えばリッチなUIができるそうだ。まあ実際に実装してみないとどういうことかわからんので、カリキュラムに沿って勉強。最初はブログアプリにAjaxでコメント機能実装。仕組みと実装方法を書いてある通りやると、コメント欄とコメント一覧が確かに通信せずとも表示される。非同期通信だと、どのタイミングでDBにパラメータが保存されてるのか。表示のタイミングと保存のタイミングが多分違うのかな。今までのやつは必ずHTTM返してルーターからコントローラっていう明確なラインが理解できてたけど。そもそもMVCとかとは話が違うんだろうな。実装できるようにすることに精一杯で、イマイチ掴めず。難易度また上がってますわ。次、友達つながり機能(フォロー機能)の実装。アソシエーションの応用的な手法を用いるので、Ajaxより前にそっちの理解が必要。1つのテーブルを2つの別のテーブルに見立てて、多対多のアソシエーションを作る。今回でいえば、usersテーブル。userを「Follower」と「Followed」2つの違うテーブルに見立てて「relationship」中間テーブルを作成し、アソシエーションを行う。理解はできるんだけど、とにかくコード上でややこしい。「Follower」と「Followed」がどっちがどっちかわからなくなるのは俺だけなんだろうか。:followerこの4つが、userモデルにコーディングするアソシエーションの記述です。following、followed、followers、follower、・・・ややこしくないですか?どっちがどっちか。DBからパラメータ引っ張ってくるコーディングをしようと思うと、どっちがどっちか毎回確認しないといけなくて。ツイッターやってないから、フォローとフォロワーどっちがどっちか瞬時にわからないんですかね。ややこしさの原因は、もう一つあります。子テーブルの名前を定義上、本来のテーブル名と別の名前で定義している点です。今回で行ったら、本来の小テーブル名は「relationships」。これを定義上「active_relationships」と「passive_relationships」の2つに名前を変えてます。「User」と「Relationship」のモデルクラス間で2つのアソシエーションを定義しないといけないわけですから、そりゃ名前一緒じゃ無理なわけですけど。このアソシエーションと、さっきやったAjaxのコーディングを合わせてするのはしんどいですわ。最後は、1対1のメッセージ機能実装。これもやっぱりテキスト見ながら同じようにコード書けば実装はできてしまうんですけど。コピペすれば正直なんとなくの理解でも機能実装できるのが、プログラミングのいい所でもあり怖い所でもあるなと。機能実装について要件定義の流れから教えてくれているのが助かります。外観にしてもテーブルにしても、機能実装前の設計について今まであまり考える機会がなかったので、今回の「1対1のメッセージ機能」を作る場合の要件定義を、1から流れに沿って教えてくれたのは非常に勉強になりました。実装しただけので、見た目はなおざりですが、ちらっと載せます。特定のユーザーに対し一対一でメッセージが送信できます。2、ユーザー一覧画面の追加アカウントを持っている全てのユーザー一覧画面です。メッセージボタンとフォローボタンの追加しております。フォロー・ファロワー一覧もマイページに実装しております。3、ブログ詳細画面にコメント機能追加ブログの一覧画面です。上にjsでコメントが表示されます。応用きかすだけの理解は到底できてませんが、次回はとりあえず次のカリキュラム進みます。以上ありがとうございました。コメントをキャンセルメールアドレスが公開されることはありません。コメント名前メールアドレスサイト上に表示された文字を入力してください。