[B! document] griefworkerのブックマーク

SwaggerのAPI定義からPDFドキュメントを生成する

前回はASP.NET CoreのWeb API プロジェクトにSwaggerを組み込んでAPIのドキュメントをブラウザ上に表示させるところまで実行しました。これはこれで手軽にAPIの仕様を確認出来て便利なのですが、受託開発の際の納品物としてお客様に渡すには少し不便です。﹁納品は紙︵PDF︶で﹂と言われる事がまだありますよね？ブラウザに表示されているものを印刷して渡してしまっても良いかもしれませんが、それだと今ひとつ見栄えが良くないので出来ればもう少しきれいなPDF文書を自動生成したいところです。そこで調べたところ、次のような事が分かりました。 ● swagger2markup-cli を使えばSwaggerが生成するJSONファイルから静的なHTMLやMarkdown、AsciiDoc形式のドキュメントなどを生成する事が出来る。 ● asciidoctor-pdf を使えばAsciiD

griefworker 2021/04/27

リンク

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

griefworker 2021/01/23

リンク

設計書には何を書くべきなのか - terurouメモ

設計とは、要求︵やりたいこと︶をヒアリングする要求を要件︵何を満たさないといけないのか︶に落とし込む要件を実現するために考えられる手段を洗い出す手段の検証を行う検証結果を元に、どの手段を使うかを選定する選定した手段を合意する︵一部要件を満たさない事項がある場合は、代替策や妥協ラインについても合意する︶合意内容を元に、実装や設定に落とし込むをやることである。画面設計や機能設計のように、3-5の検証/選定が薄くなったり曖昧になったりするものはあるが、一般化するとこの流れになる。設計書には、上記の設計でやってきたことを順番に書いていけばよい。これを文章構成のテンプレに落としていくと、要求要件方式対応案︵いわゆる比較表で書いていくのが楽︶検証結果選定・合意結果︵合意した代替策や妥協ラインについても記載する︶詳細設計︵どういう実装にするとか、パラメーターにするとか、細

griefworker 2020/07/30

リンク

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

griefworker 2018/02/14

リンク

タベリー | とある仕様書 – Yamotty – Medium

グループ共有機能仕様書の公開に踏み切ったのは、10Xのプロダクトがどうやって作られているか、について部分的に触れてもらえると思ったから。 10Xでは「細かな実装・デザインの白兵戦」・「認知と理解を獲得していく空中戦」を一緒に戦えるプロダクト・マネージャーを育てていきたいと思っているので、この仕様書を読んで「10Xで力を試してみたい！」という方はぜひ以下のフォームから応募してほしい。ユーザーの感情を科学できる人が10XのPMにはフィットすると思う。仕様書の前提となる考え仕様書は「チームのワーキングスタイル」によってその役割をかえるものだ。今の10Xは「ユーザーの前に積まれた膨大な課題の山に優先度を付け、とにかく早くプロダクトをプッシュしていくこと」が最優先のチーム。そのため、「膝を突き合わせて瞬発力の高いコミュニケーション」を重視している。リモートはしない。この環境では議論のすべてが口

griefworker 2018/01/30

document

リンク

技術書を作るための技術スタック | メルカリエンジニアリング

Mercari Advent Calendar 2017の3日目はmhidakaがお送りします。 Advent Calendarで空いてるところに収まったら12月3日は日曜日ということで、エンジニアの趣味的な話です。筆者は技術的なブログや書籍を書くかたわら、技術書のためのイベントなどを開いてます。技術を追求すること、プログラミング、まとめることが好きでモバイル分野で継続的に書籍を出版しています。内容はおおむね同人誌作りへ適用している技術の話です。書籍の作り方は出版社によっても違いますが、紹介する内容と同様の作り方をしている商業書籍もたくさんあります。ここでは著者の目線から出版業界のテクノロジーをのぞいてみましょう。作る楽しみと読者の視点著者が本を書く動機は人それぞれですが技術を広めたい、たくさん売れたい、自分の知識をまとめたいなど目的を持って書き始めます。また一方で書籍の目

griefworker 2017/12/03

リンク

サンプル例に見る機能仕様書の基本的な書き方＆読みやすくする7つのテクニック (1/3)：プロジェクト成功確率向上の近道とは？（2） - ＠IT

サンプル例に見る機能仕様書の基本的な書き方＆読みやすくする7つのテクニック‥プロジェクト成功確率向上の近道とは？︵2︶︵1/3 ページ︶ ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は、Joelの機能仕様書を日本人向けにカスタマイズされたものを例に、機能仕様書の基本的な書き方、読みやすくする7つのテクニック、仕様書作成ツールは何を使うべきか、誰が書くべきかなども解説します。連載目次連載の第1回の前回﹁ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門﹂では、ITシステム開発がビジネスに貢献していくためには、まずは開発の成功が出発点になること、そしてITシステム開発におけるコミュニケーションの重要性、そしてコミュニケーションにおけるドキュメントの重要性について説

griefworker 2016/07/27

リンク

ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門

ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門‥プロジェクト成功確率向上の近道とは？︵1︶︵1/2 ページ︶ ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は﹁Joelの機能仕様書﹂のポイントを解説する。連載目次はじめに本連載では、ITシステム開発がビジネスに貢献していくために必要な、最も基本的な条件である“システム開発の成功”につながるいくつかのポイントを紹介します。筆者は、さまざまなコンピューターシステム開発に長年携わってきたソフトウェア技術者ですが、この連載では、あえて技術的ではない話題を中心に述べます。というのも、技術論だけではシステム開発が成功する条件としては不十分ですし、すでにたくさんの優れた技術論が各方面で展開されています。あらためてそこ

griefworker 2016/07/27

リンク

残業も減らせる!? 上級エンジニアになるためのDesign Doc超入門

残業も減らせる!?上級エンジニアになるためのDesign Doc超入門‥プロジェクト成功確率向上の近道とは？︵3︶︵1/3 ページ︶ ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は、﹁技術視点﹂のドキュメントとして、2000年代以降注目されている﹁Design Doc﹂について解説します。 IT 技術がビジネスに貢献していくためには、まずはシステム開発を成功させることが重要です。本連載﹁プロジェクト成功確率向上の近道とは？﹂では、システム開発を成功させるために、コミュニケーションが果たす役割の重要性と、ドキュメントによるコミュニケーションの重要性について解説してきました。連載1回の﹁ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門﹂、第2回の﹁サンプル例に見る

griefworker 2016/07/20

リンク

わかりやすいREADME.mdを書く

GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う．成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで︵自分の中で︶最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある．プロジェクト，ツールの使い方，インストール方法プロジェクト，ツールの宣伝元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている．さらに

griefworker 2014/08/01

README ファースト開発。

リンク

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 まで教え

griefworker 2013/12/05

リンク

Bitbucket | Git solution for teams using Jira

With best-in-class Jira integration, and built-in CI/CD, Bitbucket Cloud connects developer workflows from planning to incident management. Join millions of developers who choose to build on Bitbucket.

griefworker 2011/08/01

BeProud の Mercurial 運用管理ドキュメント。チームに Mercurial を導入するなら参考になりそう。

リンク

はてなブックマーク

タグ

関連タグで絞り込む (11)

documentに関するgriefworkerのブックマーク (12)

お知らせ

今週のはてなブックマーク数ランキング（2024年7月第3週）

今週のはてなブックマーク数ランキング（2024年7月第2週）

はてなブックマーク透明性レポート（2024年 2月-2024年4月）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス