MOSA Multi-OS Software Artists

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

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

Sketchのプロジェクトフォルダは /Developer/Examples/AppKit/Sketch にあります。このフォルダを適当なところにコピーして、改造用のSketchプロジェクトとしてください。コピーしたらとりあえず、Xcode3でSketch.xcodeprojを開いて、ビルド・実行してみて、まったく手を付けていない素のSketchが動作することを確認しておくとよいでしょう。よろしいでしょうか？　では機能追加にとりかかります。

■ RubyCocoaフレームワークを追加

まずは、以下のような手順でRubyCocoaフレームワークを追加してください。

・プロジェクトウィンドウ内のグループとファイルの一番上、Sketchプロジェ
クトの中にあるExternal Frameworksグループを選択
・コンテキストメニューで「追加/既存のフレームワーク」コマンドを実行
・/System/Library/Frameworks/RubyCocoa.framework を追加

■ RubyCocoaを初期化するおまじない

次に、Sketchのmain関数にRubyCocoaを初期化するためのおまじない的なコードを書き加えます。main関数が定義されているSKTMain.mを開いて以下のように2行を書き加えてください:

--------------------------------------- SKTMain.mから抜粋 --
#import 
#import                   // 追加1

int main(int argc, const char *argv[]) {
 RBApplicationInit("main.rb", argc, argv, nil); // 追加2
 return NSApplicationMain(argc, argv);
}
-------------------------------------------

RubyCocoaフレームワークの関数RBApplicationInitは、アプリケーションのためにRubyCocoaを初期化します。この関数が呼ばれると、RubyCocoa自体を初期化(まだ初期化されていなければ)して、そのあと、一番目の引数で指定されたRubyプログラム(ここではmain.rb)が実行されます。

SKTmain.mをXcode3で編集している場合は、RBApplicationInitのところにマウスをおいてコンテキストメニューの「定義へジャンプ」コマンドを実行すると、ヘッダーファイルRBRuntime.hにあるRBApplicationInitの宣言と簡単な説明を読むことができます。

■ main.rb の記述

次にmain.rbを作ります。以下のような手順でmain.rbを生成してください:

・プロジェクトウィンドウで、Sketchプロジェクトを選択
・コンテキストメニューで「追加/新規ファイル」コマンドを実行
・Ruby application init を選択
・main.rb という名前で保存

生成されたmain.rbを開いてください。以下のようなRubyプログラムが生成されています。

------------------------------------------- main.rb --
require 'osx/cocoa'

def load_ruby_programs(bundle)
 path = bundle.resourcePath.fileSystemRepresentation
 rbfiles = Dir.entries(path).select {|x| / .rb z/ =~ x}
 rbfiles -= [ File.basename(__FILE__) ]
 rbfiles.each do |path|
   require( File.basename(path) )
 end
end

OSX.init_for_bundle do |bundle, param, logger|
 # bundle  - the bundle related RBApplicationInit
 # param   - the 4th argument of RBApplicationInit
 # logger  - NSLog wrapper for this block
 #             usage: log.info("param=%p", param.to_s)
 load_ruby_programs(bundle)
end
-------------------------------------------

先に説明したように、RBApplicationInitが呼ばれると、このmain.rbが実行されます。

ごちゃごちゃと書かれているように見えるかもしれませんが、手短に説明すると、このプログラムは、アプリケーションバンドルの中のResourcesフォルダの中にあるすべてのRubyプログラム(拡張子が.rbのファイル)をロードしています(load_ruby_programsの中身)。

[余談] ちょっと細かい話をすると、main.rb自体もResourcesフォルダの中に置かれるのですが、ということは、main.rb自体が再帰的に無限にロードされてしまうのではないかと心配になりませんか？　load_ruby_programsメソッドの

rbfiles -= [ File.basename(__FILE__) ]

の行のところで、自分自身(main.rb)を採取したRubyプログラムの一覧から取り除いて再帰的なロードが発生しないようにしてあります。Rubyプログラムでは、そのプログラムが記述されたファイルへのフルパスが __FILE__ という定数に定義されています。[余談終わり]

