To: 中根 <max@example.com>

また、返信する場合は、元のメールの FromやToや Ccに入っている名前がそのまま入ってしまう。それがどうした、と思われるかもしれないが、実はこれが結構気になるのだ。どんな時に気になるかというと:

前者の場合は単に相手に失礼である。後者の場合、僕の個人的な意見としてはそういう風な名前の入れ方をする先方の問題だと思うのだけれど、日本ではこういうアドレス帳を使っている企業人は少なくないようである。この場合、送信者と同じ組織の人には「弊社何とか」という名前が、それ以外の人には「何とか様」という名前が付けられていることもある。そういうメールに返信すると、たとえば A社の鈴木さんが B社の私と C社の佐藤さん、さらに A社の田中さんに送ったメールの場合、こんなことになってしまう:

From: 中根 <max@b.example.com>
To: 鈴木 <suzuki@a.example.com>
Cc: 佐藤様 <sato@c.example.com>,
    弊社田中 <tanaka@a.example.com>

これでは鈴木さんと田中さんに失礼な上に、田中さんが何者だか分かりづらくなってしまう。僕自身は自分がアドレス欄にどういう風に入っているかはほとんど気にならない (漢字が違っているのはちょっと気になるけど) ので別にいいのだが、アドレス帳にこういう入れ方をしている人たちはきっと気にすることだろう。だから、これまで Thunderbirdでメールを書くときは、場合によってはわざわざ手動でこの名前の部分を消す、などということをしてきた。 (Wanderlustの場合は wl-draft-reply-use-address-with-full-nameを nilに設定してやれば、少なくとも返信の際は名前の部分を勝手に消してくれるのでその必要はないし、そもそも Wanderlustではアドレス帳をほとんど活用していないので関係ない。)

そんな訳で困っていたのだが、この問題を解決するのに良さそうな、Auto Address Cleanerという Thunderbirdのアドオンを見つけたので、早速試してみた。

このアドオンをインストールすると、メールを送信する段階で宛先の内容を処理してくれて、名前の部分を消してくれる。送信前のメールの編集段階では名前はそのまま入っているので、宛先に入力されているのが誰のアドレスなのかを容易に確認できる点も便利である。処理が送信の際に行われるため、送信する前の段階では少々不安になる、ということもあるのだが、実際に自分に Bccしたメールを見てみるとちゃんと消されていることが確認できる。

ということで、これでアドレス欄で相手を不快にする心配はしなくてもよくなったようだ。 (もっとも僕の場合はメールの内容で不快にすることがありそうだけど、それはまた別の問題ということで…。)

• Webブラウザを使った読み書きが可能
• Windowsや MacOS Xなど、いくつかのプラットフォーム向けの専用プログラムが提供されていて、これを使えばインターネットに接続されていない環境で読み書き可能 (オンラインの時に簡単に同期できる機能がある)
• 上記専用ソフトをインストールすると、選択しているテキストや表示中の Webページを簡単に noteとして保存することができるようになる
• 自分用に割り当てられた専用メールアドレスにメールを送ると、その内容が noteとして保存される
• IMAPで自分の noteを閲覧できる (ただし現時点ではアルファ版)
• 複数の notebookを作り、用途などに応じて noteを分類可能
• noteにはタグを付けられる
• テキスト情報だけでなく、画像や音声も保存できる

ということで、普段使う PCには片っ端から Evernoteの専用アプリケーションをインストールし、普段使わない PCからはブラウザを使うようにすれば、 PCさえあれば noteの読み書きができることになる。出先で PCがない時でも、携帯電話からメールすれば、少なくとも書き込みはできる。僕は持っていないが、 Windows Mobileの端末や iPhoneを持っている人なら、これらで読み書きすることだってできる。つまり、自分のメモへのアクセスに関する問題のほとんどが解決することになる。また、分類や検索のための機能も比較的しっかりとしているので、検索性の問題も随分改善するはずだ。

使い勝手だが、スクリーン・リーダのユーザには必ずしも良いものではない。特に、専用アプリケーションでの noteの編集作業は現実的ではないと思う。 (これは編集時のカーソルが認識できないためである。) しかし、 Webを使えば編集は容易にできるので、編集したい時には Web、と割り切って使えるのならば問題は少ないだろう。また、選択したテキストなどを登録する作業については特に問題なくできるので、比較的便利だ。専用アプリケーションの場合も Webの場合も、タグの整理などの作業ではドラッグ&ドロップが必要になる場合もあるので、慣れていないスクリーン・リーダのユーザには少々難しいかもしれない。どんな操作は専用アプリケーションからするとやりやすく、どんな操作は Webからやるとやりやすいか、といったノウハウをある程度蓄積していかないといけなさそうではある。しかしこれはあくまでもスクリーン・リーダを使っている場合であって、そうでない場合にはかなり便利に使えるのではないかという印象だ。

とりあえず 1週間ばかり使ってみたのだが、これまで僕が抱えていた問題を解決しつつ、実用に耐えるスクラップブックとして使えそうだという結論に達しつつある。重要なことは、「何でもかんでも放り込まない」ということだと思う。つまり、気になったものを片っ端から保存したのでは、タグ付けも大変だし、後で探すのも、いくら検索機能がしっかりしているとはいえ大変だ。だから、仕事や趣味で後で思い出したくなりそうな情報かどうかを考えた上で保存する、というのが重要だろう。それから、特定の notebookに入っている noteについては、一定期間経過したら削除するようにする、などという運用も必要かもしれない。ということで、今のところそれなりに気に入っているので、もうしばらく使ってみようと考えている。

