_ Sony's Idei - Part 2 from AlwaysOn (20:17)

• Sony's Idei - Part 2 - http://www.alwayson-network.com/comments.php?id=250_0_2_0_C

Sony's CEO Unplugged from AlwaysOnのパート2。今回の話は主にLinuxを中心としたOSに関する戦略および現状分析。

それにしてもLinuxに関して、

Ultimately, somebody needs to be responsible for the interoperability of the OS. So who will perform the function of Microsoft in the Linux world?

ってのはやっぱり重要なのか。確かになにか不具合が起きたときに、その責任者に「直せ」と言えないのは商売としては厳しいのかもしれないけど、ソニーとかならば社内にオープンソースプロダクトの不具合を修正できる人材を抱えておいて、いざというときに自前で対処できる体制を整えておいた方が、他社（マイクロソフト）による修正を待つよりも安全なんじゃないか？

In the past, every time that Microsoft developed a new OS, they wrote it using a different language.

ってのはNTのときに開発言語をC++に切り替えたことを言っているのかな？　それ以降には特に大きな採用言語の変動があったって話は知らないけれど。今回の.NETでまた大きく変わっただろうけど、あれはまだマイクロソフト社内でもメインの開発環境にはなっていないだろうしな。

Our best strategy is to focus on selling entertainment content and hardware, and work with an experienced OS partner for the long term.

というわけで、基本的にソニーはOSを自分で作ることにはあまり興味がない――というか、OSを自分で作ったりするのはソニーにとって良い戦略ではないと思っているわけだね。でもその割にはPalm Sourceは買い取りたいとか言っていたけれど。あれはまあ現状でもすでにある程度完成したOSだからか？

Sun has problems with their management structure. We are supplying them SRAM chips so we know this.

ふーん、そうなんだ。「SRAMチップを供給している関係で、サンがマネージメント構造に問題を抱えていることを知っている」ってのもすごい話だな。直接取引をした相手にならばばれちゃうくらいわかりやすい問題なのか？

それにしても、企業のトップがこれだけ幅広く技術の現状を認識しているってのはすごいな。金関係のことだけでも考えなければならないことは山ほどあるだろうに。

_ Wikiのマークアップの利点 (20:17)

Wikiの利点の一つとして、そのマークアップルールがシンプルなため、レンダリングする前のプレーンテキスト状態でも、十分可読性が高い（人間が普通に読んで意味が取れる）ということがあるよな。最近の高機能系Wikiではその部分が忘れ去られつつあるけれど。

その部分に注目して、簡便な可読性の高いマークアップルール以外は許さないという縛りを作り、その上でWiki的なシステムを実装していこうとすると、自動的にシステムの設計も決まっていきそうな気がする。簡単なマークアップでどれだけ高度な機能を実現するか、あるいは簡単なマークアップで実現できない機能は搭載しない、といった方向で。

結構こういうアプローチは悪くないかもな。フルにHTMLを手書きするパターンや、普通の掲示板レベルのほとんど表現力がないパターン、HNS風のマークアップおよびその拡張とかいろいろ試してきたけれど、結局現状のWikiLikeでサポートしているWiki系マークアップ（の簡単なもののみサポート）が人間に一番優しい気がする（＝俺が入力しやすい）。

Wiki系マークアップのシンプルな部分だけ使った場合、せいぜいキーワードを二重大括弧で囲んだり、引用部分の頭に>を付けたり、PRE部分の先頭に空白をつけたりするだけだから、文章を作る途中で既入力部分を見直すのがつらくないもんな。リンクも基本的にはURL文字列を書くだけだし。

_ ◆日経新聞社長が名誉棄損で社員を訴える from ZAKZAK (20:17)

• ◆日経新聞社長が名誉棄損で社員を訴える - http://www.zakzak.co.jp/top/t-2003_03/3t2003030603.html

この話、どっちに利があるのか分からないけれど、うやむやにならないことを期待しつつ注目しておこう。

