TiddlyWiki を ToDo 記録用に使い始める - [更新停止] 新芽の手、ほんとの手

気軽でフレキシブル、かつ再利用性を損なわない ToDo リスト

昨日は Trac だったが、今日は TiddyWiki。業務のタスクが複数化し、現在の進行状況をそれぞれ聞かれる度に「どういう状況だったっけ？」とソラで脳みそを切り替えられるハズもないので副題の条件を満たす ToDo 管理ツールを検討する。

trac で出来てしまえばいいなーとは思ったのだが、チケット管理するにしては作業の粒度が細か過ぎるのでチケット管理はまず有り得ない。Wiki 機能を使おうと思ったが、VMWare にインストールした trac の速度がそもそも遅く、速度改善を施す時間は無いので今回は却下。多分別途サーバを立てて使えば物理的な LAN 転送速度が遅くなるってのはあり得ないだろうから、そこにpukiwiki Plugin を入れて運用するとかいいやり口も考えられそう。

ちなみに外部のサーバに wiki を置けば、という意見はここでは無理。フィリピンにおいて外部回線は月に 1 度くらい止まるという気持ちで使ってないとやってられないぐらい信用ならないし、原因不明で遅くなるのもザラ。
もうローカルでいいや、てことで過去に導入を断念した TiddyWiki を再び導入。

TiddyWiki のインストール・設定

設定といってもやることは少ない。初期状態の empty.html を好きなディレクトリに配置するだけでまずインストールは完了する。

html をブラウザで開くと GettingStarted が表示され、ユーザ名を入力して自動保存の設定を行って完了、、、となるはずだったが、コケた。Google Chrome では、ローカル html に対して Cookie が通常起動状態では無効になっている + AutoBackup のスクリプトが正常に動作しないらしい。あちゃあ。
以下のサイトの情報を元に .jar ファイルを入手し、オプションの設定やユーザ名については該当箇所の初期値をソースを直接でもって変更することで対処。
Google Chrome で TiddlyWiki を使うときにハマる二つのポイント

また、自動保存の時間単位が秒単位なのはとても頂けない。初期状態ですら 300 KB もあるファイルをそんなに高頻度で保存したら結構な容量になってしまう。これについてもソースを開き、convertToLocalYYYYMMDDHHMM を元に convertToLocalYYYYMMDDHH を作成し、getBackupPath でファイル名生成の為に利用している同関数を作成した関数に置き換える。これで、毎時単位のバックアップになるので容量の心配は少なくなった。日単位にまで削ってもいいけど、大抵 ToDo の変更は一日に何度もあるので時間単位でバックアップぐらいはしておきたい。

前々日以前のファイルに付いては手動で最終版以外のバックアップファイルを削除することとする。そんぐらいは大した手間じゃないし。

あとは 3 カラムだと本文幅が狭くなって文章が長くなる時に大変見辛い。StyleSheet の Shadow Tiddler に 2 カラム変更用のスタイルシートを記述して、2 カラムに変更。ここの css を参考に、とりあえず現行版でも 2 カラムになるようにパラメータを追加する。（css には詳しくないので、absolute 等で無理やり配置換えしてます）

#mainMenu {
  position: relative;
  display: block
  width: 160px;
  height: 160px;
  float: right;
  left: auto;
  right: 10px;
  text-align:right;
  padding: 0em 1em 0em 1em;

  background-color: #eee;
  color:#cccccc;
}

#displayArea {
  position: static;
  top: 0em;
  margin:0 17em 0 1em;
  padding:0;
}

#sidebar {
  position: absolute;
  top: 320px;
  right: 10px;
  width: 16em;
  font-size: .9em;
}

これで割と使い易くなった。タスク管理ツールはこうやって使い込んで自分のベストを模索していくしかない。