ところで、このサービスを使ってみて、改めて情報の入出力は、その方法が多い方が良い、ということを感じさせられた。そういった視点で開発されるサービスやアプリケーションがもっと増えてくれると面白くなりそうだ。

ともあれ、荷物の運搬はさっさと終わった。荷物を車から降ろしてアパートのドアを開けてみると、管理会社の人が手配してくれたらしい家具が入っていた。簡単なものだけ貸してもらえればいいと思っていたのだが、そこにはダイニング・テーブルと椅子、3人掛けのソファ、ソファの横に置くような小さなテーブルが 2脚、ソファの前に置くような長いテーブル、そしてご丁寧にホテルの部屋なんかにありそうな比較的大きなランプのような感じの照明器具まで置いてあった。これに加えて冷蔵庫とディッシュウォッシャーは元々備え付けられていたし、言うまでもなくエアコンは備え付けだし、洗濯機と乾燥機はアパートの住人が使えるコインランドリーがあったので、家電製品も本当に必要なものは最初からそろっていると言っていい状態だった。

とは言うもののやはり足らないものはいくつかあった。まずはベッドだった。これは、この時の手伝いもしてくれた、僕が何かと世話になっている友人が余らせていたマットレスとシーツを貸してくれて解決した。他にも、食器は全くなかったし、電子レンジがないのも不便だった。また、テレビがないというのも少々寂しいものだった。そんな訳で、その週の土曜日に、その友人に手伝ってもらって量販店に買い出しへ行ってきた。買ったのは、食器が数点、店で一番安かったテレビと電子レンジ (どちらも 50ドルくらい) 、バスルームで使うシャワー・カーテンなど、全部合わせても 150ドル以内に納まるようなものだった。買ったものを部屋に運び込んで、それっぽい場所に置くと、生活環境はほぼ完璧に整ったと言っていい状況になった。

唯一欠けていたのはインターネット接続環境だった。電話や電気は、入居する前日に担当の会社に電話しておくだけで開通するほど簡単だったが、インターネット接続についてはそれほど簡単ではなかった。当時のオースティンで考えられる接続方法は、アナログのモデムを使う方法、 ADSLを使う方法、そしてケーブル・テレビが提供している接続サービスを使う方法の三つだった。当時はまだアナログ・モデムのユーザも多い時代だったが、僕はそんな遅い環境には戻れないと思っていたし、実際問題として家庭内サーバがある場合、モデムを使ってしまうと常時電話線がモデムにとられてしまって電話が使えないので、この選択肢は最初から全く考えていなかった。では ADSLかケーブル・テレビということになるのだが、いろいろと調べるとどうも ADSLの評判が芳しくなかったこともあって、結局ケーブル・テレビのサービスを使うことにした。

アメリカの場合、何も言わなくてもだいたいのアパートに最初からケーブル・テレビが来ている。だから、自分の所でインターネット接続サービスが使えるかどうか、というような心肺はしなくてよい。ケーブル・テレビの会社に電話をかけて申し込めば、やがてエンジニアがやってきてどうにかしてくれるのが普通だと思う。ただ、電気や電話と違って、電話をかけてから実際に開通するまでには少々時間がかかった。正確には覚えていないが、たぶん1週間程度は待たされたような気がする。

我が家のネットワークが開通するのに合わせて、僕は学校に置きっぱなしになっていたサーバ用 PCを持ち帰ってきていた。ネットワークが開通してからその PCを設定して、ようやく僕の生活のリズムが引越前のものに戻ったような感じがしていた。そして、丁度その頃 (正確にはその少し前) 、修理のために日本に送り返してあった PCも戻ってきた。止まっていた航空便もまた、以前同様に運行するようになっていたのだ。テレビやラジオをつけると相変わらず重苦しい雰囲気を感じさせられるばかりだったが、こうして僕も、そして社会全体も、一歩ずつ前進して徐々に普段の生活を取り戻そうとしていた、少しずつ奈津の終わりを感じられるようになってきた9月の終わりだった。

(続く)

関連記事

