一覧 
 
 
福井県立大学・経済学部 田中求之 (Motoyuki Tanaka)
最終更新日: 07年02月09日 16時06分

小さなものから始めよう(Start small)

どうやってオブジェクトの参照を組み立てたらよいか学ぶためや、どんな処理が行われるのかを確かめるために、スクリプトのうちの非常に短い部分を何度も何度も繰り返しテストすることがある。この作業のためにどれだけの時間を費やしているかに目を向けてみてほしい。この場合の問題の一部は、実際に試してみるまでアプリケーションがどんな処理をやってくれるのか分からないということにある。辞書は、実際のことを教えてくれない。問題の別の部分は、AppleScript にはデバッグを楽にできる仕組みが組み込まれていないことにある。だから、プログラムを開発するときには、一度に1行ずつ、(過去にテスト済みで)すでにうまくいくことか分かっているものを一つずつ積み上げていくというやり方が必要になる。AppleScript では、プログラム全体を一気に書き上げておいてからうまくいかない場所を探し出す、なんてことはやってはいけない。絶対にうまくやれない。プログラム全体を一つにまとめ上げる時には、法廷で証人の反対尋問を行う弁護士のようであるべきだ。つまり、理想としては、答えをまだ知らない質問は決して投げ掛けたりしないことである。

(*田中補足:このアドバイスは、ようするに確実に動作が分かっている小さなスクリプトを一つずつ積み上げていってプログラムを作れってことなんだけど、これは、ある程度大きなスクリプト、たとえば CGI とかワークフローをコントロールするとかそういうスクリプトを書いたことがある人は皆共感するのではないか。少なくとも自分は強く共感する。自分が長めのスクリプトを書くときには、仕上げるべきスクリプトのウィンドウ以外に、動作確認のスクリプトを書いて動かすウィンドウが、たいていは2つ3つは開いている。そして、テスト用ウィンドウで動作を確かめてから、それをメインのプログラムにコピーして、参照なんかを書き直して、と作業している。結局、この方法が、確実にプログラムを組み上げていくことができるんだよね。)

すべてステップをテストすること(Test every step)

自分のスクリプトが実行されていく中でコードが投げ掛ける質問の答えが分からない時には(=スクリプトがどのような判断や処理を行うのか分かっていない時には)、それを明らかにすること。スクリプトを走らせて、「結果」に表示されるものを利用しよう。イベントログも活用しよう。スクリプトを開発しているときには、実行して起こることが自分が望んだり期待したものであるかどうか、全てのステップについて分かっておくべきだ。

(*田中補足:これは先のアドバイスと重複するけど、ようするにきちんと動作を確かめながら書いていくことの重要性を言ってる。そしてスクリプトを走らせて動作を確かめるときには、「結果」や「イベントログ」に表示される内容を利用しようということだ。実際、自分は「結果」ウィンドウなしにはスクリプトは書けないです。)

実験することを恥じないこと(Don't be ashamed to experiment)

推測することを恥じない! 数多くの AppleScript のコード開発は、当て推量をすることだ。アリストテレスが言ったように、あるテーマについて、そのテーマの認める適確な質問を発するのは知恵の印なのだ。

(*田中補足:最後のアリストテレスが云々ってのはよく分からないけど(初めて聞いた気がする)、「こうかも知れない」「こうなるかな?」と考えて、それを試してみることは重要だよ、ってことでしょう)

すべての解決にあてはめる前に、個別のケースを解決すること(Solve the single case before expanding to "every")

ある処理をループで行う前に、一つの場合でちゃんと処理できるようにすること。境界条件での動作について悩む前に(つまり、ループの実行回数が正確に何回になるのかを解き明かそうとする前に)、人工的なテストのループでちゃんといくようにすること。

(*田中補足:ループで大量の一括処理や繰り返し処理を行わせる場合には、ループの中に入れる処理がちゃんとうまくいくことを確かめ、またループの終了がどうなるかは、テスト用のループを作って確かめること、といったことですね。)

AppleScript の謎めいたエラーメッセージを理解しようとはするな(Don't try to understand AppleScript's mysterious error messages)

大切なことは何が間違っているのかではなくてどこが間違っているかだ。どこかが問題かが分かるだけでたいていは十分だろう。だって、たとえスクリプトを書いた時にエラーになるかもしれないなと思っていた場合でも、どこを変えなければいけないか分かるわけだ。もしエラーはたいして重要でないと考えているのなら、エラーを無視するためにエラー処理(try のブロック)を使えばいい。そうすれば、コードを実行したときにエラーで止まることはないからね。

(*田中補足:このアドバイスには個人的には同意しかねるんだけど、でも、確かにエラーメッセージ自体は、特に AppleScript を始めた人にとっては、かえって混乱の種になるかもしれないということは認めざるをえない。というのも、エラーメッセージは、最終的に実行時にどんな障害が起きたのかを告げてはくれるが、その障害がどんなスクリプトや条件によって引き起こされたのかということは告げてくれないことが多い。結果だけ告げられて原因は自分で考えないといけないからだ。でも、自分は、それでも、そのエラーを考える過程が、AppleScript について学ぶということにおいて重要だと考えている。スクリプトと実行プロセスの間の因果関係?みたなものが自分の中に感得できるようになることは、確実にプラスになる。)

スクリプトの最終版を書く前にお試し版を書くこと(Write a practice script before writing the final version of the script)

AppleScript はとても深刻な影響を及ぼすようなことをする力を持っている。たとえば、ファイルを消去したり書類を壊してしまったりとかね。「これは練習なんかじゃない」っていう本番のスクリプトのスイッチを入れちゃう前に、自分でやろうとしていることがうまくいくことをしっかりと確かめる必要がある。

(*田中補足:あんまり補足しなくてもよいとは思うのだけど、ファイルやファイルのデータを扱うスクリプトの場合、慎重に確かめた上で実戦投入するっていうのは重要なこと。スクリプトの操作には Command-Z は利かないからね)。

言語を知ろう(Know the language)

私がプログラムを開発している過程で、FrameMaker のオブジェクトモデルについて、多くの推測を行ったのは事実だけど、でも、AppleScript という言語そのものには一切推測は行っていない。my と it が何を意味するか、tell と of をどう使うか、論理式の値をテストするための条件式をどう書いたらいいのか、あるいは、プロパティとエレメントの違いはいったい何なのか、こういったことを全く分かっていなかったら、私はこの章で紹介したプログラムを書くことなんかできなかった。AppleScript は英語みたいに思えるので、(英語が分かっている人なら)英語はもう知っているので AppleScript だって分かっていると考えてしまうかもしれない。でも、そう考えるのは間違っている。AppleScript は、他のプログラミング言語同様に、ルールに基づいて構成されているプログラミング言語なのだ。厳格で、気難しくて、細かいことまでうるさいものなんだ。この本は、君が書いてみたいと思っている特別なスクリプトをどうやって書くかを教えることなんてできない。でも、君に、AppleScript というプログラミング言語を教えることはできるし、教えるものであるんだ。

(*田中補足:AppleScript は、それがどんなに英語に似ていたとしても、一つのプログラミング言語として、ちゃんと学習しマスターする必要があるってこと。この点は、自分の Tanaka's osax 絡みのやり取りなんかで、自分が考えていたことと一致している。)。