MOSA Multi-OS Software Artists

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

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

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

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

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

    2008-03-25

    目次

    • 「「Wonderful Server Life」    第67回   田畑 英和
    • 小池邦人のCarbon視点でCocoa探求
    • ターミナルの向こうから      第22回  海上 忍 

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

      〜Open Directory編〜

     「サーバ環境設定」によるアカウント管理のグループ編です。「サーバ環境設定」を起動し「アカウント」の「グループ」を選択するとグループアカウントの管理ができます。前々回の連載で解説しましたように「システム環境設定」でもグループ(ローカルグループ)の管理ができるようになりましたが、「システム環境設定」ではネットワークグループの管理を行います。
     といいましても、機能的にはいたってシンプルですので「システム環境設定」でグループの管理ができるのであれば、「サーバ環境設定」でも特に問題なく管理ができるでしょう。
     「システム環境設定」の「グループ」画面を表示するとまずは、画面の左側に登録済みのグループのリストが表示されます。前回解説しましたように、「Workgroup」グループがあらかじめ登録されています。「システム環境設定」で登録したユーザは、このグループのメンバーとして設定されていることが確認できます。

    ◇グループの登録と削除
     まずはグループの登録ですが、ユーザの登録とよく似ています。画面左下の「+」ボタンをクリックし、次の2つのグループアカウントの属性を設定します。

    グループアカウントの属性
     ・グループ名
     ・ユーザ名

     グループなのに「ユーザ名」となっているのですが、これはたんにリソースの翻訳上の問題です。英語環境で「システム環境設定」を起動してみると分かるのですが、「Short Name」が英語環境での表記です。ユーザ/グループに関わらずShort Nameをユーザ名と訳してしまっているのですね。
     「グループ名」は日本語の入力が可能ですが、「ユーザ名」に日本語を入力することはできません。またユーザアカウントと同様に、グループアカウントでも登録後は「システム環境設定」から「ユーザ名」を変更することは出来ません。ちゃんと名前を決めてからグループを登録しましょう。「グループ名」のほうは後からでも変更は可能です。
     グループを登録すると自動的に「/グループ」フォルダ内にグループのユーザ名でグループフォルダが作成されます。グループ名が「sample」の場合にはグループフォルダのパスは「/グループ/sample/」なります。さらに画面左側のグループリストには各グループのメンバー数が表示されます。

     次にグループの削除方法ですが、左側のグループリストから削除するグループアカウントを選択し、左下の「ー」ボタンをクリックします。

    ◇グループ設定
     「システム環境設定」の「グループ」画面は、さらに「グループ設定」と「メンバー」の2画面から構成されています。それでは「グループ設定」からみていきましょう。

     「グループ設定」ではまず「グループ名」と「ユーザ名」の確認ができます。先ほど申し上げたように「グループ名」は後から変更可能です。ただし、他のグループと同じ名前を設定することはできません。
     あとはグループサービスとして次の項目のリンクが表示されます。

    グループサービス
     ・ファイル共有フォルダ
     ・メーリングリスト
     ・Wikiとブログ
     ・Webカレンダー
     ・メーリングリストのWebアーカイブ

     これらのリンクが機能するにはあらかじめサービスの設定が必要なものもありますが、それぞれ次のようになっています。
     まず「ファイル共有フォルダ」ですが、グループ登録時に作成されたグループフォルダをFinder上で表示します。「メーリングリスト」は「メール」アプリケーションを起動しグループ宛の新規メッセージを作成します。グループ宛のメールアドレスは次のようになります。

    ・グループ宛のメールアドレス
     グループのユーザ名@ホスト名

     server.example.com上のsampleグループであれば、このグループ宛のメールアドレスはsample@server.example.comになり、メールを送信すればグループの各メンバーにメールが送られます。
     あとの3つはそれぞれLeopard Serverで新しく導入されたWikiの各画面へのアクセスになります。WikiですのであらかじめWebサービスが正しく設定されサービスが有効になっている必要があります。

    ・「グループ設定」画面
    http://www.htabata.com/Site/LeopardServer/Pages/Server_Preferences%28Standard%29.html#10

    ◇メンバー
     「メンバー」画面ではその名前のとおり各グループのメンバー設定を行います。「メンバーシップを編集」ボタンをクリックすると登録済みネットワークユーザの一覧が表示されますので、グループのメンバーに加えるユーザをチェックします。逆にメンバーから外す場合にはチェックを外します。メンバーの編集が終われば最後にもう一度「メンバーシップを編集」ボタンをクリックします。

    ・「メンバー」画面
    http://www.htabata.com/Site/LeopardServer/Pages/Server_Preferences%28Standard%29.html#13

     以上が「システム環境設定」でのグループアカウントの管理になります。これで「システム環境設定」を使ったアカウント管理については一通り解説したことになりますが、サーバ構成を「ワークグループ」にした場合にはここにさらに機能が追加されますので、次回はそちらの機能について解説したいと思います。
    次回へつづく                             

    小池邦人のCarbon視点でCocoa探求(2008/03/21)

    〜 NSDocumentメソッドのオーバライド 〜

    今回は、MyDocument.mでオーバライドすべきNSDocumentメソッドの内容を解説します。こうしたメソッド(候補)は、「Cocoa Document-based Application」プロジェクトを新規作成した時点で、最初から5つだけ記述されています。

    (1)- (id)init

    initは、MyDocumentの初期化メソッドです。MyDocumentのインスタンスが作成される時に何か独自の初期化が必要であれば、このメソッドをオーバライドします。本アプリケーションでは、画像ファイルのパス名などを「ImageFile」オブジェクトに保存することになります。その配列を保管しているNSMutableArrayは、MyDocumentのインスタンス変数(_list)ですので、最初にそれを作成して初期化する必要があります。

    @interface MyDocument : NSDocument
    {
       NSMutableArray    *_list;
    }
    @end
    


    後々、MyDocumentのインスタンス変数の種類は増えるかもしれませんが、とりあえず今回のinitは以下のようになります。

    - (id)init
    {
       if( self=[super init] )
           _list=[[NSMutableArray alloc] init];    // NSMutableArrayの作成と初期化
       return self;
    }
    


    独自の初期化をする前に、スーパークラス(今回はNSDocument)の初期化を実行することを忘れないでください。

    (2)- (NSString *)windowNibName

    windowNibNameメソッドでは、ドキュメント表示用のウィンドウ・オブジェクトが保存されているnibファイルの名称を返します。今回のNibファイルは、MyDocument.nibですので、このメソッドは以下のようになります。これにより、NSDocumentがnibファイルを読み込み適切なウィンドウを作成してくれます。

    - (NSString *)windowNibName
    {
       return @"MyDocument";
    }
    


    ドキュメントの内容をひとつのウィンドウに表示するだけなら上記処理で問題無いのですが、アプリケーションによっては、ドキュメントの内容を複数のウィンドウに表示したい時があります。この場合には、上記メソッドのオーバライドではなく、代わりに以下のmakeWindowControllersメソッドをオーバライドします。

    (void)makeWindowControllers;
    


    通常では、このメソッドがwindowNibNameメソッドを呼んでいるわけで。しかし、直接こちらを用いる場合には、アバウトを表示する時に利用したNSWindowControllerクラスのinitWithWindowNibName:メソッドなどを使い、nibファイルからウィンドウを呼び出し、そのWindowControllerをaddWindowController:メソッドでNSDocumentオブジェクトに登録する必要があります。よって、そこでの処理は若干複雑となります。

    (3)- (void)windowControllerDidLoadNib:(NSWindowController *) aController

    windowControllerDidLoadNib:メソッドは、ドキュメント内容を表示するウィンドウが作成された直後に呼ばれます。ここでは、ウィンドウ、もしくはWindowControllerに必要とされる独自初期化(読み込んだドキュメントのデータをビューに表示するなど)を実行することになります。こちらも、先んじてスーパークラス側のメソッドを呼び出すことを忘れないでください。

    - (void)windowControllerDidLoadNib:(NSWindowController *) aController
    {
       [super windowControllerDidLoadNib:aController];
       [[aController window] center];    // Windowをスクリーンの中心に表示する
    }
    


    今回は、ウィンドウに関する初期化処理は何もありませんが(まだデータ内容の表示については何も準備されていないので)、例題としてウィンドウを強制的にスクリーンの中心に移動させる処理を追加してみました。

    (4)- (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError

    次のdataOfType:error:メソッドには、ドキュメント内容をファイルに書き出すために、それをバイナリデータ(NSData)に変換する処理を実装します。新規ドキュメントであれば、このメソッドが呼ばれる前にファイル名入力ダイアログが表示され、ユーザが保存場所と名称を入力していることになります。typeNameには、書き出すべきファイルタイプが入ってきますが、今回は対象ドキュメントが一種類だけなので(info.plistの登録されている)、何かを判断するためにそれをチェックする必要はありません。

    - (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError
    {
        NSData    *data=nil;
    
       if( data=[NSArchiver archivedDataWithRootObject:_list] ) //バイナリーデータ作成
           return data;
       else
       {
           if( outError!= NULL )
               *outError=[NSError errorWithDomain:NSOSStatusErrorDomain code:unimpErr
                                                                         userInfo:NULL];
       }
       return data;
    }
    


    バイナリーデータは、NSArchiverのメソッドである
    archivedDataWithRootObject:に対象となるNSMutableArrayを渡して作成しています。このメソッドから返されたバイナリーデータを、NSDocumentが責任をもってファイルへと保存するわけです。

    古いCocoaの解説書の中には、dataOfType:error:の代わりに
    dataRepresentationOfType:メソッドが紹介されている場合があります。それを含め、Mac OS X 10.4から、いくつかのNSDocumentメソッドがDEPRECATED宣言(推奨しない)されました。ただし、アプリケーションのターゲット環境にMac OS X 10.3以前が含まれる場合には(今回は違う)dataOfType:error:でなくdataRepresentationOfType:の方をオーバライドする必要がありますので、注意してください。

    (5)- (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName
                                                 error:(NSError **)outError

    最後の、readFromData:ofType:error:メソッドはdataOfType:error:の逆で、ファイルから読み込まれたバイナリーデータ(NSData)からドキュメント内容(NSMutableArray)を構築します。つまり、このメソッドが呼ばれる前にはファイル選択ダイアログが表示され、ユーザが対象ファイルを選び、NSDocumentがそのファイルのバイナリーデータを読み込んでくれているわけです。

    - (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName
                                           error:(NSError **)outError
    {
       BOOL                    ret=NO;
       NSMutableArray    *array;
    
       if( array=[NSUnarchiver unarchiveObjectWithData:data] ) // データからArrayを得る
    
       {
           [_list addObjectsFromArray:array]; //  インスタンス変数に保存する
           ret=YES;                           // 読み込み成功
       }
       else
       {
           if( outError!= NULL )
           *outError=[NSError errorWithDomain:NSOSStatusErrorDomain code:unimpErr
                                                                       userInfo:NULL];
       }
       return ret;
    }
    


    バイナリーデータは、NSUnarchiverのメソッドであるunarchiveObjectWithData:を使いNSMutableArrayに変換します。その後、addObjectsFromArray:でインスタンス変数の_listに追加します。copyでなくaddなのは、新規だけでなく、画像ファイルの登録追加処理にもこのメソッドを使いたいためです。またバイナリーデータ読み込みの方も、ターゲット環境が10.3以前の場合は、readFromData:ofType:error:の代わりに
    loadDataRepresentation:ofType:メソッドをオーバライドする必要がありますので、注意してください。

    ファイルのセーブとロードについては、さらに追加処理が必要となるかもしれません。ここまで準備を進めれば、次は実際に画像ファイルを登録してウィンドウに表示する仕組みを用意する番でしょう。次回は、 複数の画像ファイルを読み込んで、そのパス名などをImageFileオブジェクトへと登録する仕組みをどうするのか考えてみます。
     つづく
                                   

    ターミナルの向こうから      第22回  海上 忍

    〜  日本語文字コードについて考える (1)〜

     ふだん何気なく使用している日本語の文字列ですが、文字に置き換える処理、あるいはその前処理の段階でいろいろな苦労があります。今回は、日本語文字コードの変換・判定を行う方法について考えます。

    ・日本語文字コード
     コンピュータにおける文字とは、厳密に言えば「特定の文字に対応付けられた一意の数値情報」ということになります。その符号化された文字集合が「文字コード」であり、かなや漢字など日本語を表現するために必要な文字集合が「日本語文字コード」というわけです。
     代表的な日本語文字コードには、旧Mac OSの時代から使われている「シフトJIS」、UNIX系OSを中心に利用されてきた「日本語EUC」、インターネットメールに用いられる「JIS(ISO-2022-JP)」などがあります。その他に、多言語の文字を単一の文字コードで取り扱うことを目的に制定された「Unicode」があり、UTF-16やUTF-8などいくつかの符号化方式が存在します。
     文字コードのことを慎重に説明しようとすると、本1冊でも足りないほどですが、ここでは「ときとして文字コードは変換が必要」という点を強調しておきます。たとえば、シフトJISで記録(符号化)されたテキストを無理に日本語EUCで開くと意味不明な文字列が出現します。逆もまた然り、日本語EUCで符号化されたテキストは、シフトJISとしては開けません。MOSA伝をお読みの皆さんには、釈迦に説法のような気もしますが、いきなり文字コード変換ツールを紹介するのも唐突なので、敢えて枕詞代わりに書かせていただきました。

    ・文字コード変換ツール(標準装備)

     文字コード変換ツールは、Leopardにもいくつか収録されています。そのうち、プログラミング不要なものを紹介してみましょう。

    i) iconv
     Leopardには、オープンソースの文字コード変換ライブラリ「GNUlibiconv」と、そのインターフェイスである「iconv」コマンドが収録されています。iconvには文字コード自動判定機能がないため、変換前の文字コードを明示する必要があるものの、書式はかんたんです。アップルスクリプトやAutomatorから利用してもいいでしょう。
     iconvで文字コードを変換する場合、「-f」オプション(From)に続けて変換前の文字コードを、「-t」オプション(To)に続けて変換後の文字コードを指定し、変換前のファイル名を引数として与え、他のファイルへリダイレクトして書き出します。以下のコマンド実行例では、シフトJISのファイルをUTF-8に変換しています。なお、指定できる文字コードは、「iconv -l」を実行すれば確認できます。

    - - - - -
    $ iconv -f SJIS -t UTF8 before.txt > after.txt
    - - - - -
    


    ii) 標準装備のテキストエディタ
     標準装備のテキストエディタ(TextEdit.app)も、保存時に文字コードを手動で変更することにより、文字コード変換ツールとして利用できます。そのほかに、ターミナルからEmacsを起動し、内部コマンド(set-buffer-file-coding-system)を使うという方法もありますが、ここでは割愛します。

    ・文字コード変換ツール(自力で用意)

    i) nkf
     nkf(Network Kanji Filter)は、十年以上の歴史を持つUNIX系OS汎用の文字コード変換ツールです。文字コードの変換だけでなく、テキストファイルのエンコード形式の判定など、応用範囲が広いことが特徴です。最新版のバージョン2.0.7ではUTF-8にも対応しているので、Mac OS Xでも利用価値の高いコマンドといえます。まずは、以下のとおりコマンドを実行して、インストールしてみましょう。

    - - - - -
    $ curl -O http://osdn.dl.sourceforge.jp/nkf/20770/nkf207.tar.gz
    $ tar xzf nkf207.tar.gz
    $ cd nkf207
    $ make
    $ sudo cp nkf /usr/local/bin/
    - - - - -
    


     nkfコマンドの特徴の1つが、文字コード自動判定機能です。かなりの精度で入力する(変換前の)ファイルの文字コードを正しく判定し、指定された文字コードへと変換します。以下に示す実行例では、文字コード種不明のテキストファイル「temp.txt」をUTF-8に変換、同じファイルに上書き保存しています。

    - - - - -
    $ nkf -w --overwrite temp.txt
    - - - - -
    


    ○nkfコマンドの主なオプション
    -j (省略可) : ISO-2022-JPを出力
    -e         : 日本語EUCを出力
    -s         : S-JISを出力
    -w         : UTF-8を出力(BOM無し)
    -Lm        : Macintosh改行形式(CR)に変換
    -Lu        : UNIX改行形式(LF)に変換
    -Lw        : Windows改行形式(CRLF)に変換
    -g         : 文字コードを判定する

    ii) QKC
     シフトJIS、日本語EUC、ISO-2022-JPの各日本語文字コードを、高速に相互変換するコマンドです。ただし、Mac OS X用バイナリは提供されていないため、UNIX系OS汎用のソースコードをコンパイルし、コマンドの形で使わなければなりません。UTF-8には対応していないこともあり、nkfを使えば十分でしょう。

    http://hp.vector.co.jp/authors/VA000501/

     次回は、PerlやRubyを利用した日本語文字コードの変換方法を紹介する予定です。

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

     

     MOSA Developer News   略称[MOSADeN=モサ伝]
            配信停止 mailto:mosaden-ml@mosa.gr.jp
     記事内容に関するご意見 mailto:mosaden-toukou@mosa.gr.jp
          記事投稿受付 http://www.mosa.gr.jp/?page_id=850
    Apple、Mac OSは米国アップル社の登録商標です。またそのほかの各製品名等
    はそれぞれ各社の商標ならびに登録商標です。
    このメールの再配信、および掲載された記事の無断転載を禁じます。
    特定非営利活動法人MOSA  http://www.mosa.gr.jp/
    Copyright (C)2007 MOSA. All rights reserved.

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

    2008-03-18

    目次

    • りんご味Ruby         第21回  藤本 尚邦
    • 藤本裕之のプログラミング夜話   #134
    • 高橋真人の「プログラミング指南」  第132回
    • 開発ツールよもやま話      ドキュメントアクセス

    りんご味Ruby   第21回  藤本 尚邦

    第17回から第19回にかけて、Objective-Cで書かれているXcode ToolsのサンプルアプリケーションSketchに、RubyCocoaフレームワークをリンクして、Rubyプログラムで機能(新たな種類のグラフィックオブジェクトなど)を追加していく様子を示してきました:

    ・Sketchプロジェクトに、Rubyプログラムを組み込むための準備 (第17回)
    ・角丸四角形を表すSKTRoundedRectangleクラスをRubyで実装 (第18回)
    ・ツールパレットに角丸四角形ツールを追加 (第19回)

    ■ 角丸四角形対応Sketchアプリのビルド・実行

    第19回では、InterfaceBuilderを使って角丸四角形ツールボタンを追加し、ツールパレットコントローラ(SKTToolPaletteController.m) に角丸四角形のためのコードを追加しました。実はこれで、Sketchアプリケーションで角丸四角形を描くために必要なものは基本的に出来上がっています。

    ということで、Sketchプロジェクトをビルドして、改造したSketchアプリケーションを走らせてみましょう。ツールパレットで角丸四角形ツールを選択してウィンドウ内に図形を作ると、角丸四角形が作成できるようになっています。Objectve-Cで定義された四角形クラスや楕円クラスと、Rubyで実装された角丸四角形クラスを同等に扱うことができているわけです。

    ■ スクリプティングブリッジ

    Sketchアプリケーションはスクリプティングに対応していて、AppleScriptなどでグラフィックを生成したり属性を変更したりすることができるようになっています。以下は、Sketchアプリケーションのドキュメント上に、四角形オブジェクトを1つ生成して、位置やサイズをセットするAppleScriptのプログラムです:

    tell application "Sketch"
     tell document 1
       make new box
       tell box 1
         set width to 100
         set height to 100
         set x position to 100
         set y position to 100
         set stroke thickness to 8
       end tell
     end tell
    end tell
    


    LeopardからMac OS Xに搭載されるようになったScriptingBridgeフレームワークを使うと、Objective-CやRubyのプログラムからも同様のアプリケーション操作が可能になります。以下は、上のAppleScriptプログラムと同様の操作を(RubyCocoaフレームワークを使って)Rubyでプログラムしたものです:

    --------------- ScriptingBridgeを使ってSketchアプリケーションを操作 --
    require 'osx/cocoa'
    include OSX
    require_framework "ScriptingBridge"
    
    # Sketchアプリケーションオブジェクトを取得してsketchという名前を付けた
    sketch = SBApplication.
     applicationWithBundleIdentifier("com.apple.CocoaExamples.Sketch")
    
    # スクリプティングの用語集で"box"という名前が付けられている四角形グラ
    # フィッククラス(SKTRectangleのこと)にbox_classという名前を付けた
    box_class = sketch.classForScriptingClass("box")
    
    # 四角形オブジェクトを生成
    box = box_class.alloc.init
    
    # ドキュメントに生成した四角形オブジェクトを追加
    sketch.documents[0].graphics.addObject(box)
    
    # 追加した四角形オブジェクトに各種属性値を設定
    box.width = box.height = 100
    box.xPosition = box.yPosition = 100
    box.strokeThickness = 8
    -------------------------------------------
    


    ちなみに前回紹介したMacRubyを使って書く場合には、最初の3行の部分を:

    framework “ScriptingBridge”

    に置き換えるだけで、あとは同じになるはずです。

    さて、角丸四角形グラフィックをスクリプティングに対応させるためには、以下の3つのファイル:

     ・SKTDocument.m
     ・Sketch.scriptSuite
     ・Sketch.scriptTerminology

    を変更する必要がありそうです。次回はこれに着手しようかとも考えていたのですが、Rubyとほとんど関係のない話になってしまいそうな気もします。もっとRubyよりの別の話に予定変更するかもしれません。

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

     承前、前回は各種(というほど多くないか)統計調査をひき、「パソコンが普及したわりにソフトウェアがそれに比例して売れてない」理由は、「ほとんどの人が買ったそのままで出来ることしかパソコンをつかってやってないから」であることを確認したわけだが覚えてますか? いや別にあなたが覚えてなくてもそのまま話は進むんだけどさ。

     前回みた日米韓のパソコンの用途調査で(と書くとまるでオレが調査したみたいで偉そうだが)、米韓のトップは「音楽を聴く」であった。日本人だって結構パソコンで音楽を聴いているような気がするんだけど、とある人にいったら「フジモトさん、日本人が音楽を聴いているのはケータイでなんですよ」という返事が返ってきた。

     そんなぁ、音楽のオンライン配信において iTunes Storeのシェアが6割だとか聞いたことがありますよと聞き返したら、なんとそれは「ケータイへの音楽配信を入れない、パソコン相手だけの数字」なんだそうな。そんで、iTunesStoreが6割を占める パソコン相手の音楽配信の市場規模というのはケータイ相手を含むこの業種全体の中ではなんと1割程度なんだと。がーん、と思いましたか(正直オレは思いました)?

     なんつうかさぁ、井の中の蛙大海を知らずというか、蛙の胃の中の寄生虫が井戸も知らないような話である(いくらなんでもそこまでひどかないか)。そうなのだ、なんと情報機器としてのパソコンは、その主流の地位をケータイに明け渡したどころか(いくら世間知らずのオレでもそのくらいは知ってたけどさ)、知らないうちに10倍とかいう差をつけられちゃっていたのである。

     もちろんマクロな視点で見れば、パソコンで動いてるのもiPodで動いているのもケータイで動いているものアプリケーションには違いなく、それを書いてるのもプログラマーに違いないわけで、最初に高橋編集長からいただいた「アプリケーション・プログラマは絶滅危惧種か?」というテーマに沿えば「いいえ違います。彼らは絶滅したんではなく住処を変えて生き延びたのです」と言える。言えることはね。

     だけどそれはまるで「クジラはどうして海に住むようになったのですか」みたいな話である。何代か先の子孫は知らず(いないけど)、陸の動物としてこれまでやってきた人々がおいそれとクジラやイルカになれるか。いや、なれれば言うことはないんだがコトはそう簡単ではない。それにそのケータイという「海」だってそれほど生活環境として結構なところではあるまい。隣の芝生はいつでも青い。もしかしたら中国の緑化運動みたいに緑のペンキを撒いてるだけかも知れない。

     私としてはここらでもう一度原点に戻り、そもそも俺たちが飯の種にしているアプリケーション……つうかソフトウエアつうのは何であるのか。いわゆる「それがないとコンピュータがただの箱であるところのもの」とかいう古いプログラム入門の最初の方に書いてあるようなことでなく、人がそれを作ることを生業として生活して行く商品、あるいは製品としてこいつがどんな性格のものであるのかというところを考えてみたい。

     ……て、いうかね。実を言うとオレはもうかなり長い間、そう、かれこれ10年以上も前から、俺たちが作っているこいつは実のところ「ソフトウエアの名に値しない何か」なんぢゃないかと思っているのである。……これぢゃ通じないかな、こういう風に考えてみてください。「コンピュータ・ソフトウエアというものはもっと広いカテゴリである『ソフトウエア』の中でどんな存在なんだろう」って。
                           (以下次回 2008_03_15)

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

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

    〜XcodeによるPowerPlant X入門(21)〜

     こんにちは、高橋真人です。
     さて、前回お勧めしたようにイベントハンドラの中にログを書き出すコードを加えて、MyViewの挙動を観察してみましたでしょうか?
     今回4つのクラスを継承することで加えられたCarbonイベントのハンドラとして機能するメンバ関数は以下の通りです。(カッコ内は継承元のクラス)

    DoControlDraw()【PPx::ControlDrawDoer】
    DoControlHit()【PPx::ControlHitDoer】
    DoControlHitTest()【PPx::ControlHitTestDoer】
    DoControlHiliteChanged()【PPx::ControlHiliteChangedDoer】
    


     それでは、通常のプログラムの動作に沿って、それぞれのハンドラ(関数)がどのように呼ばれるかを見ていきましょう。
     まず、最初に呼ばれるのはDoControlDraw()です。このハンドラはユーザーにViewの見た目を提供する重要な役目を持っており、Viewの表示が必要になった時に呼ばれます。
     そのため、この関数の実装には「状態の判断」の処理が入ります。今回のプログラムでは「Viewがアクティブであるか」と「Viewがハイライトされているか」をチェックし、この両方を満たす場合には表示色が濃くなるようにしています。
     さて、ユーザーがマウスでこのViewを押したとします(ボタンはまだ放さない)。すると、DoControlHitTest()が呼ばれます。この関数の処理の中心は、「Viewのどの部分が押されているのか」を判断することです。少し分析的に言い替えると「マウスポインタの現在の位置は、Viewのどの部分か」ということです。
     「部分」というのは何のことかということですが、例えばスクロールバーのような複雑なコントロールを思い浮かべてもらうと分かると思うのですが、コントロールにはいろいろな構成パーツが存在していて、それぞれ独自の反応をするということです。今回は極めて単純な四角のボタンですから、構成部品は“ボタン”のみということで、コードで表すとkControlButtonPartとなります。
     ちなみに、これらの「コントロールの構成部分名」を表す値は
    ControlDefinitions.hというヘッダファイルに定義されています。Xcodeで、コードのkControlButtonPartという部分をコマンドキーを押したままでダブルクリックするとこのヘッダファイルが開き、kControlButtonPartの定義部分が選択された状態になると思います。選択部分の少し上には、”Control PartCodes”と、コメントで見出しが付けられていて、以下、enum型として“部品名”が羅列されているのをご覧になれると思います。
     さて、今回のプログラムでViewが表現しているのは、あくまでシンプルな四角形のボタンですから、構成部分はkControlButtonPart以外にありません。もしかしたら、「構成部品が一つしかないのだし、ハンドラが呼ばれるのはボタンが押された時に決まっているのだから、位置判定など必要ないのでは?」と思われる方もいるかもしれません。この点については、すぐ後で判明します。
     さて、このハンドラでマウスポインタがViewの中にあると判断されたら、outPartCodeにkControlButtonPartをセットしてやるわけですが、これによって新たなイベントが引き起こされます。それに伴って呼び出されるハンドラがDoControlHiliteChangedです。
     このイベントはViewのハイライト状態が変化した場合に発生します。ハイライトというのは、通常のMacのコントロールにおいてマウスクリックに反応して色が青くなったり濃くなったりするような状態のことです。
     まず、Viewの上でマウスボタンを押したら、ボタンを押さえたままでポインタをボタンの外に出したり、戻したりと、あちこち動かしてみてください。もし、DoControlHitTest()の中に、冒頭でも触れたログを書き出すコードを書いてあった場合、マウスボタンを押したままでポインタの位置が変化すると、頻繁にこの関数が呼び出されることが観察できるはずです。
     このとき内部では、outPartCodeに返ってくる値を見張っていて、これが変化した時にその内容に沿った処理をします。今回のプログラムでは変化はkControlButtonPartとkControlNoPart(Controlのどの部分でもないことを表す)の2つの状態を行き来するだけですが、その度にHiliteControl()を呼び出して「ボタンのハイライト状態」をオンにしたりオフにしたりしているのです。
     この「オンとオフの切り替え」は、ボタンのハイライト状態の変化として認識されて、また新たなイベントの発生につながります。この時、イベントのハンドラであるDoControlHiliteChanged()が呼び出されるわけです。この関数の中では、単にViewに再描画命令を発生させているだけですが、これによりView描画のイベントが発生して、DoControlDraw()が呼び出されるというわけです。

     ハンドラの関数ごとに細かく説明をしたので、話が入り組んでいるように思えた方もいるかもしれませんが、DoControlDraw()、DoControlHitTest()、DoControlHiliteChanged()がどのように連携し合いながらボタンのインタラクションを実現しているかを観察してみると、そんなに難しくはないのが分かるでしょう。
     重要なポイントは、これらの関数が直接に呼び出しをしているのではなく、必ずイベントを介して連携しているということです。まあ、イベントのハンドラなので当然ですが。

     さて、ほとんど付け足し程度の簡単な説明になりますが、ボタン本来の目的である“クリックに対する反応”が、DoControlHit()です。この関数を呼びだすイベントは、今まで話してきたボタンのインタラクション処理の結果、「ボタンがクリックされた」と認識された場合に発生することになります。
     PPx::BaseViewにイベントハンドラを加えてボタンの振る舞いをさせる仕組みが分かっていただけたでしょうか?

    開発ツールよもやま話     ドキュメントアクセス   高橋 政明

     待望のiPhone SDKが登場しました。NDAのため情報は公式サイトのものだけですが、既にたくさんのドキュメントがあります。
     Xcodeはドキュメントへのアクセスがいくつか用意されています。今回はこれを解説します(基本部分なのでiPhone SDKでも共通なはずです)。Xcode3ガイドの第9章に「製品ドキュメントにアクセスする」があります。Xcode3ではこれまでの『「製品ドキュメント」ウインドウ』に加えて『リサーチアシスタント』も利用可能になりました。

     かつて、ドキュメントは書籍の「インサイドMacintosh」や印刷物のテクニカルノートでした。APIなどを検索する専用ツールやオンラインでドキュメントを参照するツールが使われた時代を経て、現在ドキュメントは基本的にhtmlファイルで提供されブラウザで参照します。
     htmlファイルは検索が可能ですし関連情報へのリンクにより、たとえばメソッドの引数の型の確認など必要な情報をたどる場合に便利です。
     htmlと同じ内容のPDFのドキュメントも用意されています。pdfのドキュメントは新しいクラスを腰を据えて勉強する場合などには印刷してじっくり読む場合などに重宝します。

     どのバージョンのXcodeもhtmlドキュメントを検索し対応する項目の説明を表示する機能を持っています。Xcode3の日本語表記では「製品ドキュメント」ウインドウがそれです。

    ◆製品ドキュメント
     製品ドキュメントウインドウはヘルプメニューから開くことができます。(Xcode2.4では「マニュアル」と表記されています)
     ソースリストのクラスやメソッド名をoptionキーを押しながらダブルクリックすると対応する説明を検索し結果が表示されます。サンプルや既存のソースを調べる場合など最も頻繁に検索する方法と思います。ちなみにコマンドキーを押しながらダブルクリックすると定義しているソースをEditウインドウに表示できます。

     検索は検索欄に直接文字列を入力しても可能です。APIオプションで検索範囲を指定できます。APIと全文検索が選べます。(Xcode3からは「タイトル」も選べます)
     全文検索ではワイルドカード「*」やブール演算子「括弧と ! & |」も使えます。例えば「path」で全文検索すると図形とファイル関係が両方ヒットしますが「path & ! file」とするとファイル関連以外を検索できます。

     私がよく使うのはAPI検索です。ガイドなどにリンクがある場合はブラウザを使って開くことが多いです。
     うまく表示されない場合は検索条件、特にどこから検索しているかを確認してください。「すべての製品ドキュメント」から検索しているのか「CoreReference Library」なのか「Developer Tools Reference Library」から検索するのかで検索結果は変わります。

     Xcode3ではドキュメントのブラウズが可能になりました。ツールバーのブラウズボタンをクリックします。普段使っている方法で必要な情報が見つからないや広範囲に調べる場合などにこのブラウズ機能を試すとよいかもしれません。もう一度ブラウズボタンをクリックすると通常の検索に戻ります。

     なおXcodeが表示するドキュメントのパスはXcode2.xでは
    /Developer/ADC Reference Library
    Xcode3では /Developer/Documentation/DocSets/ です。
     ここにhtml形式のファイルがありインターネットに接続していない状態でもドキュメントの検索と表示が可能です。高速な検索が可能な反面鮮度は落ちて行きますので、最新ドキュメントかどうかを意識しましょう。最新ドキュメントのインストール方法はXcodeのバージョンで違いますのでヘルプを参照してください。新機能だけではなく記述が詳しくなるなど最新ドキュメントは充実する方向です。

    ◆リサーチアシスタント

    リサーチアシスタントは情報表示に特化したパネルです。
    上から順に
    ・外部へのリンク(別ウインドウを開く)
    ・宣言
    ・抽象
    ・利用できるかどうか
    ・関連API
    ・関連製品ドキュメント
    ・サンプルコード
    必要なデータがパネルにコンパクトにまとまっています。パネルを表示した状態でキャレットのあるクラスやAPIの情報を自動的に探し、あれば表示してくれます。

     Xcode3からはコンパイルオプションや警告設定の説明もリサーチアシスタントに表示されるようになっています。

    ◆本日のまとめ
    ドキュメントを検索する方法はいろいろある。
     普段使っている方法以外の検索方法も確認しておくと、いざと言う時に役に立つはずです。

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

     

     MOSA Developer News   略称[MOSADeN=モサ伝]
            配信停止 mailto:mosaden-ml@mosa.gr.jp
     記事内容に関するご意見 mailto:mosaden-toukou@mosa.gr.jp
          記事投稿受付 http://www.mosa.gr.jp/?page_id=850
    Apple、Mac OSは米国アップル社の登録商標です。またそのほかの各製品名等
    はそれぞれ各社の商標ならびに登録商標です。
    このメールの再配信、および掲載された記事の無断転載を禁じます。
    特定非営利活動法人MOSA  http://www.mosa.gr.jp/
    Copyright (C)2007 MOSA. All rights reserved.

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

    2008-03-11

    目次

    • 「「Wonderful Server Life」    第66回   田畑 英和
    • 小池邦人のCarbon視点でCocoa探求
    • ターミナルの向こうから      第21回  海上 忍 

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

      〜Open Directory編〜

     それでは今回は、Leopard Serverの新しい管理ツール「サーバ環境設定」を使ったアカウント管理を解説します。ひょっとすると前回解説した「システム環境設定」でのアカウント管理よりもシンプルかもしれません。
     「サーバ環境設定」はLeopard Serverの初期設定時にサーバ構成を「標準」もしくは「ワークグループ」に設定したときに使用できますが、まずは「標準」の場合を前提に話を進めて行きます。「ワークグループ」でも基本的には同じなのですが、若干違いがあります。違いについては次回以降の連載で解説したいと思います。

     「標準」のサーバ構成ではOpen Directoryのマスターが自動構築されることはこれまで解説してきましたが、「サーバ環境設定」で管理するアカウントは、Open Directoryのマスターで管理されるネットワークアカウントになります。Tiger Serverと同様に「ワークグループマネージャ」でも管理はできますが、複雑な設定をしない場合などは、「サーバ環境設定」のほうが圧倒的にお手軽です。まるで「システム環境設定」を使っているような感覚でアカウント管理ができます。
     管理可能なアカウントはユーザとグループに分かれていますがまずはユーザの管理からみていきましょう。ユーザの管理画面は「アカウント」「コンタクト情報」「サービス」「グループ」の4つから構成されています。

    ◇アカウント
     まずは基本となる画面です。ここで既存の各ユーザの確認やパスワードのリセットができます。左側のリストには登録済みユーザの一覧が表示され、左下の「+」「ー」ボタンでユーザの登録/削除を行います。ユーザ登録時には次の4つのパラメータを指定します。

    ・ユーザ登録時のパラメータ
      - 名前
      - ユーザ名
      - パスワード
      - 管理者権限の有無

     パスワードの設定には「システム環境設定」と同様にパスワードアシスタントが使用できます。パスワードですがパスワードがないユーザを登録することはできず、必ずパスワードを設定する必要があります。ただし「ワークグループマネージャ」でユーザを登録する場合はパスワードをなしにすることもできます。
     「システム環境設定」でユーザを登録したときにはホームが自動的に作成されますが、「サーバ環境設定」でユーザを登録してもホームは自動的には作成されません。これは前回説明した「共有のみ」のローカルユーザとよく似ています。ユーザ属性を確認すると、ホームのパスとログインシェルはデフォルトで次のように設定されていることが分かります。

    ・ホームのパス(NFSHomeDirectory)
    /var/empty
    ・ログインシェル(UserShell)
    /usr/bin/false

    ・「アカウント」設定画面
    http://www.htabata.com/Site/LeopardServer/Pages/Server_Preferences%28Standard%29.html#2

    ◇コンタクト情報
     次は「コンタクト情報」です。ここでは住所などの情報を管理します。入力したコンタクト情報はネットワーク経由で「アドレスブック」から参照することができまます。ただしデフォルトでは制限なしに情報を公開してしまいますので、サーバのアドレスさえ分かればネットワーク接続可能なクライアントからは自由にアクセスすることができます。運用にはくれぐれも注意しましょう。
     日本であればぜひともここにふりがなの属性を追加して欲しいところですが、残念ながらそういった属性は用意されていません。また、同様の情報は「ワークグループマネージャ」でも管理できます。

    ・「コンタクト情報」設定画面
    http://www.htabata.com/Site/LeopardServer/Pages/Server_Preferences%28Standard%29.html#3

    ◇サービス
     この設定は重要です。ユーザごとに使用可能なサービスを許可することができます。ユーザを新規に追加すると、そのときに有効になっていたサービスは自動的に許可されますが、起動していないサービスは自動的には許可されません。一方ユーザを登録した後から起動したサービスはそのままでは利用できず、ユーザごとに手動でサービスを許可する必要があります。
     ですので、ユーザを登録したら必ずサービスの許可をチェックするようにしましょう。また後からサービスを起動した場合も、しっかりと確認をするようにしましょう。特定のサービスを利用しないことが分かっているユーザは、あらかじめサービスを許可しないでおけば余計なサーバへのアクセスを防ぐことができます。
     「システム環境設定」ではユーザごとにしかサービスの許可が管理できませんが、「サーバ管理」ではグループ単位でも管理することができます。また、「サーバ管理」のほうがより多くのサービスに対する許可を設定することができます。

    ・「サービス」設定画面
    http://www.htabata.com/Site/LeopardServer/Pages/Server_Preferences%28Standard%29.html#4

    ◇グループ
     最後の画面では各ユーザが所属するグループを設定します。「サーバ環境設定」でユーザを追加した場合、自動的にWorkgroupのメンバーとして登録されます。「ワークグループマネージャ」で登録したユーザは自動的にはWorkgroupには登録されません。

    ・「グループ」設定画面
    http://www.htabata.com/Site/LeopardServer/Pages/Server_Preferences%28Standard%29.html#5

     以上「サーバ環境設定」でのユーザ管理についてみてきました。今回解説しましたように「サーバ環境設定」と「ワークグループマネージャ」では一部挙動が異なる部分もあります。混乱を避けるために「サーバ環境設定」を使ってアカウント管理を行う場合は基本的にはこれを使用し、必要に応じて「ワークグループマネージャ」も併用するといった使い方がよいでしょう。
     それでは次回は「サーバ環境設定」でのグループ管理について解説する予定です。
    次回へつづく                             

    iPhone SDK登場に思う(2008/03/08)          小池邦人

    3月6日(日本では 3月7日の深夜)Apple社のスペシャルイベントで待望のiPhone SDKが発表されました。即座に、ADCメンバーを対象にSDKβ版のダウンロードが開始されたのですが、Apple社のデベロッパーサイトへのアクセスがものすごく、すんなりとダウンロードできるようになるまで半日以上かかりました。Appleサイトがこんな激しいトラフィックに見舞われるのは、最近では珍しいことです。それだけ注目度が高いと言うことでしょうが、残念ながら、iPhone SDKβ版はNDA(秘密保持契約)扱いになるようで、その技術的な情報を公の場で掲載、議論することはできません。つまり、6月末に予定され
    ている正式版が登場するまでは、雑誌やウェブなどにおいて、その技術内容の詳細が紹介される事はありません。

    オンラインADCメンバーでもダウンロード可能ですので、配布対象制限は存在しないのに等しいのですが、相変わらずお堅い話です。まあ、中途半端な完成度のSDKについて色々と論評されるのを避けたいのでしょうが、「だったら約束通り2月末までに正式版を出してね!」と、突っ込みを入れたくなります(笑)そんなわけで、技術的な話題として取り上げることができるのは、スペシャルイベントでの発表内容(そこからの推測事項)のみと言うことになります。これでは、詳細な技術議論は何もできません。SDKを普及させ、出来る限りiPhoneアプリケーションを増やしたいという気持ちは、Apple社もユーザも同じでしょうから、もう少し柔軟な取り扱いはできないものかと思ってしまいます。

    ところで、今までiPhone搭載のOSは「OS X」と呼ばれていましたが、iPhoneSDKの登場により、正式に「iPhone OS」と呼ばれることになったようです。スペシャルイベントでの発表では、iPhone OSは「Core OS」「Core Services」「Media」「Cocoa Touch」の4つのレイアに分かれています。個人的に嬉しいのは、各レイアには、Mac OS Xでなじみ深い「Framework」が多数採用されていることです。これであれば、Mac OS Xで習得した技術の多くが無駄にならず、iPhoneアプリケーションの開発にそのまま生かせます。特に、MediaレイアにおけるQuartz 2D、Core Animation、OpenGLの採用は(個人的にもお得意のFrameworkなので)自作iPhoneアプリに即生かせそうです。

    iPhone OSに置ける3D描画環境は「OpenGL ES(Embedded System)」が担当します。最近では、3Dだけでなく2D描画にも大きな役割を持つOpenGLですが、iPhone OSでの採用により、その認知度がさらに上がる事を期待したいと思います。OpenGL ESは、携帯電話などの組み込み用3Dシステムとしてはよく知られていますが、パソコンの3D描画環境としては、やはりWindowsの「Direct X」が主流であり、どうしても、そちらに関する書籍や資料の充実が先行します。そのため、GPUメーカの目も、まずはそちらに向きがちで、機能的にOpenGLが後手を踏む状態が続いています。iPhone OSの採用によ
    り、OpenGLの有効性が広く認知されれば、パソコンにおけるOpenGL環境の充実にも一役買うかもしれません。

    今のところ、iPhone SDKβ版はLeopard(Mac OS X 10.5)用しか提供されていません。つまりMacintosh専用ということになります。XcodeやInterfaceBuilderなどの既存Mac OS X開発ツールがそのまま使われるので、Windows版やLinux版が登場するかどうかは怪しいところです。ちなみに、iPhoneシミュレータの仕組みを実装することは、特定のFrameworkには依存しないでしょうから、そんなに難しくはないと思われます。たとえCocoaやObjective-Cが必須だとしても、Mac OS Xの開発環境自体を別プラットフォームへ移植する(例えばCocoa for Windowsとか)よりは壁は低いはずです。ただし、実際にMacintosh以外のプラットフォーム用のSDKが出るのかと言えば、それはあり得ないかもしれません。

    なにせ、SDKの使用環境がMacとMac OS Xに限られますから、iPhone用ネイティブアプリを開発しようとすれば、必ずMacを購入することになります。Apple社としは物理的「ハロー効果」と言うべきか…大変美味しい商売になるわけです(笑)。iPhoneが全世界でどの程度普及し、その有用性がどの程度認知されるかにも関わりますが、Apple社が言うように、2008初年度だけで1000万台の販売目標が達成できるとすれば、現Macデベロッパー以外のiPhoneデベロッパーによるMac需要も、かなりの数になると予想できます。間違いなく、短期間で現在のMacデベロッパーの数を抜くでしょうね。今から、今年のWWDCでの基調講演や朝食の席取りが不安になってきます…。

    iPhone用アプリ開発に魅力を感じるソフトメーカや個人が増えれば、他のプラットフォームからの乗り換えや両刀使いも促進され、Macintosh自体に目を向けてくれる技術者や開発者も増えるかもしれません。今は「仮想環境」の普及で、MacでWindowsやLinuxも利用している技術者が増えていますが、さらにその傾向に拍車をかけることになります。これは、MacプラットフォームとMacOS Xに関しても大きなメリットとなるでしょう。現在、Mac用アプリケーションの主流はCocoa FrameworkとObjective-Cで開発されています。しかし、CocoaやObjective-Cによる開発作業があまり一般的でない(マイナーな)ために、Mac OS Xでのソフト開発には興味はあるのだが、二の足を踏んでいる別プラットフォーム開発者(潜在的なMac開発者)がかなり存在しています。

    iPhone OSとSDKは、そういう人達をMacに引きつける起爆剤になって欲しいところです。また、Carbonや別Frameworkを使うMac開発者は、旧資産の活用やメンテナンス、技術資料の不足といった理由から、CocoaやObjective-Cへ移行しづらい状況が続いています。つまり、個人的にはいつでもOKなのですが、会社としてそうは動けないという問題です。 Apple社も、QuickTimeやCarbonの64Bit化を中止するなど、移行促進をサポートしていますが(笑)現実はなかなか難しい状況です。ところが、iPhone SDKでは、今のところCocoaとObjective-Cを使うしかありません。やるしかないとなれば、会社としても即実行となるでしょう。それは、Cocoaの素晴らしい特徴を多くの開発者にアピールする絶好の機会にもなり、関連技術資料や書籍の充実にも貢献するはずです。

    今回、開発者(特に小規模や個人)にとって最も魅力的な発表は、開発したアプリケーションの配布に「App Store」が用意されている点だと思います。ソフト登録の仕組みや利益配分率なども「ざっくり」とシンプルで分かり易く定義されています。アプリケーション登録(出店)についても、難しい認定を得る必要もなく、$99の費用で「iPhone Dveloper Program」に加入しさえすればOKのようです。このあたりの仕組みは、さすがにApple社、さすがにJobs CEOと言ったところでしょうか(笑)。ただし「iPhone Developer Program」は米国先行となっています。その点は、日本の開発者としては少々不満なのですが、すみやかに加入手続きが始まることを期待したいと思います。

    まあ、インターネット経由でのソフト販売そのものは珍しい事ではありません。筆者も何度か販売経験がありますが、供給元が一本に絞られているというのは結構魅力的です。購入したいお客を集約でき、煩雑な手間を省けます。Webアプリケーション開発者であれば、サイトにアクセスするためのアプリを有料で提供することで、今までは個人レベルでは難しかった「課金」という仕組みを簡単に実現できそうです。また、iPhoneアプケーションは物理的に小規模ですので、膨大な資金と人材を使い力ずくで開発した「モンスターソフト」が市場を荒らす可能性も少ないでしょう。つまり、個人や小規模といった
    点がデメリットとはならず、アイデアに対して小回りが利くというメリットになる可能性が大きいのです。
    パソコン自体、もしくはApple IIや初代Macが登場した時もそうでしたが、新しいプラットフォームが登場したばかりには、それを所有しているユーザには大きな「飢餓感」があります。つまり、面白くて変わっていて興味ある物なら何でも購入するのです(笑)。それの価格が1万であれば、少し「ためらい」が生じますが(昔はそれも無かった)1000円なら一瞬考えるだけ、100円なら間違いなく「即ポチ」するでしょう。自動販売機で缶コーヒーを購入する気軽さと同じです。価格の妥当性まで考えが及ぶ暇もなくダウンロードされていくわけです。最初のうちは英語版さえ作成しておけば(多分)市場ターゲットは全世界です。100円の商品を年間10万本販売できれば1000万の収入となります。大企業であれば大したことはないのですが、個人であれば大変魅力的な金額です。

    App Storeが成功するかどうかは、今後、iPhoneが魅力的なプラットフォームとしてユーザを魅了するかどうかにかかっています。しかし、たとえ成功したとしても、上記の様な活況は一定期間経てば収束するでしょう。今回はその期間が短いかもしれません。いかなる時もそうでしたが、大量の製品が登場し出せば、同様なアイデアを実装したライバルも増えます。一旦そうなってしまうと、幾らか技術的アドバンテージがあろうとも、多くの類似品の中に埋もれる可能性が高くなります。そして、10円単位の価格競争が起こるかもしれません(笑)。ですから、もし素晴らしいアイデアがあるなら、誰よりも先んじて実
    現し、App Storeに出店することが肝心です。それが多くのユーザに受け入れられれば、短期間で大きな利益(個人的レベルの話です)を生み出せるはずです。

    ある意味、筆者が夢に描いていた「ソフト屋商売のビジネスモデル」が登場することになります。人生の中でもこうした大きなチャンスにはそうは何度も遭遇できません。また、Mac開発者には間違いなく先行アドバンテージがあるわけですから、それを生かせるかどうかは「あなた」次第なのです。さて皆さん、お互いに頑張りましょう(笑)。

    以上

    ターミナルの向こうから     第21回  海上 忍

    〜 スプレッドシートとの共存を考える (3)〜

     前回は、Perlモジュール「Spreadsheet::WriteExcel」を利用し、日本語データをExcelブックに書き出す方法を紹介しました。今回は、Perlモジュール「Spreadsheet::ParseExcel」を利用し、Excelブックから日本語データを取り出してみます。

    ・CPANについて
     前回前々回とPerl関連の内容が続いていますが、その中で特に説明を加えないままCPAN経由でモジュールをインストールしています。意味不明に思われる方もいらっしゃるはずですので、本題に入る前に、少しばかりCPANについて説明しておきましょう。
     CPAN(Comprehensive Perl Archive Network)は、Perlモジュールおよび関連文献の集積場です。オンライン経由でアクセスすれば、Perlプログラマは必要なモジュールを入手し、そのドキュメントを参照できます。世界中にミラーサイトが設置されているため、アクセスも高速です。
     そのCPANにアクセスするためのクライアントが、「CPANシェル」です。ターミナルから「cpan」コマンドを実行すると、プロンプトが「cpan>」に変化し、cpanの内部コマンドを実行できるようになります。内部コマンドの種類と機能については、「help」で確認してください。
     これまでcpanコマンドを紹介するときには、「sudo -H cpan」として管理者権限を使用していますが、その理由はカレントユーザの作業領域(~/.cpan/)ではなく、rootの作業領域(/var/root/.cpan/)を使うためです。こうしてcpanコマンドを実行すれば、モジュールは全ユーザが利用できるよう適切なシステム領域へとインストールされます。というわけで、今回利用するモジュール「Spreadsheet::ParseExcel」、それが依存する「Jcode」を、以下の手順でインストールしてください。

    - - - - -
    $ sudo -H cpan
    cpan> force install Jcode
    cpan> force install Spreadsheet::ParseExcel
    cpan> exit
    - - - - -
    


    ・Spreadsheet::ParseExcelを使う
     今回紹介する「Spreadsheet::ParseExcel」は、前回紹介した「Spreadsheet::WriteExcel」とは逆に、Excel 97-2004ブック(バイナリフォーマット、拡張子は.xls)を解析し、値を取得する機能を提供します。全機能の照会はターミナルから「perldoc Spreadsheet::ParseExcel」を実行していただくとして、ここでは日本語を含むExcelブックを対象にするときの注意点など、具体的な使用事例を紹介します。
     以下のスクリプトでは、「Spreadsheet::ParseExcel」と「Spreadsheet::ParseExcel::FmtJapan」モジュールをロードします。後者のモジュールは、日本語を含むExcelブックを扱うときに必要です。

    - - - - -
    1: #!/usr/bin/perl -w
    2: use strict;
    3: use Spreadsheet::ParseExcel;
    4: use Spreadsheet::ParseExcel::FmtJapan;
    - - - - -
    


     続いて、作業対象のファイルを指定します。ここでは、ファイル名にコマンドライン引数を、文字エンコード方式にはUTF-8を指定しています。

    - - - - -
    5: my $file = shift @ARGV;
    6: my $fmt = Spreadsheet::ParseExcel::FmtJapan->new( Code=>'utf8' );
    7: my $xls = Spreadsheet::ParseExcel::Workbook->Parse($file, $fmt);
    - - - - -
    


     Spreadsheet::ParseExcelモジュールには、Excelブックから属性情報を取得する機能も用意されています。以下の例では、ファイル名(File)、ワークシートの枚数(SheetCount)、作成者名(Author)の各プロパティから値を取得し、標準出力へ書き出しています。

    - - - - -
    8: print "File Name  :", $xls->{File} , "\n";
    9: print "Sheet Count:", $xls->{SheetCount} , "\n";
    10: print "Author:", $xls->{Author} , "\n";
    - - - - -
    


     Excelブックに複数のワークシートがある場合、SheetCountプロパティを取得し、その情報により各ワークシートにアクセスします。各ワークシートには、行/列の有効範囲を示すプロパティとしてMinRowとMinCol、MaxRowとMaxColがあり、それを参照することでアクセス範囲を決定できます。
     以下の例では、そのMinRowやMaxColなどの値を参照し、Excelブック上に存在するすべてのワークシートについて、全データを行/列番号付きで標準出力へ書き出しています。

    - - - - -
    11: my($row, $col, $sheet, $cell);
    12: for(my $iSheet=0; $iSheet < $xls->{SheetCount} ; $iSheet++) {
    13:  $sheet = $xls->{Worksheet}[$iSheet];
    14:  print "--------- : ", $sheet->{Name}, "\n";
    15:
    16:  for(my $row = $sheet->{MinRow} ;
    17:     defined $sheet->{MaxRow} && $row <= $sheet->{MaxRow} ; $row++) {
    18:     for(my $col = $sheet->{MinCol} ;
    19:           defined $sheet->{MaxCol} && $col <= $sheet->{MaxCol} ; $col++) {
    20:           $cell = $sheet->{Cells}[$row][$col];
    21:           print "( $row , $col ) =>", $cell->Value, "\n" if($cell);
    22:     }
    23: }
    24:}
    - - - - -
    


     以上のリストをつなげて1つのファイルとして保存し、ターミナルから「perl ***.pl ***.xls」の要領で実行すれば、Excelブックの内容がダンプされることと思います。

    ニュース解説   MOSAic

    ★★★ 開発関連のニュースはwebに掲載中 ★★★
    http://www.mosa.gr.jp/?page_id=1017

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

     

     MOSA Developer News   略称[MOSADeN=モサ伝]
            配信停止 mailto:mosaden-ml@mosa.gr.jp
     記事内容に関するご意見 mailto:mosaden-toukou@mosa.gr.jp
          記事投稿受付 http://www.mosa.gr.jp/?page_id=850
    Apple、Mac OSは米国アップル社の登録商標です。またそのほかの各製品名等
    はそれぞれ各社の商標ならびに登録商標です。
    このメールの再配信、および掲載された記事の無断転載を禁じます。
    特定非営利活動法人MOSA  http://www.mosa.gr.jp/
    Copyright (C)2007 MOSA. All rights reserved.

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

    2008-03-04

    目次

    • りんご味Ruby         第20回  藤本 尚邦
    • 藤本裕之のプログラミング夜話   #133
    • 高橋真人の「プログラミング指南」  第131回
    • 開発ツールよもやま話     Xcode3のバージョン管理

    りんご味Ruby   第20回  藤本 尚邦

    MacRubyというRuby処理系が公開されました。ということで、今回は予定を変更してMacRubyを概観します。MacRubyの特徴としては:

    ・すべてのオブジェクトがNSObject
    ・文字列・配列・ハッシュのリテラル
    ・メソッドの定義・呼出のための拡張構文
    ・Ruby 1.9ベース
    ・処理系に組み込み
    ・GCがObjective-C側のGC

    などたくさんありそうなのですが、目に留まったところを見てみます。

    ■ すべてのオブジェクトがNSObject

    MacRubyでは、クラス階層構造の頂点にNSObjectクラスがあります。RubyのオブジェクトはすべてObjectクラス(およびその派生クラス)のインタンスなのですが、そのObjectクラスがNSObjectクラスからの派生クラスになっています。

    ・Ruby 1.8では: Object < ...
    ・Ruby 1.9では: BasicObject < Object < ...
    ・MacRubyでは: NSObject < Object < ...

    このようなクラス階層構造により、すべてのRubyオブジェクトをNSObjectとして扱うことができ、Rubyプログラムで定義されたクラスもすべてNSObjectクラスの子孫となります。

     irb> class Hoge
           end
      irb> Hoge.ancestors
      => [Hoge, Object, NSObject, Kernel]
      irb> Hoge.is_a? NSObject
      => true
    


    (注) KernelはすべてのRubyオブジェクトにincludeされるモジュールです
    (注) ancestors は、すべての先祖クラスとincludeしたモジュールの配列を
    返すメソッドです

    RubyCocoaでは、必要になったときにRubyのオブジェクトをObjective-Cのオブジェクトに変換していますが、MacRubyではRubyのオブジェクト=NSObjectでもあるので、変換する必要がないということになるでしょう。

    ■ 文字列・配列・ハッシュのリテラル

    MacRubyでは、String(文字列)、Array(配列)、Hash(ハッシュ)クラスが、それぞれ、NSString,NSArray,NSDictionaryからの派生クラスになっています。

    Rubyでは文字列、配列、ハッシュをリテラルとして記述できますから、これはつまり、MacRubyではNSString, NSArray, NSDictionaryをリテラルで記述できるということになります。

      irb> "りんご味Ruby".class.ancestors
      => [String, Comparable, NSString, Object, NSObject, Kernel]
    
      irb> [ "りんご", 12345, "これは配列" ].class.ancestors
      => [Array, Enumerable, NSArray, Object, NSObject, Kernel]
    
      irb> { "りんご"=>"apple", "味"=>"flavor", "Ruby"=>"Ruby" }.
             class.ancestors
      => [Hash, Enumerable, NSDictionary, Object, NSObject, Kernel]
    


    上の配列リテラルの例では、NSArrayであるはずの配列の要素に、数値リテラルが含まれています。NSArrayの要素には、Objective-Cオブジェクトしか置くことができないので、Objective-C言語ならば、NSArrayの要素に数値リテラルを入れることはできません。しかし、Rubyでは数値リテラルもオブジェクトですから、MacRubyにおいては数値リテラルがNSObjectということになります。したがって、NSArrayであるはずの配列リテラルに数値リテラルを置くことができるわけです。

    ■ メソッドの定義・呼出のための拡張構文

    Rubyでは、キーワード付き引数の代用としてHashがよく使われています(Ruby on Railsなどで多用されています)。MacRubyでは、Objective-Cのキーワード付きメソッドの定義と呼出のために、一歩踏み込みRuby言語の構文を拡張しています。これは、Rubyプログラミングでよく使われる実行時の疑似構文による拡張ではなく、処理系のパーサ(構文解析器)自体を直接変更しています。

    キーワード付きメソッドの定義例:

    def outlineView outlineView, numberOfChildrenOfItem:item
        item ? item.numberOfChildren : 1
      end
    


    キーワード付きメソッドの呼出例:

    window = NSWindow.alloc.
        initWithContentRect( frame,
                  styleMask: NSBorderlessWindowMask,
                    backing: NSBackingStoreBuffered,
                      defer: false)
    


    この拡張構文はObjective-Cのための構文といえるので、プログラムの中では、WindowsやLinuxなど他の環境で使うことを考慮する必要のないところでのみ使うようにした方がよさそうです。

    ■ 実装はRuby 1.9 ベース

    現時点でのMacRubyは、Ruby 1.9のソースコードに対して、オブジェクトシステムやガベージコレクタに変更を加えた形で実装されています。

    RubyCocoaは、Ruby処理系のソース自体には手を加えず、実行時にObjective-C対応の変更を加えるライブラリとして実装されています。それに対して、MacRubyは、Ruby 1.9のソース自体を積極的に変更して、処理系のビルド時にRubyのオブジェクトシステムにObjectve-C対応を組み込んでいます。

    ■ RubyCocoaとの関係

    RubyCocoaとMacRubyと2つあってややこしいとか、どっちを使えばいいのかなと思われるかもしれません。基本的に用途はほとんどかぶっているので、ユーザとしてはひとつに統一してほしいところです。現時点でのMacRubyは開発まっただ中でまだまだ動かないところもあるようですが、完成度が高まるにつれてMacRubyに移行していくことになるでしょう。

    今回は、私もMacRubyを試してみたばかりで勘違いしていることもあるかもしれないのですがその点ご容赦ください。

    ■ 参考URL

    MacRuby
    http://trac.macosforge.org/projects/ruby/wiki/MacRuby

    Objective-CベースのRuby実装「MacRuby」が登場(海上さんの記事)
    http://journal.mycom.co.jp/news/2008/02/29/021/index.html

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

     前回まで、Macに限らずPCに限らずパーソナルコンピュータの普及は進み、いまやウチにパソコンがない人のほうが珍しい……ってことはないのかな、とにかくオレが最初のMacを買った頃に比べたら絶対的にとんでもないことになっているのに、その割にソフトウェアが売れないのはパソコンの使い方が違うのぢゃないか、という話をしてきたわけだが、この辺でそのヨタ話の地歩をちと固めてみたい。……つうかちょっとだけ調べてみたんだけどね。

     内閣府がやってる「消費動向調査」というのがあって、これは調査対象が2人以上の日本人世帯、つまり「イヌと外国人はお断り」……ぢゃなかった「独身者(シングル)と外国人の買うものなんかはどうでもいい」という、ちょっとどうかと思うような調査だったんだが(最近のでは単身世帯は入ってる)、ともかくそれによると1987年3月の段階でパソコンの普及率は11.7%であった。翌88年はなぜか減って9.7%、89年が11.6%と、この時期は調査対象世帯をランダムに選ぶことによって生じる誤差を考慮すればだいたい11%くらいだったわけだ。パソコンは10軒に1台、これって自家用車に比べてどうなんだろうって数字だよね。

     この数字が変化の兆しを見せるのは1994年。この年数字が13.9%、Windows95が出た翌年が15.6%、以降2005年に前年の65.7%から64.6%とわずかに下がるが、2006年には68.3%と盛り返し、昨年3月には遂に71.0%と初めて70%を超えた。やれ人口が減ってますとかパソコン市場はケータイに食われてますというが、実に10軒に7軒がパソコンを保有しているのであり、冒頭にオレが書いた「いまやウチにパソコンがない人のほうが珍しい」ってほどではないものの「ない人の方が少数派」という情勢ではあるわけである。

     こうなってみると当然「ほんぢゃそのパソコン所有者の人たちはたとえば年にいくらくらいソフトウェアにお金を使うのよ?」という辺りを知りたくなるが、残念ながら内閣府ではそういう調査はやっておらず、また結構一所懸命探したつもりなのだが民間でもそういう調査をやってるところはないみたいなので、ちょっと目先を変える……というかからめ手から攻めてみる。つまり「ほんぢゃそのパソコン所有者の人たちはパソコンを何に使っているの?」と。ね、こっちの調査だったらどっかにありそうな気がするでしょ。

     ちうわけで「パソコン 用途 調査」の三題噺……ぢゃなかった三要素でググってみるとありましたありました。「ネットワークと国民生活に関する調査」調査報告書というpdf文書。これの「情報通信機器の利用状況」の中にそのものズバリ「パソコンの用途」という調査結果を発見した。アメリカと日本、そして韓国のパソコンユーザーに

    (1)テレビ番組を見る
    (2)テレビ番組を録画する
    (3)ビデオを編集する
    (4)デジカメ画像を編集する
    (5)DVDを視聴する
    (6)音楽を聴く
    (7)音楽を編集する

    という選択肢を示し、自宅でのパソコンの用途を複数選択可で訊きました、というもの……っておい、そもそもこれしか選択肢がないのか、と思ってしまうが、興味深いのは日本人ユーザーの用途の1位がアメリカ人、韓国人のそれと違うことである。なんだと思います? 日本人のトップは「デジカメ画像を編集する(58.2%)」なんだけど、米韓の1位は「音楽を聴く」なんである。あ、なるほど一時「あるのはデジカメ付属ソフトの仕事だけ」みたいな状況だったもんね。……ちうか、そうなのである。これってほとんどMacやPC(とデジカメ?)買えばその日からできちゃうことばかりではないか。

     とにかくそういうことなので、オレの「パソコンが普及したわりにソフトウェアがそれに比例して(別に比例まで望んでないのにさ)売れてないのはなんでだ」という疑問というか問題意識にはちゃんと根拠があるということが確認できたわけだ(できたでしょ?)。次回からは「なんでだ」の中身を掘り下げつつ「それをなんとかすることができるんだろうか」という方向に話を進めて行きたい(もんである)。
                           (以下次回 2008_02_29)

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

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

    〜XcodeによるPowerPlant X入門(20)〜

     こんにちは、高橋真人です。早速、前回のコードの解説をします。
     今回のプログラムで目新しい部分はPPx::Viewの拡張です。それについてはあとで説明しますが、その前に今回“ついで”に加えた新しい部分を説明してしまいましょう。
     MyApplication.cpのウインドウを生成する部分で、Windowの生成直後に以下のようなコードがあります。

     if (theWindow) {
          PPx::View *contentView = theWindow->GetContentView();
    
          HIRect contentFrame;
          contentView->GetLocalFrame(contentFrame);
    
          HIRect frame = CGRectOffset(
              contentFrame, 20.0, contentFrame.size.height - 60.0);
          frame.size = CGSizeMake(120.0, 40.0);
          MyView *view =
              PPx::CreateView(contentView, frame,true, true);
    
          PPx::BindingsFrameAdapter *adapter = new PPx::BindingsFrameAdapter;
          adapter->SetBindings(true, false, false, true);
          view->SetFrameAdapter(adapter);
    
          ::RepositionWindow(
    ...
    


     ボタンとして機能するMyViewのための矩形(frame)を、前回のような決め打ちの値にせず、ウインドウの位置から割り出して左下に配置されるように調整してあります。コード量を減らすために少し変な書き方になっていますが、以下のように書いてももちろん同じことです。

    HIRect frame = CGRectMake(
        20.0,
        contentFrame.size.height - 60.0,
        120.0,
        40.0);
    


     PPx::CreateView()によってMyViewを生成しているすぐあとにあるPPx::BindingsFrameAdapterというのは、このビューの上位ビューの大きさが変化した場合にどのように追随するかを指定するものです。SetBindings()に与える4つの真偽値パラメータがそれぞれ左、上、右、下を表します。言葉でいろいろ説明するよりも、この値の組み合わせをいろいろ変更してプログラムの挙動を見るのがいちばん理解しやすいでしょう。
     それでは、拡張したMyViewの解説です。表示されている青い四角(これが、MyViewのインスタンス)をマウスでいじってみると、ボタンと同じように動作することが分かるはずです。
     MyView上でマウスボタンを押すと、青い色が濃くなります。そのままマウスボタンを放すとボタンをクリックしたことになり、「Clicked」というアラートが表示されますし、ボタンを放さずにポインタをMyViewのエリアから出すと、青い色が最初の状態に戻ります。もちろんそのままマウスボタンを放すと、クリックはキャンセルされます。
     このように、ボタンの振る舞いをするViewがどんな仕組みで動いているのかは、MyViewの定義を見ればすぐに分かります。ヘッダファイル(MyView.h)を見ると、MyViewはPPx::BaseViewに加えてさらに4つのクラスから継承されていることが読み取れます。それぞれのクラスは個別にイベントハンドラを加えているわけです。
     どのクラスがどのハンドラに対応しているかは、いちいちクラスのソースを見なくても、名前から容易に想像が付くと思います。でも、ここでもっと大切なのは、ボタンの挙動を実現するためにそれぞれのイベントハンドラがどのように連携しながら機能しているかを理解することです。
     HIView(=Control)に絡むCarbonイベントのハンドラを持つクラスは、PPxViewEvents.hにリストアップされているのですが、この中を見てみますと、いかにもボタンにふさわしそうな名前のControlClickDoerなんてものがあったりします。しかし今回のMyViewの継承元としては、意外にも登場していません。
     さて、ここでBaseViewに加えた4つのハンドラがどのように連携しているのかを説明するのも一興ですが、言葉でああだこうだ説明するよりも実際に動いているものを観察した方がずっと分かりやすいと思います。お勧めの方法は、各ハンドラの先頭に、呼び出された時にログを吐き出すメッセージを仕込んでおくことです。
     たとえば、

    OSStatus
    MyView::DoControlHitTest(
        PPx::SysCarbonEvent&    ioEvent,
        ControlRef              inControl,
        const HIPoint&          inHitPoint,
        ControlPartCode&        outPartCode)
    {
    #pragma unused (ioEvent, inControl)
    
        ::CFShow(CFSTR("DoControlHitTest called."));
    
        OSStatus status = eventNotHandledErr;
    
        HIRect frame;
        GetLocalFrame(frame);
    
        if (::CGRectContainsPoint(frame, inHitPoint)) {
            outPartCode = kControlButtonPart;
            status = noErr;
        }
    
        return status;
    }
    


    というような感じです。こうすると、マウスのアクションに対して、Viewがどのように(Carbonイベントを通じて)反応しているかが観察できると思います。表示されるメッセージを少し工夫すれば、かなり多くのことがわかるはずです。

    開発ツールよもやま話     Xcode3のバージョン管理   高橋 政明

     Xcode3ではいろいろな改良が加えられました。バージョン管理(ソースコード管理)もその一つです。
     Xcodeユーザーガイドではバージョン管理(Version Control)となっていますが、XcodeのメニューではSCM(ソースコード管理)となっていて混乱すると思いますので、最初に用語をまとめます。

    バージョン管理: Xcodeユーザーガイドの表記です。
    ソースコード管理: バージョン管理と同じ意味です。
    SCM: Xcodeのメニューです。(ソースコード管理の頭文字)
    subversion: バージョン管理ツールのひとつです。
           (XcodeではCVSとPerforceも利用可能)
    リポジトリ: バージョン管理ツールのデータベースファイルです。

    さてXcode3のバージョン管理ですが
     リポジトリをXcodeに登録できるようになり、ターミナル操作が必要な場面が少なくなった。
     ファイル比較ツールがXcodeに内蔵されUTF-8エンコーディングで日本語コメントがあっても正しく比較できるようになった。この二点が最大の改善点です。

     これらの変更点をXcodeユーザーガイドでみても『SCMの拡張。読み込みやチェックアウトなど、すべてのSCM操作を「Xcode」で実行できます。』としか載っていません。調べてみると
    Xcode Source Management Guide
    http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeSourceManagement/30_Source_Control/chapter_3_section_2.html
    に英文ですが説明がありました。

     チェックアウトやインポートもターミナルを使わずにXcodeで可能です。
     リポジトリそのものを作る操作だけはできませんが、リポジトリが存在していればそれをXcodeに登録するだけで利用可能です。

    ◆Xcode3のバージョン管理の利用手順
    1)リポジトリを登録
    2)チェックアウト
    3)チェックアウトしたプロジェクトの「SCMリポジトリ」を設定
    となります。

    具体的には
    1)リポジトリを登録
     Xcodeの環境設定で「SCM」の「リポジトリ」タブを選ぶ
     リポジトリリストに追加するため「+」ボタンをクリック
     名前と「subversion」などの種類を選ぶ
     リポジトリのURLを入力する(必要ならポート、ユーザ、パスワードなども
    入力する。SSHのパスフレーズはSSHタブで設定する。)
    以上で問題なければ緑のアイコンと『認証されました』の文字が表示されま
    す。

    2)チェックアウト
     SCMメニューの「リポジトリ」を選ぶ
     リポジトリを選ぶ
     チェックアウトするフォルダを選ぶ
     ツールバーのチェックアウトアイコンをクリックする
     保存先を指定する

    3)チェックアウトしたプロジェクトの「SCMリポジトリ」を設定
     チェックアウトしたプロジェクトを開きSCMメニューの「このプロジェクト
    のSCMを構成...」メニューを選ぶ
     (プロジェクトの情報パネルの「一般」タブが開きます)
     「SCMリポジトリ」で1で登録したリポジトリを選ぶ

    1〜3の手順でチェックアウトが完了しバージョン管理が利用可能になります。

     リポジトリウインドウのツールバー「書き出す」はsubversionならexportです。バージョン管理情報を含まないプロジェクト一式が保存できるので、納品などにはこちらを利用します。
     同様に「読み込む」がインポート機能(subversionならimport)です。インポートするフォルダを選び、初期コメントをシートに入力するだけの操作です。ただしフォルダ名がそのままになるのであらかじめプロジェクト名のフォルダをリポジトリ内に作成し、読み込むフォルダ名をtrunkとしてから「読み込む」を行うのがコツのようです。この操作は改良の余地がありそうですね、コマンドラインに慣れているならそちらの方が確実と思いました。操作方法が変わる可能性があるためにマニュアル類に載っていないのかも知れません。

    ◆ファイル比較にXcodeを指定する
     Xcodeの環境設定で「SCM」の「オプション」タブを選ぶとXcode3では比較の方法で「Xcode」が選べます。FileMargeを使った比較では問題のあったUTF-8エンコーディングのファイルでも問題なく比較できます。もちろん比較するソースリスト内に日本語のコメントがあっても大丈夫です。
     Xcodeのファイル比較は便利なのですが、バージョン管理を使わずに比較機能だけ単独で使う方法は見つけられませんでした。

     Mac OS X v10.5ではsubversionがDarwinに含まれたためインストール作業も必要なくなり、バージョン管理はすぐに(しかも無料で)はじめる事ができます。バージョン管理は個人で開発している場合でも重要で有用なツールです。すべての開発者に導入をおすすめします。

    subversionについてはモサ伝251号の書籍紹介でご紹介した「Subversion実践入門 第2版」などを参照してください。

    ◆本日のまとめ
    Xcode3のバージョン管理は強化された。
     リポジトリを登録できチェックアウトもターミナルをつかわずに可能
     比較ツールがXcodeに内蔵され対応可能なエンコーディングが増えた

    ニュース解説   MOSAic

    ★★★ 開発関連のニュースはwebに掲載中 ★★★
    http://www.mosa.gr.jp/?page_id=1017

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

     

     MOSA Developer News   略称[MOSADeN=モサ伝]
            配信停止 mailto:mosaden-ml@mosa.gr.jp
     記事内容に関するご意見 mailto:mosaden-toukou@mosa.gr.jp
          記事投稿受付 http://www.mosa.gr.jp/?page_id=850
    Apple、Mac OSは米国アップル社の登録商標です。またそのほかの各製品名等
    はそれぞれ各社の商標ならびに登録商標です。
    このメールの再配信、および掲載された記事の無断転載を禁じます。
    特定非営利活動法人MOSA  http://www.mosa.gr.jp/
    Copyright (C)2007 MOSA. All rights reserved.