Home • About • me

Rails Developers Meetup 2018: Day 2 大阪会場に参加しました

Tags: ,
Created at: 2018-03-25 02:00:00
Last modified at:

Rails Developers Meetup 2018: Day 2 大阪会場 に参加しました。

以下、メモです。

会場

大阪会場は昨日と同じ場所でした。

Observability, Service Meshes and Microservices

  • トラックA
  • Draft: Observability, Service Mesh and Microservices by taiki45
  • マイクロサービスに挑戦している理由については時間の都合上カットして資料に掲載
  • Service Mesh とは
  • マイクロサービスでの問題点
  • Observability
  • 繋がり部分を監視
  • アプリケーションの外から監視
  • つなぎ目の要所の proxy を中央の control-plane から管理できるのが新規性
  • data-plane : Envoy proxy

ある程度の規模がある環境向けという感じで個人で数台で気軽に試せる規模ではあまり関係なさそうだけど、そのうち使うようになるのかもしれない。

冴えてるRailsエンジニアの育て方

  • トラックB
  • 前置き
    • 自己紹介
    • Rails 経験者はなかなかいない
  • 採用編
    • 「コミュニティへの露出をして採用に繋がらなくてもめげない」
    • 直接と紹介会社経由のルートがある
    • 行動: 技術者コミュニティへの露出
    • 紹介会社経由で「関西Ruby会議でスポンサー」(2年前)していたのを覚えていて選んでもらえたことがある
    • 書類審査: 「少しでも多く今のアウトプットをみる」
    • その人が書いたコードを見るのが基本 (なければ Qiita でも blog でも)
    • なければお題を渡して書いてもらう
    • 課題も難しい場合は面接で
    • コード評価の視点
    • 他に書いてもらっているもの
    • 面接
      • 人柄 : 仕事でテンションが上がった瞬間は?
      • コミュニケーション能力 : 説明力 (重要度高い), 愛想が良い (重要度低い)
      • エンジニア魂 : 「今まで読んだ技術書の中で最もライフチェンジングだったものは?」「Ruby(…)の良いところ悪いところ」(良いところだけではだめ)「気になっている技術」
      • 技術面接
  • 育成編
    • 入社してすぐ : パイロットプロジェクト
    • コードレビュー
      • 習熟を意識する
      • 褒めるのも大事
    • ペアプログラミング
      • 五十六メソッド
      • 1日に1-2時間程度がリズムができて良い
      • 手離れを意識する
  • 質疑応答
    • 使っている採用サイト?
    • 10時間以上かかる課題は応募者が大変なのでは?
    • GitHub などに自分のプロダクトをあげましょう
    • 10時間以上というのは応募者と相談してなので、もっと短い場合もある
    • (聞き取れず)?
    • 多くの人はチュートリアルをさわっている程度
    • Qiita とかでもコントリビューションの多さだけではなくニッチなもので良い情報なども見落とさないようにしている
  • 冴えてるRailsエンジニアの育て方 by KUROKI Shinsuke
  • あとで twitter で紹介されていた参考資料

色々と参考になりました。

コードレビュー自動化の最前線から

  • トラックA
  • しようぜといっている → したくない
  • するときもされるときも考えることがたくさんある
  • コードレビューは難しい
  • めんどくさい、時間がかかる、人間関係 → 機械にやらせたい
  • コードレビューとは
  • コードレビューの自動化
  • コードの問題
  • プロジェクト固有の問題
    • .env.sample
    • プロジェクト固有のメソッド
    • 一般的な lint ツールではカバーできない
  • そのために RuboCop プラグインを作るのは大変
  • 解決方法 : 簡単にルールを追加できる lint ツールを開発する
  • querly という gem を作った
  • 使い方の例
  • 精度が悪い
    • false positive が多い → 意図されたデザイン
    • 「雑にルールを追加して、雑に検査する」
    • PR で変更されたところだけ表示して絶対数を減らす
    • OSS (reviewdog) でやるか、金で解決 (SideCI)
  • 質疑応答
    • false positive はどれくらい?
    • 1PRで10とか20とか
  • コードレビュー自動化の最前線から by Soutaro Matsumoto

LT大会(( ⁰⊖⁰)/)

