過去最大規模のRuby on Railsのカンファレンス「Rails Developers Meetup 2019」に参加しました!

投稿者: | 2019年4月8日

こんにちは!
GMOアドマーケティングのT.Iです。

2019年3月22〜23日の2日間にわたって開催されたRails Developers Meetup 2019に参加したので、当日の様子を参加レポートという形で紹介させていただきます。
※今回は有料の勉強会でしたが、社内のエンジニア支援制度を使って参加費は会社負担で参加させていただきました。

Rails Developers Meetupとは?

Rails Developers Meetupは『Rails導入企業・Rails開発者が集まり、Railsコミュニティの活性化と技術交流を目的とした勉強会』で、2017年5月に第1回のイベントが開催されました。
開催ごとに規模は拡大し、今年開催された『Rails Developers Meetup 2019』は300名超のエンジニアが集まる過去最大規模のRuby on Railsのカンファレンスとなりました。

Rails Developers Meetupが始まった経緯やこれまでの軌跡については以下の資料に記載されています。
イベントを企画、運営するノウハウも詰まっている素晴らしい資料です。
※以下の資料は「銀座Rails#2」での資料です

今回2日間でたくさんのセッションに参加しましたが、参加した中から一部のセッションのみ紹介します。


jQuery + Sass な SPA Rails アプリを React + CSS in JS にリプレースした話

ソニックガーデン社の自社サービスである、リモートワークのためのバーチャルオフィス『Remotty』を「jQuery + Sass」から「React + CSS in JS 」にリプレイスした話。
jQueryからReactへの移行方法やReactでのi18nの扱い方法などの技術的な紹介に加えて、ソニックガーデンの価値観の一つである「小口化」という考え方を元に「如何にリプレイスを乗り越えたのか」が紹介されていて、非常に勉強になるセッションでした。


少人数でサービスをすばやく開発するためのRails活用事例

少人数で素早く安全に開発するための取り組みを紹介したセッション。
HerokuやCDN、Swaggerなどの紹介も興味深かったのですが、中でも「Railsを(フルスタックなフレームワークとしてではなく)APIサーバーとして使った」という話は個人的にも興味のある領域だったのでとても参考になりました。
RailsをAPIサーバーとして使った理由、Railsを採用した理由など、共感する内容が多い発表でした。
Herokuのレスポンス問題をCDN(東京でキャッシュすれば実質東京!)で解決したというのもとても参考になりますね。


To make Ruby ready-to-use in the data science field. And the impact that it has on Rails applications.

Rubyでデータ処理を自然に(Pythonと同じぐらい)できるようにするための取り組みについて紹介したセッション。
私自身、Webアプリケーション開発はRuby、データ解析や機械学習はPythonといったように使い分けているので、このプロジェクトは引き続き注目していきたいです。
RubyでデータサイエンスをするためのDockerイメージもあるとのことなので、早速使ってみます。


万葉のRails新人研修のコードレビューコメントを分析してみました

万葉さんの新入社員教育用カリキュラムのコードレビューコメントを分析したというセッション。
特に面白かったのは話題の分析(ジャンル)で、話題の多くを占めていたのはドキュメンテーションやテスト、コーディングスタイルなど、Rails以外のものが多くを占めていたこと。
その理由を「初心者と経験者のギャップ」として

  • 初心者は「ちゃんと動くものを作れるかどうか」を心配
  • 経験者は「コードが”わかりやすいか”がいちばん気になる?」

のように分析していて、どの分野でも起こりうるギャップだと思いました。
個人的な考えとしては、コーディングスタイルは初心者にも改善しやすい事柄で、レビューする側も指摘しやすい(ハードルが低い)ので、結果としてコーディングスタイルやテストに関する指摘が多くなったのかなとも感じました。
これはリーダブルコードの「表面上の改善」にも繋がりますね。


毎日の開発に役立つRailsプラグインづくりの秘訣