_ ソニーのBlu-rayレコーダを巡る「謎」 from ZDNet (20:18)

• ソニーのBlu-rayレコーダを巡る「謎」 - http://www.zdnet.co.jp/news/0303/04/cjad_kitagawa.html
• ソニー、Blu-ray Discレコーダのすべてを語る - http://www.zdnet.co.jp/news/0303/07/nj00_bluray.html

前の記事であげられていた謎に関して、だいたい答えが返ってきている。

（1）現在策定中の再生専用ディスクは読めるのか？

読めない。

（2）2層記録メディアの読み出しはできるのか？

できない。

（3）コピーワンス番組を録画したときのアナログ出力はどうしたのか？

著作権保護対応。

（4）地上波デジタル放送が始まったときのチューナーサポートをどうするのか？

まだ考えていない。

（5）青紫色レーザーの数は取れるのか？

全然問題ない。

どうも話を聞く限りでは、一般向けに実用性が高い製品というのではなく、ごくごく一部のユーザーにとっては実用性がないわけでもないけれど、基本的には実験的製品って感じだね。まあソニーが得意なやつだ。HDD＋DVD-R/RAMユーザーはひとまずまだ気にしなくても良さそうだね。開発者の口から聞いてもまだそのメリットを語るのが苦しそうだもんな。

_ インタラクション2003顔アイコンはアイコンを超えるか？ from ZDNet (20:18)

• インタラクション2003顔アイコンはアイコンを超えるか？ - http://www.zdnet.co.jp/news/0303/06/nj00_int_kao.html

うわー、これはすげー単純だけど真面目に考えてみたことがなかったよ。確かに実用性がものすごく高そうだな。「人＝顔」として認識するのはごくごく普通でしかもインパクトが強いもんな。Web上で公開するとなるとセキュリティとかプライバシーとかいろいろ考えなければならなくなるけど、イントラネットで使うグループウェアなんかで人＝顔と結びつけたインターフェースを用意すると、ものすごくわかりやすくなりそうだ。

_ 2003F1オーストラリアGP (20:18)

予選1日目

今日は家を出る前ぎりぎりまでスカパーで予選1日目の様子を見ていたんだけど、予選はもう完全に別物になったと考えるべきだね。レギュレーション改訂に関してはあちこちに記事があるだろうけど、文章で読んでもいまいちどう変わったのかわかりにくいから、最初のうちだけでもきっちり予選1日目からテレビで見ておいた方がいいかも。

予選1日目はチャンピオンシップの上位から順番に、単独で1周こっきり（実際に走るのは、アウトラップ→アタックラップ→戻りのラップの3周セットね）のタイムアタックを行う。その結果が二日目のタイムアタック順序となる。で、二日目は下位から順番に5人ずつ（コースインのタイミングをずらして）タイムアタックを行うようになるらしい。

予選二日目にどの順番でタイムアタックするのがいいのかは、翌日の天候などの状況によって異なるだろう。たとえば午後から天気が崩れるみたいな予報が出ていた場合は、できるだけ早めにアタックしたい（＝予選1日目で下位につけたい）。逆に雨が午後に晴れるとなったら、できるだけアタックのタイミングは遅くしたいだろう。雨以外にも気温やタイヤマークなども関係してくる。

さらにスカパーの中継で話されていたのだけれど、チームメイト同士が離れたタイミングでアタックできるように調整することで、先にアタックしたチームメイトからコースのコンディションを聞いて、それにあわせて後からアタックする方がセッティングを調整するなどといったチーム戦略をとることも可能だ。予選2日目は5人ずつタイムアタックをすることになるので、チームメイト同士が一緒にアタックをする5人の中にいたのでは、後の人間がセッティングを変更する時間がないが、わざと上位と下位に分かれておけばそのあたりの情報を交換する余裕が出てくる。

