MOSA Developer News［MOSADeN＝モサ伝］第230号

2006-11-28

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

■　 〜Xserve編〜

　前回チラリとご紹介した新型Xserveですが、ようやく出荷が始まったようですので、今回は予定を変更して新型Xserveについてレポートしたいと思います。
　まずこれまでの経緯ですが、今年の8月に開催されたWWDCでPower Mac G5の後継機となるIntel Xeonプロセッサを搭載したMac Proが発表になりました。Mac Proはすぐに発売開始となりましたが、同じ日に発表された新型XserveはWWDCの時点では10月発売開始予定とアナウンスされていました。
　10月発売予定と聞いてしばらく間隔があるので「ヤバイかも」と思ったのは私だけではないと思いますが(笑)、まず新型Xserveの発表後にそれまで販売されていたXserve G5の在庫が徐々になくなっていきました。つまりXserveが欲しくても入手しづらい期間ができてしまったということです。これはサーバ機にとってはちょっと致命的な問題ですね。システムの稼働スケジュールを調整したり、場合によってはアップル製以外のサーバ機を検討しなくてはならなくなります。
　特にMac OS X Serverではオープンソース系のソフトが全面的に採用されていますから、手間と時間さえかければ同様のサービスはほかのプラットフォームでも実現できてしまうわけです。そこに品がないということになれば、いくらコストパフォーマンスや使い勝手がよかったとしても時間的な問題により採用計画からは外さねばならないケースも出てしまいます。
　発売が予定されていた10月になってからですが、いっこうに発売が開始される気配がなく、10月下旬になってからようやく注文が受け付けられ、11月も下旬にさしかかろうとしたときにようやく出荷が開始されました。
　さいわいオンラインのApple Storeを見てみますと出荷予定日は「24時間以内」となっておりますので、供給体制は整っていることが期待できますが、Xserveは過去にもモデルチェンジの時期に入手できない空白時期が発生していたので今後は2度とこういったことはやめていただきたいものです。

なんだかネガティブな話題から始まってしまいましたが、新しくモデルチェンジしたXserveのスペックについてみていきたいと思います。
　まずこれまでは3種類の基本構成が用意されていましたが、モデルチェンジに伴い基本構成は1種類になりました。基本構成が1種類なのはMac Proも同様ですね。またCPUもMac Proと同様のIntel Xeonプロセッサが搭載されています。具体的な基本のシステム構成と価格は次のとおりです。

・基本システム構成:
　CPU：2.0GHz 64ビットデュアルコアIntel Xeonプロセッサ×2基
　メモリ：1GBメモリ（667MHz DDR2 Fully Buffered DIMM、ECC機能付き）
　HDD：80GB 7200-rpm 3Gbps シリアルATA ハードディスクドライブ×1基
　グラフィックカード：ATI Radeon X1300（64MBビデオメモリ搭載）
　OS：Mac OS X Server 10.4 Unlimitedクライアント版
　価格：379,800円

　これまでのXserve G5から大きく変わったところはやはりCPUがPowerPC G5からIntel Xeonプロセッサになったことです。クロックも最大で3.0GHzまでカスタマイズ可能になっており、パフォーマンスの向上が見込めます。アップルが公開している資料によれば最大約5倍のパフォーマンス向上が見込めます。
　最近は性能をアピールするのにワットあたりのパフォーマンスが評価されていますが、ちなみに新型Xserveの消費電力は650Wとなっています。

・パフォーマンスについて
http://www.apple.com/jp/xserve/intelxeon.html

　筐体はいままでどおりの19インチラックにおさまる1Uの筐体ですが、奥行きが5cmほど長くなり76.2cmになっています。コンパクトなラックをすでに使用しているケースではラックにおさまるかを事前に確認する必要があります。
　またこれまではグラフィックカードは拡張スロットに追加するか、あるいはグラフィックカードなしのヘッドレスな状態で運用する仕様でしたが、新型のXserveでは標準でグラフィックカードが内蔵されています。拡張スロットを使わずにオンボードで用意されていますので、グラフィックコントローラを使用したとしても、拡張スロットが2基使用可能な状態になります。
　ネットワークはギガビットEthernetがこれもオンボードで2基搭載されています。

基本構成は1種類だけですが、Apple Store(Online)上では様々なカスタマイズが可能ですので、どのようなカスタマイズが可能かをみていきましょう。

□CPU
　標準では2.0GHzのデュアルコアIntel Xeonが2基搭載されています。つまりクアッドコア構成になっています。クロックは標準構成も含め以下の3通りから選択可能です。()内は構成を変更したときのApple Store差額です。

　2.00GHz x2
　2.66GHz x2(プラス102,060円)
　3.00GHz x2(プラス229,950円)

□メモリ
　8基のDIMMスロットが用意されています。標準構成では512MBが2枚ですが、最大で4GBを8枚搭載できますので32GBまでメモリを増設することができます。ただし32GB増設するには2,986,200円の追加費用が必要になりますので、よっぽど大量のメモリを必要とするケースでしか32GBの構成はかえって費用効果が悪いでしょう。これだけの価格があれば標準構成のXserveがもう何台か購入できてしまいますから。
　なおメモリを増設するにはバンド幅を活用するために4枚構成もしくは8枚構成での追加が選択可能になっています。

□HDD
　標準構成でHDDは1基のみですが、追加で最大3基までHDDを搭載できます。ディスクのタイプはSerial ATA(7,200rpm)と、より高いパフォーマンスが実現できるSAS(15,000rpm)のどちらかを選択できます。それぞれのタイプで選択可能なディスク容量は以下のとおりです。標準の80GBで足りない場合はSASタイプのものを選択するか、Serial ATAで500GBに変更することになります。

　Serial ATA(7,200rpm)：80GB/500GB
　SAS(15,000rpm) 73GB/300GB

　Xserve G5ではハードウェアのRAIDコントローラを拡張スロットに追加できましたが、新型XserveではハードウェアのRAIDコントローラが用意されていませんので（内部のレイアウトも変更になっています）、RAIDを使用する場合はソフトウェアRAIDにするか、Xserve RAIDなどの外付けのRAIDストレージを別途用意する必要があります。

