このツールは、全体的な傾向を把握するためのもので、意図的に不正確な指標になっている。そのため個人の仕事のパフォーマンスを評価するために使ってはいけない。
![DevOpsカルチャーのKPI - kawasima](https://cdn-ak-scissors.b.st-hatena.com/image/square/d777b269771fcdc3ceef7e29a87190beed3dbf63/height=288;version=1;width=512/https%3A%2F%2Fscrapbox.io%2Fassets%2Fimg%2Fcontent-logo.png)
このツールは、全体的な傾向を把握するためのもので、意図的に不正確な指標になっている。そのため個人の仕事のパフォーマンスを評価するために使ってはいけない。
POSAでの定義 レイヤードアーキテクチャを、体系だって書いたのは「Pattern-Oriented Software Architecture, Volume 1, A System of Patterns」だろう。まずはその原典に立ち返って、レイヤードアーキテクチャとは何かをみてみる。 コンテキスト ソースコードの変更がシステム全体に波及させたくない。それが1つのコンポーネントに閉じられ、他に影響を与えないようにすべきだ。 インタフェースは安定している。標準化団体によって規定されている場合もある。 システムの一部は交換可能である。コンポーネントはシステムの他の部分に影響を与えることなく、実装を入れ替えることができる。 現在設計しているシステムと同様の下位レイヤの課題をもつ他のシステムを、将来構築することがあるかもしれない。 理解のしやすさと保守性のために同じ責務はグルーピングしておきた
Microserviceの分割の仕方について語られているものを収集します。 microservices.ioのサイトに載っている分割パターンは4つ。ただし「自己完結型サービス」と「チームごとのサービス」は、直交していないので大きくは「ビジネスケイパビリティでの分割」と「サブドメインでの分割」の2つ。 ビジネスケイパビリティでの分割 https://microservices.io/patterns/decomposition/decompose-by-business-capability.html 現在の業務機能にしたがってサービスを分割する。 したがって、コンウェイの法則にしたがった分割とされる。 サブドメインでの分割 https://microservices.io/patterns/decomposition/decompose-by-subdomain.html DDDのサブドメ
#翻訳 https://www.scalyr.com/blog/the-10-commandments-of-logging/ CC BY 4.0 @Brice Figureau 1.自分でログの書き出しをしない printfをつかったり、ログエントリを自分でファイルに書き出したり、ログローテションを自分でやったりしてはいけない。運用担当者にお願いして、標準ライブラリやシステムAPIコールを使うようにしよう。そうすれば、実行中のアプリケーションが他のシステムコンポーネントと適切に連携して、特別なシステム設定なしに適切な場所またはネットワークサービスにログを記録できるようになる。 ロギングライブラリを使いたければ、特にJavaの世界にはLog4j, JCL, slf4j, logbackなど多くのものが存在する。私はslf4jとlogbackを組み合わせて使うのが好きだ。とてもパワフルで、設
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く