[B! 設計] t-cyrillのブックマーク

AWS システム構築非機能要件ヒアリングシートを公開してみた | DevelopersIO

こんにちは。ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きなネクストモード株式会社の吉井亮です。日本国内においても多くのシステムがクラウド上で稼働していることと思います。俊敏性、拡張性、従量課金、IaS、セキュリティなどクラウドのメリットを享受しやすい所謂 SoE で多くの実績があるように感じます。ここ1~2年は、社内基幹システム・情報システム、SoR 系のシステムのクラウド移行が本格化してきたというのが肌感覚であります。クラウドでのシステムインフラ構築は従来のようにゼロから非機能要件定義を行っていくものではなく、ベストプラクティスをまず実装して少しずつ微調整を行っていくものと考えています。とはいえ、システムごとの要件は予め明らかにしておくことがインフラ構築においても重要になります。クラウド上では出来ること出来ないこと

t-cyrill 2020/07/28

便利情報だ

設計

リンク

Qiitaのランキングの最初の設計者としての「いいね」の設計と、「LGTM」は下においてほしいという話 - mizchi's blog

https://blog.qiita.com/like-to-lgtm/ Qiitaさんの変更。思想はまぁわかるものの、「全部読んでから押してほしい」といいながら、開いた直後に押せるところに配置するのは意味がわからないかなあ。https://t.co/HEtwKg0txr— chokudai(高橋直大)🌸🍆🍡 (@chokudai) 2020年3月12日これについては chokudai さんに完全に同意なのですが、その理由として、自分の在職時に企画したサービス設計意図が強くあって、退職者がそれについて今更どうこういうのはどうか思うところもあるのですが、当時の同僚がほぼ全員退職してしまっているため、ここでその意図を伝えます。お前は誰 & 何当時の Qiita の開発で、ストックといいねを分離して、いいねをベースにしたランキングの実装のを提案したのが自分です。社内の Qiita:

t-cyrill 2020/03/13

こういうのが読みたい

リンク

Microservices時代の監視設計 - An Epicurean

前のエントリの続きです。思ってた以上に反響があったので、主語を控えることも検討しましたがこのまま行きます。前回同様、すでにMicroservicesでバリバリやっている人は読む必要ないと思います。前回の最後にMicroservices時代になると、開発者がこれまで以上に監視に取り組んでいく必要があると言う話を書きました。多少重複するところもありますが、その辺りから話を始めます。モノリシック世界観での監視アプリケーション監視の浸透 Microservices時代の監視設計開発者自身が監視するどう監視するかメトリクス設計 The Four Golden Signals USEメソッド REDメソッド USEとREDの補完関係 The Four Golden Signalsの素晴らしさ例: ある認証コンポーネントの監視設計まとめモノリシック世界観での監視 Webサービスの構成が

t-cyrill 2019/04/13

わかりやすい

リンク

Kubernetes 運用設計ガイド / A design guide for Kubernetes in production (Japanese)

2018/04/19 JAPAN CONTAINER DAYS V18.04 (https://containerdays.jp/) にて発表したものを加筆修正しました。 Abstract: Kubernetes は豊富な機能とその高い拡張性により、現実における様々なユースケースに対応できる一方、その多機能さゆえにどう使えば良いか迷っている方もいると思います。Kubernetes の基本を学んだ人や本番運用を始めた人を対象に、私がメルカリでの Kubernetes 本番運用経験を元に考えた、アプリケーション運用、インフラ運用、組織の 3 つの観点での設計の指針を紹介します。

t-cyrill 2018/04/24

リンク

プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!

今やどんなビジネスでもITが関係している。ITを支えているのはソフトウェアだ。あらゆるものがソフトウェアで実現される時代になった。そんな事業や生活に密接に関わるソフトウェアだが、その開発について知られていないことも多い。とくに経営者がプログラミング経験がないことで、ソフトウェア開発のリーダーシップをとるときに的外れなマネジメントをしてしまうことがある。あまねく経営者がプログラミング経験があれば良いのかもしれないが、それは現実的ではない。プログラミング経験がなくても、せめてソフトウェア開発の特性について知っておくと良さそうなこともあると思い、なるべく専門用語を使わずに本稿を書いた。プログラミングは製造ではなく、設計であるいまだにソフトウェア開発を、ビルや家屋の建築に喩える人がいるし、工場でモノを製造するようにプログラムが作られると思っている人もいる。ここが間違いのもとだ。ハードウェ