株式会社SUPER STUDIO という会社でバックエンドエンジニアをしている芝田です。
Ruby歴はかれこれ5年ほど。業務でRuby / Ruby on Rails を扱う機会も多いです。
この度、晴れて弊社がRubyのSilver Sponsorとなりスポンサー招待枠をいただけたので、長野の松本市で開催された RubyKaigi 2023に参加してきました。
自分はちゃんとした（？）テックカンファレンスに参加すること自体が初めてだったので、とても刺激的で得るところの多い3日間となりました。
この記事では、簡単にではありますがRubyKaigi 2023の内容をレポートしていきたいと思います。
そもそもRubyKaigiって？
RubyKaigiとは 世界最大級のRuby国際カンファレンスです。
Rubyの産みの親であるMatz氏の基調講演や、コミッターの方などのRubyに関する講演、Rubyスポンサーの各企業のブースや講演後の交流パーティなど、3日間見どころ目白押しのイベントです。
参加レポ
今回のRubyKaigiの開催場所は長野県松本市。自分は神奈川在住のため始発の電車で松本に向かいました。
松本駅に着いたところで、RubyKaigi歓迎の垂れ幕が目に入りました。さすが大々的なイベントなんだなあと妙に感心してしまったことが記憶に残っています笑
今回の会場はまつもと市民芸術館という建物だったのですが、非常に立派な建物でした。
セッションが始まる少し前に会場入りしたので空いた時間で各社のブースを見て回っていたのですが、思っていた以上にどの会社も力が入っていてびっくりしました。
国際カンファレンスということもあり、正直参加するまではもっとお堅めのイベントをイメージしていたのですが全くそんなことはなく、会場全体がお祭りムードに溢れています。
ノベルティグッズなどもたくさんあり、ブースを見て回るだけでも楽しめると思います。
自分も挨拶がてらブースを回り、各企業の方々と名刺交換をさせていただきました
（また他の方の例に漏れず前職の知り合いと再会して同窓会ムードになったりもしました笑）
セッション終了後のDrinkUpやOfficial Partyなどの交流イベントも盛んなので、カンファレンスとかは敷居が高くてちょっと...というような人にもおすすめできるイベントだと思います。
（あとセッションの内容は熟練者でも理解が難しいものが多々含まれているので、理解できないということを負い目に感じる必要は特にないと思います笑）
Matz Keynote
セッションは、Day1のKeynoteであるMatzのセッションから始まります。
内容はRuby30年の歴史を振り返り、そこで学んだ教訓について語るというものでした。
自分が現地で聞いた内容をざっくり以下にまとめてみます（あくまで自分が解釈した内容なので、厳密な内容は後に公開されるであろう公式資料をご参照ください）
- Rubyの名前が決まった日が、Rubyの誕生日になっている
- ソフトウェアは概念の存在なので、名前によって存在が決まると固く信じている
- なので、（まだ実体のコードがないけど）名前が決まった日がRubyの誕生日
- 「良い名前」を決めるのが大切。事業にせよ何にせよ良い名前かどうかである程度成功するかどうかが決まるのではないか（他にも「Coral」、「Tish」のような名前の候補があったが、「Ruby」ではなく「Tish」という名前であったら、ここまで多くの人に使われることはなかったかもしれないと感じている）
- 初期開発の頃は一人でこっそり開発していた
- 初期開発の時点でRubyの基礎はもうできていた（言語の原則は最初から今まで変わっていない。保持している。それが大切なことなんだという教訓だと思う）
- Rubyをインターネットで公開する前に、少数の有志を募って使ってもらっていた。色々な人の意見を聞いて、自分では学べないことを学んだ（例えば、初期の頃のブロックはdo~endができなかったが、やりづらいよと言われて直したり）
- その後、初期リリース。届いたメールは「おめでとうございます」「バグります」「バグります」
- 最初の品質は低かったけど、そこでやりとりが発生したことによってコミュニティが始められたのではないかと感じている（しょうがないなあと思いながら開発に関わってくれる人がいた）
- コミュニケーションとコミュニティが大切
- 初期リリース後のRubyはキラーコンテンツがなくあまり伸びなかった。生まれたばかりのソフトウェアはどうしてもユーザーに提供できる利益に限界がある（Rubyは知ってるけどPerlで事足りるから使ってないよ的な）
- でも、「好きだから」Rubyを使う、作るという少数の人たちに語りかけていた（自由へのモチベーションで頑張っていた）
- Rubyの初書籍はずるずる2年くらい伸びた（明確な締め切りがないからぐだった）。でも何とか書いてそこそこ売れた
- その後、英語のRuby書籍を書いてくれた人がいて、それがきっかけで海外の知名度も広がり始めた
- その後、海外カンファレンス（2001年9月）をした。その頃DHHと出会う。この頃の彼は学生インターンのPHPエンジニア。その時はこの人がRailsを作るとは夢にも思わなかった
- Rubyカンファレンスを2001年10月に行う。この時の参加者は35人。でもこの時のつながり（言うなれば人脈）が今の発展の基礎。つながり大切
- そして、2004年についにRuby on Railsが生まれる（待望のキラーアプリケーション）
- この頃、RubyAssociationも始まり、ビジネスでRubyを使いたい人と楽しむためにRubyを使いたいギークな人の差を埋める組織などもできた（Rubyは初期の頃から、「楽しくものづくりしたい人」と「利益を求める人」とで考え方のギャップがあった）
- この頃の教訓としては、楽しみながら作り続ければいつか芽が出る（かも）ということと、マーケティングはとても大切ということ（Matzは良いものは報われると信じていたが今は必ずしもそうではないと思っている。DHHはマーケティングがうまくて、「Rails使えばJavaの10倍の生産性が出るぜ」と言って今で言う炎上マーケティング？的なことをやったことで広まったりしていた。後この頃Youtubeが出て、「15分でアプリができる！」というプレゼン動画を作ってそれが伸びたりもした。ちゃんとした広報が大切ということをこの頃学んだ）
- Ruby1.9にする際、互換性の問題で一部の人がバージョンアップを拒否し、コミュニティが分断。そのような分断の時代が5年以上続いた。その後は互換性に配慮するような工夫を色々するようになった
- また、Ruby1.9でパフォーマンスが改善したことで、バージョンアップを嫌がっていた人が折れてくれたりもしたので、それ以降パフォーマンス改善が大切という姿勢を堅持している
- その後、Ruby2.0。この頃Matzが作りたかった機能が概ね完成する。
- しかし、その頃Railsの人気に翳りが出始める。せっかく理想のRubyができてきたのに残念。。
- この頃からRubyは死んだとも言われ始めるが、頑張るしかないなあと
- Ruby3系でRubyを3倍早くする！という目標を掲げた。ぶっちゃけ無理かもと思っていたが、言い張りながら頑張っているといろんな人が解決法を見つけてくれたりする。ビジョンとリーダーシップがあれば実現することもある
- そして現代。Railsは死んだとも言われており、その中でNo1を目指すのは、、頑張りたいね笑。でも我々が価値を提供しているのは紛れもない事実であり、頑張っていけるはず
- 今はTypeScriptをはじめとする静的型付けが主流。TypeScriptなどの型付けの有用性を否定し続けるDHH（ら）は天動説を信じ続けるような人間と同じなどとも言われる。そうではなく、我々にも正当性はあるんだよということを証明するには、今の主流の方向だけが未来じゃないよと証明していくしかないよね
- 完結で読みやすく拡張性が高い言語こそが、今後30年生き残る言語。Rubyはいい線いってるんじゃないかな？
- もちろん色々課題はあるけど、改善はだいぶ出来ているはず
- Chat GPTに型推論をしてくれたら普通にしてくれたよ。もうこれでいいんじゃないかな？
- ↑は言い過ぎかもだけど、こういったテクノロジーを取り入れていくことでもっと楽にスマートに現在の型などで得ているメリットを得られる時代は来る（多分）
- だから型を安直に導入するのではなく、もっと良い方法がある（と思う）ので、それを提供していきたい
- 我々は、これからも自分たちの信じる未来に向けて歩み続けるよ。みんなも参加してくれると嬉しいな
他の参加者の方のブログなどにも書かれていますが、様々な教訓が読み取れる良いスピーチでした。
最初に決めた原則を保持すること。楽しんで続けていくこと。マーケティングを軽視しないこと。コミュニケーションとコミュニティを大切にすること。ビジョンとリーダーシップを示していれば無理そうなことでも実現する（かもしれない）こと。
プロダクトを作る上でも意識したいことばかりですね。
Sessions
Matz氏の基調講演が終わったら各Speakerの方のSessionをタイムスケジュールに沿って拝聴していきます。
（自分が聞いた中で個人的にいくつかピックアップして軽く紹介します）
Make Regexp#match much faster
正規表現（Regexp）は、プログラマにとって基本的なテキスト処理ツールである。RubyにもRegexpの関数が標準装備されています。Regexpは便利ですが、いくつかの問題を引き起こすことがあります。代表的な問題は、Regexpマッチングの脆弱性であるReDoS（Regular expression Denial of Service）です。Regexpマッチングをバックトラックで実装した場合、マッチング時間が爆発する可能性があります。この爆発はサービスに過負荷を与え、サービスの提供を困難にする。このようなRegexpマッチングを利用したDoS攻撃はReDoSと呼ばれています。例えば、Cloudflareに被害を与えた。以前のRubyのRegexpの実装では、ReDoSを引き起こす可能性がありました。Ruby 3.2.0では、Regexpマッチングを最適化し、ReDoSを防止しています。この最適化により、これまで指数関数的なマッチング時間を要していたRegexpが、線形時間でマッチングされるようになりました。本講演では、Ruby 3.2.0で実装されたRegexpマッチングの実装とRegexpマッチングの最適化の詳細について説明する。
こちらの方の講演は、Rubyの正規表現のパワフルさと脆弱性についてというお話でした。
Rubyの正規表現はそれだけで簡素な言語も作れたりするほど強力なものだが、「ReDoS」と呼ばれる脆弱性を内包してしまっている（いた）そうです。
ReDoS脆弱性とは、正規表現の評価に非常に長い時間がかかるような入力を送信することで、サーバーのリソースを消耗させ、サービスを拒否（Denial of Service, DoS）させる脆弱性であり、nokogiriやRackにもReDos脆弱性が報告されていたとのことです。
それらの対先の一つとして、「メモ化」と呼ばれるパファーマンス改善（正規表現のパターンや結果などを記録して、以降同じパターンが来たときに計算を省略して高速化するような技術）を行なっていると言う話でした。
（ただ、メモ化はメモ化でメモリ食いだったり後方参照などでは適用できなかったりと課題も多いと言うお話でした）
React辺りを使っているとメモ化の話はお馴染みだと思いますが、Rubyの正規表現でもこのワードを聞くことになるとは思わず不思議な気持ちになりました。
Revisiting TypeProf - IDE support as a primary feature
TypeProfは、Ruby 3.0から搭載されたRubyコードの型分析器です。タイプアノテーションのないRubyコードの型推論を第一機能として提供し、Language ServerによるIDEサポートを第二機能として提供してきました。今年はこれを逆手にとって、IDEを主なターゲットにしようと考えています。そのために、アナライザーの設計を見直します。IDEでの編集に迅速に対応するため、解析をモジュール化・インクリメンタル化し、編集ごとの再解析を減らす予定です。また、解析をバイトコードベースからASTベースに変更することで、マウスホバーヒントとして解析済み型を表示する機能を実装する予定です。本講演では、TypeProfの新しい設計とそのプロトタイプを紹介する予定である。
こちらの方の講演は、Rubyの型推論機能についてのお話でした。
近年になってRubyには型推論機能がつきましたが導入しても開発体験がさほど良くならなかったこともあり、実際のところあまり使われていない、と言うのが講演者の方の現状認識のようでした。
なので、それを解消するためにIDEサポートを主眼に据えた型推論機能を提供をしていこうとしているとのことでした。
- メソッドの引数と返り値、メソッド呼び出しなどの記述から型推論がコメントで出る
- 型注釈も書ける（型注釈と違う型の値を呼び出しているメソッドから警告が出る）
- メソッド定義へのジャンプも使える
- エディタ上でのDXを良くするために0.1秒以内のレスポンスを目指す
と言うような内容が紹介されています（話を聞いていて、やはりTypeScriptのDXを強く意識したものなのかなと感じました）
Introduction of new features for VS Code debugging
従来の標準ライブラリlib/debug.rbを置き換えるruby/debugは、2年前から開発が進められています。また、現在も多くの改良が行われています。
本講演では、VS Codeのデバッグにおけるユーザーエクスペリエンスを向上させるための新機能を紹介します。
VS Codeのデバッグビジュアライザーです： Active Recordオブジェクトをテーブルとして見ることができれば便利でしょうか。Debug Visualizerでは、棒グラフや折れ線グラフなど、多くのオブジェクトを様々な方法で可視化することができます！デモ: https://www.youtube.com/watch?v=9vLVCrpzlDQ
Trace Inspector: Trace Inspectorは、VS Codeでトレースするときに便利です。Rdbg Trace Inspector を使用すると、トレースログを簡単に検索し、多くの有用な情報を得ることができます。例えば、どのメソッドが呼び出されたのか、どの行が実行されたのか、ある時点のローカル変数などを知ることができます。
こちらは、VS Code デバッグ用の新機能の紹介でした。
ActiveRecordのオブジェクトのコードリーディングと言う題材で、実際のステップデバッグを行いながら解説してくれました。
トレースログという機能の紹介で、
- どのメソッドが呼ばれたかがログになるので、振り返りが簡単
- ステップの時系列が出て、時系列を選択することでその時点での変数の値などが確認できる
というような機能が紹介されていました。
パッとみた感じでは使いこなせればかなり便利そうな機能だったので今度試してみようかと思います（debug.gemの1.8から動くようです）
The Adventure of RedAmber - A data frame library in Ruby
RedAmberはRubyで書かれたデータフレームライブラリです。データフレーム処理をRubyライクに記述できるようにすることを目的としています。RedAmberは、カラムナフォーマットに基づく言語に依存しないデータ処理基盤の構築を目指すApache ArrowのRuby実装であるRed Arrowを利用しています。RedAmberの開発は2022年4月に開始され、主要機能の実装と大幅なコード改訂を完了しました。本発表では、Rubyによるデータ処理の分野におけるRedAmberの意義、他のライブラリにはない独自の機能、今後の改善点などを紹介する予定です。また、RedAmberの作成過程において、OSS開発初心者であった私の経験から、Rubyコミュニティへのメッセージもお伝えしたいと思います。
こちらの方は、自作されたRubyのデータフレームライブラリ RedAmber の話でした。
自分がデータフレーム周りを業務で扱っていることもあり、この方の講演はかなり興味深く聞けました。
この方はRubyでデータ処理をしようというコミュニティ(Red Data Tools)で活動しており、pandasの操作性に課題を感じてRubyライクな書き心地のデータフレームgemを作られることにしたそうです。
Apache Arrowというデータ交換処理に適したデータフォーマット（データフォーマットというのはCSV、JSONなどのデータ形式のこと）の「巨人の肩に乗る」設計方針とのことでした。
- 欠損値を全てnilにしてくれる
- Rubyのオブジェクトのようにデータフレームを扱う（複数の便利メソッドを提供）
- tdrと呼ばれるデータプレビューメソッドなども提供している
というような特徴が紹介されており、Rubyの書き心地が好きな自分としては良いライブラリだな〜と感じました。
ただ使いやすさの反面、速度が少々犠牲になっている（らしい）ので、そちらも改善していきたいとのことでした。
飲み会
Sessionが終わった後は、みんないそいそと飲み会に向かって行きます笑
飲み会は、RubyKaigi自体が主催しているオフィシャルパーティと協賛企業が開催しているDrinkupの二種類があり、前者は有料で後者は無料でした。
自分は以下3つのイベントに参加させていただき、他の方との交流を楽しませていただきました。何気なく話した人がコミッターの方だったり某ビックテックに勤めているすごい方だったりして、こういうところもカンファレンスならではだなと感じました笑
Findy Drinkup at RubyKaigi 2023
Agileware Drinkup at RubyKaigi 2023
どのパーティも活気があり、雰囲気だけでも楽しめます。
また、その場で転職志望者の方と出会ってカジュアル面談に進んだり仕事の話につながったりということも普通に起こるので基本的にメリットしかないイベントだと思います（協賛企業さんのイベントだと美味しい食事がタダだし...）
自分もTwitterアカウントの交換や転職志望者の方との交流をさせていただきました。
閉幕
そんなこんなであっという間に3日が過ぎ、最後のSessionを終えたところで閉幕のスピーチが始まりました。
次の舞台は沖縄だそうです。自費だとちょっとお高くつきますね笑
まとめ
冒頭でも書きましたが、とても刺激的で学びの多い3日間でした。
自分が普段行なっている開発の場合、ビジネスロジックをRuby（もしくは他の言語）で実装する、といういわば表層のレイヤーの開発が大半なので、こういった低レイヤーの部分の話をガッツリ聞ける機会はとても貴重なものに感じられました。
（もっとも他の参加者さん曰く、昔はもっとC言語寄りの話が多かったが今はそれよりハイレイヤーの話が増えた感がある、とのことでしたが...笑）
また、他の企業さんとの交流も自分の視野を広げるのに非常に役立ちました。こういった場で定期的に今まで知らなかった企業さんのビジネスモデルを聞いたり技術への取り組み方を聞く機会を設けるのは、自身のキャリアを振り返るいい機会にもつながるので大切だと感じます。
課題
その上で反省点を上げるとすると、やはり自分の英語力の無さが響くなあとしみじみ感じました。
特に3日目のセッションは大半が英語セッションだったこともあり、内容の理解が進まず手持ち無沙汰になってしまった時間もあり、そこが残念でした。
ただ他の参加者の方に話を聞いてみると「正直自分も英語のセッションは良くわからなくて、、」と仰られる方が大半だったように見受けられ、日本語の字幕も会場の片隅に置いておいてくれれば良いのにな〜と思ってしまいました。
（もちろん国際カンファレンスなので英語がベースなのは当然すぎるほど当然なのですが、せっかく日本で開催している日本人参加者が半数以上のイベントなのでもう少し日本人フレンドリーだと嬉しいなと感じました）
また、交流イベントに対しての自分の準備のなさも反省点でした。
交流イベントにここまで力が入っていると思っておらず事前の準備などはほぼしていなかったため、参加予約などはかなりギリギリでドタバタしてしまい、しかも会社からの参加者はほぼ自分一人という状態だったので結構アウェーでした笑
コミュ力に自信のあるタイプでもないので、Day0のような事前イベントに参加してあらかじめ顔馴染みを作っておくとか、Twitterで事前に参加者の方にアタックしておくとか、もっと準備をしておくべきだったな〜と後悔しました。
（余談ですが、自分の他に参加している同じ会社の方が一名いて、その方に諸々サポートいただきアフターパーティーでの交流まで漕ぎ着けたという経緯があります。その節はありがとうございました笑）
最後に
諸々書きましたが、総括すると非常に素晴らしいイベントで、Rubyコミュニティの底力を見せつけられました。
運営の皆様、発表されたコミッターやコントリビューターの方々、スポンサーの皆様、最後まで本当にお疲れ様でした。
また、私を快く送り出してくれた会社や、会社の同僚の皆様にも重ねて感謝します。楽しい3日間が過ごせたのは皆さんのおかげです。
ありがとうございました！
SUPER STUDIOの採用について
SUPER STUDIOでは、エンジニアを採用しています。
少しでも興味がありましたら、以下をご覧ください。
昨年12月に9期目を迎えたSUPER STUDIOのキックオフイベントで社内表彰されたエンジニア受賞インタビュー記事です。よりSUPER STUDIOのエンジニア組織を理解できる内容となっておりますので、ご一読ください。
Discussion