WWDC2007 参加レポート
　　　　　　　　　名古屋学芸大学大学院　メディア造形研究科　渡辺 徹

　初めまして、名古屋学芸大学大学院メディア造形研究科の渡辺徹と申します。
　今回、MOSAからのご好意にて、私は学生参加者としてWWDCに初めて参加をすることができました。私は開催日の三日前から観光も兼ねて渡米し、サンフランシスコに滞在しました。アップルストアの訪問はもちろんのこと、サンフランシスコの街の観光を一緒にできたことを感謝しております。

　私はWWDCがはじまるまでは、中華街やフィッシャーマンズワーフに行ったり、SFMOMAやSan Francisco Design Center、Asian Art Museumなどで芸術鑑賞をしたりとSFを満喫し、充実した時間を過ごすことができましたが、AppleCompany Storeに行けなかったのが残念でした。
　今回、私はユースホステルに滞在しておりましたが、WWDC開始前からホテルでは、参加者であろうと思われる外国の方たちが、アップルのラップトップを持ち歩く様子をたくさん目にしました。本当に異常なくらいMacを所有している滞在者が多く、ユースホステル内にあるフリースペースでMacのスクリーンを眺める光景をよく目にしました。
　PCを所有している滞在者が、ほぼMacであったことに驚きを隠せないほどでした。サンフランシスコでは、あたりまえのことなのかな？　と思うほどでした。

　サンフランシスコは気候を含めとても過ごしやすく、何をするのにも非常によい環境で、いつも頭がフル回転で良く回りそうであることに羨ましく感じました。
　またサンフランシスコのアップルストアにて、一番驚いたことは、ワークショップが充実していること。常に何かのワークショップが行われています。スケジュールはショップのオープンからクローズまで全て組まれていることに、アップルの普及率が高いのだと思いました。
　日本でも、特に私の住んでいる街のストアでも、より多くこのような機会があったらもっとよい環境になるだろうと感じるほどでした。私は外国のアップルストアの訪問は、今回が初めての体験だったのですが、店内のマーチャンダイジングやスタッフの対応・サービスは、私が思っていた通り、日本のストアと同様、一貫した展開をし、統一性を持っていることにアップル社の偉大さを感じました。

　ジョブス氏の基調講演は、今回の参加人数が多くなってしまったために、学生スカラシップ制度を受けた参加者は、別部屋でのモニター鑑賞になってしまいました。私はその事情を当日に知りまして、ジョブス氏が同じ会場内にいるのにと思うだけで非常に残念でした。しかし、その他のセッション及びラボなどは不自由なく受けることができました。
　セッションで一番印象を受けたことは、アップル社のメンバーのプレゼンテーションが本当に素晴らしいことです。技術的スキルは当然パーフェクトではありますが、更に表現力が素晴らしいと思いました。
　私は、Contents and Media と Graphics and Imagingを中心にセッションを受けましたが、どれも魅力的な内容で更にプレゼンテーションが素晴らしいだけに分かりやすく、内容に入りやすいことが印象的でした。どのセッションも概ね個性豊かなプレゼンテーターで、大げさですがアップルのデベロッパがスーパースターに見えてくる気がしました。

　日本からは私を含め十人に満たない学生が参加していましたが、世界中の学生参加者の割合を考えると少ないものです。またアジア圏の学生の割合を考えても非常に少ない印象を受けました。今後、日本からもっと多くの学生参加者がでてくるとApple Design Awardsを受賞する学生が出たりなどと面白くなりそうなのにと思いました。
　また気になる点が一つありました。世界中から参加している学生が、それぞれ出身国が別々なのにも関わらず、おおむね英語を使って頻繁にコミュニケーションを取っていた点です。私にとっては普段あまり経験できないことだけに、魅力を感じました。
　コミュニケーションといえば思い出すのは、それらの学生参加者たちがiChatを起動したときに表示されるメンバーリストの項目が多かったことです。常に数十人のメンバーがリストアップされていて、びっくりすると同時に、初めての経験で感動してしまいました。

　話を戻しまして、セッションも素晴らしく、世界中の参加していた学生とコミュニケーションが取れることの素晴らしさをWWDCでは常に感じました。また学生を対象とした期間限定で「Getting the most out of WWDC」と題した就職フェアが開催されていまして、様々な企業の人事マネージャと会う貴重な機会があり、私の英語力が優れていたなら積極的にアプローチをしたいものでした。非常に悔しく思います。

　サンフランシスコの会場付近で行われたバッシュの感想は、まずはじめに公立公園でパーティを開催するアップルという企業がすごいと思ったこと、さらにその内容もアップルの製品同様に考え込まれて企画されてると感じ、連日続いたセッションの疲れからリラックスできる内容でした。
　食事も学生の身分である私からすると、すごくおいしく、私がアップルのセンスの良さ、繊細さを感じたのは、会場の空間は気を抜いていないことは当然ですが、お皿やナプキンまで気を抜いていないこと。ナプキンは黒色を使用していたんですね。このバッシュの企画はアップルの誰がしているのだろうと思いました。私はWWDCで行われたセッションは、当然のこと満足いく内容でしたが、さらにセッション以外にかいま見るアップルのセンスの良い気遣いにも感動しました。

　WWDCに少しでも興味のある方は、とくに学生の方は是非参加してほしいと思います。

●執筆者プロフィール
名古屋学芸大学大学院　メディア造形研究科2年　渡辺 徹
　現在、名古屋学芸大学大学院にて映像メディアを専攻し映像メディアの研究をしています。作品制作の自由度を高めたいために、マックでのプログラミングを勉強しています。

「Wonderful Server Life」　　第49回　　田畑 英和

　 〜環境設定編〜

　WWDC07も終了し、参加した方々は会場で配布されたLeopardのベータ版を試していることかと思います。ムービーも公開されている基調講演ではLeopardとWindows版Safariの話が中心で、Leopard Serverについてはなにもふれられていませんが、Web上ではその内容がすでに紹介されています。

・Leopard Server Sneak Peek
http://www.apple.com/server/macosx/leopard/
・ニュースリリース
http://www.apple.com/jp/news/2007/jun/11leopardserver.html

　といいましても、ここで紹介されている内容は基本的にはWWDC06のころからすでに紹介されていたものですが、画面のスクリーンショットなどは最新のビルドに合わせて差し替えられています。
　前回から解説を始めました「環境設定」についても若干の説明があり、新たに「ペアレンタルコントロール」「Dashboard」「Front Row」などの項目が加わっていることが分ります。
　ベータ版をすでに入手した方々は、新機能についての確認も重要ですが、既存の機能がどのように拡張されているかもチェックしてみてはいかがでしょうか。

◇環境設定の設定手順
　環境設定は「ワークグループマネージャ」を使って設定しますが、大まかな手順としては次の3ステップになります。

1) ツールバーから「環境設定」を選択
2) 左側のリストから環境設定の対象となるアカウントを選択
3) 画面右側から任意の項目を選択して「環境設定」を設定

　設定するパラメータは項目によって様々ですが、サーバ上で設定した環境設定は、ディレクトリサーバ上で管理され、クライアントへと適用されることになります。
　設定した環境設定の内容がどこに保存されるかですが、ユーザに設定した環境設定はユーザレコードに、グループに設定した環境設定はグループに、コンピュータリストに対して設定した環境設定はコンピュータリストのレコードに保存されます。

◇環境設定の項目
　それでは次に、具体的にどのような環境設定の項目があるかを紹介していきましょう。一部アカウントの種類によっては設定できない項目もありますが、Tiger Serverでは合計14種類の環境設定を管理することができます。