ながらみしていました。

バス因子が自分でバス因子を脱するための方法

  • トラックB
  • バス因子 ≒ トラックナンバー
  • どうやってバス因子が生まれたか?
  • なぜバス因子を減らすのか?
    • やりたいことをやるため
    • 組織をスケールするため
  • バス因子を減らすために同僚とやってきたこと
    • 同僚が私を変えてくれたこと
      • 他の人にドキュメント化してもらう発想がなかった
      • 周りから機会を奪わない
    • 組織全体が変わったこと
  • バス因子が自分で バス因子を脱するための方法 by sinamon129

社会構造をハックする 〜電子申請編〜

チーム開発積み重ね 〜Railsの上にも9年〜

  • トラックB
  • 自己紹介
  • Rails の好きなところ
  • 9年前は仕事ではほとんど使われていなかった
  • 最近は普通に使われている
  • 銀の弾丸はない
  • 自分たちのレールを作って敷いていく
  • Rails の思想や考え方を知る
  • チームの開発の流れを知る
    • チームの数だけやりかたがある
  • https://github.com/everyleaf/el-training
  • コミュニケーションについて
    • 伝え続けたり、伝え方を変えたり
  • そもそも伝えてなかった
  • 言葉(言語)は大事
  • コードレビュー
  • Team Geek の HRT
  • ツールについて
    • RuboCop
    • コーディングガイド : 迷わなくて良いように決めておくもの
    • SPA
    • ツールに使われたくない
  • 決める係を決めておく
  • 役割をまわす
  • わかるとできるの壁
  • 完璧にできなくて良い
  • マンネリに気をつける
  • 役を振ってみる
  • 意思が大事
  • めんどくさいことは早めに対処したい
  • 現状を疑う : よりよくできないか考える
  • 理想と現実の使い方
  • 視点?
  • 遊び心を忘れない
  • つまったとき
  • 勉強会
  • 自分と同じ経験値の人たちと
  • 経験値のすごい人と
  • 知識を育てる
  • 知識を使う
  • ゆるいアウトプット
  • チーム開発積み重ね Rails Developers Meetup 2018 Day2

FintechとRailsとgRPCと

  • トラックB
  • 自己紹介
  • Fintech
  • 金融サービスに求められること : 高い安定性、様々なコンプライアンス対応
  • 一方で「革新的」「開放的」でありたい
  • エンジニアの「得意」ごとにチームが分かれる
  • 「落ちたらマジでヤバイ」レベルごとにサービス分割
  • kubernetes を使っている
  • SRE の仕事を減らす
  • できる限り Infra as Code
  • サービスのデプロイは Slack から bot (ruboty) に依頼して Digdag に置いてあるデプロイタスクをキック
  • ログは CloudWatch で誰でも見える
  • gRPC
  • RPC as HTTP API : Rails だと REST + JSON が多い
  • gRPC は Protobuf
  • Protobuf の説明
  • Protobuf のメリット
    • 型がある : 複数言語で連携するサービスだと大きい
  • Protobuf のデメリット
    • バイナリなので human readable ではない
    • curl とかで簡単に確認できない
  • THEO では gRPC をどう使っているか
    • go + gRPC が多いらしい
  • Rails でどう使うか
  • 今回は PoC で徐々に本番に入れていきたい
  • FintechとRailsとgRPCと by cnosuke

サービスクラス、その前に

  • スポンサーセッション
  • ビジネスロジックという用語は明確な定義はない
  • MVC の M がビジネスロジック
  • M は V と C 以外の全て
  • Model の設計方針はエンジニアの手に委ねられている
  • Rails の出発点は Model = ActiveRecord
  • Form とか Service とか
  • Model の Rail は自分たちで引いていきましょう
  • サービスクラス、その前に

リモートなチーム開発

  • トラックB
  • リモートなチーム開発 / Team Development Remotely by Ryunosuke Sato
  • チーム開発としてのリモートワーク
  • 難しさについて考えてみる
  • 負のフォース
  • 同期が大事という話
  • リモートが原因での失敗はない (失敗するときは別の問題がある)
  • リモートが原因でまずさが拡大することはある (調整するタイミングもつかめない)
  • いくつかの実例
  • 質疑応答
    • 最初はオフライン
    • zoom
    • esa

