piu lentoの日々 (piu lento days)

ずっと やりたかったものの、大変そうだから延期し続けていたことが半分くらい片付いた。

Joplinは結構使い勝手が悪くて早く排除したかったので、業を煮やして「ちょっと」思い付いたことを試したら※意外にうまく行ったので(これが いつもの嵌まるパターン)、その方向で進めたら(これも悪手だ!)やっぱり大変だった。が、常々イライラしていたJoplinから どうにか脱却できそうなので、うれしい。

※結構前に、どういうふうに進めるか・するかを考えて居たが、ちゃんとやるのは大変な感じだったので進まなかった。そこで、一旦それを棚上げして思い付きを試してみた。テキトーに作るのは良くないが、停滞状態を変えるには こういうこともアリなのだろう。そのあとが大変だが。

以前も書いたが、僕はJoplinをノートを書くために使っていない。MD(Markdown)で書くなんて面倒臭くてやってられないので、Zim(僕の改良版)で書いて※Joplinはスマフォ(サーバ)にノートを送ったり、画像をZimに貼り付けるためだけに使って居る。

※JoplinにもWYSIWYG編集モードがあるが、以前使ったら ひどいものだったので止めた。その他のWYSIWYGのMDエディタも僕には使いにくく、Zim(MDではない)だけが残った。

参考までに書くと、具体的な使い方は日々の買い物メモだ。それが90%以上だ。メモ用紙の削減に絶大な効果がある。詰まらないことだけど、例えば、日々変わる食品・日用品(例: レトルト食品)の有無・残量※は覚えられないし、紙に書いて更新・持参するのは非効率だ。

とは言え、紙のメモでなくてはならない場合もあるので、片方だけにすべきだとは思って居ない。適材適所だ。

※余談だが、ものの残量などを自分で調べてノートに打ち込むのは全くアナログだ。そこで、(半)自動で更新するようなシステムが便利そうだが、実現はなかなか難しい。冷蔵庫の中を調べる製品はあるようだが、そういうのでは全く不充分だ。

それから、良くあるアプリのパターンだが、それがスマフォだけでしか見たり更新できないのも不便だ。やっぱり、慣れたPCでも使えないと不便だ。もちろん、それらの間の転送も自動でないと面倒だ。

更に、気に入って使って居るのに、提供者の都合で勝手に改悪・終了されたりしたくないし、余計なお世話もされたくない!

それだけのことなのに、どうにも使いにくかった。Joplinや今までのシステムには以下の問題があった。

• サーバとの同期が遅い、おかしい。
  • 特にスマフォでは、設定していてもバックグラウンドで同期することがない。
    • 電池の最適化をoffにすればいいかも知れないが(以前試して駄目だった気もする)、電池消費が激しくなりそうだ。
  • ノートを見る時に手動で同期するしかないが、2回連続して同期しないと最新版が表示されない。
  • 同期が すごく遅い。
    • 何をしているか分からないが、同期が始まるまでが特に長い(体感で1-2分くらい)。
    • 上述のように それが2回必要なので、とにかくスマフォでの同期は嫌だった。
• スマフォアプリは使い物にならない。
  • 上の同期の問題以外に、遅い。大きなノートは まず開けない(実用的な時間では無理だし、大抵落ちる)。
  • 大きなノートのスクロールも困難。
    • 下のほうを見るには延々とスワイプし続ける必要がある。
      • ただし、ほとんどの他のアプリでも同様
• メモリの大食い(特にPC)
  • Electronアプリのため、複数のタブ(ノート)を同時に開くのは全く実用的でない。
• ディレクトリ構成が悪い。
  • すべてのノートの画像を一箇所(ディレクトリ)に格納しているため、僕の場合、そのファイル数が1万個を超え、負荷の増大や上述の同期速度の低下の原因になっていることが疑われる。
    • こんなに大きい画像ディレクトリはファイルマネージャでも容易には見られない。
  • この件以外にも、(技術的にはどうか分からないが、)システム構成を ちゃんと考えずに作った印象があり、将来性(ずっと使い続けられるか)は疑問だ。
    • 構成以外にも、独自のサーバを作ったりするのはいいけど、既存部分のサポートが いい加減な感じで、余り信用できない・付き合って居られない感じだ。
• DBが不便かつ大きい。
  • ノートの文章はDB(sqlite)に格納されているが、Joplinなどを介さないと開けず不便なうえに、大きい(100MB以上)ので厄介だ。
    • インクリメンタルバックアップの容量が増大する。
  • その割には、サーバにはノートごとに格納しているようなのが謎。
  • DBの構成を見ると、似たようなフィールド(カラム)が沢山あって理解不能。
• 勝手にバージョンアップして同期できなくなることがあった。
  • スマフォアプリのバージョンアップでサーバ内の構成が変わったらしく、PCにまで影響した。
    • PCのアプリには特にエラーが出ていなかったので、しばらく気付かなかった。
• (Joplinだけでなく、JoplinとZimの関係による) 画像がZimのノートに手軽に貼り付けられない。
  • 主にJoplinとZimのディレクトリ構成の違いによるのだが、一旦 画像をJoplinのノートに貼り、そのノートをZimにインポートして、そこから本来のノートに貼り付ける必要があった。

今までの処理の流れ

今までは以下のようにして、PCで書いたノートをスマフォで見ていた。

• PC
  1. Zim: 元のノートを書く。
  2. Zim+自作変換ソフト(zim2jop): ノートの更新を検出後、MDに変換してJoplinにエクスポートする。
  3. Joplin(PCアプリ): MD+画像をサーバに送る。
• スマフォ
  • Joplin(Androidアプリ)
    1. MD+画像をサーバから取得する。
    2. 取得したMDを表示する。

なお、ZimやMDでなく、一般的なアプリ・ファイル形式を使えば良いと思われるだろうが、PCとスマフォでの操作性の良さの両立や規格のオープンさ(その会社・製品に依存しないために重要)などを重視して検討した結果 こうなった。

例えば、Evernoteなどは反オープンの極みだし、Office(Wordなど)は(特にスマフォで)煩雑だし余りオープンでない。HTMLはオープンだけど使い勝手が今一つだ。各社のメモアプリ(例: Google Keep)は汎用性・柔軟性がないし、フォーマットがオープンでないので その会社・製品に依存してしまう。

新しい処理の流れ(脱Joplin)

