MOSA Multi-OS Software Artists

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

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

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

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

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

    2006-08-29
     

    目次

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

    MOSA理事コラム   第6回   MOSAオーディオブックのできるまで!
                      松木英一

     MOSAのメーリングリストでもお知らせしたことがあるので、ご存知の方も多いかもしれないが、MOSA湘南ミーティング2005の基調講演を収録したオーディオブックについて、その出来上がる過程をここでご紹介しておきたい。日本でオーディオブックという言葉が聞かれるようになったのは、2005年8月にiTunes Music Storeが日本でサービスを開始してからのことだ。iTunes Music Storeは、ご覧になってわかるように音楽だけをダウンロード販売しているだけではない。ショートムービーやミュージックビデオ、オーディオブックも取りそろえている。オーディオブックは、Audible(オーディブル)という音声コンテンツの著作権管理技術の開発企業が、iTunes Music Store経由で提供しているコンテンツである。

    オーディオブックの基本形は、書籍として存在している「本」をアナウンサーや俳優等が朗読して音声ファイル化し、インターネットで配信されるものである。楽曲をダウンロードするかのように、音声ファイル化された「本」を入手するのだ。日本においても古くからソノシートやカセットやCDといった形で存在しているが、旧作や名作とされるものが中心で、ベストセラーのようなものはあまりない。海外ではつい最近も『ハリー・ポッター』がでたり、旧くはアップル社CEOであるSteve Jobsの評伝『The Second Coming of Steve Jobs』など、話題の本も多い。
     Audibleは、米国を中心に250社以上のコンテンツ企業と提携していて、新作の投入にも意欲的だ。もともと米国では、車で移動する機会が多いので、本を耳で聞くという需要が存在している。書店やレコード店などにも独立した売り場が確保されているほどだ。しかしオーディオブックが広く注目を集めるようになったのは、iPodを始めとする大容量の携帯用デジタル音楽プレーヤが普及しはじめてからだ。これで外出時にオーディオブックを持ち出すことが可能になり、通勤やスポーツをしながら聴くことが可能になった。なおiTunes Music Storeではオーディオブックも著作権管理技術“FairPlay”で保護されている。

    さてMOSAらしいオーディオブックとは何だろうか? iTunes Music Storeの中を探してみても、パソコン系の技術書的なものは存在しないのだ。これは考えてみればきわめて奇妙な状況と言える。パソコンやiPodで聴いているにも関わらず、これらの解説書のオーディオブック版がないのだから。
     そこで「無いものは作ろう」の精神で、挑戦することにした訳だ。いろいろ考えて思いついたのが、MOSA湘南ミーティング2005の基調講演録である。講演録というは、オーディオブック向きのジャンルのひとつだといえる。現時点でiTunes Music Storeにおける日本語の講演録というのは、非常に少ない。もちろんMac関連のものと限定すれば皆無である。湘南ミーティングに参加している方はご存知かと思うが、ここしばらく基調講演の講師を務めている、大谷和利氏の軽妙な語り口ながら深い洞察力を秘めた話は、定評があり書籍や雑誌の記事から受ける印象とはまた違った魅力がある。録音状態は必ずしもベストとは言えなかったが、会場との掛け合いなど、ライブ感あふれるちゃめっけたっぷりな氏の語りは絶品と言って良いだろう。特にこの講演の中で紹介された「ポッド電」にまつわるくだりは、会場の笑いと喝采を呼んだ。

    制作の手順は、ビデオテープから音声の部分を抜き出して、雑音を取り除いたり音楽が流れている部分をカットしたり、解説やオマケ部分を追加録音して編集を行いオーディオCDを作成した。このあとパッケージ化する際に必要な情報(カテゴリ、タイトル名、執筆者名、価格、再生時間、出版社名等)を、所定のシートに記載し、iTunes Music Storeにおける取りまとめ窓口の、オーディブルジャパンに受け渡しを行うのだ。
     もちろんiTunes Music Storeでオーディオブックを販売するためには、ただ一つの代理店であるオーディブルジャパンと契約を交しておく必要がある。こうしてMOSA湘南セミナー講演録「素晴らしい技術は三幕で構成される!」は、原盤の受け渡しから2ヶ月後に公開された。通常は3週間程度と聞いていたので、今回はずいぶんかかったことになる。データの調整に時間がかかったということだが、次回からはスムーズに公開されることを期待しよう。
     なお大谷氏の意向で、講演録の収益は全額MOSAの活動資金として寄贈される。
     今後ともこのシリーズの充実を図って行きたいと考えている。皆さんからのアイデアを是非お寄せ頂きたい!

    ■プロフィール
    松木英一(まつき えいいち)
    昭和28年生まれ 福井県福井市出身 明治大学文学部卒。
    1987年NIFTY-Serveのサービス開始と同時にMacintoshユーザーのためのネットワーク上のフォーラムであるMACUS-Jを主宰。
    1993年にネットワーク通信メディア上でのビジネスを展開するため有限会社パステルを設立し、一貫してネットワーク通信メディア上で事業を展開する。
    2003年には有限会社パステルの関連会社として有限会社パムリンクを設立。
    2005年に株式会社アイチューンズとiTunes Music Storeでのダウンロード販売契約を行い、以後、iTunes Music Storeでの音声コンテンツのダウンロード販売を手がける。本業のかたわら、MOSA常任理事としてMOSAが関係する一般向けイベントを担当している。また、Macintosh関連の専門誌MacFanにても執筆活動中。

    WWDC06レポート        川本 康詔

    MOSA会員の皆様、こんにちは。株式会社ナナオの川本康詔と申します。今年もMOSAツアーを利用してWWDCに参加いたしました。僭越ながらWWDCの感想を書かせていただきます。

    私は今もCodeWarriorでMac OS 9でも動作するCFMアプリを開発しておりますが、近い将来いきなりUniversal Binary移行をすることになりそうなので、そのときはCocoaではじめから書き直そうかと考えています。しかし、Cocoaは10.2の頃の知識しかないため、今回のWWDCのテーマは「Cocoa再入門」でした。Cocoaのセッションを中心に聴講しましたが、どのセッションも内容が濃く、とても勉強になりました。

    WWDCの参加は2001年、2005年に続いて今回が3回目ですが、今年が最も熱気に包まれていたような気がします。また、最も充実し、最も楽しめたのではないかとも感じています。今年は金曜日の午前中で終了になりましたが、最後のセッション終了まで大勢の参加者で賑わっていたのがとても印象に残っています。木曜日のCampus Bashでは現地で知り合った人がレンタカーを借りるということで、便乗させていただいてAppleキャンパスに先乗りすることができ、カンパニーストアでの買い物もゆっくりでき、キャンパス内でもゆっくり楽しむことができました。
    ただ、今年は8月の開催になったため、避暑にはとても良かったのですが、ツアー料金が高くなったため、8日間コースを選ばざるを得なくなり、やはり5月か6月が良いな、と思いました。ただ、今年はホテルで無線LANも利用可能になっていたので、とても便利でした。

    (来年参加を検討されている方へ  〜特に初めての方へ)
    WWDCにはたくさんの日本人デベロッパが参加しますので、いろんな人と知り合いになれる良い機会です。航空券やホテルの手配は例年AppleやMOSAがツアーを企画しているため心配はありません。英語でのコミュニケーションもWWDC会場内ではAppleの日本人スタッフのサポートがあるので特に心配することはないと思います。海外未経験の方でもWWDCは参加しやすいのではないかと思います。

    来年も可能であれば参加したいと思っていますが、是非皆さんも参加しましょう!

    ■プロフィール
    川本康詔(かわもと やすのり)
    大学修了後、株式会社ナナオに入社。入社後はしばらくLCDモニターのスケーリング(解像度変換)技術開発に従事し、その後Windowsアプリケーション開発を担当。2000年からMacプログラミング業務を開始する。Mac開発の比重が高くなるにつれ、個人でもMacを楽しむようになり、現在、WWDC2006直前に購入したMacBookでCocoaプログラミングを楽しもうと考えている。

    Wonderful Server Life」  第16回  田畑 英和

      〜これからの連載〜

     さて、これまでMac OS X Serverの導入について解説してきましたが、これからはいよいよMac OS X Serverで運用する各サービスの解説を始めていきたいと思います。サーバで利用可能なサービスは色々あり、どのサービスから解説を始めたものか迷ってしまいますが、ディレクトリサービスの解説から始めていきたいと思います。

    ◇ディレクトリサービスとは?
     さて、ディレクトリサービスとはいったいなんでしょう? まずはディレクトリサービスを導入することにより、どういったことが実現可能になるかをみてみましょう。ディレクトリサービスは、ほかのサービスとも密接に関連していますので、ほかのサービスとディレクトリサービスとの組み合わせでどのようなことが実現できるかをみてみます。

    ・ファイルサービスを利用する
     ファイルサービスはもっともよく使われるサーバのサービスですが、ディレクトリサービスがない環境では、クライアントとサーバ上にそれぞれユーザアカウントが必要になってきます。ディレクトリサービスを導入すればサーバ上でユーザアカウントを一元管理できます。(こういったユーザのことをネットワークユーザと呼びます)。
     ネットワークユーザは、クライアントへのログインに使用することもできますし、ファイルサーバへのアクセスに使用することもできます。つまりネットワーク上でユーザアカウントを共有することができるのです。また、アクセス権の管理をおこなうさいにもディレクトリサービスは重要になります。

    ・ネットワークホームを利用する
     ユーザアカウントだけでなくホームディレクトリもサーバ上で一元管理することができます。ネットワークユーザとネットワークホームを組み合わせればどのMacを使っても、いつも同じユーザとホームを利用できます。各ユーザごとのホームディレクトリの情報や、サーバ上のホームを動的にマウントするためのマウントレコードはディレクトリサービスを使って管理することができます。

    ・NetBootを利用する
     NetBootとは、サーバ上に用意したシステムのディスクイメージから、ネットワーク上のクライアントを起動するテクノロジーです。このとき各NetBootクライアントはサーバ上のディスクイメージを共有し、クライアントからサーバ上のディスクイメージを直接変更することができません。ですのでNetBoot用のシステム(サーバ上のディスクイメージ)では、ユーザやホームを管理することが難しくなります。
     そこで、通常NetBoot環境ではネットワークユーザとネットワークホームを利用することになります。ですのでNetBootシステムではディレクトリサービスの導入が不可欠になります。

    ・クライアントの環境設定を管理する
     こちらはディレクトリサービスそのものの機能になりますが、ディレクトリサービスを使ってサーバ上でクライアントの環境設定を一元管理することができます。
     様々な環境設定が可能ですが、たとえばクライアント上で起動可能なアプリケーションの制限、ネットワークの環境設定(Proxy設定)、メディアアクセスの制限(CD-R/DVDへの書き込みや外付けディスクの使用制限)、Dockの設定などを行うことができます。

     このように、ディレクトリサービスを利用することで様々な機能を実現することができるのです。このほかにもシングルサインオン環境、Finderのネットワーク表示のカスタマイズ、アドレス情報の管理などを実現することができます。
     ディレクトリサービスは、様々な情報をサーバ上で一元管理し、ネットワーク上で共有可能にするためのサービスです。ディレクトリサービスを導入することによりクライアント管理の効率がぐんと向上します。

    さてこれからの連載ですが、ディレクトリサービスの設定方法から話を始めていきます。ディレクトリサービスの話ばかりにかたよってもいけませんので、ほかのサービスの解説も交えながら連載を進めていきたいと思います。
     次回の連載ですが、ディレクトリサービスをきちんと動作させるにはDNSの環境が整っている必要がありますので、Mac OS X ServerのDNSについて解説を行いたいと思います。

    つづく

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

    〜 Carbonモダンアプリケーションへの道(その2) 〜

    今回は、もう少し詳しくDEPRECATED APIを調査してみたいと思います。いったい、どんなAPIが消え、どんなAPIが生き残ったのか? APIの差し替え作業をするにも、まずこの点を把握しておかなければ始まりません。

    どのような種類のAPIがDEPRECATEDの洗礼を受けるのかについて、何かしらはっきりとしたルールが存在すれば使う側も判断しやすいのですが、どうも、そうした明確な基準は提示されていないようです。しかし、Carbon Frameworkのヘッダーファイルを調べてみると、まず最初にQuickDraw関連のAPIがほとんどダメ(DEPRECATED指定)だと言うことに気づきます。QuickDraw関連のAPIが定義されているヘッダーファイルは、QD.hというヘッダーファイルにまとめて記載されていますので、その個々の内容を調べることで大まかな状況を把握することができます。

    ここで対象となるヘッダーファイルは、QuickDraw.h、QuickdrawText.h、PictUtils.h、QDOffscreen.hなどです。前回も少しお話しましたが、QuickDraw.hでDEPRECATEDと指定されていないAPIは全部で60弱です。
    QuickdrawText.h、QDOffscreen.h、 PictUtils.hの3つについては、ほぼ全てのAPIがDEPRECATEDとなっています。DEPRECATED指定を免れたAPIを分類してみると、QDBeginCGContext()やQDEndCGContext()、そしてQDSwapPort()のように、名称の先頭に「QD」とついたAPIはほとんど生き残っています。これらはMac OS X以降に導入された比較的新しいAPI群です。QuickDraw.hでは、こうしたAPIが20程度存在しています。

    それ以外は、不思議なことに、GetPortBounds()、GetPortForeColor()といったCGrafPortの情報を得るためのAPIが結構生き残っています。
    GetPortBitMapForCopyBits()も、そのうちの一つですが、この情報が必要であるCopyBits()がDEPRECATEDなのに、何故にこのAPIのみが生き残っているのかはかなり謎です(笑)。この状況を見ると、GWorld(オフスクリーン用CGrafPort)については、それを用いることを禁止したいようですが、CGrafPort自体を無くしてしまうことはないようです。システムの深淵に、まだどうしても外すことができない「理由」が存在しているのかもしれません。GetPortTextFont()、GetPortTextFace()、GetPortTextMode()、GetPortTextSize()などもDEPRECATEDでないのが本当に不思議です。

    QuickDrawのメイン画像フォーマットであるPictureを操作するAPIは全滅です。ただし、既に保存されている画像ファイル(PICTファイル)を取り扱いたいケースは多々ありますので、CoreGraphicsで描画を行う時に必要な情報を得るためのAPIが別途用意されています。それらは、QDPictToCGContext.hというヘッダファイルに記載されています。また、Polygonを操作するAPIは全滅ですが、Region(任意領域)については、RgnToHandle()やIsValidRgnHandle()が生き残っています。これを見ると、システム内部でのRegion利用が根絶されたわけではなく、Window Manager関連などでは、まだその使用が継続されているようです。ただし、Appleとしては、徐々にRegionをCoreGraphicsの「Shape」に切り替えたいと考えているようです。Shapeに関してはHIShape.hを参照してみてください。

    現在のMac OS Xネイティブ描画システムはCoreGraphics(Quartz 2D)ですから、何らかの描画においては、そちらのAPIを代用すれば、ほとんどのケースは問題ないはずです。ところが、QuickDraw.hでは、描画に直接関係していないAPIもDEPRECATEDとなっており、その処遇に納得いかない場合が多々あります。例えば、Rect構造体を操作するSetRect()やOffsetRect()といったAPIがそれです。ちなみに、Window ManagerのCreateNewWindow()(こちらは当然DEPRECATED指定でない)では、以下のように引数としてRect構造体を渡す必要があるわけです。よって、SetRect()ぐらい残しておいてもバチは当たらないと思うのですが…どうなんでしょうかねぇ?

    extern OSStatus CreateNewWindow(
    WindowClass windowClass,
    WindowAttributes attributes,
    const Rect * contentBounds,
    WindowRef * outWindow )

    まあ、このレベルのAPIであれば手間さえ惜しまなければ、以下のように自作の代用ルーチンを用意すれば問題は解決します。しかし、CopyBits()、CopyMask()、SeedFill()、BitMapToRegion()といったハイエンドAPIは、ベテランプログラマになると描画処理の目的以外でも色々と活用しているケースが多々あり、こうした有用なAPIがなくなり、かつCoreGraphicsにその代用品が無いとなると、非常に困った事態に遭遇することになります。筆者が一番頭をかかえているのはこの点でして、そうしたAPIは何とか残しておいて欲しいのですが…まあ、無理なんでしょうね(涙)。

    void setRect( Rect *drt,short left,short top,short right,short bottom )
    {
        drt->left=left;
        drt->top=top;
        drt->right=right;
        drt->bottom=bottom;
    }
    
    void offsetRect( Rect *drt,short dx,short dy )
    {
        drt->left+=dx;
        drt->top+=dy;
        drt->right+=dx;
        drt->bottom+=dy;
    }
    
    void insetRect( Rect *drt,short xx,short yy )
    {
        drt->left+=xx;
        drt->right-=xx;
        drt->top+=yy;
        drt->bottom-=yy;
    }
    
    void rectToCGRect( Rect *drt,CGRect *cgrt )
    {
        cgrt->origin.x=drt->left;
        cgrt->origin.y=drt->top;
        cgrt->size.width=drt->right-drt->left;
        cgrt->size.height=drt->bottom-drt->top;
    }
    


    こうして色々なヘッダーファイルを調べてみると、最初は、システムのパフォーマンスや安定性に直結するスレッドセーフや64bit対応に不向きなAPIが、そのままDEPRECATEDに指定されているのかと考えたのですが、どうやらそうでもなさそうです。GWorldやPicture同様、Pascalストリングス(Str255)やファイル保存場所を指示するFSSpec構造体を引数に渡すAPIは、ほとんどがDEPRECATED指定を受けているようです。ところが、Mac OS X登場時には「風前の灯火」と噂されていた(笑)Resource Manager(Resources.h)には、何故だかDEPRECATED APIがひとつも存在しません。システムの進化の「都合」が色濃く出ているようで、実に興味深い結果です。

    さて、自作アプリケーションのメイン処理の中心として活躍していたAPIが突然消えてしまったら、デベロッパーは途方にくれてしまいますよね。そうした事態を避けるために、Apple社は何年かかけて少しずつ代用APIを準備してきました。次回は、そうした代用APIを取り上げ調査してみたいと思います。

    つづく

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

    本連載では、名前は知っていてもなかなか触れる機会のないSmalltalkについて、最近話題のSqueakシステムを使って紹介しています。前回に引き続き、簡易GUIビルダを作成します。今回のテーマは、ウインドウメニューへのメニュー項目の追加です。

    ウインドウメニューは、ウインドウのタイトルバー左寄り、クローズボタンの右隣にあるボタンをクリックしたときにポップアップするメニューのことです。このメニューには、モデル(a SystemWindowのインスタンス変数「model」に束縛されているオブジェクト)を通じて、好きなメニュー項目を追加することができます。作成中のGUIビルダでは、このメニューに、ウィジェットを追加したり削除するためのメニュー項目を設ける予定です。

    手近なところでは、ワークスペースのウインドウメニューに項目が追加されています。どんなふうにしてそれを行なっているのか、参考にするため、しくみを調べてみましょう。

    ▼ワークスペースで追加されている項目の確認
    まずは、デフォルトの状態。まさに「GUI Builder」ウインドウがそうなのですが、特に項目が追加されていない場合、次図のようなメニュー項目が現われるはずです。

    [fig.A]デフォルトの項目のみのウインドウメニュー

    次に、ワークスペース。デスクトップをクリックしてデスクトップメニューを呼び出し、cmd + K(あるいは、「開く…」→「ワークスペース」)でワークスペースを呼び出してから、ウインドウメニューボタンをクリックしてください。

    [fig.B]ワークスペースのウインドウメニュー

    4つのメニュー項目(正確にはさらに二本の区切り線)が追加されていますね。以上のメニュー項目が、どのようなメソッドを介して追加されているのかを調べるのには、すでに学んだ方法を駆使するいくつかの方法(よかったら、復習がてらにチャレンジしてみてください)がありますが、今回は、メニュー項目の文字列を手がかりにした、別の新しい方法をご紹介します。

    ▼メニュー項目の文字列を手がかりに関連メソッドを手繰る
    すでに第57回ごろに学んだとおり、メニュー項目の追加は、通常、メニューオブジェクト(a MenuMorph)にメッセージを送信し、#add:target:action:などのメソッドを起動させることで行なわれます。このことは、たとえば「save contents to file…」というメニュー項目を作る式(あるいは、そのとき送信されるメッセージ)には、’save contents to file…’という文字列リテラルが含まれている可能性が高いことを意味します。

    ところで、Smalltalkシステムには、ある文字列リテラルを含むメソッドを探し出して列挙してくれる便利な機能が用意されています。シフト黄ボタンメニュー(黄ボタンメニュー→「さらに…」。英語ではmore…)にある「メソッド中文字列の部分」(英語では、method strings with it)で起動することが可能で、そのとき選択されている文字列が対象とされます。キーショートカットはcmd + shift + Eです。

    つまり、メニュー項目の文字列を指定して、このサービスを利用すれば、注目するメニュー項目を定義しているメソッド、あるいは、それに深い関わりを持つ可能性が高いメソッドを列挙することが可能…というわけです。

    ここで、さらにもうひとひねり。Squeakシステムで使われているポップアップメニューには、shiftキーを押しながら項目をクリックすると、そのメニュー項目をテキストとして選択可能…という、何に使うのかよく分からない、ちょっと変わった挙動を示します。この性質を先のcmd + shift + Eと組み合わせてみましょう。

    [fig.C]shiftクリックで選択されたメニュー項目のテキスト

    図のように、メニュー項目をテキストとして選択した状態にしてから、先に紹介したcmd + shift + Eをタイプしてみてください。結果、システムは、文字列「save contents to file…」について、ParagraphEditor class >>#shiftedYellowButtonMenuとWorkspace >> #addModelItemsToWindowMenu:の二つのメソッドがこれを含むことを見つけてきてくれます。念のため、我々が探しているメソッドは後者です。

    [fig.D]「save contents to file…」を含むメソッド一覧

    たった2アクションでこんな情報にアクセスできるなんて、Smalltalkというのは、まさに“なんでもあり”のシステムですね(笑)。ただし、残念ながら、メニュー項目が日本語の場合はこのTIPSは使えないようなので、他のメニュー項目で試してみたいときは、デスクトップメニュー→「ヘルプ…」→「言語を設定…」でEnglishを選んで言語を切り替えておく必要があります。

    さて。当初の目的である「ウインドウメニューへ項目の追加」のためには、モデルの属するクラス(ワークスペースなら「Workspace」、作成中のGUIビルダなら「GuiBuilder」)に、#addModelItemsToWindowMenu:を定義して、パラメータとして与えられているaMenuにメニュー項目を追加すればよさそうなことが分かりました。

    余力があれば、この、Workspace >> #addModelItemsToWindowMenu:の定義を変更(たとえば、メニュー項目の文字列を変更したり、新たにメニュー項目を追加するなど)して、実際に影響が及ぶかどうかを試してみるのも面白いでしょう。分解して仕組みを調べて学んだり、遊んだりできるのが“暫定ダイナブック環境”の醍醐味ですから、これを実践しない手はありません。

    GuiBuilderへの#addModelItemsToWindowMenu:の追加は、次回。

    バックナンバー:

    ニュース・解説

     今週の解説担当:木下 誠

    ———————————————————————-
    Leopard先行プレビュー
    ———————————————————————-

    先日行われましたWWDC 2006では、予告通り、Mac OS X 10.5 “Leopard”のプレビューが行われました。サンフランシスコに行った方は、すでにインストールして、新機能を試している事でしょう。

    Leopardの情報は、一部Appleのサイトでも、先行プレビューとして紹介されています。英語版は、WWDCの基調講演と同時に公開されましたが、このたび日本語版も用意されました。

    Time MachineやSpacesといったユーザの耳目を集める機能から、Xcode 3.0やObjective-C 2.0といった開発に関わる情報も、ほんの少しだけあります。サンフランシスコに行けなかった方は、こちらから予想しましょう。

    Leopard先行プレビュー
    http://www.apple.com/jp/macosx/leopard/

    ———————————————————————-
    Xcode 2.4、CHUD 4.4.2、Boot Camp 1.1
    ———————————————————————-

    WWDC後に登場した、ツールをまとめておきましょう。

    まず、Xcodeが2.4にバージョンアップしました。ハードウェアの様々な情報を調べる事が出来る、CHUDも4.4.2がリリースされています。

    さらに、Boot Campも1.1が登場しています。新しく登場したMac Proへの対応が、主な機能になっています。

    Xcode 2.4
    CHUD 4.4.2
    http://developer.apple.com/tools/download/

    Boot Cammp 1.1
    http://www.apple.com/macosx/bootcamp/

     

    ◇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=モサ伝]第217号

    2006-08-22

    目次

    • MOSA理事コラム          第5回   田中 太郎
    • 「Wonderful Server Life」      第15回  田畑 英和
    • 藤本裕之のプログラミング夜話 #97
    • 高橋真人の「プログラミング指南」  第95回
    • ニュース・解説                小池 邦人

    MOSA理事コラム   第5回 「Core Audio」
                     田中 太郎 有限会社ソノランブルー

    MOSA会員の皆様、こんにちは。ちょうどこの原稿を書いている時にWWDCが開催されておりましたが、今年は残念ながら参加できませんでした。基調講演をネットで見る限りでは、まだ次のOSで搭載される新機能が見えてきませんでしたが、CD-ROMが届くのを待っていることにします。

    今回は、あまり皆さんが取り上げなかったCore Audioについてちょっと書こうと思います。(ひょっとして興味がないのか? 心配ですが…)
    旧世代のMacOSでは、Sound Managerが、オーディオ回りの役割を担当していました。しかし、サラウンドスピーカーや高いサンプリングレートやビットレートが世の中で使われるようになってから、Sound Managerでは限界にきていました。それが、MacOS XになってからはCore Audioが登場し、より高性能で拡張性が高くなっています。アップル社がプロアプリケーション用にオーディオのソフトを販売するために、開発会社を買収し、そのエンジニアたちによって、Core Audioが開発されていった歴史もあります。
    もちろんそのア−キテクチャーは、優れているのですが、とっつきづらい点もあります。アップル社から提供されているサンプルが、シンプルでないため、量はあるのに、理解しにくいです。Core AudioのAPIはC言語のAPIなので、Carbonからも、Cocoaからも利用できます。しかしサンプルコードの多くは、何故か、C++で書かれています。クぅっー

    では、まずはじめに、単純にオーディオのファイルを再生してみたいと思います。オーディオファイルのURL(CFURLRef, もしCocoaの場合はNSURL*をキャスト)を取得した所から始めます。それをFSRef形式に変換します。

       FSRef                fileRef;
       CFURLGetFSRef((CFURLRef)[self fileURL], &fileRef);

    MacOS X 10.4から、ExtendedAudioFileが導入されました。こちらの方がより簡単に扱えますので、こちらを使います。取得したFSRefを使って、オーディオファイルを開き、それへの参照(ExtAudioFileRef)を取得します。

      OSStatus             err;
       ExtAudioFileRef      _audioFileRef;
    
       err = ExtAudioFileOpen(&fileRef, &_audioFileRef);
    


    次は、実際に音が鳴るスピーカー(出力)を取得します。デフォルトの出力を探すことにします。Core Audioでは、出力の部分、オーディオを混ぜ合わせる部分、サンプリングレート等を変更する部分、フィルターをかける部分などのそれぞれのパーツが単独で分かれており、Audio Unitと呼ばれる単位になっています。実際にはQuickTimeで使われている、Componentです。

       AudioUnit       _outputUnit;
       _outputUnit = OpenDefaultComponent(kAudioUnitType_Output,
                             kAudioUnitSubType_DefaultOutput);

    タイプが出力のAudio Unitのタイプで、サブタイプをデフォルトの出力を指定してAudio Unitを開きます。開いたAudio Unitを初期化します。

      AudioUnitInitialize(_outputUnit);

    音は実際に出力のAudio Unit(つまりスピーカー)から出てくる訳ですが、鳴らしたい音を出力のAudio Unitに渡して(入力)してあげなくてはなりません。どういったフォーマットの入力をすればいいのか、出力のAudio Unitに、「あなたはどういった形式を渡せば、音を鳴らしてくれるの?」と問い合わせます。

       UInt32           propertySize;
       AudioStreamBasicDescription  desc;
    
       propertySize = sizeof(AudioStreamBasicDescription);
       err = AudioUnitGetProperty(_outputUnit,
                 kAudioUnitProperty_StreamFormat, kAudioUnitScope_Input,
                 0, &desc, &propertySize);
    


    次は、オーディオファイルの読み込み側に、「お客さまはこういった形式の音を欲しがっているので、この形式変換して読み取りたまえ」ということを、オーディオファイル側に伝えます。

      err = ExtAudioFileSetProperty(_audioFileRef,
                 kExtAudioFileProperty_ClientDataFormat,
                 sizeof(AudioStreamBasicDescription), &desc);

    音を鳴らす処理を、普通に考えると、最初にファイルからデータを読み込んでそれをスピーカーに渡していくと思いますが、Core Audioは、逆です。スピーカーに「さあ音を鳴らせ」と伝えると、スピーカーの方から逆に「このデータを入力してくれ」と要求してきます。「エサをくれ」といっているスピーカーに対して、ファイルからデータを読み込んで渡すコールバック関数を用意します。

    OSStatus renderCallback(void *inRefCon,
                 AudioUnitRenderActionFlags *ioActionFlags,
                 const AudioTimeStamp *inTimeStamp, UInt32 inBusNumber,
                 UInt32 inNumberFrames, AudioBufferList *ioData)
    {
       OSStatus            result = noErr;
       MyDocument          *document = (MyDocument*)inRefCon;
       UInt32              numberFrames = inNumberFrames;
    
       result = ExtAudioFileRead([document audioFileRef],
                           &numberFrames, ioData);
       return result;
    }

    これで準備が整いましたので、出力のAudio Unitに対して、再生を行うように指示を出します。

     AudioOutputUnitStart(_outputUnit);

    iTunesのライブラリの中のファイルを選択すると、きっと音楽の再生がされると思います。ここからは、Audio Unitを葉っぱと例えると、枝となるAUGraphを使って、それぞれを接続していくことを行ってみます。枝と枝の間に、フィルターのAudio Unitを入れたりしてって、遊ぶと面白いと思います。

    資料:アップルのReference Libraryから
    - Core Audio Overview
    - Core Audio (これはReferenceです)
    


    ハードディスクのDeveloperフォルダの中のExamplesの中に、CoreAudioというフォルダがあり、男らしいサンプルが多数収められております。

    ■執筆者プロフィール
    田中太郎
    たなか たろう

     早稲田大学理工学部卒業の後、アップルコンピュータ株式会社にてデベロッパサポート業務。退社後、有限会社ソノランブルーを設立し、Macintoshソフトウェアの開発を行う。社員および弟子を募集中

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

      〜Mac OS X Server v10.4.7、Xserve、Leopard Server〜

     今年の1月にiMacから始まったハードウェアのIntelへの移行も、WWDCにて発表になったMac ProおよびXserveでついに最終章へと突入しました。Mac Proはすでに出荷が始まっていますが、Xeonを搭載したXserveは10月からの発売開始が予定されています。
     すべてのモデルがIntelに移行したことにともない、Mac OS X ServerもようやくUniversal対応したパッケージが発売になりました。今回はIntel対応したMac OS X ServerとXserveおよび、すでにWeb上でも情報が公開され始めているLeopard Serverについてレポートします。

    □Mac OS X Server v10.4.7
     Mac OS X ServerがようやくUniversal対応しました。これまではサーバを運用するためのハイエンドのデスクトップおよびサーバ機がまだIntelに移行していなかったわけですが、ハードウェアも出揃いつつあり、OSとハードウェアの両方がIntel対応することになります。
     Universal対応版のバージョン番号は、これまでリリースされていたPPC用の最新版と同じv10.4.7になります。バージョン番号が同じことから特に機能的な変更はないものと思われますが、システム条件にいくつかの変更があります。
     まずメモリが256MBから512MB、ハードディスクが4GBから10GBにそれぞれ変更されています。CPUにはIntelが追加されたわけですが、逆にPowerPC G3がシステム条件からは外れました。

    ・Mac OS X Server v10.4.7(Unlimitedクライアント)
    http://store.apple.com/0120-APPLE-1/WebObjects/japanstore?productLearnMore=MA612J%2FA

     サーバの管理ツールもv10.4.7に対応したバージョンがリリースされており、ソフトウェア・アップデート経由でのアップデートが可能です。

    ・サーバ管理ツール(v10.4.7)
    http://www.apple.com/jp/ftp-info/reference/serveradmintools1047.html

    □Xserve
     Intel対応したXserveですが、デュアルコアのXeonが2基(つまりクアッドコア)搭載されています。筐体はこれまでどおりの1Uですが、奥行きが約5cm長くなっています。

    ・Xserveのサイズ
    Xserve G5 高さ:4.4cm 幅:44.7cm 奥行き:71.1cm
    Xserve(Xeon) 高さ:4.4cm 幅:44.7cm 奥行き:76.2cm

     ほかのスペックをこれまでのXserve G5と比べてみますと、Xserve G5ではオプションだったグラフィックカードが標準で内蔵されるようになりました。グラフィックカードのために拡張スロットは使用していないため、グラフィックカードを内蔵しつつ、2基の空きスロットが使用可能です。
     ディスクストレージは7,200rpmのSATAもしくは15,000rpmのSASドライブのどちらかを選択でき、750GBのディスク(SATA)を3台搭載すれば最大2.25TBのストレージを搭載することができます。電源ユニット(650W)が2重化され、ホットスワップに対応しているため、システムを稼働させながら電源ユニットの交換ができるようになりました。2基目の電源ユニットはオプションになります。
     また、管理機能も強化されリモートから電源のコントロールができるようになっています。OSはこれまでどおりMac OS X Serverが付属します。
     出荷開始は10月が予定されていますが、Xserve G5はすでに在庫が少なくなってきているようですので、Xserveの導入を検討していた方は導入を再検討する必要があります。基本的にはXeonベースのXserveのほうがパフォーマンスは優れているわけですが、Xserveを収納するラックの仕様や、サーバ上で使用するソフトウェアのIntel対応について事前に確認しておく必要があります。

    http://www.apple.com/jp/xserve/

    □Leopard Server

     Mac OS X Serverの次期バージョンであるLeopard Serverは、様々な機能強化が行われております。詳細については製品が実際にリリースされてから取り上げることになるでしょうが、今回は主な新機能について紹介しておきましょう。
     まず管理ツールですが、新しいサーバ用のシステム環境設定ツールが導入されます。この新しい環境設定ツールではユーザやグループ、サービスの設定ができるようになる予定です。またシステムのステータスを監視するDashboardのwidgetも導入されます。
     新機能としてはiCalサーバが搭載され、個人やグループでのカレンダーの共有が可能になります。iCalサーバはカレンダーの標準プロトコルCalDAVを採用しており、ソースコード(主にpythonで実装されています)がDarwin Calendar Serverとして公開されます。さらに、専用の構文を覚えなくても手軽に編集が可能なWikiサーバも搭載され、チームでの情報共有が手軽に行えるようになっています。
     このほかにも、ネットワークボリュームの検索に対応したSpotlightサーバや、Podcastの制作ワークフローが自動化されたPodcast Producer、認証サービスを提供するRADIUSのサポートなど様々な新機能が搭載されています。
     最近人気のあるRuby on Railsや、Ver2系列のApache(これまでも搭載されてはいましたがデフォルトはVer1.3系列でした)も搭載されることになっています。リリースが待ち遠しいですね。

    ・Leopard Server
    http://www.apple.com/jp/server/macosx/leopard/
    ・Darwin Calendar Server
    http://trac.macosforge.org/projects/collaboration
    ・MAC OS FORGE
    http://www.macosforge.org/

    つづく

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

     残暑御見舞申上候。いやはやなんとも暑いですな。さて、WWDCのため1週間余計に間があいたわけだけど復習なしで続けていいですかね? ダメか。えっと前回はサンプルプログラムが描画する2つの矩形のうちの片方をドラッグ可能にして、マウスカーソルのシェイプを変える領域をどうやって更新するか、というのを見たわけである(え、と思うかもしれないけどそうなんだよ)。
     で、今回は、……これ、あんまり本筋とは関係ないようなんだけど、この「はいはい、この線から入ったらマウスカーソルの形を変えるからね四角形」(面倒なので以下『カーソル変形領域』と呼ぶ)2つがオーバーラップしたときの話を書いてみたい。前回インプリメントしたように、カーソル変形領域はNSViewのメソッド、resetCursorRects をオーバーライドして以下のように設定される。

    -(void)resetCursorRects {
         [self addCursorRect:openHandRect
                         cursor:[NSCursor openHandCursor]];
         [self addCursorRect:pointingHandRect
                         cursor:[NSCursor pointingHandCursor]];
    }
    


     この2つの矩形、openHandRect と pointingHandRect の間にはどうも優先順位というのがないみたいなのである。つまり(つうかホントはプログラム書いて試してみてもらいたいんだけど)、このメソッドでpointingHandRectの方が後から設定されているからといって、オーバーラップしたときにこっちのカーソル変更が優先されるわけぢゃないのだ。シアンで塗られたpointingHandRect の上でポインタをうろうろさせているとき、隠れて見えない openHandRect の上にくると突然カーソルが変わってしまう。これはちょっとまずい、よね。

    これはやっぱりなんとかしたい。いや、これをなんとかしたいと思わなかったらプログラマぢゃない。もしそういうヒトがこれを読んでたら悪いこたぁ言わないから今のうちに職業替えしなさい。世の中にはプログラマより楽で実入りも良さそうな職業が……もうなんつうか悲しいくらいたくさんあるんだから。

    悲しい話は置いておいて、まず思いつくのは resetCursorRects で2つの矩形が重なっているかどうか判定し、重なっていれば下になる方(この場合はopenHandRect に決まっているんだけど)を分割して見えている部分だけをcursorRect として設定することだろ。それなら絶対安全剃刀的に動作するだろうけど、その矩形の分割つうのになんつうか気が進まない。いや、このサンプルは2つの矩形が同じ大きさだからいいが、例えば pointingHandRect が 完全に openHandRect の上に乗っかってしまうとすると、この矩形を4つに分割しなければならないし、その場合分けも面倒である。なにかもっと楽する方法はないか。

    ここで一度原点に立ち戻り、なぜ2つの矩形のカーソル変更に優先順位がないように見えるのか、を考えてみよう。そんなこと言ったって矩形は2つ、どっちかを先どっちかを後で判定しているに違いないのにこれはいったいどういうことか。種明かしをしちゃうとこの判定は mouseEnterd: とmouseExited: に対して行われているからで、2つの矩形がずれている限り、片方に既にEnterしたものは一度 Exit するまで二度と同じものに Enterできないのにもう片方には Enterできる、というリクツが働いているのである(ここ、文章だと分かりにくいけど絵に描いてやってみるとすぐ解るよ、ホントにプログラムを書くのが一番だけど……しつこいか)。で、結論、ならば先にオーバーラップ部分への Enter を検出して上にある矩形のカーソルにしてしまえばいい。すなわち:

    -(void)resetCursorRects {
         if(NSIntersectsRect(openHandRect, pointingHandRect)){
              [self addCursorRect:
                   NSIntersectionRect(openHandRect,pointingHandRect)
                              cursor:[NSCursor pointingHandCursor]];
         }
         [self addCursorRect:openHandRect
                         cursor:[NSCursor openHandCursor]];
         [self addCursorRect:pointingHandRect
                         cursor:[NSCursor pointingHandCursor]];
    }
    


    と、これでこの問題は解決である。次回「ドラッグ中だけカーソルを変えるには」つうのをやってこの話題を終わりにしたい。そん次は何にしようかしら。

    (2006_08_17)

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

    プログラマのためのオブジェクト指向再入門(3)

    〜オブジェクト<2>〜

     こんにちは、高橋真人です。
     前回のお話をまとめますと、入門者の視点から見た場合には必ずしも「オブジェクト=モノ」という見方はふさわしいとは限らない、ということになります。では、どんなアプローチが入門者にふさわしいのか。その辺から今回は考えてみたいと思います。
     いきなりですが以下のコードをごらんください。

    int a = 3;
    int b = 5;
    
    a += b;
    printf("%d", a);

     Cの入門段階の人でも容易に理解できるコードだと思います。老婆心ながら付け加えますと、a += bはa = a + bとも書くことができます。ただ、前者の方が「aにbを加える」ということをよりストレートに表現しています。
     この「aにbを加える」は、「aとbを加える」でないことに注意してください。aとbを加えただけでは、a自体は(もちろんbも)変化しませんが、「aにbを加える」と、aの値はbの値分だけ増加することになります。

     では、今度は以下のコードを見てください。

    IntType a(3);
    IntType a(5);
    
    a.add(b);
    a.print();
    


     今度は、Cのある程度の経験者でも「げ、何なのだ、これは?」と引きかけたかもしれません(笑)。しかし心配はご無用。これは私が適当にでっち上げた架空の言語です。もっともC++を使えば、さらに数行加えることでこのまま動作させることは可能ですが。(もちろん、理解は不要です)

    それはさておき、こうやって並べてあると、下の架空の言語が何を表しているかは何となく理解できませんか?

     IntTypeというタイプ(型)の変数を宣言(定義)する。初期値は整数の3。
     ちなみに、

    IntType a = 3;

    という書き方をしてもよかったのですが、初期化を強調したいために、初期化構文をでっちあげました。(あくまで架空の言語ですから・笑)

     で、同様にIntType型の変数bを初期値5で定義します。
     次にaにb(の値)を加算します。

     ここで、まだ余りCに通じていない人のために解説。
     すぐ上の文章で、bの後に「の値」とカッコ書きしたわけですが、これは最初のCの例でも同じことです。ともすれば、「aにbを加える」というような表現をしてしまいがちです(実際、私も上でそのように書いてます)が、厳密に言えば「変数同士を加え」たり「変数に変数を加え」たりすることはできません。
     aとbを加える場合、aから格納されている「値」が取り出され、bから取り出された「値」と加算されて、それが結果として「評価」されます。(評価された結果は、変数で受けたり関数に渡したりしなければその場で捨てられます)
     また、aにbを加える場合も、やはりbから取り出された値がaに格納してある「値」と加算されて、aの中に「新たな値」として納められるのです。

    以上は、Cなどのプログラミング言語をきちんとマスターしている人には当然の話ですから、日常的には「aにbを加える」でも何の問題もなく話は通じます。ただ、ちゃんと「実は変数そのものではなく、値の計算をしているのだ」ということも認識できていることは大切です。この辺の認識が曖昧だと、さらに進んだ学習をする際に躓きを招く恐れがあります。
     たとえば、Cを学習していてポインタがなかなか分からない人の場合、変数とその中身の区分けがきちんとできていないのが混乱の原因であることも多いようです。

     話を戻しましょう。
     最後の行ですが、aに対して、格納する値の表示をさせています。
     さて、お分かりとは思いますが、最初のCのコードと2番目の架空言語のコードでは、やっていることは同じです。何が違うのかと言えば、それは架空言語の例はオブジェクト指向の書き方をしてあるということです。
     Cの例では、+=という演算子も、printf()という関数も、変数から取り出した「値に対して」操作をしています。
     それに対してオブジェクト指向では、変数(オブジェクト)に対して「操作を依頼するような」書き方になっているのです。
     aの直後にドットでつながっているadd()とprint()はそれぞれIntTypeオブジェクトのメソッドです。呼び方はメソッドだろうが関数だろうが何でもいいですが、IntTypeとして定義されたオブジェクトが持つ機能であるということを理解してください。
     ちなみに、今のところ、オブジェクトと型と変数という言葉が混ぜこぜに使われていますが、そのうち整理をしますので、今は似たようなものだと思っていればOKです。

     どうでしょう? ここまでは理解できましたか?
     もし、ご質問があればモサ伝編集部(mosaden-toukou@mosa.gr.jp)まで。

    ニュース・解説

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

    ● Carbon ドキュメント & サンプル & SDK ナビゲーション(2006/08/18)

    【開発環境】

    WWDC2006も無事終了しました。筆者的には、予想通り64bit版のCocoaとCarbonの発表があり大変満足しています。ただし、全体としては「まだ何か隠されているのか?」という感じが拭えず、ちょっと「お預け」をくったようなWWDCではありました(笑)。まだ詳しい内容は書けないのですが、64bit版アプリケーションを作成する上での注意点についてもだいたい予想範囲内でした。ただ一点だけ「え〜、そんなことをしても大丈夫なの?」という驚きがありましたが、その件については可能な時期が来たら、API徒然草の方で詳しく解説したいと思います。

    Mac OS X 10.5(Leoperd)では、今までの32bitアプリケーションも問題なく起動できるわけですから、大容量のメモリを消費するとか、doubleの浮動小数点演算を頻繁に実行するとかの処理が無い限り、一般的なアプリケーションが64bit化を考慮する必要はほとんどないと思います。それよりも、Mac OS X 10.4(Tiger)から試験的に実装されている(と言うか、間に合わなかった?)レゾリューション・インディペンデント・ユーザインターフェースに対応する方が重要だろうと感じています。とにかく、また仕事が増えたことだけは間違いないようですね…。

    兎にも角にも、参加された皆さん大変ご苦労様でした!。また来年、会場でお会いいたしましょう!

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

    前回から8月18日の期間中、Apple社のGuidesサイトには新規ドキュメントが多数登録されましたが、Referenceサイトへの新規登録はひとつだけでした。WWDCで発表されたMac Proのハードウェア仕様ドキュメントが登録された関係上、関連する「Developer Note」がすべて更新されています。それ以外ですと、Mac OS X Server関連のドキュメントが多数更新されています。こちらも、WWDCでインテル版Mac OS X Serverが発表された関係でしょう。加えて、Xcode 2.4についてのリリースノートやデベロッパ向け読み物が登録されています。

    「QuickTime 7.1 Update Guide」(PDFあり)(初版)
    「Mac Pro Developer Note」(初版)
    「AirPort Developer Note」
    「Audio Developer Note」
    「Bluetooth Developer Note」
    「Ethernet Developer Note」
    「FireWire Developer Note」
    「Hardware Developer Note Terms and Abbreviation」
    「CI Developer Note」
    「RAM Expansion Developer Note」
    「Universal Serial Bus Developer Note」
    「Video Developer Note」
    「Apple Remote Desktop Focus on Task Server」(PDFあり)(初版)
    「Audio Unit Programming Guide」(PDFあり)(初版)
    「Core Audio Overview」(PDFあり)(初版)
    「Mac OS X Security Configuration Guide」(PDFあり)(初版)
    「Mac OS X Server Collaboration Services Administration」(PDFあり)
    「Mac OS X Server Getting Started」(PDFあり)
    「Mac OS X Server Getting Started Supplement」(PDFあり)(初版)
    「Mac OS X Server Security Configuration Guide」(PDFあり)(初版)
    「Mac OS X Server Upgrading and Migrating to Version 10.4 or Later」(PDFあり)
    「Quartz Composer Web Kit Plug-in Programming Guide」(PDFあり)(初版)
    「Smart Card Setup Guide」(PDFあり)(初版)
    「Xsan Administrator’s Guide for Xsan 1.4」(PDFあり)
    「Xsan Migration Guide for Xsan 1.4」(PDFあり)

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

    「QuickTime 7.1 Update Reference」(PDFあり)(初版)

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

    リリースノート

    「Xcode 2.4 Release Notes」
    「Xcode 2.3 Release Notes」
    「Core Audio Release Notes」

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

    「Bare Bones Uses Platform Innovation for Yojimbo」(読み物)

    http://developer.apple.com/business/macmarket/yojimbo.html

    「Automating Development Tasks with Automator and Xcode」(読み物)

    http://developer.apple.com/tools/xcode/automatorforxcode.html

    前回から8月18日の期間中、新規テクニカルノートはひとつも登録されませんでしたが、新規テクニカルQ&Aの方はひとつだけ登録されました。それにしても、CarbonにはあるのにCocoaにはないユーザインターフェースオブジェクトがあったんですね(笑)。

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

    QA1485「How to create a Cocoa Disclosure Button Control」(初版)

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

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

    前回から8月18日の期間中、Apple社のSample Codeサイトには、バラエティーにとんだサンプルソースコードが16も登録されました。また、WWDCに参加された方は、Apple社のWWDC2006サイトのセッションのページから、そのセッションに関連しているドキュメントやサンプルソースコードをダウンロードできるようになっています。そちらも早めに参照しておいてください(サイトが無くなる前に…)。

    https://developer.apple.com/wwdc2006/

    「SayIt」(Web Kit関連)(初版)
    「CarbonCocoa_PictureCursor」(Carbon&NSCursor関連)(初版)
    「BlockAnimation」(Java関連)(初版)
    「Dicey」(Cocoa&Gamet関連)(初版)
    「OpenGL based game template」(Game&OpenGL関連)(初版)
    「Resizer」(Widget関連)(初版)
    「Birthdays」(Widget関連)(初版)
    「CarbonQuartzComposer_TV」(QuartzComposer関連)(初版)
    「HelloStudio」(AppleScript Studio関連)(初版)
    「Processes」(AppleScript Studio関連)(初版)
    「TextEditPlus」(Cocoa&TextEdit関連)(初版)
    「CxxNewDelete」(C++関連)(初版)
    「Carbon Porting Tutorial」(Carbon関連)(初版)
    「CarbonCocoaCoreImageTab」(CoreImage関連)(初版)
    「AttachAScrip」(AppleScript関連)(初版)
    「ComplexPlayThru」(CoreAudio関連)

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

    【デベロップメント SDK】

    前回から8月18日の期間中、Apple社のSDKサイトには新しいSDKが2つ登録されました。
    「QuickTime 7.1.2 SDK」と、同じくそのWindows用のSDKです。またToolsサイトには「Xcode 2.4」と「CHUD 4.4.2」が登録されています。Xcode 2.4では、最新のMac Proに搭載されているXeonプロセッサが64bit版であることから、PowerMac G5と同様にインテル版64bitアプリケーションを作成できるようになりました。ただし、Mac OS X 10.4.xではCocoaやCarbonが64bit対応ではありませんので、ユーザインターフェースを分離した形での開発となります。Mac OS X 10.5の登場が待ち遠しいですね!

    「Xcode 2.4」
    「Computer Hardware Understanding Development (CHUD) 4.4.2」

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

    「QuickTime 7.1.2 SDK」
    「QuickTime 7.1 SDK for Windows」

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

     ◇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=モサ伝]第216号

    2006-08-08
     

    目次

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

    MOSA理事コラム   第4回 「WWDCとインターネット」
                      岩田 勇  株式会社エルゴソフト

    MOSA会員の皆様、今年も暑い夏をどのようにお過ごしでしょうか。タイミング良くWWDCの開催の頃に私の原稿をご覧に頂くことになりましたので、少しWWDCのネタに触れてみたいと思います。

    今年のWWDCは8月7日からサンフランシスコの真ん中にあるモスコーンセンターで開催されますが、数年前まではサンフランシスコから1時間半ぐらいのところにあるサンノゼという街のコンベンションセンターでゴールデンウィーク明けに行われていました。
    参加するとなるとゴールデンウィークを含めて半月ぐらい会社を空けることになるので、毎回その準備でかなり四苦八苦した記憶があります。
    その昔はe-mailや携帯電話なんて便利な道具はありませんでしたから、日本とのやりとりは基本的にFAXになってしまい、問い合わせて回答まで1日ぐらいかかります。ですから、半月不在でも業務にも支障が無いように一通り手配する必要があったのです。(今では現地の夜中でも平気で携帯に電話が入りますから…。逆に準備は楽になりましたが…)参加する側からみれば、簡単に邪魔が入らないわけですから、この隔離された環境で1週間どっぷりと新技術に浸れるという点では楽しい一時ではあります。もちろん観光旅行ではありませんから、仕入れた最新情報を日本に報告する義務があります。その昔はキーノートが終わった後、日本の朝一の時間にあわせてホテルに戻り、速報を国際電話で報告なんてことをしていました。
    今では、キーノートが終わると速報をe-mailすることになりますが、キーノートで発表された内容をまとめ報告しても、チョット聞き漏らした箇所なんかは日本で様々な速報サイトを見ていた人間の方が詳しくて、間違いを訂正されるなんて、笑えないこともありました。
    以前はWWDCに参加するのには、最新情報を収集するという明確な目的がありましたが、最近は少々薄れてきているように感じます。
    振り返ってみると、インターネットや携帯電話という通信インフラが気がつかない内に、私たちの行動に大きく影響を与えていることに驚かされます。
    ところで、毎年WWDCでは新製品の発表があります。今年は何が発表されたのでしょうか。皆さんの予想は的中しましたか?(ちなみに私は、昨年のIntel Macの発表を当てました)
    日本にいらした皆さんはどうやってそれを知りましたか。
    やっぱりインターネットは便利なツールなんですね。

    ■プロフィール
    岩田 勇
    いわた いさむ

    株式会社エルゴソフト
    取締役マーケティング部長
    1963年生まれ。1986年エルゴソフトへ入社。
    EGBRIDGE、かな漢字変換エンジンなどの開発担当、EGWORDの開発責任者を経て、2002年より同職。
    現在のMacBook Proで、個人購入のMacとしては Mac SEから数えて10台目。
    この夏、MacBook Proのパームレストの熱さに耐えきれるか不安に思うに日々を過ごしている。

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

     さて、この原稿はWWDC前に書いておりますが、この号が配信されるころにはもう基調講演も終わり、新しい発表で話題が持ち切りなことでしょう。基調講演ではサーバ関連の発表はあまり期待できませんが、なんといっても今年の目玉はLeopardですね。これまでと同様ならばLeopardとLeopard Serverが同時にリリースされるでしょうから、Intelへの切り替えとあわせて今後の対応を考えていかなければなりません。

    さて、前回までMac OS X Serverの管理ツールについて解説してきましたが、今回はもう1つサーバ管理に役立つツールをご紹介しておきましょう。前回まではMac OS X Serverに標準で付属する管理ツールを解説してきましたが、今回ご紹介するツールはアップルの製品ではありますが、別売のソフトです。
     標準で付属する管理ツールの多くはネットワーク対応しており、リモートでの管理ができます。また、Mac OS X Serverはデフォルトでsshが有効になっていますので、「ターミナル」からコマンドラインでリモート操作することもできます。つまりほとんどの管理作業はリモートでもできるのですが、なかには画面を直接操作したい場合もあるでしょう。たとえばGUIでしか操作できないソフトをサーバ上で使うことも考えられますし、そもそもGUIでの操作のほうが慣れている方もいらっしゃるでしょう。
     そんなときに役に立つのが「Apple Remote Desktop(ARD)」です。ARDを使えば、ネットワーク上のマシンの画面をリモート操作することができます。サーバ機の場合はモニタを接続せずにヘッドレスで運用したりもしますが、そんなときでもARDを使えばリモートで画面を操作することができます。

    ARDの環境をセットアップするにはまず管理用のMac(Mac OS Xで大丈夫です)を1台用意してください。そして、管理用のMacにARDをインストールします。ARDですが、こちらは別売のソフトですのであらかじめ購入しておく必要があります。ARDのライセンスには2種類ありApple Storeでの価格は以下のとおりです。

    ARDの価格
    ・Unlimitedマネージドシステム版 57,000円
    ・10マネージドシステム版 34,000円
    http://www.apple.com/jp/remotedesktop/

     ARDの最新版はVer3が最近リリースされ、2種類のライセンスが用意されています。2つのライセンスの違いですが、10マネージドシステム版では同時に10台以下のマシンしか管理することができません。Unlimitedマネージドシステム版では同時に管理できるマシンの台数に制限はなく、無制限に管理することができます。
     一方ARDの管理対象となるマシンですが、Mac OS XおよびMac OS X ServerにはあらかじめARDの機能が備わっています。この機能を有効にするには「システム環境設定」の「共有」で「Apple Remote Desktop」を開始します。また開始にするだけではダメでして、別途アクセス権の設定も行う必要があります。
     ARDでマシンを管理するには、管理用のMac上であらかじめ管理対象のマシンをリストに追加しておく必要がありますが、このときユーザ認証が求められます。つまり、管理対象のマシン上でアクセス権の設定を行い、ユーザ認証に用いるアカウントを指定しておく必要があるのです。またARDでは様々な操作ができますが、許可する操作もアクセス権の設定で指定できます。

    準備が整えばさっそく管理用のMac上で、管理対象のマシンをリストに追加しましょう。管理対象のマシンが多い場合は、「iTunes」のようにマシンをグループ化して管理することもできます。マシンをリストに追加したらまず「管理」メニューから「クライアントソフトウェアをアップグレード」を実行しましょう。ARDの最新版はVer3ですが、Ver3はまだリリースされたばかりですので、管理対象のマシンには少し古いバージョンのARDが組み込まれています。
     アップデートを実行しないと最新版で追加された機能が使えなかったりしますので、まずはアップデートを行いましょう。アップデート作業は、管理用のMac上で一括して実行できます。複数のマシンを同時にアップデートすることもできるのですが、同時にアップデートを行う場合動作が不安定になることがあります。1台1台個別にアップデートを行う場合には特に問題はありません。

    さて、ARDでどのような管理ができるかですが、基本的な機能としては監視と制御があります。監視機能では複数台のマシンの画面を同時に監視することができます。監視対象のマシンが多くて1画面に表示しきれない場合は、定期的に画面を切り替えながら(自動的に切り替わります)すべてのマシンを監視することができます。ARD3では画面監視用のDashboardウィジェットも用意されています。
     制御機能では管理対象のマシンの画面をリモートで操作できます。ARD3からは制御の機能が強化されて、ローカルマシンとリモートマシンとの間でドラッグ&ドロップによるファイルのコピーが出来るようになりました。またクリップボードの内容もローカルとリモート間でやり取りすることができます。ARD2までは制御中の画面操作はそのまま管理対象のマシンの画面上に表示されていましたが、ARD3からは新たにカーテンモードが加わり、このモードで制御しますと管理対象のマシン上では画面がロックされて、管理者の操作を隠すことができるようになりました。
     その他にもARDではパッケージをリモートインストールしたり、管理対象のマシンの情報(ハードウェアおよびソフトウェアに関する情報)をレポートしたり、Unixコマンドを送信したりできます。また、管理対象のマシンのスリープ、再起動、システム終了、起動ディスクの変更などもでき、複数台のマシンを管理しているときには特に威力を発揮します。これらの操作はただちに実行することもできますし、スケジュールを設定しておいて特定の日時に実行することもできます。
     ARDはシステム管理を強力にサポートしてくれますので、ぜひ導入を検討してみてはいかがでしょうか。

    つづく

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

    〜 Carbonモダンアプリケーションへの道(その1) 〜

    今回からは、「Carbonモダンアプリケーションへの道」というテーマで、Carbon APIに関連する最新の話題を取り上げてみます。

    「モダンアプリケーションを作りたければCocoaを使えば?」という意見もあるでしょうが(笑)、それを言ってしまうと本連載の意味が無くなりますので、「最近のCarbon APIも随分とモダンになったもんだ」という暖かい眼差しで気長にお付き合いください。具体的には、自作ソースコードに太古から鎮座している「レガシーなCarbon API」を、最近登場した「モダンなCarbon API」に差し替えていく作業を解説します。例えば描画処理であれば、QuickDraw APIを用いている箇所をQuartz 2D(Core Graphics)APIで差し替える作業などが対象となります。当然、新しいAPIはMac OS Xに最適化されていますので、こうした差し替え作業の積み重ねが、自作アプリケーション全体のパフォーマンスや操作性の向上につながるわけです。

    それから、今回は、モダンAPIへの差し替え作業を急がなければならないもうひとつの大きな理由が存在します。Mac OS Xが登場した時、我々デベロッパーは自作アプリケーションを延命するため、ソースコードに記していた旧ToolBox APIの多くをCarbon APIへと差し替えました。この作業を「アプリケーションのCarbon化」などと呼んでいましたが、確か、System 7が登場した時や、MacintoshのCPUがIBMのPowerPCに切り替わった時にも、小規模でしたが、そうした差し替え作業を行った記憶があります。しかし、インテル版CPUを搭載したMacintoshの登場で発生した「Universal Binary化」においては、こうしたAPIの差し替え作業は不要でした。そんなわけで、少々油断をしていたら、実際にはその裏で、Apple社による今までにない大規模な「API切り捨て作戦」が展開されていたのです。

    Carbon Frameworkを用いてプログラミングをされている方は既にご存じだと思いますが、Mac OS X 10.4(Tiger)のDeveloper Tools(Xcode Tools)では、Apple社が「これからは使うことを推奨しない」と明言したAPIの存在を確認することができます。Frameworkのヘッダファイルの定義に「*** DEPRECATED ***」というコメントが入っているAPIがその対象です。Xcode 2.3で「Mac OS X 10.4(Universal)SDK」を用いている場合、もしソースコードにこうしたDEPRECATED APIが記述されていると、コンパイル中にその都度警告が表示されます。古いソースコードを実際にコンパイルして試してみると、ちょっとした規模のものでも数百、プロジェクトが大規模になれば1万を越える警告が表示される場合もあります。それほど多くのAPIが、Apple社により「推奨しない」という烙印を押されたことになるわけです。

    例えば、数百ものAPIが定義されているQuickDraw.hヘッダファイルでは、コールバック用のUniversal Procedure Pointer API(名称の最後がUPP)を除くと、生き残っているAPIはわずか60弱のみです。それ以外はすべてDEPRECATEDとなっています。また、QD.hの一部である、QuickdrawText.hやQDOffscreen.hを見てみると、既存APIは全滅していることが分かります(涙)。ところで、Xcodeが表示する警告ですが、なにやら「旧友」をバカにされているような気分になり、古くからのMacintoshプログラマにとっては感じ良くありません…。この警告の除外は、プロジェクトアイコンやターゲットアイコンを選択し、「情報を見る」で表示されるウィンドウの「ビルド」タブで行います。上部のコレクションメニューから「GNU C/C++コンパイラ4.0」「警告」を選び、「推奨されない関数についての警告」のチェックを外しておけばOKです。

    では、DEPRECATEDと言うのは具体的に何を指すのでしょうか?そして、このAPIの運命はいったいどうなるのでしょうか(Cocoaにもあるらしい)?「推奨されない」とは、こうしたAPIがそのうちシステムから完全に取り除かれることを意味しています。とは言っても、今すぐ取り除いてしまうと、そのAPIを用いているアプリケーションは、その時点で起動不可になります。昔々、Apple社は、SCSI ManagerのAPIを完全に削除してデベロッパーから大ひんしゅくを買ったことがありました。そうした経験上、突然の廃止はあまりにも無謀だと理解しているでしょうから、API自体はしばらくの間システム中に残るはずです。その代わり、最新SDKのヘッダファイルからはAPI定義が削除されるでしょう。現状でも、ヘッダファイルには定義されていないが、システム内には存在していて機能しているAPIがいくつかあります。

    こうした移行はいつ起こるのでしょうか?それがデベロッパーとして最も気になる点ですが、困ったことにApple社はその時期を明言していません。つまり「そのうち」と言うことのようです(涙)。例えば、ヘッダファイルからの定義削除がMac OS X 10.5で実行されたと仮定しましょう。Xcodeプロジェクトにおいて、最新のSDK(Mac OS X 10.5 SDK)を用いCarbon Frameworkをリンクすると、DEPRECATED APIを含んだソースコードは「未定義エラー」で正常にMakeできなくなります。つまり、DEPRECATED APIをソースコードにひとつでも含んでいるアプリケーションは、10.5の最新SDKを用いて開発を継続することが不可能になるわけです。ただし、API自身はシステムに存在しているので(多分)、Mac OS X 10.4 SDKを用いて開発したアプリケーションは、10.5でも起動できます。

    さて、Mac OS Xが登場して既に5年以上経過していますので、モダンだと言っても導入されてから随分と時間が経っているAPIもあります。しかし、いまだしぶとくMac OS 9が生き残っている現状を見れば、有名なアプリケーションであろうが、そのソースコード内にレガシーAPIが大量に生き残っている可能性は大です。まあ、今回のような大規模なAPI廃止は、デベロッパー側にも大きな負担をかけますので、差し替え作業まで手が回らないのが現実でしょう(Universal Binary化だけでも大変なのに…)。そんなわけで、この件に関しては、Apple社の舵取りが重要な意味を持ちます。うまく裁いて欲しいところです。そして、お願いですから、API自体の破棄は10年後ぐらいにしてください(笑)。

    次回は、もう少し詳しくDEPRECATED APIを調査してみたいと思います。いったい、どんなAPIが消え、どんなAPIが生き残ったのか?APIの差し替え作業をするにも、まずこの点を把握しておかなければ始まりません。

    つづく

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

    本連載では、名前は知っていてもなかなか触れる機会のないSmalltalkについて、最近話題のSqueakシステムを使って紹介しています。

    前回まで、ポップアップメニューやウインドウの出し方、クリックやドラッグ操作から情報を得る方法、ウィジェットがあらかじめ決められたモデルに仕事を丸投げする様子、などを観察しました。以上を用いて、本題の、シンプルなGUIビルダの製作にとりかかることにいたしましょう。

    なお、これから作るGUIビルダについては、Super ASCIIの1991年10月号に掲載された青木淳さんの「Smalltalkソフトウェア開発」に登場するサンプルプロググラム「ViewBuilder」を参考にさせていただきました。この連載の全記事はWebで公開されていて、現在も読むことができます。Squeakでのお気楽なプログラミングとはまた違った、プロの目線での高度なSmalltalkの操り方を垣間見ることができて面白いので、興味のあるかたは是非。

    http://www.sra.co.jp/people/aoki/SuperAsciiJ/

    ▼GUIビルダのクラス「GuiBuilder」を定義する

    クラス定義については、すでに第15回でご紹介済みのことなのですが、ずいぶんと間があいてしまいましたので、復習を兼ねて、改めて手順を示したいと思います。

    クラス定義はシステムブラウザを使います。定義済みクラスのブラウズには、そのクラス名をタイプして入力後、選択して、browse it(cmd + B)するショートカットがありました。しかし、新規にブラウザを開くには、デスクトップメニューの「開く…」から明示的に指示する必要があります。あるいは、デスクトップをクリックして(ポップアップするデスクトップメニューは無視して)cmd + B…というショートカットを使うのもよいでしょう。

    新しく作るクラスは必ず“カテゴリ”に属していないといけません。適当なクラスカテゴリが既存のものに見つからないとき、上段右端にあるクラスカテゴリ一覧枠の黄ボタンメニューから「add item…」を選んで追加できます。ここでは、たとえば「Category-MosaDen」などとして「了解」(Accept)しましょう。

    [fig.A]クラスカテゴリの追加

    クラスカテゴリ追加と同時に(あるいは、既存のクラスカテゴリを選択すると)下のコード枠にそれに属する新しいクラスを定義のためのテンプレートが現われます。「NameOfSubclass」の部分を定義したいクラス名に変えてaccept(cmd + S。黄ボタンメニューからなら「了解」)することで、クラス「Object」のサブクラスとして指定した名前のクラスを新規に作成することが可能です。上段二番目のクラス一覧枠に名前が現われれば成功です。

    [fig.B]新しいクラス「GuiBuilder」の定義

    ▼作業用のウインドウを開くメソッドを定義

    ワークスペースなどでは、クラス(ワークスペースなら「Workspace」)に「open」というメッセージを送ることでウインドウを開くことができます。これから作るGUIビルダでも、この方法を真似ることにしましょう。クラスに「open」を送信することで起動されるメソッド(クラスメソッド)「#open」は、GuiBuilderクラスのクラス「GuiBuilder class」に定義します(GuiBuilder class >> #open)。

    クラスメソッド(メタクラスに属するメソッド)の定義には、クラス一覧枠でターゲットとなるクラスを選択した状態で、その枠の下にある「クラス」ボタンを押してモードを切り替えます。

    [fig.C]クラスメソッド定義モードへの切換え

    クラス同様、メソッドも必ず“カテゴリ”に属している必要があります。ただ、クラスと違ってカテゴリを特に指定せずに定義することが可能です。そのときは「as yet unclassified」というカテゴリに自動的に分類されます。でも、#openは一般に「instance creation」というカテゴリに属していることが明らかなので(#openをbrowse it(cmd + B)して、既存の#openを一覧すると分かります)、今はこれに倣うことにします。

    メソッドカテゴリ一覧枠(上段右から二番目)の「– all –」をクリックして選んでから、改めて同じ枠の黄ボタンメニューの「new category…」を選び、ポップアップするメニューから「instance creation」を選択します。リストに「instance creation」が追加されたら、それをクリックして選択した後、下のコード枠で、次のコードを入力(タイプするか、このメールから最後のコメント行までをコピー&ペースト)し、accept(cmd + S)します。

    open
       | window |
       window := SystemWindow labelled: 'GUI Builder'.
       window model: self new.
       ^ window openInWorld
    
    "GuiBuilder open"

    イニシャルを尋ねられたら適当に答えて「了解」(Accept)します。メソッド一覧枠(上段右端)に「open」が現われれば成功です。最終行のコメントは、動作チェックに使えます。ダブルクオーテーション「”」の内側(行頭の「”」と「G」の間か、末尾の「n」と「”」の間)をダブルクリックすると、ダブルクオーテーションで括られた中味が選択されるので、その状態でdo it(cmd +D)します。「GUI Builder」というタイトルのウインドウが開けば成功です。

    [fig.D]GUIビルダウインドウの呼び出し

    ▼ちょっとした修正

    前述の「GuiBuilder class >> #open」の記述中にある、a SystemWindowに送られている「model: self new」というメッセージは、そのセレクタ「#model:」が示すように、パラメータがモデル(Modelのサブクラスのインスタンス)であることを期待します。ところが、GuiBuilderはModelのサブクラスにはしていないので、今は大丈夫なように見えても、将来、なにかしら問題が起こりそうに思えます。GuiBuilderの定義を変更することで、これを修正しておきましょう。

    ブラウザに戻って、クラス一覧枠の「instance」ボタンを押してブラウズモードをメタクラスからクラスに切り替えてください。クラスの定義が下のコード枠に現われるので「Object」を「Model」に書き換えてaccept(cmd + S)します。「Recompiling GuiBuilder」という表示が出て、それが消えれば変更作業は終わりです。

    [fig.E]ObjectからModelへのスーパークラスの変更

    もっとも、実のところObjectには、歴史的な経緯でModelの主要なメソッがすでに定義済みのため、Objectのまま進めても問題はないはずなのですが、一応、念のため。

    次回は、ウインドウのタイトルバー左寄りに設置されているボタンでポップアップする「ウインドウメニュー」に、ウィジェット設置のためのメニュー項目を追加する方法を紹介します。

    [fig.F]GUIビルダウインドウの「ウインドウメニュー」

    バックナンバー:

    ニュース・解説

     今週の解説担当:木下 誠

    ———————————————————————-
    WWDC 2006開幕!
    ———————————————————————-

    いよいよ、8月7日からWWDCが始まります。この記事が配信されている頃には、基調講演も終わっている事でしょう。多くの噂に上ったハードウェアは登場しましたか?そして、Leopardの出来はいかがでしょう?

    AppleのWWDCのWebサイトには、「WWDC 2006 Attendee Site」というものが登場しています。トップページよりログインすることで、視聴するセッションのスケジュールを組み立てる、アジェンダを作成する事が出来ます。これを活用してみるのも、面白いかもしれません。

    WWDC 2006
    https://developer.apple.com/wwdc2006/

    ———————————————————————-
    多数のサンプルが登場
    ———————————————————————-

    この記事を書いているのはWWDCの前ですが、ADCのサイトに多くのサンプルが登場しています。

    対象となる範囲も、JavaやAppleScriptから、QuartzComposerまで、多岐にわたっています。

    おそらく、WWDCが始まれば、もっと多くのサンプルが登場する事でしょう。

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

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

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

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

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

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

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

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

    AttachAScript
    http://developer.apple.com/samplecode/AttachAScript/index.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=モサ伝]第215号

    2006-08-01

    目次

    • 「Wonderful Server Life」      第13回  田畑 英和
    • 藤本裕之のプログラミング夜話 #96
    • 高橋真人の「プログラミング指南」  第94回
    • ニュース・解説                小池 邦人

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

     WWDCまであとわずかになりました。現在Power PCベースのマシンはXserveとPower Macのみになってしまいましたが、はたしてWWDCでIntel版のXserveは発表されるでしょうか。XserveにはMac OS X Serverがバンドルされていますので、Intel版のXserveがリリースされればMac OS X Serverも正式にIntel対応するのではないかと思われます。

    □Admin Tools
     さて、前回に引き続きMac OS X Serverの管理ツールについて解説します。今回とりあげます管理ツールのうち「サーバ管理」と「ワークグループマネージャ」は特に利用頻度の高いツールになりますので、より詳しく解説したいと思います。

    ・サーバ管理
     Mac OS X Server上で稼働する各種サービスの監視および設定を行います。様々なサービスがMac OS X Serverに搭載されていますが、おおまかに分類しますと以下のようなサービスが「サーバ管理」から扱えます。

     (1)ファイルサービス:AFP、FTP、NFS、Windows
     (2)ネットワーク:DHCP、DNS、NAT、VPN、ファイアウォール
     (3)インターネット:Web、メール、WebObjects、アプリケーションサーバ
     (4)ディレクトリサービス:オープンディレクトリ
     (5)その他:iChat、NetBoot、QuickTimeストリーミング、Xgrid
         ソフトウェア・アップデート、プリント

     「サーバ管理」でサーバの管理を行うにはサーバへの接続を行います。これはサーバ機上で直接操作する場合であっても同様です。複数のサーバに接続することもできますので、1台のマシン上で複数のサーバを管理することもできます。
     ほかのツールにも共通することですが、「iTunes」のように1ウインドウで操作を行う画面構成になっています。サービスによっては画面が入り組んでかえってどの画面で操作をしているのか分かりづらい部分もありますので、画面上で迷子にならないようご注意ください。
     管理画面は各サービスごとに用意されており、サービスの一覧からいずれかのサービスを選択して操作を行います。サービスごとに画面の構成は異なりますが、サービスのログを表示したり、稼働状況をグラフで表示するような画面が用意されています。v10.4の「サーバ管理」からはログファイルのパスが画面上で表示されたり、画面上でログの検索ができるようになりました。
     各サービスの設定画面は、さらにいくつかの画面から構成されています。基本的にはGUIでお手軽に設定ができるのですが、画面上の表記だけでは意味が分かりづらい部分もありますので、別途マニュアルを読み込まないと完全には把握しきれません。本連載ではこれから各サービスの解説を始めていく予定ですが、待ちきれない方はじっくりマニュアルを読んでください:-)
     「サーバ管理」で設定した内容はファイルに保存できますので、一時的に設定を変更する場合でもあらかじめ設定内容を保存しておけばいつでも保存時の内容に設定を戻すことができます。
     サービスの監視と設定のほかに、「サーバ管理」ではサーバ全体の管理もできます。Mac OS X Serverのシリアル番号を入力したり、ソフトウェア・アップデートを実行することができます。サーバ機のCPU使用率をグラフ表示する機能もあり、デュアルCPUの場合はきちんと2本のグラフを表示してくれます。

    ・ワークグループマネージャ
     「サーバ管理」と並んで使用頻度の高いツールです。このツールは大きく分けて次の機能があります。

     (1)共有ポイントの管理
     (2)ネットワーク表示の管理
     (3)アカウントの管理
     (4)環境設定の管理

     (1)の共有ポイントの管理ではファイルサービスで共有するフォルダの設定を行います。アクセス権の設定や各プロトコルごとの設定ができます。V10.4からはファイルのアクセス権としてWindowsと互換性のあるACLのアクセス権もサポートされるようになりました。ACLのアクセス権を使えば1つのフォルダにユーザやグループを複数設定し、それぞれに対してより細かなアクセス権の設定ができます。
     (2)のネットワーク表示の管理はv10.4からの新機能です。MacではFinderからネットワーク上のサーバを自動的にブラウズすることができますが、Finderのネットワーク表示をサーバ上で管理することができます。例えばサーバをグループ化してフォルダごとに整理して表示することができます。
     (3)のアカウント管理では、ユーザ、グループ、コンピュータをアカウントとして管理できます。ネットワーク上で共有可能なネットワークユーザの作成には「ワークグループマネージャ」を使用します。また、v10.4からはグループのメンバーとしてほかのグループを登録できるようになりました。ここで作成したアカウントは環境設定の管理で使用し、コンピュータアカウントはネットワーク表示の管理でも使用します。
     最後に(4)ですが、通常は各クライアント上で行う環境設定(たとえばDockの設定)をサーバ上で一元管理できます。環境設定は(3)で作成したユーザ、グループ、コンピュータ、それぞれに対して適用することができます。例えば全てのユーザのDockの設定を管理者が一括して行うようなことができます。
     これらの機能の多くはディレクトリサービスを利用していますので、「ワークグループマネージャ」はディレクトリサービスの管理ツールと言ってしまってもよいでしょう。

    ・サーバモニタ
     こちらはXserve専用の管理ツールです。Xserveのドライブや温度などハードウェアに関する状態を監視し問題が発生すれば警告を表示します。サーバの再起動や停止をリモートで実行することもできます。

    ・システムイメージユーティリティ
     最後のツールになりますが、このツールでNetBoot用のシステムイメージを作成します。システムイメージとはようするにブート可能なディスクイメージのことです。NetBootシステムではサーバ上に配置されたディスクイメージからクライアントを起動します。

    つづく

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

     承前。今回は書くことが多いので「前回までのあらすじ」はなし。あれ、なんだったっけ? というヒトは自分で確認してくだされ。さて、ビュー上でカーソルの形が変わる領域を動かすためにはそのためのコードを書かねばならぬ。まずは問題の矩形をインスタンス変数として、initWithFrame: で以下のように初期化、drawRect: では色違いで描画するようにする。当然ながらカーソルの形を指定するメソッド、resetCursorRects も以下のようになる。ここまではいいよね。

    - (id)initWithFrame:(NSRect)frameRect {
         if ((self = [super initWithFrame:frameRect]) != nil) {
              openHandRect = NSMakeRect(10, 10, 100, 100);
              pointingHandRect = NSMakeRect( 120, 120, 100, 100);
              dragging = NO; // これはドラッグ中かどうかのフラグ。
         }
         return self;
    }
    
    - (void)drawRect:(NSRect)rect{
         [[NSColor yellowColor] set];
         NSRectFill(openHandRect);
         [[NSColor cyanColor] set];
         NSRectFill(pointingHandRect);
    }
    
    -(void)resetCursorRects {
         [self addCursorRect:openHandRect
                         cursor:[NSCursor openHandCursor]];
         [self addCursorRect:pointingHandRect
                         cursor:[NSCursor pointingHandCursor]];
    }
    


     これに、シアンで塗られるpointingHandRectをmouseでドラッグして動かすためのコードを追加する。ま、いろいろ工夫の余地はあるけど一応、以下のようなもんですかね。

    - (void)mouseDown:(NSEvent*)theEvent {
         NSPoint   p = [self convertPoint:[theEvent locationInWindow]
                                    fromView:nil];
         if(NSPointInRect(p, pointingHandRect) == YES){
              dragging = YES;
              pointingHandRect = NSMakeRect(p.x-50, p.y-50, 100, 100);
              [self setNeedsDisplay:YES];
         }
    }
    
    - (void)mouseDragged:(NSEvent*)theEvent {
         if(dragging == YES){
              NSPoint   p = [self convertPoint:[theEvent locationInWindow]
                                    fromView:nil];
              NSRect    r = [self bounds];
              if(NSPointInRect(p,r) == YES){
                   pointingHandRect = NSMakeRect(p.x-50, p.y-50, 100, 100);
                   [self setNeedsDisplay:YES];
              }
         }
    }
    
    - (void)mouseUp:(NSEvent*)theEvent {
         [self mouseDragged:theEvent];
         if(dragging == YES){
              dragging = NO;
         }
    }
    


     これでpointingHandRectは動くようになったがマウスカーソルは相変わらず最初の位置でしか変わらない。これを変えるにはつまりresetCursorRects をもう一度呼べばいいのだが、このメソッドの解説には「こいつを直接呼び出すな、代わりにNSWindowのメソッド、invalidateCursorRectsForView: を使え」とある。なんだかとっても回りくどいよな気がするが、mouseUp: の「dragging = NO;」の直後に以下のステートメントを足せばOKである。

    [[self window] invalidateCursorRectsForView:self];

     いやしかし、ほんとに作ってみたヒトは気付いていると思うけどちょっと問題が残ってるよね? 次回はそれについて考えてみよう。
    (2006_07_28)

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

    プログラマのためのオブジェクト指向再入門(2)

    〜オブジェクト<1>〜

     こんにちは、高橋真人です。
     さて、前回から始まりました、オブジェクト指向にプログラマの視点から独断的な解説を加えるシリーズですが、お話の進め方として、オブジェクト指向技術に関連する言葉を一つずつ取り上げ、それについて関連する話題を繰り広げるという形で行きたいと思います。

     さて最初の言葉ですが、そのものズバリ「オブジェクト」です。
     オブジェクト指向というからには、この言葉がなければ始まらないわけですが、オブジェクト指向に取り組み始める人にとって、この言葉ほど混乱の元になっている言葉もないのではないか、という気もするぐらいに取り扱いに注意を要する言葉でもあります。

     そもそも、なぜ、オブジェクト指向というのでしょうか。

     世にある多くのオブジェクト指向入門書の中には、「オブジェクトとは、すなわちモノです」と説明しているものがかなり見られます。
     確かにこの説明は間違っていません。オブジェクト指向技術を日常的に使っている開発者にとって、この「オブジェクト=モノ」という考え方は極めて自然です。ところが、これがオブジェクト指向をこれから学ぼうとする入門者にとっては、必ずしもそうでない場合があるのです。
     「群盲象を撫でる」という言葉があります。これは、目の見えない人が何人かいて、それれぞれが初めて遭遇する「象」という動物を手で触ったイメージから「象とはどのようなものか」を構成する例えです。
     しっぽを触った人は「象とは縄のようなものだ」と言い、耳を触った人は「象とはウチワのようなものだ」といい、足を触った人は「太い柱のようなものだ」と言うわけです。人間には想像力というものがあるために、自分が見たり経験したものから、情報の欠けている部分を想像力で補って、全体のイメージを構築します。そのため、よほど注意をしないと、俗にいう「言葉が一人歩きする」という状態になってしまうわけです。
     オブジェクト指向を理解する上で「オブジェクトとはモノである」という説明を聞いた人の中には、実際に物体(つまり、モノ)が動き回っているイメージが浮かび、「プログラムの内部で『何かの物体』が動くのか?」なんてことを想像したりします。
     先の象の例で言えば、ひとたび正しく象という言葉の中身を理解できた人であれば、たとえ耳だけを触ったとしても、触っていない他の部分を正しく補うことができるので、「ウチワのようだ」などと思ったりはしません。
     ですが、全体像が見えていない状態で、「欠けている部分」を正しく補える人はまれです。オブジェクト指向とは言っても、それまでにやっていたプログラミング手法(ほとんどは構造化指向のものでしょうか)と極端にかけ離れるものではないのですが、すべての学習者が必ずしもそうは考えません。

     私自身の経験を元にすると、例えばCでプログラミングを経験していて、そこからC++なり、Javaなりに踏み入ろうとした場合、「オブジェクト指向」という言葉を意識し過ぎると、あたかもそれまでやっていたプログラミングとは全く違う概念がそこに存在するのだと想像をしてしまいます。
     もちろん新しい言語を学ぶので、何らかの入門書なりリファレンスなりをいろいろと目にしながら、見よう見まねでコードを紡いでいくわけですが、C++やJavaであれば、当然それまでに自分が書いていたCのコードとそんなに見た目には変わらないので、それがオブジェクト指向だということに気が付きません。
     特に、C++に至ってはオブジェクト指向専用の言語ではなく、あくまでハイブリッドな言語であるため、「私は言語としてはC++を使っているが、全然オブジェクト指向にはなっていない」というように思うわけです。(ちなみに、「CのソースコードをC++のコンパイラでビルドしている」というような話をしているのではありません。)

     そんなわけで、私は「とりあえず『オブジェクト』という言葉を一時的によけておくことはできないか」と考えてみました。しかし、残念ながらこの技術には既にオブジェクト指向という名前が付いてしまっているのです。
     たとえば、「オブジェクト指向と呼ばずに、いっそ○×△指向と呼ぶ」ことにしたとしたら、「オブジェクト指向を学びたい・身につけたい」と思っている人から見向きもされない恐れがあります。つまり、「ん? ○×△指向? これは私の学びたいオブジェクト指向とは別のものだな」となってしまうわけです。
     じゃあ、ってんで、後ろにカッコ書きで付けて「○×△指向(オブジェクト指向)」とやってしまったら、結局のところ別の名前を用意した意味があんまりないですし。

    ですのでオブジェクトという言葉を使うのをやめることは諦めて、「オブジェクト指向におけるオブジェクトとは、こういうものなんです」という切り口で説明をするしかないな、と私は考えたわけです。だからといって「つまり、オブジェクトとはモノなんです」とやるつもりはもちろんありません。

    いろいろ考えた末に私が思い付いたのは、「変数=オブジェクト」という切り口です。
     厳密なことを言うと、この表現はあまり正確ではないかもしれません。しかし、実際のところオブジェクトをプログラムのコードの中で表現する場合には必ず変数はつきものですし、コードを書くという方向からオブジェクト指向にアプローチする場合には、必ずしも悪い切り口ではないなと思うわけです。

    さて、オブジェクトについて話すと言いながら、弁解めいた言葉が並んでしまいました。どちらかというと初心者向けというよりは既にオブジェクト指向を理解している人に対しての言い訳のような話だったかもしれません。
     ですがこれからは、全面的に初心者向けにお話しします。すべての初心者に向けてというよりは、「今までいろんな入門書を読んで、試してみたけど、今ひとつピンと来ない」といった人に向けてのお話です。 さらに、説明の内容はあくまで「オブジェクト指向という概念を理解するための、一つの方便」であるということを認識した上で読んでいただく必要があります。したがって、必ずしもこれからオブジェクト指向を学ぶすべての人にとって適切な解説記事でもないことをお断りしておきます。
     では、どのような人に向くのかということですが、一つの目安として「Cを学ぶ際に、ポインタの概念がなかなか分からなくて苦労した経験のある人」というのが上げられるかもしれません。前にも書きましたように「オブジェクトという言葉の想起するイメージに振り回される」人がいるわけですが、これはポインタに関しても似たようなことが言えると思うのです。「ポインタ」という言葉も、習得済みの人にとっては「指す」という概念がコードを書く上でも便利に使えますが、つまずく人にとってはこの「指す」という理屈がかなりやっかいだったりもします。
     ポインタを習得するのに苦労した人は、きっとオブジェクト指向を学ぶ時にも苦労をしているだろうと私は思うわけです。
     さてそんなわけで、次回もオブジェクトについてのお話を続けますが、技術を習得済みの人にとっては余り益の多くない記事だと思いますので、次回以降は「入門者限定」ということにさせていただきます。
     経験者に対する配慮は極めて抑えるつもりですので(笑)、そこのところをよろしくお願いします。

    ニュース・解説

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

    ● Carbon ドキュメント & サンプル & SDK ナビゲーション(2006/07/28)

    【開発環境】

    いよいよ来週からWWDC2006が始まります。今回の目玉はLeopard(Mac OS X 10.5)のプレビュー版で決まりですが、発表されたばかりのインテル社製CPU「Core 2 Duo」を搭載した新型MacProやXserveのデビューも間違いないところでしょう。筆者としては、Boot Campだけではなく、「Parallels Desktop」と同じようにCPU仮想化技術を用いたバンドルソフト、Front Row用SDK(ありそう)、できればiPod用SDK(ありえないか?)などの発表もあると嬉しいかぎりです。

    ですが、個人的に一番期待しているのは、64bit版のCocoaとCarbonについて何らかのコミットメントがなされることです。現在、興味を持って開発している対象処理が、とんでもなくメモリを消費するということも一因なのですが、1プロセス4GByteの壁を何とか突破したいわけです。Mac OS X自体が64bitアドレッシングに対応していても(既にG5では可)、やはり両Frameworkが対応していないと、やれることが大きく制限されます。

    ビジュアルのリアルタイム処理を行うアプリケーションにとって、ユーザインターフェース部分と処理エンジン部分の分離開発は向きません。ヘッダーファイルに記載されている「DEPRECATED」(推奨しない)APIは省いてもかまいませんので(多分そのつもりだろうけど)、何とか早急の対応をお願いしたいものです。そう言えば、昨年のWWDC直前にも同じ様な事を書いた気がしますが、突然発表されたCPUのインテル移行騒動のおかげで、64bit版CocoaとCarbonの話はどこかへすっ飛んでしまいました(笑)。

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

    前回から7月28日の期間中、Apple社のGuidesサイトとReferenceのサイトには数多くのドキュメントが登録されました。ただし、大部分は今までの内容のマイナーチェンジです。今回は、その中で初版と内容が大幅変更になったドキュメントだけをピックアップしました。「Deploying Mac OS X Computers for K-12 Education」や「QuickTime 7.1 User’s Guide」などは、デベロッパ以外の方にも大変有用ですから、早急に日本語訳を出して欲しいところです(毎回言っている…)。また、デベロッパ向け読み物もひとつ登録されています。こちらの内容については、前号の木下さんの記事を参照してください。

    「Apple Remote Desktop Administrator’s Guide Version 3」(PDFあり)
    「Cocoa Event-Handling Guide」(PDFあり)
    「Deploying Mac OS X Computers for K-12 Education」(PDFあり)(初版)
    「Mac OS X Server Command-Line Administration」(PDFあり)
    「Mac OS X Server System Image and Software Update Administration」(PDFあり)
    「Mac OS X Server User Management」(PDFあり)
    「QuickTime 7.1 User’s Guide」(PDFあり)(初版)
    「Software Delivery Guide」(PDFあり)

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

    「Data Browser Reference」(PDFあり)

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

    「Going Universal: Audio Developers Catch the Wave」(読み物)

    http://developer.apple.com/audio/audiodevinterviews.html

    前回から7月28日の期間中、新規テクニカルノートと新規テクニカルQ&Aが2つずつ登録されました。テクニカルQ&Aの方は、前号の木下さんの記事も参照してみてください。

    TN2091「Device input using the HAL Output Audio Unit」
    TN2083「Daemons and Agents」

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

    QA1481「MovieAudioExtraction – Extracting all available audio samples」(初版)
    QA1446「Losing the character code when using the control key」(初版)

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

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

    前回から7月28日の期間中、Apple社のSample Codeサイトには、新しいサンプルソースコードが3つ登録されました。その中でも「GLSLShowpiece」は、OpenGLファンお待ちかね!「OpenGL Shading Language」をたっぷり使ったサンプルアプリケーションの最新版です。VertexプログラミングとFragmentプログラミングを用いた美しいデモを見せてくれます。OpenGLに興味が無い方も、最近のプログラマブルGPUの能力を知る良い機会だと思いますので、ぜひダウンロードでして起動してみてください。

    「qtdataexchange.win 」(QuickTime&Windows関連)
    「RecordAudioToFile 」(CoreAudio関連)(初版)
    「GLSLShowpiece」(OpenGL関連)(初版)

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

    【デベロップメント SDK】

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

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

     

    ◇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.