PodCastingを拡張して、iTunes Music Store上の試聴曲やローカルのiTunesジュークボックスライブラリ内にある楽曲データをPodCastingの番組内から再生可能にするソフトウェア「PiyoCast」の開発が、PowerBook G4/667のクラッシュ（画面のヒンジが折れたので唯一の開発場所である通勤電車の中で運用できなくなった、、）、および年末年始の風邪によって遅れを見せる中、ようやく「実行環境はMac OS X 10.3.9をサポートしない」「Universal Binaryで提供」という決定により（クラッシュしたPowerBook G4はMac OS X 10.3.9の環境で動いていた）、最終局面を迎えつつある。
よく考えれば、機能自体はほとんど完成しているのである。もう、βとはいえない完成度にはなっている。
途中で欲を出してデータフォーマットを変更したり、リバースエンジニアリング対策をやっている間にちょっと時間がかかってしまっていたのだ。AppleScript（正確に言えばXcode＋Interface BuilderのAppleScript Studio）でプログラムを作っているので、コンパイル済みScriptをバイナリダンプすれば、なんとなくそれっぽい文字列とかshellを叩いてごにょごにょしている部分などは処理内容が分かってしまう。
かくして、プログラムが公になる前にそれらの暗号化やら復号化やらデータフォーマットの変更やらを行っていた。
ほかに、システムのネットワーク設定からProxyサーバの情報を取得しようとして、電車の中でplistファイルと戦っていたのだが、か〜なり面倒で苦戦している。当初はProxyサーバを設定しているような環境には対応しないことを明記すべきか。shellレベルのUnixな世界のツールで何かProxyの設定を取得できたら楽ができそうな気がする今日このごろだ。
リバースエンジニアリング対策という問題においては、ひとりAppleScript Studioのみが問題になるわけではない。Objective-Cで作ったCocoaアプリだってダンプすればけっこうなことが分かってしまう。
ここまで作ってみて、AppleScriptのファイルが20本以上、合計行数が2000行は下らないというコード量になってきた。サブルーチンのたぐいはメイン部分から追い出してライブラリ化してあるものの、全体の見通しがえっらく悪くなってきている段階だ。
この手の「AppleScriptで作成した膨大なプログラムの集合体」アプリケーションというのは、構造的に問題を抱えている。AppleScriptがスクリプト言語であるがゆえに、Mac OS X本体側でバグが出たり仕様の変更が行われると、その影響をモロにかぶってしまうのだ。
通常のObjective-CやC++で作成したバイナリなら、おおよそのところでOSのバージョンが上がったからといってそんなに気軽に動作が狂ったりするものではない。それが、AppleScriptならあり得るのだ。
AppleScriptで作ったプログラムは、OS環境のバグ汚染による影響をそのままストレートにかぶってしまうわけで、生き物で例えるなら、皮膚もウロコもないクラゲのような生物のイメージだ。クラゲよりも下等なアメーバとかゾウリムシといえるかもしれない。
そんなわけで、そーゆー感じの構造の巨大なプログラムを「はい、これがアプリケーションですよ」といって配ることにはもんのすごい勇気が必要になる。Web上でいろいろ配っているが、それもこれも、こういうPiyoCastのような「本気」のアプリケーションの配布を突然行ってトラブルを出さないように、日頃から動作実績を作っておくという点に目的がある。
で、US Appleの開発チームがOSのアップデートのたびにまいどまいどバグを出してくれるので、プログラムを作る方は戦々恐々といった状態だ。
もう、開発チームを全員ムチ打ちにしたぐらいでは気が済まないぐらいの勢いで不愉快である。毎回、あのバカどものファッキンな仕事のせいで不利益を被っている。
そんなことを考え出すと、実に精神衛生上よろしくない。何か有効な対策はないものか、と考えてしまう。
……で、それを思いついたのだ。まったく関係ない話がそのまま使えることに。
Unit Testだ！
いままでに作ったすべてのサブルーチンをUnit Test用アプリにブラ下げて、実行結果が期待どおりかどうかすべてチェックさせるのだ。通常、これはプログラムのバグ抜きを自動で行うために行うものだが……われわれは、これを「Appleがバカをやった場合に足を引っ張られないようにする」ために行うのだ。
ただ……そのためには、OSのバージョンを固定したUnit Test用専用マシンが必要に（ーー；；
そこまでかんがえてハタと思うのである。これは、Apple自身が行うべきことではないのか、と。そして、絶対にApple自身はそれを行っていないであろうことも確信するのである。
Proxyが云々というのは、Mac OS Xに標準添付の「URL Access Scritping」では問題にならないのですが、curlを使ってshell経由でダウンロードしたいような場合、curlがシステム側のProxy設定を考慮しないで通信するため、別途Proxyの設定を取得して、curlのオプションとして指定してあげなくてはならないというお話であります。