Layout/EmptyCommentの実装を再開しておいた

ある実装者のアクティビティがなくてクローズされていた Layout/EmptyComment への実装を再開しておいた。着手し始めていた (元イシューとクローズされていた PR でのやり取りの理解が主) のは今週の木曜くらいで週末に PR まで持って行こうと思っていたところで今日の夕方が終わるくらいに実装の本腰を入れて、そのまま日曜日が残り30分で終わるあたりで PR できて一応予定どおり。

github.com

この Cop が取り締まることについて自分が困ったことは最近はないけれど、イシューを見た感じまあありそうだということと、ソースコードコメントまわりのノードの処理について興味があったことから着手していた。

この実装で一番時間が掛かった気がするのが以下 autocorrect の実装で、コメント行を一行まるっと消すにはどうしたものかというあたり RangeHelp#range_by_whole_lines を見つけるまでの時間だった気がする。

def autocorrect(node)
  lambda do |corrector|
    range = range_by_whole_lines(node.loc.expression,
                                 include_final_newline: true)

    corrector.remove(range)
  end
end

こういったありがちなのを地味に実装したくないと思っていたので、見つけられて良かった。

rubocop-rails 1.2.1 がリリースされた

昨日の日記の続きになるが、先日 Rails に適用されている RuboCop のルールを Gem に切り出そうと思って、作るなら名前は rubocop-rspec に倣って rubocop-rails が良いだろうと RubyGems.org を見たらすでにご近所で作られていた。

github.com

先日 Rails に追加した設定を PR にして送ったところ、即日マージされて 1.2.1 がリリースされた。自分が Pull Request を出すときは、アクティビティ関係なく仕事で使っていてパッチを送らないとにっちも行かない送り先を別にすると、きちんとアクティビティがあるかといった点が最初の基準のひとつになりうるので、こういったスピード感は分かりやすくモチベーションを上げてくれてありがたい。

もともと Gem に切り出そうと思ったきっかけは、Rails のコーディングスタイルそのままというよりは、それを基準に差分を設定していくといった PoC を試みようと思ったのがきっかけ。余力があればどこかしらで試みたい。

rails/railsが設定しているEnforcedStyleAlignWith: variableへのメモ

rails/rails での var = if ... else ... end などに関する autocorrect がうまく働いていないという話から、Layout/EndAlignment などの設定を追加した PR を先日出していた。

github.com

rails/rails では EnforcedStyleAlignWith: variable を有効にしているので、以下が期待されたものになるが rails/rails に送られている PR のコードがそうなっていないときに offense が出なかったり、autocorrect がうまく働いていなかったりというあたりを改善した設定になる。

var = if cond
  foo
else
  bar
end

やりとりにあるとおり、var = case ... when ... else ... end まわりを中心とした autocorrect で動きが微妙なあたりは RuboCop 自体への変更が必要そうな継続課題として追い追い見ていく。RuboCop 自体は Ruby Style Guide に準じたデフォルト EnforcedStyleAlignWith: keyword であるため、オルタナティブの弱点をついていたのではと思っている。

スタイルは最終的に個々人の趣味でもあるので、RuboCop のイシューで見ている優先順位は低いものの rails/rails でのスタイルということと、自分も rails/rails 同様 variable にアラインメントするスタイルが好みというのが、他のやりたいこととの優先順位の中のどこかで引き続き見てみようという動機。

Oracle enhanced adapter 5.2でcurosr_sharingのデフォルトがexactになる

Rails 5.2 に対応する Oracle enhanced adapter から cursor_sharing のデフォルトが force から Oracle デフォルトの exact に変更になる (厳密に言うと config/database.yml への cursor_sharing の設定がない場合の force への変更がなくなるため、Oracle のデフォルトの exact が尊重されるようになる) 。

github.com

Rails 5.1 までの Oracle enhanced adapter で同様の挙動にしておきたい場合は、config/database.yml に以下のような設定をしておくと良いだろう。

 default: &default
+  cursor_sharing: exact

追記: yahonda さんから Rails 5.1 以下では基本的にオススメされない旨のコメントをいただいたため、そちらも参照のこと。

