みるくCocoa

MacOSX10.6でCocoa-Javaな環境が綺麗さっぱり消滅した影響で、MIDIWindが動かなくなりました。
で、どうしようか迷っていたのですが、MacOSX10.6対応版を作ることにしました。いちおうターゲットはこれまでと同じ10.4です。そのため一部10.6でDeprecatedとなったAPIを使うことになりますが、これはこのAPIが10.7で消滅しないことを祈るしかありません。

ちなみに、現在の開発状況はこんな感じです。

見ての通りターミナルの画面ですが、別にMIDIWindがコンソールアプリになる訳ではありません。
MIDIWindは、MVCパターンに沿った設計をしています。そしてMVCパターンでは、
・Viewは、ModelとControllerに依存する。
・Controllerは、ModelとViewに依存する。
・Modelは、どれにも依存しない。
となっているので、理論上Modelを先に作る方が、開発効率がいいはずなのです。それで今回は、Modelを先に作って、それをテストするために、GUIの代わりにCUIを作って見ました。見た目はコンソールアプリですが、GUIなものと同等の機能を持っています。

Modelの方はだいたい出来上がったので、これからViewとControllerを作ります。

最近は、新しいネタもないので、前回のネタを引っ張ってみる。

NSArrayやNSDictionaryと言えば基本的なコンテナクラスとして、Cocoaでは頻繁に使われます。

// 要素の取得
id item = [items objectAtIndex: 1];
id name = [record valueForKey: @"name"];

// 要素の設定
[items replaceObjectAtIndex: 2 withObject: @"apple"];
[record setValue: @"red" forKey: @"name"];

しかし、要素の取得や設定が通常のメソッド呼び出しになっていて、コード書くのが少し面倒なうえ、あまり綺麗じゃない。できれば添字を使ってアクセスしたいところだ。

そんな願いはObjective-C++が叶えてくれる。まずは、前回出て来たIdクラスに添字の演算子オーバーロードを追加する。

class Id {
    id object;
public:
    Id() : object(nil) {}
    Id(id obj) : object(obj) {}
    operator id() { return object; }

    // 添字演算子
    Id operator [](NSUInteger index) {
        return [object objectAtIndex: index];
    }
};

NSArrayについては、とりあえずこんな感じに書く。すると添字で要素の取得ができるようになる。

Id items = [NSArray arrayWithObjects:@"red", @"blue", @"Green", nil];

id item0 = items[0];
NSLog(@"item0: %@", item0); // item0: red

Id item1 = items[1];
NSLog(@"item1: %@", (id)item1); // item1: blue

NSInteger length2 = [items[2] length];
NSLog(@"item2 str length: %i", length2); // item2 str length: 5

Id colors = [NSArray arrayWithObjects:(id)items, nil];
id color = colors[0][1];
NSLog(@"color: %@", color); // color: blue

このように２次元配列にいたるまで期待どおりの動作をする。objectAtIndex:と比べれば、その差は歴然だ。この調子でoperator [](NSString* key)を定義すれば、NSDictionary (KVC)もサポートできるようになる。

と、ここまでは簡単なのだが、この調子で要素を設定できるようにするには、ひとひねり必要になる。

class Id {
    ...
    KeyAccesser operator [](NSString* key) {
        return KeyAccesser(object, key);
    }
};

class KeyAccesser {
    id object;
    NSString* key;
public:
    KeyAccesser(id obj, NSString* k) : object(obj), key(k) {}

    // 添字
    KeyAccesser operator [](NSString* k) {
        return KeyAccesser([object valueForKey:key], k);
    }

    // 要素の取得
    operator id() {
        return [object valueForKey:key];
    }

    operator Id() {
        return operator id();
    }

    // 要素の設定
    void operator=(id obj) {
        [object setValue:obj forKey:key];
    }
};

このように中間処理用のクラスを用意すればよい。これで要素の設定ができる。

