GitHub - k1LoW/ndiag: ndiag is a high-level architecture diagramming/documentation tool.You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Design Docs のいけすかなさ / morrita - Message Passing
Design docs というのが昔からあまり好きでない。読むのも書くのも好きでない。 仕事で文書を書くのはやぶさかではないけど Design docs はなんとなくいや。 せっかくなのでこのイヤさを言語化してみたい。 Design Docs とはなにか 自分が想定している Design docs は この文章が説明しているようなものだ。 なにかそれなりの規模があるものを作る時に設計やそのトレードオフをざっと文書化する文書。 もっというと一般名詞の design docs ではなく、リンク先に書いてあるような自分の勤務先固有の The Design Docs 文化が好きでない。 「設計やそのトレードオフをざっと文書化する。」 それだけ聞くと割と良いもののような気がして、自分もある時期までは良いものだと思っていた。 「ドキュメンテーション」というのは、プログラミングのポップカルチャーにおいて
Design Docs at Google
One of the key elements of Google's software engineering culture is the use of design docs for defining software designs. These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project. The design doc documents the high level implementation strategy and key design decisions with emphasis on the trade-of
[レポート]レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡 #DDDAlliance ｜ Developers.IO
こんにちは。プロダクトグループのshoito(しょいと)です。 9/26(水)に開催された レガシーコードにドメイン駆動設計で立ち向かった5年間の軌跡 に参加してきたのでレポートします。 当日のtwitterのハッシュタグ#DDDAllianceのツイートがTogetterでまとめられています。 BIGLOBEにおける、5年間のDDDへの取り組みと今後について ビッグローブ株式会社 西 秀和さんより 30年間、事業を支えてきた業務システムをDDDで刷新する。 そのためには、組織的、エンジニアのレベルなど多くの問題があります。 その壁をどう乗り越えたのか？ そして、壁の向こうで得た恩恵とは何のか？ 5年という期間を経て、得ることのできた気づきや組織的な変化をお伝えしたいです。 アジェンダ DDD導入に至るまで 導入時の苦労 導入による効果 今後の目標 BIGLOBE販売システムについて、DD
![[レポート]レガシーなコードにドメイン駆動設計で立ち向かった5年間の軌跡 #DDDAlliance ｜ Developers.IO](https://cdn-ak-scissors.b.st-hatena.com/image/square/ca7afdf4d75f0e7f31dad0cb5f52f15acfa79209/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2018%2F09%2FDDD_blue.png)
分散キューという名の苦しみ - Software Transactional Memo
TL;DR 分散システムにおいてキューを導入する場合、本当にキューが必要なのか再考すべき。そこが地獄の入り口だから。 システムの抽象 コンピュータの世界は、本来は0と1の信号の羅列が飛び交う無機質なものである。でも人類は信号だけですべてを語らず、様々な喩えを定義してきた。それはデスクトップ・ウィンドウ・マウスカーソルといったグラフィカルな表現に留まらず、パケットやカプセル化といった用語にロック・キュー・リスト・木などのアルゴリズムやデータ構造の世界にも自然に溶け込んでいる。これらはすべて人間の理解を助けるための喩え話に過ぎず、この喩えこそが人間のより直感的な理解をもたらす一方で、発想の制約を生み出してきた。 人間が大きなシステムを作るときも何らかの喩えを用いてシステム全体を整理する。アーキテクチャの「ポンチ絵」を描いて情報共有をするのは企業に勤めていれば経験した人も多いだろう。パワーポイン
分散ロックという名の過ち - Software Transactional Memo
 TL;DR; 「分散ロック」が分散システムの設計図に登場した時 だいたいその設計は間違っていて本当に必要なものはトランザクションだ 並行システムを実装する際にロックを用いるのはとても自然なことだ。 僕も普段はロックフリー系のアルゴリズムに詳しいと言われがちだが知識量でいったら実はロック系の方が多く蓄えているかも知れない。 分散システムは並行システムであることが多いので、その中にロックが登場するのはとても自然な発想である。 よく「分散」「並行」「並列」の言葉の定義がごっちゃになっているケースがあり、この記事の主題にしたいわけではないので深くは言及しないが、分散システムは環境などの要因で突如として参加者が音信不通になったり復活したりする点で並行システムと大きく異なる。 並行システムと同じノリで分散システムを設計しようとした際に陥る頻出の過ちが「分散ロック」である。そのアイデアはとても簡単で
サーバーレスアーキテクチャのパターン別ユースケース - yoshidashingo
セクションナイン の 吉田真吾（@yoshidashingo）です。 昨今のサーバーレスアーキテクチャの実装パターンについて5つの分野でユースケースをまとめました。 実装方法はAWSがベースですが、クラウド各社のFaaSに大きな機能差はないので(そもそもシンプルなコンセプトなので)、FaaS単体よりも、連携可能な周辺サービスまで含めて自分のアプリケーションのユースケースに合っているかどうかが大事になってきます。また、そもそもいくつかの実装はPaaSのオプション機能として組み込まれている場合もあります。よって、この先連携先の機能強化などによってもっと多くのパターンが発見されることになると考えています。 【1】Webアプリケーション シングルページアプリケーション ex. Serverless Single Page Apps Web API REST API GraphQL 非同期Webジョ
時系列データベースという概念をクラウドの技で再構築する - ゆううきブログ
サーバ監視サービスMackerelにおいて開発中の、高解像度・長期間のサーバメトリック収集を実現するための新しい時系列データベースDiamondを紹介します。具体的には、Amazon ElastiCache、Amazon DynamoDB、Amazon S3を組み合わせ、Amazon Kinesis StreamsとAWS Lambdaによりコンポーネント間を接続した、階層構造のデータストアアーキテクチャの設計と実装を解説します。 2018/06/05 追記: この記事の内容をWSA研#2でより一般的なアーキテクチャレベルでの貢献として書き直しました。 サーバレス時代におけるヘテロジニアス時系列データベースアーキテクチャ - ゆううきブログ はじめに 先日開催されたAWS Summit Tokyo 2017にて、「時系列データベースという概念をクラウドの技で再構築する」というタイトルで登壇
Serverless Anti-Patterns
1. Serverless Anti-Patterns Keisuke Nishitani (@Keisuke69) Amazon Web Services Japan K.K. Mar 09, 2017 Photo via VisualHunt.com 2. Profile Keisuke Nishitani Specialist Solutions Architect, Serverless Amazon Web Service Japan K.K @Keisuke69 Keisuke69 ✤ RESTおじさん ✤ 餃⼦の王将エヴァンジェリスト（⾃称） ✤ ⾳楽が好きです、フジロッカーです、今年も⾏きます ✤ ブログ: http://keisuke69.hatenablog.jp/ Keisuke69 Keisuke69Keisuke69x
#yapc8oji 得票数4位トーク「あの日見たM V WhateverのModelを僕たちはまだ知らない」実況中継 - Re.Ra.Ku tech blog
丸山です。ヤパチー、最高に楽しかったですね。スライドの公開はしたのですが、正直重要なことは全部口頭で説明していて、スライドには情報が少ない。しかし、動画を見るのは正直だるい。40分もPCの前で集中して映像を観れないですよね。知ってる。というわけで、受験参考書の「実況中継」シリーズ（知ってます？）方式で、プレゼンをブログで再現します。長いぞ。でも多分動画見るよりははやく読み終われる。ぜひ読んでいってください。 アバンパート 今日はこういうトークをします。 簡単に自己紹介すると、こういうものです。 息子紹介です。かわいいですね。 WEB+DB Press 91号では特集を、92号ではPerlHackersHubに記事を書かせてもらいました。もう原稿料いただいてるので、もうこれ買ってもらってもわたしには一銭も入らないんですけど、いい雑誌なので買ってないひとはぜひ買って読んでください。 まずMVW
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
技術選択とアーキテクトの役割
特定のプロジェクトがあり、要件定義をし概要設計をする。 それがアーキテクトの仕事だと思われがちですが、大きな視点を持ち様々な課題を自らリードして解決していく立場としても絶好のポジションです。 このセッションでは、Mobage オープンプラットフォームの立ち上げから、 グローバルプラットフォーム展開、さらには mixi 社との共同プラットフォーム構築、 JavaScript SDK と認証技術の組み合わせによる新しい HTML5 プラットフォーム構築をアーキテクトという立場でリードし続けた立場から、技術選択のみならず実現したい事に対する俯瞰的な捉え方を、これまでの実例と共に紹介し、アーキテクトという役割について、お話します。Read less
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Design Docs の逡巡- Message Passing
https://nocomplexity.com/documents/arplaybook/index.html
The Amazon Builders' Library
[AWS Start-up ゼミ] よくある課題を一気に解説！〜御社の技術レベルがアップする 2017 夏期講習〜![[AWS Start-up ゼミ] よくある課題を一気に解説！〜御社の技術レベルがアップする 2017 夏期講習〜](https://cdn-ak-scissors.b.st-hatena.com/image/square/5ddbca4f64dae3e3403f0885ce5c19d689e85ed7/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fawsstartupzemi-2017summer-170816032526-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
フロントエンドに対するAPIバックエンドの提供パターン
これからの Microservices
Fluxアーキテクチャの覚え書きを書いた - saneyuki_s log
Facebook の決断：MVCはスケールしない。ならば Flux だ。
