RubyMineのデバッグ時に標準入力を受け取る方法
デバッグ時に標準入力の方法が分からなかったのでメモ。
デバッグ開始直後では、プログラムの状態を調べたりするデバッグ用のインタラクティブコンソール。 この状態で入力しても、標準入力としては認識されない。
コンソールタブの左側にアイコンが沢山あり、「ゴミ箱」アイコンの下にある「コンソールプロンプトを表示」アイコンを押す。 すると、標準入力可能。
参考: debugging - Ruby debugger fails on STDIN.gets user input - Stack Overflow
MacでVirtualBox上のCentOS7が起動しない場合の対処方法
書籍「新しいLinuxの教科書」のチャプター1の手順で失敗した際の対処ログ
再現手順
下記構成でCentOSを起動しようとすると「予期せぬ理由...」でコケる
- macOS Catalina 10.15.7
- VirtualBox 6.1
- CentOS-7-x86_64-DVD-2003.iso
結論
VirtualBoxのバージョンを6.1から6.0に下げる
VirtualBox 6.1 のアンインストール方法
ソートアルゴリズム
挿入ソート
計算量
O(n2)
ほとんど整列済みの数列に対してはほぼO(n)と高速で動作する
概要
- 前半をソート済み部分、後半を未ソート部分で分ける
- 未ソート部分の先頭を、ソート済み部分の最後尾から比較して配置
- 安定している
詳細
258369
緑部分がソート済みの場合、
- まず、8と3を比較し、8を後ろにずらして、 253869
- 次に、5と3を比較し、5を後ろにずらして、 235869
- 最後に、2と3を比較し、3を挿入位置が確定して、235869
- 235869 となり、次は6をどこに挿入するかを考える
バブルソート
計算量
O(n2)
遅い。一連の処理において、ある条件を満たせば次のループへ、ということがない。
概要
挿入ソートと同様に、前半をソート済み部分、後半を未ソート部分で分ける
ソート済み部分の最後尾から順々に比較し、大小逆転していれば交換する
安定している
詳細
12534
緑部分がソート済みの場合、
- まず、4と3を比較し、12534でそのまま
- 次に、3と5を比較し、12354
- 再度、一番最後尾から比較、12345
選択ソート
計算量
O(n2)
遅い。
概要
例によって、前半をソート済み部分、後半を未ソート部分で分ける
未ソート部分から最小の要素を特定し、それを未ソート部分の先頭と交換する
安定なソートではない
詳細
1387945
緑部分がソート済みの場合、
- まず、最小となる4を探す
- 次に、4と8を交換し、1347985
- 上記の処理を繰り返す
RSpecがRandom failする場合の調査方法や対処方法
Random failする理由は様々ですが、下記を見てみます。
それぞれの詳細は別途ググって見てください。
- feature specでCapybara::ElementNotFound等で落ちる場合
- データ不整合等の理由で、特定の実行順で落ちる場合
1. feature specでCapybara::ElementNotFound等で落ちる場合
原因
- ajaxの処理が未完了
- 要素の描画が未完了
など
対策
- その1. Capybaraのwait時間を伸ばす
デフォルトで2秒しか待たない設定なので、それ以上に伸ばします。
下記の設定だとグローバルに待機時間が伸びます。テスト毎に設定も可能
Capybara.default_max_wait_time = 5
- その2. rspec-retry gemを導入
テストが失敗した場合に自動リトライさせます。
https://github.com/NoRedInk/rspec-retry
- その3. feature specからsystem specに移行する
system specにすると、処理が高速化し、エラーで落ちにくくなります。
database cleanerが不要になるなど、処理時間も半分近くになるのでオススメ。
2. データ不整合等の理由で、特定の実行順で落ちる場合
原因
- テストの実行順により、データの状態が変わり落ちる
- データが存在しない、すでに同じキーでデータが存在するなど
- ActiveRecord::RecordNotUniqueが出たりするので比較的分かりやすい
調査
まず、どの順番になると落ちるか？を特定するため、エラーを再現させます。
RSpecの結果に表示されている Randomized with seed #### と出力されるseed番号を実行時に指定することで、同じ順序でのテスト実行が可能です。
rspec --seed 12345
これによりCI上で発生していたエラーがローカルでも再現できるはずです。
で、エラーを発生させるために毎回上記を実行していると非常に時間が掛かるので、bisectオプションを付けることでエラーが発生する範囲を特定できます。
rspec --seed 12345 --bisect
上記を実行すると次の表示が出力されます
The minimal reproduction command is: rspec 'hogehoge' --seed 12345
出力されたコマンドを実行すると、最短でエラーを再現できるようになります。
エラーの再現ができるようになったので、後はデバッグして問題を解決するだけです。
参考: seedやbisectオプションの詳細は下記を参照
実用的な新機能が盛りだくさん！RSpec 3.3 完全ガイド - Qiita
その他の調査方法
Circle CIの場合、rerun with sshすることでCI上の環境でデバッグ可能。
binding.pryを埋め込んだりもできる。