今回、以下のようにしてJoplinを排除することができた。

• PC
  1. Zim: 元のノートを書く。
  2. Zim+自作変換ソフト(zim2md): ノートの更新を検出後、MDに変換してNextcloud(以下、NC)の同期ディレクトリに格納する。
  3. NCアプリ: MD+画像をサーバに送る。
  4. 自作同期プログラム(sync-zim-md-rem): MD+画像を直接スマフォに送る。 (7/31 6:09)
     • FolderSyncで定期的に同期させた時のスマフォの電池消費が気になったので追加した。 (詳細は後述)
• スマフォ
  1. FolderSync: MD+画像をサーバから取得する。 (通常は上述の自作同期プログラムでPCから直接転送されているので、不要になった。: 7/31 6:09)
     • Zettel NotesのWebDAVでの同期に問題がある(後述)ので、それが直るまでは これを使うことにした。
     • 定期的な自動同期の他に、手動での同期も可能※
       • ※同期を開始するウィジェットをホーム画面に登録できるので、手軽に同期できる。
       • 使っていて分かったが、どういう仕組みか不明なものの、Zettel Notesでノート一覧を更新(下にスワイプ)すると同期が始まるようで、本当にそうなら上のウィジェットも不要で とても便利だ。 (7/21 17:21) ← 残念ながら、単にZettel Notesの更新中のマークが出ていただけだったようで、FolderSyncで同期は始まらない。 (7/22 18:27)
  2. Zettel Notes Epsilon Notes: 取得したMDを表示する。
     • 注: Zettel Notesの正当性が疑わしいため、使用を一旦止めてEpsilon Notesに切り替えた。 (下の「気になること」も参照のこと) (7/31 13:52)

実装などのメモ

• このシステムではスマフォからPCへの逆同期も可能だが、スマフォで ちゃんと書く機会がほとんどないし、面倒で その気も起こらないので、今は実装していない。
  • スマフォでの簡単なメモは、(以前書いた)自作のメモシステムでPC(サーバ)に送れるので それで充分だし、書くたびに日時を手で入れる必要がないので便利だ。
• MDへのエクスポート時のノートと画像のディレクトリ構成
  • ノート内の画像は、基本的にZimのエクスポートの仕様に従い、ノートと同じディレクトリにあるノートのファイル名+"_files"のディレクトリに格納するようにした。 (例: ノートのファイル名が"test"の時、画像ディレクトリは"test_files")
    • この時、同名(だけど中身が異なる)ファイルとの競合※を防ぐため、ファイルの中身のダイジェスト(またはハッシュ)をファイル名に追加するようにした。 (例: "image.png" → "image_726fa81814c56c6e.png")
      • ダイジェストにはCRC64を使った。
        • CRC64を計算するコマンドは ほとんどないが、調べたら7zでできることが分かった。 (→ 参照)
      • ※このディレクトリ構成ではZimに添付できている画像のファイル名が競合することはないが、仮に画像ディレクトリを共通にした時に効いてくる。
  • ただし、Joplinから取り込んだ画像は、従来との互換性維持と区別を容易にするため、ノートと同じディレクトリの"resources"というディレクトリに格納する。
    • Joplinの画像のファイル名は既にユニークなようなので(UUID?)、ダイジェストは追加せず、Joplinのものをそのまま使って居る。
    • これらは、将来 完全にZimに取り込んだ時に、上記のディレクトリに移る予定だ。
• 更新されたノートの検出には、以前から興味があったinotifywaitを使った。
  • これにより、今まで無駄に定期的に(30秒にしていた)更新ファイルを検索していたのが不要になった。
  • また、ノートを書き込んでから変換を開始するまでの待ち時間※を、指定した値(今は3分にしている)に近付けることができた(ただ、そのメリットは余りない)。
    • ※書き込んですぐに変換開始すると、ノートの更新中に頻繁に変換することになって良くないので、こうした。
    • 待ち時間を実現するため、inotifywaitの出すファイル変更イベントの発生時刻とファイル名などをテーブルに保持するようにした。
      • 周期的なタイマーイベント(待ち時間の1/5にしている)やイベント発生時に、テーブルから待ち時間の経過したイベント(ファイル)を探す。
      • なお、イベントが頻繁に発生すると検索が無駄に多くなるので、前回の検索からの間隔がしきい値未満の場合は検索しないようにした。
    • この処理を独立のプログラム(スクリプト)にしたので、あとで何かに使えそうだ。
  • ただし、変換プログラムの起動時には前回の終了以降に更新されたノートが分からないため、従来の方法(指定時刻以降に更新されたものを検索)で検出している。
• zim2mdはシェルスクリプトで、ずっと普通のsh(実際はdash)を使っていたが、配列が必要になってbashにしたら、原因不明のエラーが出て困った。
  • いろいろなオプションを試行錯誤しても直らなかったが、POSIXモード(--posix)にしたらエラーが出なくなった。特にPOSIXを意識して書いた訳ではなかった(「普通」に書いた)が、どこかにPOSIXだけでしか使えない記述があったようだ(そもそも、何がPOSIXか知らないｗ)。
    • ひどいのは、エラーの行番号がズレて出るため、本当にどこが悪いのか分からなかったことだ。
  • 気持ち悪いが どうにもならないので、とりあえずPOSIXモード専用とした。bash以外に配列が使える(軽い)shellがあれば良いのだが。
• Zettel NotesやFolderSyncの電池消費が気になったが、頻繁に使わなければ問題なさそうだ。※
  • 電池の最適化のためか、スマフォが長時間スリープ中は同期間隔が伸びる(設定: 30分 → 3時間など)が、スケジュールなどと同様で、僕には好都合だ。 ← 使ってみたところ、どうやらFolderSync自体は きっちり間隔を守るようだ。長くなったのは、外から戻った時にWi-Fiがずっと繋がらなかったとか、一旦同期に失敗すると しばらく復活しないためではないか想像している。 (7/22 19:51)
  • ※その後、FolderSyncを動かしていると電池消費が高目(1%/h前後)になることがあるので、なるべく使わないような仕組みにした。別途または追って書きたい。 (7/27 17:28)
• FolderSyncのWevDAVの接続情報(URLなど)の設定は難しい(謎)。
  • WevDAVサーバを標準ポートでなく、またサブディレクトリにインストールしている場合、「サーバーアドレス」にポート番号とサブディレクトリ(/remote.phpの前まで)を含めたURLを、「ポート番号」にポート番号をそれぞれ設定し、「ファイルパス」に/remote.php以降を設定する必要があった。
