まず、テープメディアの特徴とは？それは、「ランダムアクセスができない。けど安い」ってことだ。つまり、コストパフォーマンス重視のバックアップストレージとして使われる。というわけで、まずメディアの値段を比較してみよう。

比較するメディアは、DV テープと、ディスク系メディアとして CD-R と DVD-R。うん、待てよ、DV に保存できるなら、理屈では DVHS にもすぐ対応できるはずだ。そういえば BluRay もこの間出たよな。というわけで、DVHS テープと BluRay ディスクも比較しよう。あと、HDD のデータも調べる。とりあえず、メルコ（BUFFALO）の「HD-250FB (250G)」で比べてみる。データは yodobashi.com から適当に安めのものを見繕ってきた。

メディア	1 つあたりの容量	1G あたりの値段
DV	10G	43.6 円
CD-R	650M	120.0 円
DVD-R	4.7G	84.3 円
DVHS	32G	23.4 円
BluRay	23G	134.8 円
HDD	250G	171.2 円

というわけでコストパフォーマンスは、DV はなかなか、DVHS は圧倒的、HDD はやっぱり高いね、という感じだ。BluRay はこれから下がるだろう。仮に 1T のストレージを構築するとすると、

DVHS	24,000 円	32 本
HDD	171,200 円	4 台

となり、値段の差は明らかだ！ま、32 本の DVHS を管理する煩わしさはおいておくとして、だ。

じゃ、そんな安いメディアがなぜ使われないのか？技術的なバックグラウンドを見てみよう。FireWire ではデータの伝送の方法に Asynchronous Transaction と Isochronous Transaction の 2 つがある。前者は非同期の伝送で、後者はリアルタイム伝送だ。いろいろと違いはあるんだけど、データの転送保証という観点で見ると、Async は確実なデータ転送が保証されるけど、Iso は保証されない。Iso は A/V データのような、少し途切れてもかまわないけどリアルタイムで送りたい、というときに使われるんだ。

そして、現行の DV カメラは Iso 伝送を使ってデータを保存している（詳しくいうと、コマンドを送る際に Async は使うけど、A/V データは Iso を使う）。だから、データストレージとして使うと、Mac 側からデータが保存されたことを保証する術がないんだ。開発者の気持ちとしては、「そりゃ DV や DVHS テープは安上がりだけど、保存されたかどうかあやふやなものをストレージには使えんよなぁ、、、」という感じだろう。

というわけで、結論。DV Backup は、たまにはきちんと保存できるかもしれないけど、きちんと保存される保証はない。ま、お遊びソフトだね。それとは別に、DVHS テープを使って Async で転送する（つまりデータ保証をする）ストレージデバイスの開発は道があるかもしれない。

とりあえず、Java のツールを試してみようかな、ということで、oXygen をインストール。う、起動遅い（iMac 1GHz）。うう、GUI 重い。ううう、テキストの表示が乱れる。さまざまな障害を乗り越えれば、かろうじて使えないことも無いかもしれないけど、Windows で動かしてみたらあまりの軽快さに脱力。ぷしゅ〜。しばらくは Mac OS X では動かしたくない。

しょうがないので、コマンドラインの簡単な変換ツールを使っているけど、XSLT の修正箇所を探すのが面倒くさいし。

うーむ、自分で作るか？その場合、Cocoa と libxml2 と libxslt かなぁ。Panther には libxml2 入るみたいだし。なんか、Mac OS X には決定的なクライアント向け XML 環境がないよなぁ。

まずは、このサイトを。面白いっちゃぁ、面白いんだけど、使いやすいかと聞かれれば、使いづらい。

このインタフェースってのは、「多数のものを表示して、その中の 1 つを選択する」ってパターンだよね。表示領域が固定している場合は、表示する数が多くなると、各々が小さくなる。

じゃあ、ってんで「ポイントしたら、それを拡大する」というアプローチを取ったわけだ。でもそれをすると、GUI の鉄則「動く GUI は使いにくい」にひっかかってしまう。

もちろん、この使いにくさは Dock に通じる。Dock の場合は、1 次元的だからまだまし、ってとこか。うーむ、ズーミングインタフェースは、まだ練り上げる余地があるな。

あぁ、これやりたかったんだよ！HMDT 本には、Objective-C の説明はあるけど、C 言語の説明がないんだよ。無くてもだいじょうぶだと思ったんだけど、本当はあった方がいいよな。

この連載がどう続いていくかは分からないけど、Cocoa プログラミング入門のためのピースの 1 つになる分野であることは間違いない。勝手に翻訳してしまいたいぐらい。

