MOSA Multi-OS Software Artists

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

　 〜NetBoot編〜

　いよいよLeopard／Leopard Serverの発売日が発表になりました。10/26(金)から発売が開始され、すでに予約の受付も始まっています。本連載でもさっそく次回からLeopard Serverを取り上げた解説を始めていきたいと思います。

◇NetBootサービスの開始
　前回の解説でNetBoot用のイメージを作成するところまでたどり着きました。イメージが完成すればサービスの開始まであと少しです。ちなみにイメージが保存されるのは次のパスです。

・イメージの保存先（起動ディスクに保存した場合）
/Library/NetBoot/

　イメージを作成した次は「サーバ管理」を使ってNetBootサービスの設定を行います。まずNetBootサービスの「設定」から「イメージ」設定画面を表示します。

・「設定」＞「イメージ」
http://www.htabata.com/img/MXS104/NetBoot/NB_ADMIN_04.png

　ここにはサーバ上に作成したイメージの一覧が表示されます。イメージを複数作成した場合には、複数のイメージが表示されます。NetBootサービスで実際に利用するイメージの「使用可能」にチェックを入れます。複数イメージを作成している場合は、いずれかのイメージを「デフォルト」として設定することができます。設定した後は必ず画面右下の「保存」ボタンをクリックしてください。
　あといくつか設定項目がありますが、ツールバーの「サービスを開始」をクリックすることでNetBootサービスを開始することができます。
　NetBootサービスは他のサービスに依存していることを以前解説しましたが、「サーバ管理」でNetBootサービスの「概要」を表示すれば、他のサービスとの依存関係を確認することができます。具体的にはNFSやDHCPサービスが必要になります。NFSはこの時点で自動的に設定されているはずですので、あとはDHCPが稼働していれば（必ずしもNetBootサーバ上でDHCPを稼働させる必要はありません）NetBootサービスを提供することができます。

◇NetBootクライアントの起動
　サーバの準備が整いましたので、いよいよクライアントをNetBootで起動します。クライアントをNetBootで起動する方法は3種類ほどあります。すぐにNetBootの起動を確認したい場合は「N」キーを押しながらクライアントを起動してください。これで自動的にネットワーク上のNetBootサーバを検出してクライアントをNetBootで起動することができます。サーバ上で複数のイメージが使用可能な状態になっている場合、デフォルトとして設定したイメージから起動します。
　NetBootで起動した場合、クライアントの画面には地球のアイコンが表示されます。このアイコン表示でNetBootでの起動を確認できますが、基本的には内蔵ディスクから起動した場合と外見上の違いはありません。
　システムが起動するとあとは通常通りログインができ、普通にMacを使用することができます。あらかじめ適切なディレクトリサービス関連の設定を行っておけばネットワークユーザ／ホームを使用することもできます。もしうまくNetBootで起動できない場合は、最初から設定を見直してみてください。

　起動時に「N」を押す以外にも、NetBootで起動する方法があります。optionキーを押しながら起動すると起動ディスクを選択する画面が表示されますが、
ここにNetBoot用のアイコンが表示されますので、ここからNetBootで起動する方法があります。サーバ上に複数のイメージがあってもNetBoot用のアイコンは1つしか表示されず、この場合デフォルトとして設定したイメージからの起動になります。「N」キーあるいはoptionキーを使ってNetBoot起動した場合ですが、起動ディスクの変更は保存されず、クライアントを再起動すれば、それまで起動ディスクとして使用していたボリュームから起動してしまいます。
　起動ディスクをNetBootに固定したい場合は、まずなんらかのシステムでクライアントを起動してから、「システム環境設定」の「起動ディスク」を使います。「起動ディスク」にはNetBootサーバ上にある使用可能なイメージが表示されます。イメージが複数あった場合でも、使用可能なすべてのイメージが表示されますので、ここでは任意のイメージを選択することができます。