• (7/31 6:09) 実際に使っていて、FolderSyncで定期的に同期させた時のスマフォの電池消費が大きくなることがあって気になったので、スマフォが家(LAN(Wi-Fi)内)にある時には、自作の同期プログラム(sync-zim-md-rem)でスマフォに直接送るようにし、FolderSyncでの定期的な同期は止めた。
  • sync-zim-md-remはシェルスクリプトで、上記のzim2mdが作ったMD+画像を定期的にrsyncでスマフォのMDのディレクトリ(FolderSyncの同期ディレクトリと同じ)に転送している。
  • 転送間隔が短いと電池消費が増える場合があったので、20分間隔にした。
  • 外出直前などにすぐに同期したい場合のために、ZimにMD変換と同期を行うカスタムツールを追加し、それを起動するボタンを付けた。
    • 仮に転送し忘れた場合でも、サーバからFolderSyncで同期することができる(可能性が高い: 外出の3分くらい前までPCを起動していれば良い)。
  • このプログラムは、元々、以前から使って居るスマフォ内の画像の自動取得プログラムに組み込もうとしていたが、自動取得プログラムの処理が複雑になってしまうので、(とりあえず)独立にした。
    • 自動取得プログラムと似た処理だが、近頃のLAN(Wi-Fi)構成の変化のためか随分簡単になったので、自動取得プログラムを改良できる余地がありそうだ。

昨日までに ここまで出来て、Zimにペースト・ドロップ・添付した画像をスマフォで表示できるようになった。そのため、通常はJoplinを使う必要が全くなくなり、すごく使いやすくなった。以下に表示例を示す。

まあ、何の変哲もない ただのノートアプリのキャプチャだし、ごく当たり前にできるはずのことだが、ここまで来るのは なかなか大変だった・・・

上のキャプチャを撮る時にも不具合が見付かり、芋づる式に いろいろ修正(仕様変更もあり・・・)して12時間以上掛かって、これを書くのの再開が今日になった。

残件

• Joplinのノートを全部Zimに移す(引き上げる)。
  • 今は必要なものだけをZimに入れている。
    • Joplinのノートは全部で千個くらいあるようなので、自動化する必要がある。
  • Joplinの画像をZimに移すのが面倒。
    • ノート内の画像参照を変更する必要がある。
      • 今回も同様の処理(MD内の記述を書き換える)があったが、大変苦労した・・・
• 細かい改良
  • 山ほどある・・・
• 今までの不具合修正
  • これも多い・・・
    • 上の改良もそうだが、面倒なのと多少我慢すれば使えるので、延々と延期して来た。
  • 今回の変更で不要になったものも多そうだ。
• デバッグ出力を減らす。
  • これが難しい。: 「出来た、大丈夫だ!」と思って減らすと問題が起こって、また出す羽目になることが多い。あと、通常時のチェック(たまに見ることがある)に必要な出力まで削ってしまって、役に立たなくなることもある。

気になること

• Zettel NotesやFolderSyncの安全性(例: データ・アカウント情報の漏洩)と将来性
  • とは言え、Joplinが良かったかも不明
  • あと、近頃、ZNへの問い合わせ(Google groups)への回答が途絶えた。 → その後回答がなく、Google playのレビューで どうなってるのか聞いたら不可解な応答をしたため、怪しいアプリの可能性を疑い、使用を一旦止めてEpsilon Notesに切り替えた。 (7/31 13:52)
    • 今回のシステム構成は同期と表示を別のアプリにできるので、これが駄目なら別のもの(上記のように とても少ないが)に換えれば良い。
    • 別のもう1件には全く回答がないことも合わせて、今後も回答がないままなら、信頼できないから切ることもある。
      • 自分で作っているなら、問題の原因やヒントが分かりそうなものなのに、だんまりってのは怪しい。
      • ただ、外観や使い勝手を見る限り、これが何かのパクリとも思えないのが謎だ。
      • 課金する訳でもなくオープンソースでないのも、怪しさ(不信感)を増大させている。

 

おまけ: 試用したAndroidのMDエディタ・ビューアで良かったもの

Zettel Notesの次はEpsilonが良さそうな感じだ。 → (8/5 9:14) その後、Zettel Notesは不審なので止め、Epsilon NotesとObsidianを比較して全体的に少し良さそうな、Obsidianを使って居る。

• × Zettel Notes (以下、ZN)
  • (8/5 9:14) MD表示の出来は一番良いものの、開発者が不審なので使用を中止した。推奨しない。
    • Google groupsでの問い合わせへの回答が突然止まった。回答のないものもある。
    • その件をGoogle Playのレビューに書いたら、Google groupsは知らん顔で別のところに書けという返事が来た。
  • 若干の問題はあるものの、いろいろ試した中では これが良さそうだったが、WebDAVでの同期に問題がある。
    • 問題の起こる詳細が分からないが、同期する画像ファイル数が多い場合、サーバから取得後、それらをサーバに送ってしまう。
  • 対応しているクラウドストレージとの使い勝手の比較
    • Dropbox: 変な("(",")"など、異常ではないが特殊な文字が使われている)ファイル名のファイルを無視する。無料の容量が小さ過ぎる。
    • (pCloud: 今一つメリットがない。パッとしない。): Zettel Notesは非対応。
    • Google docs: いつまで使えるの?? 信用できない。
    • sftp: 使い方が謎で使えなかった。
    • (DavX5のDAVマウント): Zettel Notesは非対応。
  • スマフォでの表示
    • 若干の問題はあるものの、いろいろ試した中では これが一番良さそうだった。
    • ただ、たまに変な表示になる。: キャプション(alt-text)の付いた画像を引用で表示すると、同じ画像が2つ表示される。下に問題の起こる例を示す。

> 

• • • • MDへのエクスポート時にキャプションを出さないようにすれば解消するので、大きな問題ではない。
    • 大きいノートの表示は遅い。もたつく。
