MOSA Multi-OS Software Artists

目次

• 「Wonderful Server Life」　　　　　　 第31回　　田畑 英和
• 藤本裕之のプログラミング夜話　#105
• 高橋真人の「プログラミング指南」　 第103回
• ニュース・解説　　　　　　　　　　　　　　　 小池 邦人

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

　 〜AFP編〜

　前回まででAFPを利用したネットワークホームの設定方法について解説してきました。今回はこれまでのまとめとして、ネットワークホームを使用するさいの挙動について解説いたします。ネットワークホームの処理の過程を理解しておくことにより、問題が発生したときのトラブルシューティングに役立ちます。

□マウントレコードの読み込み
　クライアントコンピュータが起動すると、まずディレクトリサーバを参照して、マウントレコードを読み込みます。ディレクトリサーバを参照するためには、クライアントコンピュータはあらかじめ「ディレクトリアクセス」を使用してディレクトリサーバにバインドしておく必要があります。
　マウントレコードを読み込めばどのファイルサーバのどの領域をマウントすればよいかが決まります。ちなみに、ユーザを管理するOpen Directoryのマスターと、ネットワークホームを管理するファイルサーバを別々のマシンで運用することも可能です。サーバを分けることによって負荷を分散させることができます。

□ユーザのログイン
　ログインウインドウで認証を行うと、あらかじめ「ディレクトリアクセス」で設定しておいたディレクトリドメインの検索順に従い、各ディレクトリ上に該当するユーザが存在するかどうかを確認します。このときユーザの確認は、必ずクライアントコンピュータ上のNetInfoで管理されているローカルディレクトリから行います。ですので同じユーザ名をもったローカルユーザとネットワークユーザが存在していた場合、ローカルディレクトリ上のローカルユーザのほうが優先されます。
　ローカルディレクトリに該当するユーザがいなければ、Open Directoryのマスターなどのネットワーク上のディレクトリドメインに該当するユーザが存在するかどうかを確認します。
　該当するユーザが存在すればユーザ認証が行われ、ユーザ認証に成功するとログイン処理が継続されます。

□ネットワークホームのマウント
　ログイン後は直ちにネットワークホームが使用できる必要がありますので、ログイン時にネットワークホームが自動的にクライアントコンピュータ上にマウントされます。
　ログイン時にまずユーザごとに設定されたホームの情報が読み込まれます。ホームのパスとしてファイルサーバ上のネットワークホームが設定されていれば、自動的にクライアントコンピュータ上にファイルサーバ上のホームがAFPを使ってマウントされます。このときネットワークホームのマウントはログインしたユーザとしてマウントが行われ、自動的に認証が行われます。

□トラブルシューティング
　このようにネットワークホームを使用したときには、様々な情報を読み込み、背後で自動的に処理が行われます。正しく設定が行われていないとネットワークホームが正常に機能しないことがあります。例えば、ログインウインドウで正しいユーザ名とパスワードを入力しても、ネットワークホームが正常に機能していないとログインに失敗することがあります。
　ログインに失敗した場合は、まずは問題点の切り分けを行いましょう。問題があるとすればたいていの場合、ユーザ認証に問題があるか、あるいはネットワークマウントに問題があるかのどちらかです。
　ログインウインドウからログインする場合は、ネットワークホームが機能していないとログインそのものが出来ない場合がありますが、ローカルユーザでログインしてから「Terminal」上でloginコマンドを使えば、ネットワークホームが使えなくてもネットワークユーザの認証は行えます。
　ですので、「Terminal」上で認証できた場合、おそらく問題はネットワークマウントにあるのではないかという推測ができます。ユーザ認証に問題がないことが確認できましたら、例えば手動でAFPのマウントが出来るかなどを確認して、AFPの動作を確認するようにしましょう。また、複数のユーザで動作確認を行えば、問題が特定のユーザに依存する問題なのかどうかを切り分けることができます。
　問題が発生する場合は、たいていどこかに設定ミスがあるはずですので、落ち着いて設定内容を見直しましょう。

つづく

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

　承前、年の瀬で忙しいのでさくさく行こう。前回掲載したリストの解説である。まずビューオブジェクトのロードが終わった awakeFromNib でregisterForDraggedTypes: を呼んでいるのは自分がドラッグ用ペーストボードに入れたデータを自分で受け取る必要がある場合のため。今回のサンプルはこれがなくても動くんだが、例えば NSTableView におけるアイテムの順番変更などをドラッグ＆ドロップで実現する場合、自分の入れたデータを自分で受け取ることが必要になる。その場合、ここでレジストしておかないと受け取れない。

