MOSA Multi-OS Software Artists

MOSAはソフトウェア開発者を支援します

プログラマーに興味がある方なら誰でも入会いただけます。
MOSA Multi-OS Software Artists
===SINCE 1995===

  • iPhone/iPod touch アプリ紹介
  • MOSA掲示板
  • 活動履歴
  • About MOSA(English)

MOSADenバックナンバー 2006年3月発行分

  • MOSA Developer News[MOSADeN=モサ伝]第198号

    2006-3-22

    目次

    • 「WebObjects Dev Report」    第44回  田畑 英和
    • 小池邦人の「Carbon API 徒然草」
    • SqueakではじめるSmalltalk入門  第58回  鷲見 正人
    • ニュース・解説               木下 誠

    「WebObjects Dev Report」  第44回  田畑 英和

     前回はWebObjectsアプリケーションのインストールについて解説しました。今回はいよいよインストールしたアプリケーションの運用を開始する方法について解説いたします。

    ◇Monitor
     WebObjectsの運用環境では「Monitor」というアプリケーションを使って各種設定を行います。この「Monitor」はそれ自身がWebObjectsで開発されており、Web上で操作が可能になっています。まず「Monitor」の起動方法ですが、「ターミナル」上で次の起動スクリプトを実行します。

    ・「Monitor」の起動
    % cd /System/Library/WebObjects/JavaApplications/JavaMonitor.woa/
    % ./JavaMonitor

     開発環境ではWebObjectsアプリケーションを起動しますと自動的にWebブラウザが最初の画面にアクセスしますが、運用環境ではただアプリケーションが起動するだけです。「Monitor」を起動した「ターミナル」上にはアプリケーションのURLが表示されますので、Webブラウザを使って手動でアクセスします。

    ・「Monitor」の設定
     「Monitor」を起動しますとまずApplicationの一覧画面が表示されます。本格的な設定を始める前にまずは「Monitor」の設定を行いましょう。
     「Preferences」タブをクリックしてパスワードを設定します。ここでパスワードを設定しておけば、「Monitor」の起動時にパスワードの入力を求められるようになります。
     次に「Hosts」タブをクリックして、WebObjectsサーバのホスト名もしくはIPアドレスを入力します。ホストの登録に成功するとAvailableにYESと表示されるはずです。

    ・アプリケーションの登録
     アプリケーションの登録は大きくわけて次のような手順になります。

    1. アプリケーションの追加
    2. アプリケーションの設定
    3. インスタンスの追加

     まずアプリケーションの追加ですが、「Applications」タブをクリックします。そして追加したいアプリケ−ションの名前を入力して「Add Application」ボタンをクリックします。ここで入力するアプリケーションの名前は管理しやすいようにプロジェクト名と同じ名前を使うのがよいでしょう。

    次にアプリケーションの設定ですが、最低限起動スクリプトのパスを入力します。起動スクリプトのパスはプラットフォームごとに異なるパスを入力できるようになっています。Mac OS X Serverで運用を行う場合は、「MacOSX」のところにパスを入力します。
     パスの入力は直接起動スクリプトのフルパスを入力してもかまいませんし、Path Wizard機能を使ってWebブラウザでサーバ上のファイル階層をブラウズして起動スクリプトのパスを指定することもできます。
     起動スクリプトはMac/Unix用のものとWindows用のものが自動生成されていますので、間違って選択しないように気をつけてください。
     パスの入力が終われば右側の「Push」ボタンをクリックします。このボタンをクリックしておかないとパスの設定は反映されません。

     アプリケーションの設定の次は、いよいよ最後のインスタンスの追加です。まず画面右上の「Detail View」ボタンをクリックしてインスタンスの詳細画面に移動します。そして追加したいインスタンスの数を入力し、インスタンスを稼働させるホストを選択します。WebObjectsの運用環境は標準で負荷分散に対応していますので、複数のインスタンスを同時に起動することができます。また、複数のサーバ上でアプリケーションを起動することもできますので、インスタンスを追加するには実行するホストを選択します。あらかじめ「Hosts」画面で設定しておいたホストが自動的にリストアップされますので、あとは適切なホストを選択するだけです。
     初めてアプリケーションを運用する場合は、いきなり複数のインスタンスを追加せずに、まずは1つのインスタンスだけを追加して正しく起動できるかどうかを確認するのがよいでしょう。

    ・アプリケーションの起動
     インスタンスを追加すれば、自動的にアプリケーションが起動します。これはデフォルトの状態でAuto Recover機能がONになっているからです。
     アプリケーションの起動が完了するとStatusの表示がONに変わります。もしStatusがONにならなければ、どこかの設定に問題があるか、あるいはそもそもアプリケーションに問題があります。こういったときにはアプリケーションを「ターミナル」上で直接起動するなどして原因を確認してください。
     アプリケーションを起動すると、インスタンスの詳細画面にアプリケーションのトップ画面にアクセスするためのハイパーリンクが表示されますので、このハイパーリンクをクリックすればすぐにアプリケーションにアクセスできるようになります。

    小池邦人のCarbon API 徒然草(2006/03/17)

    〜 アプリケーションのUniversal Binary化(その5) 〜

    今回は、PowerPCとx86 CPUのエンディアンの違いによる影響を、実際のソースコードを調べながら検証していきたいと思います。まずは、エンディアンの違いで影響が出るだろうと思われる点を具体的にピックアップしてみます。

    ・整数フォーマットが反転する(2bytes,4bytes,8bytes整数)
    ・浮動小数点フォーマットが反転する(4bytes,8bytes浮動小数点)
    ・ネットワークで流れるデータはビッグエンディアンで固定されている
    ・Excelファイルフォーマットはリトルエンディアンで固定されている
    ・Photoshop画像フォーマットはビッグエンディアンで固定されている
    ・Quartz 2Dのビットマップ画像はbitmapInfoパラメータで調整される
    ・TIFF,Exif,Dicomファイルフォーマットは両方が存在 (ヘッダのMMとII表記で区別)
    ・Font関連リソース(FOND、NFNT、sfnt など)はビッグエンディアン
    ・OSTypeをストリングとして扱う場合にはエンディアンを考慮する必要がある
    ・UnicodeはBOMがなければビッグエンディアンとして認識される
    ・関数を利用してビットテストを実行すると結果が異なる場合がある
    ・一般リソースデータの入出力はResource Managerがエンディアンを考慮する
    ・カスタムリソースデータの場合にはエンディアンが考慮されない
    ・カスタムアップルイベント&ペーストボードデータはビッグエンディアンのまま

    まず最初に、エンディアンの違いを考慮すべき典型的な例として、整数フォーマットの反転に対処する例を見てみます。アプリケーションの内部処理で整数を利用している時には何も問題はないですが、固定エンディアンフォーマットで整数や浮動小数点をファイルに保存し、それを別エンディアン環境で読み込み利用しようとした時に問題が生じます。例えば、ビッグエンディアンフォーマット(PowerPC)で保存された初期設定ファイルをリトルエンディアン環境(x86)のHDへ複製してそのまま利用しようとした時などです。

    今回の初期設定ファイルは以下の構造体を使い、short整数を128個保存することにします。ファイルのネイティブフォーマットはビッグエンディアン(PowerPC)とします。

    typedef struct  {
                        short    p_para[128]; //  初期設定保存用の整数配列
    
                    } Pref,*PrefPtr,**PrefHandle;
    
    最初のgetPrefFSSpec()ルーチンは、ライブラリフォルダ内にあるPreferencesフォルダを探し、そのFSSpecを返します。今回はGetIndString()により、STR#リソースから初期設定ファイル名を得ています。ここではエンディアンの問題は存在しません。
    
    
    short getPrefFSSpec( FSSpec *fsc,short nb )
    {
        short    vref;
        Str255   name;
        long     id;
    
        GetIndString( name,128,nb );  // STR#リソースから初期設定ファイル名を得る
        if( ! FindFolder( kOnSystemDisk,kPreferencesFolderType,kCreateFolder,
                                                                &vref,&id ) )
        {
            FSMakeFSSpec( vref,id,name,fsc ); // PreferencesフォルダのFSSpecを得る
            return( 0 );
        }
        return( 1 );
    }

    続いて、初期設定の構造体データをファイルから読み込むreadPreferences()ルーチンです。もし初期設定ファイルが無ければ、それを作成してから初期化したデータを書き込みます。よってx86用の実行コードでは、この書き込み処理の直前に、Pref構造体に含まれている整数を反転させる必要があります。それを行っているのがflipPreferences()ルーチンです。ここで注意することは、オリジナルの初期設定構造体(sys_Pref)の整数値を反転させてしまうと、その後の内部処理が正常に行われなくなることです。よって、ここではsys_Prefをtempへ複製し、それを反転させてから書き込むようにしています。

    Pref    sys_Pref;  // 外部変数としてPref構造体を確保する(内部処理で用いる)
    
    short readPreferences(void)
    {
        short    fref,ret=1;
        Pref     temp;
        FSSpec   fsc;
        long     len;
    
        if( ! getPrefFSSpec( &fsc,1 ) ) // 初期設定ファイルのFSSpecを得る
        {
            len=sizeof( Pref );
            if( ! FSpOpenDF( &fsc,fsRdPerm,&fref ) ) // ファイルオープン
            {
                ret=FSRead( fref,&len,&sys_Pref );   // ファイルを読み込む
                flipPreferences( &sys_Pref );        // 整数のエンディアンを反転
                FSClose( fref );                     // ファイルを閉じる
            }
            else // 初期設定ファイルが存在しなければ初期化をしてから作成する
            {
               initPreferences(  &sys_Pref ); // Pref構造体の初期化自作ルーチン
                if( ! FSpCreate( &fsc,'mosa','pref',smSystemScript ) )
                                               // 初期設定ファイルを作成する
                {
                    if( ! FSpOpenDF( &fsc,fsWrPerm,&fref ) ) // ファイルオープン
                    {
                        BlockMoveData( &sys_Pref,&temp,len ); // tempへ複製する
                        flipPreferences( &temp );       // 整数のエンディアンを反転
                        ret=FSWrite( fref,&len,&temp ); // ファイルを書き出す
                        FSClose( fref );                // ファイルを閉じる
                    }
                }
            }
        }
        return( ret );
    }
    


    次は、初期設定ファイルを保存(書き出し)するwritePreferences()ルーチンです。処理内容は,readPreferences()の初期設定ファイル新規作成の箇所とほとんど同じです。

    short writePreferences(void)
    {
        short    fref,ret=1;
        Pref     temp;
        FSSpec   fsc;
        long     len;
    
        if( ! getPrefFSSpec( &fsc,1 ) )         // 初期設定ファイルのFSSpecを得る
        {
            if( ! FSpOpenDF( &fsc,fsWrPerm,&fref ) )  // 初期設定ファイルオープン
            {
                len=sizeof( Pref );                   // Pref構造体のサイズを得る
                BlockMoveData( &sys_Pref,&temp,len ); // sys_Prefをtempへ複製する
                flipPreferences( &temp );             // 整数のエンディアンを反転
                ret=FSWrite( fref,&len,&temp );       // ファイルを書き出す
                FSClose( fref );                      // ファイルを閉じる
            }
        }
        return( ret );
    }
    


    以下は、すべての整数配列のエンディアンを反転させるflipPreferences()ルーチンです。2bytes整数の反転にはEndian16_Swap() APIを用いています。このソースをUniversal Binaryとしてコンパイルした場合、#if__LITTLE_ENDIAN__と#endifで挟まれた部分は、PowerPC用の実行ファイルとしてはコンパイルされませんので、PowerPC環境で実行した時には、何も処理しないで素通りすることになります。

    void flipPreferences(PrefPtr pptr)
    {
        #if __LITTLE_ENDIAN__   // x86用コンパイルの時だけコードが発生する
    
        long    i;
    
        for( i=0;i<128;i++ )    // 配列個数分だけループさせる
            pptr->p_para[i]=Endian16_Swap( pptr->p_para[i] ); // エンディアンを反転
    
        #endif
    }
    


    初期設定ファイルは、エンディアンの影響を受けないテキストファイルやXMLファイルで保存すべきでしょう(CFPreference APIなどを使う)。しかし、古いアプリケーションに関しては今更手遅れです(笑)。初期設定ファイルが、単体マシンでしか利用されないのなら今回説明した処理は不必要なのですが、Macintoshには「移行アシスタント」という便利なツールがあるおかげで、現在利用している初期設定ファイルも別マシンでそのまま使われる可能性があります。ですから、CPUの種類が異なるマシン環境であると認識したら、初期設定ファイルを再構築する処理か、ファイル読み書きの出入り口で整数や浮動小数点のエンディアンをひっくり返す処理が必要となるわけです。

    次回は、Macintosh独自のデータ保存方法「リソース」についてエンディアンの影響を調べてみましょう。例題としてQuickDrawで利用してきたPicture(PICT)構造体を取り上げたいと思います。

    つづく

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

     本連載では、名前は知っていてもなかなか触れる機会のないSmalltalkについて、最近話題のSqueakシステムを使って紹介しています。前回に引き続き、簡単なスクリプトで作成したポップアップメニューの機能を果たすモーフを用いて、これをSmalltalkならではのツールを用いて解析し、その仕組みをより細部にわたって観察してみましょう。

     念のため、スクリプトを再掲します。

    | menu |
    menu := MenuMorph new.
    menu defaultTarget: 1.
    menu add: 'default (one)' action: #inspect.
    menu addLine.
    menu add: 'two'   target: 2 selector: #inspect.
    menu add: 'three' target: 3 selector: #inspect.
    menu add: 'four'  target: 4 selector: #inspect.
    menu addLine.
    menu
       add: 'open workspace'
       target: Workspace
       selector: #openLabel:
       argument: 'My New Workspace'.
    menu invokeModal
    


     CocoaのApplication Kitでメニューを作る手続きととてもよく似ていますね。このスクリプトをワークスペースなどにペーストした後、全体を選択してdo it(cmd + D)することで、次図のようなポップアップメニューを機能させることができます。

    [fig.A]スクリプトで作られたポップアップメニュー

     こうして作られたメニューも他のGUIウィジェット同様にモーフで構成され、主にコマンドキーを用いたモーフとしての操作も受け付けます。たとえば、コマンドクリック(コマンドキーを押しながらクリック)でモーフとして選択したり、そのままドラッグして移動させることができます。

    [fig.B]モーフとして選択されたポップアップメニュー

     ハローのうち、右端の上から2番目にあるグレイのボタンは「デバッグハロー」と呼ばれ、クリックすると、選択しているモーフに関する「デバッグメニュー」をポップアップします。デバッグメニューには、選択したモーフの内部的な情報にアクセスするのに便利なメニュー項目が用意されています。

    [fig.C]デバッグハローとデバッグメニュー

     このうち「モーフの検査」というメニュー項目を選択することで、選択したモーフ(今の場合、自作のポップアップメニュー)のインスペクタを開くことができます。

    すべてのモーフはsubmorphsというインスタンス変数を持ち、これに自分に属するサブモーフを束縛しています。今開いたインスペクタの左上のリストペインでsubmorphsという欄をクリックすると、先のスクリプトで#add:action:などを介して定義したメニュー項目モーフ(a MenuItemMorph)がその数だけ登録されていることを確認できます。

    [fig.D]自作ポップアップメニューのsubmorphs

     また、ownerというインスタンス変数には、逆に自分がサブモーフとして属しているモーフが束縛されています。今はnilになっていますが、これはデバッグメニューを開いたときに観察対象のメニューモーフが画面から消えてしまっているからです。デバッグハローをshiftキーを押しながらクリックすることで、メニューを介さずに直接インスペクタを開くショートカットを使えば、観察したいメニューを消さずにインスペクタを同時に開くことが出来るので、この方法で再度ownerを見てみましょう。

    [fig.E]ポップアップメニューのownerの確認

     すると先ほどのnilの代わりに本来のa PasteUpMorph(n) [world](nは適当な数値)が束縛されていることが分かります。PasteUpMorphとは、デスクトップを表現するのに用いられているモーフの属するクラスです。また、ここでnはオブジェクトにhashというメッセージを送ったときに得られるオブジェクト固有の数値(原則として…)で、オブジェクトの同等性の判断に使われます。

    では引き続き、デスクトップをコマンドクリックしてモーフとして選択した後、右側に現れたデバッグハローをshiftクリックすることで、デスクトップのインスペクタを呼び出してみてください。インスペクタとのタイトルバー、あるいはselfを選択して右側のペインに表示される内容と、先ほどのポップアップメニューのownerの値は一致しているはずです。

    つまり、ポップアップメニューは、メニュー項目をサブモーフとして追加して組み立てられたあと、デスクトップにサブモーフとして追加されることで、我々の前に現れたわけです。非常にシンプルで、わかりやすい動作モデルですね。

    実装からも同様のことを確認することが可能です。スクリプト中のinvokeModalを選択してbrowse it(cmd + B)でブラウザを開き「implementors」ボタンを使って、#invokeModal: →#invokeModalAt:in:allowKeyboard: → #popUpAt:forHand:in:allowKeyboard:とたどってゆくと、そこでデスクトップを束縛したaWorldに対してメッセージ「addMorphFront: self」を送信していることがわかります。

    バックナンバー:

    ニュース・解説

     今週の解説担当:木下 誠

    ———————————————————————-
    QuickBooksの開発事例
    ———————————————————————-

    ADCでは、時折Mac向けソフトウェアの開発事例を紹介していますが、今回は
    IntuitのQuickBooksが取り上げられています。これはSOHO向けの簿記ソフト
    ウェアのようです。

    QuickBooksの開発行程の中から、CarbonからCocoaへの移行、Tigerの機能や.
    Macとの統合、が述べられています。この辺りが、Appleがソフトウェアベンダ
    にプッシュしていきたいところなのでしょう。

    Tiger機能の活用としては、Web Kitの利用、iCalとの統合、Address Bookとの
    同期などが挙げられています。これらはPantherまでに出揃っていた気もしま
    すが。

    Intuit Enhances QuickBooks for Mac: New Tiger Features and .Mac Integration
    http://developer.apple.com/business/macmarket/quickbooks.html

    ———————————————————————-
    Cocoaに関する新規ドキュメントが多数公開
    ———————————————————————-

    先週の小池さんの記事にもありましたが、Cocoaに関するドキュメントが、多数新規に公開されています。以下のものがあります。

    - Cocoa Drawing Guide
    - Cocoa Fundamentals Guide
    - Cocoa Scripting Guide
    - Document-Based Applications Overview
    - Scroll View Programming Guide for Cocoa
    - View Programming Guide for Cocoa

    これらのドキュメントは、単なるリファレンスではなく、実際のアプリケーションでの利用に則した形で解説しています。また、いままで分散されていた情報が一つにまとめられていたり、サンプルソースコードのコメントからしか伺い知る事ができなかった情報があったりと、非常に有益な形になっています。

    Cocoaのプログラミングに慣れている方も、一度目を通す事をお勧めします。きっと、新しい事に気づく事があると思います。

    簡単に、個人的に興味を惹かれたトピックを並べてみました。

    【Cocoa Drawing Guide: Advanced Drawing Techniques】

    Cocoaで描画する際の、テクニックを集めたものです。パスに影を付ける、グラデーションを使う、フルスクリーンで描画する、アニメーションを行う、描画を最適化する、といった項目が取り上げられています。

    http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaDrawingGuide/AdvancedDrawing/chapter_9_section_1.html

    【Cocoa Drawing Guide: Incorporating Other Drawing Technologies】

    CocoaのNSViewで、Cocoa以外の描画のためのフレームワークを利用する方法を解説しています。Quartz、OpenGL、QuickTime、Quartz Composerが含まれます。

    http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaDrawingGuide/QuartzOpenGL/chapter_10_section_1.html

    【Cocoa Fundamentals Guide: Cocoa Design Patterns】

    Cocoaのクラスを、デザインパターンの文脈から解説しています。Cocoaの様々なクラスが、デザインパターンで言うところのどのパターンに当てはまるかを分類しています。

    http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/chapter_5_section_1.html

    【Document-Based Applications Overview: Message Flow in the Document
    Architecture】

    ドキュメント・ベース・アプリケーションでの、処理の流れを解説しています。ドキュメント・ベース・アプリケーションでは、NSDocumentController、NSDocument、NSWindowControllerといったクラスが使われますが、この3つのクラスの間で、どのようにメッセージがやりとりされているのか、フローチャートで表しています。新規ドキュメントの作成、ドキュメントのオープン、ドキュメントの保存、が詳しく解説されています。

    http://developer.apple.com/documentation/Cocoa/Conceptual/Documents/Articles/ObjectInteractions.html

    【Scroll View Programming Guide for Cocoa: Synchronizing Scroll
    Views】

    スクロールビューを実現する、NSScrollViewのサンプルを紹介しています。ここでは、2つのスクロールビューがあったとき、これらを同期させるサンプルが取り上げられています。

    http://developer.apple.com/documentation/Cocoa/Conceptual/NSScrollViewGuide/Articles/SynchroScroll.html

    ———————————————————————-
    Cocoaのサンプル
    ———————————————————————-

    Cocoaに関するサンプルが、2つ公開されています。

    まず、Web Kitで、新しいプロトコルをサポートするためのサンプルです。NSURLProtocolのサブクラスを作る事になります。このサンプルでは、メモリにあるJPEGイメージを表示するプロトコルを例として作成しています。

    SpecialPictureProtocol
    http://developer.apple.com/samplecode/SpecialPictureProtocol/SpecialPictureProtocol.html

    もう1つは、NSViewでドラッグ・アンド・ドロップを行うためのサンプルです。

    DragItemAround
    http://developer.apple.com/samplecode/DragItemAround/DragItemAround.html

    ———————————————————————-
    ColorSyncとIntel Mac
    ———————————————————————-

    ColorSyncとIntel Macに関するQAが公開されています。ColorSyncでビットマップを得るAPIを使ったとき、バイトスワップをする必要があるかどうか、を解説しています。Universal Binary化では、このようにAPI毎の対処が求められていくのでしょう。

    QA1464 ColorSync Color Matching on Intel-based Macs
    http://developer.apple.com/qa/qa2006/qa1464.html

     

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

     

    MOSA Developer News   略称[MOSADeN=モサ伝]
          記事投稿受付 http://www.mosa.gr.jp/topics/mdn-toukou.html
    Apple、Mac OSは米国アップルコンピュータ社の登録商標です。またそのほかの各製品名等はそれぞれ各社の商標ならびに登録商標です。
    このメールの再配信、および掲載された記事の無断転載を禁じます。
    特定非営利活動法人MOSA  http://www.mosa.gr.jp/
    Copyright (C)2006 MOSA. All rights reserved.

  • MOSA Developer News[MOSADeN=モサ伝]第197号

    2006-03-14

    目次

    • 「WebObjects Dev Report」     第43回  田畑 英和
    • 藤本裕之のプログラミング夜話 #87
    • 高橋真人の「プログラミング指南」  第85回
    • ニュース・解説                小池 邦人

    「WebObjects Dev Report」  第43回  田畑 英和

     今回はWebObjectsアプリケーションのインストールについて解説します。プロジェクトが完成し、運用を開始するにはまずインストールを行います。このときあらかじめ開発機上でインストール用のビルドを行い、その後運用機にビルド済のファイル一式を移動するという手順になります。

    ◇インストール用のビルド
     ビルドを行う前に、いったんプロジェクトをクリーニングした状態から正常にビルドができるかどうかを確認しておくのがよいでしょう。問題なくビルドできれば、さっそくインストール用のビルドです。前回Split Installの話をしましたが、Web Server Resourcesとそれ以外の部分を分割してインストールする必要があるため、ビルドも分割して行います。Xcodeにはビルドを実行するためのコマンドxcodebuildが用意されていますので、このコマンドを使ったやり方を紹介しましょう。
     xcodebuildはバージョンによってオプションが異なりますが、以下のようなコマンドを実行します。このコマンドは「ターミナル」を使って、プロジェクトが存在するディレクトリに移動してから実行します。

    ・Xcode 2.0以前の場合
    xcodebuild install -buildstyle Deployment DSTROOT=/
    xcodebuild install -buildstyle WebServer DSTROOT=/
    ・Xcode 2.1以降の場合
    xcodebuild install -configuration Deployment DSTROOT=/
    xcodebuild install -configuration WebServer DSTROOT=/

     Xcode 2.0までは-buildstyleと指定していたオプションがXcode 2.1からは-configurationに変わっています。このオプションのパラメータでビルドの形式を指定しますが、”WebServer”と指定するのがWeb Server Resources用のビルド形式になり、”Deployment”と指定するのがそれ以外のファイル用のビルド形式になります。
     ビルドを実行すると、アプリケーションの場合はデフォルトで次のパスにビルド済のファイルがインストールされます。

    ・Deployment
    /Library/WebObjects/Applications
    ・WebServer
    /Library/WebServer/Documents/WebObjects

     インストール先は自由に変更することができます。Xcodeでプロジェクトを開いて、ターゲットの設定で「インストール先」を変更します。このとき設定をおこなうターゲットは、アプリケーション名がついたターゲットを設定します。
     フレームワーク用のプロジェクトをインストールする場合もビルド方法は同じですが、インストール場所が異なります。フレームワークの場合はデフォルトで次のパスにビルド済のファイルがインストールされます。

    ・Deployment
    /Library/Frameworks
    ・WebServer
    /Library/WebServer/Documents/WebObjects/Frameworks

     フレームワークはアプリケーションから参照されますので、手順としてはまずフレームワークをビルドしてから次にアプリケーションをビルドすることになります。
     つまりアプリケーションをビルドする時点では、すでにフレームワークはビルドされて/Library/Frameworksにインストールされています。アプリケーションのプロジェクトに登録したフレームワークが、インストール後の正しいパスを参照していることを確認してから、アプリケーションのビルドを行うよう注意が必要です。

    ◇運用機へのインストール
     開発機上でのビルドが終われば、次はビルド済のファイルを運用機上に移動します。ようするに運用機上にファイルが転送できればよいのですが、ファイルの転送には「Apple Remote Desktop(以下ARD)」がお勧めです。ARDはマシンをリモートで操作するためのソフトですが、ファイルを転送するための機能も備えています。
     ARDを使用するためにはあらかじめ、転送先のマシンでARDを有効にしておく必要があります。「システム環境設定」の「共有」からARDを有効にすることができます。このときARDでのアクセスを許可するユーザを指定します。
     ファイルの転送時には転送元のパスと同じ場所に転送することができますので、開発機上でインストールしたファイルがそのまま運用機上にも同じパスで転送することができます。
     「ARD」は別売のソフトですが、こちらを利用できない場合はAFPでファイルを転送したり、なんらかのメディアを経由して運用機上にファイルをコピーします。

    ◇その他の準備
     アプリケーションがフレームワークだけでなくjarファイルなどを参照している場合は、それらのファイルもあらかじめ運用機上に準備しておく必要があります。またデータベースに関してもあらかじめ適切なセットアップを行っておく必要があります。
     アプリケーションサーバとデータベースサーバを別マシンで運用する場合には、運用環境でのデータベースの接続先が開発機上とは異なる場合がありますので、このような場合にはモデルファイルに設定したJDBCのURLに注意する必要があります。
     また実際にアプリケーションの運用を始める前に、コマンドラインから直接アプリケーションを起動して、正常に起動するかどうかを確認しておきましょう。こうすることでサーバ設置時のミスを防止することができます。コマンドラインからアプリケーションを実行するには、「ターミナル」を使ってアプリケーションがインストールされているディレクトリに移動し、プロジェクト名と同じ名前のファイルを実行します。このファイルはアプリケーションの起動用スクリプトになっています。

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

     さて、前回までのややこしいアトリビュートが片づき、今回のネタは「Has texture」。もうこれは「読んで字の如しであります、以上おわり」で次に行ってもいいような項目だ、と思うでしょう? ところが調べてみるとなかなかどうしてそうでもないのであった。
     まずはちょうど10回前、本連載第77回から数回に渡って説明したNSWindowの初期化メッセージを思い出してくだされ。

    -(id) initWithContentRect:(NSRect)contentRect
                          styleMask:(unsigned int)aStyle
                            backing:(NSBackingStoreType)bufferingType
                              defer:(BOOL)flag;
    


    あのとき私は、これの2番目のパラメータ、styleMaskについて、NSWindow.hに以下のような定義があると書いた。

    enum {
        NSBorderlessWindowMask = 0,
        NSTitledWindowMask = 1 << 0,
        NSClosableWindowMask = 1 << 1,
        NSMiniaturizableWindowMask = 1 << 2,
        NSResizableWindowMask = 1 << 3
    };
    


    そして、Interface Builderでは一番上のNSBorderlessWindowMaskをセットすることはできないので、タイトルバーのないウインドウを作りたいときには、initWithContentRect:styleMask:backing:defer: をプログラムから呼び出すしかないという説明をしたのである。覚えてますか。
     説明がややこしくなるのであんときは割愛したのだが(つうか、なにを隠そう今回のために虎視眈々タンカラリンととっておいたのだが)、NSWindow.hの上の定義のすぐ下に、実は次のような追加がある。

    #if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_2
    /* Specifies a window with textured background (eg. metal)
    */
    enum {
        NSTexturedBackgroundWindowMask  = 1 << 8
    };
    #endif
    


    そうなのだ。Interface Builderでは別建てだが、実は今回のテーマ「Has texture」アトリビュートは、あの styleMask で指定されるものであり、したがって、styleMask他のビットと同様、いったんウィンドウを作っちゃったらプログラムから『あ、やっぱテクスチャやめます』とかいうことはできないのである。びっくりしましたか。
     なお、テクスチャを持つウインドウと通常のウインドウの違いに、前者はタイトルバーだけでなくウインドウのバックグラウンド部分を「掴んで」ドラッグすることが出来る、というのがあるが、この機能は実はテクスチャとは独立で、setMovableByWindowBackground: というメッセージで変更することができる。これで「NO」をセットすれば、テクスチャ・ウインドウでもタイトルバー以外のところを「掴んで」ドラッグできなくすることが可能だし、逆もまた真、普通のウインドウを「そこらを持ってドラッグできる」ようにも出来るのだ。
     もうひとつ「なお」、注意深いヒトは上の追加定義の下に、Tigerになってからの追加があと2つあることに気付いたと思う。が、これについても「フジモトめ、出てきたときに『実はまだあったのである』とやるつもりだな」と察して、今は見て見ぬふりをしてくれるような大人のヒトがオレは好きである。ではまた次回。
    (2006_03_10)

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

    UNIXとしてのMac OS X

    〜Perlについて(31)〜

     こんにちは、高橋真人です。
     さて前回ご紹介した、私が実際に仕事で使ったスクリプトを解説して行くわけですが、このスクリプトで私が処理したのは辞書用の登録データです。余り細かくは触れませんが、このデータはMacの世界ではよく見るタブ区切りのテキストで、1レコードが1行、各項目をタブで区切ってあるというフォーマットになっています。
     そんな形のテキストデータを処理するために私が書いた先のスクリプトですが、大まかに見ると以下のような処理の流れとなります。

    1. 入力ファイル名の末尾に".sort"と付けたものを出力ファイル名とする
    2. 出力ファイルを開く(なかったら作成)
    3. 出力ファイルのクリエータ・タイプをYooEditのテキストに
    4. データ処理、書き出し
    5. メッセージダイアログを表示、終了

     スクリプトの行数の割に処理内容が少ないと思われるかもしれません。実はこのスクリプトのキモはほとんどが4.にあり、それ以外はおまけです。そして、4.の部分に該当するのは、実は全体の30行を占める「1つの文」です。
     ちなみに、3.と5.に関しては頭にMacPerl::と付いていることからも分かるように、MacPerlによる独自の拡張です。今でこそ、BSDのレイヤーからもMac OS Xの独自の部分のいくつかにはアクセスできるようになっていますが、当時は純然たるUNIX文化のPerlとMac独自の部分を融合することは決して容易なことではなかったので、これらのMacPerl拡張には重宝しました。
     もっとも、MacPerlが備えていた独自拡張はこの程度のものではなく、Toolboxの各種マネジャーにもアクセスできるようになっていたはずです。ただ、当時の私の技術力では残念ながらこれらの機能を生かすことはできなかったのですが。
     さて、話を戻します。Perlではセミコロンが付いたところで文が終わることになっていますので、このスクリプトは実はたった7つの文からなっているということが言えるのです。
     「え?! セミコロンはもっといっぱいあるけど?...」なんて声も聞こえてきそうですが、この7つの文というのはあくまで「複文も1つの文」と見なしてのことです。つまり、{} によって囲まれているのは、複数の文がまとめられて一つの文になっているという見方です。
     もちろん「文の数が少ない方が偉い」などという価値観でお話ししているわけではありません。注目してほしいのは、どうして行数にして30行近くあるこれだけの処理内容をあえて1行で書くのかというところです。確かに変数などを新たに設けることによって、複数の文に分けることはもちろん可能です。しかし、ここはあえて1つの文で書く方が合理的なのだということです。
     実は私がPerlの勉強を進めて行っていちばん衝撃を受けたのがこのことです。ここをメインに少し掘り下げてみましょう。
     この「1文」の構造の概略を示すと、以下のようになります。

    map {} sort {} map {} grep {} map {} <>;

     {} の中、つまり複文の中に書いてあるこまごました処理を省略するとこのような流れが見えてきます。map、sort、grepなどの演算子が並んでいますが、{} で囲まれた複文の部分は、これらの演算子を修飾していると見てください。
     先頭から見ると、mapはsortの結果を受け、sortはmapの結果を受け、mapはgrepの結果を受け...、という具合になるわけですが、ここはそうやって前から見て行くのではなく、後ろから読んで行くのです。
     まず、<>によってstdin(MacPerlでは、ドロップしたファイルがここに割り当てられる)からデータを読み込んできますが、ここはリストコンテキストなので、結果としてファイルの各行が要素となったリストが返されます。
     なぜ、リストコンテキストなのかというと、次にデータが渡される、1つ前の演算子であるmapがリストを要求するからです。ちなみに、今までの連載でご理解いただけた方もいらっしゃると思いますが、map、sort、grepの各演算子はいずれもリストコンテキストを要求するものとなっています。
     実は、正にこここそが、今回説明する形式の処理でのポイントとなります。演算子が順番に並んでいますが、データはリストの形で後ろから前に順番に処理されて行きます。
     実は連載の61回目でもこのやり方に少し触れていますが、今回はもう少し分析的に解説してみましょう。
     まず、sort演算子を例にとります。sortはリストを受け、それを並べ替えてリストにして返します。例えばこんな感じです。

    @list = (5, 3, 7, 2, 6, 1);
    @list = sort @list;
    print @list;
    
    


    【出力結果】
    123567

     説明を簡略にするために出力体裁などに手を抜いていますが、@listに渡されたリストがsort演算子によって並べ替えられることがお分かりいただけると思います。(ここでは分かりやすさのために変数を使って複数の文に分けていますが、もちろん print sort (5, 3, 7, 2, 6, 1);という1行だけでも同じです)
     では、次にsort演算子に比較のオプションを与えてみます。今度は、アルファベットをリストの中に格納してソートしますが、大文字小文字をごちゃまぜにします。

    @list = qw(f D c N m L b s Z p);

     qw()というのは初めて出てきましたが、これは "quote words" の略で、('f', 'D', 'c', 'N', 'm', 'L', 'b', 's', 'Z', 'p');と同じことです。書きやすさのためによく使われます。
     さてこのリストを先ほどのスクリプトで並べ替えると、'DLNZbcfmps'という結果が出力されます。コード順で大文字が小文字よりも先にくるためにこうなりますが、これをちゃんと、つまり大文字と小文字に関係なく、アルファベット順に並べるにはどうしたらいいのか、ということです。
     といったところで、続きは次回。

    ニュース・解説

     今週の解説担当:小池邦人

    ● Carbon ドキュメント & サンプル & SDK ナビゲーション(2005/03/10)

    【開発環境】

    Apple社からWWDC2006の開催日程が発表になりました。今年は8/7から8/11までサンフランシスコで開催されます。例年と比べて、やけに時期が遅いですね!Mac Proに搭載する予定のインテル版CPUの発表に合わせたのか、Leopard(Mac OS X 10.5)のプレビュー版提供が、その時期でないと間に合わないのか? 色々と勘ぐりたくなります(笑)

    http://developer.apple.com/wwdc/

    レジストレーションの早期割引の締め切りは6/23ですので、参加を予定されている方は忘れないように注意いたしましょう。また、ADCのセレクトメンバーを継続したい方は「WWDC 2006 E-ticket and ADC Select Membership」を選択すれば$400割引となりますので、こちらもお忘れなく!

    MOSAでは、アップル社協力のもと、アップル社側の和訳がなかなか追いつかないテクニカルドキュメントの要約を行っています。今回は、Cocoaテキスト関連テクニカルドキュメントが中心です。完訳ではありませんが、Cocoaプログラムに挑戦しようと考えている方には、少なからずお役に立てると思います。ご活用ください。

    http://www.mosa.gr.jp/htmdocs/article/document-2005oct.php

    【テクニカルドキュメント】

    前回から3月10日の期間中、Apple社のDocumentationサイトには数多くのドキュメントが登録されました。ただし、大部分は今までの内容のマイナーチェンジです。今回は、その中で初版と内容が大幅変更になったドキュメントだけをピックアップしました。Cocoaプログラミングに役立つドキュメントが大量に登場しています。また、デベロッパ向け読み物もひとつ登録されました。「Using Ruby on Rails for Web Development on Mac OS X」については、前号の木下さんの記事が参考になります。加えて、日本のアップルデベロッパサイトにウェブ技術関連の和訳ドキュメントが2つ登録されました。

    「Cocoa Drawing Guide」(PDFあり)(初版)
    「Cocoa Fundamentals Guide」(PDFあり)(初版)
    「Cocoa Scripting Guide」(PDFあり)
    「Document-Based Applications Overview」(PDFあり)
    「Quartz 2D Reference」
    「Scroll View Programming Guide for Cocoa」(PDFあり)(初版)
    「View Programming Guide for Cocoa」(PDFあり)(初版)

    http://developer.apple.com/documentation/index-rev-date.html

    「Using Ruby on Rails for Web Development on Mac OS X」(読み物)

    http://developer.apple.com/tools/rubyonrails.html

    「Safari FAQ」(日本語訳)

    http://developer.apple.com/jp/internet/safari/faq.html

    「Web開発のベストプラクティス」(日本語訳)

    http://developer.apple.com/jp/internet/webcontent/bestwebdev.html

    前回から3月10日の期間中、新規テクニカルノートは2つ登録され、新規テクニカルQ&Aも2つ登録されました。テクニカルノートの方は両方とも改訂版としての再登録となります。QA1370については、前号の木下さんの記事も参考にしてください。

    TN2146「Making the most of Cocoa bindings in Quartz Composer」
    TN2123「CrashReporter」

    http://developer.apple.com/technicalnotes/index-rev-date.html

    QA1465「Movie Export From Procedures - Providing k2vuyPixelFormat da to
    MovieExportGetDataProc」
    QA1370「Common QA and Roadmap for USB Software Development on Mac OS X 」

    http://developer.apple.com/technicalqas/index-rev-date.html

    【サンプルソースコード】

    前回から3月10日期間中、Apple社のSample Codeサイトには、新しいサンプルソースコードが2つ登録されました。どちらも新作ですが、「QTSetMovieAudioDevice」の方は「QuickTime 7 for Windows」用ですので御注意ください。

    「QTSetMovieAudioDevice」(QuickTime関連)
    「iTunes Controller」( Carbon関連)

    http://developer.apple.com/samplecode/index-rev-date.html

    【デベロップメント SDK】

    前回から3月10日の期間中、Apple社のSDKサイトには新しいSDKがひとつも登録されませんでした。

    http://developer.apple.com/sdk/

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

    MOSA Developer News   略称[MOSADeN=モサ伝]
    Apple、Mac OSは米国アップルコンピュータ社の登録商標です。またそのほかの各製品名等はそれぞれ各社の商標ならびに登録商標です。
    このメールの再配信、および掲載された記事の無断転載を禁じます。
    特定非営利活動法人MOSA
    Copyright (C)2006 MOSA. All rights reserved.

  • MOSA Developer News[MOSADeN=モサ伝]第196号

    2006-03-07

    目次

    • 「WebObjects Dev Report」     第42回  田畑 英和
    • 小池邦人の「Carbon API 徒然草」
    • SqueakではじめるSmalltalk入門  第57回  鷲見 正人
    • ニュース・解説               木下 誠

    「WebObjects Dev Report」  第42回  田畑 英和

     2/18にApple Store Shinsaibashiで開催されたKansai Developer’s Nightには多くの方々にご参加いただきありがとうございました。きっと2回目も開催されるかと思いますので、今回参加できなかった方もぜひ次回はご参加いただければと思います。

    ◇アダプターのUniversal Binary対応
     さて、今回からは数回にわたってWebObjectsアプリケーションの運用について解説していきたいと思います。まずは実行環境から確認しておきます。すでにIntel Macの出荷が始まっており、入手済の方もいらっしゃるかと思いますが、WebObjectsはJavaでプログラミングをおこない、Javaプログラムであれば基本的にはPower PCのMacでもIntelのMacでも動作します。
     しかし、WebObjectsの実行環境には一部C言語で実装されたプログラムがあります。WebサーバとWebObjectsアプリケーションを連携する「アダプター」と呼ばれるプログラムがそれなのですが、この「アダプター」がUniversal対応しているかどうかを確認してみました。なお「アダプター」にはApache用のアダプターとCGI用のアダプターの2種類がありますので、両方とも確認を行ったところ以下のようになりました。

    ・Apache用アダプター
    % pwd
    /System/Library/WebObjects/Adaptors/Apache
    % file mod_WebObjects.so
    mod_WebObjects.so: Mach-O fat file with 2 architectures
    mod_WebObjects.so (for architecture i386): Mach-O bundle i386
    mod_WebObjects.so (for architecture ppc): Mach-O bundle ppc

    ・CGI用アダプター
    % pwd
    /Volumes/Tiger/System/Library/WebObjects/Adaptors/CGI
    % file WebObjects
    WebObjects: Mach-O fat file with 2 architectures
    WebObjects (for architecture i386): Mach-O executable i386
    WebObjects (for architecture ppc): Mach-O executable ppc

     このように両方とも2つのアーキテクチャをサポートしていることが分かります。ただし、現状ではまだMac OS X ServerをサポートしたIntel Macがないために、Mac OS X Serverで運用を行うにはPower PCベースのMacが必要になります。なお今回は、Tiger上にXcode2.2をインストールした環境で確認を行っています。

    ◇wotaskd
     次にWebObjectsの運用環境を構成するファイルやディレクトリの確認を行っておきましょう。Tiger Serverを前提として話を進めますが、Tiger Serverではデーモンプログラムの起動の仕組みが変更になっています。WebObjectsの運用環境ではwotaskdというデーモンが動作していますが、このwotaskdをシステム起動時に起動するには以下のplistファイルを用います。

    ・wotaskdのplist
    /System/Library/LaunchDaemons/com.apple.wotaskd.plist

     このplistファイルの内容に基づいてlaunchdがwotaskdを起動します。システム起動時にwotskdを起動するかどうかは、このplistファイルを直接編集しなくても、「サーバ管理」というMac OSX Server用の管理ツールから設定することができます。
     といいましても設定が必要なパラメータといえばwotaskdが使用するポート番号程度で、あとはサービス開始ボタンをクリックするだけでwotaskdが起動するようになります。
     wotaskdはXML形式の設定ファイル”SiteConfig.xml”を必要とし、このファイルは次のパスに保存されます。

    ・wotaskdの設定ファイルのパス
    /Library/WebObjects/Configuration/SiteConfig.xml

     wotaskdはappserverユーザ権限で動作するため、appserverユーザに対して/Library/WebObjects/Configuration/へのアクセス権が与えられている必要があります。もし適切なアクセス権が設定されていないとwotaskdは起動に失敗します。また、wotaskdは次のパスにインストールされています。

    ・wotaskdのパス
    /System/Library/WebObjects/JavaApplications/wotaskd.woa

    ◇Web Server Resources
     WebObjectsではアプリケーションをインストールするときに、画像ファイルなどのWeb Server ResourcesをWebサーバ上に直接配置し、それ以外のJavaプログラムなどのファイルを別の場所に配置するSplit Installを行います。
     アプリケーションとフレームワークでインストール先が若干異なりますがそれぞれ以下のパスにWeb Server Resourcesをインストールします。

    ・アプリケーションのWeb Server Resourcesのパス
    /Library/WebServer/Documents/WebObjects/
    ・フレームワークのWeb Server Resourcesのパス
    /Library/WebServer/Documents/WebObjects/Frameworks

     ちなみにアプリケーションのインストール先ですが、任意のパスにインストールすることもできますが、次のパスにインストールするのが一般的です。

    ・アプリケーションのインストール先
    /Library/WebObjects/Applications

    ◇フレームワーク
     アプリケーションを開発するさいに、オープンソースのフレームワークを使用する場合もあるでしょうし、独自に開発したフレームワークを使用するような場合もあるでしょう。フレームワークは通常次のパスにインストールします。

    ・フレームワークのインストール先
    /Library/Frameworks/

    ◇Monitor
     WebObjectsには運用環境の設定をおこなうWebアプリケーション「Monitor」が付属しています。「サーバ管理」を使ってシステム起動時に「Monitor」を自動起動することもできますが、必要に応じて手動で起動することもできます。
     Monitorを手動で起動するときは、以下のパスにある「Monitor」の起動スクリプトを実行します。

    ・Monitorの起動スクリプト
    /System/Library/WebObjects/JavaApplications/JavaMonitor.woa/Monitor

     というわけで、今回はWebObjectsの運用環境について解説してきました。次回はアプリケーションのインストールなどについて解説する予定です。

    小池邦人のCarbon API 徒然草(2006/03/03)

    〜 アプリケーションのUniversal Binary化(その4) 〜

    今回は、PowerPC用のソースコードをUniversal Binary化する時に注意すべき点をピックアップしてみます。最大の関門は、 PowerPCとx86 CPUのエンディアンの違いを克服することですが、それ以外にも色々な要因が存在します。

    エンディアンの問題を含め、Universal Binary化でのソースコードの書き換えは、ほとんどがPowerPCとx86 CPUのアーキテクチャの違いにより生じます。以下に対象となるCPUアーキテクチャの違いをピックアップしてみました。

    1.エンディアンの違い(PPCはビッグエンディアンでx86はリトルエンディアン)

    2.AltiVecユニットの有無の問題(x86 CPUではSSE/SSE2に切り換える必要あり)

    3.ゼロで割ったときの処理が異なる(PowerPCは結果がゼロでx86はクラッシュする)

    4.変数アレンジメント(PowerPCは4Byteや16Byteだがx86は1から10Byteの可変)

    5.構造体とUnionのアレンジメントに違いがある

    6.整数演算オーバーフロー時の代入値の違い(PowerPCは0x7fffffff、x86は0×80000000)

    7.データ長の違い(x86はlong doubleが80Bits、boolはx86が1ByteでPowerPCは4Byte)

    8.浮動小数点の比較に違いが生じる時がある(オーバーフローなどの扱い)

    9.関数の呼び出し時の引数(引数の積み方x86ではスタックへPowerPCではレジスタへ)

    10.ビットフィールドの扱いが異なる(これはコンパイラの仕様にもよる)

    これら以外にもまだ幾つか存在しているかもしれませんが、ソースコードに影響が出ると考えられる要因についてはこれぐらいでしょう。一番影響が大きいのは1番ですが、画像処理の高速化などにAltiVecコードをバリバリ用いているソースコードでは、2番も大きな問題となります。逆に、AltiVecをまったく利用していなければ、2番に関しては何も気にする必要はありません。3番に関してはあってはいけないミスです。通常は、事前にゼロで割ることは避けるように処理されているべきで、そうでないと、x86 CPUはクラッシュします。どちらかと言うと潜在的に存在していたバグだと考えて対処すべきでしょう。

    4番と5番も大きな問題ですが、68K CPUからPowerPCへソースコードを移植した経験のあるデベロッパは、すでに対策済みのソースコードを用いているはずですので、それほど心配はないでしょう。今のところ、筆者もこの2つの要因にひっかかりソースコードに手を入れたことはありません。数多くのアプリケーションをUniversal Binary化してきた経験上、それ以外の要因については、通常あまり気にする必要はなさそうです。ただし、今回の話は、あくまでも筆者のソースコードの「書き方」に限定されますので、各人それぞれ注意を怠らないようにしていただきたいと思います。

    上記の要因に対処していないと、いかなる結果が起こるのか予想してみましょう。まず1番のエンディアンの違いが無視されていると…クラッシュする、計算結果が異なる、画像のカラー表示が異常、Unicode(複数バイト文字)テキストが正しく表示できない、バイナリファイルが正しく読み書きできない、ネットワークによるデータのコミュニケーションが正しく行われない、などなど数多くのトラブルが生じます。AltiVecコードを利用していれば、x86用コンパイル時にエラーが表示されます。また、それ以外の要因を無視した結果としては、分岐処理の異常やクラッシュなどが考えられます。

    こうして調べてみると、やはり「エンディアンの違いの克服」を達成すれば、Universal Binary化の仕事は90%完了することが理解できると思います。ただし、ソースコードに一カ所でも対処し忘れの箇所が存在すると、それが大きなバグとして残りますので、細心の注意をはらい対応箇所を探し出す必要があります。特に画像関連のアプリケーションをUniversal Binary化していると感じるのですが、このエンディアンへの対処、本当にひとつひとつ「つぶす」という表現がピッタリと当てはまる根気のいる作業です。

    次に、もうほとんどの皆さんは理解されていると思いますが、復習として「エンディアンの違いとは何か?」を簡単におさらいしておきます。PowerPCの場合には2Byte、4Byte、8Byteの数値は、そのバイト順にメモリに格納されますがx86の場合には逆順に格納されています。この数値のメモリへの格納方法の違いがエンディアンの違いを示し、バイト順通りに格納される方をビッグエンディアンと呼び、逆順で格納される方をリトルエンディアンと呼びます。

        unsigned long       value;
        unsigned char       *cptr;
        unsigned char       cc;
    
        value=0x12345678;
        cptr=(unsigned char *)&value;
        cc=*cptr;
    
    


    上記ソースコードでは、valueというunsigned long(4Byte)に16進の0×12345678を代入しています。そして、valueの先頭アドレスをキャストを使いポインタのcptrに代入し、その先頭アドレス1Byteのみをunsigned charのccに代入しています。処理後、何らかの方法でccの内容を表示してみると、PowerPC(ビックエンディアン)では0×12と表示されますが、x86(リトルエンディアン)では0×78と表示されます。この表示結果から、x86ではunsigned longの数値の最終バイトから順にメモリに格納されていることが良く分かります。ちなみに…

    cc=*(cptr+1);

    とすると、PowerPCでは0×34と表示され、x86では0×56という表示結果になります。

    ところで、ビッグエンディアン、リトルエンディアンと言う呼び名の由来はどこから来たのでしょうか? どうも、ガリバー旅行記に登場するとある王国が、卵をとんがった(小さい)方から食べる派閥と、膨らんだ(大きい)方から食べる派閥に分裂していたという逸話が発端のようです(笑)。
    何故ガリバー旅行記から引用されたかは謎なのですが、そんな面白い由来も「Universal Binary Programming Guidelines」で紹介されています。

    次回は、PowerPCとx86 CPUのエンディアンの違いによる影響を、サンプルアプリケーションのソースコードを調べながら検証していきたいと思います。数値のバイト順がひっくり返りメモリに格納されるという摩訶不思議な体験(まあそう思うのは純正マックデベロッパだけですが…)をしてみたいと思います。

    つづく

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

     本連載では、名前は知っていてもなかなか触れる機会のないSmalltalkについて、最近話題のSqueakシステムを使って紹介しています。前回はサブモーフやサブモーフ化という仕組みを取り上げました。そこで、このサブモーフ化という仕組みをふまえて、いま一度、ポップアップメニューやウインドウがどのような構成になっているかを調べてみましょう。まずはポップアップメニューから。

    ポップアップメニュー(メニューモーフ)は、たとえば、次のようなスクリプトで簡単に記述することができます。

    | menu |
    menu := MenuMorph new.
    menu defaultTarget: 1.
    menu add: 'default (one)' action: #inspect.
    menu addLine.
    menu add: 'two'   target: 2 selector: #inspect.
    menu add: 'three' target: 3 selector: #inspect.
    menu add: 'four'  target: 4 selector: #inspect.
    menu addLine.
    menu
       add: 'open workspace'
       target: Workspace
       selector: #openLabel:
       argument: 'My New Workspace'.
    menu invokeModal
    


     このスクリプト全体を選択しdo it(cmd + D)すると、その場に次の図に示すようなメニューが現れます。

    [fig.A]スクリプトで作られたポップアップメニュー
    http://squab.no-ip.com:8080/mosaren/uploads/57a.png

     もちろん格好だけではなく、メニューとしてきちんと機能します。「default (one)」を選択すると「1」のインスペクタが、「two」「three」「four」ではそれぞれ「2」「3」「4」のインスペクタが表示されます。最後の「open workspace」では「My New Workspace」というタイトルの付いた新しいワークスペースが現れます。

    ポップアップメニューのモーフとしての“姿”と“振る舞い”を確認できたところで、今度は先ほどのSmalltalkで記述されたスクリプトの中身を読み下してみましょう。

    このスクリプトでは最初で、テンポラリ変数「menu」にa MenuMorph(MenuMorphのインスタンス)を束縛しています。MenuMorphは、その名の示すとおり、メニューの役割を果たすモーフの属するクラスです。

    このmenu(に束縛されているa MenuMorph)にメニュー項目(a MenuItemMorph)や区切り線(a MenuLineMorph)をサブモーフ化することでメニューは構成されています。ですが、いちいちメニュー項目や区切り線の細かな仕様を決めてサブモーフ化するのは大変なので、#add:action:(あるいは、#add:target:selector:、#add:target:selector:argument:)や、#addLineという便利メソッドを起動するメッセージを最低限のパラメータを添えて送信することで、そのような面倒な“手続き”に代えています。

    たとえば、メッセージ「addMenu」で起動する「MenuMorph >> #addLine」メソッドの定義は、次のようになっています(スクリプト中の「addLine」部分を選択して、browse it(cmd + B)で呼び出せます)。

    MenuMorph >> addLine
       submorphs isEmpty ifTrue: [^ self].
       (self lastSubmorph isKindOf: MenuLineMorph)
          ifFalse: [self addMorphBack: MenuLineMorph new].
    


     ここで「submorph」は、すべてのモーフが持つインスタンス変数で、そのモーフに登録されたサブモーフたちを収めた配列を束縛しています。したがってこのメソッドには、「項目が何もないメニュー、あるいは、最後のサブモーフが区切り線の場合は手を付けず、それ以外なら、区切り線をサブモーフとして追加する」という内容が記述されていることを読み取ることができるでしょう。どうです(#addMorph:こそ起動していませんが)ちゃんとサブモーフ化の手続きがとられていますね。メソッド(#add:target:selector:argumentList:)をひとつ介しますが、メニュー項目(#add:action:)についてもしかりです。

    メニュー項目(a MenuItemMorph)を追加するメソッドはいくつかありますが、最低限、メニュー項目に付けるラベル(文字列)と、その項目を選択されたときに送るメッセージのセレクタ(シンボル)を引数として渡してあげる必要があります(#add:action:)。ターゲットを指定しない場合は、メニューが把握しているデフォルトのターゲットに指定したセレクタを含むメッセージが送信されます。デフォルトターゲットは初期状態ではnilですが、メニューに「defaultTaget: …」を送信することで変更可能です。

    今回作成したメニューでは、デフォルトターゲットに「1」を指定しています(defaultTarget: 1)ので、ターゲットを明示的にせずにサブモーフ化されたメニュー項目「default (one)」では、その選択時にメッセージ「inspect」が「1」に送信されます。結果、「1」のインスペクタが現れる…というカラクリです。実際のアプリケーションでは、このメニュー選択をトリガーにして行ないたい事柄を体現するメッセージを、それにふさわしいオブジェクト(ターゲット。たいていはアプリケーションのモデル)に送るよう指示しておけばよいことになります。

    ターゲットはメニュー項目ごとに変えることもできます。それが「two」から「four」までの例です。それぞれ、第二パラメータ(第二引数)に希望するターゲット(「2」か「3」か「4」)を添えて、#add:target:selector:というメソッドを起動するメッセージをmenuに送信しています。

    ターゲットに送信するメッセージにパラメータが必要な場合は、#add:target:selector:argument:を起動するメッセージを送ります。最後の「open workspace」がその例です。新しいワークスペースを開きたいときには、Workspaceに「openLabel: titleString」というメッセージを送るのですが、メッセージ「inspect」と異なり、この際、ウインドウタイトルを明示的にするためのパラメータ(例では’My New Workspace’)が必要になります。menuへのメッセージ送信時にはこれを第三パラメータとして添えています。さらに多く(2つ以上)のパラメータが必要なメソッドを起動したいとき向けには、「add: itemString target: targetObject selector: selector argumentList: argArray」というメッセージも用意されています。

    次回は、このメニューをモーフとしてバラバラに分解してみて、メニュー項目モーフの中身がスクリプトでの注文通りの仕様になっているのかを確認してみましょう。

    バックナンバー:
    http://squab.no-ip.com:8080/mosaren/

    二ュース・解説

    今週の解説担当:木下 誠

    ———————————————————————-
    Ruby on Railsの紹介
    ———————————————————————-

    Webアプリケーションのフレームワークとして、最近急速に注目を集めているのが、Ruby on Rails。Ruby をベースにしていて、高速なアプリケーション開発ができるのが特徴です。この Ruby on Rails を紹介するドキュメント「Using Ruby on Rails for Web Development on Mac OS X」が ADC で公開されました。

    もともと、Mac OS XにはRuby環境が標準で添付されているので、相性はいいはずです。その証拠に、このドキュメントの最後に参考文献として「Agile Web Development with Rails」という本が紹介されていますが、この本の図版はすべて Mac OS X上で動かしたものになっています。

    UNIXベースのため、このような新しい動きにすぐついていけるのが、Mac OS Xの大きな利点でしょう。しかし、こういう記事が ADC で紹介されると、「WebObjectsの立場は?」と突っ込んでみたくなりますが。

    Using Ruby on Rails for Web Development on Mac OS X
    http://developer.apple.com/tools/rubyonrails.html

    Agile Web Development with Rails
    http://pragmaticprogrammer.com/titles/rails/index.html

    ———————————————————————-
    USBソフト開発のQAが更新
    ———————————————————————-

    USBソフトの開発に関するQA「Common QA and Roadmap for USB Software Development on Mac OS X」が更新されました。UHCIのサポートに関する記述が追加されています。

    もともと、Mac OS XではOHCIとEHCIがサポートされていました。これが、Mac OS X 10.4になってから、UHCIのサポートが加わりました。今から考えると、これがIntel Mac登場の布石だったのかもしれません。Intel Macでは、UHCIとEHCIが使われています。

    QA1370: Common QA and Roadmap for USB Software Development on Mac OS X
    http://developer.apple.com/qa/qa2004/qa1370.html

    ———————————————————————-
    ホットキーに関するサンプル
    ———————————————————————-

    ホットキーを使ってiTunesをコントロールするサンプル、iTunesControllerが公開されました。

    iTunesのコントロールを行うことのできるソフトですが、主眼はホットキーの扱い方におかれています。ホットキーをコントロールするために、RegisterEventHotKey、UnregisterEventHotKey、CGPostKeyboardEvent、といったAPIを使用しています。iTunesのコントロールは、AppleScriptを使っています。

    iTunesController
    http://developer.apple.com/samplecode/iTunesController/iTunesController.html

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

    MOSA Developer News   略称[MOSADeN=モサ伝]
    Apple、Mac OSは米国アップルコンピュータ社の登録商標です。またそのほかの各製品名等はそれぞれ各社の商標ならびに登録商標です。
    このメールの再配信、および掲載された記事の無断転載を禁じます。
    特定非営利活動法人MOSA
    Copyright (C)2006 MOSA. All rights reserved.