最近まで使っていた VAIO SR だが、とうとう最初から最後まで、 一度も内蔵モデムを使わなかった。 モジュラージャックが付いているのは知っていたが、 一度も使っていない。 今度使っている VAIO Z はどうだろう。 まさかとは思うのだが、 モジュラージャックというのは何に使うのだ、 という人が、今なら存在するのかもしれない。 パソコン通信が流行していた10年前には、 パソコンを電話回線に接続して… という使い方が当たり前だったのだが、 もはや、インターネットに常時接続という時代で、 LANケーブルで接続したことしかない、という人も多いのか。

※ VAIO SR: SONYのノートpc。 小型軽量なのに画面が1024x768あって、かなり重宝した。

もちろん、 パソコン通信がなくなったとしても、 コミュニティそのものが消滅するわけではない。 自分でBBSサーバーを立ち上げてその中に世界を構築することは、 技術的には簡単だ。 草の根BBSという世界は、名前と形を変えて今も健在なのである。 では、フォーラムは?

昔はフォーラムという仮想空間は、 それ以外に選択肢のないような特殊な場所だったし、 それ故、フォーラムの運営には、公平性が要求された。 偏った行為は批判の対象になったのである。 「文句があるなら自分でやれば?」とか言える状況ではなかったのだ。 ところが、今となっては「自分でやれば?」なんて言ったら最後、 「あっそうか、自分でやればいいんだ」という状況になってしまったのである。 ある程度の規模の掲示板やチャット程度なら、 やりたい人が勝手に作ることが可能なのである。 そうなると、コミュニティに求められるのは、新たな存在価値である。 利用者が感じるはずの、 「なぜそこに行かなければならないのか」 という疑問への回答が必要になるのだ。

実は、これは割と簡単な話に集約できると思う。 要するに、面白ければいいのだ。 「行くと面白いから行く」というのは、実際、 極めて多くの状況下で成立している普遍的な原理なのである。

現在のように、インターネットに各種のコミュニティが存在し、 誰でも自由に参加できるようになれば、 利用者の選択理由はコミュニティを管理する側にとっても気になるところだ。 参加してみて面白い、というのは結構重要なことで、 特に理由がない限り、面白くない所にわざわざ参加する人はいない。

そこで問題は、どういう場を作れば面白いのか、ということになる。 これが割と難問なのである。 「面白い」に対する個人差が大きすぎるからだ。 もちろん、面白いといっても、笑えるとか、癒されるとか、 そういった感情的な話だけではなく、 例えば役に立つとか、情報がgetできるとか、 金儲けになるとか、勉強になったとか、 そういった系統の刺激も重要になってくる。

そして、この種の具体的な条件に対して、 これとこれを実現したらいいだろうと選択できたとしても、 次のステップとして、 そのような具体的なニーズに応えられるような仮想空間を作るには、 一体ナニをどうすればよいのか。 その答えがまた難しいのだ。

§

プログラマーズフォーラムの話。 最近いまいちな感じなのだが、 とりあえず、自分が使ってみてもっと面白いようにできるのでは、 という方向で模索している。 プログラマーズフォーラム的「面白い」の一つの回答としては、 面白い人がいるかいないか、である。 そういう意味では、コンテンツはやはり重要。 ただ、作る側の発想としては、 どういうコンテンツを揃えるか、で終わってしまいがちだと思うのだが、 どんなにモノを集めても、 実際「つまらん」と観客に思われてしまったら、 折角の努力は意味のないものになってしまう。

※ プログラマーズフォーラム: その昔 NIFTY=Serve で始まったという伝説のコミュニティ。 「いまいち」というのは、参加者が減ったことを言っている。

いずれにしても、自分が使って面白くないのでは全然話にならないと思うのだ。 そこで、何か「発言するのがもっと面白くなる」みたいなツールはないかと思って、 なければ自分で作ってしまえ、ということで、作っていたりする。 その一つがHTTPベースのオートパイロット処理をするためのソフト。 これを、 特定のサイトに対応するだけではなく、 汎用的に対応できるように作ろうとして、かなりハマった。 これがまた話を始めると訳が分からなくなるほど面白いのだが、 とりあえずまたの機会ということにして。