次の drawRect: でやってることはドラッグ＆ドロップに直接関係ないので割愛。で、その次、mouseDown: の時点で「今ドラッグしてますフラグ」をオフにして、mouseDragged: のなかでこれがオフの時だけドラッグデータをセットする部分は私の勘違い。……つうかソースの使い回しが原因のミスであります。これについては後述。

で、肝心カナメの mouseDragged: 。まずは「ドラッグされるデータ」として文字列　@”Data to be dragged”　を用意し、次にドラッグ用ペーストボードへのリファレンスを獲得。次にこのペーストボードに対して、declareTypes: owner: を送り、これから入れるデータのタイプを申告する。このメソッドの第2パラメータ、owner: には、ここで申告したタイプのデータをこのボードに入れる責任を負うオブジェクトを……回りくどいな。このサンプルでは NSStringPboardType 1個しかデータのタイプを申告していないし、しかも次のステートメントですぐにそれをセットしているのでここは nil でも構わないんだが、そのデータを用意するオブジェクトがこのビュー自身ぢゃない場合など、ここにそのオブジェクトがどれかを申告しておいて、そいつに対して pasteboard: provideDataForType: メッセージが来るのを待ってセットするということが出来るわけ。……なんだけど、このサンプルでは簡単に文字列　@”Data to be dragged”　をペーストボードにセットしてこの処理はおしまい。

さあ次、これが結構大切、実際に画面上をドラッグされて動くイメージを作らなくちゃならない。ああ、見た目の問題ねと思うかも知れぬが、実はこれを端折ると、いくらマウスボタンを押してドラッグを始め、押したまま他のアプリケーションのウインドウの上までポインタをドラッグして行き、そこでマウスボタンを放してデータをドロップした……つもりになっても何も起きないのだ。うそだと思ったらやってみなさい。まぁサボれるとしてもサボったらユーザの顰蹙を買うことは必至だけどね。
　ではその詳細。ペーストボードに入れた文字列をデフォルトの属性で描けるだけのサイズの NSImage オブジェクトを作り、そこに描画する。ここでは描画もデフォルトの属性のままでやっているが、それっぽくしたければフォントの色をグレイにしたり半透明にしたりすることも可能。なお、サンプルでは属性を持たない NSStringPboardType しか入れてないのでこれでいいが、リッチテキスト（NSRTFPboardType）などをサポートした場合にはこのイメージにもそれなりの見た目のものを用意するべき。
　イメージができ上がったら、NSViewのdragImage: at: offset: event: pasteboard: source: slideBack: メソッドを使ってこれを……なんというのかな、「ドラッグされるイメージ」としてセットする。at: にはイメージを最初に表示する左下の座標をこのビューの座標系でセット。次の offset: はmouseDown: が発生した場所を基準にした現在のmouseの位置……なんだが、Mac OS X 10.4以降では無視されるので気にしない。event: は現在のイベント。ペーストボードも今データをセットしたペーストボード。source: にセットするのはこのドラッグ・オペレーションのコントローラ・オブジェクトで、NSDraggingSource プロトコルに適応している必要がある。具体的には最低限以下のメソッドをインプリメントしておけと……いうんだが、これ無くても別に支障がないみたいなんだけどね。

- (unsigned int)draggingSourceOperationMaskForLocal:(BOOL)isLocal;

とにかく、普通はビュー自身、場合によってはビューを含むウインドウをセットする。上のメソッドが何を返すべきかは NSDraggingSource プロトコルのドキュメントを参照のこと。最後の slideBack: はこのデータのドロップが拒否されたとき、つまり NSStringPboardType のデータを受け取らないオブジェクトの上でドロップされた場合にこのビューまで跳ね返されるアニメーションを行うかどうかのフラグである。
　で、さっきの「後述」部分、このメソッドを呼ぶと、これはドラッグが終わる（どっかでmouseボタンがリリースされる）まで戻ってこないので、ドラッグペーストボードにデータが入ったままこのmouseDragged:が重複して呼ばれることはない。なので、前回リストのフラグのことは忘れてくだされ。

