[Takaaki Naganoya]

条件を与えているパラメータは、

（１）ファイル形態　Script書類か、Appletか
（２）コード署名の有無
（３）実行環境（ランタイム）
（４）公証の有無

これらに加えて、

（５）SIPの有効/無効

も条件に。

[Takaaki Naganoya]

macOS 10.14.6上で実験

CASE A1（コードサインしていない、Nortarizeしていない、Script Bundle、スクリプトメニューから実行）

Script Editor, Keynoteをコントロール
初回：実行
２回目以降：途中で処理が中断される

CASE A2（コードサインしていない、Nortarizeしていない、Applet、スクリプトメニューから実行）

Script Editor, Keynoteをコントロール
初回：認証ダイアログが表示されて実行
２回目以降：認証ダイアログが表示されて実行

CASE A1（コードサインしていない、Nortarizeしていない、Script Bundle、スクリプトメニューから実行）

Illustrator CC 2019だけをコントロール
初回：実行
２回目以降：実行

Code Signすると、もう少しまともになるでしょうか（開発機上で調整中）。

[Takaaki Naganoya]

131.113.101.130
inetnum: 131.113.0.0 – 131.113.255.255
netname: KEIO-NET
country: JP
descr: Keio University
admin-c: KN195-AP
tech-c: TH499-AP
tech-c: SH1263-AP
tech-c: TY471-AP
tech-c: TO110-AP
status: ASSIGNED PORTABLE
mnt-by: MAINT-JPNIC
mnt-irt: IRT-JPNIC-JP
last-modified: 2011-04-04T07:52:01Z
source: APNIC

99.72.204.56
NetRange: 99.10.64.0 – 99.75.191.255
CIDR: 99.16.0.0/12, 99.32.0.0/11, 99.64.0.0/13, 99.11.0.0/16, 99.10.128.0/17, 99.75.0.0/17, 99.12.0.0/14, 99.72.0.0/15, 99.75.128.0/18, 99.74.0.0/16, 99.10.64.0/18
NetName: SBCIS-SBIS
NetHandle: NET-99-10-64-0-1
Parent: NET99 (NET-99-0-0-0-0)
NetType: Direct Allocation
OriginAS: AS7132
Organization: AT&T Corp. (AC-3280)
RegDate: 2008-02-25
Updated: 2018-07-19
Ref: https://rdap.arin.net/registry/ip/99.10.64.0

45.255.126.135
inetnum: 45.255.126.0 – 45.255.127.255
netname: YINGDA-HK
descr: UNIT 2406A 18/F BANK OF, AMERICA TOWER 16 HARCOURT RD, CENTRAL, HONG KONG
country: HK
admin-c: SYCT1-AP
tech-c: SYCT1-AP
status: ALLOCATED NON-PORTABLE
mnt-by: MAINT-YINGDA-CN
mnt-irt: IRT-YINGDA-CN
last-modified: 2017-03-06T04:19:38Z
source: APNIC

[Takaaki Naganoya]

こんな感じかな。

スクリプトエディタは、macOS標準搭載の、AppleScriptなどのOSA（Open Scripting Architecture）ベースのスクリプト言語を記述、実行、保存、簡易デバッグ、対応アプリケーションの用語辞書のブラウジングを行うためのアプリケーション。

Classic Mac OSから続いており、現行のmacOSに標準搭載されている。

スクリプトエディタは、macOSのバージョンによって呼称が異なっている。

　Classic Mac OS：スクリプト編集プログラム
　Mac OS X 10.1〜10.6：スクリプトエディタ
　OS X 10.7〜10.9：AppleScriptエディタ
　OS X 10.10〜：スクリプトエディタ

所在
OS X 10.6までは「アプリケーション」フォルダに入っていたが、OS X 10.7からは「ユーティリティ」フォルダに入っている。

制限事項
Classic Mac OS〜Mac OS X 10.2の間、スクリプトエディタはCarbonベースで開発されており、編集可能なスクリプトに32Kバイトの上限が存在していた。Mac OS X 10.3ですべてCocoaベースで書き直されており、この32Kバイトの制限も撤廃された。OS X 10.7で64ビットアプリケーションに書き直され、32ビットOSAXとの互換性が失われた（スクリプトエディタ自体を32ビット起動すれば使えないことはないが）。

