Xcode 14.2でAppleScript App Templateを復活させる

Posted on 3月 21 by Takaaki Naganoya

AppleScript＋Xcodeでアプリケーション開発を行う方法についてわかりやすくまとめた電子書籍「AppleScript＋XcodeでつくるMacアプリ　Xcode 14対応」を刊行しました（PDF 448ページ＋付録、サンプルXcode Project Zipアーカイブ）。

この書籍の中では、テンプレートがXcode 14.2に存在していないので、書籍添付のプロジェクトをコピーして使ってください、という説明を行っています。

と、そんな本をまとめたところ、edama2さんから「なんか、前バージョンのXcodeからテンプレートをコピーして来れるみたいだよ」という話が！

早速、調べてみました。edama2さんから教えていただいた記事のとおりにはいかなかったので、Xcodeのバージョンによっては細部が変わっているようです。

自分は、Apple Developer Connectionに契約しているので、古いバージョンのXcodeもダウンロードできます。古いといっても古すぎるのはどうかと思いますので、ここではXcode 13.2をダウンロードしてきました。アーカイブ展開してさっそく、Xcode 13.2のバンドルパッケージ内にアクセスします。

Xcode 13.2.appをFinder上で選択して、マウスの右ボタンクリックでコンテクストメニューを表示させ、「パッケージの内容を表示」を実行。

/Contents/Developper/Library/Xcode/Templates/Project Templates/macOS/Other

の中に「AppleScript App.xctemplate」が存在していました。

この「AppleScript App.xctemplate」をXcode 14.2（記事執筆時最新）が認識するテンプレートのフォルダにコピーすれば使えるでしょう。

~/Library/Developer/Xcode/Templates

の中にコピーすると、Xcodeが14.2が認識してくれました。

Xcode 14.2を起動し、File＞New Project

「AppleScript App」を選択すると、問題なく新規プロジェクトが作成できます。

テンプレートをZip圧縮して、ダウンロードできるようにしておきます。

Download Templates.zip

Elgato Stream DeckをAppleScriptでフル活用

Posted on 11月 25, 2020 by Takaaki Naganoya

▲Stream Deck本を発売しました！　新刊「elgato STREAM DECK 徹底活用Mac+STREAM DECKで時短+作業効率化!!」

友人から実機を借りて、Stream DeckからAppleScriptを実行する方法について一通り確認しました。この場をお借りして、Sutohさんにお礼を申し上げます。

また、初期公開時の記事に対してコメントいただいたTechnocraft様に感謝申し上げます。このお二方の尽力なしには評価できなかったことでしょう。

本記事はフィードバックを取り入れ、初回掲載時からは大幅に書き換えてあります。

▲Stream Deckの「システム」＞「開く」アクションに登録して、macOSのGUIアプリケーションのメニュー操作を簡単に行うツール「Piyo Menu Clicker」ベータ版の配布を開始しました

Stream Deckとは？

Elgatoが製造・販売している、キートップ画面つきの小型サブキーボードです。Mac本体とはUSB端子で接続します。キートップの内容をカラー液晶ディスプレイで表示しており、キータッチ時の実行内容やキートップ表示内容の差し替えがソフトウェアにより柔軟に行えるようになっています。

メカニカルキーで、キーストロークはありますが、キーボードというよりもゲームコントローラのような操作感です。ゲームに使えるかと言われれば、不可能ではないものの快適とも言い難い感じです。キーストロークが深めなので、連打が不可能とは言いませんが、格子状のキー配置がゲーム向きというよりも業務系コントローラ的な印象を受けます（ゲーム用にハードな利用をしたときの耐久性は未知数）。ゲームコントローラには専用のデバイスやフットスイッチを使った方がよいでしょう。そんなにお安くはありません。

また、キー自体がテンキーのような格子状に配置されており、本体にずいぶん厚みもあるため、これで高速に文章を打つのは（キー数も足りないですし）無理だと思います。専用の日本語入力プログラムを用意すれば、15キー程度でもメールの返信ぐらいは不可能ではなさそうです（そういう野望は別途持っています。評価期間中には完成しないぐらいの壮大な野望が、、、、）。

はるかかなた昔（2000年代前半）、すべてのキートップの内容をカスタマイズできるよう、各キートップに有機EL（OLED）を搭載した「Optimus Maximus」が発表され、長い年月を経たのちに19万円（当時）という価格で発売されたことを覚えている人もいるでしょう。Optimus Maximusのコンセプト自体は広く支持されたものの、実現方法に無理があったために、ひじょうに高価で巨大なものとなってしまいました（そして、スマートフォンやタブレットの登場により魅力と需要は減ってしまいました）。

Stream DeckはOptimus Maximusの基本コンセプトを踏襲しつつ、その欠点（複雑すぎるハードウェア）を見直し、現実的な価格に収めたものと見ることができます。同機では１枚ものの液晶画面の上に透明なキートップのハードウェアキーボードを並べることで同様の操作系を実現しています。

また、フルキーボードではなく、LCDボタン6個、15個、32個といった限定されたキー数の製品をラインナップし、業務現場における簡単ワンキー操作ソリューションといった市場をねらっているようです。「ライブコンテンツ作成コントローラ」といった少し不思議な名前がついていますが、それは映像中継の現場などで使って便利なようにソフトウェアの標準機能が整備されているためで、本来そのように用途が限定されるものではありません。

そのような現場では、照明が暗く、キーボードが発光すること自体に意義があります。また、スマートな操作系を少ない設置の手間で実現でき、有線接続で確実に動作する本製品は競合に対しての牽制を行う「見栄アイテム」として有効でしょう（意外と重要）。自動車の運転席にコンピュータのインタフェースを設置するとしたら、ベストな形態かもしれません。車載コンピュータインタフェースとしては、おすすめできそうです（自分、運転しないので具体的な使用例を紹介できませんけれども）。

アクションはStream Deckの複数のキーボードに対して別々の内容で設定することができ、Stream DeckのすべてのキーにAppleScriptを呼び出すアクションを（別々のScriptを呼び出すものを）登録しておくこともできます。各Profileは最前面のアプリケーションごとに自動変更させられるために「物理キーボード版のScript Menu」のような運用ができます。

アプリケーション起動アクションを割り振っておくと、「物理ボタンのあるアプリケーションランチャー」として利用でき、この使い方もけっこう便利です（外では使えないけど）。

機能固定のStream Deckと最前面のアプリケーションごとに機能を自動変更させるStream Deckの２台を並べておくと便利そうな気がします。

AppleScriptを呼び出してこそ魅力を引き出せるStream Deck

Stream Deckで呼び出せる機能は、Elgatoが用意しているソフトウェア上で、デフォルトのアクションを選択してStream Deck上の各キーに指定することで使えるようになります。このソフトウェアキーボード設定（Profile）は複数持つことができ、macOSのメニュー上から随時切り替えられます（このProfileの切り替え自体をStream Deckのキーから行う「Switch Profile」アクションもあります）。キー数が少ないとProfileをこまめに切り替える必要があるわけで、15キーモデルが実用最低レベルでしょう（６キーモデルは何のために？）。

純粋に文字入力キーとして割り当てることも可能ですが、複数の動作をワンキーで行ってくれることが望ましいところです。

複数のアクションを連続して実行する「Multi Action」アクションが存在するものの、やはりまとまった処理についてはAppleScriptで記述して実行できたほうが便利に思います。

AppleScriptをこのようなソリューションに利用する意義は、条件を考慮して処理を変更できることでしょうか。

ネットワーク上にいるマシンがSleepしているか稼働しているかをチェックして、稼働していたらYouTubeの再生を別マシンに引き継がせるといった処理は、AppleScriptならではのものです。

時間や日付から処理を変える（休日は実行しないなど）こともできてしまうわけです（曜日によっては定休日のため「出前注文アクション」を実行しないなど）。

標準装備のAppleScript実行アクション。「System > Open」

Elgatoが標準で用意しているStream Deckソフトウェアに、指定のAppleScriptを実行するアクションはとくに用意されているように見えません。

見えませんが、さんざん確認してみたところ、アクションのうち「System > Open」でAppleScript書類のうち「.scpt」形式（非バンドルAppleScript書類）と「.applescript」形式（テキスト形式のAppleScript）については関連づけたアプリケーション（デフォルトではスクリプトエディタ）ではなく、osascriptコマンドを使って実行されます。

アクション名：Open（標準装備）
ランタイム名：osascript
指定可能要素：アイコン画像、Title、AppleScript File
Script File Format：.scpt / .applescript
インターネット接続：不可
ダイアログ系の命令実行：可
"facetime-audio" URL event発行：OK
GUI Scripting利用許可：OK

唯一、「.scptd」形式のAppleScript書類のみ、関連づけたアプリケーション（デフォルトではスクリプトエディタ）でオープンされ、実行されることはありません（自分が普段使っているAppleScriptって.scptd形式ばっかりなんでひっかかりました）。

▲AppleScript書類の形式が「.scpt」と「.applescript」の場合は実行、「.scptd」の場合にはエディタでオープンされる「System > Open」アクション

この「System > Open」アクションで実行されるAppleScriptでは、Cocoaの機能やGUI Scriptingを呼び出せますし、GUI Scriptingの認証も取得できます（２回目以降の実行で認証ダイアログが表示されることはありません）。display dialogやdisplay notification、choose from listなどのダイアログ系のUIの表示も問題ありません。

オープンソースのAppleScript実行アクション。scptd形式が実行できる「RunAppleScript」

このStream Deckソフトウェアデフォルトの「System > Open」アクションとは別に、Github上でオープンソースの「streamdeck-applescript」プロジェクトが配布されており、これを簡単に導入できました。

