パーフェクトRuby on Rails【増補改訂版】をレビュアー献本いただいた

パーフェクトRuby on Rails【増補改訂版】をレビュアー献本いただいた。出版おめでとうございます & 献本ありがとうございました。

パーフェクト Ruby on Rails 【増補改訂版】

以前、Ginza.rb のおりに netwillnet さんから「パ Rails の改訂版を書くにあたってレビュアーお願いできますか？」と声をいただいて、執筆パート担当の igaiga555 さんからのパスでレビュアーに加わらせていただいていた。

全体については仕事の速い tatsuoSakurai さんが書いている書評を見ていただくとして、RuboCop に関わるパートで出版後の変化について記しておこうと思う。

本編9章で rubocop -a を実行すると Style/FrozenStringLiteralComment cop によるマジックコメントが適用されるとあるのですが、RuboCop 0.87 以降では -a オプションでは適用されなくなりました。rubocop -a は安全な cop のみ自動修正するオプションという意味合いに変わったためです。

そのため安全でないとマークされている Style/FrozenStringLiteralComment cop を使った自動修正をするには rubocop -A (大文字の A ) を実行する必要があります (この変更が取り込まれたのは、おそらく脱稿して原稿が印刷所に行っているころ) 。

安全でない自動修正とは、例えば 'foo' << 'bar' のようなコードがあった場合に、frozen string リテラルのマジックコメントなしからありになると、FrozenError (can't modify frozen String) という挙動に変わりますが、このように互換性がない auto-correct になりうるものです (このケースで互換性を維持するためにはレシーバーを dup などする必要がある) 。

rubocop -a と rubocop -A について詳しくは以下のエントリを参照してください。

koic.hatenablog.com

技術を扱う書籍についてツールがアップデートされていくのは常ですが、レビュー時点ではこの変更への PR 自体も出ていなかったので 1ヶ月くらい時期がずれていれば ...といったライブラリアップデートに関する補完となります。

本書に戻ると Rails 6.0 対応で Docker や GitHub Actions にも触れられているので、これからの業務への知識のステップアップを目指す方などに適した一冊になるのではと思います。改めて執筆お疲れ様でした！

rubocop -a と rubocop -A オプション

RuboCop 0.87 がリリースされた。

github.com

今回の目玉は rubocop -a コマンドラインオプションへの非互換変更となる。

これまでは rubocop -a オプション (rubocop --auto-correct も同義) を使った場合に、自動修正を備えたすべての Cop が適用されたていた。そのため Safe でないと見なされる Cop の自動修正も適用されるというのがデフォルトの振る舞いだった。

今回のリリースからは rubocop -a は Safe とマークされている Cop のみが自動修正の対象となり、従来どおり自動修正を備えた Unsafe を含むすべての Cop を適用する場合は rubocop -A (rubocop --auto-correct-all) を実行することになる。つまり RuboCop 0.59 で導入された rubocop --safe-auto-correct が自動修正のデフォルトの振る舞いになる (そして rubocop --safe-auto-correct オプション自体は非推奨になりました) 。

RuboCop に導入されている Safe というメタデータについては過去の日記を参照してください。

koic.hatenablog.com

GitHubの新デザインを先取りして使う

GitHub がユーザー全体のデザインを変えるより前に、Feature preview を使うと先駆けで新デザインを使うことができる。

先行して新デザインが使えるときは、以下の Feature preview に通知がきているので、それを有効にする。

過去に自分が見たプレビュー機能には、"Design updates" と "Repository refresh" があった。

"Design updates" はユーザープロフィールページを新デザインにするものだった。

I've enabled "Design updates", a feature preview on GitHub. pic.twitter.com/DeUYhbldab

— Koichi ITO (@koic) 2020年6月9日

"Repository refresh" はリポジトリのトップページを新デザインにするものだった。

I've enabled "Repository refresh", a feature preview on GitHub. pic.twitter.com/xNVRjtY3qT

— Koichi ITO (@koic) 2020年6月18日

それぞれ "Give feedback" のリンクからフィードバックできるようになっている。

"Repository refresh" について、リポジトリのトップに表示されている最新のコミットで CI の結果 (✔︎or❌) が分からくなっていて不便だったのを以下の画像添付と一緒に GitHub にフィードバックしていた (たしか昨日 (2020年6月23日) か一昨日くらいのこと) 。

この日記を書いている 2020年6月24日現在、リポジトリのトップで master ブランチへのマージ後の最新のコミットへの CI の結果がわかるようになっていた。GitHub への自分のフィードバックか、誰か他の人も同一のフィードバックをしていたかは分からないが、便利になって良かった (というかもともとのデザインで見れていたものなので、ないと不便だった) 。

いまは "Feature preview" が空になっているので、また次のプレビューが楽しみですね。

GitHub が落ちた時に復旧情報を受け取る

Twitter のタイムラインが賑わう GitHub のサービスダウンに関する tip です。

GItHub のサービスの状態については https://status.github.com/ で確認できます。

さらに右上の Subscribe から復旧状態をメールなどで通知を受け取ることができます。

たとえばメール通知にすると、復旧したらこんな感じでメールが来ます。

実践的には GitHub に繋がらなければ繋がらないでできる仕事にスイッチして進めている間にだいたい復旧しているので、UX 最高とまではいかなかったりですが参考までに。

pluck.uniqをdistinct.pluckに置換する

先日リリースした RuboCop Rails 2.6.0 でバグフィックスされた Rails/UniqBeforePluck についての話。

この Cop は RuboCop Rails に細かな部署があるなら、スタイルではなくパフォーマンスに属するもの。RDBMS から結果を取得したあとに Ruby の uniq で一意にするのではなく、DISTINCT を使ったクエリを RDBMS に発行してあらかじめ一意になっている結果を得るもの。

デフォルトで以下のような検出を行う。

# bad
Model.pluck(:foo).uniq

# good
Model.distinct.pluck(:foo)

なお、この Rails/UniqBeforePluck cop はバグ修正された RuboCop Rails 2.6 以上でないと distinct に置換すべきところ Rails 5.0 で非推奨にされた uniq にオートコレクトしてしまう問題がある。

github.com

いまメンテナンスされている Rails 5.2, Rails 6.0 なんかでは NoMethodError: undefined methoduniq'` エラーになるので自動修正を使うときは RuboCop Rails を最新の 2.6.0 に更新してください。

なお Rails/UniqBeforePluck は EnforcedStyle のオプションを持っていて、デフォルトの EnforcedStyle: conservative は偽陰性が起きえて、EnforcedStyle: aggressive は偽陽性が起きうるという。常時はデフォルトの EnforcedStyle: conservative のままとしている。パッチ会あたりでも聞いてみたいところ。

github.com あとは悲しいかな、誤検知をもちうる Cop のため git grep 'pluck.*uniq' なんかで置き換えが可能かどうかを見て判定というのが最初の導入として確実。まずは grep で対応した後に EnforcedStyle: conservative あたりで検出を行うというのが、まさに consavative なやり方になるだろう。型があれば誤検知なく EnforcedStyle: conservative が使えそうで未来の処理系に期待される。

そして、Rails/UniqBeforePluck cop は歴史的経緯ですでに名前が実体にあっていないので、RuboCop Rails 3.0 あたりでリネームされる予定です。

追記

同僚の kunitoo より例えば MySQL の collation によって、RDBMS によっては非互換が生まれる可能性があるかもという指摘があった。たしかに現状の実装だとオートコレクトの unsafe を検討できるかもしれない。

SSDが擦り切れる前にルーターとHDDを導入した

2013 年モデルの MacBook Pro を開発機に使っていて、一説によると寿命の目安が5年くらいとも言われている SSD がアディショナルタイムに突入して数年経過している。多くの作業中ブランチを含む手元の OSS リポジトリやら環境が飛ぶと立ち直るのがつらい状況に対し、重い腰をあげて Time Machine でバックアップをとるための機材を購入した。

ちょっと前までであれば Time Capsule を使えば無線 LAN ルーター + NAS を兼ねて便利そうだったけれど、すでに生産終了のアイテムになっているため寿命がある前提の外部ストレージとしては選択肢から外した。

結果的には ASUS の無線 LAN ルーターと BUFFALO の外付け HDD の組み合わせにした。バックアップのため有線で外付け HDD を繋げたりする面倒はしたくない性格なのと今後の拡張性から無線 LAN ルーターを合わせて導入している。

ASUS WiFi 無線LAN ルーター RT-AC68U 11ac デュアルバンド AC1900 1300+600Mbps 最大18台 4LDK 3階建 【 iPhone X / XS 対応 】

信頼できる筋の人たちによる ASUS RT-AC68U への絶賛帯はルーター選定への後押しになっている。この場を借りて感謝。

• TimeCapsuleが生産終了になったので、Wifiルーター + ネットワークHDD（NAS）に移行しました - give IT a try
• 無線ルータをASUS RT-AC68U に変えたら色々改善された - memo_md

最終的に、この無線 LAN ルーターは Time Machine の USB アプリが入っているので今回の目的と相性が良いだろうというのが決め手となった。

外部ストレージについては、第一の用途が保険的なバックアップストレージなので今回は速度より価格面をとって SSD ではなく安価な HDD としたが、SSD の体験を知っていると HDD の IO は結構ストレスになったりもする。いずれも寿命のあるものながら、日常の体験を考えて SSD にしておくべきだったかもしれない。

BUFFALO USB3.1(Gen1)/3.0/2.0対応 PC/家電対応 外付けHDD 3TB ブラック HD-LC3.0U3-BKF

また保険的にはクラウドストレージが一番なんだろうけれど、現在 COVID-19 の社会的影響で滅多に外出していない状態で、その買い物にも PC を持って行くことなんか絶無なので今回の構成にしている。例えば iCould 2TB でも現在の状況での保険用途に限れば支出がペイしないかもという判断は断念した要因のひとつ。

一方でそうそうあることではないとは思っているが、MBP の内蔵 SSD と外付けの HDD が同時になくなると目も当てられないので、物理デバイスだとしてもデュアル HDD あるいは SSD にそのうち装備を強化したいところ。いずれにせよ保険にいくら掛けられるかということになる。

そして手元に届いた後はさっそくバックアップを行なったわけだが、Power Nap を ON にしていなかったのが原因か sparsebundle が壊れているらしく「信頼性を向上するために、Time Machineは新規バックアップを作成する必要があります」で何度か半日は掛かる初期バックアップ削除からやり直しの憂き目に遭った。キーワードとして書き記しておく。

---

無限にやることがある OSS への活動に対して、土台となるこういったインフラ機材についても GitHub Sponsors でまかなったり選択肢を増やせるようシフトできると良いなと思っていて OSS 活動へのスポンサーを募集しています。

github.com

もちろん心意気にあわせてモチベーションもブーストされます :-)

