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

モサ伝読者の皆さまはもちろんご存知だと思いますが、ようやくLeopardが出ましたね。ということで、今回は当然ながらLeopardの話題でいきます。実のところ、Leopardは現在最強のRuby開発環境ではなかろうかというくらいRuby関連のソフトウェアがいろいろと入っています。概観してみましょう。

■ Ruby.framework にインストールされた Ruby 1.8.6

LeopardにはRuby.frameworkというフレームワークがあります。TigerにもRuby(1.8.2)がインストールされていたわけですが、そこにはRuby.frameworkというものはありませんでした。Leopardで導入されたこのフレームワークは、Ruby本体のインストール先としての意味を持っています。Tiger以前のMacOS Xに付属しているRubyは、/usr ディレクトリ以下に直接インストールされていましたが、LeopardにあらかじめインストールされているRuby 1.8.6は

 /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr

にインストールされています。/usr/binの下に置かれているRuby付属の各コマンドは、RubyCocoa.frameworkの中にある実体へのシンボリックリンクになっています。仮想マシンベースになった新しいRuby 1.9がリリース(今年の12月といわれている)されるときなど、このフレームワーク化により、Ruby 1.8と1.9を簡単に切り替えて使えるようになるのではないかと予想されます。

■ RubyGems

RubyGemsは、Rubyの世界で普及しているネットワークベースのRuby関連プログラムパッケージインストールシステムです。Ruby on Railsやrakeをはじめとして、よく使われているコマンドやライブラリなどのパッケージがあらかじめインストールされています。

■ Ruby on Rails

WebアプリケーションフレームワークのRuby on Rails (1.2.3)が、RubyGemsパッケージとしてインストールされています。

Railsの開発ではリレーショナルデータベース管理システム(RDBMS)が用いられるのが一般的ですが、Leopardに付属しているRDBMSはsqlite3というライブラリ形式のものだけです。Railsアプリケーションを生成するためのrailsコマンドでは、デフォルトで使用するデータベースがあらかじめsqlite3に設定されています(コマンドラインオプションで変更可能)。Railsの解説書ではMySQLを前提にしている場合が多いので、解説書で学ぶときには少しだけ読み替える必要があるかもしれません。

筆者も最近Railsの開発をするようになりそれで気づいたのですが、Railsは必ずしもリレーショナルデータベースを必要とはしません。Mac OS Xに搭載されたことで、例えばCoreDataのフロントエンドWebアプリの開発にRailsを使うという応用などもありうるかもしれませんね。

■ RubyCocoa

この連載でもすでに何度か紹介しているように、RubyCocoaはアプリケーションなどのMac OS X用プログラムをRubyで開発するためのフレームワークです。

Xcodeの新規プロジェクトに Cocoa-Rubyアプリケーションをはじめとして、
RubyCocoaアプリケーション用のテンプレートが加わっています。また、これが大きいのですが、XcodeとInterface BuilderがRubyプログラムをサポートするようになっています。

 ・XcodeでRubyプログラムのアウトレットやアクションを追加・変更すると
   Nibファイルに反映される

 ・Interface Builderでアウトレットやアクションを追加・変更するとXcode
   側のRubyプログラムに反映される

 ・NibファイルのコントローラからRubyプログラムを生成する

ドキュメントもあらたに加わっています。Xcodeのヘルプメニューの「製品ドキュメント」で、RubyCocoaで検索すると、RubyCocoaやPyObjCについて解説したドキュメントがいくつかあって参考になります。RubyやRubyCocoaなどのサンプルプログラムは、/Developer/Examples/Rubyフォルダの中に入っています。

■ まとめ

今回は、LeopardのRubyまわりについて概観しました。以下のURLにも詳しく書かれているので興味のある方はご覧ください。

http://trac.macosforge.org/projects/ruby/wiki/WhatsNewInLeopard

Leopardが発売になったということで、今後RubyCocoaについてもいろいろ取り上げていこうと思います。

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

　前回まででツールバーにアイテムを出す仕組みはだいたい飲み込めていただけたと思う。予告通り今回からは，この仕組みの細かいところ、重箱の隅めいたところをつついていこうと思うのだが、その前にちょっと準備をせねばならない。いやたいしたことぢゃないんだけど、つまりは今まで追加してきた「ネコ」とかぢゃなくて、もともとシステムに用意されているいくつかのツールバーアイテムについて書いて、適当にテストプログラムにこれらを追加しておかねば今後の説明がやりにくいのだ。

　NSToolbarItemクラスにはあらかじめ、7つのIdentifierが定義されている。早い話……遅い話にするのは難しいが、これらを　
toolbarDefaultItemIdentifiers: とtoolbarAllowedItemIdentifiers:  に渡すアレイに含めてやれば、あとはなんもしなくてもツールバーアイテムとして表示されてくれるわけ。順に説明しておく。

NSToolbarSeparatorItemIdentifier
　ツールバーの上でアイテム同士を区切る縦棒である。身近なところでは「プレビュー」でなんかファイルを開くと、「パネル」と「反時計回り」の間と、「時計回り」と「実際のサイズ」の間に表示されてるので暇なひとは「おお、これか」と確認されたし。

NSToolbarSpaceItemIdentifier
　空白である。探してみたがあんまり使われていないと思う。このあとテストプログラムで使ってみましょう。

NSToolbarFlexibleSpaceItemIdentifier
　これも空白だけど、こっちは伸び縮みするので結構使われている。Xcodeのエディタの「ブレークポイント」と「プロジェクト」の間とか、Finderの「アクション」と「検索」の間にありますな。これが入ると以降のアイテムがウインドウ幅に対して右寄せで表示される。

NSToolbarShowColorsItemIdentifier
　こっからはちゃんとアクションを持っているアイテム。まずこれは「カラー・パネル」を表示させる。……どっかで使ってるのを見た気がするんだが、ちょっと見つからない。まぁ出してみればすぐわかる。
　
NSToolbarShowFontsItemIdentifier
　同じく「フォント・パネル」を表示させるアイテム。

NSToolbarCustomizeToolbarItemIdentifier
　これはツールバーをカスタマイズするパネルを出すアイテム。このからくりはあとで説明する予定なんだけど、とりあえず見たことがないひとはたとえばXcodeのエディタでウインドウの右肩のところにある……これ、正しい呼び名がわからんのだが、扁平なボタンをオプション・キーとコマンド・キーを押しながらクリックしてみてちょうだい。出ましたか？　それを出すアイテムであります。他のキー・コンビネーションだと違うことが起きるので注意。

