プレインテキストへの決意 ～for progmatic programmer～

達人プログラマーが取り扱う情報は、知識です。
その知識を永続的に格納するためのフォーマットで最も適しているものが、プレインテキストです。
プレインテキストを使えば、手作業、自動的な作業を問わず、
事実上すべてのツールを使って思い通りに知識を操作することができるようになるのです。

この、自由自在にというのには熟達が必要だが、そうなれれば確かにすごく効率が上がりそうだ。 すごいブログラマの生産性は10人の一般人に値すると聞いたことがあるが、 プレインテキストを使いこなすことが一つのヒントかもしれない。

プレイン・テキストとは、印字可能な文字からなる、人間が直接読んで理解することのできる形式です。

バイナリ形式は、データを解釈するためのコンテキストがデータ自身から切り離されてしまっている。
これでは、暗号化されていると同じ。

プレインテキストのデメリットは、バイナリに比べて大きな格納領域が必要、多くの計算量が必要。
メリットは、透明性が保証される、様々な活用ができる、テストが用意になる。

プレインテキストは、長持ちするし、ツールで自由自在に加工できる。

最近、mixiやYahooブログに投稿した昔の日記をwordpressに移行しようとしているのだが、 Rubyスクリプトで取り出そうとすると苦戦してる。単純なHTML形式で保存すればどんなによかったかと思う。

また、今までEvernoteに情報を集約していたが、Evernoteはプレインテキストではない。 Evernoteを利用することに危機感を覚える。 なにかEvernoteに変わるような代価手段も見当する必要があるかもしれない。

ソースコード管理システムは巨大なUNDOキー。

すべてをソースコード管理システムで管理すること。それがソースコードでなくても。
ドキュメント、電話番号、メモ、小さなスクリプト、日々の作業はリポジトリ内で厳重に保管される。

我われの扱うものが知識であり、それがプレインテキストで記述されるならば、 それを管理する洗練されたツールとして、ソースコード管理システムを利用する。

コードだけを管理すればいいと思っていた思い込みを打破するカルチャーショック！

全てはドキュメント。

コードとドキュメントを結びつける。同じような作業を繰り返して行わず、また時間の無駄にならない方法で、
ドキュメントを手近なところ（つまり可能な限りコード自身のなか）に置くことによって、簡単にドキュメントを作成できる。

実効可能ドキュメント、ドキュメントからコードを生成する。
ドキュメントとコードの２つをメンテナンスすることはDRY原則に反する。

プレインテキストならば、スクリプト言語によって加工が可能。
プレインテキストでないならば、ドキュメントは副次的なものにする、またはマクロを記述してドキュメントを生成する。

これは、Pandocのようなものを言っているのだろうか。プレインテキストから、Wordやpdfを自由に生成できる時代だ。 こういうツールを普段の開発に導入するためには、どうすればいいだろう。 自分のまわりはWordとExcelという、不動の権力が立ちはだかる。

しかし、それでもWordを捨ててプレインテキストで仕様書がかけるかどうか、tryはしてみよう。