MOSA Multi-OS Software Artists

目次

• 「Wonderful Server Life」　　　　第87回　　　田畑 英和
• 小池邦人のCarbon視点でiPhone探求
• ターミナルの向こうから　　　　　　第42回　　海上 忍　

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

〜「Podcast プロデューサー」編〜

　今回はPodcastプロデューサーの稼働に必要となるXgridについて解説します。実はPodcastプロデューサーでシステムを構築するには他にも必要となるサービスがあるのですが、まずはXgridからみていくことにします。
　
◇Xgrid
　XgridはTigerで初めて搭載されたサービスで、Xgridを用いることで、ネットワーク上の複数のコンピュータで処理を分散して実行できるようになります。Xgridによるシステムを構成するには、まず次の3つのコンポーネントについて理解しておく必要があります。

・Xgridを構成するコンポーネント

クライアント：Xgridにジョブ（処理）を依頼するコンピュータ
コントローラ：ジョブを管理するコンピュータ
エージェント：タスク処理を実行するコンピュータ

　Xgridに処理を依頼するのはPodcastプロデューサーですので、この場合クライアントはPodcastプロデューサーになります。
　コントローラにはMac OS X Serverを使用します。コントローラはクライアントからジョブを受け取り、ジョブを複数のタスクに分割してエージェントに処理を依頼します。
　実際に処理を実行するのがエージェントです。エージェントにはMac OS XとMac OS X Serverの両方を利用することができ、1台のコントローラから複数のエージェントを利用することができます。エージェントの台数に制限はありませんが、エージェントの数が増えるとネットワークなどシステム全体の負荷も高まるため、単純に台数を増やせば増やすほどよいというものでもありません。

◇Xgridの設定
　それではXgridの設定方法について解説します。今回は1台のサーバをXgridのコントローラ兼エージェントとし、同一サーバ上でPodcastプロデューサーを稼働させることにします。
　Xgridサービスを設定するには「サーバ管理」を使用します。まず「サーバ管理」からサーバに接続し、左側のリストからXgridを選択します。Xgridをまだリストに表示していない場合は、リストからサーバを選択してツールバーから「設定」＞「サービス」を選択し、「Xgrid」を有効にして画面右下の「保存」ボタンをクリックします。
　Xgridの「設定」画面ではエージェントとコントローラについてそれぞれ設定ができますが、アシスタント機能を使って設定することもできます。
　アシスタント機能を利用するには「概要」画面の右下にある「Xgridサービスを構成」ボタンをクリックします。なおこのときサーバ上ではすでにOpen Directoryのマスターが稼働しているものとします。

・Xgridのサービス構成アシスタントの設定手順

1. アシスタント画面が表示されたら、「続ける」ボタンをクリックします。
http://www.htabata.com/img/MXS105/xgrid/Xgrid_admin_02.png

2. 構成画面では「グリッドを管理」を選択して「続ける」ボタンをクリックします。「グリッドを構成」を選択するとMac OS X Server上でエージェントとコントローラの両方が起動します。
http://www.htabata.com/img/MXS105/xgrid/Xgrid_admin_03.png

3. 認証画面ではディレクトリ管理者のユーザ名とパスワードを入力して「続ける」ボタンをクリックします。
http://www.htabata.com/img/MXS105/xgrid/Xgrid_admin_04.png

4. 最後に設定内容を確認すればXgridサービスの設定は完了です。

　以上の操作でMac OS X Server上でXgridのエージェントとコントローラが使用可能になります。このときエージェントはコントローラとして自分自身を使用し、認証方式にはKerberosを使用するよう設定されます。

◇Xgridの動作確認
　Xgridには管理ツールとして別途「Xgrid Admin」も用意されています。このツールも「サーバ管理」と同様にAdmin Toolsの一部ですので、クライアントのMac OS X上でも使用可能であり、「/アプリケーション/サーバ/」にインストールされます。
　「Xgrid Admin」を使用するとXgridのコントローラに接続して、Xgridの状態を確認することができます。クライアントからネットワーク経由で「XgridAdmin」を使用する場合は、まず「ディレクトリユーティリティ」を使ってクライアントをOpen Directoryのサーバに接続しておきます。これはXgridコントローラへの接続時にKerberosを使って認証するためです。

　「Xgrid Admin」が起動したらまず接続するコントローラを指定し、認証方式として「シングル・サイン・オン資格情報を使用する」を選択します。このときすでにKerberosのチケット(TGT)を取得していればそのままコントローラに接続できます。まだKerberosのチケットが取得できていない場合はKerberosの認証ダイアログが表示されて、認証を求められます。「XgridAdmin」ではエージェントの一覧などが確認できます。

