RubyKaigi Takeout 2020 に登壇した。
本編登壇は RubyKaigi 2018 以来 2 回目。去年 RubyKaigi 2019 では LT 登壇で TracePoint を使うことによって仕込んでしまったバグの話をしていた。
今回のスライドは以下です。
RuboCop 1.0 に向けた話
本編から RuboCop 1.0 に向けた話をいくつかピックアップしておきます。後述の収録への問題があったため、特に終盤テンポが上がっていることからテキストとして少し補足しておきます。
拡張 API の変更
拡張 Cop の開発者向けの API は以下のように変更になります。
これまでの API:
class CustomCop < Cop
def on_send(node)
end
def autocorrect(node)
end
end
これからの API:
class CustomCop < Base
extend AutoCorrector
def on_send(node)
add_offense(node) do |corrector|
end
end
end
従来の RuboCop::Cop::Cop はすぐに削除されるものではない soft deprecated なものですが、今後は RuboCop::Cop::Base を使うことをすすめます。RuboCop 自体もまだ移行中です。依存している Parser 実装から変わっているため、まだ予期していない不具合を持っている可能性があります。何か問題を見つけたら rubocop-hq までご連絡ください。
Safe / SafeAutoCorrect
RuboCop には Safe と SafeAutoCorrect という概念があります。
Safe は偽陽性を起こすことなく検出できるかどうかによって、避けることが難しい偽陽性が目立ったものは安全でない Safe: false がマークされています。
SafeAutoCorrect は振る舞いの互換性を維持できるかどうかです。こちらも RuboCop の提案による変更で非互換を起こすものは SafeAutoCorrect: false が設定されています。また偽陽性を持ったままの変更したことで壊れることを防ぐため Safe: false とされているものは SafeAutoCorrect: false です。
とりわけ最近の重要な変更点として、rubocop -a オプションの挙動変更と rubocop -A オプションの導入です。前者は安全な Cop でのみ自動修正を行うもので、後者は安全でない Cop も含めて自動修正を行うものです。
RuboCop 0.86 以前では、frozen stirng magic comment を追加する場合は rubocop -a でしたが、frozen string になったことで破壊的メソッドへの呼び出しがあるような場合など非互換の変更になる可能性があります。このような安全でない Cop での自動修正を実行したい場合は rubocop -A コマンドを使うことになります。
以下のエントリも参考にしてください。
koic.hatenablog.com
pending ステータス
もしいま使っている RuboCop がちょっと古くてアップグレードしづらいといった問題は、Cop への pending ステータスの導入での軽減を図っています。
ここ何バージョンかで RuboCop に追加された新しい Cop は 1.0 までは pending というステータスで、デフォルトでは有効になっていません。ユーザーが明示的に .rubocop.yml への Enabled: true か Enabled: false を指定してどうするかを決めるようになっています。
pending ステータスのものは RuboCop 1.0 で有効になりますので、もしそれまでにデフォルトで有効になるべきでない Cop を見かけたら RuboCop HQ までお知らせください。
本編収録にあたって
音楽 CD でライブ盤とスタジオ盤があるように、これまでふだんをライブだったとすると、今回はじめてのスタジオ盤の収録となってなかなか思うように行かなかった。その点を書き残しておく。
スライドと録音を同期させる方法として RubyKaigi チームから紹介があり、普段使いのプレゼンテーションツールが Keynote なので、Keynote での録音が手速かろうと進めていた。
実はそこでもいろいろとあって、手元の環境が古すぎて録音機能がない Keynote 6.0 (2013年) からのアップグレードというのが最初に必要だった。そしてそもそもの macOS が古いため OS のアップグレードも必要でとなり、そのあたりのセットアップに時間が使われたりした。
そのあとはスライドへの音録りになるけれど Keynote の録音機能の使い方を調べつつ覚えていった。ページ切り替えのタイミングによってやや音質が変わるのは、うまく録音できていた箇所まで戻してやり直しかひと呼吸取るためのものだった。
そしてインターネットの向こうにも人がいない PC に向かって話すということができなくて、全編テキスト起こしをするということをしていた。筋肉少女帯の『詩人オウムの世界』のギターソロはふだんアドリブで弾いているところ、譜面に起こしたという逸話をもとにしたものだったけれど、以下のようにうまくいった部分とそうでない部分があった。
- 話し始めるにあたり、何から話していくかの流れができているのは良い
- 急いでテキスト起こしをしたツケで、バグっているテキストをそのまま読み上げてしまっている箇所がある (Opal への説明ミスとか)
はじめての試みっぽいバグとしてテキストを読みつつもライブ感を作りたくて、流れに乗ったタイミングでテキストから外れるというものだった。どっちつかずの弊害でした。
こういったことをやっていると、タイムキーピングが疎かになって終盤、畳み掛けるようなスピードで収めに行くことになった。結果として 25分程度というオファーのところ 25分54秒だったので、最後は編集で少しカットできないかやってみようとしたけれど、ソフトの選定や使い方を覚えるまで辿り着けず断念。これは時間の中でこなせるスキルを予め獲得しているかという経験がものをいう世界線だった (そしてそのスキルは現状持ちあわせていなかった) 。
いちおう覚えたこととして、あとで編集しやすいようにまとまりのあるスライドごとに音声を収めておくと良いという知識を得ることができた。ページ切り替えのタイミングで話しているとそのパートだけを削除したいという編集ができなくなるのが理由。
あと MacBook Pro の内蔵マイクで収録していたけれど、途中音質がガラッと変わる部分があった。機材自体は変えていないので姿勢やマイク距離が変わったなどで、音の当て方が変わっていたのではと思う。このあたり音質を担保するのであればそれようの機材を使った方が良さそう (今現在は持っていないのですが) 。
以上のような失敗経験やノウハウを得る良い機会にもなったのが今回のスライド作成だった。次回はもう少しうまくできるんじゃないかなと思っている。
RubyKaigi Takeout 自体は、リモートながら RubyKaigi 感があって良かった。収録済みの配信であるもののタイムテーブルがあったのが良い舞台装置になっていたのではと思っている。勤務先ではタイムテーブルを見る会を実施したり、当日はどちらのトラックを聞こうか悩んだりできていつもながらのアクティビティを起こすきっかけにできたのは大きかったと思う。コンテンツとしては Parser を使ったトランスパイルの話がいくつかあったり、それに伴って見慣れた S 式が出てきたりと、普段の OSS 活動で備えている特異技術とリンクしたトピックなんかはとりわけ興味深く聞いていました。
楽しかったです。RubyKaigi Takeout 2020 の関係者のみなさん、ありがとうございました。
