MOSA Multi-OS Software Artists

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

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

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

MOSADenバックナンバー 2005年10月発行分

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

    2005-10-18

    目次

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

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

     この回が掲載される週にはいよいよMOSA湘南ミーティングが開催されます。今年も例年どおり初台のアップルコンピュータセミナールームに集合して、その後湘南国際村センターへの移動となります。私は数年前から毎年参加させていただいて、毎年懲りずに(笑)WebObjectsのセッションを担当しておりますが、今年もWebObjects関連のセッションを担当することになっています。
     今年はこの連載をとおして紹介していますビジネスマッチングシステムについて、システムのプロトタイプ版をもとにWebObjectsで開発するシステムの実体をご紹介したいと考えております。
     開発状況といたしましてはまだ細かなエラー処理などが作り込まれていない状態なのですが、これまでご紹介してきたEOFの継承を用いたモデルの作成ですとか、Reusable Componentを用いたコンポーネント作成など、WebObjectsならではのテクニックを実際に用いています。まもなくソースコード一式も公開できると思いますので、湘南ミーティングに参加されない方々にも実際にご覧になっていただくことができるかと思います。

     さて、今回は話題を少しかえましてサーバ構築についてお話しておきたいと思います。

    サーバのプラットフォーム

     まずは運用をおこなうプラットフォームですが、Mac OS X Serverを用意すればそこにWebObjectsの運用環境も含まれていますので、これがもっともお手軽な方法かと思います。以前のMac OS X ServerではWebObjectsの運用環境を別途インストールする必要がありましたが、10.3や10.4では最初からOSのインストールディスクにWebObjectsの運用環境も含まれていますので、特に意識することなくインストールをおこなうことができます。
     Mac OS X Serverですが、10クライアント版(52,000円)とUnlimitedクライアント版(98,000円)の2つが入手可能です。どちらを使えばよいかですが、10クライアント版での制限はファイル共有に関する制限になりますので、WebサーバやWebObjectsの運用環境として使用するにはいっさい制限がありません。ですので10クライアント版を利用するのがもっとも経済的です。実はWebObjectsのパッケージを購入するとちょうど10クライアント版とUnlimited版の間ぐらいの価格(76,440円)ですので、運用環境のみを準備するのであれば10クライアント版のMac OS X Serverがもっとも安価な方法となります。

    WebObjects

     現状のWebObjectsはどのバージョンを使えばよいのかがちょっと複雑です。まず最新版は5.3なのですが、まだ本格的にリリースされているとは言えない状態です。5.3の開発環境なのですが、WebObjectsの開発環境がXcode2.1からは標準で含まれるようになりました。つまりWebObjectsの開発環境を用意するために別途パッケージを購入する必要がないわけです。
     Xcode2.1/2.2はADC会員でないと入手できないという制約はあるのですが、それよりも完成度がまだ高くないため、これからWebObjectsを始める方がいきなり5.3から始めるのは危険かもしれません。1つ前のバージョンの5.2はまだパッケージ版が販売されていますので、有償にはなりますがこちらを使うという方法もあります。ちなみに5.2を用いる場合はPantherでは5.2.3が最新版となり、Tiger上で利用するには5.2.4にUpdateする必要があります。

    サーバ機

     サーバのハードウェアをどうするかですが、Mac OS X Serverを使うのであれば必然的にMacということになります。サーバ機として使うにはやはりサーバ向けのXserveの利用を検討してみましょう。XserveであればMac OS X Serverもバンドル(モデルによって10クライアント版かUnlimited版かは異なります)されていますので、別途OSを購入する手間が省けます。
     Xserveの価格はAppleStore(Online)の標準構成で、346,290円からとなっており、Mac OS X Serverの価格分を考慮したとしてもPower Macを購入するよりは割高になってしまいますが、1Uの筐体ですのでラックに収納する場合には最適です。ただし逆にラックがないような環境で利用する場合には、くれぐれも設置にご注意ください。

     というわけでお勧めの環境としてはXserve + Mac OS X Serverということになります。総合的に考えるとこの組み合わせがもっともお手軽ではないでしょうか。それでは湘南ミーティングでお会いしましょう。

    小池邦人のCarbon API 徒然草(2005/10/14)

    画像ファイルをウィンドウに表示する(その3)

    今回は、openViwerWindow()で実行されているcreateMyWindow()ルーチンの解説が中心となります。ウィンドウ作成に必要な様々な情報をcreateMyWindow()に渡すことで、nibファイル経由でなくともウィンドウを作成することができます。

    以下が、実際に画像表示用ウィンドウを作成しているcreateMyWindow()ルーチンです。

    short createMyWindow( Str255 title,OSType wid,WindowClass wcls,
                       WindowAttributes watt,Rect *brt,FSSpec *fsc,WindowRef *wptr )
    {
        short    ret=1;
        Rect     wrt;
    
        setupMyWindowBounds( wid,brt,&wrt );             // ウィンドウの表示枠を得る
        if( ! CreateNewWindow( wcls,watt,&wrt,wptr ) )   // ウィンドウの作成
        {
            SetWindowIdealUserState( *wptr,&wrt );       // UserState矩形枠をセット
            if( ret=setupMyWindow( *wptr,title,wid,fsc ) ) // プロパティのセット
                DisposeWindow( *wptr ); // エラーであれば削除する
        }
        return( ret );
    
    }
    


    最初の引数はウィンドウタイトルで、ここには画像ファイルの名称が渡されます。続いてウィンドウの識別子としてOSTypeの’VIEW’を渡します。画像ウィンドウのWindowClassはドキュメントウィンドウです。WindowAttributesには、標準アトリビュートに、「ライブリサイズ利用」「スタンダードハンドラ利用」「コンポジティングモード利用」の3つのアトリビュートが追加されて渡されます。WindowClassとWindowAttributesの具体的な設定は、以下の通りです。

      wcls=kDocumentWindowClass;
      watt=kWindowStandardDocumentAttributes|kWindowLiveResizeAttribute|
           kWindowStandardHandlerAttribute|kWindowCompositingAttribute;
    


    次のRectには、imageFileToImage()で得た画像データの矩形枠が代入されます。これにより、ウィンドウ表示時の初期サイズ(幅と高さと位置)が決定されます。次のFSSpecには、表示するる画像ファイルの保存場所が渡されます。この情報は、タイトルバーに表示されるプロキシアイコンの作成に利用されます。そして、ウィンドウが問題なく作成されると、ルーチンは最後の引数にそのWindowRefを返してきます。

    最初に実行されているsetupMyWindowBounds()ルーチンは、画像データの矩形枠から実際のウィンドウサイズを計算しています。ウィンドウの初期サイズをメインモニター内に収めるように調整し、複数ウィンドウをオープンした場合には、見やすくするために、その表示位置を前より少しずらします。今回は、一度のオープンで16ピクセルずらし、5度目のオープンで最初の位置に戻るように処理されています。こうして得られたウィンドウの初期サイズと表示位置は、SetWindowIdealUserState()に渡され、ズーム処理のディフォルト矩形枠(UserState)として利用されます。

    void setupMyWindowBounds( OSType wid,Rect *brt,Rect *wrt )
    {
        static long    w2_ct=0; // オフセット位置を決めるためのstatic変数
        Rect           grt;
        short          dd;
    
        dd=(w2_ct++%5)*16; // XY方向へ16ピクセルずらすためのオフセット値の計算
        switch( wid )
        {
            case 'VIEW': // 画像表示用ウィンドウの識別子
    
                *wrt=*brt;
                wrt->right+=15;              // 縦スクロールバーの幅だけ拡大
                wrt->bottom+=15;             // 横スクロールバーの幅だけ拡大
                OffsetRect( wrt,16+dd,48+dd );        // モニター原点より移動
                GetRegionBounds( GetGrayRgn(),&grt ); // モニター矩形枠を得る
                InsetRect( &grt,16,16 );              // 上下左右16ピクセル縮小
                SectRect( wrt,&grt,wrt );  // モニター枠内に収まるように縮小
                break;
    
            default:
    
                *wrt=*brt;
                break;
        }
    }
    


    次に呼ばれているsetupMyWindow()ルーチンでは、ウィンドウのプライベートな初期化を行います。nibファイルからメインウィンドウ(CatalogWindow)を作成する時にも説明しましたが、この処理では、ウィンドウに必要なプライベートなメモリ領域(WInfo構造体)をウィンドウのプロパティとして登録し、WindowRef経由でいつでも参照できるようにします。
    SetWindowProxyFSSpec()は、ウィンドウタイトルの左側にドキュメントのプロキシアイコンを表示します。実際のプロパティ登録では、WInfo構造体はシステム内部の格納場所に「複製」されますので、自分自身で確保しておいたポインタ(iptr)は不要となります。最後にDisposePtr()で解放することを忘れないでください。

    short setupMyWindow( WindowRef window,Str255 title,OSType wid,FSSpec *fsc )
    {
        short       ret=1;
        WInfoPtr    iptr;
    
        if( iptr=(WInfoPtr)NewPtrClear( sizeof( WInfo ) ) ) // WInfo造体用メモリ確保
        {
            SetWTitle( window,title );     // ウィンドウのタイトルを設定
            SetWRefCon( window,wid );       // ウィンドウの識別子を設定
            if( fsc )
                SetWindowProxyFSSpec( window,fsc ); //ファイル保存場所を格納
            SetWindowModified( window,0 );  // 未編集ウィンドウの印を付ける
            ret=setWInfo( window,iptr );    // WInfo構造体をプロパティとして保存
            DisposePtr( (Ptr)iptr );        // WInfo造体用に確保したメモリを解放
        }
        return( ret );
    }
    


    WInfo構造体はsetWInfo()ルーチンでウィンドウ自体に添付します。この時に利用するのが、Window ManagerのSetWindowProperty() APIです。また、指定ウィンドウのWInfo構造体を得るのには、getWInfo()ルーチンを用います。こちらは、GetWindowProperty() APIを利用します。

    #define    MY_SIG    'MosA'    // アプリケーションのシグネイチャを代用
    #define    MY_DOC    'MosD'    // ドキュメントのファイルタイプを代用
    
    short setWInfo( WindowRef window,WInfoPtr woptr )
    {
        short    ret=1;
    
        if( IsValidWindowPtr( window ) ) // WindowRefが正常ならプロパティをセット
            ret=SetWindowProperty( window,MY_SIG,MY_TAG,sizeof( WInfo ),woptr );
        return( ret );
    }
    
    short getWInfo( WindowRef window,WInfoPtr woptr )
    {
        short    ret=1;
    
        if( IsValidWindowPtr( window ) ) // WindowRefが正常ならプロパティを得る
           ret=GetWindowProperty( window,MY_SIG,MY_TAG,sizeof( WInfo ),NULL,woptr );
        return( ret );
    }
    


    最後に、WInfo構造体のw_prefに親ウィンドウのWindowRefを代入するsetWParent()ルーチンを紹介しておきます。画像表示ウィンドウでは、WInfo構造体のメンバーのうち、このw_prefしか利用しません。

    short setWParent( WindowRef window,WindowRef wptr )
    {
        WInfo    winf;
    
        if( ! getWInfo( window,&winf ) ) // WInfo構造体をプロパティから読み込む
        {
            winf.w_pref=wptr;            // 親ウィンドウのWindowRefをセットする
            setWInfo( window,&winf );    // WInfo構造体をプロパティとして保存
            return( noErr );
        }
        return( 1 );
    }
    


    次回は、setupViwerWindow()ルーチンとsetupViwerWindowEvent()ルーチンを解説したいと思います。この両ルーチンでの処理内容が、Mac OS Xのバージョンによって大きく変わることも紹介いたします。

    つづく

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

     本連載では、名前は知っていてもなかなか触れる機会のないSmalltalkについて、最近話題のSqueakシステムを使って紹介しています。今回は、手を加えたメソッドのバージョン履歴などを蓄積するのに使われる「チェンジファイル」を取りあげます。

    ▼バージョン管理の復習
     Smalltalkシステムでは、すでに定義済みのメソッドにブラウザ上で修正を加えてコンパイル(accept。cmd-S)すると、バージョン情報が更新され、あとからその履歴を「バージョンブラウザ」で一覧したり、任意のバージョンの内容を、ひとつ前のバージョンとの差分情報(追加は赤文字、削除は青字の取消線)と併せて閲覧できます。

    [fig.A]バージョンブラウザの起動
    http://squab.no-ip.com:8080/mosaren/uploads/49a.png

    [fig.B]バージョンブラウザ
    http://squab.no-ip.com:8080/mosaren/uploads/49b.png

     バージョン情報には、メソッドのソースコードの他に、改変を行なったユーザーのイニシャル(…に限らず、短めのニックネームなど。Utilities setAuthorInitialsで確認および変更可)と、いつ改変が行なわれたのかといった情報も含まれます。また、「revert」ボタンで、指定したバージョンに巻き戻すことも可能です。

     さて、このバージョン情報。いったい、どこにどのようにして管理されているのでしょうか。

    ▼システム改変のログ「チェンジファイル」
     Smalltalkシステムには、クラスやメソッドの新規、あるいは、再定義の際に、そのとき使われたソースコードおよび付随情報を自動的に記録していく機構があります。このチェンジ管理機構がシステム改変情報を書き出すのに使われるのが「チェンジファイル」(.changes)と呼ばれるテキストファイルです。すでにご存じのように、このチェンジファイルは、同名の仮想イメージファイル(.image)と常にペアで用いるよう定められているものです。

     オブジェクトメモリ(Smalltalkシステムでオブジェクトを管理したり機能させるための仮想デバイス)の内容をダンプした仮想イメージファイルと異なり、チェンジファイルは、少し大きめ(十数メガバイト程度)のファイルを開く能力を持つテキストエディタを使えば、その中身を容易に確認できます。チェンジファイルの最後のほうを見ると、見覚えのある作業が記録されているはずです。(なお、実際にテキストエディタで開いて見るときは、内容を書き換えて保存してしまわないように注意してください。)

     冒頭のメソッドのバージョン管理には、じつは、このシステム改変履歴から注目するメソッドに関連する情報を抜き出して再構成したものが使われています。

    ▼チェンジファイルのブラウザ(Recent changes)
     わざわざ“外の世界”のテキストエディタのようなソフトに頼らなくてもよいように、Smalltalkシステムの中からこのチェンジファイルの中身を閲覧する手段も、当然ですが、もちろん用意されています。

     デスクトップメニューの「変更…」(英語メニューではchanges…)を選んだときに現われるサブメニューから「最近記録された変更…」(英語メニューでは「recently logged changes…」)を選びます。項目の選択と同時にポップアップが現われますが、これには、システムの保存もしくは終了(Squeak VMの強制終了ではなくて、デスクトップメニューなどから終了操作による終了)操作の履歴が列挙されます。

    [fig.C]システムの保存および終了の履歴のポップアップ
    http://squab.no-ip.com:8080/mosaren/uploads/49c.png

     ポップアップから適当な項目を選ぶと、対応するピリオド間(Squeakシステムが動作している間)に記録されたログが解析され、それらをリストにして上のリストペインに表示します。リストには、クラス、メソッドへのすべての改変と履歴に加えて、do it(あるいはprint it)されたコードなども含まれます。リストの項目をクリックすると、下のペインに詳細が表示されます。

    [fig.D]Recent changesブラウザ
    http://squab.no-ip.com:8080/mosaren/uploads/49d.png

     なお、ごくまれにログ解析を失敗することもあるので、そうした事態に備え、「最近のログファイル…」(英語メニューでは「recent log file…」)というメニュー項目も用意されています。これは、ピリオドを選択するためのポップアップが現われるところまでは「最近記録された変更…」と同じですが、チェンジファイルの内容は解析されずに、生データ(ファイルアウトの形式)のままファイルリストに表示します。

    ▼Recent chagnesの活用 — 強制終了時のリカバリ
     新しいクラスやメソッドをシステムに追加しながら開発を行なっているとき、それらの動作テスト中にシステムが異常終了してしまうことは、Smalltalkシステムでのプログラミングに限らずとも、よくあることです。言うまでもなく動作テストを行なう前には、仮想イメージを保存するか、すでに定義済みのクラスやメソッドをファイルアウトして不測の事態に備えておくべきです。が、必要なときに限って、うっかりして大切なバックアップを怠ってしまっていることも、これまた、よくあることです。

     そんなとき、逐次、チェンジファイルに自動的に蓄積されているクラスやメソッドの改変履歴は大いに役立ちます。万一、トラブルが発生してシステムの強制終了を余儀なくされても、それまでの作業のほとんどすべてを、Recent changesを使うことで取り戻すことができるからです(取り戻したい定義を選択して上のリストペインの黄ボタンメニューから「fileIn selections」)。なお、こうしたリカバリ作業をするときに目障りなdo itコードや古いバージョンの履歴は、あらかじめ作業履歴リストから排除可能です。

    [fig.E]do itコードや古いバージョンのリストからの排除
    http://squab.no-ip.com:8080/mosaren/uploads/49e.png

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

    ニュース・解説

    今週の解説担当:木下 誠

    ———————————————————————-
    Xcodeのプロジェクトを紹介するドキュメント
    ———————————————————————-

    Xcodeのプロジェクトの設定方法を紹介したドキュメント、「Understanding Xcode Projects」が公開されています。Xcodeの機能のうち、特にプロジェクトやターゲットに焦点をあてて、紹介されています。

    Xcodeは、正直なところ、パッと見ただけではあまり機能が充実していないように思いますが、実はビルドの設定等はかなり充実してきています。gccに対するコンパイルオプションの設定とその切り替え、ビルドのフェーズ毎でのファイルのコピー、指定したスクリプトの実行、ターゲット間やプロジェクト間での依存関係の設定、等、必要な機能は一通り出そろってきています。

    ただ、インタフェースが分かりづらく、マニュアルを熟読しないと発見できないのが残念です。この辺りのアクセスしやすさに、改善が欲しいところです。

    Understanding Xcode Projects
    http://developer.apple.com/tools/xcode/xcodeprojects.html

    ———————————————————————-
    .Mac SDK 1.2が公開
    ———————————————————————-

    .Mac SDKが、1.2にバージョンアップしています。Universal Binaryへの対応が行われました。.Mac SDKを使うと、アプリケーションから.Macへの接続や、.Mac上のファイル操作等が行えます。

    7月に.Mac SDK 2.0のDeveloper Previewが公開されていますが、こちらはまだアップデートされていないようです。

    .Mac 1.2 SDK
    http://developer.apple.com/sdk/

    ———————————————————————-
    Windows + Visual BasicのQuickTimサンプル
    ———————————————————————-

    QuickTime 7を利用した、ムービーを再生するサンプルが公開されています。こちらは、珍しく、Windows 2000とVisual Basicを使ったサンプルになっています。

    Windows用のQuickTimeは、COMでラップされているので、Interface Builder +Cocoa並みの手軽さで扱うことができます。ただ、用意されている機能以上のことをやろうとすると、とたんに大変になるのですが。

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

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

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

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

    2005-10-11

    目次

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

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

    Reusable Componentの最適化

     さて今回はReusable Componentの続きです。前回はコンポーネントのインスタンスを共有化する次のメソッドを紹介しました。このメソッドを実装したコンポーネントは1度しかインスタンス化されず、アプリケーション内で共有されるため、メモリの消費量を抑えることができます。

         public boolean isStateless() {
             return true;
         }
    


     Reusable Componentを最適化する方法としては次のようなコーディングも有
    効です。

         public boolean synchronizesVariablesWithBindings() {
             return false;
         }
    


     Reusable Componentは、Dynamic Elementのように親コンポーネントから値をバインドすることができ、デフォルトの状態ではバインドしたデータのコンポーネント間でのやりとりは自動的に行われます。
     つまりコンポーネント間でのデータの同期が自動的におこなわれるわけで、もちろん自動的にデータをやりとりさせておけば、コーディングをおこなう必要もないので便利なのですが、上記のコードを追加することによりこの自動同期を停止することができます。この場合、データの同期をおこなう処理をコーディングしなければならないのですが、自動でデータの同期をおこなう場合に発生するオーバーヘッドを抑えるとともに、コンポーネント間でのデータのやりとりを完全にコントロールできるようになります。
     自動同期を停止することにより、必要に応じて親コンポーネントからデータを取得したり、親コンポーネントにデータをセットしたりすることができます。具体的にはReusable Componentにおいて次のようなコーディングをおこないます。

         public String value() {
             return (String)valueForBinding("value");
         }
    
         public void setValue(String value) {
              setValueForBinding(value, "value");
         }
    


     ここでは”value”というAttributeに対してバインドをおこなっているとします。value()が実行された場合は、親コンポーネントで”value”にバインドしてあった値を取得してreturnします。setValue()が呼び出された場合は、引数の値を親コンポーネントにセットします。これで親コンポーネントとのデータのやりとりが自由にできるようになります。
     データの入力をともなわないReusable Componentの場合は、getterメソッドだけを実装しておけばよいですし、データ入力をともなう場合はさらにsetterメソッドも追加しておく必要があります。

     あとはReusable Compopentを新規作成するたびにisStatless()とsynch…()を追加すればよいのですが、毎回追加するというのも手間がかかりますので、あらかじめこれら2つのメソッドを実装したクラスを作成(WOCompoentを継承)しておき、あとはそのクラスを継承して各Reusable Componentを作成すれば手間を省くことができます。

    Reusable Componentのネスト

     Reusable Componentを別のReusable Componentに組み込んで使用することもできます。つまりコンポーネントのネストができるわけですが、ネストすることによりさらにコンポーネントを細分化していくことができます。
     たとえばタブをもったメニューがあり、複数の画面で使用されているとしましょう。このときまず各画面で共通しているタブメニューの部分だけを1つのコンポーネントとして実装し、各画面から共有することができます。
     タブメニューは、タブが繰り返し表示されて並ぶインターフェイスになっています。このとき各タブは異なる画像を使用したり、タブをクリックしたときに呼び出すactionメソッドはタブごとに異なっていたりしますが、タブごとに画像をもっているということと、actionメソッドを呼び出すということは共通しています。
     そこで汎用的なタブコンポーネントを作成し、実際に使用する画像やactionメソッドをバインドにより指定するようにすれば、タブを再利用することができます。このときコンポーネントの関係は次のようになります。

    ・コンポーネントの関係
     親コンポーネント > タブメニューコンポーネント > タブコンポーネント

     このようにまず各画面に共通している部分はコンポーネント化するということと、さらに繰り返し表示されるような部分もコンポーネント化してしまうというのがReusable Component作成のポイントになります。 
     慣れないうちはどのような単位でコンポーネントを切り出していったらよいか分からないかもしれませんが、ページのなかにあるパターンを見極めてコンポーネント化していきましょう。

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

     前回は、NSWindowの初期化メッセージ、

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


    の解説の途中、最後の flag について書いているところで時間が……ぢゃない紙数が尽きたんだった。この flag 、ウィンドウの描画に関わる命令の実行を、実際にウィンドウがスクリーンに持って来られるまで延期するどうかを指定するもんだった。
     これを延期できると何がいいのか。簡単に言うとアプリケーションの起動が速くなるのである。始めから終わりまで、煮ても焼いても(そんなことをするヒトはいないが)一個しかウィンドウを出さないプログラムもあるかも知れないが、普通のアプリというのはあーだこーだといろいろなウィンドウがあるもんだ。でしょ?
     その中には……例えば「そのアプリについて……」メニューで表示されるアバウトボックスみたいに、通常のセッション(一個のアプリが起動してから終了されるまで)では一度も表示されないことが多いモノもあるわけ。しかしながら、そういういわば出番のないウィンドウも、きっちり起動時に楽屋を用意されてメイクアップをして弁当も食ったりする、当然ながらその分CPUタイムも食う、と。
     この flag をオンにしてウィンドウを初期化しておけば、世に名高いトヨタのカンバン方式が実行されて、楽屋入りしてメイク……てな作業はいざ画面に出る直前に行なわれる。食ってる暇がないから弁当も出さなくて済む(笑)。その替わり当のウィンドウが開く時、ちょっとだけ時間がかかるけど、という……こういう話である。

     defer flagの話が長くなってしまったが本題に入る。覚えてますか、前回ワタシが提示した問題は、「そうは言うがこの初期化メッセージ、通常あんまり使わないよな」ということであった。それは何故でしょうと、実はこれが本題。……まぁ答えは簡単で、つまり普通のウィンドウは Interface Builderで定義できちゃうので、わざわざこのメッセージを使ってプログラム中で作る必要はないってことなんだけど、ではInterface Builderで定義できない「普通ぢゃないウィンドウ」って例えばドンなもんか、と話を進めたい。
     もしそうできる環境でこれを読んでいたら、是非 Interface Builderを起動し、新しいウィンドウを一個作ってみてほしい。上の初期化メッセージに渡される引数のうち、contentRect、bufferingType、そして最後の flag の内容はここで指定できることが分かるはずだ。contentRect は画面上のそのウィンドウの位置とサイズそのものだし、bufferingTypeは「window backing」という見出しに続くラジオボタンで指定できる。defer の flag に当たるのはその下に並んだチェックボックスのうちの「Deferred」というヤツだろう。……もうおわかりか、そう、aStyle だけが指定できない。いや、正確には以下の指定出来うるすべての値(前回も出したが)

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

    のうち、「NSBorderlessWindowMask」だけがどうあがいてもここでは設定できないのである。つまり、InterfaceBuilder ではタイトルバーのないウィンドウは作れないのだ。
     というワケで、次回はなんでタイトルバーのないウィンドウなんか作りたいのか小一時間……ぢゃなくて(笑)、タイトルバーのないウィンドウの作り方を解説しようと思う。ほんぢゃ。
    (2005_10_06)

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

    UNIXとしてのMac OS X

    〜Perlについて(22)〜

     こんにちは、高橋真人です。
     前回まででほぼ正規表現の記述に必要な要素に触れたので、今回から検索置換の「置換」つまり正規表現を使った文字の置き換えについて説明します。
     今までは正規表現の実例を出してもほとんどが、マッチした部分の消去か出力ということでした。しかしこれに「置き換え」という処理が加わると、途端に正規表現を使うメリットが広がってきます。
     正規表現を使った置換処理の場合、マッチした全体を単純な文字列に置き換えてもよい(例えば、改行コードの変換などといった処理はこれで行けます)のですが、パターン表現の中で丸カッコを使った「グルーピング」を施すことで、マッチ結果に応じた処理ができるようになるのです。
     まずは丸カッコを使ったグルーピングについて説明します。正規表現では多くのプログラミング言語と同様に結合の優先順位を変えるためにカッコを使うことができます。例として以下のような正規表現を見てください。

    /b|peach/

     bとpの間にある縦棒の演算子は、C言語でもおなじみのOR演算子で、この演算子を挟んでいる「どちらか」ということを表します。従ってこの正規表現はbeachとpeachにマッチし、/[pb]each/という正規表現と同等と言うことができます。
     では、これを応用してpeopleとappleという2つの単語の両方にマッチさせたい場合にはどう書けばよいでしょうか。

    /peo|apple/

     最初は、こういう書き方をしてしまう人が結構います。ですが、残念ながらこれでは意図した通りにはなりません。| 演算子の優先順位は直前と直後の文字にしか及ばないために、この場合「oかa」という意味になってしまうのです。よってこの正規表現がマッチするのは、peoppleとpeappleということになります。
     そこでカッコの登場です。結合の優先順位というのがピンと来ない人もいるかもしれませんから説明しますと、正規表現においては個々の文字(もしくは文字表現)が一つずつそれぞれに式の要素を形成していると考えます。従って、/cat/という正規表現を無理矢理C言語の式に置き換えると、以下のように表すことができます。

    char s[4] = "cat";
    if (s[0] == 'c' && s[1] == 'a' && s[2] == 't') {
         // マッチした
    }
    


     つまり、c、a、tという文字列の構成要素を一つずつ検証して、すべての条件が成立した場合(もちろん、それぞれが順序通りに連続して並んでいる必要があります)に、はじめてマッチしたということになるわけです。
     それでは/peo|apple/を無理矢理Cで表現してみます。

    if (s[0] == 'p' && s[1] == 'e' && (s[2] == 'o' || s[2] == 'a') && s[3] == 'p' && s[4] 
    == 'p' && s[5] == 'l' && s[6] == 'e') {
         // マッチした
    }

     こんな感じになります。このCの式に基づいて元の正規表現を「結合関係をより明確になるように」表記し直すと、/pe(o|a)pple/となります。こう書くと、意図通りになっていないことがより分かりやすいのではないでしょうか。
     さて、ここまで分かればもう簡単です。peopleとappleにマッチさせるためには、カッコを使って結合をコントロールしてやればいいのです。答えはこんな感じです。

    /(peo|ap)ple/

     これで、見事に正規表現が意図した通りに機能するようになります。

     このように、丸カッコを使うことで文字表現の結合関係をコントロールすることができることはお分かりいただけたと思いますが、実は正規表現の丸カッコにはもっと重要な役割があるのです。それは、上記のように丸カッコを使って囲った部分が特定の記憶領域に記憶されるという「副作用」です。次回はその中身を見ていきましょう。

    ニュース・解説

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

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

    【開発環境】

    長い間熱望されていたMOSA会員専用掲示板が開設されました。会員相互の交流、技術情報の交換に大いに役立つと思われますので、皆さんバリバリ活用しましょう! ひとつの質問スレッドが、多くのMOSA会員にとって大変有用な情報源になると思います。どんな簡単な内容でも気にする必要はないので、ぜひ数多くの質問を書き込んでください。現在はQ&Aを中心に、初心者向けと一般向けの2つの会議室が技術的な話題の中心ですが、将来的に利用頻度が増え、色々な技術分野の会議室(Webとか3Dとか)が増設されて行けば、より面白くなるでしょうね!

    なにせアップル社へひとつ質問をすると、その正式な回答を得るためにかなり高額な費用が発生します。また、その質問内容がバグに関係していると、アップル社から「逃げ道的」や「裏技的」な回答を得られるかどうかは定かではありません(笑)。MOSA掲示板には、現場の最前線で活躍されている数多くのMacデベロッパーの方々が参加されています。「バグは会議室で起こっているのではない!」ということで(笑)、MOSA掲示板からは、アップル社とはひと味もふた味も違った的確なアドバイスを期待できるのではないでしょうか!

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

    前回から10月7日の期間中、Apple社のDocumentationサイトには数多くのドキュメントが登録されました。ただし、大部分は内容のマイナーチェンジです。今回は、その中で初版と内容が大幅変更になったドキュメントだけをピックアップしておきます。Mac OS Xになってから行方不明になっていた「AGL Programming Guide」(Carbon用のOpenGL環境の解説)の新版が、やっとこさ登録されました、また、前回紹介した2つのリリースノートの改訂版が登録されましたので、関係者は内容をチェックしてみてください。デベロッパー向け読み物の方は2つ登録されました。「Taking Advantage of the Accelerate Framework」では、AltiVecコードを記述せずに画像処理などを高速にするのには、どのようなAccelerate Framework APIを利用したら良いのかを紹介しています。「Scoping Your Transition Projects」の方は、前号の木下さんの記事を参照してみてください。

    「AGL Programming Guide」(PDFあり)(初版)
    「Bonjour Overview」(PDFあり)
    「Deploying Mac OS X Server for High Performance Computing」(PDFあり)(初版)
    「DNSServiceDiscovery API Reference for C」(初版)
    「DNSServiceDiscovery Programming Guide」
    「FWAUserLib Reference」(初版)
    「Miscellaneous User Space API Reference」(初版)
    「NSNetServices and CFNetServices Programming Guide」(PDFあり)(初版)
    「Writing PCI Drivers」(PDFあり)
    「Xsan Tuning Guide」(PDFあり)(初版)

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

    リリースノート

    「J2SE 5.0 Release 1 for Mac OS X Release Notes」(マイナーチェンジ)
    「WebObjects 5.3 Release Notes」(マイナーチェンジ)

    http://developer.apple.com/releasenotes/

    「Taking Advantage of the Accelerate Framework」(読み物)

    http://developer.apple.com/performance/accelerateframework.html

    「Scoping Your Transition Projects」(読み物)

    http://developer.apple.com/transition/projectscope.html

    前回から10月7日の期間中、新規テクニカルノートはひとつだけ登録されました。また、新規テクニカルQ&Aの方は5つ登録されています。TN2143は、以前に登録された物の改訂版です。テクニカルQ&Aについては、QA1378のみが初登録となり、それ以外の物は内容が改訂(Mac OS X 10.4に対応するためなど)されて再登録されています。

    TN2143「Getting images in and out from Quartz Composer compositions」

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

    QA1037「CGBitmapContextCreate Supported Color Spaces」
    QA1396「Creating color spaces that ensure color matching.」
    QA1413「QuickTime for Windows returns bdNamErr (-37) error with long Windows file name」
    QA1378「StopAlert and NoteAlert now use the Application icon」(初版)
    QA1438「Using the QuickTime DVCompressor properties」

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

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

    前回から10月7日の期間中、Apple社のSample Codeサイトには、新しいサンプルソースコードが8つ登録されました。このうち初登録されたサンプルは、「DisplayURL」と「QTQuartzPlayer」と「tcplognke」の3つのみです。

    「AudioCDSample 」(Core Audio関連)
    「CocoaInCarbon」(Carbo&Cocoa関連)
    「ComboBoxPrefs」(Carbon関連)
    「DisplayURL」(Carbon関連)(初版)
    「filesystem_example」(Carbon関連)
    「HelpHook」(Java関連)
    「QTQuartzPlayer」(Cocoa&QuickTime関連)(初版)
    「tcplognke」(Divice関連)(初版)

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

    【デベロップメント SDK】

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

    http://developer.apple.com/tools/download/

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

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

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

    2005-10-04

    目次

    • 「WebObjects Dev Report」    第24回  田畑 英和
    • SqueakではじめるSmalltalk入門  第48回  鷲見 正人
    • ニュース・解説               木下 誠

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

     さて、前回までモデルファイルの作成方法を中心に話を進めてきましたが、今回は話題を変えてMVCのViewにあたる、画面表示について解説していきたいと思います。

    画面構成

     まずジョブマッチングシステムの画面構成ですが、現在のシステムを参考にしますと以下のようになります。

    ・画面一覧
     トップ画面
     [[閲覧系]]
      一覧画面
      PR画面
      詳細画面(スキルシート/タスクレベル)
     [[登録系]]
      ユーザ認証画面
      データ入力画面(Profile/Skill Sheet/Task Level/Careers/P.R.)
      登録実行画面

     これらはあくまでも現在の画面構成であり、システムをリニューアルするからには改良を加えていかなければ意味がありませんが、まずは現状の画面構成を土台にしていきます。

    Reusable Component

     WebObjectsでは画面をWeb Componentと呼ばれる単位で作成していきますが、かならずしも「1画面=1コンポーネント」というわけではありません。画面をReusable Componentと呼ばれる部品の組み合わせで構成することができ、この仕組みを積極的に利用することにより効率の良い開発が可能になります。
     例えば複数の画面で共通して使用するようなパーツ(ヘッダー、メニュー、フッターなど)をReusable Componentとして実装しておけば、同じものを毎回作成する必要がなくなります。また1カ所でしか使用しないパーツであっても、適度な範囲でReusable Component化しておくことにより、1つのコンポーネントが複雑になることを防ぐことができます。さらに共通したレイアウトをもった画面であれば、レイアウトそのものをReusable Componentとして実装し、各画面に共通したレイアウトを適用することもできます。

     とうわけで、今回列挙した画面は合計12画面ありますが、実際に作成するコンポーネントの数はそれ以上になります。具体的には全体的な画面構成のために次のようなReusable Componentを作成していきます。

    ・Reusable Component一覧
     -レイアウトコンポーネント
     -ヘッダーコンポーネント
     -フッターコンポーネント
     -メニューコンポーネント

    Reusable Componentの作成方法

     作成方法は基本的には通常のコンポーネントと同様です。WOComponentのサブクラスとして作成し、WebObjects Builderを用いてレイアウトやDynamic Elementの配置、バインドの設定をおこなうことができます。

     通常のコンポーネントとの違いとしてはまずHTMLの構造が上げられます。画面全体を1コンポーネントとして作成する場合と違い、画面内に組み込んで使用するReusable Componentは部分的なHTMLとして作成します。具体的にはといったページ内で1回しか使用されないタグを含めないようにします。これはWebObjects BuilderのInspectorから簡単に設定できます。
     次に、コンポーネント間でデータをやりとりできるようにします。これは必要ない場合もありますが、画面内にReusable Componentを組み込むとき、2つのコンポーネント間でデータをやりとりすることにより、より柔軟な使い方ができるようになります。
     例えばReusable Component上で表示するデータを親コンポーネントから与えたり、Reusable Component上で入力したデータを親コンポーネントにセットすることができます。WebObjects BuilderのAPI Editorを用いれば、Reusable Component上の任意のキー(変数)を親コンポーネントに公開することができ、WOStringやWOTextFieldのようなDynamic Elementと同様に、Inspectorから値をバインドできるようになります。

    Reusable Componentの応用

     Reusable Componentは使用した数だけインスタンス化されます。たとえば1つの画面内にReusable Componentを10個配置した場合、それが同一のコンポーネントであったとしても、インスタンスは配置した数だけ生成されます。それぞれのコンポーネントが固有の状態を管理する必要がある場合はこれでもよいのですが、例えば親コンポーネントから値を受け取ってそれを表示するだけのような場合は、Reusable Component側で状態を管理する必要がありません。
     つまり、1つのインスタンスだけを生成してそれを使い回すことができればメモリの消費量をおさえることができます。これを実現するためには、次のようなメソッドをReusable Componentのクラスファイルに追加します。

         public boolean isStateless() {
             return true;
         }

     このメソッドはWOComponentで提供されているメソッドですが、デフォルトではfalseを返すところを、オーバーライドしてtrueを返すことにより、そのコンポーネントのインスタンスは1つしか生成されずアプリケーション内での共有が可能になります。

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

     本連載では、名前は知っていてもなかなか触れる機会のないSmalltalkについて、最近話題のSqueakシステムを使って紹介しています。前回、Squeakシステムの“外の世界”にコードを持ち出すための「ファイルアウト」を取りあげましたが、今回はその逆の「ファイルイン」についてです。

     ファイルイン(file in)は、ファイルアウトを使ってシステムから“吐き出され”たクラスやメソッドの定義群を、読み込みながら次々とコンパイルして、システムに取り込んでゆく機構です。

    ▼ファイルアウトされたコードを、別のシステムでファイルインする
     前回、ファイルリストの文字化けを解消するために手を加えた「FileList >> #defaultEncoderFor:」メソッドの定義をファイルアウトしましたが、これを別のシステムにファイルインしてみましょう。ファイルインの結果を分かりやすくするために、いったん使用中のSqueakシステムを終了し、ダウンロードしたzipファイルから取り出したばかりの新しい仮想イメージファイルで起動しなおします。

     起動が完了したらファイルリストを開いてください(デスクトップメニュー→ 開く… → ファイル・リスト)。念のためここで、上段右手のリストペインから「ShiftJisExample.txt」をクリックして選択し、文字化けが起こることをあらかじめ確認しておくとよいでしょう。そして改めて、同じリストペインから「FileList-defaultEncoderFor.st」を探して選択します。もし探しているファイルが仮想イメージとは別のフォルダにあるのならば、上段左手のリストペインでそのフォルダを指定しなおしてから作業を行なってください。

     「FileList-defaultEncoderFor.st」を選択すると、拡張子「.st」から、その内容がSmalltalkコードであると認識され、右手上段のボタン群の構成が変化します。「filein」というボタンが追加されるので、これをクリックします。
    ボタンを押した直後、一瞬だけプログレスバーが現われて消えます。一瞬なのは、たんにファイルインするコードが短いからです。ノーティファイア(エラー)が表示されなければ、システムへの読み込みは無事完了となります。

    [fig.A]ファイルアウトしたコードをファイルインするためのボタン
    http://squab.no-ip.com:8080/mosaren/uploads/48a.png

     確認のため、FileList >> #defaultEncoderFor:の定義をブラウズしてみましょう。今ちょうど、ファイルリストで開いている「FileList-defaultEncoderFor.st」の3行目に「defaultEncoderFor:」という文字列がありますので、これを選択してからbrowse it(cmd+B)するのが早いと思います。定義は、先ほどファイルインした「FileList-defaultEncoderFor.st」の内容、つまり、前回、手を加えたコードになっているはずです。

     さらに前回の復習を兼ねて、念のため、ウインドウ中程の「versions」ボタンを押してバージョンブラウザを開いてみてください。最新版(上端のリストペインの一番上の項目)をクリックすれば、下のペインに、ファイルインしたバージョンとの差分情報も確認できます(追加した行が赤い文字で表示されます)。

    [fig.B]ファイルインした定義が最新のものとなっていることを確認
    http://squab.no-ip.com:8080/mosaren/uploads/48b.png

     もちろんファイルリストの挙動もファイルインの前後で変わっています。再び、ファイルリストのウインドウをクリックしてアクティベートしてから、右手のペインより「ShiftJisExample.txt」をクリックして内容を読み込みます。ファイルインによるパッチがうまく機能していれば、もはや文字化けは起こらないはずです。

    [fig.C]ファイルイン後、.txtファイルの読み込み時の文字化けは解消
    http://squab.no-ip.com:8080/mosaren/uploads/48c.png

    ▼ファイルリストを使わずにファイルインする方法
     実は、ファイルインはファイルリスト独自の機能というわけではありません。たとえば、ファイルインしたいコードがすでに手元にある場合は、Squeakシステム内の、テキストの入力や編集を行なう場所ならどこでもファイルインが可能です。つまり、“外の世界”からクリップボード経由で(コピー&ペーストで)持ち込んだり、極端な話、手で直接タイプしたコードでもファイルインは可能…というわけです。実際に試してみましょう。

     簡単のため、ファイルリストで開いている「FileList-defaultEncoderFor.st」の内容を使うことにします。このファイルの内容を全選択(cmd-A)後、コピー(cmd-C)して、ワークスペース(デスクトップメニュー → 開く… → ワークスペース)などに貼り付け(cmd-P)てください。改めて、全選択(cmd-A)し、シフト黄ボタンメニュー(shiftキーを押しながら黄ボタンメニューを呼び出すか、黄ボタンメニューの「さらに…」を選択)から「ファイル・イン」を選ぶと、選択テキストをコードに見立ててファイルインすることができます。

     なお、当該メニューの項目に「(G)」と添えられているのは、このメニュー項目の機能(選択文字列のファイルイン)がキーボードショートカット「cmd+shift-G」でも起動できることを意味します。

     また、GUIではなく、あえてSmalltalkの式を使ってファイルインを行ないたい場合は、

    (FileStream fileNamed: ‘FileList-defaultEncoderFor.st’) fileIn

    をdo it(cmd-D)しても同じことが可能です。動的に定義ファイルを読み込む必要があるとき、たとえばソフトのインストールを行なうコード(インストーラ)などでよく使われます。もちろん、先に紹介したGUIを用いたファイルインも、内部では、これと同じ式が評価されています。

    ▼ファイルイン前にコードを閲覧できる「ファイルコンテンツブラウザ」
     コードをファイルインしてシステムに読み込む前に、どのクラスのどんなメソッドを改変しているのか、あるいは、どんなクラスやメソッドを追加しているのかを確認したいことはよくあります。ただ、ファイルアウトされたSmalltalkコードには“チャンク”(まとまり)の区切りを示す記号である「!」が、多数、機械的に挿入されているため、あまり読みやすいものではありません。

     このようなときに便利なのが「ファイルコンテンツブラウザ」です。ファイルコンテンツブラウザはシステムブラウザのようなウインドウを表示し、指定したファイルアウトコードの内容を、システム内のコード同様、容易に閲覧できるような機能を提供してくれます。

    [fig.D]ファイルコンテンツブラウザ
    http://squab.no-ip.com:8080/mosaren/uploads/48d.png

     ファイルコンテンツブラウザはファイルリストから起動するのが簡単です。ブラウズしたいファイル(ファイルアウトされたもの)を選択し、上端の「code」ボタンをクリックします。

    [fig.E]ファイルコンテンツブラウザを起動するためのボタン
    http://squab.no-ip.com:8080/mosaren/uploads/48e.png

     GUI(ファイルリスト)を使わず、次の式を適当な場所で入力後にdo it(cmd-D)しても同じです。

    FileContentsBrowser browseStream: (FileStream fileNamed: ‘FileList-defaultEncoderFor.st’)

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

    ニュース・解説

    今週の解説担当:木下 誠

    ———————————————————————-
    Developer Transition Resource Centerの
    日本語版がオープン
    ———————————————————————-

    先月、IntelベースMacへの移行を支援するためのページ、「Developer Transition Resource Center」がオープンしたとのニュースを伝えましたが、その日本語版が公開されました。

    このページは、Intelへの移行に必要な情報、ソフトウェア、技術資料へのリンク集となっています。今回の日本語ページのオープンに合わせて、「Universal Binaryプログラミングガイド」、「Universal Binaryの導入」、「XcodeへのCodeWarriorプロジェクトの移植に関する概論」の、日本語への翻訳も公開されています。

    また、いくかのドキュメントは「翻訳中」となっているので、近日中に公開されることでしょう。

    Developer Transition Resource Center
    http://developer.apple.com/ja/transition/index.html

    Universal Binaryプログラミングガイド
    http://developer.apple.com/ja/documentation/MacOSX/Conceptual/universal_binary/index.html

    Universal Binaryの導入
    http://developer.apple.com/ja/macosx/adoptinguniversalbinaries.html

    XcodeへのCodeWarriorプロジェクトの移植に関する概論
    http://developer.apple.com/ja/documentation/DeveloperTools/Conceptual/MovingProjectsToXcode/index.html

    ———————————————————————-
    Intelへの移行パス確認のドキュメント
    ———————————————————————-

    IntelベースMacへの、移行のパスを確認するためのドキュメント、「Scoping Your Transition Project」が公開されています。

    このドキュメントは、Mac OS Xアプリケーション、オープンソースUNIXプロジェクト、Javaのようなアーキテクチャ非依存言語、といったカテゴリー毎に、どのような作業が必要になるかを、列挙したものです。また、必要な資料へのリンクも併せて掲載されています。

    Intelへの移行は、必要な技術資料は一通り出そろい、Appleとしてはそれをデベロッパに広く知らせようとしている段階に来ているように思えます。

    Scoping Your Transition Project
    http://developer.apple.com/transition/projectscope.html

    ———————————————————————-
    ADCで、オンラインでの書籍ブラウズサービス開始
    ———————————————————————-

    ADCで、一風変わったサービスが始まりました。Webブラウザ上で、本のブラウズ、検索ができる「ADC Bookshelf」というサービスです。Safari Books Onlineが提供するそうです。

    このサービスでは、1,000冊の技術書を、オンラインで読んだり、検索できたりするものです。ADCの一部として提供されるので、もちろん、Mac系の書籍も含まれます。

    さて、面白そうなので、やってみました。まず、これは有料サービスです。始めに登録を行います。値段は、ADCの会員レベルに応じて、PremierとSelectが月$17.99、Onlineが月$19.99です。

    ログインすると、本の一覧と、自分の本棚(Bookshelf)ができます。本棚には、本を10冊入れることができます。本棚に入れた本は、全文をオンラインで読むことができます。ただし、一度入れた本は一ヶ月出すことができません。一ヶ月たったら、他の本と入れ替えることができます。

    つまり、一月に10冊の本が読み放題になる、というサービスです。本棚に入れた本は、そのまま残しておいてもいいですし、必要なければ他の本と入れ替えます。短期的に、様々な分野の技術が必要になったときや、興味のある分野の本をちょっと試し読みしたいときに、便利なサービスでしょう。

    本文は、Webブラウザ上で、テキストとして読みます。PDFではありません。リスト、テーブル、画像等もきちんと含まれます。Webブラウザで長文を読むのが苦にならなければ、便利です。ですが、ここを不便と感じる方もいるでしょう。本の一部をPDFとしてダウンロードできるものもあるようです。

    Webページのデザインは、それなりに使いやすいです。ただ、本文がテキスト表示、というのが最大のポイントになると思います。これを受け入れられて、月に数冊の本を買うような方なら、使いがいのあるサービスでしょう。最後に、当然ですが、すべて英文の本です。

    ADC Bookshelf
    http://developer.apple.com/adcbookshelf/

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

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