ししおどし

Inkscape (0.92.5) の macOS 版は MacPorts 版を使うべし。 MacPorts 版の Inkscape をインストールするには、もちろん、， MacPorts 自体 をインストールして使えるように準備しておく必要がある。.pkg のインストーラーが使えるので、難しくはないはず。 そして、MacPorts によってインストールするのは、Inkscape だけでなく、X.Org Server も必要になる。 sudo port install inkscape sudo port install xorg-server これで一旦再起動する。X.Org を先に立ち上げてから、ターミナルで inkscape コマンドを実行すれば Inkscape が立ち上がる。 起動時の警告 起動時に、ターミナル画面に警告メッセージが表示されるが： Dynamic session lookup supported but failed: launchd did not provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded! Failed to get connection dbus とやらのセットアップに関するもののようなので、sudo port load dbus による指摘に従えば解消できる： port notes dbus dbus has the following notes: Startup items (named 'dbus-system, dbus-session') have been generated that will aid in starting dbus with launchd. They are disabled by default. Execute the following command to start them, and to cause them to launch at startup: sudo port load dbus つまりこの場合 sudo port load dbus を実行して一度セットアップしてしまえば、以後...

旧 Mac（MacBook 12inch Early 2015）から新 Mac（MacBook Air M1）へメールアカウントを移行した。IMAP なので、データをエクスポート＆インポートするような必要はなく、新 Mac 側でメールアカウントをセットアップするだけである。それもメールアカウントの設定自体、iCloud で管理しているので、新 Mac 側で iCloud へサインインした段階で復旧される。 メールの動作に不具合が発生 ところが、メールの動作に不具合が発生した。削除したはずのメールが何度も何度も受信ボックスに戻ってくる。 仕方ないので、一旦メールアカウントを iCloud に保存された設定も含めて削除して、改めて手動で設定し直した。すると問題は解消された。 IMAP アカウントの設定 Gmail などのテンプレートにあるアカウントの場合は問題ないと思うが、その他の一般の IMAP アカウントを設定する場合、デフォルトでは、メールボックスの設定がうまくいっていなかった。メールサーバーに元からある受信・送信済・ゴミ箱・迷惑メールが使われず、新たなメールボックスがそれぞれ作られてしまうので、手動で設定し直して、重複するものを削除する手間が必要だった。 @sakura.ne.jp（独自ドメインメール）: IMAP を使っているのでポート番号などのサーバ設定等は細かく設定し直す必要があり、単に iCloud からの復旧されたデフォルト設定のままでは上手く機能しない。旧マシン（macOS）の各設定画面を記録しておいてそれを参考にすると復旧しやすい。 @gmail.com: メールボックスなどの反映に少々のタイムラグがある。そのままでも大丈夫だと思うが、メールボックスの割り当ては再設定し直した方がより確実かもしれない。 署名の設定 署名もデータ自体は残っているものの、アカウントとの紐付けが復元されなかったので、改めて手動で設定し直す必要があった。すべての署名からアカウント毎にドラッグして移動した上、「署名を選択」で該当署名を選択しておくことで、メール作成時に自動で署名が入るようになる。