また、予選二日目に関してはタイムアタック後、無給油＆（ほとんど）セッティング変更なしで翌日の決勝に臨まなければならないというレギュレーションができたので、今までのような車の性能限界を出し切る予選にはなり得ない。決勝の戦略によって各車がどういうタイムアタックをするのかが変わってくるだろう。下位チームなどが強引に予選で上に立ってブロック気味の走行でレースペースを落とさせて紛れを狙う、などという作戦もあり得るかもしれない。

今回のレギュレーション改定は、基本的に速い車を楽に勝たせないことが目的なので、そういう意味ではかなり有効そうに思える。予選1日目の頭5分みた感想をちょっとだけ書いておこうと思ったら、なんだかやけに長い文章になっちまったな。でもこれから予選1日目の残りと予選2日目と決勝が続くんだよ。

予選2日目

• ミナルディはマシンの耐久性に難があるので、負荷を減らすために予選アタックはしなかった（1周目で引っ込んだ）。107％ルールはもう有名無実だね。
• ミハエル以外は予選1日目にまともに走った（ちゃんと普通の予選アタックした）というパドックの評価らしい。ルノーの人は自分たちの結果を実力通りだと。だとするとBARは本当にいいのかな？
• クルサードは唯一、1ストップ可能な燃料を搭載しているっぽい。マクラーレンは1ストップ作戦好きだもんな。こういう予選形態になっても従来通りの計算が通じるのか気になるところ。
• うわー、ミハエルはえー。やっぱりはえー。フェラーリが燃料をむやみに少なくして決勝でリスクを背負うとは思えないんで、普通に燃料を積んでこういう結果なんだろうな。1秒速いってのはすごいよ。
• BARはよく分からないな。得意不得意が激しいのかな？　ヴィルヌーヴの最終セクターでのタイムの落ち込みの理由は車の特性なんだろうか。まあなんにしろ今までで一番できがいい車であることは確かそう。
• おお、バリチェロもはえー。っつーか、結局フェラーリがまた強いのか。昨年型の車でこれだからなー。あるいは去年の車のできが良すぎたのか。

今回のルール改正は速いチーム（＝金をかけて車を開発できるチーム）を遅くすることによって、下位チームとの差を減らすという目的で導入されたんだろうけど、なんだかフェラーリ以外の上位チームに効き過ぎていて、肝心のフェラーリにあまり効いていないんじゃないか。まあ紛れは起こりやすくなったと思うし、まだみんな新しいレギュレーションの隅から隅まで活用していないから、これからどうなるか分からないけど。

あと、この予選はトラブルとかミスとかで大きく順位が変動するので、車の実力通りの結果が出にくくなる（＝エンターテインメント性が高まる）という目的があったんだろうけど、予選でのパフォーマンスが限りなく決勝でのパフォーマンスに近いものになってしまうぶん、決勝での意外性が大きく減じる（＝エンターテインメント性が低くなる）という結果にもなっているな。まあ「意外性が減る＝エンターテインメント性が減る」とは限らず、情報量が多くなることによって面白くなる場合もあるけどさ。

• http://f1.racing-live.com/en/headlines/news/detail/030308045201.shtml

決勝

