すがブロ

sugamasaoのhatenablogだよ

rustでgemパッケージ内のコードを書く方法のメモ

Ruby 3.2に同梱されるBundlerでは、 bundle gem に --ext=rust とすることでrustでgemのコードを書けるようになります。

新しいものはとりあえず触ってみたいので、試してみましょう（完全にn番煎じなのですが、自分用の備忘録です）

事前準備

  • rustのビルド環境
  • Ruby 3.2.0（正確にはBubdler 2.4.0以上）

やってみる

rust_gem_sample という名前のライブラリを作ってみるとしましょう。

$ bundle gem rust_gem_sample --ext=rust
 : # 場合によってはさまざまな質問があるので適当に答える

これで雛形ができる。 作成された rust_gem_sample ディレクトリへ移動し、コードをさらっと眺めてみましょう。

rustのコードはC言語の場合と同じように ext ディレクトリ内に生成される。

$ tree ext
ext
└── rust_gem_sample
    ├── Cargo.toml
    ├── extconf.rb
    └── src
        └── lib.rs

ちなみに、生成されるサンプルコードはこんな感じ

# ext/rust_gem_sample/src/lib.rs
use magnus::{define_module, function, prelude::*, Error};

fn hello(subject: String) -> String {
    format!("Hello from Rust, {}!", subject)
}

#[magnus::init]
fn init() -> Result<(), Error> {
    let module = define_module("RustGemSample")?;
    module.define_singleton_method("hello", function!(hello, 1))?;
    Ok(())
}

define_singleton_method でメソッドが定義されているということは、RustGemSample.hello で呼び出せて、1つの引数を受け取るコードってことですね。

さて、ビルドするためには事前準備が必要なので、以下を修正します（これはrust関係なく、bundle gemした時に必要な一般的なもの）。

  • rust_gem_sample.gemspec
    • TODOをURLっぽい値に書き換えておく（これをしないとビルド時にエラーになる）
  • testを生成している場合、自動生成された test コード
    • デフォルトのコードは失敗するようなコードになっているので、修正するなり消すなりする必要がある

これは余談ですが、久しぶりにgemspecの中身を見て source_code_uri や changelog_uri というのが設定できるということを知りました。RubyGemsのドキュメントを見るに、設定しておくとrubygems.orgのサイドバーにいい感じに表示してくれるっぽいですね……？

$ ./bin/setup
$ bundle exec rake

これで無事にビルドできるはずです。

ではお試しで実行してみましょう。

$ ./bin/console
Ignoring rust_gem_sample-0.1.0 because its extensions are not built. Try: gem pristine rust_gem_sample --version 0.1.0
irb(main):001:0> RustGemSample.hello("hoge")
=> "Hello from Rust, hoge!"
irb(main):002:0>

おー、うごいた！

せっかくなのでブログにしてみよーと思って書き始めたのですが、なんか、思ったより何もせず動いてしまった……（いい話）。

2021年に読んだ本

2021年は比較的本を読んだ気がします。

よく考えると、ゲームチェンジが起こったことが影響しているかもしれませんね。

読み切った本

いかにしてアーサー王は日本で受容されサブカルチャー界に君臨したか

アーサー王とかエクスカリバーとか、小さい頃から慣れ親しんでいたけれど、それが日本でどのように受容されてきたかの話。どのように編纂されてきたかも含めて読み物としてめちゃ面白い。それと、「いかにして〇〇は〇〇したか」構文はアーサー王伝説を編纂した「アーサー王の死」の章タイトルに由来しているということを知れたのは結構なアハ体験。

あと、コラムとして本文の途中に差し込まれている侘助さんという方のコラムが完全にオタク特有の早口文体なんだけど読みやすくて、なんというか筆力を感じてすごい。

残念ながらkindle版はないのですが、amazonでも物理本は購入できます。kindle版があればな〜〜と思いつつも、この本は装丁もめちゃくちゃ凝っているので本で購入する方が良い体験を得られると思います。

07-9いかアサ〈ガウェイン〉 | みずき書林

いかにしてアーサー王は日本で受容されサブカルチャー界に君臨したか〈ガウェイン版〉: 変容する中世騎士道物語