新しい Mac（MacBook Air M1）を入手して移行作業が終了したので、これまで使っていた MacBook 12inch（Early 2015）の方は初期化することにした。ディスクユーティリティで Macintosh HD を一旦消去してから、Big Sur を再インストールしようとしたが、その時はネットワークが遅かったせいか中々進まなかったので後でやり直そうと思い、電源を切った。そして改めて再インストール作業をしようと立ち上げたところ、Macintosh HD 自体を消去してしまっているため、macOS 復旧プログラム自体が起動しない状態になってしまっていた。まあ、ある意味当然と言えば当然である。 初めてこのような経験をした時は青くなったものだが、今は特に致命的ではないことを知っているので冷静に インターネットリカバリーモードで起動 する。ただし、この場合は macOS 復旧プログラム自体をネットワークからメモリーに読み込んで起動して行うことになるので、途中で作業が失敗して中断してやり直したりする場合は、最初の macOS 復旧プログラムをネットワークから読み込む段階からの再開となる点に留意したい。致命的ではないものの、それなりの手間（時間）のかかる作業となるのである。 リカバリーモード には次の 3 種があるわけだが： Command + R（Macintosh HD からのブート） Option + Command + R（最新 OS のインターネットブート） Option + Shift + Command + R（購入時 OS のインターネットブート） (1) は Macintosh HD を初期化してしまっているので当然使えない。使えるのは (2) か (3) だが、(3) だと購入当時の旧い macOS 復旧プログラム（Yosemite）のものが使われ、APFS にすら対応していないので、やはり論外。(2) だと Big Sur 用の復旧プログラムが使われるので、これを選ぶ。 ※ この macOS 復旧プログラムのネットワークブートは、回線の繋がりがあまりにも悪いと、-2006F エラー等でブート途中で失敗してしまうことがある。回線の繋がり方にも、モバイル回線のせいや、Apple のサーバーのせいなど、様々な要因が...

Linux 時代から使っていた f.lux だが、macOS で Night Shift が導入されてから、使わなくなっていた。 しかし、Night Shift を使い続けてきて、結局、「日の出と日の入りのタイミングの切り替えしかできない」という点が不満になってきた。それで久し振りに f.lux を使ってみたら、「Movie mode」という、夜の時間帯でも一発で通常の色表示に戻せる機能が実装されているのに気付いた。まさしくこれまで動画を観るたびに、Night Shift を手動で Off していたので、求めていた機能である。当然、f.lux に戻ることにした。

MacBook 12inch (2015) では、OS を Big Sur にアップデートして、GIMP や Inkscape のインストールに苦労していた（通常のパッケージでは重かったりして正常に動作しないので、MacPorts 版を使ったりした）が、MacBook Air M1 では、今試してみたところ、通常のインストールパッケージを入れて普通に動作している。 ただし、ちょっと使ってみただけなので、細かい使い方をすると、不具合はあるかもしれない。

遅ればせながら、MacBook Air M1 (16GB / 512GB / US-KBD) を入手（4/2 発注、4/7 受注、4/13 着便）し、新品なのに早速 HD を初期化して、APFS を case-sensitive 化！──しようとして、ハマった……。 これは恐らく M1 Mac かどうかは関係がなく、macOS Big Sur の問題だと思う。 Big Sur の再インストールができなくなる！ リカバリーモード（起動オプション）の中のディスクユーティリティーで、元々の Macintosh HD を消去し、改めて APFS + case-sensitive + 暗号化でフォーマットする。すると、Big Sur の再インストールが、「暗号化されているせいで、できません」となる。 焦って、再度 Macintosh HD を APFS + case-sensitive（非暗号化）でフォーマットし直す。すると、Big Sur の再インストールが、「認証するユーザがいません」となる。アクティベーション・ロックがかかって、Macintosh HD に対する再インストール操作ができないような状態になる。 お手上げ状態。情報を検索すると、Apple の サポートフォーラムの記事 を見つけた。 コンテナ disk を消去せよ デフォルト状態では Macintosh HD などの論理ディスクしか表示されておらず、これだけをいくらフォーマットし直しても、暗号化や「認証するユーザー」を管理している部分は初期化されていないので、本当の意味の初期化にはなっていないのである。このあたりのことは、Apple の 公式 KB では全く触れておらず、単に「左側のリストでディスクを選択し、「消去」ボタンをクリックします。」としか書いていない。コンテナディスクと論理ディスクの違いや、デフォルトで表示されているのが論理ディスクである件には触れていないので、これは Apple の公式 KB の欠陥である。 デフォルトでは論理ディスクしか表示されていないので、まずは「すべてのデバイスを表示」させてから、コンテナディスクを選択する必要がある。 また暗号がどうのと言われると嫌なので、暗号化は後回しにして、APFS + case-sensitive でコンテナ ...

