雑記

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|
2007|01|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|09|11|
2009|02|03|05|06|07|08|10|11|12|
2010|01|03|04|05|06|07|08|09|10|
2011|05|06|09|10|
2012|03|07|09|12|
2013|01|02|04|05|07|08|10|11|
2014|04|05|08|10|12|
2015|01|05|
2016|09|

2003-06-04

MS FrontPage

カウンタをページに付けたのだが、うまく動かないとクレームがつく。CGIのパスの設定だろうとたかを括って相手先に出向くと、みたこともないタグが。いやな予感がしてヘルプを読むとFrontPage Server Extention とやらがサーバ上に必要らしい。そんなん知るか〜〜〜〜〜。

CGIの仕組みだけ簡単に説明して「頑張って下さいネ」と逃げようとするも、相手も必死で「じゃあ今から一緒にやりましょう」とガッチリ食いついて離さない。結局、適当なところからカウンタのCGIを取ってきてインストールし、動かす。手を動かしていたのはもちろん私だ。終ると一言「難しいですねぇ」。はぁ〜。

これ以上FrontPageに振り回されてはかなわんので、ホームページビルダーを強く推薦して帰る。

これまで知らなかった世界がどんどん開けてゆく。今後が不安。

本日のツッコミ(全4件) [ツッコミを入れる]

Before...

- taru-k [ホームページ・ビルダー,5000円じゃなくて、約10,000円です(www.amazon.co.jp調べ)。]

- nishi [FrontPageとかホームページビルダーって 使ってるんだ? WEBサイトとか持ってんの??]

- hs [このページの左上参照.]


2006-06-04

なんじゃこりゃ

さよならコピーレフト(Open Tech Press)という記事がセキュリティホールmemoで紹介されていました。記事ではWeb 2.0と呼ばれているものの中で、特にWebサービスに焦点を絞っているので、本コメントもそれに準じます。

結局目に見える形では何が起こっているかと言えば、サーバ側でこなす処理がどんどん増え(データもサーバ側に蓄積され)、一方でクライアント側での作業がどんどん定型化しているということである。
いきなりですが、上記の記述はWeb 2.0の解釈としてはかなり外しているように思います。

まず、オライリーの挙げたWeb 1.0的なものとWeb 2.0的なものの比較例を見ると、むしろサーバ側ですべての処理をこなしてブラックボックス化しているものがWeb 1.0的なものであり、APIを公開し、クライアントとサーバの間で協調(あるいは分担)して処理を行えるようになっているサービスがWeb 2.0的なものということになっています。より具体的な例としてAjaxについて考えてみると、このアプローチではサーバ側で実行する処理と、ブラウザ側で実行する処理をうまく切り分けることによって成り立っており、クライアント側での処理(作業)はむしろ1.0的なWebサービスよりははるかに多様化、複雑化しています。つまり、現実に起こっていること、ないし今後の発展の方向は、「ウェブサービスをウェブブラウザ経由で利用」しているように見えて、実はかなりの部分をクライアント側で処理し、サーバ側には必要最小限の処理だけを実行させる、というものでしょう。クライアントとサーバの性能差があまり無く、かつ「高速なネットワーク環境が普及」している時代であれば、なおさらこの傾向は強まっていくはずです。したがって、Web 2.0が巻き起こしている現象は、「インターネットを介したシンクライアント的発想への先祖返り」というよりはむしろ「クライアント(ブラウザ)をエージェントとして活用する、分散処理アーキテクチャ的発想への転換」とでも表現すべきものだと私は感じています。この流れでは、筆者の言うような「パソコン」というコンセプトの死には向かわず、むしろクライアントにはエージェント実行環境として、ある程度の高性能が求められます。

「パソコン」というコンセプトの死という考え方には私が思うにもうひとつ無理があって、それは、世の中にはWebアプリである必然性がまったく無いアプリケーションが多く存在するという、ある意味では当たり前の事実です。シンクライアント構想がいまいちパッとしないのは、既存のアプリでやっていたことを単純にWebサービス的なものに置き換えようとしたからだとも私は感じています。なにより、サーバに障害が発生したら、一切の作業が出来なくなってしまうようなアーキテクチャをいまさら採用するのは、リスクマネジメントという観点からすると論外に思えます。これからは、シンクライアント化ではなく、高性能なクライアントに最新のアプリを自動的に提供するようなサービスが主流になっていくのではないかと個人的には予想しています。

