ケツロン構成 - 2024年11月版 -
- Vite 5.4.10
- Vitest 2.1.4
- Valibot 1.0.0 beta7
- Sinon.JS 19.0.2
- power-assert ( @power-assert/runtime 0.2.1 + rollup-plugin-power-assert 0.1.1)
- Deno 2.0.0
Vite は 5.4.10 で試したけど、6 でも変わらないんじゃないかと思う(期待)。
これを書いている人のバックグラウンド
- JavaScript自体はとても長く触っているけど専業ではない
- フロントエンドもバックエンドもやるけどバックエンドを JS で書きたいとは思わない
- TypeScript は JS のゆるふわさに対抗するための現実的でよい手段
- TDD が好き
- もうトシなのでオシゴト的にはいわゆる上流的な話が多め
やりたいこと
既存の知識、既存の資産は活かしたい
- Node.js
- npm
- ES Modules
- Vite
- Vitest
- Sinon.JS</l...
GitHub Actionsから「環境変数」が渡らない
やろうとしていたことは以下の図のような感じ。
- GitHub Actions で
env
をセット - Actions から起動した sh script へは変数は渡ることは確認済み
- sh script から rake task を起こし、さらにそこから起こす vite ではこの変数を読み取れない
渡っていたのはなんなんすかね?
では、上図の sh script で読み取れていた変数はいったいなんなのか? これが Un*x...
環境
確認したのは以下のバージョン
- 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 ... </div>
- GitHub Actions で