OSA言語モジュールのインストールや、OSA言語の命令語拡張のためのスクリプティング拡張書類（OSAX）、Script Librariesなどの管理についてスクリプトエディタは一切関知していない。

保存形式
スクリプトエディタが保存可能なファイル形式は、プレーンテキスト形式（.applescript）、コンパイル（構文確認）ずみスクリプト（.scpt）、スクリプトバンドル（.scptd）、アプレット（.app）。OS X 10.8でAuto Saveに対応したため、構文未確認状態のスクリプトでも保存できるようになった。

バンドル形式のスクリプト（.scptd）を保存すると、バンドル内を直接操作するための編集ペインが表示できるようになり、バンドル内にスクリプトライブラリや各種Cocoa Frameworkの追加/削除/移動が可能になる。また、Bundle IDやバージョン番号などもバンドル形式時にのみ編集可能。

記述OSA言語の切り替え
macOSのOSA機構は登場当初の1993年から、アプリケーション操作自動化のためのOSA言語に複数言語をインストールして切り替え運用するスタイルを許容するようになっており、現在ではAppleScriptとJavaScriptベースのJXA（JavaScript for Automation）が標準搭載されている。これらのOSA言語の切り替えはOSA言語ポップアップから選択するようになっている。

かつて存在していたshell OSA、Tcl OSA、Perl OSA、JavaScript OSAなども実際にインストールして当時のスクリプトエディタ上で切り替えが可能なことを確認している（これらのOSA言語はOS X 10.7の64ビット化に対応できずに消えた）。

ただし、OSA言語ポップアップで記述言語を切り替えたとしても、記述中のScriptの内容が他のOSA言語に自動で翻訳されることはない。

コードサイン
スクリプトエディタでは、スクリプトのアプリケーション書き出し時にコードサインを行うことができる。ただし、そのためにはmacOS開発者プログラムに登録して（有償）、コード証明書をダウンロードし、開発環境にインストールしておく必要がある。

拡張方法
（１）スクリプト
スクリプトエディタ自体がOSA言語からコントロール可能な（スクリプタブルな）アプリケーションであり、AppleScriptなどのOSA言語からコントロール可能である。外部スクリプトやOS標準装備のスクリプトメニューからスクリプトを呼び出して、スクリプトエディタを操作可能。

（２）スクリプトアシスタント
スクリプトエディタの編集エリア上でControlキーを押しながらクリック、あるいは複数ボタンが存在しているマウスなどで右クリックすると、コンテクストメニューが表示される。このコンテクストメニューには、特定ディレクトリ以下のフォルダ階層構造がそのまま反映され、選択したスクリプトを実行できるようになっている。

選択中のテキストに対して処理を行う補助スクリプトを呼び出せるほか、サードパーティが提供している強化スクリプトにより、変数名の置換や各種オプションの記述が必要なコマンドの自動記述（choose fileでUTIを指定してファイル選択を行う場合のUTI記述など）を行える。

（３）プラグイン
スクリプトエディタ自体にプラグインをインストールすることができるようになっている。過去にいくつかのプラグインが発表されたが、だいたいはOSに標準機能として搭載されるようになった。開発用の資料も公開されていないため、ほぼプラグインは存在していない。

特殊機能
（１）「フォアグラウンドで実行」機能
Controlキーを押しながら「スクリプト」メニューをクリックすると、「実行」コマンドが「フォアグラウンドで実行」コマンドに表示変更される。本機能は、スクリプト内でCocoaの機能を呼び出したときに、NSWindowやWebViewなどのメインスレッドで呼び出す必要のあるクラスの操作に備えたもの。これらのクラスを用いている場合に、普通の実行コマンドを操作しただけではエラーになったり、スクリプトエディタがクラッシュしたりする。

（２）「記録」機能
アプリケーションの操作を「記録」（レコーディング）できる機能。ただし、OSA言語による操作に対応していて、そのうえで「記録」に対応しているアプリケーションの動作しか記録できない。対応アプリケーションも少なく、記録されている内容を読んでも理解しやすい内容になっているわけではないので、メーカーからも非推奨の機能になっている。有名な対応アプリケーションには、FinderやBare Bones SoftwareのBBEditがある。

