TidBITS: Apple News for the Rest of Us  TidBITS-J#584/18-Jun-01

WebObjects とはいったいなんだ?どこから来たんだ?WebObjects が何で、 どこから来て、Web アプリケーションを作成する他の方法と比較してどう かをまさに説明する Jonathan Rentzsch 氏の 2 部構成の記事の最初の部 を読んでみよう。また、今週は、Adam がインターネット上の「過酷な市 場独占」に関するレポートについて苦言を呈し、IPNetSentry 1.1.1、 Rewind 1.2、BBEdit Lite 6.1.1、icWord 1.2 のリリースを掲載する。

目次;

Copyright 2001 TidBITS Electronic Publishing. All rights reserved.
問い合わせは <info@tidbits.com> へ、感想は <editors@tidbits.com> へ。

TidBITS 日本語版は TidBITS 日本語版翻訳チーム メン バーのボランティアによって翻訳・発行されています。TidBITS 日本語版 では翻訳に協力してくれる方を募集しています。詳しくは以下の URL を 参照してください。

<http://jp.tidbits.com/join_us.html>


今回の TidBITS のスポンサーは:


MailBITS/18-Jun-01

(翻訳:篠原 慎一 <sshino@mbd.sphere.ne.jp>)
(  :今井 律子 <poorsun@mb.neweb.ne.jp>)

Rewind が 1.2 に進化 -- Power On Software 社は Rewind をアップデー トした。この 100 ドルのユーティリティは、クラッシュやミスの場合に、 ファイルやシステムを以前の状態に戻すものだ( TidBITS-564  「Macworld SF 2001 のトレンド:優れものユーティリティ」を参照)。 Rewind 1.2 には Rewind アーカイブの容量に上限を設ける機能が加わり (変更状況のカタログは Mac を使用している時に、ファイルに作られる)。 多くの修正の中でも、今回は特に、通常とは異なったメモリ操作を行うよ うなプログラムとの安定性を改善し、Virtual PC 4 のディスクイメージ を正しく扱えるようになった。アップグレードは無料だが、Rewind 1.2 のマニュアル付きフルバージョン(7 MB のファイル)をダウンロードす るためにはシリアル番号を入力しなくてはならない。Rewind は Mac OS バージョン 8.1 〜 9.1 上で動作し、ハードディスクの最低 10 % の領域 を必要とする。[JLC]

<http://www.poweronsoftware.com/products/rewind/>
<http://db.tidbits.com/getbits.acgi?tbart=06280>

icWord 1.2 が 2 バイト言語をサポート -- Microsoft Word 文書の表 示・印刷ユーティリティである Panergy 社の icWord 1.2 アップデート は、Microsoft Word のアジア(中国語、日本語、韓国語、その他の 2 バ イト言語を含む)バージョンで作成されたファイルを読み込むことが可能 になった。その他に、サウンドのサポート、脚注を巻末の注記として表示 する機能、Unicode テキストファイルのサポートといった機能を含んでい る。同社はさらに、Word の 組み込みグラフィック、テーブル表示、段落 スペースのサポートを改善した。このアップデートは無料で、ダウンロー ドサイズは 2.0 MB。[ACE]

<http://www.icword.com/>
<http://db.tidbits.com/getbits.acgi?tbart=06074>

IPNetSentry 1.1.1 で侵入者を追跡 Sustainable Softworks 社は IPNetSentry 1.1.1 をリリースした。同社のパーソナルファイアウォール ソフトのマイナーアップデート版である( TidBITS-564 「Macworld SF 2001のトレンド:パーソナルファイアウォール」を参照のこと)。このバー ジョンでは、最近の 32K 分のログを表示する内部の Log ウインドウと、 IPNetSentry Companion アプリケーションの起動時に Command を押し続 けることで起動画面を回避する機能が追加されている。更に重要なことは、 IPNetSentry が侵入者を発見すると、ユーザーに、侵入者の IP アドレス のルート追跡を行えるようにしたことだ。それで攻撃の発信元を特定しや すくなる。実際のルート追跡は、Sustainable Softworks 社の別製品であ る IPNetMonitor によって行われる。IPNetSentry へのアップデートは無 料だが IPNetMonitor の方は 30 ドルかかり、割引価格で色々なバンドル 製品が付いてくる。IPNetSentry 1.1.1 は 1.2 MB のダウンロードサイズ で、PowerPC ベースの Mac 上で動作する Mac OS 7.6.1 と Open Transport 1.1 か、それ以降のバージョンが必要だ。