いかにしてアーサー王は日本で受容されサブカルチャー界に君臨したか〈ガウェイン版〉: 変容する中世騎士道物語

  • みずき書林
Amazon

眼の誕生

進化の過程でどのように生物が眼という器官を発生させたかという話。推理小説のような書きっぷりで、表題に到達するまではそれなりに読み進めなくてはいけないけれど、光と生物の関係についてじっくり説明していくので、それはそれで読み物として面白い。

眼が発生するのは光を検知して外敵を発見するなどする光受容体をより発達させていったものという内容が段階を経て理解できる構成になっていて良かったのと、三葉虫が目を獲得していった話とかは読み応えありました。

これも物理本しかなかった。

眼の誕生――カンブリア紀大進化の謎を解く

眼の誕生――カンブリア紀大進化の謎を解く

Amazon

ユニコーン企業のひみつ

いわゆるスクラムのような1チームで成果を出す規模を超えてしまったときに、Spotifyはどういうアプローチでスケールさせていったか？ということが書いてある。LeSSのようなスクラムチームをスケールさせる手法をとっている場合、おそらくアプローチは異なるけど目指す方向は似てるはずなので、Spotifyがどういう取り組みをしていたかは解像度を高めるための参考になりそうな気がしています。

詳しくはこっちに書いた。

🦄ユニコーン企業のひみつを読んだ🦄 - すがブロ

ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方

ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方

Amazon

OKR

OKR、雰囲気でしかわかってなかったので参考になった。とはいえ、エンジニアの評価軸に合わせるの難しいな〜〜とか、今週の目標確認やウィンセッションなどのイベントごともスクラムを取り入れた組織だとコンフリクトしそうだよな〜〜などの感想を得た。杓子定規なOKRとスクラムの併用は難しいだろうなあ（導入するならそれなりに強い意志でアレンジしていかなといけなさそう）というのはググるとチラホラ見かけました。

OKR（オーケーアール）

OKR（オーケーアール）

Amazon

エラスティックリーダーシップ

以前読んでいたのを再読した。

エラスティックリーダーシップを読んだ - すがブロ

感想としてはあまり大きく変わらないけれど、当時よりは解像度が高い状態で読めて良かった。

エラスティックリーダーシップ ―自己組織化チームの育て方

エラスティックリーダーシップ ―自己組織化チームの育て方

Amazon

つまみ食いで読んでるシリーズ

手を動かしながら学ぶTypeScript

同僚が執筆したTypeScriptの本。 #手TypeScriptというハッシュタグ流行らせたいんですが、全く流行っていません😭

まだ読み進めている途中ですが、個人的には数年前、当時在籍していた会社でJS -> TSへのコンバートをやったときにこの本があれば……!! という気持ちがあります。

手を動かしながら学ぶ TypeScript

手を動かしながら学ぶ TypeScript

Amazon

達人プログラマー 第2版

いまさら語ることは無い良本ですが、最近になって読み直したけどやっぱり良いこと書いてありますね。

最初は数々の引っ越しイベントを経て手元に残していた初版を読んでいたのですが、圧があったので2版を買いました（のちに気が付いたんですが、kindle版ではなくどこかのPDF版を購入済みだった）。

達人プログラマー ―熟達に向けたあなたの旅― 第2版

達人プログラマー ―熟達に向けたあなたの旅― 第2版

Amazon

アジャイルな見積もりと計画作り

自社ではスクラムをベースとした開発をしており、「これ、どう考えたら良いんだっけ？」というときに見直しています。

アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～

アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～

Amazon

Clean Agile

こっちの本はほぼ読んだと思うけど、アジャイルな見積もりと計画作りと同じく、考え方を参考にしたいときに読み直しています。

Clean Agile　基本に立ち戻れ (アスキードワンゴ)

Clean Agile　基本に立ち戻れ (アスキードワンゴ)

Amazon

エンジニアリング組織論への招待

これはまだ読んでいる途中なのですが、2021年の後半はチーム内のチーフというロールをやることになったので1on1をやる機会もあり、メンタリングについて興味があって読んでいます。 これは1on1をやり始めてすぐ読むべきだったな〜〜〜というくらい良い本でした。まだ読みきれてないけど……。

エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング

エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング

Amazon

