RubyKaigi 2024に参加してきました。
聴講したセッションについて、ざっくりとまとめたいと思います。
内容の不足だけでなく、勘違いも多くあるかと思います。
Rubyコミッターの話を完全に理解するのは至難の業でしたので、本当に自分用のメモです🙏
セッション
Writing Weird Code
Unlocking Potential of Property Based Testing with Ractor
- RSpec的なテストはexample based testであり、property based testという手法がある
- property based testは短いテストコードで大量のテストをおこなうことができるのが特徴
- ただし、example based testと比較するとテスト時間が長くなるというデメリットもある
- そこで、 PBT gemを開発し、Ractorの特徴を活かしてパラレルでテストを実行できるようにした
Long journey of Ruby standard library
- Rubyの標準ライブラリには、組み込みクラスと標準ライブラリがある
- 標準ライブラリが最も多かったのは、Ruby 1.8
- 当時は気軽にインターネットに通信することが難しく、ライブラリを都度インストールすることが難しかった
- 初期段階で多くのライブラリをインストールすることが良しという考えだった
- (それ以降は理解ができませんでした)
Let's use LLMs from Ruby 〜 Refine RBS types using LLM 〜
- LLMの性能は向上している
- Rubyの型推測をLLMにさせたい
- RBS Gooseというアプリを作成した
- untypedに型を当てはめる
- まだ改善の余地あり
Exploring Reline: Enhancing Command Line Usability
- RelineとGNU Readlineの違いを紹介
- Relineを使いたい気持ち
- (ここ優位性なのか利便性なのか、何故だかは分かってません。)
- Relineにundo機能を追加した
Optimizing Ruby: Building an Always-On Production Profiler
-
datadog/dd-trace-rb
- CRuby/MRI Ruby 2.5+
- Ruby + C +Rust
- めちゃ多いプロファイラを少ない時間の中でどう処理するか?
Getting along with YAML comments with Psych
- yamlに#でコメントを入れたい
- Psych-commentsというgemを作ることで実現した
- 改行やスペースの扱いを工夫する必要があった
- 他の方からコミットしてもらい、乗り越えた箇所もある
Good first issues of TypeProf
- TypeProfとは、Rubyエディタの機能
- 型推論をしてくれる
- 型エラーを表示してくれる
- メソッドの補完
- 新機能
- 一部をリネームすると他の箇所も連動してリネームされる
- メソッドの他の使われている箇所を一覧で出してくれる
- TypeProfの使い方
- TypeProfの開発方法
- TDDを採用
Squeezing Unicode Names into Ruby Regular Expressions
- \p{Hiragana}
- RubyはUnicode propertiesをサポートしている
- HIRAGANA LETTER A -> U+3042(あ)
The test code generator using static analysis and LLM
時間の都合上LTを聞くことはできませんでしたが、GitHubリポジトリを見ました
Ruby Committers and the World
- 新しいコミッターの紹介
- ディスカッション
- literal string will be frozen in the future
- Ruby 4.0で実装される予定
-
frozen_string_literal: true
とかString#freeze
とかが不要になる
-
defer
for Ruby?- Goにある機能
-
ensure
との比較
- literal string will be frozen in the future
- Ruby confの紹介
Make Your Own Regex Engine!
- 正規表現の先読み、後読みのメモ化がRuby 3.3で実装
- 正規表現エンジンの中身を理解しよう
-
https://github.com/makenowjust/kantan-regex-book
- literal:
a
- concat:
aa
- choice:
a|a
- repetition:
a*
- literal:
Matz Keynote(Rubyをよりよくするには)
- Rubyは良い
- 「こういうメソッドがあったら良いのにな」が大体ある
- 制限が少ない
- Integer Size
- Built-in / User Defined
- 生産性が高い
- Railsは今年で20周年
- https://toprubycompanies.info/
- 効率が良い
- 過去は「遅い」と言われていた
- Rubyをより良くするには
- YARV
- 高速化を支援
- YJIT
- MJITより早い
- Rails appが1.8倍早くなった
- Rubyを省メモリにする必要がある
- 開発パフォーマンス
- ツールによるサポート
- Ruby-LSP, RuboCop,,,
- Parserが必要
- ツールによるサポート
- API will be based on Prism
- 未来のRuby
- Selector Namespace
- Namespace, What and Why
- これが実装されたらRuby 4.0になるかも
- Packages
- Matzが欲しいもの
- 地球に優しい省資源なRuby
- SDGs, GX
- AOTコンパイラ
- 地球に優しい省資源なRuby
- Selector Namespace
- YARV
- Ruby Community
- ヨーロッパ圏内でRubyカンファレンスが5つ開催された
コミッターとの会話
ESM Night Cruise at RubyKaigi 2024にて、@k_tsjさんと会話する機会がありました。
そこでRubyコミッターへのモチベーションを伺うことができました。
(個人的にはこの会話をできたことが一番良かったです。)
k_tsjさんは高校生の頃からプログラミングを趣味として楽しんでいたそうです。
当時からRubyを用いてプログラムを作成しており、その魅力に取り憑かれていたとのことです。
しかし、社会人になりSIerとして働き始めると、仕事でRubyのコードを書く機会がほとんど無くなってしまいました。
プログラミングをする機会が減り、次第にフラストレーションが溜まっていったそうです。
そんな中、k_tsjさんはフラストレーションを発散するために、OSSであるRubyへのコミットを始めたのです。
それが社会人約3年目のことでした。
仕事でのストレスを和らげるために、時間を見つけてはRubyのコードを書き、コミュニティに貢献していきました。
それからk_tsjさんは約10年間RubyKaigiへの登壇をするほど継続的にコミットし続ける人材となりました。
彼の話を聞いて、不満な現状に対して能動的に動くことの大切さを改めて感じることができました。
Rubyコミュニティの一員として、彼のような情熱的なプログラマーの存在は非常に励みになります。
海外エンジニアとの会話
Dring upでは海外エンジニアとも会話する機会がありました。
以下では自分が質問した回答をまとめます。
(Rubyistの回答なため、多少ポジショントーク的な要素はあると思います)
- 海外でのRubyの使用率は?
- 少なくない。特にスタートアップでの採用率が高い(フロリダからの参加者)
- もし新しいプロダクトを開発する際はRubyを採用するかも(shopify社員)
- エンジニアリソースの確保が容易なため
- セッションの理解度は?
- 難しかったけど、面白いね(フロリダからの参加者)
- (面白いと言えるってことは、理解してるのでは、、?)
- 難しかったけど、面白いね(フロリダからの参加者)
- あなた達の企業も、RubyKaigiへの参加者に対して補助が出るの?
- 出るよ〜(shopify社員)
雑多な感想
- 経済効果いくらくらいあるんだろう?
- 約1,000人が参加してホテル代とか飲食代とかに落ちるのか
- 自治体から誘致の連絡とかあっても良いレベルでは?
- 被災地とかで開催すれば良い気がする
- リアルタイム翻訳はどうやってるんだろう?
- 翻訳してるってことは内容を理解してるってことだよね?
- コミッターの話す内容が理解できる && 翻訳できるほどの英語力 を持ち合わせた人材がいるということ?
- ステッカーもらえて嬉しい
- Macに貼ります
- 採用施策としての効果はどのくらいあるんだろう?
- 言語のマッチングが確約してて、参加するモチベーションがある人達が集まる訳だから企業は欲しがるよね
- 分かりやすい構成
- 課題の共有(こういうことしたいよね)
- 解決策の提示(こんな風に解決しました)
- 前提(そもそもxxっていうのは、、、)
- アプローチ(だから、ここをこうすればイケると思ったんだよね)
- 乗り越えるべき壁(そしたら、新たにこんな問題が発生しました)
- アプローチ(それを何とかして乗り越えました)
- 解決策のデモ(その結果できあがったのがこちらです)
- (今後の課題)
- 締め
- 自分が普段使ってるサービスの開発者と会話ができるのすごい
- どんな思いで開発しているのか
- どんな開発体験なのか
- 自社名を伝えたときに「知ってます」とか「使ったことあります」と言われるようになりたいな
- 会話してて、誰も自分に質問してこないのはさみしい
来年の情報
2025年4月16-18日
愛媛県松山市にて