　以上3種類の方法を使ってクライアントをNetBootで起動することができます。NetBoot環境でクライアントを使用した場合、NetBootだからといって特に制約なく操作できます。環境設定を変更したり、通常通りファイルを保存することもできますが、NetBootの場合決定的に違うところがあります。それは再起動後の挙動です。NetBootクライアントを再起動すると起動ボリューム、つまりNetBootのイメージに対する変更はすべて破棄され、最初にNetBootで起動した状態に戻ります。つまり、NetBootのイメージに対しては永続的に変更を行うことができないのです。システムが起動中は、あたかも変更しているかのように動作していますが、これは変更内容が直接イメージに対して反映されるのではなく、シャドウファイルと呼ばれるファイルに対して反映されているからなのです。
　NetBootクライントは、起動中はNetBootイメージへの変更をシャドウファイルに書き込み、再起動すると元の状態に戻ります。こうすることでシステムを保護しているのす。ですのでNetBoot環境ではネットワークユーザ／ホームを組み合わせて、そちらでユーザやデータの管理を行うことになります。

◇シャドウファイルの保存場所
　一時的に変更内容を保持するシャドウファイルは、サーバ上に作成することもできますし、クライアント上に作成することもできます。
　デフォルトではクライアント上にシャドウファイルが作成されますが、サーバ上に作成したい場合は、「サーバ管理」のNetBootサービスの「イメージ」設定画面で該当するイメージの「ディスクレス」を有効にしておいてください。
「ディスクレス」を有効にする場合、あらかじめ「一般」設定画面で「クライアントデータ」を保存するボリュームを選択しておく必要があります。また、サーバ上のシャドウファイルはクライアントからAFPサービスを使ってアクセスされますので、この場合NetBootサーバではAFPサービスも稼働している必要があります。

・「サーバ管理」でシャドウファイルの保存場所を設定
http://www.htabata.com/img/MXS104/NetBoot/NB_ADMIN_03.png

　以上がNetBootサービスを構築する手順です。これまで解説してきましたように、NetBootサービスを利用するには他のサービスも組み合わせて利用することになりますので、各サービスの役割をしっかりと把握しておく必要があります。
　さて、冒頭でもお知らせしましたように次回からはさっそくLeopard Serverの解説を始めていきたいと思います。ご期待ください。
　　　　　　　　　　　　　　　　　　　　　　　　　　　Leopardへつづく

小池邦人のCarbon視点でCocoa探求（2007/10/19）

〜　First Responder　〜

前回は、File’s Ownerアイコンを調査しましたが、今回は、もうひとつの謎のアイコンFirst Responderの仕組みを調べてみたいと思います。こちらも、File’s Owner同様「線を引く相手がいない！」「さてどうする？」と言う問題点が謎を解くヒントとなります。

First Responderアイコンの利用法を見るには、テンプレートから作成した「Cocoa Document-based Application」に含まれるMainMenu.nibファイルのMainMenuオブジェクトをオープン（表示）します。例えば、そのEditメニューのCutを選んで、InspectorのConnectionsタブでTarget/Actionを調べてみると、グラフィックの接続ラインはFirst Responderアイコンに伸びており、それをTargetとする「cut:」アクションが選ばれていることが分かります。また、FileメニューのNewも同じく接続ラインはFirst Responderアイコンに伸びており、こちらは「newDocument:」アクションが選ばれています。

何らかのアプリケーションを作成すると分かるのですが、EditメニューのCutの対象となるターゲット・オブジェクトを先んじて固定することはできません（可能な場合もありますが…）。Cutの対象は、ある時はテキストかもしれませんし、またある時は画像かもしれません。テキストであっても、入力フィールドが複数ある場合には状況によって対象が変わります。つまり、InterfaceBuilderでTarget/Actionを設定しようとしても、Targetとなるオブジェクトを先んじて選べないのです。FileメニューのNewについても同じ事が言えます。

そのため、こうした場合の接続先としてFirst Responderアイコンが用意されているわけです。Interface BuilderのMainMenu.nibウィンドウからClassesタブを選んでクラスブラウザを表示させると、NSObjectを継承した位置にFirstResponderが用意されています。ここでFirstResponderを選択し、InspectorのAttributesタブを見てみると、ディフォルトで81のアクションが定義されていることが分かります。こうして用意されているアクションは、使いなれたCarbonの仕組みで言うならば、Carbon Eventにディフォルトで用意されている’cut’や’new’といったコマンド（OSType）と同じだと考えれば良いで
しょう。