設定値については Oracle Databaseリファレンスを参照のこと。 https://docs.oracle.com/cd/E60665_01/db112/REFRN/initparams044.htm

ローカルでRuboCopを実行するときにgitの差分だけ実行する

RuboCop 全体で実行すると遅いから、git でローカルの差分があるものだけを実行したいというイシューが挙がっていた。

github.com

シェル自体の書き方はいくつかあると思うが、このイシューでは git diff --name-only と組み合わせて、以下のようにすると良いといった回答をした。

% git diff --name-only | xargs rubocop

解決したい問題についてなるほどーと思ったのと、第一感で *NIX っぽく役割ごとのコマンドを組み合わせる方が合理的だと思い、RuboCop 自体にオプションを足すのは pocke さんが付け加えてくれたようにそのアプローチはないかなと思ったりしながらコメントしていたりした。

Ginza.rb 第55回

『Ginza.rb 第55回 もうすぐやってくる!Rails5.2を見ておこう』に行った。会場はみんなのウェディングさん。

ginzarb.doorkeeper.jp

Rails 5.2 の Major Features について y-yagi さんがまとめてくれたスライドを元に進行していた。

https://y-yagi.github.io/presen_rails_5_2/#/

以下、Rails 5.2 (beta2 時点) の Major Features について個人的な所感。

Active Storage

例えば既知のファイルアップローダーである CareerWave なんかと比べて、不特定多数のユーザーからのファイルアップロードを受け付けるにはバリデーションがないあたりで実戦投入が難しそう。クラウドサービスへのアップロードが Rails 本体でサポートされているというのは便利だと思うので、今後使って見た人がどうフィードバックしていくかの Rails 6.0 での姿に期待している。

Redis Cache Store

Memcached でも良いのではという考えもひとつあるとは思うけれど、Redis という選択肢が標準でサポートされるようになるのは良い話で Active Storage よりも Rails 5.2 で使われる機能になりそうな予感がした。

HTTP/2 Early Hints

HTTP ステータス 103 について知識を増やすことができた。会場では Early Hints についての挙動に違和感がある場合は HTTP 1 脳に慣れ親しんでいて HTTP 2 脳ができていないのではという見解が面白かった。

あとこの機能自体 Puma でないと効かないといったあたりから、Puma で本番運用している人がどれくらいいるか最近のアプリケーションサーバー事情が気になったところ、Unicorn と 1/3 から半々くらいの割り合いで結構いたのが印象的だった。

CSP

Rails 5.2 に向けて rails app:update した際に、initializers に追加される CSP のデフォルト設定は厳しいのでアップグレードで動きがあやしい場合に見てみるポイントとして知ることができたのは収穫 (知っている知らない問題は知っているとはやい) 。 y-yagi さんのスライド 22 ページあたりとあわせて見ておきたいイシュー。

github.com

Credentials

Rails 5.1 で Encrypt Secrets を使っている場合は、移行していくと良さそう。そちらはゆるく Deprecate になっていくというあたりのアプローチの仕方がセンスいいなと思った。

Ruby25にRuby貢献者枠で申し込んだ

元々は勤務先のスポンサー枠で参加する予定だったところ、スポンサーチケットが枯渇したことから Ruby 貢献者枠で申し込んだ。

申し込み時の貢献内容のテキストは以下。

Ruby 2.3 で導入された squiggly heredoc についての irb へのパッチを送りました。また Ruby 2.3 で導入された Frozen String Literal をおそらく現在最も Ruby が使われてる契機になる Rails に対して何人かの Rails コントリビュータとともに Rails 5.2 向けに導入しました。

Ruby 2.4 へのアップグレードに際して、Integer Unification による警告の抑制を中心に 30 以上の Gem リポジトリに PR を送り、そのうち多くが取り込まれました。

Rails が台頭して Ruby が業務で取り扱われるようになってきた 2007年に『Web 2.0ビギナーズバイブル』という書籍 (絶版) に PHP, Perl, Python といった他の Lightweight Language とともに RubyRails の章を寄稿しました。

なんというか日頃が Rails を介しての Ruby の利用ということから、Rails を介したエコシステム色ある One of them な内容という感じではある。