NSToolbarPrintItemIdentifier
　これはたとえばXcodeのリファレンスのウインドウとかに出てくる「プリント」のアイテムである。アクションはファイルメニューから「プリント」を選んだときと同じ。

　とまぁ、講釈たれてばっかりだと退屈なので、とりあえずテストプログラムの toolbarDefaultItemIdentifiers: と toolbarAllowedItemIdentifiers: の中身を以下のように変更して実行してみて欲しい（どっちも同じコードでOK）。

return  [NSArray arrayWithObjects:
    @"Cat",
    NSToolbarSeparatorItemIdentifier,
    NSToolbarShowColorsItemIdentifier,
    NSToolbarSpaceItemIdentifier,
    NSToolbarShowFontsItemIdentifier,
    NSToolbarFlexibleSpaceItemIdentifier,
    NSToolbarCustomizeToolbarItemIdentifier,
    NSToolbarPrintItemIdentifier,
    @"Align Text",nil];

　できたらウインドウをリサイズしたり、アイテムをクリックしたり（できないのもあるはず、それは後で説明する）して何が起きるか確かめてくだされ。あ、書かなかったけどInterface Builderでウインドウにある NSTextViewがちゃんとウインドウのリサイズに追随するように設定しておくと見栄えがよろしいと思います。ほんぢゃ。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　（2007_10_25）

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

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

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

　こんにちは、高橋真人です。
　今回は、前回のコード部分の続きになります。

[MyWindow.h]

　修正後の方が短くなりますので、すべてを掲載します。

#include 
#include 

#include "MenuCommandDisableDoer.h"

class MyWindow : public PPx::Window,
                 public SpecificMenuCommandDisableDoer
{
private:
    virtual void        FinishInit();

};


[MyApplication.cp]

　こちらも関数一つのみになりますので、すべてを掲載します。

#include "MyWindow.h"

#include 

void
MyWindow::FinishInit()
{
    EventTargetRef targetRef = GetSysEventTarget();
    SpecificMenuCommandDisableDoer::Install(targetRef);
}

　残りは新規のファイルです。
　ReverseCommandConverterとMenuCommandDisableDoerという名前で、それぞ
れヘッダとソースのペアを二つずつ作ります。以下はその内容です。

[ReverseCommandConverter.h]

#include 

class ReverseCommandConverter : public PPx::CommandConverter
{
protected:
   virtual OSStatus    DoCommandUpdateStatus(
                               PPx::SysCarbonEvent&    ioEvent,
                               HICommand               inCommand,
                               UInt32                  inMenuContext);
};


[ReverseCommandConverter.cp]

#include "ReverseCommandConverter.h"

#include 

OSStatus
ReverseCommandConverter::DoCommandUpdateStatus(
   PPx::SysCarbonEvent&    ioEvent,
   HICommand               inCommand,
   UInt32                  inMenuContext)
{
   if (PPx::EventUtils::UpdateCommandID(inCommand, inMenuContext) != noErr) {
       if (inCommand.attributes & kHICommandFromMenu) {
           ::EnableMenuCommand(nil, inCommand.commandID);
       }
   }

   return noErr;
}


[SpecificMenuCommandDisableDoer.h]

#include 

template 
class SpecificMenuCommandDisableDoer : public PPx::SpecificMenuCommandEnableDoer
{
private:
   virtual OSStatus    DoEvent(PPx::SysCarbonEvent& ioEvent);
};


template 
OSStatus
SpecificMenuCommandDisableDoer::DoEvent(PPx::SysCarbonEvent& ioEvent)
{
   ::DisableMenuCommand(nil, TCommandID);

   return noErr;
}


[SpecificMenuCommandDisableDoer.cp]

《中身はありません》

　最後のソースファイル、SpecificMenuCommandDisableDoer.cpは中身がカラです。従って、このファイル自体がなくても構いません。
　ちなみに、C++のテンプレートを利用したライブラリではヘッダファイルだけですべての機能を実現してしまうものが多くあります。何故なら、テンプレートを使った場合ヘッダファイルに実装コードを記述する必要があるからです。
　テンプレートを利用したコードは、テンプレート引数（上記の
SpecificMenuCommandDisableDoerの例ではTCommandIDがこれに当たります）が
特定されて初めてコンパイルが可能になるので、ヘッダ部のみでコンパイルされるわけではないのです。よって、これらの機能は、必ずいずれかのソースからインクルードされることになります。
　このような仕組みのため、テンプレートを多用して作られたC++のライブラリは、単にヘッダをインクルードするだけで済み、ソースファイルやライブラリをプロジェクトに加えたりする必要がないものが多くあり、気軽に利用できるのです。

　以上で作業は終了です。動かして試してみてください。

書籍紹介　　　　　　　　　　　　　　求めない

　解説担当:高橋政明

求めない
　加島 祥造　著
　小学館　　ISBN978-4-09-387722-0　　1,365円（税込）

　先日、朝のテレビで紹介されていた本を買いました。テレビを見た時点で買ってみようと決めていましたが、本屋に行ってみると売れ行きランキングのベスト10に入っていてびっくり。うまく乗せられてしまったようです…それが今回ご紹介する『求めない』です。

　詩集だそうです。『ベストセラー』にも『詩集』にもこれまでまったく縁がなく自分で買った記憶はありません。

　見開きページの使い方が新鮮でした。
　詩なので当然なのでしょうが、読んだときのリズムも心地よく、ずんずん読み進めることができます（行数も字数も少ないことももちろんですが）。
　でも、急いで読む本ではありませんね。

　評判の本ですので、私があれこれ書かずともいろいろな感想や書評を目にされることと思います。

　職業柄多くのストレスにさらされている（そう思っている　あるいは、そう思わされている？）私たちにとって、ちょっとしたギアチェンジのきっかけになってくれそうな本なのでご紹介しました。

　CDジャケット程の小ぶりの本です。
　まずは手に取って、ぱらぱらとページをめくってみてはいかがでしょうか。

▼出版社のweb
http://skygarden.shogakukan.co.jp/skygarden/owa/solrenew_detail?isbn=9784093877220

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

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

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

前回は、RubyのC言語用ライブラリとしての面からlibrubyについて取り上げました。今回はその続きとして、Rubyの拡張ライブラリを作ってみます。

■ 拡張ライブラリとは？

第2回で紹介したように、Rubyプログラムからライブラリをロードして使うときにはrequireメソッドを使います。

 require ロードしたいライブラリを表わす文字列

