# 【第25週】パRails輪読会🚂 \(2024\-02\-05\~ 2024\-02\-07\)

###### tags: `パRails🚂`

- [開催概要](https://hackmd.io/4A_8ahJtQNi5hz713N5Y7w?view)
- [パRails輪読会 ノートまとめ](https://hackmd.io/jsgA8Pf_RVioOgSL_VOR4g)
- サンプルコード・正誤表：[サポートページ：パーフェクトRuby on Rails【増補改訂版】：｜技術評論社](https://gihyo.jp/book/2020/978-4-297-11462-6/support)
- **サンプルコードをダウンロードしただけでは、すぐに`rails s`できない可能性が高い**です。
以下のページに環境構築の手順をまとめたので、ドライバーをやってくださるという方は、こちらに沿って環境構築をお願いします🙏
⏩ [環境構築の手順 2022年版](https://hackmd.io/y7qb2BRMT2Wd4tAtKYObcQ)
⏩ [環境構築の手順 2023年版](https://hackmd.io/3_lnn8_QRD6wEjwFbWcBzQ)
💁‍♀️ [更新の手順 2章編](https://hackmd.io/pZAmF2EjSmyQ38lUtJ_CqA)

## 目次

[TOC]

------

## 2024\-02\-05(月)

### ファシリ
@sugiwe
### ドライバー
@shodan
### 読んだところ
9-3-1 423p コラム「Gitのコミット前フックを利用して検査する」から
9-3-2 「Breakman」まで。
PR:　https://github.com/PerfectRubyonRails-Rindoku/Perfect_Ruby_on_Rails_Ch6/pull/32
### 次回
9-4 「カバレッジ測定」から。🚂
### 学んだこと・感想
- @sharoa
- `rubocop`のデフォルト設定と、チームの方針が一致しないことはよく起こるらしい、そのために`rubocop`の設定ファイルを書いてチームで育てていくことが重要になるとのこと。
- `rubocop`をチームで議論しながら、必要な種別あるいはcopを加えていくのが設定ファルの育て方の一例。
- 検査されたくないコードの行があれば、`# rubocop:disable cop名`と書くことで検査をスキップできる。
- `--auto-gen-config`オプションをつけて、段階的にRubocopを導入する、の節は、画面で確認できたのがすごくよかったです。
- `Breakman`はrailsアプリケーションの脆弱性を静的解析してくれるgemのこと。

- @sugiwe
- Rubocopはチームで方針を揃えて活用していくのが大切。
- 何も考えずに`# rubocop:disable cop名`を増やしていってはダメ！
- `bundle exec rubocop --auto-gen-config`というように`--auto-gen-config`オプションを付けると`.rubocop_todo.yml`が生成されて、直すべき部分をtodo化してくれる。
- Rubocopは綺麗に書けているかどうかを見てくれる。Brakemanは脆弱性があるかどうかを見てくれる。どっちもやってどっちも直すべき。

- @moegi29
- Gitのコミット前フックを利用して検査する。検査されたくない部分には `#rubocop:disable cop名` を書くことで検査をスキップできる
- チームでRuboCopを育てていくという考え方がある
- RubyStyleGuideのトップページにロボコップの主人公のセリフ？が載っていてやっぱりRuboCopは映画のロボコップが名前のルーツなのかと思った。
- 規模が大きめなアプリの場合、--auto-gen-configオプションを使ってtodoファイルを作成して段階を踏んで修正していく

- @motohiro-mm
- Gitにはフック機能がある
- コミット前、プッシュ前などにRuboCopを実行するように設定できる
- `.git/hooks`のファイルに設定を書く
- RuboCopに検査されたくないコードは`# rubocop:disable cop名`と書くとその検査をスキップできる
- 途中からRuboCopを導入するときなど検出項目が多すぎる時には`--auto-gen-config`オプションを使う
- `.rubocop_todo.yml`が生成され、中は現在ひっかかっている項目が書かれている
- 修正すべき項目はそのまま`.rubocop_todo.yml`に残して、修正せずに残す項目は`.rubocop_to.yml`から削除して`.rubocop.yml`に移してRuboCopがひっかからないようにする
- `.rubocop_todo.yml`に残ってる項目を解消したら順に削除していく
- Brakemanは脆弱性に関係ありそうなところをチェックしてくれる

- @ayu-0505
- Rubocopの設定がチーム方針と相反する場合は設定調整する必要がある
- `rubocop:disable cop名`で検査スキップできる（多用は禁物）
- `--auto-gen-config`を使うとRubocopに設定するかどうかの判断をする用の.rubocop_todo.ymlファイルが作られる
- `Brakeman`gemはコード規約ではなく、Railsにおける脆弱性を解析する
- 久しぶりの学習の参加でした、嬉しいです。

- @shodan
- Gitのコミット前フックというものがあるということを初めて知りました。
- 対象のGit管理リポジトリの`.git/hooks`以下にスクリプトファイルを置く
- プッシュ前とか、マージ前とかいろんなフックがある
- 機密情報をコミットしないとか、こういうところでチェックできる？（専門のアプリケーションがあることも聞いたことがありつつですが）
- RuboCopには`--auto-gen-config`というオプションがある。実行時点でLintに引っかかった項目を、`.rubocop_todo.yml`にまとめてくれて、一時的にLintのチェックから除外してくれる
- もちろんこれを放置してはだめで、そこから段階的にLintが通るようにチェック・修正していく。
- チームのコーディング規約として抑制したままでいいLint項目は、`.rubocop.yml`にその除外設定を移し、最終的に`.rubocop_todo.yml`の方は消せるようにする
- BrakemanはRailsアプリケーションの脆弱性をチェックできるgem。
- 今回の場合、ストロングパラメータを通さず値を渡しちゃってる箇所とか、Railsバージョンの遅れとかを指摘してくれた。
------

## 2024\-02\-06(火)

### ファシリ
@sadanora
### ドライバー
@sugiwe
### 読んだところ
9-4 「カバレッジ測定」から
9-5-2 「Skylight」まで。
PR:
### 次回
9-5-3 「rack-mini-profiler」から。🚂
### 学んだこと・感想

- @moegi29
- カバレッジはアプリケーションのコード全体のうちテストコードにより実行されたコードがどれくらいあるか示す指標
- SimpleCovはカバレッジ測定するgem。ローカルでカバレッジレポートを表示してくれる
- CoverallsはCI上でテスト実行し、テストのカバレッジをWeb上でみれる
- 以前課題修正の時にgitでコンフリクトを起こしてしまい解消するのがとても大変だったことを思い出しました。gitは全然慣れないし難しい。。。すぎえさんドライバーお疲れ様でした！

- @shodan
- テストのカバレッジやパフォーマンスの数値などを測るgemや、Webサービスがある。
- Webサービスの場合、サービスに登録したときに発行されるトークンなどを環境変数に入れて実行したりする必要があったりする。
- gitで昨日の変更が今日の作業分が含まれてしまっていることが気になってしまって、そこから長い旅が始まってしまって申し訳ないです〜🙇‍♂️すぎえさん、ドライバーありがとうございました🙏

- @ayu-0505
- カバレッジ測定にSimpleCovというgemを使用するとテストコード実行時に測定レポートをHTMLで出力してくれる
- 並列テスト設定はオフにする（並列テストとは複数のプロセスを分岐させテストの実行時間を短縮する機能）
- CoverallsはGithubと連携してカバレッジをWebページ上で確認できる（CI実行時）
- skylightはパフォーマンスを測定して可視化するサービス
- ` git rm --cached`で追跡対象となったファイルのキャッシュを除外する
- `git add -p ファイル名`で対象ファイルの変更点をaddするかどうか行ごとに選択することができる
- すぎえさん今日のドライバー大変だったと思います。お疲れ様でした！

- @sharoa
　　- アプリケーション全体のうち、テストコードにより実行されたコード割合がどれくらいであるかを示す指標のことをカバレッジという。
　　- カバレッジを測定するツールの中にはカバレッジに加えてどのコードがテストされたか、されていないかのレポートを出力するツールもある。
　　- SimpleCovというgemを使う場合、テストコード実行時にカバレッジ測定結果をレポートをHTMLとして出力してくれる。
　　- 設定の注意点として、他のコードをrequireする前に書く必要がある。つまり、test_helper.rbのできるだけ先頭に近いところに書く。
　　- テストのカバレッジを表示してくれるWebサービスとしてCoverallsというものがあり、GitHubと連携して、カバレッジを Webページ上で確認できるもの。
　　- 今のところ個人でやるには設定諸々大変そうだったので、本やdemoを見てふむふむといった感じだった。
　　- gitの難しいところが久しぶりに出てきた回だった！マジでスギエさんお疲れ様でした！そして、ありがとうございました！

- @sadanora
- カバレッジ測定を支援してくれるgemが色々ある
- SimpleCov
- test実行時にレポートをcoverageディレクトリに生成してくれる
- HTMLなのでブラウザで表示して確認できる
- Coveralls
- GitHub ActionsのようなCIで実行するように設定しておくと、自動作成してくれたレポートをWeb上で確認できる
- skylight
- パフォーマンスを測定してくれるSaaS、でいいのかな？
- 設定するとskylightのサイト上でレポートを確認できる。
- `$ git add -p`でaddする範囲を行単位で指定できる！
- すぎえさんドライバーありがとうございました！

------

## 2024\-02\-07(水)

### ファシリ
@moegi29
### ドライバー
@ayu-0505
### 読んだところ
9-5-3 「rack-mini-profiler」から
10-1-2 「コンテナ技術」まで。
PR:　https://github.com/PerfectRubyonRails-Rindoku/Perfect_Ruby_on_Rails_Ch6/pull/34
### 次回
10-2 「基本的なDockerイメージの情報」から。🚂
### 学んだこと・感想
- @sharoa
- railsアプリのパフォーマンスを測定するgemに`rack-mini-profiler`というものがある。ローカルで動かすことができて手軽にパフォーマンスを測定できるとのこと。
- やり方としては、development環境でサーバーを起動して動かすと、自動的に画面左上にプロファイルを表示してくれる。
- 10章突入！！ということですが、初っ端から難しい内容でした。
- 昔は各環境ごとに設定手順書やスクリプトを手書きして、サーバを構成することが主流だったけど、色々な課題が出てきた。そうした中でコンテナ技術というものが登場したらしい。
- 次からはDockerに触れる。ついていけるよう頑張る。

- @moegi29
- `rack-mini-profiler`はローカルで動かせるRailsアプリのパフォーマンスを測定するGem。ブートキャンプアプリにも入っているらしい。
- Railsを本番環境で動作させるためには様々なコンポーネントが必要。
- Dockerによってアプリやミドルウェアの動作環境を丸ごとパッケージとして提供したり1つのOSの中で複数のコンポーネントを動作させることが簡単になった！
- 冪等：ある操作を1回行っても複数回行っても結果が同じであることをいう概念。10章にはいり冒頭から難しいワードばかりでついていけるか心配です。

- @sadanora
- `rack-mini-profiler`
- ローカル環境で手軽にパフォーマンスを確認できるgem
- Dockerに入って難しい用語のオンパレード
- 言わんとすることのイメージは分からなくもないけど、ふわっとしてる
- flyioにデプロイするときに、Docker使われてた気がする

- @sugiwe
- 昨日バタバタでメモをできなかった＆見れてなかったのですが、皆さんコメントありがとうございます…！
- rack-mini-profilerを使うと、ローカル環境でビューのレンダリング時間やSQLの実行時間などを確認することができる
- コンテナ。とっても便利なんだろうなぁと思いつつ理解はふわっとしている。前に苦労したElasticsearchなんかもDockerを使えば各々の環境を気にせず使えるってことっぽい。
- Docker、わかってないけど起動だけする機会があるのですが、すごくメモリを食う…。

- @ayu-0505
- rack-mini-profilerでRailsアプリのパフォーマンスを測定できる(左上に接続時間のリンクが表示され、詳細が確認できる)
- ローカル環境で手軽に動かせるが、レコード数の違いなどで本番との差異がでるので、development環境をなるべく本番に近い状態にする。（DB数など）
- Railsを本番で業務運用するには多くのコンポーネントを必要とする→インフラ構成テクニックが必要
- 冪等性、HTTPのプラクティスで出てきたのが記憶の底から呼び起こされた
- Dockerが登場したことにより、コンテナ技術をインフラ構成に利用できるようになった
-----