• こういう新レギュレーションで、セッティングの自由度が少なくなったとたんに、予選晴れ→決勝雨の後かよ。でも面白いことになったな。
• 結構こういうスタートも面白いな。燃料積載量のばらつきが激しいし、セッティングもぐちゃぐちゃ。
• ザウバーはえー。トヨタおせーのはセッティングのせいか。BARびみょー。
• あほたれバリチェロ。そんなことやってるからナンバー2止まりなんだよ。
• あらファーマンも。
• フェラーリ珍しい。こういう大事なときにタイヤ交換をミスるなんて。これでミハエルはちょっときついかな。
• ダマッタも死亡。ドライの方がタイムが出るけど、ワンミスで終わりって感じなんだろうな。
• セーフティカーが入っちゃったね。
• みんなドライに変えたかな？　もうどこが有利なのか分からなくなった。別画面で河合ちゃんメモを見せてくれ。きっとやつなら各車の燃料積載量とタイヤ交換予想ラップとかがExcelかなんかでまとめられているに違いない。
• あら、バリチェロどうせフライングだったのね。
• モントーヤ、トゥルーリ、ラルフ、ウェバー、ライコネン、ミハエル、クルサード……って感じでレース再開。上位でタイヤ交換＆給油済みなのはミハエル以外に誰がいたっけ？
• さて、掃除機をかけている間に何が起こったかな。ラルフが回転しているのはちらっと見かけたんだけど。どうやたまたペースカーが入っているっぽいな。よく分からない止まり方をしたウェバーの後始末のためか。
• おや、ライコネンより前はすべてペースカー中にピットインしたのね。ライコネンって燃料はどうなっているんだろう？
• あらハイドフェルド止まっちゃった。っつーかスローダウン中にラルフを巻き込んだのか。これは最低だな。ラルフは大丈夫だったかな。
• お、いつの間にかヴィルヌーヴが4番手、バトンが5番手まで上がっている。
• うわー、BARさいてー。なんでこんななんでもないときに同時ピットストップなんだよ。バカじゃないの。
• ミハエルはライコネンがミスするかピットにはいるのをじっくり待つ構えか。燃料量の計算は済んでいるってことかな。結局今年のF1も、コース上で抜くよりもピットで抜く方がメインになるってことか。
• あら、ミハエルの方が先にピットに入ったよ。これはもしかして、マクラーレンが久しぶりに作戦勝ちになるのかな？
• さて、食器洗いをしている間に何が起こったのかな？
• ライコネンアホ。こんなところでペナルティかよ。
• えーっとトイレに行っている間にまた状況が変わったな。ミハエルは何が起こったの？　あれはどこのパーツなんだ？　ピットで外しただけでいいのか？
• あららモントーヤまで自滅か。開幕戦とはいえいろいろありすぎだな。
• モントーヤ、ライコネン、ミハエルという並びは面白いな。でも誰も仕掛けないのか。つまらねーな。初戦はポイントキープ重視ってこと？
• クルサード棚ぼたではあるけれど、マクラーレンの戦闘力自体は結構高そうだな。圧勝できるほどではないけど、去年ほどウィリアムズとの差は大きくなさそうだ。まあフェラーリがトラブってくれないと優勝には絡めないかな。

_ インタラクション2003公開し、侵入可能にするパスワードの使い方 from ZDNet (20:18)

• インタラクション2003公開し、侵入可能にするパスワードの使い方 - http://www.zdnet.co.jp/news/0303/07/nj00_int_spass.html

なるほど、「パスワードは隠さなければならないものだ」という無意識の前提を取り払ってしまえば、公開されたパスワードが有用なシーンも見つかるってことだね。ここで紹介されている運用例は、「物理的にパスワードが見える人しか使えない＆パスワードの有効期限を短くすることで、ある場における共有物を管理する」というものだけど、考えればほかにも応用がありそう……ぽくぽくぽくぽく、ちーん。何も思いつきませんでした。

_ インターネットタイム？ (20:18)

• http://member.nifty.ne.jp/ippo/s_d200303.html#d7_t5

一歩さんのところで知ったインターネットタイム（っつーか、ずいぶん昔に見た覚えがあるな）。何かというと、スウォッチが作った（お遊び的）規格で、スイスにあるスウォッチ本社での0時を基準に1日を1000に分割した全世界＝インターネット標準時間。単位は@で「ビート」と読むらしい。

確かに地域の枠を越えてつながるインターネット上で、共通の時間認識を広めるってのは悪くないよなーと思うけれども、実際のところこんなの全然意味ないじゃん。GMT（グリニッジ標準時）と比較して便利なのは、「時と分」の二つの12進数字で表現されるGMTよりも、0〜1000までの単純な十進数字の方がシンプルだってことと、インターネット標準時という新しい概念を表すためには新しい表現方法を採用した方がわかりやすいってあたりか。でも、それだったらたとえば1200@と書いたらそれはGMTで12:00のことだとしたっていいじゃん。

