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がどんなもので、どのように開発しているかを眺める
- 面白い
- 興味が湧く
- 使っている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に習う
- 基本はそうだけど、こっちのほうが便利じゃない?
- DHHに習う
Easyを作る体制を作る
- 楽をするための努力を惜しまない
- 足回りは最初に整える
- テスト
- もちろん書く
- CI/CD
- もちろん回す
- メトリクス
- もちろん取る
- シンプルに始める
- routes
- REST準拠
- schema
- 正規化を崩さない
- ブランチ運用
- github flow
- Issue / PRのテンプレートを書いておく
- routes
- 改善がまわる環境づくり
- ふりかえり
- 定点観測
『技術的負債とリファクタリング』
@sinsoku_listyさん(株式会社grooves)
- DB制約
- 変更しやすいコード
- リファクタリングいつする?
DB制約
- null: falseは基本的に必須
- null: falseがつけられなければ、Tableを分ける
- unique制約
変更しやすいコード
- コードの可視性
- private
- Refinement
- 読みやすいコード
- 命名
- ABCSize
- 過剰なDRYより分かりやすさ
リファクタリングいつやるか
- 良いコードは伝説
- ソフトウェア開発は難しい
- 少しずつ直していく
- コードを読んでいくタイミングで
- 理解した内容をコードに反映する
- スコープを狭くする(未使用なら消す)
『ドリコムで使ってるgem一覧』
@sue445さん(株式会社ドリコム)
- 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
- テスト
- http
- web mockを使う
- httpリクエストがあたかも行われたかのように振る舞う