はぁはぁ、駆け足したがなんとか年内にここまでこぎつけたぞ。来年1月からは NSTableView に話題を絞って上にも出てきたアイテムの順番変更などのやり方を説明する予定。それではみなさま、よいお年を。
（2006_12_14）

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

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

〜カプセル化について(2)〜

　こんにちは、高橋真人です。
　さて今回は、前回お話ししたMLTEの例でカプセル化ということについてのお話をしたいと思います。
　MLTEはかなり大きな機能のセットです。そのため、「お任せ」で使う分にはかなりラクができます。つまり、使う側は余り多くのコードを書かなくてもいろいろな機能を実現できるのです。しかし、MLTEが標準で提供しているものと違ったことをしようとすると複雑な手間を強いられることがあります。
　PowerPlantでは、多くのクラスがMac OSが提供している機能を包んだ（ラップした）形で設計されています。たとえば、LWindowというクラスは、WindowRecordという構造体をラップする形でクラスが構成されています。こうすることで、フレームワーク利用者は、WindowRecord（もしくはWindowRef）を直接扱うよりも、少ない手順でウインドウを操作することができるようになるわけです。
　さらにLWindowが提供する機能では足らない場合には、オブジェクト指向の仕組みを利用してサブクラス化することで、利用者独自の機能を追加することができます。
　ところでMLTEをラップしたLMLTEPaneは、とても簡単に使うことができます。これは、最初に言った「MLTEはラクができます」というのとはラクさの度合いが違います。
　PowerPlantが標準で用意するConstructorというGUI編集ツールを使って、部品パレットからウインドウ上にLMLTEPaneを持ってきて配置するだけで主な作業は完了。あとはコードの方にRegisterClass_(LMLTEPane);という1行を加えるだけで、表示したWindow上にちゃんとMLTEが生成されます。MLTEが備えるオプションを利用したい場合にもConstructorの設定パレットでいくつかのチェックボックスを選択する程度の手間しかかかりません。
　「MLTEはラクができます」と言っても、普通にCでMLTEを使う場合には、書かなければならないコードがそれなりにあるので、それに比べても相当に「ラクができる」と言えるでしょう。
　ところで、MLTEをカスタマイズする必要が出てきた場合、どうすればよいのでしょうか？
　Cによるアプローチの場合、MLTEの仕組みが提供する機能を適宜利用して、自分のカスタマイズの用途に合わせたコードを書いていきます。
　では、オブジェクト指向の場合はどうでしょうか？
　先ほども言いましたように、PowerPlantでは、MLTEをラップした形でLMLTEPaneというクラスが構成されています。しかし、この「ラップした仕組み」がカスタマイズの邪魔をすることがあるのです。
　今回私が取り組んだプログラムの場合、複数の写真を切り替えながらキャプションを編集する仕組みになっています。このキャプションを表示・編集する部分にMLTEを使用しているわけなのですが、ここで問題が出てきました。
　ユーザーが写真を切り替えた場合、新たに選択された写真のキャプションがMLTEの中に表示されるわけですが、内部的にはそれまで表示されていたテキストにさしかえて新しいキャプションをセットすることになります。
　すると、ユーザーが編集メニューから取り消しを選んだ場合、キャプションフィールドは以前に選択されていた写真のキャプションを表示してしまうのです。これは、MLTEが無限回数のアンドゥをサポートしているために発生する現象ですが、ユーザーからすればこの動作はちょっと不自然です。（選択されている写真も前のものに切り替わるならばまだしも）
　そんな時にどのように対処すべきか、アプローチはいくつか考えられるでしょうが、私は、写真が選択し直される場合にMLTE自体を一度消去し再度作り直すという方法を取ることにしました。（このやり方自体の是非はここでは議論しません）
　ところがMLTEというのは少しクセのあるコントロール（ボタンやフィールドなどのパーツのこと）で、生成時にしか指定のできないオプションがある上、これらのオプション値は既に生成されているMLTE自体から読み取ることができないのです。
　私の取った「新規に作り直す」というアプローチのためには、それらのオプション値をどこかから得なければなりません。MLTEのコントロールから取れないとなれば、再度リソースデータから読み出してくる必要があります。
　ところが、Constructorというツールによって作られているPowerPlantのWindowは、Windowの上に配置されているコントロールがWindow自身と共に一つの固まりとなってリソースに格納されています。
　新規にWindowを生成する場合には、そのリソースの固まりを頭から順番に読んでいき、コントロールを一つずつ生成していくようになっています（もちろん、これらは「Windowを生成する」という作業の裏側でPowerPlantが勝手にやることです）が、Window上の任意のパーツを特定して読み出すとなると話はそんなに簡単ではありません。
　パーツの数が少なければ、とりあえず全部のデータを読み出して、必要ないものは捨ててしまうというアプローチもあったのでしょうが、今回のケースではWindow上のパーツがかなりの数に上ったので、その方法は取りませんでした。
　そうなると、最初にLMLTEPaneのオブジェクトが生成される際に、リソースから読み込んできた各種設定値をどこかに保存しておけばよいということになるわけですが、あいにくLMLTEPaneはこのような機能は持っていません。
　サブクラス側から、このLMLTEPaneの初期化動作を横取りできればよいのですが、残念ながら初期化のための関数はprivate指定です（サブクラスからもアクセスができない指定。もう少しあとの回で説明します）。
　仕方ないので、サブクラスの生成関数の中で、途中まで読み出されたWindowのリソースのデータをLMLTEPaneが読み出した分だけ巻き戻して、再度読み込み直す、という回りくどいアプローチをすることで、結局実現に至ったのでした。

