RubyKaigi 2024初参加!(セッション編) #rubykaigi
こんにちは!
ツクリンク株式会社のめばしい ( @aiuhehe ) です!
「RubyKaigi 2024初参加!(出会い編) 」にてRubyKaigi開催期間での交流についてまとめております。
本記事では聴講したセッション内容をいくつかピックアップして感じたことを記載していきます〜!
会場
RubyKaigiでは3つの会場に分かれてスケジュールが組まれており、自分で興味のある会場(同じ施設内)に向かうことができます。
セッション会場では、聴講側から見て壇上左手側に日本語から英語へのライブ通訳とDiscord上でのチャットログが表示されるようになっておりました。
RubyKaigiのOnsiteページにDiscordへの流入口がありました。
Day1 Writing Weird Code
tomoya ishida ( @tompng ) さん
まず、アート的な表現をコードで書くことができることに非常に感動しました。
アスキーアートのようなコード、絵の一部にコード、どちらも見た目に美しく(文法的な意味ではなく映像的な意味)、エンジニアでなくても楽しめることに感銘を受けました。
正直、どんなトリックなのか発表中に説明してくださっていましたが、思いもつかない発想がとても興味深かったです。
%!s! == "s"
%%s% == "s"
%%% == ""
"RubyKaigi %d" % 2024 == "RubyKaigi 2024"
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% == ""
こんな世界があるのか😦
もっと複雑なトリックも説明してくださっていましたが、説明込みで発表資料に記載があるので見てみると非常に面白いです!
Rubyに関してまだまだなので、Techhouse株式会社さんのブースでGETしたTechouse特製ノートfor Rubyistと照らし合わせてみたのですが演算子の優先順位やEncording周りもより深く学べました💡
いつか私も作ってみたいのでRubyKaigi終わってから発表資料参考にしつつ、GitHubのソースコードも読んでみたいと思います!
Day1 Namespace, What and Why
Satoshi Tagomori ( @tagomoris ) さん
名前空間とは何か、どんな目的があるのか、展望についてのセッションでした。
名前空間は、1つのプログラム内で同一名の異なるクラスやモジュール、ライブラリを名前、定義、バージョンの衝突を回避して、使えるようにする仕組みです。
目的は、クラス・モジュール・ライブラリの名前・定義・バージョンの衝突を回避することです。
同一ライブラリの複数バージョンを混在させたり、同一名だけど別のライブラリを混在させたりできるようになるだろうとおっしゃっていました。
展望については、アプリケーション毎に名前空間を定義することで、1つのアプリケーションサーバで複数のアプリケーションを動かすことが可能になるかもしれない。全ライブラリを名前空間にて管理することで、ライブラリ同士の命名衝突を回避可能になるとおっしゃってました。
実現してはいないそうですが、Rubyに取り入れられた場合影響が大きそうだと感じました。
また、Matzさんのキーノートでも「名前空間が入ったらRuby4.0にしよう」と取り上げられていました。
名前空間は大きな注目を浴びているようだと感じました!
Day2 Good first issues of TypeProf
Yusuke Endoh ( @mametter ) さん
TypeProfの説明、開発を手伝ってくれる方を募集していますというセッションでした。
TypeProfの開発を手伝ってくれる方向けにこんな感じで開発いるよ〜と説明がありました。
テストを書く
実装する
テストが通ることを確認する
テスト駆動開発を取り入れているのですね。
「テストを書く」だけでもいいから書いてくれると嬉しいと協力者募集しておりました。
注意事項としては、Ruby構造を網羅できていないため開発で使う際に失敗してしまうことがあるそうです。
セッションで例に挙げたものでは、キーワード引数は失敗してしまうとおっしゃってました。
自分もテストだけでも貢献できないかな。。となるようなセッションでした。
Day3 Using Ruby in the browser is wonderful.
ruby.wasmを利用してブラウザ上でRubyが動かせるよ、ruby.wasmにどんな貢献をしてきたよという発表でした。
CRubyとJavaScriptの架け橋に貢献し、JavaScriptのコードがRubyのコードに混ざらなくなるのでスッキリ書くことができるようになるとのこと。
ブラウザ上で動くテトリスのデモも行っていました。
セッション中ではないのですが、のちにRubyKaigi感想戦を社内エンジニアで行った際に、STORES 株式会社さんのクイズも、もしかしてruby.wasmのおかげでブラウザ上でRubyを動かした結果の表示ができたのな?と思いました。
Day3 Ruby Committers and the World
Rubyコミッターがステージに登壇して、トークテーマに関して議論してました。
例年がどうなのかわかりませんが、Rubyのコミッターの方達が一堂に会する機会ってそうそうあることなのか?!すごい瞬間を見ているのではないか?!と思いながら参加していました。
Frozen string literal
お恥ずかしながらセッション中は何のお話かわからなかったです。
後で調べてみたのですが、まとめてくださっている方がいたので、自分と同じく今年初参加だったり、Ruby歴短くて何のお話かわからなかったという方は下記参考にしてみるといいかもしれません。
RBSに関して会場に問いかける場面もありました。
こんな感じだったと思います。
GVLを取るか残すか?という壇上での挙手での多数決もありました。
自分が、かなり前方に座ってしまっていたため、壇上の奥の方の挙手が見えていないのですが、下記のような割合での挙手でした。
いらない: 2名(だいたい)
残すべき: 8名(だいたい)
Improving Ruby's async usability
なんかうまくいかないからasync付けたことある人いません?というMatzさんからの問いかけがありましたね。
Matzさん「ダメだって言ってasync付けるのは Bad Experienceだと思いますよ」
どうしてそうしたいのか、一度立ち返る分岐点にしようと思いました。
Day3 Matz Keynote
いつもは最初に基調講演でトークされることが多いらしく、最後に話すことは珍しいため緊張しているとのことでした。
Ruby2を一度新しい言語として作ろうとした時期があったが、今のRubyへの協力者が増えてどんどんやりたいと思っていたことが形になっていったとおっしゃっていました。
Rubyを取り巻くツールに関してもサポートが厚いと感謝されてましたね。
RubyLSP, rubocop, steep, copilot。steepは知らないツールだったので調べました。
使ったことない!ので、早速使ってみようと思っています💪
当たり前に使っている方もいらっしゃるとは思いますが、勉強中の私にとって、トーク中に色々な単語やツールを出してくださるのはありがたいです。学習速度がグッと早まる気がします!
The state of Ruby devToolというセッションがあったのですが見れていないのでまとめ記事参考にしつつ後で拝見させていただこうと思います。
Parserに関してはprismとLramaどちらを主軸にするか悩んでいるというお話。基本的な構造はprism使おうと考えているらしいですが一長一短であり、まだ悩むところがあるらしいです。
私はこの一長一短の部分が理解できなかったので来年までに勉強したいと思います💪
あとは、今日から1年程、prismのクオリティを上げるためにRubyの文法の変更をしない提案を挙げていらっしゃいました。
バグリリースや文法をよりクリアにするとかの変更は行っていくけれども、基本的な変更はしていかないということらしいです。
prismの開発者であるKevin Newtonさんとの月末の話し合いで提案撤回する可能性はありますが、現状の方針としては文法変更はしないという方針のようです。
今後の夢の話ということでしたが、下記挙げていました。
地球にやさしいRuby
コストが低いRuby
まとめ
Matz Keynoteにて現状のRubyの取り組み、今後のRubyの展望が語られており、各種イベント会場でも来年までにこれらの開発をしようという感想を話している方々が多かったです。
今回の参加者の中にRubyKaigiは2回目からが本番だとおっしゃっている方がいました。
来年に向けて、今回掴んだトレンドの分野の勉強をして、RubyKaigi2025はさらに内容を理解しつつ楽しめるようになります!
松山が待ち遠しいです!