エンジニアのためのマネジメントキャリアパス

どういう内容かはそのっつさんの感想を読むとわかりやすいですが、ひとまず自分の目の前にあるチームのマネジメント文脈ほしさで5章まで読んだ。

自社のチーフというロールはプレイングマネージャーなので、参考や目標に。

これはkindle版が無いのが惜しい

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

Amazon

おわりに

読んだマンガとかも書こうと思ったけど分量がめちゃ多くなりそうなのでここで終わります。

といいつつ、いま一番良いなと思っているのを書いておくと、ハイパーインフレーションです（最初はイロモノ的なマンガかなと思ったけど、完全にシリアスな笑いを狙ってきていて引き込まれる良さがある）。 shonenjumpplus.com

RubyMineでよく使ってる機能

この記事は SmartHR AdventCalendar の2日目です。

20代の頃はVimを使っていたのですが、膝に矢を受けてしまいIDEを使うようになってしまいました。

さて、そんなこんなで普段使いしているRubyMineですが、この中でよく使う機能について少し書いてみようかなと思います。

というわけで書いていきますが、ファイルを開くとか検索するとかはメジャーだと思うのでそれ以外について書いていきます。

コードを見ているときに便利なやつ

キャプチャを取得する際のサンプルとしてrubygems.orgのコードをRubyMineで開いています。

cmd + clickで関数ジャンプをした後、cmd + [で戻る

メソッドを探索していて、「今見ているメソッドを呼び出していた部分を読みたい」というときに戻れて便利。

さらに、cmd + ]で戻った状態から進むことができるらしいのですが、何らかのアプリにショートカットが吸われていて使えた試し無し😇

開いているファイルを「Project」タブ内で選択状態にする

読み進めているファイルと同じ階層の別ファイルを開く場合などに、シュッと周辺ファイルを探すことができて便利。

f:id:seiunsky:20211202002036p:plain

「Structure」で概要を見る

単純にメソッド一覧が表示されるだけでも便利なのですが、RSpecなど、テストを書いているときにどのようなテストケースが書かれているか把握するのに便利（RSpecだと階層構造も把握しないとテストの全体像が把握できなかったりするので）。

RSpecに関しては--dry-runを実行するという手もありますが、編集しながら横に表示できるのが便利なんですよね〜〜〜。

f:id:seiunsky:20211202002943p:plain

With Coverageでコードカバレッジを見る

テストを実行するときに、「'With Coverage'」を選択するとテスト実行後にカバレッジを表示できます。 網羅率がどうこうというより、テスト対象としたいコードに対して正しくテストが通っているかを確認するのに便利。

f:id:seiunsky:20211202003130p:plain

便利Plugin

ゴテゴテ入れるのは好きでないので、あまり入れてませんが……。

GitLink

Open in GitHubのショートカットを追加するやつ。カーソルがある行に対応するGitHubのパーマリンクが取得できるので便利。

https://plugins.jetbrains.com/plugin/8183-gitlink

Find Pull Request

該当行を変更したであろうPRを探してくれるくん。システム考古学してるとき便利。

https://plugins.jetbrains.com/plugin/8262-find-pull-request

Railways

rails routeをシュッと見る用です。絞り込みもできるので便利。

https://plugins.jetbrains.com/plugin/7110-railways/

SmartHRに入社して1年が経った

めでたいのでハッピーターンをたくさん食べました

これまでのあらすじ

sugamasao.hatenablog.com sugamasao.hatenablog.com

近況

5/1で入社して1年ということになりました。

10年ちょっとぶりの転職なので世の中のエンジニアリングについていけなかったらどうしようかと思っていたのですが、幸いにもWebアプリケーションエンジニアとしてなんとかやれてます（たぶん……）。

今までロクに経験のなかったチームでの開発ってやつを楽しんでます。

SmartHRとぼく

忘れそうなので書いておきます。

認知のきっかけ

2018年

この頃、転職はまだ少し先の話という認識でいました。