話がそれました。さて、Web 2.0として成功しているサービスは、クライアント単体、もしくは個人といっても良いかもしれませんが、それらがスタンドアロンでは絶対に実現できない新しい経験を利用者に対して与えているものばかりです。そうしたアプリの中でデータがサーバ側に蓄積されているものについて考えると、そこにはある種の必然性が見えてきます。つまり、それらのサービスでは、サーバ側にデータを置くことにより、

  • 個人では不可能なほど大量のデータを取り扱うことを可能にしている
  • データの更新内容がアプリ(エンドユーザ)に即座に反映される
  • データの維持・管理が双方にとって楽になる
といった、サービス提供者にも利用者にも便利な環境が整備されているのです。いくらPCのディスクスペースが巨大化してきたといっても、Google マップのデータを個々のPCに抱え込ませることは不可能ですし、Amazonの在庫データを手元にコピーして、常にサーバと同期させるなんていうのはナンセンスでしょう。

さて、件の記事では以下のように続きます。

ソフトウェアがサーバでのみ実行されるならば、そこにソフトウェアの「複製」も「頒布」も介在しなくなる。サーバから送られてくるのは処理済みのデータのみだからだ。こうなるとコピーレフトは全く無力である。
(中略)
コピーレフトが実質的に機能しなくなると、どういうことになるだろうか。おそらく、ソフトウェアのブラックボックス化が、今までとはやや違った形でゆっくりと進んでいくだろう。手元に実行形式があるのに、プロプライエタリだからソースが見られない、のではない。そもそも何も頒布しないからソースが見られないのだ。しかしソフトウェアを実行した結果はユーザに手に入る。そんな世界である。これはコピーレフトが実質的に無化された世界と言っても良い。
この主張については、前後の文脈を無視すれば異論を挟む余地はありませんが、これまで述べてきたとおり、Web 2.0と絡めるのには、かなり無理があるように思います。このエントリの最初で、記事の文脈に合わせるために、Webサービス以外のWeb 2.0的なものは除くと書きましたが、そもそもWeb 2.0という広大な世界の、一部についてのみ記述しておきながら、最終的には、
Web 2.0的世界を突き詰めていくと、これまでオープンソース/フリーソフトウェアを支えてきた大黒柱の一本が無効化される可能性がある、ということは、頭の片隅にとどめておく価値のあることではないかと思う。
と、あたかもすべてのWeb 2.0的な物に問題があるような結論とするのは、完全なミスリーディングでしょう。オライリーの挙げたWeb 2.0的な物の実装には、むしろオープンソースプロジェクトのほうが多いぐらいじゃないでしょうか。

ということで、明らかな勘違い、または変な意図に沿って書かれた記事という印象が強く、まさに「なんじゃこりゃ」だったので、取り上げてみました。

余談1

プログラミングをする立場の人間からすると、2.0的Webサービスのうち、APIが公開されているものについては、ソースを見られるに越したことはありませんが、逆に非公開であったとしても、さほど問題ではありません。極論すれば、きちんとしたAPIの公開は、ソースの公開よりもある意味強力なのです。具体例を挙げましょう。

Susieという画像閲覧ソフトでは、本体のソースは公開されていませんが、いろいろな形式の画像ファイルに対応するためにプラグイン方式を採用しており、そのAPIが公開されています。そこで何が起きているかというと、このAPIに対応したプラグイン自体の開発はもちろんのことですが、Susieプラグインを利用して画像を表示するビュワープログラムも開発されているのです。

これをWebサービスに当てはめると、APIを挟んで、クライアント側、サーバ側両サイドに関して、独立したプロジェクトが乱立し、それらがAPIで結合されているという状態です。つまり、サービスの提供者がソースを公開していなくても、そのサービス用に開発された多数のクライアントを、ほとんど変更すること無しに利用可能な別のサービスをオープンソースなプロジェクトとして立ち上げることが可能なのです。

さて、ここでたとえ話です。もし仮に、今現在、「amazon.co.jp」となっている部分を別のドメインに書き換えるだけで、Amazonよりも高いレートでお金を得られるアフィリエイトサービスが出現したら、あなたはどうしますか? Amazonにしてみればぞっとする話でしょうが、こうしたチャンスがあるのもまた現実です。

余談2

素朴な疑問なのですが、記事の筆者はWeb 2.0的なページで「ソースの表示」を試したことが無いんでしょうか?そこにあるのは、クローズどころか、ソースがばら撒かれている世界です。例えば、Google マップのページを開いてソースを表示させると、JapaScriptのプログラムを読むことが出来ます(。IEだと勝手にHTMLと解釈され、いきなり表示しようとするので注意)。今、彼らがバイナリで配布されるJavaアプレットではなく、ソースがそのまま流れてくるJavaScriptを採用しているのは、単なる偶然かもしれません。しかし、彼らがソースを公開することに抵抗を感じていないということは、頭の片隅にとどめておく価値のあることではないかと思います。