さて、このmain.rbがちゃんと実行されているか確認の意味を兼ねて、RubyやRubyCocoaのバージョン情報をログに出力するようにコードを書き加えることにします。main.rbの OSX.init_for_bundle のブロックの中身を以下のようにしてください:

OSX.init_for_bundle do |bundle, param, logger|
 logger.info("RUBY_VERSION=%s", RUBY_VERSION)
 logger.info("RUBYCOCOA_VERSION=%s", OSX::RUBYCOCOA_VERSION)
 logger.info("RUBYCOCOA_SVN_REVISION=%s", OSX::RUBYCOCOA_SVN_REVISION)
 load_ruby_programs(bundle)
end

■ RubyCocoa組み込み完了

今回はここまでです。ビルド・実行してみてください。コンソール(実行メニューのコンソールコマンド)を見るとRubyとRubyCocoaのバージョンが出力されていれば、うまく動いているということになります。いかがでしょう？

これで下準備はできました。Sketchでは、ツールパレットから4種類のグラフィックオブジェクト(Rectangle, Circle, Line, Text)を選んで描くことができます。次回は、Sketchに、5つめのグラフィックオブジェクトとして角丸四角形RoundRectangleを、Rubyプログラムとして組み込んでみることにしましょう。

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

　ちょっと時間が経ってしまったがみなさん、明けましておめでとうございます。
　実を言えばこの新年第一回の原稿を書くにあたり、谷川俊太郎が水尾比呂志への結婚祝いにハンカチーフを選んだときのように（「あれにしようかこれにしようか散々迷った挙句に買った結婚祝につけて水尾比呂志に贈る祝婚歌。又は、ハンカチーフの能について」という詩があるのだ）迷ってしまった。せっかく新年と共に始まるシリーズだし、なんか目新しいことをやりたいと思うのだがここんとこオレ自身がCocoaを使ってプログラムを書くてな仕事をやっておらず、これというネタが思い浮かばないのである。

　タカハシ編集長に相談したところ、「別にコードを含む記事でなくてもかまいません。たとえば『アプリケーション・プログラマは絶滅危惧種なのか？』というテーマでエッセイを書くというのはどうですか？」と言う。……いや正確にはメールに書いてきた。一瞬なるほどそのテか、と思ったが、そんなものを書いて「そうだ、我々はニホンオオカミのよう……ならまだしも、ドードー鳥のようにこれから絶滅していくしかないのだ」ちう結論に達してしまうのもコワイ（コワイでしょ？）やないの。

　実際のところ、最近街で石を投げれば（投げませんけど）「IT技術者」に当たり、その「IT技術者」に会社でどんなことやってんのと聞けば（聞きませんけど）彼らは十中八九我々のようなプログラマではなくて、いわゆる「ネット屋さん」であり、その仕事の内容も「ものを作ってる」というよりは「コンピュータ（サーバって言ってもいいけどさ）のお守りをしてる」に近いようだ。……こないだとあるお好み焼き屋で隣のテーブルを囲んでいた30代前半男女5人組から漏れ聞こえてきた会話をベースにしての想像で、もちろん統計的価値は全くないけどそれほど間違ってないと思う。

　そう言えばむかしむかしあるところに須藤慎一というヒトがいて（いま何してんだろと思ったら朝日新聞とかにセキュリティ関係の原稿を書いていた）、そのヒトの書いた「愛すべきハッカー」という本に、「コンピュータ関係の仕事として最低にランクされるのが『プリンタのおもり』、『テープかけ』、『カード読ませ』である」という記述があった。スドーさんはこれらの仕事の中身を詳しく説明し……あ、ここでも説明が必要かな？　もはや『カード読ませ』なんて羅宇屋とか射掛け屋と同じくらい珍しい仕事ではあるけど（笑）。

