【第30週】パRails輪読会🚂 (2024-03-18~ 2024-03-22)

tags: パRails🚂

目次

2024-03-18(月)

ファシリ

@ayu-0505

ドライバー

読んだところ

13-2 「コールバックオブジェクト」から
13-2-4 510p　の途中まで。
PR:

次回

13-2-4 510p 「▫️更新系の場合」から🚂

学んだこと・感想

  • @sharoa

    • モデルのコールバックは【コールバックを実装するブロック、コールバックを実装するメソッド名のシンボル、コールバックを実装するオブジェクト】のいずれかをbefore_saveをはじめとした各メソッドの引数に指定して呼び出すことで設定できて、そのうち最後のオブジェクトのことをコールバックオブジェクトと呼ぶらしい。
    • このコールバックオブジェクトはモデルとは独立したクラウをとして定義されるため、複数のモデル間で再利用できる。
    • コールバックオブジェクトを単独で利用するのではなく、Consernと一緒に使うことで色々と使いやすくなる？みたい。
    • でも結局Consernだけでも同じことは実現できるって。わお。
    • コールバックオブジェクトを利用すべきかという疑問が生まれることもあるらしい。Consernの時にも似たようなこと言ってたな〜と思いました。

  • @ayu-0505

    • コールバックオブジェクトとは、モデルとは独立したクラスとして定義されるオブジェクト。
    • Concernsにまとめることでさらに共通化、抽象化することができる。（ただし、わかりにくさにも繋がる）
    • FBCのコードはこういう内容の現状における最適解が分かりそうで勉強になりそう
    • 久しぶりに参加できて嬉しかったです！

@moegi29
- コールバックオブジェクトを今回の例ではmodelの中で使っているけどもっと共通化したい場合はconcernディレクトリの中で使うみたい
- コールバックオブジェクトはブートキャンプアプリの中でも使われている。書き方を覚えておきたいと思いました
- __send__とsendは機能的には同じだけど再定義できる、できない部分で違いがある
- tapメソッドはtapの前のオブジェクトをブロック引数に渡してブロックを渡せるメソッド
- ついに明日最終回！

  • @sakanobu

    • リスト13.15,16の Concern の使い方がとてもなるほどなと思った
      • Model の before_save などのクラスメソッドの記述を手続き処理のかたまりと捉えることで、それらをリスト13.16で encrypt_attributes というメソッドで呼ぶ出せるように Concern を使えるというのはお〜となった
    • リスト13.17の send は皆さんがいてくれたおかげで after_find と after_save の記述の簡略化だとやっと理解できたので輪読会っていいなぁと改めて思いました

  • @shodan

    • Concernが混じったコールバックオブジェクトのところはすみません、だいぶ雰囲気で読んでいました😅
    • bootcampのコードとか、（必要になった時に）実際に見た方がピンときそうな気はします。
    • 最後の章はどれも単一のモデルの責務を超えるような複雑な内容をどうモデルから分離するか、ということがテーマになっていると思います。
      • 今回でいえば複雑なコールバック。

  • @motohiro-mm

    • コールバックオブジェクト：コールバックを実装するオブジェクト。
      • コールバックのクラスを定義してコールバックオブジェクトを導入できる
      • 共通化して使える
    • コールバックオブジェクトをあちこちで定義すると保守性が低下するので、コールバックオブジェクト単独で利用せず、Concernと併用すると良い
      • フィヨルドアプリは単独っぽい（利用している部分が少ないから？）
    • sendと__send__勉強になりました
    • .tap{pp _1}はメソッドがたくさんつながってるときに途中のselfが分かるので便利（そうにみなさん使ってました）
    • あとすこしでおわる！でも最後の最後まで難しい！

  • @sugiwe

    • コールバックを実装するオブジェクトのことをコールバックオブジェクトと呼ぶ。コールバックオブジェクトはmodelディレクトリとかにボンっと置いておいたりする
    • phone_numberを暗号化するメソッドをUserモデルに書いていた際、属性を暗号化するメソッドをUserモデルでなくコールバックオブジェクトに書くことで別のモデルでも再利用できるようになる
      • ただしそれだとまだUserモデルに少し記述が残っており、コールバックオブジェクトでなくConcernとして抽出することで完璧に分離できる。ふむふむ…？
    • tapメソッド、使いこなしたい
    • sendと__send__は動作としては同じっぽいけどsendは再定義できてしまうので、知らぬところで再定義されている可能性を考慮して__send__を使うと良いらしい…？（予約語みたいに（？）、再定義できなければいいのにとも思った…）
    • 「最後の章はどれも単一のモデルの責務を超えるような複雑な内容をどうモデルから分離する」わかりやすかったのでこちらにもメモ📝

2024-03-19(火)

ファシリ

@motohiro-mm

ドライバー

読んだところ

13-2-4 510p 「▫️更新系の場合」から
520P　最後まで
PR:

次回

終わり〜！🎉