せっかくインターネット標準時みたいなネタを考えるんだったら、普通の時間系とは違っていることに意味がある規格を作って欲しいなー。たとえば、1日じゃなくて1年を1000000（100万）に分割して、その単位を「@1@」（読み方不明）とするのはどうだろう？　ちょっと桁が多くて直観的じゃないけれども、インターネット時刻を1日なんてせせこましくてローカルな単位で表すよりは、年みたいな世界中で共感可能な単位で表現した方がいいんじゃないか。

そうすると「@1@」はだいたい30秒ちょっとになる。たとえば日本時間で2003年3月7日17:30は、GMTで2003年3月7日8:30だから、だいたい「@0179052@」と表すことができる。年号付きで表すと「@2003/0179052@」って感じか。「今はだいたい2003年の17%くらいを過ぎたところなんだなー」なんて感じの時間感覚が、インターネットタイムよりもよほど面白い気がするんだけど。どうせならば数字は下の桁ほど省略可能にして、「@2003/017-@」なんて感じの表現を許容してもいいかもしれない。適当な名前を付けて広めれ《ら抜き表現》。

• そうだ名前は「ITime」にしよう。「IT＋Time」とか「Internet Time」風でもあるし、「IT好き」な方々にも大受け（わらひ）。
• へっへっへ、ページごとの作成・更新日にITime表記も追加するようにしちゃったぜ。ほかの日付にも追加しよう。

ITime表示Flash（MX）を作ってみようかと思ったんだけど、なんかいまいちきれいに書けない。Flashでsprintfみたいなことってどうやるんだろう？　あと日付時刻関数（クラス）の使い方もなんかこなれていない感じ。ちなみに以下のような感じのActionScript。ITimeは表示用のダイナミックテキストオブジェクトね。そのうちちゃんとしたのを作ろう。ただFlashは会社のなんだよなー。JavaScriptかJavaAppletにしておいた方が無難かなー。だれかカッコよくてジャマじゃないの作ってプリーズ。

now = new Date();
year = now.getUTCFullYear();
current = Math.round(
    Date.UTC(now.getFullYear(), now.getMonth(), now.getDate(),
    now.getDay(), now.getHours(), now.getMinutes(), now.getSeconds())
  / 1000);
start = Math.round(Date.UTC(year, 0, 1) / 1000);
end = Math.round(Date.UTC(year + 1, 0, 1) / 1000);
currentITime = Math.round((current - start) * 1000000 / (end - start));
currentITime = Math.round(currentITime);
max = 7 - currentITime.toString().length;
for (i=0; i<max; i++) {currentITime = "0" + currentITime;}
ITime = "@" + year + "/" + currentITime + "@";

_ remote trackback　/ 文字化け from StrangeIntimacy (20:18)

• remote trackback　/ 文字化け - http://jouno.s11.xrea.com:8080/b2/index.php?p=71

TrackBackの文字コードを統一するのならばUTF-8が無難な選択でしょうけど、現時点ではまだそれは厳しすぎると思います（グローバルな標準環境として、海外のMovableTypeユーザーの存在も考えつつ）。となるとやはりなんらかの形で送信側が文字コードを示し、受信側はその指定をみてそれなりに対応するというのが現実的でしょう（うちみたいに送信側がわざわざ相手の文字コードに変換してあげてから送信するのはあくまでもイレギュラーな対応。というか私の趣味）。

あと、TrackForward（というかTrackBack送信履歴）については、うちではそのうち実装する予定です。やっぱりTrackBackを送った履歴が見えないのは不便ですよね。うちの場合はコメント欄＋トリップ欄でTrackBackを表現しているんで、その手の拡張は簡単。その代わり、TrackBack一覧をRSS出力するためには、テキストをもう一度Parseしなければならないので面倒だけど（だからまだ実装していない）。