streamdeck-applescript-masterフォルダ中の「Release」フォルダに、「com.mushoo.RunAppleScript.streamDeckPlugin」が入っているので（ビルド不要）、これをダブルクリックすると、streamdeck-applescriptプラグインがSTREAM DECK管理ソフトウェアに読み込まれます。

バンドル形式のScriptおよびフラットなscptファイル、あるいは単なるテキストで書かれたAppleScript（inline script）を指定できます。

アクション名：RunAppleScript（Githubからダウンロード）
ランタイム名：RunApplescript
指定可能要素：アイコン画像、Title、Script File / AppleScript（Inline）
Script File Format：scpt / scptd / text (Inline)
インターネット接続：不可
ダイアログ系の命令実行：不可
"facetime-audio" URL event発行：OK
GUI Scripting利用許可：OK

Elgatoが自社Webから提供しているStream Deckソフトウェア自体は、Sandbox化されているわけではないようですが、いろいろ（長大な）AppleScriptを突っ込んで実行してみたところ、一定の制限が存在していることがわかりました。

すぐに気がつく点は、display dialog、display alert、display notification、choose from listなどのダイアログ表示系のコマンドが効かないということ。Standard scripting additionsの利用が禁止されているのではなく、「LSUIElement=true」の設定による影響を受けているように見えます。この点、標準装備のOpenアクションのほうが気楽に使える感じです。

Stream Deckアプリケーションはアプリケーション形式のドライバ/設定ソフトウェアであり、Dockにアイコンを表示しない状態で動作します。そのため、ダイアログ系の通知を行えない状態であると推測されます。とはいえ、Cocoaの機能を呼び出してAlert Dialogを表示させるとあっさり表示するという「裏技」があります。

Stream Deckから「streamdeck-applescript」アクション経由で呼び出したAppleScriptでは、インターネットへのアクセスが許可されておらず、これが最大の制約項目でしょう（Openアクションも同様）。

Stream Deckアプリケーション自体はSandbox化されていないため、「streamdeck-applescript」自体の制約に見えます。同アクションの開発者がAppleScriptから直接インターネット接続してWeb APIを呼び出すような処理を考慮していなかったためにこのようになっているのか、あるいはStream Deckソフトウェア自体の制限であるかは不明ですが、現状ではそうした（よくある）処理が行えません。

確認してみたところ、Stream DeckソフトウェアのInfo.plistに「Allow Arbitrary Loads=true」のエントリがないために、プラグインおよびそこから呼び出されるAppleScriptではネットワークへのアクセスが行えないようです。これを配慮不足と受け止めるか、セキュリティ上の面倒ごとに巻き込まれたくないものと受け止めるか、そこまで考えていないものと取るかは個人の受け止め方次第でしょう。

Stream Deckの各ボタンにRunAppleScriptアクションを割り振って、Stream Deckのボタンを乱打すると、アクション呼び出しがバッファリングして実行されるため、（挙動としては正しいものの）やや扱いに困る印象を受けました。

つまり、コンピュータに関して知識の少ないユーザーがStream Deck上のキーを押して、すぐに反応がない状態だとキーを連打する可能性があり、連打された内容はバッファリングされ、キャンセルが効きません。

このあたり、呼び出すScriptですぐに何らかの視覚的なフィードバックをしつつ処理に入るなどのケアを行う必要性を感じました。コンピュータに関する知識の少ないユーザーに使わせるには注意が必要でしょう。AppleScriptを割り当てて実行させる場合でも、「ちょっとかじった」ぐらいのScripterでは、十分な配慮を行えないため、Stream Deckの「streamdeck-applescript」アクション経由で動くAppleScriptを書くのにはけっこうなスキルが必要とされるように感じられました。

活用例

facetime-audioで所定の相手に通話を行うAppleScriptを、相手の顔写真入りで登録すると、まるで内線電話感覚でオーディオ通話をかけられて便利でした。

実際に作ってはいませんが、Web経由で出前の注文を行うScript（そんなに難しくないもの）を書いておいて実行すると、「パエリア注文、１時間後に」といった運用ができて便利です。定休日には注文を実施せず、配達時間もシステムクロックから拾ってきた値をもとに指定できるため、とても実用的なものとなるでしょう。

よく行う、LAN上のファイルサーバーのマウントや特定のフォルダのオープンを行わせるのも便利でした。TimeMachineドライブのアンマウントなども便利でしょう。

フローティングパレット上からAppleScriptを実行できる、macOS標準搭載の「Switch Control」も便利ですが、それらのScriptをStream Deckに登録すれば、画面上の場所を占有されることなく同様にAppleScriptを（最前面のアプリケーションごとにProfile表示を切り替えて）実行できるので、道具としてコンピュータを便利に使いこなすという方向で、キートップの表示内容を変更できるハードウェアキーのソリューションは実用的であり、さまざまな作業の苦痛を緩和してくれるものであると感じます。

総合評価

こうしたAppleScriptを自分はいつもScript Menuから実行していますが、アイコンつきの物理ボタンから呼び出せるのは本当に便利です。

Stream Deck標準搭載アクションでは、メールの未読本数の表示などStream Deck上のボタン表示に対してカスタム内容をフィードバック表示させることが可能です。一方で、RunAppleScriptアクションでその機能は利用できないため、不満がないわけではありません。Scriptからネットワーク接続できないのも、REST APIやCDN上のJavaScript Libraryを呼び出しまくっている今日のAppleScriptの利用レベルからすると、世界観が狭すぎて不満が残ります。

活用は行えるものの、Stream Deck自体が価格相応かと言われると「見栄用途」に使わないかぎり疑問が残ります。

そんな向きには、iOS用のElgato Stream Deck Mobileアプリが用意されており、とりあえずiPhoneやiPadにインストールしてこれらのデバイスをStream Deckに見立て、Macの操作を試すことができます（よくできている、、、）。

ちなみに、iOSデバイスとMacの間の接続は無線で行われ（WiFi？）Stream Deck実機のように有線接続する必要はありません。１月あたり350円（無料で１か月のお試しあり）なので手軽に試せるでしょう。また、iOSデバイスとStream Deck実機は同時使用できるため、iOSデバイスを臨時の追加Stream Deckとして運用することも可能です。

Stream Deckのドライバはアプリケーションとして動作するため、Intel版ではありますがM1 Mac上でも問題なく動作することでしょう。

冒頭に「友人から借りた」と書いてあるとおり、本製品には自分に購入させるだけの何かがあるわけではありません。身の回りのさまざまな用途に活用できるものの、たいていは代替手段が存在します。

一方で、リアルなハードウェアキーによる操作が欠かせない用途も存在することでしょう。多忙な現場、つねにオーディオチャットを内線電話のように利用している現場、あまりコンピュータに詳しくないユーザーに対して定型作業を行わせるような用途には、ハードウェアキーによる操作はわかりやすく、導入しやすいことでしょう。

再来週あたり友人に返却する必要があるのですが、少し「惜しい」と思える程度の魅力はあります。使うかどうかはその人次第でしょう。

（注：本記事の転載やまとめを禁じます）

個人的に嫉妬をおぼえるほどナイスアイデアのソフトウェア

Posted on 11月 20, 2020 by Takaaki Naganoya

「やられた！」と、感じるソフトウェアに出会うことはたまにあります。なんで自分では思いつかなかったんだろう、くやしい、これは自分が作るべきだったソフトウェアだ。でも技術力と発想力で勝てていない。素直に賞賛するしかない。

そういう目で見てしまうソフトウェアが何本かあります。それが、ものすごいヒットを叩き出してセールスをあげた、というわけでもないんですが、それでも羨ましいという気持ちはあります。

＃　この項目、あとから追記するかもしれません。

UI Action

PFiddlesoftの旧称「Prefab UI Action」といったか……GUI版のFolder Actionみたいなソフトなんですが、所定のアプリケーションのメニューなどのGUI部品を監視・実行するAppleScriptを設定できるツールです。つまり、各アプリケーションのGUI操作を横取りして、AppleScriptを実行させるというものです。

同様のことができないかと考えていたので、「やられた！」と、叫んでしまいました。

ただ、これができたらできたで、セキュリティ的にとても問題になりそう（知らないうちにアプリケーションの挙動が変えられてしまう）なのと、どのマシンにも同じソフトウェアとScriptをインストールしておけるわけでもないので、運用性がいまひとつだと感じました。

これは過去最大の「一本とられた！」と感じる嫉妬のスマッシュヒットでした。完敗です。

Siri

2000年代前半にはAppleScriptで同様のプログラムを実現していたので、とても「やられた！」と感じましたが、けっこうみんな同じようなことを考えていろいろ作っていたので、出し抜かれても仕方ないといえば仕方ないですね。予想どおりサーバー側で音声認識を行うなど、しかるべき努力をまっとうに行ったシステムという印象です。

さらに、自分たちで試作したソフトウェアでは住所録データやスケジュールデータが充実していないと、ほとんど意味がないし使っていても面白くないことがわかっていました。それがまさか、SNSなどの発達により個人データがネットを通じて住所録にたまっていく環境が出来上がっていくなど、普及の前提条件がクリアされていたことには気づきませんでした。外部環境が変わりつつあることを敏感にキャッチできていなかったというべきでしょうか。

ただ、実際に使ってみると「日常的にこれといって便利な用途がない」とも感じます。とんがっていないマイルドな味付けなので、（自分には）ささらない感じです（激辛希望）。

Retrobatch

Flying Meat SoftwareのRetrobatch。画像処理専門に特化したAutomatorという感じです。