Id record = [NSMutableDictionary dictionaryWithObjectsAndKeys:
    @"red", @"color1", 
    @"blue", @"color2",
    @"green", @"color3", nil];

id color1 = record[@"color1"];
NSLog(@"color1: %@", color1); // color1: red

Id color2 = record[@"color2"];
NSLog(@"color2: %@", (id)color2); // color2: blue

record[@"color3"] = @"yellow";
NSLog(@"color3: %@", (id)record[@"color3"]); // color3: yellow

以前Objective-CとC++のハイブリッド・オブジェクトについて紹介したが、今回もObjective-C++の面白い応用について紹介する。

Objective-CはC言語を拡張してオブジェクト指向をサポートした言語で、同じくC言語を拡張してオブジェクト指向をサポートしたC++とは、いろいろ比較されることも多い。特にObjective-Cは、Objective-Cに出来てC++に出来ないことよりも、C++に出来てObjective-Cに出来ないことの方が多いため、低く見られがちだ。その一つに、Objective-Cでは演算子オーバーロードができないことが上げられる。

しかし、Objective-C++を使うと、Objective-Cも演算子オーバーロードの恩恵を受けられるようになる。それも、以外と簡単な方法で。

まず最初に、C++でid型のラッパークラスを定義する。

class Id {
    id object;

public:
    // 変換コンストラクタ
    Id(id obj) : object(obj) {}

    // =演算子オーバーロード
    void operator=(id obj) { object = obj; }

    // 変換演算子
    operator id() const { return object; }
};

これは、C++のオブジェクトでありながら、id型の変数とそっくりな動作をする。まず、変換コンストラクタと=演算子オーバーロードにより、キャストなしでObjective-Cのオブジェクトを代入できる。さらに、変換演算子により、キャストなしでObjective-Cのメソッド呼び出しができてしまう。

// 変換コンストラクタ
Id str1 = @"hello, ";

// =演算子オーバーロード
Id str2;
str2 = @"world.";

// 変換演算子
char* s = [str1 UTF8String];

これで準備は完了。あとは、このIdクラスを利用して演算子オーバーロードを定義していくだけだ。たとえば、+演算子オーバーロードは次のように定義できる。

@implementation NSString (Operator)
- (id)op_add:(id)obj {
    return [self stringByAppendingString:obj];
}
@end

Id operator+(Id obj1, Id obj2) {
    return [obj1 op_add:obj2];
}

C++側で、+演算子の処理をObjective-Cのop_add:メソッド呼び出しに変換。あとは、Objective-Cの任意のクラスにop_add:メソッドを実装していくだけだ。

Id str1 = @"hello, ";
Id str2 = str1 + @"world.";
printf("message: %s", [str2 UTF8String]);
// 出力：　message: hello, world.

これで念願の+演算子による文字列結合が実現する。見た目もスマートだ。

このid型ラッパークラスと演算子オーバーロードは、他にも様々な応用が可能だ。たとえば、double型の変換演算子を定義すると、

class Id {
    ...
    operator double() const {
        return [object doubleValue];
    }
};

Id str = @"3";
int num = str + 4;
printf("%d", num);
// 出力：　7

文字列と整数の足し算ができる。まるで、どこかのスクリプト言語のようだ。
また、=演算子をこのように定義すれば、

class Id {
    ...
    void operator=(id obj) {
        if(object == obj) return;
        [object release];
        object = [obj retain];
    }
};

ガベージコレクションがなくても、retainとreleaseの記述を省略できる。
デストラクタを定義すれば、

class Id {
    ...
    ~Id() { [object autorelease]; }
};

- (id)get {
    Id obj = [MyObject new];
    return obj;
}

メソッドから返る時に、autoreleaseの記述を省略できる。
この他にも、Java1.5のようにNSNumberとintとのオートボクシングなど、考えられる応用技はまだまだあるだろう。

Objective-C++は、Objective-Cに新しい世界を開いてくれる。

