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

■　 〜新Xserve〜

　MacWorld開催前にMac ProとXserveの新モデルが発表されました。今回は新しくなったXserveについて取り上げてみたいと思います。

◇8コアに進化したXserve
　前モデルはデュアルコアのIntel Xeon 5100を2基搭載できましたが、今回のモデルチェンジではCPUが4コアのIntel Xeon 5400に変更になりました。CPUを2基搭載して8コアの構成を選択できるようになっていますのでパフォーマンスの向上が期待できます。OnlineのApple Storeでの標準構成は次のような仕様になっています。

・Xserve標準構成（359,800円）
　　CPU：2.8GHz 4コア Intel Xeon 1基
　　Memory：2GB(2 x 1GB)
　　HDD：80GB SATA(7200rpm)
　　グラフィック：ATI Radeon X1300

　このように標準構成では4コアになりますが、BTOでのオプションを選択すれば、2.8GHzまたは3.0GHzの4コアXeonを2基搭載できるようになっています。
　メモリスロットは8基用意されており、全てのスロットに4GBのメモリを使用すれば32GBまで拡張できるようになっています。ただし4GBのメモリを8枚用意するとなると非常に高価格（Apple Storeで32GBを選択すると価格が1,163,820円も上がる）になりますので、ここまでメモリを使用するのはかなり限られたケースになるかと思います。
　HDDは前モデルと同様にドライブベイが3基用意されており、シリアルATAまたはSASのドライブが使用できます。BTOでは1TBのドライブ(SATA)を3基使用すると3TBのストレージを実現することができます。さらに前モデルでも用意されていたRAIDカードがオプションで装備できますので、これを使用すればハードウェアによるRAID(JBOD/0/1/5)を構築することができます。
　前モデルから標準装備されるようになったグラフィックカードは新モデルでも標準装備になっており、BTOではグラフィックカードを省くこともできます。
グラフィックカードを省くと価格が若干（6,090円）下がります。Xserveはネットワーク上のほかのMacからリモート管理が出来ますので、必ずしもグラフィックカードは必要ありませんが、万が一ネットワークに問題が生じた場合にはリモート管理ができなくなりますので、いざというときに備えて標準構成のままグラフィックカードを搭載しておくのもよいでしょう。

　インターフェイスにも変更がありました。これまではフロントパネルにFireWire 400のポートが1基装備されていましたが、これがUSB 2.0のポートに変更になりました。前モデルでも新モデルでもリアパネルにもUSBポートが装備されてはいますが、スペースが限られておりメモリスティックなどを使用するとものによってはうまくささらなかったりしましたので、スペースに余裕のあるフロントパネルもポートが装備されたことでUSBデバイスは使いやすくなったのではないでしょうか。ただしこれまで装備されていたFireWire 400のポートは廃止され、リアパネルにはFireWire 800のポートが2基装備されています。その他のポートは、ギガビットEthernetのポートが2基とDB-9のシリアルポートが1基装備されています。

　拡張スロットはPCI Express 2.0に対応したものが2基用意されており、ライザーカードを使用すれば片方の拡張スロットではPCI-Xのカードを使用することもできます。拡張スロット用のカードとしては、SCSIカード、ギガビットEthernetカード、4GbのFibre Channelカードが用意されています。

　OSは昨年発売になったMac OS X Server v10.5 LeopardのUnlimitedクライアント版が付属します。サーバを構築する場合、同時に発売になったMac Proを使用するといった方法もありますが、この場合Mac OS X Serverは別途購入する必要がありますので、トータルコストバランスを考えればXserveでの運用のほうが有利な場合があります。もっともXserveはラックマウント用のサーバであり、奥行きもかなりありますので設置場所をあらかじめ考慮しておく必要があります。

◇次回はディレクトリサービス
　さて次回からはまたLeopard Serverについての解説に戻りたいと思います。様々なサービスがありますのでどこから始めていくか悩むところですが、まずはシステムの中核ともなるディレクトリサービスから始めていきたいと思います。実はLDAPによるアカウント管理、Kerberos／パスワードサーバによる認証など基本的な構成はあまりTiger Serverから変わっていないのですが、Leopardで新たに導入された標準／ワークグループ構成におけるディレクトリサービスの役割など、あらかじめよく分っていないと混乱しやすい部分などもありますので、変更点なども交えながら詳しく解説していきたいと思います。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　次回へつづく

小池邦人のCarbon視点でCocoa探求（2008/01/25）

〜　既にあるものは使いましょう！　〜