ActiveRecordデータ処理アンチパターン

  • トラックB
  • 自己紹介
  • 1行概要
  • 本発表のゴール
  • Why not SQL?
    • DB とのインタラクションを ActiveRecord モデルに集約
  • ベンチマーク環境
    • Circle CI
    • User has many Posts : User 10万件、Post 約50万件
    • タイムゾーンは UTC
  • ActiveRecordデータ処理アンチパターン | Toshimaru’s Blog
  • 事例1: 全ユーザーの中から2017年以降の登録ユーザーへ100ポイントを付与する
    • All Each Pattern
      • all → where
      • each → find_each
    • N+1 Update Queries Pattenr
      • update → update_all
    • update と update_all は等価ではない
      • update_all は callback と validation をスキップする
      • テーブルロックに注意
  • 事例2: ユーザー毎の記事のいいね数（like_count）合計が多い順でTOP100ユーザーをユーザー名、いいね数とともに出力する
    • Ruby Aggregation Pattern : レコード全取得、Ruby の世界で集計・並び替え
      • All Each Pattern も踏んでいる
      • [Ruby] Sort_by & reverse → [SQL] order など
    • N+1 Queries Pattern
      • includes を付与
  • 事例3: ユーザー毎の記事のいいね数（like_count）合計が多い順でTOP3000ユーザーのユーザーID一覧を出力する。
    • Unnecessary Query Pattern
      • 本来必要ではないリソースを取得していること
      • 不必要な参照を削除 post.user.id → post.user_id
    • Unnecessary Model Init Pattern
      • 不必要な ActiveRecord モデルの生成が発生
      • select → pluck
  • ActiveRecord は諸刃の剣
  • データベースの最適化の方がシステム全体に効く汎用的な解決策となりやすい
  • ref. 「SQL アンチパターン」
  • 質疑応答
    • アンチパターン名の出典を教えてください → 僕です
  • ActiveRecordデータ処理アンチパターン / active-record-anti-patterns by toshimaru
  • https://github.com/toshimaru/rdm-rails5.1

「社内ツール作成サークル」活動記録

  • ここからはトラックAのみ
  • 自己紹介
  • サークル福利厚生が始まって飲み代がでるようになった
  • ツール紹介
  • 使ってる gem とか
  • なぜ内製するのか
  • 社内ツールと素振り
  • 社内ツールを作る文化を後押しする仕組み
  • 社内ツール独特の問題
  • 社内ツールを社内に広げる
  • 運営の問題
  • Webサービスはヨシヨシしないとスネる - pblog
  • 式年遷宮→ディスポーザブル長屋