・Classic
　　Classicの起動や詳細設定、アップルメニューの制御
・Dock
　　Dockに配置する項目および表示の設定
・Finder
　　環境設定、メニューの制御、表示の設定
・アプリケーション
　　使用できる、または使用できないアプリケーションの設定
・インターネット
　　メールおよびWebブラウザに関する設定
・システム環境設定
　　「システム環境設定」で利用可能な項目の設定
・ソフトウェア・アップデート
　　ソフトウェア・アップデート・サーバのアドレスの設定
・ネットワーク
　　各種プロキシサーバの設定
・プリント
　　プリンタリストおよびアクセス制御の設定
・メディアアクセス
　　CD/DVD/記録可能ディスク/内蔵ディスク/外部ディスクのアクセス制御
・モバイル環境
　　モバイルアカウントおよびホームの同期設定
・ユニバーサルアクセス
　　画面表示やキーボード/マウスなどのユニバーサルアクセスの設定
・ログイン
　　ログイン項目やログインウインドウの設定、ログインスクリプト/ログア
　　ウトスクリプトの設定も可能
・省エネルギー（コンピュータリストにのみ設定可能）
　　省エネルギーおよびスケジュールの設定

　クライアント上の「システム環境設定」で設定可能な項目もありますが、な
かには設定できないような項目もあります。また、項目によっては適用可能な
クライアントのOSのバージョンが限定されているものもあります。それでは、
次回はより詳しい設定方法について解説していきたいと思います。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
つづく

小池邦人のCarbon API 徒然草（2007/06/22）

〜　Carbonモダンアプリケーションへの道（その17）　〜

今回は、ファイル処理の色々な話題を集めてみました。ファイルパス名の扱い、エイリアス処理、ディレクトリ・カタログからファイルを抽出する処理などです。

今まではファイル保存場所を特定するためにFSRefを用いましたが、Mac OS Xになってからは、そのUNIX遺伝子の影響でファイルパス名（POSIX Path）が使われることが多々あります。例えば、環境設定にユーザの好みのファイル保存場所（フォルダ）を記録させておきたい場合には、ファイル選択ダイアログ（Navigation Service）でフォルダを選択させ、得られたFSRefをパス名に変換してからテキストとして保存します。Navigation Serviceで得たFSRefをパス名に変換するには、次のFSRefMakePath()を利用します。

OSStatus  FSRefMakePath(const FSRef *ref, UInt8 *path, UInt32 maxPathSize);

maxPathSizeにはパス名用のバッファ最大サイズを設定しますが、まあ1000もあれば問題ないでしょう。返ってきたPOSIX PathはUTF8でエンコーディングされていますので注意してください。逆にパス名からFSRefを得るにはFSPathMakeRef()を用います。APIから返されるisDirectoryは、そのパス名がファイルなのかディレクトリ（フォルダ）なのかを示します。ディレクトリの場合には、isDirectoryにtrueが代入されるわけです。

OSStatus  FSPathMakeRef(const UInt8 *path, FSRef *ref, Boolean *isDirectory);

ちなみに、ファイル保存場所を指定するもうひとつの方法は、CoreFoundationに定義されているCFURLRefを使うことです。しかし、CFURLRefはFileマネージャではほとんど用いられていません。ボリュームパスをCFURLRefで返すFSCopyURLForVolume()を含めて、定義されているAPIは4つのみです。CFURLRefの利用方法や詳細については、ヘッダファイルのCFURL.hを参照してみてください。

ところで、環境設定にフォルダのパス名を保存しておいても、ユーザがフォルダ名を変更してしまうと、そのパス名が無効になってしまう場合があります。これは、保存場所をパス名で管理している時の大きなデメリットです。こうした事故を防ぐために、Macintoshのファイルシステムには、もうひとつ便利なファイル保存場所管理の仕組みが存在しています。それがAliasマネージャです。

Aliasマネージャを用いると、一度記録されたボリューム、フォルダ、ファイルを、あらゆる手段を用いて探し出してくれます（ファイル名を変更したりしても大丈夫）。また、対象がネットワークボリューム内であれば、それをマウントする処理までも受け持ってくれます。Aliasは大変便利な仕組みでしたので、Mac OS 9時代には多種多様な処理に利用されていました。筆者も、画像データベースで保存したファイルの管理としてAliasを重宝していました。しかし、何故だかMac OS Xでは積極的に活用されていません。Cocoaには同様なメソッドが存在しないという話も聞きます（Handleを使うのが問題なのか？）。

Alias関連のAPIが定義されているヘッダファイルは、Files.hではなくAliases.hですので注意してください。Fileマネージャと同様に、FSSpecを引数として渡していたNewAlias()やResolveAlias()などは、すべてがDEPRECATED指定となっています。現在ではFSSpecの代わりにFSRefを引数として渡すFSNewAlias()やFSResolveAlias()を利用します。

OSErr FSNewAlias( FSRef *fromFile,FSRef *target, AliasHandle *inAlias );

OSErr FSResolveAlias( FSRef *fromFile, AliasHandle alias,FSRef *target,
                                                    Boolean *wasChanged );

Aliasの仕組みは簡単です。FSNewAlias()にファイル保存場所のFSRefを渡すと、ファイルに関するより詳細な情報が含まれたAliasHandleが返されます。これを保存しておいて必要な時にFSResolveAlias()に渡せば、望んだファイルのFSRefが得られる訳です。両APIに引数として渡しているfromFile（FSRef）は、ファイルを特定場所からの相対検索で見つけ出すための基点です。これにNULLを代入した場合には、絶対位置による検索が実行されます。通常の場合はNULLを代入しておけば問題ありません。

また、Finderではフォルダやファイルのエイリアスを作成することが可能です。状況によっては、自作アプリケーションにドラッグ＆ドロップされたファイルが、通常ファイルなのかエイリアスなのかを判断する必要が出てきます。Aliasマネージャには、そうした判断のためにFSIsAliasFile()が用意されています。もしそのファイルがエイリアスファイルであればFSResolveAliasFile()を使い、ファイル本体（本物）のFSRefを得ることも可能です。

OSErr FSIsAliasFile( FSRef *fileRef,Boolean *aliasFileFlag,Boolean *folderFlag);

OSErr FSResolveAliasFile( FSRef *theRef,Boolean resolveAliasChains,
                                Boolean *targetIsFolder,Boolean *wasAliased );

続いてディレクトリ・カタログからJPEGファイルだけを抽出するような場合の話です。今まで、こうした処理についてはPBGetCatInfo()にFSSpecを渡すことで実現していました。しかし、すでにPBGetCatInfo()もDEPRECATED指定となっています。

short doFileCatalog( FSSpec *sfsc ) // カタログ検索対象フォルダのFSSpec
{
   short        ret=1;
   short        nb=1;
   CInfoPBRec   crec;
   Str255       str;

   while( 1 )
   {
       crec.hFileInfo.ioCompletion=0L;
       crec.hFileInfo.ioNamePtr=(StringPtr)str;
       crec.hFileInfo.ioVRefNum=sfsc->vRefNum;
       crec.hFileInfo.ioFVersNum=0;
       crec.hFileInfo.ioFDirIndex=nb++;
       crec.dirInfo.ioDrDirID=sfsc->parID;
       if( PBGetCatInfo( &crec,0 ) )
           break;
       if(  crec.hFileInfo.ioFlFndrInfo.fdType=='JPEG' )
       {
             //  ここにファイル抽出処理を記述していた
       }
   }
   return( ret );
}