・KerberosでXgirdの認証を行ったときのチケットの様子
http://www.htabata.com/img/MXS105/xgrid/Kerberos_01.png

　Developer Tools(Xcode)をインストールしている場合は、Xgridを利用したサンプルプログラムが収録されていますので、実際にXgridを使用することができます。

・Xgridのサンプルプログラムのパス
 

  /Developer/Examples/Xgrid

　サンプルプログラムは2つ収録されていますが「GridMandelbrot」は見た目も派手ですのでまずはオススメです。このサンプルプログラムを実行すると、Xgridを利用してマンデルブロ集合を描画することができます。サンプルプログラムを起動したときには「Xgrid Admin」と同様にコントローラと認証方式の指定が必要になります。

・Xgridサンプルプログラム「GridMandelbrot」
http://www.htabata.com/img/MXS105/xgrid/Xgrid_Mandelbrot03.png

　プログラムの実行中に「Xgrid Admin」をみるとXgrid全体でどれだけのCPUパワーを使っているかや、実行中のジョブを確認することができます。

・Xgrid Admin
http://www.htabata.com/img/MXS105/xgrid/AdminTool_01.png
http://www.htabata.com/img/MXS105/xgrid/AdminTool_03.png
次回へつづく

小池邦人のCarbon視点でiPhone探求（2009/02/20）

〜　ああ、SysBeep(1)が懐かしい！　〜

今回から、作成したモデルオブジェクトを管理し、アーカイブとしてファイルへ保存やメモリーへの読み込みを行うモデルコントローラの話に入ります。これは、Mac用のCocoaアプリケーションであれば「NSDocument」が行う仕事です。

OOPの世界では、モデル・ビュー・コントローラ（MVC）という単語がよく出てくるのですが、これは大ざっぱなクラス役割分担を指しています。大規模なアプリケーションなどでは、上記コントローラがモデル寄りの役割とビュー寄りの役割に分かれて作業分担している場合があります。片方をモデルコントローラと呼び、もう片方をビューコントローラと呼んだりします。まあ、正確なクラスカテゴリーの切り分けについては、私も勉強不足で良く理解できていませんが（笑）、例えば、Mac用Cocoaアプリケーションを開発する時に、Xcodeのプロジェクトテンプレート（雛形）から「Cocoa Documentbased Application」を選んで作業を開始すると、必ずAppKitNSDocumentクラスのお世話になります。

このNSDocumentクラスが、もっとも身近なモデルコントローラの例です。通常このテンプレートを使ったアプリケーションでは、NSDocumentクラスをスーパークラスとする独自クラスを用意し（例えばMyDocumentクラスとか…）そこで、NSDocumentクラスが実装しているメソッドをオーバライドすることで、ファイル保存されているドキュメントに対する操作（読み込みや書き出し）などを実現します。しかし残念ながら、iPhoneのUIKitには、これに準じるクラスが存在していません。まあ、iPhoneアプリでは不特定多数のファイルを同時に取り扱うケースが少ないので、モデル管理としてはSQLite（データベース用フレームワーク）があれば十分だろうと言う判断かもしれません。

しかし、今回はSQLiteを使わずに、独自でモデルコントローラを実装してみることにします。さてモデルコントローラの話へと移る前に、実際のコーディング作業を効率良く行うための準備をします。まず最初に、テキストエディターの各種設定を自分の環境に合わせることが大事でしょう。それには、Xcode環境設定の「コード入力補助」「キーバインド」「テキスト編集」「フォントと
カラー」などに含まれる設定項目の意味を良く理解し、それを自分の環境にマッチした設定に変更する必要があります。まあ、すべてデフォルトでOKな人はまったく問題ないのですが（笑）ちょっとした設定を変更するだけで、ソースコードの入力し易さが激変することがありますので、一度腰を落ち着けてチェックしてみてはいかがでしょうか？

例えば「コード入力補助」の「自動的に候補を表示」の設定ですが、これが機能するのが「大きなお世話」だと感じる人もいるはずです。その場合は「しない」に変更します。候補が表示されるタイミングも「すぐに」と「少し経ってから：」（秒数も指定可能）の2種類から選べますので、どちらが自分のキータッチのタイミングに合うのか試してみることが大事です。加えて、エディター入力時の文字サイズとカラーも環境設定の「フォントとカラー」で調整しておきましょう。大きなスクリーンを利用している人は、10ポイント文字ではさすがに小さすぎますし（老眼ではないとしても）、デフォルトもカラー設定もちょっとビビッド（笑）すぎるような気がします。結局、筆者はすべてのカラーの輝度を落とすことで再調整してしまいました。