<http://www.sustworks.com/site/prod_ipns_overview.html>
<http://www.sustworks.com/site/prod_ipmonitor.html>
<http://www.sustworks.com/site/bundles.htm>
<http://db.tidbits.com/getbits.acgi?tbart=06281>

BBEdit Lite 6.1.1 でバグを修正 -- Bare Bones Software 社が BBEdit Lite 6.1.1 をリリースした。同社のフリーテキストエディタのバ グを修正したアップデートである。BBEdit Lite 6.1.1 では今回、 Default Font 設定の変更を記憶し、multi-file 検索の検索オプションも 設定通り使えるようになった。Mac OS 8.1 かそれ以前のバージョン下で ダイナミックスクロールを提供し、Mac OS X のクリップボードパフォー マンスも改善した。また Hard Wrap コマンドに関連するクラッシュのバ グを修正している。BBEdit Lite 6.1.1 は 4.3 MB のダウンロードサイズ で、PowerPC ベースの Mac を必要とする。

<http://www.barebones.com/products/bbedit_lite.html>
<http://db.tidbits.com/getbits.acgi?tbart=06448>


インターネットは私たちのもの

by Adam C. Engst <ace@tidbits.com>
(翻訳:蒲生 竜哉 <gamo@lib.bekkoame.ne.jp>)
(  :斎藤 美礼 <mirei@x.age.ne.jp>)

2001 年 3 月の時点で全米インターネットユーザー(ホームユーザーと企 業ユーザーの両方を含む)のインターネット利用時間総合計の 50 % 以上 がわずか 4 社によって独占されているという刺激的な内容が最近の Jupiter Media Metrix 社のレポートで報告されている。ちなみに 2 年前、 1999 年 3 月の時点では同じ 50 % のインターネット利用時間に 11 社が ひしめいていた。さらに刺激的なことに 1999 年 3 月の時点で 60 % の インターネット利用時間を占めていたのは 110 社であるのに対し 2001 年 3 月ではわずかに 14 社となってしまっている。

<http://www.jup.com/company/pressrelease.jsp?doc=pr010604>

これら上位の具体的な名称を挙げると AOL Time Warner 社(32 %)、 Microsoft 社(7.5 %)、Yahoo 社(7.2 %)それにNapster 社(3.6 %) の 4 社となる。ところでこうした巨大企業とは関係ない者として言うの だが、このレポートは盲目的な仮定によって誤った結論に達していると思 う。このレポートの結論はインターネットの市場独占は可能だというもの なのだが、私は最終的にはこれとはまったく逆の理解を得るに至った。

仮定その 1:すべてのインターネット利用時間は同じである -- Jupiter Media Metrix 社はこのレポートのサマリーで調査方法を公開し ていない。しかし脚注の一つにこの調査の範囲(必ずしもこうした数字を 比較する必要はないが)に関するヒントがあった。AOL Time Warner 社の パーセンテージは問題外に大きいように見えるが、これは合計の 2/3 が メールとインスタントメッセージの専用コミュニケーションサービスによっ て占められているところが大きい。こうしたサービスを除いても AOL Time Warner 社がトップであることに変わりはないが、その利用率は 10.7 % に落ちる。他の各社(ただし無料専用メールサービスを持ってい る第 2 グループの Juno 社を除く)についてはこうしたコミュニケーショ ンサービス使用時間を「インターネット利用時間」の計算に含める操作は 行われていない。標準的なインターネットメールの利用時間や非専用イン スタントメッセージの利用時間がインターネット利用時間に含まれている かどうかは不明だ。私などは他のインターネットアプリケーションのどれ よりも長い時間を Eudora を使うことに費やしているのだが。