□光学式ドライブ
　最大24倍速のComboドライブ（標準）か、最大8倍速の2層式に対応したSuper Driveが選択できます。

□内蔵グラフィック
　ミニDVI出力端子付きのグラフィックカードがあらかじめ内蔵されており、23inchのCinema Displayまで対応しています。内蔵グラフィックカードをなしにして価格をおさえることもできますが、差額は6,300円しか違いませんのでそのままつけておいたほうが便利でしょう。

□拡張スロット
　PCI Expressの拡張スロットが2基用意されており、グラフィックカードが内蔵になったことから、2基とも活用することができます。拡張スロットにはギガビットEthernetカード、SCSIカード、Fiber Channelカードなどが選択できます。
　2基ある拡張スロットはそれぞれ細かな仕様が異なりますので、拡張スロットを利用する場合には事前に仕様をしっかりと確認しておきましょう。

□電源オプション
　新型Xserveでは電源ユニットを2基搭載できるようになりました。標準で電源ユニットは1基だけですが、オプションで2基目の電源ユニットを追加できます。電源ユニットはホットスワップに対応していますので、電源ユニットを2基使用している場合には本体の電源を入れたままで片方の電源ユニットを交換することができます。システムの停止時間を極力短くしたい場合には検討すべきオプションになります。

□ラックマウントキット
　今回のモデルチェンジでラックへのマウントキットは「角穴タイプ」と「ねじ穴タイプ」の2種類から選択するようになりました。これは購入時にどちらかを選択する必要がありますので、事前にラックを確認して適切な方を選択しましょう。

□Apple Care
　以上がApple Storeで選択可能な主なオプションですが、他にもApple Storeの保守契約があります。予備のパーツをあらかじめ取り寄せておく「AppleCare Service Parts Kit for Xserve」や、電話／E-mailによるサポートおよび出張修理サービスがうけられる「AppleCare Premium Service and Support Plan」が提供されています。それぞれの具体的なサービス内容は次のURLを参照してください。

http://www.apple.com/jp/support/products/partskits.html
http://www.apple.com/jp/support/products/premium.html

　出荷の遅れという問題はありましたが、これでようやくすべての製品がIntel対応したことになります。1年前はまだすべての製品がPower PCだったことを考えるとこれはすごいことですね。
　さて、次回は前回の続きでネットワークホームの設定方法について解説したいと思います。

つづく

小池邦人のCarbon API 徒然草

● Carbon API 徒然草（2006/11/24）

〜　Carbonモダンアプリケーションへの道（その7）　〜

アプリケーションを多国語対応にする場合、Shift-JISコードで表記できない文字列を用意する必要が出てきます。そこで登場するのがユニコードです。今回はユニコードを操作するAPIについて、その特徴や活用方法などを解説したいと思います。

まずはソースコード内で頻繁に使うユニコードデータの保存用構造体を決めます。つまりPascalストリングスならStr255、Cストリングスなら前回紹介したCStr255構造体に相当するものです。独自に定義してもよいのですが、筆者はFile ManagerのAPIで利用されているHFSUniStr255構造体を用いています。この構造体はFiles.hヘッダーファイルで定義されています。

struct HFSUniStr255 {
UInt16 length; // ユニコード文字列の長さ
UniChar unicode[255]; // ユニコード文字列データ
};

構造体で利用されているUniCharは別の場所でUInt16として定義されています。ここに記載されているUInt16はunsigned shortの事です。つまり1文字のデータが2バイトということになります。また、長さは65535文字まで設定できますが、UniCharの配列が255しか確保されていませんので、文字列長のオーバーフローには注意が必要です。この構造体のサイズ（sizeof(HFSUniStr255)）は512バイトとなります。今回も、CStr255を定義した場合と同様に、以下のように格納文字長だけが異なる構造体（HFSUniStr63、HFSUniStr31、HFSUniStr15など）をいくつか用意しておくと便利です。

typedef struct  {
                    UInt16   length;
                    UniChar  unicode[63];  // 63文字まで格納可能
                } HFSUniStr63;

typedef struct  {
                    UInt16   length;
                    UniChar  unicode[31];  // 31文字まで格納可能
                } HFSUniStr31;

typedef struct  {
                    UInt16   length;
                    UniChar  unicode[15];  // 15文字まで格納可能
                } HFSUniStr15;

HFSUniStr255にユニコード文字列を格納し、各種APIや自作ルーチンに渡す場合に注意することがあります。HFSUniStr255のワードデータはPowerPC環境ではビッグエンディアンで、X86環境ではリトルエンディアンで保存されています。よって、この構造体を一度外部ファイルへ書き出し、異なるエンディアン環境のユニバーサル・アプリケーションで読み込む場合には、エンディアンをひっくり返す必要があります。もしアプリケーションのネイティブ・ファイルフォーマットをビッグエンディアン（PowerPC）とするならば、x86環境で読み込んだ場合には、以下のようなスワップルーチンを通すことになります。

void flipHFSUniStr255( lHFSUniStr255 *ustr )
{
    long    i;

    ustr->length=Endian16_Swap( ustr->length );  //  文字列長をスワップ
    for( i=0;ilength;i++ )                //  文字データをスワップ
           ustr->unicode[i]=Endian16_Swap( ustr->unicode[i] );
}

文字の処理中に、ユニコード文字列をCFStringRefに変換したり、CFStringRefをユニコード文字列に変換したりする作業が発生した場合には、以下の2つのFile Manager APIを用いると便利です。ユニコードからCFStringRefを得るにはFSCreateStringFromHFSUniStr()を…

CFStringRef FSCreateStringFromHFSUniStr( CFAllocatorRef alloc,
                                            const HFSUniStr255 *uniStr);

逆に、CFStringRefからユニコードを得るにはFSGetHFSUniStrFromString()を使います。

OSStatus FSGetHFSUniStrFromString( CFStringRef theString,
                                                   HFSUniStr255 *uniStr);

