今日の出来事というよりか、昨日の出来事なんですけどね。
・BFでタンクのケツを取り一撃でしとめた瞬間が一番快感な気がしてきた
・BL H4でチップインイーグルした
・マナカナの区別をする自信がちょっとついた気がした
2005年10月アーカイブ
[ITmediaニュース] goo検索をATOKが支援 キーワード変換候補を“賢く”表示
「gooとATOKが連携してWeb検索を支援！」てな論調の紹介となってます。実際に使ってみるにはこのへんからどうぞ。
なんつーか、斬新ですなぁ。これに近いものとしてはAjax+自然言語技術を統合しているこの人が有名どころでしょうか。その中でも、「Ajaxを使った日本語Full IME」なんかは、力業でよくここまで仕上げたもんだという感想を持ったものです。で、先にニュースを読んだ感じでは、これのATOK版かな、とか思ってたわけです。
がしかし、実際にこの「gooサジェストβ with ATOK」を使ってみて思うのは、IME機能そのものをASPで提供するというよりは、ケータイでよく取り入れられている「推測変換(予測変換)」と国語辞書機能を統合したもの、という印象を受けます。先頭の数文字を入れるだけで単語候補が絞られるのは推測変換と一緒、候補として現れる単語の横にその単語の説明が添えられる、てなインターフェースです。つまり、ATOKがAjax使ってASP的に提供されるというよりは、推測変換+辞書機能がAjaxでASP的に提供されるといった方が近い気がします。
さてさて、このサービスの利用者層を考えてみましょう。明らかにPC上でのIME操作になれていない人がターゲットとなります。初心者向け文字入力支援システムとしては、ケータイのテンキー的なスクリーンをマウスでつつくシステムなんてのもありました。これは、キーボードタイプすら全くできないような人がターゲットであるといえるでしょう。これに対し、今度のはキーボードタイプはちょっとだけならできるけど、タイプミスや漢字変換がおぼつかないような人がターゲットとなるでしょう。
変換精度競争が終わり、関西弁やインターネット連携など新たな機能を模索するJustsystemにとって、いわゆる親指族のためのIMEインターフェースの模索は重要な戦力目標なんでしょうね。
トユーカ、数文字入れるだけでたくさんの単語候補とその単語の意味がずら〜っと出てくるの、なんかコワイくらいにスゴイ気がする。
やたら刺激されたんで、トラックバック送りつつリンクはらせてもらいます。にとよんの技術日誌: iPod＋iTunes＋iMac に想う
参考リンク- [ITmedia ライフスタイル] DLNAで一躍脚光を浴びる「DiXiM」とは何か
- [PCウォッチ] Intelが盛んにDTCP-IPをアピールすることの、“なぜ?”(笠原一輝のユビキタス情報局)
- [PCウォッチ] ついに発表されたEast Forkこと“Viivテクノロジ”(笠原一輝のユビキタス情報局)
- [AVウォッチ] Apple、QVGA液晶搭載MPEG-4/H.264対応の新「iPod」
- [PCウォッチ] アップル、新iMac G5/iPod発表会を国内公開
- CNET Japan Blog - 梅田望夫・英語で読むITトレンド：「オンラインミュージックは儲からない」と競合を牽制するスティーブ・ジョブズ
- デジモノに埋もれる日々: 「ウォークマンがiPodを逆転？！」の数字はこうして作られる
上記のエントリを簡単にまとめると、ホームサーバとしてのiMac、外にあるコンテンツブラウザとしてのiTMS、外と内両方にあるコンテンツブラウザとしてのiTunes、パーソナルモバイルメディアプレーヤ(パーソナルモバイルクライアント)としてのiPod、これらを統括するAppleは次世代コンテンツ流通インフラを制しつつある、てな感じです。まぁ順番に見ていきましょう。
これらの中で一番弱いのがiMacです。根本はMacに対し圧倒的なシェアを持つWindowsというところにあります。AppleはWindow向けにもiTunesを提供するという英断をしており、これが将来DLNAサーバとして機能するようになるかもしれません。が、これとて、Windows MCEやViiv(East Fork)の前では決して優位に立てるとは限りません。内にあるコンテンツのサーバとしてのiMacが一番弱いところでしょう。ビデオ対応iPodの発表と一緒に新iMacも発表しアピールしているのは、こういうところを意識しているのでしょう。
ただ幸いなことに、DLNAガイドラインの枠組みではコンテンツサーバは分散しているのが前提になっています。つまり、5年くらい前から騒がれているホームサーバは家庭内コンテンツのすべてを集約するという思想のもと提案され続け失敗し続けてきていますが、DLNAではコンテンツは分散したサーバが個々に持っていると前提をおいています。
内にあるコンテンツは著作権保護する必要がないため、内にあるコンテンツを保持するサーバはDRMやDTCP-IPを意識する必要がなく、サーバがクライアントのためにリアルタイムトランスコーディングする必要がないです。つまり、内にあるコンテンツのサーバはPCほどのCPUパワーが必要にはなりません。結果、DVRやコンポあたりでも内にあるコンテンツを分散保持していられるはずです。
外にあるコンテンツは著作権保護する必要があります。ホームネットワークで共有するためにはDRMやDTCP-IPを乗り越える必要があります。DTCP-IPの枠組みを考えると、クライアントのためにリアルタイムトランスコーディングする必要があり、結果CPUパワーを持ったPCが有利となります。外にあるコンテンツを保持するサーバは、CPUパワーが豊富であり決済機能を持っていることが求められます。
ViivやWindows MCEは結局、この外にあるコンテンツを保持するサーバの地位を争っていることになります。次世代コンテンツ流通インフラを考えると、そこまで大きなウェイトを占める地位ではないでしょう。・・・とか書いてみたものの、やっぱある程度重要な地位に思えてきた(ぉ) HD DVD/Blu-rayプレーヤは強力なCPUパワー(+GPUパワー:CGやJavaが絡む)が必要だし、デジタルテレビ放送の録画は著作権保護を意識せざるを得ないだろうし(コピーワンスは見直し協議中)。で、なんだかんだで、内のコンテンツより外のコンテンツの方が割合多いだろうし・・・そのためのiTunes+iTMSか？
なんか、書き出したら止まらないぞ(ぉ) まだまだ書きたいことのうち半分も書いていないぞ(ぉ)
外にあるコンテンツブラウザとしてのiTMSの地位は揺るぎないものになってきました。各社メーカがP2Pの違法コピーに頭を悩ませているコンテンツホルダーの顔色をうかがい二の足を踏んでいるうちに、AppleはiPodとiTMSを完全に広めきってしまいました。Appleのうまかったところは既存のMP3などを制限なしにiPodに転送できるようにした点でしょう。ユーザにiPodを買ってもらうための敷居を下げました。ただもちろんそれだけではなく、大量の音楽を徹底的に限界まで安く提供するiTMSも用意しました。買ってきたりレンタルしてきた音楽CDをMP3やAACに変換しアーティスト名と曲名を入れて管理するのは手間がかかることであり、iTMSならそれらがすでに処理されたファイルが簡単に手に入ります。近くの音楽店へそもそも置いているのかどうかすらわからない曲を求め永遠とさまようのは時間のムダであり、iTMSなら簡単に検索できます。しかも、どこの店にも売ってないような古い昔の曲もおいていることが多いです。iTMSは使い勝手の面を相当考えて作っている、と指摘する人も多いです(私は使ってないので何ともいえないんですが)。
iTMSは儲かっていないのは有名な話です。オンライン販売で儲けようとしているコンテンツプロバイダ(≠コンテンツホルダ)は、儲けなど考えていないiTMSには価格では勝てません。AppleはiTMSで音楽を売って儲けようとはしておらず、iPodを売ることで儲けようとしています。まぁそのせいで私的録音録画補償金制度が勃発しているわけですが。
で、上記で音楽だったところが今回動画になりました。Apple自身は以前から、そして今回も、iPodが動画対応したことをあまり積極的にアピールしないようにしています。いぜん音楽が大事だと言い続けています。ただ、iTMSで動画配信まで始まるとなると、皆はiPodが動画に対応したと騒ぎ立てます。ちょっと文化人を気取った人は、音楽と動画は利用スタイルの異なるコンテンツで動画対応は大事でない・音楽が大事だ、とAppleの話を真に受けます。しかし真実は、上記で音楽だったところは「デジタルコンテンツ」だったんですよ。電子書庫サービスにいつ参入するかもしれません、ゲーム配信だってあり得ます。私の頭が固いんでこれ以上出てこないんですが、「デジタルコンテンツ」なら何でもやりかねないことでしょう。一時期「iPod photo」とかいってましたが「iPod」に統一されました、今回の動画対応版も「iPod video」とは名付けられていません(勝手にそう呼んでいる人はいますが)。iPodはデジタルコンテンツのメディアプレーヤであり、決して音楽や動画だけに絞っているわけじゃないんです。この路線が成功すれば、iTMSは外にあるコンテンツのポータルサイトとなることでしょう。
iTunesとは何かを考えると実は難しいんです。ちょこっと調べてみると、「音楽プレーヤーソフト」「音楽管理再生ソフト」あたりが主流ですね。Appleのページには「No.1ミュージックストアを楽しめるデジタルジュークボックス」と書かれています。デジタルジュークボックスという言葉は、今回動画対応したことを意識しているんでしょう。iTunesは、音楽プレーヤだけではなく、音楽管理ソフトだけでもなく、iTMSへの窓口のソフトです。
さて、音楽は「デジタルコンテンツ」に置き換えられます。iTunesは、iTMSで販売されるデジタルコンテンツへアクセスするためのソフトです。まぁちょっと高機能で、デジタルコンテンツをそのまま再生したりiPodに転送したりできます。ここまでなら普通ですが、iTunesはデジタルコンテンツを管理できます。
私はコンテンツ管理ソフトが嫌いです。よく「スキャナで取り込んだ画像を管理するソフト」「デジカメで撮影した写真を管理するソフト」「CDからエンコードした音楽を管理するソフト」「OCRで文字にした文章を管理するソフト」なんてありますが、あのたぐいのものは大嫌いです。そんな私が使っているのは結局Windowsのエクスプローラです。エクスプローラはファイラでしたが、最近はそうでもなく、ムダにプレビュー機能を統合してくれたりしています。つまり、あのたぐいのものを嫌っていながら、使っていたファイラはあのたぐいのものへと向かってたんですよ。
話を戻しましょう。従来のコンテンツ管理ソフトがエクスプローラやiTunesと異なっている点は、ネットワーク対応です。従来のコンテンツ管理ソフトは自分(ソフトの動いているPC)で作り管理しているコンテンツしか再生できませんでした。エクスプローラやiTunesは、ネットワーク対応することにより、他の機器に存在するコンテンツをも再生できます。管理はちょっと微妙ですが検索くらいならできます。このようなソフトを、コンテンツ管理ソフトとまでは呼びきれないので、コンテンツブラウザと呼びましょう。
エクスプローラは、LANやイントラネットを対象にしたコンテンツブラウザでした。いわば内にあるコンテンツのためのブラウザです。iTunesはiTMSのためのソフトです。いわば外にあるコンテンツのためのブラウザです。しかしiTunesはネットワーク共有機能を持っています。これまではネットワーク共有されるのは音楽でしたが、音楽は「デジタルコンテンツ」なので、iTunesはデジタルコンテンツをネットワーク共有できます。つまり、内にあるコンテンツのためのブラウザにもなり得ます。
話がちょっとそれます、DLNAがらみの話でもあります。上のような感じでコンテンツブラウザは整備されつつあるのに、実は検索が非常に弱いままです。Windows(エクスプローラ)の検索機能が弱いのはよく指摘される点ですが、エクスプローラは内にあるコンテンツのブラウザであるため、結果内にあるコンテンツの検索機能が非常に弱いままとなっております。デスクトップ検索ソフトがはやっていたのは1年ほど前ですが、その流れのままイントラネット検索(ホームネットワーク検索)ソフトにまでいってほしかったですね。デスクトップ検索ソフトは自分のPCにあるコンテンツしか検索できません、内にあるコンテンツも検索できるようにしてほしいです。このへんはWinFS頼みだったんですが。というわけで、Appleの次世代コンテンツインフラのためにWinFS開発をがんばってください＞MS
さてiPodです。これまでは、iTunesやiTMSはiPodのために用意したものであるという説明を聞き続けてきました。これに対し、上記の説明により、iTunesやiTMSがiPodのため(=iPodの付属品)にすぎないわけがなく、もっと重要な役割を担うことは理解していただけたかと思います。しかしここもAppleのうまかったところ。iTunesやiTMSはiPodのためのものと言い続けてきたのにはわけがあります。iTunesやiTMSをがんばって作っても決して儲からないのです。iTunesやiTMSは次世代コンテンツ流通インフラに不可欠ではありますが、そこから儲けを出そうとしなかったのです。ただの音楽プレーヤや管理ソフトに金出そうと思う人は少ないでしょう、オンライン販売はできるだけ安いところで買いたいでしょう。どれだけ次世代コンテンツ流通インフラに不可欠なものであろうとも、一般ユーザにしてみればただの音楽プレーヤや管理ソフトにすぎないのです。シェアを取るためには安く提供する必要があります、儲けを考えないくらいに。そこで目をつけたのがiPodです。iTunesやiTMSはiPodのためとウソをついて、その間に壮大な次世代コンテンツ流通インフラを構築しようとしているんですよ。
もちろんそのためにはiPodが飛ぶように売れてもらわないと困ります。iPodが飛ぶように売れるようにするためAppleがどんな戦略をしてきたのかというテーマで語らなければいけないところですが、このテーマは実はこれまでにおそらくたくさんの人々に語られてきた話だと思うんで、ここではあえてさけておきます。「実は知らないだけなんだろ？」とか脅迫じみたコメントは容赦なく削除いたします(ぉ) 事実なので反論できないだけです(ぉ)
「iPodの背中が見えてきた! ソニー「ウォークマン」の逆襲」とか笑わせてくれますね。当時朝日新聞でも「iPod vs ウォークマン」とかいう笑わせる記事を見かけました。ソニーは負けました。正確に言うなら、デジタルポータブルオーディオプレーヤ市場におけるブランド争いに負けました。iPodブランドは絶大です。今からがんばったんじゃもう間に合いません。たとえば、「Gigabeatが動画対応!」では誰も見向きもしてくれません。「iPodが動画対応!」ならほっといても一般人が布教してくれます。「Gigabeatッテナニ？」が通常の人の反応です。今からiPod対抗のHDDウォークマンでは視野が狭すぎます。iPod＋iTunes＋iTMSの次世代コンテンツインフラを意識して切り崩しにかからないと。(と書いてみたものの、Gigabeatってまだ動画対応してなかったのかよ)
そんなiPodの目指している方向は何なんでしょうか。音楽・動画などと来れば、当然ながらPDA的な地位が思い浮かびます。モバイル情報端末としてのPDAのコンセプトは非常に共感できるんですが、いかんせん誰も買いませんでした。近年PDAに取って代わろうな勢いなのがケータイです。ケータイが通話やメールの端末だと思っている人はすでに遅れていて、ケータイは実は音楽・動画・ゲームのための課金プラットフォームです。むろん、PDA的な軸を見据える人もまだいるわけですが、スケジューラやフルブラウザやアドレス帳やPDFビューアを喜んでいるのはコアな人だけでしょうね。おサイフケータイは・・・びみょー、まだよくわからん、向いてる方向は電子決済か？
iPodとPDA(or PDA的なケータイ)との違いは、パーソナルであるかどうかだと思ってます。音楽聴いてる途中で電話が鳴ったりしない、ゲームしてる途中でメールが入ってきたりしない、それがiPodのようなものに求められている機能です。・・・というようなことをどっかの有名な人がBlogで書いてたはずなんだけど、探しても見つからない・・・ケータイにカメラ機能がついたのは、ケータイがパーソナルな端末であることの象徴だと思います
ただし、ケータイがiPodに対し弱いのは、ケータイがキャリアの縛りを受ける点です。キャリアはコンテンツを囲っています。端末がどれだけ高機能化しようとも、コンテンツを持っていないメーカはキャリアの言いなりです。キャリアは以前ケータイは通話とメールの端末であると言い続けているため、iPodのようにパーソナルな端末にはなりきれないでしょう。そういう意味では、PSPやNDSの方がiPodに近いかもしれません。
また、別のケータイが弱い点としては、端末とキャリアのネットワークで閉じてしまっている点でしょう。最近でこそSDカードやUSB接続により内にあるコンテンツを共有できるようになってきましたが、以前はそれすらままなりませんでした。外にあるコンテンツはキャリアが囲っています。キャリアは自社インフラ越しでしか外にあるコンテンツの配信を認めません。こっちもパケット定額制導入によりましにはなりましたが、以前はいわゆるパケ死直結というユーザに優しくなさすぎるプラットフォームでした。これでも先進的なデジタルコンテンツ流通インフラだったんですよ。
そんなわけで、次世代コンテンツ流通インフラを制しつつあるAppleということで話をしてきました。そんなAppleにも弱みがあります。
まずDLNAガイドラインに賛同していないこと。AppleのDRM(FairPlay)をオープンにしていないことにも起因するんだと思いますが、iPod+iTunes+iTMSの自社製品で閉じようとしています。この路線は商売的に危険でしょう。自社以外にも解放するなら、そろそろDLNA賛同だとか表明してほしいところではあります。
次、オンライン販売の利益が薄いこと。上の自社で閉じていることとも関係しますが、最終的に超広く超薄くもうける路線に行きたいんでしょう。問題は、そこまで多くのユーザを抱えられるかどうかです。
最後、iPodにはPCが不可欠であること。これまた自社で閉じていることに関係しますが、iPodにコンテンツを転送しようと思うとiTunesが不可欠です。iTunesはPC(Macも含む)が不可欠です。ただ、この点は利用スタイルにも影響するのでそう簡単には解決できないでしょうね。iPodにEthernetコネクタ(or無線LAN)がついてiPod単体でiTMSにアクセスできるとして、果たしてそれは便利で使いやすいんでしょうか。ケータイは端末単体で通信できるのでこの点で圧倒的に有利です。ただ、ケータイの狭い画面でしか見られない映画なんて好き好んで買う人は少ないでしょうけどね。
さてさて、長々と語ってしまいましたが、最後に、Appleが次世代コンテンツ流通インフラを完成させるための手順について見てみましょう。
まずiTMSの強化があげられます。音楽や動画にとどまらないデジタルコンテンツ全般を網羅する最強のコンテンツポータルに仕上げる必要があるでしょう。
次はiMac(or iTunes)の強化。ホームネットワークまで視野に入れるならiPodやiTunesというプレーヤだけでは少なすぎます。テレビ・HD DVD(Blu-ray)プレーヤといったクライアントにデジタルコンテンツを届けるためのiMac(or iTunes)が必要です。
その次がiTunesの強化。外にあるコンテンツブラウザとして成長してきましたが、ホームネットワークを考えると内にあるコンテンツを見る機能の強化が求められます。NASに蓄えられた孫の写真を手軽に見たい老人の要望には応えるべきでしょう。
最後にiPodの強化。次のデジタルコンテンツが何であるかにもよりますが、たとえばテキストビューアの強化であったりフルブラウザ搭載であったりゲームのためのMIDP対応(Java対応)であったりするでしょう。
以下はタイトル文に合わせるための蛇足。
ここまでを考えると、これまでに考えられてきたホームネットワーク構想に足りなかったものは、コンテンツブラウザとパーソナルモバイルメディアプレーヤです。
DLNAガイドラインの貧弱さにもよるんでしょうが、まずコンテンツブラウザが弱すぎます。DiXiMでコンテンツがどのマシンにあるのかを意識させないインターフェースが実装され評価されたりしてますがそんなの序の口、iTunesのように外にあるコンテンツもシームレスに探せる必要があるでしょう。内か外かを意識させなくてもいいかも。外にしかないなら、買ってホームサーバにDRM保護つきで保存しDTCP-IPでそのままコンテンツブラウザ上で再生できればうれしいでしょうね。むろん、iTMSのように密着したオンラインストアが必須ですが。
で、パーソナルモバイルメディアプレーヤの存在です。現在でも音楽・動画を再生できたり電子書庫を転送できたりする端末はありますが、転送のための敷居が高すぎます。普通のユーザは、AACとかMP3とかWMAとかMPEG2とかMPEG4とか3GPPとかmovとかJPEGとかPNGとかXMDFとかEBKとか意識したいわけがないです。Ethernet端子がついてDTCP-IPで転送？家にいないときはどうするの？USBごしにストリームだけでなくコピーもできないとダメですね。著作権保護問題があるので難しいところでしょうが、iTunes+iPodという閉じた組み合わせだからこそできるわけです。
ここ半年くらい技術動向の情報を仕入れてこなかったせいなのか、2ヶ月くらい前に「Ajaxテナニ？」な顔をして友人にポカーンとされてしまいました。Ajaxの説明はe-Wordsにも説明があります。私なりにまとめるとなると、JavaScriptでHTTP通信しその結果をDHTMLを使ってページ切り替えを伴わせずに表示する手法のこと、てな感じでしょうか。この手法を積極的に用いてきたのがかのGoogleであり、その手法をAjaxと名付けたのがadaptive pathということらしいです。
adaptive path的には、Ajaxは単なる一つの手法にとどまらず、「ページ切り替えは当たり前」とされてきたWebナビゲーションの常識を覆す手法であり、またDHTMLをView、JavaScriptをController、HTTP非同期通信をModelとするMVCをWeb上で実現する画期的なアーキテクチャである、とまで言い切ってます。そこまで画期的なのかどうかまでは私にはわからんのですが、いずれにしても、ここ半年の間にあっという間に広まった技術上のトレンドであることは確かです。
で、そのAjaxを用いたアプリケーションの象徴ともいえるのがGoogle Mapsです。Google Mapsは、Ajaxを使ってページ切り替えなしに地図を見ていけるインターフェースとしても注目されましたが、ひょっとするとそれ以上に注目されたのがGoogle Maps APIです。これは、ぺーぺーのWeb制作者が自分だけのGoogle Mapsを自分のサイト内に無料で作れちゃうということで注目されました。それ以前に、地図データを無料で使えるサービスなんてのはなかなかないしね。
で、私もGoogle Maps APIの登場のニュース自体はしってたんですが、しょせんJavaScriptでいじれる程度のものでしかない、てな認識に立ってました。ええ、AjaxでJavaScripの能力が再評価されてきているなんていうトレンドを知りませんでしたから。4年くらい前はDHTML+JavaScriptで遊んでたんですが、当時はやっぱ異なるブラウザでも問題なく動いてくれるようにするのが激しく面倒だったことは覚えてます。ここ最近はそんな土壌がましになってきたということもあるんでしょうかね。むしろFireFox/Opera/IE7なんて話題で、またJavaScript互換性に悩まされるオチが待ってるかもしれませんが。
話がそれた、半年くらい技術動向の情報を仕入れてこなかっただけならず、半年くらいまともなプログラミングをしてこなかったという私の事情もあります。Ajaxを知ったという事情もあります。なので、ここは一つGoogle Maps APIで遊んでみようか、てな感じに思いました。ただ、Google Maps API自体が公開されてからもう半年近くも立ってしまっていたせいで、誰でも思いつきそうなのはもうとっくにやられちゃってるので、何やるかも含めていろいろと悩みました。
で、作ってみたのがGoogle Maps Farm(と勝手に名付けたもの)です。IE6以外は動くかどうかも含めてシラネ。目指した機能は二つ。一つ目が、ユーザが自由にマップ上にアイコン(マーク)を追加してアノテートできること。二つ目が、JavaScriptやHTMLなんかも知らないユーザが自由に自分だけのGoogle Mapsサイトを作れること。「Farm」という用語は、ある特定の機能を持ったものを複数新規に作っていける(ホスティングできる)ようなものの意味で使われます。WikiFarmなんてのが有名な使われ方ですね。とかいいながら、肝心の「Farm」の部分を作っていないんですがね(=まだ新規にGoogle Mapsサイトを作れるようなのは用意していない) Farm部分は、上で公開したGoogle Maps Farmのテストサイトの評判がよければ作ってみますです。
Google Maps API, DHTML, JavaScript, REST, PHP, XMLDOM, MySQLといったあたりを何となくミーハーな気分で使ってみました。JavaScript非同期通信してますが、通信に失敗したらデータがブラウザ上は反映されてるのにDBに反映されてない状態になります。HTMLタグが入ると壊れる可能性があります。SQLインジェクションされちゃうかもしれません。複数の人が同時にデータ修正しようとするとどっちかが上書きされます。といった状態ですが、もうこれ以上改良する気が出ないのでとりあえず公開という流れになりました。
一度作って身内に公開したら、「すでに似たようなのがあるよ」(はてなマップ http://mapli.jp/)と言われてしまったのが、これ以上改良する気が出ない理由の半分です。残りの半分はご想像にお任せいたします。
Google Maps APIにて、InfoWindowが開いた状態でてきとーなところをクリックした場合、
・click
・infowindowclose
の順でイベントが起こる。まぁ当たり前といっちゃ当たり前なんだけど、深みにはまってしまった。ここで、clickイベント発生時に別のInfoWindowを開くようプログラムした場合、
・click
・infowindowclose
・infowindowopen
の順でイベントが発生する。これも考えちゃ当たり前なんだろうけど。30分くらいはまりました。
Ajaxを使う時、XmlHttpRequest.responseXML.documentElementを参照したときにIEにて、
「documentElementはnullまたはオブジェクトではありません」
のエラーが出る場合がある。しかもXmlHttpRequest.responseTextあたりは問題なく参照できる。そんな場合、XmlHttpRequest.openするときに与えた引数のURIで、サーバからの返事で、Content-type:でapplication/xmlもしくはtext/xmlを返していないのが原因でしょう。1時間くらいもろはまりました・・・
PHPでXMLを使う場合(php-domxml)、domxml_open_memを呼ぶと
PHP Warning: domxml_open_mem(): input conversion failed due to input error
などのWarningが出る。これはどうやら文字コードに起因する模様。
<?xml version="1.0" encoding="UTF-8" ?>
といった文字コードの宣言と実際に入力された文字コードとをちゃんと確認しましょう。結構はまったけど、原因はこの次に書くやつが根本だった。
たとえEUC-JPなHTMLのページからJavaScriptでXMLHttpRequestを使う場合でも、明示的に指定しない限りPOSTされたデータはUTF-8で送られることになる。しかも、POSTなのでデータはいわゆるURLエンコードされた状態で送られる(ココに一番はまった)。参考(http://www.hawk.34sp.com/stdpls/xml/xmlhttprequest.html)ページを読む限り、明示的に指定しても怪しいのかな？上のやつと併せて、実質2時間くらいはまった。てか、あまりに深みにはまったのでふて寝したら1日が終わった。
apt-getでphp-domxmlを入れたとき、コマンドラインからはちゃんと動作するのに、Webからアクセスするときにphp-domxml関連のクラス・関数が動かなかった。Apacheはphpをmodとして動かしているので、新しくPHPのライブラリを入れたらApacheも再起動しないといけないです。5分くらいはまりました。
タスクスケジュールというと、通常OSの各プロセスの優先度を元にCPU割り当て時間と順序を決めていくやつを指しますが、ここではそれはおいといて、一般的なスケジュールを考えます。つまり、仕事の場面にてやらなきゃいけない案件がいくつかあってそれぞれに重要度があってかつ締め切りがあって、てな場合です。
いわゆるスケジュールってやつは実際に作ろうと思うと難しいです。午前はこれやって午後の2時間はこれやってその後これをやって・・・と頭の中ではイメージするんですが、重要度の高いものを先にやらなきゃいけなかったり、重要度の高いものを優先していると重要度の低いものの締め切りが近づいていて・・・とか。ってことで、ここではそれらを徹底的にモデル化してみようと思います。似たようなことはおそらくすでに誰かが考えているんでしょうけど、まぁここは私流に考えてみます。
まず、時間は有限であるとして(勤務時間は1日で一定時間)、日々の仕事は複数の案件からなると考えます。個々の案件をタスクと呼ぶことにしましょう。タスクにはそれぞれの重要度があって締め切り日時が決まっていて、タスクをこなすのに要するであろうと思われる時間がわかっています。このとき、タスクをどの順に並べて実際に取りかかっていくかを考えます。
とりあえず締め切り最悪法を提案します。これは、それぞれのタスクの締め切りぎりぎりになるまで手をつけないという方針でスケジュールする方法です。今与えられたタスクすべてを締め切りが最も遠い順に並べます。最も遠いタスクの締め切りぴったりにそのタスクを終えられるようにそのタスクの開始時間を決めます。2番目に締め切りが遠いタスクでは、その締め切りぴったりの時に1番目に締め切りが遠いタスクにすでに取りかからなければいけないかどうかで条件分岐します。取りかからないといけない場合は、1番目のタスクに取りかかる開始時間ぴったりに2番目のタスクを終えられるよう2番目のタスクの開始時間を決めます。取りかからなくてもよい場合は、2番目のタスクの締め切りぴったりちょうどに2番目のタスクを終えられるよう2番目のタスクの開始時間を決めます。ここで、2番目のタスクが終わってから1番目のタスクに取りかかるまでの間に空いた時間を暇と呼ぶことにします。これを永遠と繰り返していくことで、すべてのタスクをスケジュールしてきます。
ここでできあがったスケジュールは、いわば最悪の場合のシナリオです。つまり、このスケジュールよりも少しでも遅れてしまうと締め切りがすぎてしまうタスクが出てきてしまい、暇のあるところまで取り戻しができなくなります。このスケジュールを下回らない範囲でタスクをこなしていけばよいことになります。
ここで、重要度に移りましょう。重要度の高いタスクは、締め切りはあるもののできるだけ早く仕上げる方がよいという意味にします。先の締め切り最悪法で定義された暇のところで、今与えられたタスクのうちもっとも重要度の高いタスクに取りかかるようにすればムダがなくなります。
暇の時間での取りかかりにより重要度の高いタスクを終えられた場合、タスクが減った分スケジュールが変わるので、締め切り最悪法により再度スケジュールを作ります。で、あとはその繰り返し。
うん、我ながらなかなかいいアルゴリズムを作れた。あとはこれを実践するだけだ。さぁ個別のタスクの締め切りと重要度とこなすのに要するであろう見積もり時間を登録すれば、後はコンピュータが勝手にスケジュールを生成してくれる。で、できあがったスケジュールは・・・あ、すでに間に合わんわな。こうして今日も残業するのでした。
(上記は架空の話であり、現実の会社員のスケジュールや残業時間とは一切関係ございません)
「よ〜く考えよ、お金は大事だよ」は某CMのキャッチコピーです。私がまだ学生をやっているせいもあるのか、このキャッチコピーをあまり意識せず普通に聞いていました。が、最近よく思う。「本当にお金は大事なのか」と。そりゃ全くお金が必要ないとは言いませんが、お金よりも時間の方が大事であるはずとなんとなく感じます。
よく「時間を買う」なんて言い方がされます。まぁたいていは経済の分野の言葉でして、お金を持ってる会社が技術を持ってる会社を買収することで、技術を開発するために必要であろうと思われる時間を節約し技術を手に入れる、てな使われ方です。まぁ経済の話を持ってきても私自身があまりピンとこないんで、もっと身近な例に置き換えて。
知り合いの某官僚様は文字通り寝る間も惜しんで仕事をなさってます。帰りはタクシー、洗濯する間も惜しいのでクリーニング店利用、てな具合に、まさしく時間をお金で買っています。まぁこれは極端な例でしょうが、電車の特急券・高速道路の利用料などは、典型的な「時間をお金で買う」例でしょう。
んでふと考えてみると、これまでの経済発展はまさしく「時間をお金で買えるようにする」ための技術で成り立ってきたんじゃないかと。掃除機や洗濯機があると、ない場合に比べて作業時間は大幅に減らせます。新幹線はムダな移動時間を減らします。電話は会いに行く時間を削れます。技術ってのは究極的には、人々の時間をより節約できるようにするために使われることが多いようにも思えます。
一方で、経済発展の結果時間を節約しまくってできた余暇はどのようにすごされるのかというと、いわゆる「遊び」に分類される部分になります。動物学的な広い意味での「遊び」と言えばいいんでしょうけど、ここではもっと一般的な意味の遊びでもいいです。エンターテインメントといった方がいいかも。ここで「人はなぜ遊ぶのか」なんてことを考えるのもいいんですが、その話はおそらく哲学につながってしまうと思うんでやめときます。「人間は遊ぶ動物である」とも定義されたりするくらいだそうです、へぇ。遊ぶ動物なら「遊ぶために生きている」といっても過言じゃないでしょう。
というわけで、上の話をふまえると、BF1942で遊んだ後「ああ時間を無駄に過ごしてしまった」と思ってしまうのは果たしてどういう状態なんでしょうか。「人は遊ぶために生きている」のならBF1942で遊んだんだから後悔する必要はないはず。なのに後悔するということは「人は遊ぶために生きているのではない」ということでしょうか。だからといって「仕事するために生きている」と結論づけるのもイヤだしなぁ。なので「BF1942で遊んで後悔する必要はない」ということにしておきます。よし、明日の晩もdamepo-jpnにいくぞ。
出だしと結論がこうも正反対なのは、理論の展開がまずいからであろう。「理論の展開がまずい」人の書く文章で「理論の展開がまずい」と主張するのはこれいかに。
apt-get dist-upgradeで、rpmになったKernelモジュール類が/boot/に展開される。いつからかは知らんけど、少なくとも3.2では、vmlinuzとvmlinuz.oldを自動で作ってくれる模様。(内部ではただのシンボリックリンク)
/etc/lilo.conf
prompt
timeout=50
default=linux
boot=/dev/hda
map=/boot/map
install=menu
message=/boot/message
image=/boot/vmlinuz
label=linux
read-only
root=/dev/hda2
append=" resume2=swap:/dev/hda3"
image=/boot/vmlinuz.old
label=old
read-only
root=/dev/hda2
append=" resume2=swap:/dev/hda3"
とか書いとけばOK。
/sbin/lilo実行してブートローダ更新。再起動しておしまい。
