3/22（金）に外苑前にて開催されたrails dmに行ってきた際にメモを取ってきたので備忘録として残しておきます。
ただ、バックグラウンドとなる知識が不足している状態でメモったので書いたことが全て正しいかは保証し兼ねます。

「アプリケーションを作るときに考える25のこと」
株式会社はてな 大仲 能史さん

全体的な話
・はてなアドベントカレンダー記事について解説
・最近のはてなではperlだったものをrailsで置き換える作業が多くなってきている
・perlで作られていた社内チャット的なものをrailsで置き換えようとしたら、「エゴだよ、それは」と言われたらしい、というのが面白かった

アドベントカレンダーは下記参照
https://qiita.com/advent-calendar/2018/hatena

サービスを作る軸
・価値・難易度の2軸でサービスを作るかの判断を行う
・FWは簡単に価値があるもの作るようになることが目的

最近のユーザー事情
・SPAが一般的なwebアプリケーションとなってきており、通常のhtmlではユーザーの求める品質を満たせないのではないか。

gemについて
・gemは複数の選択肢が発生することがあるので、なぜそのgemにしたのかをドキュメントに書いておくのおすすめ。
・gemの採用について悩んだ時は、ひたすらgithubを検索してgemについての記事を見たりしてgemの有用性の判断を行うらしい。
・gemの紹介
　　ページ遷移系：kaminari一択のような気がする。
　　画像アップロード系：最近はvipsが人気？
　　編集履歴：auditlog

「DevOps, Immutable Infrastructure, 〜」
クックパッド株式会社 庄司 嘉織さん

Immutable Infrastructure
・Chad Fowler
・Blue-GreenDeployment
・デプロイの高速化と安定化等を主観としていた。

Microserveices
・Martin Fowler
・実は組織パターンの概念だった
→一つの大きなチームでやってもあまり意味がない
→チームは機能横断型

・MicroserveicesPrerequistes
サービスの可用性やビジネス上の問題等を検出できる体制でないと導入すべきでない。まずはこれらが可能な体制を整えてからマイクロサービスを導入すべき。

・Docker
★アプリ側もImmutableを意識することを強制された
・ファイルをサーバーにアップロードさせないとか

Container Orchestration
・ECSなど
・アプリケーションの実行を抽象化
・サービスの数が70〜100とかになってきた時に導入を考えるのがおすすめ

Service Mesh
・サービス通信の状況把握
・Envoyを採用
・envoyの設定ファイルを見れば、どのサービス間で通信をしているかを一覧化して確認できる

Chaos Engineering
・サーバーを落とすことではないらしい
・Steady Stateの計測が重要
→サービス自体の定常状態を計測できるようにする
→cookpadではレシピの閲覧数と検索数の比で定常状態を計測しているらしい

サービスメッシュを導入するとカオスエンジニアリングがしやすい。らしい。

「What's new in RubyGems 3.0」
GMOペパボ株式会社 柴田 博志さん

RubyGems
・rubygemsでは、bugfixとかも盛んだけど、既存の機能にデグレとかが発生するかもしれないので、最新版ではなく、マイナーバージョンがついているやつ（x.x.x.1とか4桁のもの）がアップデートにはおすすめ

・メジャーバージョンアップを最近したよ（３がリリース）
　変更・追加点は下記の通り

1. bundle使ってたら関係ないけど、３になってからgemのインストール速度が改善されたらしい。
2. multi-factorという機能が追加された
3. ファイルオープンのコマンドの変更？file.openで明示的にファイルを指定してからファイルをオープンするようになった。らしい。よくわからない
4. gem infoコマンドの追加
5. ４に伴い、gem infoとgem installコマンドの実行がgem i で衝突するようになったので、gem i ではinstallを実行するようになった。
6. 不要と思われるオプションの削除
7. Rubocopを導入したよ
8. budler finder versionがruby gems2.7に追加されたらしい。ただ、規約が厳しすぎたので、それをソフトな規約にしたとのこと。bundlerのメジャー系バージョンだけを見るようになったらしい。
9. 古いrubyをサポートしなくなった。

・Bundlerもメジャーバージョンをリリースしたよ（２が出たでござる）
　変更・追加点は下記の通り
1. 古いruby(2.2以下)をサポートしなくなった
2. 内部のコードを少し綺麗にした

そもそもrubygemsって何？という方はこちら
https://qiita.com/sumyapp/items/5ec58bf3567e557c24d7

「SQLQL は GraphQL にとって、何なのか
What's SQLQL for GraphQL?」
小栁 真太さん

・サーバー側のRDBMSのSQL処理系は便利なのでそのまま使いたかった
・sqlqlのサンプルアプリがある（github上にHerokuにデプロイできるボタンが設置されている）

CTE
・インラインのview
・サブクエリに名前を付けることで、クエリ中で何度も使用できる
・CTEによってユーザーに見せたくない情報のみ射影させることも可能
・再帰クエリによる無限ループの問題がある
・Mutationsの問題

Mutationsの除外
・rails6で複数DBに正式に対応するようになった
・

テーブルホワイトリスト
・postgresにpg-queryというクエリがある
・

無限ループ対策
・SQLQLの処理に時間制限を設ける（3秒とか）
・ただ、DOS攻撃など今後の課題は残っている

SQLQLの核となる考え方

・オブジェクトが得意な処理とリレーションが得意な処理はそれぞれでその役割を担わせた方がいい。
・インピーダンスミスマッチ

