MOSA Multi-OS Software Artists

目次

• MOSA理事コラム　　　　　　　　　 第8回 　　小林 正明
• 「「Wonderful Server Life」　　　第20回　　田畑 英和
• 小池邦人の「Carbon API 徒然草」
• SqueakではじめるSmalltalk入門　　第70回　　鷲見 正人
• ニュース・解説　　　　　　　　　　　　　　 木下 誠

MOSA理事コラム　　第8回　　 MOSAカフェWestへの取り組み
　　　　　　　　　　　　　　大谷 和利　　　テクノロジーライター

　皆さん、MOSA理事でテクノロジーライターの大谷和利です。
　自宅を大阪に移して（と言ってもインターネットのおかげで、仕事上、物理的な場所はあまり関係ありません。良い時代です）足かけ13年のときが過ぎました。その間に一度国外に転出したので、大阪市内でも、一回引っ越しをしたことになります。
　大阪は東京に比べるとこぢんまりとしていて坂もほとんどないため、ボストンやニューヨークに近い、自転車サイズの街だと感じます（ちょっと交通マナーがアレなので、その点は注意が必要ですが）。

関西圏のMacユーザーの熱意は、昔から東京に負けず劣らず熱く、厚いものとして知られてきました。しかし、その熱気を発散させるイベントもいつしかなくなり、アップルストアも、銀座、渋谷に次いで原宿店まで噂されるようになった東京に対して心斎橋の1店舗だけと、差がついています。
　しばらく前から、MOSA会長の矢野さんより、小規模であっても関西のユーザーや開発者のためのイベントや会合を開けないだろうかとの相談を受け、ヤノ電器さんの本社で1日限りのミニ展示会＋トークセッションを試みたこともありました。その時に感じたのは、単発では告知も行き届きにくく、不定期だとつい本業の忙しさなどにかまけて準備などが後手に回ってしまいがちということです。

そんな折、MOSAカフェの関西版をやってみてはどうかという話が出て、それならば続けられるかもしれないと感じ、今年1月の1回目からお手伝いさせていただいてきました。なるべく2ヶ月に1度、定期的に開催するという目標を掲げたおかげで、（9月は諸般の事情でスキップしましたが）次の10月のミーティングで5回目を迎えます。これもひとえに、忙しい中、興味を持って毎回のように顔を出していただいている参加者の皆さんのおかげです。中には、東京やはるばる北海道から参加されたメンバーの方もおられ、そんな中から少しでも交流の輪が広がっていければと思います。
　また、会社業務の合間を縫ってスケジュールを調整し、当日は飲み物の買い出しなどまでお願いしている矢野会長にもいつも感謝しています。
　単なるオフ会にならないように、毎回、ゲストスピーカー（レギュラー参加者の中で、独自のテーマを持たれている方にお願いすることもあります）をお呼びして、興味深い話をしていただくのですが、このセッティングが楽しくもあり、大変なところでもあります。何か面白い話題のあるときには自分自身も発表者になりますが、やはり様々な方にお話をしていただきたいので、あまり世話役が出しゃばってしまうのもどうかとは感じています。

そのような中、毎回12名程度の参加者で進めてこられましたが、これからも最低限同程度、できれば多少増やす方向で参加人数を確保し、関西におけるMOSAの情報発信の拠点として機能していければと考えています。これを読まれた方の中にも、もしMOSAカフェWestで話してみたいという方がおられましたら、ぜひとも事務局までご連絡下さい。もちろん、参加者としてでも結構ですし、大歓迎いたします。
　次回、MOSAカフェWestは10月12日に、佐藤徹理事のWWDC報告を中心テーマとして開催いたしますので、奮ってご参加を。

また、10月20、21日のMOSA湘南ミーティングのキーノートセッション「『Apple 2.0』時代の夜明け」でお会いする方もおられるでしょう。今年もご期待通り、いやご期待以上の「変なもの」をお見せできればと思っております。