Automatorのダメダメさ加減に業を煮やして作ろうと思ったのか、自分ならもっとすごいものが作れるぜ！　と、思ったのかAutomatorを反面教師としたアプリケーションはいくつも存在します。

Cocoa APIの仕様を眺めていると、だいたいこういう感じのものが作れることはわかります。でも、それを実際に形にするのはまったく別の話。個人的にものすごく羨ましく妬ましいソフトウェアです。

とくに、CoreMLのパワーを利用して「なんとなくこんな感じの処理」をバッチ中に組み込めるというのが、うらやましすぎるポイントですね。それ、自分もいろいろ研究している部分なので。この方面の処理は、実際に作ってみると思い通りに動かないし、実現できたからといって評価されるわけでもないという微妙な位置付けと難易度なので、ついついそんなに真剣に考えないものなんですが、きちんと動いて役立つレベルに仕上げて売っているのはすごいと思います。尊敬します。

手元にあるアプリケーションのうち、CoreMLのモデルをアプリケーション内に格納してあるのは、Pixelmator ProとこのRetrobatchだけでした。

システム負荷の小さなAppleScript記法

Posted on 11月 12, 2020 by Takaaki Naganoya

主に、AppleScript Studioの時代に起こったことですが、巨大なプログラムを書いていると、原因不明の異常事態に直面することがよくありました（PowerPCの時代）。

Xcode上でAppleScriptで書いたプログラムのコンパイルが通らず、Xcodeがクラッシュ。１行追加しただけでクラッシュするほどで、その追加した内容に文法的な間違いはありません。AppleScript Studioには本当に煮え湯を飲まされました。

Mac OS X 10.5の時代に「ようやく安定したか、デバッグ機能は使えないけど」と思っていたら廃止されて、Mac OS X 10.6でAppleScriptObjCに入れ替え。できることが増えたのであまり文句は言いませんでしたが、今度はドキュメントやサンプルが１つもない状況。自分がGUIアプリケーションをXcode上で書いて、Mac App Storeにアプリケーションを出せる（審査でいちゃもんがついてもかわすことができる）のも、Shane Stanleyをはじめとする先人の積み重ねがあったからこそです。

AppleScript Studioの時代に原因不明のトラブルのすえプロジェクトが瓦解した苦い経験をもとに、AppleScriptの処理系に負荷をかけない（たぶん）プログラミングを心がけるようになりました。

１行に記述する構文要素を最低限に

１行に多くの内容を詰め込むと、クラッシュやコンパイルエラーなどの原因になりやすいと感じています。本Blogに掲載しているプログラムは、１行に複数の処理を詰め込むことを極力避けています。可読性を高めるためにこう書いている、という側面もありますが……本来の目的は構文解析時のシステム負荷を最小限に抑えることにあります。

逆に、システム負荷の小さい書き方をしないと、巨大なAppleScriptのプログラムは開発途中でクラッシュを頻発する可能性があります。

構文解釈上、問題のある文字を使わない

行を書き分けする継続記号（Continuation Mark）が入っていると、行数が増えたときに謎のコンパイルエラーが発生するケースがあります。とくに、プログラムの行数が少ない場合にはエラーにならないのに、行数が増えるとエラーを引き起こします（何度も経験しました）。自分のプログラムに極力、継続記号（Continuation Mark）が入っていない理由はこれです。不等号もやや怪しいので、問題が出たら大小比較の不等号は英単語に展開しています。

if文などのネスティングの段数を減らす

つい、if文の条件を何段もネスティングして表記することがありますが、これをやると大規模なプログラムを記述したときに原因不明のクラッシュを引き起こします。

１ファイルに記述する行数を減らす

このあたりから普通のプログラミング言語っぽい話になりますが、１本で1万行といった巨大なAppleScriptを書かず、複数のScriptに分けて構文確認を通せるようにしています。目安は1,000行ぐらいなんですが、GUIをつけたプログラムだとイベントハンドラ処理部分とかGUI部品とバインディングしているプロパティ宣言部分などを外せないので、ついつい巨大になってしまいがちです。

ほかにも、言語処理系的にマイナーな仕様の表現を書かないとか（as anythingあたり）いったところでしょうか。

そうした書き方をフィードバックしてあるのが本Blog掲載のプログラムリストです。日本語環境で動作確認してあるので、中国語や韓国語の環境でも問題を引き起こす危険性が低くなっています。当然、英語などの言語圏で問題が出る可能性はさらに低いものとなります。

linked listとvector

Posted on 7月 5, 2020 by Takaaki Naganoya

今日その存在を初めて知りました。linked listとvector。2020年になって知らない予約語があったとは、目が覚めるような思いです。

AppleScriptの隠れ予約語なんだとか。たまにこういう「隠れ仕様」が転がっていて息が止まりそうになります。

set x to {{{1, 2, 3}}} as linked list
--> {1,2,3}

リストの一種らしいのですが、Language Guideにも掲載されていないので、正直よくわかりません。

不用意に多次元化してしまったlistを最低限の次元に落としてくれるようです（linked list）。

かといって、有効活用したいとかいうことは考えないほうがいいようです（Apple側でも検証していないでしょうね、いろんなランタイム環境での実行内容とか）。

set x to {{{1, 2, 3}}} as linked list
--> {1,2,3}

set a to length of x
--> 3

set b to class of x
--> list

--set the end of x to 4
--> error "end of {1, 2, 3}を4に設定できません。" number -10006 from last insertion point of {1, 2, 3}

--set beginning of x to 0
--> error "beginning of {1, 2, 3}を0に設定できません。" number -10006 from insertion point 1 of {1, 2, 3}

set x to x & 6
--> {1, 2, 3, 6}

vectorもlinked list同様な感じではあるものの、要素をbeginningとendに追加できるようで。

set aVec to {{{1, 2, 3}}} as vector
set aLen to length of aVec
--> 1

set aClass to class of aVec
--> list

set the beginning of aVec to 0
--> {0, {{1, 2, 3}}}

set the end of aVec to 9
--> {0, {{1, 2, 3}}, 9}

不定クラスの予約語「anything」もその筋での評判がよろしくありません。macOS 10.14以降のスクリプトエディタでようやく誤解釈されなくなりましたが、それまではASObjC環境で「list of string or string」と解釈されてしまっていました。一方でScript Debugger上では「any」と解釈され、足並みが揃っていません。

明確に予約語がないにもかかわらず、機能が実装されているのが「as «class utf8»」。機能がないと致命的に問題が出るので、なくなることはないと思います。

edama2さんと本件について雑談していたら、「見かけたことがある」とのことで、その場で調べてみたら見つかりました。

http://mtlab.ecn.fpu.ac.jp/WSM_1999/990521193527.html

Sandbox環境で封じられる処理

Posted on 4月 22, 2020 by Takaaki Naganoya

ふだん、AppleScriptの処理はOSによる制約の少ない環境で処理を行っています。サンドボックスによる制約がない、あるいはきわめて少ない環境であるといえます。

そうした自由な環境に慣れていると、Sandbox環境下で（Xcode上で）アプリケーションを作成したときに、あっと驚く制約が存在していて驚かされることが多々あります。

他のアプリケーションを操作するScriptは書き込み禁止に

Sandbox環境下では、他のアプリケーションを操作するAppleScriptについては、実行専用形式で保存したうえでファイル書き込み不可の状態にしておく必要があります。Scriptのプロパティ（resultもプロパティ）を書き換えられてはいけないので、この措置が必要になります。Sandbox環境ではこのプロパティの書き換えが、自己書き換えと判定され、禁則事項に該当してしまうためです。

ファイルの新規保存時のchoose file nameコマンド（＋拡張子追加）が抵触

ファイルの新規保存時にchoose file nameコマンドで保存先のパス＋ファイル名をユーザーに指定させるような処理を行っています。このときに、ファイルの拡張子が指定されていない場合には、choose file nameから返ってきたパスを文字列に変換して、拡張子を文字列で追加するような処理もよく行っています。

これが、Sandbox環境下では禁じ手になります。

最初に遭遇したときには「意味がわからない！」と、イラつきまくりましたが、落ち着いて考えつつ追試を行ってみたところ理解できました。

Sandbox化したアプリケーションでファイル保存を行うためには、Xcode上でentitlementsファイルを編集し、「com.apple.security.files.user-selected.read-write」といったエントリに「YES」を設定しておくことになります。ユーザーが選択したファイルの読み書きを許可するという設定です。

このとき、choose file nameコマンドで入力されなかった拡張子の部分をAppleScript側で勝手に補ってしまうと、「ユーザーが指定したファイル」以外のファイルを処理することになるわけで、（拡張子を文字列操作で補ったようなパスは）ファイル保存することができませんでした。

そこで、NSSavePanelを用いてファイル保存ダイアログを作成する必要に迫られます。事前に補うべき拡張子の情報を渡してダイアログ表示を行うので、ユーザーが拡張子まで入力しなくても、拡張子がついたファイルパスが返ってきます。

ほかにもいろいろありますが、作成するAppleScriptのプログラム全体の数から見ると、Sandbox環境下で動かすAppleScriptはごく一部であるため、あまりノウハウが蓄積されていません。たまーにSandboxの制約に抵触して驚かされるといったところでしょうか。

プログラムで作ったアラートダイアログ上のTextViewをフォーカスする

Posted on 4月 14, 2020 by Takaaki Naganoya

AppleScriptでダイナミックに（動的に）生成したアラートダイアログ上にテキストビューを生成し、そのテキストビュー上にテキスト入力用のキャレットを移動させる（フォーカスする）AppleScriptです。