一時期 スマートバナー を推奨していたかと思えば、結局は廃止して、 アダプティブバナー が登場した AdMob 。これまで何とな〜くで、アダプティブバナーを使っていたのだが、より最適化した使い方をするために、一度本格的に突っ込んで調べてみることにした。 公式の説明らしい説明は、 https://developers.google.com/admob/android/banner/adaptive だけで、あとは API リファレンスが投げ出されているのみ。AdMob に限らず、Google さんのいつものことで、正解（最終結論）だけ示して、途中過程が何もない数学の解答みたいな感じというか。 加えて、日本語訳はさらに実際の API の開発に絡んでいない、日本の Google スタッフが翻訳している感じなので、余計に謎が深まるわけで。 アダプティブバナーのサンプルコード その公式解説に掲げてある サンプルコード だが、よくわからないので、これまではほとんどそのままのスタイルで書き写して使っていた。特に謎なのが、 AdSize.getCurrentOrientationAnchoredAdaptiveBannerAdSize を使っているあたり。Android の API と違って、AdMob の API はソースコードが公開されているわけではないので、中で何をやっているのかがわからない。 それで、テスト用のアプリ ID とデバイス ID を使って色々テストしてみたが、結局、この AdSize.getCurrentOrientationAnchoredAdaptiveBannerAdSize はあくまでもオマケ機能であって、アダプティブバナー的には必須の部分ではないのだということがわかった。 Google が教えてくれないアダプティブバナーの本質的な使い方 要するに、 アダプティブなわけだから、任意の好きなサイズの AdView を用意するだけで良い 。 つまり、「アダプティブ」というネーミングをした段階でそこは既に解説済。何ひとつ語る必要なし。小学生じゃあるまいし、語らずともわかるよね〜？──というのが、Google の開発チームの原語版の解説を執筆した人たちの感覚なわけだろう。 で、さっさとプラスアルファの機能を盛り込んだサンプルコ...

今さらながら Android の OpenGL ES に初めて手を付けてみた。これまでは ImageView の onDraw のカスタムか、ゲーム的なものでも、2D で SurfaceView の画面を丸ごと FrameBuffer として更新するような使い方しかしてこなかった。ところが今回、ちょっと凝った 2D のマップアプリのようなものを作ることになり、先述の通り従来は ImageView の onDraw カスタムで対処してきたのだが、できれば、SurfaceView か、さらには OpenGL ES 化して、Google Map のようなヌルヌルしたものにできないかと思い、3D 用だと思って敬遠してきた OpenGL ES の領域にまで足を踏み入れてみることにした。 SurfaceView 以前、使ったことがあると言っても、ちょっとした 2D ゲームのサンプルで使った程度であり、非ゲームのアプリに利用するというような場合も含めて SurfaceView 自体を研究したことはなかったので、まずは SurfaceView をいじってみることにした。 レンダリング用スレッドを使用する Activity 側で SurfaceHolder.Callback を implement するなりして、レンダリング用スレッドの生成や終了処理を行う。レンダリング用スレッド中では、SurfaceHolder を通じて Surface への（Canvas の描画命令を使った）描画を行う。 Canvas → SurfaceHolder → Surface という 3 重のバインド構造になっているの（ 参考 ）で初見では戸惑うかもしれないが、やっていることは Surface（framebuffer のようなもの）へのデータの書き込みである。 val canvas: Canvas = holder.lockCanvas() // Canvas#drawBitmap 等を使った描画処理 holder.unlockCanvasAndPost(canvas) レンダリング用スレッドを使わないで、そのままメイン UI スレッドで同様のことを行うこともできるが、圧倒的に処理が重くなる。SurfaceView を使う意味がない。 SurfaceView を使うこと...

