全文検索(S)

サイトリニューアルで考えたこと

このサイトの更新はしばらくいい加減になっていたわけだが、なんで更新が止まったかというと、その「作りの悪さ」に困っていたから、というのが一番の原因であった。

もともとこのサイトはかなり早い時期(7年位前?)から、HTMLの表示部分と中身を分けて管理すること、いわゆる「データの分離」を行ってきたのであるが、RSSだブログだといった形で情報を提供するにするには、それだけではどうにもならないのである。

10年も前にさかのぼれば、個人のウェブサイトはスタティックなHTMLファイルが普通だった。ダイナミックな処理をするプログラムを書くとしても、必要な作業はせいぜいデータの格納方法を決めることと、データを読み込んで整形して表示することくらいだった。データはCSVファイル(カンマ区切りファイル)であったり、あるいはRDBだったりするだろうが、そのデータの編集には、別途他のアプリケーションを利用すればいい。CMS(コンテンツ管理システム)の必要はあまりなかった。簡易CMSと言えなくもない掲示板のログだって、不具合があれば直接エディタで編集するものだったわけだ。ということは、かなり昔からデータの分離を行っていたこのサイトは、当然裏側で山ほどのデータファイルを抱えていたわけである。

ブログスタイルのページを生成しようとすると、30個くらいのXMLやTSV(タブ切りのテキストファイル)を読み込むことになった。日記のファイルは個別に分かれているし、トップページのイラストの履歴とか、アーカイブに入れたイラストの説明文だとか、その他の更新情報を格納したファイルだとか、イベントの参加ログだとか、まあとにかく、ものすごい数になる。毎回これらをパースしてはいられないから、当然、RSSやブログのための中間ファイルを生成することになる。かなりエレガントじゃない実装になった。以前、その実装の汚さと動作の鈍重さから、蛇蝎のごとく忌み嫌った、とある日本製のブログシステムと、ほとんど変わらないような状態になっていた。

大昔からパッチを当て続けて使ってきたこのサイトの管理システムは、エディタのマクロとか、アップロード用の画像を生成するスクリプトとか、実際にアップロードするスクリプトとか、データをパースするプログラムとか、サイト全体で考えると、恐竜のように肥大化しすっかり煩雑で萎え萎えなものになっていた。

仕方ないので、CMSをゼロから作り直して、古いデータはある程度コンバートしてRDBに流し込むことにした。CMSを作るってのは、情報を完全にゼロからデザインするってことでもある。いまさら新しく作り直すのは車輪の再発明だといえばその通りかもしれないが、その過程で考えられることは多かった。

なんといっても、CMSというバックエンドを作る方が、表側のサイトとして見える部分を作ることより、圧倒的にめんどくさい。

自家製CMS画面(ブログ管理)
図1. 自家製CMS画面(ブログ管理)
自家製CMS画面(画像管理)
図2. 自家製CMS画面(画像管理)

10年前は、まだ常時接続が多くはなかったから、ウェブに載せる具体的なデータの部分はオフラインで処理することが多かったと思う。以前俺が公開していた、Excelなどの表計算ソフトで作ったデータを処理してリンク集にするためのスクリプトも、そういう方針であった。

常時接続が当たり前になった2000年くらいから、ウェブ上のCMSでデータを操作したいという欲望が強くなってくる。当然、ウェブサイトはデータを操作するツールごと作らねばならない。ここら辺の時期に、ユーザと技術者とが完全に分断したんじゃないかなぁ。普通の人がCMSを作るのは無理だ。当然、誰かが作ってくれたCMSを利用するだけになる。多くの技術者も、自分でCMSをとやかくする気は、かなり失せた。ある程度以上の技術者にとって、ウェブ用のCMSを自分で実装することは全然難しいことではない。だが、あまりにも工程が面倒くさい。ウェブは、サービスの提供者と利用者とに綺麗に分断された。ウェブは、「作る世界」から「使う世界」に変わったのだ。これが「ブログの普及」という言葉で表される現象だろう。

ほとんどの人が、誰かが作ったお仕着せのCMSを使うことに何の不安も疑問も恐怖も感じないこと。それが「Web2.0」の特徴の1つなんだと俺は思う。

