こんにちは!24新卒の久冨(@tomi_t0mmy)です。ラクスル事業本部でサーバーサイドエンジニアをしています。
写真の1番左の、風で前髪が吹っ飛んでいるのが私です。テックブログ用の大事な写真に限ってネタみたいな写真になってしまった……
さて、5/15〜5/17に沖縄でRubyKaigi2024が開催されました!私は学生時代からRubyをメインで使っていて以前から参加してみたいと思っていたので、入社してまだ1ヶ月半ですが思い切って行ってきました!今回はそのレポートと感想をお伝えできればと思います。
RubyKaigiについて
RubyKaigiとは、年に一度、世界中のRubyistが集まりRubyについて語り合う国際カンファレンスです!今年は世界各地から約1400人のRubyistが参加していたようです。めちゃくちゃ多い!
RubyKaigiの大きな特徴として、Rubyを使っている人ではなくRubyを作っている人によるセッションが多い、ということが挙げられます。Rubyのコアな部分を知り尽くしている人たちが、この1年での成果やRubyの未来について熱量高く語ってくれます。そのため、内容を理解するためにはある程度の前提知識を必要とするセッションが多いです。
事前に各セッションの概要を確認したところ、全く聞いたことのなかった概念がたくさんありました……!先輩方と予習はしましたが、それでも理解できるか不安な気持ちを抱えたまま当日を迎えました。
また、たくさんのRubyistと交流できることもRubyKaigiの魅力の一つです。オフィシャルパーティーだけでなく、スポンサーブースやイベント、「知り合いの知り合い」繋がりなど、普段話せない人と話せる機会が本当に多くあります。
私はRubyKaigi初心者であり、オフラインイベント初心者でもあるので、「うまく話せるかな……」と緊張していました。
実際に参加したコンテンツ
期待と不安の入り混じった気持ちで迎えたRubyKaigiですが、開催期間中はコンテンツ盛りだくさんで忙しい3日間になりました!ここからは期間中に参加したコンテンツについて紹介していきます。
セッション
メインイベントである、Ruby開発者の方々によるセッションです!ここでは私が面白いと感じたセッションを3つ紹介させていただきます。
Writing Weird Code
TRICK2022(超絶技巧Ruby意味不明コンテスト for RubyKaigi)において金賞を受賞されたぺん!さん(@tompng)によるKeynoteセッションです。タイトル通り、”変なコード”がたくさん紹介された面白いセッションでした。
序盤では比較的短い”変なコード”が多く紹介されました。例えば、このコードはただ%を適当に並べただけのように見えますが、ちゃんと実行できます!
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%という記号にはいろんな意味があります。まず文字列リテラルの%記法では以下のように記述することができます。
%!string! == "string"
この!
部分には任意の非英数字を使うことができるため、以下のようになります。
%!s! == "s" %%s% == "s" %%% == ""
また、Stringクラスには%メソッドがあり、以下のようになります。
"RubyKaigi %d" % 2024 #=> "RubyKaigi 2024" "" % "" #=> ""
よって、
%%%%%%% == "" % "" %%%%%%%%%%% == "" % "" % ""
となり、4n+3個の%を並べたものはsyntax validとなります。
他にも、いろんな記号を繰り返したコードやヒアドキュメントや正規表現の記法を用いたコードなど、一見しただけでは分からないテクニックが本当にたくさんあることを知りました。
このセッションで、いかにRubyが自由で奥深い言語なのかを少し感じられた気がします。また、このようなコードを書けるようになって初めて見つけられるバグがあったりして、仕事で役に立つこともあるというお話を聞くこともできました。
そして後半では、ぺん!さんがRubyKaigi2024のために作ったTRICKyなコード6作品(多い!凄い!!)を紹介していただきました。どれも本当に面白い作品でしたが、個人的にはMost Floralが「画像って実行できるんだ……」と感動しました。作品のコードは以下のレポジトリで公開されているので、ぜひ手元で動かしてみてください!
Unlocking Potential of Property Based Testing with Ractor
こちらはMasato Ohbaさん(@ohbarye)によるRactorを用いたproperty based テストについてのセッションでした。Ractorとは、Ruby3.0で導入された並行処理のための機能です。現時点ではユースケースが少ないと考えている人が多そうなRactorですが、このセッションでは「property based テストがいいユースケースになるのではないか」と考え、その仮説を検証した結果が説明されています。
私はproperty based テストとRactorの両方ともそれほど詳しくありませんでしたが、登壇者の方の説明が分かりやすく非常に勉強になったセッションでした。
まずproperty based テストについての説明がありました。例として、Ohbaさんが作成したPBTというツールのReadmeのコードを元に説明します。以下のsort関数がテスト対象であるとします。
def sort(array) return array if array.size <= 1 pivot, *rest = array left, right = rest.partition { |n| n <= pivot } sort(left) + [pivot] + sort(right) end
よく用いられるのはexample based テストで、これは入力値とそれに対して期待する出力値(example)を設定し、実際の出力値が期待する値と一致するかを確認するものです。RSpecで書くと以下のようになります。各it句内でそれぞれのexampleが記述されています。
# Example Based Test with RSpec RSpec.describe 'sort method' do it 'sorts an empty array correctly' do expect(sort([])).to eq([]) end it 'sorts an array with a single element correctly' do expect(sort([1])).to eq([1]) end it 'sorts an already sorted array correctly' do expect(sort([1, 2])).to eq([1, 2]) end it 'sorts a reverse sorted array correctly' do expect(sort([2, 1])).to eq([1, 2]) end it 'sorts a randomly ordered array correctly' do expect(sort([2, 3, 1])).to eq([1, 2, 3]) end it 'sorts an array with negative numbers correctly' do expect(sort([0, -1, 2, -3, 3, 1, -2])).to eq([-3, -2, -1, 0, 1, 2, 3]) end end
example based テストは、理解や記述は比較的容易であり、期待通りに動いているかを確認しやすいという長所がありますが、エンジニアが予測しているバグしか見つけられないという短所があります。
これに対して、property based テストはexampleではなくテスト対象が満たすべき性質(property)を記述し、それに基づいて膨大な量のランダムな入力値を生成して行うテストです。result.each_con(2)
以下でpropertyが記述されています。
# Property Based Test with PBT Pbt.assert do Pbt.property(Pbt.array(Pbt.integer)) do |numbers| result = sort(numbers) result.each_cons(2) do |x, y| raise "Sort algorithm is wrong." unless x <= y end end end
property based テストはより多様な入力値を試せるので想定外のバグも見つけやすいですが、学習コストの高さとテスト実行にかかる時間の長さが欠点となります。
example based テストとproperty based テスト、どちらも一長一短があるので、ケースによって使い分けるのが良いとされています。
さて、このproperty based テストですが、生成されるそれぞれの入力値に対するテストは互いに独立しているので、Ractorのユースケースの候補として良いのではないかとOhbaさんは考えたそうです。Ractorで上手く並行に処理出来れば、property based テストの欠点である「実行に時間がかかる」という欠点を改善することが出来ます。
PBTはこの仮説検証のために実装されました。このツールは、property based テストを簡単に実装したり、property based テストの並行処理を可能にするものです。セッションの中では、このツールの設計の詳細や特徴について詳しく説明されていました。
このツールを用いた検証では、テスト対象のタスクがCPU-boundかつRactorで動かせるという条件を満たしていればRactorを用いた方が実行時間は速くなるが、それ以外の場合ではsequentialに実行した時の方が早い、という結果が出たそうです。
property based テストにおける有用性としてはまだ限定的なところがありそうですが、Ractorのユースケースを広げるための知見となる面白いセッションだったと感じています!
Namespace, What and Why
こちらはNamespace on readという機能をRubyに提案・開発しているTagomoriさん(@tagomoris)による、Namespace on readの解説セッションでした。まだRubyに取り込まれていない機能ということで、未来のRubyがどうなるのかを想像させるワクワクしたセッションでした。
Namespaceとは、アプリケーションやライブラリを閉じ込めた、独立した”空間”のことです。スペース内での変更を隠し、スペース外から見えないようにする機能を持ちます。
Namespaceはコードの名前や定義、バージョンの衝突を避けるために必要な概念です。
名前の衝突
開発現場では名前の衝突を避けるためにFoo::Bar::Bazのように構造化した名前がよく使われます。しかし、Topレベルの名前として使いたい名前が被っている場合も多く、衝突を避けるのが大変になります。
定義の衝突
オプションの設定やグローバル変数の中身が意図せず書き換えられてしまい、挙動が変わってしまうことがあります。また、モンキーパッチが全体に影響してしまうことも考えられます。
バージョンの衝突
ライブラリの依存関係において、同じライブラリの別バージョンを使いたい場合が考えられますが、Namespaceのない現状では困難です。
Namespace on readの機能が導入されればこのような課題が解決されるため、期待されている機能の一つだと言えるでしょう。
また、まだjust ideaの段階とのことですが、tagomoriさんの想像しているNamespaceの未来についても語ってくださっていました。
例えば、各アプリケーションをNamespaceに入れれば、複数のアプリケーションを一つのプロセスで動かしてモジュラーモノリスっぽいことができるかもしれません。また、バージョンの衝突が起きた場合も片方をNamespaceに閉じ込めることで解決できそうです。その他、究極的には、全てのライブラリをNamespaceで管理できるのではといったアイデアもありました。
他にも、なぜ”on read”なのかという話や実際にNamespaceをどう実装するかという話など、詳しく説明されていました。私にとっては難しい話もあり全てを理解するのは困難でしたが、未来の機能についての話はとても面白く、想像膨らむ楽しいセッションでした!
スポンサーブース
セッション以外の大きなコンテンツとしてスポンサーブースがあります。たくさんの企業さんがRubyにまつわるクイズやコード課題、コードレビュー企画などをやっており、エンジニアなら思わず足を止めてしまうようなコンテンツがたくさんありました!
こちらはMoney Forwardさんのコードレビュー企画です。
#rubykaigi
— Money Forward Developers (@moneyforwardDev) 2024年5月15日
皆さんからいっぱいレビューコメントいただきました。
ありがとうございます! https://t.co/AUQ4xUiFHt pic.twitter.com/h8pCImUk8g
こちらはFindyさんのブースの様子で、私もRubyクイズに挑戦させていただきました。
Findyブース完成!
— まっきーㅣFindy DevRel (@ayamakkie) 2024年5月15日
1F奥のかなり暗いところにあるんですが、みんな見つけて遊びにきてください🥺Rubyクイズとアンケートとってます!
そしてしおりが新しくリニューアル!みんなもらいにきてね✨
#rubykaigi pic.twitter.com/UevXDGRHAl
その他にも、オリジナルグッズが当たるガチャガチャやタイピングゲームなど、どのブースも力を入れて運営されていました。いろんな会社の事業や取り組みについて楽しく勉強できましたし、「ラクスルでも工夫を凝らしたブースコンテンツを作りたい!」とワクワクしました。
イベント
RubyKaigi開催期間は各社によるイベントも盛んに行われています。今回私は、オフィシャルパーティーと3つのイベントに参加してきました。
RubyKaigi 2024 Official Party
こちらはオフィシャルのパーティーでたくさんの人で賑わっていました。会場は海の近くで景色が最高でした!
BBQを楽しみつつ、同じテーブルの方々と各々が開発しているプロダクトや使われている技術についてざっくばらんにお話ししました。参加人数が多い分、本当に様々な企業の方とお話しできてとても面白かったです!
Timee Drinkup at RubyKaigi 2024
会社の先輩が参加するとのことで、その方に着いていく形で参加しました!Drinkupイベントも初参加な私は、「ずっとRubyについて語っている会なのかな…」と少しビビっていましたが、社外の方との交流の場として楽しむことが出来ました!Rubyの話に限らず、コミュニティ活動についてのアドバイスをいただいたり、Timeeさんの取り組みについて色々お話を伺うことができて、とても有意義な会でした!
Findy Drinkup at RubyKaigi 2024
前日のDrinkupイベントがかなり楽しく、「他のイベントも参加したい!」と思って急遽参加を決めました。当日急に決めたのでぼっち参戦になり、話し相手を見つけられるか心配していましたが、ベテランの方も含めて皆さん優しく話しかけてくださいました。他の人をどんどん紹介してくださったりして、繋がりが増えてとても嬉しかったです!
また、自分のキャリアについての相談に乗っていただいたりRubyの楽しさを語っていただいたりと、前日のイベントとはまた違った良い話をたくさん聞くことができて、思い切って参加して良かったと思いました!
RubyKaigi 2024 After Party sponsored by mov
こちらは国際のれん街の1Fと2Fを貸し切っての大規模なアフターパーティーでした!参加人数がかなり多かったこともあり、基本的には一緒に参加した先輩方とRubyKaigiを振り返っていましたが、途中から他の会社の方とも交流できました!
そして、なぜか初めましての人とラーメンを食べにいくイベントが発生し、「これがRubyKaigiか〜〜(褒めてる)」となりました。こちらもとっても楽しかったです!
行ってみての感想
分からなかったけど楽しい!
予習してから参加したとはいえ、すべての参加セッションの内容をその場でしっかり理解することはできませんでした。
が、それでもRubyKaigiは楽しい!!!
内容がわからなくても登壇者の方々のRubyへの愛が伝わってくるし、Rubyが好きな人同士で盛り上がっている雰囲気を感じるだけでも本当に楽しかったです。
また、スポンサーブースや他のRubyistとの交流など、セッション以外のコンテンツも想像していた以上に豊富でかなり楽しめました。
新卒1年目でも、Ruby初心者でも楽しめます!!
Rubyがもっと好きになった
私がRubyを使い始めたきっかけは、学生時代にインターンでお世話になった会社で使われていたことです。つまり、たまたま使うことになったというだけでした。そのため、「書きやすいな〜」と思ったり、他の言語との違いを考えることはあっても、「Rubyが好き!」というほどの強い気持ちがあるわけではありませんでした。
しかし、Rubyの良さをたくさんのRubyistに語っていただき、「Rubyって楽しい言語だな」と感じるようになりました。そして「私も輪に入って語れるようになりたい!」と心から思えるようになり、今後の勉強のモチベーションアップにも繋がりました。(ひとまずあなたの知らない超絶技巧プログラミングの世界を購入しました)
またRubyだけではなく、Rubyistのコミュニティもより好きになりました。イベントの参加経験があまりなかったため、初対面の方との交流に緊張していたのですが、とにかく皆さんあたたかい!!初心者の私にも優しく話しかけてくださってありがたい限りでした。
他社さんとの交流がいい刺激になった
スポンサーブースやアフターイベントでは様々な企業のエンジニアの方と交流でき、各社の事業や技術的な取り組みについても話すことができました。
いつもは会社の同僚や先輩方と話すことがほとんどなので、他社での取り組みを聞けたことはとても良い刺激になり、「ラクスルでもこんな取り組みをやってみたい!」とアイデアが膨らみました。
これまで社外の方との交流の機会はあまり作ってこなかったのですが、今後は定期的にオフラインイベントに出たり、情報発信やSNS活動を通じて交流していきたいと思います。
最後に
初参加でしたが、参加前に抱いていた不安な気持ちが全て吹っ飛ぶような、とても刺激的で楽しい3日間になりました!RubyKaigiの運営の方々、スポンサー各社の方々、話して下さった方々、色々教えてくださった会社の先輩方などなど、皆様のおかげです。本当にありがとうございました!!
まだまだひよっこエンジニアではありますが、これからRubyをもっと楽しんで勉強し、今よりもさらにパワーアップした上で、来年も必ずや参加しようと思います!