今回は、アバウトウィンドウへのボタンや画像の配置、ボタンとアクションのリンク、記述したソースコードの解説などを行います。また、練習用に追加した不要なソースコード部分を外す処理も行います。

About.nibファイルに登録したAboutウィンドウは、そのままでは空っぽなので、お気に入り画像やコピーライト文字列、そしてウィンドウを閉じるときに使う「OK」ボタンなどを配置します。まずウィンドウを選択し、インスペクタのIdentityのClassをNSWindowのサブクラスである「NSPanel」に変更しておきます。続いてAttributeの方に戻り、使わない「Resize」や「Minimize」のチェックを外します。Titleの下の「Frame Name」に何らかの名称を代入しておくと、そのウィンドウをオープンした位置が自動で記憶されますが、アバウトはいつもスクリーンの中心に表示させる予定なので、このカラムへの名称代入は必要ありません。

まずは画像です。先んじてAboutに表示したいJPEG画像ファイルを用意して、Xcodeの ShinbunShi3プロジェクトの「Resources」グループに登録しておきます。本サンプルでは、Koike.jpg、About.jpg、Symmetry.jpgといった画像ファイルが用意されています。そうすると、これらの画像アイコンがInterface Builderのライブラリの「Media」タブに表示されますので、ここからドラッグ＆ドロップでAboutウィンドウへ配置します。もし表示画像に枠が必要なら、インスペクタのAttributesで「Border」の種類を選択できます。これらの画像は最終的にはアプリケーションパッケージのResourcesフォルダに
格納され、nibファイルからアクセスされることになります。

ボタンの配置は簡単です。Interface Builderのライブラリを「Objects」タブに切り替え、そこからボタンオブジェクトをドラッグ＆ドロップで好みの位置に配置したら、インスペクタのAttributesのTitleに「OK」を代入します。Carbonで、Returnキーを押す事で反応するデフォルトボタンを作るのには、AttributesのTypeを「Default」に設定すればOKでした。しかし、Cocoaのボタンではそれに準じる設定がありません。どうすれば良いのかとしばらく悩んだのですが（笑）「Key Equiv.」にReturnキーを入力すれば良い事に気がつきました。これで表示も青色に変わります。つまり、Carbonで言うところの
Cancelボタンであれば、ここにEscキーを入力しておけば良いわけです。

続いて、OKボタンのアウトレットをFile’s Owner（AboutController）の_okButtonに設定（リンク）する作業と、 ボタンのターゲット・アクション（押されたときに実行されるメソッド）をAboutControllerのcloseAbout:に設定する作業を行います。リンク対象となるアウトレットはAboutController.hに記述されている…

IBOutlet id _okButton;

です。Carbonで言えば、そのボタンのControlRefがこの変数に代入されると考えればOKです。ターゲットアクションの方は、AboutController.hに記述されている…

- (IBAction)closeAbout:(id)sender

です。 Carbonの場合には、ボタンにcommand（OSType）を設定でき、CarbonEventでそれを判別することでターゲットとなる処理ルーチンを実行するのですが、Cocoaでは、そのルーチンを直接ボタンに教え込む事ができると考えれば良いでしょう。さっそくリンク作業を行ってみます。

OKボタンを選択してインスペクタを表示します。ConnectionsのSent Actionsにある「selector」の右端の丸をドラッグします。すると「青い線」が表示されますので、引き延ばしてその先頭をFile’s Owner（青い立方体）アイコンに重ねます。そこでマウスを離すと、近くに「closeAbout:」と「showWindow:」という2つのメソッドが表示されますので、closeAbout:の方を選択します。これでアクションのリンクが完了しました。

続いて、File’s OwnerのConnectionsを表示します。Outletsの「_okButton」から線を引いてウィンドウ上のOKボタンにリンクします。同様に、Outletsの「window」の方は、Aboutウィンドウのアイコンにリンクします。これで両アウトレットのリンクが完了しました。こうしたオブジェクト間の線によるリンクは、インスペクタからだけではなく、オブジェクトをControlキーを押しながらマウスクリックすることでも可能です。

上記のアウトレットやアクションのリンク作業は、About.nibファイルがXcodeのプロジェクトに登録されていないと行えません。また、 アウトレットのwindowをリンクし忘れると、AboutController（WindowControllerのサブクラス）が自分の担当するウィンドウをnibファイルから読み込めなくなりますので（表示できない）注意してください。

ところで、今回用意した_okButtonアウトレットの実際の用途はありません（単にリンクの練習用）。また、 ウィンドウを閉じるアクションのcloseAbout:の方は、NSWindowクラスの以下のメソッドで代用できます。