また、これらのAPIと同じ働きを持つルーチンをCore FoundationのAPIを利用し作成すると、以下のような感じになります。cfToUnicodeString()がCFStringRefからユニコード文字列への変換、unicodeToCFString()がユニコード文字列からCFStringRefへの変換を行います。

SErr cfToUnicodeString( CFStringRef cfstr,HFSUniStr255 *ustr )
{
    short        err=1;
    CFRange        range;

    if( ustr->length=CFStringGetLength( cfstr ) )   // 文字列の長さを得る
    {
        if( ustr->length > 255 )                    // 255文字以上はカット
            ustr->length=255;
        range=CFRangeMake( 0,ustr->length );
        CFStringGetCharacters( cfstr,range,ustr->unicode );  // 文字列変換
        err=noErr;
    }
    return( err );
}

OSErr unicodeToCFString( HFSUniStr255 *ustr,CFStringRef *cfstr )
{
    short    err=1;

    if( *cfstr=CFStringCreateWithCharacters( NULL,ustr->unicode,ustr->length ) )
        err=noErr;
    return( err );
}

さて、話をアプリケーションの多国語対応に戻しましょう。Core Foundationには、ユニコード文字列を外部ファイルから読み込み自作アプリケーションで利用するのに最適なAPIが用意されています。以下のCFCopyLocalizedString()です。このAPIはCFBundle.hヘッダーファイルに定義されています。

CFStringRef CFCopyLocalizedString( CFStringRef key,const char *comment );

CFCopyLocalizedString()を利用するには、先んじて、アプリケーションで使うユニコード文字列を列記した「Localizable.strings」というファイルを、アプリケーションパッケージの「Resouces」フォルダ内の各言語対応フォルダに入れておく必要があります。例えば、英語用であれば「English.lproj」、日本語用ならば「Japanese.lproj」フォルダ内です。Finderの情報ウィンドウに各国語でバージョン番号等を表示させるために用意する「InfoPlist.strings」ファイルと同じ仕組みです。このAPIが、CFString.hではなくCFBundle.hに定義されているのは、利用形態が「パッケージ」の仕組みに深く関わっているのが理由です。

各国語用のLocalizable.stringsファイルは、Xcodeプロジェクトのファイル一覧に登録しておくことにより、リンク時にアプリケーションパッケージ内の適切なフォルダに格納されます。まず最初のサンプルとして、Apple社から提供されている「iPhoto」の日本語用Localizable.stringsを調べてみることにします。このファイルには恐ろしく大量の文字列が列記されていますが、最初の数行を見てみると…

AppName = "iPhoto";
VersionFormat = "%1$@ (%2$@)";          // for example, "4.0d8 (150)"
AboutFormat = "バージョン %2$@";        // AppName VersionFormat
MediaBrowser = "Aperture ライブラリを表示...";

となっています。最初の1行は、CFCopyLocalizedString()の最初の引数にキーワードとしてAppNameを渡せば、”iPhoto”というユニコード文字列がCFStringRefとして返ってくることを意味しています。ちなみに、2番目の引数は翻訳用コメントを記載しておく場所であり処理自体には何も意味を持ちません。キーワード側もCFStringRefである必要がありますので、以下のように記載すれば目的は達成されます。

CFStringRef    cfstr;
HFSUniStr255   ustr;

cfstr=CFCopyLocalizedString( CFSTR( "AppName" ),"" );
FSGetHFSUniStrFromString( cfstr,&ustr );

同様に、4行目のキーワードのMediaBrowserを渡せば、日本語ユニコード文字列として”Aperture ライブラリを表示…”が返ってくるわけです。

cfstr=CFCopyLocalizedString( CFSTR( "MediaBrowser" ),"" );

今回取り上げたLocalizable.stringsサンプルの2行目には、返す文字列の中に「%1$@」といった表記があります。これは、どんな意味を持つのでしょうか？
　次回は、さらに詳しくLocalizable.stringsの表記の仕組みを解説したいと思います。

つづく

SqueakではじめるSmalltalk入門　　　第74回　　鷲見 正人

本連載では、名前は知っていてもなかなか触れる機会のないSmalltalkについて、最近話題のSqueakシステムを使って紹介しています。今回は、製作中の簡易GUIビルダにおいて、扱うことができるウィジェットの種類を増やす拡張を施す際、メソッド定義のコピーをせずともそれができる仕組みを考えます。

テキストフィールドをウインドウに追加するためのメソッドは次のようなものでした。

addFieldTo: window
   | field relFrame |
   field := PluggableTextMorph
      on: self text: nil accept: nil readSelection: nil menu: nil.
   relFrame := (Rectangle fromUser
      scaleFrom: window layoutBounds
      to: (0 asPoint extent: 1e3 asPoint)) scaleBy: 1.0e-3.
   window addMorph: field frame: relFrame

前回は、ボタンを追加するためのメソッド「#addButton:to:」を、この#addFieldTo:の必要な部分を書き換えることで定義したのでしたね。しかし、新しいウィジェットを扱えるようにするたびに、似たようなメソッドの複製が増えてゆくことは避けるべきです。

そこで、どんなウィジェットでも利用できる汎用のウィジェット追加用メソッドがどんなものであればよいのかを考えます。この新しいメソッドは、ウィジェットの種類を#fieldや#buttonなどといったシンボル（widgetSym）で与えることにして、「add: widgetSym to: window」というメッセージで起動できるメソッド「#add:to:」であると想定します。#addFieldTo:と#addButtonTo:の共通部分を抽出して、#add:to:の定義は（まだ完全ではありませんが…）次ように書くことが可能です。

add: widgetSym to: window
   | widget relFrame |
   widget ":= この部分をどう書くか？ ".
   relFrame := (Rectangle fromUser
      scaleFrom: window layoutBounds
      to: (0 asPoint extent: 1e3 asPoint)) scaleBy: 1.0e-3.
   window addMorph: widget frame: relFrame