サーバーをPowerMac G4 Cube(PowerPC G4 450MHz)からMac mini(Intel Core2Duo 2GHz)に入れ替えたことで、サーバーの処理能力が大幅に向上しました。そして、Webサービスだけでは使いきれない、有り余るCPU資源を活用すべく、Xcodeの分散ビルドサーバーを立てて見た。

まず、最初にサーバーのファイアーウォールに穴を開けます。
MacOS X Serverの場合は、サーバー管理ツールのファイアーウォール設定で、「分散コンパイラ　ポート3632」を許可します。

MacOS X クライアントの場合は、システム環境設定のセキュリティのファイアーウォール設定で、実行ファイル/usr/bin/distccdに対して、受信接続を許可にします。
なお、/usrディレクトリ内部のファイルは、初期状態では選択できないので、エイリアスやシンボリクリンクなどをうまく使う必要があります。


つぎに、Xcode環境設定の分散ビルドで、「共有ワークグループビルドのためにこのコンピュータを共有」にチェックを入れる。これで、分散ビルドのサーバープロセスが起動するので、アクティビティモニタを見て、distccdというプロセスが幾つか起動しているのを確認しよう。なお、分散ビルドの設定が終わったら、その後Xcodeを終了させて、ログアウトしても、分散ビルドサーバーは起動し続けます。


サーバー側で分散ビルドのサーバープロセスが起動すると、クライアント側には、そのホスト名などが表示され、ステータスが「共有」になります。もしも、ステータスが赤字で「到達不能」などと出た場合は、Bonjourによってホストを認識しているので、レイヤー２のEthernetレベルではパケットが通るけど、レイヤー３のIPレベルでパケットが通らないということになるので、サーバーとクライアントのIPアドレスの設定や、ファイアーウォールでブロックされていないかなどを調べよう。または、手動でセットとホストを新規に追加し、ホスト名にIPアドレスを直接入力して見るのも手です。
分散ビルドサーバーをうまく認識したところで、「共有ワークグループビルドでビルドを分散」にチェックを入れると、あとは普通にビルドを実行するだけで分散ビルドになります。


うちでは、サーバーとクライアントが、ギガイーサーで接続されているので結構快適に動作します。サーバーもクライアントもCPUがCore2Duoなので、コア数が合計４コアになって、４つのソースファイルを同時にコンパイルするようになりました。

サーバーをPowerMac G4 CubeからMac miniに入れ替えました。もちろん、HDDはSSDに交換してあります。
ほぼ無音で動作していたPowerMac G4 Cubeに比べて、小型冷却ファンの分だけ騒音が増えましたが、スペックが大幅に向上し、さらに省スペースになりました。そしてなにより、SSDを搭載していることで、ある日突然HDDが壊れたりすることもなくなり、信頼度が向上しました。
それと、サーバーのメンテナンス用に小型のキーボードも買いました。
メンテナンスとは言っても、ほとんどのことはリモートで出来るので、このキーボードを使う機会はあまりないけど。ちなみに、このキーボードにはCommandキーに該当するキーがありませんが、MacOSXの場合は「システム環境設定」→「キーボード」→「修飾キー」でCommandキーの割当を変更できるので、なんとかなります。


それから、見ての通りサイトのデザインも更新しました。というか、一番変わったのはデザインよりも中身です。
これまでは、ブログツールにBlojsomを少しカスタマイズして使っていましたが、あまり使い心地が良くなかったので、思い切って自前でブログツールを作りました。
で、当初はJBoss5 + EJB3.0 + JSP + JSF + MySQL5といった構成で開発して、ほぼ完成したのですが、いざMacOS X Server10.6にインストールしようとしたら、JBoss5が無いということになり、JBoss5をダウンロードしてこようと思ったら、どうもJBoss5がついに有料化されたっぽく、簡単にダウンロードできない状態になってました。
EJB3.0を動かすために、別のコンテナを使う手もあったのですが、いろいろ検討したあげく、ここで一気に方向転換して、Tomcat6 + Seasar2 + Mayaa + MySQL5という構成で最初から作り直しました。
Seasar2もMayaaもSeasarプロジェクトで開発されている純国産製のソフトです。
Seasar2はオブジェクトを管理するDIコンテナで、S2JDBCというO/Rマッピング機能も含んでいます。これでEJB3.0に代わって、MySQLに間接的にアクセスしています。
Mayaaは動的なHTMLを出力するテンプレートエンジンです。JSPと同じ位置づけですが、JSPとは違い、HTML内に特別なタグやコードを一切書かないので、JSPのように実行しなくても普通にブラウザでプレビューできるし、Dreamweaverとかで普通に編集できます。ビューとロジックが完全に分離してる理想的なテンプレートエンジンです。