新しい方法は、FSOpenIterator()でFSIteratorを作成し、それをFSGetCatalogInfoBulk()に渡すことで実現します。FSGetCatalogInfoBulk()は
PBGetCatInfo()と異なり、カタログ検索の階層レベルも指示できます。これにより、フォルダ内のフォルダ内といった具合に検索の階層レベルを掘り進めて行くことも可能となりました。

OSErr setIDSpanBase( FSRef *pfsref ) // カタログ検索対象フォルダのFSRef
{
   FSRef            fsref;
   short            err=1;
   FSIterator       itor;
   ItemCount        ict;
   FSCatalogInfo    cat;

   if( ! FSOpenIterator( pfsref,kFSIterateFlat,&itor ) ) // FSIteratorオープン
   {
       while( ! FSGetCatalogInfoBulk( itor,1,&ict,NULL,kFSCatInfoFinderInfo,
                                                   &cat,&fsref,NULL,NULL ) )
       {
           if( cat.finderInfo.fdType=='JPEG' )  // ファイルタイプがJPEG
           {
             //  ここにファイル抽出処理を記述する
           }
       }
       FSCloseIterator( itor ); // FSIteratorをクローズするのを忘れない
   }
   return( err );
}

今回でCarbonのファイルシステムに関する話は終了したいと思います。

さて次回からはWWDC2007の流れを考慮し（笑）開発に利用するFrameworkをCarbonからCocoaへ切り替える作業を順次解説して行きたい考えています。ご期待ください！
つづく　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

ターミナルの向こうから　　　　　　第4回　　海上 忍

〜Mac OS Xのディレクトリ構成(3)〜

　前回は、Finderには現れないUNIX由来のディレクトリのうち、コマンドに関連するものを取り上げました。今回は、ディレクトリ構成に関する話題の締め括りとして、/usrと/varディレクトリ、および/etcディレクトリについて説明します。

・/usr
　UNIX系OSでは、いわゆる「アプリケーション」は処理を行う部分（バイナリ）とライブラリ、その他リソースファイルの3種類に分類することができます。それらのファイルは、「/usr」ディレクトリ以下に用意された用途別のディレクトリに分かれたうえで保存されます。
　アプリケーションのうちバイナリ部分は、前回説明したとおり「/usr/bin」か「/usr/sbin」へインストールされることが一般的です。ライブラリは同じ/usr以下のlibディレクトリ（/usr/lib）、画像やドキュメント類などのリソースファイルはshareディレクトリ（/usr/share）へインストールされます。
　このように、/usrディレクトリはもっぱら”アプリケーション置き場”として利用されますが、サブディレクトリのX11R6（/usr/X11R6）とlocal（/usr/local）は、サブディレクトリとしてbin（/usr/X11R6/bin、/usr/local/bin）やlib（/usr/X11R6/lib、/usr/local/lib）を備えるなど、/usrと同様の構造を持ちます。傘の下に傘がある構造、とでもいえばわかりやすいでしょうか。
　それらファイルのインストール方法ですが、大量にあるファイルを手作業で適切なディレクトリへコピーすることは、かなりの難易度です。アンインストールも同様、ある程度UNIXに精通していないかぎり困難です。RPMやPortsなど、UNIX系OSでパッケージ管理システムが普及してきた背景には、このような事情があるわけです。

・/var
　/varディレクトリは、メールやシステムログなど頻繁に書き込み/消去されるデータのための領域です。もっぱらアプリケーション（コマンド）の領域として利用される/binや/sbin、/usrといったディレクトリは、一度書き込まれると消去されることは稀ですが、/varディレクトリの内容は頻繁に変化（Variable）します。
　Mac OS Xでは、サブディレクトリのvm（/var/vm）をスワップファイルやスリープ時のメモリ保管領域として利用します。システムログの保管領域は/var/log、プリント/FAXのスプール領域は/var/spoolが用意されていますが、内容の閲覧には管理者権限が求められるものもあります。

・/etc
　名称がetcetraに由来することからもわかるように、いろいろなファイルが置かれますが、実際のところ用途はシステム用設定ファイルに限定されています。システムの起動時に参照されるシェルスクリプト（/etc/rc）、Windowsファイル共有機能の設定ファイル（/etc/smb.conf）など、エトセトラという名前の軽さとは相反したシステム管理上重要なファイルが置かれます。
　Mac OS Xでも/etcの重要性は変わりませんが、各種ファイルサーバ機能をON/OFFする設定ファイル(/etc/hostconfig)の変更にはシステム環境設定を使うなど、管理用GUIツールが整備されているため、大半のユーザにとって存在を意識する必要のない領域となっています。

・/dev
　UNIX系OSでは、ハードディスクやCD-ROMなどの記憶装置やネットワークアダプタは、ファイルの形でシステム上に存在します（デバイスファイル）。このデバイスファイルが置かれる領域が、/devディレクトリです。デバイスファイルは、システムにより自動生成されるため、ユーザが直接関与することはありません。
　Mac OS Xでは、認識されたディスクは”/dev/disk*”(*は数値)としてデバイスファイルが生成されます。たとえば、起動ディスクは最初に認識されるので「/dev/disk0」となります。外付けHDDやメモリカードリーダーなどをマウントすると、/dev/disk1、/dev/disk2……と連番でデバイスファイルが割り当てられます。ディスクが複数のパーティションに分かれている場合には、パーティションそれぞれが/dev/disk0s1、/dev/disk0s2などと異なるデバイスファイルが用意されます。ターミナルから「diskutil list」とコマンドを実行すれば、現在の状態を確認できます。

・その他
　一時利用のファイルが保存される「/tmp」も、他のUNIX系OSと共通のディレクトリです。システム起動時に内容が消去されるため、不要なファイルで溢れかえる、ということはありません。
　/coresも、多くのUNIX系OSに見られるディレクトリです。プロセスが異常終了したとき、その時点のメモリの情報を書き出すことを「コアダンプ」、俗に”コアを吐く”などといいますが、吐かれたコアが保存される領域がこの/coresです。/tmpとは異なり、内容が自動消去されることはないため、ときどき内容をチェックしましょう。無駄なコアを削除すれば、わずかながらディスクスペースを稼げます。

◇MOSAからのお知らせと編集後記は割愛します◇

りんご味Ruby　　　第5回　　藤本 尚邦

■

今回は、初回で提示した簡単なRSSリーダプログラム

 require 'rss/2.0'
 require 'open-uri'
 url = 'http://www.mosa.gr.jp/?feed=rss2'
 rss = open(url) { |io| RSS::Parser.parse(io.read, false) }
 puts "-- #{rss.channel.title} (#{rss.items.size} entries) --"
 puts
 rss.items.each { |item| puts item.title }

の3行目

 url = ‘http://www.mosa.gr.jp/?feed=rss2′

を見ていきます。単純そうに見えるこの1行ですが、いろいろと深い意味が含
まれています。Rubyプログラマとしての筆者はこの1行を

 「MOSAのURLを表わす文字列に`url’という名前を付ける」

と解釈します。もう少し詳しく表現すると

 ・MOSAのRSSのURLを表わす文字列オブジェクトを生成して
 ・その文字列オブジェクトに`url’と名前を付ける

となります。「変数urlに文字列オブジェクトを代入する」とは表現しないところがポイントなのですが、それについては後ほど。まず、1番目の文字列の生成の部分を見ていきましょう。

■ 文字列の生成 — 文字列リテラル

Rubyプログラムの実行中には、いろんなところで陰に陽に、文字列が生成されますが、Rubyプログラム中に直接記述できる文字列のことを文字列リテラルといいます。RSSリーダプログラムの3行目「=」の右側には、URL文字列を表わす文字列リテラルが記述されています。