学んだこと・感想

  • @sharoa

    • 更新系（データの暗号化など）のデータ操作（Create,Update,Delete）に関するロジックの場合の実装にはコールバックオブジェクトが利用できるが、参照系（木構造のデータ取得など）のデータ操作（Read）に関するロジックの場合にはコールバック自体が利用できない。
    • Consernでも同じようなことはできるが、更新系は特に理由がない限りコールバックオブジェクトを利用した方が良い
    • 上にも書いたように参照系はコールバックが使えないので、Consernを利用すると良い。
    • テストコードの件が難しすぎて、聞くことしかできなかったです。最後の最後まで難しすぎて流石だわって感じでしたw
    • 約７ヶ月のパrailsの輪読会でした。
    • 私の体調不良でだいぶ日数を奪ってしまい本当に申し訳ないです。
    • そして、みなさん最後までありがとうございました！！

  • @sugiwe

    • 更新系（Create、Update、Delete）に関するロジックの実装にはコールバックオブジェクトを使うことができる。
    • 木構造＝ツリー構造。階層構造のこと
    • 更新を伴わない操作、つまり参照系のデータ操作（Read）にはコールバックを使うことはできない。コールバックを呼び出すタイミングがないから。
    • リスト13.18の読み解きがほとんどわからなくてフリーズしていましたが、とにかくフィナーレに参加できてよかったです😄
    • パRails、1人だと確実に挫折していたので輪読会に参加できてよかったです、ありがとうございました◎
    • Railsをまた復習するためにRailsチュートリアルあたりやってみようかな…

  • @moegi29

    • 更新系のデータ操作に関するロジックの場合、テストがしやすいためコールバッグオブジェクトを使うと良い
    • コールバッグオブジェクトを使っているとmockでテストができる。mockはテスト用の空のオブジェクトのようなもの(sakanobuさんからの引用)
    • Concernでも同じことが実現できるけどテストダブルへの置き換えが難しく本物のオブジェクトを用いてテストするので大変
    • パRails輪読会ついにフィナーレ！自分ひとりでは全く理解できなかった部分がたくさんありみなさんの議論を聞いて理解できた部分もたくさんありました。ありがとうございました！！

  • @shodan

    • チーム開発でもmockを触らなかったので、このあたりはふわっとしたままだな〜という感想。
      • IssueによってはWebAPIのモックを作ったり触ったりするかも。
    • パRails全体について
      • 3章くらいまでのところについて、なんだかんだ何度もパラパラめくり返して「おお〜」っとなったりしていたので、基本が全然身についていないんだな〜と思います。
      • イベントアプリを作る流れでさらっと説明される便利メソッドとかよくあるパターンとかがたくさんあった気がするので、読み返して付箋を貼りたい。
      • 12章以降のところは、いつか困ったら参照できるお守りという気持ちで今はいます（これでいいのかはわからない）。
        • でも世の中のすごい人たちは大体この辺のことの知見をシェアしているような気もする。
      • Action Cable, Action Textとかは使うことがなければ完全に忘れていきそう（使うことはあるのだろうか）。
      • Active JobやRackあたりは引っ越しやら何やらで出れなかったんですが（この辺の方がむしろ大事そう）、おおまかに出席できて完走できて嬉しいです。

  • @ayu-0505

    • データの暗号化といった更新系データ操作ロジックの実装ではコールバックオブジェクトを利用できる
    • コールバックオブジェクトを使わず、Concernのみでも同じような実装はできるがテストのしやすさなどから、コールバックオブジェクトを使う方が良い
    • テストダブルとはテスト用に用意するダミー品。モックはその中でも出力を調査するために使用する。
    • データ操作ロジックにおいてはコールバック自体が利用できない（それはそう）。この関係のロジックではConcernを利用する。
    • 最初の方のパRails輪読会に参加できなかったのが悔やまれます、本当に参加できてよかったです！

  • @sakanobu

    • Concern 内でコールバックオブジェクトを利用するかの判断が、その Concern が before_save などの更新系なのかそれとも参照系なのかというのは言われて見れば単純明快な基準だなと思いました
    • mock についての Discord に書いた自分のメモなのですが、今読み返しても「変なこと書いちゃったな…」みたいな部分が多々あるので「ふーん？」みたいな参考程度で読んでくれるとありがたいです(後で修正しようと思います)
    • パRails輪読会には Docker あたりからの参加になってしまったのですが、ラジオ参加にもかかわらず皆さんが暖かく受け入れてくれたのでとても嬉しかったです！！本当にありがとうございました！！

  • @motohiro-mm

    • 更新系（create,update,delete）の場合はコールバックオブジェクトが利用できる
    • 参照系（read）はコールバックオブジェクトが利用できない
      • そもそもコールバック自体が利用できない、データ操作と関係ないから
    • コールバックオブジェクトを利用すると、テストダブル（モックとか）に置き換えられるのでテストが容易になる
      • コールバックオブジェクトを利用せずにConcernのみでやった場合は本物のオブジェクトを使ってテストするので手間がかかる
    • ぱRailsおわった！！！みなさんのおかげで最後までいけました！！！感謝です

  • @sadanora

    • コールバックオブジェクトとConcernどちらが適当か、データ操作が更新系か参照系かによって判断できる
      • 更新系の場合、コールバックオブジェクトの方が適当
        • Concernでもできるけどコールバックオブジェクトの方がテストが楽になる
        • コールバックオブジェクトでは、自身を利用するオブジェクトが外から渡されるため、これらをテストダブルに置き換えることで容易にテストできる
        • Concernの場合テストダブルへの置き換えが難しく本物のオブジェクトを用意しないといけないので、コールバックオブジェクトを使う場合より手間がかかる
      • 参照系の場合、コールバックを伴わないのでConcernのが適当
    • 完走おつかれさまでした！一人でちゃんと読みきれなかったので輪読会で最後まで読めて感謝です！
      • 今後も詰まった時にちょこちょこ開いて理解度を深めていきたいと思います

2024-03-21(木)

ファシリ

ドライバー

読んだところ

PR:

次回

学んだこと・感想

2024-03-22(金)

ファシリ

ドライバー

読んだところ

PR:

次回

学んだこと・感想

Select a repo