（３）構文色分け設定機能
OSA言語ごとに構文色分けを設定できるようになっている。ユーザーは自分の好みの構文色分けを定義することで、スクリプトをより読みやすくすることができる。とくにAppleScriptにおいては「return return」（サブルーチンから返り値として改行コードを返す）といった記述もできるため、構文要素ごとに色分けされていないと可読性が著しく低下する（AppleがOS出荷時にデフォルトで設定している構文色分け内容は、お世辞にも見やすいものではない）。

（４）簡易デバッグ機能
スクリプトエディタには、アプリケーションからの返り値などを確認するために、簡易ログ表示機能が用意されている。アプリケーションからの応答内容などを確認するのが主な用途であるため、変数のリアルタイム監視やブレークポイントの設定などの機能は持たない。AppleScript内蔵のlogコマンドでこのログへの変数や定数の内容表示でき、こちらが主に利用されている。

スクリプトエディタのデバッグ機能はあくまで簡易版であるため、変数のリアルタイム監視やブレークポイントの設定、ステップ実行などのデバッガーの機能についてはサードパーティのアプリケーション「Script Debugger」の導入を検討すべきである（同デバッガはAppleScript専用）。

[Takaaki Naganoya]

構文色分けの機能についての言及がないかも？

[Takaaki Naganoya]

■経緯

エックスサーバーのWebホスティングサービスを利用して10年たちますが、トラブルが発生していない時の同社のサービスは快適です。価格も低廉であり、ただBlogを漫然と運営しているだけであれば不満は出ないでしょう。

エックスサーバーは、当初、WordPressの自動インストールなど（当時としては）画期的なサービスを提供することで、手軽に使えるWebホスティング業者として、他に類を見ない手軽なWebホスティングサービスを提供していました。

インストールの手間がかかる各種Web系のプログラムをWeb画面から手軽にインストールできるため、「コンテンツには興味があるがWebサーバーのお守りには興味がない」ユーザーに支持されました。

■MySQL4の問題

当初、WordPress ME（2.11相当）＋MySQL 4で自動インストールサービスが提供されました。このWordPress MEでサービスが始まったことが遠因といえなくもないでしょう。いまでは、手軽にアップデートが行えるWordPressですが、その体勢になる「前」の混乱期のソフトウェアでもあり、エックスサーバーとしてもWordPress MEから現行のWordPressへの移行手段を「提供してこなかった」点が、そもそもの原因といえます。

■MySQL5への移行

古いバージョンであるMySQL4からMySQL5への移行はエックスサーバー側からお知らせが（数年前から）届いていました。同社が提供している管理画面ではPHPのバージョン変更なども行えるようになっているため、管理画面上からMySQL4→5への切り替えI/Fが提供されており、自分も移行期限の１年ぐらい前に切り替えたつもりになっていました。

管理画面上では「MySQL5を使っている」ことになっており、Terminalアクセスのための手続きも煩雑なため、Webブラウザで現状を確認するしかなかったのが実際のところです。

■問題を拡大したエックスサーバーのサポートの「コミュニケーション力のなさ」

以前から、エックスサーバーのサポートにメールで質問しても、トンチンカンな要領を得ない返答が返ってくることが多く「この程度のサービスなのだから、この程度のレベルの低いサポートしか抱えていないのだろう」という「価格相応」の（日本語が不自由な）サポートにも、半ばあきらめの気持ちで接していました。

問題が表面化したのは2018/1末のMySQL4強制シャットダウン強行時です。当時、自分は風邪をひいて寝ていたため、「寝て起きたらBlogが見えなくなっていた」という状況にただただ驚きました。

MySQL4のサーバーダウンについて、サポートに状況の説明を（メールで）求めたところ、

　「これは以前から通告してきたことであり、撤回はない」
　「データベースの内容は消去したため、内容のダンプなどは提供しない」

の一点張り。

エックスサーバーから送られてきたメールをあらためて確認すると、シャットダウン直前に送られてきたメールにはご丁寧にMySQL 4サーバーに上がっているデータベースのテーブル名一覧なども入っていたのですが、

　　Subjectが普通のおしらせメールと変哲のないもの

だったので、内容はとくに読んでいませんでした。

MySQL4のデータベースを利用中のユーザーの方々に、といった注意を引くものではなく

　[XSERVER インフォメーション] 【重要】「MySQL 4」データベース提供終了のお知らせ（再通知）

といった、重要なのはわかるんだけど自分が対象であることが「まったくわからない」ものでした。普通のお知らせフォーマットなので、さっぱりわからないんですね、これだと。

