Rails 7.2 で rails new した際に搭載される rubocop-rails-omakase について、それがどのようなもので、どのように使うことを期待されているかを書き記しておきます。 github.com rubocop-rails-omakase は DHH が著者となる Ruby コーディングスタイルルールです。 一次情報はあくまで作者である DHH 発信のものとしてもらいたいですが、私自身も rubocop-rails-omakase や Rails 7.2 の RuboCop 関連機能にコントリビューションしていることもあり、比較的オリジンに近いことを述べることができると思います。また RuboCop のコミッターをしているため、たぶん RuboCop の世界にちょっと詳しい方でしょう。 とはいえ、いろいろな考え方がある領域であることも承知しているため、ひとつの考

Gemfile での Ruby バージョンの指定を、値の直書きではなく .ruby-version からの読み込みに変更する設定です。 https://github.com/rubygems/rubygems/pull/6876 例えば、Rails アプリケーションなんかで Gemfile に .ruby-version と同じ 3.3.0 を指定しているようであれば、以下のように記述できます。 -ruby '3.3.0' +ruby file: '.ruby-version' asdf に類するものを使っているようであれば、ruby file: '.tool-versions' と記します。 https://github.com/rubygems/rubygems/pull/6898 この設定によって Ruby のアップデート時のバージョンの更新ポイントを減らすことができます。 なお、古

タイトルのとおり。RuboCop 1.53 で LSP (言語サーバー) を標準搭載しました。 最初に3行まとめを書いておきます。 RuboCop を使っているけれど LSP を使っていない場合は、高速なリアルタイム性で開発体験が変わると思います。速い！ VS Code ユーザーを使っている方は、後述する vscode-rubocop という VS Code 拡張をインストールすれば OK です。 Emacs や Vi などのユーザーは、LSP クライアントの設定で rubocop --lsp を起動するように LSP 設定してください (VS Code では不要) 。 公式の使い方としては以下のドキュメントを更新していくことになるものの、実装者が自分なのでこちらに軽く書き記します。 docs.rubocop.org rubocop --lsp コマンドは直接ユーザーが手動実行するものでは

RuboCop 1.0 がリリースされた。 github.com 自分が最初にリリースを行った 0.93.1 が RuboCop 1.0 より前の最後のリリースになったというのも感慨深いものがあるけれど、さておきついに 1.0 になった。 よい節目なので RuboCop 1.0 と周辺に関するエントリを書いておこうと思う。 0.93.1 までアップグレードしている人への主な変更 ここまでアップグレードしている人は、1.0 に向けたマイルストーンを達成したひととおりの機能を手に入れています。0.93.1 から 1.0 での主な変更点は以下です。 デフォルトで pending だったコアの Cop がすべてデフォルトで有効になった。DidabledByDefault: true などしているのでなければ、これが一番ユーザーインパクトのある変更だと思う。なお、今後 1 系で追加される Cop は

Ruby 3.0 に向けた Ruby 2.7 と Rails の状況がめまぐるしく変わっているようなので、現在持っている知識のスナップショットを書き残しておきます。 Rails 6.0 系と Ruby 2.7 系 昨日、Matz によって今後リリースされる Ruby 2.7.2 でキーワード引数の分離への警告出力が Ruby 本体側で取りやめになるだろう旨の投稿が Rails の Discuss フォーラムにありました。 discuss.rubyonrails.org これにより以下の組み合わせでは、キーワード引数の分離への警告が出なくなる見通しが考えられます。 Rails 6.0.3 以上と Ruby 2.7 系 Rails 6.0.2.2 までの Rails 6 系であれば Ruby 2.7.2 以上 というか警告が抑制される場合の Ruby 2.7.2 はジョーカーなので、Rails

先日のパッチ会で kamipo さんにもらったアドバイスを書き残しておく。 TL;DR としては表題そのまま。キーワード引数の分離への対応にRuby 2.8.0-devを使うというもの。 2.8.0-devを使えばイージーモードだけど2.7.0縛りプレイだと常人にはクリア不能のむずかしさ https://t.co/tpJGTARwAc— Ryuta Kamizono (@kamipo) 2020年1月24日 Ruby 2.7.0 を使ってキーワード引数の分離への警告のみでそれを抑制しようとする場合は、スーパーハードモードルビーとパッチ会で呼ばれた変更箇所の特定が難しいケースになる場合がある。 スーパーハードモード (Ruby 2.7.0) Ruby 3.0 に向けてキーワード引数の分離が必要になる場合は、Ruby 2.7.0 を使うと以下のような警告が表示される。 % ruby -v ru

