fv17の日記

Webエンジニアの備忘用ブログです。主にWeb界隈の技術に関して書いています。

RubyMineのデバッグ時に標準入力を受け取る方法

デバッグ時に標準入力の方法が分からなかったのでメモ。

デバッグ開始直後では、プログラムの状態を調べたりするデバッグ用のインタラクティブコンソール。 この状態で入力しても、標準入力としては認識されない。

f:id:fv17:20220305114707p:plain

コンソールタブの左側にアイコンが沢山あり、「ゴミ箱」アイコンの下にある「コンソールプロンプトを表示」アイコンを押す。 すると、標準入力可能。

f:id:fv17:20220305115113p:plain

参考: debugging - Ruby debugger fails on STDIN.gets user input - Stack Overflow

MacでVirtualBox上のCentOS7が起動しない場合の対処方法

書籍「新しいLinuxの教科書」のチャプター1の手順で失敗した際の対処ログ

再現手順

下記構成でCentOSを起動しようとすると「予期せぬ理由...」でコケる

結論

VirtualBoxのバージョンを6.1から6.0に下げる

Eclipse - コードの自動補完を設定する

自動補完の設定

Eclipseのデフォルトでは「.」が入力された時にしか自動補完されない。
設定 > Java > エディター > コンテンツアシスト > 自動有効化 で設定を変更する。

自動有効化遅延: 30~100
Javaの自動有効化トリガー: .abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_

f:id:fv17:20200922185803p:plain
自動補完設定

ショートカットキーの設定

Macの場合、EclipseのデフォルトではSpotlight検索と被るので変更が必要。
画像の赤枠で適宜設定する

f:id:fv17:20200922190005p:plain
キーバインディングの設定

ソートアルゴリズム

挿入ソート

計算量

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する理由は様々ですが、下記を見てみます。
それぞれの詳細は別途ググって見てください。

  1. feature specでCapybara::ElementNotFound等で落ちる場合
  2. データ不整合等の理由で、特定の実行順で落ちる場合

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を埋め込んだりもできる。