こんにちは、hsbt です。デス・ストランディング2のストーリーをやっと終えることができて国道建設や補修、荷物運びに専念する日々が続いています。
本エントリでは、来月開催される Ruby Association Activity Report への登壇の紹介と最近の Ruby の開発で取り組んだことについてご紹介します。
Ruby Association Activity Report に登壇します。
2025年8月28日(木)にビジョンセンター品川で開催される「Ruby Association Activity Report」に登壇します。「OSS開発者という働き方」というタイトルでフルタイムの OSS 開発者として、2年以上が経過した今の毎日の過ごし方や、仕事として OSS に向き合うときに考えていることなどについてご紹介する予定です。
また、本セミナーはイベント名にもあるように 2024 年度の Ruby Association の活動報告も行われます。特に 2024 年度の開発助成事業に採択された同僚の hasumi さんによる「PicoRuby2: VMにmrubyを利用した新PicoRuby」の結果報告をはじめとして、RDoc や Processing Gem に関する発表もあるため、Ruby の幅広い用途や開発の現状について知ることができる貴重な機会と思います。
ご興味がある方はぜひセミナーにご参加ください。当日は皆さんにお会いできるのを楽しみにしています。
最近 Ruby の開発で取り組んだこと
net-http のデフォルト Content-Type の廃止
Ruby に標準添付されている Net::HTTP ライブラリは、リクエストボディのメディアタイプが不明な場合でも、デフォルトで Content-Type として application/x-www-form-urlencoded というヘッダを自動的に付与していました。
この挙動について、送信者がメディアタイプを把握している場合にのみContent-Typeヘッダを設定するべき、というRFC 7231の仕様に反する挙動ではないか、という報告がありました。特にこの挙動は AWS S3 のような Content-Type ヘッダが API の重要なパラメータとなるサービスにおいて、問題を引き起こしているということでした。
実際に AWS SDK では、この Content-Type が常に指定される挙動を以下のようなコードで握りつぶしているそうです。
module Patches def self.apply! Net::HTTPGenericRequest.prepend(PatchDefaultContentType) end # For requests with bodies, Net::HTTP sets a default content type of: # 'application/x-www-form-urlencoded' # There are cases where we should not send content type at all. # Even when no body is supplied, Net::HTTP uses a default empty body # and sets it anyway. This patch disables the behavior when a Thread # local variable is set. module PatchDefaultContentType def supply_default_content_type return if Thread.current[:net_http_skip_default_content_type] super end end end
開発者会議で、AWS で実際に困っているらしいのでどうしましょうか、と相談しつつ、RFC で定義されていることもあるし、とりあえず消してみて様子を見てみようということになったので私の方で変更を行い、廃止してみました。
この変更は次の安定版リリースの Ruby に付属する Net::HTTP でのデフォルトの挙動として反映される予定です。次回のプレビューリリースの際に試していただいて、もしこの挙動が問題になる場合は、明示的に Content-Type ヘッダを設定するか、 https://bugs.ruby-lang.org か https://github.com/ruby/net-http/ にご報告いただければと思います。
tsort の bundled gems 化に向けた準備
tsortは、トポロジカルソート(依存関係のあるタスクの順序解決などに使われるアルゴリズム)を提供するライブラリで、長らくRubyに標準で default gem として添付されていました。
昨年、私が default gem を bundled gem として切り出していく作業をしているときに set の内部で tsort を密結合して使っている箇所があり、tsort をコピーして set に埋め込んでまで tsort を切り出す必要はないと判断したため、Ruby 3.4 では tsort はそのまま default gem として残されていました。
しかし、set が Rubyのコアクラス（組み込みクラス）にするという提案がつい先日 Matz に approve され、実際に C で書き直された set が Ruby 本体に組み込まれました。
set が組み込みクラスになる、という提案の時には気が付かなかったのですが、つい先日 tsort をたまたま眺めていた時に、昨年 bundled gem にすることを断念したということを思い出し、実際に Ruby 本体から tsort を消して試してみたところ、ビルドもテストも完走することを確認できたので、改めて提案した、というのが事の経緯です。
ただし、tsort が bundled gem になるのは、今年ではなく来年リリースされるバージョンである 3.6 か 4.1 になるため、今年リリース予定のバージョンでは tsort が bundled gem になる、という警告が表示されるようになります。
tsort を使っているアプリケーションやライブラリの開発者は、bundled gem になった tsort を引き続き使うためには、手元のアプリケーションの Gemfile に追加するか、ライブラリであれば gemspec に add_dependency メソッドを用いて追加する必要があります。まだ1年以上先のため猶予期間はありますが、念頭においてもらえるとありがたいです。
まとめ
来月開催される Ruby Association Activity Report の登壇とイベントの内容、最近 Ruby の開発で取り組んだ内容のうち、Ruby でソフトウェアを書いている方に影響がありそうな内容についてご紹介しました。引き続き、今回紹介したような細かい変更でも、意図や背景などを解説していこうと思うので、ぜひ本テックブログにご注目ください。
アンドパッドでは Ruby の動向をキャッチアップしながら、息を吸うようにアップストリームにフィードバックもする Rubyist を大歓迎しています。