少なくとも半年後に転職するとかそういう気持ちではなく、IT業界にありがちな、そのうち転職するとしたら合いそうな会社の目星をつけておこうくらいの温度感ですね。

  • おそらく最初に認知したのはこのconnpassだったと思う
  • もしかしたらRubyKaigiでの宮田さんの話だったかもしれないけど、このRubyKaigiは不参加だったのでTwitterのTLごしにうっすら認知していた可能性がありそう（いまとなってはこの時点で認知していた気がするけど、存在しない記憶の可能性がある）
  • エンジニア向けの体験入社制度ができましたの時に名前だけじゃなくて事業も把握したはず
    • というのも、当時は私自身も半蔵門に勤務していたので、ふつうの出社気分で体験入社できそうだな〜とか考えたりしていたのだった
    • 良さそうな会社という認識はあったので転職する気持ちが高まってたらすぐに飛びついていた可能性はあった

2019年

アラフォーで同じ会社に10年いるのやばくね？　みたいな気持ちが高まっており、ワンチャン転職しても良いかもっていう気持ちになってきた年です。

正確に書くと、40歳過ぎてから転職するのヤバそう（転職した時の期待値を越えられなさそう）という気持ちが強く、40歳になる前に−−そして転職に失敗した場合の再転職バッファも考えると今のうちに一度転職しておいた方が良さそうだなみたいな事情です（2019年当時、私は37歳）。

  • Rails DMのランチセッションでSmartHRが会社紹介をしていて、その話を聞いた時かなり魅力的に感じた記憶がある
    • この手のランチセッションって、ご飯食べながらだし、言うても話半分で聞く感じになりがちだと思うのですが、なんかめちゃくちゃ響いたんですよね
      • この時点ではすぐに転職活動するつもりはなかったのですが、時が来たら話を聞きにいこうと思った
  • そのほかにはたらいの話がすごく良さそうに思えて、人が増えていってもちゃんと対処できてそうという雰囲気を感じたのだった

ちなみに、これが響いた様子です（これはさまざまな感情を圧縮した結果のコメントです）

それから

以前の転職活動メモにも少し書きましたが、転職活動は2019/10ころから始めていました。

初手は転職ドラフトで本当に自分自身に市場価値あるんですか……？みたいなところを見つつ、転職ドラフト経由以外に自分からいくつかの企業にコンタクトをとったのが11月末〜12月くらいって感じですね。

SmartHRに関しては、たまたま参加したイベントに人事の方がいらっしゃったのでダイレクトアタックして選考フローに乗せてもらいました（ふつうにHPから応募しようと思っていたので、これは本当に偶然）。

その後、なんやかんやあって、ありがたいことに内定はいくつかいただけたのですが、どの会社も魅力的で本当に迷っており、パーフェクトRuby on Railsの改訂作業を行う精神力が保てなくなったりしました（それはまた別のお話）。

ここまでを振り返ってみると

SmartHR社は転職に対するマインドシェアが高まっている時にちょうどよく認知を高めるイベントがあったのかな〜〜という感じはありますね。

最終的に決断した一手はこれらとは別にありましたが、そこに至るまではやはり「タイミングが合っていた」というのは結構重要なファクターだったかもしれません。

露骨な宣伝

それはそれとして、CTOからのお知らせにあるとおりSmartHRではWebアプリケーションエンジニア（に限らず）積極採用中なので、もし話を聞いてみても良いかなって人がいらっしゃればぜひ以下の資料やエントリーページをみていただければと思います。

会社説明資料はこちら。

speakerdeck.com

以下の採用ページにある各職種の募集ページからエントリーしていただけますが、カジュアル面談のエントリーも可能なので、まずはどんなもんか話を聞いてみようかって場合はそちらを選択していただければと思います。

smarthr.co.jp

露骨な宣伝2

パーフェクトRuby on Railsも何卒よろしくお願いします。

パーフェクト Ruby on Rails　【増補改訂版】

パーフェクト Ruby on Rails　【増補改訂版】

🦄ユニコーン企業のひみつを読んだ🦄

私は訳者お二人のファンなので書いました。まあもちろん、それ以外にも単純にスクラムをもうやっていないという宣伝はシンプルに気になりますよねということでシュッと買って読みました。

ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方

ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方

  • 作者:Jonathan Rasmusson
  • 発売日: 2021/04/26
  • メディア: 単行本（ソフトカバー）

ちなみに、オライリーのサイトだと電子書籍版を購入できます。

www.oreilly.co.jp