ウェブ自体も、ティム・リーが作ったお仕着せの仕組みだといえばその通りだけど、彼は出来るだけユーザーから中立的な仕組みを作ろうとする努力を欠かさなかった。『Webの創世』で彼はこう述べている。

私はCERNにやってきた数多くの開発者が、情報を体系化するのに「役に立つ」システムを押し付けてくるのに立ち会った。彼らはこういうふうに主張するのだ。「このシステムを使うには、すべての文章を4つのカテゴリに分割するだけでよい」とか「それぞれのデータをWordWonderful文書としてセーブしさえすればよいのだ」とかである。私はそういった提案者が次々と、憤慨した研究者たちによって炎の中で打ち倒される姿を目撃した。というのも、これらのシステムの開発者たちは、研究者たちの仕事をシステムに適合するように強制的に再編成しようとしたからである。私は誰もが受け入れることが可能な共通した決まりに従ったシステムを創造する必要があった。これは、でき得る限り何も決まりがないというのに等しいことを意味する(p. 27)

だからhttpは、仕様も実装も限りなくシンプルだ。

ブログはどうだろう。CMSは、定型のフォーマットに流し込むための定型のデータを求める。インタフェースはどれも似たようなものになる。そのお陰で書く側も見る側も分かりやすくなったし、サイト内で迷子になることも少なくなった。でも、CMSは、かなりのバッドノウハウの習得をユーザに求める。複雑怪奇なWikiの文法はその好例であろう。そしてCMSは、HTMLを利用して実現可能な表現より、ずっと狭い範囲でしかアウトプットしない。ユーザにできるだけ多くのことを許すように作られては、いない。

ブログは言論の開放なんだっていう言説は、伊藤穣一を嚆矢として社会学系の学者からもよく出てきたけど、それはある程度正しいがやっぱり半分は嘘だ。誰かが作ったシステムという、他人の手のひらの上で踊るコトも、確かに言論の自由ではあるだろう。でもそれは、言葉が起こせる範囲での変革だ。書籍に情報を載せることと、根本的には変わりはない。しかし、新しい情報システムを自由に作れることというのは、文字通り世界をひっくり返しかねないことだ。その昔インターネットに胸躍らせた本質はそこであって、言論の自由のレベルじゃ変革の可能性が一段違う。情報システムが世界をひっくり返すなんてアホかという、昔の佐藤俊樹みたいな反論を試みたい人は、GoogleやWinnyやSkypeのことでも考えてくれればいいと思う。

世間が、お仕着せのCMSを利用することが「ブログ」や「インターネット」だと思っているとしたら、それには抗ってみるべきだ。CMSをゼロから作り直すってのは、ブログを書くだけじゃなく、ブログがどうできるのか、httpはどういう仕様なのか、Apacheの実装はどうなっているのか、OS って何なのか、CPUってどう動いてるのか、そういう「下のレイヤ」へ興味を持つことの意味を、Web2.0で浮かれる世界の中で考えるには、良い機会だった。

やっぱ時々は車輪の再発明しないと技術も教養もつかないのかなぁ、とか考えながら、CMSを作ること自体は結構楽しかったのでした。

(122)

著作者 : 未識 魚
最終更新日 : 2006-10-21 17:36:30

ネットワークは何のため?

そもそも、昔の技術者はなんでコンピュータをつないでネットワークを作ろうなんて考えたんだろう。山形浩生はその理由を、コンピュータ単体じゃショボくて何もできなかったからだとアスキーPCの連載で述べている。その通りだ。周辺機器はおろか、ディスクもメモリもCPUも何もかも足りなかったから、リソースは可能な限り共有せざるを得なかった。では、なぜティム・リーはウェブ(ハイパーテキスト)を作ったのだろうか。これは本人の文章がウェブ上にある。要するに研究資料やコードなんかを上手く共有するために考えたわけだ。そもそもコンピュータネットワークとは、情報など資源の共有を目的とした存在なのだ。そして巨大なコンピュータネットワークであるインターネットも、情報を共有することを目的としている。ウェブもメールも情報の共有だ。情報はコピーされることで伝播していく。

