Moto: Mock AWS Services — Moto 5.0.6.dev documentation
Getting Started Getting Started with Moto Non-Python SDK’s / Server Mode Proxy Mode FAQ IAM-like Access Control AWS Config Support Multi-Account support Releases and Upgrade Paths Configuration Configuration Options Implemented Services Implemented Services Supported CloudFormation resources Patching other Services Contributing to Moto Contributing Development Installation Architecture New Feature
わかりやすくて役に立つリリースノートを書くための10のポイント
リリースノートとは、ソフトウェアのリリース時に機能や目的などを知らせるための資料であり、ソフトウェアがアップデートされる場合も機能強化や不具合修正に関する情報をリリースノートとして公開します。リリースノートの中には優れたものもあれば悪いものもあるとのことで、「よいリリースノートを書くための10のポイント」について、ソフトウェア開発者のサイモン・ウィルソン氏がまとめています。 Writing better release notes https://simonwillison.net/2022/Jan/31/release-notes/ ウィルソン氏は、「リリースノートはオープンソースプロセスの重要な部分です」と述べ、GitHubなどでオープンソースのプロジェクトをリリースする場合、リリースノートを適切に書くことが大切だと主張しています。最近、「よいリリースノートの書き方」について考えていた
ドキュメント駆動開発v2
前提 ここで言っているドキュメントは仕様書ではなく、顧客向け製品ドキュメント。 ミドルウェア製品を開発 小さなチーム パッケージ製品とパッケージ製品のクラウド版 そのため顧客に提供するドキュメントが必ず必要 GitHub を利用 自分で開発する場合のフロー 作りたい機能をぼんやりでいいので GitHub Issue に追加する feature ブランチを切る デザインドキュメントをリポジトリの doc/ 以下に書く デザインドキュメントに合わせてコーディングを進めてなんとなく動くところまで作る 動かなくてもいいのでイメージを膨らませるためにコードを書いてみる デザインドキュメントは書き捨て前提で、とにかくメモを書く 製品ドキュメントを書き始めて、一旦書き終える ブランチマージに向けてコーディングを進める 書ける範囲でテストを書く ドキュメントを平行して修正する プルリクエストをだしてレビュ
システムの変化に追従可能でかつ理解し易いドキュメントシステムのモデル化 / Web System Architecture #8
https://github.com/k1LoW/wsa-sg-8th-draft
目的に沿ったDocumentation as Codeをいかにして実現していくか / PHPerKaigi 2021
https://fortee.jp/phperkaigi-2021/proposal/42ce8b07-6972-42bb-a2ac-96af7249cfa4 あるシステムを理解して開発を開始するとき、必要なのはInfrastructure as Codeを含むソースコードだけでは大抵の場合は不十分です。では挙動がわかるようなテストコードがあれば十分かというとそうでもありません。 いわゆる「オンボーディングの効果的な運用」「開発開始までのオーバヘッドの削減（PHPerKaigi2020で発表）」は継続的な生産性向上のためには考えなければならない要素です。 そして、上記を補完するためにしばしばドキュメントが書かれます。 私はドキュメント運用のアプローチとして「コードによる生成を含んだドキュメント運用」に興味を持っています。 私はこれを「Documentation as Code」と呼んでいま
社内のドキュメンテーションの取り組みと、Kitenのご紹介 - Pepabo Tech Portal
はじめに 技術部の @june29 と申します。最近の趣味は「お散歩」で、よく晴れた休日には妻といっしょに2時間くらい歩き回ったりしています。この記事では、わたしが2020年から力を入れて取り組んでいる社内におけるドキュメンテーションの活動の一部を紹介したいと思います。 問題意識 もともと、ペパボで働く人々には「書く」という行為が定着しています。現在利用中のサービスを見渡してみると、GitHub、Slack、Google Docs、Scrapbox、Notionなどがあり、常に積極的な読み書きが行われています。 しかし、ドキュメンテーションという観点から見て、すべてが理想的にうまくいっているとは言えない状況であるとも思っていました。具体的には、下記のような課題があると感じていました。 書く場所が何種類もあり、どこになにが書かれているかがわかりにくい 場所ごとにアクセス制限が行われており、ど
StackOverflowが新サービス「Documentation」を開始。サンプルコードを中心に技術解説、質問されなくとも有用な情報を共同で作成
StackOverflowが新サービス「Documentation」を開始。サンプルコードを中心に技術解説、質問されなくとも有用な情報を共同で作成 StackOverflowは、エンジニア向けのQ&Aサイトとしてよく知られています。誰かが質問をすると、その答えを知っている人が回答する。質問をよりよくするために書き換えることもできるし、質問や答えの有用さを評価することもできて良い質問や良い答えはポイントが上がるなど、サイト全体のコミュニティの質が保たれるような仕組みを備えているのが特長です。 そのStackOverflowが、新サービス「Stack Overflow Documentation」（以下Documentation）をベータ版として公開しました（英語版StackOverflowにて。日本語版StackOverflowにはまだのようです）。すでにさまざまなトピックのドキュメントがあ
設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog;
以前開発のドキュメントをどこに置くか問題 - $shibayu36->blog;という記事を書いた。まだよい方法はちゃんと考えられてないが、少しずつケースバイケースでいろいろな手法を試してみている。今回は設定項目の仕様のドキュメントという観点で考えたときに、テストを作ることで解決できないか、ということについて書く。 設定項目の仕様 例えば以下の様な設定があったとする*1。 [ { "blog_url" : "http://shibayu36.hatenablog.com/", "permission" : "public", "can_be_edited_by" : [ "shiba_yu36" ] }, { "blog_url" : "http://shibayu36-private.hatenablog.com/", "permission" : "private", "can_be_
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Laravel - The PHP Framework For Web Artisans
Phacility - Home