【プロフィール】
大谷　和利　　Kazutoshi Ohtani
テクノロジーライター、私設Macintoshエバンジェリスト、自称路上写真家、原宿AssistOn（www.assiston.co.jp）アドバイザー。1958年生まれ。Macは初代128Kからのユーザー。現在のメインマシンはMacBok Pro／15／2.0GHz。Mac雑誌全般、デザイン雑誌「AXIS」、バイシクルクラブ別冊「自転車生活」などに連載、単発記事執筆多数。

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

　 〜DNS編〜

　これまでMac OS X Server上でのDNSについて解説してきました。ゾーンを追加して、ゾーン内でコンピュータを管理する方法について説明してきたわけですが、これでようやくネットワーク上からの名前解決に答えられるようになったわけです。今回はDNSの動作確認と、あとDNSが動作する仕組みについて改めて解説します。

・DNSの動作確認
　DNSの設定が一通り終わったら、さっそく正常に動作しているかどうかを確認してみましょう。第17回の連載で「ネットワークユーティリティ」を使用した確認方法を紹介しましたが、今回は「ターミナル」を使用してコマンドライン上で確認を行ってみたいと思います。
　ネットワーク上のマシンから動作を確認するには、まず、コマンドを実行するマシン上で「システム環境設定」の「ネットワーク」を開いて「DNSサーバ」を動作を確認したいDNSサーバのIPアドレスに変更します。
　DNSの名前解決を実行するコマンドとして”host”コマンドが用意されています。使い方はいたって簡単で引数に名前解決を行いたい名前を指定して”host”コマンドを実行します。例えば、”server.example.com”に対応するIPアドレスを調べたい場合には以下のようにコマンドを実行します。

・"host"コマンドの実行例（正引き）
% host server.example.com
server.example.com has address 192.168.0.1

　コマンドの実行結果をみると”server.example.com”に対応するIPアドレスは、”192.168.0.1″であることが分かります。では次に逆引きの名前解決も行ってみましょう。さきほど得られたIPアドレス”192.168.0.1″に対応する名前がなんであるのかを確認するには”host”コマンドの引数にIPアドレスを指定します。

・"host"コマンドの実行例（逆引き）
% host 192.168.0.1
1.0.168.192.in-addr.arpa domain name pointer server.example.com.

　この実行結果から”192.168.0.1″に対応する名前は”server.example.com”であることが分かります。つまり正引きと逆引きでそれぞれ同じ組み合わせのIPアドレスと名前が対応付けられていることが分かります。
　このようにクライアントから名前解決の要求を行ったときには、DNSサーバ上ではあらかじめ設定しておいたゾーンファイルの情報をもとにレスポンスを生成しているわけです。
　では、DNSサーバが管理するゾーンファイルに存在しないコンピュータに関する名前解決が要求された場合どうなるのでしょうか。結果がどうなるかは環境にも依存しますが、インターネットに接続されている環境ですとおそらく無事名前解決ができるはずです。DNSは1台のサーバで全ての情報を管理するようなことはせず（そもそもそんなこと無理ですが）、インターネット上のあちらこちらに存在するDNSサーバが分散して、それぞれのゾーンを管理しています。ですのであるDNSサーバで解決できなかった要求は、別のDNSサーバが解決してくれるのです。
　DNSサーバが自分自身で名前解決できなかった場合、次にどのDNSサーバに問い合わせるかですが、次に問い合わせるDNSサーバの情報が以下のファイルに書き込まれています。

・ルートネームサーバのリスト
/var/named/named.ca

　次に問い合わせるDNSサーバはルートネームサーバと呼ばれており、ルートネームサーバでは”.com”や”.jp”といったDNSの名前空間のトップレベルのゾーン情報を管理しています。このようなルートネームサーバは世界中に十数台存在しますが、ルートネームサーバの情報が「named.ca」に書き込まれています。
　ルートネームサーバはトップレベルのゾーン情報を管理していますが、その次のレベル（例えば”apple.com”）のゾーンはまた別のDNSサーバが管理していたりします。このようにいくつかのDNSサーバをたどって目的の名前が解決できる仕組みになっています。
　実際に外部のDNSサーバを参照するには「DNS」の「一般」設定で「再帰」がチェックされている必要があります。「再帰」のチェックが外れていると、DNSサーバは外部への参照を行いません。