かんたんな感想

スクラムとかアジャイルとかあまり詳しくないので小学生並みの感想です。

今北産業

  • 「スクラムをやっていない」isいわゆるSpotifyモデルの話
    • ただ、これはあくまで著者がSpotifyに所属していた時期（2014〜2017）のモデルであって、いまどうなっているかを書いているわけではない
  • 「Spotifyモデル」is少数チームで迅速に開発をする速度を維持しながらスケールさせるには？という話
  • このモデルを実現させるためには"開発チーム"みたいな閉じた座組みではなく、経営陣を含めた考え方、つまり企業の文化を変えなきゃダメだよねということを述べている

ちなみに、本文の補足を書いてある「訳者あとがき」はインターネット上に公開されているので、購入前に一読してみると良いかもしれません。

https://scrapbox.io/iki-iki/%E3%83%A6%E3%83%8B%E3%82%B3%E3%83%BC%E3%83%B3%E4%BC%81%E6%A5%AD%E3%81%AE%E3%81%B2%E3%81%BF%E3%81%A4%2F%E8%A8%B3%E8%80%85%E3%81%82%E3%81%A8%E3%81%8C%E3%81%8D

感想

Spotifyモデルのことを名前しか知らなかったのだけど、どういう思想のもと作られたものかわかってよかった。 また、これは読めばわかることだけど、「スクラムをやっていない」、それはそうだけど事業規模や会社に合わせて変化させていった結果であって、取り組みはスクラムの知見や経験をベースにしていてスクラムは役に立たなかったとかとかそういう話ではなさそう。

Spofityモデルの話をベースにしているけど、どちらかというと"テック企業になるためには文化を作っていかなくてはいけないんだよ"というメッセージが書いてあるように思えたので、形をまねるのではなく自社がより良い一歩を踏み出すための参考にする感じが良いのかなあ。

👇のような話もあるし、世の中銀の弾丸なんてないのじゃ……（真偽のほどはわかりません）。

https://agile.quora.com/Spotify%E3%81%AF-Spotify%E3%83%A2%E3%83%87%E3%83%AB-%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%84%E3%81%AA%E3%81%84

ちなみに、Spotifyモデルを見ていてLeSS(大規模スクラム)と似ている*1ようで異なるなーと思ったのですが、お互いに影響を与えたりがあったりしていたんですかねえ。

読書メモ

*1:どっちも企業文化から変えないと価値をデリバリーできないですよねって話は共通してるかな〜とか

2020年のメモ

振り返るほどかっこいい生き方してないのですが、今年は転職があったり書籍の出版があったりしたので、せっかくなのでメモしておきます。

1月

  • 転職活動が佳境に入る
    • 具体的に言うと選考が最終選考に入り、いよいよどこに入社するか決断しなくてはいけない
  • 改訂版パーフェクトRuby on Railsの執筆新体制でリブート
    • @_yasaichi さん、@igaiga555さんを含めた新体制でやっていく気持ちを新たにしたところ
    • 執筆自体は2019年の秋頃から進めていたのですが、現体制では目標となる発売日までには手が足りず厳しい状態だったのでした
  • サイゼリヤで豪遊して近年稀に見る二日酔いになる

2月

  • 転職活動の最終選考が終わり、いよいよどこに入社するか決めなくてはいけない感じになる
    • 決められないおじさんだったので、体験入社やエンジニアの方との会食などを開いてもらうものの、新型コロナの影響で予定が伸びたりしていた
  • 退職手続きなどを進める
    • 今思うと、入社先が決まってないのに退職するの結構スリリングじゃん
  • 改訂版パーフェクトRuby on Railsの執筆が佳境に入りつつある
    • と言いつつ、転職活動などで精神力を使い果たして身が入らず進捗が厳しい状態に

3月

  • 入社先を決定する
    • 入社を決定した一方、内定辞退の連絡をする必要もあり、本当によくしてもらったのでつらかったです
  • 11年近く在籍した会社を退職した（3月の時点では正確には最終出社で、有給消化期間に突入）

