OpenTelemetryのトレースシグナル取得をする上で、ユーザーの属性に応じてサンプリングを調整したいことがある。たとえば以下のような具合だ。 userType=freeの場合は1%サンプリング（1%拾い、99%は廃棄） standardなどほかのuserTypeの場合は全サンプリング（全部拾う） テールサンプリングかな？と思うところだが、これは少々問題がある。 tail_sampling: decision_wait: 10s policies: - name: free_sampling type: and and: and_sub_policy: - name: match_free type: ottl_condition ottl_condition: span: - attributes["userType"] == "free" - name: probabilistic

@matsuuさんのポストより。 x.com Docker Hub、2025/03/01から認証なしでのimage pullはIPアドレス毎に1時間あたり10回までに制限。認証してもPersonalはアカウント毎に1時間あたり40回まで。まじかよ。いよいよ厳しくなってきたな。 / “Usage and limits” https://t.co/hJWuR41b9G— matsuu (@matsuu) 2025年2月23日 x.com これ、先ほどサイト確認したら書き変わってて、2025/03/01→2025/04/01になってた。 Personalアカウント上限も40回→100回 でも認証なしの10回まではそのまま。— matsuu (@matsuu) 2025年2月23日 これはつらい。 最近業務でトレーシングハンズオンをした折に、配布のために魔改造Jaeger HotRODデモをDoc

他者のGit管理下のプロジェクトに対して、ローカルでのビルドでpackage.jsonが変わってしまうとか、.rbenvでのバージョンが微妙なのでそこはいじったとかな場面で、うっかりコミット候補に入ってしまわないよう注意深さを必要とするのが、地味に手間だった（怠惰）。 .gitignoreのローカル向けの.git/info/excludeは未コミットのものを最初から除外しておくものなので、すでに追跡されているもの向けではない。 サブコマンドで何かあったような気が……と探したところ、skip-worktreeサブコマンドを使うのが良いようだ（記事ありがとうございます）。 qiita.com 最初。 $ git status On branch main Your branch is up to date with 'origin/main'. Changes not staged for c

ITエンジニアリングに対する理解が深く、開発チームと（embededレベルで）密接に連携しながら、ユーザーに伝わるヘルプドキュメント・マニュアルを機能リリースと同期して出していく職種ってどうだろう、と妄想していた。 ＜妄想＞ プロダクトをよく理解していて開発チームにガッツリ入り、プランニング時点でドキュメント準備にかかる。デイリー報告やチーム議論に加わり、開発チームの言葉・デザイナーの言葉を咀嚼しながら、プロダクトユーザーへの伝わりやすさを常に考えてドキュメントを組み立てる。スプリントレビュー時点でドキュメントの作業を完成させ、機能リリースと同時にドキュメントも公開される。ドキュメントができていなければ、オーナーと協議して機能リリースを遅らせることもある。 ライティングや文章構成、ユーザーにとってのわかりやすさについて知見があり、ドキュメント関連に専念し、ユーザー視点での機能のわかりやすさ

OpenTelemetryのzero-code計装として公式に言及されているGo、.NET、Java、Python、PHP、JavaScriptについて、同系統の簡単なWebサーバーを立てながら試してきた。 kmuto.hatenablog.com kmuto.hatenablog.com kmuto.hatenablog.com kmuto.hatenablog.com kmuto.hatenablog.com kmuto.hatenablog.com 「簡単なWebサーバー」の作りがいろいろ大雑把だったので、フレームワークで作ったものだといろいろ出るし、基本ライブラリに近いコーディングだとあまり出ない。ORMなデータベースが絡めばサービス間通信っぽさが出るけど、別段不要な場合は自己完結で終わってトレースとしてはいまいち面白さはない（簡単なWebサーバーなのに、裏でデータベースアクセスを