- 開催日時 -- 2017 年 8 月 5 日 (土) 13:00-18:00
- 開催場所 -- 株式会社 みんなのウェディング 会議室
- 主催 -- ginza.rb
- 参加者 -- およそ 80 名
- 公式サイト -- https://ginzarb.github.io/kaigi01/
- 公式ハッシュタグ -- #ginzarb (通常ミートアップと同一)
ぎんざ.rb は 2013 年 6 月に発足し、毎月第 3 火曜にミートアップを開催しており、 2017 年 8 月に 50 回目のミートアップを迎える事を記念して、 ぎんざ Ruby 会議 01 が開催されました。その様子についてレポートします。
いつもミートアップ告知ページで愛嬌のある猫のイラストを書かれている @ken1flan さんによると、 Ruby on Rails 4 が出る頃に、ランチで集まって話をしている間に「Rails 4 を勉強しなきゃね」という話題になり、 ぎんざ.rb が始まったそうです。Ruby on Rails 周辺の話題が多く聞けるミートアップという印象がありましたが、その理由を知ることができました。
基調講演「Rails コミュニティの話」 from 松田 明さん (@a_matsuda)
Ruby と Rails 両方のコミッターである松田さんから「Ginza.rb というコミュニティが Rails 4.0 以降に始まったので、それ以前の Rails のコミュニティについて、語ろうかな」と話されました。
Ruby on Rails のトップページ(http://rubyonrails.org/) には、なぜかトップからは飛べないリンクがあるそうです。そのページ(http://rubyonrails.org/community)によると Rails Community とは、 Rails ユーザではなく、 Rails 開発者のことを指すそうです。Rails Community は以下の 3 つの役割ごとにチームに分かれているそうです。
- commiters チーム
- Issue チーム
- docrails チーム
また、開発を離れた人は The Alumni となり、Rails Community 自体も健全に新陳代謝しているそうです。Rails にコミットを残すと名前が載る、Rails Contributors がありますが、このサイト自身もOSSになっているため、今回の講演のために、パッチを当てて、各バージョンごとに活躍した開発者のコミットを集計したそうです。その集計結果をメジャーバージョンごとに見ていきながら、
- 当時活躍したコミッタの担当範囲や、海外のカンファレンスに参加することでわかる人柄
- 入った機能や消えた機能
- 当時の技術トレンド
などについて松田さんの視点で語られました。講演の最後に、「人を知ると、プロダクトの見え方や GitHub 上での SNS 活動のリアリティが変わります。日本にいても Rails のコミュニティには会えません。海外に出ていきましょう。」との言葉で締めくくられました。
「ActiveSupport::Multibyte::Unicode::UnicodeDatabase を消したかった」 from 松島 史秋さん (@mtsmfm)
Rails を使っている方は Rails で 1 番大きなファイルが何かご存知でしょうか？松島さんによると、Unicode正規化処理のモジュール ActiveSupport::Multibyte::Unicode::UnicodeDatabase が使用している unicode_tables.dat だそうです。
ちょうど直前に基調講演をされた松田さんの Rails Conf 2016 での講演資料をヒントに Unicode 正規化について理解を深め、Ruby 本体のメソッドで置き換えていき、この巨大ファイルを使った処理を削減する挑戦について発表されました。 最終的に Rails 本体に送ったプルリクエストは、Ruby 2.x 系のサポートする Unicode のバージョンと Rails のサポートする Unicode のバージョンの差異にためにプルリクエスト #26743 をマージすることができないそうです。Rails 6.0 でマージされるか注目したいと思います。
「マイクロサービス指向 Rails API 開発ガイド」 from 森 久太郎さん (@qsona)
勤務先の会社のビジネス上、 Web API や マイクロサービスを大事にして開発されているそうです。Web API でよくある失敗を避けるために「強いリソース指向」というものを取り決めて開発しているということでした。強いリソース指向で定義した、リソースを BFF(Backends For Frontend) でまとめあげる例が、スマートフォンアプリの画面で示されていました。 UI の柔軟さに対応するためにもドメインモデルの考察が重要だということです。そして、Rails で実装する方法について話されました。
「Railsを仕事にする会社で新卒が1年間学んだこと」 from 小林 純一さん (@junk0612)
新卒の立場から、どんなことを学び、考えてきたのかを情報共有したい、という趣旨で以下のトピックについて話されました。
- Ruby の面白さ
- Rails に早く乗るには
- PR で考えておくといいこと
- Git でコード外の意図を伝える
この発表は、前月に行われたイベント Rails Developers Meetup #3 で発表された、勤務先の先輩である伊藤浩一さんの発表(資料) と対をなすそうです。プルリクエストのレビューで同じ指摘をされないように、プルリクエストを出す前にチームメンバーになりきってレビューしてみたり、自分の性格を考慮してコミットを書く習慣づけをしたりと言った工夫をされているそうです。新人でなくとも、見直してみると役立ちそうなトピックを話されました。
「Spring Frameworkと比較して学ぶ、Webアプリケーションフレームワークの責務分担」 from 鈴木 雄大さん (@onigra)
Ruby on Rails という Webアプリケーションフレームワークには、批判が割りと多いそうです。鈴木さんは、現在お勤めの会社に転職後、 Java + Spring Framework(Spring Boot) に触れたことから、 Spring Framework との比較を通して、 Ruby on Rails への批判の内容を理解しようという発表をされました。2 つのフレームの機能を比較していくと、Rails はユースケースを絞って割り切った設計をしていて、マッチしないビジネス要件にはつらみが出ることもあるそうです。一方、 Spring Framework ははじめから広いユースケースに対応するように設計されているため、複雑なビジネス要件や長期的な拡張性を考えると適しているそうですが、あらかじめ理解しなくてはいけないことも多いそうです。最後に、「どちらが優れていると優劣をつけるのではなく、フレームワークやアーキテクチャの思想とユースケースを理解して、適切な技術選定をしましょう」と締められました。
「Railsアプリケーションのパフォーマンス改善手法」 from 国分 崇志さん (@k0kubun)
テンプレートエンジンの高速化などで、 Rails をお使いの方がお世話になっているであろう、国分さんから以下について話されました。
- パフォーマンス改善の失敗パターン、原因分析と対策
- 各種プロファイリングツールの仕組みとメリット・デメリット
- 実際にコードレビューで見た非効率なコードとその改善例
テンプレートエンジンの速度改善を手がける国分さんならではと思わされるトピックも多くありました。パフォーマンス改善は、計測自体がとても難しいことがあるとのことでした。プロファイラの使い方などをどうやって調べたり、憶えていくのかと著者が発表後に個人的にお話を伺ったところ、覚えていられないのでラッパーのスクリプトやコマンドを書いていて、その時に覚えたり、覚える必要がなくなったりしているという回答をいただきました。
以下のメンバーによる Lightning Talk が行われました。
- 「Application Templateのススメ」 from @onk さん
- 「Railsフロントエンドの modernizeにおける一事例 ~ decaffeinateからES2015移行まで ~」 from @treby さん
- 「歴史あるPHPアプリケーションのジョブキューシステムのリプレース」 from @hypermkt さん
- 資料 さん
- サービス中断を伴うメンテナンスを極力避けてゲームの運用をしている話 by @tkeo さん
- 似非サービスクラスの殺し方 from @joker1007 さん
- 資料 さん
基調Q&A from 上薗 竜太さん (@kamipo)
Rails の ActiveRecord ライブラリに数多くのコミットを残していることで有名な上薗さんが、 事前に集めた質問に答えていく形で、Q&Aが展開されました。思い出深い Rails へのプルリクエストからよく行く飲み屋までざっくばらんに回答されていました。
上薗さんは、自分が解決したい問題の認知を高めるために、GitHub のプルリクエストでキリ番を取るということを実践されているそうです。 例えば、プルリクエストの 30000 番を取るために、 29996 から 30000 まで連続でプルリクエストを出していることが明らかになり、会場ではスゴいという驚嘆の声が漏れていました。普段から手元に数多くのコミットを作っておき、どの順番でプルリクエストを出せばマージされるか、非常に戦略を練られていました。中には、rails は Cosmetic Changes のプルリクエストは受け付けていないため、「 trailing space を消すためにそのファイルを弄れる修正を考える」こともあるそうで、とてもすごい情熱です。その結果としてか、本会議の直後には Rails のコントリビュータに就任されました。これからも上薗さんの活躍に期待ですね。
以下の企業様にスポンサーして頂きました。ありがとうございました。(50音順)
- 永和システムマネジメント株式会社
- 株式会社ドリコム
- 株式会社みんなのウェディング
@suginoy -- フリーランスで Web エンジニアを数年やっています。最近は Ruby on Rails を使ったサービスの開発に関わることが多いです。