銀座Rails#21で「Fat Modelの倒し方」を発表しました 〜質問・感想編〜

(image)銀座Rails#21で「Fat Modelの倒し方」を発表しました 〜質問・感想編〜

本記事は『銀座Rails#21で「Fat Modelの倒し方」を発表しました』の後編になります。

当日あった質問、発表してみての感想などを書きたいと思います。

当日の質問

ファイルの置き場について

質問の文脈としては「POROファイルの置き場ってどこ？」という内容でした。

発表中でPOROは「Modelの補助輪」という表現をしましたが、役割としてはModelにあたるので置き場所もapp/models配下で問題ないと考えます。

特別な置き場を作りたくなってしまうかもしれませんが、Railsの提供するMVCのレールを逸脱しない範囲で独自路線を作っていくのが個人的には良いアプローチかなと考えています。POROをモデルの延長線上にあるものと考えれば、app/modelsにPOROが配置されているのは不自然ではないかと思います。

もちろん app/models の内部でドメイン毎にnamespace（module）を持たせファイルを構造化していくのはアリだと思います。例えば下記の例です。

app/models
├── application_record.rb
├── domain1
│   └── plain_object.rb
├── domain2
│   └── plain_object.rb
├── domain3
│   └── plain_object.rb
|
...

app/modelsにフラットにファイルを置いていくと、テーブル数増加・コード肥大化とともにものすごい数になってしまいます。意味のある単位でディレクトリ（module）を切っておくのは今すぐできる手軽な構造化という意味で、早いうちに導入しておくと良いと思います。

trailblazer について

「trailblazer についてどう思う？」という話がありました。今回の発表にあたりtrailblazerはノーマークだったので、当日は「ちゃんと調べて触ったわけではないので、正直わかりません」という回答をしました。

trailblazer自体は、2015年頃にRuby Rogues Podcastで聞いて知っていて、当時は「へ〜、興味深いコンセプトのフレームワークだけど、Not for meかな〜」「RailsのMVC構造とは違って小難しそうなフレームワークだな〜」などと思っていました。

今回の発表を通して改めて trailblazer を評価してみると、Railsの巨大化にともなって発生するペインポイントを回避するためによく考えられたアーキテクチャだ と思いました。

trailblazer は「高度に抽象化（high-level abstractions）されたRubyフレームワーク」だと謳っています。「何と比べて高度か？」というと、明らかに「Rails（MVCアーキテクチャ）と比べて高度だ」と考えることができます。具体的にはMVCアーキテクチャと比べて、大規模化しても破綻しにくいアーキテクチャになっているかと思います。

trailblazer

一方でtrailblazerアーキテクチャの中には「Railsでもgemとか使えば表現できるよね？」っていう部分もあるのは事実だと思います。trailblazerのアドバンテージとしては gem拡張なし で 標準で 実現できる点と言えます。素の状態で破綻しにくいアーキテクチャが提供されています。

Hanamiにも共通して言えることなのですが、trailblazerを採用するときのディスアドバンテージはこんな感じでしょうか。

  • gem拡張に乏しい
    • やりたいことをやれるgemが転がっているか？
  • ハマったときのトラブルシュートの難しさ
    • ドキュメントは十分にあるか？
    • コミュニティは成熟しているか？
  • バグを踏んだときの問題解決の難しさ
    • アクティブなメンテナはどれだけいるか？
    • バグを報告したらすぐ反応して直してくれるか？
    • Pull Request を upstream にカジュアルに投げることができそうか？

上述したデメリットを考えると、Hanamiないしtrailblazerがどれだけ優秀なアーキテクチャであっても採用は慎重にならざるを得ないと言えます。

Ruby on Railsの優位性はRuby Webフレームワークの圧倒的デファクトになっていることです。gemエコシステムやコミュニティ、ドキュメント、ブログ記事がしっかり整っているのは圧倒的アドバンテージと言えるのではないでしょうか。

初リモート登壇してみて

セットアップ

今回の発表が初のZoomによるリモート登壇でした。

macOS + iPad の2画面をSidecarを使って実現した形となります。通常登壇だとスピーカーノートを手元のマシンに映して、プレゼン資料をプロジェクタに映して…とするところですが、リモート登壇だとプロジェクタにあたる部分が無いのでサブディスプレイは必須だなと感じました。

リモート発表ということもありネットワークが一番の心配事だったのですが、Google WiFiルーター ⇔ macOS とのネットワーク優先度をMAXにして、5GHz帯を掴むようにして発表に臨むことで、特に問題は発生しませんでした。

また発声がキレイに通るように、ノイズキャンセリングApp・Krispを導入していました（こちらから登録すると一ヶ月無料で使えます）。リモート時代には必須。

プレゼンツールはおなじみのDeckset。マークダウンでまとめられるのはGood、一方でデザインを凝ろうとするとパワポやキーノートより逆に大変なのでそのへんは課題感あります。

感想

正直な気持ちをいうと、「発表するならジェスチャーが使えて、オーディエンスの顔・反応が見れて、緊張感を持って臨めるリアル登壇が良いかなー」って考えだったのですが、コロナが長期化しそうな状況を鑑みて今回のリモート登壇にチャレンジしてみることにしました。

実際にやってみて良かったこととしては、お家環境で椅子に座ってノンビリ発表できるのでそこまで疲れないという点でした。あとZoomはリモート登壇にはとても便利なツール（良い背景画像が無かったので今回はバーチャル背景を使わなかったのが若干後悔）。

逆に難しいなと思ったのはやっぱりオーディエンスの反応が見えない点。ここは運営側でComment Screen環境を用意してもらえたことで、発表中のオーディエンスへの質問や反応はある程度見ることができました。またこれは登壇者側・参加者側どちらでもそうなのですが、リアル現場での懇親会のように発表後にカジュアルに話せないのはちょっと残念だなーと思う点です。

総じてリモート登壇を初めての体験できてよかったと思います。

あと今回いただいた30分という尺はある程度まとまった量の発表をゆっくり進行するには丁度良い尺でした。それ以上の長さになると発表者側もオーディエンス側もダレそうだなぁという印象。

Special Thanks

本発表はもともと銀座Rails#18で発表予定だったものです。改めての発表機会をいただき、銀座Rails運営の皆様ありがとうございました。

Rails Model の限界を考えるにあたり、yasaichiさん、hshiroyamaさんの発表を参考にさせていただきました。ありがとうございました。

関連記事