実際、いったん「インターネット利用時間」って何なんだろうと考え始め るとなぜこの調査に Napster が含まれているのか不思議に思うに違いな い。巨大な MP3 ファイルとインターネットコミュニティに属する多くの 人が未だにモデムを使っているという事実を組み合わせた時、こうした遅 いダウンロードが莫大な量のインターネット利用時間を Napster にもた らすであろうことは容易に理解できる。AOL が専用ソフトウェアを使って 広告を流していることや、このソフトがインターネット利用中のすべての 使用感に影響があることを考えれば AOL Time Warner 社のコミュニケー ションサービスがインターネット利用時間に含まれていることはまだ理解 できる。ところが Napster はほとんどの場合バックグラウンドで利用さ れている。ダウンロードが終わるまでは見えなくなっているかあるいは無 視されているのだ。

仮定その 2:ユーザーは自動インターネット利用時間生成機械だ -- TidBITS は主に Macintosh のインターネットコミュニティを構成する個 人ユーザーに対して情報を送ったり、あるいはそうした人々から情報をも らったりすることを手助けするために存在する。こうした活動は私たちの 記事を読んだりそれに返信したりすることに自身の時間を費やすことを選 択してくれた学識があって楽しい私たちの読者と相互に影響し合うことを 常に伴う。これはいつまでも続くギブアンドテイクだ。もし数百万の読者 を抱えていたとしたらこの刊行手段を変えなければならないことは間違い がない。しかしそれでも私はいまだに「インターネット利用時間をコント ロールする」とか「ユーザーを形作る」とかといった言葉を見ると怖じ気 づいてしまうのだ。

このレポートにはユーザーというものが何をするかということに対する選 択はない、そして彼らはこうした 4 大企業のサービスを利用することを 無理強いされているという含蓄が含まれているように思える。私は Yahoo を普通に使っている。しかしそれは私が Yahoo のサービスとデザインが 好きなためで、Yahoo が何らかの手段によって私をそこに閉じこめている からではない。実のところ私のインターネットユーザーに対する印象は信 じがたいほど移り気というものだ。インターネット利用時間上位 4 社の どれかがランキングから叩き落とされるのにも大して時間はかからないだ ろう。実際、レコード業界との法廷バトルの第 1 ラウンドの敗北や以前 はそのサービスから入手可能だった人気マテリアルの量の(そして使用感 も)減少から Napster は今まさにこうした墜落の危機に立たされている。 しかも他社サービスは Napster が取り残した数々の機能を急速に取り込 みつつあるのだ。

<http://db.tidbits.com/getbits.acgi?tbart=06346>

インターネットメディアビジネスに身を置く人全員に対し、オンラインユー ザーの忠誠心を得、そしてそれを維持しようとしている今の状況を考え直 して欲しいと私は思っている。確かに AOL が専用インターフェースを使っ たり、Microsoft が MSN を Windows で推進している様に一つの会社のサー ビスにユーザーを引き留める方法はあるだろう。しかし最終的には高品質 のサービスによって真の価値をユーザーに提供するしかないのだ。

仮定その 3:インターネットの残り部分は楽しくない -- では残り 40 % のインターネット利用時間、上位 14 社に独占されていない部分はどう なのだろう。Jupiter Media Metrix 社はこれについてはレポートの中で 触れてさえいない。しかし、もしも誰かに「記憶に残るオンラインセッショ ンはどのようなものでしたか?」とたずねたらほぼ間違いなくその答えは 個人的なメールのどれかかあるいはあまり一般的ではない Web ページや サービスであり、決して日々の天気予報などを報じている有名ポータルで はないと私は確信している。インターネットを他のマスメディアから分か つ大きな違いはその途轍もない深遠さだ。これに比べればテレビ、ラジオ や映画、あるいは書籍やソフトウェア、雑誌ですら遙かに浅薄だ。こうし た他の分野にはインターネットに比較すればわずかな数の制作者しかいな いし、何かを制作するための敷居はいまだ高い。こうした状況だと理屈上、 制作物は高品質となるはずだ。しかし私たちが今まで見てきた通り、実の ところこれは一般受けするものを人々に強いているに過ぎない。