Webページを既にgetしたかどうかの判断処理が、 どうも予想外に負荷が高い。 実は理由は割と単純で、最初から予想していた。 オートパイロットの処理は Java で書いてあって、 今までにgetしたページのリストを、XML で処理している。 単に URL に対してアクセスしたかどうかを知るだけでも、 XML から Document を作成し。 Element を最初から確認して、 今までにアクセスしたかどうかを確認するような処理になっていて、 いかにも重そうだ。 もっとも、 この処理は最終的には別に立てたDBをアクセスするように修正する予定だから、 とりあえず動作確認という程度のつもりなのだが。

---- List 1 (要素のサーチ、NodeList 版) ----

    NodeList nodes = documentElement.getElementsByTagName(TAGNAME);
    if (nodes == null || nodes.getLength() == 0)
        return null;

    for (int n = 0; n < nodes.getLength(); n++) {
        Element element = (Element) nodes.item(n);
        if (isMatch(element, key, title))
            return element;
    }

    return null;

---- List 1 end ----

Document とか Element というのは Java の DOM に出てくる話なので、 興味のある方は、それに関するドキュメントを見ておいてほしい。

最近、 Javaのプログラムに殆どコメントを書かなくなった。 List 1 を見てもらうと分かると思うのだが、 殆どコメントを書く余地がないのだ。 多分、isMatch というメソッドがこの処理に埋め込まれていたら、 そこに「マッチしたら云々」というコメントでも書くのかもしれない。 リファクタリングの技法として、 コメントを書かないと分からないような箇所は、 その処理を別にくくりだして、 処理の内容を意味するような名前を付ける、 というものがある。 それを意識してコードを書くと、 結局、コメントを書くような箇所がなくなってしまうのだ。

で、この処理のどこがヤバいか。 必ず最初からサーチするという所にある。 実は、アクセスしたページの情報は XML の最後に追加していたのだ。

---- List 2 (最後に情報を追加する) ----

    documentElement.appendChild(newElement);
    documentElement.appendChild(createTextNode("\n\n"));

---- List 2 end ----

List 2 で、"\n\n" という TextNode を追加しているのは、 生成された XML のファイルを人間が見た時に、 改行が入っていないとびっくりするからなのだが、 プログラム的にはそういう無駄なものは入れない方がいいのかもしれない。 それはさておき、 最後にアクセスしたサイトの情報をこのように最後に追加すると、 後でそれをチェックしたい場合に、 その前に追加されていた殆ど全ての Element をチェックしてから、 最後にマッチしてヒットするという動作になってしまう。

実は、同じサイトを何度もアクセスすると、 そのような状況になる可能性が極めて高いのだ。 例えば、トップページから、話題1のページ、話題2のページ、話題3のページ、の3つにリンクされているとする。 このページの管理者は、 話題1の内容が古くなると、 そのリンクを外して、新しい話題4のページへのリンクを追加したくなるだろう。 その結果トップページは、話題2のページ、話題3のページ、話題4のページの3つにリンクした状態になる。 オートパイロットはこのページを見て、 話題2のページ、話題3のページ、話題4のページをチェックしようとするのだが、 この時、話題2のページと話題3のページは既にgetしているということが、 最後の最後でヒットして判断できるという状況になってしまうのだ。

ここで、 今のような状況が現実的にあることから、 経験的に想定してよい条件が2つある。 まず、最近getしたページに対するチェックが発生する確率が高い。 そして、かなり前にgetしたページに対しては、 チェックが発生しなくなる可能性もあるということだ。 先ほどの話だと、話題1のページがそれである。 トップからリンクされなくなった時点で、チェックの必要がなくなるからだ。

そこで、ちょっと考えてみた。 最後にアクセスしたページの情報が先頭にあればいいのではないか。 つまり、XML の最後ではなくて最初に追加するようにする(List 3)。