VB ランタイムが必要なのが残念だけど、効果はある。しかも面倒なセットアップは考える必要なし。凝るなら別だけど。設定に
- Fast
- Turbo
の項目があらかじめ用意されていて、それを選ぶだけで ok。Turbo にしても普段使う
- 閲覧（ズーム）
- 印刷
- テキストのコピー
なんかには影響ない。（Adobe Acrobat 5 で確認。）影響出るのは PDF 以外のフォーマットへの書き出しやメール送信、注釈や署名関係の機能が。[ ツール ] メニューでは Distill 以外全部消えたので、Reader で Turbo にしたら [ ツール ] メニューはなくなるのかもしんない。 元の設定に戻すのも AdobeReader SpeedUp から Restore Original Configuration を選ぶだけなので楽だ。しかもほんとに Read するだけの人は設定を戻す必要も恐らくない。
あ、インストーラはないので自分で適当なフォルダに放り込んで起動しやすく設定しておくこと。
久しぶりに Dolphin のステータスを確認したら 5000位を切っていた。おおざっぱに言うと 3ヶ月で 300万弱をタイプ。なんだこりゃ。
なんで Dolphin をふと思い出したかというと、実はすでにキーボードの Enter や右 shift の辺りが「キシキシ」言い始めたから。自前の ThinkPad はまだ元気なのでこのキーボードがダメなのか、あるいは「以前よりタイプ量が増えたか」。
で、ちょっと考えたら、以前よりやっぱ打ってる気がする。もともと打つ/書くのは好きだが、Wiki の導入で以前より断然楽に書けるようになったってのが大きいのかもしんない。（最近は Wiki スタイルで書きやすさが飛躍的に向上したこの tDiary も貢献している。）
Wiki 以前は
- 保存ファイル名と保存場所をどうするか
を悩むプロセスがあった。時系列にメモファイルをどかどか増やすのは好きじゃなかったので、書く段階で整理先を決めるようにしていたのだ。しかしこれはやはり書き始めるまでの障壁が高い。
しかし今は Wiki や tDiary でとにかくその日の記録として書き出してしまうことにしている。これは
- ファイルの存在を気にしなくてよい
- 検索の機能がついている
の2点がやはり大きい。また、案外
- あとで整理しやすい
というのもある。これらが安心感となって、メモ書きのペースが上がっているってわけだ。もちろんメモだけでなく資料作成にも使っているので、なんというかライティングそのものがシームレスなのである。日常と業務が切り離されていない感覚。これはもちろん良し悪しだが、仕事モードに切り替えることなく仕事に役に立つメモが取れるし、趣味に役に立つ記録を作成できるし、仕事しながら日常生活のメモもできる。エディタや付箋ソフト、メモソフトなどあれこれ使い分ける必要もない。
以前から「起きている間ずっとキーボードに向かう」ような生活だったが、便利な道具の出現によりそれがさらに加速されているって感じだ。
この「書きやすさ」は 20年を越える自分の PC 歴の中で、スクリプト言語の習得と同じかそれ以上の革新である。革新のほとんどはここ数年で起きているってのがなんだかビミョーだが、革新を支えるスキルを地味に磨いていた（Web サーバや Unix を扱えるなど）ことの賜物だろう。と思うことにする。
ほーらあっという間にこんだけ書いちまった。ただ、以前より内容のダブりが増えているような気もする。同じ内容をくり返し書いているのだ。これは内容でページを起こさなくなってきているからなんだよな。まぁ、量から質を抽出する戦法ということにしよう。
ドキュメントというと、Excel を方眼紙にした1関数1ページで仕様書を書くというふざけた習慣が一部にある。これは著しく生産性が悪いし、絶対に撲滅させるべき習慣だが、こうした、まだ「システムといえば大掛かりで当然」だった頃の古い体質に学ぶことが一つある。入力と出力を常に意識している点である。
なぜこうしたことを思ったかと言うと、ある Web アプリのある画面に関するコメントで、
- 入力（これは当然ブラウザからくる）
- 出力（画面用）
- 出力（他の画面に渡す用）
の3種類に変数が整理されて書かれていたものを見かけたから。
これは書くのは面倒だが実はありがたいコメントである。しかしドキュメント作成システムと相性が悪い。（ここでは PHPDoc を念頭に置いているが、）ドキュメント生成システムは原則的にクラスとメソッドに関するドキュメントを自動生成するものである。「画面」に対するドキュメントではない。これは PHPDoc のもとになった JavaDoc の性格を引き継いでいるのだろうが、Web アプリの場合は「画面1つ」に対して必ず何らかの「プログラムファイル1つ」が対応する。（もちろんモード分けによって画面数よりファイルが少なくなることはよくあるが。）ここが問題になるのだ。
何を言いたいかというと、GUI アプリと違って、Web アプリの場合は画面とドキュメントがうまくかみ合わないということである。GUI アプリはウィンドウやダイアログにクラスを割り当て、それらに対して操作を行うので、画面とドキュメントはスムーズに対応する。しかし Web アプリではそういうきれいな対応は作れない。
もちろん上の方法に倣ってすべての「画面」を「ページインスタンス」と見做し、全部オブジェクト指向で書くという方法もあるだろう。これならドキュメントシステムとの相性はよい。それが実現可能な言語ならそういう方法はアリだ。
でもそれは激しく書きにくいだろう。今度は HTML との相性が悪くなるし。
あ。でも画面を全部テンプレートに追い出して全部 OO で書くならイケそうだな。サーブレット + JSP な現場はどうなっているのかな？ 調査が必要かもしんない。
最近すっかりオブジェクト脳だ。
だいたい、IE コンポーネントブラウザが IE を駆逐できるわけないじゃん。IE 依存なんだから。なんだこの記事は。