令和になってもマックでシャカチキを頼む 
id:arthur-1 です。
買ったまま放置して冷めてしまったシャカチキを電子レンジで加熱したい、そんな経験はありませんか？
この時に、加熱した後に粉をかけてシャカシャカしようとするのはアンチパターンです。
なぜなら、油で紙袋がふやけてしまい、シャカシャカした時にチキンが第二宇宙速度で飛び出してしまうから（n敗）
冷たいうちに粉を掛けてシャカシャカを楽しんでから電子レンジに入れましょう。
アグリコラ：15周年記念BOX の誤訳指摘・おもしろ情報
恒例のやつです。今回はおもしろ情報もあります。とりあえず速報として出してゆっくり加筆修正する予定。
今までの例だと独・英語版が出てから1年以上間が空いてしまっていたので、日本語版をスピーディに出していただけるのありがたいですよね。
id:arthur-1 はドイツ語版と英語版を所有しているので、それら製品との比較となります。
変更履歴
ルールブック
まだ読んでません。チラッと今回追加される拡張のところは目を通して大丈夫そうでした。
ゲームボード
- （表記揺れ）「粘土坑」が相変わらず漢字間違ってました。修正シール配布してほしい。
カード
よかったところもあって、A・B デッキのこれまでのエラッタは反映されていそうでした。全ては確認していないのですが、[B114*] 子なしが日本語版のエラッタ後になっていたり、[B104*] 夢遊病者が農場の羊だけしか変換できないようになっていたり、などの修正が見受けられました。
また、リバイズドエディション基本セットに含まれていたカードの文字が大きくなりました。おそらく今回追加された[L097] 植字工のことを考えるとやらざるを得なかったのだと思いますが、嬉しいですね。
[X03] 変換機
- （原文エラッタ） 品物の定義について「食料、建設資材、家畜はすべて品物とみなす」とある。農作物（小麦・野菜）について言及されていないが、ただの見落とし。ドイツ語原文の時点ですでに見落とされている*1
- これは変換機に限らず、今回のセットに含まれるカードで同じようなミスが見受けられる
[X06] 冥王星の商人
- （表記揺れ） アクションスペース「柵」は「柵設置」という名称に変更されたはずだが反映されていない。
- ちなみに、ラウンドカードの方も修正されていない
[X10] レプリケーター
- （誤訳） 「このカードは自分の前に置かず、左隣のプレイヤーの手札に入れる」とあるが、手札ではなく、左隣のプレイヤーの前に置く（つまりプレイ済みの状態とする）のが正解
- （誤訳） 「品物1種類につき、追加で同じ種類の品物を1つずつ得る」とあるが、1種類につきではなく、品物1つごとにもう1つもらえる *2
- 例えば、累積スペースから木材3を取った時に、レプリケーターからもらえる木材は1つではなく3つである
[X12] フサフサの友人
[X14] 地球人は簡単
- （表記揺れ）「西の石切場」→「西の石切り場」
[X22] 炭素冷凍のいとこ
- （表記揺れ）「開始プレイヤー」→「スタートプレイヤー」
[L097] 植字工
（おもしろ情報）
英語版とドイツ語版で意図的に効果が違うカード。日本語版はどうなるかと注目の的となっていました。
結果は英語版と同じ「6行未満」でした！自身が含まれないように頑張って改行しているのが微笑ましいですね。
ちなみに、このカードの条件の数字は、カード全体の集合のうち44%が対象になるように調整したものになっているそうです。日本語版でどうなっているかは要検証ですね。
パイオニアチャレンジ
という遊びをたまにやっている。MtG は全く関係なく、自分が Twitter に投稿しようと思ったネタツイを検索して、世界で初めてそのネタを思いついた人間かどうかを確かめるというものだ。
今日は「i~cloud~~」と歌う華原朋美がふと脳内再生されたので早速検索してみた。
こんなレベルではお話にならない。パイオニアチャレンジ失敗である。
自分の Twitter の履歴を検索しても、失敗した例はあれど成功した例は一つもない。凡才なので仕方ないね。
ヒマダダイチ #パイオニアチャレンジ失敗
— Arthur (@Arthur1__) 2022年12月29日
これパイオニアチャレンジ失敗してるのか、世界は広い https://t.co/Q7ugXUWsXB
— Arthur (@Arthur1__) 2021年5月13日
FY2023上半期を振り返る・広く浅く
こんな形で今後も public な振り返りを定期的に書いていきたいですね。
ということで、2022年8月〜2023年1月の振り返りを書いていきます。
幅広い技術とコンポーネントに触れた
Mackerel は多くのコンポーネントから構成されています。Web のフロントエンド・バックエンドはもちろんのこと、裏には内製の時系列データベースがいたり外形監視やクラウドインテグレーションを実現するためのクローラーがいたりします。OSS として公開しているアプリケーションもたくさんあります。
サブコンポーネントに詳しいアプリケーションエンジニアや SREs と一緒のチームで働く利点を活かして、これら多くのソフトウェア・インフラに幅広く触れることができました。
今では自分がチームの中で相対的に、より細かい挙動・仕様を知っているコンポーネントや機能もあります。また、可観測性やコスト面を改善するアーキテクチャの提案もできました。最近の話だと、mackerel-agent の Windows での挙動について調査したり改修したりしています。問題を見つけ、取り組める形に分解するところまでは比較的できているので、今後は手早く安全に問題を解決し、価値を届ける力を身につけたいです。
技術面で言うと、Go 言語や Terraform が全く触れない状態から、ある程度のものを作ったりエコシステムを理解できている状態にすることができました。これは普段のチームの仕事だけでなく、開発合宿や個人開発でも積極的に触れることで身につけることができました。
コードレビューできるようになってきた
この半期はコードレビューの量・質を高めることを目指し、エンジニアメンターと目標設定をして取り組みました。上記で示したように幅広い範囲をキャッチアップできたこともあり、目指した通りにレビュー力を上げることができました。
これは index が張られたようなイメージで、「このレビューをするために見なければならない情報はここにある」という知識が脳の引き出しに入っていて、それを取り出してレビューするのにかかる時間を短くすることができました。
「良い設計」に関してはテックリードの考える所にはまだまだ遠く辿り着けていないなあと思っています。「安定したコードが不安定なコードに依存してはならない」と言うのがシンプルに本質を表す金言だなと感じていて、この言葉を噛み締めて開発に取り組んでいきます。
「監視」が分かってきた
入社してすぐの、グラフ定義で選べる単位を追加する*1というタスクに取り組んでいた頃は、監視というドメインへの理解がかなり浅かったなと思います。Mackerel の中の一機能への理解と、それを実現する技術のキャッチアップで精一杯でした。
日々の仕事の中で、自分が開発者として何をどう監視したいかと言うイメージが湧いてくるようになりました。こういったものを可視化したい、監視したい！と思い、メトリック化したりダッシュボードを整備したり、と言う動きもできました。
そうやって Mackerel を利用する主体になって初めて、Mackerel に対する夢・アイデアがどんどん膨らんできました。ユーザー目線に立って、PBI (Product Backlog Item) が生み出す価値について言語化したり、価値を理解した上で実現方法を取捨選択することもできました。
社内/外のアウトプット
社内向けのアウトプットにしては、自分が選んだ選択や仕事で行った創意工夫のベースにある思考を言語化して共有する機会がありました。また、ほたてに小ネタを持ち込んだり、Slack で技術に関する議論を巻き起こしたりなど、アウトプット・情報交換の場を盛り上げることも併せてできたかなと思います。
社外に関しては、Mackerel Advent Calendar 2022 の運営と、参加者としてエントリを投稿したのが一番大きかったです。まとめエントリも書きましたので、Mackerel ユーザの方はぜひお読みください。
また、先日開催された Hatena Engineer Seminar に登壇しました。先ほど Mackerel に対する夢について書きましたが、Mackerel チームの夢の膨らませ方とその実現について話したので、よろしければご覧ください。
まとめ
総括すると、広く浅くさまざまなことに取り組んだ半期だったなと思います。来期どういう風に生きたいかはまだあんまり考えていないのですが、とにかく価値提供したい、という気持ちが今は強いです。
そしてありがたいことに、半期末の納会で新人賞を頂きました。来期も頑張ります。
*1:cf.) 時間やネットワークトラフィックの単位が追加された Mackerel でネットのスピード監視 - Diary of a Perpetual Student https://blog.arthur1.dev/entry/2022/12/01/000100
パフォーマンスだけを考えると WMI を使わないほうが良いのかもしれない
OS 名は WMI から取得したほうが良いが……
前にこんなエントリを書いた。
このエントリを要約すると、「Windows の OS 名を取得するとき、レジストリにアクセスするのではなく WMI を使って取得しよう。なぜなら、Win 11 が Win 10 として認識されてしまうから」という内容である。
mackerelio/mackerel-agent には、WMI を利用せずに基盤の情報を取得している箇所がいくつかある。たとえば、レジストリの値を参照していたり、dll を読んで Windows API を呼び出したりしている。こういった場所も WMI に置き換えたほうが良いのだろうか。
それは、現状持ち合わせている情報では分からない、というのが誠実な答えになるだろう。OS 名に関してレジストリの値が信用ならないことは分かったが、それが一般に成り立つとは限らない。
Windows の細かい話は素人にはよく分からないので総合的な良し悪しはあまり語れないが、今回はわかりやすいパフォーマンス面での比較をしようと思う。
パフォーマンス比較実験
実験のために書いたプログラムは以下のリポジトリで公開している。
実験設定
比較対象は3つの手法である：
この3つの手法それぞれで同等な情報を得られるものを探した結果、プロセッサのアーキテクチャを取得させることにした。
各手法の実装は、mackerelio/mackerel-agent で利用している util パッケージを import する、もしくは同等のコードを書くことによって行った。
ベンチマークには Go 言語に標準で付随する testing パッケージの Benchmark を利用する。
比較対象は、自分所有の PC *1において以下のコマンドで benchmark を実行したときに表示される ns/op （関数1実行あたりにかかったナノ秒）である。
go test .\windows\ -bench .
実験結果
上記コマンドを実行すると、以下のような出力が得られた。
> go test .\windows\ -bench .
goos: windows
goarch: amd64
pkg: github.com/Arthur1/windows-api-benchmark/windows
cpu: 12th Gen Intel(R) Core(TM) i7-12700F
BenchmarkGetProcessorArchitectureFromApi-20 1000000000
--- BENCH: BenchmarkGetProcessorArchitectureFromApi-20
windows_test.go:9: 9
windows_test.go:9: 9
windows_test.go:9: 9
windows_test.go:9: 9
windows_test.go:9: 9
windows_test.go:9: 9
BenchmarkGetProcessorArchitectureFromWmi-20 1000000000 0.01329 ns/op
--- BENCH: BenchmarkGetProcessorArchitectureFromWmi-20
windows_test.go:14: 9
windows_test.go:14: 9
windows_test.go:14: 9
windows_test.go:14: 9
windows_test.go:14: 9
windows_test.go:14: 9
windows_test.go:14: 9
BenchmarkGetProcessorArchitectureFromReg-20 1000000000
--- BENCH: BenchmarkGetProcessorArchitectureFromReg-20
windows_test.go:19: AMD64
windows_test.go:19: AMD64
windows_test.go:19: AMD64
windows_test.go:19: AMD64
windows_test.go:19: AMD64
windows_test.go:19: AMD64
PASS
ok github.com/Arthur1/windows-api-benchmark/windows 0.782s
この結果を見ると、Windows API や レジストリを用いる手法では ns/op が表示されないほど短い時間で実行できているが、WMI を用いる手法だと1実行あたり 0.013 ns ほど掛かっているということが分かる。
どこで詰まっているか（詰まっているというほどではないと思うが）気になったので、pprof を使って詳しい様子を観察してみた。概ね、WMI にクエリを投げるのに相当するシステムコールに時間が掛かっている、といったところだろうか。
まとめ
今の mackerel-agent の実装をすべて WMI を使う形に置き換えればいいじゃんと思っていたのだが、パフォーマンスを比較すると WMI が劣っているということを知った。劣っているといっても 0.1 ns にも満たない程度なので、（クエリにもよるだろうが）通常の利用の範囲では問題ないように感じる。
つまり、安定して情報が取得できるか、得た情報が正しいかどうか、などの他の軸に重きをおいて手法を評価したほうが良いということになる。冒頭に紹介したエントリでは得た情報の正しさを鑑みて WMI を選択したが、それに関しては良い選択だったのではないかと思う。
Windows に詳しい人はぜひいろいろ教えてほしい。