Xcode上でAppleScriptでGUIアプリケーションを作っていて、文字サイズの大きなテキスト入力フィールドを動的に生成。さらに、テキスト入力フィールドにテキスト入力用のキャレットを移動させようとして、割と手こずっていました。

テキスト入力を受け付けるGUI部品に対して、入力フォーカスを与え、テキスト入力のキャレットが置かれた状態を再現するには、GUIの画面上からはマウスカーソルでクリック操作するとできます。同じ状態をプログラム側から作る場合にはFirstResponderにセットするという処理になります。

この、FirstResponderに指定することは理解でき、Xcode（Interface Builder）上で配置した部品に対して実行する処理は昔からやっています。NSTextFieldに強制的に入力フォーカスを置いた上でバーコードリーダーからのテキスト入力を受け付けるといった処理です。

一方、プログラムから動的に生成したGUI部品に対して、Cocoaが用意しているAPIのどれを用いて、どのように指定すべきなのかで困りました。

親WindowのFirstResponderにしてみたり、アラートウィンドウのFirstResponderにしてみたり、いろいろ試した末に、

parentWin's setInitialFirstResponder:aView

で、Alert DialogのWindowをparentWinに、alert dialog上のテキストビューをaViewに代入した状態で実行して、入力キャレットをテキストビュー上に移動できました。本Xcode Projectは上記の１行の記述の検証を行うためのテストプロジェクトです。

–> Download Xcode Project

AppleScript名：AppDelegate.applescript

—
— AppDelegate.applescript
— dialogCarret
—
— Created by Takaaki Naganoya on 2020/04/14.
— Copyright © 2020 Takaaki Naganoya. All rights reserved.
—

script AppDelegate
　　property parent : class "NSObject"
　　
　　property |NSURL| : a reference to current application’s |NSURL|
　　property NSFont : a reference to current application’s NSFont
　　property NSView : a reference to current application’s NSView
　　property NSAlert : a reference to current application’s NSAlert
　　property NSColor : a reference to current application’s NSColor
　　property NSTextView : a reference to current application’s NSTextView
　　property NSScrollView : a reference to current application’s NSScrollView
　　property NSRunningApplication : a reference to current application’s NSRunningApplication
　　
　　— IBOutlets
　　property theWindow : missing value
　　
　　property returnCode : 0
　　property resStr : ""
　　
　　
　　on applicationWillFinishLaunching:aNotification
　　　　—
　　end applicationWillFinishLaunching:
　　
　　on applicationShouldTerminate:sender
　　　　return current application’s NSTerminateNow
　　end applicationShouldTerminate:
　　
　　on clicked:sender
　　　　set tmpStr to "TEST"
　　　　set paramObj to {myMessage:"Input Text", mySubMessage:"", mes1:(tmpStr), mesWidth:400, mesHeight:200}
　　　　my performSelectorOnMainThread:"dispTextViewWithAlertdialog:" withObject:paramObj waitUntilDone:true
　　　　set aResText to (my resStr) as string
　　　　
　　　　display dialog aResText
　　end clicked:
　　
　　on dispTextViewWithAlertdialog:paramObj
　　　　–Receive Parameters
　　　　set aMainMes to (myMessage of paramObj) as string –Main Message
　　　　set aSubMes to (mySubMessage of paramObj) as string –Sub Message
　　　　set mesStr to (mes1 of paramObj) as string –Text Input field 1 Label
　　　　set aWidth to (mesWidth of paramObj) as integer –TextView width
　　　　set aHeight to (mesHeight of paramObj) as integer –TextView height
　　　　
　　　　set vNum to system attribute "sys2"
　　　　if vNum > 13 then
　　　　　　set apRes to retLightOrDark() of me
　　　　　　if apRes = true then
　　　　　　　　set textColor to (current application’s NSColor’s cyanColor())
　　　　　　else
　　　　　　　　set textColor to (current application’s NSColor’s blackColor())
　　　　　　end if
　　　　else
　　　　　　set textColor to (current application’s NSColor’s blackColor())
　　　　end if
　　　　
　　　　
　　　　— Create a TextView with Scroll View
　　　　set aScroll to NSScrollView’s alloc()’s initWithFrame:(current application’s NSMakeRect(0, 0, aWidth, aHeight))
　　　　set aView to NSTextView’s alloc()’s initWithFrame:(current application’s NSMakeRect(0, 0, aWidth, aHeight))
　　　　aView’s setDelegate:me
　　　　aView’s setRichText:true
　　　　aView’s useAllLigatures:true
　　　　aView’s setTextColor:textColor
　　　　aView’s setFont:(current application’s NSFont’s systemFontOfSize:90.0)
　　　　set aColor to current application’s NSColor’s colorWithDeviceRed:0.0 green:0.0 blue:0.0 alpha:0.1
　　　　
　　　　aView’s setBackgroundColor:aColor
　　　　aView’s setString:mesStr
　　　　aScroll’s setDocumentView:aView
　　　　aView’s enclosingScrollView()’s setHasVerticalScroller:true
　　　　
　　　　— set up alert
　　　　set theAlert to NSAlert’s alloc()’s init()
　　　　tell theAlert
　　　　　　its setMessageText:aMainMes
　　　　　　its setInformativeText:aSubMes
　　　　　　its addButtonWithTitle:"OK"
　　　　　　–its addButtonWithTitle:"Cancel"
　　　　　　its setAccessoryView:aScroll
　　　　　　set parentWin to its |window|()
　　　　end tell
　　　　
　　　　parentWin’s setAlphaValue:0.8
　　　　–parentWin’s setOpaque:(false)
　　　　parentWin’s setLevel:(current application’s NSScreenSaverWindowLevel)
　　　　
　　　　parentWin’s setInitialFirstResponder:aView —Place Input Carret to Alert Dialog
　　　　
　　　　— show alert in modal loop
　　　　NSRunningApplication’s currentApplication()’s activateWithOptions:0
　　　　my performSelectorOnMainThread:"doModal:" withObject:(theAlert) waitUntilDone:true
　　　　
　　　　if (my returnCode as number) = 1001 then
　　　　　　—
　　　　else
　　　　　　set my resStr to aView’s |string|()
　　　　end if
　　end dispTextViewWithAlertdialog:
　　
　　
　　on doModal:aParam
　　　　set (my returnCode) to aParam’s runModal()
　　end doModal:
　　
　　
　　on retLightOrDark()
　　　　return true
　　end retLightOrDark
　　
end script

★Click Here to Open This Script　

マウス充電用AppleScript

Posted on 3月 6, 2020 by Takaaki Naganoya

本Scriptはいつも書き捨てにするAppleScriptですが、使用頻度はそれなりに高いものです。

AppleのMagic Mouse 2を充電するには、裏返してLightningケーブルを挿す必要があります。

STEP1：コンピュータをスリープさせる
STEP2：マウスを裏返す
STEP3：ケーブルを挿して充電する

という手順になるわけですが、、、マウスを裏返した時点でボタンが押されたりして、充電できないケースが多々あります。

そこで、本Scriptをスクリプトエディタ上で実行して、10秒以内にマウスに充電ケーブルを挿すと、あとからコンピュータがスリープ。問題なくマウスを充電できます。

AppleScript名：マウス充電用Script

delay 10

tell application "System Events" to sleep

★Click Here to Open This Script　

FileMaker v18でAppleScriptを使えるように設定

Posted on 3月 6, 2020 by Takaaki Naganoya

Classic MacOS時代はJeditとFileMaker Proがないと機能がなさすぎて即死でしたが、現在はAppleScriptのソリューションを成立させるのにFileMakerが必須ということもなくなりました。本Blog掲載のサンプルを見ていただければ分かるように、データのソーティングも抽出も、AppleScriptだけで相当なことがこなせます。

AppleScript単体でもCocoaの機能を利用することで、数万〜数十万件レベルのデータ件数であれば、別にFileMakerデータベースを併用する必要もなくなってきました。

ただ、かといってFileMakerの魅力が減ったわけではありません。とくに、小規模なチームで短期間で業務支援システムを組み立てる必要がある場合など、FileMakerの手軽さは圧倒的です（個人事業者ならなおのことです）。さらに、各種データソースからデータを自動で取り込んで蓄積する部品として、FileMakerが使えることは大きな力になります。

FileMakerは昔とはやや位置付けが変わりましたが、それでも大きな価値を持っています。

FileMakerのデータベースがAppleScriptから使えるようになるまで

実際にFileMaker v18のお試し版（FileMaker Advanced）をダウンロードして、AppleScriptを利用できるように設定を行ってみました。

デフォルトで、FileMakerのアプリケーションにnameやversionなどを問い合わせすることは可能ですが、データベースへのアクセスは行えません。FileMakerのアプリケーション本体にAppleScript制御受付の設定があるわけではなく、データベース書類に対してユーザー権限とDB書類オープン時のユーザー設定などを行うことで、AppleScriptからアクセスできるようになります。

データベースに対して権限設定を行うので、まずは対象となるデータベースをオープンしておく必要があります。そのうえで、「ファイル」＞「管理」＞「セキュリティ」を実行。

新規アカウント「AS User」（なんでもいい）を作成し、

この新規作成したアカウント「AS User」の権限を新規に定義します（新規アクセス権セット）。

拡張アクセス件で、必要な権限を設定した上で「Apple EventおよびActiveXによるFileMaker操作の実行を許可（fmextscriptacess）」にチェックを入れておきます。

ユーザーおよびユーザー権限を設定した上で、データベース書類に対して、この新規作成したアカウント「AS User」でオープンするように設定を行います。「ファイル」＞「ファイルオプション…」を実行して、

