MOSA Multi-OS Software Artists

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からのお知らせと編集後記は割愛します◇