　とにかくハナシは「これらの仕事にはコンピュータ関係の知識はほとんど必要ないかわり、ひたすら体力と忍耐力が要求される。だからちょっとでもプログラムを組めるような学生ならこんな仕事はまず選ばない」（記憶で書いてるのであんまり正確な引用ぢゃありません）と続く。もうちっとましな仕事としてCOBOLをつかう業務用のオフコンソフト開発……これもあんまり頭は使わない。あ、いや、これはスドーさんがそう書いてたんであってオレの意見ぢゃないからね。

　で、ここまでくるともう想像がつくと思うが、当時「コンピュータ関係の仕事」として最も頭を使い、やりがいがあり、そしてそれなりにお金になる、とされていたのが「マイコン（つう言葉が現役だったころの本なのだ）組み込み機器やパソコンのためのソフト開発」であったのである。いや、あったのであるって他人事ぢゃなくて、そうだったからオレはいままでそれで食ってきたんだし、これを読んでいる大半のヒトがそうでしょ？

　しかし上にも書いたように、現在「IT技術者」と言ったら「サーバのおもり」になってしまった。「プリンタのおもり」よりは頭を使うかも知れないが（そしてそれなりに勉強も必要だろうけど）、少なくともオレには、あれが自分でイチからプログラムを作るほど面白い仕事とは思われない。でもタカハシ編集長の危機感どおり、なんつうかワクワクするようなプログラミング仕事の絶対量は減っている。なんでかしら？

　うーん、確かにコワイ結論になるかも知れないが、これについてちゃんと分析してみるのは面白そうである。つうことで、しばらく技術系のおハナシは他の方に委せ、このテーマを追っかけてみましょう。ご意見文句激励圧力などいただければケースバイケースでそれなりに歓迎撃退感謝反撃などいたしますのでどうぞよろしく。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　（2008_01_18）

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

コミュニケーション能力を高めよう(1)

　皆さんこんにちは、高橋真人です。
　今回は、今年最初の連載ということでもありますので、いつものお話をお休みして、年頭らしいお話をしたいと思います。テーマは、去年ぐらいから私の頭の中にある「言葉はデジタルだ」というお話です。

　人と人とが情報交換、つまりコミュニケーションを行う場合に大きな役割を持つのが言葉です。「“コンピュータとの会話”とかいう話なら分かるけど、人同士のコミュニケーションがプログラミングに何の関係があるの？」と思う人もいるかもしれません。
　プロのプログラマであれば、ユーザやお客さんとのコミュニケーションもプログラミングの一要素であることを否定する人は少ないでしょう。また、プログラムを作れば、そのプログラムを通してユーザーとの間にコミュニケーションが発生します。
　このように、プログラマにとってコミュニケーション能力が欠かせない資質の一つであることはお分かりいただけると思います。しかし今回は、まだプログラマとは自覚していない、この連載のもともとの対象読者であるプログラミングの学習者に焦点を当ててお話しします。
　それでは、プログラミング学習者という立場における対人コミュニケーションにはどのようなものがあるでしょうか。
　まず、人からプログラミングを習う場合、ここには当然コミュニケーションが成立します。一対一で教わるという恵まれた立場にはなくとも、講習会などに参加すれば、そこには講師と受講生という形でコミュニケーションが発生します。
　このような“空間を共有した”やり取りにおいては、言葉も重要な伝達手段であると同時に、言葉以外のいろいろな要素も大きく介在します。視覚や聴覚はもとより、ちょっと五感では表しにくい「何となくの雰囲気」などというのが、意外と「言葉にならない言葉」を伝えていたなんてこともままあることです。
　では、言葉以外の情報伝達手段が存在しない、書籍による学習のような場合はどうでしょう。
　コミュニケーションというと、双方向的なもののみを前提にすることも多いかもしれませんが、ここでは本のような一方向のみの情報伝達もコミュニケーションととらえて話を進めたいと思います。まあ、コミュニケーションという呼び方に抵抗があるならば、情報伝達と言い替えていただいても全く構いません。ちなみに、今まさに皆さんがこの文章を読んでいるのも、文字のみによるコミュニケーションであるということにはお気付きですか？
　さて、このような文字のみによるばかりか、一方通行の情報伝達ですといろいろな制約がありますから、充実したコミュニケーション、つまりより多くの情報を効率的かつ高精度に伝えるには、送り手である筆者と、受け手である読者の能力の巧拙が大いに影響してきます。
　まずは本を例にして、作者から読者への情報伝達の流れをざっと見てみましょう。

