MOSA Developer News［MOSADeN＝モサ伝］第122号
2004-07-27
目次
- SqueakではじめるSmalltalk入門 第4回 鷲見正人
- 小池邦人の「Carbon API 徒然草」
- 「Behind the WebObjects」 第24回 田畑 英和
- 高橋政明のWWDC2004参加レポート ★MOSA会員専用記事★
- ニュース・解説
SqueakではじめるSmalltalk入門 第4回 鷲見正人
本連載では、名前は知っていてもなかなか触れる機会のないSmalltalkがどんなものであるかを知っていただこう…というテーマで、最近話題のSqueakを紹介しています。今回は、簡単なSmalltalkコードを記述して実行してみます。
Smalltalk言語には文法というほどのものはありません。LispにおいてS式ですべてを記述できるのと同じように、Smalltalkではすべてをメッセージ式で記述します。メッセージ式とは、送りたいメッセージとそれを受けるオブジェクトを「object message」という順番でスペースで区切って記述するものです。Objective-Cでいうところの[ ]内に記述するアレです。
書式の“object”のところにはあらかじめオブジェクトを束縛しておいた変数、もしくは、新しくオブジェクトを生み出すリテラル式、あるいは、返値を期待する別のメッセージ式を記述します。“message”のところには、先のオブジェクト（レシーバ）に対して送信するメッセージを記述します。メッセージにはパラメータ（つまりレシーバとは別のオブジェクト）を伴わせるか否かで3種類あって、それぞれ単項メッセージ、二項メッセージ、キーワードメッセージと呼ばれます。
単項メッセージは、いわゆる引数をとらないメッセージです。なお、Squeakでは文字列リテラルはダブルクオートではなく、シングルクオートで括ります。一方、ダブルクオートはコメント文として解釈されます。
3 factorial “=> 6 ”
Float pi “=> 3.141592653589793″
‘Squeak’ reverse “=> ‘kaeuqS’ ”
キーワードメッセージは引数をひとつ以上とるメッセージで、引数の前にObjectvie-Cでお馴染みの「:」を置きます。ただ、Objective-Cとは違って、Smalltalk言語の場合、「:」の前には少なくとも1文字のアルファベットが必要なので「:」だけでメッセージの末尾に引数が追加されることはありません。
3 raisedTo: 4 “=> 81 ”
‘Squeak’ copyFrom: 3 to: 4 “=> ‘ue’ ”
Workspace openLabel: ‘untitled’ “ウインドウを表示”
二項メッセージは引数がひとつだけの特殊なキーワードメッセージと考えることができます。メッセージセレクタ（メッセージから引数とスペースを取り除いた文字列）はアルファベットを含まず、引数の前（つまりセレクタの末尾）には「:」は付きません。主に数式や等式などをメッセージ式として違和感なく表現するために用意されたものだと思われます。そう、Smalltalkでは数式（のように見える式）もメッセージ式です。たとえば「3 + 4」は、3と4の加算を意味する二項演算ではなく、「3に+ 4というメッセージを送信する」と解釈し、内部的にも（バイトコードへのコンパイルまでは）そう処理されます。
3 + 4 “=> 7 （和）”
3 * 4 “=> 12 （積）”
3 = 4 “=> false （等価か）”
3 ~= 4 “=> true （不等価か）”
3 // 4 “=> 0 （除算の商）”
3 4 “=> 3 （除算の余り）”
3 / 4 “=> (3/4) （分数オブジェクトの生成）”
3.0 / 4 “=> 0.75 (除算）”
メッセージが複数混在するとき、二項メッセージはキーワードメッセージに、単項メッセージは二項メッセージに優先して送信されます。たとえば「3 raisedTo: 4 + 5 factorial」は「3 raisedTo: (4 + (5 factorial))」の順で評価されます。もちろん括弧で括ることで優先順位を明示的にしたり、評価の順番を変更することもできます。二項メッセージと単項メッセージのみが連続する場合は、左にあるものから順に送信され、その結果として返ってきたオブジェクト（返値）に対して次のメッセージが送られます。「3 + 4 – 5 * 3」は「((3 + 4) – 5) * 3」、「Float pi sin」は「(Float pi) sin」です。なお、二項メッセージにおける加減算に対する乗除算の優先はありません。乗除を優先したい場合は、あらかじめ括弧で括っておく必要があります。
キーワードメッセージについては、これを連続して記述することはできません（別のメッセージセレクタとして解釈されてしまいます）。必ず括弧を使って最初のメッセージ式の返値に改めてメッセージを送ることを明示的にしてください。逆の例ですが「3 = 4 ifTrue: [5] ifFalse: [6]」は3 = 4の返値（当然false）にifTrue: [5] ifFalse: [6]というメッセージが送られることを意味し、「(3 = 4 ifTrue: [5]) ifFalse: [6]」のように解釈されることはありません。
では複数のメッセージ送信を織り込んだ、メッセージ式の例を見てみましょう。
(FileDirectory default fileNamed: ‘test.txt’) edit “ウインドウを表示”
この式は、まずFileDirectoryという（グローバル変数に束縛されている）オブジェクトに対してdefaultというメッセージを送って、仮想イメージがあるディレクトリを示すオブジェクトを得ます。それに対し改めて、fileNamed:’test.txt’というメッセージを送っています。ここで、test.txtという名前のファイルがあればそれを、なければ作ってそれを制御するためのオブジェクト（StandardFileStreamのインスタンス）が返ってきます。さらにそのオブジェクトに対してeditというメッセージを送ることで、当該ファイルを編集するファイルエディタ機能を持ったウインドウが現われます。括弧でメッセージ送信の順を変えて、editが’test.txt’という文字列オブジェクト（Stringのインスタンス）に送られることを阻止しています。
普段、ファイルを編集するだけなら、こんなメッセージ式の評価ではなく、別に用意されたFileListという名のファイラを起動してそのGUIを使います。ここでは、オブジェクトに対するメッセージ送信により各種オブジェクトの機能が発現していることを実感していただければ結構です。
実際にdo itして動作を確認してみてください。Workspace openLabel:’untitled’で開くのとは違ったウインドウが現われます。このテキストエディタ内でももちろんSmalltalkコードを入力して実行できます。Smalltalk環境内では文字入力を受け付ける場所ならどこででも、Smalltalkコードを入力して評価（必要なら結果を表示）することが可能です。次のコードを入力して選択（cmd-A）し、続けてdo it（cmd-D）すると、赤いペンでマウスの軌跡を描くことができます。
| pen |
pen _ Pen new.
pen defaultNib: 3.
pen color: Color red.
[Sensor shiftPressed] whileFalse: [
| position |
position _ Sensor peekPosition.
Sensor redButtonPressed
ifTrue: [pen goto: position]
ifFalse: [pen place: position]]
いささか稚拙ではありますが簡易ペイントソフトのできあがりです。shiftキーを押せば制御がGUIに戻ります。複数行のメッセージ式を区切るにはピリオドを使います。改行とタブ、余分なスペースはコードの見た目を整える以外の意味を持ちません。Smalltalkのコード中で使用する一時変数にはアルファベット小文字で始まる英数字を使用し、同じコード内であらかじめ「|」で括って宣言しておきます。変数へのオブジェクトの束縛は「_（アンダースコア。Squeakの画面では“←”と表示）」か「:=」で左辺に束縛したい変数を、右辺に束縛したいオブジェクトを返値に持つ式（メッセージ式かリテラル式）を置きます。
この短いコードとその動きから、どんなオブジェクトにどんなメッセージが送られているのか、じっくりと考えてみてください。なおこの記述は、ウインドウの黄ボタンメニューからaccept→overwrite that fileで保存できます。再び開くには、デスクトップメニュー→open…→file listで呼び出すことができるファイラ（FileList）を使うか、ひとつ前に示した「(FileDirectory…」という式を記述して評価します。ウインドウを閉じずに置いておき、環境を終了するときにsaveする、という方法でもよいでしょう。
次回はこのプログラムの解説と描いた絵を保存する機能の拡張を試みます。
小池邦人の「Carbon API 徒然草」（2004/07/23）
Main Event Loopへ入る前準備-その2
今回は、サンプルアプリケーションに実装される一番最初のCarbon Event Handlerの話をします。イベントハンドラは、コントロールやウィンドウといった各オブジェクトに対してそれぞれ用意することが可能です。初期化ルーチンのstartApplication()から呼ばれているsetupApplicationEvent()では、このうち「アプリケーション」自身に届くイベント（Carbon Event）を処理するためのハンドラルーチンを実装しています。
例えば、ユーザがウィンドウ上のボタンをクリックしたとします。すると、「コントロールがクリックされた」というイベントが、まずはコントロール自身のハンドラへ送付されようとします。もし、コントロールにハンドラが実装されていなければ、今度はコントロールが配置されているウィンドウへ、それもなければ最終的にはアプリケーションへと送付先が切り替わり処理されます。通常、ボタンクリック等のイベントは、コントロールかウィンドウのイベントハンドラで処理されますので、アプリケーションのハンドラまで届くことはありません。アプリケーションのハンドラで処理するような例としては、ウィンドウが表示されていない時のメニュー選択で発生するイベントなどがあります。
以下が、アプリケーションにイベントハンドラを実装しているsetupApplicationEvent()です。アプリケーションにハンドラを実装するのには、EventTypeSpecのリストに受諾を許可するイベントのクラス名（eventClass）と種類（eventKind）を列挙しておき、ハンドラルーチンの名称と一緒にInstallApplicationEventHandler()に渡します。今回は、4種類のイベントに対応するようにEventTypeSpecのリストが作成されています。
void setupApplicationEvent(void)
{
EventTypeSpec list[]={
{ kEventClassCommand, kEventProcessCommand },
{ kEventClassCommand, kEventCommandUpdateStatus },
{ kEventClassMenu,kEventMenuBeginTracking },
{ kEventClassMenu,kEventMenuEndTracking }
};
InstallApplicationEventHandler( myApplicationEventHandler,
GetEventTypeCount(list),list,NULL,NULL );
}
同様に、コントロール用であればInstallControlEventHandler()を、ウィンドウ用ならばInstallWindowEventHandler()を、メニュー用ならばInstallMenuEventHandler()を使いイベントハンドラを実装することができます。本サンプルアプリケーショの場合は、アプリケーションメニューの「MOSAについて…」「MOSAを終了」、それからファイルメニューの「新規」と「開く…」が、アプリケーション用ハンドラルーチンで処理されます。つまり、これらは、ウィンドウが何も表示されていない時でも選択できるメニュー項目となります。今回は、そうした処理をアプリケーション用ハンドラで実行していますが、状況によっては、メニュー用ハンドラで実行した方が都合が良い場合もあるでしょう。「どのオブジェクトのハンドラでどんなイベントを処理するのか？」この課題に対していかに効率的な設計を行えるかどうかが開発者の腕の見せ所となります。
以下のmyApplicationEventHandler()が、InstallApplicationEventHandler()で実装されているアプリケーション用のイベントハンドラルーチンの本体です。
static pascal OSStatus myApplicationEventHandler( EventHandlerCallRef myHandler,
EventRef event,void *userData )
{
short ret=eventNotHandledErr;
unsigned long ekind;
WindowRef wptr;
HICommand cmd;
long cls;
cls=GetEventClass( event ); // イベントのクラス名を得る
ekind=GetEventKind( event ); // イベントの種類を得る
if( cls==kEventClassCommand ) // Carbon Eventのクラスはコマンド
{
switch( ekind ) // Carbon Eventの種類を判断
{
case kEventProcessCommand: // ユーザの操作でコマンドが発生した
// コマンドの種類をパラメータから得る
GetEventParameter( event,kEventParamDirectObject,typeHICommand,
NULL,sizeof(HICommand),NULL,&cmd );
switch( cmd.commandID ) // コマンドIDの種類を判断
{
case 'new ': // ファイルメニューの「新規」
newCatalogWindow( &wptr ); // 新規ファイルルーチン
ret=noErr;
break;
case 'open': // ファイルメニューの「開く...」
loadCatalogFile( &wptr ); // ファイルロードルーチン
ret=noErr;
break;
case 'abou': // アプリメニューの「MOSAについて」
openAboutWindow(); // アバウト表示
ret=noErr;
break;
case 'quit': // アプリメニューの「MOSAを終了」
if( quitApplication() ) // アプリケーションの終了
ret=noErr;
break;
}
break;
case kEventCommandUpdateStatus: // メニューの状態チェック開始
// MenuRefをパラメータから得る
GetEventParameter( event,kEventParamDirectObject,typeHICommand,
NULL,sizeof(HICommand),NULL,&cmd );
ret=mainteApplicationMenu( cmd.menu.menuRef );
break; // メニューの表示、非表示の切り替えを行う
}
}
else if( cls==kEventClassMenu ) // Carbon Eventのクラスはメニュー
{
switch( ekind ) // Carbon Eventの種類を判断
{
case kEventMenuBeginTracking: // メニュー選択が開始された
menu_tarck=1; // EventTimer用の外部変数のmenu_tarckをセット
break;
case kEventMenuEndTracking: // メニュー選択が終了した
menu_tarck=0; // 外部変数のmenu_tarckをクリア
break;
}
}
return( ret );
}
イベントのクラス名と種類は、GetEventClass()とGetEventKind()で得ることができます。クラス名と種類の両方が判明したらケース文を使いそれぞれの処理を切り分けます。例えば、メニュー選択により届くイベントは、クラス名が「kEventClassCommand」で種類が「kEventProcessCommand」となります。ただし、この時点ではどのメニュー項目が選択されたのか（どんなコマンドIDが届いたか）は判断できないので、GetEventParameter()により、そのイベントに添付されているパラメータを調べます。コマンドIDを調べたい場合には、パラメータ名に「kEventParamDirectObject」を、タイプに「typeHICommand」を指定し、HICommand構造体を得ます。この構造体のメンバーのcommandIDに、メニューに設定されている（Nibファイルにおいて設定済み）コマンドIDが代入されているので、それをチェックすることでメニュー項目ごとに処理を切り分けます。
今回で、Main Event Loopへ入る（RunApplicationEventLoop()を実行する）までにやっておかなければいけない「アプリケーション初期化」についての話はすべて終了しました。次回からは、「新規や」「開く…」など、メニューから選択できる機能を各ルーチンごとに追跡して行くことにします。
つづく
「Behind the WebObjects」 第24回 田畑 英和
さていよいよ今回からProject WONDERの具体的な使い方を解説していきたいと思います。とはいいましてもProject WONDERは様々なフレームワークから構成されていますので、どこから紹介していったらいいものか迷ってしまいますが、次のような理由からまずはERCnahgeNotificationJMS(以下ERCN)を取り上げてみたいと思います。
・他のProject WONDERフレームワークに依存していない
・アプリケーション側のコードを修正する必要がない
まずどういったときにこのフレームワークが役立つかを説明しておきます。WebObjectsの実行環境ではインスタンスを複数起動することにより手軽に負荷分散をおこなうことができます。WebObjectsの運用環境は、ライセンス上のインスタンス数の制限はありませんので、ぜひともこのマルチインスタンスによる負荷分散の機能は積極的に使っていきたいところです。
しかし、インスタンスを複数にした場合には考慮しなければならない問題が発生します。それはインスタンス間でのEOの同期です。デフォルトの状態ではインスタンスごとにデータのスナップショットが作成されますが、同一のデータを複数のインスタンスで共有する場合、このスナップショットの挙動を正確に理解しておく必要があります。
例えば2つのインスタンスでデータベース上の同一のデータ”A”をFetchしたとしましょう。次に、インスタンス1でデータ”A”を”B”に変更してデータベースに保存します。このときインスタンス1とデータベースではデータが”B”に変更されますが、インスタンス2のスナップショットは”A”のままです。つまりインスタンス間でデータの内容が食い違う状態になります。
そしてインスタンス2でデータを”C”に変更して保存したとします。しかしこのときの保存処理は失敗します。なぜならば、EOFはデータの更新時にまずスナップショットのデータ(インスタンス2のスナップショットはまだ”A”のまま)とデータベース上のデータ(すでに”B”に変更済み)を比較し、違いがなければ保存処理を実行し、違いがあればデータのコンフリクトが発生したということで保存処理をキャンセルするからです。
設定によっては同一インスタンス内であってもコンフリクトが発生することもありますし、コンフリクトの検出機能をOFFにすることもできますが、処理の流れを簡単にまとめますと以下のようになります。
インスタンス1：A > B > B
インスタンス2：A > A > C <- Fetch後にデータベース上のデータが変更
データベース ：A > B > B <- インスタンス2の変更は保存できない
またFetchをおこなったときに、スナップショットに該当するデータがあれば、EOFはスナップショットのデータを用いてEOを作成します。つまりFetchをしたからといって、常に最新のデータにアクセスできるとは限りません。
スナップショットを明示的に破棄するようなプログラミングもできますが、いずれにせよスナップショットを常に意識してプログラミングをおこなう必要があります。
そこでERCNが登場するわけですが、このフレームワークを用いるとインスタンス間で自動的にスナップショットの同期をおこなってくれます。上記の2インスタンスの例の場合以下のような挙動になり、Fetchしたときも常に最新のデータにアクセスすることができます。
インスタンス1：A > B > C <- インスタンス2の変更内容が自動的に反映
インスタンス2：A > B > C <- インスタンス1の変更内容が自動的に反映
データベース ：A > B > C <- 両方のインスタンスでの更新は成功
しかも、アプリケーションをERCN対応するにはフレームワークをプロジェクトに追加するだけでよく、ソースコードは一切変更する必要がありません。
ただし、ERCHはあくまでもWebObjects向けのフレームワークですので、同じデータベースを編集する非WebObjectsアプリケーションまではサポートできませんし、自動的に同期をとらないほうがよい場合も考えられます。
さらに、ERCHを用いる場合にはあらかじめOpenJMSをインストールしておく必要があります。OpenJMSはJavaのメッセージサービスの規格であるJMSのオープンソースによる実装です。JMSではPublish-Subscribeモデルをサポートしており、Publiserは複数のSubscriberに対してメッセージを送信することができます。ERCHでは、このJMSの仕組みを利用することにより複数のインスタンス間でのデータの同期を実現しています。
今回は背景を説明しただけになってしまいましたが、次回はOpenJMSを含むERCHのセットアップ方法を紹介する予定です。
・JMS
http://java.sun.com/products/jms/
http://www.oreilly.co.jp/BOOK/jms/
・OpenJMS
http://openjms.sourceforge.net/
高橋政明のWWDC2004参加レポート
少し時間がたってしまいましたが、WWDCレポートをお送りします。
ジャパン・オリエンテーション
開催前日の日曜日、会場近くのホテルを会場にApple社による日本からの出席者向けの立食パーティが開かれました。初日の基調講演を聞くにためにほとんど参加者は前日までには現地に入っています。日本からの参加者が最初に顔を合わせる機会がこのパーティです。
日本からもずいぶんたくさんの方が参加していることにあらためて驚いてしまいました。Windows業界のことはわかりませんが、毎年ではないにしても技術的な発表の場にこれほどたくさん日本から開発者が詰めかけることはあるのでしょうか？
料理も充実していて夕食代が浮きました。なおこのパーティはAppleの無料ご招待で、WWDC期間中の身分証明であるバッジを見せると入場できました。日本のApple DTSのスタッフはもちろん、Mac雑誌の編集者、そして開発者の皆さんが勢揃いです。このように参加者同士の情報交換や交流もWWDCの大きな魅力です。
Tiger
いつものように基調講演の内容以外は機密事項なので書いたり解説したりすることはできませんが私なりの印象をまとめます。Tigerについてはずいぶん詳しいプレビューがAppleのwebですでに公開されています。
基礎的な部分では32bitと共存できる64bitに大きく生まれ変わります。実は64ビットと言われてもピンと来なかったのですが、100万台規模でのクラスタも可能とはすごいですね。
そのほか多くの特徴が発表されました。ただOSとしての機能とアプリケーションの機能が並列で紹介されていました。あえて区別せず発表した印象です。
Spotlight、Core Image、VoiceOver、Automator、Dashboard、など10.3までの機能や安定性の上に実現される訳ですが、これらの機能のアイディアのルーツはコープランドであるものも少なくないように感じました。コープランドとはもちろんSystem7の後継として発表されたOSのコードネームです。（もう9年程前でしょうか）
基調講演は充実していて時のたつのを忘れましたが、後から冷静になって考えるとMacintosh20周年の話題がありませんでした。ちょっとひねくれた見方になりますがMacの歴史に触れるとコープランドなどの話題も登場するからだったのかも知れません。
2005年前半としか発表されていないTigerの登場時期、実際に現段階ではいつ「登場させるか」は決まっていないのでしょう。
個人的印象ですがTigerに搭載予定の機能すべてを洗いざらい発表したとは考えられません、現在開発中で今回発表されなかった機能も少なくないはずですし、Finderがどうなるのかといったことは今回のWWDCでは触れられませんでした。
Spotlightをはじめ今回発表された機能だけでもかなり魅力的でこれまでと違った使い勝手が期待されます。当然Finderをはじめとするシステム全体が今回の新機能を搭載してくるはずですが、その詳細は来年までまたなければなりませんね。（まったく新しいiアプリの登場の可能性ももちろんありますね）
我々開発者はTigerの新機能をどう応用するか、ある意味ではAppleとの競争が始まっています。
Tigerではこれまでの高性能化の延長とは次元が違う飛躍がありました。その飛躍をWWDC参加者がどのように料理し、創造するか来年のTiger正式登場もそしてそれ以降も対応ソフトの登場が楽しみです。
WWDC2004の感想
Redmond, start your photocopiers. などの今年のスローガンは個人的には印象が悪いものでした。何を狙い誰に向けたメッセージだったのでしょうか？
セッションスケジュールに初日まで空欄があったことも残念です。基調講演の内容と関係し発表できなかったのかも知れませんが、少なくとも参加者だけが見る配布印刷物の空欄は避けてほしいものです。
エンタープライズITとQuickTimeとデジタルメディアを加えたとは言え同じ時間帯に10ものセッションが同時進行するため、どのセッションに参加するかは悩ましい問題です。実際ぜひ参加したいセッションが3つあるいは4つ重なった時間帯がありました。
参加できなかったセッションは後日DVDで確認する事になります。すべてのセッションを録画していたわけではないようでした、DVDがどんな構成で送られてくるのか気になります。
WWDCの一週間は開発者にとって強化合宿のようなものだと参加するといつも感じます。朝9時から夕方6時頃までセッションと情報交換に明け暮れる。会場が広いのでとにかく歩く。そしてカリフォルニアの青空でリフレッシュし、アップル本社キャンパスでのパーティとカンパニーストアでの買い物は自分へのご褒美です。世界の開発者のパワーを肌で感じやる気は自然に高まります。
今回得た情報をもとにTigerを研究するのはかなり刺激的な体験となりそうです。
最後に宣伝ですが日本国内で参加できるミニ合宿であるMOSAの「湘南ミーティング」は11月です、ぜひ予定に組み込んでください。
ニュース・解説
今週の解説担当:新居雅行
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃REALbasicで作ったMac用Office向けのユーティリティ集
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
REAL Softwareは、Microsoft Office向けのユーティリティ集「Office Power Pack Volume 1」をリリースした。REALbasicで開発された5つのアプリケーションからなる。Microsoft Office XおよびOffice 2004 for Macintosh上で利用可能なアプリケーションとなっている。Office X以降、ExcelやWordのマクロ作成ツールとしてREALbasicが利用できるようになっている。Windows版Officeと違ってMac版Officeのプログラミング機能は遥か以前のバージョンから変化がほとんどないため、本格的なソリューション開発にはREALbasicを使う方がより効率的であるとも言えるのだが、その実例に加えて実用になるものをReal Software社自身が提示したものと言えるだろう。アドレスブックをWordのラベル印刷文書などに展開する「Address Book Merge」、アドレスブックをExcelに取り込む「Address Book Export」、QuickenのデータをExcelに取り込む「Quicken Data Mover」、アドレスブックのデータを元にFAXの送信票を作成する「Fax Cover Sheet Maker」、伝票作成の「Invoice Maker」が含まれて、価格は$49.95となっている。
Office Power Pack
http://www.officepowerpack.com/
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃FileMaker Pro 7でイベント処理を記述可能なプラグイン
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Waves in Motionは、FileMaker Pro 7向けのプラグイン「Events 4.0 for FileMaker Pro 7」をリリースした。Eventsを使えば、FileMaker Proのデータベースでイベント処理ができる。たとえば、レコードを作成したり、フィールドにデータを入力したタイミングを見計らって処理を記述する事ができる。前のバージョンEvents 3.0はファイルメーカーPro 6までに対応するが、Events 4.0はFileMaker Pro 7向けだがかなりの部分を作り直して高いパフォーマンスを発揮できるとしている。価格は、1ユーザライセンスが$129などとなっている。
Events 4.0 for FileMaker Pro 7
http://wmotion.com/events/events_4.html
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃Mac OS X以外でMac独自機能を含むJavaプログラムのコンパイル
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
サンプルコードで公開されていた「AppleJavaExtensions」が改訂されている。Mac OS XのJava環境では、Apple独自のクラスがいくつかあるが、それらの利用を含んだソースコードをMac OS X以外の環境でコンパイルするときに、クラス定義情報が必要になる。そのために使うのがAppleJavaExtensionsで、1つのjarファイルにまとめられているのでこのファイルをコンパイル時に参照するようにしておけばよい。改訂では、Mac OS X以外でダウンロードしたときに扱いやすいようにzipで圧縮されるようになり、一部欠けていたメソッドが含められている。
Sample Code: AppleJavaExtensions
http://developer.apple.com/samplecode/AppleJavaExtensions/AppleJavaExtensions.html
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃Visula Basicプログラマ向けREALbasicの解説
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Real Softwareは同社のサイトで、Visual Basicのプログラマ向けに、REALbasicを使ってMac OS XやLinux向けに開発したアプリケーションの移植をしようといった趣旨のドキュメントを公開した。移植における考慮点や言語の違い、さらにはオブジェクトの違いやユーザインタフェースの違いなどがまとめられている。
Porting VB Applications to Linux and Mac OS X
http://www.realsoftware.com/realbasic/guides/portingvisualbasic/
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃FileMaker Pro 7の初心者向けセミナー
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
コンピュータワークスは、FileMaker Pro 7の初心者向けのセミナー「ファイルメーカーPro 7 エントリー編」を、2004年8月25,26日に開催する。受講料は42,000円で、会場は大阪のEPSONスクエア御堂筋。初心者だけでなく、ある程度FileMakerを使った経験のある人でも知識を整理するのに参加することも勧めている。
コンピュータワークス
http://www.computerworks.co.jp
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┃FM-Techが大阪や札幌でファイルメーカーProのトレーニング
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ファイルメーカーPro関連のトレーニングを展開するFM-Techは、7月から8月にかけて、トレーニングを実施する。8月3,4日は大阪で「基礎習得」（57,750円）、8月10,11日は札幌で「基礎習得」（57,750円）、8月19,20日は大阪で「中級」（63,000円）、8月23日は大阪で「リレーション」（31,500円）、8月24,25日は大阪で「Web1」（63,000円）、8月26,27日は大阪で「Web2」（63,000円）、となっている。講習はファイルメーカーPro 6を使って行われる。
FM-Tech
http://www.fmtech.jp/
MOSAからのお知らせと編集後記は割愛します
Apple、Mac OSは米国アップルコンピュータ社の登録商標です。またそのほかの各製品名等はそれぞれ各社の商標ならびに登録商標です。
このメールの再配信、および掲載された記事の無断転載を禁じます。
http://www.mosa.gr.jp/
Copyright (C)2004-2006 MOSA. All rights reserved.