• △ Epsilon Notes (以下、Epsilon)
  • ZNの画像の問題は起こらない。
  • メニューの構成が変
  • 設定のテーマが容易に変更できない。
  • ファイルマネージャ(CX File Explorer)のMDの「開く」に出るので便利そう。
  • Dropbox対応は有料
  • (8/5 9:14) MD(CommonMark)の解釈が厳密なため、いくつかの(Joplinに対する)互換性の問題がある(正しい動作だが、使いにくい)。
    • 「普通の」(または引用中の)改行が無視される。: 下の場合、行1と行2、あるいは行3と行4が繋がる。: CommonMarkでは間に空行(または空の引用)を入れるようだ。 → CSSを追加して緩和した。

行1
行2

> 行3
> 行4

• • • 上・下付きに ^文字^, ~文字~ が使えない。: CommonMarkには ない。
    • 書式が空白を含んだり、英語・日本語が混ざると おかしい場合がある。Joplinや他のMDエディタでも起こったので、基本的な問題のようだ。: 下の場合、取り消し線が出ない。

~~aaa ~~bbb

• △ Obsidian
  • ZNの画像の問題は起こらない。
  • ノートのフォルダが"Vault"なるものなのが面倒な感じ。
  • 表示は まあまあ。: (8/5 9:14) 全体的にはEpsilonより美しい。
    • 変な文字(異常ではないが、通常使われない文字)の表示が変。 (→ 例: Obsidian, ZN) ← フォントの変更で直る?
    • 大きいノート(test-diary-60)を開くのはEpsilonより遅いかも。
    • 設定したテーマが記憶されない? ← 設定ファイルがサーバのもので上書きされたために起こったようだ。下を参照。 (8/5 9:14) ← 設定ファイルが上書きされなくても、勝手に設定が初期化されることがある。そうなる原因は分からない。 (8/11 14:31)
      • ただ、レビューでは そういう苦情を見ないので、僕の環境に原因があるのかも知れない。いずれにしても不便なので、再発したらEpsilonに移ろうと思っている。
  • Dropboxは非対応か有料
  • (8/5 9:14) MDの対応が異なる(CommonMark?)ため、いくつかの(Joplinに対する)互換性の問題がある。ただし、Epsilonよりは良い。
    • 上・下付きに ^文字^, ~文字~ が使えない。 (Epsilonと同様)
    • 書式が空白を含んだり、英語・日本語が混ざると おかしい場合がある。 (Epsilonと同様)
    • なお、Epsilonと違い、普通の(または引用中の)改行は無視されない。
      • 設定(Editor: Strict line breaksをoff)によるようだ。
  • (8/5 9:14) 設定ファイルがVaultに格納されるので、Vaultがサーバと同期されている場合、設定も同期されて予期せぬ問題となる。例: 上の「設定したテーマが記憶されない?」

他にもいろいろ試したが、まともに使えるものは本当になかった。なんで使えないものを出しているのだろうか?

 

おまけ: AndroidのMDエディタ(例: Obsidian, Epsilon Notes)で取り消し線の表示を見やすくする方法 (表示スタイルのカスタマイズ)

描画やフォントの関係だろうが、横線の多い単語(例: 牛丼)に取り消し(strikethrough)の書式を設定しても、見えにくい場合がある。僕の場合、PCはZimで、取り消しにすると文字の色もグレーになるから分かりやすいが、スマフォアプリは そうではないので見間違いやすい。

そこで試行錯誤したところ、アプリにCSSを追加設定すれば、色や線のフォーマット(太さや形状)が変えられることが分かった。方法はアプリごとに異なるが、以下にEpsilon NotesとObsidianの場合を示す。

Epsilon Notes

設定で追加のCSSファイルが指定できる感じだが、ファイル選択のダイアログは出ず、試行錯誤するのが面倒なので、標準のテーマ(Day)にスタイルを追加した。以下のように、del(CSSに詳しくないので、何というカテゴリか不明: タグ? セレクタ? クラス?)に設定すれば良い。

下のようにすると、取り消し線は茶色の太い波線になる。

del {
    text-decoration-style: wavy;
    text-decoration-thickness: 3px;
    text-decoration-color: maroon;

    /*text-decoration: line-through;*/
}

下では、Zimのように、取り消された文字が灰色になる。

del {
    text-decoration: line-through;
    /*text-decoration-style: wavy;*/
    text-decoration-thickness: 3px;
    color: gray;
    /* text-decoration-color: maroon; */
}

Obsidian

設定の"CSS snippets"に追加CSSファイルを指定する。そのファイルは(Vault)/.obsidian/snippets/*.css に置く。※ (設定の表記で誤解したが、"snippets.css"などではない。)

※スマフォ版では埒が明かず、Linux版で試行錯誤して ようやく分かった。

以下のように、.cm-strikethroughに設定するようだ。※ (念のためにdelにも追加したが、関係なさそうだ)。設定内容はEpsilon Notesと同様である。下のようにすると、Epsilon Notesの2番目と同様に、取り消し線が太線になり、取り消された文字は(Zimのように)灰色になる。

※これもLinux版で開発者ツールで調べた。

.cm-strikethrough, del {
    text-decoration: line-through;
    /*text-decoration-style: wavy;*/
    text-decoration-thickness: 3px;
    color: gray;
    /* text-decoration-color: maroon; */
}

(7/21 17:21 少し追加、修正; 7/22 18:27, 19:51 修正; 8/5 9:14 「試用したAndroidのMDエディタ・ビューアで良かったもの」を修正・加筆; 8/9 9:35 おまけを追加; 8/11 14:31 Obsidianの設定が初期化されてしまう件について追記)

しなくちゃならないけど面倒で、なかなか進まないことが溜まった。ただ、いくつかは事前の予想と違って すんなりできた。

• PHPとLinux Mintの更新。。。
  • 久し振りに両方がメジャー更新なので、互換性の事前確認をする必要があったり、更新中・後に必ず問題が起こるので、全く気軽にできない。
    • ただ、Linux Mint(実際にはUbuntu)を更新すれば それに含まれるPHPも更新されるので、手間は少ない?
  • デスクトップだけでなくサーバもなので、面倒さは2倍だ・・・
  • まあ、Winのように鬱陶しい通知や強制更新がないから、自分のペースでできるから助かる。
• [済] digiKamの更新: 比較的容易に更新できた。結構改良されていた。
  • メジャー更新直後は まともに使えなかったので2年近く放置していたが、今回は ちゃんと動いて良かった。
  • ただ、どういう訳か、OSの再起動後に一度カタログ(画像のディレクトリ)全体を更新しないと、新しい画像が自動認識されなかった。
