こんにちは。最近は奥さんの影響でVaundyとCreepy Nutsばかり聞いています P山 です。先日三重県津市で開催されたRubyKaigi 2022 へ参加したので、そのレポートをお届けします。
RubyKaigiとは
みなさまも御存知の通り、Rubyは島根県在住のMatzことまつもとゆきひろ さんによって開発されたプログラミング言語です。いまや世界中で利用されているRubyの国内最大級のカンファレンスがRubyKaigiです。2022年は3年ぶりのオフラインでの開催がありました。また同時にオンラインでの配信も行われており、現地にいかなくても楽しめるイベントでした。
オフラインの会場は三重県津市にある、三重県総合文化センターで実施されました。
また会場内の中庭ではランチ用のテントが建てられており、外で数種類の弁当を楽しむことができました。
ご覧の通り、とても大きな会場で、スピーカーセッションは2つのホールで日本語、英語それぞれのセッションが行われていました。
GMOペパボでは今回GMOインターネットグループがスポンサー協賛したので、GMOインターネットグループのパートナーとブースを出店しています。
今回のブースでは、謎のテクノロジーによって、狙ったアイテムをゲットできない、千本つりを提供しました。会場でブースに来ていただいた皆様有難うございました。
セッション紹介
今回、GMOインターネットグループとしては30名近くのパートナーがオンライン・オフラインで参加しており、それぞれのメンバーから、リレー形式で印象に残ったセッションを紹介します。
The Better RuboCop World to enjoy Ruby
引き続きP山からは、株式会社万葉の @nay3 さんのセッションを紹介します。
このセッションは世の中の多くのRubyistが大変お世話になっているRuboCopについて、同じく、多くのRubyistが頭を悩ませている、「状況にあわないルール」などを示しながら、どのようにRuboCopと付き合っていくかということを述べたセッションでした。
まずセッションはRuboCop開発者への感謝、リスペクトの明示に始まり、RuboCopをそのまま利用すると、特にRubyに熟練していないエンジニアはRuboCopのルールの妥当性が判断できず、厳守してしまうことによって、かえって命名が状況にあわなかったり、未来安全ではない実装になってしまう課題があると述べられました。
スライドの言葉を借りた私見ですが、Rubyのスキルがある人は「Rubyを使えば何でも思い通りにサッと書ける」が、スキルのない人はRuboCopに強く制約されるがゆえに、Ruby本来の楽しさや生産性を損なってしまうことがあるとP山も感じます。
僕とか、自分しかメンテしないようなプロジェクトのときには「俺の書き方が正しいし、これでええんや！！！と rubocop --auto-gen-config」で済ましてしまうこともありますが、プロダクションに入れるコードはそういうわけにもいかず、RuboCopのためのコードを書いたこともあります。
セッションの話に戻ると、これらの課題に立ち向かうには、下記の手段があると述べられています。
- プロジェクト全体のルールを変える
- そのコードではルールを変える
- とりま、ルールに従っておく
これらの3以外については、RuboCopでは設定ファイルを利用して、ルールごと、ファイルごとにルールを無効にすることができるので、それらを活用することで対応できるが、こういった設定の柔軟さだけでは、RuboCopに起因するリスクを回避できないと述べられています。その理由は、ルールの死活を決めるには経験、十分な技術力が必要であり、またRuboCopの開発チームもあらゆる利用者の未来のリーズを予見できないからであると述べられており、ではどうするかというと、自組織のためのルールを、自組織で適切に設定することが大事であると述べられました。万葉社では自社向けのベースラインのルールを作成しており、設定例は万葉社の新卒研修用のリポジトリで公開されています。
いよいよセッションも終盤に向かい、RuboCopに対して話し手が感じている価値観の共有、設定ファイルを定義する際に発生するジレンマがあると紹介されました。P山の解釈では、ルールを厳格にすると、状況にあわないルールが増えるが、一方でルールをゆるくしすぎると、コードの改善が減ってしまうというジレンマがあると理解しました。 それに対する対応としてはRuboCopの設定ファイルを厳守すべきルールと、情報提供のルールに分けることや、それらを用いてCIツールで強制させるのか、手元で実行した際に情報として提供するのかと行った使い分けを行うということでした。
そうすることで、守るべきものは守られて、情報提供されることで修正の気付きもあるのでとてもいいとP山は感じました。
ここまでがセッションの紹介です。P山の感想としては、開発者に対するリスペクトを示しながら、利用者としての困りごとの開示、改善提案が建設的に行われていて、かつスライドも日英併記されていて、多くの方に配慮されたとてもすばらいいセッションだと感じ、見習わなければなと強く思いました。それでは、次のセッション紹介はkeigoです。
Types teaches success, what will we do?
こんにちは、今年4月に新卒入社した keigoです。 私は、Fu-gaさんによる「Types teaches success, what will we do?」というセッションについての感想を書きます。
このセッションは、Rubyの型導入をより一般的にするために、gem_rbs_collectionにコントリビュートしていこうというお話でした。 印象的だったことは、冒頭で「Rubyを使用しているプロジェクトに型付けはありますか？」という質問から入ったことです。 会場の中で手をあげた方は少なかったです。しかし、「TypeScriptを導入していますか？」という質問に対しては、多くの方が手をあげていました 以上のことから、プロジェクトに型定義を導入した方がよいというのは共通認識はありつつも、Rubyプロジェクトでは導入しきれていないという現状が示されていました。
Ruby3.0には、RBS, Steepがバンドルされています。しかし、会場内のアンケート結果からみてもあまり使われてないことがわかります。 あまり使われていない理由として、約173,000個あるgemのなかで44個しか対応していないからなのでは？という考えが挙げられていました。 そこで、より一般的にしてくために「gem_rbs_collectionにcontributeしていこう」という話になっていきました。
contribute手法として、2パターン紹介されました。
1つめは、既存の型定義の修正・追加です。
こちらの手法は、はじめに steep checkコマンドを使用するなど、自分で未対応箇所を発見します。
そして未対応箇所を、手動でgem_rbs_collectionに型を記述していきます。
2つめは、新しいgemの型追加です。 こちらでは、手動で型を記述していくだけでなく、generatorを使用して自動で型追加をしていく手法が紹介されました。 実際にgeneratorを使用した型定義の追加から、テストの記述、PRにしていく過程を実例に基づいてお話いただきました。 また、全てのAPIの型定義をしなければいけないわけではなく、自分のプロジェクトで使用していたり、公式のREADMEやdocsに書いてあるような部分の型定義をすれば良いとのことです。 contributionのハードルを少し下げてくれている感じがして、とてもいいなと思いました。
感想
私は今回がRubyKaigi初参戦でした。まだまだ業務経験も浅く、Ruby歴も長くない自分がこのようなイベントに参加してもいいのか？と不安でした。 しかし実際にオラインで参加すると、Rubyコミュニティの存在を肌で感じることができました。今回参加したことで、Rubyの学習モチベーションが向上し、contributeしていきたい！！という気持ちが強くなっていきました。 今回このようなイベントに参加する機会をいただき、感謝の気持ちでいっぱいです。ありがとうございました。
Ruby meets WebAssembly
こんにちは！！！RubyKaigiに初めて参加した新卒エンジニアのpochyです。
私は、@kateinoigakukunさんによる、CRubyをWebAssemblyに移植するプロジェクトについて述べられたセッションを紹介します。このセッションは初日のKeynoteでした。
WebAssembly(WASM)は、バイナリ形式の低レベルな言語です。C言語やGo、Rustなどの言語からコンパイルされ、できたWASMファイルはブラウザーで実行することが可能です。WASMのプログラムはセキュアで実行環境に依存しないという特徴を持ち、処理が高速であることが期待されます。Rubyはバージョン3.2からWebAssemblyへのサポートが始まります。
このセッションではWASM版Rubyを作るに至った動機が語られ、実際にブラウザーでRubyを動かすライブデモを挟み、移植するにあたって直面した技術的課題の詳細が説明されました。
@kateinoigakuさんがRubyをWASMに移植しようと考えた主な動機は「Rubyへの参入を簡単にしたい」というものだと語られました。RubyがWASMで動くようになれば、Rubyで書かれたプログラムを動かすためにサーバーを立てる必要はなくなり、初学者が環境構築でつまずくこともなくなります。
動機の説明とWASMについての解説が終わると、ruby.wasmでプログラムを動かす実演が始まりました。
行われたデモは、素のHTMLファイルに <script type="text/ruby">というタグとともにRubyのコードを書いてブラウザーでそれを実行するという内容でした。書かれたプログラムは"Lucky"か"Unlucky"がランダムに出力される「おみくじ」のプログラムで、実行して見事に"Unlucky"が出ると会場が拍手に包まれました。また、ブラウザーでirb(Rubyのコンソール)が動作し実際にSVGが描画されるデモや、ブラウザーではなくedgeのWASMでRubyが実行されるデモが実演され、成功するたびに会場が盛り上がりました。irbのデモはこちらのページ、エッジコンピューティングのデモはこちらのページからそれぞれ実際に動いていることを確認できます。
デモに続いて、「WebAssemblyはブラウザーだけで動くものではない」という話が始まりました。WASI(WebAssembly System Interface)という標準化されたインターフェースを通すと、ウェブの外でもWebAssemblyを動かすことができます。しかし、WASIでの実行をするためにはバイナリファイルを一つだけにする必要があります。そこでwasi-vfsという仮想ファイルシステムを作り、複数のRubyファイルを格納してひとまとめにすることでシングルバイナリ化を達成したと述べられていました。
セッションの後半では、CRubyをWASMに移植する際に直面した難点が「３匹のドラゴンを討伐する話」として語られました。 CRubyは、その頭に"C"が付いているように、内部的にはC言語を使って書かれています。C言語で書かれたコードをWebAssemblyにコンパイルすることは簡単なように思われましたが、実装するにあたっては次の３つの難敵（ドラゴン）がいたそうです。
- Exeptions
- Fiber
- Conservative GC
これらのドラゴンを倒すために、Asyncifyという技術が使われました。Asyncifyは低レベルな一時停止・再開機能を提供するので、上記の問題点が一挙に解決されたそうです。
ここからは私pochyの感想です。私はこれまでフロントエンドを扱うことが多く、WASMのことはブラウザーで速い処理を行えるかもしれない技術として少しだけ注目していました。セッションではWASM/WASIのことを「ゲームチェンジャー」であると表現しており、デモでRubyをポータブルに動作させている様子を実際に見てWASI技術の可能性を感じました。また、WASIアプリケーションへのパッケージングツールやnpmパッケージが配布されていると聞いたので手元で試してみました。お手軽にRubyプログラムをブラウザーやWASIランタイムで動かすことができたので、今後の技術発展がさらに楽しみになりました。
Ruby Committers vs The World
今年4月に新卒入社した技術部のyuchiです。私が印象に残ったセッションは2日目の最後のRuby Committers vs The World (資料)です。
このセッションはRubyKaigi 2022に来場しているRubyコミッターがメインホール壇上に集結し、What is your future Ruby?というお題目に対して各コミッターの方からの発表がありました。
各コミッターの「Rubyを良くしていくぞ」の"熱量"や"やっていき"を感じられました。特にJeremyさんのBug-Free Rubyというスライドで「Bugs make programmers unhappy. Increase programmer happiness by avoiding」と発表されていたのは個人的に一番印象に残っています。バグは誰も幸せにならないですからね。
セッション後半ではコミッター同士が機能に対しての議論が始まり、RubyKaigiの伝統(?)を知ることもできました。
感想
自分は初めてこの規模のカンファレンスに参加しましたが本当に良い経験となりました。参加前は業務や趣味でもあまりRubyを書くことが無いため参加していいのか、楽しめるのかという気持ちでしたが実際3日間とても楽しくあっという間に過ぎていきました。 「お久しぶりです！」や「初めまして！」という会話をいろいろな場所でできたり、他社の新卒の方や入社数年の若手の方と多数お話しすることができたのはオフライン参加ならではだったと思います。 個人的に一番おもしろかったのは休憩中自作キーボードが並べられ、興味がある人々がそこに集まり自作キーボードの話が繰り広げられていたのは非常に印象的でした。
自作キーボードが集まってくる空間に来ています #rubykaigi pic.twitter.com/654wXYep8x
— yuchi / ゆーち (@F_YUUCHI) September 9, 2022
また、後述するRuby Music Mixinにも出演し、ほんの少しはコミュニティへの盛り上げに貢献ということはできたのかなと思っています。来年もし参加するのであればRubyに対しての理解を深め、セッションをより理解できるようになっておきたいと感じました。
DJイベント Ruby Music Mixin
改めましてyuchiとkeigoです。RubyKaigi 2022終了後、Music Loundge スポンサーであるpixivさん主催のRuby Music Mixinというイベントが開催されました。
今回yuchiとkeigoの2人がこのイベントでDJとして出演しました。会場に来場していただいた方、配信でご視聴していただいた方ありがとうございました。当日の盛り上がりはイベントハッシュタグ#ruby_music_mixinをぜひご覧ください。
yuchi感想
このイベントで2番目にDJをしましたyuchiです。カンファレンスが3日続いた後の懇親会的なイベントだったので落ち着いた感じの曲を流そうと思っていましたが、最初から会場はとても盛り上がっており、自分も出演10分前に流す曲をガラッと変えることをするぐらい素晴らしいパーティーでした。
RubyKaigi中にお話しすることが無かった方々ともお酒を片手に気軽に立ち話をすることができたあの時間はとても良かったと感じました。
keigo感想
このイベントで4番目にDJをしたkeigoです。普段自分はハウス系のダンスミュージックをプレイしますが、今回来ていただいているお客さんはRubyKaigiにこられた方ということで、みなさんが知っている有名曲のアレンジや、 We Will Rock YouにGMOのジングルを重ねるなど、楽しくプレイさせていただきました。
このようなパーティがあることで、RubyKaigi中にきっかけがなくて話すことができなかった人とも話すことができ、よりRubyコミュニティになじむことができた気がしました！ またこのようなイベントがあった際にはぜひ参加させていただきたいです。
How fast really is Ruby 3.x?
EC事業部の @aruma です。 株式会社クリアコードの藤本さんのセッションをご紹介します。
このセッションでは、Ruby3におけるパフォーマンスの改善（Ruby 3x3）を実際のアプリから評価するというテーマで、Fluentdで実測した結果が発表されていました。
Fluentdにて Ruby 3x3 を評価することには、以下のメリットがあるとのことでした。
- FluentdはRubyで重い処理を実行している。Ruby外の処理時間が大きいRailsよりも、Rubyのパフォーマンス改善の効果を受けやすい。
- Ruby v1の頃から続くプロジェクトであるため、Ruby 1.9.3 から Ruby 3.2.0 まで幅広く比較することができる。
Fluentdはログの収集を行えるソフトウエアです。パフォーマンスの評価は、一秒あたりの処理したログの行数を基準として実施されていました。
Ruby 3.2.0 + YJIT のパフォーマンスを Ruby 1.9.3 と比較すると、LTSVのパースでは約3.1倍、Nginxアクセスログでは約2.6倍高速に処理ができ、Rubyの高速化によりFluentdに大きなパフォーマンス改善がもたらされたことが示されていました。
次に、Rubyと他のスクリプト言語のパフォーマンス比較結果が発表されました。 この比較はテキストをパースするというコードを、可能な限り各言語で条件をそろえて行われていました。
この実験の結果は、パフォーマンス順で各言語を並べるとどのような順番になるか、というクイズとして出題されました。 私は、「Ruby 3x3 によって、Rubyは他と比較しても中間的あるいはより高速になったのではないか」と予想しましたが、残念ながら結果としてはLuaやPerl、Pythonの方がより高いパフォーマンスとなったそうです。
他言語でも高速化の取り組みが行われている。 アプリ開発者としては Ruby 3x3 Revisited が実現されると嬉しい、という内容でした。
感想
私は特にパフォーマンス周りの話が好きで、大変興味深く発表を聴きました。 Rubyの開発に携わる方々の貢献によってRuby 3x3 が進められ、特にRuby 3.2.0 + YJIT では大きなパフォーマンス改善が実現されていると知り、自分が関わるプロダクトでもYJITを試してみようと思いました。
RubyKaigiの参加は今回が初めてでした。 Rubyコミュニティの圧倒的な熱量を感じ、「自分も貢献していくぞ！」という気持ちが強まりました。
当日ヘルパー
SUZURI事業部の cobachie です。 今年は同じくSUZURI事業部の tanaken と cobachie が当日ヘルパーとして参加してきました。
当日ヘルパーというのは、開催日当日に会場で運営のお手伝いをするスタッフです。 私は RubyKaigi 2019 に続き2回目のヘルパー参加となりました。 前回と大きく異なったのは、毎日の検温と、現地参加するためには事前申請が必要だったことです。 私は主に受付でイレギュラー対応にあたったのですが、スタッフのスムーズなオペレーションと参加者のみなさんの練度の高い行動によって、大きな問題もなく3日間を終えることができました。受付のほかにも、ランチ会場の整備やごみの回収、ノベルティ配布、ホールのドア開閉などでもかげながらヘルパーが活躍していました。現地参加のみなさんが快適にすごしていただけていたらうれしいです。
気づかれた方もいると思いますが、スタッフは常時トランシーバーを装着して、進行状況や作業依頼、トラブル対応などのコミュニケーションを行っていました。 2日目のネットワークトラブルやスケジュール遅延のときの対応状況や意思決定などもトランシーバーで聞いており、一般参加したときより少しだけ近くで RubyKaigi の裏側を見ることができました。 ヘルパーとして運営に関わったことで、RubyKaigi は運営チームの多大な労力によって成り立っていることを実感し、あらためて開催していただいたことに感謝を感じたのでした。
クロージングと RubyKaigi 2023 に向けて
最後はチーフオーガナイザー松田さんによる恒例のクロージングです。 松田さんの「この場所をもう失いたくない」というメッセージに続いて、来年 RubyKaigi 2023 が長野県松本市で開催されることが発表されました。
松本というと RubyKaigi 2020 の開催地として予定されていながら COVID-19 によりキャンセルになったことは記憶に新しいと思います。 私は RubyKaigi 2020 のローカルオーガナイザーでした。 そして RubyKaigi 2023 のローカルオーガナイザーでもあります。 RubyKaigi という最高にテッキーで世界中の Rubyist が集まる素晴らしいカンファレンスを自分の地元で開催できることに今からわくわくしています。 来年はみなさんを松本でお待ちしています。
おわりに
再びP山です。
今回、GMOペパボからは今年入社した新卒パートナーを中心に多くのメンバーがRubyKaigi 2022に参加することができました。これもひとえに普段からRubyの開発に携わっている方々や、オーガナイザーや運営の方々、Rubyコミュニティを支えてくださっている方々のおかげだと思っています。この場を借りて、御礼申し上げます。
また今回会場となった津市の飲食店やホテルにも大変お世話になりました。美味しいものをたくさん食べ、旨い酒をたくさん飲めました。
GMOインターネットグループ、GMOペパボとしても今後もよりRuby発展のための一助となるよう、日々サービス開発に励み、コミュニティに還元していきたいと思います。