はじめに
4/18〜4/20に開催されたRubyKaigiに、スタメンエンジニア@mmoto99299415(写真左) と @uuushiro(写真右)の2名で参加してきました。そのレポート記事になります。
セッション
いくつか気になったセッションを紹介します。
1日目
Building Serverless Applications in Ruby with AWS Lambda
AWS SDK for Ruby チーム の@alexwwoodさんによるセッションでした。 柔軟性・スケーラビリティ・高可用性・セキュア・従量課金制といったサーバーレスの利点の説明から、実際にAWS SAM CLI・AWS SDK for Ruby・aws-record を用いたサーバーレスアプリケーションのライブデモの実施まで丁寧に説明してくれました。スタメンでも分析基盤のコンポーネントの一つにRubyを実行するAWS Lambdaがあります。別の機会にテックブログで紹介したいと思います。
https://speakerdeck.com/awood45/building-serverless-applications-in-ruby-with-aws-lambda
GraphQL Migration: A Proper Use Case for Metaprogramming?
Square Incのエンジニアである@gao_shawneeさんによるセッション。 GraphQLを扱うにあたり、サーバーサイド側では、モデルに対応したType・Fieldを定義する必要があります。加えて、Queryによりデータを取得するため、QueryType内に必要となるFieldと、それに対応したメソッドを定義します。対象とするモデルが増えると、Type・Field・メソッドの定義も一緒に増加し、だんだんFatになっていきます。 メタプログラミングを利用することで、動的にType・Field・メソッドを定義してこの問題を防ぐという内容のセッションでした。 スタメンではGraphQLを採用したサービスはまだありませんが、今後導入する場合は同じ問題に直面するので、とても参考になりました。
https://speakerdeck.com/shawneegao/ruby-kaigi-slides
2日目
Yabeda: Monitoring monogatari
eBaymag.com を運用しているエンジニアの@Envekさんによるセッションでした。 eBaymagでは大規模なSidekiqの運用をしており、そこで学んだ経験についてのトークでした。例えば、Sidekiqのジョブが遅くなったとき、それがなぜ遅くなったのか、どこから考えるべきか、原因を見つけるにあたって必要な理論はなにか？といったような現実世界での課題に対して具体的な方法を知ることができました。スタメンではSidekiqの数値の監視にはSidekiq標準のダッシュボードしか利用していませんでしたが、このセッションでは、prometheus-client という gem を利用してアプリケーションに簡単に Prometheus で監視するためのメトリックを追加し、Grafanaによってクラフを作成し可視化するということを実践していました。アプリケーションが成長に伴って、監視すべきメトリクスも増えていくことは今後の参考になりそうでした。
3日目
Cleaning up a huge ruby application
Cookpad Incのエンジニアである@riseshiaさんのセッション。 不要なコードを削除することで、コードの可読性が高まり、アプリケーションの読み込み時間も改善できたという内容でした。 具体的には次のような取り組みが紹介されていました。 - コードを削除するための仕組みづくり（どのようにメンバーにアサインするか） - ソースコードが実行されているかどうかの調査方法 → logの取得 - 詳細なlogの取得方法（InstructionSequense, oneshot coverage）
コードを削除することは、成果がすぐに現れないため、どうしても優先順位が後ろになります。でもその中で、仕組み化し、実践していく方法は参考になりました。 １年間で実際に数万行のコードを削除できた。という成果をみて、毎日の積み重ねの重要さを感じました。
https://speakerdeck.com/riseshia/cleaning-up-a-huge-ruby-application
ブース
各企業のブースを見て回りました。
普段、RubyMineを使って開発しているのですが、そのエディタを提供しているJetBrainsもブースを出していました。様々なノベルティが有り、面白かったです。
同じ名古屋からは エイチーム がブースを出しており、はるばる福岡で話をすることができて嬉しかったです。
他にもブースを回ったのですが、エンジニアの方とゆっくり話ができて、有意義な時間が過ごせました。
感想
松谷(@uuushiro)
初参加のRubyKaigiとても楽しかったです。特に印象に残ったのは、3日目の「Ruby Committers vs the World」という、Rubyコミッタの方たちがステージ上でこれからのRubyについて様々な議論を繰り広げるといったコーナーです。そのコーナーの中では、コミッタの皆さんのRubyを良くしたいという思いと、絶え間ない努力を重ねてきたという過程を垣間見ることができ、改めて支えてくださっている方々に感謝の気持ちが湧きました。 コミッタの方同士の掛け合いが日本語で交わされるのも日本発祥のプログラミング言語ならではだと思いましたが、グローバルな仲間たちとコミュニケーションをとり、RubyKaigiをもっと楽しめるように英語の壁を乗り越えて来年のRubyKaigiを迎えたいです。また、Rubyを支えている側と利用している側の間に大きい技術的な壁を感じました。私自身、Rubyを支えている方々と同じ目線でRubyの未来を考えられるように、エンジニアとしてもっと成長したいと思いました。 スタメンの創業事業「TUNAG」は、Rubyを利用し成長してきました。スタメンとしてもRubyにお世話になるだけではなく、恩返しをしてきたいと思います。 来年のRubyKaigiは松本市ということで、名古屋から近いのでスタメンのエンジニアみんなで参加します。 RubyKaigiでお世話になった皆さん、本当にありがとうございました。来年もよろしくお願いします。
ミツモト(@mmoto99299415)
RubyKaigiに参加し、充実した時間を過ごすことができました。各セッションを通じて、普段の開発では知ることのできない内容に触れ、深く掘り下げるきっかけが得られました。（ただ、日本語通訳が無いのは辛かった汗） 最も心に残ったセッションは、自分も松谷と同じ「Ruby Committers vs the World」です。 互換性を捨ててでもアグレッシブに仕様を変えていくべきか？という議題や、version upで追加したい新しい機能（右代入、イテレートのブロックパラメーター）において、様々な意見が交わされていました。Rubyを開発する上での議論を目の当たりにして、1Rubyistとして興味深かったです。 これまで、Rubyという言語で当たり前のように開発していましたが、その裏側にいるコミッタ、安定版のversionを提供するメンテナーの方々のおかげで、普段の開発が成り立っていることを肌で感じることができました。 加えて、RubyKaigiを通じて、他のエンジニアと交流を持てたこともすごく嬉しかったです。アプリケーションを作るにあたり、アーキテクチャ、技術選定、開発体制など、一緒に議論できる仲間が増えたのはすごく良かったです。
おまけ
スタメンはちょうど4月に福岡支社を立ち上げたので、福岡支社のメンバーとめんたい重を食べてきました！ 福岡でもスタメンをよろしくお願いします。
おわりに
今回、RubyKaigiには業務として参加しており、宿泊費と交通費を会社に負担してもらいました。 スタメンではRubyを書く機会がたくさんあります！絶賛Rubyistを募集中です！！興味がある方はWantedlyよりご連絡ください。
