エクセルで手順書を作るのはきっとやめた方がいい - Qiita
追記(2017-01-05) 「エクセル 手順書」でググったら上の方にくるようになったのですが、その検索結果ページには業務手順書をエクセルで作るとかそういうのがあり、なかなかカオスです。 あとから見ると主語が大きい気がしたので、すこし補足をいれます。あくまでエンジニア業界で、特にソフトウェアのインストールや、サーバの環境構築などの手順書にはエクセルは不向きなのでは、という実体験に基づいたお話です。 ある製品のインストール手順書を作ることになり、参考資料として過去の案件で作ったものをもらったのだが、それはエクセルファイルだった。 どういうものだったかを端的に述べると以下の通り。 目次がない シート名に番号はついていない 各シートにも番号の記載はない 各シートの中身はスクリーンショットの羅列 スクリーンショットについての説明がほぼない 間違った手順のスクリーンショットも混ざっている 操作の結果
API Blueprint | API Blueprint
API Blueprint. A powerful high-level API description language for web APIs. API Blueprint is simple and accessible to everybody involved in the API lifecycle. Its syntax is concise yet expressive. With API Blueprint you can quickly design and prototype APIs to be created or document and test already deployed mission-critical APIs. Tutorial Tools section Focused on Collaboration API Blueprint is bu
Promise本で取り組んだ電子書籍の開発ツール、CI、継続的リリースについて
Promise本の取り組み JavaScript Promiseの本の開発で取り組んだ事と取り組んでおくべき(考慮しておくべき)だったことについてのメモ書き 技術書のディレクトリ構成とか参考になるものがあんまりなくて適当に作ったので、その辺を整理をしたい目的で書いてます。 はじめに ここで書いたPromise本のディレクトリ構成やCI、テスト手法、使ったツールなどについては以下に大体書いてあります。 JavaScript Promiseの本 付録 上記の付録のソース : promises-book/Appendix-Note at master · azu/promises-book promises-book/CONTRIBUTING.md at master · azu/promises-book なので、結構省いて書いてるのでちゃんと見たい人は付録とかの方を見て下さい。 後、書籍の文
tbaggery - A Note About Git Commit Messages
19 Apr 2008 I want to take a moment to elaborate on what makes a well formed commit message. I think the best practices for commit message formatting is one of the little details that makes Git great. Understandably, some of the first commits to rails.git have messages of the really-long-line variety, and I want to expand on why this is a poor practice. Here’s a model Git commit message: Capitaliz
language agnostic - How to write a good README - Stack Overflow
As others have noted, README should be simple and short, but a good README can save time especially if it's for something like command-line parameter parsing library. Here's what I think it should include: name of the projects and all sub-modules and libraries (sometimes they are named different and very confusing to new users) descriptions of all the project, and all sub-modules and libraries 5-l
Asciidoctor | A fast, open source text processor and publishing toolchain for converting AsciiDoc content to HTML5, DocBook, PDF, and other formats.
A fast text processor & publishing toolchain for converting AsciiDoc to HTML5, DocBook & more. = Hello, AsciiDoc! Doc Writer <doc@example.com> An introduction to http://asciidoc.org[AsciiDoc]. == First Section * item 1 * item 2 [source,ruby] puts "Hello, World!" Asciidoctor is a fast, open source, Ruby-based text processor for parsing AsciiDoc® into a document model and converting it to output for
Javadoc の書き方 - イトウ アスカ blog
みなさん、Javadoc 書いてますか？ Javadoc は「API ドキュメント」と言われることが多いように、主にライブラリ的なプログラムで書いてこそのものだと思っている方もいるかもしれません。しかしながら、仕様書を Word や Excel（笑）で別途作ると、プログラムと仕様書の同期がとれてないというはめに陥り易くなりますので、Javadoc はどんなときも活用したいというのが私の考え方です。 まず、overview.html を書け Javadoc コメントをいくらか書くような人でも、overview.html を書く人は意外と少ないのではないでしょうか。リファクタリングが何度となく行われるアジャイル開発の現場では、クラスの構成がよくかわりますので、いちいち詳しいコメントを書いていられないということはあるかもしれませんが、overview.html はそれほど何度も手をつけるようなも
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
jax-doclets
GitHub - kmuto/review: Re:VIEW is flexible document format/conversion system