そうそう、文字カラー変更の話が出たついでに、このカラー変更の対象となるインスタンス変数名の話もしておきます。前回、モデル（Model）クラスを定義する時に、そのインスタンス変数の先頭を「mo_」という表記で揃えました。これは「二文字＋アンダーバーが先頭についているのはインスタンス変数である」という「識別し易さ」を考慮したわけですが、これについては色々な意見があると思います。「カラーを変更すればOKでは？」と言う人もいるでしょう。Apple社のフレームワークで定義されているインスタンス変数は先頭にアンダーバーが付いていますので、それらを継承したクラスの方では一般的な変数名を付けても問題はありません。ですから、「md_name」は、単純に「name」の方が分かり易いという人もいるでしょう。

今までMac用Cocoaアプリケーションを開発する時には、ほとんどの場合はアクセッサを用いてインスタンス変数にアクセスしました。ですから、対象クラスの外でインスタンス変数を記述するようなことは滅多にありませんでした。しかし、プロパティ宣言ができるようになり、ドット演算子によるアクセスが可能となって、インスタンス変数名がソースのあちらこちらに登場するようにな
りました。この状況で各クラスに同じインスタンス名があると、その名称をエディターで一括変換（全ソース対象）したい場合に問題が生じます。まあ、これはアクセッサメソッド名の一括変換についても同じことが言えるのですが…。とにかく「変数名についてはこうだ！」「メソッド名はこうだ！」と、自分の中で一貫したルールを決めておくことが重要なのかもしれません。

続いてもう一つ！　CocoaにはNSLog()という便利なコンソールへのログ書き出しルーチンが存在します。これをうまく活用して何らかの情報を表示すれば、デバッグを効率良く行うことができます。しかし、筆者も含めて昔から簡単なデバッグにビープ音を使っている人も多いと思います（本当か？）。「その処理を通ったのか、通らなかったのか？」「どの処理まで入ってきたのか？」
「そこを何回通ったのか？」などなど、ビープ音による識別は、コンソールをオープンせずともちょっとしたチェックが可能で大変便利なのです。ところが、iPhoneのUIKitにはCarbonのSysBeep(1)やMac版CocoaのNSBeep関数が存在しません。つまり簡単にビープ音を鳴らすことができないのです。

ならばと言うことで、AudioToolboxのAudioServicesCreateSystemSoundID()ルーチンを使い、以下の様なビープ音を鳴らすルーチンを作ってみました。ビープ用のサウンドファイル（bp.wav）をプロジェクトのResourcesグループに登録しておき、アプリから呼び出して使います。

SystemSoundID   sys_sound;