上記に上げたものは、Java関連のものばかりですが、実は今回のブログツール開発に当たっては、Java言語を使っていません。代わりにScala言語を使っています。
Scala言語は、関数型と手続き型のハイブリッドな言語で、JavaVM上で動作します。Java言語とは異なる言語でありながら、Java言語と互換性の高いバイトコードを生成するため、何の苦もなくJavaとの間で相互にメソッドの呼び出しができ、Javaサーブレットも普通に作れてしまいます。
関数型のアプローチで、Java言語よりも簡素にコードが書けて、「コード量はJavaの半分になる」と言われていますが、実際に使ってみてそれも納得できる内容となっています。
一度Scalaを覚えてしまうと、もうJavaには戻れないって感じです。

世間ではiPadの話題が沸騰しているようですが、うちでは7年ぶりにMacを買い替えました。
今まではPowerMac G5(2.0GHz dual)でしたが、今回買ったのはMac mini(2.53GHzモデル)です。
以前はパフォーマンスが欲しくて、ハイスペックなPowerMacを買い続けてきましたが、最近のMac Proだとスペックが高すぎて持て余しそうな感じだったので、安くて、小さくて、静かなMac miniにしました。

しかも今回は、内蔵HDDを東芝製SSD(256GB)に交換したので、通常のMac miniよりも高速です。電源ボタンを押した瞬間から自動ログインでFinderが起動するまでの時間が、わずか24秒です。
買ってきて、一度も起動することなく、いきなりSSDに交換したので、元々の起動速度と比較してどの程度高速になったのか分かりませんが、とにかく速いです。

それから、キーボードとマウスも買い替えました。両方ともBluetoothです。
いままで、MacとWindows機で同じキーボード＆マウスを使うのに、ホスト切替機を使っていましたが、MacとWindowsを同時に起動させることはないので、Windows機にもBluetoothを装備させてキーボードとマウスを共有する構成にしました。
テーブルの上からホスト切替機とUSBケーブルが無くなって、とってもスッキリしました。

Xcodeのテキストエディタには、多くの言語に対応した構文色付け機能があって、予約語などがカラーリングされる。
でも、この構文色付けは、全ての言語を網羅している訳ではないし、実装されているJava言語がJava1.5からの新しい構文に対応していないなど、既存のものも完璧という訳ではない。

そんなわけで、Xcodeで構文色付け定義が書かれている.xclangspecファイルを編集して見ようと思ったのだが、、、どこを探しても.xclangspecファイルに関する情報がない。
まあ、Xcodeのプライベートフレームワーク関係のものなので、Appleが情報を公開していないのも無理はない話なのだが。。。
それで、しかたがないので、自分でXcodeでの構文色付け定義の資料を作ってみた。

.xclangspecは、Xcode3.0以降で使用可能なファイルで、ここに言語の構文定義を書くと、構文色付けだけでなく、コードフォーカスや関数ポップアップまで定義できるようになります。
ただ、なにぶん情報が少なく、手探りの状態で書いた資料なので、全てを網羅している訳でもないし、説明が足りない所や間違っている所も多々あるかも知れない上に、プライベートフレームワーク関係のものなので、いつ内容が変更されるかも分からない状態です。
でも、Xcodeに新たな言語を追加しようとしている人や、構文の色付けなどを自由にカスタマイズしたい人には一読の価値があると思います。

