コードを書いていても、マニュアルの制作をしていても、コンピュータで扱うファイルは増え続ける。 これを如何にに上手にマネジメントしていくか、という話。
自分がコンピュータで管理している主なファイルは...
以前、AppleWorksを愛用していて、レポートなど第三者に見せる体裁が必要なドキュメント作成に利用していた。
慣れの要素も大きいが、すばやくそれなりの体裁のレポートを作成できるため気に入っていた。
しかし、コンピュータを買い替えるうちに、AppleWorksのドキュメントを開ける環境がなくなって、困ったことになった。
そのとき、どうせならMS-Wordでつくっておいた方がましだった、とは思ったが。
教訓その1: 特定の（特に商用の）アプリケーションに依存したファイル形式を使うな 。
またそれから別の教訓を得たのは、 あなたの文書を流用するから、データ提出せよ といわれたとき。 AppleWorksじゃあね。やっぱりこのときも、MS-Wordでつくっていたらよかったと思ったけど
教訓その２: 普及していないデータ形式を使うな 。
結論としては、現在 Markdownを中心に、それをワンソースマルチユース的に使い回しているのだが、Markdown以前には、Radeoxという記法を使っていた。 （さらに悪いことに、数年はRadeox記法を拡張した独自マークアップ言語を自分で開発して使っていた。）
Radeoxや独自拡張した独自マークアップ記法は自分のニーズにぴったりあうのだが （しかもソースはプレーンテキストだから教訓その１・その２に違反していなくもない） 何かちょっとした追加機能のたびに自分でコーディングしなければならない。 結局、Google App Engine上でメモサーバを構築しようとしたときに、独自マークアップ記法をPythonに移植できなかった。 当時は Google App Engine で使える言語は Python だけだった。そして自分で用意した独自マークアップ記法の処理系は Java で実装していた。
Markdown に乗り換えてから、何か困ったことがあっても、少しネットを調べれば誰かが解決策をブログなどで書いているし、 その他いろいろな追加機能は、既に誰かが実装していることが多い。
教訓その３: 普及しているデータ形式を使え 。
Markdown=プレーンテキストの良いところ
プレーンテキストでドキュメントが書けると良いことは、
- ライティングにお気に入りのテキストエディタが使える
- ファイルサイズが小さい
- Subversion でファイル管理できる
ファイルサイズが小さい、というのはかなりリソースを節約できる。 バックアップも時間がかからないし、サーバ上でメモるときも （現在は、GoogleAppEngine上にメモサーバをつくってそこでメモを書いている） 使用帯域が狭くて済む。 テキストエディタはワードやOpenOfficeOrgと違って軽いのでマシンも低スペックで済む。 何かと経済的。