外部のDNSサーバを参照する場合があるということは、自分が管理しているDNSサーバ（例えば”server.example.com”）も、ほかのDNSサーバから参照される場合があるということになります。では、ほかのDNSサーバはどのようにして”server.example.com”の所在を知ることができるのでしょうか。残念ながらこれまで解説してきた設定を行っただけでは、ほかのDNSサーバから参照されることはありません。そもそも設定するゾーン名（ドメイン名）も勝手に付けられるわけではなく、ドメイン名を取得する手続きが必要になります。また、ドメイン名はすでにどこかで使われている場合もありますので、必ずしも希望するドメイン名が取得できるわけではありません。
　ドメイン名の取得方法については特にMac OS X Serverに依存するような話ではありませんので、本連載では省略しますがドメイン名取得の手続きを行ってくれる業者がありますので、ネット上で検索するとすぐ取得方法がみつかるはずです。
　つまりインターネット上で動作するDNSサーバを設置するにはあと一仕事必要だということですが、少なくともこれまで説明してきた設定方法でローカルネットワーク用のDNSサーバを設定することはできます。ローカル内でのみ使用するサーバであれば、ローカルのDNSサーバだけで十分な場合があります。

DNSにはほかにもセカンダリーゾーンの設定などもありますが、DNSの解説はここらへんにして、次回からはOpen Directoryの解説を始めていきたいと思います。

つづく

小池邦人のCarbon API 徒然草（2006/09/21）

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

前回はDrag Managerについて代用APIを調査してみましたが、前回の例題と同じような状況はCarbon Frameworkの広範囲に及んでいます。今回は、QuickDrawの引退により絶滅が危惧（笑）されているPicture画像フォーマット（PICT画像）の作成や描画について調査してみます。

なにせ、QuickDrawのほとんどのAPIがDEPRECATED指定されていますので、結局のところPICT画像（PicHandle）の作成や描画をつかさどるAPIもすべてDEPRECATEDです。それに加えて、PictUtils.hで定義されているユーティリティ関連のAPIもすべてDEPRECATED指定となっています。とは言っても、開発者側としてはアプリケーションで利用したいPICTファイルがまだ存在するかもしれません。そのために、Apple社では、QuickDrawの代わりとなるPICT画像表示の手段を用意しています。

そうしたAPIは、ヘッダーファイルのQDPictToCGContext.hに定義されています。全部で以下の7つしかなく、画像データの参照にはPicHandleの代わりにQDPictRefを用います。

QDPictRef QDPictCreateWithProvider( CGDataProviderRef provider );

QDPictRef QDPictCreateWithURL( CFURLRef url );

QDPictRef QDPictRetain( QDPictRef pictRef );

void QDPictRelease( QDPictRef pictRef );

CGRect QDPictGetBounds( QDPictRef pictRef );

void QDPictGetResolution( QDPictRef pictRef,float *xRes,float *yRes );

OSStatus QDPictDrawToCGContext( CGContextRef ctx,CGRect rect,QDPictRef pictRef);

PICT画像のウィンドウへの描画は可能ですが、残念ながらPICT画像を作成するAPIは含まれていません。ただし、QDPictCreateWithProvider()を使えば、ベタの画像データ（ビットマップ）をPICT画像へ変換することは可能です。結論として、PICTファイルを描画する場合には、QDPictCreateWithURL()とQDPictDrawToCGContext()を用いることになります。以下のdrawPICTFile()は、アプリケーションパッケージのResourcesフォルダ内に存在する「Sample.pct」というPICTファイルを読み込み、ウィンドウ上のHIView（CGContextRefで参照）へ描画するためのサンプルルーチンです。