さて、そのインターネットとは、全体を管理する組織が存在しない自律的なネットワークであるといわれる。ちょっと立ち止まって考えてみよう。それって、P2P 通信モデルのことじゃないですか。インターネットを構成している各ネットワークを結ぶルータは、全体を統括する存在がないわけだから、C/S(クライアント / サーバ)モデルではなく、P2P で動いている。RIP なんてまさにそうだ。P2P というのは別に新しく出てきた概念ではない。昔からインターネットは(広義での)P2P で動いているのだ。

情報資源の共有を目的としたインターネット。そしてインターネットは P2P モデルともともと相性がいい。だから、インターネット上の P2P システムで多量の著作物がやり取りされるというのは、(法的、倫理的な視点は抜きにして)システム的に考える限り、実は当たり前のことなのである。良い悪いに関わらず、インターネットというのはそういうベクトル(≒方向性)を持っているアーキテクチャ(≒仕組み)なんだ。そして、こういったベクトルを嫌がる側が、この構造を理解するよりも早く、インターネットはさっさと広まってしまった。はやっ。

もちろん、このベクトルは、現在の著作権法と禿しくコンフリクトする。現行の著作権法は、著作権者の権利を守るため情報の共有を制限する、ちょうどインターネットとは逆のベクトルを持っている。だから、情報ネットワーク社会と現行の著作権法とは、あまり相性がよろしくないのだ。これが現在の著作権法をめぐる問題点の 1 つだ。以上を鑑みるに、

「そろそろ匿名性を実現できるファイル共有ソフトが出てきて、現在の著作権に関する概念を変えざるを得なくなるはず。試しに自分でその流れを後押ししてみよう」

という Winny 開発者の発言の意図は、ネットワークがもたらす(あるいは既にもたらされていた)「当たり前」と、現行の著作権法とのギャップを何とか埋める、あるいは全てを押し切ってしまうことであったのではなかろうかと想像できる。上手に理念的にやればクリエイティブコモンズになり、強引に実装すれば Winny になるのだろう。

これを未必の故意による幇助と見るか見ないかは法律のプロがやることだから私には判断が付かないが、私に判断が付きそうなのは、こういった背景が司法判断をする法律のプロに伝わるかどうかという点だ。……うーん。微妙なところだな。簡単なことなんだけど。

(45)

著作者 : 未識 魚
最終更新日 : 2006-09-26 17:58:31

seek me - 私を探して

なぜGoogleではなく、Yahoo! JAPANか?という記事をハケーンし、触発されて自前のでも調べてみることにしました。リンク先の Perl スクリプトは、日本語の処理や複数キーワードの処理がちょっと不満だったので、さらっと PHP で集計スクリプトを書いてみたものの、遅い。ものすげぇ遅い。こりゃ C で書かなきゃだめか? とか一瞬血迷ったが、PHP や Perl みたいな糞遅いプログラムの中でカウントしたりソートしたりするのがイクナイ。

zcat ログファイル | キーワード抽出 > ファイル
sort ファイル > ファイル
集計 > ファイル
sort > ファイル

つまりはこんな風にシェルスクリプト中心にやればいいのだ。grep とか sort ってほんっとに速いなぁ。GNU ツールとシェルスクリプトのポータビリティすばらしや。

ついでなので、MSN と excite と goo.ne.jp も対象にした。イメージ検索をサポートしているサーチエンジンについては、それも対象にしてみた。googleは、補足しうるかぎりの全ドメイン、Yahoo!は、.jp と .com 、その他は .jp のみである。Yahoo! ディレクトリからのアクセスは対象外としている。いわゆる全角の英数字は半角に変換し、半角のカナは全角に変換してマージしている。google で無視されそうな記号も削ってみた。複数のキーワードは、分解して別々のキーワードとしている。また、ログの前後の行の文字列の類似度を見積もって、リロードなどによる重複と思われるものも可能な限り排除してみた。結果は以下のとおり。