別に個人制作物が良いと言っているのではないし、実際多くの場合あまり 良くはない。Sturgeon の法則は「90 % のサイエンスフィクションはゴミ である。なぜならすべてのものの 90 % はゴミだからだ」と言っている。 もし 90 % のテレビ番組がゴミであるなら(ところでこれはだいぶん楽観 的な見積もりだ)、残りの 10 % とはずいぶんと少ないものになるはずだ。 しかしこれと同じ理屈をインターネットに適用した場合は違う。例え今存 在する Web サイトやサービスのうちわずか 10 % だけが良いものだとし てもその数は膨大だ。あなたはゴミの山の中にも数多くの価値ある Web サイトやサービスを見つけることができるはずだ。

これは大きな違いだし、お定まりの「量対質」の議論に対して面白い展開 をもたらす。不可能なほど敷居の高い他メディアでは多々見られる質の低 下がインターネットではみられない。サイトの量がその質をおおむね保証 するのだ。

仮定その 4: 情報の単一化が望ましい -- Jupiter Media Metrix 社の レポートから学ぶ教訓はあるだろうか。ありはするが、レポートの筆者が 予想したのとは違った教訓だ。彼らがレポートを書いている目的は、奇妙 な言い方で述べているように、「チャンネル」の数は無限にあるにもかか わらず、インターネットにおける深刻な市場の支配が実際にあり得るとい う証拠とするためだ。それは本当だが、特に興味深いわけではない。とい うのも、インターネットで使用頻度の高いサービスの大半はほとんど変化 がなく何度も複製されているという単純な理由があるからだ。ヘッドライ ンニュース、株価情報、電話番号検索、地図サービス、Web ベースのメー ル、検索エンジン、価格比較サービスなど、名前を挙げたものは今の時点 で多くのいろいろな企業によって行われている。だから、Yahoo、MSN、 AOL、Netscape を見ると、皆ほとんど同じ内容と機能を提供しており、あ る人がどれを使っているかは、個人的な好みか、なんらかの外的要因のた めであることが多い。似たようなサービスを提供しているほかの企業が低 迷したり買収されたりしてもあまり発表されないし、率直に言ってあまり 話題にもされない。

多様性はインターネットのもっとも重要な面であり、大企業からのコンテ ンツやサービスの種類という問題は、換金作物の単一化の情報版といった ところである。生物における単一化は、高い生産性の代償として、壊滅を もたらすような病気や環境による被害を受けやすくなる。そして、私が議 論したいのは、データ、情報、知識、思想の世界でも、同様な代償を払う ことになるだろう、ということだ。よく引用される生物学の類似に、現代 のコンピュータのウイルスがある。Microsoft 社の Windows と Microsoft のメールクライアント Outlook の単一化に近い状態の中で、 ウイルスは力強く成長している。もうひとつの類似はミームという概念だ。 自己複製する伝染性の思考のことで、これもまたよく受け入れられている。

<http://www.memecentral.com/>

この類似を一般的な情報と思想にあてはめると、インターネット、もっと 具体的にいえば、企業の単一化によって生成されていないインターネット の部分は、明らかに我々の知的な進化の必須の部分である、と私は考えて いる。なぜそう考えるのか疑問に思われるだろう。進化には働きかけるた めの素材が必要だからだ。だから、有性生殖が進化の上であんなに成功を 収めたのだ。莫大な数の DNA の可能な組み合わせによって、絶えまない 変化と実験が起こったのだ。インターネットによってアクセス可能となっ た情報は新しい概念の DNA として見なすことができる。これがなければ 我々は前進できないし、種としての自分自身に重大な損害を与えさえする かもしれないのだ。だから、人類の知の未来のために役目を果たし、イン ターネットのあまり人の来ないノードにも思いきって出かけてほしい!


WebObjects 物語、パート 1

by Jonathan "Wolf" Rentzsch <tidbits@redshed.net>
(翻訳:吉田 節 <benjamin.takashi@nifty.ne.jp>)
(  :斎藤 美礼 <mirei@x.age.ne.jp>)
(  :三好 泰子 <yokomo@mio.to>)
(  :飯橋 真紀 <k-m611@ma4.seikyou.ne.jp>)
(  :山下 英治 <vatcanza@fhe.freeserve.ne.jp>)