ここでロードされるライブラリもまた、Rubyインタプリタで実行するためのプログラムです。ライブラリのプログラムはもちろんRubyで書くことができるのですが、C言語で書くこともできます。その場合、前回紹介したlibrubyを使うことになります。C言語で書かれたRubyプログラム用のライブラリのことを拡張ライブラリといいます(Rubyのソースに含まれているREADME.ETX.jaによると)。

あえて、RubyではなくC言語で拡張ライブラリを書くことにはどんな意味があるでしょう？　たとえば、速度上のボトルネックとなっている処理をC言語で書くことによりパフォーマンスを出したいということが考えられます。また、C言語などでAPIが提供されているライブラリをRubyから使いたい場合も拡張ライブラリを書くことになるでしょう。外部のライブラリをRubyから使えるようにすることにより、Rubyの応用範囲を広げることができます。

■ 簡単なRuby拡張ライブラリを作ってみる

さて、拡張ライブラリを書くのは面倒なのではないかと思われるかもしれませんが、C言語に親しんでいる方であればきっと想像しているよりも手軽に作ることができます。ここでその手順を紹介します。以下は、ごく単純な拡張ライブラリのプログラムです。

------------------------------------------- myextlib.c --
#include "ruby.h"

static VALUE cMyExtLib = Qnil;

/* メソッド(モジュール関数)の実装 */
static VALUE
myextlib_f_sum(int argc, VALUE *argv, VALUE mdl)
{
 long i, sum;
 for (i = sum = 0; i < argc; i++)
   sum += NUM2LONG(argv[i]);
 return LONG2NUM(sum);
}

/* 拡張モジュールがロードされるときに呼ばれる初期化関数 */
void
Init_myextlib()
{
 cMyExtLib = rb_define_module("MyExtLib");    /* モジュールを定義 */
 rb_define_module_function(cMyExtLib, "sum",
                        myextlib_f_sum, -1);  /* メソッドを追加 */
}
-------------------------------------------

このプログラムでは、MyExtLibというモジュールを定義し、MyExtLibモジュールに MyExtLib::sum というメソッド(モジュール関数)を定義しています。このメソッドは、可変長の引数を受け取り、それを整数とみなしてその総和を返します。

このプログラムから拡張ライブラリを作るために、以下のrubyプログラムを用意してください。

------------------------------------------- extconf.rb --
require 'mkmf'
create_makefile "myextlib"
-------------------------------------------

以上2つのファイルを同じディレクトリに置き、ターミナルアプリケーションで
以下のようにコマンド($はプロンプトです)を実行します。

 $ ruby extconf.rb && make

すると、同じディレクトリに myextlib.bundle というファイルが出来上がります。これが拡張ライブラリになります。irb を起動して確認してみましょう。

 $ irb
 irb(main):001:0> require 'myextlib'
 => true
 irb(main):002:0> MyExtLib
 => MyExtLib
 irb(main):003:0> MyExtLib::sum(1,2,3,4,5,6,7,8,9,10)
 => 55

実は、当初、CocoaのNSStringをRuby拡張モジュールにしたものを例示しようと考えたのですが、実際に書き始めてみるとこの記事に載せるには少々大きくなりそうだったため、やむなくもっと単純なモジュールに差し替えました。

■ まとめ

今回は、Cプログラマにとって拡張モジュールが割と簡単にできることを示そうと考えたのですがいかがでしたでしょうか？　Rubyにビルトインされているクラスやモジュールも、あるいはRubyCocoaにしても、基本的には今回示したようなコードがベースになっています。

最後に拡張ライブラリを作る上での参考資料をまとめておきます。

・README.EXT.ja (Rubyのソースコードに付属)
・Rubyソースコード完全解説 http://i.loveruby.net/ja/rhg/book/
・Rubyのソースコード (array.cなどのクラス定義やext以下のディレクトリなど)

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

　さて、前回までで一応ツールバーにネコのアイコンを出し、これをクリックするとそれなりの動作が行われるようにするところまでこぎつけたわけだが、知っての通りツールバーに並ぶのはアイコンだけではない。今これを書いているJedit Xのツールバーを見ても、左から順に「フォントメニュー」、「サイズメニュー」、「カラーメニュー」に「検索テキストボックス」、そして一番右に「書類情報」のアイコンてな具合で、我らがネコと同じ仕掛けなのは最後の「書類情報」だけである。
　今回からこういう「アイコンぢゃない項目」をツールバーに並べるのはどうやるか、というのを説明していくわけだけど、だんだんコードがややこしくなってくるので、その気のある人は是非いままでのところまでのプログラムを実際に作って、ネコ（別にネコが嫌いならイヌでもムカシトカゲでもゴミムシダマシでもいいんだけどさ）のアイコンがツールバーに並ぶことを確認した上でこっから先を読んでいただきたい。例によって全部終わったらサンプルはMOSAのサイトで公開するけどさ、こういうのは結果でなくプロセスだから。

　ほんぢゃ、まずサンプルのプロジェクトファイルをダブルクリックしてXcode を起動していただきたい。MyApplication.hを開き Outlet をひとつ追加して欲しい。

 IBOutlet NSView*         sampleView;

　プロジェクト・ウインドウの「ファイル」タブを開いて「MainMenu.nib」をダブルクリック、Interface Builderを起動する。セーブしたMyApplication.hを「MainMenu.nib」にドラッグ＆ドロップすると MyApplication クラスに上の Outlet が追加される。
　次にこの View のインスタンスを作る。Cocoa Controllerのツールバーから「Containers」を選び、「Custom View」を「MainMenu.nib」のウインドウ、「Instance」タブの中にドラッグ＆ドロップしていただきたい。画面の真ん中へンに「View」というタイトルの「なんでデフォルトでこんなに小さいんだよ」と思うようなウインドウが開くので、これを適当に横に拡げ、今度はこの中に……何がいいかなぁ、そいつの機能をインプリメントするのが話の主眼ぢゃないので簡単なのがいいよね。
　よし、Cocoa Container のツールバーから「Controls」を選び、NSPopUpButton を View にドラッグ＆ドロップしてくだされ。で、このポップアップの中身を上から「Left」、「Center」、「Right」とし、それぞれのメニューアイテムからメインのウインドウにある NSTextView にアラインメントのアクションをつなげる。「Left」から「alignLeft:」へ、「Center」から「alignCenter:」へ、「Right」から「alignRight」へ。
　そしたら「File's Owner」からこの View （NSPopUpButtonぢゃないよ）にコネクションを張って、さっき作った sampleView という Outlet とつなぐ。……一気に書いちゃったけどできましたか？