- (void)performClose:(id)sender

これは、ファイルメニューの「閉じる」が選択された時のアクションでして、そのメッセージは現在のフロントウィンドウに渡ります。ですから、OKボタンのselectorアクションをこちらに変更すれば、closeAbout:とまったく同じ結果を得られます。このアクションへリンクするには、selectorからの線をFirst Responder（赤い立方体）アイコンの方へ延ばし、表示されたアクションの中からperformClose:を選択すればOKです。

そんな訳で、NSWindowControllerのサブクラスとして用意したAboutControllerクラスが不必要となりました。そこで、AboutControllerクラスを使わなくてもOKな様に、nibファイルとソースコードを若干修正します。
まずは、About.nibのFile’s OwnerのClassをAboutControllerからNSWindowControllerに変更し、続いてApplicationConroller.hの内容を…

@interface ApplicationConroller : NSObject
{
    AboutController *_aboutController;
}

から

@interface ApplicationConroller : NSObject
{
    NSWindowController *_aboutController;
}

へと修正します。そして次に、ApplicationConroller.mの内容を…

- (IBAction)openAboutWindow:(id)sender
{
    if( ! _aboutController )
        _aboutController=[[AboutController alloc] init];
    [[_aboutController window] center];
    [_aboutController showWindow:self];
}

から

- (IBAction)openAboutWindow:(id)sender // Aboutウィンドウを表示させるメソッド
{
    if( ! _aboutController ) //  アバウトウィンドウは最初に一度だけ作成される
    {
        _aboutController=[ [NSWindowController alloc]
                    // NSWindowControllerクラスのインスタンス化
                                     initWithWindowNibName:@"About"];
                    // Aboutウィンドウを指定nibから読み込みNSWindowController管理下に
    }
    [[_aboutController window] center]; // Aboutウィンドウを中心位置へ移動
    [_aboutController showWindow:self]; // Aboutウィンドウを表示する
}

へと修正します。最後にプロジェクトから、AboutController.hとAboutController.mを外し（削除）てしまえば、修正作業は完了です。

次回は、「しんぶんし 3」で必要とされるだろうデータ構造（モデル・オブジェクト）について考えてみます。基本的には、複数の画像ファイルを管理するのに必要とされるデータ構造です。本連載で作成したプロジェクトファイルは、MOSA Exchangeに順次アップロードされています。今回分の名称は「ShinbunShi3_08_01_25.zip」です。

つづく　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

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

〜 Yet Anotherなテキスト処理系を考える （2）〜

　前回は、GhostScriptというアプリケーションの概要について説明しました。今回は、日本語処理との関係と、GhostScriptとの「対話」について取り上げます。

・GhostScriptと日本語処理の関係
　フリーなPostScript互換インタープリタとして開発がスタートしたGhostScirptは、当初日本語を扱えませんでした。そもそもPostScriptのType1フォントフォーマットは欧文を前提としており、扱えるデータが1バイト256文字種に制限されていたことが理由です。有志ユーザの手により日本語化も行われていましたが、正式に扱えるようになったのはコンポジットフォントをサポートしたバージョン3の代です。
　それからしばらくの間は、コンポジットフォント（バージョン5からはCIDフォントも）を使うことで日本語に対応してきましたが、GS-CJKプロジェクトの働きにより、CIDフォントの扱いが簡略化されるとともに、TrueTypeフォントがサポートされました。種類が多く入手しやすいTrueTypeフォントのサポートにより、GhostScriptの日本語対応は格段に向上したといえます。
　上記の経緯から、最新バージョン（v8.61）のGhostScriptはデフォルトで日本語に対応していますが、巷ではいまだ「日本語版」と銘打ったパッケージが配布されています。これは、日本語用のフォントマップなど、日本語処理に必要だがGhostScriptの標準配布物には含まれないリソースをパッケージングしたものです。フォントの設定には興味がない、とりあえずPostScript互換インタープリタを試せればそれでいい、という場合には、前回も紹介した「GPL/ESP Ghostscript 8.15.4 for MacOSX 10.5 (ppc/intel)」をインストールすればOKです。

http://www2.kumagaku.ac.jp/teacher/herogw/index.html

