Active Record Oracle enhanced adapter 5.2.6 がリリースされた

Active Record Oracle enhanced adapter 5.2.6 がリリースされた。

変更点としては、RailsConf 2019 の帰りの飛行機で書き始めていた TCP keepalive について database.yml から設定可能にする機能追加となる。

github.com

database.yml に以下のように tcp_keepalive の値を false に指定することで TCP keepalive を無効にできる。

 development: &development
   adapter: oracle_enhanced
+  tcp_keepalive: false

また以下のように tcp_keepalive_time の値を指定することで TCP keepalive の時間を変更できる。

 development: &development
   adapter: oracle_enhanced
+  tcp_keepalive_time: 3000

それぞれの tcp_keepalive のデフォルト値は true で tcp_keepalive_time のデフォルト値は 600 (10分) としているため、Breaking change にならないように Oracle enhanced adapter 5.2 で導入された振る舞いは維持している。

今回 Oracle enahanced adapter 5.2 系へのバックポートなど含めて Rails/OSS パッチ会で yahonda さんに相談に乗って頂きました。いつもありがとうございます。

blog.agile.esm.co.jp

次回の Rails/OSS パッチ会は 6月6日 (木) です。

RuboCop 0.69がリリースされた

RuboCop 0.69がリリースされた。このバージョンから Ruby 2.2 以下をサポートから切っているので、サポート対象は Ruby 2.3 以上になる。

あわせて Ruby 2.2 以下のサポートを切った RuboCop Performance 1.3.0 もリリースしておいた。RuboCop RSpec も同様にサポート対象が Ruby 2.3 以上になる。

またオフトピックとなるが、公式ドキュメントとなる http://www.rubocop.org のデフォルト表示を開発版である "latest" から安定版である "stable" に変更した。これは多くの利用者は開発版ではなく安定版のドキュメントをまず読みたいであろうという pocke さんのアイデアが元になっていて、Read the Docs まわりの設定を変更したもの。流れで RuboCop の Read the Docs の管理者権限をもらっているので、何か気になる点が見つかったら RuboCop core か RuboCop JP などでお気軽にフィードバックしてください。

github.com

銀座 Rails#9 に登壇します

銀座Rails#9 @リンクアンドモチベーションに登壇します。

ginza-rails.connpass.com

RuboCop コミッターとしての観点を交えての、RuboCop 入門をテーマに話をします。

ユーザー向きのコンテンツをベースにしつつ、私が押さえている今後の RuboCop の動きや、私から見た他のコミッターや私自身が持つ思想など交えたイメージでこれからスライド作りなどする予定です。

よければ遊びに来てください。

RuboCop (>= 0.69) からRuby 2.2サポートを外した

おそらく次のリリースとなる RuboCop 0.69 のリリースで、Ruby 2.2 のサポートを外すことになった。

RuboCop の実装として safe navigation operator や squiggly heredoc など使うようにしているので、構文上も Ruby 2.2 は動かなくなる。

今回サポート対象をどうするかについては以下のイシューがベースになっていて、Ruby 2.3 は様子見をしたいので保留し Ruby 2.2 のみを外した。

github.com

加えて Ruby 2.3 に関する PR が最近来たりなどしてもいたので、しばらくサポートする見込み。

他に特筆しておく点としては Ruby 2.2 を外したことにより、以下の Cop に変更が入る。Ruby 2.2 以前をターゲットにしていた場合は Breaking change になる。

まず Layout/IndentHeredoc cop だが、Ruby 2.2 以下で Rails を有効にしている場合と Ruby 2.3 以上の場合で処理を分けていた auto_detection オプションは、今後必ず Ruby 2.3 以上ので廃止。これまで Ruby 2.3 以上の振る舞いとなっていた squiggly オプションを新たなデフォルトとした。言い換えると Active Support の String#strip_heredocRuby 2.3 以上の <<~ かの判定はなくなり、デフォルトとでは <<~ が選ばれることになる。

次にStyle/FrozenStringLiteralComment cop となるが、Ruby 2.3 以上のときのみに frozen string literal マジックコメントを有効としていた when_needed オプションは廃止して、これまで Ruby 2.3 以上の振る舞いとなっていた always オプションを新たなデフォルトとした。つまり frozen string literal マジックコメントがデフォルトで要求されるようになる。この関係で RuboCop 本体のテストコードの改修が骨だったのは裏話。

あとは流れで squiggly heredoc に関する JRuby の非互換を見つけて jruby/jruby の既存イシューにコメントしていたりした。

RuboCop Performance 1.2.0 をリリースした

RuboCop Performance 1.2.0 をリリースした。ミネアポリス時間で朝7時前だったので健康的。

RuboCop 0.68 での NodePattern への拡張にともなって、RuboCop Performance 1.1.0 までリグレッションになった以下のようなコードにおける偽陰性の修正を含んでいる。

def foo
  if /re/.match(foo, 1)
    do_something
  end
end

github.com

上記の偽陰性の修正と、それにともない RuboCop 0.68 以上を要求するようにした点が主な変更となる。

RuboCop Performance 1.2.0 とマイナーバージョンを上げた理由は、RuboCop 0.68 以上を要求するようにしたことから。これは RuboCop Performance 自体が RuboCop 0.68 で本格的に切り離されたものになることと、RuboCop 0.68 で追加された NodePattern に依存する実装になったことが理由。

GemifyされたCSVを使う

RubyKaigi 2019 で kou さんと秒速さんが話されたプレゼンで得た今日から使える tips 紹介。

https://slide.rabbit-shocker.org/authors/kou/rubykaigi-2019/

Ruby にデフォルトでバンドルされている CSV ではなく、Gemify されて独立してリリースされている新しい CSV を使うことで、業務とエクセルとCSVという三位一体のシステムを少しずつ速くできる (かもしれない) 。

単純に Gemfile に gem 'csv' を指定して bundle install をする。

# Gemfile
gem 'csv'

これによって使っている Ruby のバージョンに縛られず新しい CSV gem を使えるようになる例。

% bin/rails r 'p CSV::VERSION'
"2.4.8"

% bundle install
(snip)
Installing csv 3.1.0

% bin/rails r 'p CSV::VERSION'
"3.1.0"

以下のようなメッセージの改善があったりするので、当然ながらアプリケーションの CI がとおるなどざっとは見ておきましょう。

github.com

kou さん、秒速さん、今日から使える改善と紹介ありがとうございました。

Active Record Oracle enhanced adapter 6.0.0.rc1 がリリースされた

Rails 6.0.0.rc1 にあわせて Active Record Oracle enhanced adapter 6.0.0.rc1 がリリースされた。yahonda さんリリースありがとうございます。

github.com

今回の Oracle への ORM としての目玉は Address ORA-01795: maximum number of expressions in a list is 1000 で、SQLIN 句に 1,000 件を超えるリストを指定した場合に発生する ORA-01795 を 1,000 件ごとの OR で繋ぐことでエラーを抑制する振る舞いになる。

これによりアプリケーション側で 1,000 件より多くを渡さないようにロジックを組んだり、それを想定したコードレビューをしたり、データ量が増えるとエラーになったりといったことが発生しなくなる。このあたりたびたびパッチ会などでも相談したりしていた。

yahonda さん、kamipo さん、対応ありがとうございました。