・作者が伝えたいことがある（思い）
・文章に起こす
・読者が文章を読む
・読んだ文章を理解する（→思い）

　作者が考えをまとめるとか、取材をするとか、編集者が手を入れるなどの細部は一切無視して考えますが、ここで送り手である作者から受け手である読者へ送られる情報の中身である「思い」は、二段階の変化をすることに注目してください。
　作者が自分の思いを言葉にするとき、ここでは頭の中の漠然とした思いが言葉という明確な形に変換されます。そして、読者がその言葉を読むと、今度は読者の頭の中に「理解」や「解釈」という形である種の「思い」が形成されることになるわけですが、ここにおいても「言葉から思い」への変換処理が行われることになります。
　私が「言葉はデジタルだ」ということで伝えたいのはまさにこの部分です。何も「電子的に」とか「数値的に」とかいうことを言いたいのではなく、言葉というのはデジタルデータとしての性質を持つものだということを言っているのです。
　簡単に解説しましょう。
　皆さんご存知のCDですが、これは音というアナログ情報を数値化することで盤面に記録します。ところが、数値化をするに当たって避けて通るのができないのが、情報の切り落としということです。
　余り詳しいことを書いている余裕はないのですが、CDでは44.1kHzがサンプリング周波数です。これは、すべての音の中から22.05kHz（1秒間に22,050回の振動）までの音のみを切り出して数値変換（デジタル化）することになります。自然界の音というアナログの存在を数値化するに当たって、この切り出し作業は宿命なのです。
　もともとCDの規格を作る際には、人間の可聴領域（およそ15,000〜20,000Hz）に多少の余裕を持たせたもので充分だろうと思われていたのですが、その後の研究で、人間は意識的に聞こえていない高周波成分も、何らかの形で感じていることが分かり、もっと高い音も記録できるべくSACDなどの技術も生まれています。
　ただ、どんなに情報量を増やしてもデジタルである限り「完璧に」収録することは不可能です。
　人間が文章を書く際にも同じことが言えます。文章が生み出されるとき、そこにはアナログ→デジタル変換（A/D変換）が起こっています。つまり、書き手が自分の頭の中の思いを言葉にする際に「言葉を選ぶ」作業をします。これは数値化の時と同じく、情報の切り落としになります。自分の思いをそのまま言葉に完璧に表すことはできないので、一所懸命に「より適切な言葉」を探すわけです。
　文章を読む読者の側でも変換が行われます。文章を読んでそこから何かを得る作業、つまり読解力というものは、言えばデジタル情報になった言葉をアナログに戻すための変換作業（D/A変換）であり、この能力が低ければ、やはり書き手の意図はうまく伝わりません。
　このように、言葉による情報の受け渡しには、A/D、D/Aの二回の変換処理が行われるため、各変換処理エンジンの性能（要は、作文力と読解力です）によって、伝わる中身が大きく影響を受けてくるわけです。
　皆さんがプログラミングの勉強をする際に、本を選ぶ作業も大切です。何故なら、皆さんが本を読もうとする時点では、既に作者の側の変換作業は完了してしまっています。そして多くの場合、本の向こう側にいる人がどれだけの情報を持っているのかをあらかじめ知っていることはありません。
　よって、当然のことながら最初の段階としてはまず、いかに的確に本を選ぶかという作業が重要になってくるわけです。

開発ツールよもやま話　　　　　　Interface Builder3　　　　高橋 政明