・なぜMac OS XでGhostScript?
　Mac OS XでGhostScriptを必要とする場面は、大きく分けて2つあります。
　その1つが、LaTeXで作成したPostScriptファイル（.tex → .dvi → .ps）の出力です。Mac OS Xの描画/印刷エンジンQuartzは、フォント名だけでなくフォントデータそのものを埋め込んでプリンタへ送信しますが、LaTeXで作成したPostScriptファイルのようにフォントデータを持たないものを処理するときには、PostScriptインタープリタが必要となります。
　しかし、Mac OS Xでこの役割を担うはずのPSNormalizer.framework（およびフロントエンドのpstopdfコマンド）は、2バイト文字に対応していません。処理対象外のフォントはすべてCourierに置換されてしまうため、Ryumin-LightやGothicBBB-Mediumといった日本語フォントの部分は、意味不明となります。それが、GhostScriptを必要とする理由です。
　もう1つが、前回解説した「印刷時のフィルタ」です。この場合GhostScriptは、プリンタ記述言語や印刷システム（CUPS）へ橋渡しするドライバとしての機能を果たします。このときは、ユーザサイドがGhostScriptの存在を気にかける必要はほとんどありません。

・GhostScriptの使い方
　能書きが多くなってしまったので、肩慣らしにGhostScriptと「対話」してみましょう。前述のGhostScriptパッケージをインストールすると、「gs」コマンドがインストールされるので、ターミナルから「gs」を実行します。すると、バージョン名などが表示されたあとに、次のようなプロンプトが表示されるはずです。

- - - - -
GS>
- - - - -

　これが、GhostScriptのシェルです。ここへPostScriptのコードを入力すれば、GhostScriptが処理を行います。PostScriptは逆ポーランド記法の言語ですから、「3+4」の計算は「3 4 add =」のような要領で行うことになります。

- - - - -
GS>3 4 add =
7
- - - - -

　足し算だけでは味気ないので、簡単な絵を描いてみましょう。ただし、今回利用しているGhostScriptは、出力デバイスとしてQuartzをサポートしていないので、X11の描画機能を利用します。X11.appを起動し、そちらのターミナル（xterm）から「gs -sDEVICE=x11」としてGhostScriptを起動します。現れた真っ白なウインドウが、GhostScriptのシェルから実行したコマンドの出力先となります。
　次に示すコマンドは、X座標=300 / Y座標=400の位置に、半径200ポイントの黒塗りの円を描きます。あとはPostScriptプログラミングの領域の話となりますが、正方形や正三角形を正確に描くときなど意外に重宝する（画像ファイルを出力先に指定できます）ので、お手すきのときに調べてみてはいかがでしょうか。

- - - - -
newpath
300 400 200 0 360 arc fill
- - - - -

ニュース解説　　　MOSAic

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

・12月のニュース
http://www.mosa.gr.jp/?p=1476

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

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

今回から数回にわけて、Objective-Cで書かれているXcode ToolsのサンプルアプリケーションSketchに、RubyCocoaフレームワークをリンクして、Rubyプログラムで機能(新たな種類のグラフィックオブジェクトなど)を追加していく様子を示すことにします。

Sketchのプロジェクトフォルダは /Developer/Examples/AppKit/Sketch にあります。このフォルダを適当なところにコピーして、改造用のSketchプロジェクトとしてください。コピーしたらとりあえず、Xcode3でSketch.xcodeprojを開いて、ビルド・実行してみて、まったく手を付けていない素のSketchが動作することを確認しておくとよいでしょう。よろしいでしょうか？　では機能追加にとりかかります。

■ RubyCocoaフレームワークを追加

まずは、以下のような手順でRubyCocoaフレームワークを追加してください。

・プロジェクトウィンドウ内のグループとファイルの一番上、Sketchプロジェ
クトの中にあるExternal Frameworksグループを選択
・コンテキストメニューで「追加/既存のフレームワーク」コマンドを実行
・/System/Library/Frameworks/RubyCocoa.framework を追加

■ RubyCocoaを初期化するおまじない

次に、Sketchのmain関数にRubyCocoaを初期化するためのおまじない的なコードを書き加えます。main関数が定義されているSKTMain.mを開いて以下のように2行を書き加えてください:

--------------------------------------- SKTMain.mから抜粋 --
#import 
#import                   // 追加1

int main(int argc, const char *argv[]) {
 RBApplicationInit("main.rb", argc, argv, nil); // 追加2
 return NSApplicationMain(argc, argv);
}
-------------------------------------------

RubyCocoaフレームワークの関数RBApplicationInitは、アプリケーションのためにRubyCocoaを初期化します。この関数が呼ばれると、RubyCocoa自体を初期化(まだ初期化されていなければ)して、そのあと、一番目の引数で指定されたRubyプログラム(ここではmain.rb)が実行されます。

