Bundler 1.16.2 がリリースされた。個人的には 0xColby の初リリースというのも印象的 (彼は RubyKaigi 2017 で Bundler 2 の話をした Bundler のコミッター) 。
🎉🍾This was my first Bundler release! https://t.co/BcDcmVfFRH
— Colby Swandale (@0xColby) 2018年5月16日
CHANGELOG は以下。
自分もひとつ入っていて、Ruby 2.6 に向けて ERB.new を調整したもの。
Update binstub generator to use new ERB.new arity in Ruby 2.6 (@koic)
ERB.new といえば、手元のリポジトリにあってランタイムで警告がでそうなものはだいたいメンテしたと思うので、あとはリポジトリオーナーや各利用者に託します。
Issue #5887 での false positive のレポートを受けて、Lint/SplatKeywordArguments cop を削除する PR を出した。
削除にあたり、ag 'remove.*cop' CHANGELOG.md で cop を消した前歴があるか CHANGELOG.md を見たりしたりもしていた (わずかにあった) 。
削除を決めた理由は Issue にあった以下。
options = { opt1: 1, opt2: 2 }
def method1(kw_args); end
def method2(**kw_args); end
method1(**options) # This will warn in ruby 2.6 and currently warns in rubocop.
method2(**options) # This does not warn in ruby 2.6 and should not warn in rubocop.
レシーバーのメソッドの定義を辿って def method(kw_args) か def method(**kw_args) を知るといったのは、知る限りいまのメカニズムでは無理なので TKO となった。ランタイムまで行けば source_location とか使ったゴリ技とか浮かびはするので、あとはそれをどう洗練させるかになるけれど、現状の RuboCop のメカニズムでの静的解析だとどうしたものかなのだった (以前ランタイムに頼る PR を出して、あ、あ、あ、となったのを思い出したりしてた) 。
というくらい目処がつかないまま放置した disabled cop があっても良いことはないと思ったので、削除という選択肢をとったのだった。
Ginza.rb 第59回 GitLabのお宝を拝見しよう！に行った。会場はメドピアさん。
今回もイントロダクション芸人として定評の y-yagi さんが以下 Gist を用意してくれて道案内をしてくれた。いつもありがとうございます。
https://gist.github.com/y-yagi/30e62bb2b305250e5c59fb781d719d3e
個人的な GitLab の印象は、綺麗に Rails way から離れた Rails という印象だった。どういうことかというと外れるべきところには、きちんと説明が記されたドキュメントがあり、GitLab として Rails way から外れるべき選択をしたことが残されていること。それはドキュメントはリポジトリのリソースの中で完結していて、何々については何処何処を見てといったリソースの分散がない点も良さそうだった。
そんな感じで GitLab は秩序を考えながらいろいろと魔改造している感あったが、中でも印象に残ったのはデータベースのマイグレーションでダウンタイムが発生するかどうかを、マイグレーションファイルに明示するあたり。以下はひとつの実例より。
class AddTypeToLabels < ActiveRecord::Migration include Gitlab::Database::MigrationHelpers DOWNTIME = true DOWNTIME_REASON = 'Labels will not work as expected until this migration is complete.'
DOWNTIME を真にした場合は、DOWNTIME_REASON にその理由を示すようにしており、これは良さそうな拡張だと思った。
以前の Ginza.rb で Discourse を読む会があったが、(背景があるのはもちろんのこと) 作り手次第でいろいろな色がつくことを再確認しつつ面白く参加させてもらった。今回もありがとうございました。
CHANGELOG.md が溜まっていて、怒涛のマージが進むなーと感じたらリリースのシグナルとわかってきたこの頃のリリース。
自分の変更に関する1行コメント。
Rails からの輸入。
Rails 5.2 のリリースに合わせて挙がった Issue に応えたもの。
Ruby 2.6.0 向けの ERB.new のインタフェースに向けたもの。
これはいったん disabled にしてもらった方が良いかもしれない (このマージリリース日の夜は、もしかしてリリースの前兆、、、と思いながらもちょうど体調不良で寝ていたので、disabled にする対応が遅れたのだった!!1) 。
タイトルのまま。これ系は再帰で対応していて、今回も再帰を使って解決した。
LiteralInInterpolation という "foo #{123_456}" を 'foo 123456' にしようというものだが、autocorrect すると 'foo 123_456' になるなどのバグの修正をした。テストケースのバグが印象的だった。
滑り込みで入っていた部署の変更。ガード条件の後ろに空行を入れることはあっても前に入れることはないだろうという見解は変わらず、cop 名の変更はしていない。
以下 2018年3月の公式アナウンスのとおり Ruby 2.2 系列は EOL となっていることから、backport_dig のメンテナンスを終了した。
かねてからの予告通り、今月末をもって、2.2 系列のセキュリティメンテナンスならびに公式サポートは終了する予定です。
https://www.ruby-lang.org/ja/news/2018/03/28/ruby-2-2-10-released/
Ruby 2.3 以降での dig を使っていきましょう。
とちぎテストの会議05に行った。隔年開催なので前回からおよそ2年ぶり。
今年は一般講演がとおったので、「あのチーム」とは異なる体制でのテスト体制などの話を持って行った。スライドは以下。 speakerdeck.com
会場に到着した際にお弁当と一緒にもらった「うまくいったらどうなるの？」バッジは、実はとてか05自体が「うまくいったらどうなるの？」という問いかけのあったイベントだったことが最後に明かされることに繋がっていて、全体としても面白い構成様式のイベントになっていた。
パネルの際に「うまくいったらどうなるの？」はじめ、あのチームで使われている言葉について捉え方によっては相手が重圧を感じたりしないか？といった参加者からの声があったけれど、おそらく「あのチーム」ではアラートのシグナルとして村社会 (そのチーム) に馴染んだ言葉になっていて、そういった重圧は感じないのではないかなと思った。一方で他のチームがこれから導入する際には注意するポイントとして気を払っておくと良さそうと思い良い質問だった。
最後に2分の LT があって、そちらでも2分間話した。話の概要としては「あのチーム」と「自分のチーム」の違いについての1枚スライドのものだけれど、そちらは公開しない。あの場には一連の流れがあって、その流れを受けての発表スライドなので、それだけで公開することに意味はないと思うのが理由。
とてかに関して思うのは、参加してあの空気の中にいないと拾えない質というか何かがあって、まとめると2年後に予定されているとてか06もみんな参加しようということだった。
とてか05 の LT スライドも作っておこうと思っていたけれど力尽きて及ばず1回休み。