　レパードになり開発ツールは大幅に強化されました。XcodeもInterfaceBuilderもバージョンが3.0に上がりました。
　特にInterface Builderは別のアプリケーションと思える程のかわり方です。もちろん単に変わっただけではなく機能面で大幅に強化されています。
　Interface Builderはアイコンからドライバーがなくなりました。アプリケーションであることを示唆する「道具」は三角定規になりました。Xcodeが
設計図の青焼きとハンマーで変わらないことと比べてもInterface Builderが生まれ変わった事がわかります。（Xcodeもバージョン3.0でハンマーの向きが変わっていますが）
　余談ですが、青焼き（ジアゾコピー）って現代の若者にとっても「図面」を象徴しているのでしょうか？（これは『アイコン作りは難しい』という話題につながるのですがそれはまた別の機会に）

　歴史的にInterface BuilderはNeXTのツールでOPENSTEP直系のツールとして
Rhapsody（ラプソディ）の時代から基本部分はあまり変わっていませんでした。
　手元にある古い資料（DISCOVERING OPENSTEP:A Developer Tutorial）を見るとInterface Builderのアイコンもウインドウも、TigerのXcodeToolsに含まれるInterface Builderバージョン2.5と大きな違いはありません。
　nibに対応するウインドウにはInstances Classes Imagesの三つのタブがありツールパレットのツールはメニュー、コントロール、ウインドウ、テキストと順番が若干違いますが機能は同じようです。
　AppleがRhapsodyを打ち出した当時は、配布された『Prelude To Rhapsody
Release 4.1 for Windows』の動作環境がWindowsのみであったこともあり、あまりにも違う開発環境に大変戸惑いました。これは私だけでなく多くのMac開発者共通で、AppleもほどなくCarbonを打ち出しMac OS X用の開発環境に加えた事はご承知の通りです。私自身Cocoaの開発環境に慣れるには期間が必要でした。

　さて、レパードのInterface BuilderはClassの扱いが大きくかわりました。
　Classesのタブもメニューもなくなってしまったため戸惑った方も多かったはずです。MOSAdeBB（会員掲示版）プログラミング技術Q&A 初級／InterfaceBuilder3でカスタムクラスを登録する方法　でも話題になっていましたが、私もとまどった一人です。

　Classes操作が変わったため、アウトレットやアクションの接続先となるオブジェクトのインスタンス化が従来の方法が使えなくなりました。かわりにライブラリパレットからObjectをドラッグ＆ドロップしてclass名を選択します。（以下の例はnib修正前にXcode3で、ソースのヘッダファイルでクラスの@interface 以下を正しく記述し保存した前提です）
　具体的には
1）ライブラリパネルでObjectを選び
2）ライブラリ＞Cocoa＞Objects & Controllersをクリックする
3）青い立方体が「Object」なので
　これをnibのウインドウへドラッグ＆ドロップする
4）nibのウインドウで上記ドロップしたObjectアイコンを選択する
5）toolsメニューでIdentity Inspectorを選ぶ
6）Inspectorパネルのclass Identityでクラスを選ぶ
の手順になります。6で自分で定義したクラスがリストにない場合、ヘッダ
ファイルをnibウインドウへドラッグ＆ドロップしてからもう一度試してください。

　Xcodeとの連携が強化されたのは嬉しい点です。nibウインドウの一番下にズームボタンを小さくしたような緑色のインジケータとプロジェクト名が表示されていれば同期中です。プロジェクト名をクリックするとXcode3に切り替わります。この状態でXcode3でアウトレットの名称を「リファクタリング」機能を使って変更するとnibファイル側も自動的に変更されます。これは強力でとてもありがたい機能です。接続し直す作業は不要となりました。

◆本日のまとめ
　Interface Builder3は対応するプロジェクトを同時にXocode3で開いていると連携処理を行います。

ニュース解説　　　MOSAic

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

・12月のニュース
http://www.mosa.gr.jp/?p=1476

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