先日、神速さんのエントリを見てあとで書こうと思ったもの。 表題ママだけれど、Ruby / Rails の企業として新卒氏が入社した後にウォッチするように伝えているもの。もちろん流量も結構なものなので実際にどの程度ウォッチしているかは本人に委ねている。自分も全部は見れていない。メールでのタイトルか送信者 (PR や Issue を出した人) で興味を引かれたものが基準。 Rails 研修での Rails Tutorial の流れで、upstream とそれに近い情報源を伝えている。特に y-yagi さんのブログは、子供の頃に読み始めた新聞と同じで最初は分からなくても読み続けているうちに分かることが増えてくるので継続するのが力になることと共に伝えている。 GitHub 上のリポジトリ https://github.com/rails/rails ... ruby/ruby のリポジトリと一緒

主催の平野さんから登壇依頼のメールをもらって、二つ返事で回答させてもらったのがはじまり。オファーをもらったときに「育成をテーマに」と言われていたので、主題に悩むことなくストーリーづくりを進めることができた。 rails-developers-meetup.connpass.com 当日のスライドは以下。ここ数年行なっている育成についてまとめるいい機会になったと思う。熱が入りすぎて作り込み過ぎてしまい30分枠のところ40分くらい話させてもらって恐縮でした (るりまへのパッチの話など諸々を結構割愛したけれど、それでも溢れてしまった) 。 Stairway to The Pragmatic Rails Programmer from Koichi ITO www.slideshare.net 余談だけど、英語タイトル『Stairway to The Pragmatic Rails Program

コミットメッセージには、変更に対する「なぜ」を書く。 週末の余暇のうちに以下のツイートについてもう少しテキスト化しておく。 「コメント対応」というコミットメッセージへの指摘がめんどうなので、クライアントサイドでの git hook を用意した。配置を求めるのがなんだけど。 https://t.co/rbpS0DF2Cw— Koichi ITO (@koic) November 14, 2016 Git など使うことで、ソースコードへの変更理由について、5W1H に沿った変更履歴を知ることができることが理想。 「いつ (When) 」コードに対していつ変更を加えたのかはタイムスタンプを見れば分かる 「どこで (Where) 」コードに対して何を変更を加えたのかはリソース (file/dir) 名で分かる 「誰が (Who) 」コードに対して誰が変更を加えたのかは author を見れば分かる

YJIT の Rust 実装がマージされました。いまのところ今年の Shopify からの代表作ではと見ています (YJIT 自体は Ruby 3.1 で C 実装導入されている機能です) 。 github.com そういうわけで、現在の Ruby 3.2.0dev で YJIT を有効にする場合は、Rust の処理系 (1.60.0 1.58.1 以上) が必要になります。Rust のインストールに使う rustup については以下の公式ページなどを参照してください。 www.rust-lang.org YJIT はデフォルトではビルドされません (なので YJIT を使わないビルドであれば Rust 処理系は不要です) 。 デフォルトの YJIT なしの Ruby をビルドしている場合は --yjit オプションを渡しても、ruby: warning: Ruby was built w

スローテスト対策への熱が再燃してきていたので、Ruby関西 勉強会で以前に使ったスライドをベースにオンライン社内勉強会を行った。 スローテスト刑事 (デカ) from Koichi ITO www.slideshare.net やっぱりどのプロジェクトでも Feature テストが Rails アプリケーション開発でのスローテストの要因になっていることが多いようで、このあたりミドルウェアレベルでスピードアップするようなエポックメイキングなソリューションが誕生することを願っている (他力本願) 。 最後は「スローテスト対策への銀の弾丸はないけれど、金の弾丸はある」というので締め括った🍵

パッチ会や地域 Ruby コミュニティなどで集めた知見を元に、勤務先の永和システムマネジメントなんかで度々話している表題についてテキスト化しておく。 TL;DR Ruby 2.8.0 の開発が始まっているが、それは 2020 年のどこかで Ruby 3.0 になるらしい Ruby 3.0 ではキーワード引数 (以下 kwargs) の分離という破壊的変更があり、Ruby 2.7 系は事実上の移行パスバージョン的な位置付けになるだろう 2020年1月8日の現時点では、Ruby 2.7 の kwargs の分離警告について対応された安定版の Rails はなく、周辺 Gem も WIP なので OSS エコシステムに参加していくと良い 2.8.0 (tentative; to be 3.0.0) development has started 2019年の ruby/ruby での matz

Nokogiri が 1.11.0 からプリコンパイル済みで配布される (らしい) 。 このエントリを書いている時点での Nokogiri のプレリリースバージョンは 1.11.0.rc3 なので、大きな問題がなければ近日リリースの Nokogiri からという少し先取りの話になる。 おや？となったツイートは以下。 On a more serious note, we're REALLY close to shipping precompiled native gems.https://t.co/tKcuym2UqQ— mike dalessio (@flavorjones) 2020年10月8日 後述するイシューに詳しくは記載されていますが、Linux だけではなく macOS にも対応しているらしい。 早速手元の macOS で見てみることにする。 % time gem install