　MainMenu.nib をセーブして MyApplication.m を開き、

  [toolbarItems setObject:catItem forKey:@"Cat"];
    [aToolBar setDelegate:self];

という2つの文の間に、以下のステートメントを追加する。

  NSToolbarItem* alignPop =
          [[[NSToolbarItem alloc] initWithItemIdentifier:@"Align"] autorelease];
    [alignPop setLabel:@"Align Text"];
    [alignPop setPaletteLabel:@"Align Text"];
    [alignPop setToolTip:@"Align Text"];
    [alignPop setView:sampleView];
    [toolbarItems setObject:alignPop forKey:@"Align Text"];

　ネコの時は setImage: だった部分が setView: になり、アクションとターゲットはポップアップメニューの受け持ちだからここには書かない。それからArray を返す2つのデリゲート・メソッドに「Align Text」を追加すればできあがり。

- (NSArray*) toolbarDefaultItemIdentifiers: (NSToolbar*) inToolbar {
    return  [NSArray arrayWithObjects:@"Cat",@"Align Text",nil];
}

- (NSArray*) toolbarAllowedItemIdentifiers: (NSToolbar*) inToolbar {
    return  [NSArray arrayWithObjects:@"Cat",@"Align Text",nil];
}

　NSToolbarItem の見た目を決められるのは setImage: と setView: だけなので、こりゃただのアイコンぢゃないな、というものは複雑に見えてもみんなこれのバリエーションである。次回からはもう少しこの仕掛けの重箱のスミをつっついてみよう。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　（2007_10_12）

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

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

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

　こんにちは、高橋真人です。
　3つめのPPxプログラムのコードの解説が終わりましたので、ここで前々回にお約束していた「何もウインドウが出ていない時には有効になっているメニュー項目が、ウインドウが出ている時には無効になる」というのを実際にやってみたいと思います。
　実現の方向としては、最初にすべてのメニューを有効になるようにしたうえで、特定の項目（今回は、「New」＝kHICommandNew）がウインドウの表示されている時にのみ無効になるようにします。
　ちなみに、すべてのメニュー項目が有効になるというと、2番目のPPxプログラム例（PPxForXcode02）でも、そのようになっていました。しかし、表面的には同じに見えても、実現の仕方には違いがあります。
　復習になりますが、前々回の記事で触れたようにCommandConverterが最終的にすべてのメニュー項目（SpecificMenuCommandEnableDoerなどで個別措置をしていないものに限るが）を最終的に面倒を見、無効の状態にします。ですから、CommandConveterを使用せずに、Nibファイルでの設定のままがそのまま結果としてれたのとは違うということです。思い出していただけたでしょうか？
　そういうわけで、今回「すべてのメニュー項目を有効にする」というのは、CommandConverterのような動的な処理を行うことによって有効にするわけです。もちろん、CommandConverterですと、メニュー項目は無効になるわけですから、ここでは新たなクラスを起こしてCommandConverterの逆の処理をさせる必要があります。具体的な実現方法としては、CommandConverterのサブクラスを作るという形になります。
　メニュー項目をすべて有効にできたら、次は、特定の状況でメニューを「無効にする」動作を実現します。こちらも、SpecificMenuCommandEnableDoerの動作と逆になりますので、同じようにこのクラスのサブクラスを起こして実装します。
　具体的には「ウインドウが開いている時にはNewを選べない」ようにするという動作です。つまり、ウインドウを一つ開いたら、それ以上は開けないという仕組みの実現となります。

　それでは、実際にプログラムを作成してみましょう。基本は、PPxForXcode03となります。これを複製して、PPxForXcode04として、以前と同じように変更を施してください。
　ところで、今までのやり方では、プロジェクトの名前が変わっても、出来上がったアプリケーションの名前は、依然としてPPxForXcode01のままでした。ですので、今回から併せてアプリケーション名も変えることにしましょう。

・プロジェクトメニューから「アクティブターゲット'PPxForXcode04'を編集」
　（コマンド＋オブション＋E）を選択し、「ビルド」タブに切り替えます。
・「コレクション」のポッブアップメニューから「パッケージング」を選び、
　プロダクト名の右欄をダブルクリックして編集します。
・編集状態になった時に表れる「PPxForXcode01 $(CONFIGURATION)」を
　「PPxForXcode04 $(CONFIGURATION)」に変更します。

　この時、名前に関しては必ずしもこの名前にせず、ご自分の好きなものにしても構いませんが、$(CONFIGURATION)の部分は、ビルド時に内部的な変数展開が行われるので、そのままにしておいた方が無難です。

・「構成」のポップアップメニューから「Release」を選択し、同様にプロダ
　クト名の欄を変更します。

　アプリケーション名の変更のための操作は以上です。
　これ以外のプロジェクト複製後の作業が完了したら、以下を参考にコードの編集をしていきましょう。

[MyApplication.h]

