Posts

結論 hurl の変数はファイルごとに作り直される。hurl login.hurl me.hurl で login.hurl が capture した値は me.hurl に届かず、me.hurl は Undefined variable で exit 3 になる --variable の値は、数字だけなら数値として読まれる。+819098765432 は 819098765432、09012345678 は 9012345678、1.50 は 1.5 として届く。書いた文字のまま渡すなら "..." で囲む --variables-file は値の $VAR も $(...) も展開しない。同じ名前を --variable でも渡すと、渡す順に関係なく --variable の値が使われる 環境変数で届くのは HURL_VARIABLE_<name> と HURL_SECRET_<name> だけで、HURL_<name> は届かない。ファイルで使わない変数を渡しても、エラーも警告も出ない jsonpath の結果は件数で型が変わる。フィルタの一致が 0 件なら値なし (none)、1 件ならその値、2 件以上ならリストになる。1 件の count == 1 は Filter error で落ち、2 件を capture して {{}} で埋め込むと Unrenderable expression で落ちる 値が null なのとキーが無いのは別の状態で、not exists はキーが無いときだけ通る。ただし親が null なら、その下のキーへの not exists は通る 以下は hurl 8.0.1 / bash 5.3.15 / linux/amd64 で実測した。要求は手元で立てたサーバ (/echo は受けた要求の X- ヘッダを JSON で返し、それ以外のパスは同名の JSON ファイルを返す) に送った。 ...

結論 --select-1 は候補が 1 件なら、--exit-0 は 0 件なら、一覧を出さずに終わる。「fzf で人が選ぶ」前提の導線でも、1 件に絞れた候補はそのまま確定する --query の既定はあいまい一致で、行全体を照合する。api は apps-migration に当たり、--exact でも main は domain-model に当たる。行と完全に一致させるのは ^main$ だけ fzf は --filter 以外では起動時に /dev/tty を開く。制御端末の無いプロセスでは、--select-1 で 1 件に絞れても failed to open /dev/tty で exit 2 になる 終了コードは 0 (選んだ) / 1 (一致なし) / 2 (エラー) / 130 (中断)。--expect= (キー無し) は 2。producer | fzf は、fzf が先に終わると producer が SIGPIPE の 141 で終わり、pipefail で全体が 141 になる {} {1} はシングルクォートで囲んだ 1 引数に展開される。自分で "{}" と囲むと、そのクォートが値に混ざる preview は行ごとに別の $SHELL -c で走り、呼び出し元の関数と export していない変数は見えない --multi の出力は選んだ順。--tac は入力の並びを反転するだけで、カーソルは常に並びの先頭に乗る 以下は fzf 0.74.3 / bash 5.3.15 / linux/amd64 で実測した。対話の操作は script コマンドが作る疑似端末 (pty) の中で fzf を動かし、キーを送って再現した。 ...

結論 0 issues. / exit 0 は「違反が無い」ではなく「報告まで残った指摘が無い」。golangci-lint は ファイルの読み込み => linter の検査 => 検査後の後処理 の 3 段階で動き、指摘はどの段階でも消える 後処理: issues.new: true は差分で追加された行の指摘だけを残す。クリーンな checkout では HEAD~ との差分しか見ない。issues.fix: true は直せる指摘をファイルへ書き込み、報告から外す 抑止コメント: gosec の指摘を抑止するコメントは 2 種類ある。#nosec は gosec が読むので、gosec 単体でも golangci-lint 経由でも効く。//nolint:gosec は golangci-lint が読むので、golangci-lint 経由でだけ効く。# を抜いた //nosec は gosec も golangci-lint も読まず、どの実行でも指摘が出る。抑止されるのは名指しした ID だけ 読み込み: build tag 付きのファイルは、run.build-tags に入れないと型検査にも載らない 検査: staticcheck は ST の一部を既定で外す。forbidigo は既定で呼び出しの字面だけを照合し、exhaustive は名前付きの型の列挙だけを見る。gopls の analyzer の一部は golangci-lint に入っていない CI では --new=false --fix=false を明示する。設定を書いたら、違反を 1 つ置いて検出されることを確かめる 以下は golangci-lint 2.14.0 (go1.26.4, linux/amd64) と gopls v0.23.0 で実測した。設定は v2 の形式 (version: "2") で書く。 ...

結論 Firestore のトランザクションが競合として扱うのは、その中で tx.Get した文書だけ。 トランザクションの外で読んだ値、読まずに書いた文書、クエリで「無かった」ことは守らない 悲観 (Standard の既定) と楽観 (Enterprise の既定) で違うのは決着の時点だけで、守る範囲は同じ。 判定に使う値をコールバックの中で読み直せば、同じコードがどちらでも通る 「1 件だけ」を守りたい値はドキュメント ID にして名指しで読む。件数を数える判定は、エミュレータでも条件次第で 2 件できた SDK はコールバックの中での生のクライアントの書き込みも、外側の ctx で張った RunTransaction も止めない。どちらもトランザクションの外で確定する 複数の文書を「全部か、無しか」で書くなら RunTransaction。BulkWriter はアトミックでない 以下は cloud.google.com/go/firestore v1.26.0 / Firestore エミュレータ v1.22.0 / Go 1.26.4 で実測した。 エミュレータは --database-edition=standard と --database-edition=enterprise の 2 つを立てた。 本番の Firestore では試していない。 前提: 競合として扱うのは、トランザクション内で読んだ文書だけ 公式ドキュメントは、並行制御の 2 つの方式をどちらも「読んだ文書」で説明している ( Data contention in transactions )。 悲観: “transactions place locks on the documents they read” 楽観: 読んだ文書を追跡し、“only if none of those documents changed” のときだけ書き込みを確定する 読んでいない文書はロックも照合もされない。 書くだけの文書、トランザクションの外で読んだ値、クエリの結果に入らなかった文書は、守る対象に入らない。 以下の節は、どれもこの 1 点から出てくる。 ...

結論 go test の結果キャッシュは、テストバイナリ・cacheable なフラグ・テストが読んだ環境変数・モジュールの中で開いたファイルで照合する。モジュールの外のファイルは、書き換えても (cached) のまま緑になる 境界はパッケージのディレクトリではなくモジュールルート。外のフィクスチャは、モジュール内に張った symlink 越しに読めば追跡される -coverprofile / -coverpkg 付きの実行もキャッシュされ、カバレッジ率も前回の値が出る GOFLAGS=-count=1 は、そのフラグを持たない go build / vet / list / fmt / run では無視され、エラーにならない。Makefile で export すれば、全ターゲットの go test をキャッシュから外せる CGO_ENABLED を変えると、cgo のファイルを持つ net と、それを import するパッケージがすべて別のキーで作り直される ビルドキャッシュはユーザ単位で、全リポジトリが共有する。1 つのリポジトリの go clean -cache / -testcache が、同じマシンの全プロジェクトに効く 以下は Go 1.26.4 (linux/amd64) で実測した。実験では GOCACHE を一時ディレクトリに向け、手元のキャッシュには触れていない。 前提: テスト結果のキャッシュは何で照合するか go help test は次のとおり書いている。 The rule for a match in the cache is that the run involves the same test binary and the flags on the command line come entirely from a restricted set of ‘cacheable’ test flags, defined as -benchtime, -coverprofile, -cpu, -failfast, -fullpath, -list, -outputdir, -parallel, -run, -short, -skip, -timeout and -v. If a run of go test has any test or non-test flags outside this set, the result is not cached. (中略) The idiomatic way to disable test caching explicitly is to use -count=1. Tests that open files within the package’s module or that consult environment variables only match future runs in which the files and environment variables are unchanged. ...