List)を作成し、シャッフルするAppleScriptです。Stanleyによる乱数シャッフルルーチンがあり、これにシーケンシャル値の作成部分を追加。最終的にはこのシャッフルした値をもとに文字列の入ったリストのシャッフルを行いました。結局、本ルーチンは不要だったので、そのままそっくり書き捨てになりました。途中まではCocoaの機能を用いて連番リストを作りかけていたのですが、自分の考えた範囲ではCocoaの機能を用いてメリットが生まれるような要素数(数万以上)のデータ処理を行う可能性が低そうだったので、連番生成はループで行っています。NaganoyaバンドルIDで指定したアプリケーションのResourcesフォルダ中の、指定ロケールのstringsファイルをすべて読み込んでkeyを取り出すAppleScriptです。アプリケーション内の指定のローカライズしたメッセージ(テキスト)の内容を取り出すことはできますが、そのためにはキーを知っておく必要があります。そのキーを取り出してローカライズされた文字列を取り出すため、キーを調査してみました。これをそのまま何かのツールなりScriptに使うというものではなく、いわゆる「下調べ」のためのScriptの部品です。ありもののルーチンを再利用しただけのプログラムでできていますが、ありものはありもので、数千本のAppleScriptのストックからそれを探し出してくるのも一苦労です。アプリケーションバンドル内のResourcesフォルダ以下の(各lprojフォルダ以下の)stringsファイルの中身はまんま(シリアライズした)NSDictionaryなので、そのままDictionaryに読み込んでallkey()などのメソッドを実行できます。昔のstringsファイルはテキストファイルだったような気がしますが、テキストファイルだとparseしないといけないんで、ビルド時にparseしておいてDictionaryの状態でファイルに書いておくのは正しいと思います。8あたりから、アプリケーションのローカライズのルールが変更になったようで、基本となる言語環境がBase.lprojになり、英語はen.lprojといった1ローカライズ言語という位置付けに変更になりました。NSLocalizedStringFromTableInBundleを使ってアクセスしようかとも思ったのですが、こちらはまだ目的を達成できていません。11上で実験的に作成したAppleScriptアプリケーションのバンドル構造(左)。ローカライズしていない状態だとEnglishではなくBase.lprojが作成される。右はKeynote.app/Contents/Resources/ja.lprojフォルダの内容。getLocalizationsFromBundleID–指定アプリケーションファイルの、指定Localeにおけるローカライズ言語リストを求める。Naganoya指定のテキストをAppleScriptとみなして構文確認して、指定の構文要素が入っていないかチェックするAppleScriptです。scriptすると、一応いろいろ保護機能はあるものの、セキュリティ的にリスクの高い操作になってしまいます。scriptコマンドで実行されてしまったらと思うとゾッとします。ためしに実行してみたら、実行権限がないので実行できないエラーになりましたそこで、文字列をいったんAppleScriptとして評価(構文確認)し、コマンドなどの危険と思われる構文要素が入っていないかどうかチェックするものです。これら、「コマンド」および「追加コマンド」といった構文要素が入っていたらtrueを返します。scriptしてよいかどうか判定できるようにするものです。repChar–リストに入れたレコードを、指定の属性ラベルの値で抽出。Naganoyaアイテム番号の入ったリスト(配列変数)をもとに、ヒットしなかった項目を返すというAppleScriptです。これは、なにがしかのデータとなにがしかの書類上に配置されたデータの照合を行って、存在が確認されなかったデータの一覧を作成するために作成したものです。存在確認といえば、たいていは「存在していたデータそのもの、あるいはデータのアイテム番号一覧」といったものを出力するようになっています。そこに、「存在が確認できなかったデータの一覧が欲しい」という要望が出てくることも、だいたいは普通の出来事です。この手の「言語化すると大したことはないが、実施に精神的な抵抗感をおぼえる処理」といいいますか、「後片付け的な処理」というのは、書くのが面倒で後回しになりがちなものでもあります。事実、実際に書いてみたら、、、既存のサブルーチンの組み合わせで作りましたが、1日たって見直してみると何が書いてあるのかよく思い出せないレベルです(既存のサブルーチンの組み合わせが過ぎて、意味がわかりにくいのかも)。NaganoyaNumbersの表のカラムを表現するアドレス文字列(26進数)と数値の間のエンコーダーおよびデコーダーのAppleScriptです。2004/2008で採用されたカラムアドレス形式に対処するためのScriptでした。Excel上のセルのアドレス(場所)を指し示す方法は、「R1C1」(行とカラムを数値指定)形式、あるいはAppleScriptの行オブジェクトとセルオブジェクトで指定する形式でした。そこへ新たに「A1」形式......画面上で表記されている行、カラムと親和性の高い形式が採用されることになりました。当初は相互変換のための関数なども用意されていなかったと記憶しています(間違っていたらご指摘ください)。そのため、Scripterが自力でこのA1形式に対応する必要が出てきました。そんな中、Excel書類にAppleScriptを埋め込んで実行するAppleScriptを開発。本ルーチンはそのScript開発のために作成したものです。2008でVBAの処理系が外されてMac上のVBA的なマクロ処理はAppleSctiptに一本化されるという話になっていたため(当時の話)、これを好機ととらえ、マイクロソフトのご担当にデモして、US本社で紹介していただくということになりました。その会議上でVBAの復活プランが発表され、自分の提案したプランは廃案に(まさか当時のREALbasicのコンパイラの開発者を引き抜いてきてVBAの処理系をスクラッチで書かせるとは思いませんでしたわー)。2011でVBAの処理系が復活。本ルーチンも割とHDDの肥やしとして絶賛在庫状態になっておりました。2011でVBAの処理系が復活したことを知らない方がいて、「VBAで動いているマクロをAppleScriptに移植してほしい」という問い合わせがあるのですが、「Excelの最新版を購入してください。VBAがありますよ」とお返事しています。最新のExcelが動く環境を購入する費用よりも安く仕事としてお受けすることは困難なので。そこから年月が流れ、AppleがNumbersをリリース。2004/2008と同じ形式になっているために、しまいこんでいたルーチンをふたたび引っ張り出してきた次第です。一応、条件つきで使えるものの、作りが古い(やっつけ仕事な)点が気になります。誰かがもっといいルーチンを作って使っているに違いありません。一応、本ルーチンでは1〜1351の範囲での動作を確認しています。改良したいところではあります。実用上は、Numbersでそこまで大きなデータは扱わない(はず)ので、問題はあまりないものと思われます。Naganoya指定のAppleScriptのテキストを構文確認して、構文的に「変数・プロパティ、サブルーチン名」部分に該当する部分のテキストを取得して、目的のテキストに差し替えるAppleScriptです。Debugger上の生産性を向上させるために書いたものです。Debuggerはいわゆる「デバッグ」段階では役に立ちますが、快適にScriptを書くための機能はほとんどありません。いわゆる、ブレークポイントの設定、プログラムのステップ実行、ステップ実行時の変数値のリアルタイムモニタリング、という「デバッガ」の機能は持っていますが、巨大なScriptを書いたときの特定のサブルーチンを前回実行時に指定したパラメータで再実行して結果を比較といった機能は備えていません(切実にほしー。自分で作りたいぐらい)。記述中のAppleScriptの選択部分の構文要素を検出して特定の構文要素(コメントとか変数名とか)についてのみ処理を行うような機能が用意されていない点が残念です(スクリプトエディタ用は数百本書いて使っているので)。プロパティ文の記述などは毎回同じようなものをコピペで足すだけなので、書き足すのがかったるいと思っていました。そこで、編集中のAppleScriptの範囲から構文要素を考慮して変数名だけ書き換えてくれるといった機能を足してみました。{}実際にメモリ上でコンパイル(構文確認)して、書式付きテキストを取得し、そこから構文色分け設定に基づいて該当する構文要素をピックアップ。該当する構文要素の箇所を置換します。値が近すぎると)エラーになります。先日報告された「RGB以外の色空間の色」で設定してある場合でもRGB色空間に色データを変換して処理しています(まさかCMYKとかグレースケールで色設定しているユーザーがいるとは思わなかったわー)。Debugger上での動作を確認していますが、Applet書き出ししたときにまだ謎なメッセージを出すようです。何か、明示的にメインスレッドで実行する必要のあるものがあったでしょうか。Naganoyaリモート操作ソフト「TeamViewer」の画面から、ユーザーIDとパスワードを取得するAppleScriptです。Scriptingの機能を使って、画面上から情報を取得し、正規表現で抽出してみました。TeamViewerで実家のMacなど、離れた場所にあるマシンをメンテナンスする必要がある場合に、実家から電話がかかってきて、TeamViewerのパスワードとIDを口頭で教えてもらって接続する必要があるわけですが、親が高齢のためそれが心もとなくなりつつある昨今、確実に確認するために作成したものです。その場で、(自分のために)「TeamViewerを起動してIDとパスを確認して自分あてにメールで送ってくるAppleScript」を作りかけたのですが、途中からビデオ編集の仕方を教えろなどと言われて説明する羽目に。Naganoya指定のAppleScript書類のソースコードを取得し、構文色分け情報をもとにコメント部分の文字列のみを取得するAppleScriptです。Assistant」に入っています)。Cocoaの機能を利用して処理すると、スクリプトエディタを操作せずにAppleScript書類から情報を取得できます。GUIアプリケーションを操作しないぶん、並列処理にも有利です。本Scriptを実行すると、指定のAppleScript書類をバックグラウンドでオープンして、書式情報を取得し、コメントに該当する箇所の文字のみを取得して返します。library)ほんの少し修正することで、ソースコードからコメント部分のみを削除したテキストを取得することも可能です。NaganoyamacOS標準搭載のスクリプトエディタで定義している、AppleScriptの構文要素ごとの色分け情報。これを設定ファイルから取り出してレコード型データ(を入れた配列)に変換するAppleScriptの、カラースペースを考慮したデータの取り出しを行う改修版です。AppleScriptの構文色分け情報は、ユーザーごとに異なります。自分の好きなように変えてね、というメッセージだと受け止めました)(2)重複した色が設定されている構文要素がたくさんある(構文要素ごとの見分けがしにくいので、デフォルトのままだと無意味。ほら変更したくなったでしょ、というメッセージだと受け止めました)ということから、AppleScript入門初日に設定色を変更。何度か細かい変更を行いつつも、今日までだいたい同じ感じの設定を使い続けています。他のScripterがどのような配色にしているかはあまり知りません。Scripterごとに違うんだろうな、ぐらいの感じです。ところが、蓋を開けてみたらこの構文色分け設定に「RGB以外の色」が設定できることが判明。長い間、この処理系使い続けてきましたけれど、昨日はじめて知りました。具体的に言えば、RGB以外の「CMYK色」と「グレースケール色」の2つを設定可能なことが判明。CMYK色は、何度かアクセスしているうちに勝手にRGB色に置き換わってしまうようですが、グレースケールで指定した色はそのまま色種別がグレースケールのまま保持される(RGBに変換されたりしない)ようです。そのため、NSColorからredValue()などのメソッドで数値を取り出そうとするとエラーになる事例が発生したのでした。そこで、RGBの各チャンネルの値を取り出す前にNSColorの色空間(グレースケール色空間というのはないので、種別ぐらい?)をチェックし、RGB以外であれば変換処理を行うようにしてみました。この色空間(色モデル)の確認にNSColorのcolorSpaceNameというメソッドを使っている点に注意が必要です。10.13で非推奨(deprecated)になっています。Space(色空間)といいながら実際には色空間に該当する(HSBとかL*a*b*とか)ものを指定しているわけではないので、色タイプと言い換えることにした、という説明が行われていました。10.15betaでは未確認ではあるものの、このNSColorからRGB値を取り出すという処理自体を書き換える必要が出てくるため、本ルーチンだけ別のライブラリに分離しておくとか、メンテナンス時にわかるように書いておくとよいでしょう(NSColorのtypeを取得してみたものの、いまひとつサンプルなどもなく不明。10.14上で全部一律で0が返ってくるし)。AppleにOS内部の機能修正リクエストを出す場合、「実際に機能不全を起こしているんだから直してほしい」と依頼してもなかなか直らない一方で、「学術的に正しくない」という指摘をされるととっとと変更するんだなーという発見をしたような気がします。Debugger上でオープン中の2つのAppleScript書類のうち、名称が同じハンドラ(サブルーチン)の内容同士を比較して、お互いに合っているかどうかをチェックするAppleScriptです。Lib内のフレームワークが呼べないため)。▲本Scriptはスクリプトエディタの環境設定で行うAppleScriptの構文色分け設定色が「RGBカラー」でないとエラーになります。CMYKとかグレースケールカラーで指定して、そのままRGBに変換されずに保持される(CMYK色はアクセスしているうちにRGBに変換されるが、グレースケールは保持される)ため、色空間の判定を行ってRGB色に変換してから処理する必要があります(自分用メモ)スクリプトエディタ上で設定する構文色分け設定をもとに、AppleScriptの構文要素を考慮したハンドラ一覧を作成し、2つのAppleScript書類の間に共通して存在するハンドラ名のハンドラ(サブルーチン)のAppleScriptソースを取得。インデント(tab)を削除したのちに比較を実行。共通名称のハンドラすべてをチェックして、結果を表インタフェースで表示します。初版(v1)では実行するたびに1つのハンドラをチェックしていたのですが、あまりにかったるいので即座にループですべて調べてまとめて結果を表示するようにしました(v2)。Object(JavaScriptでいうところのClosureみたいなもの)で論理分割された同名のハンドラが複数回登場するパターンは想定していません。複数検出するとエラーになります。Debuggerを対象にせずスクリプトエディタを対象にしてもよいのですが、些細な変更で実現できるため、興味のある方はやってみてください。あと、本Scriptは必要に迫られまくって作ったものなので、動作でおかしい箇所があったらぜひぜひご指摘を。個人的には、ハンドラ名称を構文要素を考慮しつつ取得している一方で、ハンドラの内容は単なる文字列検索で取り出しているというあたりにアンバランスさを感じます。10.14.5上のスクリプトエディタで、構文色分け情報を何回設定しても「黒」になるという現象に遭遇したのですが、他のユーザー環境上での再現性については未知数であるため、まだレポートできない状況です。その後、本ツールは強化されて、構文色分け設定にRGB以外の色が設定してあってもRGBに変換して処理する機能や、構文色分け設定を参照したコメント除去機能や、各種書式情報の取得を3倍高速化するカラーキャッシュなどの機能を実装したプログラムに(必要に迫られて)成長しました。Objectの使用は考慮していない。extractStrFromTo。