GitHub - schemaspy/schemaspy: Database documentation built easyYou 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
持続可能なデータベースドキュメント生成 | メルカリエンジニアリング
この記事は Merpay Tech Openness Month 2022 の17日目の記事です。 はじめに こんにちは。Credit Design Teamでバックエンドエンジニアをしている@tk8です。主にメルペイスマート払いに関わるマイクロサービスの開発や運用をしています。 この記事では、私のチームでの持続可能なデータベースドキュメントへの取り組みに関して紹介します。 背景 私が担当しているマイクロサービスでは歴史的経緯（*1)もあり複雑なスキーマ設計をしています。また、領域的にドメイン知識が複雑なものも多く、バックエンドエンジニアでもデータとスキーマの関連に関して理解が難しいことが多々ありました。 さらに私のチームではQAエンジニアやPMもデータベースに関するドキュメントを読むことがあり、不明点があれば都度詳しそうな人に聞いたり過去のSlackでの会話を調べたりするなど非効率な状態
【レポート】より快適、より安全なアプリケーションを実現する AWS エッジネットワークサービス(AWS-56) #AWSSummit | DevelopersIO
【レポート】より快適、より安全なアプリケーションを実現する AWS エッジネットワークサービス(AWS-56) #AWSSummit こんにちは！最近仕事もプライベートも忙しい日々を過ごしているつくぼし(tsukuboshi0755)です！ この記事では、2022年5月26日(水)に行われたAWS Summit Online 2022のオンラインセッション AWS-56『より快適、より安全なアプリケーションを実現する AWS エッジネットワークサービス』をレポートします。 皆さんは、AWSエッジネットワークサービスについて、どの程度ご存じでしょうか。 既に本番環境でバリバリ使用しているよ！という方もいらっしゃれば、AWSのエッジサービスを使う事で何ができるのかまだ良く分かっていないという方もいらっしゃるかと思います。 個人的に、最近CloudFrontやWAFを触る機会が多いため、一度AW
【レポート】SaaS の認証認可について改めて考える〜 アーキテクチャーパターンと実装例 〜(AWS-33) #AWSSummit | DevelopersIO
はじめに こんにちは。大阪オフィスの林です。 今回は2022年5月25 - 26日の2日間開催されているAWS Summit Onlineのセッションレポートをしていきます。 セッションのサマリーを理解し、興味があるセッションをチェックすることにご活用ください。また、セッションのアーカイブも公開されますので、詳細はそちらをチェックしてください。 SaaS の認証認可について改めて考える〜 アーキテクチャーパターンと実装例 〜(AWS-33) セッション概要 概要 SaaS アプリケーションではテナント横断的なリソースを共有するアーキテクチャを採用することによって、 コスト最適化、 デプロイの俊敏性、 運用の効率化を図ることができます。 一方で、 いかにリクエスト元のテナントを識別してアクセスを分離するかはセキュリティ上重要な考慮事項であり SaaS ならではの実装が必要です。そこで本セッシ
)
DREAD (risk assessment model) - Wikipedia
DREAD is part of a system for risk-assessing computer security threats that was formerly used at Microsoft.[1] It provides a mnemonic for risk rating security threats using five categories. The categories are: Damage – how bad would an attack be? Reproducibility – how easy is it to reproduce the attack? Exploitability – how much work is it to launch the attack? Affected users – how many people wil
Documenting Architecture Decisions
Context Architecture for agile projects has to be described and defined differently. Not all decisions will be made at once, nor will all of them be done when the project begins. Agile methods are not opposed to documentation, only to valueless documentation. Documents that assist the team itself can have value, but only if they are kept up to date. Large documents are never kept up to date. Small
アーキテクチャの「なぜ？」を記録する！ADRってなんぞや？ - Qiita
5月のThoughtWorksのTechnology RadarでもADOPTされたADRという手法について、面白かったので、ざっくり自分なりに調べたメモです。 Technology Radarでは以下のように述べられています。 多くのドキュメントは、読みやすいコードとテストに置き換えることができます。しかし、進化的アーキテクチャでは、将来のチームメンバーの利益と外部の監督のために、特定の設計上の決定を記録することが重要です。Lightweight Architecture Decision Recordsは、重要なアーキテクチャー決定を、そのコンテキストおよび結果と共に取り込むための技法です。これらの詳細は、WikiやWebサイトではなくソース管理に格納することをお勧めします。そうすれば、コードと同期したままのレコードを提供できるからです。ほとんどのプロジェクトでは、この手法を使いたくな
Design It!
本書は、設計スキルを成長させたいプログラマーに向けたアーキテクティングの入門書です。ソフトウェアアーキテクチャの基礎とデザイン思考の考え方から始まり、ソフトウェアアーキテクトとして、チームと共に優れたソフトウェアを作り上げていく方法を包括的に解説します。本書を読むことで、適切なステークホルダーを特定してニーズを理解する方法、アーキテクチャ上重要な要求に基づいて技術やアーキテクチャを適切に選択する方法、アーキテクチャを軽量かつ効果的に評価する方法、チームのアーキテクト力を高める方法などを学べます。モダンなアーキテクチャ設計のための実践的な手法が詰まった本書は、より良いプログラマー、技術リーダー、そしてソフトウェアアーキテクトになるために必携の一冊です。平鍋健児氏による「日本語版序文」を収録。 目次 本書への推薦の言葉 日本語版序文 序文 はじめに 第Ⅰ部 ソフトウェアアーキテクチャ入門 1章
〜その意思決定を刻め〜「アーキテクチャ・デシジョン・レコード(ADR)」を利用した設計の記録 - スタディサプリ Product Team Blog
こんにちは。スタディサプリのWeb開発をやっている@highwideです。 今日は、自分の所属する"コーチングチーム"(個別指導コースや合格特訓コースの機能開発を行っています)が、最近のプロジェクトで利用した「アーキテクチャ・デシジョン・レコード」、通称「ADR」について紹介したいと思います。 アーキテクチャ・デシジョン・レコード(ADR)とは 「ADR」「アーキテクチャ・デシジョン・レコード」という概念を知ったのは、社内で行っていた「Design It! プログラマーのためのアーキテクティング入門」(以後「Design It!」)の読書会でのことでした。 www.oreilly.co.jp 最初にそのキーワードが登場する「11.2.3 必要なときだけ形式的な記述に投資する」では、「"膨大な量のドキュメントになる傾向"がある形式的なドキュメンテーション」に対比して、以下のように紹介されます
Architectural Decision Records | adr.github.io
Architectural Decision Records (ADRs) An Architectural Decision (AD) is a justified design choice that addresses a functional or non-functional requirement that is architecturally significant. An Architecturally Significant Requirement (ASR) is a requirement that has a measurable effect on the architecture and quality of a software and/or hardware system. An Architectural Decision Record (ADR) cap
アーキテクチャ・デシジョン・レコードの勧め | 豆蔵デベロッパーサイト
庄司です。 Michael Nygard 氏は「DOCUMENTING ARCHITECTURE DECISIONS」で、特にアジャイル開発では最初の時点でアーキテクチャが決まることはなく、また包括的なドキュメンテーションには価値がなく、小さなピースのドキュメントが全てのステークホルダーに必要となるため「アーキテクチャ・デシジョン・レコード (ADR: architecture decision record)」と呼ばれるドキュメントを提案しています。 その後、ADR は 2022年の InfoQ のトレンドレポートで「アーリーアダプタ」の位置を獲得し、さらに「Fundamentals of Software Architecture (邦題: ソフトウェアアーキテクチャの基礎)」の中にも解説されています。 この記事では、「ソフトウェアアーキテクチャの基礎」に書かれていることをベースに、A
Terraform v1.2の新機能preconditionとpostconditionを調べた | DevelopersIO
Terraformのversion 1.2.0が 2022/05/18にGAになりました。新機能preconditionとpostconditionについて調べたのでレポートします。 preconditionとpostconditionとは 一言でいうとバリデーションのための新機能です。 これまでTerraformでのバリデーションというと、variablesに対して行なうことができました。typeで簡単な型チェックができ、validationブロック内で正規表現を使うなどして柔軟なチェックもできます。 variable "image_id" { type = string description = "The id of the machine image (AMI) to use for the server." validation { condition = length(var.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - k1LoW/tbls: tbls is a CI-Friendly tool for document a database, written in Go.
AWS IoT 再入門 2021 の記事一覧 | DevelopersIO
Mastering Qualitative Risk Analysis with the DREAD Model | Infosec
Security/OSSA-Metrics - OpenStack
GitHub - pseudomuto/protoc-gen-doc: Documentation generator plugin for Google Protocol Buffers
GitHub - joelparkerhenderson/architecture-decision-record: Architecture decision record (ADR) examples for software planning, IT leadership, and template documentation
Spotifyのアーキテクチャ決定レコード