4月

  • 無を満喫する（と思いきや執筆や登壇準備で全然ゆっくりできなかった
  • 日本に緊急事態宣言が発令される
  • ホットクックで料理を作ることを覚える
  • Railsエンジニア養成読本をネタに銀座Railsで登壇
  • 改訂版パーフェクトRuby on Railsの執筆が佳境に入る（ガチ）

speakerdeck.com

5月

  • 現職へ入社
    • 1ヶ月以上働かない状態から突然の仕事で身体がびっくりしちゃうね
    • 昨今の諸事情により初手からフルリモート
  • 改訂版パーフェクトRuby on Railsの執筆が終盤に入り、レビューや修正などで大忙し

6月

  • 改訂版パーフェクトRuby on Railsの執筆が終盤に入り、レビューや修正などで大忙し(2回目)

7月

パーフェクト Ruby on Rails　【増補改訂版】

パーフェクト Ruby on Rails　【増補改訂版】

speakerdeck.com

8月

  • 試用期間が終わり無事に正社員になれました。良かったですね

9月

  • RubyKaigi Takeout 2020 感想戦＠仮想松本という自社イベントに参加しました

www.youtube.com

10月

speakerdeck.com

11月

12月

  • 憧れのおつかれ🚿に呼んでいただきました
    • 特に、2回目冒頭の「海でも川でも溺れたことがある」という紹介はかなり良さみが深かったです

youtu.be youtu.be

ここまで書いてみて

今年は転職活動をはじめ、人間との関わりが多かった一年でした*1。 その節は大変お世話になりましたが、引き続きどうぞよろしくお願いいたします。

*1:新型コロナの影響がある中、リモートの対応で滞りなくやりとりできてよかった

RuboCopの実行がOOMに殺されて1ヶ月が過ぎました

これはSmartHRアドベントカレンダー2日目のエントリです。

f:id:seiunsky:20201201194541p:plain

私の所属先であるSmartHRではCircle CIを使ったCI環境を用意していて、その中でRSpecやRuboCopを実行しています。

そんななか、たまにRuboCopのjobがReceived "killed" signalと発して死んでゆく現象が発生していました。

しかも、なんとなく発生頻度が高まっているような……？という気がしてきて地味に困るので調査を開始しました。死亡現場である動作ログをよく見るとRuboCopの検査自体は終了しているように見えるものの、その後のなんらかの処理で死んでいる*1ように見えました。

RuboCopの実行後の処理とは

CircleCIではJUnit形式で実行結果を出力しておくと違反があったときいい感じにしてくれる機能があるため、例に漏れず我々のプロダクトでもJUnit形式のXMLを出力していました。

（📝 RuboCopでは0.80.0からJUnit用のフォーマッターを内蔵するようになったので、rubocop-junit-formatterなどの専用gemを使わなくても良いようになっています）

処理の流れをエスパーするに、おそらくこの処理で長大なXMLを生成しようとして力尽きているのでは……と予想を立てました。

で、どうしたの

どうしようかなあと困っていたのですが、RuboCopのチェンジログを眺めていると0.85.0*2 で--display-only-failedというオプションが追加されていることを知りました。これはJUnit形式のXMLを生成する際に利用できるオプションで、失敗したものだけをXMLに出力するという大変省エネなオプションです。

use --display-only-failed

見立て通り死因がOOMであればこのオプションは有効であろうと思われるので、早速このオプションをCircleCIのconfig.ymlに追加しました。

すると、目に見える効果としてRuboCopのジョブ自体の実行時間が結構減りました（具体的には4〜5分だったものが1〜2分で終わるように）。

そして、数日の間CircleCIの結果を眺めていたところ、RuboCopの不審死は見当たらなくなりました。

どうやら問題は解決できたようです。やったね🎉

というわけで

人間は慣れてしまうもので、ちょっと不便だな〜というものはそのままにしがちなのですが、ちゃんと調べたら解決できることもあるので、面倒がらずに調べてみると良いですね。

特にCIの設定は一度設定するとあまり注視しないものなので、効果的な設定があってもそのままにされがちだったりします。たまには設定の棚卸しをすると良いかもしれませんね。

※アイキャッチ画像はこちらの画像を利用しています

*1:killが送られてきているので、OOMっぽいなと当たりをつけました

*2:https://github.com/rubocop-hq/rubocop/blob/master/CHANGELOG.md#0850-2020-06-01