NaganoyaNumbersでオープン中の複数の書類があったときに、書類Aのすべてのシートの表1を、書類Bの現在のシートの表1にまとめるAppleScriptです。機械的な作業すぎて手で行う気にはなれなかったので、ありもののScriptを利用して作ってみました。list」を利用しています。10.14/10.15に邪魔されて認識されない環境では動かせないかもしれません。このあたり、SIP解除するしかないと思わせるものがあります。ライブラリで複雑な選択を行えるUI部品を作っておいたおかげで、これだけ込み入った動作を行うAppleScriptを書きましたが、Cocoaの機能はほぼ使っていません(getDataFromNumbersDocは作り置きしておいた、頻出ルーチンなので使いまわしています)。listライブラリは、こういう用途のために作っておいたものであり、まさにそのぴったりな用途であったといえるでしょう。commentBlogアーカイブのMarkdown書類をリネーム。NaganoyaFinderで選択中のファイルすべてに対して、親フォルダ名、親+1階層のフォルダ名を反映させたファイル名をつけるAppleScriptです。Blogアーカイブ本を作るのに、こうした道具を作って使っています。一度書いておけば、2度目からは大幅に時間を短縮できます。最初のファイルから拡張子を取得してそれを後続のファイルすべてに適用するため、同一種類のファイルである必要があります。自分用のツールならではの手抜きといったところでしょうか。AppleScript名:BlogアーカイブのMarkdown書類をリネーム。NaganoyaSVGのPath指定(相対座標指定)をparseして、x,y座標の最小値、最大値を求めるAppleScriptです。countryといった命令を作る野望が)。メルカトル図法の世界地図で塗った箇所がわからないぐらいの規模の国が世界中にはたくさんあることを再認識しただけでした。アメリカ合衆国とかロシアとか中華人民共和国ぐらい国土が広ければ赤く塗っておけば視認できますが、赤く塗っても面積が小さければ視認できません。そこで、地図上では「点」にしか見えないような国の位置を明示するためには、色を変えて塗る以外の表現方法が必要になってきます。SVG世界地図上では、それぞれの国データがpathで表現されていました。このpathはすべてを絶対座標で表現するタイプと相対座標で表現するタイプがあり、部品として使いまわしたりデータサイズを抑えることを考えれば、相対座標でデータ表現したくなることでしょう。実際、自分が見つけたSVG世界地図データは相対座標でデータが作られていました。そこで、指定のPath内の座標値をすべて絶対座標に計算し直しつつ、x,y座標の最小値、最大値を求め、その値を元に塗りつぶすことで、面積の小さな国の所在位置を赤い線の交点として表現できそうだと考えました。した実証実験のために作成したのが本AppleScriptです。テストデータは日本列島のもので、このサイズのデータからx,yの最小値、最大値を計算するのに0.06秒ぐらいで処理できています(自分の開発環境での計測値です)。プログラムの作りやすさを優先して、あとで全データから最大値/最小値を求めていますが、座標計算しながら最大値/最小値を求めれば、0.05秒ぐらいにはなると思います。同時に計算したら0.039秒で済みました座標データ数がそれほど多くないので、Cocoaの機能を利用しても大幅な速度向上は見込めません。▲米領サモア本Scriptで取得したPathの最小値、最大値をもとに塗りつぶしを行なってみたところ、地図上で1ドットにも満たないような面積の国でも所在位置がわかるように表現できました。面積に応じて、塗りつぶし時のアルファ値を変更するような処理もためしていますが、面積が広いのに点にも見えない国(島で構成される国)だと、対象が見えないのに塗りつぶし色が薄くて見にくいなど、まだいろいろ試行錯誤が必要なようです。データを返すAppleScriptです。試作品なので、あちらこちらに「お可愛らしい」実装が転がっています。NSBoxがまだまともに使いこなせていないあたりとか(Xcode上で部品として配置するのは楽勝ですが、プログラムから動的に生成して使用するのは別なので)。抽出キー数は可変で外部から指定できるとよいのですが、本Scriptでは固定です。各抽出条件も外部から供給するのが本来あるべき姿ですが、ハードコーディングしています。あと、TableViewの下側に謎の余白があるのは、めんどくさくなってそのまま放置しています。これで外部から各種パラメータを指定できるようにして、sdefつけて1命令で呼び出せるようにしておけば、レコード数の多い選択項目から条件抽出しつつ項目選択できてよいでしょう。プログラム内容自体は、高度でもなければ高尚でもありません。実にダラダラとGUI部品のパラメータを設定しているだけです。if–このあたり、複数条件をハードコーディングしているのは超絶頭悪い。listの複数リスト版。list」AppleScriptライブラリです。10.13以降対応です。テキストエディタ上でオープン中のテキストのdiff表示を行う場合のファイル選択のために作成したものです。NaganoyaiTunesLibrary.framework経由でiTunes/Music.appのライブラリのジャンルごとの再生回数を集計するAppleScriptです。10.14.6)で0.7秒程度で終了します。10.15.1で0.6秒程度です。10.15以降(Music.app)でも同様にiTunesLibrary.framework経由でライブラリへのアクセスが行えます。List(1次元配列)のデータを指定セグメント単位で合成(加算)するAppleScriptです。何を言っているのか作った本人にしか通じない雰囲気が漂っていますが、単にデータの集計単位を変更するためのものです。24時間を1時間単位で集計したデータを3時間単位で区切って集計するとか、午前午後(2セグメント)でまとめて集計するとかといった用途に使います。いちじるしく、日常的に書き捨てしているレベルの処理ではありますが、再利用できる部品にまとめておきました。NaganoyamacOS標準搭載のテキストエディタ「テキストエディット」の最前面のドキュメントから書式情報を取得し、フォント名とフォントサイズのペアをスタイルを反映させたポップアップメニューで選択。選択したスタイルが該当する箇所を抽出したのちにテキスト化してTextViewで結果を表示します。RTF(なんでもOK)▲添付のAppleScriptアプレットは、初回実行時に制御許可のダイアログが表示されます。OKすれば、2回目以降はダイアログ表示されません▲書式情報をRTF書類から読み込んで、スタイルを反映させたポップアップメニューで表示。NaganoyaiTunes/Musicのライブラリに入っている楽曲データのジャンル分けのゆらぎ吸収を行う、ジャンル名のいわゆる「名寄せ」を行うAppleScriptです。▲1つのアルバム中でもジャンル名に表記ゆれがあるのは勘弁してほしいiTunes/Musicライブラリ中の全楽曲の最終再生日時を24時間の各時で集計を行い、ジャンルごとに再生時間に偏りがないかどうかを分析するため、さらにジャンルごろに集計してみました。「名寄せ」(なよせ)は昔から情報処理に見られる泥臭い地道な処理で、データ上の表記ゆれを吸収するための処理です。地名などの固有名詞で多く見られます(念のためにWikipediaで調べたら、異なる業界では割とブラックな言葉として用いられている模様)。このジャンル名が英語で入っていたり日本語で入っていたりと、ゆらぎが発生しているので、同様のジャンル名であれば同じものとして合算して集計してみました。英語で表記されたジャンル名ではなく日本語で表記されたものを採用(=すべてアルファベットで書かれたものを不採用)しています。それほどいじめ抜いていない(自分の環境でしかテストしていない)ので、ジャンル名の名寄せリストはもう少し鍛えておく必要があるものと思っています。List(1次元配列)同士を加算するAppleScriptです。書き捨てていますが、AppleScriptにそんな命令はないのでループで加算することになります。最近では、Musicの楽曲ライブラリ中の曲の、カテゴリごとの最終再生日時の分布集計を行なったときに、「Classical」「クラシック」などの表記ゆれを吸収するために、これらの複数カテゴリのデータを合成するときに使いました。書き捨てレベルだとこんな感じ(↑)ですが、今後使い回すことを考えて書いておくと、こんな感じ(↓)でしょうか。Listを連続して大量に加算する必要が発生した際への対策を行なっています。Naganoyaツリー状のデータ構造をNSBrowserで表示するためのデータ抽出を行うAppleScriptです。NSBrowserでツリー構造のデータを抽出しつつ表示するインタフェースを作るために、その基盤部分となるツリー状のデータを絞り込むプログラムを書いてみました。やりたいことをそのまま実装してみたもので、著しくどこかに同じ機能を持つものが存在していそうな気がします(NSTreeControllerとか)。"eeeeeeeee"}}該当するツリーアドレスの同一ブランチに存在するデータ一覧を取得するだけなので(日本語でも表現できているかどうか怪しい)、そこの部分だけ実装してテストしてみたものです。"eeeeeeeee"}よその処理系で見かけた処理なので、広く普遍的に存在していそうな処理ではあるものの、探してみるとなかなかお手軽なものが見つからなかったので、自分で作った次第です。NaganoyamacOS標準搭載のテキストエディタ、「テキストエディット」(TextEdit)をコントロールして、最前面のウィンドウの書類から、指定のフォント名とサイズに該当するテキストを抽出するAppleScriptです。テキストエディットはApple純正のアプリケーションの割にはAppleScriptサポート機能がよくできていて、選択範囲(selection)を取得できないことをのぞけば、けっこう使えます。16pointを指定Webブラウザなどからコピペしてきたスタイル付きテキストから、特定のフォントや文字サイズの箇所を抽出したい場合に使います。実行すると、リッチテキストで使用されているフォント名とサイズの一覧を生成し、ダイアログでフォント名の選択、そして、文字サイズの選択を実行。すると、該当箇所のみ抽出して返します。改行で区切ったテキストに変換するとかいった処理を行なってもよいでしょう。RTFのファイルを処理するのであれば、テキストエディットを使わなくてもCocoaの機能を用いて同様の処理を行えますが、割と書き捨てレベルの瑣末なScriptなのでテキストエディット経由で書式情報を取得するように組んでみました。IDで指定したアプリケーションのバンドル中(/Contents/Resources/)の現在のLocalizationに存在する指定のstringsファイル内で、指定キーの値を取得するAppleScriptです。アプリケーションバンドル内の各ローカライズフォルダの名称は一意に決定されているものでもなく、ある程度の「ゆらぎ」が生じています。/Contents/Resources/Japanese.lproj//Contents/Resources/ja.lproj/NSLocaleからcurrentLocale()を取得すると、「ja-JP」のような識別子が得られます。これと上記のパターンのフォルダとの付け合わせのためのメソッドがどこかに存在しているはずなのですが、現状では見つけられていません(ないと各アプリケーションが正しくメニュー表示できていないので)。いまひとつ、しっくりきていません。getLocalizationsFromBundleID–指定アプリケーションファイルの、指定Localeにおけるローカライズ言語リストを求める。NaganoyaCotEditorの最前面のドキュメントの選択範囲を、簡易形態素解析ルーチンeasyJparseを用いて、いい感じに伏せ字にするAppleScriptです。CotEditor)easyJparseは日本語のコマンド解析用にでっちあげた作った超簡易形態素解析プログラムです。単語(形態素)ごとに分割しますが、品詞まではわかりません。コマンド解釈用ではあるものの、少し他の用途にも使えないかと思い、このような用途に使ってみました。v2.0に収録されています▲CotEditorの選択範囲を伏せ字にする。形態素解析して単語化して、単語単位で伏せ字にするかの判断を実行テキストエディタ上で伏せ字処理というのは、個人的によく使います。オリジナルの文章に対して同様の分量の文章を作らなくてはならないようなケースで、文字数の感覚をつかむために使います。一種のダミーレイアウトのようなものです。本スクリプトのような伏せ字処理については、ニーズがあるんだかないんだか不明なものですが、とりあえず掲載してみました。自分で使ってみたところ、たしかに面白いものの、実用性については未知数という印象です。入れている語群は、どこかからか拾ってきたもののようではあるものの、すでに何か方向性を見失っているような気がしないではありません。script–伏せ字化しない助詞などの単語リスト。名詞だけを残すように整備。