CIでopensearchコンテナの起動を待つ

  • CIで時々opensearchへのアクセスに失敗してテストが失敗していた
  • (ちゃんと調べたわけではないけど)opensearchの起動が終わるより前にアクセスしにいって失敗している風
    • Faraday::ConnectionFailed: end of file reached
  • opensearchコンテナ、毎回Dockerfileからビルドをしているので時間がかかっていた
  • そこでdocker compose -f docker-compose.ci.yml up -d --buildのようにして、ビルドしてからupするようにした
  • が、これでもまだ失敗する
  • 次の手として vishnubob/wait-for-it: Pure bash script to test and wait on the availability of a TCP host and port を利用して、9200番ポートが空くまで待つようにした
  • が、これでもまだ失敗する
  • opensearchのログを見ると、9200番ポートを開けてからまだ少し何かをしているので、そのタイミングでアクセスしてしまっている模様
  • 結局↓のようなメソッドを定義して、テスト起動時のopensearchへのアクセスでエラーが起きたら時間を空けてリトライするようにしたところ解決した
def retry_on_error(times: 3)  
  try = 0  
  begin  
    try += 1  
    yield  
  rescue Faraday::ConnectionFailed  
    sleep 5  
    retry if try < times  
    raise  
  end  
end

リスコフの置換原則のWikipedia日本語版の説明が一部間違えている気がするがどうなおしたらいいかわからない

リスコフの置換原則 - Wikipedia

(直感的な考えでは、「サブタイプ」のオブジェクトは別の型(「スーパータイプ」)のオブジェクトのすべての振る舞いと、更に別の何かを備えたものである。 ここで必要とされるものは、以下に示す置換の性質のようなものだろう:型 S の各オブジェクト o1 に対し、型 T のオブジェクト o2 が存在し、T に関して定義されたすべてのプログラム P が o1 を o2 で置き換えても動作を変えない場合、S は T のサブタイプである。)

とある。だけど自分の理解だと、「o2(スーパータイプのオブジェクト)をo1(サブタイプのオブジェクト)で置き換えても動作を変えない」じゃないとおかしい。

英語版のWikipeaid Liskov substitution principle - Wikipedia だと自分の理解と同じ。

Liskov's notion of a behavioural subtype defines a notion of substitutability for objects; that is, if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program

日本語版のは英語の文章の翻訳が間違っているのだろう、wikipediaを編集しなきゃ、と思ってwikipeaidのアカウントを作ったはいいけどの↓の箇所をDeepLにいれるとo1をo2で置き換える、と出てくるのでどうしたもんか…となっている

the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T.

jsのArray.prototype.sort()は引数を渡さないと、要素を文字列に変換して比較する

タイトルがすべて。

rubyだと

elements = [100, 99]
elements.sort #=> [99, 100]

のようになるのでjsでも同じ挙動を期待するけど、タイトルの通りの仕様なので次のようになる。

const elements = [100, 99]
elements.sort() #=> [100, 99]

sortの引数に次のように関数を渡すと期待通り動く。

const elements = [100, 99]
elements.sort((a, b) => a - b) #=> [99, 100]

参考: Array.prototype.sort() - JavaScript | MDN

herokuの無料dyno/addon有料化で無料のままでいるDBやredisは削除される(が、サポートの人に頼むと復旧してもらえる)

タイトルがすべて。

For non-Enterprise users, hobby-dev databases will be deleted in accordance with the Heroku Documentation starting November 28, 2022.

Removal of Heroku Free Product Plans FAQ - Heroku Help

ちゃんと書いているのに見逃していました…><

DBの中身がなくなると困るのでサポートに連絡すると、すぐにレスポンスが来て対象アプリケーションやDB名などを聞かれ、返したらシュッと復旧してもらえました。30分くらいで解決してすごい!

cookiesのサイズ制限っていまどんな感じですか

  • 発端はこのコミットを見たことAdd details of cookie name and size to CookieOverflow exception · andyw8/rails@0ec8f21
  • クッキーの値が4096バイトより大きければエラーになっている
    • コミットは、エラー時にどの名前のクッキーがどの容量なのかをエラー文言に含めるぞ、というもの
  • 1つのドメインが複数のクッキーを扱っているときに、全体として 4096バイト以内じゃないとだめなんじゃなかったっけ…?
    • そしてそうだとすると単一のクッキーが4096バイト以内でエラーにならなくても、ブラウザ側で期待しない挙動(例: 値がtruncateされる)になったりするケースがあるだろうか?
    • と思ったので調べた
  • いまのchrome(107.0.5304.110)だと1つのクッキーあたり4097バイトまで格納でき、かつドメインあたり180個のクッキーが設定できる
    • ドメイン全体で4096バイト以内、みたいなのはIEなどの古いブラウザの話だった模様
  • ↑のRailsの実装で問題ないぞ、というのを確認できた

参考

default gemとrubygems.orgから取得するgemの違い

require 'zlib'
Zlib::InProgressError

Rails7でシステムテスト失敗時のスクショが保存されるディレクトリが変わる

  • Rails7未満でスクショが保存される先は"tmp/screenshots"配下固定だった。
  • このコミットでスクショ保存のディレクトリの設定が変更になって、「Capybara.save_pathがあればそれを優先して使う」になった。
  • require 'capybara/rails'すると Rails.root.join('tmp/capybara')がCapybara.save_pathに設定される(これはずっと前からそう)
  • このあわせ技により、Rails7にアップグレードするとスクショの保存先が"tmp/capybara"に変わってしまう
  • "tmp/screenshots"にしたい場合は、require 'capybara/rails'しているところよりも下でCapybara.save_path = Rails.root.join('tmp/screenshots')で :ok_woman: