Kaigi on Rails 不参加記 Part4
Kaigi on Rails 不参加記とは #
Kaigi on Railsには参加してないけど最近Rails周りなんもキャッチアップしてないと焦っている人間による、公開されている資料を見ての適当な感想を書く記事です。
運営の方々、発表者の方々、資料まとめてくださっている@hassanさん、その他皆々様ありがとうございます！！！！！！！
part1
part2
part3
資料ごとの感想 #
Hotwire的な設計を追求して「Web紙芝居」に行き着いた話
- Hotwireにはそんなに興味があるわけではないけど、複数のアプローチを比較して検討しているのがすごい
- アプローチを言語化して他人伝えるって大変だと思う
- 当初考えていた境界に別軸の境界がある話、ある
- スライドを見ていておもったけど、Hotwire単体だけでもこれだけ考えることがあって、プログラムを書くってめっちゃ大変だよなぁと思う
- この資料を見せたうえでWeb紙芝居でいきましょう！という提案ができればいいけど、現実は部品的アプローチをしてから、Web紙芝居に移行したくなりそう
- その時にWeb紙芝居にアプローチを変更するのは果たしてできるのだろうか？
- Web紙芝居もさらなる問題が出てくるかもしれないのに？
- 設定より規約という世界において、その規約をどう伝えていくのかが本当に難しいと思う
- 特に継承使うと、Aさんの脳内規約とBさんの脳内規約がぶつかってすごいことになってるのをよく見る
- ソフトウェアを多人数で作るってまじでむずかしいな
- 僕は一人では何も作れませんが…
管理機能アーキテクチャパターンの考察と実践 / Learn Architecture through Admin
- チャーンと新規契約のどっちが大事かってどこのフェーズで切り替わったりするのかな
- 最初からどっちも大事か
- 自分の中になかった視点としては、エンドユーザーと管理者の間で解決したい問題領域が同一か？という視点
- 大体の場合同一だと思うけど、ここをバックエンドを分離させない理由として持ってくるのは良さそう
- admin系SPAのライブラリってたくさんあるよね…
- 高速に動作するUIでストレス軽減というのはそんなにわかってない
- ただ速いだけなら既存のRailsのview + 適当なCSSフレームワークでも十分な気はする
- 既存の機能の運用に影響がでないか？も考慮にいれたい
APMをちゃんと使おうとしたら、いつのまにか独自gemを作っていた話
- あるある全てわかる〜〜〜〜〜〜〜〜〜〜
- わかりすぎてわかり徹也になっちゃう
- SQLの発行場所がわからない
- ソレソレソレソレ
- Ruby での処理が重いケース
- ソレソレソレソレ
- どこを手動トレースするかって結構難しそう
- 手動で怪しいところをトレースするのは良さそう
- jsonのrenderとかでめっちゃ時間かかってる処理とかよくわからないがち
- StackProfでシュッと見つけられるようになりたい
自分の道具を自作してつくる喜びを体感しよう、Railsで。 〜4年続いたPodcastを実例に〜 / Kaigi on Rails 2023
- Railsでものを作るっていい話
- ロギング用URLに飛ばしてからキャッシュの聞いたURLにリダイレクトするの賢い
- 自分の趣味の面倒みてくれるのは自分だけ！
- Railsのエコシステムはすごい！本当にすごいんだ！
- なにか作ってみようという気持ちになる資料でした
ペアプロしようぜ 〜3人で登壇!? 楽しくて速いペアプロ/モブプロ開発〜/pair-mob-programming-kaigi-on-rails-2023
- 発表者が三人！？
- ペアプロやモブプロ、疲れるけど本当に有効なんだよな
- まず考慮漏れや不具合が圧倒的に減る
- このスライドの通り、まちがいの発見は早ければ速いほど良い
- 終わらないレビューも最初だとあるよね
- あと他人に監視されてるからダラダラしないというのも正直大きい気がする
- メリットがしっかり言語化されてて勉強になりました
- 生成されてるっぽいイラストがキャッチーで良い
- 履歴を本当に永続化のためだけに使うなるほど
- 開発環境ではなかなか想定できないデータ量だと、クエリ書くのも気を使いますね
- こういうのもあってincludesじゃなくてpreloadとeager_load使い分けたいというのが出てくるんだろうな
- BIGINTの対応漏れの対処法、知見すぎる
- こういう、苦しいけどサービスは動かし続けなければならない状況でどうしたか？っていうのは本当に参考になる
- パスキーって単純に多要素認証なのか
- 公開鍵みたいな感じなんですね
- 認証まわりの実装って「本当にこのロジックでRFCに沿えているのか…」ってめちゃ不安になるよね
- そもそもwebauthnって単語とパスワードレス結びついてなかったので勉強になった。
Kaigi on Rails 2023 - ActiveSupport::CurrentAttributes: すっごく便利なのに嫌われ者？！
- evilmartiansのOSS一覧の資料社内にテンプレありそう
- ActiveSupport::CurrentAttributesはマルチテナントのGem掘った時にみましたね
- スライドにもあったけど、反対意見の記事も読んだ
- 値がどのタイミングでリセットされるのかとか内部実装を知らないとテストがしにくいというはわかる
- テスト内でセットしたはずの値は実際にはリセットされてnilになってるとかね
- 適切なテストが難しそうで、アプリケーション内の自分たちでメンテするコードにはあんまり使わないほうが良いかもなぁとは思います
- 値がどのタイミングでリセットされるのかとか内部実装を知らないとテストがしにくいというはわかる
- 道具箱の一つという感じで捉えるのが良さそう
コードカバレッジ計測ツールを導入したらテストを書くのが楽しくなった話
- カバレッジ100％に意味はないが、カバレッジ99％には意味があるって言葉どこかで読んだ
- 研鑽Rubyだった気がする
- branch coverageってC1カバレッジともいうのか
- 31％とかみると自分が今まで働かせてもらっていたプロダクトのカバレッジってめちゃ高かったんだなと思う
- モデルは100％に近いし、コントローラーも90％くらいあった
- 最初に必要なのは統合テストだけど、詳細に書くべきはモデルだよなぁと思う
- モデルに全部入れとけ脳なので…
Hotwire を使って管理画面を簡単にプチSPA化する - Kaigi on Rails 2023
- Hotwireって結構みんな注目しているイメージ
- 使わない現場だと本当に使わない
- もともとSPAの知識があって、「SPAのあれHotwireでどうすりゃいいの？」が出てくるともっと興味を持って読めると思った
まとめ #
どの資料も勉強になりました！ 改めて運営の方々、発表者の方々お疲れ様です。
スライド読んで関連記事読んでってしてると知識が広がっていく感じがしていいですね。結構勉強になったので来年もやろうかな。
RubyKaigiは感想が「なんかすごい！」で終わることが多いので、Kaigi on Railsの資料はその点ちょうど良いなぁと思いました。
あと箇条書きの散文形式だと書きやすい。読みやすくはないけど。