void drawPICTFile(WindowRef window,CGContextRef cont )
{
    CFURLRef    url,url1;
    CGRect      prt;
    QDPictRef   pref;

    if( url1=CFBundleCopyResourcesDirectoryURL( CFBundleGetMainBundle() ) )
    {                                    // ResourcesフォルダのCFURLRefを得る
        if( url=CFURLCreateWithString( kCFAllocatorDefault,
                                              CFSTR("Sample.pct"),url1 ) )
        {                                // Sample.pctファイルのCFURLRefを得る
            if( pref=QDPictCreateWithURL( url ) ) // CFURLRefからQDPictRefを得る
            {
                CGContextSaveGState( cont );      // 現在のCGContextの状態を保存
                prt=QDPictGetBounds( pref );      // PICT画像の矩形枠を得る
                QDPictDrawToCGContext( cont,prt,pref ); // CGContextへ描画する
                CGContextFlush( cont );           // 描画結果の表示を実行
                QDPictRelease( pref );            // QDPictRefをリリース（解放）
                CGContextRestoreGState(cont );    // CGContextの状態を戻す
            }
            CFRelease( url );  // Sample.pctファイルのCFURLRefをリリース（解放）
        }
        CFRelease( url1 );     // ResourcesフォルダのCFURLRefをリリース（解放）
    }
}

すでに昔話になってしまいましたが、以前は画像サムネイルを作成する時など、以下のようなPICT画像のリサイズルーチンをよく使いました。しかしなんと、この中で使っているAPIでDEPRECATEDでないモノは、QDGetPictureBounds()とGetPortBitMapForCopyBits()だけになってしまいました。とても寂しいことです…（涙）

short createPict( Rect *frt, PicHandle pp,PicHandle *pict )
{
    GWorldPtr    gptr,off;
    Rect        srt,drt;
    short        ret=1;
    GDHandle    ghd;

    GetGWorld( &gptr,&ghd );                   // DEPRECATED
    QDGetPictureBounds( pp,&srt );             // 生き残り
    fitRect( 1,frt,&srt,&drt );                // 自作ルーチン
    if( ! NewGWorld( &off,32,&drt,0L,0L,0 ) )  // DEPRECATED
    {
        LockPixels( GetGWorldPixMap( off ) );  // DEPRECATED
        SetGWorld( off,ghd );                  // DEPRECATED
        DrawPicture( pp,&drt );                // DEPRECATED
        if( *pict=OpenPicture( &drt ) )        // DEPRECATED
        {
            CopyBits(GetPortBitMapForCopyBits(off),
               GetPortBitMapForCopyBits(off),&drt,&drt,0,NULL ); // DEPRECATED

            ClosePicture();                    // DEPRECATED
            ret=noErr;
        }
        DisposeGWorld( off );                  // DEPRECATED
    }
    SetGWorld( gptr,ghd );                     // DEPRECATED
    return( ret );
}

ちなみに、最新のCoreGraphics APIを利用しなくても、QuickTime APIを利用すれば、PicHandleを入手したり、それをウィンドウに描画することが可能です。これらのAPIはImageCompression.hに定義されています。とりあえず、こうしたAPIはDEPRECATED指定されていません。ただしPicHandleに関しては、それを直接描画するAPIが存在しなくなりますので、一度ファイルに保存してから操作する必要があるでしょう。GetPicture()で得ていたPICTリソースも同様です。ただし、GetPicture()自体がDEPRECATEDですので、代わりにGetResource()を使う必要があります。

最初のサンプルでは、FSSpecで示されたPICTファイルからPicHandleを得ています。もう片方は、FSSpecで示されたPICTファイルの内容をウィンドウに描画するサンプルです。

short importPictureFile(FSSpec *fsc, PicHandle *pict)
{
    short                      ret=1;
    GraphicsImportComponent    gi;

    if( ! GetGraphicsImporterForFile( fsc,&gi ) ) // 対応コンポーネントを得る
    {
       ret=GraphicsImportGetAsPicture( gi,pict ); // ファイルからPicHandleを得る
       CloseComponent( gi );                      // コンポーネントを解放する
    }
    return( ret );
}

