【レポート】オープン・ネイチャー - 芸術は科学? 感じる芸術から、計算し、考える芸術へ (1) アーティストたちの変化、シミュレートされる"自然" (MYCOM PC WEB)ネタ。古いネタだが、情報処理学会ヒューマンインタフェース研究会の案内に「システムが生み出すアート」の招待講演の話が出ていて、検索すると引っ掛かった(^^;)記事なので、こういうことが起きる。結果としては直接は関係のない記事であるが、コンピュータがあるからこそ出現したアートについて知ることができる。講演者名から検索すると、直接的な情報が得られた。想像力をくすぐる世界が広がっている。
『アルス・エレクトロニカ』、今年のテーマはハイブリッドネタ。
まずはARS Electronica FUTURELABぐらいから探索するとよいかもしれない。とても短時間では見れそうもない。
トム・クランシー著、田村源二訳、「国際テロ(上)」、新潮文庫ク 28 33、平成17年8月1日発行、478ページ、781円。トム・クランシー著、田村源二訳、「国際テロ(下)」、新潮文庫ク 28 34、平成17年8月1日発行、452ページ、743円。「国際テロ」というタイトルは賛否両論だろうけど、著者の名前で売れるので目立てばよいだけかもしれない。「虎の牙」(The Teeth of The Tiger)が原題である。
テロ対策部隊の話はジョン・クラーク主人公の「レインボー・シックス」があるのだが、本作品がどのようなつながりがあるのかはまだプロローグの途中なので知らない。クランシー・ワールドのさらに先を進むものであることを期待している。「教皇暗殺」は読了しないままに、新作に手を伸ばしてしまった。「日米開戦」や「合衆国崩壊」の驚くべき圧倒的な想像力の世界を再現して欲しいものだ。
養老先生の「人間科学」、「まともな人」。ジョン・ル・カレの「ナイロビの蜂」上下。「まともな人」は中央公論連載「鎌倉傘張り日記」の2001年1月~2003年9月分を収録したものである。
アマゾンのマーケットプレースで注文した本。和樂堂からすぐ届いた。
津田一郎著、「カオス的脳観 - 脳の新しいモデルをめざして」、サイエンス社、1990年10月25日初版、220ページ、1803円。1990年の初版だが、新品同様だ。マーケットプレースの場合は送料340円が必要なので、半額というわけにはいかないが、それを含めてもかなり安い。お買い得だ。この本は養老先生の本の解剖学Ⅰ、Ⅱと松岡正剛氏の千夜千冊の重なる唯一の一冊である。
序を読み始めると、1960年代後半から1970年代にかけて質の異なる科学が生まれてきたとあり、最初にルネ・トムのカタストロフの理論が上げてあったので、大変懐かしくなって、野口広著、「カタストロフィーの理論 その本質と全貌」(1973)を引っ張り出した。
パラパラと捲りながら、アトラクターという言葉に気付く。カオスで有名になった用語である。つながりがあるのか、カオスもここらが出発点なのかな。野口さんの本もおもしろいのだが、ルネ・トムの本も読んでみたいとアマゾンを検索する。ルネ・トム、E.C.ジーマン、宇敷重広、佐和隆光著、「形態と構造 カタストロフの理論」(1977)が出てくる。この本は持っているのじゃないかな、本棚を探し始める。あった、あった(^^)奥まったところに収まっていた。約30年ぶりに読み直すことになりそうだ。当時は新し物好きで読んだのだが、現在の視点で読むのはまた全然違うし、理解度も違うだろう。カオス的脳観が記憶の奥底に沈んだ過去を蘇らせてくれた。
アマゾンから立花隆著、「サル学の現在 上、下」(文春文庫1996年、元の平凡社単行本は1991年)が届いた。
以前、分厚い単行本を手に取ったことはあったけど、結局買わなかった。養老先生の本の解剖学で推薦されていて、調べると文庫本になっていたので注文した。まだ、最初のところだけど、期待に違わずおもしろい。人間とは何かを考え直す良い機会になるかもしれない。
序章にある今西先生の言葉をいくつか引用しておこう。
そうやな。ぼくは今の自然科学のようなちっぽけな問題をやるのは忍びんねん。人間はうまれつきもっと大きいんですよ。その大きい人間を生かさないかんな。そのためには自然科学を捨てなさい、というたら一番ええねん。
はじめのうちはうまいこといっていたのやけどな。もう今日になったら、くちゃくちゃやな、この機械文明というものは
楽天のスーパーポイントが、DVD-2910購入分と500ポイントのプレゼントで1000円分を越えると同時に、楽天ブックスで使えるようになったので、早速使ってみた。松岡正剛の千夜千冊『生命を捉えなおす』清水博が欲しくなったからだ。Webで調べているうちに、合わせて最近執筆された「場の思想」も購入することにした。
注文が9/28の夜、今日帰宅したら届いていた。ライティングディスクには世界を捉えなおすために読まなくてはならない本が堆く積まれている。
being digitalが書かれたのは1995年だ。「カオス的脳観」や「生命を捉えなおす - 増補版」が書かれたのは1990年というから驚く。「生命を捉えなおす」の原初版は1978年というからさらに驚く。日本人も捨てたものじゃないどころか、すごいなと思う。
テレビとの融合加速へ──パソコンの未来像を各社PC担当トップに聞く 第1回:IT Proネタ。
現在のテレビの形態はなくなるだろう。PCとモニタのセットがテレビという形態になる。モニタは高画質の大画面のものが居間に置かれるだけで、チューナーを内蔵するか、外付けしたPCからコントロールするようになるだろう。無論、PCはインターネットに接続して最新の番組表を表示し、モニタに番組を映し出したり、HDD/DVDレコーダに録画したりすることができる。VODとかEODとかにも対応するようになるだろう。レコーダで録画したものはホームサーバーにライブラリとして蓄積され、LAN経由で各部屋のPCにダウンロードして再生することができる。各部屋には本来のPC用のPC-モニタとメディア視聴用のPC-モニタが置かれるはずだ。メディア視聴用のPCはTVチューナーとレコーダをそれぞれ持つことになるだろう。
僕の予想は単に現状のテレビをPC+モニタ(+レコーダ)に置き換え、家庭内LANに接続した状況を描写したものである。PCの画面でPCを使いながら長時間に渡ってテレビを視聴したいと思う人はいないと思う。テレビとPCは本質的に違うものである。一緒になることはない。[Revised: 2005-09-20]
さて、年末にはXbox 360が、来年にはPlaystation 3が、Intel版Mac mini(nanoかもしれない^^;)が、Windows Vistaが、Mac OS X 10.5 Leopardが出る。どのような展開が待ち受けているのか。
ハードウェアの能力の向上はまだ止まらない。HDDの記憶容量もまだ増大しそうだ。PCに搭載されるHDDも1基でテラバイトの世界を伺うようになるだろう。デスクトップに世界が入るようになる。個人がこれまでは信じられないぐらいのコンピューティングリソースを保有できるようになる。
Windows上でもオープンソースの成果を享受できるようになり、様々なフリーのプログラミング言語やアプリケーションを使うことができるようになっている。Windowsは単なる一つのプラットフォームと化しつつあるようにも見える。そのような中での動き。注目しよう。
PCがテレビと融合するというよりも、テレビがインターネットにつながる家庭内LANに接続するためにはPC化する必要があるということである。同時に録画機能+ホームサーバーとしての機能を持つことが必然となる。本当のPCはPCのままである。個室には、やはりLANに接続したテレビとPCの両方が必要である。個室のテレビにもサーバーと録画機能があったほうがおそらく便利だろう。PCとテレビの差はテレビ放送やビデオを映しているか、あるいは録画マシンを接続しているかどうかぐらいしかなくなる可能性もある。しかし、PCとテレビはものとしては同じになっても、使い方はけっして同じにはならないのである。
フォトレポート:次世代ゲーム機が火花を散らす、東京ゲームショウ2005開幕 - CNET Japanネタ。
今朝テレビを見ていると、PS3とXbox 360のゲーム画面が紹介されていた。なるほど、これまでのものとは違うようなリアリティさである。養老先生もゲームがお好きなようだが、どのように評価されるのか聞いてみたい気はする。まあ、僕はゲームにはそれほど興味がないので評価する能力はない。
養老先生の「人間科学」を読み始めると、まずは「自分を知れ」である。結局、人間が生きることは「自分を知る」ことである。それは「人間とは何か」を考えることに通ずる。人間とは何かを考えるために、世界とは何かを考える必要が出てくる。さらに言えば、社会とは何かであり、自然とは何か、宇宙とは何かであり、素粒子とは何かであり、時空とは何かである。ゲームをするよりはそちらのほうがおもしろいと思う。しかし、ゲームをする人間について考えるのは、人間とは何かを考えることに通じるだろう。そういう意味ではゲームを体験するのも一興かもしれないが・・・はまったりして(^^;)人間とは奇妙な生き物である。
新ゲームマシンについては英語版のWikipediaがリファレンスも充実していて、情報の収集度が素晴らしい。PS3については、日本で44,800円、米国で399$というメリルリンチの予測を記載している。Xbox 360の価格はこれにぶつけているようにも見える。
現時点であれば、この価格で、Linuxを載せて、フォントや仮名漢字変換システムをきちんとすれば、絶対売れるはずだが。PS3は80GBのHDDにLinuxを搭載するプランがある(Kutaragi talks more on PlayStation 3 - News at GameSpot)。PCの性能と価格がどこまで追いついてくるのか。インテルの本格的マルチコアCPUの登場は2007年ぐらいになりそうだが、逆にCellの消費電力と発熱の問題は来年までにクリアできるのか。ディスプレイ・キーボード・マウス・HDDを加えてのシステム価格はどれくらいになるのか。ゲーム機とPCをセットにしてシステムの競争力を高めようというビジネスモデルが成功するのかどうか、実際どのような戦略が実行されるのか、楽しみではある。
こうして見ると、PCとテレビとゲームマシンのコンソールはいずれ同じものになっていくということだ。メモとして最新情報と復習情報のリンクを追加しておこう。
久夛良木社長の話を読み直していて、PS3にとってOSはアプリケーションだというのがおもしろかった。確かに何が出てくるかわからないかもしれない。PS3の開発というのはどのようにするのだろう。
次世代のコンピューティングは低消費電力CPUのインテルか、Cellか、いずれにしても来年は楽しい年になりそうである。Cellのほうが夢があるような気はするのだが・・・
更新日記のOpenGL関連の情報をチェック。全部Playstation関連だ。あまりない。
MITなど、100ドルノートPCの詳細を発表--ゼンマイ駆動も可能 - CNET Japanネタ。Being Digital(1995)のNicholas Negroponteのお話。
僕も欲しい。みんながMIT Media Laboratoryにアクセスしているみたいだ。
ビル・ジョイ:「ウェブの未来は携帯端末に」 - CNET Japanネタ。
なんでもいいから、とにかく日曜プログラマが働けるようにしておいてくれ(^^;)押し付けのアプリに使われたくない。
気象台の台風予報に書いてある台風の名前だが、デジタル台風:単一系列ビュー(台風200514号)を見ると、NABIとある。預言者という意味である。ナービーは風はそれほど強くない雨台風だ。広島も雨が強くなってきた。被害がなければよいが。
おもしろいネタはいろいろあるけど、試してみるだけの余裕がない。インターフェースの街角(90)の「TV番組の検索と録画予約システム」はおもしろそうだ。これはどこかで試してみたい。先立つものが問題だが(^^;)
もう一つは、japan.linux.com | パノラマ画像を作成するソフトウェアツールネタ。これも楽しそうな話なので、いずれ是非トライしてみたい。
読書はだいぶ進んできているが、少しずつ整理していこう。まあ、焦らずいこう。焦ると楽しくなくなる。Have a fun.とは良く言ったものだ。風の中で虫が鳴いている。
養老先生の「本の解剖学1 脳が読む」を読み終えた。そこからちょっと引用。『現代文化が表層的な感じを与えるのは、それが根本的に理性主義をとるからである。そこでは、「わけのわからない」ものは、いっさいあってはならない。しかし、自然にせよ、その産物である人間にせよ、ほんとうにわけのわかるものか。』
テクノロジー、デザインは製品を評価する場合に理解しやすい要素で欠くべからざるものである。が、実際のところユーザーにとっては表層的なものである。iPodやiTunesの持つ機能は単純なものである。単に音楽を購入して蓄積し、モバイルで音楽を聴けるようにするだけだ。シンプルな音楽選択・購入・管理・鑑賞の仕組みは、iTMS-iTunes-iPodのセットで提供される。ユーザーが製品を購入するのは自分のニーズを満たしたいからだが、Appleが演出しているのは一種のコミュニティである。確かに、フラッシュメモリが半額になったのには驚いた。フラッシュメモリの価格低下はマイクロドライブとの競争が背景にあるのだろうが、低価格で広く普及させ、音楽を日用品化させる戦略だろう。誰もが参加できる音楽コミュニティをiTMS-iTunes-iPodが媒介するのである。iTMSはメディアである。
ソニーがなすべきことはと、えらそうなことを言うわけだけど、音質に徹底してこだわるべきである。記録フォーマットを変えてもよい。ソニーはテクノロジーに特徴のある会社である。昔はオーディオ部門もあった。音質が明らかに違えば、そしてそれを評価できる環境を生み出せば、音楽ファンは良いほうを選択するだろう。原理は本質的でシンプルである。一音楽ファンからのささやかな提言である。
Tech-On!にある今井拓司氏のブログによれば、Appleの製品設計の根幹にあるのは、User Experienceという概念なんだそうだ。Don Norman's jnd.org / user advocacy and human-centered designは勉強する価値があるかもしれない。それはそうと、iTunesのライブラリの曲数が、iPodに収納できる曲数を上回った時、何をiPodに残しておくのかはどのように決めるのだろう。あるいは曲の入れ替えはどのような手順でするのだろう。ずっとそれが気になっている。
以前にも述べたが、iTMSで感動したのはアーティストのバイオグラフィーである。このようなものがあることに驚くのはコストが掛かるからである。バイオグラフィーにはビジネスとは異質な印象を受けるのである。懐の広さがある。無論、販促してコストを回収する仕組みを内蔵しつつ、ユーザーを喜ばせる情報を提供しているということであるかもしれない。残念ながら、日本のアーティスト、例えば浜崎あゆみのバイオグラフィーはない。少なくともアーティストのオフィシャルサイトへのリンクぐらいは提供するとよいかもしれない。英語版のバイオグラフィーにあるアーティスト名からの検索は生きていないものもあった。実際にはあるのにも関わらずヒットしない。まだまだ問題は残しているが、音楽データベースとしてさらに発展することを期待している。音楽がより身近になり、より楽しめるものになるだろう。
昨日は、帰宅時の定点観測で23℃、今日は25℃と少し下がった気温が上がってきた。明日はまた暑くなるらしい。最近は傾向的には天気予報は当たる。
日記のタイトルはできるだけ同じにならないようにと思って、最近は更新日記検索をすることが多い。メモ代わりの日記なので、当然とは言え、自分で興味のある同じような傾向の内容になってしまう。自分自身、次第に飽きてきている。新しい傾向のネタを探したいものだが・・・
本の解剖学のⅠ、Ⅱを一応読み終えたのだが、載っている本のうち、読んだことのあるのは約160作品中、5作品だった。「偶然と必然」、「金閣寺」、「仮面の告白」、「主体性の進化論」、「山月記」。3.1%。人の読む本というのはなかなか重ならない。千夜千冊でも読んだことのある本はほとんどないような気がする。これも一度チェックしてみよう。
1059夜のうち41夜が一致。約3.9%。もっと読んでいるかもしれないが、人間は忘れる動物である。[Added: 2005-09-17]
第26夜 『さらば愛しき女よ』レイモンド・チャンドラー 第53夜 『雪国』川端康成 第62夜 『ニューロマンサー』ウィリアム・ギブスン 第64夜 『城』フランツ・カフカ 第80夜 『時の声』J・G・バラード 第106夜 『Yの悲劇』エラリー・クイーン 第110夜 『華氏451度』レイ・ブラッドベリ 第117夜 『奇巌城』モーリス・ルブラン 第155夜 『ジーキル博士とハイド氏』ロバート・スティーブンソン 第300夜 『白鯨』上下 ハーマン・メルヴィル 第312夜 『サラダ記念日』俵万智 第317夜 『悲しき熱帯』レヴィ・ストロース 第324夜 『ガリヴァ旅行記』ジョナサン・スウィフト 第363夜 『マルタの鷹』ダシール・ハメット 第367夜 『徒然草』吉田兼好 第380夜 『吸血鬼ドラキュラ』ブラム・ストーカー 第389夜 『十五少年漂流記』ジュール・ヴェルヌ 第426夜 『フランダースの犬』ヴィーダ 第428夜 『地球幼年期の終わり』アーサー・C・クラーク 第438夜 『水滸伝』楊定見・施耐庵・羅貫中 第452夜 『心の社会』マーヴィン・ミンスキー 第465夜 『ライ麦畑でつかまえて』J.D.サリンジャー 第479夜 『デミアン』ヘルマン・ヘッセ 第485夜 『檸檬』梶井基次郎 第509夜 『異邦人』アルベール・カミュ 第516夜 『ピノッキオの冒険』C・コッローディ 第534夜 『砂の女』安部公房 第538夜 『地球の長い午後』ブライアン・オールディス 第545夜 『知の考古学』ミシェル・フーコー 第560夜 『野獣死すべし』大藪春彦 第563夜 『フランケンシュタイン』メアリー・シェリー 第583夜 『草枕』夏目漱石 第600夜 『リア王』ウィリアム・シェイクスピア 第611夜 『ハックルベリイ・フィンの冒険』マーク・トウェイン 第649夜 『北回帰線』ヘンリー・ミラー 第714夜 『テクストの快楽』ロラン・バルト 第0883夜 『ヴァリス』フィリップ・K・ディック 第0900夜 『銀河鉄道の夜』宮沢賢治 第0940夜 『サンクチュアリ』ウィリアム・フォークナー 第1001夜 『エレガントな宇宙』ブライアン・グリーン 第1033夜 『音、沈黙と測りあえるほどに』武満徹
更新日記のカテゴリを整理するためにカテゴリを分類してみようと思い立った。書棚のガラスに80項目ぐらいのカテゴリをポストイットを使って貼り付けてみた。しばらく眺めていよう。
カテゴリを分類するいつものことながら、日記を書きながら、書き直している。テーマ(ネタ)を調べるに連れて、考え方はどんどん変化するし、以前考えていたことを再発見したりする。追加した場合やわかりやすく書き直したり、明らかにおかしい文章を修正した場合は[(Added|Revised): 日付]をつけている。
最近は、strikeタグを使って、一度書いたことを残しながら、字消し線で否定する方法も採用することにした。日記を書きながら一度アップロードしたものは消すわけにもいかないからである。ある条件下ではそのように考えたという記録でもある。divタグにwarningというclassを作って、変更した部分の背景を黄色で表示するという方法を組み合わせている。
HTML関係を調べていると、blockquoteとかinsやdelなどのタグがあったり、表現と内容の分離を理由にスタイルシートを使えとか、いろいろとある。結局どうするのということはあるのだが、テキスト処理でどうにでもなる問題なので、あまり気にしないで自由に書くことになる。DTIで本サイトを作成し始めた1998年当時、HTMLを書き始めたわけだけど、それ以来まじめに勉強したことはない。重要なことは自分に必要な表現ができるかどうかということとHTMLが読みやすいかどうかということである。tableタグは使わざるをえないが、HTMLが見辛くなることは間違いない。
へーっ、insを使うと下線付きで表示されるんだ。delタグを使って削除部分を書いてみよう。なるほど、消し線で表示される。strikeと一緒の効果がある。
この日記は複雑に入り組んだ迷路を構成しつつあり、月の記事数も100に迫るとマンスリーインデックスをもってしても一覧しにくい。大体人間が一度に覚えられるのは7つぐらいのことらしい。もっと違ったインターフェースが必要なのかもしれない。
更新日記の80項目程度のカテゴリは次第に増殖しつつあり、世界を現す一つ一つの言葉にまで細分化していく勢いである。最近はcategory.txtを更新するだけでよいので、増やすのは容易である。
更新日記がどのような話題を好み、その興味はどのような範囲に及び、各記事はどのように関連付けられるのか。カテゴリを整理することによって、多少は見えてくるかもしれない。
カテゴリを上位概念・下位概念、対立性、類似性等で整理してみたい。
米マサチューセッツ州、OpenDocumentとPDFにお墨付き - CNET Japanネタ。
Open Document Format関連では、OpenOffice.org 2.0が元になっているということで、これまで記事がいくつかある。PDFもODFに対応するということならさらにおもしろくなる。
ハリウッドに捧げる「DVD依存体質からの脱却のススメ」 - CNET Japanネタ。
映画は映画館で基本的に見るという習慣から未だに抜け切れていないので、DVDはたった2枚しか持っていない。レンタルビデオも最近はほとんど借りない。ゆっくり見る時間がないということもある。
DVDを捨てるほど持っていないので、EODに簡単に乗り換えられそうだが、ビニール盤のLPはまだ欲しいと思う。LPは400枚ばかりしか持っていないけど、このコレクションを増やすことができないのにはがっかりする。この広大なインターネットにもLPの情報は枯渇している。あっても高価では、存在しないのと同じである。
しかし、やはりここでも時代は変わるのである。古きよき習慣に囚われて愚痴を言う旧時代人を振り捨てながら、新しいインターネットを基盤とした文明が出現するのであろう。
スラッシュドット ジャパン | SMEがiTMSへ楽曲提供へネタ。Mora(音楽ダウンロード・メガサイト Mora [モーラ])を米国のConnectと同様に変えていくのかと思っていたけど・・・
iPod nano(アップル - iPod nano)が出たというので見に行ったら、iTunes 5があった。早速インストールしてみた。QuickTimeもバージョンが7に上がっている。
これまで不満だったデザイン面がすべて改善された。大きすぎるフォントサイズ、欠けたフォント、見えない価格の問題が解消され、適切なクールなデザインに収まった。
iPod miniはラインナップをはずれて、iPod nanoになってカラー化された。価格は2GBで2万ちょっとで、mini並みの価格設定。矢継ぎ早に打ち出される新製品、なかなかやるねえ。今日はニュースサイトも混み合っている。応答が悪くてイライラしてしまう。
iTunesの新しい機能への言及があるので、MYCOM PC WEB記事もリストアップしておこう。
iTunes 5からソースが「ライブラリ」の場合、検索バーがつく。「編集→検索バーを表示」で使えるようになる。単に「すべて」、「ミュージック」、「オーディオブック」、「ポッドキャスト」、「ビデオ」、「ブックレット」の絞込みができるだけの検索バーである。
残念ながら、この検索バーはあまり意味がない。なぜなら、「編集→ブラウザを表示」で、「ジャンル」、「アーティスト」、「アルバム」で表示する曲の絞込みができるからである。また、曲、アーティスト、アルバムを「検索」から検索可能である。
注目しているのは、検索バーの項目に「ビデオ」があることである。ミュージックビデオもあるだろうが、映画も当然ターゲットに入るのだろうと思う。
「フォルダを使ったプレイリストの分類・整理が可能になった」と記事には書いてあるのだが、これは意味がわからない。iPodを使う場合の話かもしれないが・・・
iTunesの最新版に問題頻発--ユーザーの間で混乱と怒り - CNET Japanネタ。
iTunes 5には問題があるらしい。iPodユーザーは特に注意したほうがよい。
マイクロソフトは何をやっているのか。ようやく少し見えた。
Xbox 360、日本の販売価格は3万7900円に--12月10日発売 - CNET Japanネタ。
高いと見るか、安いと見るか。どちらとも言えない。PCとしてコストパフォーマンスは高いのだろうか。当面、PCとして動くわけではないので、ゲーマーではないユーザーにとっては評価が難しいかも。
結局、ゲームマシンがPCの性能を凌駕することはないというのが予想である。長期的には当然のことであるが、来年がどうなるかについては、PS3を拝見してから結論を出そう。[Revised: 2005-09-18]
米マイクロソフト、次世代デザインツール「Expression」提供へ - nikkeibp.jp - 注目のニュースネタ。
今週はマイクロソフトウィークかもしれない。
ビル・ゲイツ、グーグルを語る - CNET Japanネタ。
デスクトップはどう変貌していくのか。もうそれほど変わりそうもない。それはマイクロソフトにとって危機であるかもしれない。デスクトップのメタファーは時代遅れというか、ほとんど完成した。これからは実世界指向インターフェース(モバイル&センシング・コンピューティング)か、ロボットだろう(^^;)
情報は編集して知識化しなければ役に立たない。編集作業は人間がやらねば意味がない。編集結果は人間が利用しなければまた意味がない。情報の収集部分はすでに素晴らしいレベルに到達している。やることはまだ何百年分いろいろあるにしてもこの調子ですすめばオーケーだ。しかし、個人的には情報は集めすぎてもないのと同じである。それを忘れないことだ。人間の持つ生物学的限界を越えることはできない。
マイクロソフト、Macやウェブ用のアプリケーション開発ツールなどを発表 - CNET Japanネタ。
また、お疲れ気味なのに日付変更線を跨いでしまった。様々な仕組みが登場するのだが、スクリプト言語との関係はどうなるのだろう。XAML、JavaScript、Dynamic HTMLは当然登場するようだが、XAMLとGUIを結び付けるランタイムが出てくるらしい。ガジェットはそれと関係があるのか?
Xbox.com :: Xbox 360の情報からXbox 360を使うために必要な費用を算出してみた。本体の価格は39795円なのだが、本体とはどの範囲なのか、ホームページからは本体からリムーバブルなユニットのうち、ハードディスク20GB、メモリユニット64MB1個(2個接続可能)は標準添付のように見える。それ以外に最低必要なもの、コントローラー、リモコン、AVケーブルは希望小売価格が付いており、別売のようだ。お節介でまとめてみた(^^;)
構成要素 | 価格(円) |
---|---|
本体(20GBHDD、64MBメモリーユニット含む) | |
コントローラー | 3675 |
ユニバーサル メディア リモコン | 2625 |
D 端子 HD AV ケーブル | 3675 |
計 |
コントローラーにワイヤレスを使うと充電が必要になるのでその他オプションが必要でかなり高くなり、AVケーブルをS端子接続で普通のテレビにつなぐなら、1000円ぐらい下がる。
CNET Japanの記事を見直してみると、基本パッケージがあり、本体価格というのが基本パッケージの価格であれば、米国とほぼ同じと言えるだろう。もう一度整理(^^;)
Xbox 360は3万7900円で12月10日に発売,来年1月末までに約20タイトルを予定 - デジタル家電 - Tech-On!の記事には「20Gバイトのハード・ディスク装置(HDD)を搭載したモデルで,コントローラやリモコン,Ethernetケーブル,AVケーブルなどを同梱する」と明確に書かれているので、39795円というのは基本パッケージの価格というのが結論。問題はコントローラーの選択とどのテレビに接続するのかということにある。やはり米国と同様コアシステムが必要と思われる。
項目 | 米国価格($) | Xbox 360 | Core System | 日本価格(円) | 基本パッケージ |
---|---|---|---|---|---|
パッケージ | 399.99 | 299.99 | 39795 | ||
Memory Unit (64 MB) | 39.99 | 39.99 | 39.99 | 3360 | 3360 |
Hard Drive (20 GB) | 99.99 | 99.99 | 10999 | ||
Controller | 39.99 | 39.99 | 3625 | ||
Wireless Controller | 49.99 | 49.99 | 4725 | 4725 | |
Play and Charge Kit | 19.99 | 2100 | Rechargeable Battery Pack | 11.99 | 1365 |
Media Remote | ? | ? | |||
Universal Media Remote | 29.99 | 2625 | |||
Headset | 19.99 | 19.99 | 2625 | ||
D 端子 HD AV ケーブル | 3675 | 3675 | |||
Component HD AV Cable | 39.99 | 39.99 | 3675 | ||
Composite AV Cable | ? | ||||
S-Video AV Cable (U.S. only) | 29.99 | 2625 | |||
VGA HD AV Cable | 39.99 | 3675 | |||
Ethernet Connectivity Cable | ? | ? | |||
Wireless Networking Adapter | 99.99 | 8925 | |||
Faceplate | 19.99 | 2100 | |||
(現在の為替レートは1$=110円、20GBHDDの日本価格は未公表なので換算した数値。"?"の価格は日米とも未公表。)
マイクロソフトが直面する10年越しの「悪夢のシナリオ」 - CNET Japanネタ。
デスクトップにいまさらしがみついても仕方がない。デスクトップとWebとの融合というマイクロソフトの初期のアイデアが今や現実化してマイクロソフト自身を脅かしている。セキュリティという足枷に囚われている間に。
「グーグルはマイクロソフトの脅威となるか」--ウェブで議論白熱 - CNET Japanネタ。
グーグルはマイクロソフトの助け舟かもしれない。グーグルはInternet ExplorerやWindowsデスクトップ上で動くアプリケーションに過ぎないということもできる。むしろ、Windowsのプラットフォームに共生している存在である。Windowsを補完しているのだ。
真の脅威はLinuxである。その上では、OpenOffice.orgやFirefoxが動くのである。動かないのはGoogle Desktop Searchである。今のところ、グーグルはマイクロソフトの味方である。
デスクトップがすべてではないのと同様、Webがすべてになることはない。個人の情報や個人が作成・収集した情報はデスクトップに保持される。けっしてWeb(他人の管理下)に流出させることはない。今日はグーグルのPicasaという画像管理アプリケーションをインストールしてみた。デザインもよい。早速デスクトップの画像データベースが出来上がったみたいだ。存在を知らなかった画像も大量にリストアップされている。グーグルはWindowsデスクトップをセンス良く再定義しつつある。ただ、これが無料なんだから大歓迎である(^^)v グーグルがOfficeアプリケーションを作り始めると気をつけないといけない、というか、喜ばなくてはならないかな・・・
Google's Picasaデスクトップの機能をネットワークが吸い取る---MicrosoftがGoogleを恐れる理由:IT Proネタ。同じような記事が頻出する感じだが。
ローカルの意味なんだが、当然のことながらパーソナルとオフィスは区別して考える必要があることを指摘しておこう。今後は、家庭内LANにサーバーを設置して、セキュリティを確保しながら外部からアクセスできるようしたいというニーズは高まると思う。オフィスにおいても同様だが、セキュリティの要請によって、限定された実施に留まるだろう。このような観点からはローカルはデスクトップから拡張された概念になっていくだろう。パーソナルサーバーという概念が登場するはずである。それはクラスターやグリッドの技術とも関連が出てきて、コンピュータの利用の仕方は様変わりしていく可能性もある。ネットワークがコンピュータになる。デスクトップの機能をネットワークが吸い取るというよりはネットワークそのものがデスクトップになったりするわけだ。今から分散コンピューティングを勉強しておくとよいかもしれない。
マイクロソフトがOSでシェアを維持するためには、さらに使いやすく高度な環境を低価格で提供するしかない。ソフトウェアはいずれほとんどがフリーになってしまう。プラットフォームに直結する部分のソフトウェアの提供やサービスしかビジネスにならなくなる。
「音楽配信発のビッグアーティストを生み出したい」--丸山茂雄氏の挑戦 - CNET Japanネタ。
僕も古い世代に属していることがわかった。確認するまでもないか(^^;)
iTMSの話題に続いて、もっとすごい音楽配信の話題。もっとも音楽データの配信ではないのだが。音楽をデパートで売るのか、専門ショップで売るのか、アーティストが売るのか。iTMSは品揃えがすべて、既にショップでは買えないようなものを見つけて買う場合には特に有用である。最新作をどう売るのかの見本はこちらである。
Miles DavisのAURAをDVD-2910で聴きながら、Becky!で受信したメールをチェックしていると、めずらしくHerbie Hancock Possibilitiesとあるのに気が付いた。herbiehancock.comからのニューズレターである。開くと、HTMLでメールは受信するように設定しているので目を引くオレンジ色のアルバムカバーが表示される。これをクリックすると、herbiehancock.comをブラウザが開く。プロモーションビデオや視聴用の曲目リスト、メディア評へのリンクが整然と並べられている。カルロス・サンタナのギターに始まり、スティングのボーカルに終わるビデオを試聴する。想像を超える顔合わせだ。これは買い。しかし、買うのはCDではなくて、DVDにしようと思う。演奏だけでなくビデオの質も高い。もうしばらく待つ必要がある。
herbiehancock.comからのニューズレタービクター、音楽配信の音質を向上させる「net K2」~着うたにも適用ネタ。
高音質配信、高音質再生は当然の流れ。CDに音質が劣るのでは、すべての音楽ファンが満足するとは考えにくい。音質が向上した場合に対応できるタワーレコード+ナップスターの音楽配信の考え方も興味深い。
自宅のPCのOfficeとしてOpenOffice.org 2.0βをインストールしているが、「実践実用Perl」執筆当時、大変お世話になったWriterとご無沙汰である。娘にOOoをインストールしたデザインが洒落たIIYAMAのノートを譲ったが、学校のWordを使う宿題を印刷したりするときに同じイメージにならなくて困ったりしているようだ。実際のところ、Wordが使いやすいワープロと感じたことはないし、Writerも日本語を取り扱うワープロとしてはまだまだという感じもする。行におけるフォントの配置が乱れると感じることが多いし、Wordと同様、自在にコントロールしにくいからである。これは固定長フォントとプロポーショナルフォントの取り扱いに関係があるのかもしれない。ただ、単に使い方が悪いせいかもしれない。慣れのせいかもしれない。まだ、使い方のノウハウを含めて日本語が馴染むレベルには到達していないのではと思う。
しかし、新しい顔ぶれ、Base、Drawが加わり、OpenOffice.orgの迫力が増してきた。CalcやImpressも使ったことがあるが、それなりに使える。Impressは図版を作るのに執筆に使った。PowerPointとの互換性はもう一つの感じはあるが、素晴らしいものである。BaseやDrawも使ってみたいと思う。このような高機能なアプリケーションを無料で使わせてもらえるのだから、不平を言うとバチが当たるかもしれない(^^;)
OpenOffice.orgとスクリプト言語との関係もこれから重要になるのではと思うし、今後の展開に期待している。OpenDocument Formatを通しての関連性は当然出てくるだろう。これをスクリプト言語におけるOOo効果と呼ぼう。スクリプト言語の世界がデスクトップに向かってさらに大きく広がっていくだろう。
ITmediaのメールにOpenOffice.org 2.0の記事が出ているので覗いてみたら、特集記事がいろいろとあるので最近の記事へのリンクを作ってみた。
japan.linux.com | オフィスソフト間の整合性を妨げるものはマクロネタ。
Pythonがudk: Python-UNO bridgeを持つことは既によく知られている。udk: OOo scripting framework and pythonにあるようなダイナミックなスクリプトがOpenOffice.orgで動くようになる。
PerlにはスクリプトからOpenOffice.orgの文書を生成するためのOpenOffice-OODocというモジュールがある。CPANからPXPerlにインストール可能だった。
TSNETネタだけど、OpenOffice2.0β2をVine Linux 3.0にインストールするのは1.1.2のときのようにInstallerがないので、どうしてよいのかわからなかったのだが、初めてrpmをコマンドラインで使った。解凍したディレクトリで、
rpm -ivh RPMS/*.rpm
日付変更線を越えてしまったか(^^;)
スクリプトをUTF-8で書き、入出力もUTF-8にすれば、基本的にはjperlでShift_JISを取り扱うのと同じようにできるのだろうと考えていたのだが、現実はそうではないようだ。いまさらなんだが、少しずつ、思い込みを具体的に確かめていこう。テキスト処理において基本的で重要な正規表現の問題。UTF-8でスクリプトを書いたとして、正規表現パターンにどのようにUTF-8文字はマッチするのか。
$str = "ソレイユabcd"; @chars = ($str =~ /(.)/g); foreach (@chars){ print $_, "\t", length($_), "\n"; }
上記のスクリプトをUTF-8で書いて、Perl5.8で実行すると、abcdの文字列部分はそのまま出力されるが、最初の「ソレイユ」というカタカナ部分は1バイト長の12個の文字化けとなって出力される。Shift_JISで同様に書いて、jperlで実行すると、カタカナ一つ一つの文字は分離されて文字化けすることはない。"."は一つの文字にマッチするはずなので、結論として上記のスクリプトの文字列はバイト列として認識されているということである。
それで、結局、encodingを使ってみようということになる。まず、Shift_JIS文字列で書き直して、use encoding 'Shift_JIS';を最初の行に追加しよう。Perl5.8のjperl化のお呪いだ。カタカナの文字単位で"."はマッチする。ただし、jperlと違うのは、lengthの出力は1となることだ。Perl5.8ではlengthは文字数を出力する。jperlはバイト数を出力する。
さあ、UTF-8で書いたスクリプトに戻ろう。use encoding 'UTF-8';と最初に加えよう。OKだ。カタカナ文字は一つずつマッチする。lengthはやはり文字数を出力する。UTF-8でスクリプトを書く場合にも、encodingの指定は必要ということだ。UTF-8で書いてもスクリプトはシンプルにはならない。
結論。Windowsでは、Shift_JISでスクリプトを書こう。use encoding 'Shift_JIS';をスタート地点とする。遠回りをして元に戻ってきてしまった(^^;)多国語を取り扱う場合は、集合の大きなUTF-8をベースにしたほうがよいと思われるが、Catalystで経験したブラウザの問題もあるので、この問題はもう少し先送りしておこう。当面、jperlスクリプトをPerl5.8スクリプトに移植する場合の注意点・問題点を考えていく。CatalystのモジュールをShift_JIS文字コードに対応させるために必要な要素を抽出するための作業になるはずだ。
「実践実用Perl」のjuri_encodeサブルーチンはマッチした文字のバイト数をlengthで判定して動作を変化させているので、Perl5.8では動かない。次回はこの問題を片付けよう。
「実践実用Perl」はjperlだけで書くか、最後の最後でPerl5.8も考慮するかどうか迷ったこともあったが、Perl5.8の検討を始めると泥沼に入りそうだったので、結局、jperl一本に絞った。これは正解だったと思う。libwwwとlibnetのモジュール群が動けばインターネットプログラミングは自由自在である。後はテキスト処理だ。Shift_JIS環境のテキスト処理にjperlは大変有効なのである。Perl5.8のパフォーマンスはjperl×1.05程度であろう。苦労して使うだけの動機付けにはまだ弱いと判断したのである。
さて、それでも時代は変わる。jperlの有効性について変化はないが、Perlの未来はPerl5.10/Perl6/Parrotにある。Perl5.8.1以降、jperlのノウハウが取り込まれ、Shift_JIS文字コードの取り扱いも問題がなくなったと言われる。成熟したjperlをメインで使いながら、Perl5.8の使い方を研究することは有意義であろう。Perl5.8はjperlに代わり得るのか。検証していこう。
Perl5.8については「プログラミングPerl」はまだないが、Perl5.6用の第3版(2000年、翻訳2002年)がほとんど適用できると考えてよい。おそらく、Unicodeやencodingの文字コード関連以外はそのままだろう。これは文字通り予想である。しばらく検証を続けていけばそうではないという結論になるかもしれない。2004年7月に出たPerl5.8.4までは非互換性の仕様が導入され続けているからである。また、テキスト処理を行うモジュールは鬼門である。モジュールにはUTF-8でデータを渡せば問題ないと言われるが、これはおそらくシングルバイトの文字の場合だけであろう。マルチバイトでは問題が出る可能性がある。まあ、これらも予想である。頭の中で縺れている様々な状況で聞きかじった知識の断片をパズルを解くように並べて、一貫性のある実用的な知識にまとめる必要がある。
さて、今日は、Perl5.8で文字列のバイト数を数える方法を調べよう。jperlならlengthでバイト数を測定できるが、Perl5.8では文字数になる。シングルバイト文字なら同じ値が得られるがマルチバイト文字では結果が異なる。
結論は、use bytesを宣言して、bytes::lengthで測定すればよいということになる。use bytesはレキシカルスコープで(例えばブロック内で)動作するプラグマモジュールである。機能は読んで字の如しである。スクリプトの先頭のほうで、use bytesを宣言してしまうと、その影響はスクリプト全体に及ぶので、マルチバイト文字のencodingの宣言があったとしても無効になり、文字列はバイト列として取り扱われる。以下のスクリプトはUTF-8で書いて、Perl5.8で実行する。[Revised: 2005-09-03]
use encoding 'UTF-8'; $str = "ソレイユabcd"; @chars = ($str =~ /(.)/g); foreach (@chars){ print $_,"\t",do{use bytes;bytes::length($_)},"\n"; }
実行結果は次の通りである。UTF-8のカタカナは3バイトである。
>perl -w test_u.pl ソ 3 レ 3 イ 3 ユ 3 a 1 b 1 c 1 d 1 >Exit code: 0 Time: 0.213
PIXIGREG.COMへ接続できなくなったので、PXPerlが利用できなくなっている。ParrotやPugsの他のWin32ディストリビューションには、Jonathan @ JWCS.NET :: Perl 6 / Parrotがある。Pugsを使えば、Perl6のプログラミングを楽しめそうだが、ライブラリのLWPのフォルダにはまだSimple.pmが入っているだけだ。
Perl5.8へjperlで書いたrss2html.cgiの移植を検討した。TSNETでZazelさんに指導してもらって、ようやくPerl5.8が見えてきたと思ったのだが・・・
基本的な戦略は、use encoding 'Shift_JIS'をベースにすることと、juri_encodeの文字のバイト数の判定にuse bytes;bytes::length()を使うことでスタートしたのだが、もう一つのポイントは、LWP::UserAgentのgetメソッドで取得したデータをutf8で格納することだった。jperlでは当然のことながらShift_JISにすべて変換して格納している。
use encoding '特定のエンコーディング'は、すべてのリテラルを特定のエンコーディングからutf8へ内部的に変換する。それから、STDIN、STDOUTのPerlIOレイヤーを特定のエンコーディングに変更する。問題は他のファイルハンドルによる入出力やLWP::UserAgentのgetメソッドなどからの入力の取り扱いである。これらは、encodingプラグマによる影響を受けない。従って、これらは自前で処理をする。jperl用のrss2html.cgiの場合は、RSSファイルの文字コードをShift_JISコードに変換して格納していたのだが、Perl5.8ではutf8に変換して格納する必要がある。
HTMLフォームからブラウザが受け取ったデータはURLエンコードされて、CGIに渡され、CGIはデコードして出力する。気になっていろいろ試してみたのだが、CGIが受け取ってデコードしたデータをencodingプラグマ下ではスクリプト中で思うように制御できない。まだ、よく理解できていないのか(^^;)
encodingプラグマ下、rss2html.cgiのjperlからPerl5.8への移植は、Zazel氏、Bruce.氏、極悪氏のご協力を得ながら、紆余曲折を経て一応完了した。ありがとうございました。文字コード変換モジュールはUnicode::JapaneseモジュールからEncodeモジュールへ変更した。juri_encodeサブルーチンでmemol_edit.cgiに渡す変数をUTF-8からShift_JISに変換する必要があるのだが、なぜかUnicode::Japaneseモジュールではうまくいかなかった。
以上が、移植内容のすべてである。実際のスクリプトを載せておこう。しかし、jperlで実行する場合には1秒で済む処理(CNET JapanのRSSを読んで、HTMLに変換して表示する)に9秒を要した(ActivePerlでもPXPerlでも同じ、バージョンは5.8.7)。この結果、encodingプラグマは使わずに、UTF-8でスクリプトを書く方向を試してみることに方向転換しようと思う。ぐるぐる回っているようだが、確認する価値はある作業である。
rss2html.cgi (use encoding 'sjis'版)
#!/PXPerl/bin/perl.exe require 'cgi-lib.pl'; use LWP; use encoding "Shift_JIS"; use Encode; $btime = time;# 処理開始時間取得 @header = ( 'UserAgent' => "libwww-perl/$LWP::VERSION", ); $browser = LWP::UserAgent->new; # 環境変数の取得 $docroot = $ENV{'DOCROOT'};# ローカル HTTP サーバーのドキュメントルート $cgidir = $ENV{'CGIDIR'};# ローカル HTTP サーバーの CGI ディレクトリ $mp = "QT"; # RSS URL データの取得 &ReadParse(*in); if($in{'rss'}){ # CGI で URL を取得する $getfile = $in{'rss'}; }elsif($ARGV[0]){ # コマンドラインから URL を取得する $getfile = $ARGV[0]; }else{ print "RSS URL データが存在しない。\n"; exit;# 終了する } # CGI 最初の部分の出力 print <<HEADER; Content-type: text/html <HTML> <HEAD> <TITLE>RSS Reader</TITLE> <META HTTP-EQUIV=\"Content-Type\" CONTENT=\"text/html; charset=Shift_JIS\"> <LINK REL=\"STYLESHEET\" TYPE=\"text/css\" HREF=\"/mystyle.css\"> </HEAD> <BODY> <div class=\"emph\">ニュース</div> HEADER # RSS URL の RSS ファイルを取得 unless($res = $browser->get($getfile,@header)){ print "<p>LWP::UserAgentのget関数がundef値を返しました。</p></BODY></HTML>\n"; exit; } $content = $res->content;# UserAgentのget関数の戻り値 # エンコーディングの取得 if($content =~ /<\?xml +version="1.0" +encoding="([^"]+)" *\?>/){ $encoding = $1;$enc = $encoding; $encoding =~ s/^Shift_*JIS$/sjis/i; # シフト JIS $encoding =~ s/^euc-*j*p*$/euc/i; # EUC-JP $encoding =~ s/^utf-*8$/utf8/i; # UTF-8 $encoding =~ s/^ISO-8859-1$/ascii/i;# ISO-8859-1 $encoding =~ s/^us-ascii$/ascii/i; # US-ASCII $encoding =~ s/^ISO-2022-JP$/jis/i; # JIS } if($encoding eq ""){ # エンコーディング情報のないものは、UTF-8 とする # 実際のRSSファイルにはXMLを宣言する行、<?xml...?>自体がないものもある $encoding = "utf8";$enc = "None"; } # エンコーディング情報をもとに、UTF-8文字コードに変換 $content = decode($encoding, $content); # RSS ファイルの解析 # 解析用の前処理: 文字列データから行頭行末の空白を取り除き、改行文字を削除する $content =~ s/[ \t]*[\r\n]+[ \t]*//g; # 終了タグの後に改行を入れる $content =~ s/(<\/[^>]+>)/$1\n/g; # 主要素の開始タグの後に改行を入れ、要素タグのみの行を作る $content =~ s/(<channel[^>]*>)/$1\n/; $content =~ s/(<image[^>]*>)/$1\n/g; $content =~ s/(<item[^>]*>)/$1\n/g; # データ文字列を改行で分割して、行単位のデータで配列に格納する @content = split(/\n+/, $content); # データを行単位で処理する。 foreach $line (@content){ # RSS バージョンの取得 if($line =~ /<rss.+?version\s*=\s*['"](.+?)['"]/i){ # Rich Site Summary/Really Simple Syndicationのバージョン取得 $ver = $1; }elsif($line =~ /xmlns\s*=\s*"http:\/\/purl\.org\/rss\/(.+?)\/"/){ # RDF Site Summary 1.0 のバージョンの取得 $ver = $1; }elsif($line =~ /xmlns\s*=\s*"http:\/\/my\.netscape\.com\/rdf\/simple\/0\.9\/"/){ # RDF Site Summary 0.9 のバージョンの取得 $ver = "0.9"; } # rdf:RDF か rss のルート要素からXML 名前空間のリストを得る if($line =~ /(<rdf:RDF|<rss)/i){ @nss = ($line =~ /(xmlns:?\w*?\s*=\s*["'].+?["'])/ig); } # CDATA セクションの処理 <![CDATA[・・・]]> の除去と実体参照エンコード if($line =~ /<[^>]+><!\[CDATA\[/i && $line !~ /\]\]><\/[^>]+>/){ $line =~ s/<[^>]+><!\[CDATA\[//i; $cdatasw = 1; $cdata = $line; }elsif($cdatasw == 1 && $line !~ /\]\]><\/[^>]+>/){ $line =~ s/<!\[CDATA\[//gi; $line =~ s/\]\]>//g; $cdata .= $line; }elsif($cdatasw == 1 && $line =~ /\]\]><\/[^>]+>/){ $line =~ s/\]\]><\/([^>]+)>//; $prop = $1; $cdata .= $line; $line = "<$prop>" . &entities_encode($cdata) . "</$prop>"; $cdatasw = 0;$cdata = ""; } # channel、item、image 要素開始の判定 if($line =~ /<channel/){ $csw = 1; }elsif($line =~ /<item( |>)/){ $isw = 1;$csw = 0; }elsif($line =~ /<image/){ $imgsw = 1;$csw = 0; } # 要素データを主要素毎に要素名をキーとして取得 if(($buff = $line) =~ s/<\/?([^>]+)>//g){ # channel 要素の格納 if($csw == 1){ $channel{$1} = $buff; } # image 要素の格納 if($imgsw == 1){ $image{$1} = $buff; } # item 要素の格納 if($isw == 1){ if($1 eq 'guid'){ # RSS 2.0 の guid 要素は、isPermaLink属性が true の場合には URL if($line =~ /isPermaLink\s*=\s*['"]true['"]/i){ $item{'guid'} = $buff; } }else{ $item{$1} = $buff; } } } # enclosureタグからURL属性を取得する if($line =~ /<enclosure +url="([^"]+)"[^>]+>/){ $item{'enclosure_url'} = $1; } # channel 要素終了の判定 if($csw == 1 && $line =~ /<\/channel>/){ $csw = 0;# RSS 1.0 } # image 要素終了の判定 if($imgsw == 1 && $line =~ /<\/image>/){ $imgsw = 0; } # item 要素終了の判定と item ごとのデータの格納 if($isw == 1 && $line =~ /<\/item>/){ # item 日付要素の選択 # Dublin Core モジュールの dc:date 要素があれば、 if($item{'dc:date'}){ $item{'date'} = $item{'dc:date'}; $elms{'dc:date'} = 1;# マッチした要素の収集 # RSS 2.0 の pubDate 要素があれば、 }elsif($item{'pubDate'}){ $item{'date'} = $item{'pubDate'}; $elms{'pubDate'} = 1; } # 表示要素追加時チェック部(1) push(@items, join("\t",$item{'date'},$item{'link'},$item{'guid'},$item{'title'},$item{'dc:description'},$item{'description'},$item{'content:encoded'},$item{'dc:subject'},$item{'category'},$item{'dc:creator'},$item{'author'},$item{'slash:department'},$item{'prism:publicationName'},$item{'enclosure_url'})); $isw = 0;%item = (); } } # channel 要素の description 要素を実体参照デコードしておく $channel{'description'} = &entities_decode($channel{'description'}); # 実体参照への変換が二重に行われている場合の対応 if($channel{'description'} =~ /&[a-z0-9]{2};/){ $channel{'description'} = &entities_decode($channel{'description'}); } # image 要素データがある場合とない場合に分けて HTML 出力の仕方を指定 # image 要素データがある場合には、channel 主要素の title 要素 if($image{'url'}){ print "<dl><dt><a href=\"",$channel{'link'},"\" target=\"main\">", $channel{'title'}, "</a><dd><p><a href=\"",$image{'link'},"\" target=\"main\"><img src=\"",$image{'url'},"\"></a> ",$channel{'description'},"</p></dl>\n"; }else{ print "<dl><dt><a href=\"",$channel{'link'},"\" target=\"main\">", $channel{'title'}, "</a><dd><p>",$channel{'description'},"</p></dl>\n"; } # item 要素データを HTML 表に変換して出力 print "<table border=0>\n"; # item ごとに表示要素を処理する foreach $item (@items){ # 表示要素追加時チェック部(2) ($date,$ilink,$iguid,$ititle,$idescription,$rdescription,$cdescription,$isubject,$rcategory,$icreator,$rauthor,$sdepartment,$prismpubname,$enclosure_url) = split(/\t/,$item); print "<tr bgcolor=\"#eeeeee\">"; # タイトルとリンクの処理 if($ititle){ $title = &entities_decode($ititle); # 実体参照への変換が二重に行われている場合の対応 if($title =~ /&[a-z0-9]{2};/){ $title = &entities_decode($title); } # タイトルにリンクがある場合は、別にリンクする if($title =~ s/(<a.+?)>(.+?)(<\/a>)/$2/i){ $titlelink = " -> $1 target=\"main\">LINK$3"; }else{ $titlelink = ""; } # RDF/RSS の item 主要素の link 要素の場合 if($ilink){ print "<td><font color=\"#000000\"><a href=\"", $ilink, "\" target=\"main\">", $title, "</a></font>$titlelink</td>"; $elms{'link'} = 1; # RSS 2.0 の guid 要素の場合 }elsif($iguid){ print "<td><font color=\"#000000\"><a href=\"", $iguid, "\" target=\"main\">", $title, "</a></font>$titlelink</td>"; $elms{'guid'} = 1; }else{ print "<td><font color=\"#000000\">$title</font>$titlelink</td>"; } $elms{'title'} = 1; }else{ # タイトルがない場合は、リンク文字列にリンクしてタイトルに表示する # RDF/RSS の item 主要素の link 要素の場合 if($ilink){ if($ilink !~ /http:/){ # PATH のみの URL の場合、 ($linkhead = $channel{'link'}) =~ s/^(http:\/\/.+?\/)(~\w+?\/)*.*$/$1$2/; # channel のリンクから BASE URL を取り出し、 $ilink = $linkhead . $ilink; # PATH に URL を付加する。 } print "<td><font color=\"#000000\"><a href=\"", $ilink, "\" target=\"main\">", $ilink, "</a></font></td>"; $elms{'link'} = 1; # RSS 2.0 の guid 要素の場合 }elsif($iguid){ print "<td><font color=\"#000000\"><a href=\"", $iguid, "\" target=\"main\">", $iguid, "</a></font></td>"; $elms{'guid'} = 1; } } # 表示要素追加時チェック部(3) # item 記事要素に相当する要素の処理 if($idescription){ # Dublin Core モジュールの dc:description 要素 $description = &entities_decode($idescription); $elms{'dc:description'} = 1; }elsif($rdescription){ # RDF/RSS の item 主要素の description 要素 $description = &entities_decode($rdescription); $elms{'description'} = 1; }elsif($cdescription){ # content モジュールの content:encoded 要素 $description = &entities_decode($cdescription); $elms{'content:encoded'} = 1; } # 実体参照への変換が二重に行われている場合の対応 if($description =~ /&[a-z0-9]{2};/){ $description = &entities_decode($description); } # item 記事相当要素の出力 if($description){ # HTML 表の表示が乱れるため、<p>タグは除去、</p>タグを<br>に置換して出力 $description =~ s/<p.*?>//ig; $description =~ s/<\/p>/<br>/ig; print "<td>",$description,"</td>\n";$description = ""; } # item 日付要素 if($date){ print "<td>",$date,"</td>\n"; } # item 製作者要素 if($icreator){ # Dublin Core モジュールの dc:creator 要素 print "<td>",$icreator,"</td>\n"; $elms{'dc:creator'} = 1; }elsif($author){ # RSS 2.0 の item 主要素の author 要素 print "<td>",$author,"</td>\n"; $elms{'author'} = 1; } # item カテゴリー要素 if($isubject){ $isubject = &entities_decode($isubject); if($isubject =~ /&[a-z0-9]{2};/){ $isubject = &entities_decode($isubject); } print "<td>",$isubject,"</td>\n"; $elms{'dc:subject'} = 1; }elsif($rcategory){ print "<td>",$rcategory,"</td>\n"; $elms{'category'} = 1; } # Slash モジュールの item 特殊分類要素 if($sdepartment){ $sdepartment = &entities_decode($sdepartment); print "<td>",$sdepartment,"</td>\n"; $elms{'slash:department'} = 1; } # PRISM モジュールの item 特殊分類要素 if($prismpubname){ print "<td>",$prismpubname,"</td>\n"; $elms{'prism:publicationName'} = 1; } # RSS 2.0のenclosureタグのurl属性 #<A HREF SRC="MyMovie.qtl"> Click Here for a QuickTimeMovie </A> #Important #For this to work, your Web server must be configured to associate #the .qtl file extension with the correct MIME type: #.qtl = application /x-quicktimeplayer #MyMovie.qtl #<?xml version="1.0"?> #<?quicktime type="application/x-quicktime-media-link"?> #<embed src="http://www.myserver.com/Movies/My.mov" /> if($enclosure_url){ if($enclosure_url !~ /\.mp3/i){ $count++; if($mp eq "QT"){ open(QT,"> qt${count}.qtl"); print QT "<?xml version=\"1.0\"?>\n"; print QT "<?quicktime type=\"application/x-quicktime-media-link\"?>\n"; print QT "<embed src=\"$enclosure_url\" autoplay=\"true\" />\n"; close(QT); print "<td><a href=\"./qt${count}.qtl\">Podcast</a></td>\n"; }elsif($mp eq "WM"){ open(WM,"> wm${count}.asx"); print WM "<ASX version=\"3.0\">\n"; print WM "<Entry>\n<Ref href=\"$enclosure_url\" />\n</Entry>\n</ASX>\n"; close(WM); print "<td><a href=\"./wm${count}.asx\">Podcast</a></td>\n"; } }else{ print "<td><a href=\"$enclosure_url\" target=\"status\">Podcast</a></td>\n"; } } # メモ作成用「メモる」システム CGI、memol_edit.cgiへのタイトルとリンク出力 if($ilink){ $ilink_encoding = &juri_encode($ilink); }elsif($iguid){ $ilink_encoding = &juri_encode($iguid); } $ititle_encoding = &juri_encode($ititle); print "<td><a href=\"$cgidir/memol_edit.cgi?url=$ilink_encoding&title=$ititle_encoding\" target=\"main\">メモ作成</a></td>\n"; } print "</tr></table>\n";# RSS ファイルの記事内容表出力終了 print "<hr>\n"; # 解析したRSSファイルの情報を表示する # エンコーディングの表示 print "エンコーディング: $enc<br><br>\n"; # 表示要素追加時チェック部(4) # RSS/モジュールとRSS要素の表を作成する foreach $elm (sort keys(%elms)){ if($elm !~ /:/){ $mod{$ver} .= $elm . "\t";# RSSバージョンデフォルト要素 }elsif($elm =~ /^dc:/){ $mod{'Dublin Core'} .= $elm . "\t";# Dublin Core モジュール要素 }elsif($elm =~ /^content:/){ $mod{'Content'} .= $elm . "\t";# Content モジュール要素 }elsif($elm =~ /^slash:/){ $mod{'Slash'} .= $elm . "\t";# Slash モジュール要素 }elsif($elm =~ /^prism:/){ $mod{'PRISM'} .= $elm . "\t";# PRISM モジュール要素 } } print "<table border=0><tr bgcolor=\"#eeeeee\"><th>RSS/モジュール</th><th>item 表示要素</th></tr>\n"; foreach $key (sort keys(%mod)){ print "<tr bgcolor=\"#eeeeee\"><td>$key</td><td>$mod{$key}</td></tr>\n"; } print "</table><br>\n"; # XML 名前空間のリストを表示 print "<table border=0><tr bgcolor=\"#eeeeee\"><th>XML 名前空間</th><tr>\n"; if(@nss){ foreach $ns (sort @nss){ print "<tr bgcolor=\"#eeeeee\"><td>$ns</td></tr>\n"; } }else{ print "<tr bgcolor=\"#eeeeee\"><td>None</td></tr>\n"; } print "</table><br>\n"; print "<hr>\n"; # 表示に要した秒数を計算して出力 $etime = time - $btime; print "表示に要した時間: $etime 秒<br>"; # HTML 出力終了 print "</BODY>\n</HTML>\n"; # サブルーチン # Jperl 用 URL エンコーディング sub juri_encode{ my($str) = @_; $str = encode("sjis",$str); $str =~ s/([^a-z0-9\-_.!*'\(\)~ ])/&blength($1) == 2 ? sprintf "%%%1s%1s%%%1s%1s", split("",unpack("H4", $1)) : sprintf "%%%02X", ord($1)/egi; $str =~ tr/ /+/; return $str; } sub blength{ my($s) = @_; use bytes; return bytes::length($s); } # マークアップ記号の実体参照デコード # 文字実体参照と数値実体参照の両方に対応 sub entities_decode{ my($str) = @_; $str =~ s/(<|<)/</g; $str =~ s/(>|>)/>/g; $str =~ s/('|')/'/g; $str =~ s/("|")/"/g; $str =~ s/(&|&)/&/g; return $str; } # マークアップ記号の実体参照エンコード sub entities_encode{ my($str) = @_; $str =~ s/&/&/g; $str =~ s/</</g; $str =~ s/>/>/g; $str =~ s/'/'/g; $str =~ s/"/"/g; return $str; }
cgi-lib.pl: Steven E. Brenner氏のcgi-lib.plの一部である。→ The cgi-lib.pl Home Page
sub ReadParse { local (*in) = @_ if @_; local ($i, $key, $val); # Read in text if (&MethGet) { $in = $ENV{'QUERY_STRING'}; } elsif (&MethPost) { read(STDIN,$in,$ENV{'CONTENT_LENGTH'}); } @in = split(/[&;]/,$in); foreach $i (0 .. $#in) { # Convert plus's to spaces $in[$i] =~ s/\+/ /g; # Split into key and value. ($key, $val) = split(/=/,$in[$i],2); # splits on the first =. # Convert %XX from hex numbers to alphanumeric $key =~ s/%(..)/pack("c",hex($1))/ge; $val =~ s/%(..)/pack("c",hex($1))/ge; # Associate key and value $in{$key} .= "\0" if (defined($in{$key})); # \0 is the multiple separator $in{$key} .= $val; } return scalar(@in); } # MethGet # Return true if this cgi call was using the GET request, false otherwise sub MethGet { return ($ENV{'REQUEST_METHOD'} eq "GET"); } # MethPost # Return true if this cgi call was using the POST request, false otherwise sub MethPost { return ($ENV{'REQUEST_METHOD'} eq "POST"); } 1; #return true
久しぶりにご質問をいただいた。Jcode.pmのインストールについてである。弾氏のサイト(Jcode.pm)には最新版の2.03しか置かれていない。この最新版には、以前のようにwin_install.plが同梱されていない。Makefile.PLを使っても、windows.hがないと言われて、単純にはxsがnmakeできないのでインストールに失敗してしまう(これは私に必要な知識がないだけだろうけど)。xsは使わなくてもよいので、適当にコピーする手はあるのだが、スマートではない。JcodeはCPANにあることを思い出して、そちらから0.88(search.cpan.org: Dan Kogai / Jcode-0.88)をダウンロードしていただくことにした。0.*の最終版である。2.03は基本的にはPerl5.8用なので、jperlにわざわざインストールする必要はないだろう。
「実践実用Perl」はインターネット実務検定協会で1級参考テキストとして掲載していただいた。インターネットはテキスト処理を適用する史上最大の対象なのである。Perlなどのスクリプト言語でインターネット上の情報を自在に加工して活用していただきたい。
use encoding "sjis"を使うと、rss2html.cgiで日本語サイトのRSS処理スピードが極端に落ちる現象が認められた。これに対処するために、encodingを使わずにUTF-8でスクリプトを書き、UTF-8のHTMLを出力するように変更すると、Perl5.8でも予想通りほぼjperl同等の性能が得られるようになった。しかし、他の「メモる」システムがShift_JISのHTMLを出力するため、CGI間あるいはフレーム間の整合性を取るためにはすべてを書き直す必要が出てくる。今のところ、この方法はUTF-8で取り扱うことにメリットがあるか、jperlで動かないモジュールを使いたい場面まで置いておこうという判断である。
もう一つの方法は出力をShift_JISにする方法。スクリプトはUTF-8で書いて、出力のみ、Shift_JISにする。use encoding "utf8", STDOUT => "sjis";としてみる。jperlで0~1秒で処理できるもの(CNET JapanのRSSを読んで、HTMLに変換して表示する)に10秒要する。残念ながら、use encoding "sjis"とほぼ同等と思われるパフォーマンスしか出ない。
他に、encodingは使わず、UTF-8でスクリプトは書き、Encodeモジュールで出力をいちいちShift_JISに変換してしまうという方法があるが、そんなにまでして使う必要はないと思って試していない。やはり、Perl5.8はUTF-8をベースに使うものなのだと思う。UTF-8でスクリプトを書き、Encodeモジュールを使って各種の文字コードを対象にテキスト処理をする見通しが得られたのは大きな収穫だった。この方法は、PerlをEUCで使ってきたUnixにおけるPerlの使用法と同じなのだと思う。Windowsの世界ではこれまで体験しにくかったのだが、Cygwin+Poderosaのおかげで何とかなりそうである。
ただし、WindowsのShift_JIS入出力環境下で、HTMLをUTF-8で運用できるかどうかの検証がまず必要だろう。Webブラウザはどのように動作するのだろう。このような基本的なことが書いてある本はない。encodingを使わなければ、URLエンコーディングはシンプルになるが、受け取り側の文字コードは意識する必要がある。受け取る側が文字コードを判定して変換できれば問題ないが、自動判定がすべて成功するとは限らないだろう。
日本語Windows上ですべてをUTF-8で統一すれば、基本的には、Shift_JIS入力で、UTF-8に変換して受け取り、出力はUTF-8のままということになるのだろう。
ちょっとした手違いで、DTIのページに一時的に戻します。よろしくお願いいたします。→ 「実践実用Perl」サポートページ
だいぶ前にメールが届いたのだけどそのままになっていた。ダウンロードしてみた。今回の表紙はかわいいラクダのぬいぐるみだ。毎度の楽しみである。冊子がまだ届かないなあ。サイトもインタビュー記事を掲載するなど充実してきている。
The Perl Review v2i0Perl Newsに、The Script Center Script Repository: Sample Perl Scriptsが出ていた。Win32::OLEモジュールを使う例が満載である。役に立つときがあるかもしれない。ローカルに起動したApacheでArrangeNoteのOLEオートメーションに続いて、Win32::Clipboardを使ったCGIが動くことを確認した。Windows上のローカルCGIでOLEを使う場合に参考になりそうだ。
Curtis "Ovid" Poe氏の10ページに及ぶ"Logic Programming in Perl"の記事が目を引いた。AI::Prologモジュールの紹介記事。
PS3に引っ掛けて、少しOpenGLの香りぐらい味わってみるかと、OpenGLのプログラミングをPerlでできないか探してみた。あっけなく動いた。
glut32.dllをC:\WINDOWS\SYSTEMにコピーして、ppmでOpenGL.ppdからPerlモジュールをネットワークインストールしただけ(Perl5.6とPerl5.8用のモジュールが準備されている)。demos.zipをダウンロードして、その中のスクリプトをコマンドラインからActivePerl5.8で動かす。noof.pl以外はすべて動いた。
心配していたけど、perl.perl6.compilerメーリングリストでアナウンスがあった。
Memories release, Maypole tutorial releaseネタ。
Simon Cozens氏のGod SchoolのRSS配信から。Maypoleも使ってみたいけど、Cygwinではうまくインストールできなかったような。Linuxマシンを動かすかな。・・・あれ、Linuxも同じ。Perlは5.8.2を使う。GDのインストールもこける。Simon Cozens氏のMemoriesのREADMEにあるモジュールの部分が"This is the hard part."になっているし、Maypoleのところには、good luckとある。しかし、こんなに複雑なものがよく作れるなと思う。もっとシンプルにならないものか(^^;)
perl.com: The State of the Onion 9ネタ。笑ってしまうが・・・Gloriaというのは奥さんの名前だ。PerlもGloriaという名前になっていたかもしれないのだ。どの登場人物が現実の誰に相当するのか当て嵌めてみるのは楽しいパズルだろう。
それで当然Perl 6の動向だが。
誰もやっていないことを手掛けているのは間違いないし、進歩していることも間違いないが、前人未到の地に到達するにはやはり後5年ぐらいは必要だろう。
「実践実用Perl」サポートサイトがようやく回復。DTIの推敲サイトも公式サイトに転送するように設定しなおした。
hTunesのページに置いているPodcast対応版rss2html.cgiを更新した。CDATAセクションの処理が不完全なケースにぶつかったので、バグフィックスした(バグというよりはロジックが足りないだけ^^;)。このCGIも200件近いRSSを処理して次第に完成の領域に近づいている。
最近はPodcastを含むRSSが多くなってきた。Podcastを含むRSS2件を推奨リストに加えた。
PHPのゼンドに、M・アンドリーセンなど大物が参加 - CNET Japanネタ。
これからのプログラミングはオープンなスクリプト言語の世界になる、と思っている。我田引水気味だが(^^;)
究極の検索ツールを追い求める米大学の取り組み - CNET Japanネタ。
究極の検索ツールをロジック指向で追い求めるのは虹を追いかけるようなものである。単純な検索は横に置いておいて、新しい知識や発見を生み出すような検索ツールが必要なのだ。GoogleのPageRankはそのような手法の一つである。よく閲覧される価値の高いページを上位に表示するという方法によって、それを実現した。大変有効な方法である。Google Desktop Searchは検索者個人によって選別された情報の集合から検索するので必要なものにマッチする可能性が高い。これも大変有効な方法である。
次のステップは知識を関連付け、使いやすく、取り出しやすく蓄積する仕組みを構築して運用することである。[Added: 2005-09-03]
新しいリンクだけ。
岡山で新幹線に乗る前に久しぶりにインターネットマガジン(2005年10月号)を手に取った。厚みが1/3ぐらいになったと思うけど、松岡正剛氏の名前とGETAの文字が表紙に見えたので購入してみた。
PUBLISHER'S NOTESのタイトルも「『編集』のオープン化が始まる」という刺激的なものである。編集者が書くのだから、問題意識は深い。これは出版自身がオープン化していく可能性と相まって、一種の必然のように感じられる。
松岡氏は「編集なき検索は検索ではない」と述べているが、検索は情報を編集して知識に転化するために行う一つのプロセスである。また、非線形読書という用語が出てくるのだが、これは編集読書とも言えるのかなと思わせる。あらゆるプロセスにおいて編集は現れる。編集こそが思考である。
GETAは日本の検索技術の一つとして取り上げられているのだが、国立情報学研究所のWebcat Plus等に使われている。この日記でも随分以前に取り上げたが、今は宝の持ち腐れ状態、そのうちリバイバルと行きたいところである。
NHKのニュースでアップルとソニーが同時に新製品を発売したというので、ソニーも調べた。News and Information 「新・ウォークマン」誕生 ユーザーの好みに合わせて“進化”するウォークマンAシリーズ。
「古き良き時代はもう来ない」--ソニー、新ウォークマン発表 - CNET Japanのような記事も出ている。デザインやスタイルのような皮相なものを追いかけるのではなくて、是非本質的な新しい世界を生み出して欲しい。あっと驚くような・・・