リファレンスマニュアル閲覧用の Chemr だけど、ベースの Electron を1.2.1にバージョンアップした。

しかし codesign するとあいかわらずフリーズするので改めて調べてみたら Console.app に以下のようなログがでていた。

 sandboxd[131]: ([19968]) Chemr Helper(19968) deny mach-lookup org.chromium.Chromium.rohitfork.19966
 sandboxd[131]: ([19973]) Chemr Helper(19973) deny mach-lookup org.chromium.Chromium.rohitfork.19966
 sandboxd[131]: ([19974]) Chemr Helper(19974) deny mach-lookup org.chromium.Chromium.rohitfork.19966

ググってみると Electron broken on OS X in Apple Sandboxed apps (App Store) · Issue #3871 · electron/electron · GitHub あたりの問題のようだ。

Sign Your App のentitlements あたりに変更が必要になった模様。

長いので結論だけ書くと以下のようにすればなおった。electron-packager を使っている前提で

Team ID を取得する

Apple Developer Center にいくと、Membership Details に Team ID という項目がある。

あるいはコードサイン用に Key Chain に自分用の証明書を入れていると思うが、その証明書名の括弧の中の文字列がチームIDとなっている。

追加の Info.plist を作る

<plist version="1.0">
<dict>
	<key>ElectronTeamID</key>
	<string>$TEAM_ID$</string>
</dict>
</plist>

こんな感じで Info.plist を作っておく、不完全なファイルに見えるが、残りは electron-packager が埋めるのでこれで良い。

こうした上で electron-packager に --extend-info=dev/Info.plist をつけて実行する。

entitlements ファイルの更新

parent.plist を以下のようにする。com.apple.security.network.client は今回の件とは関係なく、Chemr に必要なのでつけているだけで、必須ではない。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.network.client</key>
    <true/>
    <key>com.apple.security.application-groups</key>
    <string>$TEAM_ID$.net.lowreal.Chemr</string>
  </dict>
</plist>

child.plist は以下のようにする

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.inherit</key>
    <true/>
  </dict>
</plist>

codesign

electron-packager にも codesign のオプションはあるが、使ってない。electron-osx-sign を直接呼びだしている。

./node_modules/.bin/electron-osx-sign --no-pre-auto-entitlements --version=1.2.0 "$APP_PATH" --entitlements=dev/parent.plist --entitlements-inherit=dev/child.plist --identity="$APP_KEY"

こんな感じで、上記 entitlements ファイルを指定して codesign させる。

なお electron-osx-sign の 0.4.0-beta4 以上だとこの entitlements の処理を自動でやってくれるみたいだが、なんとなく自動的にやるのが信用ならないのでこれはつかってない。

備考

使ったツールのバージョン

  • "electron-osx-sign": "^0.4.0-beta4"
  • "electron-prebuilt": "1.2.1"
  • "electron-packager": "^7.0.3"
  • electron-packager に渡す --version の値: 1.2.1 (新しいものじゃないと ElectronTeamID に対応してないので注意)

証明書なしでサンドボックスアプリとして実行したい

デバッグのため、とりあえず証明書なしでサンドボックスを有効にしたい場合、ad-hoc signing でも動かすことができた。これは identity に - を指定することでできる。

すなわち

./node_modules/.bin/electron-osx-sign --no-pre-auto-entitlements --platform=mas --version=1.2.0 "$APP_PATH" --entitlements=dev/parent.plist --entitlements-inherit=dev/child.plist --identity="-"

のようにする。おそらく Team ID は一致さえしていればなんでもいい(と思うが試してはいない)

備考 electron-osx-sign を verbose にする

環境変数 DEBUG を設定すると詳細なログがでるようになる。DEBUG='electron-osx-sign' これは debug という npm パッケージを使っているため。

  1. トップ
  2. tech
  3. codesign した Electron アプリがフリーズするのを修正