あと、はじめてのブラウザのつくり方も更新。今回はブックマークメニューの追加。

今回は、Carbon 本が 2 冊。入門 Carbon と Carbon Programming。そして、もちろん、Happy Macintosh Developing Time を追加。著者による説明なので、その辺は割り引いて読んで下さい。

まず、iSight で使われているストリームのフォーマットは何だろう？Apple の iSight のページには、何も書いていない。しょうがないので QuickTime のページに行き、ここから推測してみる。QT のビデオコーデックのうち、TV カンファレンスに使えそうなのは、DV、H.263、Motion JPEG、MPEG-4 ってとこか。それぞれの特徴を書いてみよう。

乱暴に区分すると、こんな感じか。で、iSight は、あの値段、大きさ、画質の評判から判断するに、H.263 か MPEG-4 ってとこか？

また、iChat AV は、DV カムもカメラとして使える。だけど、アップルの TIL によると、PowerPC G3 の Mac では、DV カメラを認識しないらしい。ふーむ。まず、これはハードウェアの問題とは考えられないな。だって、DV カムの認識なんて、FireWire の基本的な機能だけでできるし。

と、思っていたら、MAC お宝鑑定団の 7/17 にいいレポートがあった。まず、

「音声チャットでは au の携帯電話でも採用されている CDMA 方式が採用されており、また、iSight は本体内部で送信する映像をエンコーディング処理している」

とのこと。うん？CDMA って無線のデータ転送の規格じゃなかったの？それって IP ネットワークで使えるの？それとも、CDMA の中で画像フォーマット、音声フォーマットが決まっているっていうこと？それともそれとも、CDMA = MPEG-4 っていうことを言いたいのか？誰か、教えて下さい。

もう 1 つのポイントは、

「iChat AV で DV カメラを使用する場合、DV データを iChat AV で使用出来るデータにエンコーディング処理する必要があり、そのため G4 プロセッサーマシンが必要だと説明していました。」

つまり、DV カムを使う場合は、DV フォーマットを H.263 か MPEG-4 にコンバートしないといけない。それをソフトウェアで行うので、非常に負荷がかかるということだ。ということは、ここから推測だけど、現行の iChat AV は CPU タイプを判別して、ソフトウェア的に DV カムを認識するかどうか、決定しているということかな？G3 だと、負荷が大きくて使い物にならないので、最初から認識しない、と。

あれ、予約の状況を見ると、発売日が 7/23 になっている。延期しちゃったのか？

追記）あ、そういうものなのですか。知らなかったです。すいません。

おぉ、アビーだ！なんか、久しぶりに名前を見たな。アビーは、Mac OS X の土台である、Darwin の前身である、NeXT のカーネルである、Mach の設計をしていた人。乱暴を承知で一言でいってしまえば、現在の Mac OS X の心臓部を作った人だ。Darwin のソースコードを見ていると、カーネルの部分でコードの作者としてアビーの名前が書いてあるものもあるんだ。

この CSO って役職は、Jobs の言葉を信じるなら、いままで統括的な立場だったのが、もっと現場に近くなるということらしい。ま、企業の中の話だから、実際どうなるのか分からんけど。なんにしても、いまとなっては数少ないカリスマ性のあるエンジニアなので、がんばってほしいです。

こんな感じになるらしい。

@try {
    ...
    @throw expr;
    ...
}
@catch (AnObjCClass *exc) {
    ...
    @throw expr;
    ...
    @throw;
    ...
}
@catch (AnotherClass *exc) {
    ...
}
@catch (id allOthers) {
    ...
}
@finally {
    ...
}

こんな感じで、@try、@catch、@throw、@finally が追加されると。あと、@synchronized もあるらしい。

@synchronized (ObjCClass *lock) {
    ...
}

@synchronized は、Java みたいな、スレッドセーフのブロックを示すものでしょう。

前の、使いにくかった NS_HANDLER よりはましだと思うけど。ただ、Cocoa の API がこれに移行するのはいつのことになるんだろう？さらに、Cocoa の API って、ある API は例外投げたり、ある API は nil を返したり、ってバラバラだから、これもなんとかしてほしいな。

個人的には、@finally が好き。いままでは、goto 文を利用せざるを得なかったからな。え？もちろん、goto 文好きだよ。例外処理って、結局 goto みたいなもんだし。

そして、紹介ページも作ってみた。HMDT の本の内容を、けっこう細かく紹介しています。ちょっと長くなってしまったけど、よかったら、読んでみて下さい。