これからの Ruby on Rails

  • https://railsdm.herokuapp.com/issues/1?sort=most_liked
  • デバッグ方法?
    • print debug, p
    • byebug を使うこともあるが fork してると使いにくいので print debug
    • スタックトレースとかみて再現方法を推理するしかないことも
  • MVC 以外のレイヤー
    • サービスは書きたくない
  • アンチパターン
    • action_args おすすめ
  • Railsで今後10年、まだ戦っていけると思いますか？また、今後10年Railsで戦っていくために、必要なことって何でしょうか?
    • DHH が毎回議論になるようなものを入れてくるのがすごい
    • DHH がいなくなると厳しい?
    • 10年間変わり続けている
    • コミッターも入れ替わっている
  • Railsのコードで「これはつらい。というか誰かなんとかできるの？」という部分ってあるでしょうか。
    • TimeZone 周りは歴史的経緯を知らないとつらい
    • basecamp のチャットで話していて GitHub の方だけみてもわからないことがある
    • ActiveRecord はつらいところがいっぱいある
    • scoping 周りが特に
    • journey, arel
  • 複数DB対応新着情報
  • ActionCable 使ってる?
    • 会場では少数
    • basecamp で使っている
    • ActiveStorage もその流れで入った
  • ActiveRecord に upsert ?
    • (飛ばされたか聞き逃したか?)
  • コミッターのみなさんに質問です。自身の Rails への快心のコミット、あるいは一番印象に残った PR や、PR でのやりとりなどあれば伺ってみたいです。
    • 一番最新のコミットが快心のコミット
    • where.not
  • つい最近までながらく松田さんが国内で唯一の Rails コミッターだったわけですけど、数年前と比べて Railsコミュニティ をとりまく状況とか雰囲気とかってこの数年で結構変化してきているものなんですかね？体感的に国内からの Rails Contribution もずいぶん増えている気がするんですけど、その辺の変化って何が起因しているんでしょうか
    • 謎
  • 機能ベースのリリース計画か日付ベースのリリース計画か
    • ある程度コミッター間ではリリース間隔の方針があるが遅れるのが普通
  • もうちょっと極端にいうと、機能ベースでのリリースを行なっているなら、現状のマイナーバージョンアップをメジャーバージョンアップにしてもいいのではないかとも思いますが、それについて意見はありますか。
    • 今ぐらいでいいんじゃないか
  • Rails コミッターのなかでも、◯◯ の詳細に関しては XX さんくらいしか把握していないので他のコミッターではレビューできない（例えば Aaron しかレビューできない）みたいな部分って結構あるものなんですかね？もしありそうなら ◯◯ と XX の例をいくつか挙げて欲しいです。ぶっちゃけ今 Rails の全体像を一番詳しく把握してそうなのって誰ですか？Rafael？
    • enum とかメンテナがいなくなっているので狙い目?
  • 主観でかまいませんので、もしかしたら廃止されるかもしれないよ、というAPIを教えてください（たとえば、accepts_nested_attributes_for や form_tag など、これは現段階では使わないほうがいいものがあれば）
    • 代替があるものは消える (form_tag とか)
    • accepts_nested_attributes_for は消えると不便になるだけなので消えないのではないか
    • 意外とみんな下位互換性を気にするので、いきなり消えて困ることは少ない (gem で残るとか)
  • かつてのActiveResourceやObserverのように、Railsの本体から外してもいいんじゃないか? と思われる機能はありますか? あと、機能が除外されるときは、コミッター内で相談があって、除外される感じなのでしょうか?（それともいきなり…?）
    • DHH の鶴の一声でいきなりはある
  • 本当は XX みたいな Pull Request がもっと欲しいんだけど来ないからコミッターが自分でやってる、みたいなのって何かあります？
    • なくはない
    • あとちょっと直してくれたらマージするのに、という状態のものがあるので、それを拾って直して欲しい
  • どんな道具を使ってRailsの開発をしていますか。使っている道具のイチオシポイント、こだわりポイントを教えてください。
    • vim
    • git blame, git log
  • Ruby on Railsの 愛して止まないところ はどこですか?
    • リアルな問題を解決してくれる道具
    • basecamp が実際の問題を解決するのに使っている
    • 確実にみんなに使われているので、直すと誰かの問題が解決する
  • Railsもしくは他のオープンソースソフトウェアのフルタイムコミッターになりたいと思いますか。 仮になりたいとして、現状そうではないのには、何が必要だと思いますか。 もしすでにそうであるとしたら、何が主な要因だったと思いますか。
    • お給金次第
    • アプリケーションプログラマとしてリアルな問題として踏んだバグを修正することが多い
    • 現場にいたい
    • Rails のフルタイムコミッターもいるが basecamp でプロダクトも触っているはず
  • 日本人コミッターのみなさんに質問です。もし日本の Rails に関するカンファレンスに、外タレの Rails コミッターをキーノートで1人呼ぶという立場になったら「誰に」「どういったテーマの話」でオファーを出されるでしょうか？
    • (メモとれず)

見てないセッションの発表資料

Rails Developers Meetup 2018 スライドまとめ というのもあるようです。

その他

ハッシュタグ #railsdm のツイートでは https://crash.academy/ に動画が公開される予定らしいです。 動画を公開すると言っている側のツイート以外の情報を見つけられていませんが、公式サイトにはスポンサーの撮影協力としてのっているので、信用しても良さそうです。

Disqus Comments
Written by

Kazuhiro NISHIYAMA

Ruby のコミッターとかやってます。 フルスタックエンジニア(って何?)かもしれません。 About znzに主なアカウントをまとめました。

znz znz

Published

Supported by