Target/ActionのActionの方はInspectorで指定できたのですが、Targetの中身の方はどうなっているのでしょうか？　TargetとしてFirstResponderが接続された場合、その中身は「nil」つまり不定となります。Cocoaの仕組みでは、このnilターゲットを持ったアクション・メッセージは、それに応答できるオブジェクトに遭遇するまで、順次ターゲットを変えながら伝搬されます。最初にどのオブジェクトにメッセージを渡し、ダメなら次はどれを選ぶのかと言う伝搬順序には正式なルールがあり、最終的には正しいオブジェクトで正しい処理がなされることになります。つまり、nilターゲットへ渡したいアクションは、すべてFirst Responderアイコンに接続しておけば良いわけです。

この仕組み、Carbon使いの人であれば、Carbon Event Handlerでのイベント処理方法と似ていることが理解できるでしょう。例えば、メニューやボタンからのコマンドを受け渡すkEventClassCommandクラスのkEventProcessCommandイベントは、最初はフォーカスされたコントロールのHandlerに渡され、そこで処理されないとウィンドウのHandlerへ、そこでもダメならアプリケーションのHandlerへと伝搬されます。イベントの伝搬を止めるには、こうした階層のどこかのEvent Handlerの返値（OSStatus）をnoErrとします。つまり、処理が完了した時点でnoErrを返せばイベント（メッセージ）の伝搬を止められるわけですが、その代わりにeventNotHandledErrを返せば、イベントは次の階層（クラス）へと伝搬されます。

さて、今回も名称に対する不満なのですが（笑）、このFirst Responderというアイコン名称はどうも気に入りません。Cocoaでは、ウィンドウ上のアクティブビュー（現在テキスト入力のターゲットとなっているビューなど）を指示すために用意されているOutletを「FirstResponder」と呼ぶため、いくらか混乱を生じているような気がします（筆者も混乱した）。こちらは、Carbonで言うところのフォーカスされたコントロールのことですね。ですから、FirstResponderではなく、もう少し分かり易い名称は無いものでしょうか？　ダイレクトにNil-Target-Objectなどでも良いような気がします…。

ところで、MainMenu.nibというファイル名にもしっくりきてない人はいませんか？　Carbonプロジェクトのmain.nibでも良いのですが、Application.nibとかの方がピッタリきます。ちなみに、この名称を変更することは可能です。ただし、ファイル名を変更しプロジェクトファイルに再登録しただけでは、アプリケーション起動時に読み込んでくれません。プロジェクトのターゲット（アプリ名アイコン）をダブルクリックして表示される「ターゲットの情報」ダイアログの「プロパティ」タブにおいて「主要Nibファイル」の内容をMainMenuからApplicationへ変更しておく必要があります。

ついでに、MyDocument.nibの方もMainDocument.nib変更してみます。まず、
Interface BuilderのClassesタグで、MyDocumentクラスをMainDocumentに変更し、同時にFile’s OwnerのCustum ClassもMainDocumentにします（ここは自動にそうなります）。そしてMainDocument.hとMainDocument.mのソースファイル名も変更し再登録し、中身のクラス記述もすべてMyDocumentからMainDocumentへ置換してしまいます。忘れてはいけないのは、MainDocument.mのwindowNibNameメソッド内の「return @”MyDocument”」を「return @”MainDocument”」に変更しておくことです。そして最後に、ターゲット情報のプロパティタブの「書類のタイプ」の「クラス」をMainDocumentに直せば完了です。

Leopard（Mac OS X 10.5）の販売開始日が正式に発表されました。同時に、Apple社からはiPhone用SDK提供の発表もありましたので、Objective-C＋Cocoaによる開発環境もいよいよ面白くなってきました。本連載でテンプレート・プロジェクトに含まれているNibファルなどをちまちま解説して時間稼ぎをしていた理由は、実はLeopardでCocoaの開発環境が大幅に変更されることが分かっていたからです。つまり、先んじて説明したことが無駄にならないように考えた苦肉の策なのです（笑）。やれやれ、やっとその呪縛から解放される時が来たようです。

次回からは実施にObjective-Cのソースコードを記述することで、テンプレートから作成した「Cocoa Application」と「Cocoa Document-basedApplication」を拡張していく作業に入ります。新着のLeopardにて開発作業を開始いたしましょう。
つづく　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

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

〜 自動文書作成ツール「Doxygen」その3 〜

　前回は、Doxygenの設定を中心に解説しました。今回は、コメントの書き方と日本語LaTeX用の対策について説明します。