• [済] Spotifyのアプリ: 旧版から現行版に乗り換えた。
  • 現行版だと耳に問題(例: 耳閉感)が起こるので旧版を使っていたが、逆に以下のような問題が起こるようになったので、乗り換えた。
    • Autoplayをoffにしているのに、ミックスやアルバムが終わると勝手に曲が追加されてしまう。
    • レイアウトがおかしくなった。: 例えば、Made for youのアイコンが巨大になってしまう。
  • 耳の問題は、オーディオシステムの改良(あとで「その後」(完結編?)を書きたい)の効果か、あるいは、季節が変わって耳の調子が良くなったのか、起こらなくなった。
    • 想像では両方だと思う。: 現行版のアプリは旧版より耳に良くない音(超低域(例: 10Hz以下)と推測している)が出やすいのではないかと思う。
      • オーディオを改良して それらの音が出にくくなり、また、春になって耳の血行が良くなったために問題が起こりにくくなったのではないか。
        • → 改良が片付いてから原因を調べる予定だが、おそらく再現せず分からない気がする。その場合は次の冬に確かめられる。
• [保留] スマフォの買い替え? → 壊れるまで保留にした。
  • OSが古くなってセキュリティの問題はあるが、「今まで大丈夫だったのでヨシ!」ということにしたｗ
  • 今のスマフォに格別欲しいものがない。
    • いろいろ退化しているのが許せない。
      • 例: 巨大で重いものばかり、画面にカメラの穴・・・、背面に不格好なレンズの出っ張り、通知ランプがない、イヤフォンジャックもない。
    • 買うならAQUOS sense 7だろうけど消去法で、特別欲しくない。

 

結局、溜まっていたけど残りは1個になった。

が、その前に、オーディオの改良の片付け(最終チェック・まとめ)をしなくてはいけない。1個謎は残って居るものの問題なく聴けているので、なかなか面倒になってしまったｗ

 

(3/28 6:53) が、その後、厄介なものが2つも増えた。。。

• Joplin (ノートをPCとスマフォで同期するために使っている)の代替探し?
  • 少し前から、スマフォのJoplinアプリの同期が開始するまでに すごく時間が掛かるようになったので、アプリのストレージを消して再設定して同期(ダウンロード)しようとしたら、何時間掛かっても終わらない。
    • 仕方ないので、サーバ側のノートなどを全部削除してPCから再アップロードし、そのあとでスマフォに同期(ダウンロード)しようとして居るが、これで直るか分からない。
    • → PCからサーバにアップロードし直し(これも遅く、約5時間掛かった)、スマフォにダウンロードしているが、約0.6ファイル/sと余りにも遅い。 (3/28 13:35)
  • 以前からJoplin(開発の仕方と出来)は怪しいと思って居たが、そもそもクソな(設計がひどい※)ことが確定したので、他を探し始めた。
    • ノートをスマフォに同期できて表示できるだけで良い。
      • 今のところ、Zettel Notesが良さそうだ。
    • ※サーバでノートやリソース(添付画像)が それぞれ全部単一ディレクトリに格納されるため、ディレクトリが肥大化してしまう。論外な作りだ。
      • 何らかの上限はあるだろうから いつか破綻するし、それ以前にも同期の効率が悪くなるだろう。
        • これが問題の原因かと思っている。
      • クライアントでもリソースは単一ディレクトリに入る。
  • ※他にも、Androidアプリの同期がクソ遅い問題を抱えている方が結構居るようだ。: 例: Sync issues finally drove me away from the Joplin note-taking app (2022)
    • 上の方は、僕同様にJoplinから他に移ることにしたとのこと。 (その後は不明)
      • ノート数が増えると遅くなるとのことなので、上に書いたように、ノートなどのファイルを全部単一ディレクトリに格納しているのも悪いのではないか(それだけではないと思う)。
    • フォーラムにも何件か問い合わせがあるが、やっぱり暖簾に腕押し状態で、結局、(以前も書いたが、)ユーザのことは どうでも良くて、自分のやりたいことしかしない人たちのようだ。
      • 結局、そういうお遊びが おもしろい人が使えば良くて、僕らのように(Joplinの志向を誤解して)真面目に使おうとする者には全く使いものにならない。時間と手間の無駄だ。
• NextCloud(PIMやファイル共有)の代替探し?
  • ちょっと前にバージョンアップしてから、管理画面のUIが醜くなり、スクロールバーでのスクロールが効かなくなってしまった。
  • フォーラムを見ると、何件か問い合わせがあるにも関わらず、「再現しない」や無視していて、Joplin同様にクソな体制と出来になってしまった。
  • OwnCloud(OCISという新しい版が出た)に戻るか、他(例: Seafile)にするか考えている。

ちょっとした工夫が うまく行くように思えたけど、意外な落とし穴があることは多い。

1. ハリ玉+ひっつき虫 → 使いやすく

壁などにコードを留める(貼る)時に ひっつき虫などを使っていたが、今まで使った以下の3種類のどれも一長一短だった(本来はポスターなど用なので、コードで うまく行かなくても仕方ない)。

• ハリ玉: 硬いので しっかり固定できるが、硬過ぎて壁に くっ付かないことがある。色はベージュ系で目立たなくて良い。
  • 一度付いたら まず剥がれないので、ツンデレ系?
• ブルタック: 柔らかくて付けやすいが、暑い時は剥がれやすい※。水色なので少し目立つ。
  • ※正確には、コードの張力や重さのために、コードがブルタックを破って浮き出る感じ。
  • ポスターなどを貼るのには一番良いと思う。
• ひっつき虫: 白なのはいいが、柔らか過ぎる(ブルタック以上)ので、暖かいと剥がれやすい。

そこで先日考え付いたのが、ハリ玉と ひっつき虫を混ぜることだ。ハリ玉の硬さと ひっつき虫の柔らかさが混ざって丁度良くなるのではないかと思った。やってみたら、なかなか うまく行った。ひっつき虫は かなり少なくていいようで、体積比で5:1とか そこら辺で良さそうだ。

が、混ぜるのに結構力が要り(陶芸のように、硬い粘土を こねるような感じ)、時間も掛かる(なるべく均一にするため)ので、準備が面倒という欠点があった。あと、時間が経過したらどうなるかは分からない。硬くなって剥がれたり、逆に剥がれなくなったり、変質して壁を汚すことがないとは言えない。