YouTube でたまたまこちらの動画 を見かけたのがきっかけで興味を持って読んだ、宮崎正弘『明智光秀 五百年の孤独』（徳間書店、2019）。 動画の印象では「織田信長によって日本がキリスト教化の危機にあり、それを憂えた明智光秀による義挙が本能寺の変の真相である」ということで、「明智光秀と反キリスト教化」「織田信長とキリスト教」を結び付ける説に新鮮味を感じたので、どういうことなのかと思ったわけである。 織田信長とキリスト教の関係 まず、「織田信長とキリスト教」の関係について。これは特に期待したようなものではなかった。織田信長がキリスト教に寛容だったことや、一方で一向宗や比叡山と対立していたことはなどは従来から知られている話である。信長は宗教に興味があったわけではなく、鉄砲等の実益からキリスト教の宣教師たちに寛容だっただけ。基本的にイデオロギーには無頓着な信長だっただけで、キリシタン大名のように、特に日本をキリスト教化しようと意欲していたわけでもない。動画の印象では、実は信長もキリシタン大名だったという隠れた事実を説いているのかと思ったが、実際はそうでもなく、著者の宮崎の説に何ら目新しいものはない。 著者の国粋主義的イデオロギーの明智光秀への投影 一方、著者の宮崎は、明智光秀の本を書いても、結局は著者自身は（保守右翼系の）イデオロギーの人である。明智光秀を国粋主義的イデオロギーの人として捉え、評価するというのがこの本の主旨と言っても過言ではないだろう。実際の明智光秀の歴史的考証が主旨というより、ともかく、明智光秀を通して国粋主義的イデオロギーを説くのが、この本の主旨のような印象を受けた。 つまり、信長は天皇を頂点とする日本の精神文化というイデオロギーに無頓着で、結局は、織田家の権力を伸張すればいいという感覚だった。しかしその一方で、キリスト教が日本人の精神に浸潤し、一方で万世一系の皇室がないがしろにされることに対しても、信長はこれといった禁忌感は抱く性質の人間ではなかったし、そのような危険人物であると、明智光秀や細川藤孝、公家・皇室は思った。であるから、暗殺・クーデター等の手段に訴えてでも、未然に阻止せねばならない。つまり、明智光秀の本能寺の変は、大塩平八郎や西郷隆盛に類せられる義挙であると。 つっこみどころ 宮崎は、義挙の人として...

10 ヶ月前の記事「 LVMC (a.k.a. MVVM: ViewModel + DataBinding) と Fat View 」でも、Activity からコードを追い出すのに夢中になっているうちにいつの間にやら Fat View になってしまった話をしたが、最近また同じ症状に陥ってしまった。 今回の場合は、「Activity からコードを追い出す」という状況ではなかったせいもあって、当初気付かなかったのだ。 ImageView に Glide を使ってネットワークから画像を読み込む機能を追加した自前のライブラリーモジュールを作っていて、ViewModel から DataBinding を通じて url 文字列さえ与えれば、ImageView が url から読み込んで表示する。そんな風な設計にしていたのだが、「ライブラリーだし、色々なプロジェクトで使い回す場合に、少しでもコードを省けるように」と、Glide を利用したネットワークからの読み込み処理の部分を、ImageView を継承したカスタム ImageView に追加で盛り込んだ。 しかし、正解としては、ViewModel から DataBinding を通じて与えるのは、url ではなく、Bitmap の方が良い。というのも、そうすれば、ImageView は、それがネットワーク上の画像なのか、ローカルにあるリソースなのか、を意識せず、ただ、layout.xml の app:bitmap="@{viewModel.bitmap}" を見て反応すればいいだけである。url 文字列ならダウンロードする、ローカルなら setImageResource() する、などと処理を分岐させる必要がないのである。 当初 url で実装した時には、わざわざ loadImageUrl() なる専用のメソッド・プロパティを用意して動作するように実装したが、後でローカルの画像を使おうとした場合に setImageResource() と使い分けなけばならないことに気付いて、url 文字列ではなく Bitmap をデータバインドして ViewModel と連絡すべきだと気付いたのである。 もちろん、そうなると、ViewModel 側で Glide を使ってネットワークから画像をダウンロードする部分...