英語版を作っています。とても真剣に。でも、英語版の本の「フォント感」がいまひとつ掴めなくて困ります。
本文にTimesはいまさら使ってない感じでサンセリフ系のフォントの幅の狭いものをタイトル部分に使っていたりするんでしょうし、各話の導入部分をイタリック体で装飾してメリハリ付けるんだろうな、などと手探りでやっています。
しょせんは英語ネイティブの人間が作っているわけではないので、違和感は残ると思っています。そこはこだわってもうまく違和感を消すことはできないでしょうから、しょーがないでしょう。
AppleScript+Cocoaの解説本は、けっこう前からいろいろまとめていました。知り合い筋には、雑談のおりにちょいちょい見せています。本Blogにも断片を掲載しています。
→ Cocoa Scripting Course #1を販売開始
▲これとか。Cocoa Scripting本のために準備した説明図です
ただ、それが一定レベル以上の具体的なものにならないのは……読者層がまったく想定できないということと、そんなにそれを求めている人がいないのではないか、と想像されるからです。
日本国内でそれを読みたいと思っている人が10人いるのかいないのか。実際にアンケート調査を行なったわけではありませんが、「そんなにいないよね?」とは思っています。
なので、書籍とオンラインセミナーの中間形態を模索しています。
基本的な解説部分と、NSStringなどの1つのテーマがセット。購入後●か月間、理解できなかった点を3つまで補足説明することを求める権利を差し上げます。つまり、詳細な情報を提供して不明な点の補足説明が行われるというものです。
やってみないと分からないものの、やるとしたらこういう形態しかないだろうと思います。サンプルScriptなども大量に掲載するので、いわば2018年1月末に発生したXserveによる無断サーバー停止によるBlog消失後の、本Blog再開後のテーマ別の説明とアーカイブというものに近くなるはずです。
▲このシリーズのみ体裁が少し変わります(横長)。いつもの体裁だと入りきらない図形が多いもので
▲あまりに「おいしそう」に見えなかったので、表紙を変更してみました。まあ、おいしそう!
あとは、SafariのScripring Book計画。こちらは、FileMaker Pro本の前から構想があったものです。
表紙と章構成ぐらいを作ってみました。はたして……
AppleScriptからFileMaker Proをコントロールするやり方を基礎から実戦レベルまで紹介する電子ブック「FileMaker Pro Scripting Book with AppleScript」を発売いたしました。定価は3,000円です。
→ 販売ページ
これまでに、「AppleScriptえほんシリーズ」を3冊出しています。Scriptについて理解していなくても、本のとおりに操作して入力すればGUIアプリケーションを動かせることから、余力があればもっと充実させたいコンテンツではあります。
▲コンテスト応募作品「Word Color Palette」。いつものthree.js回転UIなど、AppleScriptでおなじみのInterfaceをFileMaker Pro上に移植。シソーラス辞書検索やSVGサンプルデータへの自動配色などにAppleScriptを利用(iOSやWindows上では機能ダウンした処理を実行)
FileMaker Proはさすがに機能が多く、この「えほんシリーズ」フォーマットの計画もあったのですが、内容に無理を感じていました。同様にSafari本についても検討したものの「途中から急に技術レベルが上がって、入門者向けにはならない」(do javascriptコマンドが出てくるあたり)ということで塩漬け状態。そのジレンマを打開するための新たなシリーズが「徹底解説シリーズ」です。
「画面図多め+文章少なめ」の「えほんシリーズ」のフォーマットを踏襲しつつ、「えほんシリーズ」の特徴である難易度設定の厳重な管理により、急激に難易度が上がったり、そもそも記事の難しさがどの程度なのかわからないといったことのないように配慮しています。「初級」「中級」「上級」の3レベル分けを行っています。
「えほんシリーズ」ではページ数を少なめ(64ページ以下)に抑えていましたが、「徹底解説シリーズ」では分量を抑えるよりも対象のテーマを説明し切ることに重点を置き、対象レベルを若干上げています。分冊構成にすることも検討したのですが「では、検索をしたかったら下巻も買ってね」というのはさすがにご無体なので、1冊にまとめて139ページとなっています。
とくに、対象がFileMaker Proということで、同アプリケーションのエキスパートである新居雅行氏から監修していただき、内容の充実も図っています。
▲掲載デモScript。FileMaker Proのスキーマ定義を自動で行うAppleScript。リストで与えたフィールド名を自動作成。ちょっと手直しすればNumbersの表計算データからフィールド名を外部供給することも容易
これまで、プログラムリストをPDF本文にURLリンクで埋め込むという手法を用いていましたが、macOS 10.15以降のPDFViewにおいてどうもこのURL埋め込み式のPDFをApple側がセキュリティホール源と捉えており、とくに説明なしに機能をダウンさせています。このあたりの話は「専用のビューワーアプリケーションを作る」「リストを掲載しているBlogのページにURLリンクで飛ばす」などの対処が検討されてきましたが、どれもすべてを解決できるわけではありません。
そこで、おおもとの方式に差し戻してAppleScript書類のアーカイブを添付することにしました。AppleScript書類と、他のOS環境でも内容をオープンできるようRTF形式のファイルも添付しています。
また、最近の電子書籍購入者の方にはご案内していますが、「Piyomaru Script Assistant」のバージョン2を添付。Cocoaの機能呼び出しを意識した内容に再編し、macOS 10.13以降のOS環境をターゲットとしています。スクリプトエディタのコンテクストメニューからAppleScriptの主要構文を選択入力できるこのツールは、作った本人でもインストールしていないと作業性が大幅に低下してしまうほどの必携ツールです。
完成度については、さすがに屈強の筆者であり開発者であり編集者である自分が朝から晩まで作り込んだうえに、新居さんに監修していただいた(ダメ出しされまくった)だけあって、「手元に1冊置いておきたい出来」にはなっていると自負しています。
Uni Detector v1.2.1がMac App StoreのUtility部門で28位(瞬間最大風速)になりました。トータルでは、163位です。
# ニホン(Japanese Version)のMac App Storeだけでしょうか?
Mac App Storeのランキングはひんぱんに再計算されるため、見ている間に順位が37位になりました。儚い。
ランキングの上の方を見ると、Brotherさん(企業)のスキャンユーティリティが2位にいます。無料ソフトなのに、けっこういろいろ言われていてドキドキします。有償にしてもよさそうな雰囲気ではあるのですが、そのあたりの動向は見ものです。
macOS 10.15内蔵のZipライブラリがこれまでと異なり7-zip(分割アーカイブ対応)を使ったことでおかしな挙動を示すようになり、アーカイバに対しての需要が強いことを感じさせます。
あとは、ランキング上位でも「なにこれ?」というものもあったりで、(子供の作ったような電卓アプリには驚きました)なかなか驚かされます。
ケアレスミスで、「Scroll BarをWindowの枠外に配置してしまった」Uni Detector v1.2のリテイク版、v1.2.1をリリースしました。
▲MacBook Air 11インチを基準に、このマシンで最低限の操作が行えることを想定したUser Interface
バージョン1.2以降のUni DetectorのAppleScript用語辞書には、「check arch」のコマンドしか用意していませんが、Sandboxのセキュリティを乗り越えつつ必要な機能(ユーザーによる任意の指定フォルダ以下のアプリケーションのチェック)を実現することが目的です。
本来のScriptableなアプリケーションの意義を考えると、アプリケーションのチェック結果をリストで取得するべきですが、さすがに無償配布アプリケーションでそれはやりすぎなので、実装を控えています。
AppleScript名:アプリケーションのプロパティを取得.scpt |
tell application "Uni Detector" properties end tell –> {frontmost:false, class:application, name:"Uni Detector", version:"1.2.1"} |
AppleScript名:指定アプリケーションをUni Detectorでチェック.scpt |
use AppleScript version "2.7" –macOS 10.13 or later use scripting additions use framework "Foundation" set anApp to choose file of type {"com.apple.application-bundle"} with prompt "Select target one App" with timeout of 3600 seconds tell application "Uni Detector" set aRes to check arch anApp end tell end timeout |
AppleScript名:指定フォルダ以下にあるアプリケーションすべてをUni Detectorでチェック.scpt |
use AppleScript version "2.7" –macOS 10.13 or later use scripting additions use framework "Foundation" set anApp to choose folder with prompt "Select target Folder" set appList to getFileListWithSpotLight("kMDItemContentTypeTree", "*com.apple.application*", anApp) of me with timeout of 3600 seconds tell application "Uni Detector" set aRes to check arch appList end tell end timeout on getFileListWithSpotLight(aMetaDataItem, aParam, startDir) set sDirText to quoted form of POSIX path of startDir set shellText to "mdfind ’" & aMetaDataItem & " == " & aParam & "’ -onlyin " & sDirText try set aRes to do shell script shellText on error return {} end try set pList to paragraphs of aRes set aList to {} repeat with i in pList set aPath to POSIX file i set aPath to aPath as alias set the end of aList to aPath end repeat return aList end getFileListWithSpotLight |
Universal Binary Checker「Uni Detector」のバージョン1.2をMac App Storeの審査に提出しました。
目下、Universal Binary対応アプリの提出騒乱状態なので、審査側がパンクしないようにイージーモードの審査が続いており、平時では通らないようなバグがそのまま残っていたv1.1.1でした(これは自分のせいです)。
Uni Detector v1.2はまだUniversal Binaryではありません。1つには、macOS 11.0上でUniversal Binary化できることは確認ずみで、いつでも対応可能であること。その割に、ビルド環境をmacOS 10.14.6から移行するのには(Mac App Store向けビルド環境の移行)手間がかかること。あと、どうせAppleScriptで書いたアプリケーションなので、Universal Binary化してもスピードアップの恩恵が限定的である(ことが予想される)ためです。
Uni Detector v1.2はScriptableになりました。外部からAppleScriptでコントロール可能です。AppleScript用語辞書には、本Blog同様ワンクリックですぐに利用可能なScriptサンプルを掲載しています。
ただし、実装した「check arch」コマンドはユーザーのホームディレクトリ以下に置いたアプリケーションやネットワークサーバー上のアプリケーションなどをチェックしたいという需要に応えるための必要最低限のものであり、チェックした結果のデータをlistやrecordで返すものではありません。
さすがに、他のソリューションに組み込んだり連携可能なデータを返す機能については、発展機能を持つ有償版で対処したいところです。フリー版の機能はこの程度にしておきたいところ。
AppleScriptで作ったGUIアプリケーションにAppleScript用語辞書をつけて外部のAppleScriptから呼び出すというのは、ひどく本末転倒といいますか、豆から作った豆腐を崩してふたたび固めて作る日本料理の「ひろうす」のような感じといいますか、妙な感じがします(普通にGUIつけないでフル機能をAppleScriptだけで書けるのに、変に遠回りなやりかたです)。
あとは、小さい画面の環境でも「Mac CPU Architecture Trend」の図が見えるように、ポップアップで別途表示できるようにしました。
この表示を行うために、既存のViewの内容をPDFとして取得してPDFViewで表示しています。
些細なスペルミスを修正したり、Fileメニュー以下のコマンドが一切動作していないというバグを修正したり、CM表示機能を強化したりと細かい点の修正を行っています。
Mac App Storeに提出したアプリケーションをAppleScript対応にしたのは今回が初めてです。Store未提出のアプリケーションではScriptableにしたことはありますし、AppleScript LibrariesにAppleScript用語辞書をつけて配布したことはありますが、GUIアプリにAppleScript用語辞書をつけて配布したのははじめてのことです。
次は、本アプリケーションをUniversal Binary化するぐらいでしょうか。それで、ひとまず「しなくてはならないこと」は一段落だと思います。一部のマシンでSpotlight DBが壊れたままで運用しているものがあるらしく、それを強制的にプログラムから再生成する機能でも呼び出せたほうがよいかと思っていますが、はたして、、、、
Uni Detectorのアイコンを変更します。ウニ(Sea Urchin)のアイコンには個人的に思い入れも深く、この現行のアイコンも随分前に奥方様と一緒に行った寿司屋でデジカメで撮影したものです(8年ぐらい昔?)。
つまり、「どうせPowerPCからIntelに移行したんだし、10年ぐらいたったら再びCPUの移行はあるだろう」と読んで、ものすごく時間をかけてアイコン候補の写真を撮影するような、凝ったことをしていたわけです。
ただ、いろいろダウンロード状況を分析するに、U.S.のユーザーが全然食いつかない(大統領選が終わっても変化なし)。不思議なぐらい食いつかない。無料のアプリケーションという「撒き餌」にまったく食いつかない。食い気が感じられない。
なぜだろう? と、首をひねっていたのですが、われわれには美味しい食材にしか見えない海鮮丼の写真が、海外のユーザーにはグロい写真で嫌がらせをしているようにしか見えないのでは? という仮説に至りました。
その仮説をもとにSNS上で意見を募ってみたところ、
「Dock上に置きたくないデザイン」
「ハイコンテクストすぎてApp Store向けアプリには不向き」
「そういうのは趣味でやれ」
という散々な結果に。
タイミングをねらって、必要な道具をピンポイントでリリース。ユーザーへの知名度の向上と、各種ソフトウェアの宣伝を意図した戦略的なソフトウェアが、アイコンというきわめて重要度の低い構成要素のために本来の役割を果たしていないものと判断。ここに、苦渋の決断をもってアイコンを無難なものに変更することといたしました。
Universal Binary判定ツール「Uni Detector」のv1.1をMac App Storeで配布開始しました。対象OSは、macOS 10.13以降です。ただし、macOS 10.13だと(ツールバーボタンのクリックからは)グラフ表示が行えない(メニューからはできる)ので、10.14と言いたいところです。
▲初代「うにばーさる」。久しぶりに引っ張り出してきたら動作して驚き。そして、Finder経由でファイル情報を取得しているので現行環境だと目が回るほど遅い(64bit化されたCocoa Finderでファイル処理を行うと劇遅)
v1.1では、主にmacOS 11.0, Big SurおよびApple Siliconへの言及を追加しました。
新規追加機能は、
・アプリケーションのフィルタリング機能:書類形式(ファイル拡張子)、カスタムURLプロトコルでフィルタ表示できます。HEIFをサポートしているアプリケーションの一覧を表示する、という絞り込み(フィルタ)表示や、URLプロトコル「http://」をサポートしているアプリケーションの一覧を表示することが可能です。
・選択中のアプリケーション情報表示機能:書類タイプ、ローカライズ言語一覧、サポートURLスキーム一覧表示
・各アプリケーションの情報表示機能:ターゲットプラットフォーム名表示(Apple Silicon Mac上にiOSアプリケーションをインストールした場合の識別用に)
・Scriptableなアプリケーション判定機能を強化:「えせScriptable」なアプリケーションの一覧データを保持し、AppleのiBooks Authorなどの「えせScriptable」なアプリケーションをAppleScript対応アプリケーションから除外する機能です。データリストを固定で保持して、「えせScriptable」なアプリケーションの除外を行っています
Universal Binaryチェックツール「Uni Detector」をMac App Storeで無料リリースしました。macOS 10.13以降用です。私の作るものなので、すべてAppleScriptで記述してあります。
前作「うにばーさる」はPowerPCからIntelへの切り替え時に、AppleScript Studioで作りました。
「Uni Detector」はAppleScriptObjCで作成。いろいろこなれてきているのですが、商品にはなりそうにもなかったので(そんなにひんぱんにバイナリアーキテクチャを調べたい人はいない)宣伝用にフリー配布です。
# Macの販売店の店頭でデモするのには向いているかも?
バイナリ対応度を調べるだけのソフトウェアでは、一度試したらおしまいです。日常的にこのソフトウェアを使うと便利なよう、自分で使い込んでさまざまな機能を実装しました。アプリケーションのメタデータを読み込んで、しぼり込み検索してカテゴリごとのバイナリアーキテクチャ分布を調べられるようにしました。
また、Universalバイナリ対応のほかに「AppleScript対応度」の調査もこのアプリケーションの1つの大きなテーマにすえました。AppleScript対応度もカテゴリごとに調査できます。「Microsoft」や「Adobe」をキーワードに絞り込んで、アーキテクチャやAppleScript対応度を調査することも可能です。
Scriptableなアプリケーションの一覧を表示したり、選択中のアプリケーションのAppleScript用語辞書を表示させたり、とくに本Blog上のサンプルScriptを表示させる機能がよそには真似できないところでしょう。
一覧で選択したアプリケーション名をキーとして本Blogの記事を検索・表示させる「サンプルScript表示機能」。これだけのためにポップアップするミニWebブラウザを実装しています。
「Universal Binary」は、NeXT時代のMAB(Multi Architecture Binary)、FATバイナリを引き継いだもので、NEXTSTEP(正確には後継のOPENSTEP)時代にはx86(Intel)、68K(NeXT)、SPARC(Sun)、PA-RISC(HP)などの複数アーキテクチャ向けバイナリをまとめてパッケージ内に格納できていました。
当時は複数アーキテクチャ、複数環境をサポートするための技術と受け取っていましたが、Mac OS X上での使われ方は自社プラットフォームのCPU切り替えを円滑に行うためのもので……MAB/FATバイナリとはモノが同じでありながら運用の仕方が全然違いますね。
技術的には、ツールバー上のSegmented Controlで作ったボタンがmacOS 11.0上でどう見えるか、きちんと見えるのか、Betaのたびにコロコロ見え方が変わるので、そのあたりを回避したらどうなるのかとか、そういう実証試験を行なっています。
また、macOS 10.15以降でアプリケーションフォルダ(/Applications)の内容が、/Applicationsと/System/Applications/に分かれ、フォルダの内容をScriptから取得できないあたりで悩まされました。アプリケーションのアイコンをInfo.plist経由で取得できないケースも見られ(とくに、Apple純正アプリケーション)、そのあたりの対処も悩まされたところです(フリー配布なのに手間がかかりまくっていて大変です)。
Terminal.appのコントロールを行なったら一発リジェクトでしたが、スクリプトエディタのコントロールはいいんだ、へーという発見はありました(macOS 10.14で「execute」コマンドが削除されたので無害?)。アプリケーションのAppleScript用語辞書を表示させているだけなので、コントロールというレベルではありませんけれども。
Webブラウザで表示中の範囲にあるTableデータを書き出すアプリケーション「Table Dripper」の新バージョンv1.1の審査が終わって公開になりました。macOS 10.14以降に対応しています。
新バージョンでは、かねてよりお知らせしていたとおりWebブラウザ「Brave Browser」と「Vivaldi」のサポートを追加。さらに、表データ抽出時に行ヘッダーを削除して出力する機能と、表データのHTML書き出しをサポートしています。
Table Dripper v1.1サポートWebブラウザ:Safari、Google Chrome、Microsoft Edge、Brave Browser、Vivaldi
今回のMac App Storeの審査は5日ほど。新作を出したときと同じぐらいの期間がかかっています。普通、アップデート版の審査はあまり時間がかからないのですが、本アプリケーションはv1.0のリリース後にApple側から「Mac App Storeの基準に違反しているのでアップデートで修正しろ」と言われた経緯があります。
当然、Apple社内的には審査をゼロからやり直し、初版リリース時と同じぐらいの時間がかかる可能性も覚悟していました(10日はかかりすぎですが)。5日はだいたい標準的な審査時間ではないでしょうか(新作アプリケーションの審査期間としては)。
今回のv1.1で一番大変だったのは、表ヘッダーの削除機能です。
表の全セルの内容を取ってくるのは、HTMLReader.frameworkの機能に依存してそれほど手間をかけずにできるのですが、Tableタグで作られた表は人によって書き方がまちまちで、ヘッダー宣言して行ヘッダーを書いてあるパターンはむしろ少なく、ヘッダーセルの宣言だけで行ヘッダーが作られているケースの方が多いようでした。
# HTMLReader.framework作者のNolan Waiteには毎回、「こんなScriptを作ったよ!」「こんなアプリを公開したよ!」と報告しています。大変感謝しています。当然、Table Dripperの無料コードを送りつけて「よかったら使ってみて!」と押し付けています
日本語のWikipediaに掲載されている表は、構造が単純なものが多く、本アプリケーションによるデータの再利用や流用がやりやすい傾向にあります。
一方で、英語版Wikipediaに掲載されている表は、なぜかメチャクチャ凝ったものが多く、ヘッダー部分のみ抽出するのはけっこう骨が折れます。
tableタグによる表組をいくつかのパターンに分類し、簡単なものから難しいものまでレベル設定を行い、簡単な方から徐々にヘッダー除去できることを確認していきました。v1.1は複数行の行ヘッダーに対応しているものの、ヘッダー列やヘッダー行にcolspanやrowspanなどの宣言を行なっている箇所があると評価エラーになってしまうため、ヘッダーを除去しないでそのまま出力するようにしています。
目下、Xcode上で作成するAppleScript Cocoaアプリケーションは、自分の検証環境がmacOS 10.13以降なのでmacOS 10.13以降対応とするのが自分的な基準なのですが、本アプリケーションについては外部アプリケーション操作やその対応状況の検出などの処理が必要であり、macOS 10.14以降の対応となっています。
macOS 11.0のリリースが目前に控えており、10月なかばにはGM版のリリースが行われることが予想されています(最近GMリリースしないんですけど)。11.0が出た時点でXcode 12.2の正式版も出るはずなので(すごく不透明)、それでARM/Intel 64のUniversal Binary対応とmacOS 11.0上での動作確認したバージョンをひととおり出すことになりそうです。
全部AppleScriptで記述したアプリケーションなので、Universal Binary化も容易(CPU依存部分がゼロ)ですが、macOS 11.0のGUI仕様がBetaのたびにコロコロ変わる(バグなのかなー)ので、そのバグをどう回避するかというあたりで労力が変わってくると思われます。
Mac App StoreにWebの表データ(tableタグで書かれた表)のインタラクティブ・スクレーパーである「Table Dripper」のバージョン1.1を申請し、目下審査中です。
データスクレイパーの多くは、定期巡回してまとめてサイトのデータを取ってくるものですが、Table DripperはWebブラウザで表示中の、いま目の前にある見えている表データを取り出すことに特化しています。
v1.0の審査は10日ぐらいかかったのですが、今回はもう少し早く結果が出て欲しいところです。
v1.0がAppleの承認を経て公開になったあとで、あとから「やっぱりこのアプリ、Mac App Storeの規約に反しているのでー」と言ってきたので、その部分に手を加えてアップデートしました。
temporary items folderにユーザーがアクセスできてしまうことを問題視したようです。他のアプリケーションの審査では指摘されていた項目ではあったものの、当時Mac App Storeの審査に1人で同時に3本ぐらい突っ込んでおり、他のレビューでは指摘されていた内容でした。
ちなみに、ダルそうに電話してきたApple側の担当者は「Table Dripper」という単語を読めませんでした(おかわいらしい!)。「Sandboxの仕様で話はわかるが、どう回避しろと?」と問えば、自分はそんなことは知らない、とのこと。
なるほどー、文字が読めない人間に電話させてくるのかー、知能のない人間を担当にして反論を封じるとはなかなか洒落たことをするものであります。言葉のわからないにゃんこちゃんに反論はできませんので。
これを、難しい専門用語で「サンドボックス環境」ならぬ「サンドバック担当」と呼びます。
▲起動時にDrip Folder(作業用の表データ書き込み先フォルダ)の選択を求められるようになりました。Sandboxの仕様上、動作を変えた部分
▲5つのWebブラウザをサポート。FireFoxやOperaはAppleScriptのサポートが弱い(do javascriptに相当するコマンドがない)ためにサポートできません
▲表データの解釈機能を大幅に強化。取り込み時に行ヘッダーを削除する機能を追加
相棒のTakamori氏から指摘されてはじめて気づいた事実、Piyomaru Softwareにはロゴマークが存在していませんでした!
ながらく、マスコットキャラクターの「Piyo Wolf」をロゴっぽく使ってきましたが、アイコン的に利用するには形状が複雑すぎです。
そこで、夜分に音声チャットであーだこーだ意見を交換しつつ、それらしきものを作ってみました。
自分たちでは割と気に入っています。とくに、TwitterやFacebook、YouTubeなど各種Webサービスでは個人の識別用アイコンを丸く切り抜いて表示するようになっており、その切り抜き表示時の相性がいいと思います。
印刷用のグレースケール版も存在していますが、カラー版をそのままグレースケール化しても似たような濃淡になるようにカラーを調整しています(そこが一番のこだわりどころ)。
「P」を図案化したロゴマークでは、Parking表示やPanic Inc.のロゴマークがあり、これら既存の強いロゴマークと差別化することをテーマに組み立ててみました。
▲ボツ案1 納得感がなく、これじゃない
▲ボツ案2 Google風。誰でも一度は試してみる路線
▲ボツ案3 頭が悪くない感じを狙ってみた。なごまない(脳みそへの認知負荷が高い)のでNG
例によってAppleScriptで開発したアプリケーション「White Pages」のMac App Storeでの販売を開始しました。macOS 10.13以降に対応しています。
PDFの空白ページを削除・出力するアプリケーションです。空白ページの検出のため、全ページを画像にレンダリングして、空白判定。空白判定には速度と精度で定評のある空白画像検出ルーチンを使用しています。
決して、ページごとに文字の有無を判断するだけのソフト(Fredrik Method)ではありません。それだと、グラフィックだけのページを「空白」と判定してしまいますので。
アイコンは、macOS 11.0, Big Surに合わせた形状。手の色を赤くしているのは、何らかの特定の人種を想起させるような塗り色を避けたためです。
例によってAppleScriptで開発したアプリケーション「Table Dripper」のMac App Storeでの販売を開始しました。macOS 10.14以降に対応しています(動作原理的にmacOS 10.13対応は無理だった、、、)。
Safari/Google Chrome/Microsoft Edgeで表示中のWebサイトのTableデータをCSVに変換してダウンロードしてNumbers.appでオープンするアプリケーションです。
Mac App Storeの審査に10日かかって焦りました(機能のコンパクトさに反比例して審査期間が長い。たぶん、開発期間よりも審査期間の方が長い)。
すでに、他のChromiumベースのWebブラウザ「Brave」と「Vivaldi」への対応が済んでおり、次のアップデートでこれらにも対応します。AppleScript用語辞書(sdef)を持っているWebブラウザであっても、do javascript的なコマンドが実装されていないと、本アプリケーションでは対応できません(FireFox、Opera)。まして、AppleScriptにまったく対応していないWebブラウザでは、対応のしようがありません(Sleipnirなど)。
4つのアプリケーションをコントロールするアプリケーションをMac App Storeに申請したのははじめてです。
そろそろ、Script EditorとScript DebuggerをコントロールするアプリケーションをMac App Storeに申請することに。これも、審査が荒れる(期間が長くなる)ことが見込まれます。
Mac App Storeに新アプリケーション「Rename by contents」を提出しました。Now On Saleです。
論文PDFのリネーム用ツールであり、「PDFの1ページ目の一番大きな文字の文をファイル名として採用する」というものです。macOS 10.13以降用で、Intel 64バイナリでビルドしてあります。全部AppleScriptで書いてあるので、ARM 64e向けにビルドし直すのもとくに問題ありません。
このアプリケーションほか、小物アプリケーションをMac App Storeに提出する方向で作業をすすめていますが、今回の審査は一番手間取りました。割と日常的に使っている小物アプリケーションは、小物アプリケーションらしくいろいろUIの味付けを変えているのですが、そういうアレンジしている部分を「HIG(Human Interface Guideline)に反する」という理由でリジェクトされました。
たとえば、こうした小物アプリケーションの場合に、メインウィンドウを閉じられたくない(処理がめんどくさいから)という事情があり、メインウィンドウのクローズボタンを無効にしていることがよくあります。
ウィンドウさえクローズされなければ問題は発生しないので、クローズ機能自体にフタをしてしまえばよいという話です。ただ、HIGの原則からいえば「クローズボタンがないのはダメ」なので、Mac App Store版のアプリケーションではこの「クローズボタンの無効化」は禁じ手ということになります。
クローズボタンを有効化して、メインウィンドウが閉じられたらアプリケーションを自動終了させる処理をコピペで書き足して、最終的にリジェクトを回避できました。
ちなみに、これとほぼ同時に作りはじめた別のアプリケーション「Foreign Love」(指定アプリケーションを他の言語環境で起動)は、現行のSandboxの仕様上、Sandbox環境では機能を発揮できないことが判明してオクラ入りしました。
ほかにもこまごまとしたリジェクト理由でAppleのレビュー担当(名前は知らない。毎回違うはず)とやりとりしていましたが、正直なところ小さいアプリケーションをMac App Storeに通すほうが大変な気がしました。ただ、この手の申請作業に慣れてきたような気がします。
あと、XcodeのOSACompile ビルドオプション、「Save as Execute-only」でデフォルトだとビルド時に「ソースを開示したままビルド」になっているので、AppleScriptのコードを全表示させたビルドをさせようとするのに何回も煮え湯を飲まされました。とても怖いdeath。
現在Mac App Storeで販売中のKamenoko v1.1には、Mac Pro 2019上でだけ症状が確認されているバグへの対策機能が盛り込まれています。
Mac Pro 2019は三角関数の簡単な計算を間違える「問題マシン」として認識しています(実機ないんで、細かい挙動はわかりません)。
「おそらくこう対策すれば回避できるはず」と想像された方法で機能を実装し、v1.1を動かしたMac Pro 2019ユーザーの知り合いから「大丈夫」との実機確認報告をいただきました。
▲Mac Pro 2019上でのみ報告されているHex Grid座標計算バグ(Kamenoko v1.0+macOS 10.15.5?)
Mac Pro 2019上でのみ、この6角形セルの座標計算でミスが生じることが報告されています。この座標計算はJavaScript Coreの機能をAppleScriptから呼び出して行なっているもので、このJavaScript Coreの関数演算で計算結果に誤差(ないし、想定外の高い計算精度)が発生。
このため、Kamenoko v1.1ではMac Pro 2019対策として各六角形の座標値をあらかじめ計算し、固定データとして保持して使用しています。内部的には、起動時に座標値をすべて計算してNSBezierPathを作ってキャッシュして(作成後の変更なしに)使っていたので、とくに処理フローが大幅に変わったわけではありません。
▲Mac Pro 2019上で動作しているKamenoko v1.1の想像図(実機ないんで)
この関数演算バグがMac Pro 2019上でのみ発生するものなのか、それともXeon搭載機で同様に発生するものなのかは未確認です。
Mac App Storeに「Kamenoko」の本命と位置付けているv1.1をアップロードしました。Mac App Storeへのアップに何も問題なく終わったということはなかったので、今回も何回かのやりとりが必要と思われます。
→ 今回はすぐにレビューを通過しました Now On Saleです
内容をほぼすべてAppleScriptで記述してありますが、本アプリケーションはScriptableではありません。それは、このv1.1でも同様です。
Kamenokoのアプリケーション設計段階で、本アプリケーションのAppleScript対応はあまり考えられませんでした。どちらかといえば、本アプリケーションの書類を一括で書き換えるなどの処理が適していると思われました。
このためには、書類操作用のAppleScriptライブラリを内蔵し、それをAppleScriptで呼び出すスタイルが適していると思われました。
本バージョンもまだAppleScript Libraryは内蔵していませんが、今後のバージョンでの対応を行いたいところです。なぜなら、もう単体でライブラリ自体は動いているからです。
Q&Aサイトでいろいろ答えた内容(自分自身のみ)をまとめて本にしてみました。ぴよまるソフトウェアBooks初の雑文系縦書き新書!(500円)
ぴよまるソフトウェア創設者である筆者は、元雑誌編集者。あふれるバイタリティと文章の力、そして新開発のアイデアを練るアプリケーション「Kamenoko」の威力でQ&Aサイトで1か月5万ビューの回答を繰り出した! 筆者による回答を再編集し、読みやすく縦書きの新書っぽい形にまとめた本書。全257ページ、38の珍問答。Macとガンダムに極端に強い筆者の、幅広そうで偏った知識がうなる渾身の一冊!
Kamenokoの事例集(作例集)、と見ることもできます。とにかく、毎日Kamenoko上でいろいろあーだこーだとアイデアを練って、こねて、まるめているので(本人向けに作ったので、本人にはめちゃくちゃ合っています)。
→ 製品版
→ お試し版
■航空機は一発食らってもやばいのに、どうしてガンダムは攻撃を耐えしのぐのか?
■AppleのCEO、Tim Cook氏は辞任すべきではないか?
■ファーストガンダムって何が凄いの?
■ソフトバンクの後継者問題について
■ガンダムのような巨大人型ロボットは兵器として有効か?
■いつもPCのディスク容量が足りないと嘆いているプログラマーがいます。プログラミングってそんなに多くの容量を使うのでしょうか?
■iMacは吊るしで買って数年で入れ替えるのとフルスペックで長く使うとどちらが理想的?
■コーディングを速くするには?
■勉強になるオススメのアニメや漫画はありますか?
■Macintoshで一番悩み苦しんだ出来事は?
■パソコンのディスク容量を圧迫すると実感するものの、なくてはならないツールやソフトは何ですか?
■AppleはMac Proがチーズグレーターに見えると人々が指摘することを予想していたか?
■楽しさを思いっきり表現してください
■テクノロジーが色彩(カラー)を決定している例は?
■自動車のワイパーを再発明してもらえませんか?
■MacとWindows、どちらの方が生産性が高いですか?
■どこでもドアは実現可能ですか?
■五分でめっちゃ成長する方法は?
■MacBookのアプリの閉じ方は、左上の赤い×ボタンを押すのであってますか?
■近年、サザエさんやドラえもんのような国民的長寿アニメが生まれていないのはなぜ?
■一切プログラミングの学習・経験を積まずに情報工学科の大学に進学した場合、将来エンジニアとして働けるでしょうか?
■1970年の人々にとってSFのように見える2020年のテクノロジーは何でしょう?
■ガンダムに出てくるもので一番実用的なものは何ですか?
■四十歳を超えたド素人のサラリーマンが、資料作りやホームページ作りでのデザインスキルを付けるにはどうするのが効率的でしょうか?
■エクセルの達人が複雑なマクロを作り大幅な業務効率化を達成したのですが、その人が転勤してしまい誰もエクセルのメンテナンスが出来ず元のやり方に戻りました。この事態に名前をつけるならどんなのが良いですか?
■MacのJISキーボードを使っています。Shift+0にアンダースコア(_)を割り当てるにはどうすればいいですか?
■なんで、スマホにストラップがつけられないようになったのでしょうか?
■プログラミングって賢くないと無理ですか?
■プログラミングでマウスや矢印キー以外でカーソルを移動させる方法はありますか?
■ARグラスでどのようなことができるようになると思いますか?
■パソコンがすぐ使えるようになる人とそうでない人との違いは何ですか?
■MacのことえりはAI学習機能ではないのですか? 繰り返し入力する単語でも、最初のいくつかの文字でさくっと候補に上がらないため、イライラしますが解消法はあるでしょうか?
■石に刺さった剣があります。どうにかして剣を取り出してくれませんか?
■もしガンダムでジオンがゲルググではなくギャンを次期量産モビルスーツとして採用していた場合、その後どうなっていましたか?
■子どもに「インターネットください」と言われたら、何て返事をしますか?
■アマゾンキンドルのテキストを、Macのスピーチ機能で読み上げることは出来ますか?
■なぜガンダムにはほとんど格闘戦だけのGガンダムはあるのに、逆に殆ど射撃、狙撃、砲撃だけのガンダム作品はなく、射撃+ビームサーベルなどを用いた格闘戦なのでしょうか?
This ebook “Switch Control with AppleScript” is a book about Switch Control. 89 pages (today). Price: JPY 3,000.
It is one of accessibility function for people with disabiulities. But it is very useful for every macOS users specially for the scripters.
Switch Control can launch AppleScript or run keyboard shortcut sequence. We can make button-based simple GUI for AppleScript. It is the easiest environent to make GUI.
This book will contain author’s sample Switch Control. It is useful and gives you a power of automation for macOS users.
▲supplement sample Switch Control Panel
知り合いがMac App Storeで買ったKamenokoを、
Mac Pro 2019の一番下のモデル(+Pro Display XDR)にインストールしたところ、画面の描画がおかしいという報告を送ってくれました。
▲左:開発環境で描画したところ 右:Mac Pro 2019で描画したところ
開発環境はmacOS 10.14.6ですが、macOS 10.13.6およびmacOS 10.15.4やBeta版でも動作確認は行っていました。しかし、手元のどの環境でも、こんな結果にはなっていません。
この6角形の描画については、JavaScriptCoreを呼び出して三角関数の計算を行っています(毎回計算しているわけではなく、起動時に計算した内容をキャッシュして使っています)。この計算結果がXeonとCore i7/Core i5/Core i3で異なるのではないかという「仮説」を立てています。
また、これまでRetina(Hi-DPI)表示は2xのRetinaだったわけですが、Mac Pro 2019ではこれが違っており、描画がその影響を受けている可能性もあります(だったらウィンドウなどの描画も間違うはずなので、多分これはないかなー)。
ただ、いずれにせよMac Pro 2019実機で検証を行う環境が手元にないため、仮説の検証を行えない状態です。
MacScripter.net上で三角関数の計算結果について、同じ計算結果が得られないといった話をされたことがありますが「そんなバカな」と思っていました。もしも、その時の相手が使っていたマシンがXeon搭載機だった場合には、JavaScript Coreを呼び出して三角関数の計算を行った場合に、環境によっては結果が異なるという話になるのかも?
現段階ではなんともいえませんが、さすがにDTSにサポートを依頼すべき内容かもしれません、、、