SKTmain.mをXcode3で編集している場合は、RBApplicationInitのところにマウスをおいてコンテキストメニューの「定義へジャンプ」コマンドを実行すると、ヘッダーファイルRBRuntime.hにあるRBApplicationInitの宣言と簡単な説明を読むことができます。

■ main.rb の記述

次にmain.rbを作ります。以下のような手順でmain.rbを生成してください:

・プロジェクトウィンドウで、Sketchプロジェクトを選択
・コンテキストメニューで「追加/新規ファイル」コマンドを実行
・Ruby application init を選択
・main.rb という名前で保存

生成されたmain.rbを開いてください。以下のようなRubyプログラムが生成されています。

------------------------------------------- main.rb --
require 'osx/cocoa'

def load_ruby_programs(bundle)
 path = bundle.resourcePath.fileSystemRepresentation
 rbfiles = Dir.entries(path).select {|x| / .rb z/ =~ x}
 rbfiles -= [ File.basename(__FILE__) ]
 rbfiles.each do |path|
   require( File.basename(path) )
 end
end

OSX.init_for_bundle do |bundle, param, logger|
 # bundle  - the bundle related RBApplicationInit
 # param   - the 4th argument of RBApplicationInit
 # logger  - NSLog wrapper for this block
 #             usage: log.info("param=%p", param.to_s)
 load_ruby_programs(bundle)
end
-------------------------------------------

先に説明したように、RBApplicationInitが呼ばれると、このmain.rbが実行されます。

ごちゃごちゃと書かれているように見えるかもしれませんが、手短に説明すると、このプログラムは、アプリケーションバンドルの中のResourcesフォルダの中にあるすべてのRubyプログラム(拡張子が.rbのファイル)をロードしています(load_ruby_programsの中身)。

[余談] ちょっと細かい話をすると、main.rb自体もResourcesフォルダの中に置かれるのですが、ということは、main.rb自体が再帰的に無限にロードされてしまうのではないかと心配になりませんか？　load_ruby_programsメソッドの

rbfiles -= [ File.basename(__FILE__) ]

の行のところで、自分自身(main.rb)を採取したRubyプログラムの一覧から取り除いて再帰的なロードが発生しないようにしてあります。Rubyプログラムでは、そのプログラムが記述されたファイルへのフルパスが __FILE__ という定数に定義されています。[余談終わり]

さて、このmain.rbがちゃんと実行されているか確認の意味を兼ねて、RubyやRubyCocoaのバージョン情報をログに出力するようにコードを書き加えることにします。main.rbの OSX.init_for_bundle のブロックの中身を以下のようにしてください:

OSX.init_for_bundle do |bundle, param, logger|
 logger.info("RUBY_VERSION=%s", RUBY_VERSION)
 logger.info("RUBYCOCOA_VERSION=%s", OSX::RUBYCOCOA_VERSION)
 logger.info("RUBYCOCOA_SVN_REVISION=%s", OSX::RUBYCOCOA_SVN_REVISION)
 load_ruby_programs(bundle)
end

■ RubyCocoa組み込み完了

今回はここまでです。ビルド・実行してみてください。コンソール(実行メニューのコンソールコマンド)を見るとRubyとRubyCocoaのバージョンが出力されていれば、うまく動いているということになります。いかがでしょう？

これで下準備はできました。Sketchでは、ツールパレットから4種類のグラフィックオブジェクト(Rectangle, Circle, Line, Text)を選んで描くことができます。次回は、Sketchに、5つめのグラフィックオブジェクトとして角丸四角形RoundRectangleを、Rubyプログラムとして組み込んでみることにしましょう。

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

　ちょっと時間が経ってしまったがみなさん、明けましておめでとうございます。
　実を言えばこの新年第一回の原稿を書くにあたり、谷川俊太郎が水尾比呂志への結婚祝いにハンカチーフを選んだときのように（「あれにしようかこれにしようか散々迷った挙句に買った結婚祝につけて水尾比呂志に贈る祝婚歌。又は、ハンカチーフの能について」という詩があるのだ）迷ってしまった。せっかく新年と共に始まるシリーズだし、なんか目新しいことをやりたいと思うのだがここんとこオレ自身がCocoaを使ってプログラムを書くてな仕事をやっておらず、これというネタが思い浮かばないのである。

