【第5週】パRails輪読会🚂 (2023-09-19~ 2023-09-22)

tags: パRails🚂

目次

2023-09-19(火)

ファシリ

@motohiro-mm

ドライバー

@hiromisugie

読んだところ

2-5-3 109p 「Slim」から
115ｐ　2章終わりまで。
新しいリポジトリ: https://github.com/hiromisugie/Perfect_Ruby_on_Rails_Ch3

次回

116p 第３章から。🚂

学んだこと・感想

  • @sharoa

    • 前回の続きのテンプレートエンジンで、ERBよりもHamlよりもSlimが一番便利そうと思いました。Hamlもシンプルだけど、それよりもさらにシンプルな記法ですっきり見えて良い。
    • Railsでは組み込みでJbuilderというgemパッケージを利用していて、これを使うことで宣言的にJSONデータを整形できる。
    • 「！」で終わるメソッドには特殊ないみがある。「！」で終わらないメソッドはそのままＪＳＯＮのキーになる。
    • 目の前で実行結果が見れて良かった。
    • Ｍｏｄｅｌ層。Ｃｏｎｔｒｏｌｌｅｒ層、Ｖｉｅｗ層。それぞれ大事なのことで、また勉強し直したい。

  • @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はモデルクラスに対応するテストデータをあらかじめ定義しておくもので、ＹＡＭＬ形式で定義できて、定義したデータに対して名前をつけることができる。覚えておこう。
    • テストケース実行前後に実行されるメソッドとして、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後にされているのが分かって面白かったです。
Select a repo