はじめに
Ruby/Railsの情報がだいぶ抜け落ちているので
あらためて復習も兼ねてこちらにまとめて行こうと思う。
07/02
Rails Developers Meetup
@a_matsudaさんの発表の中で出たgemを整理した。
Railsプラグイン
heaven_door
Capybaraのシナリオが書ける？
hocus_pocus
???
erb
ER図書ける？
roundabout
E2Eテストのカバレッジ表示。
still_life
Railsアップデートでの利用想定。
週刊Railsウォッチ
以下を読みました。
performメソッド
Railsにおけるベストプラクティスの話（2017年なので古い）。
postgreSQLの話が多かった。
以下がよかった。
最初に、モジュールを1つ作成します。これをincludeすると、performという名前のクラスメソッドを作成します。 次に、作成するすべてのサービスで、コンストラクタ（initialize）をprivateにします。つまり、このperformパブリッククラスメソッドだけを呼ぶということです（もちろんRubyのような動的言語ではprivateメソッドも呼ぼうと思えば呼べますが、単に呼びにくくするだけの処置です）。
Railsにおけるデザインパターン
Value Object
Service Object
Form Object
Query Object
View Object
Policy Object
Decorator
こちらも初版が2013年と古いので注意。
rbenvで管理している各Rubyバージョンのgemをアップデートする
rbenv-eachをインストール後rbenv each gem update --systemを実行すると続々とRubyGemsが2.7.9または3.0.3にアップグレードされました。
基本的にプロジェクトでは複数のバージョンのRubyを使うことが多いので便利そう。
Rails Conductor
同じ記事から。
Webコンソール（ブラウザの下部にerbが立ち上がる感じ）でRubyのコマンドとかを操作できるっぽい？
あまり進んでないから無視してもいいかも？
GitHubのRailsプロジェクトをStarの大きいものから調べてみた
forem
CMSに近いかも？
更新頻度も高くて、コード読んでみるとおもしろそう。
ディレクトリ
cypress
cypressというディレクトリがあるが、これはJSのE2Eテスティングフレームワークっぽい。
app/decolators
app/forms
app/liquid_tags
なんだろうこれ。
app/policies
app/queries
app/refinements
app/sanitizers
app/serializers
このディレクトリの存在を忘れてたのでとりあえず読んだ。
RailsでAPIモードで利用するときとかめっちゃ使いそう（察し）。
はい、よく考えてませんでした。すみません。
app/services
app/validators
app/view_objects
app/workers
diaspora
プライバシーに配慮した分散型SNSらしい。
ものすごく雑に言えば、マストドン (ミニブログ)みたいなかんじ（死語）。
マストドンのWikipedia見ると連合型SNSと書いていたけど、分散型と連合型が同じ意味になるの気持ち悪い。
開発は進んでるっぽいけど、コミュニティの大半がこのOSSの関係者っぽくてdiaspora公式のPod（サーバ）で10万人くらい。
それ以外は多くても1万人くらいのコミュニティしかなくて微妙な感じだった。
特筆すべき点なし。散ッ！！！
ディレクトリ
app/presenters
特筆すべき内容はこのディレクトリくらい。
以下を読みました。控えめに言って最高すぎてこれだけ読めばデザインパターン完璧まである（大嘘）。
decorator, presenter, ViewModel, helperとの違いがキモ。
Presenterは元々はMVCから派生したアーキテクチャパターンのMVP(Model-View-Presenter)の考えからきた概念のようです。Controllerの肥大化防止、テスタビリティの向上が期待できるみたいです。
説明じょうず。
Decorator 単一のモデルクラスに対応する ViewModel Presenter 複数のモデルクラスにまたがる ViewModel 永続化されたモデルと一致しない ViewModel ViewModel Decorator 、Presenter の上位概念。ビューに関連するロジックをまとめるレイヤーを指す。
すごい。めっちゃわかる。
MVVM（Model - View - ViewModel）はNativeApp（iOS/Android）でよく語られているイメージ。
どうでもいいけど、ViewModelってモデル層とビュー層の間のプレゼンテーション層だからM-VM-Vのほうが実態に即していると思うけど、語呂がいいほうを取ったのかな。
DraperはRailsのプレゼンテーション層の役割を担うgemです。 プレゼンテーション層とはviewとモデルの中間に位置し、モデルやビューに実装されやすい表示ロジック/フォーマットを記述する役割を担います。
ViewとPresenterの関係性は以下。
・View（UI）はPresenterのことを知るべきではない ・PresenterはViewからメッセージを受け取り、それに基づいて処理を行い、Viewに反映する これは「ViewはPresenterに依存せず、PresenterはViewに依存する」ということ
あと超どうでもいいけどMVVMでググると、「Prism WPF(UWP)」というサジェストキーワードが出てきて、どうやらWindowsデスクトップアプリを開発するためのフレームワークっぽい。
ほんとどうでもいい（失礼）。
また、永続化されないケースやActiveRecord化されていないモデルなんかもPresenterで扱うそうです。 ViewModelについてはView ObjectとかPresenter層と表現されることも多いですが、ビューに関連するロジックをまとめるレイヤーと解釈すれば問題ないかと思います。
うわー。さすが。
decoratorはdraper、ActiveDecoratorというgemで導入が可能。
draperのほうが利用数が10倍くらい多い。
DDDやクリーンアーキテクチャが優勢なので今更使うかどうかはさておき、特段の理由がなければdraperでいいのでは？と。
ちなみにhelperとの違いは以下。
helperはモデルから独立し直接関係していない描画ロジックを実装するのに用います。
それに対して
Decoratorは特定のモデルにがっつり関連した描画ロジックを実装するのに用いる
というものです。
まず、 helper にはスコープの問題があります。名前空間がグローバルなので、メソッド名が衝突する危険性があります。 一方、 ViewModel は関連するビューのドメインごとにクラスを分割するので、その危険性はありません。
深いですね。やはりほかのものと比較することで理解が深まる。
単一モデルに対応するDecoratorと複数モデルに対応するPresenterの使用例は以下に載ってました。
presenterを利用する前のcontroller
class PopupsController < ApplicationController
def index
if current_user.campaign_user?
@campaign_message = Message.where(...)
@campaign_popups = Popup.where(...)
end
# ...
end
end
presenterでプレゼンテーション層を作成
class PopupPresenter
def initialize(user)
@user = user
end
def campaign_user?
@user.campaign_user?
end
def campaign_message
@campaign_message = Message.where(...) if campaign_user?
end
def campaign_popups
@campaign_popups = Popup.where(...) if campaign_user?
end
end
controllerがすっきり！
class PopupsController < ApplicationController
def index
@presenter = PopupPresenter.new(current_user)
# ...
end
end
べんりー－－。
