アウトプット11/28

<今日のカリキュラム>

・rubyドリル

・最終課題の商品一覧表示機能コードレビュー修正

 

<問題解決など>

・コンフリクトが行っている状態ではgit push heroku master はできないので解決してから行う必要がある。

そもそも間違えたことがあっても慌てて記述するとブランチにクリプルせずにマージしてしますのでgit管理は常に集中することが大切。

・削除機能のエラー。

ブラウザの戻るボタンでは修正が反映されないので必ずリロードすること！！

linkの記載の仕方は、

<%= link_to 'リンクに表示する文字', 'リンク先のURL', method: :'HTTPメソッド名' %>

今回のケースでは、
<%= link_to '削除', item_path(@item.id), method: :delete, class: "item-destroy" %>

 

HTTPメソッドは、クライアントが行いたい処理をサーバー側に伝えるという役割。削除の場合にはDELETEを使用。

この内、「item_path(@item.id)」 の記述が曖昧だった点。pathはターミナルでdestroyに対応しているか確認。（）内は、パスにid情報をいれることでリクエスト上でのパラメーターにid 情報が含まれて、コントローラーにより削除すべきレコードを指定できるという流れ。

うーん、複雑。

 

＜分かっていなかったこと＞ 

 

 

＜理解していないこと＞

 ・fill_inメソッド

・have_selector,have_contentの違い

　指定したセレクタがあるかないかを判断するマッチャがhave_selector。have_contentは指定した文字列があるかどうかを判断するマッチャ。

・sliceメソッドとslice!メソッド

　array.slice(1) →配列の中から１番目の数値を取り出す。但し配列に影響はない。

　array.slice!(1) →配列の中から１番目の数値を取り出す。取り出した数値は配列から削除される。

・afterメソッド 

　任意の処理の後に指定の処理を実行するメソッド。テストコードでFactoryBot後に画像を保存するコードを作るときなどに使用する。

・DOM

　ドキュメントオブジェクトモデルのこと。 HTMLを解析し、データを作成する仕組み。JavaScriptではHTMLを階層として捉えて変換したデータと捉え、そのHTMLの階層を取得し、操作することでプログラムを動かす言語。

・XMLHttpRequest

　javascriptからAjaxによるリクエストを送るためのオブジェクトのこと。

・renderメソッド

　JSON形式でデータをサーバーから返却する際には、

　render json:{ post: post}

　とcreate定義に記載する。

・onload

　XMLHttpRequestで定義されているプロパティで、レスポンスの受信が成功した場合に呼び出されるイベントハンドラーのこと。

 ・セッションとクッキー

 　webサービスにおいて情報を一時的に保存しておく仕組み。セッションがハッシュの形式でクッキーという保存場所に保存される。

・before_action

　コントローラーで処理が被っているときに使用する。具体的には、同じ記述を別のメソッドで定義し、アクションの実行前にbefore_actionを実行させることで記述内容の重複を避ける。

・テーブルにカラムを追加

　rails g migration Addカラム名Toテーブル名　追加するカラム型:型

 

・devise_parameter_sanitizerメソッド（2回目！）

　deviseにおけるparamsのようなもの。deviseGem時に自分で新しく設定したカラムもストロングパラメーターに含めることが可能（nicknameなど）。application_controller.rbに記載する。

 

・N+1問題（2回目！）

　アソシエーションによる該当箇所への複数アクセスが起こってしまう問題。解決策はincludesメソッドによる該当モデルの一括取得（コントローラーに「モデル名.includes(:紐付くモデル名)」と記述。）。

・case文

　ifを使わない条件分岐

case 対象のオブジェクトや式
when 値1
　# 値1に一致する場合に実行する処理
when 値2
　# 値2に一致する場合に実行する処理
else
　# どれにも一致しない場合に実行する処理
end

・whereメソッドとLIKE句

「c」が含まれるタイトルの検索方法は、

　where('title LIKE(?)', "%c%")

　検索機能の実装で使うメソッドでモデルに記述する。

・ルーティングのネスト（2回目！）

　あるモデルと紐ついている別のモデルのid情報をパラメーターに含めるためにネストさせる。

　resources :親となるコントローラー do
　　resources :子となるコントローラー
　end

・rails_12factor

　Herokuでデプロイする場合に必要。Gemfileに以下の記述を追加し、　bundle installする。
　group :production do
　　gem 'rails_12factor'
　end

・heroku addons:add cleardb

　herokuのデフォルトデータベースはPostgreSQLというデータベースなのでMySQLに変更するため

・外部キー制約（2回目！）

　外部キーに対応するデータが必ず存在しなければならないという制約。マイグレーションファイルに「foreign_key: true」と記述する.

・not null制約

　テーブルに空の値が入らないように制限する。マイグレーションファイルに「null: false」と記述する。

・Devise

　カラム名はデフォルトで「encrypted_password」となる。

・テーブルの型

　生年月日はdate型で保存。

　長い文章はtext型。

　金額などの数値はinteger型。

