SwaggerのAPI定義からPDFドキュメントを生成する
前回はASP.NET CoreのWeb APIプロジェクトにSwaggerを組み込んでAPIのドキュメントをブラウザ上に表示させるところまで実行しました。 これはこれで手軽にAPIの仕様を確認出来て便利なのですが、受託開発の際の納品物としてお客様に渡すには少し不便です。「納品は紙（PDF）で」と言われる事がまだありますよね？ ブラウザに表示されているものを印刷して渡してしまっても良いかもしれませんが、それだと今ひとつ見栄えが良くないので出来ればもう少しきれいなPDF文書を自動生成したいところです。 そこで調べたところ、次のような事が分かりました。 ● swagger2markup-cli を使えばSwaggerが生成するJSONファイルから静的なHTMLやMarkdown、AsciiDoc形式のドキュメントなどを生成する事が出来る。 ● asciidoctor-pdf を使えばAsciiD
GitHubで使えるイカしたREADMEの作り方 - Qiita
概要 散らかっていたGitHubを整理して、きっちりしたREADMEを書いたので、その方法をまとめました。 一度フォーマットを決めておけば後々楽になるので、ぜひこれを読んでイケてるREADMEを作成してみてください。 READMEの構成 色々と調べた結果、このような基礎構成になりました。 # name image or gif ## Overview ## Requirement ## Usage ## Features ## Reference ## Author [twitter](https://twitter.com/Kotabrog) ## Licence [MIT](https://......) 必要があれば、これに付け加えていく感じです。 私のGitHubになりますが、例えばこんな感じになります。 以下ではそれぞれについて簡単に解説をいたします。 name 私は基本的にre
設計書には何を書くべきなのか - terurouメモ
設計とは、 要求（やりたいこと）をヒアリングする 要求を要件（何を満たさないといけないのか）に落とし込む 要件を実現するために考えられる手段を洗い出す 手段の検証を行う 検証結果を元に、どの手段を使うかを選定する 選定した手段を合意する（一部要件を満たさない事項がある場合は、代替策や妥協ラインについても合意する） 合意内容を元に、実装や設定に落とし込む をやることである。画面設計や機能設計のように、3-5の検証/選定が薄くなったり曖昧になったりするものはあるが、一般化するとこの流れになる。 設計書には、上記の設計でやってきたことを順番に書いていけばよい。これを文章構成のテンプレに落としていくと、 要求 要件 方式 対応案（いわゆる比較表で書いていくのが楽） 検証結果 選定・合意結果（合意した代替策や妥協ラインについても記載する） 詳細設計（どういう実装にするとか、パラメーターにするとか、細
overlasting.net
overlasting.net 2020 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
タベリー | とある仕様書 – Yamotty – Medium
グループ共有機能仕様書の公開に踏み切ったのは、10Xのプロダクトがどうやって作られているか、について部分的に触れてもらえると思ったから。 10Xでは「細かな実装・デザインの白兵戦」・「認知と理解を獲得していく空中戦」を一緒に戦えるプロダクト・マネージャーを育てていきたいと思っているので、この仕様書を読んで「10Xで力を試してみたい！」という方はぜひ以下のフォームから応募してほしい。ユーザーの感情を科学できる人が10XのPMにはフィットすると思う。 仕様書の前提となる考え仕様書は「チームのワーキングスタイル」によってその役割をかえるものだ。今の10Xは「ユーザーの前に積まれた膨大な課題の山に優先度を付け、とにかく早くプロダクトをプッシュしていくこと」が最優先のチーム。 そのため、「膝を突き合わせて瞬発力の高いコミュニケーション」を重視している。リモートはしない。 この環境では議論のすべてが口
技術書を作るための技術スタック | メルカリエンジニアリング
Mercari Advent Calendar 2017の3日目はmhidakaがお送りします。 Advent Calendarで空いてるところに収まったら12月3日は日曜日ということで、エンジニアの趣味的な話です。 筆者は技術的なブログや書籍を書くかたわら、技術書のためのイベントなどを開いてます。 技術を追求すること、プログラミング、まとめることが好きでモバイル分野で継続的に書籍を出版しています。 内容はおおむね同人誌作りへ適用している技術の話です。 書籍の作り方は出版社によっても違いますが、紹介する内容と同様の作り方をしている商業書籍もたくさんあります。 ここでは著者の目線から出版業界のテクノロジーをのぞいてみましょう。 作る楽しみと読者の視点 著者が本を書く動機は人それぞれですが技術を広めたい、たくさん売れたい、自分の知識をまとめたいなど目的を持って書き始めます。 また一方で書籍の目
サンプル例に見る機能仕様書の基本的な書き方＆読みやすくする7つのテクニック (1/3)：プロジェクト成功確率向上の近道とは？（2） - ＠IT
サンプル例に見る機能仕様書の基本的な書き方＆読みやすくする7つのテクニック：プロジェクト成功確率向上の近道とは？（2）（1/3 ページ） ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は、Joelの機能仕様書を日本人向けにカスタマイズされたものを例に、機能仕様書の基本的な書き方、読みやすくする7つのテクニック、仕様書作成ツールは何を使うべきか、誰が書くべきかなども解説します。 連載目次 連載の第1回の前回「ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門」では、ITシステム開発がビジネスに貢献していくためには、まずは開発の成功が出発点になること、そしてITシステム開発におけるコミュニケーションの重要性、そしてコミュニケーションにおけるドキュメントの重要性について説
ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門
ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門：プロジェクト成功確率向上の近道とは？（1）（1/2 ページ） ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は「Joelの機能仕様書」のポイントを解説する。 連載目次 はじめに 本連載では、ITシステム開発がビジネスに貢献していくために必要な、最も基本的な条件である“システム開発の成功”につながるいくつかのポイントを紹介します。 筆者は、さまざまなコンピューターシステム開発に長年携わってきたソフトウェア技術者ですが、この連載では、あえて技術的ではない話題を中心に述べます。というのも、技術論だけではシステム開発が成功する条件としては不十分ですし、すでにたくさんの優れた技術論が各方面で展開されています。あらためてそこ
残業も減らせる!? 上級エンジニアになるためのDesign Doc超入門
残業も減らせる!? 上級エンジニアになるためのDesign Doc超入門：プロジェクト成功確率向上の近道とは？（3）（1/3 ページ） ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は、「技術視点」のドキュメントとして、2000年代以降注目されている「Design Doc」について解説します。 IT技術がビジネスに貢献していくためには、まずはシステム開発を成功させることが重要です。本連載「プロジェクト成功確率向上の近道とは？」では、システム開発を成功させるために、コミュニケーションが果たす役割の重要性と、ドキュメントによるコミュニケーションの重要性について解説してきました。 連載1回の「ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門」、第2回の「サンプル例に見る
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
AngularJS 1.2 日本語リファレンス | js STUDIO
AngularJS 1.2 API ガイド TIPS ngモジュール ディレクティブ フィルター サービス 型 グローバルAPI ngMockモジュール サービス グローバルAPI AUTOモジュール サービス ngAnimateモジュール サービス ngCookiesモジュール サービス ngMockE2Eモジュール サービス ngResourceモジュール サービス ngRouteモジュール サービス ディレクティブ ngSanitizeモジュール フィルター サービス ngTouchモジュール ディレクティブ サービス このサイトについて AngularJSの日本語リファレンスです。 AngularJSの本家サイト(英文) の内容を翻訳して作成していますが、誤訳や誤記があると思いますのでその点についてはご了承ください。 もし、誤訳などの間違いを見つけましたら、 @tomof まで教え
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Bitbucket | Git solution for teams using Jira