STORESでフルタイムRubyコミッタをやっている遠藤(@mametter)です。 最近Rubyインタプリタのとある問題の修正に成功した(と思う)ので紹介します。といっても格好良い話ではなく、とても泥臭い話です。 問題 RubyのCIで不定期に次のようなエラーが発生していました。いわゆるflaky test。 1) Failure: TestSymbol#test_inspect_under_gc_compact_stress [.../ruby/test/ruby/test_symbol.rb:126]: ":testing" expected but was ":\"\\x00\\x00\\x00\\x00\\x00\\x00\\x00\"". 発生確率が絶妙で、しばしば起きるのですが、デバッグのために狙って再現しようとしても起きないという代物でした。 問題の分析 エラーが起きていた
私たちは、ただルールを指示的に指摘するのではなく、なぜそのルールがトリガーされた理由をユーザーに説明し、エラーを修正する方法をユーザーに伝えることが大切だと考えています。ルールは以下のような重要な要素に沿って選定されています: ユーザーに対してエラーの説明を行います。これは基本的に診断のメッセージです。 次に、ユーザーに対してエラーがトリガーされた理由を説明します。これは基本的に追加のノードで実装されます。 最後にユーザーに何をすべきかを伝えます。これは基本的にコードアクションを使用して実装されます。コードアクションが適用できない場合は、ノートでユーザーに何をすべきかを伝えます。 もしルールがこれらの要素に従っていないと感じたのであれば、イシューを作成してください。
はじめに 標準ライブラリのOpenStructクラスは柔軟に使用出来るため、気軽に使ってきたものの、Ruby3.0から非推奨になった。 DTOパターン(クラス間のデータの受け渡し)や型を気にしなくても良いテストコードなどで使用してきたが、RuboCop1.23で監視されることになったため気を付けないといけなさそうなので簡単に調べてみた。 なぜ非推奨になったのか? 公式コメント 簡単に翻訳すると以下のようなことらしいです。 パフォーマンスが悪い クラス内部でmethod_missingやdefine_singleton_methodが多用されているために、見えないところでループ処理が実行される StructやHashよりも明らかに遅い Hashと比べると200倍遅い。。 バージョン間で非互換性がある バージョンの違うと特定のメソッドで返り値の型が変わることがある 組み込みのメソッドが簡単にオ
さて、どこからお話を始めましょうか。ここに到達するまでに長い長い旅路をたどりました。かつて私は開発にVagrantを使っていましたが、当時のVMは私の4GB RAMのノートPCでは少々重すぎました。そして2017年にコンテナへの乗り換えを決意したときに、やっとDockerを使い始めました。 しかしDockerで問題がたちまち解決したという気持ちではありません。自分自身やチーム、そしてすべての人々にとって完璧な設定を追求し続けてきましたが、「これでよし」と言える究極の設定はありません。標準的なアプローチを見出すまでにかなりの時間を要しました(2019年に本記事を最初に公開した時点でも相当の時間を費やしていました)。 本記事を最初に公開して私の秘密を隅々までオープンにして以来、多くのRailsチームや開発者が私の手法を採用し、さらに改良や貢献にもご協力をいただきました。 前置きはこのぐらいにし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く