　タカハシ編集長に相談したところ、「別にコードを含む記事でなくてもかまいません。たとえば『アプリケーション・プログラマは絶滅危惧種なのか？』というテーマでエッセイを書くというのはどうですか？」と言う。……いや正確にはメールに書いてきた。一瞬なるほどそのテか、と思ったが、そんなものを書いて「そうだ、我々はニホンオオカミのよう……ならまだしも、ドードー鳥のようにこれから絶滅していくしかないのだ」ちう結論に達してしまうのもコワイ（コワイでしょ？）やないの。

　実際のところ、最近街で石を投げれば（投げませんけど）「IT技術者」に当たり、その「IT技術者」に会社でどんなことやってんのと聞けば（聞きませんけど）彼らは十中八九我々のようなプログラマではなくて、いわゆる「ネット屋さん」であり、その仕事の内容も「ものを作ってる」というよりは「コンピュータ（サーバって言ってもいいけどさ）のお守りをしてる」に近いようだ。……こないだとあるお好み焼き屋で隣のテーブルを囲んでいた30代前半男女5人組から漏れ聞こえてきた会話をベースにしての想像で、もちろん統計的価値は全くないけどそれほど間違ってないと思う。

　そう言えばむかしむかしあるところに須藤慎一というヒトがいて（いま何してんだろと思ったら朝日新聞とかにセキュリティ関係の原稿を書いていた）、そのヒトの書いた「愛すべきハッカー」という本に、「コンピュータ関係の仕事として最低にランクされるのが『プリンタのおもり』、『テープかけ』、『カード読ませ』である」という記述があった。スドーさんはこれらの仕事の中身を詳しく説明し……あ、ここでも説明が必要かな？　もはや『カード読ませ』なんて羅宇屋とか射掛け屋と同じくらい珍しい仕事ではあるけど（笑）。

　とにかくハナシは「これらの仕事にはコンピュータ関係の知識はほとんど必要ないかわり、ひたすら体力と忍耐力が要求される。だからちょっとでもプログラムを組めるような学生ならこんな仕事はまず選ばない」（記憶で書いてるのであんまり正確な引用ぢゃありません）と続く。もうちっとましな仕事としてCOBOLをつかう業務用のオフコンソフト開発……これもあんまり頭は使わない。あ、いや、これはスドーさんがそう書いてたんであってオレの意見ぢゃないからね。

　で、ここまでくるともう想像がつくと思うが、当時「コンピュータ関係の仕事」として最も頭を使い、やりがいがあり、そしてそれなりにお金になる、とされていたのが「マイコン（つう言葉が現役だったころの本なのだ）組み込み機器やパソコンのためのソフト開発」であったのである。いや、あったのであるって他人事ぢゃなくて、そうだったからオレはいままでそれで食ってきたんだし、これを読んでいる大半のヒトがそうでしょ？

　しかし上にも書いたように、現在「IT技術者」と言ったら「サーバのおもり」になってしまった。「プリンタのおもり」よりは頭を使うかも知れないが（そしてそれなりに勉強も必要だろうけど）、少なくともオレには、あれが自分でイチからプログラムを作るほど面白い仕事とは思われない。でもタカハシ編集長の危機感どおり、なんつうかワクワクするようなプログラミング仕事の絶対量は減っている。なんでかしら？

　うーん、確かにコワイ結論になるかも知れないが、これについてちゃんと分析してみるのは面白そうである。つうことで、しばらく技術系のおハナシは他の方に委せ、このテーマを追っかけてみましょう。ご意見文句激励圧力などいただければケースバイケースでそれなりに歓迎撃退感謝反撃などいたしますのでどうぞよろしく。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　（2008_01_18）

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

コミュニケーション能力を高めよう(1)

　皆さんこんにちは、高橋真人です。
　今回は、今年最初の連載ということでもありますので、いつものお話をお休みして、年頭らしいお話をしたいと思います。テーマは、去年ぐらいから私の頭の中にある「言葉はデジタルだ」というお話です。

