![[PukiWiki]](image/logo.gif "[PukiWiki]"){kind=logo}
ディスプレイ †先日から PC の CRT の調子がおかしかった． 省電力モードでディスプレイの電源が切れると，PC 側の操作をしても表示が復帰せず，電源が切れたままになってしまうのである． が，CRT のほうの電源を一旦切って入れ直すと表示できていたので，とりえずはそれでしのいでいた． が，電源の入切でも復帰しないようになってきた． これでは使いものにならないので，ディスプレイの構成を見直すことにした． 実は，CRT の他に TV チューナ入りの液晶ディスプレイがあるが，こちらは専ら TV / CS / DVD 用に使っていた． これを PC にも使用しようと考えたのである． で，それに伴うレイアウト変更をこの土曜日に行った． とはいっても，最終形ではなく，「PC をストレス無く使える」という程度である． 同時に PC 側も解像度の設定を変更した． CRT のときは，画面の解像度は 1152 x 864 に設定して使用していた． グラフィックコントローラのほうは 1280 x 1024 まで対応しているのだが，この解像度に設定すると，リフレッシュレートが 60 Hz まで落ちてしまう． CRT で 60 Hz のリフレッシュレートはちょっと厳しい． ここは電源周波数が 60 Hz の地域で，部屋の照明はインバータ無しの蛍光灯なので，余計チラつきを感じるのかもしれない． それはさておき，液晶ディスプレイの場合，60 Hz というリフレッシュレートでもチラつきは無く，全然問題がない． また，ディスプレイ側の仕様も解像度は 1280 x 1024 が最高である． というわけで，解像度を 1280 x 1024 に変更する． これ自体は xorg.conf をチョロッといじるだけで，何の苦労もなく行えた． で，ちょっといじわるをして $ xsetroot と実行し，背景を白黒ドットの市松に設定してみる． 実はこれ，CRT の場合は干渉縞が生じて見苦しい壁紙設定なのである． が，干渉縞もなく，綺麗に表示されている． すごいなぁ． と，液晶ディスプレイ環境への時代遅れの引越しをした一日だったのでした． email †今のプロジェクトでは，email による社外とのやりとりが多い． もちろん，メールはフォルダに分類してはいるのだが…とても見通しが悪い． はっきり言って破綻している． email の限界というのは，案外低いところにあるのではないだろうか． email リテラシーの問題 †1 問題 A 2 └ Re: 問題 A 3 └ 問題 B これは「メール 2 のメンバー全員にメールを送りたい」というので，メール 2 に対して「返信」し，2 のメールとは奸計の無いメール 3 を書いた場合である． メール一覧でツリー表示させるとこんな形で表示される． 4 問題 A 5 └ Re: 問題 A 6 問題 B 7 └ Re: 問題 B 8 問題 A 解決 今度はスレッド破りの例． 8 のメールは問題 A に関するものだから，4 のスレッドにくっついている方が一覧性は高い． が，別スレッドとして存在しているので，メール一覧で問題 A について追っていくことが困難となる． 「使っている人がスレッドという概念を知らない」という場合もあるのだが，Outlook Express がスレッドブレーカーだったのは，そう昔の話ではない． データ構造もしくは表示構造の問題 †9 問題 A 10 └ Re: 問題 A 11 問題 B 12 └ Re: 問題 B 13 現在の問題点のまとめ 14 └ 問題 A 解決 今度は使っている人に（たぶん）問題は無いのに時系列が追いにくくなってしまっている例． メール 13 でいままでの問題点をまとめていて，メール 14 で問題 A が解決したことを報告している． メール 13 をメール 10 やメール 12 の返信として書くと特定のスレッドの下に埋もれてしまって，妙だ． というわけでメール 13 を新たなスレッドとして起こしたのだろう． そこにメール 14 が返信として付け加えられたのである． 実は email ヘッダ自体は，このような関係を表すことが可能な構造になっている． References: 行に，参考となる email の ID を複数指定できるようになっているのである． 上記のメール群の場合は References: が 9: なし 10: 9 11: なし 12: 11 13: 9 10 11 12 14: 9 10 13 となっていれば，メールの関係をうまく表していることになる． ところが今度はメールの関係が木構造にならないので，従来のスレッド表示では表現することはできない． あえて表現するならば 9 問題 A 10 └ Re: 問題 A 13 └ 現在の問題点のまとめ 14 └ 問題 A 解決 11 問題 B 12 └ Re: 問題 B 13 └ 現在の問題点のまとめ というふうになるのかなぁ． メンバー管理の問題 †というのもある． 多人数でメールをやりとりしてると
というようなことが必ず発生する． この対策としては，原始的な所では「アドレス帳を配布・交換」という方法もある． が，アドレス帳というのは MUA に依存した形式であるため，異なる MUA を利用している人がいるとアウトである． 社内なら「MUA は〜を使うべし」というお達しで統一されていることも期待できるが，取引先で使ってる MUA まで統一されているなんてことは期待できない． で，「メーリングリスト」というのがこの場合の常識的な解決策だろう． が，大きな会社になってくると，サーバ管理部門の意識が現場の意識と離れてしまっているところも多々あるようであり，この様な場合は利用することが困難である． 途中参加者の問題 †誰かが途中でプロジェクトに参加した場合，メールによるいままでのやりとりの経緯がわからない，という問題が発生する． 原始的には「メンバーの誰かがいままでのメールを途中参加者へ転送してやる」という方法もあることにはある． が，「今までのメール」が 100 通以上あったりなんかしたりすると…不可能ではないんだけど現実的ではないだろうなぁ． aliases による簡易なものでなく fml とかを使ったメーリングリストならば，「過去メール取り寄せ」で問題は解決する． とか考えていると，そもそも †各人が同じ内容のメールの束を別々に管理しているのって，現代においては果たして合理的なのだろうか． MUA の操作を誤って必要なメールを消してしまうかもしれないし，ユーザの PC が故障するかもしれない． コンピュータウィルスにやられてマッサラからインストールし直し，なんてこともありうる． そういうあたりを考えると「IMAP サーバにメールを蓄積する」というのも悪くはないのかもしれない． メーリングリストへのメールは特定のフォルダに落ちるようにしておき，メンバはそのフォルダへの read only アクセスが可能とする． これならば，各人が参照する「メールの束」の実体は１つだけとなるので，トータルでのメール管理のコストも下がるだろう． また，先の「途中参加者」の問題も解決してしまう． かくしてリソースは中央集権されてしまったわけだが，となると，
という気分にもなってくる． web 掲示板でもいいだろうし，Wiki なんかでもいいだろう． そうすれば，錯綜したメール一覧を見てウッキー，なんてこともない． というか，そうならないような web アプリを選べばいいだけの話である． というわけで †email は，インターネット以前から存在したメディアであり，電話回線とモデムでバケツリレー転送されていた時代もあった． インターネットに接続されていても，組織外への接続は 64 kbps の専用線，という時代もあった． email の親戚に NetNews なんていう電子掲示板メディアもあるが，こちらは風前のともしびである． 理由はいろいろあるのだけど，大きな理由としては
というのがあるだろう． 昔に比べて回線も太いし，web サーバの処理能力も上がっている． 昔と今では環境が違うわけだから，昔のベストソリューションが今でもベストとは限らない． 現代は現代でベストを模索すればいいわけで，ジジィのノスタルジーに付き合う義理はない． ツボにはまった †教官と女子高生生徒の会話． 教官: この初期値と定数で計算してみろ． しばらく笑いが止まらなかった． しかし，逆ポーランド入力のできる関数電卓はいまや貴重品である． 昔の会社の上司が持っているのを触ったことはあるが，自分自身は持っていない． |
