12/8 (土) に開催された「Rails Developers Meetup 2018 Day 4 Nouvelle Vague」に参加した．イベント名に「Rails」と付いているものの，トークテーマは多岐にわたり，エンジニアなら誰でも楽しめるように工夫されていた．また YouTube ライブ配信もあり，リモート参加者も大切にするホスピタリティを感じたし，イベント運営プロジェクトのクオリティの高さに驚かされた！参加したトークの中で印象的なものを抜粋して紹介したいと思う．

今回は僕も登壇をして，既に資料を公開している．内容的に Non-Tech だからイベントの趣旨と合わなかったらどうしよう！と不安もあったけど，オーディエンスの反応を読みながら楽しく登壇できた！えーっと「プレゼン芸人感」は出てた？笑

ZOZOTOWN のバッチデータ転送基盤の紹介

Embulk + Digdag
- Digdag Ruby scripts Operators も併用している
多くの集計ジョブがある
CircleCI : データアナリストが実装した SQL 構文を CI している

Embulk + Digdag を活用した集計基盤のアーキテクチャ事例だった．後半に紹介されていたジョブ依存図は圧倒的な複雑さで大変そうだけど，どこまで Digdag を使っているんだろう？という点は興味を持った．構成次第だけど Embulk も Digdag も Dockerized すると今より運用しやすくなる可能性もありそう．登壇中にちょこちょこと ZOZO に関係する時事ネタが出てきて，笑ってしまった！

（資料公開待ち）

Rails x パターン @junk0612

単一テーブル継承 (STI : Single Table Inheritance)
- 出典 : 書籍「エンタープライズアプリケーションアーキテクチャパターン」
- サブクラスの追加に柔軟に対応できる
- ただし，サブクラスのカラムに NOT NULL が付けられない
フォームオブジェクト
- 出典 : 不明
- 複数のモデルにまたがった処理を1箇所にまとめることができる
- ただし，app/forms に多くのファイルが置かれてしまう
勘定
- 出典 : 書籍「アナリシスパターン」
- 「取引モデル」と「勘定科目モデル」に分割して，勘定科目の合計金額が 0 になるようにバリデーションを実装する
パターン中毒
- 導入前に本当に必要なのか？を議論する

「パターン」に興味を惹かれるエンジニアは多いと思う．計3種類のパターンが紹介されていて，特に STI とフォームオブジェクトに関しては Twitter のハッシュタグが盛り上がっていたので，ツイートを見ながら登壇を聞くというリアルタイムな体験は良かった！あと「PofEAA」と呼ばれる書籍「エンタープライズアプリケーションアーキテクチャパターン」は読んだことがなく，気になる！個人的には「登壇直前に資料が完成した」と冒頭で言っていた点が気になり，実際に資料にミスもあり，もう少し準備をするべきかも？と感じた．

エンタープライズアプリケーションアーキテクチャパターン (Object Oriented SELECTION)

作者: マーチン・ファウラー,長瀬嘉秀,株式会社テクノロジックアート
出版社/メーカー: 翔泳社
発売日: 2005/04/21
メディア: 大型本
購入: 10人クリック: 635回
この商品を含むブログ (143件) を見る

FiNC での5年間に渡るマイクロサービスの育て方

開始
- 開発案件を受託する形からスタートした
- 最初はローカル環境から cap deploy production を実行していた
- FiNC に吸収される形で JOIN した
成長期
- 多くの機能が必要になり，モノリシックでは難しいと判断した
- 「遺伝子検査の閲覧機能」を新規に Rails で実装した
  - これが FiNC のマイクロサービスのはじまり
加速期
- 一部のサービスに依存が強くなり「神サービス」になってしまった
  - BFF (Backend For Frontend) を導入する
グロース期
- 積極的にマイクロサービス化とリアーキテクトを実施している
- BFF は Kotlin で実装し直した

非常に刺激的な内容だった！単純にマイクロサービス化を進めるという話ではなく，スタートアップの成長フェーズによって適切な技術選定をし，さらに組織的な改善も日々しているんだろうなという苦労が感じられた．プロダクション環境で稼働中のモノリシックサービスをマイクロサービスに切り出すのは「言うは易く行うは難し」なので，ここまでリアーキテクトを実践されているのは本当に素晴らしい！

二人チームにおけるバックエンド開発の効率化を求めて @okuramasafumi

エンジニア2人
- 1人は CEO で多忙
開発効率と開発品質のバランスを取る
- JSON:API — A specification for building APIs in JSON
  - GitHub - Netflix/fast_jsonapi: A lightning fast JSON:API serializer for Ruby Objects.
    - fast_jsonapi は Netflix 製
- GitHub - collectiveidea/interactor: Interactor provides a common interface for performing complex user interactions.
  - ビジネスロジックをカプセル化する
- GitHub - r7kamura/rspec-request_describer: Force some rules to write self-documenting request spec.
  - RSpec の describe をルール化してテストの粒度を小さく保つ
- RuboCop を使う

まさにスタートアップ！という状況の中，ライブラリを適切に選定し，開発プロセスに組み込んでいる事例だった．個人的には2人だとプルリクエストのレビューが止まったりして，期待するほどリードタイムが上がらない場合もあるので，せめて3人だったら良いのに！とは思った．RuboCop の .rubocop.yml にオーディエンスの興味関心があったこともあり，お昼休憩中に .rubocop.yml を紹介する飛び込み LT をされていたのも素晴らしかった！

The Cacher in the Rye

GitHub - tsukasaoishi/bitzer_store: BitzerStore can treat multiple cache clusters in Rails.
- bitzer_store を使うと複数のキャッシュストアに保存できる
キャッシュの目的
- レスポンスタイムを短くしたい
- サーバリソースを補いたい
運用とコスト
- キャッシュを意識した実装
- 監視
リスク
- 適切ではないキャッシュが使われる
- ヒット率が低すぎる
あえて「使わない」

キャッシュを「使わない」という話だった．キャッシュは「諸刃の剣」であるという理解はあるものの，レスポンスタイムを短くするためにプロダクション環境で Memcached / Redis などを使っていた経験もあり，耳が痛い部分もあった．Memcached を使う場合は eviction をモニタリングするのもわかる．資料には「十分なリソースがあればキャッシュは不要」と書いてあったけど，例えば頻繁に実行されるクエリなど，実際にどのように対応しているんだろう？という点はもう少し聞きたかった．

複数のスタートアップを通して得た失敗と学び @threetreeslight

Repro 創業者
- 現在 VPoE
「失敗談」にフォーカスする
- 失敗軸 : プロダクト / 組織 / 採用 / 技術
0 → 1
1 → 10
- システム費を無理に削減せずに保守性を考える
10 → 30
- 採用に専念する
- 平均以上なら採用する
30 → 50
- 要望に追われる
- 雑な設計のスケール限界が見える
50 → 100
- リリースマネージャに権限委譲する
- ミドルマネージャの数が組織規模の限界を決める
100 → 300
- Corporate Operations Engineer（≒ 社内 SE）を専任化する
  - できるなら「社内 SE」と呼ばない
300 → ?

Ruby / Rails とは少し異なるテーマだけど，個人的にはベストトークだった！プレゼンスキルも圧倒的だった！そして「失敗談を楽しく語れる」ことの素晴らしさ（と強さ）を感じた．テクニカルサポートを当番制にしたり，サービスを伸ばすために個別要望に対応したら実装が破綻したり，アーキテクチャのスケール限界が見えたり，実体験とシンクロするあるある話もありつつ，ここまで言語化された資料も貴重なので，スタートアップ界隈は1度読むと良いのでは！

gitpitch.com