# 【第18週】パRails輪読会 \(2022\-11\-21\~ 2022\-11\-25\) ###### tags: `パRails(2回目)` - [開催概要](https://hackmd.io/rOcLR0riRqmOgEF0_Ssm0A?both) - [パRails輪読会 ノートまとめ](https://hackmd.io/5emISRvRRXapmakSiHnFJg?both) ## パRailsのサンプルコード・正誤表 - [サポートページ：パーフェクトRuby on Rails【増補改訂版】：｜技術評論社](https://gihyo.jp/book/2020/978-4-297-11462-6/support) - [パRails 環境構築の手順](https://hackmd.io/y7qb2BRMT2Wd4tAtKYObcQ) ## 目次 [TOC] ------ ## 2022\-11\-21(月) ### 連絡事項や確認・相談 ### タイムキーパー - LEFさん ### 読んだところ - P.455 [10-6-2 コンテナ内部のネットワーク設定]〜 ### 次回 - P.462 [11-2 値オブジェクト]〜 ### 自由に使う共有スペース ### 各自の疑問点や気づき、学んだこと - @fuwa - アプリケーションが対象とする問題領域のことをドメインと呼ぶ。いまいちイメージがつかめない。 - コンテナオーケストレーションは複数のコンテナを管理してくれるらしい - nginx復習しないと〜 - Saki - ドメイン/ドメインモデル/ドメインロジックが例えが分かれば理解を深められそう。「ドメイン知識」のドメインの意味と近そう - 単一継承をするかしないかの判断基準はメンターさんによっても考え方が違うみたいなので、自分が入ったチームの指標に合わせる形になりそう - kubernets(くーべるべっつ)と心の中で読んでいたけど全然違った。本当はクバネティス/クバネテス/クーべネティス - LEF - Dockerについては使い場面がイメージできますが、k8sについては使う場面があまりイメージできないので、暇なときにもっと深掘りしたいと思いました。 - ドメイン駆動設計のドメインとはこのことを指していたのかという気づきがありました。 - テーブルの継承について、もっと気をつけようと思いました！ - dawa - 実際にプラクティスが進んでいないので、そういうことがあるんだなぁぐらいの想像でした。Dockerも言葉は聞いたことはありますが、内容はわかりません。 - hikaru - Dockerもっと知りたいですね〜 - アプリケーションに落とし込む対象範囲＝ドメイン（勤怠アプリ） - ドメインの中の要素をモデリングしたものがドメインモデル（社員） - ドメインモデルはドメインロジックという振る舞いを持ったオブジェクト（社員.退勤） - ドメイン〇〇は概念 - DBにデータがある、これは実体 - 概念とデータを紐づけるパターンの一つがアクティブレコードパターン - アクティブレコードパターンを用いたライブラリがActiveRecord - @tomonari - kubernetesの呼び方がクバネティスというのがわかりました。内容については最初の方に理解を諦めました:cry:皆さんきちんと内容を理解しようとしてすごいな〜と思います。 - @haruguchi - ドメイン知識というと一般的な知識と対になる言葉ですかね - 専門的な知識とか、問題解決の対象となる知識と認識してます。 - パン屋のシステム作っているならパン屋に関する知識とかがソフトウェアアプリケーションの文脈でいうドメイン知識かな ### 本日の振り返り(よかった点・次回に向けての改善点・今の気分などなんでもOK) - LEF - 新しいパソコンにしてから音声出力がおかしくて、聞き間違えてしまったりするので、あとで設定を確認しようと思いました。 - JavaScript上達したい！ - @fuwa - 木曜からバイトなのですが、履歴書と職務経歴書が必要らしく慌てて書いています - チーム開発で詰まっていたところが解決しました〜結局3日くらいとんちんかんなことしてました！ - めでたい! - ありがとうございます〜！ - :tada: - dawa -　スムーズに司会させててすごいです！！ -　今日はこの後ペアプロしていただきます。進めるといいなと思います。 -　がんばってくださいー! - Saki - LEFさん、タイムキープだけでなくファシリテーターも上手でした!ありがとうございます👏 - 職務経歴書書くために企業研究してるんですが、材料が多いのもあって終わりが見えない..! - @tomonari - Bootstrapが思ったよりわかりません！ - hikaru - エキスパート！ - ドメイン知識がないので自作サービスアイデアだしが大変だ〜 - 昔買ったSoftwareDesign（2020/12月号）のDocker特集を読んでみたんですが、実践的でなかなか難しい - @haruguchi - ランニングしなくなって運動不足解消のため自転車を買いました。 - でも寒いので乗りたくないです。 - 👊 ------ ## 2022\-11\-22(火) ### 連絡事項や確認・相談 ### タイムキーパー - Saki ### 読んだところ - P.462 [11-2 値オブジェクト]〜 ### 次回 - P.469 [11-3-3 実装例]〜 ### 自由に使う共有スペース ### 各自の疑問点や気づき、学んだこと - hikaru - オブジェクトには２種類 - エンティティ：属性の値に関わらず一意に識別される - 値オブジェクト：値が同じであれば同じものとみなされる - Railsのモデルのインスタンスはid属性によって一意に識別されるエンティティ - Railsのモデルの属性を値オブジェクトとして定義すると何かといいことがあるよ - モデルをまたがる属性を値オブジェクトとして定義すると`compose_of`を使って色々なモデルから利用できるようになって便利 - サービスオブジェクトはドメインロジックを独立したオブジェクトとして定義したもの（e.g. 複数オブジェクトを組み合わせたもの） - Saki - money.rbの11.7のコードは、`include Comparable`で、比較演算を許すクラスのための Mix-inをincludeしている。 - そして`+`とか`-`など元々rubyで定義されてる演算子を自分が使う用に再定義することができる - サービスオブジェクトは卒業生の方の自作サービスでparuさんのbuzzcordやTsukadaさんの　サービスで使われてる。どちらもAPIにリクエストする処理があるので、そのあたりで使ってるぽい。 - [https://github.com/Paru871/buzzcord/tree/main/app/models buzzcord/app/models at main · Paru871/buzzcord] - お金扱うときは丸め誤差出てほしくないのでBigDecimal使う - @fuwa - エンティティ: 属性の値に関わらず一意に識別されるオブジェクト - 値オブジェクト: オブジェクトは異なるが値は同じオブジェクト - `compose_of` を利用すると値オブジェクトの表現が簡単になる - サービスオブジェクト: モデルに実装すると不自然なドメインロジックを独立したオブジェクトとして定義したもの。読み進めていけばもっとわかるかな？ - LEF - オブジェクト指向設計ガイドを自分も持っていますが、ほとんど読めていないので読みたいと思いました！ - Procやdelegateなど、Rubyで使われていたものがRailsでこのような形で使われているという気づきがありました。👀 - `+`, `-`の再定義（オーバーライド）や、宇宙船演算子`<=>`の実用例が分かって良かったです🛸 - 銀行関連のプログラムはバグが発生したらヤバそう💸 - @tomonari - phone_numberを別クラスに切り出すのがオブジェクト指向っぽいですね。composed_ofで利用するのも初めて知りました。 - チェリー本で読み飛ばしたprocの部分を読み直しておきたいと思いました。 - @haruguchi - あった！ - https://bootcamp.fjord.jp/reports/46204 - Rails理解するにはRuby力大事だなぁと改めて思った次第です。 - ProcはJSの高階関数とか勉強してからRuby戻ってやっとわかるようになった記憶がある - オブジェクトの等価性をもう少し大きくしたいというのが値オブジェクトの動機なのかな？ - 同じ値を持ってるオブジェクトは等しいと解釈したい ### 本日の振り返り(よかった点・次回に向けての改善点・今の気分などなんでもOK) - LEF - 最近顔だけ太ってしまったので、顔痩せしたいです。😶 - @fuwa - またしてもヒトカラに行ってしまいました。。声ガラガラですみません〜 - チーム開発でテストを書いているのですが、capybaraなんもわからんので勉強しないと〜 - Rubyの知識が不足してるな〜って実感しちゃいましたね。。 - hikaru - Javaで書かれていることを除けば、オブジェクト指向設計実践ガイドよりもミノ駆動本の方が読みやすいと思います！ - :eyes:気になる〜 自転車 vs ゲーム - 読みやすいんですね! - チーム開発から逃避していました... :tea::coffee::kobucya::orennjijyu-su: - そういう日もある!:tea: - Saki - 職務経歴書、やってきたことを書くのはそんなに大変じゃないけど、それをもとに「◯◯力があります!」って書くの難しいですね〜 - GitHubActionsってPRがコンフリクトしてると発動しないんですかね??FjordChoiceでHikaruさんのレビューされたPRの挙動が謎です... - :kininaru: - @haruguchi - えっ、明日休み！！！！！？ - ガラムマサラさん元気？ - @garammasala29 - 先週頑張りすぎて免疫低下して胃腸炎になってしまいました - wwwwww - お大事に...:cry: - みなさんの声が聞けて元気もらえました ------ ## 2022\-11\-23(水) 勤労感謝の日なのでお休みです ------ ## 2022\-11\-24(木) ### 連絡事項や確認・相談 ### タイムキーパー Hikaru ### 読んだところ - P.469 [11-3-3 実装例]〜 ### 次回 - P. 474 [12章　複雑なユースケースを実現する] ### 自由に使う共有スペース ### 各自の疑問点や気づき、学んだこと - hikaru - サービスオブジェクトにモデルのロジックを実装していくことでモデルの肥大化を防ぐことができる - サービスオブジェクトはロジックそのものなので状態を持たない - サービスに共通のロジックはモデルにまとめて実装する（高凝集が良いみたいな話？） - サービスの結果を記録する場合は（DBに保存する場合？）イベントを表現するモデルにする - その方がRails wayに沿っている - サービスオブジェクトはテストしやすい、イベントのモデルはその逆 - なんでもできるサービスにしないで具体化する - @fuwa - サービスオブジェクトを使う以外にもイベントを表現するモデルを使うというアプローチもあるので、どっちが良いかはケースバイケース。むずかしそう - モデルに実装すべきドメインロジックをサービスオブジェクトに書かないように気をつけましょう - @tomonari - サービスオブジェクト使い所が結構難しいみたい？ヘルパーメソッドやクラスメソッドもあるし、別モデルに切り出すという手段もあるようなので使い分けが分からないです。 - @Saki - モデルは状態を持つ。Userモデルのインスタンスはnameカラムとかの状態と持っていて、サービスオブジェクトは処理だけをさせるので、インスタンスに状態を持たない、という解釈。 - MVCの枠からは外れるので慎重に検討する必要がありそう - bootcampでのサービスオブジェクト(https://github.com/fjordllc/bootcamp/tree/main/app/models) - キャッシュの削除や通知で使われているっぽい - - @haruguchi-yuma - やっと追いついた。コールバックにロジックを実装するというのは文字通りp.471の`before_create`ですかね - サービスオブジェクトは複数オブジェクトを使ってロジックを表現したい時に候補に上がるらしい - `private_class_method`でインスタンス生成できないようにしているのなるほどと思った。(コラムのクラスメソッドを１つだけ公開しましょうのところ) - インスタンスを生成しないようにするんですね!知らなかったです👏 ### 本日の振り返り(よかった点・次回に向けての改善点・今の気分などなんでもOK) - @maimu_x2x - 2日間いなかったため、ついていくのに必死でした。。。結局よくわからなかったので読み直します！ - お弁当宅配のNoshデビューしました👶🏻 - きになる!おいしいですか??☺️ - 実はまだ届いていないため届いたら報告しますね😊 - 気になります！ - Saki - あれ、もしかして再来週には読み終わるかもですね! - 忘年会楽しみ!!まいむさん発表応援してます😍 - @fuwa - バイトで長時間マスクつけていたせいか頭が痛くて集中できませんでした〜かなしみ - お大事に😭 - チーム開発、ついに最後のissueがやってきました…！むずかしそう！ - https://github.com/fjordllc/bootcamp/issues/5779 - @tomonari - パRailsもあと40ページほどですね〜。年内には読み終わりそうです！ - maimuさん、ビブリオバトル楽しみにしてます！ - hikaru - サービスオブジェクトはミノ駆動本になかったですかね〜？ - 僕のチーム開発の懸案はバグが再現しなくなりcloseになりました - 前に調査した結果バグがすでに直っていて、でもポイントはいただけてたissueがあったと思います! - :tada: - @haruguchi - 読まなくていいです - おそらく設計に関わってくるものはチームで合意を取りながら実装していくと思うので使い所とか今そんなにガッツリわからなくても良いと思いました。 :waiwai: ----- ## 2022\-11\-25(金) ### 連絡事項や確認・相談 ### タイムキーパー LEFさん ### 読んだところ - P. 474 [12章　複雑なユースケースを実現する]〜 ### 次回 - P.481 [12-2-2途中 ■ActiveModel::Validations]〜 ### 自由に使う共有スペース ### 各自の疑問点や気づき、学んだこと - LEF - callbackを使うと、コードを順序立てて読めなくなってしまうため、必要なときに決め打ちで使ったほうが良いということが分かりました！ - 公式ドキュメントをすぐに調べられるようになりたいと思いました。 - hikaru - しれっと聴いていましたが、シリアライズ＝to_xmlやto_jsonのことだって初めて知りました。シリアル転送か？とかずっと思ってました。 - 同じことを悩んでた時期がありました　広義では直列化という意味らしいですね。 - https://discord.com/channels/715806612824260640/842263672104943636/986077129823375431 - ロジック２種類 - アプリの問題対象のロジック - ユーザーとアプリのやり取りのロジック - ユーザーとアプリのやり取り＝ユースケース - Railsのレール＝リソースとDBの一対一関係をベースにモデルに２種類のロジックを実装できるようにしている - ↑限界がある（純粋に使い回しが難しい、一対一関係が崩れた時など） - ユースケースのロジックを実装するレイヤーに分離すると良い - ActiveModelのモジュール群を使える - Saki - RailsはURLで表されるリソースをDBのテーブルと一緒に1対1に対応させており、これらのCRUD操作を通じてユーザーとやりとりする - アプリの機能が複雑になっていくにつれ、これから外れていく。 - コールバックを使うと、処理の流れが分かりにくくなるので、あんまり使いたくない。→たしかにbootcampで通知の処理でコールバックを使っていて、流れが分かりにくくなっていたので今gemを導入したり改善されてらっしゃると聞いた。 - @fuwa - ActiveModelを使うとモデルやコントローラーの肥大化を防ぐことができる - ActiveModelはActiveRecordの機能を自分で定義したRubyクラスに適用できる - @tomonari - ActiveModelを使うとActiveRecordと同じような機能を実装できる。 - serializationはオブジェクトの属性を表示できる？何かに番号をつけるのが思い浮かびますが、順番に属性を１個ずつ表示してくれるってことですかね。 - @haruguchi - POROで実装する時こういうの知ってるか知らないかで選択肢が変わりそう。 - 改めてRailsは複数のモジュールから成り立っているのを実感した ### 本日の振り返り(よかった点・次回に向けての改善点・今の気分などなんでもOK) - @maimu_x2x - いつも以上に遅刻してすみません・・・復習頑張ります！ - いえいえ!お仕事おつかれさまです:tea: - 先月のクレカ不正利用の後、ガス代の支払い方法変更を忘れていて督促が来てしまいました・・・ - 年末だからか？仕事で過去の遺産が掘り起こされて、これなんだっけ・・・？と思い出す作業に追われていますw - @fuwa - 今日は眠くて全然頭に入ってきませんでした。。 - チーム開発のissue、調査が難しいです〜 - LEF - ビブリオバトルの情熱プログラマー買いました！📕 - igaigaさんご参加頂き、ありがとうございました！☕ - フィヨルドカフェタイムも暇なときに参加したいと思います！ - @haruguchi - igaigaさんに質問できる輪読会なんて贅沢なんだ - Railsの練習帳にはお世話になってます - Saki - igaigaさんご参加くださりありがとうございました!そろそろ終わるのでその旨お伝えできたらな〜と思っていたのですが、来てくださって嬉しいです😄 - @igaiga - たのしく参加させていただきました！ありがとうございました！ -----