2. 即席単4→単3アダプタ

今朝気付いたら掛け時計が停まっていて、たまたま単3電池がなかったので、以前の単3→単1アダプタが うまく行ったのを思い出して単4の充電池※で代用しようとした。

※電池収納箱の中に1本だけあったので、是非使いたかった。以前「どうして?」と思った半端な電池は、こういう1本使いの機器のために生まれるのかも知れない(あとは3本か)。

以前のように、単4電池に何かを巻いて(今回は薄い発泡スチロールのシートを使った)太さを調整し、底に導体(巻いた網線を使った)を付けて長さを調整すればいいのだが、長さの違い(3-5mmくらい?)を埋めるのが意外に難しく、今回は一度、接触不良になった。

電池ホルダーのバネが弱いと なりやすそうだ。また、アダプタが太過ぎるとホルダーの中で適切に動かずに接触不良が起こりやすそうだ。網線でなく硬い金属を使えば いいかも知れないが、ちゃんと接触(導通)させるのは難しい。

柔らかい、金や銀なら いいかも知れないｗ

それから、今回のように電池ホルダーに蓋がなくてバネが弱い場合、太さや長さが合って居ないと外れて落ちる可能性もある。それで、念のためにマスキングテープで止めた。

あと、アダプタとは直接関係ないが、充電池の1.2Vでは動かない(推奨されていない)場合がある。: 今回は電波時計に使ったのだが、電源電圧の下限が1.3Vで、説明書には電圧が低くて動かない可能性があるので避けるよう書いてあった。※ 実際には動いたが、上の接触の件もあり、ずっと大丈夫かは分からない。

※上限(1.7V)もあり、ニッケル系一次電池は初期電圧が高いから非推奨と、なかなか注文の多いムーブメントである。

3. AndroidのFirefoxブラウザでの位置取得

以前書いたように、Androidで「位置情報の精度を改善」を有効にしていない場合、ブラウザで位置が取れるのはFirefoxだけになってしまった。それでFirefoxを使っていたのだが、気付いたら取得した位置が変わっていなかった。どうやら、キャッシュの利用期限(maximumAge)を無限に設定すると常に古い位置しか取れないようだ。

そこで、キャッシュの利用期限とタイムアウト(timeout)を適切に設定したら(例: キャッシュ: 1時間, タイムアウト: 2秒)、ちゃんと位置が更新されるようになった。

ただ、今度は設定したキャッシュの利用期限に関係なく、取得のたびに位置が更新されるようなので(常に取得時刻が更新される)、毎回GPSが動くのだとしたら、電池消費が多くなるのかも知れない。

一見矛盾している、「位置が欲しいけど、頻繁に更新したくない」の意図は、「何か(例: 写真撮影, GPSロガー)のついでに測定した位置があれば(キャッシュされていれば)欲しい」である。

 

いかがでしたか?  (← 良くある「裏技集」の最後に出て来そうｗ) じゃなくって、

という訳で、世の中 それほど甘くないという3つの例であった。

 

(11/16 5:24, 6:10 少し加筆・修正, 8:58 写真を追加, 10:18 少し補足)

外でメモ(雑記やライフログ的なもの?)を記録するのに、自作のメモ・ノートシステム BNoteを使っている。それは、ブラウザのフォームでツイート風にメモを書き込むと、日ごとのノートに追記されてサーバに保存され、作成や更新があればPCにメールで通知が来て、それに書かれているパスでノートにアクセスできるようになっている。

要するに、(今は使っていない)Evernoteに手軽にノートを追記するアプリの代わりだ。: 実際の使い方としては、帰宅後にエディタで そのノートを開いて本来のノート(例: 「日記」: Zimで書いている)に転記(コピペ)・更新する。

なぜ、外でスマフォで直接本来のノートに書き込まないかというと、(Zimはスマフォでは動かないので、自動変換して)Joplinで見られるようにしているが、ノートが大きいとスマフォで開くのが遅くなり、また、大きくなくても編集は手軽でなく、思い付いたことを全く「パッ」と書けないからである。

Joplinなんかで書いていたら、開くたびに時間と手間が掛かってイライラして、書くことを忘れてしまう。そう言えば、Evernoteもそうだった。

もう一つの問題は、スマフォとPCの変更の競合だ。Evernoteでは度々競合が起こっていて、それでもイライラしていた。Joplinでも、同期のタイミングによっては競合が起こる。そんなんなら、自分で同期(上述の転記)したほうがずっとマシだ。

更に、仮にそれらの問題がなくても、メモを書いた時刻を手で付けるのは面倒だ。

そして、各メモの前には送信時刻を付けるとともに、(興味と実益を兼ねて)位置情報(緯度, 軽度, 高さ)※を追加するようにしている。

※ブラウザではJavaScript(例: navigator.geolocation.getCurrentPosition() → サンプルコード)で取れる。ただ、位置の取得に時間が掛からないようにするようなオプション(図: 下部の"opts:"以降を参照)を指定しているため、必ずしも正しい訳ではなく、最後に取れた位置になる。まあ、ないよりはマシな程度である。

ところが、先週くらいから、その位置情報が取れなくなってしまった(ブラウザはVivaldi)。: getCurrentPosition()がタイムアウトのエラー(code= 3)になる。オプションをいくら変えても直らなかったが、不思議なことに、OperaやFirefoxでは問題なく取れる。いろいろ調べると、昔からそういう問題が報告されている。(→ 例) いくつか解決策があった(例: watchPosition()を使う)が、僕の場合はどれもうまく行かなかった。更に、getCurrentPosition()のサンプルコードすら動かなかった(もちろん、Operaなどでは動く)。

「ないよりはマシ」なものだけど、今まで取れていたものが取れなくなったら やっぱり嫌だし、何かがおかしくなったかと心配になる。

更に試したら、Androidの設定の「位置情報の精度を改善」※をonにしたらVivaldiやChromeでも位置を取れるようになった(上のリンク先にも、GPSだけ(= 「位置情報の精度を改善」がoff)の場合は位置が取れないという情報がある)。

※これをonにするとGoogleに更に「いろいろな情報」が送られそうで嫌だし、そもそもGPSの位置を改善する必要性を感じていないので、offにしている。

