# 【第5週】パRails輪読会🚂 \(2023\-09\-19\~ 2023\-09\-22\) ###### 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] ------ ## 2023\-09\-19(火) ### ファシリ @motohiro-mm ### ドライバー @hiromisugie ### 読んだところ 2-5-3 109p 「Slim」から 115p 2章終わりまで。 新しいリポジトリ: https://github.com/hiromisugie/Perfect_Ruby_on_Rails_Ch3 ### 次回 116p 第3章から。🚂 ### 学んだこと・感想 - @sharoa - 前回の続きのテンプレートエンジンで、ERBよりもHamlよりもSlimが一番便利そうと思いました。Hamlもシンプルだけど、それよりもさらにシンプルな記法ですっきり見えて良い。 - Railsでは組み込みでJbuilderというgemパッケージを利用していて、これを使うことで宣言的にJSONデータを整形できる。 - 「!」で終わるメソッドには特殊ないみがある。「!」で終わらないメソッドはそのままJSONのキーになる。 - 目の前で実行結果が見れて良かった。 - Model層。Controller層、View層。それぞれ大事なのことで、また勉強し直したい。 - @sadanora - slimは閉じタグ書かないのが楽なのですきです。 - 最近viewのトピックが長かったので、「MVCのまとめ」が出てくるまでModelとControllerの話が出てきたの忘れていた。 - RailsのAPIモードの説明むずかしい。 - ちゃんとした説明はRailsガイド https://railsguides.jp/api_app.html を読めばいいとして、噛み砕くとどうなるだろう? - フロントエンドなどを別の何かに任せて、APIサーバーとしての機能に絞ったモード? - 「ビューを切り離す」みたいなことも言ってしまったものの、フロントとバックエンドを完全に切り離すシステム構成ならそう言えるかもしれないけど、正確じゃない気がする。 - 説明がまとまらないので勉強します。 - @moegi29 - slimはHamlよりも簡潔な表記ができる。タグの表記に%を使用しない。 - rails newするときに--apiオプションをつけるとRailsアプリをAPIサーバとして用いることができる。API専用のRailsアプリとはMVCのVの部分を切り離すということ。Railsは構成の仕方次第でいろんな使い方ができる。 - MVCについてのまとめ、主要なロジックはモデルに書く。ビューとコントローラーはそれぞれのレイヤーでしかできないことに注力する。 - @motohiro-mm - HTTP APIのサーバとしての振る舞いが求められるときは、RailsのビューはHTMLを出すのではなく、JSONなどで必要な情報を返す - `rails new アプリ名 --api`:通常のアプリケーションからAPIサーバとして不要な機能を取り除いたアプリケーションを生成できる - Railsは組み込みでjbuilderというgemを利用できる - アプリケーションの主要なロジックはモデルに書くべき! - @hiromisugie - `slim`は簡潔かつ高速。簡潔すぎてあまり使いたく無いと思っていたけど、高速とのことなので、がんばって慣れた方が良さそう - APIモードを使うとビューテンプレートとかは生成されなくなる。 - FBCに入りたての頃から最近まで、卒業生の自作サービスとかで「バックエンドはRails(API)、フロントはReactで構築しました〜」みたいなことを読んだり聞いたりて、何のことかサッパリわからんけどなんかカッコイイなと思っていたが、今ならなんとなくわかる…! - 確か、Hotwireは逆にJSを(ほぼ)使わずにRailsでアプリを作れる的なものだったような気がする - 主要なロジックはなるべくモデルに書くべきという話。ちょうどプラクティスの修正で直面していたのでタイムリーでした。Fat Modelについては、初心者はまずFat Modelにするくらいのつもりで良い、的なことも見かけました。 - 新しいリポジトリの作成は経験しにくいので、皆さんに助けていただいて作ることができてよかったです! - @cellotak - SlimはHalmよりも簡潔で、なおかつ高速なテンプレートエンジン。erbよりもコメントアウトしやすくて便利。 - クライアントとサーバがより厳密に分かれるパターンでは、RailsをHTTP APIとして利用する場合がある - 複雑なJSONデータを構築する場合jbuilderを使うことで整形できる - jbuilderでは `!`で終わるメソッドには特殊な意味があり、`!`で終わらないメソッドはそのままJSONのキーになる - Enumerableオブジェクトをブロック構文の第一引数に渡すと、ブロックを繰り返してJSONの配列に展開してくれる ------ ## 2023\-09\-21(木) ### ファシリ @sadanora ### ドライバー @motohiro-mm ### 読んだところ 第3章あたまから 3-1-2 119pの途中まで。 PR:https://github.com/hiromisugie/Perfect_Ruby_on_Rails_Ch3/pull/3 ### 次回 3-1-2 119p の途中、「実行例では~」から。🚂 ### 学んだこと・感想 - @sharoa - 3章に突入しました。「押さえておきたいRailsの基本機能」ということですが、現実のアプリケーション開発を行う場合にさまざまな問題が発生するが、そういったありがちな問題にたいしてRailsの基本機能で対応できるものもある、とのことなのでこの章もしっかり読んで予習ができたらな、と思います。 - Railsでは標準でテストを実行する環境が整えられているため、scaffoldでコード生成すると対応するテストコードも生成される。rubyのときに比べて勝手に生成してくれるのは楽?? - @motohiro-mm - エッジケースの検証 = 境界値周りのテスト のこと - エラーが続いてすいません。みなさんに教えていただいて進められてよかったです - テストは苦手なので頑張ってついていきたいと思います - @sadanora - エッジケース - 境界値テストのこと - webpacker周りのエラーむずかしい - @hiromisugie - Railsでは標準でテストをする環境が整えられており、scaffoldでgenerateすると自動的にテストのファイルも生成される。 - たくさん生成されるが、ディレクトリごとにテストの観点が異なっている。 - VSCodeのターミナルで出たエラーの、ファイル名&行数のところを`⌘`+クリックすると、該当するファイルの該当する部分が開くというのを初めて知った! - @cellotak - ディレクトリごとに観点の違うテストを書く - `bin/rails test`を実行することでテストを実行できるが、テスト用のDBの設定を反映しておく必要がある - webpacker周り、難しくてよくわからないです、、 - @moegi29 - 「エッジケースでの検証」と出てきてエッジケースがわからなかった、エッジケースは境界値周りの検証を行うためのテストケースのこと。 - ディレクトリごとにテストの観点が異なる。システムテストは、アプリ全体を結合して動作を検証するE2E(エンドツーエンド)テスト - Railsのテスト環境構築、webpackerむずい ----- ## 2023\-09\-22(金) ### ファシリ @moegi29 ### ドライバー @hiromisugie ### 読んだところ PR:https://github.com/hiromisugie/Perfect_Ruby_on_Rails_Ch3/pull/4 ### 次回 3-1-8 126p 「Rails 6.0で追加された並列テスト」から。🚂 ### 学んだこと・感想 - @sharoa - Railsのテストはminitestをベースとしたテスト。 - それぞれのレイヤーごとに拡張されたテストクラスを継承することでより簡単にテストを記述できるようになっている。(らしい) - minitestに標準で組み込まれている`assert`が多い! - railsで拡張したassertメソッドもいくつかあるとのこと。 - `fixture`はモデルクラスに対応するテストデータをあらかじめ定義しておくもので、YAML形式で定義できて、定義したデータに対して名前をつけることができる。覚えておこう。 - テストケース実行前後に実行されるメソッドとして、`setup`と`teardown`が用意されている。これも覚えておこう。 - @hiromisugie - テストは、ディレクトリ単位・ファイル単位・ファイル内の行数単位・テスト単位のそれぞれで指定して実行できる - よく使うテストフレームワークは、minitestとRSpecで、RailsのminitestはRubyのminitestを拡張したもの。継承がたくさん出てきてややこしい…。 - minitestには標準で色々なassertが組み込まれているし、さらにRailsで拡張したassertメソッドもある。 - `asser_equal`くらいしか記憶がないので色々覚えていきたい。 - fixtureを使うとテストデータを作れるが、複雑になりやすいので7章で別の方法が出てくるらしい - テストケースの実行前に`setup`メソッド、実行後に`teardown`メソッドが実行されるらしいが、それぞれputsで目印を出したところ以下のようになり、`setup`と`teardown`の間でテストが行われているのかどうかがよくわからなかった。 ``` call setup call teardown TodosControllerTest#test_should_show_todo = 0.04 s = . call setup call teardown TodosControllerTest#test_should_get_new = 0.01 s = . ``` - @moegi29 - 詳細なテストケースを確認する場合は-vオプションをつける。 - 例えば`test_the_truth`のように_でつなぐとテスト名を指定して実行できる。 - minitest::Testを継承したものがいろいろある - fixtureはモデルクラスに対応するテストデータを定義しておくもの - setup テスト teardown テスト結果の順で表示 - @motohiro-mm - vオプションで実行結果のレポートが出力される - ActionDispatch::IntegrationTest < ActiveSuppert::TestCase < Minitest::Test と継承している - それぞれさらに拡張されている、らしい - `assert`はtrueになるとテストが成功する。メソッドの種類もたくさんある - fixtureでテストデータをあらかじめ定義しておくことができる(YAML形式) - setup → テスト実行 → teardown → テスト実行結果表示 の流れ - 並列度はよくわからなかったけど、次回やるみたいなのでそこで理解したい! - @sadanora - Railsのテストは素のRubyで使われるMinitestを拡張したもの - `Minitest::Test`を継承したクラスが色々ある - `bin/rails test -v`でテストの実行結果のログの詳細(実行時間など)を出力してくれる。 - `setup`と`teardown`でテストの実行前後で行いたい処理を定義できる。 - テストが成功したかどうかの実行結果の出力は`teardown`後にされているのが分かって面白かったです。 -----