Objective-Cは、C言語にマクロによってオブジェクト指向の機能を追加した言語である。Objective-Cのソースコードは、マクロ展開されてC言語のソースコードになったあと、普通にCコンパイラによってコンパイルするというのが基本原理だ。
そして、このとき、Cコンパイラの代わりにC++コンパイラでコンパイルするものを、Objective-C++と呼んでいる。

Objective-C++によって、１つのソースコード内に２つ言語を混在させることができるようになる。Objective-CのインスタンスもC++のインスタンスも、ただのポインタとして扱えば相互に利用し合う事が可能だ。
しかし、C++コンパイラを使うことによって、Objective-Cのマクロな部分がパワーアップする訳ではないので、ハイブリッドな機能をもったクラスや、ハイブリッドなインスタンスを作ることはできない。あくまで、Objective-C言語 ＆ C++言語なのである。

と、いうのが通説だったが、ハイブリッドな機能をもったクラスや、ハイブリッドなインスタンスは、ある程度までなら実現可能なようだ。それも今まで気づかなかったのが不思議なくらい簡単な方法で。

@interface Hyblid : NSObject {
    int number;
}

- (void)setValue:(int)value;

class Hyblid_ {
    @defs(Hyblid)
public:
    int getValue();
};

@end



@implementation Hyblid

- (void)setValue:(int)value {
    number = value;
}

int Hyblid_::getValue() {
    return number;
}

@end

まず、ハイブリッドなクラスのインスタンス変数は、全てObjective-C側で定義する。そして、Objective-Cのメソッド定義の中に、C++のメンバ関数定義を混在させるような形でクラスを作って行く。このときC++のクラス定義のなかに@defs(Hyblid)と書くのがポイントだ。
こうすると、Objective-CのメソッドとC++メンバ関数の双方で、同じインスタンス変数が参照できるようになる。

Hyblid* obj = [[Hyblid alloc] init];
[obj setValue:123];
NSLog(@"value: %i", ((Hyblid_*)obj)->getValue());
// [出力] value: 123

allocで生成したインスタンスは、型をキャストさえすれば、Objective-CとC++のどちらでもアクセスできる。まさにハイブリッド。

このような事が可能なのは、ようするに、これがC++版のToll-Free Bridgeだからだ。
そういう訳なので、例えば、C++のコンストラクタで、

Hyblid_() {
    isa = NSClassFromString(@"Hyblid");
    [(id)this init];
}

このように実装すると、newでもインスタンスが生成できるようになる。ただし、インスタンス変数が0で初期化されないなど、多少動作は異なる。

Hyblid_* obj = new Hyblid_();
[(id)obj setValue:123];
NSLog(@"value: %i", obj->getValue());
// [出力] value: 123

また、面白いことに、newで生成したインスタンスも、retain countが有効なようで、C++のインスタンスでありながら、Objective-Cと同じ方法でインスタンスの破棄ができる。deleteを使う必要はない。

Hyblid_* obj = new Hyblid_();
NSLog(@"%i", [(id)obj retainCount]); // [出力] 1
[(id)obj retain];
NSLog(@"%i", [(id)obj retainCount]); // [出力] 2
[(id)obj release];
NSLog(@"%i", [(id)obj retainCount]); // [出力] 1
[(id)obj release];
NSLog(@"%i", [(id)obj retainCount]); // エラー！

でも、これで何もかもうまく行くわけではない、ADCのドキュメントにあるように、制約事項は多い。まず、インスタンス生成時の初期化や破棄時の後始末の仕組みが、Objective-CとC++で違う。allocやrelease使ったときは、C++のコンストラクタやデストラクタは呼ばれない。逆に、newやdeleteを使ったときは、Objective-Cのinitやdeallocは呼ばれない。それから、ハイブリッドなクラスから、ハイブリッドなサブクラスを作ることも、ちょっと難しいだろう。