「ファイルオプション」ダイアログ中の「開く」タブで、「次のアカウントを使用してログイン」の欄にユーザー名「AS User」と設定したパスワードを設定して「OK」ボタンをクリック。

これで、いったんデータベース書類をクローズして再度オープンし直すと、ユーザー名「AS User」でオープンした状態になり、AppleScriptからの操作を受け付けるようになります。

昔のFileMakerではpropertyを求めることでファイルメーカーDBのスキーマ定義やレイアウト一覧などが、パスワードを設定してある状態ですらすべて取得できていましたが（いろいろリバースエンジニアリングしました）、現在のFileMakerではproperty属性によるアクセスが行えないので、そこまでガバガバではないようです。

RoundWindow v2

Posted on 1月 12, 2020 by Takaaki Naganoya

Edama2さんと「無理だよねー」「そうそう、絶対無理〜」などとメールで言っていたら、Shane Stanleyから届いた「できるよ」という衝撃のメール。

スクリプトエディタ上で記述する通常のAppleScriptで、CocoaのCustom Class宣言と呼び出しができるとのこと。

自分で動作確認してみるまで、半信半疑でしたが、、、、できますねこれは、、、

–> Download Editable and Executable Script Bundle

冗談半分で思いついたことを試してみたらできてしまったり、冗談半分でできるわけないよねと念のために書いておいたことが世界の誰かの目に止まったりと、「冗談半分」ってけっこう重要なことだと思えてきました。

以下、Shane Stanleyの説明による、その書き換え手順です。

（１）Subclassファイル（複数可）をXcode上のプロジェクトで書くようなスタイルで書く

こういう（↑）スタイルですね。かならずscript宣言しつつ、parent属性を宣言しておくところがXcode上のAppleScriptアプリケーションのスタイルです。あとで動作確認して、アプリケーションの起動や終了に関するイベントハンドラを書いておいたのは無駄（実行されない）ではないかとも思われました。

（２）実行するメインのScriptのResourcesフォルダ内にSubclassファイルを入れる

普通、AppleScriptのファイルが入る/Contents/Resources/Scripts/でも、ライブラリを入れておく/Contents/Resources/Script Libraries/でもなく、/Contents/Resources/の直下に入れます。ファイル名はオリジナルのEdama2さんのものをそのまま採用していますが、割となんでもいいようです。Custom Classファイルは分割してもいいし、このサンプルのようにまとめてもいいんでしょう。

＃　追加実験してみたところ、Resourcesフォルダ以下の/Scriptsや/Script Libraries/フォルダと重複しない名称の別フォルダ（例：/Classes/）に入れておいても大丈夫でした

（３）use framework “AppleScriptObjC”の宣言文を追加

見たことのない光景ですが、書くことについてはとくに障害はありません。AppKit.Frameworkもuse宣言しておいたほうがよかったかもしれません。

（４）メインスクリプトの実行時に以下の処理を実行

set theBundle to current application’s NSBundle’s bundleWithPath:pathToFolderWithScripts
theBundle’s loadAppleScriptObjectiveCScripts()

★Click Here to Open This Script　

試行錯誤して、上記の「pathToFolderWithScripts」にバンドル内の/Contents/Resources/を入れて実行すればよいことが理解できました。

以上の変更を加えて、ためしにスクリプトエディタ＆Script Debugger上で実行してみたところ、改変前と変わりなく実行できてしまいました（冒頭のスクリーンショット）。

いや、これはめちゃくちゃすごいですよ！！　何がすごいって、CocoaのCustom Classをスクリプトライブラリ中に入れて呼び出せるということで、けっこう無茶な箱庭インタフェースが作れてしまう予感が、、、、。

そして、AppleScriptObjC（AppleScriptObjC.frameworkより）でスクリプトエディタの「.scpt」形式のファイルを読み込んで実行できてしまったということは、Xcode上のAppleScriptアプリケーション内のScriptもテキスト形式だけでなく、スクリプトエディタで編集できる.scpt形式のファイルを突っ込んで編集できる可能性が見えてきました。

ただ、テキスト形式になっていないと、Interface Builderとの連携のあたりで問題になりそうな気もします。

AppleScript名：customClassTest.scptd

—
–　　Created by: Edama2 2020/01/10
–　　Adviced by: Shane Stanley 2020/01/11
–　　Modified by: Takaaki Naganoya 2020/01/12
—
use AppleScript version "2.4" — Yosemite (10.10) or later
use framework "Foundation"
use framework "AppleScriptObjC"
use scripting additions

property _clock_text_view : missing value –> 時計用の文字列
property _clock_timer : missing value –> 時計用のNSTimer

–Script Bundle内のResourcesフォルダを求める
set resourcePath to POSIX path of (path to me) & "Contents/Resources/"
set theBundle to current application’s NSBundle’s bundleWithPath:resourcePath
theBundle’s loadAppleScriptObjectiveCScripts()

my performSelectorOnMainThread:"raizeWindow:" withObject:(missing value) waitUntilDone:true

# ウィンドウを作成
on raizeWindow:aParam
　　
　　# 時計用の文字を作成
　　tell current application’s NSTextView’s alloc()
　　　　tell initWithFrame_(current application’s NSMakeRect(35, 120, 300, 40))
　　　　　　setRichText_(true)
　　　　　　useAllLigatures_(true)
　　　　　　setTextColor_(current application’s NSColor’s whiteColor())
　　　　　　setFont_(current application’s NSFont’s fontWithName:"Arial-Black" |size|:48)
　　　　　　setBackgroundColor_(current application’s NSColor’s colorWithDeviceRed:0.0 green:0.0 blue:0.0 alpha:0.0)
　　　　　　setAlphaValue_(1.0)
　　　　　　setEditable_(false)
　　　　　　–setString_("00:00:00")
　　　　　　
　　　　　　set my _clock_text_view to it
　　　　end tell
　　end tell
　　
　　# 時計を更新するNSTimerを作成
　　set my _clock_timer to current application’s NSTimer’s scheduledTimerWithTimeInterval:1 target:me selector:"idleHandler:" userInfo:(missing value) repeats:true
　　
　　# 丸いViewを作成
　　set aFrame to current application’s NSMakeRect(0, 0, 300, 300)
　　tell current application’s RoundView’s alloc()
　　　　tell initWithFrame_(aFrame)
　　　　　　setNeedsDisplay_(true)
　　　　　　setSubviews_({my _clock_text_view})
　　　　　　set customView to it
　　　　end tell
　　end tell
　　
　　#スクリーンのサイズを調べる
　　set aScreen to current application’s NSScreen’s mainScreen()
　　
　　# Window
　　set aBacking to current application’s NSWindowStyleMaskBorderless
　　–set aBacking to current application’s NSBorderlessWindowMask
　　set aDefer to current application’s NSBackingStoreBuffered
　　
　　tell current application’s CustomWindow’s alloc()
　　　　tell initWithContentRect_styleMask_backing_defer_screen_(aFrame, aBacking, aDefer, false, aScreen)
　　　　　　–setTitle_(uniqueName) –>タイトル
　　　　　　setBackgroundColor_(current application’s NSColor’s clearColor()) — Grammar Police –>背景色
　　　　　　setContentView_(customView) –>内容ビューのセット
　　　　　　setDelegate_(me) –>デリゲート
　　　　　　setDisplaysWhenScreenProfileChanges_(true) –>スクリーンプロファイルが変更されたときウインドウの内容をアップデートするか
　　　　　　setHasShadow_(true) –>ウインドウに影があるか
　　　　　　setIgnoresMouseEvents_(false) –>マウスイベントを無視するか
　　　　　　–setLevel_((current application’s NSScreenSaverWindowLevel) + 1) –>ウインドウの前後関係の位置
　　　　　　setOpaque_(false) –>ウインドウを不透明にするか
　　　　　　setReleasedWhenClosed_(true) –>閉じたときにメモリを解放するか
　　　　　　
　　　　　　#
　　　　　　|center|()
　　　　　　makeKeyAndOrderFront_(me) –>キーウインドウにして前面に持ってくる
　　　　　　–setFrame_display_(aFrame, true) –>表示
　　　　end tell
　　end tell
end raizeWindow:

#タイマー割り込み
on idleHandler:aSender
　　set mesStr to time string of (current date)
　　(my _clock_text_view)’s setString:mesStr
end idleHandler:

★Click Here to Open This Script　

AppleScript名：CocoaAppletAppDelegate.scpt

script CocoaAppletAppDelegate
　　property parent : class "NSObject"
　　
　　on applicationWillFinishLaunching:aNotification
　　　　—
　　end applicationWillFinishLaunching:
　　
　　
　　on applicationShouldTerminate:sender
　　　　return current application’s NSTerminateNow
　　end applicationShouldTerminate:
　　
end script