short loadOffScreen( WindowRef window,FSSpec *fsc )
{
    short                      ret=1;
    Rect                       drt;
    GraphicsImportComponent    gi;

    if( ! GetGraphicsImporterForFile( fsc,&gi ) ) // 対応コンポーネントを得る
    {
        if( ! GraphicsImportGetNaturalBounds( gi,&drt ) ) // 指定画像の矩形枠
        {
            OffsetRect( &drt,-drt.left,-drt.top );
            GraphicsImportSetGWorld( gi,GetWindowPort( window ),0L );
                                                     // 描画先のCGrafPortを指定
            GraphicsImportSetBoundsRect( gi,&drt );  // 描画矩形枠の設定
            GraphicsImportDraw( gi );                // 描画を実行する
            ret=noErr;
        }
        CloseComponent( gi ); // コンポーネントを解放する
    }
    return( ret );
}

PICT画像フォーマットは、イメージのみでなく、ある程度のベクトル図形やテキスト、加えてパタンやカラー情報も一緒に含めることができ、プログラマにとっては手軽で便利なフォーマットでした。しかし、Mac OS Xのイメージングモデルは、イメージ、ベクトル図形、テキスト情報の混在画像フォーマットとしてPDFを採用しています。また、イメージのみを表示する場合には、JPEG、TIFF、PNGなどのファイルを用いるのが妥当でしょう。なにせ、Windowsなどの別環境での表示や取り扱いが難しいとなれば、このご時世、切り捨てられても仕方がないのかもしれません。

今回はPICT画像を取り扱うための代用APIを調査してみました。次回は、代用APIと言うわけではありませんが、文字列操作（表示や作成）に関係するモダンAPIを調べてみたいと思います。

つづく

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

本連載では、名前は知っていてもなかなか触れる機会のないSmalltalkについて、最近話題のSqueakシステムを使って紹介しています。前回は、作成中のGUIビルダウインドウのウインドウメニューにダミーのメニュー項目を追加し、それらが機能するかどうかを確認しました。今回は、このメニュー項目を、当初の目的に沿った、ウィジェット追加のためのメニュー項目に置き換える作業をします。

ダミーのメニュー項目を、ウインドウメニューに追加するために書き足されたコードは、次のようなものでした。

aMenu add: 'inspect model' target: self action: #inspect.
aMenu add: 'inspect window' target: aMenu defaultTarget action: #inspect.

この場合、「ターゲット」として、前者にはモデル自身（self）、後者にはGUIビルダウインドウ（たまたま、項目を追加しようとしているメニューの、省略時ターゲットに指定されている…）に対して、メニュー項目選択時にinspectというメッセージを送り、それぞれのインスペクタを起動するためのアクション（実体はセレクタである#inspect）がパラメータとして添えられています。

つまり、ダミーにおいて「インスペクタを開く」ためのアクションである#inspectを、「ウィジェットを追加する」ためのしかるべきアクション（たとえば仮に#addFieldとでもしておきましょうか…）に差し替えれば、今回の目標は容易に達成できそうです。

addModelItemsToWindowMenu: aMenu
  aMenu addLine.
  aMenu
    add: 'add field'
    target: self
    action: #addField

あとは、このメニュー項目選択時に起動される#addFieldを定義するだけ…のはずなのですが、いざ、振る舞いを記述しようとするとちょっと困ったことが起こります。一般に、モデルはウインドウのことを知らない、つまり、GUIビルダウインドウを参照する手段がないため、それにウィジェットを新たに追加する手続きを記述することができないのです。

ただ、幸い、メソッド#addModelItemsToWindowMenu:内は例外で、パラメータとして与えられているメニュー（aMenu）のデフォルトターゲット（aMenu defaultTarget）として、間接的にGUIビルダウインドウのことを知ることができます。そこで、問題の解決をはかるために、ウィジェットを追加するためのメソッドを起動する際に、パラメータとしてGUIビルダウインドを受け渡すことができるよう、次のような工夫を施すことにいたしましょう。