・Active Storage

　ファイルアップデートを簡単に実装できるGem。画像を保存するテーブルは自動で形成されるので自分でテーブルを作る必要はなし。

・utf8

　database.ymlにはデフォルトで「utf8mb4」でデータサイズに制限がかかっているので「utf8」に変更する。

・devise

　パスワードの６文字制限はデフォルトで実装されているのでバリデーションでlengthを定義する必要はなし。

・文字列変換

　.to_i→数値変換、.to_s→文字列変換

参考）chompメソッドは、文字列が使用できるメソッド。
chompメソッドを使用すると、文字列の末尾に存在する改行を取り除いた文字列を返してくれます。

・正常系・異常系テストコードは分けて記載する。

 

**マイグレーションファイルの修正**
マイグレーションファイルは基本は編集しない！！
編集するときは必ず**rollback**を行う必要がある。基本的にrollbackはすべてのマイグレーションファイルを戻してしてまうので、指定したいときは、
``` rails db:migrate:up VERSION=20080906120000 ```
と記述する。

**バリデーションは難しい**

商品管理機能で一番の山場はバリデーションだった。


qiita.com

validates :age, numericality: true
またnumericalityには便利なオプションが多数用意されています。

オプション 概要
:only_integer integerのみ
:greater_than 指定された値よりも大きいか
:greater_than_or_equal_to 指定された値と等しい、あるいは大きいか
:equal_to 指定された値と等しいか
:less_than 指定された値よりも小さいか
:less_than_or_equal_to 指定された値と等しいか、あるいは小さいか
:odd trueに設定した場合、奇数か
:even trueに設定した場合、偶数か
 

 

**numericalityとformatの違い**

価格のバリデーションで一番苦戦したところ。メンターさんに頼ってしまったのであとで調べなきゃ。。

 

**2重ハッシュの取り出し方**

user_data = [
{user: {profile: {name: 'George'}}},
{user: {profile: {name: 'Alice'}}},
{user: {profile: {name: 'Taro'}}},
]
この配列からnameキーだけを取り出したいときの方法。

[:user][:profile][:name]
この二重ハッシュだけではエラーが出る。なぜなら配列の中に複数のハッシュが格納されているので、これだけだとどのハッシュから取り出すのかが指示されていないのでエラーとなる。

配列の中に複数のハッシュがある場合には、each文を使って上述の二重ハッシュを各ハッシュで適用する以下の指示を行う必要がある。

user_data.each do |u|
puts u[:user][:profile][:name]
end
 

**herokuエラー**

ローカル環境では投稿ができていたのに、デプロイを行ったらエラーがでてしまう状況になってしまった。

色々苦戦したけれど、内容としては

*マイグレーションファイルの順番が違った*

ということ。itemテーブルにuserが紐ついているのに、ファイルの順番が、item user active_storage だったのでエラーが発生。順番は、~~item~~ user item  active_storage が正しかった模様。なぜかローカル環境ではうまく行ってので気が付かなかった。

マイグレーションファイルの順番を正しくした上で、

```

rails db:migrate:reset

```

を行うことで修正できた。

ちなみにメンターさんに教えてもらったheroku上でマイグレーションをリセットするコマンドは以下。

heroku run rails db:migrate:reset REILS_ENV=prodction DISABLE_DATABASE_ENVIRONMENT_CHECK=1

・ クラスメソッドとインスタンスメソッド

　クラスメソッド；個別の情報によらず共通の結果を返す動作を定義するメソッド

class クラス名
  def self.メソッド名
    # 処理
  end
end

　呼び出し方は次の通り。

クラス名.メソッド名(引数) 

　インスタンス変数

定義は以下の通り。

class クラス名
  def メソッド名
    @変数名 = 値  # インスタンス変数
  end
end

＠をつけるインスタンス変数の特徴は、おなじクラス間であれば利用できること。＠をつけないローカル変数は定義してあるインスタンスメソッド内（def~end）でしか利用できない。

つまり、クラスメソッドを使って引数を渡したいときにはインスタンス変数を使って利用できる範囲を広くしておかないといけないということ。

なお、インスタンス変数はクラスが呼ばれるたびに実行するため、initializeメソッドを定義するのが一般的。

イメージはこんな感じ。

class クラス名
  def initialize
    # インスタンス生成したときに実行される処理（以下は例）
    puts "クラス名のインスタンスが生成されました"
  end
end

インスタンス = クラス名.new  # initializeメソッドが呼ばれ文字が表示される

・.orderメソッド

　コントローラーのindex定義に記載することが多い。定義したモデルのテーブルのカラムをどの順で表示するかを決めることができる。

通常のアプリは新しい投稿が上に来るようにするので、その場合にはDESC（降順）、逆にしたいときはASC（昇順）。

インスタンス = モデル名.order("並び替えの基準となるカラム名 並び順")

 

<気付き>

割とサクサク進んで、削除機能までデプロイ完了。

明日から山場とされる商品購入機能。頑張ろう。