google
検索語件数
1.photoshop4,153
2.着せ替え1,091
3.rgb1,067
4.cg988
5.ガンマ947
6.背景943
7.ガンマ値905
8.グレースケール861
9.輝度826
10.透明717
11.18禁698
12.osakana623
合計52,595
平均8.58
yahoo
検索語件数
1.photoshop5,164
2.着せ替え2,308
3.ロリコン1,587
4.ロリータ1,174
5.イラスト講座1,143
6.講座694
7.イラスト676
8.背景573
9.ガンマ値454
10.描き方447
11.shop423
12.水面422
合計35,921
平均10.78
msn
検索語件数
1.着せ替えゲーム4,821
2.着せ替え1,688
3.ロリcg788
4.ロリ433
5.cg334
6.photoshop275
7.ゲーム237
8.大暮維人152
9.グレースケール142
10.オーバーオール139
11.lolita137
12.ガンマ値104
合計12,522
平均17.71
goo
検索語件数
1.着せ替えゲーム714
2.着せ替え506
3.photoshop151
4.osakana.factory84
5.ロリcg78
6.ロリ64
7.ゲーム52
8.ガンマ値48
9.ガンマ45
10.cg45
11.背景43
12.グレースケール39
合計3,231
平均6.69
excite
検索語件数
1.着せ替え238
2.photoshop50
3.ガンマ29
4.水面21
5.オーバーオール21
6.ペン入れ17
7.水面の描き方14
8.グレースケール14
9.cg13
10.描き方12
11.女の子の着せ替え11
12.初心者運転10
合計948
平均2.84
全体
検索語件数
1.photoshop9,793
2.着せ替え5,831
3.着せ替えゲーム5,535
4.cg1,790
5.背景1,626
6.ロリコン1,587
7.ガンマ値1,517
8.ガンマ1,483
9.グレースケール1,457
10.rgb1,401
11.透明1,229
12.輝度1,200
合計105,252
平均13.15
メタデータ
リクエスト総数20,933,143
統計期間600日
採取できた外部HTTP_REFERER909,039
そのうち上記検索エンジン経由105,252
外部REFERERに対する割合11.58%
全体に対する割合0.50%

MSN が意外に多くてびっくりした。さすが MS の次期コアブランド、順調に洗脳が進んでいるようだ。goo や excite は全然勝負になってない。このサイトに直接関係無い唯一の固有名詞が MSN の「大暮維人」というのはちょっと面白い。全サーチエンジンで上位なのが、「着せ替え」だったというのもちょっと驚き。着せ替えはそんなに求められていたのか。

率直な印象は、「サーチエンジンからくる人ってあんまいないんだなぁ」って感じだなぁ。想像よりずっと少ない。これはつまり来てくれる人が固定化してるってことなのだろうか。アンテナサイトやロボットが発達するとこうなるのかなぁ。時間軸で切ってみるべきだったかもしれないが、十分なサンプル取れないかもしれないなぁ。HTTP_REFERER の採取率は年々下がっているし。あとせっかく載せてもらってる Yahoo! Directory を集計から外したのはもったいなかったかなぁ。

うーん他にはどう読めばいいのかなこのデータ。例えば、それぞれのサーチエンジンの合計に占める 1 位の検索語の割合。Google がダントツに低い。これはつまり、検索語件数の偏差が小さいってことだ。ということは、Google を使う人は、それぞれバラバラの検索語を叩き込んでるってことで、Google から来る人は何かを探そうという明確な目的意識をもっているという印象を裏付ける傍証になってる……のかぁ?

より使えそうな統計として、あるキーワードで訪問してきた人がどの程度滞在したかを調べるというのがあるだろう。多分、非一般的な用語の方がサイト滞在時間が長引く傾向があるだろうなぁ。

(43)

著作者 : 未識 魚
最終更新日 : 2006-09-26 17:58:40

カスウェア

UNIX 系 OS だとすぐ実現できることだけど Windows でやろうとするとちょっと困るなんていう、あまり多くの人と共有できなそうな俺の単純な悩みに、Windows では time() 関数(システムコール)の戻り値である UNIX 時間(UNIX epoch、1970年 1月 1 日 からの通算秒数)をお手軽に得られないというのがあった。

