Rails Developers Meetup #2 （東京会場）に参加してきた

概要

【増枠】Rails Developers Meetup #2 （東京会場） - connpass

所感

• @onkさんの話が日常の開発で大切だと感じた
  • ドリコムでの共通認識の作り方が参考になった
    • bundle update当番や野良コードレビューとかはやってみたい
  • 開発環境を良くしていくために投資していきたい
• DB制約大事
• 今関わっている案件的にshibaraku使えそう

『クラシルのwebサイトをちょっとした改善で100倍速にした話』

奥原 拓也さん（dely株式会社 リードRailsエンジニア）

• webの表示改善
  • 59.7sec => 0.70 sec
• キャッシュの導入
• 画像の最適化
• 不要なimportの削除

キャッシュの導入

• ページキャッシュ
  • 廃止
• アクションキャッシュ
  • 廃止
• フラグメントキャッシュ
  • 期間を指定してキャッシュできる
  • 1549ms => 131ms
  • key/valueがあったら読み、なかったら書く
  • 更新したい場合は？
    • 特定のフラグがあるとキャッシュを更新する

画像の最適化

• 画像の圧縮
  • TinyPNG
  • brew install jpengtim
  • brew install pngguant
• 画像の最適化
  • デバイスに最適なサイズを読む

不要な外部ファイルの削除

結果

• 早くなった

その他

• テックブログ書いてる
• denyはRailsエンジニア一人らしい

『ふつうのRailsアプリケーション開発』

大仲 能史さん（株式会社ドリコム スペシャリスト） @onk

• RailsエンジニアがRailsエンジニアらしい仕事ができること
• bin/setup, bin/update
  • 1コマンドで開発準備が整うようにしておけという話
• SimpleとEasyの違い
  • 設計に筋が通っていて、すっきり（絶対的）
  • 使う時に、簡単（相対的）
• Kaminari
  • 各環境向けのコードをプラグインとして切り出すことで、コアの設計指針をSimpleに保つ
  • 認証系のgemはそうなっていないのでは

RailsとEasy

• CoCを知っている人にとってはEasy
• 90%のことをやる
• 一般的でなくても、使う時にEasyなら取り入れていく
  • rails5.1のsecrets.ymlのshared機能
• 共通認識の元でEasyであることを加速させていくフレームワーク

ドリコムとEasy

• Will2Kaminari
• to_id
• count_by
• activerevord-unsigned-column-ext
• activerecord-turntabke
• ユーザ認証
  • 自作するが、deviseとIFを合わせる

共通認識を作る

• まずは個人で始める
  • 自分の認識と世の中の認識を揃える
    • 大量にインプットする
    • はてブ
    • Qiita
• bundle update当番
  • 使っているgemがどんなもので、どのように開発しているかを眺める
    • 面白い
    • 興味が湧く
• 野良コードレビュー
  • 社内の複数アプリを全体的に眺める
  • 同じ轍を踏まない
  • not null
  • unique
  • Datetime -> Time
  • ユーザの持ち物はcurrent_userから辿る
  • ユーザの持ち物のモデルにはUserを付ける
• 重複コードをgem化する
• 最後まで直しきる
• 複雑なことはしない
  • MVC
  • FromObject以外はほとんど使わない
  • Serviceはやりきるなら導入する
    • あまり導入しない
• OSS文脈に乗る
  • onkcop
  • CI/CD

Easyを作る

• 発生しないようにする
• 自動化の鬼になる
  • 手順書を見かけたら自動化可能だと思え
  • 全自動が無理ならせめてスクリプト化する
• 時間がかからないようにする
  • db:migrate:resetではなくdb:setupを使う
• デフォルト値を入れる
  • 書きたくないものを書かなくても良いようにしたい
• 認証をbefore_actionでやっているなら、ApplicationControllerに書けないか検討する
  • すべてに適用してから一部を外す
• 一般的かどうかを意識する
  • DHHに習う
    • 基本はそうだけど、こっちのほうが便利じゃない？

Easyを作る体制を作る

• 楽をするための努力を惜しまない
• 足回りは最初に整える
• テスト
  • もちろん書く
• CI/CD
  • もちろん回す
• メトリクス
  • もちろん取る
• シンプルに始める
  • routes
    • REST準拠
  • schema
    • 正規化を崩さない
  • ブランチ運用
    • github flow
  • Issue / PRのテンプレートを書いておく
• 改善がまわる環境づくり
  • ふりかえり
  • 定点観測

『技術的負債とリファクタリング』

@sinsoku_listyさん（株式会社grooves）

• DB制約
• 変更しやすいコード
• リファクタリングいつする？

DB制約

• null: falseは基本的に必須
• null: falseがつけられなければ、Tableを分ける
• unique制約

変更しやすいコード

• コードの可視性
  • private
  • Refinement
• 読みやすいコード
  • 命名
  • ABCSize
  • 過剰なDRYより分かりやすさ

リファクタリングいつやるか

• 良いコードは伝説
• ソフトウェア開発は難しい
• 少しずつ直していく
• コードを読んでいくタイミングで
  • 理解した内容をコードに反映する
  • スコープを狭くする（未使用なら消す）

『ドリコムで使ってるgem一覧』

@sue445さん（株式会社ドリコム）

ドリコムで使ってるgem一覧 #railsdm

• 11アプリのGemfileを集計
  • 集計スクリプト書いた
  • 社内gemは除く
• メジャーどころ集まりすぎたので、マイナーどころを紹介
• komachi_heartbeat
  • 死活監視
• global
  • yamlの設定をいい感じに扱う
• onkcop
  • ドリコムのrubocop
• spec-parameterized
  • パラメタライズをテストする
• shibaraku
  • start_at/end_atがあるmodelを扱うgem
• activerecord-simple_index_name
  • index名からtable名を除く
• activerecord-turntable
  • DBを水平分散する

『ペパボで使ってるgem一覧』

@kenchanさん（GMOペパボ株式会社）

• shu-cream.net
• こちらもメジャーどころではなくテーマを絞る
• 文字系
  • moji
  • makimoto/romaji
  • mwunsch/rumoji
  • willnet/gimei
    • 日本語のテストデータ作成
• ペパボ発
  • hsbt/minitest-power-asert
  • yml_ref_resolver
  • capistrano-release-notification
  • rspec-default_http_header
  • global_sign

『データフィードの現場で書く Rails アプリケーション』

@284kmさん（株式会社フィードフォース）

• Webmockの話
• データフィードの現場とは
  • データフィードとは
    • 保有している商品などのデータを外部サービス（広告配信先など）のフォーマットに変換して送信する仕組みのこと
• ふつうでありたい
• とはいえ、特殊もある
  • koala
  • google
• テスト
  • http
  • web mockを使う
    • httpリクエストがあたかも行われたかのように振る舞う