そう言えば、offにしているとGoogleマップのアプリでも度々onにしろと催促されてイライラするのを思い出した。Off(= ダイアログの「使用しない」= 「位置情報の精度を改善しない」)でも ちゃんと使えるのに、なんでそんなに押し付けるのだろうか? きっと、Googleに さまざまなメリットがあるのだろう。

仮にChromeが突然仕様を変えたとしても※近頃の文句を見ないということは、ほとんどの人はonにしているのか。だから、今後は僕はChromeなどでは位置が取れなくなるのかも知れない。

※Chromeの変更履歴を少し調べたが、関係ありそうなものは見付からなかった。ただ、量が膨大で調べきれず、また、細かく書いてないものがあるので、実際のところは分からない。

まあ、BNoteに関しては、実際にはメモを書いた位置情報を調べることは ほとんどないから実害はないし、Operaを使えば現在位置が取れるので問題はない(今はOperaを使うようにしている※＊)。

※Firefoxでないのは、Firefoxだけ表示がおかしい(入力フォーム(textarea)が幅広になる)からである。

(11/1 13:01) 原因は良く分からないが、Firefoxのtextareaのデフォルトフォント(あるいは幅などの計算に使う文字)の幅が他(Chrome系)のブラウザより広いような感じだ。本来はフォントの平均(あるいは特定文字の)幅とディスプレイ(正確には表示領域)の幅からtextareaの幅(文字数, cols)を求めるべきだが、何とも煩雑だ。

そこで、textareaの幅を文字数では指定せず、 style= "width: 90%;" のようにディスプレイの幅の相対値で指定したら、ちゃんと収まるようになった。

ただ、これだと(実際には使うことはないが)PCでは広くなり過ぎるので、モバイルの時だけにしている。

＊今日になってOperaでも位置が取れなくなった。もしやと思って使用モジュールを調べたら、しっかりChromiumと書いてあった。。。今まで表示されていたのは、更新が遅かったためだろう。

だから、取れなくなった原因は、近頃Chromeの仕様が変わったための可能性が高い。

なお、Firefoxはまだ大丈夫だが、使用モジュール(ライブラリ)は余りにも表示が細かくて調べていない。とりあえずはFirefoxでしのぐ。 (10/31 19:48)

そういえば、以前も同じような問題があってOperaを使うようにしたが※、少し前にスマフォのブラウザをVivaldiに切り換えた時に そのことを忘れて、BNoteもVivaldiにしたのが悪かったのかも知れない。ただ、先週までは ちゃんと位置が取れていたように見えるから、近頃何か変わったのは確かなようだ。

良くあるGoogleの気まぐれなんだろうが、付き合わされるほうは たまったものではない。。。

そもそもweb(JavaScript)の規格では普通に出来るはずのものが、なぜか「位置情報の精度を改善」をonにしないと出来ないのは勝手な押し付けで、それまで出来ていたものが出来なくなったために、結構な手間と時間を掛けて(上記のように)調べる羽目になったのだ。

普通に使えるはずのものは 普通に使わせてもらいたい!

少し前に、スマフォ(AQUOS sense lite)の電池が減るのが速くなった気がして※気になったのだが、古くなって電池が劣化して来たためではないかと思い、また、実際に測定するとバラつきがあって以前の値になったこともあるので、その時は問題ないと考えた。が、実はそうではなく、本当の原因は分からないものの、思わぬことで電池消費率(= 消費電力)が増えることが分かり、意外な対処で解消できた(と思われる)話。

※アイドル状態で大体1%/h(→ 1日で1/4くらい減る)で、以前は もう少し小さかった記憶がある。

発端は、ニュース記事で、あるMVNOがIPv4(以下、v4)のグローバルアドレスを割り当てるのを止めてプライベートに できるようにするというのを見たことだ。今時、スマフォにグローバルアドレスを割り当てること自体が時代錯誤(どうして そんなに確保してるんだ?!)だが、それを(客の要望で)プライベートにするのもおかしかった。わざわざそんなことをする理由は、グローバルアドレスが割り当たっているとスマフォの消費電力が増大するという説※があるからだ。

※詳しくは知らないが、グローバルアドレスの場合、ポートスキャンなどで頻繁に外からIPパケットが来て、そのたびに端末が動いて電力を消費する(と推測されている)ためのようだ。その説が本当かは分からないが、いかにも腰が重いプロバイダがわざわざ対処するくらいだから、正しいのだろう。

僕のプロバイダはプライベートアドレスだから、それ自体は僕には関係なかったが、ふと、IPv6(以下、v6)が気になった。IPv6は全部グローバルアドレスのようなものなので、上のv4と同様なことが起こるのではないかと思った。

それでスマフォのモバイル(LTE)設定を調べてみたら、一時はv6対応にしていたものの、その後気が変わったらしくv4だけになっていた。それで、LTEのv6に関しては問題なさそうなことが分かった。

が、LTEでなくWi-Fi(光)でも同様な問題がありそうな気がした。スマフォのOS(Android)はv6対応で、ルータにはファイアウォール(仕様は不明)はあるものの、それを通過したパケットには反応する。v6のアドレスは幅広いのでポートスキャンのパケットが来る可能性は低そうだが、ルータやプロバイダなどの管理用パケット(そういうものがあるのかは不明だし、頻度も不明)やPCからのパケット(ブロードキャスト)は届きそうだ。

そこで、スマフォのLTEだけでなくWi-Fiもv4だけにして試したくなった。

ただ、AndroidのWi-Fiだけv6を停めることはできず、全体のv6対応を停められるかはメーカー依存のようで、僕のは不可能だった。そうするとルータで切ることになるが、僕のルータ(I/Oデータ WN-SX300GR。以下、I/Oルータ)は普通の家庭用のものなので、LANポートごとどころか全体でもv6のon/offができない。※ もちろん、LANポートごとのフィルタリングもできない。プロバイダに頼んでIPoEからPPPoEに切り替える手はあるが、時間が掛かるうえに全部がv4になるため、PCまで遅くなってしまう。

※そもそもIPoEモードで使っているので、普通は そこでv6を停める意味がない。

そこで、もう一台、v6非対応のルータを使うことを思い付いた。手持ちの古いルータはv6非対応なので、元のルータにその古いルータを繋ぎ、古いルータのWi-Fiにスマフォを繋げばv6がカットされる はずだ。

