- 作者: 荒木飛呂彦
- 出版社/メーカー: 集英社
- 発売日: 2018/10/19
- メディア: コミック
- この商品を含むブログ (1件) を見る
銀座Rails#2
銀座Rails#2に参加した。Ginza.rb #64 以来、今週2回目の銀座。
勉強会ソムリエとしても鳴らしている平野さんこと新沼カルパスさんの発表を聞くのが初めてで、以下スライドにあるカルパスさんの話を興味深く聞いていた。
スライドにあるように、第I部 と第II部の二部構成になっていて、理論と実践例から構成されておりイベント運営の知見の塊になっているので、これからイベントを検討している人は一読して開催の流れをイメージしてから行うと良いと思う。
またイベントには主催者指名型と公募型、それのハイブリッドがあるなど、それぞれどういった特色があるかなどの知識が体系立てられていて、勉強会ソムリエが体系立てた参考書としても楽しめると思う。募集の際にはサイトオープン時に募集を開始する。サイトに2度来ると思わないように、スタートダッシュで決まる、募集開始は週明けの午前中といった、Web ディレクター視点っぽい募集の観点が入っていたのも面白い点だった。
特に第II部の実践例が重なることで全体としても、Rails Developers Meetup 自体の紹介と来年の Railsdm 2019 の事前アナウンスというメタ構成になっているので、Railsdm 自体をスタートした動機から、如何に振り返りつつも振り返らず継続しているかのコツなど記されている。
5分の LT でのスピード感で、20分走りきって、それでいて聞き取りやすいプレゼンで聞いていて楽しかったです。ありがとうございました & 関係者のみなさんありがとうございました。
1回休み
体調がいまいちでお仕事含めて1回休み。
Ginza.rb 第64回
『Ginza.rb 第64回 Stimulusは新たな刺激となりうるか?』に行った。会場は銀座のメドピアさん。
今回は willnet さんがイントロダクション芸人として Stimulus について紹介をしてくれた。
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
YAML に Safe: 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
YAML に SafeAutoCorrect: 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 は以下なので、実装に興味があればそちらを読まれたい。
また config/default.yml には、Cop が導入されたバージョン、変更されたバージョン、削除されたバージョンといったメタデータも取り込まれており、これらもいずれ振る舞いに関与してくることになると思う。このあたりのメンテナンスについて不明瞭な点があるので、あとで開発者向けにも明らかにしていきたいと思う。
1回休み
SAO の新作を観賞しつつ一回休み。