AppleScript はその昔、最も守られた Apple 社の秘密だった。それは他 のプラットフォームが未だに並ぶことのできない技術分野を切り開いたの である。しかし AppleScript は一握りの熱狂的ファンに注目されただけ だった。過去数年で状況は改善され、Steve Jobs 氏が基調講演でこの技 術を取り上げるまでになった(Mac OS X の広範囲な AppleScript サポー トは、まだはっきりしない感じがあるが)。そんなこんなで最近は AppleScript を知る人が増えたが、今や Apple 社には新しい最も守られ た秘密、WebObjects がある。

NeXT 社が衰退しつつあった頃、WebObjects は同社の頼みの綱だった。安 価ではなく、無制限接続を許すライセンスが 50,000 ドルもした。だがそ んな値段にもかかわらず、WebObjects は同種の製品に対して価格競争力 があった。

昨年の World Wide Developer Conference(WWDC)で Jobs 氏は爆弾を落 とした。ライセンスの種類を問わず 700 ドルという WebObjects の新価 格である。WebObjects は宣伝の多い iTools や iDVD のような人目を引 く消費者向け製品ではないが、値下げで人々の興味をひいた。さらに今年 の WWDC で Apple 社は WebObjects 5 をリリースした。これはすべて Java で書かれており、特に Mac OS X や Mac OS X Server を利用する人 にとって興味深いと思われる。

<http://www.apple.com/webobjects/>
<http://db.tidbits.com/getbits.acgi?tbart=05950>
<http://db.tidbits.com/getbits.acgi?tbart=06440>

ところで WebObjects について話す前に、WebObjects と同種のソフトウェ ア、つまりアプリケーションサーバについて理解を深めておくのがよいだ ろう。今回の記事ではアプリケーションサーバの歴史について簡単に触れ ると共に、WebObjects と競合製品が用いている種々のソフトウェアアー キテクチャを概観する。次回は WebObjects の 3 つの主要なツールと欠 点に話題を絞る予定である。

アプリケーションサーバ -- WebObjects は最初のアプリケーションサー バだった。アプリケーションの開発と配備のための環境であり、Web ブラ ウザでアクセスできた。

多くの点で、アプリケーションサーバはメインフレームの日々へと先祖返 りするものだ。あのころは、1 台の大型コンピュータがすべてをこなし、 複数の高額でないターミナルがメインフレームに接続されていた。ターミ ナルはきわめてライト級のコンピュータで、できることといえば、受け取っ たテキストを表示し、キー操作をメインフレームに送り返すことぐらいだっ た。

パーソナルコンピュータの革命によって、ユーザーひとりひとりが自分の ソフトウェアを実行できるようになり、企業情報システムを司る司祭の専 制から解放されたのだった。しかし、改革の途中で興味深いことが起こっ た。人々は自分たちの情報とプログラムを共有したがったのだ。

個人向けで集中管理を行うファイル共有によって、仲間の間で情報を共有 することができたが、ソフトウェアの共有が問題だった。あるプラット フォームのために開発されたプログラムが別のプラットフォームでは動作 しなかった。コンピュータ一台一台のために、ソフトウェアを購入し、イ ンストールし、メンテナンスしなければならず、費用も複雑さも劇的に増 加した。プログラムがデータを処理するためにいろいろなタイプに合わせ て専門化する必要もあった。たとえば、ある種の共有される情報、たとえ ば顧客データベースなどは、妥当性を保証できるプログラムを通じてのみ アクセスできなければならない。

その後 Web が出現した。メッセージは HTML でそれを送る媒体は HTTP だった。どんなコンピュータもほかのどのコンピュータからでも文書を引 き出すことができ、プラットフォームの問題が軽減された。もっとすごい のは、HTML の基本的なデータ入力のサポートを利用してアクセスできる プログラムを Web のおかげで作成できるようになったことだった。

すぐに、グラフィック部の Mac や経理部の PC が、人事部の Unix マシ ンが提供する同じ休暇届にアクセスできるようになった。さらに、プラッ トフォーム間で通信できるということは、ソフトウェアのインストールと メンテナンスを企業の中央サーバ上で行うことができるということを意味 する。バグが修正されたり、機能が追加されたりしたとき、サーバさえアッ プデートすればよかった。クライアントはすべて、次に使用するときには 即座に、そして自動的に、アップグレードを利用することになった。

