はてなブックマーク

2024年6月30日に今の会社を退職し、翌7月1日から別の会社に入社することになった。 現職の在籍期間は大体３年弱ほどで、アーキテクチャを中心とした技術的な意思決定も色々してきた。新規構築から運用までやってきた中で感じたことや経験豊富なエンジニアからいただいたアドバイスなど、それらを含めて当時の意思決定の反省を自戒を込めてここで書いておく。 Table of Contents 留意事項 やったこと 想定効果 基盤チーム側の効果 サービス開発（基盤のクライアント）側の効果 意思決定 技術スタック コード管理 インフラ その他 所感と教訓 コンポーネントとリポジトリの粒度は別 複雑性を犠牲にする決断の重さ（マルチクラウド、マイクロサービス etc.） 共通基盤を初めから独立したサービスとしてデプロイしないのもあり サブシステムとしての共通基盤にどこまで粗結合を求めるべきか考える 結論：後から分

2023/7/12にGithub Merge QueueがGAになりました。 https://github.blog/changelog/2023-07-12-pull-request-merge-queue-is-now-generally-available/ 機能のパッと見はPRをただキューに積んでくれるだけで「何が嬉しいんだろう？」と思う人も多そうなので、何が嬉しいのか事例付きで紹介できればと思います。 TL;DR 「PRの時点ではコンフリクトも無いしCIも通っているがマージしたらCI落ちた」というのが割とよくある 上記の対策として「マージ前にmain rebaseしてCIを再度回し、問題無いことを確認してからマージする」という作業を手動で行うしか無い Merge Queueを使用することでマージ後のCIチェックを自動化し、問題ある場合はマージせずに差し戻すことが可能になる Tab

こんにちは、@ymtdzzzです。 この記事はOpenTelemetry Advent Calendar 2022の16日目の記事です。14日目はlufiabbさんの「Goで実装したアプリケーションのメトリックをOpenTelemetryで計装する」でした。 今回はpropagatorを自前で用意してキューを挟んだ非同期処理をトレースする方法について見ていこうと思います。 Table of Contents モチベーション サンプルケース 課題 ではどうすればいいのか RabbitMQ用のpropagator実装 propagatorの仕組み propagator実装 送信側の実装 受信側の実装 トレースできた🎉 おわりに モチベーション 最近所属会社ではSLI/SLOの導入が進んでいますが、基盤系システムをきちんと計測してSLOに落とし込むのが難しく感じています。 例えば通知システムの

EmacsのLSP-modeは非常に快適で、言語サポートの追加も簡単にできるので重宝しているのですが、動作がカクついたりしてストレスになる場合がありました。ドキュメントを確認したところ、パフォーマンスチューニングの方法があったのでまとめておきます。 いざチューニング 今回対応するチューニングが正常に適用されているかどうかは、 M-x lsp-diagnose で確認できます。 Checking for Native JSON support: OK Checking emacs version has `read-process-output-max': OK Using company-capf: OK Check emacs supports `read-process-output-max': ERROR Check `read-process-output-max' default