void sysBeep()
{
   NSString    *path;
   NSURL       *url;

   if( ! sys_sound )       
   {
       path=[[NSBundle mainBundle] pathForResource:@"bp" 
                                                     ofType:@"wav"];
       if( url=[NSURL fileURLWithPath:path ) 
            AudioServicesCreateSystemSoundID( (CFURLRef)url,
                                                       &sys_sound );
   }
   if( sys_sound )
       AudioServicesPlaySystemSound( sys_sound );
}

AudioServicesPlaySystemSound()は短い（5秒以内）サウンドを鳴らすための便利なルーチンです。ところが、現在のiPhoneシミュレーターは、このルーチンでは音がでません（実機は大丈夫）。シミュレーターで鳴らせなくてはデバッグ時には活用できません。Core Audioを使いサウンドを鳴らすクラスを実装すればOKなのですが、処理が少々大げさでビープルーチンとは言い難くなります。困っていたところ、iPhone OS 2.2からAVFoundationと呼ばれるフレームワークが登場し、そこに含まれるAVAudioPlayerクラスを使うと、シミュレーターでも簡単にビープ音が鳴らせることが分かりました。現在では、このルーチンをデバッグにフル活用しています。Objectibve-Cにおいても、こうしたユーティリティ的なルーチンはCルーチンとして実装しておく方が便利です。

AVAudioPlayer    *sys_beep;

void sysBeep()
{
   NSString    *path;
   NSURL       *url;

   if( ! sys_beep )
   {
       path=[[NSBundle mainBundle] pathForResource:@"bp" ofType:@"wav"];
       if( url=[NSURL fileURLWithPath:path] )
           sys_beep=[[AVAudioPlayer alloc] initWithContentsOfURL:url
                                                               error:nil];
   }
   if( sys_beep )
   {
       sys_beep.currentTime=0;
       [sys_beep play];
   }
}

ちょっと寄り道をしましたが、次回から本格的にモデルコントローラクラスを実装していきたいと思います。まずは、モデルのアーカイブ化を行うために、NSCodingプロトコルに準拠したencodeWithCoder:とinitWithCoder:の2つのメソッドを用意することから始めたいと思います。

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

〜 いま敢えて学ぶTerminalのイロハ（9） 〜

　コマンドは、ターミナルの画面上で手入力されるだけの存在ではありません。システム運用の実際では、むしろ「シェルスクリプト」の形で利用されることが多く、その使い方と基本的な記述方法は知っておいて損のないものです。ターミナルシリーズ9回目となる今回は、シェルスクリプトについて説明します。

・シェルスクリプトとは
　シェルスクリプトとは、かんたんにいえば「コマンドのら列」です。実行順にコマンドを並べたテキストファイルがシェルスクリプトの本質であり、拡張子などファイル名に関する命名規則もありません。後述しますが、ファイルに実行権限を与えれば（実質的に）コマンドとして機能します。
　それでは、ごくかんたんなシェルスクリプトで説明してみましょう。標準出力（初期値はターミナルの画面）に「MOSA」という文字列をアウトプットする、わずか1行で構成されるものです。ファイル名は、仮に「mosaout.sh」としておきます。適当なテキストエディタで以下の行を入力し、ホームフォルダ直下へ保存してください。

- - - - -
echo "MOSA"
- - - - -

　作成したシェルスクリプトは、シェルに引数として渡すことで実行します。一般的に、シェルスクリプトはどのシステム（歴史的経緯からUNIX系OSが前提）にも備え付けられている「sh」で実行されることが想定されているので、ここでも「sh」で実行することにします。ターミナルを起動し、以下のとおりコマンドラインを実行すれば、シェルスクリプト（mosaout.sh）の内容が実行
されたことがわかります。

- - - - -
$ sh mosaout.sh
MOSA
- - - - -

・実行権限を与える
　シェルスクリプトは、ファイルに「実行権限」を与えることで、あたかも（バイナリ形式の）コマンドであるかのように振る舞うことが可能です。実際、Mac OS Xにもzles（/usr/bin/zless）やapropos（/usr/bin/apropos）など、コマンドとして使われているシェルスクリプトが多数存在します。
　ファイルに実行権限を与えるには、chmodコマンドを利用します。オプションに「+x」を与え、引数に先ほどのシェルスクリプトを指定すればOKです。参考までに、実行権限を与える前後のファイル詳細情報を添えておきますが、与えたあとは「x」が増えていることがわかるはずです。

- - - - -
$ ls -l mosaout.sh 
-rw-r--r--  1 shinobu  staff  12  2 22 08:01 mosaout.sh
$ chmod +x mosaout.sh 
$ ls -l mosaout.sh 
-rwxr-xr-x  1 shinobu  staff  12  2 22 08:01 mosaout.sh*
- - - - -

　実行権限が付与されたあとは、起動用のシェル（sh）を指定することなく、現在実行されているシェル（bash）でシェルスクリプトが実行されます。ちなみに、Mac OS Xに収録されている「sh」は、bash（/bin/bash）のファイル名が変更されたもので機能差はなく、「shmosaout.sh」としたときと同じ結果を得られます。
　ただし、カレントディレクトリにコマンドサーチパス（第38回を参照願います）は通っていないため、ファイル名だけではシェルスクリプトを実行できません。パスの指定、この場合カレントディレクトリ直下のファイルであることを示す「./」を、ファイル名の先頭に加える必要があります。なお、このファイルをパスの通ったディレクトリ — /usr/binや/usr/local/bin — へコピー
すれば、当然ながらこの記号を入力する必要はありません（「mosaout.sh」と実行するだけでOK）。

- - - - -
$ ./mosaout.sh
- - - - -

　もう少しシェルスクリプトらしい体裁も施しておきましょう。シェルスクリプトが実行された場合、インタープリタである（現在実行中の）シェルはスクリプトの1行目に記述されている内容を判断し、子プロセスとして実行するためのバイナリを決定するため、1行目にはシェルスクリプトを実行したいシェルのフルパスを記述しておくことが「お約束」となっているからです。
　前述したとおり、シェルスクリプトはUNIX系OSならばほぼ確実に収録されている「/bin/sh」で実行されるため、1行目には「/bin/sh」を指定する記述を加えておきます。つまり、mosaout.shは以下の内容で一応の完成を見ることになります。
　1行目の記述を変更すれば、他のスクリプト言語も実行できます。たとえば、Perlは「#!/usr/bin/perl」、Rubyは「#!/usr/bin/ruby」となります。なお、他の言語の場合も実行権限の付与は必要です。

- - - - -
#!/bin/sh
echo "MOSA"
- - - - -

　シェルスクリプトでなにか処理を行おうした場合、重要な役割を果たすのが「シェル組み込み（ビルトイン）コマンド」です。シェルには、条件分岐やループ処理などの機能を持つコマンドが多数装備されているので、それを活用してプログラミングを行えば高度な処理が可能になります。次回は、構文ルールなどの解説とともに、参考となる書籍やWebサイトを紹介する予定です。

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