文字列リテラルの記法はたくさんあるのですが、よく使われるものとしては、RSSリーダプログラムの中でも使用されている、シングルコーテーション「’」で囲む記法と、ダブルコーテーション「”」で囲む記法があります。

 irb> 'hello, world'
 "hello, world"
 irb> "hello, world"
 "hello, world"

ダブルコーテーション「”」で囲む記法では、文字列リテラルの中にRubyプログラムを埋め込むことが可能です。埋め込まれたRubyプログラムは、文字列が生成される時点で評価され、その結果(を文字列化したもの)は生成される文字列に展開されます。文章で説明するとわかりにくいのですが、以下の実行例をご覧になれば納得していただけるのではないでしょうか。

 irb> 'hello, world at #{Time.now}'
 "hello, world at  #{Time.now}"
 irb> "hello, world at #{Time.now}"
 "hello, world at Wed Jun 06 11:58:50 JST 2007"
 irb> Time.now
 Wed Jun 06 11:58:52 JST 2007

ダブルコーテーションを使った文字列リテラルでは、「#{」と「}」で囲まれた部分がRubyプログラム(実行時の時刻を示すTimeオブジェクトの生成)として評価され、結果(実行時の時刻)が生成された文字列オブジェクトに埋め込まれています。また、RSSリーダプログラムの5行目

 puts "-- #{rss.channel.title} (#{rss.items.size} entries) --"

では、文字列リテラルにRubyプログラムを埋め込むことによって、その時のRSSのタイトルとエントリの総数を含む表示用の文字列を生成しています。

■ Rubyにおける代入の意味 — オブジェクトのネーミング

Rubyにおける代入は

 変数名 = 値

と記述します。見た目はC言語と同じですが、RubyとC言語とでは、代入の意味が大きく異なります。

 url = ‘http://www.mosa.gr.jp/’

を、C言語プログラマの視点で解釈すると「文字列オブジェクトへの参照を変数urlに代入する」ということになりますが、Rubyプログラマの視点では「文字列オブジェクトを`url’という名前で参照できるようにする」、さらに踏み込んで

 「文字列オブジェクトに`url’という名前を付ける」

と解釈します。なぜ私が「代入」でなく「名前をつける」と表現したいのかというと、その背景には、C言語的な変数入れ物モデルとRuby的な変数名前モデルの違いがあります(どちらのモデルも勝手に命名しました)。

 ・C言語の変数 — 型ごとにサイズや構造の違う値の入れ物
 ・C言語の値   – 自分が何ものであるか知らないただのビット列
 ・Rubyの変数  – 単なるオブジェクト(値)への参照
 ・Rubyの値    – メッセージに応答するオブジェクト

Rubyの変数は全てオブジェクトへの参照(註 — 実際には、効率のために、変数がオブジェクト値そのものである場合もあるのですが、意味的にはすべて参照だと考えて問題がありません)なので、変数の型の違いを意識した発想で考えるよりも、変数をオブジェクトの名前として考える方がわかりやすいのです。

また、Rubyにおいて型とは、オブジェクトが「どんなメッセージに応答できるか」である、ととらえることもできます(DuckTyping – 後述)

代入・オブジェクト・変数については、スコープ・環境のことをおさえておく必要もあるのですが、今回は書くことができませんでした。最後にしつこく、Rubyにおける代入の要点を繰り返して今回の終わりとします。

 Rubyでの代入とは「オブジェクトに名前を付ける」こと

■ おまけ

Rubyの世界では、Duck Typingという言葉がよく使われます。型とは「あるメッセージに対して応答できるかどうか」である、というような考え方です。「ガーガーと鳴いているアヒルのような鳥がいるぞ。ガーガー鳴くのであれば、それがアヒルでも白鳥でも犬でも猫でもバケツでもヤカンでも、たいした問題ではない」と考えるのです。どのクラスに属しているかということではなく、個々のオブジェクトがどう振る舞うかを重視するのです。

今週は何と言ってもWWDCの週ですね。RubyCocoaのセッションなどもあるはずなので、現地でこのメールを読んだ参加者の方はぜひどうぞ。Ruby界では、6/9,10とRuby会議2007が東京で開催されますが(このメールが届くころには終っている)、DuckTypingという言葉の発明者、達人プログラマことDavid Thomasさんのキーノートスピーチがあります。光栄なことに、私もRubyCocoaの話をさせていただくことになっています。自分の発表のことでいっぱいいっぱいではあるのですが、楽しんできたいと思います。

藤本裕之のプログラミング夜話　#116

　承前、いよいよ今回は「分割された nibファイル」そのものを作成する。準備はよろしいか？　ってあっけないほど簡単なんだけどね。以下に示した手順の通りやればもう小学生でも（アルファベットの区別さえつけば）正しくできてしまうでしょうという代物。

　まずは Interface Builderを起動する。他のnibファイル……たとえばXcodeでプロジェクトウインドウ中の nib ファイルのアイコンをダブルクリックするとか、そういうんぢゃなくて直に Interface Builder を起動した場合、「Starting Points」というタイトルのウインドウが表示されてこれから作成する nib ファイルのタイプを選択できる。今回の場合、アバウトパネルを出すウインドウを作るので「Cocoa」の下の「Window」を選べばいい。

　選ぶとすぐにウインドウが開いてnibファイルが編集可能になるわけだけ
ど、ここで見慣れた MainMenu.nib とこのファイルの見てくれの違いに着目しよう。MainMenu.nib では、File’s Ownerのアイコンは……これ、なんて呼べばいいのかな、なんつうか「ファインダがオリジナルのアイコンを持ってないアプリケーションを表示するためのアイコン」だよね。これが今作ったばかりの Window用の nibファイルでは単なる Objectを表すブルーの立方体になっている。もう一つの違いは……そう、MainMenuというアイテムがない。

　さて、この新しい nibファイルの中身を前回コーディングした内容に合わせよう。覚えているだろうか。我々（…と、また共犯者表現をしてしまった。このテの説明文ではやりがちなんだよね。オレです、オレ）はアプリケーションのプリンシパル・クラス「MyApplication」を記述した MyApplication.h に、aboutWindowControllerというインスタンス変数を宣言した（実は今気がついたけどこの宣言の型名のほう、前回はAboutWindowManager* と間違ってた上、クラス宣言が抜けてました。おまけにMyApplicatio.mにあるべき #import文も足りませんでした。お詫びの上、訂正いたします）。

#import 

@class AboutWindowController;

@interface MyApplication : NSApplication {

    AboutWindowController*        aboutWindowController;
}

-(void) awakeFromNib;
-(IBAction)orderFrontStandardAboutPanel:(id)sender;

@end

　この「AboutWindowController」というクラスを、この nibファイルのFile’s ownerにしなければならない。第一に「Class」タブを選んでクラス・ブラウザを表示し、 NSResponder のサブクラスであるNSWindowController に新たなサブクラス「AboutWindowController」を作る。作ったら「Classes」メニューの「Create Files For MyApplication」でソースファイルを……え、前回の最後で「もうこれ以上のコーディングは必要ない」って書いたって？　まだコーディングしてないでしょうが。これらのファイルはないとエラーがでるから作るんで、別に中身は書き換える必要ないの。
　……えっとどこまで行ったっけ？　そうそうソースファイルを作ったら、「Instances」タブを選び、File’s Owner を選択状態に、Inspector で「Custom Class」選び、このFile’s Ownerのクラスを今作った
AboutWindowControllerとする。次にこいつの2つ隣にあるWindow をこいつの
アウトレットとして連結し、あとはそのWindowの中身をアバウトパネルとして
ふさわしいものにして、このnibファイルを「MyAbout.nib」という名前で保存
すればおしまいである。