「シン・クライアント」という、ブラウザや Java インタプリタのような 軽いソフトウェアを走らせる安価なコンピュータが注目の的になった。以 前のメインフレームシステムのように中央管理が可能なのに、ネットワー ク上のたくさんのコンピュータそれぞれの要求に応じるためにリソースを 費やしたりするだろうか。しかし、クライアントから負荷を取り除くこと は、サーバに負荷をかけなければならないということだ。サーバは、ユー ザーのデータだけでなく、プログラムロジックもすべて保持した。会社中 (や世界中!)の複数のユーザーが同時に昼夜をおかずにサーバに向かっ ていく。

プログラマーはソフトウェアの厳しい開発スケジュール、驚くほどの複雑 さ、そしてほとんどダウンしないサーバへの要求に直面した。NeXT はこ のような問題すべてに対処するツールやサービスを作り出して販売すると いう独特の位置にあった。

NeXT は利用できる最上の開発ツールをいくつか持っていることで当初か ら知られていた。コアがオブジェクト指向化されていたので、こういった ツールによって複雑なアプリケーションをすばやく開発することができた。 NeXT のソフトウェアは、Unix と Windows NT という、業界で競争力があ り、ミッションクリティカルなサーバに必要とされる動作可能時間への要 求を満たすことができるオペレーティングシステムでも動作した。NeXT は WebObjects を作り出すためにこのことをすべて活用した。

3 つの基本事項 -- アプリケーションサーバは、3 つの部分から成り立っ ている。それは、インターフェース、プログラムのロジック、そしてデー タアクセスである。

<http://db.tidbits.com/getbits.acgi?tbser=1197>

WebObjects は、もはやアプリケーションサーバの市場で唯一の存在では ない。今では多くの競合がいる。そして、上記の 3 つの基本をいかに分 離させるかという点で、それらは根本的に異なっている。さまざまなモデ ルを研究することは教育的な意義がある。はっきりとした設計の進化を見 ることができるからである。私がもっとも印象的に思ったことは、これら すべてのモデルは、ゆっくりとある共通の設計に向かっているということ だ。つまり、WebObjects と同じ設計へと向かっているのである。

アプリケーションサーバのいささか不自然な進化に沿って話を進めていこ う。それぞれに対して、その背景を並べて、そこから出てきたさまざまな パッケージのいくつかについてお話ししていく。フリーソフトのものもあ り、オープンソースのものもある。そして、 プロセッサ ごとに何万ド ルもするものもある。これらのリストは、大まかで概略的すぎるものだ。 そして、すぐに時代遅れになってしまうだろう。しかし、この世界が向かっ ている方向をあなたに教えてくれるはずだ。

石器時代:ロジック優先ですべてが連結されている -- 石器時代のデザ インはダイナミックページ生成のロジックに焦点を当てていることに代表 される。ほとんどすべてのプログラミング言語は、Web クエリを受けつけ その結果に基づいた HTML 形式文書を作成することができる。(一般的に 使われる言語には、C、Perl、AppleScript、Java がある)。

こういった Web アプリケーションは普通受け付けたクエリに答えるため にデータソースにアクセスする。情報を探すのに手動でファイルの中を調 べるものもあるだろうし、クライアントのクエリに基づいた SQL のクエ リを生成してデータベースに検索をかけるものもある。もし Web アプリ ケーションが計算中心であればデータソースにアクセスする必要はないか もしれない。

石器時代ラベルのついたロジック優先のデザインを非難するつもりはない。 それよりも、私はただその世代(最初のデザインだった)と複雑さ(相当 なものではまったくない)を指摘しようとしているのだ。石器時代のデザ インはライト級で、そしてあらゆるライトなものには利点がある。プログ ラマーにとっては当然のことだが、すべてが一所にあるためすぐに容易に ダイナミックページを立ち上げられるのだ。計算を多く使うアプリケーショ ンにとっては石器時代のデザインは最適なのかもしれない。

しかしながら、石器時代のデザインに欠点がない訳ではない。第一の問題 点は、データアクセス情報がロジックに埋め込まれていることだ。この埋 め込み型データベース依存性を扱いやすくするために次のような技術が導 入された。Windows の C と C++ プログラマー(そして Mac のわずかな プログラマー)には Microsoft 社の Open Database Connectivity(ODB C)、Java プログラマーには Java Database Connectivity(JDBC)、 Perl プログラマーには Database Interface(DBI)がある。