　人と人とが情報交換、つまりコミュニケーションを行う場合に大きな役割を持つのが言葉です。「“コンピュータとの会話”とかいう話なら分かるけど、人同士のコミュニケーションがプログラミングに何の関係があるの？」と思う人もいるかもしれません。
　プロのプログラマであれば、ユーザやお客さんとのコミュニケーションもプログラミングの一要素であることを否定する人は少ないでしょう。また、プログラムを作れば、そのプログラムを通してユーザーとの間にコミュニケーションが発生します。
　このように、プログラマにとってコミュニケーション能力が欠かせない資質の一つであることはお分かりいただけると思います。しかし今回は、まだプログラマとは自覚していない、この連載のもともとの対象読者であるプログラミングの学習者に焦点を当ててお話しします。
　それでは、プログラミング学習者という立場における対人コミュニケーションにはどのようなものがあるでしょうか。
　まず、人からプログラミングを習う場合、ここには当然コミュニケーションが成立します。一対一で教わるという恵まれた立場にはなくとも、講習会などに参加すれば、そこには講師と受講生という形でコミュニケーションが発生します。
　このような“空間を共有した”やり取りにおいては、言葉も重要な伝達手段であると同時に、言葉以外のいろいろな要素も大きく介在します。視覚や聴覚はもとより、ちょっと五感では表しにくい「何となくの雰囲気」などというのが、意外と「言葉にならない言葉」を伝えていたなんてこともままあることです。
　では、言葉以外の情報伝達手段が存在しない、書籍による学習のような場合はどうでしょう。
　コミュニケーションというと、双方向的なもののみを前提にすることも多いかもしれませんが、ここでは本のような一方向のみの情報伝達もコミュニケーションととらえて話を進めたいと思います。まあ、コミュニケーションという呼び方に抵抗があるならば、情報伝達と言い替えていただいても全く構いません。ちなみに、今まさに皆さんがこの文章を読んでいるのも、文字のみによるコミュニケーションであるということにはお気付きですか？
　さて、このような文字のみによるばかりか、一方通行の情報伝達ですといろいろな制約がありますから、充実したコミュニケーション、つまりより多くの情報を効率的かつ高精度に伝えるには、送り手である筆者と、受け手である読者の能力の巧拙が大いに影響してきます。
　まずは本を例にして、作者から読者への情報伝達の流れをざっと見てみましょう。

・作者が伝えたいことがある（思い）
・文章に起こす
・読者が文章を読む
・読んだ文章を理解する（→思い）

　作者が考えをまとめるとか、取材をするとか、編集者が手を入れるなどの細部は一切無視して考えますが、ここで送り手である作者から受け手である読者へ送られる情報の中身である「思い」は、二段階の変化をすることに注目してください。
　作者が自分の思いを言葉にするとき、ここでは頭の中の漠然とした思いが言葉という明確な形に変換されます。そして、読者がその言葉を読むと、今度は読者の頭の中に「理解」や「解釈」という形である種の「思い」が形成されることになるわけですが、ここにおいても「言葉から思い」への変換処理が行われることになります。
　私が「言葉はデジタルだ」ということで伝えたいのはまさにこの部分です。何も「電子的に」とか「数値的に」とかいうことを言いたいのではなく、言葉というのはデジタルデータとしての性質を持つものだということを言っているのです。
　簡単に解説しましょう。
　皆さんご存知のCDですが、これは音というアナログ情報を数値化することで盤面に記録します。ところが、数値化をするに当たって避けて通るのができないのが、情報の切り落としということです。
　余り詳しいことを書いている余裕はないのですが、CDでは44.1kHzがサンプリング周波数です。これは、すべての音の中から22.05kHz（1秒間に22,050回の振動）までの音のみを切り出して数値変換（デジタル化）することになります。自然界の音というアナログの存在を数値化するに当たって、この切り出し作業は宿命なのです。
　もともとCDの規格を作る際には、人間の可聴領域（およそ15,000〜20,000Hz）に多少の余裕を持たせたもので充分だろうと思われていたのですが、その後の研究で、人間は意識的に聞こえていない高周波成分も、何らかの形で感じていることが分かり、もっと高い音も記録できるべくSACDなどの技術も生まれています。
　ただ、どんなに情報量を増やしてもデジタルである限り「完璧に」収録することは不可能です。
　人間が文章を書く際にも同じことが言えます。文章が生み出されるとき、そこにはアナログ→デジタル変換（A/D変換）が起こっています。つまり、書き手が自分の頭の中の思いを言葉にする際に「言葉を選ぶ」作業をします。これは数値化の時と同じく、情報の切り落としになります。自分の思いをそのまま言葉に完璧に表すことはできないので、一所懸命に「より適切な言葉」を探すわけです。
　文章を読む読者の側でも変換が行われます。文章を読んでそこから何かを得る作業、つまり読解力というものは、言えばデジタル情報になった言葉をアナログに戻すための変換作業（D/A変換）であり、この能力が低ければ、やはり書き手の意図はうまく伝わりません。
　このように、言葉による情報の受け渡しには、A/D、D/Aの二回の変換処理が行われるため、各変換処理エンジンの性能（要は、作文力と読解力です）によって、伝わる中身が大きく影響を受けてくるわけです。
　皆さんがプログラミングの勉強をする際に、本を選ぶ作業も大切です。何故なら、皆さんが本を読もうとする時点では、既に作者の側の変換作業は完了してしまっています。そして多くの場合、本の向こう側にいる人がどれだけの情報を持っているのかをあらかじめ知っていることはありません。
　よって、当然のことながら最初の段階としてはまず、いかに的確に本を選ぶかという作業が重要になってくるわけです。

