MOSA Developer News［MOSADeN＝モサ伝］第191号
2006-01-31
目次
- 「WebObjects Dev Report」 第37回 田畑 英和
- 藤本裕之のプログラミング夜話 #84
- 高橋真人の「プログラミング指南」 第82回
- ニュース・解説 小池 邦人
「WebObjects Dev Report」 第37回 田畑 英和
さて今回はDirectAction内で使用しているEditingContextの扱いを改良してみたいと思います。前回紹介しましたDirectActionのbrowseAction()は次のようにEditingContextを使っていました。
・browseAction()
EOEditingContext ec = new EOEditingContext();
ec.lock();
EOFetchSpecification.fetchSpecificationNamed(
"PublicUsers", "MOSAUser");
NSArray users = ec.objectsWithFetchSpecification(fetchSpec);
ec.unlock();
このようにコーディングした場合、browseAction()メソッドが呼び出されるたびにEOEditingContextをインスタンス化することになります。セッションを用いた処理の場合には、セッションが提供するデフォルトのEditingContextを使うことができますが、セッションを使用しない場合はEditingContextを明示的に用意する必要があります。
生成したEditingContextをどこかで保持できれば、使い回すこともできるのですが、DirectActionクラスは呼び出されるたびにインスタンス化されるためDirectAction内で状態を保持することはできません。そこで、アプリケーション内からは常に共通して参照することのできるApplicationクラスを利用することにします。なお、この方法はWebObjectsのサンプルプロジェクト「Think Movies」を参考にしていますので、ぜひそちらのほうのコードもチェックしてみてください。
まず、ApplicationクラスにEOEditingContextの変数を追加します。そしてその変数を取得するためのゲッターメソッドを追加します。EOEditingContextはApplicationクラスのコンストラクタでインスタンス化しておきます。関連するコードを抜き出しますと、Application.javaは次のようになります。
・EditingContextを提供するApplication.java
public class Application extends WOApplication {
private EOEditingContext editingContext;
public Application() {
super();
editingContext = new EOEditingContext();
}
public EOEditingContext lockEC() {
editingContext.lock();
return editingContext;
}
}
ゲッターメソッドのlockEC()ではあらかじめEditingContextをロックしてからreturnしています。ロックをした場合、アンロックの処理も必要になりますので、次のようなアンロック用のメソッドも用意しておきます。
・EditingContextアンロック用メソッド
public void unlockEC() {
editingContext.unlock();
}
それでは、Application.javaに用意したEditingContextを利用するように、DirectActionのメソッドを書き換えてみましょう。改良したコードは次のようになります。
・改良したbrowseAction()
Application app = Application.myApplication();
EOEditingContext ec = app.lockEC();
EOFetchSpecification.fetchSpecificationNamed(
"PublicUsers", "MOSAUser");
NSArray users = ec.objectsWithFetchSpecification(fetchSpec);
app.unlockEC();
browseAction()でApplicationのインスタンスを取得するのに利用しているmyApplication()ですが、これはApplication.javaで次のようなメソッドを用意してあります。
public static Application myApplication() {
return (Application)Application.application();
}
これで毎回EditingContextを生成せずに、ApplicationのEditingContextを使い回すことができるようになったわけですが、最後にこの処理の問題点について考えてみたいと思います。
まずEditingContextを共有していますので、大量のリクエストがあった場合に、一カ所に負荷が集中する可能性があります。時間のかかるFetch処理を実行した場合などは全体的なパフォーマンスに影響を及ぼすかもしれません。
次に、データの追加／変更／削除をおこなうような場合、未保存の状態のEOが共有するEditingContext上に存在してしまうと他の処理に影響を与えてしまいます。
こうなると毎回EditingContextを生成したほうが安全なのではないかということにもなるのですが、ようするに今回紹介した方法はあらゆる場合に有効な方法ではないということです。なんだか歯切れの悪いまとめになってしまいましたが、これで「ビジネスマッチングシステム」で使用しているDirectAction関連の処理については一通りの解説がおわりました。
藤本裕之のプログラミング夜話 #84
さて承前、Interface BuilderでNSWindowクラスに指定できる各種属性について探求するシリーズの第……何回目かである。そういうことが気になるムキのひとはすまぬが自分で数えてくだされ。
前回まで注目していた「Released when closed」の下、「Hide on deactivate」はわかりやすい。読んで字のごとく、これがONならそのウィンドウはアプリケーションがバックグラウンドに回されると「隠される」わけだ。どんなものがそうかというと、例えば……といってiTunesとかiChatとかあれこれ触ってみたんだけどみつからない（笑）。フォントパネルとかはそうなんだけど、あれは使ってるアプリケーション自身が定義しているわけぢゃないしねぇ。
……で、探しまわったあげくようやく見つけた。iCalで出て来るアドレスパネルがそうである。断言はできないが、後述する「Utility window (Panel Only)」というのをチェックすると自動的にこれもチェックされることから、一般的にこの属性は、ツールやらデータやらを選択するためのユーティリティ・ウィンドウに与えられているようですな。……そういえばInterface Builderのインスペクタもそうなんだけど、あれはなんで消えるのかな。消えなくてもいいと思いませんか？
さくさく次にいく。次のスイッチは「Visible at launch time」。これも読めばわかりますな。ONなら起動時に可視状態にされるというわけ。確かめたわけぢゃないけど、iTunesとかiPhotoなんかのメインウィンドウはこのスイッチがONになってんだろ。
次の「Deferred」についてはNSWindowの説明を始めた最初だかに説明したので、それを読み返してもらうとして、さぁ次の「One shot」である。さぁこれはなんであろうか。NSWindowのリファレンスを参照すると「setOneShot:」というメソッドがあり、その解説はこうなっている。「レシーバー（これはNSWindowのインスタンスのこと）が管理するウィンドウ・デバイスに対し、そいつがスクリーン・リストから除外されたときに解放される（そして次に戻って来る時には新しく生成される）かどうか、を設定します」。
……なんのこっちゃ？ 「Released when closed」とどう違うんや？
確かにどちらもメモリがらみで紛らわしいように思えるんだけど、よく読むと全然違う。まず、このスイッチにしたがって解放されるのはレシーバーそのものではなくて「それが管理するウィンドウ・デバイス（これって何かというと、実はこれこそ我々が昔からウィンドウと読んでいたモノなんだが）」である。「Released when closed」の方はインスタンス自身だった。そしてその「解放」が起きるタイミングも、「スクリーン・リストから除外されたとき」、すなわち orderOut メッセージを受け取った時である。ここまでいいですか？
これを指定できると何が嬉しいかというと……、映画「スウィング・ガールズ」に出てきた野球部の小僧ぢゃないけど世の中には二種類のウィンドウがあるわけだ（ついでに言うとあの小僧の物言いは「続・夕陽のガンマン」に出て来るイーライ・ウォラックの真似である）。さっきも出てきたiTunesのメイン・ウィンドウみたいにユーザがそのアプリケーションを使っている間ほとんどずっと開いているヤツと、同じくiTunesの例えば環境設定のウィンドウみたいに、下手するとセッション（この「セッション」はアプリケーションの起動から終了まで）中一度も開かないことだってあるってヤツ。で、後者のようなウィンドウに対してこのスイッチをONにしておけば、なにがしかのメモリの節約になる、と。……言ってることはわからんでもないが、それを「One Shot」の一言で合点はできないわな。ネーミングに問題ありだと思う。……もしかしてネイティブには「One Shot」と一言書けば、タチドコロにそういう意味合いが通じてしまうような文化的背景があるんだろうか？
（2006_01_26）
高橋真人の「プログラミング指南」第82回
UNIXとしてのMac OS X
〜Perlについて(28)〜
こんにちは、高橋真人です。
前回の説明でPerlスクリプトにコマンドラインから動的にファイルを与えることができるようになりました。以下のように書くことで、与えたファイルの中身をそのまま標準出力に出力するようになります。
$file_path = shift;
open IN, "$file_path" or die;
while (<IN>) {
chomp;
print "$_?n";
}
実は、このスクリプトと等価の処理を以下のように書くことでも実現できます。
while (<>) {
chomp;
print "$_?n";
}
「一体、ファイルをどうやって指定しているんだ？」と疑問を持たれるかもしれませんが、入力のための演算子である<>という記号は、間にファイルハンドルを入れればその中からデータを読み出しますが、カラ、つまり何も指定せずに使用した場合、コマンドラインでスクリプトの後に指定したファイル名を入力先として処理するのです。
さらにこの場合、ファイルを複数指定することができます。つまり、以下のようなコマンドを指定すると、
>perl test.pl abc.txt def.txt ghi.txt
test.plというスクリプトは、abc.txt、def.txt、ghi.txtの内容を順に表示するのです。
ちなみに、かつてのMacPerl（というか今でもClassic環境があれば動作させることは可能ですが）の場合、ドロップレット形式でスクリプトを保存すると、それがそのままファイルのドロップを受けるアプリケーションになってくれたため、例えば以下のようなスクリプトを書くだけで、テキストの内容をそのまま表示するものが作れました。
while (<>) {
print;
}
もちろん、実際にはこれだけで使い物になることはまずないので、ここからいろいろと手を加えて発展させていくことになるわけですが、テキストファイルを加工するドロップレットがとても気軽に作れたわけです。また、こういう仕様があったからこそ、私自身はPerlというスクリプト言語に割とすんなり入り込むことができたのではないかと思っています。
余談ですが、2000年ごろのWWDCでBSDのセッションに参加したとき、スピーカーが「私が簡単なテキスト処理をやるならば、ターミナルを使ってすぐできますが、それを私のおばあちゃんにやらせるとなると話は別。そういう時には、チャチャッとスクリプトやコマンドをアプリケーションでくるんでドロップレットの形式にしてあげれば、おばあちゃんでも簡単に使えるようになりますね」という話をしました。
そのセッションの最後のQ&Aのコーナーで、とある人が「Perlは標準で付いているし、ドロップレットも簡単にできるのならば、もうMacPerlの役割は終わったのか？」という質問をすると、会場の一部がちょっとざわつきました。しばらくして周りの人たちに促されて若干顔を赤らめながら立ち上がった男性は、Matthias Neeracherという、MacPerlの作者その人でした。
私はその少し前にMacPerlがとても仕事で役立ってくれたこともあり、意外なところで意外な人を目撃できた感激に思わず心の中で「お世話になってます！」と呼びかけました。もちろん日本語で、ですが（笑）
しかし、最近になってつくづく思うのは、その時の質問に対する答えはやはり「ノー」なのだということです。
いろいろな言語に手を出すことが好きな私は、Mac OSがUNIXになったこともあって、Perl、Python、Rubyという「3大人気スクリプト言語」を時々試してみるのですが、「手軽に作って、手軽に動かす」という意味でMacPerlを凌ぐものには未だに出会えていません。
ここ1、2週間、少し夢中になっているPythonは、標準でかなり優秀なIDEを持っていますし、スクリプトファイルをドロップレットにしてくれるツールも付属しています。ただ、ドロップレットにしてしまうと編集ができなくなってしまうので、必ず別名で保存する必要があるなどと、MacPerlの気軽さにはいま一歩及びません。（ただし、MacPerlよりいい部分はたくさんあります）
こんなことを書いているうちに気になったので、改めてWebで検索をしてみました。その結果見つかったのは、「MacPerlはMac OS Xのクラシック環境下で動作する。今のところCarbonに移植する予定はない」との相変わらずの文章です。
今までは確かにクラシック環境があれば使えないことはなかったのですが、いずれMacがすべてIntelベースになってしまうと話は違います。Intel Macの登場が契機になって、本格的なOS Xへの移植が進まないものでしょうか。
ところで、検索をしていて新たな発見もありました。MacPerlがSourceForge*1で管理されていること、そこではPerlからMac OSのシステムの機能を呼び出せる仕組みであるmac-carbonというものの開発も行われているようです。
それと、前述のNeeracher氏が「現在はAppleで働いている」という文章も見つけました。ただ、その文章が書かれたのは99年の8月らしいので、私がWWDCで「目撃」した時は、既にAppleの社員だったようですね。
Appleの社員を現在も続けているのかは定かではありませんが、彼は今Finkのメンテナ*2も務めておいでのようです。
*1 SourceForge: オープンソースのプロジェクトを無償でサポートしてくれるサービス。CVSなどの管理機能をもち、ソフトのリリースの手段も提供し、開発者同士の情報交換用のフォーラム機能やプロジェクトのWebなどを立ち上げる機能も提供する
*2 Finkのメンテナ: Finkというのは、UNIXのソフトウエアをMac OS Xで気軽に使えるようにするための導入の手段を提供する仕組み。かなり多くのソフトウエアがあるので、パッケージによってはメンテナンス担当者、つまりメンテナがいるものがある。
ニュース・解説
今週の解説担当:小池邦人
● Carbon ドキュメント & サンプル ＆ SDK ナビゲーション（2005/01/27）
【開発環境】
インテル版Macintoshの販売が6ヶ月前倒しで開始されましたので、仕方なく、今まで開発してきた自作アプリケーションのUniversal Binary化の作業スピードを速めている今日この頃です。インテル版の実機については、「DTK Exchange Program」サービスによりインテル版17インチiMacがまもなく届くはずですのでそれ待ちです。最初は、受付終了後1〜2週間という話でしたが、残念なことに受理メールでは2〜4週間と訂正が入っていました（涙）。
その間は、DTKのマシンを利用して動作チェックをするわけですが、このマシンに搭載されているインテル版Mac OS X 10.4.3には結構バグが残っており、Universal Binary化で発生した不都合なのか？ OSのバグなのか？ その判断に苦慮する時があります。できれば、このインテルマシンでも出荷済みのMac OS X 10.4.4を使いたいと思い、アップデートの予定があるかどうかをアップル社のメンバーに尋ねてみたところ、「予定はない」と言われてしまいました（涙）。
契約上、今年の12月までDTKは使えるはずですから、出荷バージョンのMac OS Xへのアップデートは、Apple社側の責任だと思うのですが？ 仕方がないので、iMacが届くのをひたすら待つことにしました…。
【テクニカルドキュメント】
前回から1月27日の期間中、Apple社のDocumentationサイトには新規ドキュメントがひとつも登録されませんでした。インテル版のiMacとMacBook Proのハード仕様ドキュメントがなかなか登場しませんね？まだ仕様が固定していないのか（笑）
http://developer.apple.com/documentation/index-rev-date.html
前回から1月27日の期間中、新規テクニカルノートは2つ登録され、新規テクニカルQ&Aの方は7つ登録されました。TN2133「Coalesced Updates」をざっと眺めてみると、Mac OS X 10.4では画面アップデートの仕方が大幅に変更になったようですね。旧仕様とのコンパチビリティを保ちたい場合には、Info.plistにCGDisableCoalescedUpdatesキーを記述することで対応できるようです。テクニカルQ&Aの方は、QuickTimeを用いた圧縮と伸張技術に関する内容がほとんどです。QuickTimeでも一番分かり難い技術エリアでしたから、こうしたサンプル資料が沢山出てくると大いに助かります。これらについては、前号の木下さんの記事も参考にしてください。
TN2133「Coalesced Updates」（初版登場後すぐに改訂）
TN2110「Identifying Java on Mac OS X」
http://developer.apple.com/technicalnotes/index-rev-date.html
QA1457「Compression Sessions – Multipass encoding and the pass mode flags」
QA1456「Compression Sessions – Configuring options using the Standard
Compression dialog」
QA1450「Compression Sessions – Enabling muti-pass encoding」
QA1455「Compression Sessions – Temporal compression options」（初版）
QA1236「Debugging Graphics with QuartzDebug」（日本語訳あるが古い）
QA1460「Decompression Sessions – Setting codec accuracy
and field mode」（初版）
QA1062「Limiting the component list in SCRequestImageSettings」
http://developer.apple.com/technicalqas/index-rev-date.html
【サンプルソースコード】
前回から1月27日期間中、Apple社のSample Codeサイトには、新しいサンプルソースコードが2つ登録されました。どちらも改訂版としての再登録となります。
「CFNetworkHTTPDownload」（NetWork関連）
「QTMetaData」（QuickTime関連）
http://developer.apple.com/samplecode/index-rev-date.html
【デベロップメント SDK】
前回から1月27日の期間中、Apple社のSDKサイトには新しいSDKが4つ登録されました。Mac OS X 10.4.4対応「Kernel Debug Kit」（PowerPC版とIntel版あり）と「QuickTime 7.0.4 SDK」（Windows版あり）です。ところで、Mac OS X 10.3.9でXcode 1.5を利用しているのですが、この環境にQuickTime 7.04をインストールすると、Metrowerks CodeWarrior v9.6でのリンクが正常に終わりません？「QuickTime 7.0.4 SDK」をインストールすれば大丈夫かな？と思ったのですが、やはりダメのようです？ 謎ですね（涙）
「Kernel Debug Kit 10.4.4 (Intel)」
「Kernel Debug Kit 10.4.4 (PowerPC)」
「QuickTime 7.0.4 SDK」
「QuickTime 7.0.4 SDK for Windows」
http://developer.apple.com/sdk/
MOSAからのお知らせと編集後記は割愛します
Apple、Mac OSは米国アップルコンピュータ社の登録商標です。またそのほかの各製品名等はそれぞれ各社の商標ならびに登録商標です。
このメールの再配信、および掲載された記事の無断転載を禁じます。
特定非営利活動法人MOSA
Copyright (C)2006 MOSA. All rights reserved.