・コメントの書き方 〜かんたんに補足〜
　前回、コメントの書き方について触れましたが、説明不足でしたので補足させていただきます。
　まずコメントのスタイルについてですが、Doxygenは「Qt」と「JavaDoc」の2種類に対応しています。それぞれ要約説明と詳細説明の2つの表示方法をサポートし、ファイルや関数などコードの種類にあわせた情報を持たせることが可能です。
　Qtスタイルの記述法は、大きく3パターンに分類されます。詳細な説明を複数行に分けて書く場合は「/*!」〜「*/」の範囲に、要約説明を1行で書く場合は「//!」のあとに、宣言文などに続けて要約説明を書きたい場合は「//!<」のあとにコメントを記述します。

- - - - -
詳細説明         /*!  複数行のコメント */
要約説明         //!  単数行のコメント
要約説明(追記型)  //!< 単数行のコメント
- - - - -

　JavaDocスタイルは、その名のとおりJavaDoc互換のコメントフォーマットです。Qtスタイル同様に3パターン用意されていますが、先頭部に置く文字列のうち「!」が「*」に変わる程度で、基本的な使い方は同じです。

- - - - -
詳細説明         /**  複数行のコメント */
要約説明         //*  単数行のコメント
要約説明(追記型)  //*< 単数行のコメント
- - - - -

・コメントの書き方 〜内部コマンドについて補足〜
　以上のような要領でソースコードファイルにコメントを追加すれば、Doxygenで生成するドキュメントも情報量が増すはずですが、内部コマンドの機能を使うとさらに活用範囲が広がります。
　内部コマンドは、必ずコメントの範囲内で使用し、先頭はバックスラッシュ（\）またはアットマーク（@）で始まります。利用頻度が高いと思われる内部コマンドをいくつか紹介しますので、興味を持った場合はDoxygenのWebサイト
（http://www.stack.nl/~dimitri/doxygen/commands.html）を参照してください。

- - - - -
\author [作者名]   作者名を出力する
\b <文字列>   文字列を太字フォントで表示する
\bug {…}     バグの情報を出力する
\date {日時}  作成日や履歴などの日時を出力する
\file [file]  コメントブロックにfileの説明が含まれることを示す
\param <引数>{説明}   引数とその説明を出力する
\return {戻り値}   関数の戻り値に関する情報を出力する
- - - - -

　ごく簡単な例ですが、Qtスタイルで記述したファイルのコメントを以下に挙げます。このようなコメントを加えていくだけで、Doxygenで生成されるドキュメントは格段に読みやすくなるはずです。

- - - - -
/*!
\file funclib.c
\author UNAKAMI Shinobu
\brief あれをこれする関数です

\b License GPL v2

*/
- - - - -

・LaTeXでの出力
　バージョン1.5.2から内部コードがUTF-8で統一されたDoxygenですが、生成するドキュメントの文字コードについてまでは配慮してくれません。HTMLもLaTeXも一律UTF-8で出力されてしまうため、そのままでは日本語LaTeXでタイプセットできません。
　その理由は、Mac OS Xで利用される日本語LaTeX（ASCII pTeX/pLaTeX2e）デフォルトの文字コードがシフトJISに固定されていることにあります。使用する文字コードはpTeXのソースコードをコンパイルするときに指定できますが、第7回で紹介したものを含め、バイナリパッケージの形で配布されている日本語LaTeXはシフトJIS用にコンパイルされているため、TeXドキュメントはシフトJISで用意する必要があるのです。
　Doxygenの設定ファイルには、INPUT_FILTER（入力するソースの文字コードを特定するオプション）はありますが、OUTPUT_FILTERはありません。ドキュメントの生成後に文字コード変換を行うという、少々面倒な作業が必要になります。
　そこで、以下のようなRubyスクリプトを作成してみました。kconvの機能を利用してUTF8→SJIS変換を行うだけのものですが、目的は十分に果たせます。Doxygenを実行したときに生成される「latex」フォルダへ適当なファイル名で保存しておき、Terminalから「ruby ファイル名 *.tex *.sty」の要領でお使いください。

- - - - -
#!/usr/bin/ruby
require 'kconv'

while tex = ARGV.shift
 before = File.open(tex).read
 after = before.kconv(Kconv::SJIS, Kconv::UTF8)
 File.open(tex, 'w').write(after)
end
- - - - -

　次回は、Doxygenと組み合わせソースコードツリーを視覚的に表現する「Graphviz」を中心に紹介する予定です。

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