ちなみに、この擬似的なメソッド定義はもちろん動作はしませんし、コンパイル時に警告も出ますが、コンパイル（accespt (cmd + S)）それ自体は通るので、コピー＆ペーストで登録作業を済ませてしまってかまいません。こうした良い意味で“ルーズ”なところはSmalltalkもObjective-Cとよく似ていますね。

さて。問題は、この疑似コードの一行目の「この部分を…」でwidgetSymで指定したシンボル（#field、#button）からウィジェットそのものを作って返すような式を書くことです。

まず、ウィジェットを表わすシンボルと同名で、起動すると、それぞれの名前が示すウィジェットを作成して返してくるメソッドを定義しましょう。次の二つのメソッドを別々にシステムブラウザにコピー＆ペースト後、accept (cmd+ S)してください。

field
   ^ PluggableTextMorph
      on: self
      text: nil
      accept: nil
      readSelection: nil
      menu: nil

button
   ^ (PluggableButtonMorph
      on: self
      getState: nil
      action: nil) label: 'button'; yourself

これらのメソッドは通常、「self field」とか「self button」というメッセージ式を記述して起動します。しかし、メッセージを動的に送信するためのメソッド「#perform:」を用いることで、次のような記述も可能です。

s

elf perform: #field
self perform: #button

パラメータ部分を変数widgetSymにすれば、次のよう書き直せます。

self perform: widgetSym

冒頭の#add:to:の問題の箇所をこの式で“穴埋め”しましょう。

add: widgetSym to: window
   | widget relFrame |
   widget := self perform: widgetSym.
   relFrame := (Rectangle fromUser
      scaleFrom: window layoutBounds
      to: (0 asPoint extent: 1e3 asPoint)) scaleBy: 1.0e-3.
   window addMorph: widget frame: relFrame

実際に、システムブラウザの#add:to:も、このように書き換えてから、あらためてaccept (cmd + S)してください。

仕上げに#addModelItemsToWindowMenu:も、これまでの#addFieldTo:や#addButtonTo:の代わりに、新しく定義した#add:to:を使ったものに書き換えましょう。パラメータがこれまでのwindowから、widgetSym、windowの二つに増えたので#add:target:selector:argumet:の代わりに、#add:target:selector:argumentList:を用います。