　MyApplicationをリンクして実行する。どっか書き間違えたり nibファイルの保存を忘れたりしていなければ、アプリケーションメニューの一番上「About New Application…」（今度のInterface Builderではちゃんと日本語リソースを用意してくれるのかね？）を選ぶと、MyAbout.nib からリソースが読み込まれ、アバウトパネルが表示される。
　とまぁ、こんなふうにしてアプリケーションで使う多様なリソースを複数のnibファイルに分割しておける。おじいさんとおばあさんはいつまでも仲良く幸せに暮らしました、めでたしめでたし。

　と、これで nibファイル分割の話は終わるはずだったのだが、前回の原稿を送るとき「 nibファイルの分割話もあと1回でおしまいです。次はなにをやりましょうかねぇ」と書いたら、折り返し「サブビューの中身を別 nibファイルに持つというケースについても解説してよ。特にそんなかに配置されたコントロールからどうやってアクションを受け取るとか」というリクエストが……。なぁるほど、言われてみればそれはワタシ、今までやってみたことありませんでしたわ、というわけで次回WWDC明けは「ビューの中身を 別nibから読み込む」というのをやります。請うご期待。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　（2007_06_05）

高橋真人の「プログラミング指南」第114回

プログラマのためのオブジェクト指向再入門(22)

〜XcodeによるPowerPlant X入門(6)〜

　こんにちは。高橋真人です。早速続けます。
　次はMyApplication.hです。
　MyApplicationというクラスは、最初のプログラム例でも使用したPPx::Applicationというクラスのサブクラスとして定義していますので、まずはPPx::Applicationについて説明します。
　PPx::Applicationのクラス定義をしてあるPPxApplication.hを見てみると分かりますように、アプリケーションの中核を構成しているクラスにしては構造はかなりシンプルです。特に、オリジナルPowerPlantのLApplicationクラスと比較してみると、そのシンプルさは顕著です。
　これは、以前からお話ししている「PPxの開発期間が短かった」ことも理由の一つだと思いますが、同時に「Carbonイベントを積極的に利用するとコード量が少なくて済む」という要因が大きいと私は見ています。
　これも以前からお話ししていることですが、現在のCarbonの仕組みは、APIこそC言語であるものの、設計の背景には所々にオブジェクト指向的な発想が垣間見えます。そのため、Carbonフレームワーク（中でも、CarbonイベントとHIView）の設計意図を汲み取り、うまく利用してやると、C++のようなオブジェクト指向言語と馴染み易い設計ができ、処理の多くをフレームワーク任せにできるため、PPxの側ではそれほど多くを書き込まなくても済むようにできるのです。
　従って、オリジナルのPP（PowerPlant）が旧来のMac OSのToolboxを利用してオブジェクト指向の仕組みを実現するために多くのコードを必要としていたのに対し、PPxの場合にはCarbonの仕組みを利用してコードを大幅に削減しているという側面もあるのです。

　ところで、単純な構造と申し上げたPPx::Applicationですが、これが継承しているPPx::ApplicationTargetとPPx::Attachableという二つのクラスもかなり単純な作りになっています。
　まず、ApplicationTargetの方ですが、これはCarbonイベントのハンドラをインストールする際にApplicationをイベントのターゲットにするためのものです。一般に、Carbonイベントのイベントハンドラをインスールする場合、やり方はすべて同じです。即ち、

・イベントハンドラへのポインタをNewEventHandlerUPP()に渡し、
 EventHandlerUPPを生成。
・生成したEventHandlerUPPをインストールするが、その際、イベントターゲッ
 トの指定――つまりどのオブジェクトにおいて発生したイベントを処理する
 のか――と、処理する対象のイベント（複数指定可）に反応するのか――つ
 まり、イベントターゲットに対して、どのイベントが来た時にハンドラを呼
 び出すのか――の指定を行う。

という手順です。
　つまり、いろんな種類のイベントに対応するハンドラをあちこちに仕掛けておくことで、さまざまなイベントにきめ細かく対応できるわけです。

で、このイベントをインストールするAPIは基本的には一つ、

OSStatus
InstallEventHandler(/*引数省略*/);

というものです。ですが便宜上、以下の6つのマクロ、

/*同様に引数は省略*/
InstallApplicationEventHandler();
InstallHIObjectEventHandler();
InstallWindowEventHandler();
InstallControlEventHandler();
InstallMenuEventHandler();
HIViewInstallEventHandler();

が用意されています。これらは、監視の対象からEventTargetRefというものを取り出し、それと共にハンドラをインストールするという手順、例えばアプリケーション自体をイベントターゲットにする場合であれば、

EventTargetRef targetRef = GetApplicationEventTarget();
IntallEventHadler(targetRef, handlerUPP, ...);

という具合に2ステップで行う必要があるところを

InstallApplicationEventHandler(handlerUPP, ...);

と、1行の呼び出しで済むようになっています。（単に見た目の問題ですが）
　しかしながら、PPxではこれらのマクロを使わずターゲットを明示して、すべてをInstallEventHandler()で処理しています。ただ、あくまでもそれはPPx内部での話でして、PPxを使うユーザーが呼ぶのは、イベントを処理する各クラスのInstall()という関数だけです。（この辺は、実際のコードで見ていただいた方が分かりやすいでしょう。実例は間もなく出てきます）
　要はPPx::ApplicationTargetというクラスは、このような仕組みを助けるた
めに用意されているものです。
　次にPPx::Attachableの方ですが、こちらはオリジナルPowerPlant時代にも持っていたアタッチメントという仕組みを実現するためのものです。アタッチメントというのは、簡単に言いますと、既存のクラスに新たな機能を付加する時、サブクラスを作らずに行える仕組みです。また、機能を動的に付加したり外したりもできます。
　ただ、必ずしもPPxのマスターのために理解が必須というものでもありませんので、この連載では解説はいたしません。PPx付属のドキュメントに解説がありますので、興味のある方は覗いてみてください。
　さて、MyApplicationはPPx::Applicationに加えてもう一つのクラスを継承しています。CommandProcessDoerというクラスです。
　PPxでは、Carbonイベントの処理がフレームワークの担う機能としてかなり大きなものとなっていますが、イベントを処理するためのクラスはすべてEventDoerというクラスから直接・間接に継承したものとなっています。
　CommandProcessDoerは、EventDoerの直接のサブクラスでなく、
SpecificEventDoerというクラスを間に挟んで継承されています。即ち、EventDoer→SpecificEventDoer→CommandProcessDoerという継承関係になっています。
　詳しい仕組みについて興味のある方は、適宜ヘッダファイルを見て確認していだきたいのですが、C++のテンプレートという仕組みを使っているため、少し難しいかもしれません。以下のように理解していただければとりあえず使うことはできると思います。

　EventDoerは汎用のイベント処理のためのクラスで、これは抽象クラスです。このクラスを具体化するに当たり、SpecificEventDoerというクラスとテンプレートによるパラメータを組み合わせることで、特定のイベントクラス、特定のイベントの組み合わせに特化した専用のクラスを定義することができます。
　つまり、その専用クラスの一つが、いま話題にしているCommandProcessDoerなのですが、このクラスが定義されているヘッダファイルであるPPxCommandEvents.hを見てみると、

class     CommandProcessDoer : public SpecificEventDoer<
                                            kEventClassCommand,
                                            kEventCommandProcess> {
protected:
    virtual OSStatus    DoCommandProcess(
                                SysCarbonEvent&  ioEvent,
                                HICommand        inCommand,
                                UInt32           inKeyModifiers,
                                UInt32           inMenuContext) = 0;

private:
    virtual OSStatus    DoEvent( SysCarbonEvent& ioEvent );
};

