22Inc. サービス開発日誌

スタンプスのサービス開発チームが日々の業務で得たノウハウ、経験の共有ブログです。

RubyKaigi2019レポート(後半)

こんにちは、22Inc.の山崎です。

2019/04/18〜4/20 に福岡県にて開催されたRubyKaigi2019に参加してきたので、その様子をレポートにしました!

本記事では、2日目〜最終日の内容をお伝えします。

1日目のレポート記事はこちらをどうぞ!

blog.22inc.jp

(なお、記事内の画像は以下のページからお借りしております

https://photos.google.com/share/AF1QipPrHqc-rexwG-ASKojHP3nxWeTScE58YKGNGn87F2bU5KOhsVmwhyzCXEZ-ACWbvA?key=cTN4M1lOVEcwRnJRenBLV1hPWjVYNDZCcmJOR2JB

https://photos.google.com/share/AF1QipOu5CgxFtGvRHgUbuv2sB-6ftZrJrgWCEna_zc1OeQ3faxcCKm9yQfWyELkfgee3A?key=d0VUMmFzZDF5bWY4NkFqWk5vbGR5WGRFR0hNZm9R

)

2日目

スポンサードトーク

2日目はZOZOテクノロジーズ様とマネーフォワード様によるスポンサードトークから始まりました。

日本最大級のアパレルECとクラウド会計サービスを提供している2社がスポンサーというのは、改めて考えると凄いことだな〜としみじみ…

キーノート : All bugfixes are incompatibilities

f:id:yamazaki22:20190507185332j:plain

2日目は@nagachikaさんによる、Rubyの機能追加のマネジメント体制についてのお話。

Rubyの開発は主にtrunkというブランチで行われている(Gitでいうところのmaster)というのは初めて知りました。各Verにどの機能追加をするかや、どの修正パッチを当てるかを意思決定する人がメンテナとして活動しており、主に3人いるとのことです。

開発言語それ自体の改修という作業が、どういった判断基準によってなされているかを垣間見ることができて非常に興味深かったです!特に、機能追加による利便性向上と、後方互換性の喪失のトレードオフについてはなるほどな〜と考えさせられました。

Better CSV processing with Ruby 2.6

f:id:yamazaki22:20190507185834j:plain

@ktouさんと@284kmさんによる、CSVライブラリの速度向上をRuby2.6で実現したよ!というお話。

いろんなパターンでのCSV処理を1.5〜2.7倍ほど速くすることに成功しているという、とても成果の出ている取り組みでした。

複数パターンを考慮することとそれらに対して網羅的に改善を行うという、とても難しいミッションにお二人とも取り組んでおられていて尊敬です…

なお、「複数行書き出すには、Arrayオブジェクトを作って << で追加するほうが速いので、generate_lineメソッドは使わないこと!」という知見は明日から使用していこうと思います!

What is Domain Specific Language?

DSL(Domain Specific Language)とはいったい何者か?ということに切り込んだお話でした。

「英語のセマンティクスに類似した様相で、RSpecは定義されているため、言語としてRSpecは成り立つ」という旨の発言がありましたが、思わず「なるほど〜!」とうなずいてしまいました。

RSpecに限らずDSLとは、「既存の言語(RubyやC、Javaなど)が保持している単語や文法を組み合わせることで、その組み合わせに対応したセマンティクスによって構成される集合体である」という思想なのかな、と解釈しました。

3日目(最終日)

キーノート : Rubyコミッター VS World

f:id:yamazaki22:20190507185713j:plain

いよいよ最終日!最終日はMatzとRubyコミッター陣が壇上に上がり、Rubyの今後の開発にまつわる話がなされました。

大きく分けると、以下の2つの話題がありました

  • Rubyコミッター陣への質問

  • Matzからの提案(新たな記法の搭載)

Rubyコミッター陣への質問

Rubyの後方互換性を維持することを重視する保守的な思考についてどう思うか?という質問から幕を開けました。

Rubyコミッター陣および会場にいる参加者からは、「もっとドラスティックに機能変更していこうぜ!」という意見が多く見られましたが、当のMatzは「いろいろ変更して不具合起きたときに大変なのは、開発者の僕なんだからね!」という旨の発言が飛び出し、会場は爆笑の渦に包まれました笑

Matzからの提案(新たな記法の搭載) と Numbered parameters

Matzからの新たな記法の提案は、Elixirで使用されているメソッドを連鎖させる記法をRubyにも取り入れようというものでした。

a .. b |> each do
end
#というのはどうか?

x |> method1(1) |> method2(2)
x.method(1).method(2)
# という感じ

これについては色々と議論があったものの、最終的には3.0に導入するかもね、という着地になりました。

Numbered parameters

Cleaning up a huge ruby application - RubyKaigi 2019

@riseshiaさんによる、不要なコードをいかに消していったかというプロジェクトの発表でした。

@riseshiaさんの所属するクックパッドには不要なコードがいくつかあったものの、「本当にそのコードを消しても良いのか?」という問題がありました。これ、歴史があるサービスを提供しているチームにいる人ならよく分かりますよね。。。

コードを消す、という作業は一見すると生産性が高いとは思えない作業ですし、エンジニアにとってテンションが上がるとは言い難いものでもあります…笑

ついつい優先度を下げがちな「コードの削減」という作業を他の人達を巻き込みながら進めていくという、プロジェクトマネジメントとしても興味深い内容でした。

Performance Optimization Techniques of MessagePack-Ruby

f:id:yamazaki22:20190507185741j:plain

@frsyukiさんによる、MessagePackを用いたパフォーマンス最適化についてのお話でした。

MessagePackは処理速度の速いデータフォーマットですが、なぜそもそも処理速度が速いのかといったところから解説をしてもらいました。

データのフリーズによるメモリ共有や、メソッドがどのクラスに実装されているかのルックアップに伴うオーバーヘッドの削減など、普段はあまり強く意識しないパフォーマンス部分について改めて意識するきっかけになりました!

スポンサードトーク

最後のスポンサードトークは、リンクアンドモチベーション様とOCT様によるトークでした。

有名企業のみなさまに御助力によってこのRubyKaigiが成り立っているのだなあと、3日間を通して感じました。

クロージングキーノート

f:id:yamazaki22:20190507185810j:plain

最後は@jeremyevans0さんによる、Rubyのコードをいかにハイパフォーマンスにするかというお話でした。

残念ながら私は帰りの飛行機の関係上、途中で退出せざるを得ませんでした。。。

ただ、少し聞いただけでも感じましたが…非常に濃密でマニアックな発表でした笑

そこまでやるか!?と思わざるを得ないようなパフォーマンスチューニングを発表しており、会場がざわついていました笑

まとめ

3日間におよぶRubyKaigiの様子をお伝えしました。

どのセッションもハイレベルで、すぐに日々の業務に活かすことは難しいな〜というのが正直な感想です。

ただ、Rubyというコミュニティの強固さや今後の伸びしろを改めて感じ、自分も何かしら貢献していかねばと思いました。

来年は長野でRubyKaigiが開催されますが、来年は何かしら会社としてスポンサードできれば良いなーとも思っています。

この素晴らしいカンファレンスを企画・運営してくださったみなさま、本当にありがとうございました!

来年は長野で会いましょう(^-^)