ドキュメントの継続的な開発方法 | IIJ Engineers Blog
私はソフトウェア開発を主体とするエンジニアで、 クラウドサービスの開発・運用 分散処理技術の検証とサービス利用の検討 社内の開発支援環境の開発・運用 などの業務に従事していますが、今回の記事は業務とは直接的な関係は無く、私が会社で勝手自発的に行っている取り組みについて書きたいと思います。 昨今、インターネットは生活に深く浸透し、クラウドサービスを利用することで安く簡単にWebサービスを開発、公開できるようになりました。Web技術の進化や流行の移り変りも非常に激しく、既存サービスの機能追加や新規サービスの開発は頻繁に行われています。それは弊社も例外ではありません。 このような開発の現場では、リーンソフトウェア開発への取り組みなど開発手法の最適化が積極的に行われ、様々なベストプラクティスが生みだされています。それらのベストプラクティスには、 継続的インテグレーション や 継続的デプロイメント
ドキュメント作成ツールの検討(Sphinx、ReVIEWとか) - wadahiroの日記
今後、マニュアルを書いてメンテナンスも継続的にしていく機会が丁度ありそうなので、現時点(2012/05/02)でどのツールが自分たちにフィットするか検討してみた。ツールの候補は以下。なお、過去の仕事ではWordとDocBookは経験あり。 Word DocBook Sphinx ReVIEW 前提 今回のマニュアル作成の前提は以下の通り。 複数人で作業し、1つのドキュメントを作成する(主に章単位でアサイン)。 特定顧客向けに部分的にカスタマイズして提供することもある。 外部向けのドキュメントなので、体裁はそれなりに整っている必要がある。 製品のエディションによってマニュアル構成が変わる(上位のエディションだと機能が増えるので章や節、説明が増えるなど)。 出力フォーマットはWordまたはHTMLならOK。PDFは必須ではない。 ドキュメント中に画像はそれなりにある。スクリーンキャプチャ、構成
busterjs/buster-docs-sphinx · GitHub
README.rst Buster.JS documentation -- Sphinx edition This is the source for http://busterjs.readthedocs.org/, which maybe will become the new http://busterjs.org/. We'll see how Sphinx works out for the Buster.JS docs, and make a decision later. Working with the docs To work with the documentation, simply install Sphinx, clone the repo, and build the docs: easy_install pip # If you don't already h
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - benoitbryon/documentation-style-guide-sphinx: Coding standards for Sphinx-based documentations