というわけで、5 行で書けるプログラム unixtime.exe を一応公開しておく。Windows でコンパイルする環境作ったり cygwin 入れるのがダリーけど time( ) 関数の値を標準出力に出すだけのプログラムを Win32 環境で欲しがるという、ほとんど誰とも共有出来無そうな要望を持っている誰かへ。

よし、とりあえず Google で引っかかりそうな言葉は散りばめた!(w ちなみに秀丸エディタのマクロから利用する場合は、実行結果をテンポラリファイルにリダイレクトして insertfile するというのが無難と思われ。

(43)

著作者 : 未識 魚
最終更新日 : 2006-10-15 10:39:43

XML て胸キュン?

日記のデータを、腐れ独自テキスト形式から、やや真っ当な XML にしてみようと決心してみた。単に、日記に見出しを付けてみたかっただけなような気もする。

XMLで日本語扱うとなると UTF-8 しか選択肢ないノカー。格納ファイルサイズ 3/2 倍になるやんけー、って、どうでもいいかそんなのは。普段使ってるエディタやビューワがまともに UTF-8 に対応してないってのが最大の問題だな。さらりと変えてみるつもりで、幾つか弱めの障害にぶち当たる。

  1. この腐れ emacs(暴言)めっ! set-buffer-file-coding-system で UTF-8 に変えられてるのに、何故保存すると勝手に iso-2022-jp になるのじゃ!
  2. lv って行スクロールがむっちゃくちゃ遅ぇっ!
  3. xml parser って、当たり前ながら文法にキビシー!
  4. 最近の秀丸って BOM 付けるようになったんだなぁ。
  5. オブジェクトバリバリで書いたら当社比 1.5倍くらい重くなったぞ!
  6. 昔の日記内の HTML かなりヒデェよ! 内容もな!

無事 emacs で UTF-8 の読み書きが出来るようになったり、lv やめて lesspipe 書き直して nkf と less を組み合わせることにしたり、過去のデータを一括変換するスクリプト書いたらかなり HTML の間違いを見つけて鬱になったりしたわけですが、emacs 21 の UTF-8 対応で一番役立ったのは Linux JF。しかし emacs コミュニティってかなり停滞 & 荒廃してきてるような……。クワバラクワバラ。

で、無事XML化してみる。あー、イベントドリブンでツリー型のデータ形式を読みほぐしていくというのがちょっと新鮮。そして面白い。でも当たり前ながらやっぱりパーサ使った後は泥臭く書くしかなくて、とっても「半構造化」だなぁ、と思う今日この頃。

しかし、XML に関連するキーワードで検索すると、「純粋なバカを誑かして金をむしろうとするちょっと利口なバカ」な商売人ばかり引っかかるような気がするようなしないようなごにょごにょ。

ついでに各テキストにジャンルという要素も隠し持たせてみてザッと分類してみたら、ほとんどヲタネタ書いてないなぁ俺。これじゃまるで、俺がヲタクじゃなくて デムパな 情報社会学系の人間みたいじゃないか。

(43)

著作者 : 未識 魚
最終更新日 : 2006-09-26 17:58:49

R.O.D -Run or Debug- ウェブストラクチャ編

ウェブページのコンテンツは、データ(DB のレコードのみならず、文章そのものや画像ファイル、そのリソースにまつわる最終更新日などの情報)、デザイン(見た目ね)、ロジック(本でいう構成や編集といった意味合いで考えてください)の 3 つの要素に分解できる。この 3 つの要素は、動的あるいは静的に統合されて、コンテンツを構成する。

例えばこのサイトでは、PHP で書かれたサーバサイドのプログラムによって、データやデザインが一定のロジックに沿って統合され、最終的なコンテンツとなっている。これを動的な統合と呼ぼう。一方の静的な統合は、人間が GUI アプリケーションの助けなどを借り、手動でデータ、デザイン、ロジックをまとめることとなる。ほとんどの個人サイトは、後者の静的な統合で(つまり手で)ウェブページを記述している。動的な統合を行っている例としては、2ch などの掲示板や、tdiary などのブログが該当するだろう。

動的な統合を行うまず第一の目的は、データの分離である。この分離は容易だ。この日記で言えば、日付を <h3> にするとか、文章の見出しを <h4> にするといったウェブページのロジック(構成)と、DB に収納されるテキストデータとを分離するということである。つまり、日付の部分を <h3> で囲むかどうかは、DB からデータを引っ張り出して表示する時に決めればよく、<h3> で囲った日付の文字列を DB に入れたりはしないわけだ。というか、もともとウェブ以外でのデータ管理のために使われてた RDB のデータを、どうにかしてウェブに出そうってのが発想の順番かもしれないから、この detach はかなり綺麗に行われている。問題なのは、デザインとロジックの分離である。

長年試みられてきているにも関わらず、この二者の分離はかなり難しい。CSS やテンプレート化や各種フレームワーク(WebWorkとか)のお陰でかなり容易になったとはいうものの、CSS は <TABLE> によるデザインよりも表現の幅を狭めてしまっているし、テンプレートやフレームワークの利用はもっとデザインの、つまり表現の自由度を狭め、ウェブが悪い意味で定型化してしまう。だから、何かを妥協しない限りどうしてもどこかでデザインとロジックは混ざり合うことになる。でも、そうするとやっぱりウェブのポータビリティは下がってしまう。極端に言えば、デザインの変更のためにプログラマが必要になるというわけだ(この辺の単純化した例については ITMediaの記事 とか参照)。時々なんかスゲェ誤解している人がいるのだが、XML は、この手のジレンマの解決には役立たない。CSS を考えながらロジックを組むことが求められたりするからだ。結局一番有用なのは、デザインやロジック面での妥協であったりする。

というかだな、デザインとロジックという二者はそもそも分離できないと考えるべきだ。だってさ、本の構成や編集がデザイン抜きで行われることなんてありえないだろう? この日記で言えば、日付を <h3> にするというロジックと、それを下枠付きで文字間を開けて表示するというデザインとの間には、全く相関性がないのだろうか? あるに決まってる。日付を <h3> にして、文章の見出しを <h4> にした以上、その主従関係に従ってそれなりに見せるよう考える必要がある。文章の見出しを日付より目立たせるデザインは、ロジックを決定した時点で捨てられてるわけだ。

こういう分け難いものを強引にでも分離しようとすれば、どこかで何かを妥協するということになる。それもこれも、ウェブ( ≒ HTML)はロジックの規制が弱く、はなっからポータビリティが良くないのが原因だ。しかし、そのロジックの規制の弱さは自由度ってことでもあり、ウェブ作成を一般人にまで広めた原動力の最重要要素でもあるわけで、実に悩ましい。

で。ここ数日、このサイト全体の xhtml 化を試みてみたのですが、分離できていたと思ってたあちらこちらが実は全然分離できてなかったりして。で、表型のデータもツリー型のデータもラップして扱える基本のデータ処理クラスを書いてデザイン部分は表示用のメソッドをオーバーライドしてって手で書き直したものの、あっちらこっちらでオーバーライドしまくりたいという欲望が湧き上がってしまい、ということは癒着に対応しきれてないわけで、データの設計から考え直すか諦めて癒着のまま押し通すかだなぁ、と R.O.D 見ながら実行とデバグを繰り返しているわけです。ってそれなら "Run And Debug" だぜ、つか今時 "RUN" なんて言わネーヨ、ha-ha-ha!!

この長文の要旨:雪野五月萌え。(ぇ

(47)

著作者 : 未識 魚
最終更新日 : 2006-09-26 17:58:47

バカと小利口

情報処理界の非常に根深い問題として、エンドユーザの技術レベルや情報リテラシが向上するというドリームの実現については全く期待ができない、という点がある。というか 1mm たりとも期待してはいけない。アラン・ケイやテッド・ネルソンは夢を見られたかもしれないが、まだ夢みてる人は正直あんまいないと思う。だから、最もバカで DQN で救い難いほど愚かなエンドユーザに合わせて、システム全体をきつめに制限する仕組みを、技術的な部分のみならず社会的にも作ろうとすることになる。例えば、法とか倫理とかライセンスだね。

でも、技術に明るい小利口な人間は、こっそりそのシステムの制限をすり抜ける技術をみつけたり作ったりして、こっそり利用する。クラッキングってのはね、クラックしてることがバレたら、誰がクラックしてるのかはバレなくても、もう終わりなんだよ。誰にも気付かれずにリソースを使い続けるってのがクラッカーの究極の目的だからだ。で、小利口な人間はこっそり利用しながらこっそり技術を磨き、こっそり情報を蓄積し続ける。インフォリッチとインフォプアの差は一層拡がっていくわけだ。そうすると、ますますシステム全体をきつく縛る技術的・社会的枠組みが作られる。しかし、小利口な人間はその枠組みを迂回するズル賢い方法を必ず見つけ出す。だって小利口なんだもん。

そうして、ネットワークは徐々にバカ向けと小利口向けに二分化していく。インターネットって、そういう弱肉強食な世界を目指していたんだっけ?

村井先生、俺は、既存の IPv4 と互換性のない IPv6 の導入が、そういうニ分化に一役買いそうな悪寒がするんですけど。そこら辺も、是非上手く政治的にグルグル手を回してください。おながいします。

どうでもいいけど Cliff Martinez 萌えー。って彼の作品に萌えられるのは、相当なミニマリストかアンビエントテクノ愛好家のみですのでご注意を。

(45)

著作者 : 未識 魚
最終更新日 : 2006-09-26 17:58:53

仕様と呼ばれるもの

なんか今更な発見なんですが、SUSIE って、プラグイン一切無しの素のままで PNM 読めるんですね。正確には、binary(raw)モードの PPM(フルカラー) と PGM(グレースケール) に対応してやがります。バイナリモードの PPM や PGM は、BMP(DIB)とほとんど変わらないとは言え、イメージの縦・横サイズとビット深度は、アスキーな PPM ヘッダを読み取らないと分からんわけですから、明らかに意識して対応してやがるのに、何故かこの件については一切 たけちん さんから情報が公表されてないという不思議。せっかくだから、Google でひっかかるようにここで発表しておこう。ついでに、PBM は非対応でした。もしかしたら開発環境のなんかのライブラリが PPM と PGM だけ扱えるようになってるんだろうか。

ちなみに、古い OPTPiX 1.2 で試したら、PPM と PGM は、それぞれ RGB、グレースケールの RAW のベタ画像と判断して、横幅 640 ピクセル固定で読み込むようです。OPTPiX も PNM 対応についての公式アナウンスは一切ないんですが、VGA サイズの画像は扱えるってことになります。ウェブ用途というより、ゲームなどの減色をターゲットにしてる OPTPiX らしい割り切りかもしれない。しかし、PPM と PGM の区別が付くってことは、P? のマジックナンバーだけは拾うのに後は読み捨ててるってことだろうか。おもしれー判断するなぁ。

こういうブラックボックス状態で処理結果だけ眺めてても、コードを書いた人に共感したり首をかしげたり推理をめぐらしたりする瞬間というのがあるわけで、プログラムの「思想又は感情を創作的に表現したもの」としての側面を感じます。何気なく「仕様」と呼び捨てられてしまうものにも、何らかの考えがあるはずだと推測するところが面白い。

(51)

著作者 : 未識 魚
最終更新日 : 2006-09-26 23:14:06

レッシグは偉大だが全てのレッシグ支持者は偉大ではない

このままじゃ、クリエイティブコモンズは、一部のインテリとそのフォロワのオナニーで終わると俺は思う。GPL がある程度成功しているのは、ソースを書く「クリエイタ」は大体インテリでもあるという、2 層が一致する極めて珍しいケースだったからだ。現行の著作権法だって満足に浸透してないし、GPL をちゃんと理解してる人だって多くはない。そんな状態で、クリエイタに多くのリテラシを求めすぎ。クリエイタにとっては、そんなメンドイこと考えるよりなんか創る方が大事ではなかろうか。中間搾取してるだけにしか見えないレコード会社だって、クリエイタを雑務から切り離して創作に専念できる状態を作るってことも、やって来てるんだよ(でも、みんなクリエイタって存在にドリーム見過ぎ。実際は泥臭い非創造的作業も少なくない)。そうはいっても、そうやってクリエイタを「保護」してあげよう的な考え方って、コモンズが求める世界とは逆になるわけじゃん。クリエイタには、要するに自立が必要なわけよね。自立っていうとカッコイイけど、じゃあ、みんな会社や学校辞めて自分の腕だけで食っていく覚悟ができる? もともと身分の不安定な多くのクリエイタにとって、編纂業務を行っている企業というのは、数少ない拠り所の 1 つなんだ。それを切り捨てろというのは酷だ。というわけで、状況がもっと切迫しない限り、CC なんてムリではなかろうか。

……と俺は漠然と考えるわけだ。もし今のまま CC が広まったとしたら、CC層 と 非 CC層 の分化が起こるような気がする。おお、一転してアカデミックな表現だ。んで、それは、如実にリテラシの差を反映してしまうのではないか。クリエイタとしての技量なんかは関係なく。だってさ、『コモンズ』って、気楽に読める本ではないじゃん。これちゃんと読んでちゃんと理解してるのってどういう人達? 少なくとも貧乏クリエイタ層じゃないよね。で、そういう理解できる人ってどういう社会的レイヤにいるの? 利益が非明示的で啓蒙が必要な変革! オワットル。つまりさ、そういう形での「変革」って多分ムリなワケよ。まあ、そういうのを信じて実行するのがインテリの責務なんだって言われれば、そうなのかもしれない。でもこのパターンでは歴史上に失敗例が豊富だから俺は全く期待できない。

110年前に作られた曲『ハッピーバースデイ』さえ自由に歌えない ような現状に変革を起こしうるとしたら、とてつもない能力と影響力を持ってるクリエイタが、多数のファンと共に、「変えちまえ」と唱えた時くらいだろう。だからさ、どうせ啓蒙ならもっとそういう方向で動いて切り崩す方が早いんよ多分。

(45)

著作者 : 未識 魚
最終更新日 : 2006-09-26 17:59:00

多層世界の上で

コンピューターに触ることとプログラムを組むことがイコールだった時代はそう遠くない。自分でプログラムを組まないのなら、プログラムを買ってこない限りコンピュータは何もしない。だから、MS-DOS より前に何らかの形でコンピュータに触れている人で、なおかつコンピュータに興味があると言う人なら、多かれ少なかれ何かのコードは書いただろう。ゲームが好きだという人や、LISA 使ってたとかいう話はどっか置いといてね、ややこしくなるから。

今コンピュータに触ることとは、GUI な OS 上のアプリケーションの使い方を覚えることだ。で、今コンピュータやネットワークを好きだって気楽にいっちゃう人は、テレビが好きだ携帯が好きだっていう人と同じようなもんで、コンピュータやそれを利用したネットワーク上で流通するコンテンツが好きな人が多いだろう。コンピュータのハードウェアやソフトウェアの仕組みそのものが面白い人よりも、ずっとずっと。既に、http の上には、例えば SOAP とか DAV とか、もっと身近なのだと blog みたいな、あるいは 2ch なんかでもいいが、そういうブラックボックス化したプロトコルやシステムが被ってしまっていて、多くの人の興味は、OSI 第7層以下まで到達することがない。普通の人の何気ない好奇心を阻むくらいには、フクザツな仕組みだったのだ。

でもそれはレイヤー化がもたらした必然であって、こうあるべきという事態なんだ。Socket を開く時、それ以下の仕組みなんて考えない。そのレイヤーが 1 段 2 段上がった。ただそれだけのことだ。でも、情報系の学者や技術者達はこういう“衆愚”な状態は予想してはいなかったんじゃなかろうか。アラン・ケイ御大とかもね。Squeak ってなんか違うですよ、そうじゃないと思うんですよ。これに興味持って組むヤツは、大体どんなプログラム言語与えても興味持つヤツだよ。

(45)

著作者 : 未識 魚
最終更新日 : 2006-09-26 23:19:25
  1. [1]
  2. [2]
  3. NEXT >


<TOP>

[ Copyright 1996-2023 Mishiki Sakana. Some Rights Reserved. ]