環境
確認したのは以下のバージョン
- YusukeIwaki/playwright-ruby-client: Playwright client for Ruby 1.45.0
- YusukeIwaki/capybara-playwright-driver: Playwright driver for Capybara 0.5.2
- SeleniumHQ/docker-selenium: Provides a simple way to run Selenium Grid with Chrome, Firefox, and Edge using Docker, making it easier to perform ...
今回は最近例外処理でやらかしたので、それをどう防ぐかをまとめてみた。
例外にまつわる悩み
例外についての説明は割愛。
例外って難しい。できるけどやらない方がよいこと、こういう風に設計した方がよいことなどがいくつもある。逆に言うと
よほど気をつけていないとやってはいけないことを簡単に踏み抜いてしまう
しかし、「気をつける」である限り、やはり踏み抜いてしまう。あぁマーフィーの法則。
てなわけで個人的にはあまり積極的にアプリケーションのレイヤー（特にWebアプリ）で例外を使わない（ライブラリでは普通に使う）ようにしてるんだけど、これは JavaScript で多いんだけど、ライブラリが通常の制御フローかのようにカジュアルに例外を扱っているケースがあり、結果どうしてもアプリのレイヤーに例外処理が漏れ出てきてしまったりする。
対処方法 - 自覚的に意図している例外以外を拾わない
例外処理で気をつけるべきことはいくつかあるが、究極的には
自分で意図した例外以外を捕捉しない
に行き着くのではないか。そもそもエラー情報の伝播や制御フローとして例外を使ってはいけない、などいろいろあるが、まずはこれ。この程度であれば、静的解析でなんとかなりそうだ。
Ruby
Rubocop で縛れる。
Style/RescueStandardError...
もう RSpec 忘れました。対象は
- rspec-core 3.13
です。
やりたいこと
- heavy test を手元の通常の開発サイクルから除外したい
重いテストはきらいです。重いテストはきらいです。重くならざるを得ないのは分かります。でも自分が今書きたいのは重くないテストなんで、邪魔せんといて。
patternではない
Method: RSpec::Core::Configuration#exclude_pattern — Documentation for rspec-core (3.13.0)
最初に思いついたのは
- exclude_pattern
を使って特定のパターンにマッチするテストを除外するという方法だったんだけど、これはファイル名でマッチするので、ファイル名以外の任意の条件で除外するということはできない。
例えば同じパスの中に重いテストと重くないテストがあって、重くないテストは除外したくない場合には役に立たない。
filter_run_*が正解っぽいrspec-core/Filtering.md at main · rspec/rspec-core</...
docker composeって必要なserviceまとめて扱うから重いと思ってた
例えば Procfile であれば起動しないプロセスを簡単にコメントアウトできるので、一時的な ON/OFF も容易だ。
web: bundle exec rails s worker: bundle exec good_job start # <- コメントアウトすれば済むしかし docker compose は長大な YAML になっていて簡単に切り替えできないんだよなぁとずっと思っていたんだけど、いつの間にか profile というものができていた。
2021-01-20 の version 1.28.0 で
--profileを support して以降、この状況は変わっていたようだ。Docker Compose release notes | Docker Docs
ということは、2023-06 に docker compose v1 が EOL になっている今、利用可能な compose コマンドでは必ず使えるということになる。
Docker Compose: What’s New, Wh...
selenium’s Profile | Docker Hub
まだ一部 dev 版や standalone-chrome には amd64 しかなかったりするけど、割と揃っている。standalone-chrome には amd64 しかないけど standalone-chromium には arm64 もある。
そして arm 版を提供していた repository は archive になっている。
今までありがとうございました。
シレッとそれなりの数の制限がある。特に影響の大きいものを挙げる。
Container Registry & Runtime (Docker Deploys) | Heroku Dev Center
deployログを確認したければimageにcurlを足すべし
If you would like to see streaming logs as release phase executes, your Docker image is required to have
curl. If your Docker image does not includecurl, release phase logs will only be available in your application logs.入っていないと Heroku の Activity では何も確認できない。当然、エラーの様子も分からない。Log Drain 側には出ているが、意識から外れると release 時の問題についてデバッグ不能になる。
Dockerfileで使えないもの
- <code class="language-plaintext ...
問題意識
Ruby で書いた自作のツールを手軽に持ち運んで使いたい。そのために
- rubygems で配布したい（Ruby 環境を持っている場合向け）
- Docker image で配布したい（Ruby 環境を持っていない場合向け）
以上二つを同時に満たしたい。
この辺はまぁずっと持ってる課題意識ではあるし、もう一つのアプローチとしては Wasm もある
Wasmで少しだけ手軽にRubyとRubyスクリプトを持ち運ぶ (2024-05-25) | あーありがち
が、今回はあちこちのクラウドでそのまま runtime として扱いやすい Docker の方の話を扱う。
rubygemsを作る部分は割愛
bundle gemして雛形を作って、頑張ってコードを書くべし。docker build時に注意の必要なこと
「持ち込んだもの」は消せない
どういうことかというと、ポイントは以下。</...
問題意識と背景
例えば Docker コンテナとして何らかのアプリケーションをホストしていたとして、Docker image 内で base image と呼ばれる部分に更新が入った場合1、原則として
- base image を更新する
- 更新された base image の上にアプリケーションのコードを展開し、アプリケーション image を構築
- 2 で作った image からコンテナをデプロイ
という手順を踏むのがセオリーだと思う。この時、アプリケーションコードに何らかのコンパイルなどの事前準備が必要だとすると、
- base image 更新後にアプリケーションのコンパイルも必要
ということになる。
例えばやりたいことが OS レベルの軽微なパッチ適用だとしても、上記の行程をすべて経なければ更新が終わらないというのは、ちと高コスト過ぎやしませんかね？
ということでどうにか楽できないかと調べたり試したりしているうちに、結局 Docker に対する理解が深まり、割り切りができたのでそこで整理できたことを残しておくことにした。
コンテナでアプリケーションを動かすとはどういうことか
実は Docker コンテナでアプリケーションを動かす方法は複数あるのだが、Docker コンテナホスティングの説明がよくないのか、アプリケーションコードを含めて image を作って deploy しろと言われることが比較的多いように思う。
<figure class="jekyll-kroki" data-kroki-type="pla...