こんにちは @hsbt です。毎回になりますがゲームばかりやっているのに加えて、夏くらいからバラ栽培にハマっています。最近は NHK の趣味の園芸の録画と視聴に加えて Youtube の バラ塾 や ガーデンちゃんねるなどを見て、バラの育成知識を勉強しつつ、来年の春に向けた冬剪定をやったりしています。
さて、ANDPAD Advent Calendar 5日目のこの記事では、Ruby の未来に向けた機能開発の状況についていくつかご紹介します。
Ruby Hackathon 2024 を開催してきました
Ruby の core チーム(Ruby コミッタの集まり)では、例年どこかに集まって合宿という形で相談しながらなにか難しい課題を解決するコードを書くということをやっています。今年は RubyWorld Conference 2024 が開催される前日に松江駅前のオープンソースラボに集まって開催しました。
今回は Ruby コミッタ以外の方でも、何かしら Ruby のエコシステムに関連する開発をする、ということなら参加可能としました。以下のような開発テーマについて10数名で取り組みました。
- Coverity scan によって出力されている警告の triage と修正
- bug tracker の triage
- Kaigi on Rails が使っている cfpapp の 依存ライブラリアップデート
- Ruby の Unicode 15 と 16 対応の調査
- rbs の開発
- prism と parse.y の将来に向けたディスカッション
私は今年 Ruby 3.4 向けに開発した内容をリリースノートへ追記したり、turbo_tests と呼ばれる parallel_tests の拡張ライブラリを Ruby のリポジトリで使えないかどうかの調査をしました。自分がコードを書くことはもちろんですが、自分以外の人たちも含め、Ruby の機能開発を盛り上げて、Ruby が持つ課題解決能力を高めて行きたいと思います。
Ruby の中にある解決できると嬉しい人が多分多いタフな問題のその後
さて、後半は以前に私が「Ruby の中にある解決できると嬉しい人が多分多いタフな問題」として 2022 年 12 月に投稿した内容のその後と2024年の今ある課題、についてです。
まず、上記のエントリで紹介したもののうち「Socket の Happy Eyeballs Version 2 対応」「ライブラリを複数バージョン同時にロードする機構」は 2023年度Rubyアソシエーション開発助成金成果報告 として報告されている通り一定の進捗が出ており、Happy Eyeballs Version 2 対応については Ruby 3.4 に何かしらの形で取り込まれる目処になっています。
しかし、ライブラリの Ractor 対応については、それほど進んでいません。これは鶏と卵問題でもあって、標準ライブラリが Ractor に対応していないので、Ractor の利用が進まなく、Ractor の利用が進まないので標準ライブラリの対応が進まないという両面があります。そのため、誰かが強い気持ちでえいやっとやるしかないと考えています。どなたかやりませんか。
新しいタフな問題 2024
さて、最後にRuby コミッタがほしいものを集めているメモの一覧である壺の中から私見でいくつか取り出してご紹介します。
JSON5 対応
Ruby が default gems として提供している JSON ライブラリは、今までは GitHub の flori/json というオリジナル作者のリポジトリのもとで開発され、私が実質的なメンテナとして分かる範囲の pull-request をマージしたり、適宜リリースを行うなどしてきましたが、長年にわたる交渉を経て ruby/json として、Ruby core チームでメンテナンスしていくこととなりました。現在は @byroot が積極的にパフォーマンス・チューニングを行っています。
さて、そんな JSON ですが、近年では JSON5 というフォーマットが存在します。これは JSON のスーパーセットとなっていて
- コメントが書ける
- 末尾カンマが書ける
- キー・バリュースタイルのキーをダブルクオーテーションなどで括らなくても良い
などの特徴があります。私も YAML をたくさん書いたあとに JSON を書くときなどに「あれ、コメント書けないんだっけ?」とエラーが出てから気がつくということがたまにあります。それを解決してくれるのが JSON5 です。これを JSON ライブラリに統合すべきかどうか、は議論の余地があるところですが、例えば JSON.enable_json5 とか JSON.parse(..., json5: true) としたら JSON5 な json を読み込めるなら嬉しいと思います。
しかし、この JSON のようなコメントを書くことができる構造化フォーマットをパースして、ダンプしたときにコメントも復元できるべきかどうか、というのはなかなか難しい問題です。先に書いた通り、もともと存在する JSON ライブラリとはどのように共存すべきか、なども含めて進めてくれる方がいたらお声がけください。
URI のパーサーとして https://url.spec.whatwg.org/ に準拠する
Ruby が提供している URI ライブラリは従来は RFC2396 の仕様に従ったパーサーを用いていましたが、Ruby 3.4 以降に同梱される 1.0.0 以降のバージョンでは RFC3986 が標準のパーサーとして利用されます。さて、このRFC3986は実は 2005 年の規格となっていて、現在のブラウザなどが使用している規格は https://url.spec.whatwg.org/ です。
この whatwg が提供する URL の規格に沿ったパーサーを実装して、URI でそれを使えるようになると、ブラウザなどと同じ挙動となり嬉しい人が少しは増えそうな気がします。この whatwg の規格はバージョンごとに提供されるものではなく、いわゆるローリングリリースといったもので、決定されたらすぐ発行される、というものらしいです。つまり、URI から使えるパーサーについても同様に最新の仕様に追従してアップデートできるような仕組みが必要になるでしょう。
幸いにして、私が URI の標準のパーサーを変更した際に URI が使うパーサーは URI.parser = ... として変更可能としたので、とりあえずは URI.parser によって変更される箇所の API を抑えた whatwg 準拠のパーサーを書くことができれば、対応はできそうです。どなたか興味ありませんか?
おわりに
Ruby Hackathonやちょっと難しいけど頑張ると解決できそうな課題いくつかについて紹介しました。Ruby に限りませんが、OSS は使うだけでも楽しいのですが、作っても楽しいですし、いろんな人たちによる活動の積み重ねが今の Ruby を作ったと言っても過言ではありません。そのような活動に興味がある方はぜひお声がけください。一緒に Ruby をより良く、楽しいものにしていきましょう。
アンドパッドでは Ruby の開発にもコミットしたいという方を全力で応援し、そして積極的に募集しています。 ぜひ私と一緒に開発をしましょう。 hrmos.co hrmos.co
