雑記

◆ こむら返りで筋肉痛？

ここ数日、極端に不規則な生活をしたせいか、3日連続でこむら返り。そのせいなのかどうなのか謎ですが、両足の前太ももが筋肉痛で、立ったり座ったりが非常につらい。

そういえは、こむら返りになった時に、以前はふくらはぎを伸ばしたりさすったり、という対処をしていたのですが、それをやると、翌日ぐらいまで筋肉に痛みが残っていました。で、どこかのサイトでふくらはぎを伸ばしたり刺激を与えるのは駄目で、全身の力を緩めるほうが良いという記述をみて実践したところ、直りも早く筋肉痛も後に残らなくなりました。具体的なやり方は、こむら返りがおきたら、痛いほうの足が上になるように横ばいになり、足の力を抜いて一番痛みの弱くなる角度に姿勢を保ってひたすら待つ。というものです。うまく力を抜けば痙攣中の痛みも和らぎますし、痙攣が収まってしまえば嘘のように痛みは消え去ります。収まりきっていない時に、なにかの拍子で足に力が入ると再び激痛が走りますので、痛みが治まってからもしばらく安静にするのがコツです。今度こむら返りになった時にはお試しあれ。

◆ なんじゃこりゃ

さよならコピーレフト(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的な物の実装には、むしろオープンソースプロジェクトのほうが多いぐらいじゃないでしょうか。

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

◆ 余談１

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

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

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

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

◆ 余談２

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

◆ とある家族のBlog

いや、ちょっと、これは。

コメントするのも野暮なので、とにかく読んでみてください。

◆ Google Spreadsheetまもなく登場

ありゃま。うーん、表計算ソフトなんてWebアプリに向かないソフトの代表格だと思っていたんですが、何か私の思いもよらないサプライズがあるんでしょうか。

Google検索システムで使われている「Shard」のリアルタイム版（表計算で言うと、セルの入力に追従して即座に複数のサーバにバックアップが取られ、対障害性を備えているようなもの）が実装されてますとか言うのであれば、ちょっと魅力的ですが、それでも大事なデータをGoogleに預けようという気にはなれません。

いや、純然たるJavaScript+αでWebサービスの皮をかぶった完全なクライアントサイドのアプリである可能性もあるか（意味ないって）。

◆ UNIX陣営に忍び寄る危機

昨今、新しいサービスを立ち上げようとする場合、フルスクラッチなどという悠長な開発アプローチを取っている暇など無く、既存の技術を組み合わせていかに効率よくシステムを組み上げていくか、ということが大切になっています。私もご他聞に漏れず、何か思いついたときにその部品となるべき機能に関して利用可能な既存の技術があるかどうかサーベイするのですが、その結果にここのところ変化が生じています。

もともと、上記のような考え方はUNIX文化に古くから根付いていたもので、以前はそうした技術のサーベイでもUNIXでの実装がすぐに見つかっていたのですが、ここのところ、そうしたサーベイにWindows環境での実装が真っ先にヒットしたり、さらにはWindowsの実装しかないといったものが出始めています。ちょっと複雑なものやグラフィックに関連するものについては特にその傾向が強いようです。そうした結果に多少の違和感を覚えつつも、偶然かもしれないとさほど気にしていなかったのですが、折りしも「はてな，Webのスクリーンショットを作成/表示するサービスをRubyの分散オブジェクトとRuby on Railsの組み合わせで実現」という記事の

スクリーンショットを撮影するためにWebを巡回するサーバーには，Windowsマシンを2台使っている。撮影できるスクリーンショットは2台で毎分120枚，1日17万枚。舘野氏によると，最初はLinuxでスクリーンショットを撮ろうとしたが安定しなかったり遅かった。

というくだりを読んで、その傾向は着実に進行しつつあるという現実をあらためてはっきりと認識させられました。こういう裏方的な処理はUNIX系システムの独壇場だという幻想を抱いていたのですが、それはまさに幻想にすぎず、着実に侵食されつつあるようです。UNIX陣営は、こうした事実に危機感を持って早めに盛り返していかないと、いつのまにやら取り返しのつかない所まで事態が進行してしまうのではないかと、ちょっと心配です。

◆ 夕食

9時ちょっと前に出かけたところ、入ったときはほぼ満席で出るときにはガラガラ。人のことは言えませんが、みんな分かりやすすぎ。