RubyKaigi参加体験記 Day3
はじめに
こんにちは、マイベストです！
マイベストでは、mybest BlogKaigi 2024と題して4月15日からエンジニア全員でブログ連載を行ってきました。
1日目、2日目と引き続き、本日はRubyKaigi 2024体験記3日目の体験記を掲載します。
バックエンドエンジニアで、Ruby歴自体は6年くらいのgamiTa(@gamiTa_001)です。
前回の松本に引き続き今回も参加させていただきありがたい限りです。
それでは軽く
演題名① Ruby Committers and the World
毎度お馴染みのこちらのイベント。Rubyコミッターとmatzが、様々なRubyに対するテーマに対してコメントを交わすことで、matzとともにRubyのアイデンティティを再確認するイベントと認識しています。
今回のお題は下記の通りでした。
Literal sting will be frozen in the future（文字列が格納された変数は将来的にimmutableにすべきか）
Embedded: RBS: WDYT （RBSをコメントして埋め込むのどう思う？）
Replacing Ruby’s build system GNUAutotools → cmake（RubyのビルドシステムをGNUAutotools → cmake にしたい）
GVL を remove したい？（すみません英語タイトル忘れ…）
Improving Ruby’s async usabilty e.g.async…awiat（async...awaitのようにRubyの非同期利用性を向上させる）
defer for Ruby? （Go等で使われる defer を Ruby でも使いたいか？）
そして今回のテーマの中から気になったものをいくつかお話できればと。
Literal sting will be frozen in the future
さっそくQuine勢という特殊な立場の方から強い反対意見が。やはりQuine(自身のソースコードと完全に同じ文字列を出力するプログラム)勢にとってはどれだけダイナミクスであることが重要であるかの主張がとても良かったです。
しかし、YJITの性能が5%向上する話もあり（そんなにもなのか、それだけなのかの意図まで英語で汲み取れず…）、またどこかで書き換えられるならフローズンしてた方が良いという意見も。
そしてmatzは自身は思った以上に肯定的な反応であるためコミッターから「型にはいつも逆張りなのになんでFrozen String Literalはいいの？」というコメントに対し「そんなに僕は一貫してない（笑）」が一番盛り上がりどころでした。
Embedded: RBS: WDYT （RBS
RBSの型をコメントとして埋め込む動きがあり（二日目に演目がありました）、今回はそのコメントの書き方について観客へのアンケートを兼ねたテーマとなっていました。
このようなアンケートでして
上から順に左と右（3番目は上と下）でアンケートを取っていく形でした。
なお、左でも右でもない、一生型を書きたくない派のアンケートもあり、それなりにいた気がします。その筆頭であるmatzに「このコメントによる埋込はそもそもどうなんですか？」という質問に対しては一言「黙認する」(型推論がない現状としては許容という後解説も含めて）というブレないコメントを頂けてました。
これには型否定派のDHHもニッコリでしょう。
観客アンケートとして①は圧倒的に右、②は右がちょっと多いかなくらい、③は下の方が圧倒的に多く、型は欲しいけども手間は掛けたくないRubistの傾向が見えてきました（自分も同じ）
Replacing Ruby’s build system GNU Autotools → cmake
色々と規格外なkateinoigakukunさんが投げかけたテーマ。
卒論の現実逃避でビルドシステムをGNU Autotools から cmake に変えたくなったという話の入りで全く共感できないところから、さらに結果cmakeに変えたけども全然嬉しくなかったので、全然嬉しくないのはビルドシステムのせいなのでcmakeに打ち勝つビルドシステムを作る（matz< 作るって言った…）というテーマでした。
Platformの移植性はcmakeでだいぶ解決することあっても、全体像がわかりにくく現状やっていることをcmakeでやろうとすると複雑なのが辛みだそうで…
matz曰く「インスピレーション元の perlが戦犯」
演題名②YJIT Makes Rails 1.7x 1.8x Faster
いきなり、演目名が訂正されて笑ってしまいましたが、さらに早くなっていました。
YJITの技術のキモは Lazy Basic Block Versioning (LBBV) という技術です（こちらの資料わかりやすいです）。先の演目のテーマにあった「**Literal sting will be frozen in the future」**で YJITの性能が向上するのはこの理由からですね。
スピーチの初めにYJITを適用して改善した企業さんをまとめてるスライドが出てきましたが、実は弊社もYJITを適用している勢なのでちゃんと肩を並べられます
またRails 7.2ではYJITはデフォルトで有効化されていたりするのが紹介されたりと、もう当たり前の技術になっているんだなぁと。
スピーチのメインは高速化のために、今までYJITが適用できずRJITに任せていた箇所にもYJITを適用していったことの話でした。
特にRuby側からRailsのメソッドである blank? と (ActiveSupportの)presengt? に対応したことは割と驚きでこんなにも型推論する必要がなくなったよとスライドで発表してくれていました。
地味に貴重なRubyKaigにおけるRailsの話でした。
3日目の感想
3日間ぶっ続けで技術の話を浴びるイベントはやはりモチベの上がり方が違うとともに、そのモチベで英語耳を育ててより技術の話を浴びれるようになれたらと…
バックエンドエンジニアとして、24卒でマイベストに新卒入社した、はっしー(@hashimo_846)です。
昨年の入社前の内定者インターンをしていた時期にも、マイベストのエンジニアに同行させてもらったため、今年で2回目のRubyKaigi参加となります。
Ruby and the World Record Pi Calculation (URL)
Googleのエンジニアであり、円周率計算で世界記録を更新したEmma Haruka Iwao(@Yuryu)氏の発表です。
円周率などの数値計算にRubyを使うというイメージが全く無かったため、発表内容が気になり聞かせていただきました。
発表は「そもそもなぜ円周率の桁を計算するのか？」という素朴な疑問への回答から始まりました。考えたこともなかったですが、たしかに無限に続くことがわかっている円周率を計算する意味ってなんだろうと。その回答として「計算できる円周率の桁数は、人類の進歩のベンチマークだ」とおっしゃっていました。円周率計算の世界記録を破った本人がおっしゃっているということもあり、圧倒的な説得力を感じました。
実際、10億桁の円周率を計算するために必要な時間は、PCのベンチマークとしてよく用いられるようです。しかし、この発表は100兆桁の円周率を計算した際の話ということで、ますます内容に惹かれました！
計算プログラムの各種パラメータ群はYAMLファイルで定義されていて、本来であれば人の手でチューニングを行う必要がありますが、YAMLの数値部分の調整をERBによって行い、自動的にパラメータが調整されるようにしたそうです。このチューニングにより、最終的には約200%の高速化を実現できていました。
発表の結びにて、自分とRubyについての話をしてくださいました。EmmaさんはGoogleに入る前、2014年のRubyKaigiに登壇したそうです。その発表の動画をGoogleの面接にて提出し、その後Googleに入社したとのこと。Rubyと出会わなければ、Googleで働くこともなかった、円周率の世界記録を更新することもなかった、そして、今日ここに登壇していなかったとおっしゃっていました。
RubyKaigiという場が、色々な人のキャリアに影響を与えているということが感じられ、とても胸が熱くなりました！
Using Ruby in the browser is wonderful (URL)
ruby.wasmのコミッターであり、RubyKaigi2023でも登壇したShigeru Nakajima(@ledsun)氏の発表です。
直球な発表タイトルで、ruby.wasmに触れたことがない私にもとてもわかりやすく、とにかくRubyをブラウザで動かすことの気持ちよさを伝える内容でした！
そもそもruby.wasmとは何かという内容から発表は始まりました。
ruby.wasmの役割は大きく分けて2つあります。
1つ目はCRubyをWebAssemblyにコンパイルするもので、2つ目はruby.wasmがCRubyとJavaScriptとの架け橋となることです。JSではブラウザに関する外部のリソースを扱うことができますが、Rubyから直接扱うことは難しいです。しかし、ruby.wasmを使うことで、JavaScriptの変数を触ることができたり、ブラウザとターミナル上で同じコードを動作させたりすることができます。
また、発表者であるNakajimaさんは、現在Rubyによるフロントエンドのフレームワークを作成中とのこと！フロントエンドのコードも一貫してRubyで書くことができれば、よりスムーズな開発ができそうだと期待に胸が膨らみました。
3日目の感想
RubyKaigi2024に参加し、Rubyistたちの情熱や愛を感じられる濃厚な3日間でした。最後に、Matzさんの熱いKeynoteや、次回開催地の発表があり、終わってみれば短い3日間だったと感じました！
マイベストのバックエンドエンジニアをしておりますkatakyo(@katakyo_51)です。RubyKaigiは2022年の津、2023年の松本に引き続き今年で3回目の参加となります。自分の方から3日目に印象に残ったセッション、Matzのclosing keynote AfterpartyやRubykaigiの感想について書かせていただきます！
Using "modern" Ruby to build a better, faster Homebrew
このセッションでは、macOS用パッケージマネージャであるHomebrewのメンテナ、Mike McQuaid(@MikeMcQuaid)氏が発表を行いました。 Homebrewは2009年にRuby 1.8.7で開発が始まり、2016年までそのバージョンで動作していました。
その後、メンテナンスが続けられ、なんと今日(2024年5月17日)にRubyの最新バージョンである3.3.1にアップグレードされました！
Homebrewの特徴として、以下の点が挙げられました：
Homebrew formulaはRubyのDSLで書かれており、清潔で読みやすいコードになっているため人気がある
Caskも最近Homebrewに統合され、同様にRubyで書かれている
以前はmacOSに付属のRubyに依存していたが、バージョンの古さが問題となったため、現在は独自のportable Rubyを使用している
テストや型チェック、コード整形のツールとしてRubocop、Sorbet、RSpecなどのRubyツールをHomebrewの開発に活用している
また、brew listなどのbrewコマンドのパフォーマンス改善のため、一部をBashで書き直したことが報告されました。(セッションの1時間ほどリリースされたこの変更は、こちらのリンクから確認できます)
セキュリティ面の強化にも取り組んでおり、GitHub Actionsのattestationを使って配布するパッケージの完全性を検証できるようにしたいとのことです。
さらに、McQuaid氏はWork Brewという会社を立ち上げ、Homebrewを企業でより使いやすくするための取り組みを行なっているそうです。
Macユーザーなら身近なHomebrewがRubyで作られていることに加え、全体のセッションを聞いて普段我々が使っているようなツールを使い、作られていることでHomebrewがさらに身近に感じされるようになりました。
The state of Ruby dev tooling
Shopifyのシニアソフトウェア開発者であるVinicius Stock(@vinistock)氏のセッションでは、公式の開発者ツールのサポートが充実しているRust言語と、多様なツールが存在するRuby言語を比較しながら、現在のRubyコミュニティが抱える問題点と、それに対するアプローチについて解説がありました。
Stock氏は、Rubyには公式のガイダンスや統合されたツール群が不足しているため、開発者は数多くの選択肢に直面し、設定に悩まされることを指摘しました。対照的に、Rustエコシステムでは、専任のチームが様々な開発タスクのために公式で維持されたツールを提供し、統合された開発体験を実現しています。統合されたデフォルトのツール群を持つことで、統合が容易になり、意思決定が最小限に抑えられ、設定が減り、学習曲線が緩やかになり、コミュニティ内でのコラボレーションが促進されるといったメリットが強調されました。
一方で、コミュニティ主導のツール設計には課題もあります。デフォルト設定やガイダンスが不足していると、ツールが断片化し、統合が難しくなります。また、新しい開発者は過剰な意思決定を求められ、設定の選択肢が多すぎて学習曲線が急になり、コミュニティの努力が分散してしまうというデメリットがあるとのことでした。
Stock氏によると、Rust言語では公式のセットアップ、Linter、テスト、フォーマッター、サーバーツールなどの選択肢がほぼ1つしかないのに対し、Rubyでは13,200通りもの組み合わせがあるそうです。
そこで、RubyコミュニティではRubyLSPを開発しています。RubyLSPは、テキストエディタやIDEなどのクライアントと言語サーバー間の通信を標準化するプロトコルで、Rubyの開発に必要な様々なツールを統合することを目的としています。RubocopのようなLinterや型チェッカー、テストツールなどのgemともシームレスに連携し、コミュニティとしてツールの選択がしやすい環境を目指しているとのことです。
私も普段の業務でRubyLSPを使用していますが、このような思想のもとに作られたツールについて直接話を聞けたのは、とても貴重な経験でした！
Matz Keynote
最後はRubyの開発者であるMatzの基調講演でした！
Rubyの公式HPにA Programmers’ Best Friendと書かれているようにRubyは書いていて楽しいという理念のもと作られたプログラミング言語です。
オブジェクト指向スクリプト言語 Ruby
Rubyの良い点として
クラスで分類されたメソッドが豊富に用意されている
制限が少ない
GemやVSCodeの拡張機能、Rubocopなどの周辺ツールが充実している(コミュニティの人たちが作った)
生産性が高い(Ruby on Railsの普及も大きい)
効率が良い(昔のRubyは遅かったが、今はだいぶ改善してGithubのようなサービスを動かしている)
20年経ったRuby on Railsが今でもたくさんの個人開発者や企業に使われ続けている。
Rubyをさらに良くするための取り組み
Performance（実行速度）の改善
プログラマは速いプログラムが好き。YARV(2007), MJIT(2018), YJIT(2022)などの実装により高速化
Ruby3ではRuby2の3倍の速度を目指すスローガン「Ruby3x3」。Basic Block Versioning によりRailsアプリが1.8倍高速化
Performance(メモリ効率の改善)
現代のWebアプリではメモリがボトルネックに。Rubyのメモリ消費を抑えることでコストを削減できる
Performance(並列処理の改善)
Threads, GVL Processes, Fiber(for I/O), Ractors(for CPU)の活用
NxM Threads の導入やRactorの軽量化、Ractor毎のGC
Performance(開発者体験の改善)
Ruby-LSP, Rubocop, Steepなどの周辺ツールとの連携
周辺ツールがRubyを理解するためのuniversal parserの開発（Prism と Rinda）
文法の安定化のために当面はRubyの文法変更を控える方針
未来のRuby
Ruby3系の間に今回Day1でNameSpaceに関して話されていたようなNameSpaceの分離を進めていきたいとおっしゃっていました！
Namespace, What and Why
また4系以降では、現在のYJITのようなJITコンパイラからAOTコンパイラの移行を目指したり、よりメモリ消費量の少ないプログラミング言語を目指していきたいとのことでした！
Rubyの過去から、現在の課題、未来でやっていきたいことが網羅的に理解できる素晴らしい基調講演でした！
感想
3日間セッションでいろんな情報を聞いたり他社のエンジニアの方とたくさん交流することができ刺激をたくさん受けました！また昨日のLTでクリエイティブコーディングが紹介されていて興味を持ったのでWebブラウザで実行できるp5.rbを使ってクリエイティブコーディング入門しました（絵のセンスはないですが、ハイビスカスを描きました） こちらからできるのでぜひ皆さんも試してみて下さい！
def stroke(*args) = $p5.stroke(*args)
def text(*args) = $p5.text(*args)
def fill(*args) = $p5.fill(*args)
def noise(*args) = $p5.noise(*args).to_f
def random(*args) = $p5.random(*args).to_f
R = 0.5
W = 800 * R
H = 600 * R
def setup
createCanvas(W, H)
colorMode(HSB, 360, 100, 100, 100)
textAlign(CENTER, CENTER)
end
def draw
background(200, 60, 100)
fill(200, 80, 80)
beginShape()
vertex(0, H)
(0..W).step(10).each do |x|
y = H/2 + sin(x * 0.02 + frameCount * 0.05) * H/6
vertex(x, y)
end
vertex(W, H)
endShape(CLOSE)
(0..1).each do |i|
x = random(W * 0.1, W * 0.9)
y = random(H * 0.1, H * 0.4)
drawHibiscus(x, y, 100 * R, 50 * R, 320, 100, 100)
end
fill(0, 0, 100)
textSize(80 * R)
text("RubyKaigi2024", W/2, H * 0.8)
blur(0.005)
end
def drawHibiscus(x, y, r1, r2, h, s, b)
fill(h, s, b)
ellipse(x, y, r1, r1)
(0..4).each do |i|
a = i * TAU/5
fill(h, s - 20, b)
petal(x + cos(a) * r1/2, y + sin(a) * r1/2, r2, r2, a)
end
fill(60, 100, 100)
ellipse(x, y, r2, r2)
end
def petal(x, y, w, h, a)
beginShape()
(0..1).step(0.01).each do |t|
r = (1 - t) * w/2 + t * h/2
vertex(x + cos(a) * t * r, y + sin(a) * t * r)
end
(0..1).step(0.01).each do |t|
r = (1 - t) * h/2 + t * w/2
vertex(x + cos(a + PI) * t * r, y + sin(a + PI) * t * r)
end
endShape(CLOSE)
end
def blur(d)
loadPixels()
(1...width).each do |x|
(1...height).each do |y|
c1 = $pixels[(x + y * width) * 4 + 0]
c2 = $pixels[(x + (y - 1) * width) * 4 + 0]
c = (c1*(1-d) + c2*d).to_i
$pixels[(x + y * width) * 4 + 0] = c
$pixels[(x + y * width) * 4 + 1] = c
$pixels[(x + y * width) * 4 + 2] = c
end
end
updatePixels()
end
AfterParty
最終日は公式のAfterPartyに参加しました！
RubyKaigi 2024 After Party sponsored by mov (2024/05/17 18:45〜)
国際通りのれん街の1F,2Fを貸切にして、900人くらいが集まる大規模なイベントでした！https://kokusaidori-norengai.com/
イベント中お会いした方、お話いただきありがとうございました！