addModelItemsToWindowMenu: aMenu
  aMenu addLine.
  aMenu
    add: 'add field'
    target: self
    selector: #addFieldTo:
    argument: aMenu defaultTarget

メニュー項目の追加用メソッドには、パラメータ無しの#add:target:action:の代わりに、パラメータを添えることができる#add:target:selector:argument:に差し替えます。アクションも、パラメータ無し（つまりコロンで終わらない）#addFieldから、パラメータを添えることができる（コロンで終わる）#addFieldTo:に改めます。

こうしておくことで、メニュー項目選択時にターゲットであるselfに対しては「addField」の代わりに、「addFieldTo: aMenu defaultTarget」というメッセージが送られることになり、#addFieldTo:内でも無事、GUIビルダウインドウを参照できるようになります。やや、バッドノウハウっぽい“香り”もしますが、必要だがselfが知りえない情報（オブジェクト）をパラメータとして受け渡してあげる方法も、この種の問題を解決する常套策のひとつとして覚えておくことも、悪くはないでしょう。

以上で「add field」というメニュー項目が追加されます。しかし、まだ、選択してもエラーになります。モデル（a GuiBuilder）が#addFieldTo:を起動できないからです。当然ですね。

#addFieldTo:の定義は、今回はとりあえず、次のようなものにしておきます。簡単のため、追加されるフィールドの大きさや位置は、ウインドウ中央に固定にしてあります。#addModelItemsToWindowMenu:を全選択して削除（cmd + A、delete）した後、下の内容をタイプして入力するか、ここからコピー＆ペーストしてaccept（cmd + S）すれば、#addFieldTo:として追加されます（#addModelItemsToWindowMenu:に対する置き換えにはならないので大丈夫です）。

addFieldTo: window
  | field |
  field := PluggableTextMorph
    on: self text: nil accept: nil readSelection: nil menu: nil.
  window addMorph: field frame: (0.5 @ 0.5 extent: 0.5 @ 0.5)

accept後には、メニュー項目「add field」は記述どおりの動作をしてくれるはずです。次回は、ウィジェットの位置と大きさを任意に指定できるよう、この#addFieldTo:に手を加えます。

バックナンバー：

ニュース・解説

　今週の解説担当:木下 誠

———————————————————————-
Intel Developer ForumにAppleセッション
———————————————————————-

9月26日から28日まで、サンフランシスコで「Intel Developer Forum Fall 2006」が開催されますが、そこでMac OS Xに関するセッションが2つ行われるようです。「Mac OS X Overview: Performance OS for a Performance Processor」と「Creating Applications on Mac OS X: Power at Your Fingertips」です。

スピーカはAppleの方ですので、非Mac開発者に向けたMac OS X開発環境の紹介、のような内容になるのでしょう。Intel Macが登場して以来、IntelとAppleの間での様々な動きが目立つようになりました。今年のMOSA湘南でも、インテルの方がセッションを行いますしね。

Intel Developer Forum
http://developer.intel.com/idf/us/fall2006/index.htm

Mac OS X Overview: Performance OS for a Performance Processor
http://www28.cplan.com/cv125/session_details.jsp?isid=283844&ilocation_id=125-6&ilanguage=english

Creating Applications on Mac OS X: Power at Your Fingertips
http://www28.cplan.com/cv125/session_details.jsp?isid=283744&ilocation_id=125-6&ilanguage=english

———————————————————————-
Cocoaセミナー初級編、再び開催
———————————————————————-

10月13日に、アップルが「Cocoaセミナー初級編」を開催します。これは、前回行われたもののリピートセミナーとなります。

中級編、上級編は、11月に開催が予定されています。

Cocoaセミナー初級編
http://developer.apple.com/jp/briefing/cocoa1/index.html