先日話題になったheavens_doorを中心に、これまで作ってきたgemを紹介しながら「なぜgemを作るのか」を問いかけたセッション。
次々と紹介されるgemに会場がどよめいていたのが印象的でした。
「現場の問題を解決するためにgemを作る」という話がありましたが、私も日々仕事に取り組んでいるとたくさんの問題と接する機会があるので、すでに出回っているgemを使うだけではなく、gemを作る側にも回ろうという思いが強くなりました。


Ruby コミュニティの歩き方

タイトルの通りRubyとコミュニティ(地域やOSS、カンファレンスなど)の話。
特にOSSコミュニティの話やOSS活動でのコミュニケーションの内容ついては普段見る機会が少ないので興味深かったです。
私がRubyを好きになった理由の一つに「コミュニティ」があって、実際に地域コミュニティでもLTなどで登壇するようになりましたが、開発コミュニティにはまだ参加できてないので先程のgemの開発と同様にチャレンジしていきたいです。


操作履歴/時点指定アクセスの実現 – BiTemporal Data Model の実践

ある時点での情報へアクセスするためにBiTemporal Data Modelを導入したという話。
BiTemporal Data Modelについての知識がほとんどなかったので、「non-temporal」「uni-temporal」と比較した例が非常にわかりやすく勉強になりました。
最後にはActive RecordでBitemporal Data Modelを使うためのライブラリ「activerecord-bitemporal」がリアルタイムでOSS化され、会場は拍手に包まれました!


Webアプリケーションの開発運用で当たり前に必要とされる画像変換の中身

画像変換する上で知っておくべきこと(リサイズ, 色情報, Exif情報など)を紹介したセッション。
私が学生の頃に画像処理をやっていたことや、Exifを見る(カメラが趣味)機会があるので、画像変換についてはそれなりに辛さを理解していたこともあり、序盤に「画像変換エンジンを作ってみよう!」と聞いたときにかなり驚いたのですが、後半に「生半可な覚悟で画像変換エンジンは作れない」「ImageMagickは偉大」と聞いて腑に落ちました。
画像変換SaaSにまかせてしまうというのもいいですね。


ガチスタートアップ1人目のバックエンドエンジニアのリアルな戦略と奮闘

スタートアップでの技術選択やプログラマとしての葛藤や不安について、そしてその不安をどのように乗り越えたかについての話。
技術選択ではActive Storageを採用した話やwebpackerを使わなかった話など、スタートアップならではの話で、時間が許すのであればもっと詳細まで聞きたいと思えたセッションでした。
後半のマインド面も話も共感だらけでした。個人的にはベストセッション。

懇親会

セッションのあとには懇親会が開催されました。
Rubyコミュニティで繋がりのある方とお話できたり、はじめましての方ともコミュニケーションが取れてとても楽しかったです!
フォトジェニックなフードもたくさんありました。

さいごに

シンプルな感想にはなりますが、充実した楽しい2日間でした!
セッション以外のところに目を向けても

  • クオリティの高いパンフレット
  • フォトスポンサー枠があり、即座に写真が公開されていたこと
  • お水だけでなく、コーヒー(専用のブースあり)も用意されていたこと
  • ランチセッション(ランチ提供)があったこと
  • 2日連続で懇親会があったこと
  • 開催の後すぐに公式ページにスライドのリンクが掲載されたこと
  • セッションごとに質問用の専用ページが用意されていたこと

などなど、細かいところまでこだわりを感じた素晴らしいイベントでした。
私はすっかり楽しむ側だったので、主催、運営、登壇者の方々には感謝の気持ちでいっぱいです。

「Rails Developers Meetup」は今回で完結しますが、「RailsKaigi」として2020年に開催されるとのことです。
RailsKaigiの続報が楽しみですね!

※写真は「カンファレンス撮影協力」としてスポンサーをされていたラブグラフ様撮影の写真を使わせていただきました。ありがとうございます。

We are hiring!

GMOアドマーケティングではRubyエンジニアを募集しています。
興味がある方は以下のページをご覧ください。