`Layout/LineLength` のデフォルトを 120 にした

RuboCop の LineLength のデフォルトが 80 ではつらいという声はずっと聞いていて、そもそも RuboCop にパッチを送り始めた頃は、いつかこの変更をするのが目標のひとつだった。

今回 3年半越しに実現することができた。現在の最新版の RuboCop 0.84.0 に適用済み。

github.com

OSS で年月をかけた粘り強い振る舞いは kamipo さんから学んだことで、RangeError にまつわる rails/rails#30000 もそこに到るまでを含めてコントリビュータ時代から何年か掛けていると聞いている。

RuboCop リポジトリ自体の方では、その後にコアメンバーからエディタを縦分割した際に 120 だと厳しいという声があり、RuboCop リポジトリ自体の設定は 100 になったというエピソードがある (デフォルトの設定は 120 で維持されています) 。RuboCop 自体も無数にあるリポジトリのひとつなので、アクティブメンテナーが過ごしやすい設定に歩み寄った形。

実際のところ 80 から 120 になると、本来名付けたかった名前への省略や、本質的に不必要な行の折り返しなんかを考える yak shaving な手間が減るという効能を実感しているので、80 では厳しいと思っていた人には良いのではと思う。従来の 80 がお気に入りの場合は Layout/LineLength を 80 にセットしてください。