また、Webブラウザ上の管理コンソールではそうした警告表示が一切行われていないこともあいまって、

　・現状がよくわからない
　・どういったアクションを求められているかが不明
　・サービスを提供してきたWordPress MEからの移行が行えるかどうかについては一切説明がない

という、割と「これで分かれという方が無茶」な状態でありました。

そして、その状態で運命の2018年１月末を迎えてしまったのです。

■対応

10年書き溜めて、Googleの検索エンジンでもヒットしまくる「AppleScriptの穴」が、ほぼゼロから再スタートしなくてはならなくなりました。

とりあえずはWordPress最新版をインストールし、ローカルのAppleScript書類をHTML化してXML-RPC経由でWordPressに投入するAppleScriptなども作成し、大量の記事の一括投入が行えるように対処しました。

Blogについては、とくにこれで利益を生むようなものでもないので、「10年続けたけど、このままでいいのか？」などとさんざん仲間内で相談していたこともあり、心機一転できたことはプラスにとらえています。

ただ、「存在しないこと」のデメリットもすぐに見えてきたため、跡地にとりあえず最低限の「AppleScriptの穴」を再構築することにしました。

とはいえ、少なくない手間と時間がかかってしまったことも事実です。ユーザーの利益にならないアクションを、ユーザー側からすれば「たいした説明も現状表示もなく」唐突に行ったわけで、どこかのユーザーがエックスサーバーを訴えたとしても不思議ではないと思います。

ただ、この「エックスサーバー事変」からユーザー側もWebホスティング業者側も何かかしらの反省や教訓めいたものが得られないと、やっていられないものでもあります。成功から学べることはほとんどありませんが、失敗には明確な理由と原因があり、失敗から学ぶことだけは可能なのですから（ただし、学んだ内容が生かされるかどうかは別問題）。

■正直な気持ち

エックスサーバー側としては「説明はした」「以前から通知はしていた」というところなんでしょうけれど、まったく伝わっていないうえに、強行シャットダウンを行うという「もっとも賢くない選択」を行なってしまいました。当初のエックスサーバー側のサポート対応は実に強硬的で、腹立たしいことこの上ない（筆舌に尽くしがたい）状態でありました。

＃　のちに、手のひらを返したように当初の強硬対応を抑え、MySQL Adminのユーザーへの解放などの施策を打ち出してきました。ただ、当初の説明および対応が悪すぎて心象は最悪です。

つくづくエックスサーバーには愛想が尽きました。

ちょうどWordPress最新版への移行もできたので、海外のホスティング業者も含めて、移行しやすくなりました。今後、いろいろ検討してコストとサービスのバランスがもっとよくて、日本語でも英語でもなんでもいいので、「まともなサポート」を提供しているところがあれば、乗り換えたい気持ちでいっぱいです。

かつて、エックスサーバーのホスティングサービスについては、他人にもおすすめしていたこともありました。いま、他人にお勧めできるかと問われると微妙なところです。いえ、とてもおすすめできません。

• この返信は7年、 2ヶ月前にTakaaki Naganoyaが編集しました。
• この返信は7年、 2ヶ月前にTakaaki Naganoyaが編集しました。

[Takaaki Naganoya]

Finder上で選択したAppleScript書類をHTML化してWordPressに投稿するAppleScriptが完成。ただ、タグとカテゴリーの運用について少々検討の余地が、、、

[Takaaki Naganoya]

XML-RPC経由でWordPressにAppleScriptから投稿すると、XML-RPCの通信モジュールがクラッシュを起こしてまともに投稿できないケースが多々ありました。
そこで、AppleScriptObjCでXML-RPCのフレームワークを呼び出して投稿させてみたところ、問題なく投稿できることを確認しました。
これで、指定フォルダ以下のAppleScriptをBlogに自動投稿するAppleScriptが、、、、、

[Takaaki Naganoya]

ホスティング業者からはデータベースのダンプを取り戻せたものの、ダンプ内容をそのままBlogに（コピペで）突っ込んでも、リンク箇所などで問題が出る（Script Link）ことがわかりました。

WordPressのメール経由の記事投稿もうまく動作していない様子。REST APIも肝心のOAuthプラグインの仕様どおりにプログラムを書いてみてもトークンをうまく取得できなくて難航中。

XML-RPCしかないのだろーか（ーー；

[投稿者]

投稿