リファラを眺めていると Qiita:Team らしきものが稀にあるけど、https 強制にしてないのかな。もちろんアクセスしても404なので実害はほぼないと思うけど、URL にユーザIDが入っているので場合によっては誰が言及しているかはわかることがある。

と思ったけどリファラがそもそも https だった。Referrer Policy で意図的に送ってるのかな。なんの意図かは謎だけど

今年から数えで30ということで検便、腹部超音波、胃バリウムが増えた。まだ30じゃないつもりだったので心構えができてなかくてめんくらった。

これらのうち胃バリウムはやらなかった。胃腸炎で調子がよくないのがあるが、問診の話だと胃内視鏡の隔年実施になるかもよとのこと。バリウムよりも内視鏡のほうが良いので、さっさとそうなってほしい。

最近 Google 関係のアプリが「バッテリを消耗させるアプリ」として通知されるんだけど、どうしろと

はぁ〜〜〜 不愉快だな〜ー〜〜〜〜ー〜 なんで不愉快なことばかり起こるのか

わかりやすい神道の歴史 - 神社本庁研修所

神社本庁研修所

5.0 / 5.0

そういえば、この本を昨年の11月〜12月ぐらいに読んだんだけど、日記に書いてなかった。書いた覚えがあるんだけどな…… これを読んでさらに調べた結果 500 Can't connect to lowreal.net:443 (certificate verify failed) というエントリを書いた気がする。もともと古代人の神道感はどうだったのか?が気になって買ったが、これに答えはなかった (というよりも、現代では分かりようがないということがわかった) 神道の歴史と仏教は切り離せないし、神道の歴史と政治的な(具体的には天皇統治の)歴史も切り離せない。

近代以降の話はあまり興味がなくて、結構飛ばして読んだ覚えがある。


神社には生前偉業を成した人を祭っているところがあるが、現代人として自然対人間のような構造を持って見るとこれは不思議に思えることがある。実際には人間も自然の一部であると考えると不思議ではない。古代でも現代でも「すごい!」と思えるものは「神」と呼ばれている。大神神社の本殿が山そのものであったりすることからも感じられるけど、神道では人間はあくまで自然の(自動的な)仕組みの一部であることが当然のこととしてあるように感じる。

とにかく無限に下痢。

日記(ブログ)内のカテゴリを自動抽出して設定したい。いわゆるクラスタリングだと思うが、うまくできる方法がよくわからない。

動機としては「カテゴリ」とか「タグ」を設定するのが面倒なので、自動的にトピックを解析して「タグ」として抽出したい。既に TF-IDF は出しているので、上位を使えばよさそうな感じではあるが、IDF の対象が自分のエントリだけなので、一般的な「特徴語」とは違った結果になっている。

機械的にやるよりも例えば「電子工作」なら「Raspberry Pi」「電子工作」「回路」とかを含む全てのエントリを適当に検索して出せばいいだけかもしれない。かなりヒューリスティックなので自分にとっては「新しい発見」はないが、検索流入の場合は狙った似たトピックに辿りつきやすいかもしれない。

宗教とは結局のところ人生の規範を作るためのフレームワークといえよう。各宗教のことは良くしらないので怒られそうだけど、主観的には以下のような印象を持つ

  • 密結合フルスタック: アブラハムの宗教
  • 便利ライブラリの集合:仏教
  • コーディングルールのみ: 神道
  • フレームワークなし: 無宗教

なんにせよ「人生の規範」というのがある。規範なしでただ生きているという状態にはなりえない。

人間もまた自然の一部であり、心のありかたもまた自然である。自分の心をあるがままにしておくというのは自然で、制御しようというのは自然との戦いとなるが、一方戦いを行おうというのも自然のありかたである。

これは単にバランスの問題であって、どちらか一方に偏ってはいけない。「あるがまま」に成長はない。「自然との戦い」は消耗戦で、最終的には負け戦になる。