2005-04-05
目次
「WebObjects Dev Report」 第1回 田畑 英和
皆様あらためましてこんにちは! 前回まで「Behind the WebObjects」のタイトルでWebObjectsの解説をおこなってきました田畑です。予告どおり今回から内容を切り替えて新しい連載を始めることになりました。よろしくお願いします。
とはいいましてもあいかわらずWebObjectsをテーマにしていくのですが、これまでは様々な技術を個別に解説してきたのに対し、これからは実際に1本のアプリケーション(2本3本と増えていくかもしれませんが)を開発しながらその過程を逐次この連載で紹介していきます。そんなわけでしてタイトルのほうは「WebObjects Dev Report」と名付けました。
WebObjectsのもつ機能を利用すればデータベースアクセスなど様々なことが実現できますが、実際にアプリケーションを開発するとなると色々なことを考慮していく必要があります。システム構成をどうするだとか、要件分析をおこなうだとか、設計、テスト、ドキュメント作成、場合によってはトレーニング、保守運用なども必要になってきます。
こういったことをすべてこの連載で網羅するには限界がありますが、まずは「実運用に耐えうるアプリケーションをいかにして開発していくか」という実践的な内容を目標に連載を進めて行きたいと思います。連載をとおして実際にアプリケーションを開発していくわけですから、現場で発生する様々な問題を取り上げていくことになりますので、WebObjectsで開発をおこなっている方々、あるいはこれから開発を始めてみようと考えている方々に対してなるべく有益な情報を提供していくことができればと考えています。
どういったアプリケーションを開発していくかですが、「ビジネスマッチングシステム」の開発をおこなっていきます。MOSA会員の方々はご存知かと思いますがMOSAのWebサイト上ではビジネスマッチングサービスがおこなわれています。
・MOSAビジネスマッチングシステム
http://www.mosa.gr.jp/htmdocs/service-teikyo-bizmatch.htm
ここではMOSA会員がジョブスキルを登録・公開することにより、企業・人とのマッチングをおこない、ビジネスのサポートをおこなっています。具体的にはMOSA会員資格をもった方が開発経験などのスキルシートを登録し、その情報を会員・非会員にかかわらずどなたでも閲覧できるようになっています。
登録者へのコンタクトを希望する場合はMOSA事務局が仲介をおこない、その後は双方で話を進めていくというのが現状のスタイルになっています。情報を登録できるのはMOSA会員に限定されていますが、公開されている情報は誰でも閲覧することができます。
今回はこのビジネスマッチングシステムをWebObjectsを使ってリニューアルしていくのがテーマになります。現状のシステムをもとにシステムの概要を分析してみますと、ユーザ別に考えた場合は以下のようになります。
・情報提供者
ユーザ:MOSA会員
役割:スキルシートを登録し情報を公開
・閲覧者
ユーザ:誰でも
役割:公開情報を閲覧し仲介のうえ情報提供者にコンタクト
・仲介者
ユーザ:MOSA事務局
役割:コンタクト希望者と情報提供者との仲介など
これらのシステムを今後リニュアールしていくことになります。具体的にどこまで細かくレポートできるか模索しながら連載を進めていくことになるかと思いますが、ソースコードの公開も含めなるべくオープンな形で進めていければと思います。
話題が変わりまして、今年もApple社の開発者向けConference「WWDC」が開催されます。すでに参加を検討されている方は概要をご存知かと思いますが、会場は今年もサンフランシスコで6/6-10の日程で開催されます。ここ数年、残念ながらWebObjects関連のセッションは減少傾向にあり、なんといっても新しいニュースがないのが不安材料でしたが、現在公開されているセッション内容をみてみますとなにやら期待できそうな内容が掲載されています。内容についてはぜひ直接こちらをご覧になってください。
・WWDC2005 Enterprise ITトラック一覧
http://developer.apple.com/wwdc/descriptions/desc-enterpriseit.html
というわけで、今回から新連載が始まりました。連載も隔週から毎週に増えることになり、なるべく実践的で有益な情報をどんどん発信していければと思いますので読者の皆様よろしくお願いします。
藤本裕之のプログラミング夜話 #66
NSApplicationの話もこれが最後。アプリケーションが終了するときの話である。前回(あれ、前々回だっけ?)起動のときに書いたように、Nibファイルで定義しインスタンシエートしたオブジェクトはアプリケーションが起動されるとメモリ上にその場を与えられ、IBOutletやIBActionといったコネクションが確立されたところで awakeFromNib というメッセージを受け取る。
例えばここに、ダイアログボックスを通して……なんでもいいがそのアプリに関する設定をおこなうオブジェクトがあるとする。このオブジェクトがawakeFromNib を受け取ると、NSUserDefaults のクラス・メソッドstandardUserDefaults を呼び出し、そこから前回ユーザーが行なった設定を読み込んでそれをダイアログボックス上に再現する。あるスイッチがオンだったのならそれに対応するチェックボックスの state をオンに設定するというようなことだ、わかるよね? つまり初期設定の読み込みはこのタイミングでできる。では逆に初期設定を保存するのは?
実はここが今回のミソなんだが、awakeFromNib のタイミングで初期設定を読み込むのならそのオブジェクトが破棄されるとき、つまり dealloc を呼ばれたときに書き込めばいいんぢゃないかと思うわけだ。え、そうですかって?思わないヒトもいるかも知れないけどオレは最初そう思ったんだよ。
ところが、だ。これもあんまり……というか今までオレが読んだCocoaに関する本にはちゃんと書かれていたことがないのだが、この dealloc というメッセージ、送ってもらえるオブジェクトとそうでないオブジェクトがあるのである。上の例に出てきたダイアログボックスを使うオブジェクトなんか、たいがいは dealloc を送ってもらえず、なんでユーザーの設定が保存されないんだろうとプログラマが首を傾げるタグイである。
あんまりもったいぶっててもしょうがないのでタネ明かしをしてしまうと、アプリケーションの起動とともにNibファイルから読み出され、アプリケーションの終了以外では(まぁプログラムがわざわざ明示的にそれをやってれば別なんだが)その破棄がおこらないオブジェクトには、アプリの終了時にイチイチdeallocを送らない、ということである。
こう言ったら解りやすいかな、例えばあなたが壊れたパソコンを破棄するとき、いちいち部品をばらばらにして破棄したりはしないでしょ? それと同じ、そもそもdealloc の目的はメモリの解放だから、それを含んでいるアプリ全体の使用域がご破算になるのにチマチマと個々のオブジェクトに解放メッセージを送るのは時間の無駄ってこと、なんだよ。
それぢゃ初期設定はいつ書き換えればいい? そのタイミングは状況によって2つ考えられる。簡単なのは上の例のようにアプリの稼働中に開閉されるダイアログの場合、ダイアログのオープンが要求されたら初期設定を読み込み、閉じるときに書き込めばいい。しかしそうはいかないオブジェクトもあるよね、アプリが稼働している限り出ずっぱりのウィンドウの CustomViewとか……。
そこで、お馴染みNSApplicationの登場だ。ユーザーがアプリ終了のオペレーションを行なうと、NSApplicationはそのdelegateに対してapplicationWillTerminate: というメッセージを送ってくる。これを受け取ったdelegate オブジェクトが、初期設定を保存する必要のあるオブジェクトたちにそれを行なうためのメッセージを送ればいい。簡単でしょ?
やぁやれやれ、やっとこれでNSApplicationの概説はおしまいである。次回からは次なる大物、NSViewを取り上げて、Cocoaにおけるイベントハンドリングの実際を解説して行こうと思っている。御用とお急ぎでないかたは引き続きご愛読をよろしく。
(2005_03_31)
高橋真人の「プログラミング指南」第65回
UNIXとしてのMac OS X
〜Perlについて(11)〜
こんにちは、高橋真人です。
さて、前回の最後に「コードを読みづらくする要素」を余り使わずに記述するところもPerlのメリットだ、ということを申しました。Perlのこの辺のところは、「ちょっとやり過ぎ」の観があるくらいに徹底しています。
例として、以前紹介した以下のようなコードを使いましょう。
print ‘Hello’ if (/^$/);
これは、変数$_の中身が空文字列の場合にHelloと出力するというものですが、この条件がひっくり返った場合にはどうなるかと考えてみます。
print ‘Hello’ if (! /^$/);
もちろん、このように否定演算子を使って条件をひっくり返してやれば済む話です。少なくともCの場合ならば。そして、これはPerlにもちゃんと当てはまります。ところが、Perlではこの条件をひっくり返す代わりに何とunlessというものが用意されています。
これを使うと上の文は、
print ‘Hello’ unless (/^$/);
となります。つまり、$_が空でない場合にHelloと出力するということになるわけです。
ちなみにCでもよく使われる「!」という否定演算子ですが、これはかなり目立たない記号ですよね。C++ではこれと同等の予約語としてnotというのを使えることになっているので、私はC++を書く時には必ずと言っていいほどこちらを使うのですが、このnotはPerlにもあるのです。
だから、別にわざわざunlessなどというものを作らなくても、
print ‘Hello’ if (not /^$/);
で充分じゃないか、と私は思うんですけれどもね。
ところで興味深いことに、if節を後置にした場合にはこんな書き方をしているのに、Cと同様にif節を前置にした場合、Perlではブレースを省略できません。つまり、
if (/^$/) print ‘Hello’;
という書き方は、構文エラーとなってしまうのです。確かに、Cではif分を多段的に使った場合に、elseとの対応関係がおかしくなってしまうので、「必ずブレースを付けるようにしよう」というような流儀もあったりしますが、Perlではこれを強制するわけです。このように、先ほどのunlessにしても今の話にしても、Perlの個性的な部分は好き嫌いを生み出しそうな要素ですね。
こんなところにも、作者の人となりを色濃く反映していると思うのは私だけではないと思います。もっとも、Larry Wall氏(Perlの作者)を知っているわけではないのですけれども。
さて、読みにくさを排除しようとするPerlの書き方はまだまだあります。
前回話題にしたダブルコーテーションとシングルコーテーションの話でよく出てくるのは、囲った記号と同じものが文字列中に出てきたケースという話で、開きと閉じに同じ記号を使う場合には、それらの呼応関係がおかしくならないようにしなければならないわけです。こんな時、一般にはエスケープ文字というのを使うのはご存知の通りです。
print “Hello ¥”brave¥” world!¥n”;
こんなふうに、braveという単語を囲むダブルコーテーションを「閉じ記号」と誤認識させないためにエスケープ文字「?」を使うわけですが、文字列がやたらと長くなったり、エスケープするものがやたらに増えてきたりすると、これはなかなか見づらくなってくるわけです。
Perlではこんな時のために「コーテーションの別の書き方」が用意されています。上記のコードは以下のように書くことができます。
print qq/Hello “brave” world!¥n/;
つまり”"をqq//で置き換えてしまえるのです。ちなみに”の代わりにはq//というのを使えます。
ニュース・解説
今週の解説担当:小池邦人
【開発環境】
巷では、「Mac OS X 10.4(Tiger)が4月中には発売になるのでは…?」という噂が囁かれております。だとすると、WWDC2005期間中には10.4.1がシードできるくらいの順調な開発ペースですね(笑)。そんな中、Apple社のサイトにおいて、WWDC2005で開催される数多くのカンファレンス・セッションの内容が明らかになりました。
http://developer.apple.com/wwdc/descriptions/
毎年、当日でないと内容が明らかにされないセッションも幾つかあるのですが(昨年はTiger発表前だったのでその数が多かった)、今年は既にTigerが出ているでしょうから、そうした「秘密セッション」の数は少なそうです。今回の内容をざっと眺めてみたところ、筆者が注目している「Graphics and Media」系セッションはわずか7つしかないのに(OpenGL関連はたった2つ)、「Enterprise IT」系セッションは32もあります!こうして見ると、Apple社がターゲットとしているWWDC参加者の分野(職業)が、年々大きく変化して来ていることが理解できます(まだiPod関係は含まれていないが…)。
「今年は日本語同時通訳が無い!」という不安な話も持ち上がっていますが、例年以上に充実したセッションを期待したいと思います。
【テクニカルドキュメント】
前回から4月1日の期間中、Apple社のDocumentationサイトには新規ドキュメントがひとつも登録されませんでしたが、デベロッパー向けに2つの読み物が登録されました。前号で木下さんが紹介されている「Optimizing OpenGL Data Throughput on Mac OS X」は、アプリケーションからOpenGL APIを使う場合の最適化方法の解説です。同様な内容は、テクニカルノートのTN2093「OpenGL Performance Optimization : The Basic」でも詳しく解説されています。「最適化が必要なのは、我々よりもあなた達(ビデオカードメーカ&Apple社)の方が先でしょ!」と、デベロッパーから不満の声が聞こえて来そうですね…(笑)。
「Test Driving Your Code with OCUnit」(読み物)
http://developer.apple.com/tools/unittest.html
「Optimizing OpenGL Data Throughput on Mac OS X」(読み物)
http://developer.apple.com/graphicsimaging/opengl/optimizingdata.html
前回から4月1日の期間中、新規のテクニカルノートはひとつも登録されませんでしたが、テクニカルQ&Aの方は4つ登録されています。QA1414では、アイコンにフォーカスリング(青い縁取り)を描画させる方法が解説されています。Tigerでは256×256ピクセルのアイコンが表示可能になるという噂がありますが、さてどうなんでしょうか?QA1418については、前号の木下さんの解説も参考にしてください。
QA1409「Disappearing Help content」
QA1414「Defining and Using the kTransformFocused IconTransformType」
QA1418「How can I add the ability to read and write Keynote 2 documents to my application?」
QA1412「Using ConvertMovieToFile or ConvertMovieToDataRef to convert movies without displaying the settings dialog」
http://developer.apple.com/technicalqas/index-rev-date.html
【サンプルソースコード】
前回から4月1日の期間中、Apple社のSample Codeサイトには、新しいサンプルソースコードが3つ登録されました。「CarbonSketch」は、Mac OS X 10.3と最新Xcodeに対応させた修正バージョンです。「TypeServicesForUnicode」の方は、随分と古くからあるサンプルソースコードなのですが、HIViewとCarbon Eventに対応して見事に復活しました。「MemoryBasedBundle」については、前号で木下さんが紹介されています。
「CarbonSketch」(Carbon関連)
「TypeServicesForUnicode」(ATSUI関連)
「MemoryBasedBundle」(Bundle関連)
http://developer.apple.com/samplecode/index-rev-date.html
【デベロップメント SDK】
前回から4月1日の期間中、Apple社のSDKサイトには新しいSDKがひとつも登録されませんでした。
http://developer.apple.com/sdk/
MOSAからのお知らせと編集後記は割愛します