わたしがRailsチュートリアルで学んだこと【2章】

* 注意：プログラミング歴29日の初心者が書いています

* 注意：間違っていたら優しく教えてください（喜びます）

「Ruby on Rails チュートリアル実例を使ってRailsを学ぼう」
 https://railstutorial.jp/

素晴らしいチュートリアルに感謝します。

#2.1 アプリケーションの計画

###アプリケーションを作成してbitbucketにpush
`rails new` : 新しいアプリケーションの作成
bitbucketで新しいリポジトリを作成（１章とは別のアプリを一からつくるから別のリポジトリ）
`git remote add origin git@bitbucket.org:<username>/toy_app.git`：新たに作成したファイル群をbitbucketのgit対象に指定
`git push -u origin --all`：　bitbucketにプッシュ（アップロード）

###herokuにログインできないとき

ターミナルでheroku CLIにログイン
`$ heroku login --interactive `パスワード入力

それでも
`heroku: command not found`とエラーがでるときは、

`source <(curl -sL https://cdn.learnenough.com/heroku_install)`でIDEにherokuをインストールしなおし。

#2.1.1 ユーザーのモデル設計
今、ツイッターみたいなアプリを作ろうとしています。
そのためのデータベースを作っていきます。

ユーザーのモデル設計とは、その名の通り投稿を行うユーザーのデータベースです。
一人一人のユーザーは、

* ID

* name

* email 

の情報を持っています。


#2.1.2 マイクロポストのモデル設計
マイクロポストは、ツイッターでいうところのツイートです。
１つ１つのマイクロポストは、

* ID

* Content （投稿内容）

* user_id （誰が投稿したポストかわかるように）

の情報を持っています。


#2.2 Usersリソース

データの集まりで、さらにWebで扱うことができる状態になっているのが、リソースです。

例えば、さっきのUsersモデル（ユーザーのデータベース）はそのままではただのデータの集まりですが、webサービスにおいては、新規追加したり、情報を編集したりするわけです。

「webから情報を扱う」というのは、HTTPで「新規登録しろ」とか「このユーザーのデータは削除だ！」とかリクエストできるということです。

そうゆうことができる状態のデータの集まりが、リソースです。

##Railsのscaffold
Railsのscaffoldが、リソースを作る作業を全部やってくれます。
今回はそれに頼りましょう。

#2.2.1 ユーザーページを探検する
URLの末尾に`/uses`をつけることで、user一覧ページにアクセスすることができます。
そのほかにも`/new`や`/edit`など、色々なことができるようになっています。
これは、「scaffold」コマンドが全て自動で設定してくれたからです。


#2.2.2 MVCの挙動
##ルーティングってなんですか
ルーティングはURLとアクション（実行する内容）を紐づけている部分です。


```rb
Rails.application.routes.draw do
  resources :users
  root 'application#hello'
end
```
`root　'application#hello'`は、『ルート（トップページ）は、appricationコントローラのhelloメソッドを使って表示してね』と言っています。

さらに注意深く`routes.rb`ファイルの中を見ると、`resources :users`というのが新たに追加されています。
これは「resourcesメソッド」です。

まず、『「users」というURLに対しては、「usersコントローラを参照してね」』ということを言っています。

また、railsの特徴として、リソースに対するアクションはすでに７つ定義されています。

| アクション名 | 役割 |
|:--|:--|
| index | リソースの一覧を表示させる |
| show | リソースの詳細を表示させる |
| new | 投稿フォームを表示させる |
| create | リソースを追加させる |
| edit | 更新フォームを表示させる |
| update | リソースを更新させる |
| destroy | リソースを削除する |

resourcesメソッドは、これら７つのアクションを自動的にUsersリソースに割り当てます。

データベースの操作内容まで、全てRailsが作ってくれているのです。


このように、最初から７つのアクションが定義してあって、それぞれのアクションの名前や、URLの末尾に付け足す内容までがルールとして決めてあります。
あなただけでなく、みんなが同じルールに則って開発すると、誰が見てもわかりやすくて管理しやすくなります。
ちなみに、今回使っているルールは「REST」と呼ばれています。詳しくはググるといっぱい出てきます。

#2.3.2 マイクロポストをマイクロにする
##バリデーションとは
データベースにデータを保存する前に、そのデータが本当に保存していいのかどうか検証する仕組みをバリデーションといいます。

```rb
class Micropost < ApplicationRecord
  validates :content, length: { maximum: 140 }
end
```
`app/models/micropost.rb`内のコードです。
ここでは、

* マイクロポストモデルの「content」の「length」がマックス140文字まで

というバリデーションを設けています。

#2.3.3 ユーザーはたくさんマイクロポストを持っている
##has_meny / belongs_toとは
has_menyは、モデルとモデルを関連づけるために使います。
今回のチュートリアルの場合、「Usersモデル」と「Micropostsモデル」を関連づけるために使います。

```rb
class User < ApplicationRecord
  has_many :microposts
end
```
Userモデル（app/models/user.rb）内に「has_many :microposts」と記述することで、モデル同士が関連します。
ただし、マイクロポストがユーザーを持っているわけではないことに注意してください。
あくまでも、個々のユーザーは１人です。
１人のユーザーがたくさん投稿することがあっても、１つの投稿がたくさんのユーザーに紐づいているわけではないからです。

そのため、マイクロポストモデル内に、`has_many :users`と記述するのは不適です。

そのかわり、マイクロポストモデル内には

```rb
class Micropost < ApplicationRecord
  belongs_to :user
  validates :content, length: { maximum: 140 }
end
```

`belongs_to :user`と記述します。
これで、マイクロポストはユーザーに所有されているという関係になりました。

マイクロポストモデルには`user_id`という属性を設定してあったので、自動的にuserモデルのIDと対応します。