addModelItemsToWindowMenu: aMenu
   | window |
   window := aMenu defaultTarget.
   aMenu addLine.
   aMenu
      add: 'add field'
      target: self
      selector: #add:to:
      argumentList: {#field. window}.
   aMenu
      add: 'add button'
      target: self
      selector: #add:to:
      argumentList: {#button. window}.
   aMenu addLine.
   aMenu add: 'delete' target: self selector: #removeWidgetFrom: argument: window

#addField:to:、#addButtonTo:はもはや無用ですので、削除してしまってかまいません。メソッドの削除は、右上のペインで削除したいメソッドを選択した状態で黄ボタンメニューから「remove method」を選択します。

[fig.A]不要となったメソッドの削除操作

この仕組みにより、ウィジェットの登録の手続きは#add:to:に集約できたので、懸案だったメソッドの複製をして同じようなコードを分散させる心配もなくなりました。

次回はさらに一歩踏み込んで、Smalltalkの強力な動的性とリフレクション機能を最大限に活用し、ウィジェットの種類を増やすときにウィジェット生成のメソッドを登録するだけで済ませることができる（つまり、新たなウィジェット用のメニュー項目の追加も自動的に行なわれる…）ようなカラクリに挑戦してみましょう。

バックナンバー：

ニュース・解説

　今週の解説担当:木下 誠

———————————————————————-
QAが4つ追加
———————————————————————-

先週は、アメリカがThanks Ginvingであったこともあり、めぼしいニュースやドキュメントの追加はほとんどありませんでした。

そんな中、QAがいくつか追加されていたので、それを紹介しましょう。

まず、テンポラリファイルを作成して、それをすぐ削除するためにFSDeleteObjectを呼ぶと、ときたまそれが失敗する問題について。これは、ファイルを作成するとSpotlightのインデックス化や、ウィルス対策ソフトが発動するために起こります。それをさけるには、Spotlightのインデックス化が起こらないフォルダ（たとえば/tmp）に、テンポラリファイルを作るようにします。

QA1497: FSDeleteObject fails with fBsyErr, sometimes
http://developer.apple.com/qa/qa2006/qa1497.html

次に、Securityフレームワークが返すエラーコードについて。このフレームワークのエラーコードは、OSStatusエラーのもの、UNIXスタイルのエラーコードのもの、Common Security Services Manager (CSSM)で定義されているもの、に分類されます。

QA1499: Security Framework Error Codes
http://developer.apple.com/qa/qa2006/qa1499.html

3つめは、Core AudioのAudioConverterが提供する、StdAudioダイアログについて。kQTSCAudioPropertyID_CodecSpecificSettingsArrayプロパティが何を意味しているかを解説しています。

QA1390: Standard Audio – The CodesSpecifiecSettingsArray and MagicCookie properties
http://developer.apple.com/qa/qa2006/qa1390.html

最後は、Web KitプラグインをSafariで動かすときに、それをデバッグする方法について。プラグインのプロジェクトで、カスタム実行ファイルをSafariにしてやります。これは、Web Kitプラグインに限らず、プラグインスタイルのソフトウェアの開発に応用できそうですね。

QA1500: Debugging a Web Kit Plug-in in Xcode
http://developer.apple.com/qa/qa2006/qa1500.html

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

MOSA Developer News［MOSADeN＝モサ伝］第229号

2006-11-21　

 /Groups
    /Shared Items/Public
    /Users

- (unsigned)draggingEntered: (id ) sender{
     int            t;
     NSPasteboard*  pb = [sender draggingPasteboard];
     NSLog(@"pb types count = %d", [[pb types] count]);
     for( t = 0; t < [[pb types] count]; t++){
          NSLog(@"type [%d] = %@", t, [[pb types] objectAtIndex:t]);
     }
     return [super draggingEntered:sender];
}

@interface MyTextView : NSTextView {
 ....
}
...
@end

- (BOOL) performDragOperation: (id ) sender {
     [NSApp activateIgnoringOtherApps:YES];
     NSPasteboard*  pb = [sender draggingPasteboard];
     NSArray*       uList = [pb propertyListForType: NSURLPboardType];
     int            index;
     for(index = 0; index < [uList count]; index++){
          NSLog(@"Dragged File #%d is %@",
               index,  [uList objectAtIndex:index] );
     }
     return YES;
}

Dragged File #0 is file://localhost/Volumes/hirofujimoto/Documents/MonkeyBiz/mosa/NightTalk/PN101.txt
Dragged File #1 is

int a;
int *ap = &a;

int b;
int &br = b;

int c;
ap = &c;

br = c;

int &d;

void
IntType::add(IntType it)
{
     number += it.number;
}

void
IntType::add(IntType &it)
{
     number += it.number;
}

MOSA Developer News［MOSADeN＝モサ伝］第228号

2006-11-14

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

・　 〜AFP編〜

　これまでOpen Directoryを使ったネットワークユーザの作成方法について解説してきました。ネットワークユーザを使いますとサーバ上でユーザアカウントを一元管理できますが、ユーザ管理ではホームディレクトリをどこで管理するのかについても考えなければなりません。せっかくユーザをサーバ上で管理しているのですから次はホームディレクトリもサーバ上で一元管理できないかということになります。
　ネットワークユーザを使った場合、ユーザアカウントはサーバ上にありますので、ネットワークを経由してどのクライアントコンピュータからも同じアカウントでのログインが可能になります。このとき、ローカル上のホームを使ってしまうと、ログインするコンピュータごとにファイルがちらばってしまいますので、これでは効率的とはいえません。そこで、ユーザアカウントに加えてホームもサーバ上で管理すれば、どのコンピュータからも同じアカウントでログインができ、かつ同じホームが利用できるようになります。
　サーバ上で管理するホームのことを「ネットワークホーム」と言いますが、サーバ上でホームを管理するには、ネットワークを経由してクライアントコンピュータからサーバ上のホームにアクセスできる必要があります。ですので、ネットワークホームを実現するにはまずファイルサービスを設定する必要があります。そこで、今回からはファイルサービスについて解説していきたいと思います。

◇ファイルサービス
　Mac OS X Serverで提供可能なファイルサービスには、Mac向けのAFPのほかにもWindows向けのSMBや、Unix向けのNFSなどがあります。またFTPやWebDAVを使って様々なプラットフォーム間でファイル共有を行うこともできます。
　このように、Mac OS X Serverでは様々なプラットフォーム向けにファイルサービスを提供することができますが、Mac上でネットワークホームを使用するにはMac向けのファイルサービスであるAFPを使用します。
　AFPはApple Filing Protocolの略で、もともとはAppleTalkでのファイル共有プロトコルでしたが、現在はTCP/IP上でも使用できるようになっています。AFPサービスの管理を行うには「サーバ管理」と「ワークグループマネージャ」の2つの管理ツールを使用します。
　2つの管理ツールを使うのはSMBを提供するWindowsサービスや、NFS、FTPにも共通しています。「サーバ管理」ではアクセス方法の設定などサービス全体の設定を行い、「ワークグループマネージャ」では共有ポイントの設定を行い、どのフォルダを公開するかなどを設定します。

◇「サーバ管理」でのAFPサービスの設定
　「サーバ管理」でAFPサービスの設定や開始／停止を行います。デフォルトの設定のままで問題なければ、サービスを開始するだけでAFPを利用することができますが、まずはどのような設定が可能かを確認していきましょう。
　AFPサービスの設定を行うには「サーバ管理」でコンピュータとサービスリストから「AFP」を選択し、「設定」ボタンをクリックします。設定画面は次の4つに分かれています。

【一般】
　クライアントからのブラウジングに関する設定を行います。ファイルサーバの検出に使用するプロトコルがMac OS XとMac OS 9では異なり、Mac OS X向けにはBonjour、Mac OS 9向けにはAppleTalkによるブラウズを有効にします。
　またMac OS XはUnicodeベースでの国際化対応を実現していますが、Mac OS 9の時代には言語ごとにOSが分かれていましたので、そのような古いクライアント用にはエンコードを指定する必要があります。
　「ログオンメッセージ」を設定しておくと、クライアントからの接続時に画面上にメッセージを表示することができます。

http://homepage.mac.com/htabata/MXS10.3/img/AFP/AFP_ADMIN_03.png

【アクセス】
　クライアントからのアクセス方法を設定します。「認証」の設定は次の3つから選択可能です。

・標準
・Kerberos
・すべてのメソッド

　「Kerberos」を選択した場合にはシングルサインオンによるAFPの認証が有効になります。Mac OS X Serverでは、Open Directoryのマスターの機能を使ってシングルサインオンを実現することができます。
　「すべてのメソッド」を選択した場合にはまずKerberosによるシングルサインオンを実行し、もし失敗した場合には通常どおりの認証（つまり「標準」）を行います。
　また、ゲストアクセスに関する設定もありますが、実際にゲストアクセスを有効にするには「サーバ管理」での設定に加え、「ワークグループマネージャ」での共有ポイントの設定も必要になります。
　「安全な接続を有効にする」はSSH経由での暗号化した通信のための設定です。実際にSSH経由での通信を行うには、クライアントからの接続時にもクライアント側でオプションの設定を行う必要があります。
　「最大接続数」の設定では接続数の上限を設定することができます。

http://homepage.mac.com/htabata/MXS10.3/img/AFP/AFP_ADMIN_04.png

【ログ／アイドル状態のユーザ】
　「ログ」設定画面では、アクセスログおよびエラーログの設定ができます。アクセスログはイベントごとに設定することができます。
　「アイドル状態のユーザ」設定画面では、接続を解除するまでのアイドル時間などが設定できます。

http://homepage.mac.com/htabata/MXS10.3/img/AFP/AFP_ADMIN_05.png
http://homepage.mac.com/htabata/MXS10.3/img/AFP/AFP_ADMIN_06.png

　というわけで、今回は「サーバ管理」を使ったAFPサービスの設定方法について解説しました。次回は「ワークグループマネージャ」を使った共有ポイントの設定について解説する予定です。

つづく

小池邦人のCarbon API 徒然草（2006/10/11）

〜　Carbonモダンアプリケーションへの道（その6）　〜

前回は、Pascalストリングスの代わりとして登場したCFStringを簡単に紹介しました。今回は、さらに詳しくその特徴や活用方法などについて解説したいと思います。

前回、CreateNibReference() APIにCFStringRefで参照されるNibファイル名を渡す時、引数が定数（固定値）であれば、CFSTR()の内部にCストリングスを記述すればOKだと解説しました。以下のような感じです。

CreateNibReference( CFSTR( “Dialog” ),&nibRef );

ただし、この記述方法が利用できるのは、CFSTR()内の文字列が半角英数字の場合に限ります。例えば、「ウィンドウ.nib」というNibファイルを作成しておき…

CreateNibReference( CFSTR( “ウィンドウ” ),&nibRef );

と記載したとしても、ソースコードをコンパイルする時点でエラーが発生します。このエラーを回避するには、日本語のCストリングについてはソースコード内に記述可能ですので、前回紹介したcToCFString()ルーチンでCFStringRefを得てからCreateNibReference()に渡します。作成したCFStringRefは、disposeCFString()により解放することを忘れないでください。

cToCFString( “ウィンドウ”,CFStringRef &cfstr );
CreateNibReference( cfstr,&nibRef );
disposeCFString( cfstr );

ところが、この方法で万事うまく行くかと言うと現実はそんなに甘くありません（笑）。例えば「一覧表.nib」というNibファイルを作成し、同処理をするためのソースコードを以下のように記述しておきます。

cToCFString( “一覧表”,CFStringRef &cfstr );

すると、この行でコンパイルエラーが発生することが分かります。原因は「表」という文字のShift-JISコードにあります。「表」のコードは0x955Cですが、その2バイト目の0x5Cがアルファベットのバックスラッシュ（日本語キーボードだと\マーク）に相当するため、コンパイラが正しくソースコードを解釈出来ないわけです。

こうした制限を把握した上で、日本語文字列をソースコード内に記述することについては自己責任であり大きな問題はありません。しかし通常は、外部ファイル（テキストファイルやリソースファイル）に文字列を保存しておき、そこから逐次読み出してAPIや自作ルーチンで使うのが一番安全で確実な方法です。よって前回でも書きましたが、筆者はGetIndString()というSTR#リソースからインデックス番号参照で特定のPascalストリングスを抽出してくるAPIを使い、様々な文字処理に活用していました。ところが、このAPIがDEPRECATED指定になってしまったので、現在は以下のような代用ルーチンを作成して活用しています。

OSErr getIndCString( short id,short nb,char *cstr )
{
    short     i,ct,len,*ss;
    short     err=1;
    Handle    hd;
    Ptr       pp;

    *cstr=0;
    if( hd=GetResource( 'STR#',id  ) ) // STR#リソースからデータを得る
    {
        HLock( hd );                   // データはHandleとして変える
        ss=(short *)*hd;
        ct=*ss;                        // 最初の2バイト(short)が文字列の個数

        #if __LITTLE_ENDIAN__
        ct=Endian16_Swap( ct );        // x86環境ではワードスワップが必要
        #endif

        if( ct >=nb )                  // 指定番号がない場合はエラー
        {
            pp=*hd;
            pp+=2;
            for( i=1;i<=ct;i++ )
            {
                len=*pp++;
                if( i==nb )            // 指定番号の文字列を引数へコピー
                {
                    BlockMoveData( pp,cstr,len );
                    *(cstr+len)=0;
                    err=noErr;
                    break;
                }
                else
                    pp+=len;
            }
        }
        ReleaseResource( hd );       // 得られたHandleを解放する
    }
    return( err );
}

このgetIndCString()ルーチンでは、引数としてリソースIDと文字列のインデックス番号を渡すことで、指定されたSTR#リソースからCストリングスを抽出してきます（オリジナルはPascalストリングスだった）。この場合に注意する点は、リソースデータはすべてビッグエンディアンで保存されているということです。そのため、x86などのリトルエンディアン環境では、ワードデータ（shot）やダブルワードデータ（long,float）などはスワップ処理をする必要があります。

こうして得られたCストリングスを色々な処理に活用するわけですが、Cストリングスの変数をいちいち配列として記述するのが面倒な場合には、PascalストリングのStr255を真似して、typedefにより以下のような定義をしておくと便利です。そして、必要な文字列の長さにより、これらをうまく使い分けるようにします。

typedef char    CStr1023[1024];
typedef char    CStr511[512];
typedef char    CStr255[256];
typedef char    CStr63[64];
typedef char    CStr31[32];
typedef char    CStr15[16];

また、STR#リソースから直接CFStringRefが欲しい場合には、以下のようなルーチンを用意します。

OSErr getIndCFString( short id,short nb,CFStringRef *cfstr )
{
    short      err=1;
    CStr255    cstr;

    if( getIndCString( 129,3,cstr )==noErr ) // リソースからCストリングスを得る
    {
        if( *cfstr=CFStringCreateWithCString( NULL,cstr,
                                               CFStringGetSystemEncoding() ) )
            err=noErr;                      // CストリングからCFStringRefを得る
    }
    return( err );
}

上記ルーチンを利用して、ID番号で指定した文字表示用コントロール（カラム）にSTR#リソースから抽出した文字列を表示するのには、以下のようなルーチンを使います。

OSErr drawCFStringControl( WindowRef window,long cid,short id,short nb )
{
    short          err=1;
    CFStringRef    cfstr;
    ControlRef     chd;
    ControlID      cid;

    if( ! getIndCFString( id,nb,&cfstr ) )   // リソースからCFStringRefを得る
    {
        cid.id=cid;
        cid.signature='MosA';                // signatureは'MosA'に指定済み
        GetControlByID( window,&cid,&chd );  // 指定IDのControlRefを得る
        SetControlData( chd,kControlNoPart,kControlEditTextCFStringTag,
                                               sizeof(CFStringRef),&cfstr );
                                             // コントロールに文字列をセット
        DrawOneControl( chd );               // コントロールを再描画
    }
    return( err );
}

こうしてソースコード内ではなく外部ファイルから文字列データを持ってくる方法は、自作アプリケーションを多国語対応にするには最適な方法です。ただし、多国語対応の場合には、Shift-JISコードで表記できない文字列を用意しなければいけない場合が多々あります。そこで登場するのがユニコードです。次回はユニコードを操作するAPIについて、その特徴や活用方法などを解説したいと思います。

つづく

SqueakではじめるSmalltalk入門　　　第73回　　鷲見 正人

本連載では、名前は知っていてもなかなか触れる機会のないSmalltalkについて、最近話題のSqueakシステムを使って紹介しています。今回は、製作途上の簡易GUIビルダで、テキストフィールドだけでなく、プッシュボタンも追加できるように拡張します。

▼メニュー項目の追加
まずは変化が見えやすいところから始めましょう。GUIビルダウインドウのウインドウメニューに手を入れます。ブラウザの右上のペインから「addModelItemsToWindowMenu:」をクリックして選択し、下のペインに表示されたその内容を次のように変更してください。

addModelItemsToWindowMenu: aMenu
   | window |
   window := aMenu defaultTarget.
   aMenu addLine.
   aMenu add: 'add field' target: self selector: #addFieldTo: argument: window.
   aMenu add: 'add button' target: self selector: #addButtonTo: argument: window.
   aMenu addLine.
   aMenu add: 'delete' target: self selector: #removeWidgetFrom: argument: window

ボタンを追加するためのメソッド名を#addButtonTo:とあらかじめ決めてしまい、それを起動するメニュー項目「add button」を追加する行を「add field」の行の直下に挿入しています。accept（cmd + S）してコンパイルが済むと、GUIビルダウインドウのメニューには、記述通り「add button」という項目が現われます。

[fig.A]追加された「add button」コマンド

ただ、もちろん現時点では、このメニュー項目を選択しても起動するメソッドが見つけられずエラーになります。

[fig.B]起動するメソッドが存在しないため起こるエラー

▼ボタン追加のためのメソッドの定義
テキストフィールド（a PluggableTextMorph）をGUIビルダウインドウに追加するためのメソッドは次のようなものでした（GUIビルダをブラウズ中のブラウザで、右上のペインの「addFieldTo:」をクリックすると呼び出せます）。

addFieldTo: window
  | field relFrame |
  field := PluggableTextMorph
    on: self text: nil accept: nil readSelection: nil menu: nil.
  relFrame := (Rectangle fromUser
    scaleFrom: window layoutBounds
    to: (0 asPoint extent: 1e3 asPoint)) scaleBy: 1.0e-3.
  window addMorph: field frame: relFrame

これにちょっと手を加えるだけで、新たに#addButtonTo:を簡単に作ることができます。

Smalltalkのメソッド定義の最初の行は「メッセージパターン」と呼ばれ、このメソッドを起動するためのメッセージの概要を示すと同時に、メソッド名（セレクタともいう。この場合、#addFieldTo:）とメッセージに添えられたパラメータ（引数）を関連づける変数（パラメータ変数。window）を宣言する場でもあります。したがって、この行のメソッド名の部分を書き換えるだけで、新しいメソッド（たとえば、#addButtonTo:）を定義することが可能です。

手始めに「addFieldTo:」の「Field」部分を「Button」に書き換えてから、accept（cmd + S）してみてください。ただちにコンパイルが終了し、右上のペインに「addButtonTo:」が追加されるはずです。「add button」メニュー項目はこれでエラーを出さなくなりますが、相変わらずテキストフィールドしか作れません。

メソッド本体も#addButtonTo:という名前にふさわしく、テキストフィールドではなくプッシュボタン（a PluggalbeButtonMorph）を追加する内容に置き換えましょう。二行目の「field」を選択した状態で「button」とタイプしてからcmd + shift + Jとタイプすると、テンポラリ変数fieldからbuttonへの全置換を行なえます。さらに、三行目から四行目をボタン用に変更、accept（cmd+ S）すれば作業は完了です。

addButtonTo: window
  | button relFrame |
  button := (PluggableButtonMorph
    on: self getState: nil action: nil) label: 'button'; yourself.
  relFrame := (Rectangle fromUser
    scaleFrom: window layoutBounds
    to: (0 asPoint extent: 1e3 asPoint)) scaleBy: 1.0e-3.
  window addMorph: button frame: relFrame

これで、GUIビルダウインドウに新たに設けられたメニュー項目「add button」は、以後、正常に機能するはずです。

[fig.C]「add button」により追加が可能になったプッシュボタン

ただ、既存メソッドをちょっと書き換えるだけで簡単に追加できたということは、裏を返せば書き換えた部分以外まったく同じ内容のメソッドの“複製”ができてしまったということを意味します。このまま安易な拡張を続けることで、同内容の処理を分散させ、メインテナンス性が損なわれるようではいけません。次回は今回のようなコード複製をせずとも、ウィジェットの種類を増やすことができるしくみを考えます。

バックナンバー：

ニュース・解説

　今週の解説担当:木下 誠

----------------------------------------------------------------------
ADC StoreとADC on iTunes
----------------------------------------------------------------------

Lepoard向けの開発情報を続々と出し続けているAppleですが、開発者の利便性を上げるために、ADCのサイトにも新機能が追加されています。

まず、皆様ご存知の通り、現時点ではLeopardの情報を得るにはADCのPremierかSelect会員である必要がある訳ですが、というよりはAppleとしてはPremierかSelect会員を増やしたいという思惑からか、これらの会員権の購入がさらにやりやすくなりました。

いままではADCのWebページで購入手続きを行っていたものが、Apple Storeに統合されています。いつもの使い慣れたインタフェースが使える訳ですね。こちらには、「Leopard Early Start Kit」の「Buy Now」から移動する事が出来ます。または、"http://developer.apple.com/products/"からアクセスできます。

もう一つ。今年の8月に行われたWWDCでのセッションが、ビデオという形での公開が始まっています。これらが、iTunesからダウンロード、管理できるようになっています。「ADC on iTunes」です。

これを利用するには、「Leopard Early Start Kit」の「Watch Now」をクリックします。iTunesが起動して、ADCのiTunes Storeに移動できます。ここから、ビデオとスライドのダウンロードができます。もちろん、視聴にiTunesを使う事が出来ます。

iTunesとADCの統合は、予想以上に使いやすいものがあります。iTunesの新たな使い方ですね。

Leopard Early Start Kit
http://developer.apple.com/leopard/

The Apple Store - International
http://developer.apple.com/products/

----------------------------------------------------------------------
薬学ソフトウェアの移植事例
----------------------------------------------------------------------

ADCに時折登場する、他プラットフォームからMacへの移植事例紹介ドキュメントですが、新しいものが追加されました。「OpenEye and Mac OS X: Opening to the Pharmaceutical Industry」です。

OpenEye社は、薬学関係のソフトウェアを開発する会社で、その製品では膨大な科学技術計算が必要になるようです。ソースコードは、UNIX向けにC++で書かれていましたが、それをMac OS Xに移植し、最適化を行った事例が紹介されています。

OpenEye and Mac OS X: Opening to the Pharmaceutical Industry
http://developer.apple.com/business/macmarket/openeye.html

----------------------------------------------------------------------
Mac Proのメモリと、Core 2 Duo MacBookに関するドキュメント
----------------------------------------------------------------------

ハードウェア関係のTechnical NoteとDeveloper Noteが出ています。

まず、Mac Proのメモリと熱に関する、「TN2156: Thermal considerations for Mac Pro FB-DIMMs」です。

FB-DIMMs (Fully Buffered Dual In Line Memory Modules)は、Mac Proで採用されているメモリモジュールのアーキテクチャです。このTNでは、Mac Pro向けのFB-DIMMsモジュールには、熱センサーを付ける事と、許容される発熱量が記述されています。

それと、先日発表されました、Core 2 Duoを搭載したMacBookに関するDeveloper Noteも公開されています。

TN2156: Thermal considerations for Mac Pro FB-DIMMs
http://developer.apple.com/technotes/tn2006/tn2156.html

MacBook Developer Note
http://developer.apple.com/documentation/HardwareDrivers/Conceptual/MacBook_0611/index.html

----------------------------------------------------------------------
VFSプラグインのサンプル
----------------------------------------------------------------------

Mac OS Xで、VFSプラグインを作るためのサンプルが、2つ公開されています。「EmptyFS」と「MFSLives」です。

「MFSLives」は、なんと初代Macintoshで採用されていたMFS(Macintosh File System)をサポートします。曰く、「シンプルなのでサンプルに最適」だそうです。ま、確かにそのとおりですが、2006年にもなって、MFSの文字を見る事があるとは驚きです。

EmptyFS
http://developer.apple.com/samplecode/EmptyFS/index.html

MFSLives
http://developer.apple.com/samplecode/MFSLives/index.html

----------------------------------------------------------------------
ステッパーのサンプル
----------------------------------------------------------------------

Carbonでステッパーを動作させるサンプル、「LittleArrowsShowcase」が公開されています。

LittleArrowsShowcase
http://developer.apple.com/samplecode/LittleArrowsShowcase/index.html

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

MOSA Developer News［MOSADeN＝モサ伝］第227号

2006-11-07　　

% login [user]

【実行例】
% login example
Password:
No home directory 99!
Logging in with home = "/".
Welcome to Darwin!

Login incorrect
login:

APPKIT_EXTERN NSString *NSStringPboardType;
APPKIT_EXTERN NSString *NSFilenamesPboardType;
APPKIT_EXTERN NSString *NSPostScriptPboardType;
APPKIT_EXTERN NSString *NSTIFFPboardType;
APPKIT_EXTERN NSString *NSRTFPboardType;
APPKIT_EXTERN NSString *NSTabularTextPboardType;
APPKIT_EXTERN NSString *NSFontPboardType;
APPKIT_EXTERN NSString *NSRulerPboardType;
APPKIT_EXTERN NSString *NSFileContentsPboardType;
APPKIT_EXTERN NSString *NSColorPboardType;
APPKIT_EXTERN NSString *NSRTFDPboardType;
APPKIT_EXTERN NSString *NSHTMLPboardType;
APPKIT_EXTERN NSString *NSPICTPboardType;
APPKIT_EXTERN NSString *NSURLPboardType;
APPKIT_EXTERN NSString *NSPDFPboardType;
APPKIT_EXTERN NSString *NSVCardPboardType ;
APPKIT_EXTERN NSString *NSFilesPromisePboardType ;
APPKIT_EXTERN NSString *NSInkTextPboardType ;

- (unsigned)draggingEntered: (id ) sender{
     int            t;
     NSPasteboard*  pb = [sender draggingPasteboard];
     NSLog(@"pb types count = %d", [[pb types] count]);
     for( t = 0; t < [[pb types] count]; t++){
          NSLog(@"type [%d] = %@",
                    t, [[pb types] objectAtIndex:t]);
     }
     return [super draggingEntered:sender];
}

pb types count = 8
type [0] = CorePasteboardFlavorType 0x6675726C
type [1] = NSFilenamesPboardType
type [2] = Apple URL pasteboard type
type [3] = CorePasteboardFlavorType 0xC46C6E6B
type [4] = CorePasteboardFlavorType 0x73646C74
type [5] = CorePasteboardFlavorType 0x626E6368
type [6] = CorePasteboardFlavorType 0xC4706431
type [7] = CorePasteboardFlavorType 0xC4697475

void
IntType::add(int n)
{
     number += n;
}

a.add(b);

void
IntType::add(IntType it)
{
     number += it.number;
}