• テキサス、インターン物語 (1) --- 出発まで ---
• テキサス・インターン物語 (2) --- 調理実習 ---
• テキサス・インターン物語 (3) --- 小学生の情報処理教育 ---
• テキサス・インターン物語 (4) --- 中高生の情報処理教育 ---
• テキサス・インターン物語 (5) --- 夏到来 ---
• テキサス・インターン物語 (6) --- サマースクール ---
• テキサス・インターン物語 (7) --- 夏休み ---
• テキサス・インターン物語 (8) --- 新学期 ---
• テキサス・インターン物語 (9( --- 長い長い火曜日 ---
• テキサス・インターン物語 (10) --- 惨劇の後 ---
• テキサス・インターン物語(11) --- 教員研修 ---
• テキサス・インターン物語 (12) -- 親の思い --

http://java.sun.com/javase/technologies/accessibility/accessbridge/index.jsp

普通に考えれば、最新リリースの amd64版のインストール CDを使って新ハードウェアに OSをインストールして、古い環境のハードディスクをマウントして /home以下など、必要なファイルをコピーすれば良いのだが、これは誰かにそれなりの時間モニタを見てもらわないとできないので、この方法は今回は不採用。

教訓: ある程度 Unixが分かる若者をちゃんと育成しましょう。

じゃぁその代わりにどうするの?

まず、古い環境のハードディスクを1台目のドライブとして認識されるように新ハードウェアに接続してブートする。そうすると以前同様に sshでログインして普通に作業ができるので、後はネットワーク経由でやりたい放題。

ところが、なんと言っても旧ハードウェアのトラブルで引越を余儀なくされた関係で、旧環境のハードディスクが激しく壊れている模様。ブートしないので見てもらうと、マニュアルで ffsckしなさいというメッセージとともにシングル・ユーザ・モードに落ちてしまっていた。それではそこから fsck -a -y としようと思ったが、キーボードからの入力が受け付けられない。

そう言えば、以前 USBキーボードでシングル・ユーザ・モードを使う時に何かおまじないが必要だったのを思い出して調べてみると、どうやら loader.confか device.hintsに hint.atkbd.0.flags="0x1" と書けばいいらしいことが分かった。が、当然ファイルの書き換えはできないので、ブート・ローダのプロンプトで
set hint.atkbd.0.flags="0x1"
などと入れてみたのだがこれでもだめだった。そこでこの日はあきらめて、旧環境のハードディスクを自宅へ持ち帰って、自宅の FreeBSDの PCに接続して fsckすることにした。

教訓: 持つべきものは ATA/SATAを USBに変換するアダプタである。

気を取り直して

無事にfsckした旧環境のハードディスク (fsckには予想外に長い時間を要した) を、新 PCの起動ドライブとなるように接続して起動。見事に旧環境が新ハードウェア上で復活。これだけでも良いと言えば良いのだが、新環境は Opteronということで、どうせなら amd64のバイナリで動くようにしたい。その場合、各種ソフトウェアのリコンパイルも必要なので、それなりに時間が必要な作業となる。

新ハードディスクを設定

ということで、まずは amd64環境を構築するためのハードディスク領域を作る。幸い新ハードウェアには大量のディスクが載せてあるので、その内の一つについて fdiskと disklabelで設定することになるのだが、この部分は sysinstallの post configurationからやる方が楽ちん (だと思う) なのでそうした。

その際の失敗は、 disklabelのマウント・ポイントの設定で、 /だの /usrだのと書いてしまったために、いざラベルを書き込む時に、新しい、空っぽの領域が既存環境の /にマウントされてしまい、その先何もできなくなってしまったことだった。ということで、既存環境で sysinstallを使う時は、マウントポイントの設定に注意すべし。

amd64環境のビルド

新しく確保したハードディスク領域を適当なマウント・ポイントにマウントする。仮に /aにマウントしたとしよう。そうしたら以下を実行:

# make TARGET_ARCH=amd64 DESTDIR=/a world
# make TARGET_ARCH=amd64 DESTDIR=/a kernel
# make TARGET_ARCH=amd64 DESTDIR=/a distribution

これが全てうまく行けば、ビルドは終了。

ビルドを待つ間に

現在の /homeをまるごと新環境の /homeになる領域にコピーする作業を平行してやると良いだろう。もちろん旧ハードディスクをそのまま使う場合は不要だが、それでも再起動した時に ~/.sshがちゃんと見えるようになっていないと sshでのログインができないから何らかの作業をしておく必要はあるだろう。コピーに当たっては、 cpに -pRをつけるなり、 tar に -pをつけるなり、 rsync -aするなりして、ファイルのモードなどが変わらないようにするのが肝要。

電源を落とす前に

ファイルのコピー

少なくとも以下のファイルを新環境の /etc (つまり /a/etc) にコピーしておくと良いだろう。

• rc.conf -- ホスト名とか IPアドレスが書いてあるので必要
• /etcの passwd, master.passwd, pwd.db, spwd.db, group -- ユーザとグループ情報
• /etc/ssh/ssh_host* -- sshのホスト鍵 (なくてもいいけど、引き継いだ方が良いでしょう。)

他にも、 resolv.conf, ntp.confあたりはコピーしておくと良いけれど、しなくても困らない。もちろん、いろいろなサービスが上がっているホストの場合はもっといろいろとコピーする必要があるが、そういうホストの場合は、そもそもこんなネットワークにつながった状態での引越はしないだろう。

ログイン・シェルの確認

もう一つ重要なのは、自分のアカウントのログイン・シェルを、 shとか cshとか、元々システムにあるものにしておくこと。そうでないと、仮に再起動後に sshdがちゃんと上がってログインできるような状態になっても、シェルが不正で、 Illegal userがどうこうというログ・メッセージとともに、 sshによるログインが拒絶されてしまう。 (実際僕はログイン・シェルが zshになっていたためにしばらく悩んだ。)

ただし、 /a/etcにコピーした後のファイルをいじってログイン・シェルを変更するのは面倒なので、現在起動中のシステムで vipwを使って変更してからファイルをコピーする方が無難だろう。

fstabの編集

忘れてならないのが新環境の fstab (/a/etc/fstab) の編集である。これをちゃんとしておかないと、起動してもファイルシステムのマウントが正しくされず、全く使い物にならない。注意点は、次に起動する時には、このドライブが起動ドライブになるように接続し直すので、このドライブのディバイス名が変わる、という点。

便利かもしれない設定

新環境の sshd_configで、 PermitRootLoginを yesにしておくと、上述のようなログインできないとかいうトラブルの際に便利だと思うが、 noに戻すのを忘れないことが大切である。

新環境で起動

ここまですれば、後は一度 shutdown -p してから、新環境を構築したディスクが起動ドライブになるように接続し直して電源を入れればよい。うまくログインできたら、後は常用している各種ソフトウェアをひたすらインストールしたり、旧環境のハードディスクをどこかにマウントしてファイルをコピーしたりすれば良い。

ATA/SATA -> USB変換アダプタは偉大だ

一つ手元に持っておいて損はないと思った。アダプタを使わず電源だけでもかなり重宝した。特に旧ハードディスクを一時的に接続している時は、ケースの中のケーブルをがんばって取り回さなくても電源を確保できるので大変便利。そういう意味では、同様の機能を持つハードディスク・ケースよりも、コネクタが向きだしのアダプタの方が使い道が多そうだ。たとえばこんなの:

感想

いやぁ、何とかなるもんですね。

Opteron (たぶん 2ghz) は早い。

おまけ

ATA/SATA -> USB変換アダプタで接続してあった旧ハードディスクへのアクセスができなくなったので、 camcontrol rescan 0 とかしたら、それっきりうんともすんとも言わなくなりました。ということで、引越はまだ終わっていない。

他人に厳しいことを言う場合に自分の損得に言及すると、相手のためを思っての苦言ではなく、自分の利益のための攻撃のように聞こえてしまう。どんなに本質的に正しいことを言っても、相手には嫌悪感しか残さない。

心がささくれ立った時こそ、他人を思い、笑って暮らすべし。弱った自分にも周囲のためにできる最低限のことなのだから。

実は、ラップトップを使う場合でも、機種によって違っている。僕が愛用するレッツノートの場合、 FNキーを押している間はキーボードの右側のキーがテンキーと同じキーコードを出してくれるので、テンキーがなくてもなんとかなってしまう。一方、仕事関係で使わなければならない Thinkpad X61の場合は、 num lockをオンにしないとキーボードの右側がテンキーにはならないので、結局外付けのテンキーを使うというのが一番現実的な策となる。 (スクリーンリーダの設定で回避する方法もあるが、使いやすさの面で外付けテンキーの利用に軍配が上がると個人的には感じている。) ということでこれまでも外付けテンキーを使ってきたのだが、 USBポートが一つ取られてしまうこと、ケーブルが邪魔なこと、 USBのコネクタが飛び出しているのが邪魔なことなどが不満だった。そんな理由からずっと Bluetooth接続のテンキーを探していたのだが、これがどうもこれまでそういうものはなかったらしいのだ。ところが最近とうとう Bluetooth接続のテンキーが登場したというので、早速買ってみた。

届いたパッケージには、本体と単4電池2本、それにマニュアルらしきものが入っていた。電池を入れて、早速使ってみた。

ペアリングの方法

まずペアリングが必要なのだが、この方法が最初はよく分からなかった。が、適当にやっていたらできたので、以下に手順を書いておく。

1. 本体裏面にあるスイッチを onにする
2. スイッチの横に、ペン先などで押せるようになっているボタンがあるので、これを押す
3. PC側で Bluetooth機器の検索、追加を実行
4. PC側で正しく機器を見つけられると、セキュリティ・コードが表示されるので、このコードをテンキーから入力して Enterを押すと完了

搭載キー

搭載されているキーだが、普通のテンキーより1列多い。また、 0のキーが小さく、その横に 00のキーがある。追加された1列は、最上段の4つのキーで、左から ESC, TAB, BS, ALT+Enter (Excelのセル内改行用と思われる) と並んでいる。 Excel使いの皆さんにはそこそこ便利そうだという印象だ。

スクリーンリーダ、 JAWSと使宇場合

さて、本来の目的であるスクリーンリーダとの利用だが、実は大変残念なことにあまり良い結果ではない。 JAWSの場合、テンキーの 0を押しながら別のキーを押して発行するコマンドが多いのだが、このテンキーの 0とこのテンキーの別のキーを一緒に押しても認識されないようなのである。 JAWSユーザの皆さんにしか分からない話だが、結果として JAWS to PCなどの操作をこのテンキーだけではできないのである。

結論

ということで、 JAWSと使うのには向いていません。オークションにでも出そうかと思います。 (欲しい方はご連絡ください。) でも、普通は結構便利に使えると思います。

FreeBSD Ports Collectionのインデックスを検索すると、 fusefs-sshfsというのが出てきたので、とりあえず入れてみた。 (FreeBSD 6.x以降で使えるらしい。) が、入れただけだとどうしていいものやらよく分からなかったので、ちょっとあれこれ調べてみた。以下、分かったことなど。

sudo portinstall fusefs-sshfs

fusefs-*を使うための設定

/etc/rc.confに以下を記述して、 fuseで必用な kernel moduleがロードされるようにする:

enable_fuse="YES"

これで次にリブートすれば自動的にロードされるが、それまではロードされないので手動でロード:

sudo /usr/local/etc/rc.d/fuse start

一般ユーザが実行できるようにする

/dev/fuseへのアクセス許可

何も設定しないと、 /dev/fuse* というディバイスには root:operatorしかアクセスできない。 sshfsを使うユーザを operatorグループに入れれば済む話ではあるが、あまりスマートではないので、 devfsの設定で /dev/fuse* を 666にする。

1. /dev/devfs.rulesに以下を記述:

   
   [devfsrules_world_writablle=10]
   add path 'fuse*' mode 666
   

2. /etc.rc.confに以下を記述:

   
   devfs_system_ruleset="devfsrules_world_writable"
   

3. 本来ならばここで
   sudo /etc/rc.d/devfs restart
   を実行すればよいはずなのだが、なぜか 手元の FreeBSD 6.2-STABLE (ちょっと前のやつ) だとここでフリーズしてしまったので、やむなく再起動。再起動後は特に問題ない模様。

一般ユーザでも マウントできるようにする

sudo sysctl vfs.usermount=1
とすればとりあえず使えるようになるが、 OSを再起動するとこの設定が失われるので、 /etc/sysctl.confに以下を記述:

vfs.usermount=1

マウントの実行

ここまですれば準備完了。たとえば、 remote.example.comに userという名前のユーザでログインした時のホームディレクトリを、クライアントの /home/user/ssh/remoteにマウントする場合は、
sshfs user@remote.example.com: /home/user/ssh/remote
などとすればよい。

このようにしてマウントすると、後は普通にこのディレクトリの下のファイルにアクセスすることができる。エディタでの編集とか、その他のプログラムによるアクセスについても、概ね問題なさそう。ただし、 tail -f は期待したような動作にはならなかったが、これはもしかするとマウントする時のオプション指定でどうにかなるのかもしれない。

アンマウント

とりあえず使い終わったらアンマウントしておくのが賢明だと思う:

umount /home/user/ssh/remote

問題点

マウントしたままでほったらかしにしておくと、どうもよろしくないようだ。おそらく接続制がなくなったりしたタイミングでおかしなことになっているのではないかと思うが、しばらくほったらかしにしていたマウント・ポイントの下のファイルなどにアクセスしようとすると、アクセスしに行ったまま無反応になってしまうという状態が何度か観測されている。丁度 NFSがおかしなことになった時のような感じといえば、分かる人には分かるのではないだろうか。ということで、 NFSを AMD (Auto-Mount Daemon) で使うような感じで sshfsを使う方法を模索したいと思うのだが、ちょっと時間がないのでとりあえず先延ばし。

後、コマンド・ラインの引数のチェックが甘いのか、いろいろと試している時にとんちんかんなオプションを指定した時も、マウントできたふりをしつつ、実際にはうまく行っていなかったようで、マウント・ポイント以下へのアクセスで固まってしまった。こういうミスを防ぐためにも AMDが使えると便利だと思う。

結論

ちゃんと動いている時は激しく便利。

また、周囲の人々が積極的に、そして辛抱強く力士に言葉を教えているらしい点も見逃せないと感じる。本の中で、アルゼンチン人 2名の弟子を取った陸奥部屋の当時の女将さん、小川のりこ (点字で読んだので漢字は不不明) さんの以下の言葉が紹介されている。

「何回も、何回も、繰り返し、繰り返し。何度も、何度も、あきらめずに教えることかしら。私も途中でいやんなっちゃうことがあるんですが、そうすると向こうもあきらめちゃうんですよ。すぐスペイン語使い出しちゃうし。」

確かに僕が英語をそれなりに話せるようになった時のことを考えると、この本に書かれていることはどれも的確だと感じる。「言葉を学ぼう」ということよりも、「どうにか生活を成り立たせよう」という強い気持ち、周囲の人たちが辛抱強く接してくれたことは特に大きかったと感じるのだ。

僕がこの本を読んでみようと思ったのは、ある程度以上、なかなか日本語が上達しないように見える連れ合いにとって、何かヒントになることがあるのではないかと考えてのことだった。これは読む前から感じていたことではあるのだが、連れ合いには日本語を積極的に使わなければ保てない人的ネットワークはなさそうだし、また僕自身が家であまり日本語を使わないというのが大きな原因なのだ、ということを再認識させられた。やはりそういうネットワークがなければ日本語能力を伸ばそうという強い動機を持つことにつながらないし、僕が日本語を使わなければますますその動機が弱くなってしまう。

現状を考えると決して容易に解決できる問題ではなさそうだ。本にもあるのだが、他人が作った人的ネットワークというのはなかなか長く維持できるものではないから、本人が積極的にネットワーク作りをしなければならないと思うのだが、そのきっかけがつかめないということがある。一方、家の中でもっと日本語を使うようにするというのは、簡単そうで意外に難しい。しかし、そんなことも言ってられないので、できることからやっていくしかないのだろう。

ところでこの本、「英会話学校に通ってても全然しゃべれるようにならないなぁ」という不満を持っておられる方は、ぜひ読んでみると良いと思う。

安敦誌 - 最近の若い者ときたら・・・

MORAL:

道具がどんなに便利になっても、人間が工夫をする余地というものは当然に存在する。自分が若い頃に苦労して身に付けた技能が役立たなくなったからといって、若者を馬鹿にすべきではない。

という結論にたどり着くまでの彼の「妄想」がなかなか面白い。

前者については、その技能と同等のことをやってくれる機械を作ることが難しいと少なくとも今は考えられているものなので、「自分が若いときに身につけた技能が役に立たなくなる」ということはあまりないだろう。もちろんその技能に対する社会的な評価が下がってしまえばそうも言ってられないのだろうけど。

後者については、先人の苦労の結果、何かをするためのプロセスが幾度となく見直され、様々な削除や追かが繰り返され、最適化されて今にいたっているわけだから、むしろ昔より楽になっていて当たり前なのかもしれないという気がする。少なくとも情報技術の研究の世界なんかでは、昔よりも楽になり、一般的なタスクの実行に際して必要な技能が減るような方向で研究が進められないと困るのではないだろうか。つまり、「最近の若い者ときたら」と言えないというのは、その世界に身を置く人たちの努力が十分でなかったのか、努力の方向が間違っていたのか、それとも問題が大きすぎるか、ということなのだろう。

「最近の若い者ときたら」と言える大人たちは、彼らの努力の結果若者たちに利便を供与し、結果として若者たちが技能を習得する必要と機会を消し去った人たちなのかもしれない。そう考えると、僕も将来「最近の若い者ときたら」と堂々とぼやけるような年寄りになることを目指して働かないといけないのかもしれない、などと思った次第である。もっともそんなことばかりを言うような年寄りにはなりたくないが。

Emacsの TRAMPのバッファーを見てみると、正常にログインはできていて、プロンプトも返ってきていることが分かった。しかし、上述のメッセージから、これが正しくプロンプトとして認識されていないらしいことが分かる。 TRAMPの infoファイルを見てみると、プロンプトの判断は、 shell-prompt-pattern、 tramp-shell-prompt-patternという変数に設定されている正規表現に基づいているということだ。これらの変数の設定を眺めつつ、実際に返ってきている文字列を見てみると、どうもプロンプトの前にある CR (^M) が問題らしいことが分かった。

まず、 sttyの設定で CR, LFの出力を制御してみることにした。 ocrnl を設定することで、 TRAMPの問題については解決できるようなのだが、これをログインシェルの初期化で行ってしまうと、端末の表示がおかしなことになってしまうようだったので、この方法は断念した。 (もちろん sttyで -onlcrして端末ソフトの設定を変える、なんてことは試してみた。)

さて、ここでちょっと考えてみて思い当たることがあった。この TRAMPの問題は、以前は存在しなかったのだが、いつの頃からか発生するようになった、というのは前述の通りだ。それで、いつからなのかを考えてみたのだが、どうもログインシェルを tcshから Zshに変えた時からかもしれない、という気がしてきた。そこで Zshの infoファイルを調べて、何か問題解決に結びつくような設定がないかざっと見てみたのだが、これというものは見つからなかった。

だとすると、 Zshではなく shが起動されるようにすれば良いのではないかと思い、再度 TRAMPの infoを見てみた。で、分かったことは、接続方法として sshxもしくは scpx (デフォルトは ssh) を設定すると、標準のログインシェルではなく、 /bin/shが使われる、ということだ。

ということで結論は、 tramp-default-method を scpxに設定する、ということだ。実際、これでどうやら解決した模様。

インターネットは、私たちに新たな情報発信の手段をもたらしました。また、私たちの情報の受け取り方や情報との接し方、そして受け取ることのできる情報に多様性をもたらしました。このことは、私のような視覚障害者を含むいわゆる情報弱者の生活を一変させ、彼らの社会参加の機会の増大に結びついています。私は、成熟した社会とは多様性があり、それを受け入れることのできる社会だと考えます。インターネットに対する規制は、インターネットを無価値なものにするだけでなく、社会の多様性をも奪う結果になることは明白です。このような観点からも、私はこのような規制に断固として反対します。

また、もう一つ気になることがあります。本来は青少年の携帯電話によるアクセスに対するフィルタリングの必要性から始まっているはずの議論であるにもかかわらず、規制の対象がインターネット全体となっていることです。議論の進め方として大変乱暴な印象を受けます。こういった議論の進め方が他のあらゆる事柄についても行われる可能性を持つ政治にも大きな不安と不満を感じます。

なお、この件に関する声明がいくつか出ていますので以下にリンクします。また、このことに関しては以下にリンクする GIGAZINEの記事がよくまとまっており、より詳しい記事へのリンクも多く掲載していますのでぜひお読みください。

• 日本のデジタル社会を潰す「ネット有害情報規制法案」に反対する
• MIAU : 共同声明：私たちは青少年ネット規制法案に反対します
• GIGAZINE - 「青少年インターネット規制法案」が成立すると、日本のネットは完全に死ぬ

たぶん RSSの配信パターンはだいたい以下の五つに分類できるだろう。

1. タイトル、カテゴリー、著者、掲載日時のみ配信
2. それに加えて本文の最初の数十文字 (サイト毎に何文字かは決まっていると思われる) を配信
3. 本文の最初の数十文字の代わりに、最初の段落など、著者が記事毎に指定する冒頭部分を配信
4. 本文の内容は配信せず、 RSS配信用に書かれた要約を配信
5. 本文を全文配信

このブログでは、これまで上記 3. の方法を採用してきた。それが Movabletypeのデフォルトだったという消極的な理由もあったのだが、どちらかというと以前にも書いたが、僕の文章は無駄に長くなることが少なくないので、全文配信はしない方が良いだろう、と考えたということもある。

ところが、最近僕が RSSリーダーで読んでいるブログなどでも全文配信をするサイトが増えてきた。そうなってみて感じたのだが、ユーザの立場からも、書き手の立場からも、全文配信の方が便利なのではないだろうか。

まずユーザの立場から考えると、当たり前のことだが、わざわざクリックしなくても記事の全文を読むことができるという利点がある。そしてクリックしなくて良いというのは、実は結構重要な意味があると思うのだ。というのは、せっかくクリックして表示したページには、記事以外の情報やリンクがそれなりの量表示されているのが普通で、読みたい記事そのものにたどり着くのに時間がかかってしまうことも少なくないということがあるのだが、クリックしなくて良いということは、記事にたどり着き、そこに書かれている情報を取得するために必要な時間や労力を軽減できるというわけだ。 (そしてなぜだか、僕が読んでいるサイトの中では、ページのアクセシビリティがひどいサイトに限って全文配信をしていない傾向が強いような気がする。。。)

このことは、書き手にとっても大きな意味がある。「他人に何かを伝える」ことを目的にしている書き手であれば、何はともあれ記事の内容が読まれることが重要なのであるから、記事が読まれるための障壁は少ないに越したことはないはずだからだ。そして、どんなに内容がすばらしい記事でもタイトルが良くないためにクリックされずに読まれない、ということを防ぐこともできる。その一方で、 RSS全文配信をすることでページビューが減り、広告やアフィリエートによる収入が減るという考え方もあるようだ。しかし、「伝えること」よりも「稼ぐこと」の方が重要な目的になっている、いわば読者のことより自分のことを考えているサイトからはいずれ読者は離れていくのではないだろうか。少なくとも僕のサイトは (自分のためのメモという側面もあるのだが) 人に読んでいただくことが重要なので、その点を心肺する必要は全くない。

そして、 RSS全文配信はアクセシビリティの観点からも望ましいことではないかと思うのだ。前述の通り、全文配信されている場合、記事が掲載されているページにわざわざアクセスする必要がない。アクセスするページがアクセシビリティの高いページであればこのことはさして大きなメリットにはならないかもしれない。しかし、そのページのアクセシビリティが低い場合、ユーザはページにアクセスすることなく記事本文を読めるのだから、このメリットは大きい。

このことをもう少し深く考えてみると、こういうことではないだろうか。 RSSで情報を配信するということは、そのサイトが提供している情報に対して、 HTMLとは別のセマンティックなマークアップを施し、結果としてユーザが必要な情報だけを取り出して利用できるようにするということだと思う。そうだとすると、取り出せる情報の種類は多い方が良いし、取り出せない情報は少ない方が良い。利用可能な情報の中から必要なものだけを取り出し、ユーザの用途にあった形式に変換して提示する、それが Webが目指す情報提供の在り方であり、 RSS全文配信というのはまさにこの考え方に沿ったものなのだと思うのだ。

配信される RSSから必要な情報が取り出せるのならば、サイトのページの役割は何なのかと疑問に感じる人もいるかもしれない。あるいは、 RSS全文配信をすればサイトのアクセシビリティにはさほど気を配らなくても良いという勘違いをする人もいるかもしれない。しかし実際にはそんなことは全くない。サイトにはちゃんと存在価値があるし、アクセシビリティだって重要だ。 RSSを購読してくれるユーザにとって、最初にそのサイトを知り、 RSSと出会うためには、そのサイトの存在は必須だし、その内容が伝わりやすい形で作られていなければならない。それに、言うまでもないことだが、全てのユーザが RSSリーダーを使っているわけではないし、おそらく RSSリーダーを使っているのはどちらかと言えば少数派だと思う。RSSリーダーを使っている人であっても、コメントを投稿する時など、実際にその記事が掲載されているページにアクセスしなければならないケースもあるはずだ。だからやはりサイトの使いやすさやアクセシビリティは重要だ。そして、ページビューを稼がなければならないような人の場合は、使いやすいサイトを作ることで、 RSSリーダーを使っている人もそうでない人もサイトに誘導できることにつながるのではないだろうか。

もう一つの側面は、 RSSはユーザが好みに合わせて加工して情報を得るのに適していそうなのに対して、サイトの方は書き手やサイト運営者が情報をデザインするために存在しているということがあるだろう。このサイトの場合、僕の好みなどで Twitter, last.fmや各種ソーシャル・ブックマーク (各種と言っても今は2種類だけですが) を利用し、これらのサービスが保持している情報をサイト上に表示している。これに対して RSSのユーザはこういった情報は欲しければ自分で とってきて、自分にとって見やすいように加工すれば良いと言うことになる。僕は、そうやってユーザに選択権を与えつつ、何も選択しなくてもそれなりに使いやすく、情報の発信者が伝えんとしていることが伝わるように設計されたサイトがアクセシビリティの高いサイトであると思うのだ。

ということで、このサイトでは引き続きアクセシビリティを向上させる努力をしつつ、 RSS全文配信をすることにしたという次第である。

そしてより大きな理由は、リンクを新しいウィンドウで開くかどうかは、サイト運営者ではなく閲覧者が主体的に決定できるべきだと思うからである。サイト運営者はしばしば、運営サイトの外にあるページに対するリンクはポップアップするように設定する。これにはいくつかの理由があるだろうが、その一つはおそらく「そうなっている方が閲覧者にとって便利」 (だと運営者が思っている) ということだろう。しかし、実際にそうかどうかは閲覧者でなければ分からない。もしポップアップした方が便利だと閲覧者が思えば、彼らは自分でポップアップするようにリンクを開けば済む話なのに、本当に彼らがポップアップを便利だと感じるかどうかも分からないのに無条件にポップアップするようにリンクを作るというのは、やはりおかしな事の用に感じられる。

それでも、リンクをクリックする時にポップアップするかどうかが容易に予想できればまだしも、予想が困難な場合は単に使っていていらいらするサイトになってしまうだろう。このサイトでポップアップするかどうかは、外部へのリンクかどうか、ということ以外にもいくつかの要素に基づいて決めてきた。簡単に言えば、僕が読み手だったらポップアップすることを期待するかどうか、ということなのだが、冷静に考えると、これが全ての読者の感覚と一致する可能性は皆無であるように思われる。だから、ポップアップでいらいらさせられた読者も少なからずいたことだろう。

ポップアップしないようなリンクをユーザがポップアップするようにするのは簡単である一方、ポップアップする用になっているリンクをポップアップしないように開くのはそれほど簡単ではない。だから、ユーザに選択権を与えるという観点からもポップアップをしないというのが適切だと思うのだ。そしてユーザに選択権を与えるというのは、アクセシビリティの基本的な考え方である。ということで、このサイトでは今後ポップアップは使いません。

廣澤　デザインがほとんど同じですからね。一番困るのはらくらくホンと勘違いされることです。店員が説明の中でソフトバンクのらくらくホンみたいな言い方をするかもしれません。すると、音声読み上げがあると思って８２１Ｔを購入した視覚障害の方が当惑するかもしれません。

記事によれば、これはNTTドコモプロダクト＆サービス本部プロダクト部第三商品企画担当課長の廣澤克彦氏の発言だ。が、この人は本機でそんなことが起きると思っているのだろうか。ちょっといくつかのケースを考えてみよう。

たとえば、携帯電話を欲しいという視覚障害者が量販店などに行って「らくらくホンが欲しいんですけど」と言えば、普通はドコモの担当者が出てきてらくらくホンについて説明してくれるだろう。そうではなくて、ソフトバンクの担当者が出てきて「はい、こちらがソフトバンクのらくらくホンでございます」とか何とか言って821Tについて説明を始めるようなことがあるだろうか。仮にそういうことがあっても、携帯電話を購入する場合、自分が欲しい機能が搭載されているかどうかを確認してから購入するのが当たり前だ。特に視覚障害者の場合、音声読み上げが搭載されているかどうかは非常に重要なので、その点を納得せずに買うということは考えづらいのではないか。それともこの人は、視覚障害者はそういう判断ができない人種だとでも思っておられるのだろうか。

別の例も考えてみよう。量販店ではなく、ソフトバンクのショップに携帯電話を求めてやってきた場合だ。しかし、まずそもそもらくらくホンが欲しい人がソフトバンクのショップにやってくるとは思えない。仮にそういう人が来たとしても、結局詳しく機能について説明を受ければ821Tが自分の求めているものではないことが分かるのではないだろうか。

本当にユーザのため、業界のためを思うのであれば、ドコモや富士通はこんな了見の狭いことではいかん、というのは冒頭でリンクした以前の記事で書いたとおりだ。さらに言うならば、本当にユーザのことを考えているのならば、ソフトバンクに対して販売に当たって誤解が生じないようにするように求める、というのがやるべきことだったのではないだろうか。しかし、ドコモの了見が狭いことはもう仕方がないことだという気もするので、この発言も腹立たしくはあるものの、さして気にはならなかった。それよりなによりあきれてしまったのが、このインタビューを行い、記事を執筆した岩下恭士氏の発言だ。上に引用したドコモ廣澤氏の発言に対する発言はこうだ。

毎日新聞「ユニバーサロン」 - 《開発者に聞く》ドコモ、究極のユニバーサルケータイ－－エグゼクティブのためのほぼ全部入りらくらくホンプレミアム

岩下　あり得ますね。

そしてさらに続くドコモの主張に対してこんなことも言っている。

毎日新聞「ユニバーサロン」 - 《開発者に聞く》ドコモ、究極のユニバーサルケータイ－－エグゼクティブのためのほぼ全部入りらくらくホンプレミアム

岩下　よく分かります。シニア向けでもかっこいいもの、簡単でも高機能というコンセプトは、ユーザーの声をしっかり受け止めたらくらくホンが切り開いたものですからね。単なるさるまねは止めてくれと言いたくもなりますよね（笑）。ユーザーの選択肢が増えるという意味では、よい面もあると思いますけど？

[略]

岩下　８２１Ｔはあまりにも似すぎているということですね。確かにケータイにさほど関心のない人の中には、ドコモかソフトバンクかなんて気にしていない人もいますから。らくらくホンだと思って、ドコモショップに問い合わせがくる可能性があります。しかし、逆もありでしょう。そういう意味では、明確なコンセプトのない（？）ソフトバンクは自分の首を絞めるようなことをしてしまったのかもしれません。

この岩下氏の発言でインタビュー記事は終わっている。

岩下さん、係争中の件について一方の当事者の言うことだけを伝えるばかりか、それに貴方が同調してどうするのですか! それともソフトバンクと東芝に取材した結果分かった事実に基づいて「さるまね」だとか」明確なコンセプトがない」だとか言ってるのですか!? もしそうなら、その取材に基づいた情報を記事にしていただきたい。もしそうでないなら、こんなドコモの提灯記事を書いたことを恥ずかしく思うべきでしょう。仮にも新聞社の社員なのだから、もっとジャーナリスト意識を持って記事を書いていただきたい、そう申し上げたい。

ところで、この記事を読んでどうにも腑に落ちないことがある。視覚障害者が本当にこの2機種を混同することがあるのか、ということだ。ドコモによれば、デザインが酷似しているからだ、というのだが、視覚障害者が見た目で勘違いすることはないのではないかという気がするのだ。なんと言っても僕たちは携帯電話を「見て選ぶ」ということは基本的にないのだから。