こういった技術がただデータベースを探して 接続 する手段を与えてく れるだけだということを認識しておくことが重要だ。データベースからの データの出し入れに関しては、あなたは依然として SQL を書いてそれを プログラムロジックに埋め込まなければならない。SQL は特定のテーブル やカラム名を参照するので、埋め込まれたクエリ側とデータベース側のそ れらの名前を一致させておくのはあなたの責任なのだ。

他の問題点は、ロジックとインターフェースとデータをひとまとめにした デザインが基本的に一ページと一塊のコードとを結びつけることだ。もし 多数のページでロジックを共有する必要がある場合、コード共有の戦略を 成功させて最新のものに維持しておくのはあなた次第だ。   

石器時代のデザインの最後の問題点は、インターフェースがアプリケーショ ンのロジック内に埋め込まれていることだ。それは、プログラマーだけが どんなページにするかあるいは情報をどのように配列するかを変更できる ということを意味する。

石器時代のツールの例として、AppleScript、C/C++、Java、JavaScript、 Perl、Python、Windows 環境下のみの Visual Basic が挙げられる。これ らのツールがすべてプログラミング言語であることからそれらがロジック に焦点を当てていることがわかる。それらは論理的判断や演算を表現する には優れている。しかし、データアクセスやインターフェース生成を処理 することが強いられた場合に欠点がでてくる。これ以降のモデルでは、 Web アプリケーションのロジック部分を処理するためにプログラミング言 語の幾つかを使っている。

青銅器時代:インターフェース優先ですべてが連結している -- 数百の ダイナミックページを量産した後、気がつくとプログラマーたちは面白い 状況におかれていた。多くの場合、ダイナミックページはロジックとデー タアクセスの付け焼き刃であり、HTML の中にインターフェースの巨大な 塊を含んでいた。その上、ビジネス界の人々やグラフィックアーティスト は、外観の変更要求をしてはプログラマーをいつも悩ませてばかりいた。

プログラマーはぐうたらだが賢い人たちで、石器時代のデザインの関係を 単純に裏返しにした。ロジックの中にインターフェースを埋め込む代わり に、インターフェースの中にロジックを埋め込んだのだ。今度は HTML が 優位を占めて構成されたページができ、ロジックの塊を含んだ特注のタグ がついた。プログラマーはほっと安心して、優秀な Web デザイナー(生 で原文の HTML レベルで作業するような人たち)にファイルを渡すことが でき、ロジックの塊には触れないよう指示し、Web デザイナーたちはプロ グラマーを経由せずにページの外観を変更できた。

ロジックの塊を識別する(またそれを隠した)WYSIWYG 形式の HTML エディ ターを作るようなことまでするプログラマーもいたりして、このようにプ ロの Web デザイナーでなくてもページの外観を変更できるようになった

石器時代のデザインと同じく青銅器時代のデザインには取り掛かりやすく すべてが一所にあるという利点があった。青銅器時代のデザインでは石器 時代の最後の問題点はいくらか軽減したのだが、最初の 2 点については 検討されなかった。すなわちデータアクセスはやはり埋め込まれたままで (ページのインターフェースかロジックいずれかの内部に)、ページ間で のコード共有は問題のままである。

青銅器時代のツールには Active Server Pages(ASP)や Java Server Pages (JSP)、Lasso、PHP がある。これらのツールはすべて HTML の中 にプログラムロジックを埋め込んでいる。ASP は例によって Visual Basic を使い、JSP は Java を、そして Lasso には独自のタグベースの 言語があり、PHP も同様に特有の言語を使用している。

軽快なフットワークでこれらすべてのソリューションは産業化の時代のモ デルへと移せるのだが、当初はそのように設計された訳ではなかった。 JSP と PHP は両方とも Mac OS X 上で問題なく作動するが、Lasso の Macintosh での使いやすさは独自なもので、Classic Mac OS の下で作動 する性能があり、FileMaker Pro や 4D へ直接接続させれる。Lasso のこ れからのバージョンでは Mac OS X でも作動するだろう。

