Rails Developers Meetup 2017 大阪会場 に参加しました。
会場
前にきたことがある場所より広い部屋でした。
レールの伸ばし方
- 発表資料
- RSpec スタイルガイド
- プロジェクトに途中から参加するとつらい
- 適切な抽象化
- MVC が正しく使えているか
- Fat Controller
- ロジックを Model に
- Fat Model
- PORO (Plain Old Ruby Object) に切り出す
- Railsの太ったモデルをダイエットさせる方法について
- 大量の
before_filter
問題の対処方法 - クエリメソッドにして各 action で呼び出してインスタンス変数に代入
- ビューに渡す変数を抽象化
- View Model (View Object)
- Validation (callback) の場合分けが複雑になる問題
- 場合分けせずにフォームごとに Form Object を作る
- ひとつのアクションでやることがたくさんある
- Service Object という言葉は人によってさすものがいろいろある
- この3つでだいたいいける
- 現場に導入するには?
- 具体例やわかりやすいドキュメントが必要
- 誘導できるツールがあるといいのでは? → 作った https://github.com/willnet/yuba
- Yuba の詳細は時間がないので省略
- 質疑応答
- 聞き取りにくかったのでメモ取れず
- Rails Developers Meetup 2017でレールの伸ばし方について話した - おもしろwebサービス開発日記
Professional Rails on ECS
- http://joker1007.hatenablog.com/entry/2017/12/09/155456
- 1年分の知見のまとめ
- 発表時間がたりないので後日ブログにまとめる予定
- k8s が覇権をとった感じでつらい
- Fargate とか EKS とか
- Docker イメージは production と staging は同じで development はわける
- 少しの間、中継が切れてた
- assets:precompile が鬼門のひとつ
- prehook
- 秘匿値の扱い
- 設定ファイル自体を暗号化してつっこんでいる
yaml_vault
- KMS を利用すると権限を IAM で管理できる
- 開発環境は docker-compose と volumes で
- mac はボリュームマウントが遅い
- Gentoo がおすすめ
- 開発環境は Docker 環境の中に zsh なども入れて便利にしている
- ECS の説明: TaskDefinition とか Service とか
- https://github.com/reproio/ecs_deploy
- Capistrano を使っている理由: 既存資産があるなど
- 個人別ステージング環境へのデプロイ
- 苦労話なので略
- auto scale
- コマンド実行 https://github.com/reproio/wrapbox
- ログは papertrail 経由
- db:migrate → ridgepole
- diff があれば手動で DDL 発行
- テストと CI は別発表資料参照
- 質疑応答はなし
ざっくり学ぶ言語のしくみ
- https://speakerdeck.com/itkrt2y/zatukurixue-buyan-yu-falsesikumi
- 一般的な仕組みの概説
- https://interpreterbook.com/
- Ruby の場合の話
- 途中終了
RSpec しぐさ
- https://www.slideshare.net/takafumionaka/rspec-83693226
- テスト駆動開発の付録C
- BDD はテストではなく設計技法なので語彙を変えた
- assertion → expectation など
- Given, When, Then
- should から expect に変わった
- 最後の方がちょっと切れた
Enter the OSS world [RuboCop] II. lost boundary
- https://speakerdeck.com/koic/enter-the-oss-world-rubocop-ii-lost-boundary
- Part I は福岡で発表した
- Part II が今回
- bug ラベルのものをみる
- 最初に再現テストを書く
- 実際に出した PR の例
- OSS Gate の紹介もあった
Randomly Failing Specs
- https://www.slideshare.net/sinsoku/randomly-failing-specs
- 稀に落ちるテスト → 稀に通るテストになる
- ランダム値を使うテスト
- Faker の値は意外とかぶる
- Faker の unique メソッド
- FactoryBot の sequence で良いことも多い
- グローバルなものをいじるもの
-
stub_const
のわな - Capybara + JavaScript
- 途中終了
休憩
飛び込み LT
Vim and Ruby
- Ruby で Vim プラグインを作る話
- https://github.com/pocke/yaml-path.vim
GMOペパボの Rails & Vue.js プロダクト開発の現場
- https://speakerdeck.com/kymmtchan/rails-developers-meetup-2017
- カラーミーリピート
- Rails + Vue.js を Heroku で
- インセプションデッキ
- ドラッカー風エクササイズ
- 類似サービスのモデリング
- 松江合宿
- 日々の開発
- 1週間スプリントのスクラム(っぽい)開発
- ユーザテスト
- (夏の)自由研究
- 一部ページで SSR
- 新規プロジェクトへの Vue.js x SPA x SSR の導入
- Rails 5.1 API モード
- sidekiq, sidekiq-scheduler
- API 定義を活用した開発: スキーマファースト開発
- OpenAPI : API 仕様記述フォーマット
- 他には API Blueprint や RAML など
- Swagger 2.0 == OpenAPI 2.0
- API 定義の具体的な話
- チームレビュー
- 開発
- スタブサーバー
- 自動で整合性チェックする gem
-
assert_schema_conform
の呼び出しを prepend で差し込んだ - API 定義と結合
- 質疑応答
Vue.js の話はなかった。
作らない技術
- https://esa-pages.io/p/sharing/3/posts/1117/1901213944ee86efdaea-slides.html#/
- 作る is 負債
- 作ったとしても捨てる勇気
- pplog
- esa
- コンセプト駆動開発
- https://stackshare.io/esa/pplog
- pplog iOS
- 取り込んでも世界観に合わないと思ったら revert する
- Webサービスはヨシヨシしないとスネる - pblog
- あえてのつかいにくさ
- テンプレート機能は CoC 的な感じでカテゴリを流用
- labs とか spike ブランチとか
- 作らないときは本当に作らない
- 機能を流用して見せ方を変える
- 作っても捨てる勇気を持つ
- 作らないで、既存の Web サービスに乗る
- コードを読む習慣化
- 影響を受けた本
- 最後に自己紹介
- 質疑応答はなし
「Railsでまだ消耗しているの?」 ─僕らがRailsで戦い続ける理由─
- https://speakerdeck.com/toshimaru/why-we-use-ruby-on-rails
- Why Ruby?
- Why Rails?
- DRY : 普遍的
- CoC : Ruby on Rails の本質
- 「〇〇の方が速いよ」
- 「開発の速さ」にも同じことが言えるか?
- dev.to は Rails
Rails on Dockerとの戦い
- https://www.slideshare.net/ssuser21f9f1/rails-on-docker
- モチベーションはアプリケーション規格の統一化
- 何が easy かは人による
- シェルスクリプトでラップした
- docker for mac つらい
- 楽をしたいのが目的なので docker であることにはこだわらない
- だいじなことは「できる」こと
- CI 環境もデプロイ環境もクラウドがおすすめ
- レビューしやすい : git worktree → docker-compose build, up
Railsを学び、現場に入るまで
- https://speakerdeck.com/mikaji/railswoxue-bi-xian-chang-niru-rumade-rails-developers-meetup-2017-lt
- Rails 歴 = エンジニア歴
- ぶつかった壁
- コードレビューが通らない
- ActiveRecord をうまく使えていない
- どこに実装するかで悩む
- ActiveRecord を継承しないモデルを作っても良い
- サービスのレイヤーを増やすかどうかの話
Rancherで作るお手軽バッチ処理環境
- https://speakerdeck.com/morizyun/ranchertezuo-ruoshou-qing-hatutichu-li-huan-jing
- Rancher が便利という話
- メリット1: コンテナ/ホスト監視
- メリット2: CLI ツールがあってデプロイ楽
- メリット3: アドオン的なものが便利
- バッチ処理もできる
- 海外の格安 VPS が使える (Scaleway)
休憩
Rails で人狼を作ってみた
- Action Cable, Vue.js
- https://github.com/fshin1988/jinro_rails
- デモ
- 他の実装の紹介
- 人狼BBS
- 月下人狼
Rails SQL
- https://speakerdeck.com/jnchito/rails-sql-number-railsdm
- Rails❤️SQLのサンプルコード #railsdm - Qiita
- ActiveRecord や Ransack で9割以上は対応できる
- ちょっと凝った検索条件、複雑な集計処理、大量データの一括更新
- 例: キーワードの入力欄と検索対象のチェックボックス
- Form モデル
- SQL を組み立て (この程度の SQL なら AREL で組み立てた方が他の scope とかと組み合わせやすくて便利そうに感じた)
- 例: 請求履歴と入金履歴
- SQL を ERB で書く
- 応用 (SQL を DRY にしたい問題) : 半額フラグ
- 実装方針 : 変数に入れて再利用する
- 例: 大量データの一括更新
- 最後に自己紹介
Rails React
- 風呂グラマー, IT芸人
- What’s React
- サーバーサイド脳に向いている
- サーバーサイド生成
- React は同じ流れがクライアント側になったものと考えれば良い
- webpacker + react (Rails 5.1 から), react-rails (React 純正), react_on_rails
- webpacker (webpack) は大変
- browserify : 一つのファイルだけビルドするなら webpack より楽
- webpack時代の終わりとparcel時代のはじまり
- 環境を”混ぜるな危険”
- node の環境は別に作ろう : Docker で分離
- トレタの React
- View からの呼び方
- meta タグに controller と action を埋め込んでおいて自前でルーターのようなものを書いている
- Form だけ React というのもありなのでは
- react-jsonschema-form https://github.com/mozilla-services/react-jsonschema-form
- 質疑応答
とある企業のモバイル対応
- https://speakerdeck.com/yasaichi/rails-developers-meetup-2017
- pixta.jp
- 導入の背景 : Mobile First Indexing
- 同一 URL でモバイル対応を行う方法: A. レスポンシブデザイン, B. UA で表示内容振り分け
- レスポンシブは特に何もする必要がないが、UA によって分ける場合は ActionPack Variants を使う
- 複数言語対応分の View がすでにあるのでレスポンシブを選択
- 方針: 段階的リリース
- 実装: ActionPack Variants で viewport を設定
2018年から始めるRubyによる深層学習入門
- 機械学習・深層学習
- Python, C++, Lua が多い
- Ruby ではどうか
- いくつがあるが Red Chainer の話
- https://johnresig.com/blog/write-code-every-day/
外傷的Elixir
- Elixir の紹介
OSS雑メンテ
- https://speakerdeck.com/sue445/oss-zatsu-maintenance-number-railsdm
- CI がないと PR がたくさんくるようになったらつらい
- 定期ビルドや bundle update も依存 gem の更新の影響をみるためにした方が良い
- CI のバッジをまとめて表示するサイトを作った
- 「全自動化」と「情報の集約」
休憩
社長が書いたクソコードたち
サービスクラスの議論を蒸し返す
- https://microservices-meetup.connpass.com/
- https://speakerdeck.com/joker1007/number-ginzarb
- https://techracho.bpsinc.jp/hachi8833/2017_10_16/46482
Railsdm 2017 っぽいものを作ってみました
- quine
マルチテナント・ウェブアプリケーションの実践
- GraphQL はいいぞ
- GraphiQL (グラフィクル) - The IDE
- keyword: onk graphql
- Kibela について
- マルチテナント・ウェブアプリ (MTWA)
- SaaS において1つのシステムで複数の組織のチームを同居させるウェブアプリケーション
- BtoB の Web サービス ≒ MTWA
- マルチテナンシーの共有レベル
- Kibela は (3) DB の共有
- PostgreSQL の schema でわけている
- MTWA のアカウントモデル
- サービス全体でアカウントを共有: GitHub, npmjs.org
- テナントごとにアカウントを作成: Slack, G Suite, Kibela
- GitHub 型は「人」にフォーカスしたアカウントモデル
- 「誰だかわからない問題」がある
- Slack 型: こちらが標準的
- 複数のアカウント管理問題は SSO である程度解決できる
- URL の名前空間: domain vs path
- subdomain で分離
- ストレージの名前空間
- PostgreSQL は database - schema - table という階層構造
- PostgreSQL の schema の設定: apartment gem を利用
- schema が増えてきて migration に時間がかかるようになってきた → まだ放置
- KVS, S3, 全文検索エンジン, etc. の名前空間切り替え問題
- memcached for Rails Cache : Proc で渡す必要がある
- Redis by redis-namespace : スレッドセーフじゃなかったので、モンキーパッチで対応
- Elasticsearch
- namespacing v1
- 当初 index を team ごとに作っていた
- index の再構築 (≒ migration) に数時間かかるように…
- namespacing v2
- Rails の model ごとにただ1つの index を作成
- filtered alias で参照
- index 再構築は速くなったが、リクエストは重くなったので調査中
- その他S3など
- 当初は subdomain (team name) で名前空間を作っていたが rename に対応するために team id に変えた
- Analytics : schema が大量にある DB に分析クエリうてない問題
- Testing
- before/after でテナントの setup/teardown したら重かったので before(:suite)/afer(:suite) に
- namespacing のテストは難しい
- マルチスレッド×マルチテナントのテスト
JITコンパイラはいかにRailsを速くするか
- 自己紹介
- YARV-MJIT
- Rails が安定して動かなかったので直していた
- CRuby 向けの JIT たち: RuJIT, Eclipse OMR, LLRB, MJIT, YARV-MJIT
- MJIT と YARV-MJIT の話
- で、Rails で動くんですか?
- そもそも Ruby 本体のテストが全部は通らない
- YARV-MJIT + Rails は JIT 無効だと動く
- optcarrot でのベンチマーク結果
- rails_ruby_bench : このベンチマークの実行が難しい
- Ruby Grant 2017 をやっている
- YARV-MJIT の最適化の仕組み
- JIT コードの最適化戦略
- 戦略ごとの説明と Rails にきくかどうか
- Rails での YARV-MJIT の使い方
クロージング
- 2018/3/24,3/25 Rails Developers Meetup 2018
- 募集開始は 2018/2/5(月) 10:00-
感想
Rails とは直接関係ない話もいくつかあった気がしますが、いろいろあって面白かったです。
YARV-MJIT の話は RubyKaigi 2017 では LT でちゃんと話せていなかったのが、今回聞けてよかったです。(わかったとは言ってない。)
Disqus Comments