20190316 Kyoto.rb
初心者ルームとDeep Discussion ルームに分けた。
Deep Discussion ルーム
Service層とFormObject層の切り分け。チームで毎回議論になっている。
ViewとLogicは一致しないので、FormObjectで吸収したい
Module分割してModel間で共通化する
Service層は使わない。
Viewを作るのに必要なデータを集めるのはControllerの責務。セレクトボックスのデータとか。
DHH「頃合い見計らってaccepts_nested_attributes_for殺す」
RailsでDDDやるの難しくないですか?luccafort.icon
複数のテーブルをまとめて返すときに困ることがある。
それはむしろアプローチとしては正しい
RubyだとInterfaceがないほうが難しい
銀座Rails(2月末、 onk さんと Koichi ITOさんと飲んだ時の話)cawa.icon
基本的にサービス使わなくて良いのでは (by onkさん)
Fatモデルでいいじゃない (by onkさん)
見通しのいいFatモデルを目指す
includeが30行くらいあるクラスがあった
DDDはRubyにそぐわない (by ITOさん)
からのアジャイル開発の話になった、スクラムよりXPがいいよね(by ITOさん)
(cawa はスクラムでアジャイル勉強したので、ベースがスクラム。XPあまりわからない)
XPわからないluccafort.icon
Docker!!
少人数だと正直Docker使うのがめんどい(IOが遅い)luccafort.icon
Docker でProductionまでDeployやってるとこは少ないかも
ミドルウェアはDocker立ち上げたほうがいい→ほぼ共通認識
新しい人が入るときに2時間環境構築かかると時間かけすぎ
Docker剥がす派という過激派閥があるらしい
Appはコンテナにしない方になっていく
開発環境
メタプログラミング
Methodが使われてるかどうかのチェック、ログ吐いて眺める、みたいなのがベストプラクティスで良いの?
who_called_meというgemがある
メタプログラミングが許される乗ってどういう場合?嬉しさよりもつらみ多いのでは。。
基本時にはNGだと思うが……luccafort.icon