という感じになっています。
　このクラスが継承しているSpecificEventDoerのテンプレートパラメータ（<と>で囲まれている部分）を見ると、kEventClassCommandとkEventCommandProcessが指定されていることが分かります。
　つまり、CommandProcessDoerは上記のCarbonイベント（kEventClassCommand
とkEventCommandProcessの組み合わせ）を処理する専用のクラスで、このイベントが到達した場合にDoCommandProcess()という関数が呼び出されるということになります。ただし、忘れてはいけないのは、イベントの処理には「ターゲット」という概念がありますので、呼び出されるのはあくまでもこのクラスがインストールされているターゲットに上記のイベントが到達した場合に限られることです。
　この辺の仕組みは、また改めて説明します。

　ただ、上記のクラス定義を見ると分かりますが、このCommandProcessDoer自体も抽象クラスです（DoCommandProcess()の定義の末尾に=0が付いているので）。従って、このクラスの仕組みを使うためには必ず継承を使うことが必須となります。
　ややこしく思えるかもしれませんが、要は、任意のイベントターゲットになり得るクラス（PPx::Applicationとか、PPx::Windowとか）に組み合わせて継承させることで、このイベントの組み合わせを処理できるようになるわけです。

　以上をまとめますと、MyApplicationは、kEventClassCommandとkEventCommandProcessの組み合わせのイベント（以下、単に「HICommandのイベント」と呼びます）を処理するアプリケーションのクラスということになります。

書籍紹介　　　　　　　　　　　　　　　GOOGLE MAPS HACKS

　解説担当:高橋政明

GOOGLE MAPS HACKS
　　Rich Gibson, Schuyler Erle　著
　　武舎 広幸、福地 太郎、武舎 るみ　訳
　　オライリー・ジャパン　　ISBN4-87311-293-1　　定価3,045円

　先週はStreet Viewの衝撃が大きかったのでこの本を取り上げます。
　古い地球儀（大西洋でドラゴンが火を噴いている）が表紙の本の日本語版です。
　この本を読んだ時はGoogle Mapsだけで本が一冊書けてしまう事が驚きで、実のところその事への興味も少なからずありました。でもGoogle MapsのAPIを直接使う事のない私でも十分楽しめる内容でした。もちろんURLのパラメータが知りたい場合には本書は確実に役に立ちます。

　たくさんの情報が載っていますが、そこは最先端を突っ走っているシステムの解説ですから現状とは一致しない部分もありそうです。（日本語版の出版は2006年7月です）
　なお出版社のwebに翻訳者によるサポートページと追加情報へのリンクもあります。サポートページには正誤表があります。
　★正直なところこのサポートページの情報も膨大で、これだけでもかなり楽しめます。サポートページはこの本のエッセンスと言えそうです。

　199ページにはアップルのキャンパスのサテライト写真が同じ場所のVirtualEarthの写真とともに載っています。（ここのリンクもサポートページにあります）

　それにしても地図に衛星／航空写真が加わっただけでも十分に魅力的だったのですが、Street Viewは情報量も見せ方もそして操作性もすごいですね。オライリーからはたぶんStreet Viewに対応した第2版が登場する事でしょう。

　ちなみにCNET Japanの情報によると「1648 Charleston Rd」の住所で手を振っている人たちがStreet Viewチームのメンバーだそうです。ざっと60人いますね、ちょっとした会社以上じゃないですか。（Street Viewを見るには言語を英語にしてwebブラウザを起動してください）
http://maps.google.com/maps?f=q&hl=en&q=1648+Charleston
+Rd&sll=37.422935,-122.085013&sspn=0.014212,0.017209&ie=UTF8&ll=37.424878,-122
.
08334&spn=0.028424,0.048494&z=15&om=1&layer=c&cbll=37.420894,-122.084098&cbp
=1,355.755250200965,0.502066528784644,0

　Googleの開発力の一端がまさに見える上記URLのStreet Viewは一見の価値ありです。このTシャツを着た人の何人かはWWDCにも参加しているかも知れません。

▼出版社のweb（詳しい目次とサポートページへのリンクが載っています）
http://www.oreilly.co.jp/books/4873112931/

◇MOSAからのお知らせと編集後記は割愛します◇

「Wonderful Server Life」　　第48回　　田畑 英和

■　 〜環境設定編〜

　さて、今回から新しいテーマの解説を始めて行きたいと思います。今回から解説するテーマは「環境設定」です。ローカルコンピュータの環境設定といえば、Dockやネットワークの設定を「システム環境設定」を使って行うことになります。
　自分が使っているコンピュータを設定するだけでしたら、もちろんこれでかまわないわけですが、コンピュータを多数管理しなければいけない場合はどうでしょうか。1台1台設定していてはとても間に合いません。
　また、環境設定をいつも特定の状態に固定しておきたいという場合もあるでしょうし、管理者がある程度設定を行ってからユーザにコンピュータを引き渡すこともあるでしょう。

　このようなニーズがある場合、Mac OS X Serverの「環境設定」機能を使えば、サーバ上で環境設定を一元管理することができます。この機能を活用することにより、管理者はコンピュータの環境設定を1台1台設定する手間を軽減することができるのです。サーバで設定した環境設定はネットワーク上のクライアントコンピュータに反映され、クライアント上では設定を変更できないようにすることも可能です。

◇環境設定の準備
　サーバで環境設定を一元管理する場合ですが、まずOpen Directoryを使用することが必須になります。サーバで設定した環境設定はOpen Directoryによって管理されますので、Open Directoryのマスターサーバを設定することが必要になります。
　また、サーバ上で管理されている環境設定にアクセスするために、管理対象となるクライアントコンピュータはすべてOpen Directoryのマスターに「ディレクトリアクセス」を使ってバインド（接続）しておく必要があります。

◇環境設定の対象
　環境設定は次の3つのレベルで管理することができます。

・ユーザ
・グループ
・コンピュータ

　「システム環境設定」で設定する環境設定にコンピュータ全体の設定とユーザごとの設定があるように、サーバで一元管理する環境設定にも、複数のレベルがあります。
　サーバで管理する環境設定では、ユーザとコンピュータに加え、グループ単位での環境設定も可能です。ですので、複数のユーザに共通する環境設定を行いたい場合は個々のユーザに対しての環境設定を繰り返すのではなく、グループに対して設定をすることができます。グループに対して設定した環境設定は、すべてのグループメンバーに反映されます。

◇環境設定の適用範囲
　環境設定を行う場合、サーバ側での設定をいつまで適用するのかを選択することができます。
　まず、設定を常に適用することができます。この設定を行えばクライアント側では設定を変更することができなくなります。例えばDockを右側に表示するようにサーバ上で設定したとします。すると、クライアント側ではDockの位置を変更できなくなります。サーバでこのような設定を行えば、クライアント側では該当する設定項目がDisableになり、変更ができなくなります。
　また、クライアント側での変更を許可するようにも設定できます。この設定を行えば、ユーザが最初にログインしたときにはサーバ側で設定した環境設定が適用されますが、クライアント側で設定を変更したい場合、ユーザはいつでも設定を変更することができます。

◇モバイル用の環境設定
　環境設定の中にはモバイルクライアントのための環境設定も用意されています。ノートパソコンは一般的にネットワークから切り離して持ち運んだりしますが、ネットワークに接続しなければ、Open Directoryのサーバにアクセスすることはできません。Open Directoryのサーバにアクセスできなければ、ネットワークユーザも利用することができません。
　このようなモバイル環境のための環境設定が用意されており、モバイル環境の設定をおこなえば、サーバ上に登録したネットワークアカウントを、クライアントコンピュータに複製することができます。また、サーバ上のネットワークホームと、クライアントコンピュータ上のローカルホームを同期する設定も用意されています。