・RelationからObjectへ
→オブジェクトとリレーションの相容れなさに問題がある
　→Json-AGG関数やROW_TO_JSON関数を使えばSQLでjsonを生成できる

・ObjectからRelationへ
→JSON_TO_RECORD関数等を使う

SQLQLとは
https://qiita.com/yancya/items/4b7979d83cbf6af9b819

サービスを成長させる「仮説検証文化」のつくり方
株式会社トクバイ 前田 卓俊さん

トクバイ
・店の特売情報とかを地域ごとに人に発信するサービス

◼️ よい仮説検証とは
→以下の三点を考慮すること
・問題の明確さ、期待効果の大きさ
・点と線を用いた検証
・プロダクトに閉じていないか

問題の明確さ、期待効果の大きさ
・期待効果の大きさのみでなく、「なぜその問題が起こっているか」について考える必要がある。

点と線を用いた検証
・検証する指標（数値項目とか）を決定する。これが点となる。
　ユーザーの一連の行動の中で経由するポイントで点を設定し、それらを計測する
　ことで欲しい結果が得られる。

プロダクトに閉じていないか
・プロダクトから得られる結果のみでなく、ユーザーが持つ主観的な感想（定性指標）を収集する必要あり

◼️ チームとして取り組むには
・Agility
→細かく行動・修正を繰り返せるチーム作りが大事

・道具を揃える
→データを観測・分析するためのツール等を十分に用意する。
　場合によっては、道具ではなくユーザーに直接話を聞くなどの行動も必要。

万葉のRails新人研修のコードレビューコメントを分析してみました
株式会社万葉 大場 寧子さん

万葉内で新人に対して行われているrailsチュートリアルのような研修におけるコードレビューについて色々分析したらしい。

コードレビューについて注目する観点
・レビュー中のどこで会話が発生しているのか
・会話の背景には何があるのか

データ取得元
・PR
・PR内のコメントから「会話」を抽出

データ取得対象
・3人

PRから抽出するデータ
・コミット数
・コメント数
・所要日数
・所属ステップ数

◼️ 傾向からわかった初心者がつまるポイント
・データの一覧化、更新、削除といった機能の追加という「実装の方針を自分で考える必要がある」タスク

◼️ 新人とメンターの間の会話で頻出したジャンル
※一人では解決しづらく、メンターにアドバイスを求めたと考えられる
・RSpec
・コーディングスタイル
・ドキュメンテーション
・ヘルパー周り
・モデルとか

◼️ レビューのコメントについて
・共通する価値観はレビューに現れる
例）ここの部分は切り出してメソッド化した方がいいぞよ→共通化はいいことだという価値観

・そもそもコメントの意図が新人に伝わっていないケースがあった。
　どういう価値観に基づいたコメントなのか、について触れた方がいいのではないか。
例）コードを綺麗にするために、〜した方がいい。などなど

7年目を迎えたRailsアプリケーションの傾向と対策
株式会社キッチハイク 小川 剛さん

Railsの優れたところピックアップ
・COCで煩雑な設定ファイルを省略
・Active Recordでマッピングをシンプルにしている

レールから外れると…
・途端にハードルが上がるため、レールからちょっと外れる場合の実装が難しい

View Model
・表示のみに必要なコードがviewに書かれ始めてコードが増えてしまう時などに表示ロジックをview modelに書くことでviewがすっきりする
・View Modelはデコレーターやら、View Objectなど別名がある

「問題」
・N+1問題が起こった、eager_loadしにくい

「提言」
・データアクセス系の問題が怖いので、一覧系のページでは要注意。

From Model
・モデルに紐づかないフォームを作る場合に使う。
例）確認チェックのためのボックスなど

・From Modelはモデルに紐づかない専用のモデルのフォームを作る
・コントローラがすっきりする

「問題」
・Form Model自体が太った

「提言」
・あくまでForm Modelは薄く、Modelは主役
・バリデーションやらの責務はModelに持たせて、Form Modelはそれを呼び出すだけにしておくなど

Service Object
・コントローラにベタ書きされたビジネスロジックを書いておくことで
　コントローラがすっきりする

「問題」
・Serviceの定義が一般的すぎて、クラスが増えすぎた。
・結局、コントローラに書くべき処理までService Objectに書かれてしまい、太ってしまった

「提言」
・サービスの定義をチーム内で決めておく
・ロジックはモデルによせる
・1サービスクラスに1つの仕事
・あくまで主役はModel

まとめ
・現場ごとのパターンがあるので、それらをオープンにしていってみんなで改善していこうぜ

毎日の開発に役立つRailsプラグインづくりの秘訣
Ruby/Rails コミッター 松田 明さん

hocus_pocusを作った人
作者はきっとジョジョ好き
基本的に、作成したgemのデモでした。

gemを作っていく際の教訓
・小さく作って早目にリリースが大事。じゃないとやる気が消える。
・ドキュメンテーションを残すのもめんどいので、機能は少なく。
・ドキュメントがわりにアニメgif作っておくのもいいと思う。
・問題解決を動機とした開発じゃないとモチベーションが維持できないと思う。

いくつかのgemは便利そうだったので、一度見てみても面白そうかもです。
https://github.com/amatsuda?tab=repositories

こんな感じです。
万葉さんのコードレビューの解析のプレゼンが私的には一番面白かったと思います。イベントの最初にrailsの作者であるDHHさんがオンラインで色々話してくれたんだけど、いかんせん全て英語なので全く分かりませんでした。
ただ、JSをけっこうdisってたのは分かったので共感しました(*^ω^*)

以上ですよ。