はじめに オブジェクト指向の設計原則を説明します 勉強内容のアウトプットです 単一責任の原則 単一責任の原則は非常にシンプルな内容で、「1つのクラスに1つの役割(機能)」と言うものです。 これはカプセル化で強く言われる「小さなカプセル」ということに通じます。 ただ、この「1つのクラスに1つの役割」という考え方は正しいのですが、コレを正確に運用するのは非常に難しいです。運用が難しいというのは「1つのクラスに1つの役割」という言葉を指針としてしまうと思わぬ間違いを生むということです（言葉自体は正しいが、人間はアホなので間違っちゃうのです） そこで、クラスの妥当性をチェックするために別の角度から眺める必要が出てきます。この時の言葉が 「クラスを変更する理由が2つ以上存在してはならない」 という言葉です。この言葉は単一責任の原則の話で重要となる言葉ですので、覚えておいてください。 さて、あなたはあ
'HTTP_UPGRADE_INSECURE_REQUESTS'って何？（Upgrade-Insecure-Requests: 1） 問題 どうも最近 $_SERVER に $_SERVER['HTTP_UPGRADE_INSECURE_REQUESTS'] => 1 というのを見るようになったのですが、なんですかこれ。 答え httpsなページに移行していきたいときなどに役立つ仕組みとして、 httpリクエストヘッダに Upgrade-Insecure-Requests: 1 が入る仕組みがある。 → http://www.w3.org/TR/upgrade-insecure-requests/ → https://googlechrome.github.io/samples/csp-upgrade-insecure-requests/ httpsなページにアクセスしたときに、httpな
「Microservices時代の監視設計」と言うエントリーを書きたいのだけど、そもそもなんでMicroservicesで作る必要があるのかというところを先に書く必要があると感じたので私見を述べてみる。すでにMicroservicesで作っている人からすると「何をいまさら」と言う内容も多いかもしれません。 Microservicesでなぜ作るのか ドメイン分割のレイヤーの変遷 今は成長段階 Microservicesのメリットとアーキテクト クラウドはフレームワークになった 共有データベースアンチパターンとMicroservices設計 Microservices時代の監視設計 参考図書など Microservicesでなぜ作るのか 身も蓋もないことを書いてしまうと、これはもう「潮流がそうなっているから」ということだと思う。業界がそういうアプリケーションの作り方をしてノウハウを貯めていく流
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
