NaganoyaSafariの最前面のウィンドウで表示中のページのうち、現在ウィンドウ内に表示中の表要素をCSV書き出ししてNumbersでオープンするAppleScriptの改良版です。HTMLのtable中にrowspan(複数セルを行方向に連結)とcolspan(複数セルを列方向に連結)の属性値が指定されていた場合に対応します。ElementsのWebコンテンツ中の表示座標を取得して、絞り込みを行なっています。各DOM座標はWebブラウザのスクロールにしたがって数値が変わる(相対座標)ため、少々手こずりました。本Scriptでは上下スクロールのみ考慮してDOM要素の抽出を行なっており、横に長いページの横方向スクロールは考慮しておりません。colspanへの対処を追加しました。行単位で(1次元配列ベースで)表を作っていてはとても対処できなかったので、HTMLの表と同じセル数のヌル文字が入った2次元配列を作成し、そこにX座標/Y座標を指定してセルを埋めるように処理内容を変更しました。rowspan/colspanの属性を見つけた場合には、結合されていた複数セルを個別の(同じ値を入れた)セルに分解しています。本バージョンでは、1つのセル(td)でrowspanとcolspanを同時に指定しないことが処理の前提条件となっています。上の行がヘッダーの場合を想定しており、一番左の列がヘッダーになっているケースには対処しておりません。NaganoyaSafariの最前面のウィンドウで表示中のページのうち、現在ウィンドウ内に表示中の表要素をCSV書き出ししてNumbersでオープンするAppleScriptです。このところ下調べを行なっていた「Webブラウザで表示中の要素を処理する」「表示中ではない要素は処理をしない」というScriptです。これで、「表の一部を選択しておく」とかいった操作は不要になりました。ウィンドウ内に表示されている表をWebコンテンツ内部の表示座標をもとに自動抽出します。表示エリア外に位置しているものは書き出し処理しません。ElementsのWebコンテンツ中の表示座標を取得して、絞り込みを行なっています。各DOM座標はWebブラウザのスクロールにしたがって数値が変わる(相対座標)ため、少々手こずりました。本Scriptでは上下スクロールのみ考慮してDOM要素の抽出を行なっており、横に長いページの横方向スクロールは考慮しておりません。本Scriptは大量一括処理を志向するプログラムではなく、「見えているもの」をそのまま処理してほしいという考えで作ったものでもあり、Webブラウザ(Safari)で表示中のページのソースを取得してそのまま処理しています。ユーザーが閲覧中のページのデータそのものを処理しています。Chromeにはできない処理です(同じURLの内容を別途curlコマンドなどで取得すればOK。Cookie値などの再現が大変でしょうけれども)。その他、実際に作って使ってみた感想は、装飾用に使われている表データまで取り込んでしまう点に不満があるぐらいでしょうか。これら「ゴミデータ」(再利用する価値のない装飾用の表データ)を区別するために、行数が足りない場合には書き出さないといった「足切り」を行う必要性を感じます。Elementの詳細なプロパティ値を取得するAppleScriptです。複数のTableが存在しているページのそれぞれのプロパティ値を取得してdiffを取るための調査用Scriptです。JavaScriptコマンドから各種結果を取得してAppleScriptの各種オブジェクトに変換するAppleScriptです。JavaScriptコマンド経由で値の受け渡しをするときに、さまざまな型のデータをJavaScript側からAppleScript側に渡したいことがあります。まじめにデータの受け渡しはそんなにやっていないので、あらためて方法を調べておきました。Naganoya指定URLの存在確認を行うAppleScriptです。以前はNSURLConnectionを使って確認するものを使っていましたが、NSURLSessionへと移行しようかというところ。API呼び出しのサブルーチンが絶好調で動いているので、これをそのまま流用してみました。Librariesフォルダに入れておくとか、そういう使い方になると思います。自分でもわざわざこれだけの機能のために、これだけの量のコードをゼロから書くことは......めったにありません。URLSession:dataTask:didReceiveData:–ないとエラーになるので足した。APIを呼び出すAppleScriptの最新版(のスケルトン)です。10.10でほぼすべてのAppleScriptランタイムでCocoaの機能が利用できるようになったため、Cocoaの機能を利用してクラウド系サービスを呼び出すことを、割と早い時期から調査していました。Actionなどの独特なランタイム、あるいはMessages(旧称iChat)のメッセージ受信イベントから呼び出されるAppleScriptランタイムなど、それぞれのアプリケーション独自で実装している処理系についてはCocoaの機能が使えるかどうかは保証のかぎりではないからです。明確に、当初からクラウドと機械学習をAppleScriptから利用するために、苦労してCocoaの機能を追いかけてきたわけです。その途中でいろいろサードパーティのFrameworkを呼び出せたりして、期待よりも大きな成果を手にしている昨今です。OSの内部機能を直接利用できることのメリットは、処理速度や詳細な情報取得など枚挙にいとまがありません(日本語の慣用句表現なので翻訳しにくいかも?)。話をクラウドにもどしましょう。APIを呼び出すには、同期で実行されるNSURLConnectionを使うのが最も簡単で確実でした。同APIは非推奨(近い将来に廃止される)という位置付けになったため、その代わりを探す必要に迫られました。API呼び出しのScriptが大量に存在していたからです。代替APIとしてNSURLSessionが提示されましたが、こちらは非同期実行のみで同期実行モードはありません。実験してみたものの、数回に1回ぐらい、サーバーからの応答をつかまえ損ねることがあり、処理時間もNSURLConnection版より長くかかります。script経由でcurlコマンドを使って回避するか?」といった回避策を検討していたところです。そんな中、冗談半分でNSURLSessionを利用したバージョンをほんの少し修正してみたところ、いままでの不安定さが嘘のように安定して結果を得られるようになってきました。同時に問題点も見つかってきました。10.12/10.13/10.14共通でサーバーからの応答を取得できず、タイムアウトエラーになります。Debugger上でデータ受信を検出できないという問題がありました。ラベル値とproperty名でコンフリクト起こしたかも?)現象が見られました。10.14上でも問題なく動作することを確認しました。URLSession:dataTask:didReceiveData:–ないとエラーになるので足した。Naganoya指定の広さの空間(Bin)に任意のサイズのブロックの組み合わせを最適化して詰め込むPackingの問題を解くAppleScriptです。ところが、実際に使ってみたいと思っても、使い勝手のよいプログラムが見当たりません。Frameworkになっていて、NSRectをリストで渡すと結果を返してくれるようなものが個人的には理想的ですが、そういう仕様のものはほぼありません(完全にないわけではないものの、使い物にならない、、、)。Packing処理をAppleScriptで書いたものの、「ぴよまるソフトウェア」内で相談したところ外部公開はしにくい状況。Packingの機能を提供しているpackit4meを発見(よく見つかったな)。Packingを計算します。APIなので、プログラミングではなく「作業」のレベルで対処できます。Packingを計算。Packを解かせてみると、Web上の3Dプレビュー(↑)はともかく、JSON(↓)で返してくる値が割とむちゃくちゃ。0}]}]座標値にマイナスの値が含まれているなどうまく動いていない印象を受けます(制約条件が違うんだろか?)。location)を検索して、アラートダイアログ上に拡大レベルの異なる4つの地図を表示するAppleScriptです。Goecodingのサービスはipinfo.ioを利用しています。この手のサービスは入れ替わりが激しいので、長期的に使い続けられることを期待できないと感じています(有償サービスは別)。「地球を侵略しに来た異星人には向いているが、地球人向けには冗長」といった意見が多く、オクラ入りしていました。アラートダイアログでさまざまなデータを可視化する部品の整備計画時に倉庫から引っ張り出されてきたものです。17.のAppleとか)データを可視化するときにはバッチリ合っています。10.14.4上では初期状態でピンが表示されません。自体は存在しているので、地図表示タイプを変更すると表示されるのですが、一体これはどうしたものか。仕様なのかバグなのかわかりません。API)を呼び出して、指定のテキストを別の言語に翻訳するAppleScriptです。Keyを発行してScript中に記述して呼び出します(retAPIKeyハンドラ中にハードコーディングするのが嫌であれば、Keychainに登録して呼び出すことも可能です)。API呼び出しのいつものやつなんでとくに解説はしません。コピペで作れるぐらい退屈で簡単です(本Scriptも呼び出せることを確認するだけして放置していました)。本Scriptは同期処理用のNSURLConnectionを使って呼び出しているバージョンで、このNSURLConnectionが将来的に廃止される見込みなので、curlコマンドで呼び出すか、NSURLSessionを使って呼び出すように書き換えるか、といったところです。単体だとただ翻訳できるだけで、あまり面白味はありません。APIで画像認識を行なったときに、その画像認識テキストが英文で返ってきており、その内容を日本語に自動翻訳するときに使用してみました。翻訳精度は悪くないと思うのですが、画像のシーン認識テキストの英文がいまひとつだったので、「英文で出力してくれた方がまだわかりやすい」というところで、個人的にはあまり活躍していません。APIを売り物の本の翻訳に使うことが許可されていないなど、利用許諾が割と厳しいので使いどころが多そうに見えつつもそうでもない、といったところでしょうか。APIを呼び出して、指定ユーザー名の情報を取得するAppleScriptです。APIは、タグ、ユーザー、質問の3ジャンルの情報取得を行えるように整備されており、特定カテゴリ(タグで分類)の新規質問が投稿されたかどうかを定期的に確認するようなAppleScriptを作って運用することもできます(そこまでやっていないですけれども)。API呼び出しにはNSURLConnectionからNSURLSessionに移行していますが、どうもNSURLSessionだと呼び出せない(AppleScriptからの呼び出し処理が完了しない)サービスがあったりするので、結局shellのcurlコマンドを呼び出すのが手短にすむケースが多いようです。Teratailの場合も、NSURLSessionで呼び出せるAPIもあれば、結果が返ってこないAPIもあり、NSURLConnectionよりも使い勝手がよくないと感じています(個人の感想です)。このあたり、将来的なmacOSのアップデートでNSURLConnectionが使えなくなる日が来るのかもしれませんが、curlコマンドを使うように集約するべきなのか、NSURLSessionで書き換えるべきなのか悩ましいところです。API(でも、みんな知っている)を呼び出して、指定ユーザーのノート(投稿記事)を取得するAppleScriptです。APIを呼び出すよう徐々に変更しています。APIを共通ルーチンで処理できるとよいだろうかと思っていました。APIの共通処理ルーチン」というところまで共通化する段階までには至っていないところ。左がNSURLSessionを用いた呼び出し、右がNSURLConnectionを用いた呼び出しを行なったものです。NSURLSessionを使ってみてはいるものの、同一の処理でもNSURLConnectionの方が40%ぐらい高速です。同一ネットワーク環境(iPhone経由のテザリング接続)でNSURLConnectionが0.4秒ぐらい、NSURLSessionでだいたい0.5から0.7秒といったところ。有線ネットワーク接続だともう少し速度が改善するかもしれません。NSURLSessionに明示的な同期処理が存在しないため、NSURLSessionが受けわたすdelegateイベントをAppleScript側でループしつつ待っており、NSURLConnectionで素直に同期処理メソッドを呼び出すよりもオーバーヘッドが大きくなっているものと推測しています。APIを呼び出すあたりの処理をまるごと独立したFrameworkにでも追い出すとよいのではないか、といったところです。