Cocoaは、Objective-Cが持つ動的な特性を最大限に活用したフレームワークであるが、実際のところ、そういった動的なものが必要とされるのは、プログラム全体から見れば、ほんの一部でしかない。プログラムの大部分は、静的な言語のニーズの方が強いのだ。つまり、静的型付を基本とし、ピンポイントで動的型付が使える言語が理想的ということになる。Objective-C++は、そのようなニーズに対応できるのかもしれない。

プロダクティブ・プログラマという本を読んでみた。
プログラムの生産性を向上させる本。ようするにプログラムを早く作るコツが書かれている。

プログラムを早く作るコツには、いろいろあるが、ソースコードを速く書くにはテキストエディタのショートカットを活用せよと、この本の最初に書いてある。著者はテキストエディタに拘りがあるようで、UNIXのviエディタなどと比べると最近のエディタはコピー＆ペーストの機能が弱いとも書いてあった。

よく考えて見ると、XCodeにはカスタマイズ可能なショートカットが沢山あるし、Objective-Cのような言語では、ヘッダーファイルの内容を実装ファイルに頻繁に書き写さなければならないので、コピー＆ペーストは重要な機能の一つだ。

そこで、XCodeのユーザースクリプトを使って、ヘッダーファイル内の@propertyからインスタンス変数定義と実装ファイル内の@synthesizeを自動生成するショートカットを作ってみた。

まず、ここからスクリプトコードをダウンロードする。
つぎに、新規シェルスクリプトを作って、そこにダウンロードしてきたコードをコピーし、出力を「書類の内容を置き換える」にする。

これで準備完了。

あとは、ヘッダーファイルに@propertyを書いて、それを選択し、スクリプトを起動するだけ。一気に複数行選択することも可能だ。

スクリプトを実行すると、ヘッダーファイル内にインスタンス変数定義が追加される。

そして、さらに実装ファイル内には、それらに対応する@synthesize文まで追加される。


このスクリプトにショートカットを設定しておけば、ソースコードの記述がスピードアップすること間違いなしだ。ただ、XCodeはソースファイルの内容をメモリにキャッシュしてるらしく、実装ファイルを自動的に書き換えても、それがすぐに反映されないのが難点だ。。。

Snow Leopardになって、いままでDeprecatedとなっていたCocoa-JavaがJavaブリッジを含めて、綺麗さっぱり消滅しました。
そのおかげで、MIDIWindが動作しなくなりました；；
思えば、OSがバージョンアップする度に、動かなくなってるなぁ〜。MIDIWindは。
今後、JavaからObjective-Cのコードを呼びたいときは、JNIを使えと言うことらしく、JavaNativeFoundationと言ったものが用意されています。
逆にObjective-CからJavaを使う手段はないようです。

そんな訳でCocoa-Javaは消滅しましたが、その他のDeprecatedなAPIは、全部試した訳じゃないけど生き残ってるAPIも多いようで、それなりに下位互換は保たれているようだ。

それと、消滅すると思っていたPowerPCのコードは残ってるようで、オプションでRosettaをインストールすれば、PowerPCのソフトが動きます。どうせ残すなら、もう少しサポートを続けても良かった気もしますが。。。
ただし、MacOSX10.5はPowerPC32bit + PowerPC64bit + Intel32bit + Intel64bitのユニバーサルバイナリだったのが、MacOSX10.6になってPowerPC64bitのコードが削除されました。一応PowerPCは縮小方向にあるようです。
単純に考えると、これで実行ファイルの容量が25%削減されます。OSの容量が減った理由の一つがこれのようですね。

あと、なぜか、XCode3.2では、プロジェクトテンプレートから、Carbon、Ruby-Cocoa、Python-Cocoaが無くなってます。
Carbonはまだしも、Ruby-CocoaとPython-Cocoaは削除するには、少々早すぎますよね。