U-Next の NHK オンデマンドアドオンの一覧を見ていたら、アオイホノオが配信されているのを知ってもう一度一気見してしまった。
原作の漫画も全巻持っていて、ドラマの方も全話見ていたんだけど、ドラマが12年前、というのに「マジで...」となってしまった。あと内容的に、ガイアックスなどのゴタゴタもあり、今新たに公開みたいな感じだと多分難しいのだろうなあ...とか感じてしまった。
内容としては、「漫画家になれなかった時のことを考えているやつはダメ」「やらなあかん!」みたいなパワーワードを見ると、ちょっとだけやる気が出てきたのでいい経験だった。続編あればいいなあ、とか当時は思っていた気がするけど、このあとは割とグダグダが続くので、ちょうどいい終わり方ではないかな、とは思った。
syck が 4.1.0-dev でビルドできないというのを見つけて、claude にぶん投げてビルドできるようにしてから、積み上がっている pull request や issue も投げては理解して、「こう直しておいて」みたいな感じでバシバシ閉じたやつで 1.6.0 としてリリースしておいた。
https://github.com/ruby/syck/releases/tag/v1.6.0
Ruby 3.3 との組み合わせで結構な頻度で SEGV が起きる、みたいなんだけど手元だと結構な頻度で回しても発生しなかったんだよなあ。もし本気で困ってる人がいたら教えてください。直すかもしれません。
rubygems.org のデザインリニューアルが再開していて、 https://guides.rubygems.org/ にも pull request がきたのでマージしてデプロイしておいた。
https://github.com/rubygems/guides/pull/470
で、この前段階として、guides の github-pages は昔のブランチを指定したら内部で何かが動いて github-pages が作成される、という legacy ビルダーのままだったので、まずは github actions を使った方に migrate というのをやっていたのだった。
https://github.com/rubygems/guides/pull/474
もうちょい記述内容の重複とか、流れに沿って読んで意味のある構造などにしたいのだけど、それはまた今度。
2週間ぶりの定期リリース。今回のリリースでは、-j をつけたときにビルドジョブを make jobserver という仕組みで賢く振り分けたり、Fable 5 にやらせたメモリ削減を入れたり、cooldown や plugin の渋いバグを直したりとまあまあなボリュームを入れている。
https://blog.rubygems.org/2026/06/24/4.0.15-released.html
ついでに、コンフリクトをいい感じに直すのを claude に仕込みつつあるので、rb_sys のバージョン更新など、今までならコンフリクト解消だる、でやめていたのをウリャっと進めてしまった。
https://github.com/ruby/rubygems/pull/9640
あと、メンテナンスブランチへ auto pick するにはコードベースが違いすぎるので、個別に pull req を用意してマージしたやつが changelog に出てこなかったり、手元の branch が remote origin と差があるときに pick の対象とならなかったり、みたいなケースも claude に「直して」とバンバンぶん投げて直してもらった。
で、RubyGems のリリースは自動化スクリプトによる auto pick を駆使しているんだけど、2-3回は素振りをしてコンフリクトの傾向を把握してから、本番リリース、としていて素振りで修正したコンフリクトが2-3回目の試行では自動で直っていてなんで?と思ったらこれは git rerere という機能だった。
名前だけは知っていたけど、何かはよくわかっておらず、おすすめ設定として有効にしていたので適用されていた、ということっぽい。これは、コンフリクトの修正を間違えてやった場合もそのまま間違えたまま適用、を繰り返すのでだるい、となったので claude に「なんで間違えた修正が繰り返し入るんですか?」と聞いたら、rerere や、forgot を使って消すことができます、というのも教えてくれて勉強になった。
claude を使うとき、あまり丁寧に背景とか説明しないで、やりたいことだけをすごい雑に聞く、というのに慣れてきた気がする。
rubygems では 10 年くらいに渡って、トップディレクトリに bundler というディレクトリを入れたままリポジトリはモノレポだけど、ただコードが同じ箇所にあるだけ、CI には便利、一緒に直すときも便利、という物理的にしか意味がなく、コードの共有化、とか結合レベルの上げ下げ、みたいなことは何もできない状態が続いていたのだけど、AI パワーでやっと lib の下にフラットに配置してしまった。
https://github.com/ruby/rubygems/pull/9634
とはいえ、これをベースに重複している vendor コードの共通化、モンキーパッチしているコードの共通化、なども含めた大きめの計画を丸2日くらいかけて、日本語であーでもない、こーでもない、というのを考えてから「で、これ作れるんですか?」「作れます」まで行けたので進めたのだった。
https://github.com/ruby/rubygems/issues/9236#issuecomment-4748470107
実際にやってみると、手元だけでは実行できないケースで CI が落ちたものの、ひたすら claude に直させたら割とあっさり終わったので 4.0.15 のリリース後にさくっとマージしてしまった。
なんか、bundler 側に lib/rubygems/* というコードを放り込んで、ロード時に二重ロードしない、というガードを入れたら、このまままずはランタイムベースの統合を進めて行ける気がしてきたなあ。頑張ろう。
何でも claude で解決だ、と DataDog にも log drain があるのを知ったので最近よくログをダウンロードしては調査をさせていた git.ruby-lang.org の apache2 のログを DataDog に放り込むようにした。もちろん claude が全部やった。
https://github.com/ruby/git.ruby-lang.org/pull/108
実際にはこれを適用するだけで、claude から DataDog MCP を経由してサーバーの状況を把握できるようになったので捗りまくる。ec2 で面倒見てる奴はこれを入れて回れば claude だけで何もかもをシュッとできるかなあ。
先週の木曜に依頼した修理がダメで改めてメーカーに修理を依頼して、その作業が今日あった。
担当者の作業としてははいはい、って感じで特にでかい作業になることなくサクッと終わって、今までのはなんだったんだ、というくらいレバーが簡単に動くようになった。これ、自分でメンテできるんですか?と聞いたら、カルキが固まるケースなのでできない、また硬くなったら交換して欲しい、みたいな話になっていて「は?」という顔をしてしまった。
電気工事士、みたいな奴ならともかく、自分で買った家につけるものに業者の縛りを入れるのと、自分でメンテできる手段を提供しない、さらに経年劣化は避けられない、ってのは欠陥なんじゃねーの、と思うけど、担当者にブチ切れてもしょうがないので「そうなんですね」という感じで終わり。
うちの台所の水道もこんな感じのメーカー独特のやつで、交換とかメンテができないんだけど、こういうのは家を建てたり、買ったりしてから初めて気がつくポイントだよなあって思った。本当に酷い。
tDiary でも使っている CGI だけど、特に escape 周りとかドキュメントで修正が溜まっていたので新しいバージョンをリリースしておいた。
https://github.com/ruby/cgi/releases/tag/v0.5.2
Ruby 4.0 と fcgi でも軽快に動いているので、必要な人は引き続きご利用ください。