おお、なるほど。確かにそれは…。早く脂肪で動くようになって欲しいです。

4の電池交換の感覚でしたw でもなんか電池交換(と言うか電池劣化による本体交換?)を無料でやってくれると言う話も聞いたことがあり、そちらも気になってます。

自分は今年もまたBlack FridayとAmexで本体が$400引きになることを祈っております🙏

まだ調整中なんですが今のところ3月頭の予定です！

なるほど、そう考えるとGlobal Entryの方が潜在的なトラブルが少なくて良さそうですね。今日はMPCの方がGlobal Entryの3倍速くらいで通過してましたw

そうですね、そこら辺は全部plug-in的に拡張可能になっていて、"rules_<言語名>" と言う名称で再利用可能なmodule的に提供されていることが多いので探してみたら見つかるかもしれません。ただ、外部contributorによるものなので品質は言語ごとにマチマチです。最悪自分で書けば何とかなります(学習コストはかなり高めですが)。

Credential周りは最近追えてないんですが課題ではありますね。ただ、外部のCLIを使う際に強制的にwrapperを挟めたりするので、運用方法をチームで統一しやすい面はありそうです。

あと文字数の関係で先ほど書けませんでしたが、build周りに触れないユーザにとってもrepo内部ツールをbazel runするだけでbuildと実行を一度にやってくれるのも個人的に好きです。build手順を書く必要がなく、従来shell scriptやコンパイル不要な言語で書いていた内部ツールをGoやRustで書きやすくなりました。

個人的に大きいのは依存関係＆cacheの管理とhermeticityです。言語処理系が賢いbuild cacheを持っていなくてもbazelが代わりに管理するのと、何かを変更したときにその後続にあるtargetだけが並行に効率よくbuildされます。一般的なbuild toolの利点ですが、比較にならない水準で優れています。変更に関係するtargetだけテストする/tf diffを出すなども出来ます。

また外部ツールを含めて全てBazelで管理する思想なので、bazel buildすればどの環境でもローカル環境に依存せず同一の成果物が得られるhermeticな状況を維持しやすいです。

基本的に「バージョン管理された任意のexecutableを使って任意のinputから任意のoutputを生成するノード」で構成されたグラフ(edgeはinputなどのdeps)をcache込みで効率的に管理するツールなので何でもできます(極論)。

git worktreeとの噛み合わせの問題などまだ課題は多いんですが、Bzlmodの登場と移行が進んだことで数年前と比べてハマりどころが少なくなってます。数年前は確かに職人が必要でした。

BuckですがStarlark部分はある程度共有してるので結構知識やノウハウを相互運用できてます！

まさに既存のツールとのつなぎ込み部分を主体にやってるので苦労は分かるんですが、ruleを書くのもそこまで大変ではないのとrule化できたときの恩恵が大きいので、個人的にはBazel的な世界観に寄って行って欲しいなあと思ってます。

うまい店も多いんですけど、特に東アジア料理は悲惨ですよね。中国語話してる中華料理屋の安心感が異常。調理方法や屠殺方法の前提が違いすぎるんですかね。