script CustomWindow
　　property parent : class "NSWindow"
　　property canBecomeKeyWindow : true
　　
　　property _initial_location : missing value
　　
　　on mouseDown:theEvent
　　　　set my _initial_location to theEvent’s locationInWindow()
　　end mouseDown:
　　
　　on mouseDragged:theEvent
　　　　–set res to display dialog "mouseDragged" buttons {"OK"} default button "OK"
　　　　try
　　　　　　set screenVisibleFrame to current application’s NSScreen’s mainScreen()’s visibleFrame()
　　　　　　set screenVisibleFrame to my myHandler(screenVisibleFrame)
　　　　　　set windowFrame to my frame()
　　　　　　set windowFrame to my myHandler(windowFrame)
　　　　　　set newOrigin to windowFrame’s origin
　　　　　　
　　　　　　set currentLocation to theEvent’s locationInWindow()
　　　　　　set newOrigin’s x to (newOrigin’s x) + ((currentLocation’s x) – (_initial_location’s x))
　　　　　　set newOrigin’s y to (newOrigin’s y) + ((currentLocation’s y) – (_initial_location’s y))
　　　　　　
　　　　　　set tmpY to ((newOrigin’s y) + (windowFrame’s |size|’s height))
　　　　　　set screenY to (screenVisibleFrame’s origin’s y) + (screenVisibleFrame’s |size|’s height)
　　　　　　if tmpY > screenY then
　　　　　　　　set newOrigin’s y to (screenVisibleFrame’s origin’s y) + ((screenVisibleFrame’s |size|’s height) – (windowFrame’s |size|’s height))
　　　　　　end if
　　　　　　
　　　　　　my setFrameOrigin:newOrigin
　　　　on error error_message number error_number
　　　　　　set error_text to "Error: " & error_number & ". " & error_message
　　　　　　display dialog error_text buttons {"OK"} default button 1
　　　　　　return error_text
　　　　end try
　　　　
　　end mouseDragged:
　　
　　on myHandler(aFrame)
　　　　if class of aFrame is list then
　　　　　　set {{theX, theY}, {theWidth, theHeight}} to aFrame
　　　　　　set aFrame to {origin:{x:theX, y:theY}, |size|:{width:theWidth, height:theHeight}}
　　　　　　–set aFrame to current application’s NSMakeRect(theX, theY, theWidth, theHeight)
　　　　end if
　　　　return aFrame
　　end myHandler
end script

script RoundView
　　property parent : class "NSView"
　　
　　on drawRect:rect
　　　　set aFrame to my frame()
　　　　set myColor to current application’s NSColor’s redColor()
　　　　
　　　　tell current application’s NSBezierPath
　　　　　　tell bezierPathWithOvalInRect_(aFrame)
　　　　　　　　myColor’s |set|()
　　　　　　　　fill()
　　　　　　end tell
　　　　end tell
　　end drawRect:
end script

★Click Here to Open This Script　

メインScript側で宣言したglobal変数値をサブ側で使用する

Posted on 7月 25, 2019 by Takaaki Naganoya

バンドル形式のAppleScriptでは、バンドル内にAppleScript Libraryを入れて、Library側の機能を呼び出すことができます。呼び出される方のサブ側のAppleScript Libraryでメイン側で宣言した変数値を参照する基礎的な内容のAppleScriptです。

–> Download mainTest.scptd

基礎は大事なので、ちょっと怪しいと思ったら必要な部分だけ組み立てて動作確認を行っています。

冒頭で（暗黙のrunハンドラの前で）global宣言を行えば、サブ側でも同じ値にアクセスできることを確認しました。一度、巨大なプログラムでやらかしたことがあって、global変数はあまり使わないように自粛していたのですが、必要とあらば仕方ありません。

▲メイン側のAppleScript。バンドル形式のAppleScriptで、この中にサブのAppleScript Libraryを入れて呼び出す

▲メイン側のAppleScriptのバンドル内に、「EverythingToTextKit.scptd」（リストやレコードなどのデータなどすべてテキスト化するライブラリ）と、「sub1.scptd」（サブ側のScript）を格納している

▲サブ側のAppleScript。ただ単にメイン側と共有しているグローバル変数「aProp」の内容をテキスト化してダイアログ表示

▲メイン側のAppleScriptを実行すると、サブ側のルーチンを呼び出して実行

iMac Proを試してみた

Posted on 7月 12, 2019 by Takaaki Naganoya

開発のために期間限定で手元にiMac Proが来ています。すぐに返却するので、じっくりした評価は行えませんが（評価目的ではないので）、ためしにAppleScriptによる大きめの処理を試してみました。

マシン１：MacBook Pro 2012 Retina Core i7 2.6GHz 4core RAM 8GB
マシン２：iMac Pro 2017 Xeon 3.2GHz 8 core RAM 32GB

（１）700箇所の位置情報から最寄りの駅検索

アーケードゲーム「戦場の絆」が導入されている2015年の時点の約700箇所の日本全国のゲームセンターについて、最寄りの鉄道駅（約8,000箇所）との距離を求め最短のものを最寄駅とし、それぞれ最寄駅までの距離が短い順にソートするという、GUIアプリケーションに依存しない処理です。CoreLocationの機能を用いて距離計算を行います。

もともと90分かかっていたところを隣接都道府県テーブルの導入により10分へ短縮、そしてデータの形式を見直すことで５分程度に処理短縮していたものですが、実験したバージョンでは詳細な分析のために扱う情報を増やしており、マシン１で７分程度かかります。

　マシン１：７分13秒
　マシン２：４分17秒

CPUの動作クロック1.2倍にもかかわらず演算時間6割ということで、Xeonの性能の高さが見て取れました。扱うデータも割と巨大ですが、メモリ容量の大きさにより良好な結果が得られていることが伺われます。

（２）指定のAppleScript書類のコメント部分のみ除去して返す

245行のAppleScript書類を構文書式設定をもとに解釈し、構文色分け情報をもとにコメント部分のみ除去する処理です。つい最近まで、テストデータに対して十数秒かかっていたのですが、「カラーキャッシュ」という機構により大幅な高速化を遂げてしまったものです。

　マシン１：1.55秒
　マシン２：1.07秒

こちらも、想定以上の速度を叩き出せています。

（３）指定の文字列の順列組み合わせ計算（Permutations）

{“G”, “C”, “T”, “A”} などの文字列リスト（配列）の順列組み合わせ総当たり計算（Permutations）を行うものです。Cocoaの機能を用いて、メモリ上で大量のデータを処理するため、演算性能以上にメモリアクセス速度や容量（要素数が増えると8GBだとつらいもよう）の制約が少ないことが効いてきそうです。

・８要素時
　マシン１：107.27秒
　マシン２：64.83秒

これは、素直に速いといえる感じです。

（４）実践的なデータ照合

Adobe Illustratorの書類からピックアップしたテキストフレームのデータと元のCSVデータの比較を行います。単なるテキスト比較とバカにしてはいけません。元CSVデータとの照合を行うために、ゆらぎ吸収用の外部データ（同一視する表記を列挙）の内容を反映して、考えられるありとあらゆるパターンでチェックを行います。

Illustratorからテキスト抽出する際には、グループ化されたアイテムはリストとして取り出し、照合時にこのグループ化されていたデータは順列組み合わせ（Permutations）計算により、元データとの照合を行います（6つのテキストフレームがグループ化されている場合には、6x5x4x3x2x1=720パターンと200項目程度のCSVデータ項目との照合を行うため、（１項目あたり）14万回ぐらい比較を行います。実際のAppleScriptによる処理に近い、たいへん実践的な処理内容です。

　マシン１：10.69秒
　マシン２：6.25秒

ちなみに、MacBook Pro （13-inch, 2017 Two Thunderbolt 3 Ports RAM 16GB。macOS 10.14.5）だと、10秒強程度かかります。2012年から5年後のマシンがこんなに遅い（速くなっていない）とは思ってもみませんでした（＾ー＾；；

最近では、照合するデータを文字の集合としてとらえ、どれだけ集合同士が近似しているかとか、照合データを形態素解析してさらに類似している単語に展開し、展開したデータ同士の類似度を計算するといった意味類似度ベース/確率計算ベースの照合も行っています。こうした処理にもCPUパワー、とくにシングルスレッドの処理の速さが必要です。

マシン強化はプログラムの高速化手段のひとつ

高価で高速なマシンを使うというのはひとつの解決策ですが、では実際に高価なマシンを使うとどの程度の速度向上を期待できるのか、というのはこれまで実測したことがありませんでした。iMac Proは（Mac Pro不在の）現時点では最高峰のマシンであり、現時点でこれより高速なMacは存在していません（より高速なCPUは市場に存在しているので、そこが悩ましい。たしかに自分で組みたくなる）。

＃　2019年のCore i9 5K iMacはiMac Proよりシングルスレッド性能で見ると上かも

ここにあげた処理は、CPUのシングルスレッドの演算能力に大きく依存するような処理であり、そのままではなかなか性能を上げにくいものでもあります。実際に調べてみると動作クロック比率以上の性能向上を見せており、感心させられました。

ただし、コストパフォーマンスの面からいえば20万円前後のマシンに対して（しかもノート）、50万円以上するデスクトップ機がこの程度ということで、

　「高いマシンを買ったからといって価格に見合った演算性能を得られるわけではない」

ということを再確認したにとどまりました（MacBook Pro Retina 2012優秀すぎ。2017年のMacBook Pro 13インチの安い方より高速だし）。より低価格なiMacと異なり、購入後にあとからメモリを増設できないとか（仕様）。2017年に登場して以来アップデートされていないとか。Mac Pro 2019（Cheese Grater）が出てくるまでの「つなぎ」なんでしょう。

もちろん、安定性と快適さ、静粛性はくらべものにならないほどiMac Proが「上」です。外部ディスプレイを３台接続したときにマシン１では放熱ファンが回りまくり、外部冷却ファンを回さないと速度低下するケースも見られるためです（CPUのグリス塗り直しが必要か？）。また、アプリケーションの起動もきわめて高速です。

とくに、1,000行を超えるような巨大なAppleScriptの編集中にはScript Debuggerの応答速度が極端に下がります（カーソル移動に秒単位でかかるとか）。iMac Pro使用時にはこの極端な速度低下を避けられたので、これだけでも効果がありました。

