HsbtDiary

■ Rails DM 2019 で RubyGems 3 の話をしてきた

Rails DM 2019 で RubyGems 3 の話をするために青山の Oracle オフィスまで行ってきた。山手線と銀座線を駆使するってかんじだったけど中々遠い。

オープニングで DHH の AMA があって、Ruby 3 に期待することは -> Ruby は十分速いよ、というコメントが面白すぎてよかった。話も流暢だし、毎年 RailsConf でキーノートやってるだけあるなあと感心してしまった。一回くらいは RailsConf に行って会っておこう。

この後は発表を聞きながら軽く資料を手直ししたりしていた。RubyKaigi と違って practical な話が多くてだいぶ面白かったなあ。お弁当を食べながらスタディプラスの、英語学習の動画を見てよくできてるなと興味を持ったり、チラシをもらいながらぶらぶらしたり。

発表はメインホールで半分か 1/3 くらいの人が座ってたって感じで。

主に去年の後半のカンファレンスで話したことと最近のアップデートって内容の発表でした。主に過去の内容しか話してないので、未来については RubyKaigi 2019 を期待してください。質問アプリに来ている質問はここで回答しておきます。

http://railsdm.herokuapp.com/issues/117

• 現状のRubyGemsはSemVerライクとのことですが、何かSemVer準拠にできない事情があるのでしょうか？

良い質問ですね。SemVer にするメリットが何もないからですね...。実際、不具合修正と機能追加を分けたとしても不具合修正だけで絶対に regression を起こさないってのはリリースマネジメントで難しいんすよね。なので、不具合修正を大変にして少しだけ機能追加を teeny にして、割と大きい機能追加を minor, 明らかな非互換を major という Rails と似たようなリリースマネジメントの方がやる側が楽だからです。

あと、個人的に SemVer を強制する強硬派の対応に疲れてるってのもあるかもしれません。

• 空き時間の盆栽いじりと脆弱性対応は両立できないのではないかと思ったのですが、そのあたりはどのようにやっているのでしょうか。

これもいい質問ですね。実は脆弱性対応、というのは公表する側にとっては、公表しない限り脆弱性ではないのです(禅問答)。なので、脆弱性が公開されて、対応しなければいけないというアプリケーションやライブラリの利用側と違って、対応する側にとっては時間をコントロールしながら改修や調整をすればいいので、実は盆栽いじりのように対応ができるんです。この辺、builderscon あたりで、採択されたら話す予定です。

発表は久しぶりに 30min で収まるように良い感じに発表出来たので、あとはメインホールで電源を使いながらコード書いたり、なぜか会場にいた Matz とおしゃべりするなどして過ごしていた。どの発表も面白かったなあ。懇親会では主に業務的なことばかり話して、ちょっと先に抜けてから帰宅。

一日目お疲れさまでした。