convmv
- ファイル名のエンコード変更convmv というスクリプトがある。これは、ファイル名のエンコードを、他のものに変更する。
現在、Windows 環境において使われるファイル名エンコードはまちまちであり、下手をすれば Shift_JIS が用いられている可能性が多い。そもそもファイル名にマルチバイト文字を使うべきではないのだが、それはそれ、そんなことを知らない人間もそこらじゅうにごろごろと存在している。よって、日本語ファイル名をつけられたトンデモファイルが Linux 環境へと渡されてしまう場合がある。USB メモリやフロッピーのようなメディアを介したデータ授受の場合は尚更だ。
そこで役に立つのが、この convmv
。こいつを使うと、Shift_JIS エンコードのファイル名を EUC に、果ては UTF-8 にも変換できる。しかも、-r
オプションを付加することによって、ディレクトリを再帰的に潜って変換してくれるようになる。大量のファイルをコンバートするのも楽というわけだ。
詳細な使い方は より詳細な説明や man ページを参照してもらおう。
ただ、ダウンロードしたそのままの Makefile は Vine Linux において man ページの位置がおかしなことになってしまう。そこで、インストール位置を修正したパッチも用意してみた。
Makefile.convmv-1.08.vine.patch が、そのファイル。
使い方は以下の通り。
convmv
のダウンロードファイルを解凍するMakefile.convmv-1.08.vine.patch
を現在地にコピーするpatch -p0 < Makefile.convmv-1.08.vine.patch
を実行するこれでパッチをあてることができる。
そういえば、「ファイル名に日本語を使うな」と教えられたのも高専1年の頃だった。コンピュータに関してはまだビギナー(タコ?)であった私。だが、文字コード云々の話より前に、日本語を使うと深刻な問題に直面することを身をもって味わい、以後一切使うことを止めた。但し Linux 上でだったが。
理由は単純。kterm 上から日本語を入力するのがだるかった。それだけ。
あと、様々なプログラムに読ませるとき、対応していないものがあるのも痛かった。万全を期すなら、特定記号以外の英数字を用いる。それが基本になった。
後で文字コードの知識を得た時――そして、Windows で日本語ファイル名にしたファイルを Linux で見た時。私は項垂れるしかなかった。
それらも、UTF-8 によってどうにかなる日が近付いている。Fedora Core ではデフォルトエンコーディングが UTF-8 になった。Windows でも対応している。あと 10 年もすれば、EUC や Shift_JIS は時代遅れになるかもしれない。
ファイル名ひとつとっても、時代の流れを感じられる。それを改めて実感させてくれた、convmv
だった。
昨日少しだけパロディとして書いた「ヘルシング」に出てくるあの少佐が吐いた迷演説。一部だけでは飽き足らず、全部パロディにしてみた。
注意。このパロディ文書は私が個人的に作成したものであり、FSF、GNU プロジェクト、R.M.Stallman 氏等のあらゆる組織・人物とは一切関係ない。詳しくは An Escape Clause を参照。
では、どうぞ。
……
諸君 私は Emacs が好きだ
諸君 私は Emacs が大好きだ
プログラミングが好きだ
文章作成が好きだ
マークアップが好きだ
CUI が好きだ
Bash が好きだ
UNIX が好きだ
FSF が好きだ
チャットが好きだ
ゲームが好きだ
職場で 出張先で
学校で 研究室で
自宅で 友人宅で
喫茶店で ファミレスで
屋外で 屋内で
そのコンピュータ上で行われるありとあらゆる編集行為が大好きだ
ソースコードをならべた gcc の一斉コンパイルがメッセージと共に完了するのが好きだ
画面いっぱいに広げられたウィンドウが分割で四つになった時など心がおどる
ハッカーの操る Emacs の Lisp が難題を克服するのが好きだ
悲鳴を上げて Windows から飛び出してきた秀丸使いを Emacs に引き入れた時など胸がすくような気持ちだった
指先をホームポジションにそろえたブラインドタッチでソースの海を縦断するのが好きだ
恐慌状態の新人が Ctrl-x Ctrl-s を何度も何度もタイプしている様など感動すら覚える
十字キー主義の愚か者達に Ctrl-f Ctrl-b Ctrl-p Ctrl-n を教え込んでいく様などはもうたまらない
もがき苦しみながらコーディングされた汚いコードが私の振り下ろした指先とともに音もなく Emacs にせっせと整形されるのも最高だ
哀れな抵抗者達が雑多なエディタへ健気にも実装した機能を Emacs Lisp プログラムがキーバインドごと尽くコピーした時など絶頂すら覚える
dissociated-press
に滅茶苦茶にされるのが好きだ
必死に守るはずだったデータが破壊され終いには暴走しプロセスが殺されていく様はとてもとても悲しいものだ
TRON の漢字対応に押し潰されて殲滅されるのが好きだ
Windows に追いまわされ害虫の様に地べたを這い回るのは屈辱の極みだ
諸君 私はエディタを地獄の様なエディタを望んでいる
諸君 RMS に付き従うハッカー諸君
君達は一体何を望んでいる?
更なるエディタを望むか?
情け容赦のない糞の様なエディタを望むか?
支離滅裂の限りを尽くし三千世界のプロセスを殺す嵐の様なエディタを望むか?
『Emacs! Emacs! Emacs!』
よろしい ならば Emacs だ
我々は渾身の力をこめて今まさに振り降ろさんとする十本の指先だ
だがこの暗い闇の底で四半世紀以上もの間堪え続けてきた我々にただのエディタではもはや足りない!!
Emacs を!!
一心不乱のハックを!!
我らはわずかで小さな集団 万人に満たぬ技術者に過ぎない
だが諸君は一騎当千の古強者だと私は信仰している
ならば我らは諸君と私で総力100万と1人の技術者集団となる
我々を忘却の彼方へと追いやり眠りこけている連中を叩き起こそう
髪の毛をつかんで引きずり降ろし眼を開けさせ思い出させよう
連中にホームポジションの味を思い出させてやる
連中に我々のタイプの音を思い出させてやる
天と地のはざまには奴らの技術では思いもよらない事があることを思い出させてやる
100万ものキーボードによる騒音で
世界を覆い尽くしてやる
「最初にして最後の聖 GNU ティウスより全 Emacs 使いへ」
目標他種エディタ使用者全員!!
第二次 GNU Emacs 普及作戦 状況を開始せよ
諸君 私は Emacs が好きだ
諸君 私は Emacs が大好きだ
……
私は高専に入学して1年目、即座に Windows と Linux 双方の環境で授業を行う日々に突入した。
Windows では タッチタイピング、HTML、Word、Excel を。
Linux では Perl とコマンドと Emacs を。
それぞれ学んだ。
その当時、私は Emacs に「使い辛い」という感情を抱いていた。何故なら、普段使用していた OS が Windows だったからだ。カーソルは尽く十字キーで操作し、Ctrl-x、Ctrl-c、Ctrl-v だけショートカットを覚えていた。
だが、年月は私を変えた。
ノートパソコンに Linux を導入した時から、私は Emacs に心底惚れ込むことになる。
あらゆる動作をホームポジションから動かさずに行えるキーバインド。
エディタという枠に囚われず、Lisp によるプログラミングでいかようにも拡張できる豊富な機能。
ソースコードをいじるときにストレスを感じなくさせてくれる支援機能の恩恵。
それら全てを私は愛するようになった。
……だが、私の周囲は違っていた。Emacs 嫌いが多かったのだ。
理由を挙げさせれば、何てことはない。昔、私が思っていたことそのままだった。
一つをのぞいては。
最後の一つ。それが決定的な違いだったのだ。
それは、言い替えれば「動機の有無」ということになる。Emacs をどうしても使いたいんだ、ないしもっと便利に楽をするにはどうすればよいかという欲望があるかどうか。
私には両方があった。周囲には両方が無かった。
これは決定的な差異であると思う。人間は欲望があるからして何かを創造する。使ってみる。私はとにかく楽をしたかった。いちいちホームポジションから手を動かしてマウスに持っていくことが億劫になった。十字キーを押すのも遠いから面倒になった。ソースコードを整形するのが大変になった。いくつもエディタを立ち上げてメモリを消費することがきつくなった。
それら全部を解決する手段は、Emacs を使うことだった。手をホームポジションからあまり動かさずに済むようになったし、自動改行と整形を組み合わせればソースは勝手に綺麗になってくれる。立ち上げる Emacs は1つだけで、あとはウィンドウを分割すればいい。バッファにファイルを溜め込んでおいて、必要になればすぐに呼び出せばいい。
完璧だ。……とはいえ、まだ不平を言いたいところはある。文字コード認識がそうだ。だがこれも、自分で何とかできないかと頭を捻った方が生産的である。今抱えている最大の問題だ。
そう。UNIX のソフトウェア全体に言えることなのだが、Emacs は手をかけてやればやるほどに応えてくれ、更に磨きがかかっていくのである。これほど楽しいことがあるだろうか! 楽をするには苦労が必要なのだ。Perl コミュニティに存在する格言は、それを如実に物語っている。
プログラミングの三大徳目は、無精、短気、傲慢である。
Perl Community
これら全てを実現するには、実際のところ「努力、忍耐、謙遜」が必要になってくる。無精だからこそ努力しなければ楽できない。短気だからこそ忍耐を要求される。傲慢だからこそ謙遜しなければいいものができない。
そして、その思想は「技術者」と呼ばれる人間に通底しているような気がする。私自身、高専で叩き込まれたことだ。
だからこそ、Emacs は技術者・職人に好まれるのだと思う。Emacs は、手塩にかけて育てていける、自分だけの「道具」なのだ。大工が自分専用のカンナやノミを長い間使い続け、自らの一部であるかのように愛着を持っていることと、全く同じ心理状態なのである。だが、最初は何の変哲もない、武骨な道具に過ぎない。道具を使い込むことのできない人間が、Emacs を嫌ってしまうのかもしれない。若しくは、他の素晴らしい道具を使っているか、だ(Vim 使いなど)。
スルメのように、噛めば噛む程味が出る Emacs。その魅力を伝えるのは、対象が「楽をする」という言葉を見誤っている限り伝わらないのかもしれない。
昨日の記述を見た人が、Google Mail アカウントをくれました。ありがとうございます。
で、早速ログイン。見た目は一般的なメーラーの3ペインによく似ている。Ajax 技術を使っているという話も、そのレスポンスの早さから伺える。
面白い。
POP や SMTP が使えるという話を聞いたことがあったので、早速 Sylpheed からログインできるかどうかを試してみた。以下、その手順。Sylpheed 1.0.3 を使用。
でも、うまくいかない。何故か送信時、「データの送信でエラーが発生しました」と言われて終わってしまう。原因不明。なんやねん。しかもメールそのものは送信できている。……何だか気持ち悪い。
と思って調べてみたら、案の定 Sylpheed 作者である hiro 氏の Blog に原因が載っていた。どうやら GMail 側のエラーらしい。送信はできているし、エラー表示も Sylpheed 最新版では表示しないでログに落とすだけにしてあるようなので、現状無視。つーか未だに Sylpheed 1.0.3 を使っている私が駄目なんだが。アップデートしようかなぁ。
少し話を変えるが、得てしてこういう紆余曲折を楽しめない人種が存在する。こうするとダメだからああして……という行為を好まない人間のことだ。その傾向はコンピュータに慣れ親しんでいない人間に顕著である。
Sylpheed に限らず、ソフトウェアというものは、手を掛けてやればやるほど輝きを発するようになる。子供や宝石と同じだ。とはいえ、磨いても磨いてもあまり変わってくれないものもある。代表例は Windows だろう。Linux と Windows を両方使ってみれば、その違いは一目瞭然である。
もう少し突っ込んだ話は、明日することにしよう。
この Google Talk と呼ばれるサービスは、プロトコルに XMPP を使っているので、特に新たな実装を待つまでもなく Linux 上から Gaim を用いて利用することができる。実に嬉しいことだ。流石 Google。
ただ、問題点もある。Gmail のアカウントが無いと利用できない ことだ。よって、私は使えないことになる。……誰かアカウントくれないかな。
現在、私が仲間内で使っているのは MSN のプロトコルだ。所謂 MSN メッセンジャ(以下メッセ)の利用者が多いから。皆 OS は通常 Windows を利用しているし、メッセは IE と同じくプリインストールされている。それに、殆ど皆が Hotmail のアカウントを持っている。私もそうだ。よって、一番手軽に使えてしまうのである。
私は最近殆ど Linux 上で作業を行っているので、メッセに繋ぐ時には Gaim を使っている。IRC だったら Emacs 上で Riece を使ってもよかったのだが、メッセには対応していない。
それにしても、Gaim は凄い。MSN や IRC は勿論のこと、Yahoo、AIM/ICQ、Gabu-Gabu、GroupWise、Napster、Zephyr、そして肝心の Jabber (XMPP) に対応しているなど、何でもござれ状態。流石オープンソース。自由ソフトウェア。
更に Gaim は Windows でも使える。だから、多分私が Windows で使うインスタントメッセンジャクライアントも Gaim。Linux 版でもかなり動作が軽くていい感じなので。
インスタントメッセンジャは、使ってみるとかなり便利。ファイルも転送できるし。セキュリティさえどうにかすれば仕事でも使えるかもしれない。
電話より安く済むし(結局それか)。
トリビアの泉で登場しており、おっ、と思ったのが金魚すくいロボット。ごく一般的であろうロボットアームを用いて、金魚すくいを行わせる代物。
ただ、まだまだ研究中らしく、動作がぎこちなかった。トリビア撮影用にソフトウェアのバージョンを落としたのだろうか。もしくはトリビア側で失敗例だけ編集して繋げたか……それとも、本当にあれが実力なのか。実物を見たことがないので何とも言えないのがもどかしい。
もう少し技術的な内容が載っているページを参照すると、画像処理の際、次のような対象絞りこみを行っているらしい。
うーん。あまりにもアバウトすぎていまいちピンとこない。この研究についての論文でもないだろうか。部外秘の可能性もあるが。
「制御」の難しさを改めて思い返させてくれた。
「フィリップ・K・ディックのすべて」(フィリップ・K・ディック 著 ローレンス・スーチン 編 飯田隆昭 訳 ジャストシステム)をついに入手。神保町にて。因に5250円也。元値2500円。プレミアついてんだなと思わせる。
まだ殆ど読んでない。これから読破する。
そうそう。就職内定した。小さいソフトハウス。個性的なところなので面白そう。社員寮あるし。これであとは卒業するだけ。ヤッホゥ。
昨日の続き。
まずは indexOf
と lastIndexOf
。
var alphabets = ["a", "b", "c", "d", "b", "a"]; alphabets.indexOf("b"); // 1 が return される alphabets.lastIndexOf("b"); // 4 が return される alphabets.indexOf("b", 2); // 4 が return される alphabets.lastIndexOf("b", 3); // 1 が return される
ここで注意すべきなのは2点。
return
してくること(配列先頭/末尾からいくつめにあるか、ではない)1は特に問題ないだろう。問題は2の方だ。もしかしたら lastIndexOf
がどうして 4 を返して来るのかと首を捻った方もいるだろう。しかし、よく考えれば配列番号を返すのだから、配列末尾から検索して最初に発見できる b は、配列番号で4番にあるだけのこと。決して「後ろから数えて」ではない、という点に注意すればよい。
次は、some
と every
を……といきたい所だが、まずは引数として渡す関数を定義しておく。以下の関数 isAlphabetOnly
は、value
の内容が全て英語アルファベットであれば true
を、でなければ false
を返す。
function isAlphabetOnly(value, index, array) { var r = /^[a-zA-Z]+$/; return r.test(value); }
では、実例に入ろう。
var arr_1 = ["a", "b", "c", 1, 2, 3, "d"]; arr_1.some(isAlphabet); // true が return される arr_1.every(isAlphabet); // false が return される var arr_2 = ["a", "b", "c", "d"]; arr_2.some(isAlphabet); // true が return される arr_2.every(isAlphabet); // true が return される var arr_3 = [1, 2, 3]; arr_3.some(isAlphabet); // false が return される arr_3.every(isAlphabet); // false が return される
一目瞭然、といったところだろう。1つでもアルファベットが含まれているならば some
で true
が返ってくる。そして、全部アルファベットなら every
も true
になる。しかし、アルファベットが全く含まれていない場合は some
も every
も false
になる。
余談だが、例えば数理論理学のような分野では以下の限量子を用いる。
それぞれ、all は every
、 exist は some
に対応している。すると配列オブジェクトは所謂「集合」なので、集合論の記号を導入して every
と some
のしていることを以下のように表せるかもしれない(自信なし)。
A = (a, b, c) ∀x (x∈A) ∃x (x∈A)
微妙……。
次は filter
。
var arr_1 = ["a", "b", "c", 1, 2, 3, "d"]; var after = arr_1.filter(isAlphabet); // ["a", "b", "c", "d"] が return される
全ての要素について条件判断をし、アルファベットであるものだけを抽出している。arr_1
は変更されない点に注意。
最後に、forEach
と map
。
function plusValue(s) { return function(value, index, array) { return value + s; } } var alphabets = ["a", "b", "c", "d"]; // ["a.forEach", "b.forEach", "c.forEach", "d.forEach"] になる alphabets.forEach(plusValue(".forEach")); // ["a.forEach.map", "b.forEach.map", "c.forEach.map", "d.forEach.map"] になる // 但し alphabets は変更されない var final = alphabets.map(plusValue(".map"));
便利なのでクロージャを使ってみた。どちらも全ての要素に対して処理を行う、という点において一致しているが、唯一完全に違うところは forEach
が呼び出し元の配列を直接変更するのに対し、map
は変更した配列を return
するだけで元の配列に手を加えないという点だ。ここは十分注意する必要がある。
ということで、簡単ではあったが詳細な解説を終わる。ある意味自分用のメモであるが、役に立てば幸いだ。
元ネタ記事にはいくつか誤植が存在するので、戸惑うこともあるかもしれない。特に例示ソースのミスは手痛いものがある。以下、私が見つけた誤植のリスト。
alert(aColors.indexOf("green", 4)); //outputs "2"
になっている行:lastIndexOf
の間違い他にもありそうだが、とりあえずこれだけ。
元ネタ記事を読んでみると、新しく追加されるメソッド、物凄く便利そうでワクワクしてしまった。以下、簡単な解説。
indexOf(item, start)
配列先頭から探索を開始し、初めに見付かる item が配列番号の何番目にあるかを返す。存在しない場合は -1 を返す。
start に数値がある場合、該当する配列番号を先頭として探索を開始する。
lastIndexOf(item, start)
配列末尾から探索を開始し、初めに見付かる item が配列番号の何番目にあるかを返す。存在しない場合は -1 を返す。
start に数値がある場合、該当する配列番号を末尾として探索を開始する。
some(func)
配列中に、関数ポインタ func が指定する条件に一致する要素が一つでもあるならば true
、そうでなければ false
を返す。
every(func)
配列中に、関数ポインタ func が指定する条件に一致する要素を全て含んでいるならば true
、そうでなければ false
を返す。
filter(func)
配列中にある、関数ポインタ func が指定する条件に一致する要素を全て抽出し、配列として返す。
forEach(func)
全ての配列要素に対し、関数ポインタ func が指定する処理を実行する。Perl における foreach
文・配列に対する for
文と同一。呼び出し元の配列を直接変更する。
map(func)
全ての配列要素に対し、関数ポインタ func が指定する処理を実行した後、変更された要素を配列として返す。forEach
の返り値が配列になった感じだが、呼び出し元の配列は変更されない。
func の引数も全て意味を持っている。以下の通り。
function func(vValue, iIndex, aArray) { /* code */ }
vValue
には、現在参照している配列要素そのものが入る。
iIndex
には、現在参照している配列要素の配列番号が入る。
aArray
には、現在参照している配列そのものが入る。
これらを組み合わせて、配列に関する様々なコードを書くことが非常に容易となる。明日は具体的なコードを示して更なる解説を行ってみる。
昨日は昼頃に地震があった。丁度友人宅でだべっていた時のことだった。
勿論、誰も驚かなかった。
何故か? それが静岡県民クオリティ(違 ……以下、(脚色済み)地震発生当時の会話。
友人:「お、揺れてるんじゃね?」
私:「何が?」
友人:「地震っぽいね」
私:「そういえばそんな揺れだな」
友人:「震度はどれくらいかな?」
私:「3……くらい?(すかさず TV のチャンネルを NHK 総合に)」
友人:「もしくは2か」
私:「(TV のテロップを見ながら)あー、この辺は3らしい」
友人:「もしかして、また震源千葉の方?」
私:「まだわからん」
……こんな感じ。何というか、緊張感がまるでない。日々地震に慣れ親しんでいるからか。でも多分、震度5レベル以上の地震だと過剰反応するのだろう。条件反射的に机の下へ潜り込み、じっと待つのだろう。
東海地震が発生したら、静岡県なぞひとたまりもない。津波は来るし、浜岡原発は意外と地盤がゆるいところに建っているからダメージを受けるだろうし、何より最悪なのは富士山に刺激を与えてしまうことだ。噴火されたらたまったもんじゃない。海からは水、空からは火。どうしろと?
東京よりはまだ建物も低いし人口密度も少ないので死人は少なくなるのかもしれない。個人的には東海地震、震度5ぐらいのやつが断続的に来てくれた方がありがたいんだが……。
前回の続き。
Blog は、ある意味で便利になった外部記憶だといえる。HTML 直打ちとの差は、ヒエログリフを粘土板へ書いていたのに、日本語を紙へ書くようになったものだと思えばいい。それだけ楽になったのだと。
こうしてひとつの道具という形に還元された結果である Blog ツールを用いて、現代人は自分の思考を徐々に蓄積させている。
これ以上は敢えて言う必要もないだろう。有用性は語りつくされているし、利便性も欠点も既に提示されている。
ただ、これだけは言いたい。
盗み、考え、書き留めよ。
以上。
今回で、取り留めもなく書いてきた連載(のようなもの)も終了する。またいつか、加筆修正して一つの文書としてまとめるかもしれない。
この文書が、暇潰しのネタになっていれば幸いである。
因に、私は Blog ツールを用いていない。未だに手打ちで XHTML を書いている。もし手打ちが面倒になったとしても、恐らく規則的に書かれた内容を持つ単純テキストファイルを喰わせ、XHTML に成形したものを吐くスクリプトを組むだろう。その方が自分で実装できるという点で面白いし、カスタマイズも容易だ。ただ、今は直打ちが好きだからそうしているだけである。それなりに面倒ではあるのだが、xyzzy や Emacs ならメジャーモードに補完機能がついていたりして手間を省いてくれる。
前回の続き。
話を Blog に戻そう。
そもそも Blog は Web 日記の派生型である。公開され、公の目に曝されることを前提とした――意味をもっていようがいまいが、その意味付けは筆者の裁量に委ねられている――文章。ここには実際に、2つの特質を包含できるだけの余裕が秘められている。「垂れ流しの文章」と「練り上げられた文章」である。
この二つに繋がりが存在することは前述の通りである。またそれは、現代の高速性が生み出した忙しさによって束縛されていることも。
「練り上げられた文章」を書こうとするには、必ず「垂れ流しの文章」が必要である。ストックする場はどこでもよい。ポケットに忍ばせた手帳でも、自分の記憶でも。だが、現代においては別の手段が次々に生まれた。Web サイトもその一つである。
だが、Web サイトには問題点があった。そう。専門技術の必要性である。特に HTML を書くことは、この言語がかなり単純であるという点を考慮に入れたとしても、所謂一般人にとっては面倒であり難しいものであった。
HTML マークアップそのものを原因として位置付け、その手間を軽減することで WWW への出版を促進するツールとして生まれたのが、IBM の「ホームページビルダー」に代表されるような Web オーサリングツールである。しかし、これらは決定打には成り得なかった。確かにそれなりに大規模なサイトの構築には向いていたのかもしれないが、個人サイトの管理者は、そのツールを用いることすらも面倒がったのである。
そこで出てくる技術的・道義的議論は既に出尽くしているので割愛する。
こうして生まれたのが Blog ツールであった。本来、個人ニュースサイト的な情報発信に用いられるために UA 側からフォームを用いて直接編集を可能にした。いちいちオーサリングツールを用いたりマークアップを施しているようでは、情報の鮮度が落ちてしまうからだ。無論、BBS の構築で培われてきたノウハウを生かしたことは言うまでもないだろう。
故に Blog は台頭してきたのである。比較的容易・高速に文章を Web へ公開することができるからだ。HTML や XHTML、CSS、HTTP、FTP、サーバシステムなどの知識を持っていなくてもよい……専門知識を覆い隠すことで生まれた、一般性の稚児。
続く。
暫くインターネットと隔絶した生活をしていたので更新もクソもないという状況だったわけで。今日は連載っぽくなってるのを一旦筆休めして、別ネタを。
フィリップ・K・ディックの邦訳を掻き集めている昨今、あり得ないぐらい大量の入手に成功した。以下、そのリスト。
東京は神保町、古本街にて入手。店の名は羊頭書房。前に行ったときは無かったのに、今回は大漁。もうウッハウハ。全部併せて7850円也。因に S-F マガジン以外は文庫本。一番高かったのが「銀河の壺直し」で2200円。元々の定価が480円だから、実に4倍もの高値。当然と言えば当然の値段ではある。何せ発行元のサンリオ SF 文庫は、既にレーベル自体が消滅しているのだから。同社から再販の可能性は皆無。他社からの出版にしても、現在それ程加速しているわけでもない。この前東京創元社から「ブラッドマネー博士」が再販された時は嬉しくて速攻書店に駆け込んだものだ。
現在は「怒りの神」を読んでいる途中。以下、裏表紙あらすじの引用。
第三次大戦で地球は全滅した。
人々が奇妙な逆説を信仰したためだった。エネルギー開発庁長官カールトン・ルフト・オイフェルは数字の詐術を巧妙に使った演説で人々を説得したのだ。国家の機能は一定の生存者がなければ維持されないというのは嘘だ。マイクロ化されたデータのカプセルが安全に貯蔵されていれば愛国的思考形態は残って行く。1983年の演説で彼はそう主張した。そして5000マイル上空の人工衛星から、偉大な無差別爆弾(グレイト・オブジェクトレス・ボム)=怒りの神を爆発させた。
今、手足のない画家ティボール・マクマスターズは第三次大戦の背後に隠れている神ルフトオイフェルを求めて全滅したあと恐ろしい突然変異体たちの跋扈する異邦の地を二輪車を牛に引かせて旅していた。あの悪魔でもあり神でもあるルフトオイフェルの肖像画を描くよう教会から依頼されたのだ。それを妨害しようとする追跡者……すさまじくも暴力的なディック & ゼラズニイの驚嘆すべき記念碑。
「怒りの神」(サンリオ SF 文庫)
実際に読んでみると、ディックにしては割とおとなしい展開。「流れよわが涙、と警官は言った」と「暗闇のスキャナー」の間に出版された作品であり、またゼラズニイとの共著でもあるからか。時間を掛けて書き上げたらしく、それが物語の展開速度にも影響している。
まだ読み途中なのだが、結構面白くなってきたところ。物語も佳境、ティボールがそろそろルフトオイフェルと出会えるか……そういう場面。
他の本もじっくり読もう。まだ時間はある。
昨日の続き。
何だか大袈裟に書いたが、実際のところ「思考の再利用」自体は昔から行われている手法である。勿論思考だけに留まらず、知識全体が対象になる。人間が外部記憶の手段を手に入れた時から、それは延々と続けられてきた。
だが、現代においてそのニュアンスは多少なりとも変化しているように思われる。何故なら、高速に行われるからだ。
旧来の伝達手法は概して低速だった。文字というベースは現代でも同じであるが、媒体が異なればおのずと速度も変わってくる。書籍にしろ新聞にしろ雑誌にしろ、現実に存在する物質を介しているという点で伝達効率は低くなる。また、文字量が増えれば増えるほど、必要になる媒体量は膨大になり、持ち運びその他に支障が出る。検索も面倒だし、間違いの訂正にも時間を要する。
対して電子的な手段は、文字どおり光速で情報がやりとりされる。転送レートもインフラの整備に伴い改善されてきた。保存も、大きさは同じなのに入れておけるデータ量が何十倍、何百倍、何千倍という単位で異なるメディアが次々に生まれ、実用化され、すぐ安価になっていく。ハードディスクを考えてみるといい。それこそ太古の昔は 1MB の代物がノーマルだったのに、今や 100GB、私の旧式ノートパソコンですら 20GB の容量である。紙へ記録するより場所をとらない。
高速性は一種のキーワードになる。その中でも、現在既に問題となっていることがある。他人の思考をそのまま拝借し、それを垂れ流すだけで満足している輩が存在してしまっているからだ。
更に悪いことに、こうした垂れ流しは必ず劣化コピーを生み出すのである。良くなることはまずあり得ない。悪くなるしかない。全く同じものだとしても、それは他人という存在がコピーした、という時点で意味の劣化を起こす。それを補う為に、自分で考えるなり他人の考えを引っ張ってくるなりして情報に味付けを施す。文章がプログラムと異なる点はここにある。プログラムは同等になれるのに対し、文章は未満にしかなれないのだ。
故に、情報を自分なりに噛み砕いて溜めておく必要に迫られる。これは一種のバッファリングだ。ソフトウェア構築のノウハウとしてのバッファリングとは異なり、思考――情報――のバッファリングは鍋の役割を果たす。ぐつぐつと煮込み、より熟成しなければならない。
時間が無い、というのが現代人に共通する認識だという。ということは、必然的に思考バッファリングに要する時間も減っているということになるのではないか?
しかしながら、ある意味でそれは言い訳に過ぎないのかもしれない。人間はある程度のマルチタスク処理が可能である(個人差は激しいが)。それを利用すれば、或は穴埋めを行えるかもしれない。
但し、マルチタスクにも限界がある。当然ながら、既にジョブキューが満杯になっている可能性もある。あまりにも忙しいのなら、そうなのかもしれない。ただ、警鐘を敢えて鳴らすとすれば、次のことが言えるだろう。
忙しくもないのにシングルタスクしか実行していない輩は、いますぐマルチタスク処理をやってみよ。
まだ続く。……ぶっちゃけいつまで続くのか(続けられるのか)予想できなくなってきた。
昨日の続き。
では、何故多対多の会話型ではなく、一対多の雑誌型コミュニケーションが Blog 文化では栄えることになったのか?
そこには、情報というものの在り方が関わっている。
基本的に、会話型の情報は自分が参加する必要に迫られる。レスを付けることが情報そのものの密度を高める唯一の方法だからだ。もしレスが付かない場合は、提供された情報の種が芽吹くことのないままに終わってしまうだけである。故に、この方法は読者の絶対数が少ない個人サイトで採用するには、あまり適切でないことがわかる。それを有効に活用できるのは、ある程度の初発言者とネタに即した人数の投稿者(レスポンス)が集える、大きな広場しかないといえよう。最大の成功例として挙げ易いのが 2ch である。巨大である分 ROM の数も多いのだが、それを補って余りある投稿者が存在できている。
対して、雑誌型の情報は必ずしも参加する必要がない。確かにコメントを付けたりトラックバックを打ったりすれば、Blog 筆者からレスポンスが返ってくるかもしれないが、Blog 筆者はそれを必須であるとは考えていない。「レスポンスが無くとも読んでくれている人が居るだろう」、「自分で記事を書くことにこそ意味がある」、といった(自分なりの)動機さえ存在していれば、自分自身の脳味噌から絞り出した文字で情報を伝達することができる。昔、日記は自己満足云々という論争もあったようだが、今では何であれ提供される情報さえあればそれでよい、という風潮が存在しているように思われる。
雑誌型の情報とは、言い替えればテレビ型、ラジオ型、新聞型でもある。つまり、もっと包含的な言い方をすればマスメディア型なのである。すると、Blog 筆者は一種のジャーナリストであるともいえるようになる。
ここに、日本人が Blog を好ようになった理由の一端を垣間見られる。それどころか、日本に限らず欧米諸国でも Blog がここまで普及した理由を説明することもできる。
つまり、皆テレビに慣れ親しんでいたからだ。
先にも述べたが、ラジオ、新聞、雑誌、書籍といった情報媒体、特に公共性が高く伝搬速度も速い上に、視覚的情報も併せ持ったテレビは、所謂「垂れ流し」の情報を生み出す。うまく用いれば、疑問を持たせることもなく、「ああそうなんだ」と読者を考えさせることなく納得させてしまうといった芸当も可能であり、事実現在のテレビ業界は応用を効かせて我々に「偏った」情報を提供し続けている。
そして、そんなテレビの持つ「一方的な情報」と、ハイパーリンクの可能にする階層無きネットワークによる「多角的な情報」、そしてインターネットの双方向性が可能にした「双方向的な情報」の全てを併せ持ったメディアとして、WWW という土台があり、更に HTML や XHTML といった表現手法があり、CGI があり、組み合わせて簡易な保守管理が可能になった Blog ツールが生まれることになる。そう。土台はあった。技術もあった。ただ、それを容易に用いる術が無かっただけである。今までは。
昨今問題になっているのは、テレビに代表されるマスメディアが意図的にしろそうでないにしろ偏った「一方的な情報」しか提供していないという点である。視点の固定、感情的な表現の多用、自分達の汚い面を見せないようにする情報操作等々、枚挙に暇がない。
無論、メディアの申し子たる Blog も、同じ危険性を全部孕んでいる。特に個人が書いている以上、感情的な側面は確実に増長してしまう。
しかし、Blog には様々な利点がある。そのひとつが、「情報が文字として残り続けること」であろう。テレビは映像と音声で構成される。これらは非常に残しにくい。だが、テキスト情報の交換をベースとする WWW は、一度書いたものが半永久的に保存されていく。
この利点は、比較の容易さを実現する。テキスト比較ツールとして有名な diff
に代表されるように、文字列同士の比較は映像・音声のそれより機械にとっても人間にとっても格段に楽なのである。
情報の比較は自分で考えるということを誘発する。考えなければ比較はできない。また逆に、比較ができなければ考えることができない。
とはいえ、全てを自分の頭で云々するわけでもない。昔は本に書かれていた思想を拝借することが多かった。近年はテレビの情報をただ鵜呑みにすることが多かった。そして、現在。様々な Blog を読者は読み、それらの断片を繋ぎ合わせ、ひとつのまとまった考えを構築することができるようになった。
そう。それは思考の再利用。他人の思考を利用し、自分の思考をも構築する。
更に続く。……結構長引いていて自分でもびっくり。
昨日の続き。
日本人という民族が好きそうな
、と書いたのは、ひとつに Blog、コメント、トラックバックには選択性があると考えたからだ。つまり、~してもよい・~しなくてもよい、という自己決定が容易なのである。
コメントはつけてもつけなくてもよい。つければ読者は自分の意志を伝えられるし、つけなくても読者は Blog を持ってさえいれば好きなことを書くことができる。また、トラックバックを打つことで、読者は自らの Blog において成された自己主張をそのネタ元筆者にすることができる。勿論しなくても問題ない。結果として、パターンとしては実に9種類もの選択肢が提供されることになる。制約の多い世の中において、これはかなりの自由度であると考えられる。
だが、ここで疑問が起こる。では、同じようなコミュニケーションのツールとして、何故個人サイトでは BBS が衰退してきたのか? ツールとして見れば、同じようなものではないのだろうか?
実は、その認識において重要な土台、根源が存在しているのである。
それは、多対多関係と一対多関係の差異である。
多対多関係とは、BBS に代表される、管理人プラス投稿者の集団と、投稿者プラス管理人の集団とがコミュニケートする関係を意味する。スレッド(があるにしろないにしろ)の初発言者(2ch なら >>1)が大元になり、話題の種を提供し、投稿者がそれに基づいて様々なレスをつけるという形式だ。これは、最早掲示板とは名ばかりの、隔時間性チャットとでも呼ぶべきツールが生み出した性質だといえる。いわば、電子的手段で行われる、教室にできた集団で繰り広げられる他愛もない話だ。
対して一対多関係とは、コメント・トラックバックに代表される、Blog 筆者(BBS でいうところの管理人)と、投稿者プラス Blog 筆者の集団とがコミュニケートする関係を意味する。話題の提供という点で Blog 筆者は BBS スレッドの初発言者と同じなのだが、多対多関係と全く異なるのは、ネタ元が常に Blog の筆者であるという点である。いわば、雑誌の記事に対する読者投稿だ。
またまた続く。
というのは冗談で。
昔は所謂掲示板というものを設置してみようと考えていたけれど、はっきり言ってめんどくさいと感じるようになってきたので却下。最近つとに思うのだが、どうやら私はこうやってだらだらと文章を書き連ねている方が性に合っている。掲示板の管理なんてやってられん。そんな暇があったら卒研の勉強かサイトデザインの改良か新しい文章を書くかプログラミングをしている方が余程生産的だ。自分の好きなようにキーボード叩いていられるし。これが重要。
今の時代、草の根レベルの「掲示板」などというものは読者のニーズに即していないのかもしれない。何故なら、もっと便利で直接的な、そして日本人という民族が好むと思われるシステムが存在し、実際に使われているからだ。
そう。Blog、コメント、トラックバックのことだ。
流れとしては、以下のようになるだろう。
続くかも。
moezilla。……マジか。これは……うん。凄い。いろんな意味で。例えば寄稿する作家陣。有名どころ(さとみかんやきたみかんに補足されているところ)勢揃い。デザインの生みの親から同人の玄人、マッシュルームの中の人まで。今までありそうでなかった企画。そしてありえないほど豪華な作家陣。もう無茶苦茶。参加者が総勢20人に及ぶのだというから驚き。つか Øpera-tan の中の人まで居るってどういうことだよ。
今は8月。冬コミは12月。……もしかしたら、生まれて初めての冬コミになる?
今日は Diet Coke Vanilla を飲んでみる。
見た目。ノーマルなものと同じ。以上(昨日と同じだな……)。
次に香り。かなり強いヴァニラの香り。ほのかにコーラ。まさにB級飲料!という感じだったので、味にも期待。
で、飲む。………………。
何なんだこのインパクトの無さは。
はっきり言って、ペプシツイストにすら劣る。ただコーラにヴァニラエッセンス入れてみましたーという安易さ。そしてミスマッチ。駄目すぎる。確かに味は悪くないが、ぶっちゃけコーラとあまり大差ない。期待はずれもいいところだ。インパクトを重視しているわけでもなく、味にパンチがきいているわけでもなく、奇をてらっているものでもない。まさに、B級飲料の恥さらし。もうこれ以上の罵倒表現を与えるのも馬鹿馬鹿しくなる。
かなりゲンナリしてしまった。萎える。
さて、3日間アメリカ土産のB級飲料を特集してみた。ここまでの総論として、個人的な順位は以下の通り。
やはりダントツトップは Mountain Dew CODE RED。色も凄ければ味のバランスも素晴らしい。味のインパクトは弱いものの、それを補う色のインパクトと、すっきりとまとまったさわやかな味わいが高評価。B級飲料好きには是非お薦めしたい逸品。
次点は Dr Pepper Diet Cherry Vanilla。オリジナル Dr Pepper そのものが持つクオリティの高さをどうしても超えることができなかった、ある意味で悲劇の一品。だが非常に難しいオリジナルの改良を行おうとし、劣るとはいえ決して不味くはないものを造り上げた意気込みは評価したい。一回は飲んでみることをお薦めする。
そして最悪だったのが Diet Coke Vanilla。何もかもが中途半端。もう……それだけ。どうしても飲んでみたいという人は、缶の製品を。500ml も飲むのが馬鹿らしくなるので。
最後に。夏の夜に、三日分の楽しみと Blog のネタを提供してくれた友人に、大いなる感謝を。
今日は Dr Pepper Diet Cherry Vanilla を飲んでみる。
見た目。ノーマルなものと同じ。以上。
次に香り。……確かにチェリーとヴァニラの香りが強い。だが、それだけ。どうにもあまり個性的ではない――というより、ノーマルな Dr Pepper の呪縛に囚われすぎている感がある。
で、飲む。……昨日の Mountain Dew CODE RED と比べると、CODE RED がその Mountain Dew らしさを酸味とその後味に残し、フレーバーをかなり大胆にアレンジしているのに対し、Dr Pepper Cherry Vanilla はそもそも Dr Pepper そのものがフレーバーに多種多様なものを使用している(その中には勿論チェリーもヴァニラも入っている。冷たい時はチェリー、生温い時はヴァニラが強い)性質上、どうしてもその中の2つだけを強めただけでは個性的にも何にもならない。はっきり言って、「配合を間違えたフレーバー使いました」という味だった。
総論。ノーマルタイプの Dr Pepper を飲んだ方がバランスがとれていてよい。意図的に崩されたバランスは、全てに影響を与え、よろしくない方向にはたらいてしまっている。
逆に言えば、それだけ元々の Dr Pepper のフレーバーはバランスがとれていて、改良点を見つけるのが非常に難しいのだ。
新しい味わいを提供しようとする心意気は評価できるが、安易な道に走りすぎてはいないかと危惧してみたくなる、Dr Pepper Cherry Vanilla だった。
友人がアメリカへ旅行に行ったので、お土産をあらかじめリクエストしておいた。
そして、本人が届けにきた。
本場アメリカのB級飲料キター! 以下そのリスト。
凄い! 凄いぜ! 友人グッジョブ! 何てったって全部日本じゃなかなか飲めなさそうなものばかりなんだから!
一番身震いしたのは……やっぱ Vanilla Coke でしょうが! 日本でも売られていたが、私は飲み損ねたのだ。曰く、「人間の飲み物じゃない」そうだが……そんなことは関係ない。私はドクターペッパーの芸術的な香りを理解し、コアップガラナの上品な味わいに舌鼓を打ち、そしてキンキンに冷えたルートビアの、パンチの効いたフレーバーを一気に喉奥へと流し込む快感を知っている。だから、きっと Vanilla Coke も素晴らしい体験をもたらしてくれるに違いないのだ!
……でも、まだ飲んでない。だって、勿体無いんだもの。
というわけで、今日は中でも一際目立った色をしている Mountain Dew CODE RED を味わってみた。一日一本。これ基本。
まず、見た目が凄い。日本では絶対に売り出せないような、真紅。これぞアメリカクオリティ。
香りは……どうやらチェリー。よく見ればラベルに with a rush of cherry flavor とある。最近のアメリカはチェリーブームなのか(上リストの Dr Pepper を見よ!)。
一口飲む。素晴らしい。明らかに薬とわかる香り。パンチの効き具合も申し分ない。いい味だ。そのまま一気に飲み干せる心地よさと、私の腐れた脳味噌をリフレッシュさせてくれる清々しさ。合格点。
勿論、後味も重要。あの Mountain Dew 特有の酸っぱさも健在。どこまでも Mountain Dew。
結論。……もっと飲みたい。以上。