実際には、古いルータでなく、消費電力が小さいため、死蔵していたコンパクトWi-Fiルータ(TP-Link TL-WR802N, ルータモード。以下、TP-Linkルータ)を使った。v6対応だが、非対応にできるので使えた。

以下のような構成・接続である。

WAN → [I/Oルータ] → [TP-Linkルータ (v6 off)] Wi-Fi → [スマフォ (v4)]
(光, IPoE)              +→ [PC (v4/v6)]

主な設定

• • I/Oルータ: スマフォが誤って接続することがないように、Wi-Fiをoffにした。
  • TP-Linkルータ
    • WAN(I/Oルータ)側: デフォルトルータとDNSサーバをI/Oルータに設定した。
    • LAN(Wi-Fi)側
      • DHCPサーバ設定(スマフォへ): デフォルトルータをTP-Linkルータに、DNSサーバをI/Oルータに
  • PC: スマフォへのルーティング設定(スマフォのセグメントへのルータをTP-Linkルータに)を追加した。

この構成は、良く駄目だと言われている「2重ルータ状態」だが、意外にメリットがあるのかも知れない。僕はスマフォの通信速度は全く求めていないから、これで全く問題はない。

試したら、確かにスマフォの消費電力が減った。大体0.2%/h減った。: それまでは0.8-1%/h辺りだったのが0.60-0.75%/h辺りになり、以前のような減り方になった。

次に、ルータとスマフォのWi-Fi接続の問題の可能性も考え、TP-Linkのルータをブリッジモードにして試したところ、消費電力は減らなかった。ブリッジモードはv6のパケットも通すので、予想通り、v6が原因の可能性がありそうだ。

とは言え、v6が原因でスマフォの消費電力が増えるというのは どうにも腑に落ちない。上述のv6パケットが(頻繁に)来る以外に、そもそもAndroidのv6の処理が重くて負荷が高いのかも知れない。スマフォが古いのでCPUパワーが追いつかないのか。

他に考え付くのは、スマフォとルータとの「相性」である。実際、TP-Linkルータに接続すれば消費電力は増大しないが、それが何によるのかは分からない。

I/Oルータのログは簡素なので特に何も出て来ず、調べようがない。

そういえば、I/Oルータに繋いでいる場合、(別の稿に書いた、)PCからスマフォの画像を自動取得する処理でスマフォに繋がらない(スマフォが見付からない)ことがあるが、TP-Linkルータでは ほとんど起らないので、何かあるのかも知れない。

例えば、しばらく通信がないと、I/OルータあるいはスマフォがWi-Fiの接続(いろいろな層があるとして、比較的下のほうではないか)を切ってしまうが、なぜかTP-Linkルータでは切られないということがあるのかと思っている。

その他の要因として、上記のスマフォの画像を自動取得する処理の負荷が考えられるが、PCをスリープさせていて自動取得が行われない時でも消費電力は減らないので、主因ではなさそうだ。

あと、問題とは直接関係ないが、スマフォの電池残量表示から消費電力を計算すると、たまに予想外に値が大きく・小さくなることがある。それは残量の誤差(正確には表示分解能)による場合が多そうだ。というのは、Androidが表示する電池残量は1%単位なので、実際の残量は 表示値から表示値+1%未満※まで(表示値-1%未満から表示値や、表示値±0.5%も ありうる)の間の「どこか」であるためだ。

※0.5%と考えると、比較的うまく行くのかも知れない。

1%単位の表示値から正確な残量を求めるには、連続して残量変化を調べて残量曲線の細かい区間の傾きを求めれば、中間の時刻での残量を計算することができそう(直線補間)だが、手では困難だ。

あるいは、残量が変化した正確な時刻と残量を記録し(そういうアプリは ある。例: My Battery Monitor)、(任意の時刻の残量でなく)それを元に消費電力を求めるのが良さそうだ(が、今となっては遅い。→ ちゃんと確認したいので、上記のMy Battery Monitorを再度入れた)。

実際、数時間(3時間など)では誤差が大きくなることがあり、10時間くらい見ないと確からしい値は得られなかった。

例: 残量差から消費電力を計算する時、開始残量表示が90%、3時間後の終了残量表示が87%の場合

普通に計算すると、(90-87)/3= 1.0%/h となる。

一方、残量の表示分解能の影響を考慮すると、終了残量(開始残量も同様だが、簡単のため、ここでは終了だけを考える)は 87-88%の間 と考えられる。それを仮に87.5%とすれば、(90-87.5)/3= 0.83%/h となり、上の値より17%も小さい。

もし、開始残量もズレていたら、更に差が大きくなる場合がある。

 

という訳で、スマフォの電池は劣化してなさそうだし消費電力は減らせた(元に戻せた)ものの、原因が分からず もやもやするが、ひとまずは良しとしたい。

でも、時間が経つと別な要因で消費電力が増大して「あれ? また?」とか思いそうだ・・・

あと、実は最後に書いた、スマフォの電池残量の表示分解能の影響だけの問題で、実は、「何も問題はなく、だから解決すら していなかった」(= 全部 夢か幻、プラシボ効果。「は? 何寝ぼけてんだ!」ｗ)というオチもありそうだが、何度も測定・確認したので、そうではないことを願っている。

↓

と書いたら、本当に消費電力が激増してしまった。必要なくなったアプリをアンインストールしたのが関係しているのかと思って再起動して様子を見ているが、スマフォへのssh接続も遅くなってしまった。相変わらず謎は多い。。。 (10:41)

↓

Androidの電池残量のグラフ(↓)を見てみたら、消費電力が激増したところを過ぎたら ほぼ平坦になって、三角形の窪みとか斜面の宅地のようになっているので、「謎の理由」で残量の測定がうまく行かなかったようだ。最終的に辻褄が合うのも不思議だ。

もしかすると、その辺りでアンインストールしたアプリ(Gsam Battery Monitor)が電池や消費電力関係のものだったからだろうか?

また、ssh接続などが遅いのが頻発していた件は直らない。外出して戻ったら直ったと思ったが、単に充電中のためだった。Androidやルータの設定が どこかおかしいのかも知れない。(Androidがやっている)LTEとWi-Fiの切り替え・併用は難しそうだし、謎は多い。 (18:11, 19:24)

 

PS. この問題を何とかする過程で、公開予定のPCからスマフォの画像を自動取得するソフトも結構改良できたのが良かった。それだけでも価値があった＾＾