API 設計ガイド | Cloud APIs | Google Cloud
フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR
エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 ＜ご注意＞ 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する
読みやすいREADMEを書く | Yakst
いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの
現場で役立つシステム設計の原則にあるUMLをPlantUMLで書いてみる - Qiita
フューチャーアーキテクト Advent Calendar 2017の2日目です。 はじめに システム設計が大好きで大嫌いな皆さん、こんにちは。 突然ですが、皆さんはどのようにシステム設計における ドキュメント腐る問題 に立ち向かっていますか？ ドキュメント腐る問題とは、設計時に作成した各種ドキュメントがGoogle Driveやファイルサーバ上で陳腐化してしまい、現状の正しい状態を指していないことです。せっかく新規参画者がキャッチアップしようとしてもドキュメントが真実を示していないという怖いやつですよね。 解決策としては、各種ドキュメントを、MarkdownやAsciiDoc、UMLはPlantUMLやmermaid、ERDはPlantUMLやerd、画面遷移図はUI Flow、REST-API設計はSwaggerなど、なるべくテキストベースで管理し、GitHubなどのリポジトリで管理する
Javadoc ドキュメンテーションコメントの書き方 - Qiita
出展: プログラム内のコメントの書き方 | 天才まくまくノート はじめに（モチベーション） こんな話があります。あるソフトウェア企業が一人の技術者の採用を決めました。その決め手となった理由は、「公開しているオープンソースソフトウェアのドキュメントが素晴らしかったから」です。彼らは、作成されたドキュメントを見ただけで、その人には技術力がある、一緒に働いて欲しいと判断したのです。 ある国の言語を学ぶために読み書きの練習が必要であるのと同様に、コーディング技術をつけるには、多くの良質なコードを読み、多くのコードを書くことが必要です。設計ドキュメントを書くのも同じことです。日頃から分かりやすいドキュメントを書く鍛錬を怠らず、長年の経験を積んでいかなければ、良質なドキュメントを書く力は身に付きません。今日からドキュメンテーションコメントをバリバリ書いて、ドキュメンテーション力を付けていきましょう。
AsciiDoc と PlantUML と mermaid.js で素敵なテキストベース仕様書ライフ
以前からテキストベースで仕様書(PDF)などを管理したいと思っていたのですが、ようやくその環境が整い、一度実際に運用してみてかなりいい感じだったので紹介したいと思います。 基本テキストは AsciiDoc で記述する UML は PlantUML で記述する フローチャートとかは必要に応じて mermaid.js も使う つまり基本テキストで表現・管理できるものはテキストで書く 成果物は PDF形式。目次(Table of Contents) はつける。 動作確認環境 macOS Sierra 10.12.3 ruby 2.3.1 Asciidoctor 1.5.5 Asciidoctor PDF 1.5.0.alpha.14 Asciidoctor Diagram 1.5.4 mermaid 7.0.0 AsciiDoc とは AsciiDoc Home Page 軽量マークアップ言語の
エクセルやパワーポイントのドキュメントを捨てて、超美麗なドキュメント作成をasciidoctorで実現しよう！ - Qiita
エクセルやパワーポイントのドキュメントを捨てて、超美麗なドキュメント作成をasciidoctorで実現しよう！asciidoctorasciidoctor-pdf 開発には付き物のドキュメント作成、現場ではワードやエクセル、パワーポイントを使うことが普通ですよね？ そんなドキュメント作成に革命を起こしそうなのがasciidoctorです。 Office製文書の悪い問題を簡単に解決してくれます。 Officeで技術文書を作成する時の問題点 成果物がバイナリなので Git などのバージョン管理ツールと相性が悪い 内容以外の修飾に掛かる時間が膨大すぎる、ワード以外では目次の作成、章番号の連番付け、印刷結果との違いの確認など 文章の内容を記述する時間より、体裁を整えるのに時間が掛かる Windows以外ではなかなか編集できない コードのハイライトなどできない コピーペーストがままならず同じパワポ同
asciidoctor-pdfで社内ドキュメントを書こう - Qiita
この投稿は Fujitsu Advent Calender 2016 の 12日目の記事です。 この記事に書かれた見識は個人のものであり、所属する会社・組織を代表するものではありません🐸。 12/12修正: asciidoctor-pdfインストールコマンドに誤りがありました。 サンプルのスタイルファイル名を confidential_style.yaml から public_style.ymlに変更し、機密区分表記をPublicにしました（不適当だったため）。 合わせてサンプルPDFドキュメントの画像を差し替えています。 その他タイポを修正しました。 背景・動機🐸 技術職にかぎらず、仕事をする上でドキュメントを書く機会はたくさんありますが、大なり小なり組織に所属している以上、好き勝手にオレオレフォーマットを作って、「これがオフィシャルです」・というのはなかなか難しく、組織の内で用意さ
脱Word、脱Markdown、asciidocでドキュメント作成する際のアレコレ - Qiita
asciidocとは asciidocはMarkdownなどのような軽量マークアップ言語の一つで、Webページなどをプレーンテキストで記述することができる(拡張子は.adoc) asciidocを使うようになった経緯 これまではWordで機能仕様書とか書いていたが、Wordは重い、変更場所が分からない、複数人同時に修正とか面倒で、いい加減Wordを使うのは止めたくなった なので軽量マークアップ言語にしよう、一番メジャー？なMarkdownにしたら、以下の制約とかでいくらなんでもイマイチ。。 表でセルの結合ができない 表のセル内で箇条書きができない 目次が作れない 文字に色がつけられない 上記に対応しようとすると、プラグインやらMarkdown亜種がいろいろ。。 そこで、Markdownより表現方法が豊富なasciidocを使用し、実際に使って、特徴・課題を挙げてみた。 asciidocto
AsciiDocによる継続的ドキュメント開発〜１．インストールと基本的な使い方 - dackdive's blog
はじめに ドキュメントを書くための言語としておそらく今一番ポピュラーなのは Markdown だと思いますが、 かっちりした仕様書やユーザーマニュアルなど、より本格的なドキュメント作成にはやや機能不足と感じることがあります。 私も以前、ドキュメントを Gitbook で作れないか検討したことがあったんですが 表を書くのがめんどくさかったり、図のキャプションなどに対応していなかったことから断念しました。 そこで、今回は Markdown よりも表現力の高い言語として知られる AsciiDoc を試してみます。 AsciiDoc は O'reilly でも採用されているほか、Pro Git や JavaScript Promise の本 などの非常に完成度の高い技術ドキュメントが AsciiDoc で書かれています。 （参考記事） ・テクニカルライティングの未来を先取り ー Asciidoc
AsciiDoc入門 - Qiita
AsciiDocとは AsciiDocはMarkdownなどのような軽量マークアップ言語の一つです。 利用例 Pro Git book - Github オライリーの書籍 Clojure Cookbook - Github Programming Scala Mastering Bitcoin - Github Open Government - Github O’Reilly Atlas Neo4j documentation - Github Git User's Manual なぜAsciiDocを使うのか 表現力と可読性 技術文書を書く場合HTMLは汎用性が高いが可読性が低い、一方Markdownは可読性が高いがテーブル記法がないなど表現力が乏しい。 AsciiDocは可読性が高く表現力もある程度高いので、技術文書等を書くには最適である。 表現力：HTML > AsciiDoc >
Markdownを独自拡張してWordドキュメントを卒業する
こんにちはCTOの馬場です。 このたび納品ドキュメント作成で永らく使っていたWordを卒業し、 Markdownで書いてPDFで納める活動を始めたので公開します。 Wordを使っていると並行編集作業できない、改訂履歴追跡が難しいなどの課題があり、その解決のためにいろいろ模索してこの形になりました。 この仕組みには、こんなイイところがあります。 Markdownで書ける gitで差分管理、版管理される GitLab のマージリクエスト(GitHubで言うところのPull Request)を使ってレビュー・リリース管理できる GitLab CIで自動ビルドされる GitLab CI + Jenkinsで自動デプロイされる 以下のツール群を利用しています。 GitLab MkDocs HEARTBEATS Flavored Markdown extension wkhtmltopdf Jenki
MkDocs
MkDocs Project documentation with Markdown. MkDocs is a fast, simple and downright gorgeous static site generator that's geared towards building project documentation. Documentation source files are written in Markdown, and configured with a single YAML configuration file. Start by reading the introductory tutorial, then check the User Guide for more information.
ドキュメントの継続的な開発方法 | IIJ Engineers Blog
私はソフトウェア開発を主体とするエンジニアで、 クラウドサービスの開発・運用 分散処理技術の検証とサービス利用の検討 社内の開発支援環境の開発・運用 などの業務に従事していますが、今回の記事は業務とは直接的な関係は無く、私が会社で勝手自発的に行っている取り組みについて書きたいと思います。 昨今、インターネットは生活に深く浸透し、クラウドサービスを利用することで安く簡単にWebサービスを開発、公開できるようになりました。Web技術の進化や流行の移り変りも非常に激しく、既存サービスの機能追加や新規サービスの開発は頻繁に行われています。それは弊社も例外ではありません。 このような開発の現場では、リーンソフトウェア開発への取り組みなど開発手法の最適化が積極的に行われ、様々なベストプラクティスが生みだされています。それらのベストプラクティスには、 継続的インテグレーション や 継続的デプロイメント
ドキュメント生成ツール「MkDocs」でRedmine Guide日本語訳のWebサイトを作ってみた
ドキュメント生成ツール「MkDocs」でRedmine Guide日本語訳のWebサイトを作ってみた 2017.10.05 3行で言うと… これまでWebサイト「Redmine.JP」の一部として公開していたRedmineのドキュメントの日本語訳を、専用のサイトに切り出して公開した サイトの作成にはオープンソースのドキュメント生成ツール「MkDocs」を使用 Markdownでテキストを用意しさえすれば見やすいドキュメントサイトが簡単に作れる、シンプルで強力なツール 前田です。私のことをRedmineのことばかりやっている人と認識している人がいるかもしれませんが、そんなことはありません。実は8年前に「入門Radiant CMS」というRubyベースのオープンソースのCMSの本を書いたこともあります。 ということで、今回の話題はRedmineではなく、先日Webサイトの制作に使ったツール「M
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.methods.co.nz/asciidoc/
[支える技術]エクセルやパワーポイントのドキュメントを捨てて、超美麗なドキュメント作成をasciidoctorで実現しよう！![[支える技術]エクセルやパワーポイントのドキュメントを捨てて、超美麗なドキュメント作成をasciidoctorで実現しよう！](https://cdn-ak-scissors.b.st-hatena.com/image/square/e45f65486901307445fa766ae58c9833f354eda9/height=288;version=1;width=512/https%3A%2F%2Fprice-checker.jp%2Fwp-content%2Fuploads%2F2015%2F01%2Fpicjumbo.com_HNCK4034.jpg)
Asciidoctor 文法クイックリファレンス(日本語訳)
AsciiDoc の使い方