開発ツールよもやま話　　　　　　Interface Builder3　　　　高橋 政明

　レパードになり開発ツールは大幅に強化されました。XcodeもInterfaceBuilderもバージョンが3.0に上がりました。
　特にInterface Builderは別のアプリケーションと思える程のかわり方です。もちろん単に変わっただけではなく機能面で大幅に強化されています。
　Interface Builderはアイコンからドライバーがなくなりました。アプリケーションであることを示唆する「道具」は三角定規になりました。Xcodeが
設計図の青焼きとハンマーで変わらないことと比べてもInterface Builderが生まれ変わった事がわかります。（Xcodeもバージョン3.0でハンマーの向きが変わっていますが）
　余談ですが、青焼き（ジアゾコピー）って現代の若者にとっても「図面」を象徴しているのでしょうか？（これは『アイコン作りは難しい』という話題につながるのですがそれはまた別の機会に）

　歴史的にInterface BuilderはNeXTのツールでOPENSTEP直系のツールとして
Rhapsody（ラプソディ）の時代から基本部分はあまり変わっていませんでした。
　手元にある古い資料（DISCOVERING OPENSTEP:A Developer Tutorial）を見るとInterface Builderのアイコンもウインドウも、TigerのXcodeToolsに含まれるInterface Builderバージョン2.5と大きな違いはありません。
　nibに対応するウインドウにはInstances Classes Imagesの三つのタブがありツールパレットのツールはメニュー、コントロール、ウインドウ、テキストと順番が若干違いますが機能は同じようです。
　AppleがRhapsodyを打ち出した当時は、配布された『Prelude To Rhapsody
Release 4.1 for Windows』の動作環境がWindowsのみであったこともあり、あまりにも違う開発環境に大変戸惑いました。これは私だけでなく多くのMac開発者共通で、AppleもほどなくCarbonを打ち出しMac OS X用の開発環境に加えた事はご承知の通りです。私自身Cocoaの開発環境に慣れるには期間が必要でした。

　さて、レパードのInterface BuilderはClassの扱いが大きくかわりました。
　Classesのタブもメニューもなくなってしまったため戸惑った方も多かったはずです。MOSAdeBB（会員掲示版）プログラミング技術Q&A 初級／InterfaceBuilder3でカスタムクラスを登録する方法　でも話題になっていましたが、私もとまどった一人です。

　Classes操作が変わったため、アウトレットやアクションの接続先となるオブジェクトのインスタンス化が従来の方法が使えなくなりました。かわりにライブラリパレットからObjectをドラッグ＆ドロップしてclass名を選択します。（以下の例はnib修正前にXcode3で、ソースのヘッダファイルでクラスの@interface 以下を正しく記述し保存した前提です）
　具体的には
1）ライブラリパネルでObjectを選び
2）ライブラリ＞Cocoa＞Objects & Controllersをクリックする
3）青い立方体が「Object」なので
　これをnibのウインドウへドラッグ＆ドロップする
4）nibのウインドウで上記ドロップしたObjectアイコンを選択する
5）toolsメニューでIdentity Inspectorを選ぶ
6）Inspectorパネルのclass Identityでクラスを選ぶ
の手順になります。6で自分で定義したクラスがリストにない場合、ヘッダ
ファイルをnibウインドウへドラッグ＆ドロップしてからもう一度試してください。

　Xcodeとの連携が強化されたのは嬉しい点です。nibウインドウの一番下にズームボタンを小さくしたような緑色のインジケータとプロジェクト名が表示されていれば同期中です。プロジェクト名をクリックするとXcode3に切り替わります。この状態でXcode3でアウトレットの名称を「リファクタリング」機能を使って変更するとnibファイル側も自動的に変更されます。これは強力でとてもありがたい機能です。接続し直す作業は不要となりました。

◆本日のまとめ
　Interface Builder3は対応するプロジェクトを同時にXocode3で開いていると連携処理を行います。

ニュース解説　　　MOSAic

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

・12月のニュース
http://www.mosa.gr.jp/?p=1476

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

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