少し話が複雑すぎたかもしれません。PowerPlantの経験者でもないと、ちょっと理解するのは難しかったかな？
　どういうことが言いたかったのかは、次回でまとめて説明します。

ニュース・解説

　今週の解説担当:小池邦人

● Carbon ドキュメント & サンプル ＆ SDK ナビゲーション（2006/12/15）

【開発環境】

アップル社から「Leopard Tech Talk」開催の案内が届きました。アップルのエンジニアやエキスパートからリリース間近のMac OS X Leopardについての最新情報と技術知識を得られる機会だそうです。大阪で1回、東京では4回開催されるのですが、登録手続きにもたついていたら、最後の開催日（2/15）しか空いていない状況になっていました。すごい人気ですね（笑）。具体的なセッションの内容は「Mac OS X “Leopard” テクノロジー概要」「グラッフィックス概要」「新しいCocoaとObjective-C 2.0の概要」「Toolsの概要」などだそうです。

http://developer.apple.com/jp/events/techtalks/japan.html

多分、サンフランシスコExpoの基調講演ではLeopardの新機能（WWDCでは未紹介）がデモされるでしょうから、この場においても、WWDCで入手した情報よりも「さらに新鮮な情報」が入手できると嬉しいですね。期待いたしましょう！

【テクニカルドキュメント】

前回から12月15日の期間中、Apple社のGuidesとReferenceサイトには幾つかのドキュメントが登録されました。しかし、そのほとんどがマイナーチェンジの改訂です。Guidesサイトに登録された以下の2つのドキュメントだけが、内容の大幅な更新がなされています。また、デベロッパ向け読み物がひとつだけ登録されています。こちらについては、前号の木下さんの記事も参考にしてください。

「Quartz Composer Web Kit Plug-in JavaScript Reference」（PDFあり）
「Quartz Composer Programming Guide」（PDFあり）

http://developer.apple.com/documentation/index-rev-date.html

「Leopard Application Technologies Overview」（読み物）
http://developer.apple.com/leopard/overview/apptech.html

前回から12月15日の期間中、新規テクニカルノートと新規テクニカルQ&Aがひとつずつ登録されました。両方ともAudio関連です（最近多い）。

TN2113「Using AudioDeviceRead in Mac OS 10.4」

http://developer.apple.com/technicalnotes/index-rev-date.html

QA1437「Standard Audio – Parsing the kQTSCAudioPropertyID_
CodecSpecificSettingsArray property」（初版）

http://developer.apple.com/technicalqas/index-rev-date.html

【サンプルソースコード】

前回から12月15日の期間中、Apple社のSample Codeサイトには、サンプルソースコードがひとつも登録されませんでした。全体的にクリスマス休暇の影響で情報の更新が少ないです（嵐の前の静けさか？）。

http://developer.apple.com/samplecode/index-rev-date.html

【デベロップメント SDK】

前回から12月15日の期間中、Apple社のSDKサイトには新しいSDKがひとつも登録されませんでした。

http://developer.apple.com/sdk/

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