投稿者「wt」のアーカイブ

4DアプリをNotarizeするぞ、Catalina対応

これまで4Dアプリは、署名つきビルドをすれば、macOS Mojaveまでは、control+クリックで「開く」を選択すれば、実行することができた。

macOS 10.15 Catalinaは厳しい。Appleのいうところの「notarize」をしていないアプリをダウンロードして実行しようとすると、Controlクリックだろうが環境設定のセキュリティでなんとかしようとしても開けない。異常終了させられる。同じアプリをビルドしたマシンで起動させれば正常に動くし、USBで持っていけば別のマシンでも正常に動くのに。つまりアプリそのものは実行可能であるにも拘わらず、ネットから落としてきたというだけで悪者アプリのレッテルを貼ってくれる。

で、notarize。参考資料はここ↓、さすがです。

https://www.rk-k.com/archives/3458

xcodeでビルドするアプリはxcodeがこの辺りを上手いことやってくれるので、実際に何が行われているかはわかりにくい。アールケーさんありがとうございます。ターミナルコマンドでやってくれているのが助かります。4Dアプリにとっては必須ですので。

ここからは4Dアプリの場合：

4D v17.3で署名つきでビルド。まず拡張属性を取り除こう。特にResourcesフォルダとかにネットで管理しているテキストファイルとか画像ファイルを置いている場合は要チェック。まず

xattr -rc 「パス名」

これで「パス名」の中のフォルダの中まで拡張属性を取り除いてくれる。次に4Dをアプリケーションビルド。

治郎吉商店では、できたアプリとデータファイルなどをバンドルして出荷するので、出荷前にアプリを起動してデータファイルを作成。できた出荷用アプリを複製してデータファイル作成用アプリを作って起動。データファイル作成後は複製したアプリを削除。

出荷フォルダには「お読みください」などのファイルを配置。できたフォルダが次。

これをディスクユーティリティの機能でdmg化する。ターミナルを起動して、次を実行。圧縮のオプションを使っている。

ここでも拡張属性に注意。「お読みください」などのファイルを誰かに編集を依頼して、ネットで落とした場合は拡張属性がついてしまうのだ。codesignに失敗することになる。

次はnotarize

このコマンドは成功する時が長い。dmgよりも長い。何も表示されずいきなり終わる。

これでできたのをzip圧縮する。なぜかWordPressのサイトにdmgがアップできないからね。しばらくすると（数分？）Appleからメールが来る。

ShareDocにアップして、別のCatalinaマシンで試す。Catalinaで動いた！ちなみにアップしたマシンはMojaveでした。

4Dでバーコード

4Dアプリでバーコードを作成することになった。で、調べてみるとgithubにありました。プラグインとコンポーネントの両方があったので、まずコンポーネントを試すことに。プラグインよりもコンポーネントの方が4Dのバージョンとの互換性的がありそうなので。

https://github.com/miyako/4d-component-barcode

//JANコード（SVGピクチャ）を作成

$bar:=Barcode_create ($code;”EAN13″)

確かにできた、けどEAN13とCode_39はできたけど、他の３つはできなかった。

バーコードスキャナー opticon C-41で試したところ、画面に表示されたEAN13には反応したが、Code_39には反応しなかった。

Damian ‘Jr. Gong’ Marley: NPR Music Tiny Desk Concert

バックのSherieta Lewis、

クラウドサービスを使ったファイル共有の弱点

【容量】　ファイルサイズ、利用合計容量に制限がある。

【保存期限】　保存期限が短い。

【メールアドレス】　メールアドレスによる登録が必要なことがある。

【画面レイアウト】　画面レイアウトを自社用に変更することが難しい。

これらの問題を解決するには　→　ShareDoc（ドキュメント共有システム）

ファイルサーバの問題点

ファイルサーバについての考察。ずっとファイルサーバを使ってきた。手元のパソコンのデータをバックアップしたり、別のマシン・別のスタッフが再利用するためだ。一方ShareDocというインターネット上のファイルサーバがある。スタッフのリモートワークが多くなり、ファイルサーバよりShareDocを使うことが多くなってきた。ファイルサーバの長所短所を考察してみた。まず長所から。

【セキュリティ】　社外からはネットワークプロトコルを遮断することでアクセスすることができない。

【格納が簡単】　ファイルサーバのボリュームをマウントして利用する。格納先はパソコン起動時にすでにデスクトップにマウントされていたり、フォルダごと保存できるのもいい。

【ライブラリとしての機能】あらかじめ設計されて周知されたフォルダ構成、保存ルールを元に利用者がファイルを保存しているため、出来上がったファイルサーバは使いやすいライブラリになっている。過去のファイルを探す場合などに威力を発揮する。検索システムがなくても短時間で必要なファイルがまとめて手に入る。

【高速アクセス】　インターネット経由でのファイルコピーよりも高速に保存したり取り出したりできる。

【直接開く】　ファイルサーバ上のファイルを直接開くことができる。デスクトップにコピーしなくても良い。

【容量無制限】　インターネット上にディスクを確保するよりも安価に大容量ハードディスクを設置できる。一杯になったらハードディスクを増設するなど、拡張させることができる。

次はファイルサーバの短所。

【ファイルサーバの使い方】　導入時にボリューム全体の階層構造を設計、ファイルの格納場所・名前の付け方など、社内ルールを定めておくことになる。ユーザにはこのルールの理解が求められる。

【インターネットアクセス】　セキュリティー上の理由から、ファイルサーバは社内のLANからのアクセスを前提としている。社員が自宅や出先から使うのが難しい。

【社内の人とファイル共有】　別の人に知らせるには、ファイルサーバのどこに保存したかを教えたりする。保存場所のフォルダを開くと、ファイル名やタイムスタンプが新しくなっていたりするのでそれを手元にコピーして使う。

【社外の人とファイル共有】　ファイルサーバを使って取引先などとファイル共有することは基本的にできない。配布の手段を別に考える必要がある。AppleのX ServerでFTPサーバを用意して、送り先のユーザをその都度FTPに登録してファイルを落としてもらっていたこともあった。

【インターネットユーザへの配布】ファイルサーバを使ってアプリやデータをネット経由で利用者に配布することは基本的にできない。

【ファイル管理】　アップされたファイルのどれが最新なのか判断しづらい。同じファイル／フォルダがいくつもアップされても気づかない。同じファイルが別のフォルダに入っていることがわかりにくい。誰がアップしたか分かりにくい。またダウンロードされたかは分からない。