　というわけで、まずは環境設定についての概要を解説しました。次回からは具体的な設定方法を解説していきたいと思います。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
つづく

開発環境をMacProに移行する　小池邦人

最近、プログラム用のメイン開発マシンをPowerMac G5 2GHz（2CPU）からMacPro 2.66GHz（Dual Core 2CPU）に移行しました。開発作業に対するパフォーマンスについてはPowerMac G5でまったく不満ないのですが。メインマシンをIntel CPU版にする理由が幾つか出てきたので移行を早めることにしました。最初の理由は、開発アプリケーションのユーザの多くがIntelマシンへ移行した結果、ターゲットとなるPPCマシンとIntelマシンの比重が逆転したことです。アプリケーション自体はUniversal Binary版ですので、どちらのマシン環境でも特に問題はありません。しかし、どうしても開発環境マシン（今までだとPPCマシン）での動作チェックの方に重点が置かれ、もう片方のマシン環境での動作確認が若干甘めになるという傾向がありました（筆者だけかもしれないですが）。Intelマシンのユーザがどんどん多くなっていく現状を考えれば、やはり開発マシンもIntelマシンにしておくのが最良だと考えたわけです。

ところで、6月開催されるWWDC2007ではLeopard（Mac OS X 10.5）のβ版が配布されることが確定しました。「Xcode Tools」や、それに付属するFrameworkもかなり変更されることが予想されるので、それらを最新のIntelマシンで試してみたいと言うのが次の理由です。「新しい酒は新しい器に」「鉄は熱いうちに打て」と言ったところですね。続いて、開発アプリケーションの中に早急に64Bit化しなければいけない物があるのが3番目の理由です。もちろんPPCマシンの方はPowerMac G5で大丈夫なのですが、現状手元にあるIntelマシンはCore Duo CPU搭載のものだけで、残念ながら、こちらは64Bitアドレッシングに対応していません。また処理に複数スレッドを使うアプリケーションで、2
コア以上（4コアや8コア）のマシン環境における最適化（チューニング）を
色々と試験してみたかったことも大きな理由のひとつです。

さて、さっそく購入マシンスペックの検討です。筆者は、8コア版が登場した時点で4コア版MacProの価格が値下げされるとふんでいたのですが、残念ながらその予想は外れました。2.66GHz 4コア版の価格は据え置かれ、3GHz 8コア版に拡張すると、何とプラス188,790円もかかってしまいます。この価格レベルはさすがに厳しいですね（笑）。とりあえず、メモリの値段が少し下がりましたので（でも高価）2.66GHz 4コアマシンに4GB（4x1GB）実装し、搭載HDDの容量も500GBにアップしました。これでトータル424,700円となります。購入先はどうしたものかと悩みましたが、ADC Selectメンバーにはマシン1台+周辺機器（モニタなど）の開発機購入割引特典があるので、これを利用することにしました。この特典をうまく使えば、ポイント付販売店で購入するよりも割安と
なります。この特典、昔はSelectメンバー加入2年目からしか有効になりませんでしたが、現在は加入1年目から有効のようです（最終購入価格についてはアップルから見積もりが届く）。

続いては、届いたマシンのセットアップなのですが、初回起動で立ち上がるセットアップアプリケーションで大きな問題に遭遇しました。必要なデータを別マシンから移行するように設定し、FireWire経由でターゲットモードで起動した別マシンを接続したのですが、いつまで経ってもデータのコピーが始まりません？！　ターゲットマシンを別マシンに変更してもダメ、ならばと移行データをネットワーク関連だけに絞ってみてもダメ、ウンともスンとも言いません。筆者の環境だけの問題かもしれませんが、この仕組みがうまく動いてくれないと移行の手間がかなり増えてしまいます。仕方がないので、とりあえず手入力でセットアップし、まっさらの状態から「移行アシスタント」アプリケーションを使いホームディレクトリやアプリケーションをコピーしました。
ただしXcode Toolsはコピーされませんので、再インストールが必要となります。

後はシリアル番号を移行できなかったアプリケーションを再レジストしすれば、以前とほとんど変わらない環境の出来上がりです。唯一違う点はClassic環境が存在せず、Mac OS 9用アプリケーションを起動できないことです。筆者の環境では、そうしたアプリケーションはResEditだけでしたが、20年以上もお世話になってきた旧友との別れは辛いものがあります（笑）。PPC版アプリケーションの方は、Intel版Mac OS Xに搭載されている「Rosetta」が面倒を見てくれます。このRosettaの処理速度と交換性は大変優秀でして、例えば、Metrowerks CodeWarriorなども問題なく起動でき、古いタイプのアプリケー
ションをメイクすることが可能でした。あまり期待していなかったのですが、これにより古いアプリケーションをチェックするためだけに（時々ある）PPCマシンを起動する必要がなくなります。ちなみに、Rosetta上でのMetrowerksCodeWarriorのコンパイルスピードはPowerMac G5 2GHzと同等でした。

当然のことながら、ネイティブアプリケーションのパフォーマンスは素晴らしいの一言です。筆者が開発したEmonCというボクセル表示アプリケーションでの処理（マルチスレッドで複数コアをすべて使う）を比較してみると、PowerMac G5 2GHzで46秒かかっていた処理がたった11秒で終了してしまいます。Xcodeでのコンパイル処理も4倍近いスピードを発揮します。もともと、同クロックのPowerPC G5と比較して、Core 2 Duo CPUは整数処理パフォーマンスが2倍以上ありますので、この結果は予想範囲内です。ただし、浮動小数点演算やSSE演算（PPCのAltiVecに準拠）は5割から7割ぐらいのパフォーマンスなので、中には不得意とする処理もあるでしょう。しかし、こちらのパフォーマンスも、次世代CPUに新しい除算ユニットやSSE4が実装されることで大きく改善される見込みです。

ソフトウェア的な移行が完了したら、続いてハードウェア環境を整えます。MacProは4台までのHDDを内蔵でき増設作業も簡単ですから、RAID等を組むのには最適です。また、開発者は昔々に開発したアプリケーションの動作確認用として旧バージョンOSをインストールしたパーテーションを多数用意します。加えて、これから登場する新OSをチェック（Seeding）するための独立ボリュームも確保したいところです。当然バックアップ用HDDも必要ですから、それらをすべて内蔵ディスクとして管理できるのは実に効率的です。さっそく500GのHDDを2台購入して増設してみました。バルク品であれば500G HDDは13,000円〜15,000円で購入できます。購入したのは日立製でしたが、元々の内蔵HDD（シーゲート製？）よりアクセス音が静かでしたので、こちらをメインボリュームに変更してしまいました。また、MacProには2つのCD-ROMベイがあるので、将来Blue-Rayドライブが安くなったら装着してみたいと考えています。

ところで、今回の移行で一番嬉しかったのは、このマシンが大変に静かだと言う点です。以前のPowerMac G5は処理が煮詰まってくると、ファンが「ブオ〜〜」と飛び上がりそうな轟音を立てうるさくてたまりませんでした。大画面ディスプレイに対応させるためにビデオカードを上位機種へ差し替えてからは特にその傾向が強くなり、歴代で一番「熱くてうるさいマシン」のレッテルが貼られていました。ところが、MacProの方はコア数が倍になったのにも関わらず大変静かです。開発作業中はHDDのアクセス音だけが部屋に響き、あまりにも静かなので、スリープしているのか画面が暗くなっているだけなのか区別が
付きません（笑）。開発中にiTunesを使いバックグランドミュージックを楽しんでいる筆者にとっては、この静寂性が移行最大のメリットかもしれませんね。これから開発環境をIntelマシンへ移行しようと考えている方に、筆者の体験談がいくらかでも参考になれば幸いです。

