§2023-12-03

以前からエラーログに出すバックトレースが気になっている。どの場所のバックトレースを出すかについて次の選択肢があるように思えるからだ。

  1. エラーの発生箇所
  2. ログの出力箇所

1番目と2番目のどちらを選ぶべきだろうか。もし両者の場所が常に一致するなら悩む必要はない。だがウェブ API のエラーについてレスポンス時にログを出力するとなると一致は望めない。ここに悩みの余地がある。おそらく不具合調査で重要となるのはエラー発生箇所の方だろう。選ぶならこちらだ。しかしログ出力箇所の方を不要と言える自信まではない。

確信を持って選べないのであれば両方を出してみてはどうか。調査観点では情報が増えて困ることもないだろう。もちろんログの格納や検索に要するコストとのトレードオフはある。もしコストを許容できないならログ出力箇所は捨てる他ないだろう。ではコストを許容できて両方をログに出すことにしたとして、どのように出すのが良いだろうか。

ログ構造のベストプラクティスというのはあまり聞き覚えがないが、一つだけ参考資料に心当たりがある。OpenTelemetry Logging 仕様の Logs Data Model だ。 見ると Semantic Conventions for Exceptions in Logsexception.stacktrace という属性の記載がある。これはエラー発生箇所のようだ。一方でログ出力箇所についての記載は見当たらない。

仕様にこそログ出力箇所の記載はないが Appendix A. Example MappingsZap の項caller フィールドの記載がある。どうやらログの出力箇所は Attributes すなわち追加情報の一つとして扱われるもののようだ。

Example Mappings の Zap 以外の項にはログの出力箇所と思われるフィールドは見当たらなかった。ログの出力箇所は思った以上に重要性が低い情報なのかもしれない。

§2023-10-09

独自のプログラミング言語を作りたいという欲求はあまりないが、独自の設定言語が欲しいという要求くらいならあるかもしれない。といっても実際は JSON, TOML, YAML のいずれかのサブセットで済ませてしまいそうだ。となるとサブセット用のコード補完機能が欲しくなってくる。コード補完の手段と言えば今なら LSP だろうか。

JSON, TOML, YAML それぞれの Language Server が JSON Schema に対応してくれていれば話は簡単に思える。調べてみたところ全て対応されている。知らなんだ。

あるいは Language Server 生成機能つきのパーサジェネレータなんて楽しいかもしれない。探してみたところ langium が近そうだった。世の中は進んでいる。

LSP とは関係ないが、見つけた中で最も風変わりだったのは Prong だった。初見の印象ではあまり使いやすくなさそうにも思った。ただ vega-stylervega-lite-debugging といった例を見ると、既存の設定を少しだけ手直しするといった用途なら悪くはないのかもしれない。

§2023-08-26

最近になって The Grammar of Graphics という本の存在を知った。著者は SPSS で統計グラフィックシステムを開発していたらしい。

SPSS社で、Wilkinsonは画像プログラマーを組織化しnViZnプラットフォームを開発した。 nViZnは、SPSSやClementineなどの画像エンジンとして利用されている。nViZnプラットフォーム開発過程で構築された統計画像表示の概念は、The Grammar of Graphicsという本にまとめられ出版された。この本はのちに、フリーの統計ソフトであるRの画像パッケージであるggplot2や、スタンフォード大学のPolaris projectなどに大きな影響を与えた。

リーランド・ウィルキンソン - Wikipedia

The Grammar of Graphics を元にした仕事としては A Layered Grammar of Graphics がある。こちらの著者は ggplot2 の作者だそうだ。

ggplot2は、 統計プログラミング言語Rのデータ視覚化パッケージである。2005年にハドリー・ウィッカムによって作成されたggplot2は、リーランド・ウィルキンソンのGrammar of Graphicsの実装である。これは、グラフをスケールやレイヤーなどのセマンティックコンポーネントに分割するデータ視覚化の一般的なスキームである。

ggplot2 - Wikipedia

そして Vega-Lite: A Grammar of Interactive Graphics もこの流れを汲んでいるようだ。Vega-LiteVega の上に構築される高レベルの宣言型言語で、既存のものに比べてインタラクティビティに力を入れているらしい。Vega-Lite も Vega も記述には JSON を用いるが、Vega-Altair という Vega-Lite の Python バインディングのようなものもある。

これらには sum などの集計処理を行う演算子を備えているという特徴がある。見る限り便利そうではあるが、実装がナイーヴだと性能面で困りそうではある。では集計演算子入りの記述を入力として集計処理部分のみを実行し、集計演算子なしの記述を出力する仕組みがあれば良いのではないか、でも実装が面倒じゃないか、などと考えながらウェブをうろうろしていたら VegaFusion を見つけた。Example Gallery にある 10 Million Taxi Rides の速さなどはもう少し早く知っておきたかったし、不勉強が悔やまれる。

§2023-08-19

New Relic でダッシュボードを作る際は NRQL もしくは PromQL を使うらしい。NRQL は名前の通り New Relic 専用として、PromQL は Prometheus 由来のようだ。ベンダーニュートラルな選択肢があるのはそれだけで何となくありがたい。

しかしこれはどちらかといえば例外で、この手のクエリ言語は製品ごとにバラバラな印象がある。どうやら業界でも課題として認識されているらしく標準化の動きが存在していた。

The diverse range of query languages used in the observability field creates a significant pain point for DevOps professionals. Switching between languages such as Lucene and LogQL for logs, PromQL and InfluxQL for metrics, Jaeger and TraceQL for tracing, and other languages and telemetry signals, can be cumbersome and hinders productivity. The languages also vary dramatically in their conventions, utilizing different DSLs (domain-specific languages) and APIs, which further increases the divergence.

Streamlining observability: the journey towards query language standardization

成功を祈願しつつ Charter Document を眺めてみたら既存 DSL が中々の数だった。言われてみれば、という感じではあるがこんなにあったとは。

§2023-08-13

printf anti-pattern と呼ばれるアンチパターンがある。この名前が有名かどうかは分からないが、危険な書き方であること自体はよく知られているのではないかと思う。

Manipulating structured data formats using string functions.

The Most Expensive Anti-Pattern (邦訳: 最も割高なアンチパターン : 構造化されたデータを文字列関数で操作する「printfアンチパターン」について)

身の回りで陥りやすいのは SQL 文の組み立てくらいかと思いきや、GitHub Actions のワークフローもなかなかどうして危険だ。次の例が分かりやすい。

- name: print title
  run: echo "${{ github.event.issue.title }}"

Four tips to keep your GitHub Actions workflows secure

この例は見た目が echo "${title}" と似ている点にも不安を感じる。うっかりすると見落としそうだ。いっそ YAML に変数を埋め込む機能とシェルスクリプトを埋め込む機能の組み合わせは禁止すべきではないかとすら思ってしまう。actionlint で予防できるだろうか。