class MyApplication : public PPx::Application,
                     public PPx::CommandConverter,
                     public PPx::SpecificMenuCommandEnableDoer,
                     public PPx::SpecificMenuCommandDoer
{

とあるのを、以下に変更。

class MyApplication : public PPx::Application,
                      public ReverseCommandConverter,
                      public PPx::SpecificCommandDoer
{

それと、冒頭のヘッダのインクルード部の末尾に

#include "ReverseCommandConverter.h"

と加えておきます。（ヘッダファイルは後ほど作成）

[MyApplication.cp]

MyApplication::MyApplication()
{
    EventTargetRef targetRef = GetSysEventTarget();

    CommandConverter::Install(targetRef);
    PPx::SpecificMenuCommandEnableDoer::Install(targetRef);
    PPx::SpecificMenuCommandDoer::Install(targetRef);
}

この関数を以下のように変更します。

MyApplication::MyApplication()
{
    EventTargetRef targetRef = GetSysEventTarget();

    ReverseCommandConverter::Install(targetRef);
    PPx::SpecificCommandDoer::Install(targetRef);
}

　続きは、次回に掲載します。

書籍紹介　　　　　　Macintosh的デザイン考現学

　解説担当:高橋政明

Macintosh的デザイン考現学
　　　　　　　　　　　アップルプロダクトと世界的デザインの潮流を探る
　大谷 和利　著
　毎日コミュニケーションズ　ISBN4-8399-0691-2　2,200円+税

　古い本で恐縮です。2002年3月に出版され現在のところ、重版は未定（つまり書店で新刊を入手するのは難しい状態）のようです。
　Amazon.co.jpの商品の説明ではいきなり『Macintoshほど熱狂的なファンを持つ「機械」はない。その最大の理由は、Appleがずっとこだわり続けてきたデザインにある。』なんて書かれていて、それは最大の理由ではないだろうとツッコミを入れたくなりました。でも、この本の写真をながめていると、故障していても機能しなくてもとにかく手元に置いておきたいと考える人が現れても不思議でない事は実感できます。

　この本は1996年から2002年にかけてMac Fan Beginners誌に連載されたコラムを一冊にまとめ、大谷さんご自身が加筆訂正を加えたものです。

　Macintoshや他のApple製品が他にない魅力を持っている事は、使えばすぐにわかるし、眺めただけでもわかります。我々がただ漠然と「美しい」とか「デザインが良い」とか言うのと、大谷さんの解説とでは（比較して申し訳ないのですが）全く違います。
　起源と歴史、設計者（デザイナー）、どこから影響を受け何に影響を与えたのか、素材・構造さらに細かな形状処理まで多様で緻密な解説は考現学そのものです。
　帯に『時代を経ても錆び付かないデザインとは何か？』と書かれていますが、まさにその回答が書かれています。
　Apple社の製品だけではなく、多くの魅力的な『もの』たちも紹介されています。表紙にもいくつかありそのユニークさが伝わります。

　ここから宣伝も含みますが...
　雑誌記事で現在でも大谷さんの最新の解説に触れる機会があります。しかしライブは格別です。大谷さんには今年もMSMのキーノートスピーチを担当していただきます。あっと驚く「物」をご披露していただけること請け合いです。
（物理的な製品に限らず、ソフトウェア、webサイト、コマーシャル、などなどです）ちなみに昨年のMSM（湘南）にはA-bikeを持参されました。
　上記の書籍には初代しか掲載されていないiPodですが、iPod touchも登場した今年はどのようなお話が聞けるのか今から楽しみです。

※古い本のため出版社のwebページは見つかりませんでした。

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

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

　 〜NetBoot編〜

　今回はNetBoot用システムのディスクイメージ作成方法について解説します。ところでNetBootといえば東京大学での導入が有名ですが、来年度からはリプレースしたシステムの運用が始まるようです。リプレース後のシステムも引き続きNetBootが採用されています。時期的におそらくLeopardでの運用になるとのことです。

・次期教育用計算機システム(ECCS2008)について
http://www.ecc.u-tokyo.ac.jp/announcement/2007/10/01_917.html

◇イメージ作成の準備
　前回、NetBootクライアント用のMacを通常通りセットアップするところまでを説明しました。ここでは、イメージを作成するのに以下の2台のMacがあるものとします。あとFireWireケーブルを1本用意します。

・通常通りセットアップしたNetBootクライアント用Mac
・NetBootサーバ用Mac(Mac OS X Server)

　まずNetBootサーバ上でイメージを保存する領域を設定します。「サーバ管理」を使ってNetBootサービスの設定を行い、イメージの保存場所を指定します。NetBootサービスの「一般」設定画面にサーバ上のボリューム一覧が表示されますので、ここからイメージを保存するボリュームを選択します。またNetBootでは変更内容を保存するためのシャドウファイルと呼ばれるファイルを使用しますが、これをサーバ上に保存する場合は、保存先のボリュームを指定します。イメージは「イメージ」、シャドウファイルは「クライアントデータ」を設定します。

・「サーバ管理」でイメージの保存場所を設定
http://homepage.mac.com/htabata/MXS10.3/img/NetBoot/NB_ADMIN_03.png

　またNetBootサービスを提供するポートを設定することもできます。サーバが複数のネットワークポートをもっている場合は、実際にサービスを提供したいポートを選択してください。
　さて、これでイメージを作成する準備が整いました。サーバ上での設定が終われば、次にNetBootクライアント用Macをターゲット・ディスク・モードで起動します。そして、FireWireケーブルを使ってNetBootサーバに接続します。

◇イメージの作成
　いよいよイメージの作成です。ターゲット・ディスク・モードで起動したMacにはシステム一式がすでにセットアップされていますので、ここからNetBoot用のイメージを作成します。
　FireWireケーブルでサーバと接続したら、次にサーバ上で「システムイメージユーティリティ」（「/アプリケーション/サーバ」にインストールされています）を起動し、このツールを使ってイメージを作成します。

　NetBootイメージを作成するにはまず、「システムイメージユーティリティ」のツールバーから「新規ブート」を選択してください。デフォルトでは「新規インストール」が選択されていますが、このままではNetBootではなくネットワークインストール用のイメージを作成してしまいますので要注意です。
　設定はいくつかの画面に分かれていますが1つずつみていきましょう。まず「一般」の設定です。ここではイメージに名前と索引番号を付けます。イメージ名は管理しやすいように分りやすい名前を付け、イメージ索引には1〜4095の範囲でイメージごとに異なる番号を設定します。大規模なシステムでは、複数のサーバで同じシステムイメージを運用する場合もありますが、その場合は4096〜65535の範囲で索引番号を設定します。
　「使用可能な経由先」は通常NFSを使用し、サーバ上でイメージを作成している場合は「イメージへのパス」はローカルを選択しておきます。

・「一般」の設定
http://homepage.mac.com/htabata/MXS10.3/img/NetBoot/SIU_01.png

　次に「内容」でどこからイメージを作成するかを設定します。「イメージのソース」ポップアップメニューには、FireWire経由でマウントしたNetBootクライアント用Macのボリュームが表示されますので、それを選択します。
　パッケージ形式のファイルであれば、「その他の項目」でイメージに追加することもできますが、最初はあらかじめNetBootクライアント用Macに必要となるものをすべてインストールしておくのがよいでしょう。

・「内容」の設定
http://homepage.mac.com/htabata/MXS10.3/img/NetBoot/SIU_02.png

　特定の機種のみでNetBootを行いたい場合は「機種フィルタ」の設定を行います。「機種フィルタ」を設定しておくと、設定していない機種からのNetBoot起動ができなくなります。
　またNetBoot環境ではクライアントのコンピュータ名は自動的に設定されますが、特定の名前を付けたい場合には「”共有”環境設定」の設定を行います。

・「機種フィルタ」の設定
http://homepage.mac.com/htabata/MXS10.3/img/NetBoot/SIU_03.png
・「”共有”環境設定」の設定
http://homepage.mac.com/htabata/MXS10.3/img/NetBoot/SIU_04.png

　最後に「ディレクトリサービス」の設定ですが、NetBootの環境では基本的にはディレクトリサーバを設置してネットワークユーザを使用します。ですのでNetBootのイメージには、あらかじめディレクトリサーバに接続できる適切な設定を行っておく必要があります。「このコンピュータの…」にチェックを入れておくと、サーバ上の「ディレクトリアクセス」の設定がこれから作成するNetBootのイメージに引き継がれます。

・「ディレクトリサービス」の設定
http://homepage.mac.com/htabata/MXS10.3/img/NetBoot/SIU_05.png

　設定が一通り終わったら再度設定内容を確認し、問題がなければ右下の「作成」ボタンをクリックします。使用許諾書が表示されますので「同意する」をクリックし、イメージの保存先を指定します。保存先の指定ですが、まず画面下にある「提供するNetBoot共有ポイントの場所」で「サーバ管理」でイメージの保存場所として指定したボリュームを選択します。そうすれば自動的に適切なディレクトリが保存場所として選択されますので、最後に「保存」ボタンをクリックします。

・イメージ保存場所の指定
http://homepage.mac.com/htabata/MXS10.3/img/NetBoot/SIU_06.png

　イメージの作成時間は、システムの容量とマシンのパフォーマンスによって異なりますが最低でも20-30分程度はかるでしょう。ツールバーから「ログ」を選択しておくと、イメージの作成状況を確認することができます。それでは次回は、イメージ作成後の設定について解説します。
つづく　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

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

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

　Doxygen編の2回目となる今回は、Doxygenで日本語を含むソースコードを扱うときの注意点と対策を紹介します。

・Mac OS Xの開発環境と日本語
　さて、お題のDoxygenですが、日本語を含む各種言語に対応しています。しかし、皆さんご存知のとおり、一口に日本語といってもエンコーディング形式の違いという問題があり、それがDoxygenを扱うときにも問題となります。従来のDoxygenは、日本語のエンコーディング形式はEUCに固定されていたため、他の形式を扱いたい場合には、ファイル入力時にフィルタ処理を行うなどの方法で対策を講じていました。
　また、LaTeXベースでの出力を検討している場合には、日本語のTeX環境が対応する文字エンコーディング形式も考慮しておく必要があります。第7回で紹介したpTeXのパッケージは、SHIFT-JIS対応となっているため、Doxygenが前提とするEUCとは相容れません。つまり、日本語環境のMac OS XでDoxygenを使う場合、UTF-8とEUCとSHIFT-JISとで、”ボタンの掛け違い”が生じてしまいます。

・Doxyfileの編集
　……という状況はDoxygen 1.5.1までで、現在では若干改善されています。Doxygen 1.5.2の内部コードがUTF-8に統一されたため、現行バージョンでは入出力のエンコーディング形式をDoxyfile（第10回をご参照のこと。Terminalから「doxygen -g」を実行することでも作成できます）に記述するだけで、UTF-8のソースコードを適切に処理できます。手元のDoxyfileを適当なテキストエディタで開き、該当する各行を以下のとおり編集してください。

- - - - -
OUTPUT_LANGUAGE   = Japanese
DOXYFILE_ENCODING = UTF-8
INPUT_ENCODING    = UTF-8
- - - - -

　上記について少し説明しておきましょう。まず「OUTPUT_LANGUAGE」ですが、Doxygenが生成する書類に使う言語を指定するオプションです。今回は日本語環境での利用を前提としていますので、ここは迷わず「Japanese」でいいでしょう。次の「DOXYFILE_ENCODING」は、設定ファイル（Doxyfile）のエンコーディング形式を指定しますから、とりあえず「UTF-8」を指定しておきます。
　3行目の「INPUT_ENCODING」ですが、こちらは対象のソースコード次第です。UTF-8の場合は「UTF-8」、SHIFT-JISの場合は「SJIS」、日本語EUCの場合は「EUC-JP」を設定します。余談ですが、Windows日本語環境で作成したソースコードを扱う場合は、「CP932」とコードページを指定します。
　INPUT_ENCODINGで扱えるコード名を調べるには、ターミナルから「iconv -l」を実行します。ただし、情報が多く画面がスクロールするので、grepを利用して特定のキーワードに絞ったほうがいいでしょう。以下の実行例では、コード名に「JIS」と含むもののみ表示しています。

- - - - -
$ iconv -l | grep JIS
- - - - -

・すわトラブル？　と結論づける前にここを確認
　デフォルトのDoxyfileは、前述した設定に変更する程度で、ソースコードを解析したドキュメントを自動生成してくれます。ただし、ドキュメント化する範囲については、デフォルトでは狭めに設定されているため、範囲を広げないことには期待した内容とはならないかもしれません。以下、値を「YES」に設定した場合の各オプションの挙動です。

- - - - -
RECURSIVE           サブディレクトリに対しても入力ファイルの検索を行う
EXCLUDE             除外するファイル/ディレクトリを指定する
EXTRACT_ALL         すべてのエンティティがドキュメント化される
　　　　　　　　　　（PRIVATEとSTATICを除く）
EXTRACT_PRIVATE     クラスのすべてのプライベートメンバーがドキュメント
　　　　　　　　　　化される
EXTRACT_STATIC      ファイルのすべてのスタティックメンバーがドキュメン
　　　　　　　　　　ト化される
EXTRACT_LOCAL_CLASSES    ローカルに定義されたクラスと構造体がドキュメ
　　　　　　　　　　　　　ント化される
EXTRACT_LOCAL_METHODS    インターフェイス以外のセクションに定義された
　　　　　　　　　　　　　メソッドがドキュメント化される（Objective-C
　　　　　　　　　　　　　のみ対象）
FILE_PATTERNS       対象とするソースを拡張子（*.h、*.mなど）で明示する
- - - - -

　コメント文の扱いにも注意が必要です。doxygenでは、「//!」や「/*!」のように、通常のコメントに「!」を加えておかないかぎり、ドキュメントに書き出されません。なお、「//!」は1行だけの短い説明を行うときに、「/*!」は詳細な説明を行うときに使用します。詳細説明にはハイパーリンクが張られるという機能的な違いもあるので、必要に応じて使い分けます。

　次回は、日本語LaTeX出力時の対策と、ソースの構造をビジュアルで表現するツール「Graphviz」の使い方を紹介します。

Adobe MAX 2007現地レポート　　　　　　　　　　　　　　　諫山 研一

・モサ伝編集部より
米国・シカゴにて開催されたAdobe MAX 2007 North Americaに参加された諫山
さんから現地レポートが届きましたので掲載します。

　デベロッパー、デザイナー、プログラマなどが一同に集まり、最新技術の動向やTipsなどを習得するためのカンファレンス「Adobe MAX 2007 NorthAmerica」が10月1日より開催された。本イベントは元々マクロメディア時代から行われていたもので、Adobe版のWWDCと言った感じのイベントである。
　主にWebアプリケーションの開発や応用がメインのテーマとなっていることから、どちらかと言えばWindows向けのイベントと勘違いされがちだが、その実態はクロスプラットホームによるWebアプリケーションの制作がメインであり、最新技術であるFLEX、AIR、Ajaxなどの最新動向がわかる有益なイベントだ。

　今回、筆者が参加して感じた事は、今まで以上にプログラマの活躍する機会が増えてきている事と同時に、プログラマの領域へWebデザイナーたちがどんどん足を踏み入れてきていると言う点である。
　MOSAの会員の中にはFLASHなどのプログラムを行っている人も少なくないだろうが、FLEXやAIRなどの技術は今後デザイナーにも多く活用される可能性を秘めていることから、危機感をもつべきであろう。
　また、ソリューション・デベロッパー的な見方をすれば、FLEXを使う事で既存のAdobe製アプリケーションの可能性を更に拡げる事が可能になるなど、従来のプラグインやアドオンの開発とは違った側面があり、独自のソリューションを提供するには不可欠な技術となりつつある。

　しかも、これらはクロスプラットホームで開発が可能なため、開発のためのコストを抑える事ができるようになるなどメリットも大きい。
　通常、Webアプリケーションとなると、Macが除外される事が多い中、AdobeのソリューションはMac、Windows、Linuxと主要プラットホームでの動作が約束されており、ビジネスチャンスも拡がる事は間違いないほか、当然開発環境はMacで構わないのである。

　なお、Adobe MAX 2007 Japanは日本でも11月の1日と2日に、東京・お台場の日航ホテルで開催される。FLEXやAIRの柔軟性やプログラマとしてどのようなアプローチができるかを確認する良いチャンスでもある。
　今後、Webアプリケーションの需要が増える事は間違いない。その最新情報を得るためにも、ぜひともAdobe MAX Japanに参加してみてはいかがだろうか？

Adobe MAX Japan Webサイト
http://www.adobe.com/jp/events/max/

◇モサ伝編集部から「Carbon視点でCocoa探求」は都合によりお休みします。◇

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

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

　前回はツールバーに並ぶ（と言っても一個だけだけれども）NSToolbarItemというオブジェクトを一つ、新たに作ったところまでであった。これをツールバーに並べるためにどうするか、というのが今回の話。前回書いたコードの最後に、こういうのがあったはずだがご記憶だろうか。

    [aToolBar setDelegate:self];

　これはこの処理をやってるオブジェクト（この例では NSApplication のサブクラスである MyApplication）をこのツールバーのデリゲートとしてセットしているわけである。ツールバーはその上にアイコンやテキストフィールドなどのアイテムを並べるために、このデリゲートに対して3つのメッセージを送ってくる。言い換えればツールバーをツールバーとして機能させるためには、こうやってデリゲートをセットし、そのオブジェクトでその3つのメッセージに応える必要があるわけ。

　その3つのメッセージを以下に解説する。まず最初がtoolbarDefaultItemIdentifiers:。このメッセージはツールバーの初期のアイテムの配置方法を要求するもの。並べたいアイテムの identifier をNSArrayの形にして知らせる。並べるも何も現在我々は（と、こういう解説にありがちな共犯者的言い回しをしてしまうが）アイテムを “Cat” 一つしか持っていないので、インプリメンテーションは以下のようになる。このオブジェクトがいくつものツールバーのデリゲートになっている場合には、引数 inToolbar のidentifier（前回のコードでこれには “MOSA_SAMPLE” という identifier を設定した）を調べてそいつ用のものを返すこと。

- (NSArray*) toolbarDefaultItemIdentifiers: (NSToolbar*) inToolbar {
    return  [NSArray arrayWithObjects:@"Cat",nil];
}

　次にこのサンプルでは同じようだが、そのツールバーに並べることのできる全てのアイテムを要求する toolbarAllowedItemIdentifiers:。これはあとで出てくるユーザによるツールバーのカスタマイズにからむ。つまりここで返す全てのアイテムのなかからユーザはどれをツールバーに出してどれを出さないかを指定できるわけ。繰り返しになるが現時点では全てもへちまも “Cat” ひとつしか手持ちがないのでこれのインプリメンテーションも以下のようにならざるを得ない。

- (NSArray*) toolbarAllowedItemIdentifiers: (NSToolbar*) inToolbar {
    return  [NSArray arrayWithObjects:@"Cat",nil];
}

　ツールバーは初期状態で上の toolbarDefaultItemIdentifiers: が返したArray に並んだアイテムを、もしユーザがカスタマイズしたらそのカスタマイズされた通りのアイテムを「これを表示するからインスタンスをよこせ」と要求してくる。
それが以下の toolbar: itemForItemIdentifier: willBeInsertedIntoToolbar:である。どのアイテムを渡すかは identifierで指定される。これは以下のようにインプリメントする。

- (NSToolbarItem*)toolbar:(NSToolbar*)toolbar
    itemForItemIdentifier:(NSString*)itemIdentifier
    willBeInsertedIntoToolbar:(BOOL)flag {
    NSToolbarItem* newItem = [[[NSToolbarItem alloc]
                             initWithItemIdentifier:itemIdentifier] autorelease];
    NSToolbarItem* anItem = [toolbarItems objectForKey:itemIdentifier];
    [newItem setLabel:[anItem label]];
    [newItem setPaletteLabel:[anItem paletteLabel]];
    if([anItem view] != NULL){
         [newItem setView:[anItem view]];
    }else{
         [newItem setImage:[anItem image]];
    }
    [newItem setToolTip:[anItem toolTip]];
    [newItem setTarget:[anItem target]];
    [newItem setAction:[anItem action]];
    [newItem setMenuFormRepresentation:[anItem menuFormRepresentation]];
    if ([newItem view] != NULL){
         [newItem setMinSize:[[anItem view] bounds].size];
         [newItem setMaxSize:[[anItem view] bounds].size];
    }
    return newItem;
}

　identifier を調べてそのアイテムを登録してある辞書から引っ張りだし、同じものを作成して渡してやる。細かい解説はともかく、ここまで書いてビルドすればとりあえずツールバーにネコのアイコンが出現して機能するはずなのでお試しを。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　（2007_09_29）

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

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

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

　こんにちは、高橋真人です。
　コードの解説がもう少し残っていますので、続けます。

　前回の記事の最後に触れたSpecificCommandDoerの、これまた最後で触れたDoSpecificCommand()というprotectedなメンバー関数ですが、少し見慣れない形をしています。こんな感じです。

virtual OSStatus    DoSpecificCommand(
                         PPx::CommandIDType,
                         PPx::SysCarbonEvent&                ioEvent);

　実はこれ、CodeWarriorではよくやられていた「使わない引数を書かない」という手法です。例えば、以下のような関数がある場合、

void foo(int a, int b)
{
    printf("%d", a);
}

　最近のチェックが厳密なコンパイラでは「使っていない引数がある」と警告が出てしまいます。こういうとき、正統的な方法としては、

void foo(int a, int b)
{
#pragma unused (b)

    printf("%d", a);
}

というようにやるのですが、CodeWarriorでは、よく以下のようにやっていま
した。

void foo(int a, int /* b */)
{

    printf("%d", a);
}

　つまり、これはbという仮引数をコメント化して隠してしまうわけです。つまり、型のみを書いて仮引数を書かないのと同じことです。
　ところが、少し前までのXcodeはこの書き方を認めてくれず、CodeWarriorからの移植コードには大幅な手を入れる必要があったのです。とりあえず、今の私の手元の環境ではエラーが出ないようになっているみたいですが。

　というわけで、テンプレートがあるので、見た目で少し混乱するかもしれませんが、要するにこれは

virtual OSStatus    DoSpecificCommand(
                         PPx::CommandIDType inCommand,
                         PPx::SysCarbonEvent&                ioEvent);

と書くところの、仮引数であるinCommandを書いていないのです。
　ちなみに深くは触れませんが、この第一引数はDoSpecificCommandという名の、他にも山ほどある同名の関数との区別をするだけのために用意されている、いわば「裏技のタネ」とでも言うべき引数なので、関数の中でこれを使うことはまずあり得ないのです。（この関数が呼び出された時点で役割を終えている）

　さて、次はMyWindowの方の説明です。このクラスはPPx::Windowクラスの挙動をほとんどそのまま使っている（つまり、これが継承です）ので、
PPx::Windowに足りない機能を加えるか、PPx::Windowクラスの挙動を変更する
（override）ところだけを記述してあるだけです。
　よって、コードは極めて少なくなっています。ですから、ヘッダとソースを区分けせずに一緒に説明します。（連載の118回目を参考にしながら読んでください）
　まず、MyWindowが継承しているのは、PPx::Window以外にはPPx::SpecificMenuCommandDoerです。このクラスに関しては、MyApplication
の方でさんざん触れてきていますので、特に解説は不要でしょう。一言加えるなら、MyWindowクラスから作られたウインドウがアクティブになっているとき、MyWindow側のDoSpecificCommand()が呼ばれ、そうでない時にはMyApplication側の同じ名の関数が呼ばれるということです。
　さて、最後に残ったFinishInit()という関数を見てみましょう。
　これは、クラス構築の仕上げのために呼び出される関数です。オリジナルPPを知っている人ならFinishCreateSelf()、Cocoaを知っている人なら、awakeFromNibと似たようなものだと言えば、何となく分かるでしょう。
　実際にこの関数で行われるのは、イベントハンドラのインストールです。インストール関数に渡すEventTargetRef型の情報を取り出している以下の関数が、このハンドラのインスールがFinishInit()の中でなければならない1つの理由です。

    EventTargetRef targetRef = GetSysEventTarget();

　もし、このGetSysEventTarget()をMyWindowsのコンストラクタで呼び出したとすると、この関数は正しい値を返しません。何故ならコンストラクタの中では、まだクラスの構築が行われている途中だからです。この段階では、関数が情報を取ってくる先にまだ正しい情報が設定されていないのです。
　そのため、クラスの構築が完成したすぐあとに、イベントハンドラのインストールのような「準備作業」をするチャンスを与えるために、このFinishInit()が用意されているというわけです。

ニュース解説　　　MOSAic

★★★　開発関連のニュースはwebに掲載中　★★★
http://www.mosa.gr.jp/?page_id=1017

書籍紹介　　　　　　　　　　　　　　MINDパフォーマンスHACKS

　解説担当:高橋政明

MINDパフォーマンスHACKS
　Ron Hale-Evans 著
　夏目　大　訳
　オライリー・ジャパン　ISBN　978-4-87311-337-1　　2,940円

　「脳と心のユーザーマニュアル」と副題の付いた本です。webの
　　　　本書は、脳の実践的な使い方を解説した、言わば「あなたの脳の取扱
　　　　説明書」です。脳に眠っている驚くべき能力を引き出します。とのうたい文句につられ読んでみました。

　「記憶」「情報の処理」「創造力」「数学」「意志決定」「コミュニケーション」「明晰さ」「知性の健康」の八章にわたり75のテーマが載っています。各テーマはそれぞれ独立しているので興味のある物を拾い読みしても役立つと「はじめに」で述べられていますが、まさにその通りです。
　オライリーの本らしく「脳のオーバークロック」といったテーマもあります。（CPUと違って脳は差し替えはできませんからね）

　「数学」は先週の「ためしてガッテン」と似たようなテクニックが紹介されています。暗算のチェックサムや概算はミスを認識するための有効なテクニックです。
　一方もともと米国で書かれた内容の翻訳本なので記憶術などの具体例は英語を母国語としない日本人にはあまり役にたたないと思われるテクニックも散見されます。日本語の場合の注釈があるのでそれを参考に工夫は可能です。

　脳の処理能力を多少なりともパワーアップできそうなテクニックやヒントが数多く載っていますので、自分に合ったものと巡り会うことができる可能性も低くはありません。
　脳ブームでもあり『この手の書籍は難しいかうさんくさい』と思われるかも知れませんが、内容はけっこう身近なものが多く載っていました。複数のテクニックを習慣として自分のものにできれば今後の生活にプラスになったり、危機を回避できたりするかもしれません。

▼出版社のweb　（詳しい目次とサンプルコードダウンロードサービスあり）
http://www.oreilly.co.jp/books/9784873113371/index.html

◇モサ伝編集部から「りんご味Ruby」は都合によりお休みします。◇

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