ターミナルの向こうから　　　　　　第3回　　海上 忍

〜Mac OS Xのディレクトリ構成(2)〜

　前回は、Mac OS XのUNIXレイヤーに関する理解を深めるために、ディレクトリ構成の基本ルールを紹介しました。今回はその続編として、Finderには現れないUNIX由来のディレクトリのうち、コマンドに関連するものを取り上げます。

・重要な役割を持つディレクトリ
　前回説明したとおり、UNIX系OSではファイルシステムの基点（ルート）を「/」で表現します。Mac OS Xの場合、通常は「Macintosh HD」ボリュームのトップ、「アプリケーション」や「システム」などのフォルダが配置された領域が「/」に該当します。
　しかし、そこにフォルダとして表示されるのは「/」以下に存在するディレクトリの一部で、実際には非表示属性のディレクトリがいくつも存在します（第2回の表2を参照）。いずれもシステム起動時などに重要な役割を果たしますが、デスクトップで行うような作業には直結しないため、敢えてFinderから隠蔽されていると考えられます。
　それらの隠蔽されたディレクトリは、前身のNeXTSTEP/OPENSTEPおよびDarwinが開発された経緯から、基本的には他の”*BSD”と同様に配置されていますが、LinuxやSolarisなど他のUNIX系OSと大きく変わるわけではありません。たとえば、freestandards.orgが規定した「Filesystem Hierarchy Standard」※というLinuxを主対象としたディレクトリ構成の統一ルールがありますが、Mac OS X/Darwinと多くの部分で共通していることを確認できるはずです。※：http://www.pathname.com/fhs/

・コマンド専用のディレクトリ
　一般的にUNIX系OSでは、コマンドを保存しておくディレクトリが決まっています。コマンド専用のディレクトリを用意することで、その保存場所を示す文字列（パス）を指定する手間が省けるからです。
　「/」直下のbinとsbinディレクトリ（/bin、/sbin）には、合計で約100のコマンドが配置されています。/binにはシェルやファイル操作などUNIX系OSとしての基本機能を提供するコマンドが、/sbinにはマウントやフォーマット関連などシステム上重大な影響を及ぼしかねないコマンドが置かれることになっています。どちらのディレクトリもシステム専用/読み取り専用であり、任意のコマンドを置くことはありません。
　コマンドを追加する場合は、/usrディレクトリ以下に配置されたbinまたはsbinディレクトリ（/usr/bin、/usr/sbin）へコピーすることが一般的です。この2つのディレクトリの役割分担は、/binと/sbinの関係に似ていますが、システム上の重要度としては一段低くなっています。
　/usr/local/binと/usr/local/sbinディレクトリも利用されます。そもそもはローカルホスト上でのみ実行されるコマンドの置き場、という意味合いがありましたが、1人がUNIXを独占できる（Mac OS Xがまさにそうです）現在、/usr/binおよび/usr/sbinと区別する強い理由はありません。ただし、ソースコードを自力でコンパイルして導入したコマンドは、/usr/local以下へインストールされることが多く、しばしば「コマンドが行方不明」になる事件を招きます。

・コマンドが行方不明になる原因
　ディレクトリ構造の話題から若干外れますが、ここで「コマンドサーチパス」の説明をしておきましょう。
　Mac OS X 10.4/Tigerでは、デフォルトのシェルとして「bash」が利用されます。シェルにはコマンドの入力を受け付け実行するという役割がありますが、その際特定のディレクトリに対してコマンド（と判断した文字列）の有無を照会し、あれば実行、なければ「command not found」としてエラー、という処理を行います。シェルにコマンド置き場を伝えるための情報源が、コマンドサーチパスなのです。
　bashは環境変数（後日説明します）の「PATH」にある文字列を、コマンドサーチパスとして参照します。bashは起動直後に「/etc/profile」を参照するため、このファイルでPATH環境変数を定義する方法が多く利用されますが、Tigerに収録されている/etc/profileでは、PATH環境変数は次のように定義されています。

- - - - -
PATH="/bin:/sbin:/usr/bin:/usr/sbin"
- - - - -

　この文字列がPATH環境変数として定義されると、bashは/bin→/sbin……の
順にコマンドを探します。上の例では/usr/local/binと/usr/local/sbinが含
まれないため、そこに保存されたコマンドはコマンド名だけでは実行できませ
ん。「/usr/local/bin/コマンド名」のように「/」から始まるすべてのパス
（フルパス）を入力する必要があるのです。
　それでは面倒ですから、通常はPATH環境変数を再定義してコマンドサーチパ
スを追加します。前述した/etc/profileを書き換えてもいいのですが、ユーザ
のホームフォルダ直下にシェルの設定ファイル「.profile」（~/.profile）を
用意し、/etc/profileで定義したPATH環境変数を再定義したほうがスマートで
す。

- – - – -
export PATH=$PATH:/usr/local/bin
- – - – -

　コマンドサーチパスの再定義には、bashのビルトインコマンド「export」を
使用します。上の例では、「$PATH」としてその時点のPATH環境変数の値を参
照し、そこへ「/usr/local/bin」を加えています。
　追加できるパスは、/usr/local/binだけではありません。たとえば、次の要
領でPATH環境変数を再定義すると、/usr/local/binとホーム→「command」
フォルダをコマンドサーチパスに加えることができます。「mosaden」の部分
にはユーザ名が入りますので、各自置き換えてください。

- – - – -
export PATH=$PATH:/usr/local/bin:/Users/mosaden/command
- – - – -

　次回は、/usrと/varを中心に、ディレクトリ構造の解説を行う予定です。

書籍紹介　　　　　　　　　　　　　　　　Running Mac OS X

　解説担当:高橋政明

Running Mac OS X
　　James Duncan Davidson 著
　　長瀬 嘉秀 監訳　　株式会社テクノロジックアート 訳
　　オライリー・ジャパン　ISBN4-87311-192-7　　定価3,570円

　2004年に出た少し古い本です。表紙の動物はシェパードで右上に「Panther対応」とあります。原著は「Running Mac OS X Panther」です。価格も比較的高く買うべきか迷った方も多いかも知れません。日本でレパード対応の第二版が出る事を期待しつつご紹介します。

　原著は2003年発行で日本語版も2004年発行ですが、11ページのコラムでIntel対応の可能性について書かれています。最新ではありませんが10.3もまだまだメインで使われている方も少なくないことでしょう。当然今後開発するプロダクトでもサポートしなければならない場合もあると思います。そのような時の資料として貴重な一冊です。
　「4章システムの起動とログイン」にはPantherの起動プロセスが詳しく載っています。もちろんPowerPCの場合の情報ですが、ユーティリティソフトなどを開発する際には重要な情報のはずです。

　目次で確認できますが、ほとんどの章の最後に追加情報があります。本文で深く触れていない事柄についての情報源が書かれています。さらに付録Cに他の情報源が載っています。

　OSの中身や動作は必要に迫られて調べる場合と興味にまかせてたどる場合とがあるかと思います。『こんな仕組みならこんなことができないか？！』とひらめく事もある、かも知れません。手元にあれば日本語で広範囲に学べる書籍と言えます。

▼出版社のweb（詳しい目次が載っています）
http://www.oreilly.co.jp/books/4873111927/

▼原著の10.4対応版（虎の表紙）　pdfのサンプルあり
http://www.oreilly.com/catalog/runmacx2/

◇MOSAからのお知らせと編集後記は割愛します◇