もしも、バッチ処理速度の向上だけを目的として新規マシンの導入を行うのであれば、Mac miniを数台導入して分散処理したほうが得策です。これだと、GUIベースのアプリケーションを操作するAppleScriptのプログラムを、ほぼ何も書き換えずとも良好な結果が得られます。Parallelsなどの仮想環境にゲストOSとしてmacOSをインストールし、これらの環境との間で分散処理してもよいでしょう（こちらはぜんぜん実験していませんけれども）。

また、処理内容がIllustratorやInDesignなどのGUIベースのアプリケーションを用いていない場合には、プログラムを書き換えて並列処理するよう変更してもよいでしょう。

腰をすえてじっくり使う機会があれば、iMac Proのような強力で多コアなデスクトップマシン上で並列処理によりどの程度処理時間を短縮できるのか試してみたいところです。

QuickTime Playerでオープン中の全ムービーを頭出しして同時再生

Posted on 6月 27, 2019 by Takaaki Naganoya

QuickTime Playerでオープン中のすべてのムービーを頭出し（再生位置を冒頭に移動）して、同時に再生を開始するAppleScriptです。

とくに工夫も何もない、「必要だから作った」というScript。複数の条件で行った操作を画面を録画してならべ、同時に再生を行わせるという用途で使いました。

頭出しとかいうのは、カセットテープ/ビデオテープ時代の名残りの表現ですが、、、、電子データで頭出しというのは、言うんだか言わないんだか、、、

AppleScript名：QuickTime Playerでオープン中の全ムービーを頭出しして同時再生

tell application "QuickTime Player"
　　activate
　　set dList to every document
　　
　　repeat with i in dList
　　　　tell i
　　　　　　set current time to 0
　　　　end tell
　　end repeat
　　
　　
　　tell every document to play
　　
end tell

★Click Here to Open This Script　

macOS 10.15 Beta Release Notesに将来のmacOSでPython、Ruby、Perlなどのランタイムが含まれなくなることを告知

Posted on 6月 6, 2019 by Takaaki Naganoya

https://developer.apple.com/documentation/macos_release_notes/macos_10_15_beta_release_notes

Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default.

なので、これらのツールを使って処理をしているプログラムは、インストーラーを走らせるとか、パッケージ内にこれらのツールのバイナリを同梱するといった対処が必要になるようです。

普通にhomebrewなどのパッケージマネージャで各種シェル系のプログラムをインストールすることが多いので、「わかっている人には影響はない」ものの、そういう事情がわかっていない人には影響が出そうなポリシー変更ではあります。

また、今後のmacOS環境にはこれらのツールがデフォルトではインストールされていないことを前提にAppleScriptを組む必要があるため、これらのツールを使う場合にはAppleScriptのバンドル内に入れて配布、基本的にdo shell scriptの使用を避けるといった対処が必要です（これら以外のCLIのコマンドも追加インストールにならないとは限りません）。

AppleのポリシーがGPLのポリシーと相入れないためにこうなった、と見る人も多いですが、セキュリティのレベルを上げるための言い訳ではないでしょうか。実際のところは分かりませんけれども。

ちなみに、osascript（つまりAppleScriptやJXA）、shell scriptなどのインタプリタ・コマンドは添付され続けるとのことです。

肝心のAppleScriptの処理系についてですが、Version 2.7で変更はありませんでした。ただ、バージョンが変わらないものの新たなバグが出ているので、macOS 10.13で失われまくった信頼を取り戻すためにも、バグを修正していただきたいものです（PDFkitまわりとか）。

「将来リリースされるmacOS」が指している具体的な内容が、正式リリース版のmacOS 10.15なのか、次のmacOS 10.16もしくはそれ以降のバージョンを指しているのかは不明です。

Keynoteで選択中の表を取得する

Posted on 5月 3, 2019 by Takaaki Naganoya

最前面に表示しているKeynote書類中の現在表示中のスライド（ページ）上の選択状態にある表オブジェクトへの参照を求めるAppleScriptです。

Keynote v9.0で、これまで実装されていなかった「selection」が実装されたものの、予約語として存在しているだけで機能アップはしていませんでした（Pages v8.0のついでにアップデート？）。

一方で、同様にselectionが実装されてこなかったにもかかわらず、普通に選択中の表オブジェクトへの参照を取得できているNumbersがあります（ちょっとトリッキーな書き方ですけれども）。

では、そのトリッキーな記述でKeynote上の選択状態にある表オブジェクトへの参照が取得できるのか？　という疑問を持って実際に試してみたらできました、というのが本Scriptです。Keynote v8.1＋macOS 10.12.6、Keynote v9.0.1＋macOS 10.13.6、Keynote v9.0.1＋macOS 10.14.4の組み合わせで動作確認しています。

実際に、表オブジェクトを選択して本Scriptを実行すると、表オブジェクトへの参照が得られます。

AppleScript名：Keynoteで選択中の表を取得する

tell application "Keynote"
　　tell front document
　　　　tell current slide
　　　　　　try
　　　　　　　　set theTable to first table whose class of selection range is range
　　　　　　on error
　　　　　　　　set tCount to count every table
　　　　　　　　if tCount = 0 then
　　　　　　　　　　error "現在のスライド中に選択状態になっている表オブジェクトが存在しません"
　　　　　　　　else
　　　　　　　　　　–選択セルがない場合はTable 1を全選択
　　　　　　　　　　set theTable to table 1
　　　　　　　　end if
　　　　　　end try
　　　　　　
　　　　　　tell theTable
　　　　　　　　set aList to value of every cell
　　　　　　　　–> {1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0, 10.0, 11.0, 12.0, 13.0, 14.0, 15.0, 16.0, 17.0, 18.0, 19.0, 20.0}
　　　　　　end tell
　　　　end tell
　　end tell
end tell

★Click Here to Open This Script　

Numbersの表を回転

Posted on 4月 18, 2019 by Takaaki Naganoya

Numbers書類上の現在のシートの指定の表を回転させるAppleScriptです。

画像のようにぐるぐる回すわけではなく、90度回転状態と通常状態を切り替えるようです。

▲初期状態

▲transpose１回実行

▲transpose２回実行

AppleScript名：Numbersの表を回転

tell application "Numbers"
　　tell front document
　　　　tell active sheet
　　　　　　tell table 1
　　　　　　　　transpose
　　　　　　end tell
　　　　end tell
　　end tell
end tell

★Click Here to Open This Script　

TerminalですべてのテーマのWindowを新規作成する

Posted on 4月 15, 2019 by Takaaki Naganoya

Terminal.appで実行環境に登録されているすべてのTerminalのテーマのWindowを新規オープンするAppleScriptです。

実行環境のTerminal.appに登録されている「プロファイル」をリストアップし、各プロファイル（AppleScript用語辞書的には「settings set」）で新規Windowを作成します。

本プログラムは、Terminal.appの機能確認のためのものであって、これ自体に意味はありません。

AppleScript名：TerminalですべてのテーマのWindowを新規作成する

— Created 2019-04-14 by Takaaki Naganoya
— 2019 Piyomaru Software

tell application "Terminal"
　　set nList to name of every settings set
　　
　　repeat with i in nList
　　　　set j to contents of i
　　　　changeSettingAndMakeNewWindow(j) of me
　　end repeat
end tell

on changeSettingAndMakeNewWindow(aTheme as string)
　　tell application "Terminal"
　　　　set tmpID to settings set aTheme
　　　　set default settings to tmpID
　　　　set startup settings to tmpID
　　　　
　　　　tell window 1
　　　　　　do script ""
　　　　　　activate
　　　　end tell
　　end tell
end changeSettingAndMakeNewWindow

★Click Here to Open This Script　

Blogアーカイブ本の作成時に利用するAppleScript

Posted on 4月 1, 2019 by Takaaki Naganoya

「AppleScriptの穴」Blogアーカイブ本の作成作業には、大量のAppleScriptが使用されています。編集や執筆といった地味で地道な作業には、自動化のテクノロジーを投下しないととてもやっていられません。

「生きた事例」としてそれらをどのように使っているかをご紹介します。

・指定フォルダ以下にあるMDとPagesをソートしてPDFに書き出して連結 v4（連続複数出力可能、末尾空白ページ削除）

MarkdownによるPDF書籍の作成時にはなくてはならないScriptです。指定フォルダ以下のMarkdownとPages書類をすべてSpotlightで取得し、順次デスクトップにPDFで書き出しを行い、それらを連結します。PDFは記事単位で生成され、明示的な空白ページ（１ページの空白書類）以外の連結時には最終ページが空白であるかのチェックを行い、空白時には削除したうえで連結します。

「連続複数出力可能」というのは、複数の書籍の順次出力をサポートしているという意味です。Book1こと「AppleScript最新リファレンス」とBook2こと「最新事情がわかるAppleScript 10大最新技術」を同時に作成したので（作成期間が実質１か月ちょっとでしぬかと思いました）、その時に両方とも同時に全記事のPDF出力を行えるよう開発。複数の書籍のフォルダを指定して順次出力を行います。さすがにこれはBlogに載せていません。

電子書籍の執筆中は執筆しながら体裁を確認し、出力用のツールScriptも開発して「筆者」「編集者」「デザイナー」「開発者」という１人で何役もこなして目が回っていましたが、ツール類は一度作れば作業効率を大幅に上げたまま別の仕事（Blogアーカイブ本、とか）に使用できるのでたいへんに役立っています。自分が「原稿を書くだけの人」だったら、バイトを雇ったりしないととてもやっていられません。

また、これにInDesignの書類やPDF原稿を含めるように機能追加してもいいわけで、非常に拡張しやすく、システム化のためのベースとして活用したいところです。

・Skimのcurrent page indexをNumbers上のセルに転送してカーソル移動