産業化の時代:インターフェース優先、そしてその分離 -- プロジェク トが拡大するにつれ、青銅器時代のデザインでのコードの重複は悪夢となっ た。

バグが発見されたり機能が追加されたりすると、プログラマーはすべての ファイルを調べて修正個所と入れ替えなければならなかった。コードの複 製や変種をすべて把握するのに時間を費やさなければならいか、全部忘れ ずにアップデートするよう期待をかけるしかなかった。すべてが少しずつ 違うコードがからみ合ったつぎはぎのようになったとき、ソフトウェアの 質は急速に低下した。

産業化の時代のデザインはロジックをインターフェースから取り外すこと でコードの重複という問題を解決した。しかし、データアクセスがまだロ ジックの内部に埋め込まれており、青銅器時代のロジックに埋め込まれた モデルとほぼ同じく同期化が問題となる。

産業化時代のツールの例として、Cold Fusion、WebLogic、WebSphere、そ れにカスタマイズされた青銅器時代のツールが挙げられる。たとえば、管 理の仕事と一貫した秩序があれば、Active Server Pages、Java Server Pages、PHP を使用しながら産業化の時代のモデルをプロジェクトに利用 できる。Lasso はサーバサイド JavaScript も独自のタグベースの言語に 加えてサポートしている。

残念ながら、Lasso を除いてこれらのツールのうちはっきり Mac 用とし て提供されているものはひとつもない。Cold Fusion はロジックのほとん どを別のサーバサイドのファイルに置き、独自の JavaScript に似た CFScript と呼ばれる言語を含んでいる。WebLogic と WebSphere はいわ ゆる「Enterprise Java Beans」(EJB)コンテナの規格を実装し、Java ベースのロジックと Java Server Pages へのオブジェクトストレージの 提供をしている。WebLogic と WebSphere はロジックを直接ページに置く ことを禁じているわけではないが、ほとんどの人はそんなことをしないだ けの分別がある。

情報化の時代:すべてが分けられ、つり合っている -- 情報化時代のデ ザインはすべてを切り離している。インターフェース、ロジック、データ アクセスはどれも独立し、アーキテクチャとしてはっきり定められたチャ ンネルを介してお互いにやりとりする。

そのため、ビジネスロジックを伝えることなしに一群のページを外部の Web デザイン会社に作ってもらえる。舞台裏の熱狂的なオタク達は Web ページの配色や、会社が使うデータベースのブランドを気にしないでプロ グラムコードを書くことができる。データベース担当者は Web アプリケー ションが動かなくなる心配をせずに、データベースやテーブルやカラムを 移動したり名前を変えたりできる。

それに、開発者ひとりひとりが非常に速く仕事を進められるのだ。

情報化時代のデザインに欠点がない訳ではない。3 つの部分のどれもカバー する範囲が広く、それぞれが異なった領域を対象としている。だからある 面について変更を行うと、それがどんな影響を及ぼすのかすぐにはっきり しないことがよくある。そして習得はとても難しくなりがちだ。

情報化時代のツールの例は、私が知っている限り 2 つしかない。カスタ マイズした Lasso と WebObjects である。Lasso は SQL を隠すことがで きる上に JavaScript のアプリケーションロジックをインターフェースか ら切り離すことができるので、情報化時代のモデルだといえる。Lasso は 青銅器時代から情報化の時代までをカバーする唯一の製品である。これは 興味深いことだ。かなり理解しやすい青銅器時代モデルから始めて情報化 時代のモデルまで、必要に応じて徐々に利用することができる。もちろん、 そのようにすれば自分が成長するにつれて、やってきたことの大部分は無 駄になるだろう。しかしそれは他のツールでは起こり得ないことである。

WebObjects は Lasso よりもさらに学習が難しく、Classic Mac OS では 使えないが、完成度とパワーの面で Lasso に勝る。次回は WebObjects でいったい何ができるのか、もっと突っ込んだ話をするつもりである。


非営利、非商用の出版物およびウェブサイトは、フルクレジットを明記すれば記事を転載またはウェブページにリンクすることが できます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありませ ん。書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017

tb_badge_trans-jp2Valid HTML 4.01!Another HTML-lint gateway