Ginza.rb 第87回 - koicの日記
『Ginza.rb 第87回 - Ruby 3.4について学ぶぞ』に参加した。会場はメドピアさん。今月もありがとうございます。 ginzarb.connpass.com 当日は、Ruby 3.4.0 のリリース記事をベースに willnet さんのファシリテーションによる Ruby 3.4 へのアップデートが特集された。 www.ruby-lang.org 中でも it ブロックパラメータと、chilled string まわりそれぞれに関連する参加者への問いかけは、RuboCop メンテナーという自身の側面への参考になったりした。あくまで今回の参加者の傾向として、it 以前の numbered block parameter が思いのほか使われていたようなのと、frozen string literal magic comment も概ね付けるようだった。 前者の it 構文については、
RubyWorld Conference 2024 で登壇した - koicの日記
去年の RubyWorld Conference 2023 会期後の松江の飲み屋で、ko1 さんからプロポーザル提出のお声掛けを頂いたのが始まり。結果として採択して頂いた話が今回。プロポーザルがとおったあとに快諾頂いたフィヨルドさんにも改めて感謝します。 当日のスライドは以下。動画もどこかのタイミングで公式から配信されると思います。 発表について 日中の仕事からのカットということで、採用と育成をテーマにしてみました。フィヨルドブートキャンプさんというスクール視点のお話はパブリックスピーキングとしても聞いていたものの、受け入れる側の受け入れをテーマにした話というのは大きめのカンファレンスで耳にしてこなかったので、今回まとめてみた形です。 また本編でも取り上げたコミュニティのフラクタルさは、どこかの懇親会で町田さんたちと話した際に話したこと、「町田占い」はフィヨルド卒業生の同僚に聞いたことと、
rubocop-rails-omakaseとは何か？ - koicの日記
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から読む - koicの日記
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.5で導入された`SuggestExtensions`パラメータ - koicの日記
RuboCop 1.5で導入されたSuggestExtensionsパラメータについて記しておきます。 導入されたパッチは以下です。 github.com たとえば Bundler を使って RSpec を依存指定している一方で、RuboCop RSpec を使っていない場合は、以下のように RSpec に対応した拡張 RuboCop が存在することを rubocop コマンド実行のメッセージでサジェスチョンします。不必要な場合はメッセージ中に含まれている方法でオプトアウトできます。 % bundle exec rubocop --parallel (snip) Tip: Based on detected gems, the following RuboCop extension libraries might be helpful: * rubocop-rspec (http://gi
Ruby 3.2.0dev にマージされた Rust YJIT をビルドする - koicの日記
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
rubocop -a と rubocop -A オプション - koicの日記
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
Nokogiriが1.11.0からプリコンパイル済みで配布される - koicの日記
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
`Layout/LineLength` のデフォルトを 120 にした - koicの日記
RuboCop の LineLength のデフォルトが 80 ではつらいという声はずっと聞いていて、そもそも RuboCop にパッチを送り始めた頃は、いつかこの変更をするのが目標のひとつだった。 今回 3年半越しに実現することができた。現在の最新版の RuboCop 0.84.0 に適用済み。 github.com OSS で年月をかけた粘り強い振る舞いは kamipo さんから学んだことで、RangeError にまつわる rails/rails#30000 もそこに到るまでを含めてコントリビュータ時代から何年か掛けていると聞いている。 RuboCop リポジトリ自体の方では、その後にコアメンバーからエディタを縦分割した際に 120 だと厳しいという声があり、RuboCop リポジトリ自体の設定は 100 になったというエピソードがある (デフォルトの設定は 120 で維持されていま
キーワード引数の分離への対応にRuby 2.8.0-devを使う - koicの日記
先日のパッチ会で 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
RailsアプリケーションのRuby 3.0への展望 - koicの日記
パッチ会や地域 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
RubyGems 3.1のローカル非推奨警告を消す - koicの日記
RubyGems 3.1 がリリースされたのでローカル環境の RubyGems をアップデートした。 % gem update --system % gem -v 3.1.2 アップデート後、gem i <gemname> や gem の差分を見る gemdiff などを使った時に以下のような警告の川が流れるようになった。 実際 Gem::Specification#rubyforge_project= が使われている gemspec に関してかなりの量が自分のローカルの場合は表示されていたので、上記は抜粋となる (古めのリポジトリを対象としているので、それも影響しているかもしれない) 。 Gem::Specification#rubyforge_project= called from /Users/koic/.rbenv/versions/2.4.9/lib/ruby/gems/2.4
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