PDFのTOCのデータをNumbers書類上に作成するさいに使用しています。Skimで現在表示中のページ番号をNumbersの表中の選択中のセルに文字列で転送し、Numbers上のカーソルを下方向に１つ移動させます。いいかげんTOCのデータ作成も全自動化したいところですが、PDF上で確認しつつ半自動で作成しています。それでも、すべて手作業で行うよりははるかに労力を削減できています。

・Numbersの最前面の書類からデータを取り出して指定PDFのTOCを作成する v2.scptd

Numbers上に作成したTOC（PDFしおり）データから実際に指定のPDFに階層構造つきTOCを作成するAppleScriptです。「TOCなしの数百ページのPDFなんか読みたくない」「TOCつけろ」という読者の方のありがたいアドバイスにより実戦投入。いまのバージョンはNumbersの表中の選択中のセルからデータを取得しているので、選択しなくても大丈夫なように、、、、書き換えておきます。こうして、作業上問題が発生しそうな箇所はつねにアップデートしています。

・現在表示中のページをJPEG画像で書き出す

Skim用のAppleScriptです。販売サイトに掲載する表紙などの紹介画像を作成するさいに、Skimで表示中のPDFから表示中のページの内容をJPEG画像としてデスクトップに生成します。このあたりを自動化していないと、サンプルページの掲載だけでも相当手間がかかります。

・PDFから指定ページ以降を削除

販売物を掲載したあとに、「お試し版」PDFを作成する段階で使用します。指定PDFから指定ページ以降をすべて削除するものです。これでおおよそ削除しておいてから、Adobe Acrobatで編集してTOCのうちページが存在しないものを削除したり、こまかいページの削除を行なっています。

iWorkアプリケーションがアップデート。日本語の縦書きテキストに対応

Posted on 3月 29, 2019 by Takaaki Naganoya

Keynote、Pages、NumbersのいわゆるiWorkアプリケーションがそろってアップデートし、日本語、中国語、韓国語の縦書きテキストに対応しました。

	Keynote	Pages	Numbers
macOS 10.12	v8.1	v7.1	v5.1
macOS 10.13	v9.0	v8.0	v6.0
macOS 10.14	v9.0	v8.0	v6.0

この、macOS 10.14用のバージョンが今回の最新アップデートです。最新のiWorkアプリケーションは最新のmacOSが必要です（記事執筆時にはmacOS 10.13用のアップデータが出ていなかったのでこう書きました。現在は10.13/10.14で実行可能）。

iWorkアプリケーション、とくにPagesについては日本語の縦書きができないことに対してMac App Store上で膨大な批判コメントがついており、アップデートとともにこれらの批判をかわそうという意図のようです（かわすだけで、もう一歩進んだ使い方の提案などはしていないもよう）。

macOS 10.12で足踏みをしている多くのユーザー（10.13が地雷すぎてアップデートできなかったユーザー）にアップデートを思い切らせるだけのものがあるでしょうか？

AppleScript用語辞書にselectionが装備され、Pagesでは活用できる

例によってこれらのiWorkアプリケーションのAppleScript用語辞書を書き出して前バージョンと比較したところ、数少ないものの大きな変更が加わっていることがわかりました。それが「selection」の実装です。

「選択中のオブジェクトに対してScriptで操作を行う」

という処理がほぼできなかったiWorkアプリケーションにおいて、selectionが実装されたことの意味は大きいと思います。

ただし、本当にすべてのオブジェクトをselectionで取得できるのか、実際に検証するまでわかりません（それがAppleクオリティー）。

検証したところ、KeynoteとNumbersではほとんど機能アップしておらず、既存の「選択中のスライド」（current slide）「現在のドキュメント」（front document）という範囲でしかselectionが機能していないことが判明しました（Numbersで「選択中の表」をselectionから取得できないのはとても残念。別の方法（↓）はあるけど）。

tell application "Numbers"
　　tell front document
　　　　tell active sheet
　　　　　　set theTable to first table whose class of selection range is range
　　　　　　
　　　　　　tell theTable
　　　　　　　　try
　　　　　　　　　　set selList to value of every cell of selection range –選択範囲のデータを取得
　　　　　　　　on error
　　　　　　　　　　return "" –何も選択されてなかった場合
　　　　　　　　end try
　　　　　　end tell
　　　　　　
　　　　end tell
　　end tell
end tell

★Click Here to Open This Script　

唯一、Pagesではさまざまな選択中のオブジェクトにアクセスできるようになっており、常識的なエンジニアが担当していれば、じきに各アプリケーション間の機能の不整合を修正してくることでしょう。

今回のアップデートが、Pagesを中心に行われた（Pagesと共通の部品を使って、ついでにオマケでKeynoteとNumbersの機能アップが行われた）ことが伺い知れます。

Pages書類上のオブジェクトでも、状態によって参照できないケースも

まだ実装途上と思わせるものが、このあたりにあります。書類内のさまざまなオブジェクトによって、状態によってはselectionから（実際に選択していても）参照できないものがありました。とくに、Pages書類上の本文テキストをselectionから取得できないことについては、「テキストエディタ以下」「CotEditorの爪の垢でも煎じて飲ませてもらえ」ともいえるわけで、最大のがっかりポイントといえます。

	オブジェクト配置＝テキストと移動（デフォルト）	オブジェクト配置＝移動しない
本文中の文字	selectionから取得できない（エラーになる）	selectionから取得できない（エラーになる）
表（table）	selectionから取得できない（エラーになる）	取得できる
図形（shape）	取得できる	取得できる
グラフ（chart）	取得できる	取得できる
画像（image）	取得できる	取得できる
テキストオブジェクト（shape）	取得できる	取得できる
ムービー（movie）	取得できる	取得できる
ライン（line）	取得できる	取得できる

また、imageオブジェクトはファイルパスを「file」という属性ラベルで返してくることになっているのですが、この「file」が既存のAppleScriptの予約語とコンフリクトしており、属性値をまとめて取得しようとするとエラーになります。

imageオブジェクトからfile属性を単独で取得してもエラーになるため、Scripterからは解決方法がありません。ここは予約語を「image path」などのコンフリクトしない単語ないし連語に変更することで問題の回避を行なっていただきたいものです。

縦書き属性はAppleScriptから操作不能

現時点では、AppleScriptでアクセス可能な属性値に縦書きへの変更を行うためのものは用意されていません。縦書きのテキストオブジェクトを任意の場所に作成するといった処理は無理です。

しいていえば、あらかじめ縦書きのテキストアイテム（place holder）を含むテンプレート書類を用意しておき、テンプレートから作成した新規書類のplace holderにテキストを流し込むぐらいでしょうか。あと、GUI Scriptingで強引に操作すれば、縦書きのテキストアイテムを生成できないこともありません。

けっこうグッときました

最初、用語辞書の中に「selection」をみつけたときにはメイン環境をmacOS 10.12.6から10.14.4にアップデートしかけました。

ただ、詳細に検証して実態がわかると、アップデートを思いとどまりました。「selection」が利用できることの意義は大きいですが、Pagesの地の文（本文）の選択範囲が取得できないなど、何を目的として実装されたかが不明な仕上がりになっています。最終的には、本文テキストないしオブジェクト内部テキストの選択を取得するselectionと、各オブジェクトの選択を求めるselected itemの２つに分けるのがスマートなやり方だと思います（実装する方にしてみれば、泥臭い努力が必要なわけですが）。

Pagesのtableオブジェクトへのアクセスに「オブジェクト配置＝移動しない」への設定が要求されることについては、かなり根深い問題があるものと思われますが、もう２・３発ジャブが入っていたら（Keynote上のテキストオブジェクトとか、Numbers上の表オブジェクトをselectionからアクセスできたとか）macOS 10.14にアップデートしていたかもしれません。

US Apple主催のMailing Listの死活判定

Posted on 2月 14, 2019 by Takaaki Naganoya

自分は100個以上のApple MLを購読。さすがに政府公共機関向けと学校教育機関向けMLは追い出されましたが、入れるかぎりのMLに入っておいて、手元（Mail.app上）でAppleScriptのボットを走らせメールタイトルをもとに綿密なフォルダ分けを行なって、各ML上の頻出語句でフォルダ分けして情報を整理・活用しておりました。

そんな最中、2017年1月末に発生したML Serverのダウン。その後１か月もの間、US Appleにあらゆる方法でコンタクトして無視されるという経験を経て、US在住のMLメンバーが知り合いのApple社員に電話し、それでようやく復旧したことは記憶に新しいところです。

ここに、数日前に掲載した、list.apple.com上の「Lists hosted on this site」のML一覧の画像があります。25個のMailing Listが掲載されていることが確認できます（記事作成時点のカウント）。

しかし、自分の手元には、このリストに載っていないMLあてのメールが続々と到着。

「あれ？　list server上で加入フォームへのリンクが設置されていない、活動中のMailing Listがけっこうある？？」

と、気がついて、、、Numbers上に記載したメールアドレスを読み取ってテストメールを送信するAppleScriptを作成して、ジャンルごとにMailing Listにテストメールを送信してみました。

手で数えたところ、「Lists hosted on this site」のページからリンクされていないが、物理的に生きているMLが35もありました。内容によっては極端に流量が少なかったり、すでに廃止されて久しい技術のために論理的に生きていないMLなどもありますが、それでも30前後は普通に運用されているMLと言ってよいでしょう。

以下、自分の個人的なカテゴリ分けのもと、「紹介されていないが生きている」MLは名称を赤く塗っておきました。

個別のMLを正式に終了させる場合には、きちんとアナウンスしてほしいところです。

追記：SALT MLとSmartCard Users MLがテスト対象のリストからもれていましたが、いずれも健在のようです。