それよりも、しばらくTrackBackを使っていて思うのは、TrackBackをそのまま採用するのではなく、TrackBack的な機能を持つ新しい規格を考えるという選択肢は、やはりまだアリだよなーということ。TrackBack的な機能を実装する意義は大きいと思うけれども、現在のTrackBackの仕様自体はそれほどいいと思えない。

そこで他力本願。tDiaryあたりでああいうP2P的な相互通知の仕組みを実装してくれないかなー。あそこが実装すれば日本のデファクトスタンダードになりうるだろうし（はてなダイアリーあたりでも真似して実装してくれそう）。TrackBackとの最低限の互換性も保っているとなおよい。

_ ちょっとましになったかな

先週の金曜日から昨日あたりまでなかなかすごい感じで、ちゃんと朝晩薬を飲んでいても、クスリが切れかかる時間帯（朝起きてすぐと夕方過ぎくらい）にはちょっとキていたんですが、今日はずいぶん楽になった気がする。このくらいなら（クスリが効いている間は）マスクなしでも大丈夫そう。

_ smarty_modifier_json

今後JSONを使う機会は多くなるだろうけど、JSONライブラリのどれを使うべきか決め手に欠ける。あと、「サーバーとクライアントでテンプレートを共有したい場合」なんてことも考えつつ、

function smarty_modifier_json($var)
{
    require_once 'HTML/AJAX.php';
    $jsonSerializer =& new HTML_AJAX_Serializer_JSON();
    $json = $jsonSerializer->serialize($var);
    return $json;
}

のようなSmartyプラグインを用意して、

{if $mode == 'json"}
{$data|json}
{else}
{!-- $dataをHTMLとして展開するコード  --}
{/if}

なんて書くようにしておくと、JSONライブラリを差し替えるのも比較的楽かも。将来性を考えると、Zend Frameworkに入っているZend_Json_Encoderあたりが良さそうかなー。

あとsmarty_modifier_jsonの中で

header('content-type: text/javascript; charset=utf-8');

までやっちゃうと副作用が大きすぎるかな？

そういや

{if $mode == 'php'}
{$data|serialize}

とかも一応対応しておいた方がいいのかな？　この前ちょっと話題になっていたよね。

_ 花粉症の薬追加

飲み薬の方が切れたんで3週間分追加＋目がひどいことになっているんで、新しく目薬も追加。リザベン点眼薬25mg5ml。これで楽になってくれればいいけど。

_ しょうもないネタは検索インデックスに無視してもらう仕組み

blogとか日記とか掲示板とか、Web上には日々雑多なテキスト群が増殖しており、自分自身もその一端を担っているわけですが、自分でも「このテキストは、検索インデックスに登録されても意味ないよなー」と思うネタは多々あるわけで、だからといって検索インデックスに登録させるためだけにWebにテキストを公開しているわけではないので、そのまま公開していたりするわけですが、そういうネタを公開する際に、Googleさんとかが「リンクによるページ評価の対象外にしたいリンクにはrel="nofollow"属性をつけてね」とか決めたみたいに、「このテキストは検索インデックスでは無視してね」とテキスト（ブロック）単位で指定できる仕組みがあるといいかもしれない、とか思った。要は<div robots="noindex,nofollow">〜</div>とか指定できればいいのか。

こういう無駄に切れ目がない長文は、ポイントとなる部分を引用するのが面倒くさくて被言及性が低いよね。

_ 2週間くらいためた未読

2週間くらいRSS（Bloglines→Plagger→Gmail）を見ていなかったら3000エントリーくらい未読がたまってしまい、斜め読みしながらがんがん消していっても、なかなかなくならない。たまった未読エントリー群に対して、はてブに登録されているかどうかを基準にフィルタリングする仕組みとかあると便利そうだな。ストレージがGmailじゃなければ作るのも難しくないんだけど。Gmailにそういう拡張フィルターを突っ込む方法はないものか。ThunderbirdでPOPで取って来つつ、自前拡張でフィルタリングとかならできるかな。