銀座Rails#2

銀座Rails#2に参加した。Ginza.rb #64 以来、今週2回目の銀座。

ginza-rails.connpass.com

勉強会ソムリエとしても鳴らしている平野さんこと新沼カルパスさんの発表を聞くのが初めてで、以下スライドにあるカルパスさんの話を興味深く聞いていた。

speakerdeck.com

スライドにあるように、第I部 と第II部の二部構成になっていて、理論と実践例から構成されておりイベント運営の知見の塊になっているので、これからイベントを検討している人は一読して開催の流れをイメージしてから行うと良いと思う。

またイベントには主催者指名型と公募型、それのハイブリッドがあるなど、それぞれどういった特色があるかなどの知識が体系立てられていて、勉強会ソムリエが体系立てた参考書としても楽しめると思う。募集の際にはサイトオープン時に募集を開始する。サイトに2度来ると思わないように、スタートダッシュで決まる、募集開始は週明けの午前中といった、Web ディレクター視点っぽい募集の観点が入っていたのも面白い点だった。

特に第II部の実践例が重なることで全体としても、Rails Developers Meetup 自体の紹介と来年の Railsdm 2019 の事前アナウンスというメタ構成になっているので、Railsdm 自体をスタートした動機から、如何に振り返りつつも振り返らず継続しているかのコツなど記されている。

5分の LT でのスピード感で、20分走りきって、それでいて聞き取りやすいプレゼンで聞いていて楽しかったです。ありがとうございました & 関係者のみなさんありがとうございました。

Ginza.rb 第64回

『Ginza.rb 第64回 Stimulusは新たな刺激となりうるか?』に行った。会場は銀座のメドピアさん。

ginzarb.doorkeeper.jp

今回は willnet さんがイントロダクション芸人として Stimulus について紹介をしてくれた。

github.com

Stimulus の Controller と HTML へのバインディング、物理 JS ファイルとといったものが規約で繋がるという Basecamp 製っぽい JS フレームワーク。 その先にはサーバーサイド JS フレームワーク x Turbolinks という、クライアントサイド JS と異なるアプローチでの UX 改善のひとつの姿が見れそうな印象を受けた (Turbolinks への再評価的な) 。

また先日公開された Action Text なんかの話も汲まれつつ Ginza っぽい考察の入ったおもしろい会でした。今回 willnet さんのまとめのおかげで Stimulus についてどういったものかだいたいわかった気がしました。ありがとうございました。

RuboCopで導入される`--safe`オプションと`--safe-auto-correct`オプション

次の RuboCop (> 0.59) のリリースで、RuboCop 1.0 に向けた --safe オプションと --safe-auto-correct オプションが導入される。

% rubocop --help | grep safe
        --safe                       Run only safe cops.
        --safe-auto-correct          Run auto-correct only when it's safe.

これらは RuboCop 1.0 に向けたオプションであり、現状は以下のような振る舞いをする。

--safe オプション

rubocop --safe とオプション付きで実行すると以下のように RuboCop の config/default.yml なりアプリケーションの .rubocop.yml なんかで Safe: false となる Cop は適用対象外となる (厳密にいうと Enable が true かつ Safe も true の Cop が対象になる) 。

 Performance/InefficientHashSearch:
   Description: 'Use `key?` or `value?` instead of `keys.include?` or `values.include?`'
   Reference: 'https://github.com/JuanitoFatas/fast-ruby#hashkey-instead-of-hashkeysinclude-code'
   Enabled: true
   VersionAdded: 0.56
+  Safe: false

YAMLSafe: false の指定がなければデフォルトで Safe: true として扱われる。

なお、--safe オプションなしでの rubocop コマンド実行はこれまでどおり基本的に Enable :false でないものが対象。

現状で偽陽性を回避しづらいケースがある場合に Safe: false となっているようで、これまで Enabled: false だと Cop が持つスタイルへの音楽性の違いを無効にするものか、 Cop の不具合を回避するものなのか、そもそも避けづらい偽陽性を回避したいのか不明瞭など混在した根拠が分類された形になった、、、と思う (なお新たな Cop は不具合を持っている可能性を考慮して無効にしたいという意図のメタデータrubocop-hq/rubocop#5979 で検討されているところ) 。

--safe-auto-correct オプション

rubocop --safe-auto-correct とオプション付きで実行すると以下のような SafeAutoCorrect: false となっている Cop を対象外に auto-correct する。

 Style/InfiniteLoop:
   Description: 'Use Kernel#loop for infinite loops.'
   StyleGuide: '#infinite-loop'
   Enabled: true
   VersionAdded: 0.26
+  SafeAutoCorrect: false

YAMLSafeAutoCorrect: false の指定がなければデフォルトで SafeAutoCorrect: true として扱われる。

なお、--safe-auto-correct オプションは --auto-correct オプションのより安全なオプションということで、AutoCorrect: false はそもそも auto-correct 対象外となっているうえで、AutoCorrect: false の指定がない (デフォルトで AutoCorrect: true 扱い) 場合でも SafeAutoCorrect: false のものは安全とみなさないといったオプションとなる。

現状だと RuboCop の config/default.yml で AutoCorrect: false の Cop に加えて、Security/YAMLLoad cop と Style/InfiniteLoop cop ならびに Style/SpecialGlobalVars cop といった、auto-correct で破壊的変更をしてしまうレポートが挙げられてたり回避が難しそうな Cop が対象になっているもよう。


これらのオプション追加に関する PR は以下なので、実装に興味があればそちらを読まれたい。

github.com

また config/default.yml には、Cop が導入されたバージョン、変更されたバージョン、削除されたバージョンといったメタデータも取り込まれており、これらもいずれ振る舞いに関与してくることになると思う。このあたりのメンテナンスについて不明瞭な点があるので、あとで開発者向けにも明らかにしていきたいと思う。

github.com

一回休み

📝Ruby における -@#freeze でのユーザーレベルでの挙動の違いのエッジケースをハートビートで教えてもらったものの、再現するための方法を忘れて一回休み。String interpolation が関わっている話だったような、、、