レコード確定は忘れずに！
昔、「出かける時は忘れずに！」という外資系クレジットカードの CM がありました。
同じノリで、忘れないように気を付けたいのが「レコード/検索条件確定」スクリプトステップ。
自分で意識的にレコードを開いた時は忘れることはないと思いますが、例えば、ポータル行を削除した時も、レコード確定を明示的に実行するか、フィールド以外の部分をクリックするなどの操作がないと、更新は確定していないというのが FileMaker Pro 7 以降の仕様です。
ファイルメーカー Pro 6 までのフィールド設定スクリプトステップが「フィールド設定＋レコード確定」のような動作をしていたので、以前からのユーザの方がかえって分かりにくい点です。
List 関数の戻りを見ていると、この点の動作を観察することができます。例えば、ポータル行を削除して、レコード確定していない状態で、List ( 関連TO::関連レコードの外部キー ) の結果をデータビューアで見ると、削除されたレコードの外部キーはまだ残っています。レコード確定を実行した途端に外部キーもなくなります。
実は、ポータル行の追加の場合には、ちょっと挙動が異なります。新規作成を許可したリレーション越しにポータル行を追加するとします。お馴染みの手順で、ポータルの最後の行に移動して、フィールド設定。
すると、まだレコード確定していない、このタイミングで List 関数の戻りには、追加したばかりのポータルの外部キーが現れます。レコード確定を実行すると、、、もちろん結果はそのまま変わりません。
「おい、それじゃ、すでにこのレコードは確定しているのか？」とレコード確定ステップを無効にして、レコード復帰ステップを挿入します。ポータル越しにレコードを追加すると、List 関数の戻りに追加したばかりの未確定レコードの値が見えます。
ここで、レコード復帰の出番。このステップが動いた途端に、レコードは復帰（実行前の状態に戻る）され、未確定のポータル行は消えてなくなります。List 関数の戻りからも消えます。未確定には違いないのです。ちなみに、子テーブル側のシリアル値を見ると、上記の動作を繰り返す度に番号が増えていきますので、一旦レコードが作成されてはいるのです。
削除の場合も、レコード復帰すれば、消えたかのように見えるレコードが戻ってきますので、追加、削除のどちらも未確定で、復帰可能であることには違いないのです。
確定のタイミングと関数への反映の関係では整合性がないように見えますが、見方を変えて、「FileMaker の関数は追加／削除された未確定のレコードの値を参照できる」と考えれば、理屈は合うのかもしれません。
ただ、ポータルにレコードを追加するとき、重複した外部キーを持つレコードは作成しないと言うのは、よくある要件だと思います（例：同一レッスンに同一会員の重複申し込みは許可しない）が、現在の FileMaker の仕様だと、下記のような問題が生じる可能性はあります。
1. ポータル行を削除する操作（レコード確定なし）
2. 削除した行と同じ外部キーを持つレコードを追加する操作
→関数からは削除行が見えているから重複不許可の IF 条件文に処理が分岐してしまう。
「山田さんはキャンセルしたから削除。あっ、同性の別人だった。間違えたから、山田さんを登録しなおそう」→「あれっ？山田さんは削除したはずなのに、重複してると通知される。なぜ？」といった感じでしょうか。そんな時も、1 のステップで確実にレコード確定しておけば、普通は問題はないはずです。
Loop の中で同じ問題があったとしても、トランザクションやパフォーマンスの関係でレコード確定を避けたいこともありますし、動作タイミングの一貫性では「？」という部分も残りますが、FileMaker 開発者はあまり細かいことを気にし過ぎてはイケマセン。「そういうもの」と分かれば、それに合わせて作る。どんな開発環境でも、それは同じことです。
まとまりがなくなりましたが、以上、レコード確定にまつわるお話でした。
ちなみに、こんな本が出ている模様。
皆もすなる「FileMaker 資格認定」といふものを
皆もすなる「FileMaker 資格認定」といふものを、我もしてみんとてするなり
受けてみました、FileMaker 資格認定。先々週に Developer Essentials for FileMaker 10、先週に Developer Essentials for FileMaker 9 という、バージョン逆行の変則パターンで受けました。
結果は、幸い、どちらも合格。最初の Developer Essentials for FileMaker 10 の時は、試験の情報が全くなかったこともあって不安もありましたが（落ちると洒落にならない、笑）、とりあえずクリア。２回目の試験は様子も分かったので、こちらは余裕がありました。
「14日再試験ポリシー」によって、14日間は再受験できませんが、これは同じ試験を受ける場合の制限。２回をあいだ４日で受験しましたが、別バージョンの場合には関係ありませんでした。ちなみに、日本語と英語は試験番号が異なるので、ひょっとして受けられてしまうのかな？ 日本語、英語どちらも堪能な方は、（万一落ちた場合は）お試しください。
これに合格すると、「FileMaker x Certified Developer」（xはバージョン番号）のロゴを使って良くなったり、FBA メンバーの会社だと FileMaker 社サイトの紹介ページにバッチのマークが出るようになるそうです。
米国ではこの試験の実施がかなり先行していたため、FileMaker Developer Conference では、かなり多くの人がバッチを付けていたりします。そのため、何となく「実質的にはエンドユーザのための認定資格」という先入観を持っていたのですが、"Certified Developer" なので開発者の認定資格なのですよね。
今年は「今までとは違うことに挑戦する」という目標を掲げたこともあって、手始めに身近な資格を受けてみたのですが、いろいろと感じるところがあったので、つらつらと所感を書いてみたいと思います。
●ビジネス上の効果
他にもいろいろなベンダーの IT 関連資格がありますが、一部を除いては、個人の自己啓発や履歴書の資格欄といった局面でしか役立っていないのが現実ではないでしょうか。開発者としてメリットを感じられるためには、顧客層に資格の価値を認識してもらえるかどうかが基準になると思いますが、ビジネスの現場では、依然として FileMaker の特徴やメリットを説明することが必要な場面も多く、ましてや資格はその存在がほとんど知られていません。資格の訴求効果は、現実には FileMaker コミュニティ内に限られています。
●FileMaker 資格認定の守備範囲
ひとつのペーパー試験でチェックできる知識には限界があります。システム開発のような複雑なプロジェクトでは、ソフトウェアの知識は必要な要素のひとつに過ぎません。カンナやノコギリ、あるいは重機の使い方にどんなに詳しくても、家を建てるというプロジェクトを遂行する力の証明とはならないことと同じです。
たまに「FileMaker から認定を受けています」といったアピールの仕方を見かけますが、「FileMaker 内部の機能の知識について」という説明がないと誤解を招きかねません。FileMaker という特定ソフトウェアの使い方の試験ですから、あくまでもその視点で評価すべきものだと思います。
●FileMaker 社も大変だなーと思う点
データベース専業会社になって以来、FileMaker 社の売上は単一の製品ファミリーの売上に依存しています。ユーザからバージョンアップの頻繁さ、内容の小刻みさを非難する声を聞くことがありますが、ビジネスとして製品を提供しつづけるためにはやむを得ない部分だと思います。資格制度や教材作成には、収入源の多角化という動機もあるはずですし、それは別に悪いことではありません（嫌なら受けない、買わない自由がある）。
あと、FileMaker は「使いやすさ」を標榜するソフトです。多機能になってはきていますが、出題する問題を多数準備するのは大変だろーなと。
●試験内容はオープンにすべし
試験を開始しようとすると、内容を口外も議論もしてはいけない云々といった規約画面で出てきて、承諾しないと先に進めません。この点については、異議を唱えたいと思います。
資格試験は、FileMaker 社が「FileMaker開発者はこういう知識を持つべき」と考えているという指標になるべきものです。試験対策をして要領よく受かろうとする人がいても、FileMaker の開発に必要な知識が問われるようになっていれば、問題ないはずです。指標がオープンになり、それに向けて努力する人が増えれば、業界全体の水準向上にも寄与するでしょう。
FileMaker の資格試験を受ける人は、ほとんどが FileMaker 開発者／ユーザで、社会人でしょう。貴重な時間を使うのに、やみくもな勉強しかできない資格では敬遠されてしまうでしょうし、方向性を間違えて無駄に時間を費やす人も出るでしょう。
資格者が増え過ぎて、資格価値のインフレが起こるなら（喜ばしいことでしょうが）、機能＋αのより高レベルの資格を追加すれば良いのです。FileMaker 社の売上にもプラスでしょう。
●試験内容について
異議はあっても、約束は約束。残念ながら、書けません。
●試験は受けるべきか？
今まで受けていなかった人が言うのも何ですが、受験をお勧めします。試験を受けるとなれば、自信がない人は必死に努力するでしょうし、自信のある人も「万一落ちたら洒落にならない」と隠れておさらいをするでしょう（→自分、笑）。自己啓発にプラスになりこそすれ、マイナスになるはずもありません。個人負担の場合は 17,850 円也に対する価値観もあるでしょうが。
受けるも受けないも、その価値をどう判断するかも、その人の自由。でも、よく言うにも悪く言うにも、対象を知ることは必要。今回受けて一番良かったのは、（試験内容以外は）思ったことを気兼ねなく言えるようになったことですかね。
カスタム関数、一歩及ばず
FileMaker Pro 7 以降で実装されたカスタム関数、便利ですよね。
すべてのロジックを計算式に書くと、ごちゃごちゃになるような時には、汎用部分を切り出して、カスタム関数化！ ちょっとしたデータの加工などには最適です。
Developer/Advanced 版のみでしか、作成、編集、削除できないので、FileMaker Pro しか持っていないエンドユーザの現場ではいじられる心配のない点も Good！（笑）。でも、自社でデータベースのメンテをするのに、Advanced 版を持たないというのは、もったいない気もしますが。
Web 上の情報を徘徊しても、カスタム関数は人気の高い機能のようです。特に、再帰呼び出しができることで繰り返しの計算が可能になったことはインパクトがあったようですね。
使い勝手の面で、ちょっとした物足りなさは、ファイル間のコピーやインポートができない点でしょうかね。でも、ファイルをまたいで利用する関数が大量でなければ（7以降はファイル数はそんなに使いませんよね？）、大した手間ではありませんし、汎用の開発テンプレートに共有する関数を仕込んでおくという手もあります。
「一歩及ばず」の理由は、移植の問題ではありません。
人気の理由でもある再帰呼び出しの限界が問題なのです。
カスタム関数の再帰限界：合計 50,000 回まで。コールスタックの制限によって、呼び出しの深さが 10,000 までに制限されます。この制限を超えた場合、カスタム関数は「?」を返します。末端再帰は、適切に最適化されるため、末端再帰によってコールスタックのサイズが大きくなることはありません。
FileMaker Pro 10 および FileMaker Pro 10 Advanced の技術仕様
カスタム関数の作者がこの点を理解していれば、オッケー。あるいは、対象データからして、絶対に10,000回も再帰的に呼ばれることはないケースでも、まあオッケー。
カスタム関数と GetNthRecord 関数と組み合わせると、対象レコードや関連レコードを走査して値を取得できますが、単純に「引数には Get ( 対象レコード数 ) や Count ( 関連TO::関連フィールド ) を指定してね」的な使い方だと、再帰限界を超えてしまうケースはめずらしくないでしょう。
単なる動作サンプルなら問題ないですが、実際のソリューションではお客さんに「? が出てますが〜」と言われるようではいけません。そうしたリスクがある場合は、処理に時間がかかっても、レコード移動をループしながら値をかき集めるスクリプトだって、考えなければならないかもしれません（クリップボードを使う方法はもう止めましょう）。
カスタム関数が再帰呼び出しから抜けるためには、判断ができる引数が必要なので、上限以上の値が渡される可能性がある場合は引数をチェックするなり、ユーザにわかりやすいエラーを返すなりの対策を講じることも必要ですね。
ちなみに、値の連結や加算の出力を繰り返すような処理は、コールスタックの制限にひっかかるので、10,000回の再帰呼び出しが限界。10,000件の対象レコードや関連レコード、あるいは10,000文字のテキストなどでアウトですから、誰でも遭遇しておかしくない制限です。
末端再帰するようにしておけば、限界は50,000回にアップ。端折って説明すると、再帰呼び出しする時に、計算結果を次の再帰に丸ごと渡すようにする。すると、FileMaker が前の計算結果を保持するためのメモリを消費しないで済むので、再帰回数がより多くなってもオッケーというわけ。末端再帰については、サンプルを書くのが面倒なので、参考ページをば。
FileMaker 9's Custom Function Primer
50,000回の制限は、無限ループを防ぐ趣旨なのだろうが、対象レコードのキーをかき集めて一時的なリレーション越しに動的な集合に対して統計関数を使ったり、ポータル上から関連レコードを開いて擬似的なトランザクション処理を行うことも可能なので、もっと上に上限を設定してほしかった。実に惜しい。今後に期待したい。
誰にとっての「使いやすさ」？（開発者 or エンドユーザ）
前回の記事で、「フィールドを名前で設定」スクリプトステップで一歩前進と評価したが、それはあくまでも開発者としての視点。見方を変えて、エンドユーザの視点だったらどうかという検証が、今回の話。
FileMaker は、「フィールド設定」などのスクリプトでは、フィールドはダイアログ上から選択操作しかできないものの、フィールド名に変更があった場合にも自動的にそれを参照する設定側にも反映されるというメリットがある。オブジェクト名を動的に変えたい時には不便だが、そうでない用途であえて「フィールドを名前で設定」を使う必要もないだろう。
引数が可変になることは開発効率上のメリットはあるが、対象オブジェクトの名前が変更されてもリテラルは追従しないので、引き渡し後にエンドユーザが関係個所を変更すると動作しなくなる。しかも、Get ( 最終エラー ) にエラーが返らないため、EvaluationError の結果もチェックしなければならず、パッと目の複雑さは増してしまう。
分岐によって、ロジックが分かれる時にも、その分岐で何をしているのかは、フィールド名がそのまま見えている方が（普通の人には）分かりやすい（頭の中で変数に入っている値を想像する必要はないから）。テーブル、フィールド、スクリプト、変数、カスタム関数の命名規則も、汎用性や拡張性を考えれば、1バイト文字に統一したいところだが、普通の人には日本語を使う方がずっと分かりやすい。
つまり、開発者がひとつのスクリプトや関数を、より汎用的に、使い回しが効くようにモジュール化して作ろうとするのに対して、プログラムに詳しくないエンドユーザは、ベタな作りであっても、パッと見て分かりやすい方が良い（カスタマイズしやすい）。
仕事柄、何らかのシステムを開発しては納品するわけだが、FileMaker のシステムの場合、納品後はカスタマイズも含めてユーザ自身でメンテするケースも珍しくない。そうしたケースでは、どのように作るのが開発効率が高く、さらに、エンドユーザにも理解しやすく、ユーザ自身で管理できるかという点は非常に悩む部分だ。
すべての箇所で、どの程度の洗練さ／ベタ加減さが程よいのかを確認することができれば良いのだが、普通は、開発期間もコストもそれを許してはくれない。また、ユーザのスキル次第だが、説明しても、その加減によるメリット／デメリットを正確に理解できるとも限らない。
非 IT 部門（現場部門）の人に問題解決の手段を提供するという FileMaker の製品コンセプトと今後の高機能化のバランスをとっていくことは、なかなか難しいテーマを含んでいるように思う。
「フィールドを名前で設定」スクリプトステップ、一歩前進。
FileMaker Pro 10 で追加された「フィールドを名前で設定」スクリプトステップ、よい改善で、一歩前進ですね。
システムを開発する場合、処理の流れによって、異なるテーブル、異なるフィールドに値を保存する分岐は珍しくありませんが、バージョン9以前はフィールド設定の対象フィールド名はハードコードだったので、分岐が必要な時はロジック分のフローを書かなければなりませんでした。
同じロジックなのに、処理対象を動的に変えられないために、同じ処理をハードコードするというのは、ストレスのたまる作業です。修正や変更が加わると、分岐の数だけ修正や変更作業を繰り返すことになるので、想像するだけでも嫌になってしまったりします。
繰り返し位置の番号を動的に変えるのは、少し前のバージョンで対応していましたが、「フィールドを名前で設定」スクリプトステップで、フィールド名ハードコードの問題はほぼクリアされました。「ほぼ」というのは、テーブルオカレンスという FileMaker 独自の概念のために、操作対象を指定するのがちょっと面倒ということです。普通の SQL 系データベースのように、単純にテーブル名、フィールド名を狙えるとより良いのではありますが、まあ良しとしておきましょう。
FileMaker の古いバージョンでは、ハードコードを強いられる要素が多かったのですが、バージョンアップとともに改善され、一番利用頻度の高いフィールドを動的に狙えるようになったことで、不自由を感じる場面はかなり減りました。
スクリプト内でハードコード不可避な要素として残っているのは、インポート／エクスポートのダイアログ内の要素、ソート順、アカウント追加のアクセス権セットなどでしょうかね。個人的には、ダイアログ内での操作性の問題もあって、インポート／エクスポートが一番の問題でしょうかね。
インポート／エクスポートのダイアログは、ハードコードの問題だけでなく、ファイル選択ダイアログが表示するパスを指定できなかったり、ファイル形式を記憶できなかったりするので、いろいろ課題を持っていますね。ダイアログを開かない全自動処理の場合はともかく、一部の操作をエンドユーザに任せる場合には現状では不便なことが多いです。
ちょっと地味で、セールス上のアピールはしにくいかもしれませんが、現場的にはとても重要なポイントですよね。今後の改善に期待したいところです。
「最後まできたら終了」で FileMaker がエラーを返すのはなぜ？
FileMaker には、下記のレコード移動、ポータル行の移動のスクリプトステップがあって、どちらにも「最後まできたら終了」というオプションがある。
- レコード/検索条件/ページへ移動 [ 次の; 最後まできたら終了 ]
- ポータル内の行へ移動 [ 次の; 最後まできたら終了 ]
例えば、最初のレコードに移動してから、レコードを移動しながら、対象レコードの最後まで処理を繰り返すという場合に、このオプションは便利です。実際、とてもよく使います。
ただ、ちょっと不思議なのは、このオプションをオンにしている場合でも、最後のレコードやポータル行で処理を終えようとしている時にエラーコード 101（「レコードが見つかりません」の意味）が返されてしまうこと。
このオプションが動作した時には常にエラーを返すという仕様なのであれば、エラー処理がオフの時には、FileMaker標準のエラーダイアログが表示されなければおかしいが、そうはならない（何もエラーは通知されない）。つまり、エラー処理のオン／オフに関係なく、内部的にエラーが返るだけという動作になっている。
整合性という点で妙な感じなのだが、個人的にはこのオプションで処理を抜ける時にはエラーを返さないでほしいと思います。開発者が処理を抜けるようにと設定したオプションなので、「意図通り」の動作ですし。
開発中にスクリプトデバッガで処理を追っかけていて、エラー処理を入れていない箇所でエラーが返ってくるのは精神衛生上あまりよろしくありません。
関数のコード補完機能、あると良いですねー
FileMaker では、何らかの演算処理を行いたい時には、［計算式の指定］ダイアログを開くことになる。
計算フィールドの作成、スクリプトのフィールド設定の設定内容、IF 文の条件、その他、様々な場面で、［計算式の指定］ダイアログにはお世話になる。
ダイアログの左上部には、テーブルオカレンス／フィールドのリスト、真ん中に演算子、右側には関数リストが表示されている、あの画面です。
FileMaker の［計算式の指定］ダイアログの優れていることは、記述したテーブルオカレンス、フィールドが変更された時に自動的に追尾して、オブジェクト名が変わってくれることでしょうか。これがないと、開発しながら、オブジェクト名の変更ごとに、それを参照する計算式を全部変更する必要が生じるので、ありがたいことです。これは、大昔からのFileMaker の美点のひとつですね。
［計算式の指定］ダイアログでは、ダイアログ上で入力したい項目をダブルクリックすれば、計算式に転記される。キー・タイプによる入力をしなくて良いという点では便利ですが、関数名など分かりきったものはキーボードから右手を話して操作するよりも、タイプした法が速いことがままある。
そんな時には、シェル系の環境や言語系の開発環境では当たり前のコード補完の機能ですね。関数名を頭からタイプして、tab キーを打つと、未入力部分を補完してくれる。あるいは、インクリメンタルに該当する関数名がリストで表示されるといった動作のイメージです。
新しい機能を追加する場合には、他の機能への影響が大きいものと影響の出にくいものがありますが、コード補完の機能であれば影響範囲が［計算式の指定］ダイアログ内に限られますし、使わない人は、従来の操作方法をそのまま続ければ良いので、追加しやすい機能に思いますが、どうでしょうかね。
今後に期待したいと思います。
