Archive for the ‘Android’ Category

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

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

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

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

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

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

ひっつき虫(左)とハリ玉(右)を混ぜて、柔らかく くっつきやすく、かつ、強くした。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

 

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

  •  1
  •  0

外でメモ(雑記やライフログ的なもの?)を記録するのに、自作のメモ・ノートシステム 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にしないと出来ないのは勝手な押し付けで、それまで出来ていたものが出来なくなったために、結構な手間と時間を掛けて(上記のように)調べる羽目になったのだ。

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

  •  0
  •  0

少し前に、スマフォ(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%も小さい。

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

 

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

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

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

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

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

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

Androidの電池残量のグラフ: 「時間前」の辺りで一時的に残量が激減したが、なぜか元に戻った。

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

 

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

  •  0
  •  0

(部屋の異臭問題のまとめを投稿してからと思って居たが、もう少し様子を見る必要があるので、こっちを先に出す。)

そもそも読者が少ないうえにニッチなものだからニーズは ほとんどないと思われるが、他を探しても僕の欲しい機能のものがなく(開発当時)、自分では便利に使っているので、(他の作業が一段落したこともあり、)公開したくなった。そのための作業が結構あるのと体調が今一つ不調なので、とりあえず予告を。夏(が終わる?)頃までには出したいと思っている。

もし、「すごく欲しい!」という方がいらっしゃったり、質問がございましたら、「いいね」を押して下さるなりコメントして下さると励みになります^^

概要

AndroidスマフォをPCの近く(実際にはルータに繋がるところ)に置いておけば、撮影した写真などを自動的にPCに取り込み、"年/四半期/日"のディレクトリに振り分ける。

「Google Photosのローカル版みたいなもの」と言えそうだが、ほとんど使ったことがないので良く分からない。

外出時に撮影した写真は帰宅して少し(5-30分くらい)経てば自動的にPCに入り、(小さい家では、)家の中や周囲で撮った写真も同様に、撮るそばからPCに入る。

スマフォ以外では、USB PTP対応のデジカメなども、PCに接続すれば自動で取り込まれる。

取り込んだ画像には「新規画像」を示すEXIFのタグ("New")が付くので、画像管理ソフト(例: digiKam)のタグで分類する画面を開けば容易に区別できる(下を参照)。

スマフォの写真をPCに自動取り込み後、digiKamで新規画像(タグ: "New"で識別される)が表示されている画面

なお、新規画像の整理や後処理が終わったら、上記のタグの設定を解除すれば(新規には)表示されなくなる。

主な機能・仕様

  • スマフォやデジカメなど(以下、デバイス)から新しい画像など(以下、メディア)を(可能な場合は自動で)PCに取り込む。
    • 前回最後に取り込んだものの次から取り込む。
    • スマフォなどWi-Fi対応デバイスの場合は、定期的に自動で取り込む。
    • USB接続デバイスの場合は、PCに接続したら自動で取り込む。
      • 現状はPTPのみ確認済み。
  • デバイスの接続方式
    • Wi-Fi (正確にはLAN)
      • Wi-Fi経由で定期的に(約5-15分間隔)自動でチェックする。
      • デバイスがルータに繋がったら自動で認識する。
        • 正確には、上記のチェック間隔でデバイスが接続されているか調べる。
      • ルータへの接続または新規メディアの生成後、だいたい5-30分くらいで新規メディアが取得される。
        • スマフォがスリープしていると取得は遅れるが、取り込まれないことは滅多にない。
    • USB
      • デバイスをUSBでPCに接続したら自動で取り込む。
        • 実際にはLinux(UbuntuかLinux MintかThunarかその他か不明)の仕組み(リムーバブルドライブとメディア)を使って開始する。
  • 取り込みのモード
    • 自動取り込み
    • 手動取り込み
      • 取り込まれるのを待てない場合に利用可能。
      • PCからの開始とスマフォからの開始の両方が可能
  • 取り込んだメディアの処理
    • 元々のファイル名に固有のID(整数)を追加し、複数デバイス間のファイル名の競合を防ぐ。
      • IDはデバイス情報(機種名, シリアル番号)と親ディレクトリ名(例: 100SHARP)から生成する。
      • 例: DSC_6328_2964489332.JPG
    • 年/四半期/日のディレクトリに振り分ける。
      • 例: Pictures/2022/2022_04-06/2022_05_26/
      • 年の次が月だと細かいので四半期にした。
    • タグを付けて、画像管理ソフトで新しい画像を識別可能にする。
      • 画像管理ソフトdigiKamがタグとして認識する"Subject"に"New"を設定する。
      • 注: EXIF(XMP)の格納できないメディア(例: 動画)にはタグは付けられない。
  • 対応メディア
    • 静止画, 動画, オーディオ
  • PC画面での表示
    • 自動取り込みモードの場合、取り込み完了後に簡単な通知(数秒で消える)を出す。
      • 取り込みが失敗した場合は、取り込み経過(ログ)を表示するウインドウを出す。
    • 手動取り込みモードの場合、取り込み経過(ログ)を表示するウインドウを出す。

動作環境

  • PC: 古過ぎないデスクトップLinux (Ubuntu 20.3 LTS, Linux Mint 20.3など)
    • 動作確認済み環境
      • OS: Linux Mint 20.3 Xfce
      • 画像管理ソフト: digiKam 7.3.0
  • スマフォ: 古過ぎないAndroid (sshdアプリが動くもの)
    • 推奨sshdアプリ: SimpleSSHD
    • 動作確認済み環境: Android 9 (シャープ AQUOS sense lite)
  • Wi-Fiルータ: スマフォを使う場合に必要。
    • スマフォとPCは同じセグメントに繋がっていること。 → その後、(別件で)別セグメント(「ルータの向こう」)でも可能にできた。 (6/2 17:43)
    • 動作確認済み機器: I/Oデータ WN-SX300GR
  • デジカメ: USB PTP対応のもの
    • Mass Storageからの自動取り込みは未確認(実装した気もするが忘れた)。
    • メーカー独自規格の通信方式は不可。
    • 動作確認済み機器: キヤノン IXY digital 3000IS
      • iPhone 6sやNexus 4も対応しているはずだが、昔のことなので現在は不詳。

補足

「ソフト」と書いているが、実際には単一のものでなく、複数のプログラムなどからなるので「システム」と呼ぶほうが正しいが、そこまで大掛かりでもないので こうした。

そんな訳で、個々のプログラムの名前はあるが、全体としての名前がないことに、今気付いた。

 

PS. そもそもはWindowsを使っていた時にキヤノンの画像取り込みソフトとACDSeeを使っていたのだが、Linuxに移っても同様の手順・使い勝手を実現したくて(既存のものを探し・試したが いいものがなかったので、)USB版の画像取り込みプログラムを作ってdigiKamと組み合わせ、その後スマフォ(USB接続)に対応し、更に、スマフォ側でAutomagicのスクリプトを動かしてWi-Fi経由で自動で取り込めるようにし、Automagicのディスコンに伴って不要にして今に至る。

PS2. 書いてから、「別に予告なんてしなくてもいいじゃん(単なる自己満足だよ)」と思ったものの、中学の先生が、「すること・しようと思っていることを予め周りに言うと、(しなくちゃならない状況になって、)本当に実行できる」というようなことを言っていたのを思い出したので、そういう意味で この予告は意味があるのだろう。

(以前にも書いた気がするが、)その先生には いろいろ話したいことがあるものの、結構昔に亡くなってしまったので、もう同窓会などでも会えないのが残念だ。

  •  0
  •  1

使っているデビットカードがGoogle Payに対応したので登録してみた。スマフォのカメラでカードを写すと番号などが自動入力されて楽だった。

ただ、有効期限とセキュリティコードは入力されなかった。セキュリティ上の問題があるから わざと出さないのかも知れない(でないと、他人のカードを写して登録できてしまうかも知れない)。

それから早速コンビニで使ってみたら、なぜか認識されなかった。セミセルフレジでクレジットカードのカテゴリのボタンを押したのだが、そうでなく、Google PayやApple Payなどのカテゴリ(PayPayなどと一緒?)があって、それを指定すべきだったのかと、あとで思った。

が、気になるので調べたら、クレジットカードのカテゴリでいいようだ。ただ、ページの下のほうに、小さく、スマフォがスリープ状態の場合は駄目みたいなことが書いてあって、それかと思った。それで、次の日はスマフォを復帰させてからタッチしたら、みごとに使えた。決済時にスマフォの画面にカードの絵が出た。どうやら、QUICPay(スマフォがどういう状態でもタッチすればOK)とは違うようだ。

そういえば、SuicaもGoogle Payに入れているけど、自販機などで使えた試しがないのは、長期間使っていなくて停止されている以外に この問題もあったのかも知れない。

↑ 試したら、スマフォの電源をonにしても使えなかったので、Suicaは電源に関係ないけど、長期間不使用で停止されていることが分かった。それにしても、駅に行かないと解除できず、いつも面倒だ。なぜ そんなことするのか全然理解できない。 (5/24 18:05)

いや、Google Payのデビット(クレジット)カードは仮想クレジットカード番号というものを使うらしいので、それで決済時にアプリが動く(= スリープ状態でない)必要があるのかも知れない。

タッチの前に いちいちスマフォのボタンを押すのは、なんか面倒だ。他にも、セルフレジでない場合には、店員さんにタッチ決済を理解してもらうのが大変な場合がある※のに、カードも出さずに(スマフォを出して)「クレジットカードのタッチ決済」とか言っても なかなか厳しい気がする。おまけに、店によっては(タッチする場所があるのに)クレジットカードは挿し込むしかない場合もあるので、こっちの頭の切り替えも煩雑だ。

※タッチ決済と普通のクレジットカード決済の操作が同じか違うか店によって違うし、タッチ決済できるのに、できないと思い込んでいる店員が居て難儀したこともある。そもそも、「クレジットカード(決済)で」と言うのが面倒だが、「カード(決済)で」だと別のカード(例: 店の電子マネー)と思われる可能性すらあり、クレジットカードのタッチ決済のハードルは高い。更に、少ないものの、クレジットカード=デビットカードでない店もあるから大変だ。

そう言えば、以前、上のような背景(タッチ決済できないと思い込んでいる店員の居る店)で、きちんと「クレジットカードのタッチ決済で」と言ったら、店員さんが褒めてくれた。「何種類もあるから、言ってもらえると助かる」みたいなことを言っていた。

あと、カードはスマフォでタッチ決済しても紙のレシートは来るので、それを財布に仕舞うという間抜けな面倒もある。

以前も書いたように、「電子レシート」がスマフォに届けばいいのだが、まだそこまでは無理か。

更に、どういう訳か、Google PayなのにGoogle Payの管理ページ(webまたはアプリ)には出ず、(Googleでない)通常のデビットカードの管理ページで見るしかないようで、どういう管理・仕組みなのか謎だ。

そんな感じなので、果たしてGoogle Payでデビットカードを使う意味はあるのかと思って居た。が、カードを財布から出さずに済むし、結果として挿したまま・置いたまま忘れることもないのは(僕には)大きなメリットだと考え※、使い続けることにした。

※実際、今までに数回、挿したまま帰ろうとしたことがある。

そうしたら、今日、すごいメリットがあることに気付いた。: デビットカードを使うとメールで通知が来るのだが、カード会社の仕様なのか、店名が書かれておらず(数日後に管理ページを見ないと分からない)、金額と日時程度だ。が、Google Pay(のデビットカード)で払うと、ちゃんと店名(ただしローマ字)が出るのだ。

店名が出るのはいいが、同じ仕組みで やれば出来ることがGoogle Payでしかできないのが不思議だ。Google Payは処理が高速とか、即座に検索できる加盟店一覧のDBを持っているとかいう話なのだろうか。

同じような操作だけど実は処理経路が違っていて、Google Payの場合は、「Googleのクレジットカード処理」(仮想クレジットカード番号を本物の番号に置き換える関係?)※を通すために、すぐに店が分かるのかも知れない。その情報をデビットカードの会社に通知するから、メールに店名が書かれるのか。

※その処理の時、店が正当かどうかも確認せずに素通しする訳にも行かないから、決済のたびに店のIDをチェックし、その時に店名も出るのか。そういうチェックは普通のデビットカードでもしているはずだが、店名まで検索していると遅くなるから ちんたらあとでまとめてやっているのだろうか。

(何はともあれ)細かいことだけど、使った直後に店まで確認できるのは かなりのメリットだ。実は、そのデビットカードを申し込む時に説明(店名が分かるのは数日後)を読んだ時から、ここを何とかして欲しいと思って居たのだ。

という訳で、いろいろな面倒はあるものの、二つの大きなメリットがあるので、使えるところでは(多少は我慢して)Google Payのデビットカードを使うことにした。

 

(5/24 8:02 少し修正・加筆)

  •  1
  •  0

暖かくなり、このところ(昨日まで)天気が良かったので、ドライブに行きたくなって居た。予報では今日(4/14)から しばらく天気が悪そうだったので、僕の調子が比較的良かった昨日、何とか間に合った。晴れで日射しが強くて暑かったが、なかなか気持ち良く走れた。

事前に行き先を考えたのだが、いつも候補に上がる上三依水生植物園は4/15開園なので却下となり、みかも山公園のように桜の多いところは混みそうなので却下した。それから、今まで行ったことのない新しい場所を地図で探したところ、(今回行った)木の俣渓谷・木の俣園地、深山湖(ダム)、戸田水辺公園(ここまで那須塩原市)、八溝県民休養公園 (那須烏山市)が候補になった。

どうも、深山湖には以前行ったことがある気がして このブログで検索したら、約10年前(2012/11)に行っていた。今の車を買ってすぐの頃だ。

深山湖は新しくないし、八溝県民休養公園は何となくインパクトに欠ける気がしたので(ただ、その近くの釜飯屋には、ちょっと ひかれた^^)、木の俣渓谷にした。

 

9時頃出発した。10時頃までは涼しかったのだが、それから急に暑くなった(車を降りて休憩している時に冷房が切れたせいもありそうだ)。この休憩場所(道の駅 やいた)までの道は ほとんど空いて居て、気持ち良かった。また、道端の菜の花が綺麗だった。

目的地に着く頃に昼食の頃合いなので、その前に近くで食べようと思った。事前に調べて、自然料理の店か蕎麦屋にしようと思って居た。前者はおもしろそうではあったが、Googleマップのメニューや外の写真を見たら、何となく飲み屋的だったので蕎麦屋にした。

蕎麦屋に行く時、地形の関係なのか、たった数kmだけど回り道(下の地図の左上の尖った部分)をする必要があるのが気に入らなくてショートカットしようと思ったら、山の中で道に迷ってしまい、僕が方向音痴かつ地図が読めない(特に、自分の居場所が分からない)のを再認識した。

ショートカットに失敗して迷った。 (青: 走行した経路; ベージュ, 赤: 正しい経路)

蕎麦屋の場所は上の地図上方の赤丸のマークで、下辺中央辺りから進んだ。左上の尖った青の回り道を避けるため、本来はベージュ色の道で北上してから赤の道に曲がるつもりだったのだが、右下から右側中央の折れ曲がった青のように迷走してしまった。赤の道に行くところを地図の"+"の上辺りと誤解していた。。。

迷った時、山の中かつ道が細いせいかカーナビがお手上げ状態だったので、スマフォのGoogleマップのナビも併用して切り抜けようとしたのだが無理だった。※ それだけでなく、(僕には)全く役立たずだった。以下のような問題があった。

  • 最初に「南東へ」とか出ても、僕にはどっちか分からない。
    • スマフォには電子コンパスがあるんだから、「どっちに」と教えるのもできそうではないか。
      • ただ、その方向を教える方法は難しそうだ。
        • それに関連して、近頃出たパイオニアの画面なしカーナビなんて全く使えないと思う。今どこに居て どちらを向いているかや目的地は どっちかなどを地図で確認できなかったら不安しかない。 (4/15 8:43)
          • カーナビに聞けば教えてくれるとしても、例えば目的地に到着して、それがどっちにあるか分からない場合、「(目的地は)南西20mにあります」とか言われても、「うむ、で?」だよw
          • スマフォなら、例えば持ってぐるっと動かして、方向が合ってたら「こっちです」と言ってくれれば分かるが、カーナビは動かせないから無理だ。
          • せいぜい、「左のピラーの先です」などか。
  • 分岐で曲がる時、カーナビのように「*m先を」などと言わないので、どこで曲がるか分からない。
  • 更に、細い砂利道どころか、道の跡のようなところにも入れと何度も言うし、明らかに曲がるべきところで だんまりだったりする。
  • すごく電池を食う。

※まあ、上の経路図のように そもそも僕が「明後日のほう」に進んだのが悪かった訳で、Googleマップでも無理だったのだろう。

そんな訳で、地図が古くても車のナビのほうが ずっと安心感があると思った。(数年しか最新で使えないのに)随分高いけど、次の車(に換えるとすればの話)にも付けたい。

四苦八苦して、11:50頃、蕎麦屋に着いた。着いた直後には他にバイクの2人しか居なくて、平日だから余裕だと思って居たのだが、トイレに入って出たら随分増えていたので、ちょっと驚いた。

暑かったので、辛味大根蕎麦の大盛にした。1300円くらいだったか。麺は すごくおいしいが、つゆがしょっぱ過ぎた。辛味大根はまあまあだった(疲れていたのか、何を頼んだのが忘れて、「わさびが付いてなくて変なもの(辛味大根, 赤っぽかった)が付いているんだなあ」と思った)。いろいろ含めて全体的には「まあまあ」で、苦労して来るほどのものではなかった。

それでも、店内は涼しくて良かった。おもしろかったのは、相席になった おじさんも辛味大根を頼んでいたことだった。やっぱり暑かったせいか。

蕎麦屋から目的地は近かった。距離は短くはないだろうが、空いているし山道で気持ちがいいので、すごく近く感じた。だから、結果論としてはショートカットする必要はなかった。

川の水は結構綺麗で、流れは速かった。ただ、今ひとつ狭くて物足りなかった。「渓谷」というより「園地」のほうが合っていると思った。が、実は、橋の反対側が本当の園地で広かったというオチがあった。

最初に僕が歩いたのは、昔の園地だったのだろうか。実際、階段は途中で途切れて居た。それでも、結構人が来るので、急流や渓谷が見られるから それなりに人気があるのかも知れない。

木の俣川の流れ

 

余裕があれば深山ダムにも行こうと思って居たが、まあまあ歩いて満足したので、13時頃 帰路に着いた。疲れたようで、途中で左の足首が つりそうになったが、何とか持ちこたえて休憩場所まで行けた。クラッチは結構細かい調整をするから疲れるのだろうが、僕の体力も落ちている。

国道4号は おもしろくないから好きでないので、なるべく避けた(行きも)。途中でガソリンを入れたり※買い物をし、16時頃 無事に帰宅した。疲れたけど気持ち良かった。

※随分高くなり、170円/l(ハイオク)を超えていた。一方、今回の燃費は13.7km/lと、ほとんど近場だった割には良かった。 ← (4/15 8:33) 前回(2月)の給油以降の走行距離の半分以上が今回のドライブだったからだろう。

 

いつものように車の調子は良かった。特にエンジンが軽く回るのが良い(とは言え、6000rpmとかまで回すことは まずなく、3000-4000rpmくらいで充分気持ちいい)。ただ、サスが少し硬くなったようで、路面の凸凹での車体の揺れが大きい気がする。バネやダンパーが劣化したのかも知れないが、大きな問題はない。先日清掃したフロントガラスには、また花粉が少し付いていたが、今降っている雨で落ちるだろうか。走行距離は ほとんど増えておらず、約5.9万kmだ。

 

やっぱり、変な車は居た。: 妙に遅い人(まあ、自分の最適なペースで走るのが いいので仕方ない)、同様に、もう少し速ければ気持ちいい道なのに そうせず、ちょっと遅い人(自分が気持ち良く走っているのだろうから、お互いさまで仕方ない)、信号などでの発進後になぜか右にずれて、少しの間センターラインを少し越える人(車種からして営業なのか、妙に飛ばしていた)。

 

(4/15 10:39 WPのスタイルを修正し、動画を埋め込んだ。)

  •  1
  •  0

Joplin(特にエディタ)がクソで使い物にならなくなったので※、他を探してみたのだが(試したものを付録に書いた)、結局、Zettlrしか残らなかった。エディタの機能ではJoplinは足りているのだが、遅かったり表示がジャンプしたりと邪魔されて普通に文章が書けないという点で、使うことができない。

※想像して欲しい。1文字打つ・消すたびに5秒くらい待たされるので、記憶と予想で新しいカーソル位置を想定して作業する苦しさを。30年前のviだって、そんなことはなかったよ。もちろん、何か大きなことをすると(いつ起こるかは不明)いきなりカーソルが行方不明になって、文章を書くレベルじゃねえ!

前回候補に挙がったTriliumは、(いろいろな問題はあるけど一番大きいのは、)内部的にMDでない(HTMLのようだ)※せいかJoplinのノートを開くと書式が変わってしまう。Triliumを使うために全部のノートを見て修正するなんてやってられないので、やっぱり使いものにならない。

※どうしてそうしたかは分からないが、推測してみると、MDよりHTMLのほうが 幅広い表現が可能なためかも知れない。が、世の中の標準に合わせずに自分だけの(詳細が不明な)仕様で通そうとしても先は ない。そういう点で、Triliumはセンスが悪い。

更に、PC(Linux)だけの話なら まだいいが、僕はスマフォ(Android)でもノートを共有して開きたい。すると、ノートの同期システムが必要になるのだが、こちらも(僕には)まともなものがなかった(例: ちゃんと同期しない、電池を食う)。また、同期するといっても、常に全部のノートをスマフォに入れておく必要はなく、見たいものだけ適宜ダウンロードすればいいのだが、そういうものは なかなかない。Dropboxは近いのだが、その上のノートをMDエディタで開いた時に画像が開けない問題があった。Dropbox対応のMDエディタなら可能かも知れないが、有料である。※

※高いものではないから、ちゃんと使えるなら買ってもいいけど、買わないと確かめられないので どうにもならない。

すると、PCとサーバとスマフォでノートを同期するという点では、Joplinは必要充分で なかなか良いことに気付いた。

なお、JoplinのAndroidアプリはLinux版と同様に重くて(EvernoteのAndroidアプリと同様) ほとんど編集はできず、表示専用と割り切っている。

そこで考えたのは、いつものように、JoplinとZettlrで「何とかする」ことだ。それぞれの得意な(「使える」)ところを使い、以下のように分業させるのだ。

JoplinとZettlrの分業

  • Joplin
    • (Linuxアプリ) ノートの管理
    • (スマフォアプリ) スマフォでのノートの表示
      • 重いので、編集は元から諦めている。
      • ノートの編集(書き込み)の代わりに、自作のメモ記録システム(BNote)を使っている。
        • 必要なら、そのメモをPCでノートに貼り込む。
    • ノートのサーバとの同期
  • Zettlr
    • ノートの編集

試しに上記の分業システム(のPoCかプロト)を昨日作り、どうにか動くようになった。以下に基本的な動作を示す。

動作

  1. Zettlrで編集したいノートに対して、Joplinで外部エディタでの編集を設定する(ノート名で右クリック → "Edit in external editor")。
    • あらかじめ、Joplinの設定の外部エディタに、JoplinとZettlrを連携させるためのコマンド(「コネクタ」?)を指定しておく。
  2. JoplinとZettlrを連携させるコマンド(zettlr.sh)は以下を実行する。
    1. 編集用にJoplinからエクスポートされたノート(「元ノート」)を作業ディレクトリにコピーする(→ 「作業ノート」)。
      • 元ノート自体をZettlrに指定してもいいのだが、Joplinの他のファイル(設定やログ)が見えるのが嫌だし、それらを誤って変更したり削除してしまうのを防ぐために こうしている。
      • また、下にも書いたが、Zettlrは単にファイル名を指定しても開けない場合があるので、(仕方なく)作業ディレクトリを作ることにした。
      • 更に、Zettlrはsym-linkは開けないようなので、(仕方なく)編集するノートを作業ディレクトリにコピーすることにした。
        • このために かなり面倒になった。。。
        • 調べたら、ワークスペースやノートのあるディレクトリにsym-linkがあると うまく動かないことがあるようで(→ 参照)、実際に この環境でもしばらく使っていたらノートが開けなくなってしまった(なぜか、Zettlrを再起動すると開ける)ので、(仕方なく)作業ディレクトリ直下からsym-linkを排除し、ノート中のリソース(画像)を抽出してJoplinのディレクトリからsym-linkして(サブディレクトリにある分には大丈夫なようだ)表示できるようにした。これで様子を見ることにした。
    2. 作業ノートを指定してZettlrを起動する。
      • あらかじめ、Zettlrに作業ディレクトリをワークスペースとして設定しておく。
        • 設定しないと、Zettlrが起動中に新たにノートを開く時にエラーで開けない場合が多い。
    3. 作業ノートの更新または元ノートが削除されるのを待つ。
      • 作業ノートの更新の場合、少し更新を「ためて」からJoplinのディレクトリにコピーする。
        • ノートを書いている時は頻繁に作業ノートのファイルが更新され、そのたびにコピーするのは無駄だし重そうなのでそうした。
        • 現状は、10回以上更新があったか、10回未満でも約20秒間更新がなかった場合にコピーするようにしている。
      • 元ノートが削除された場合(Joplinで外部エディタでの編集が解除された)、作業ノートを削除して終了する。
        • 作業ノートを元ノートにコピーしていない場合(上記の保留された更新が未反映の場合)には、エラーダイアログを出す。 → あとで手で反映させるなどが必要。
    4. 3に戻る。
  3. ノートの編集を終える時は、Joplinでノートの外部エディタでの編集の設定("Edit in external editor")を解除する。 → 元ノートが削除され、上の「元ノートが削除された場合」が実行される。

使っている時の画面を見ても、単に「2つのMDエディタが動いているだけ」だが、背後では上のような複雑な処理をしている。そのおかげで、Zettlrでノートを変更すると少し経ってJoplinの表示も更新される。

Zettlr(左)でJoplin(右)のノートを編集している様子

 

効果・良かったこと

  • 操作性: Zettlrは高速(というか、当たり前の速さ)だし、MDエディタとしての挙動も概ね一般的(Joplinに近い)なので、書く時にストレスがなさそうだ。
    • 今までのところ、機能不明・不足以外のストレスはない。
      • 他のエディタのようなプレビュー画面はない(印刷プレビューのみ)のだが、それで充分使えるところがZettlrの表示の すごい・うまいところだと思う。やたらに機能を増やさず、着実に進めている印象がいい。
    • 一方、Joplinのエディタは まさに"disturbance/distraction-ful"だ。
  • メモリ量: JoplinもZettlrも同じElectronで動いていると思われるが、Zettlrは随分まとも(というか普通)。
    • 開いているノートの数と使用メモリ量(アイドル時)の比較例
      • Joplin: 1ノート(サイズ: 約40KB): 約1.2GB
      • Zettlr: 5ノート(サイズ: 合計約1MB): 約680MB
    • Joplinはエディタの他にノート管理や同期の機能があるとは言え、メモリを食い過ぎる。多くのノートを開くと、簡単に2GBを超える。
    • Joplinのメモリは減ることがないが、Zettlrは作業状態に応じて ちゃんと減るのが いい(というか、それが普通だ!)。

処理速度もメモリ量も、同じElectronなのにZettlrは ちゃんとしているが、Joplinは全然「なってない」。Zettlrができているので、やればできるはずのことをしていない(Androidアプリも同様にひどい)。作者は、手を広げるよりも、まず こういう基本的なところを詰めるべきだと思う。

惜しいこと

  • ノートを編集するたびにJoplinで外部エディタでの編集を設定するのが面倒。
    • Joplinを終了しなければ設定は維持されるので それほど煩雑ではないが、(可能ならZettlrに組み込まれた)シンプルなメニュー的なものが欲しい。
  • JoplinとZettlrの管理情報(タイトルの設定方法やタグやノートのIDやマークダウンリンクなど)が別々なので煩雑。
    • ノートIDの統合はできないだろうから、Joplinをベースにするしかなく、必要になるたびにJoplinに戻るのが面倒そうだ。
    • 書いていて気付いたが、Zettlrで貼り込んだ画像をJoplinに戻す必要があることを忘れて居た。面倒かも知れない。。。
    • 同様に、新規ノートはZettlrでは作れない(Joplinに入れる機能がない)。: なかなか先が長そうだ・・・
  • Zettlrの編集機能が「もう一声」。
    • 総合的には、試した他よりは ずっといいのだが・・・
      • 書式設定の機能・メニューが少ない。
      • 日本語処理は特にしていないようで、日本語中の英語の単語選択(ほとんど文章全部が選択される)もスペルチェックも誤動作する(ノートのほぼ全体が真っ赤になるw)。
    • このブログ(WordPress)のエディタくらいの機能があれば言うことないが、なかなかうまく行かないものだ。
      • 何度もブログでノートを書くことを考えているのだが、エディタの機能だけで済むものでもなく、なかなかうまく行きそうにないので諦めている。
    • あと、テーマがどれもイマイチ。自分でCSSをいじれるが、もう少し普通の感覚のものを用意して欲しかった。
      • もしかすると、日本(というか、僕?)以外では、用意されたものがごく普通なのかも知れないw が、特に色遣いの趣味が悪い。明る目の緑とかキツい赤とか止めて欲しい・・・
  • "Zettlr"の綴りが いつも分からないw
    • Zettler? Zottler? Zottero? ヒ○ラー? デスラー?などと、最初の"Z"しか分からない。

メモ・残件

  • ファイル更新の検出は、inotifywaitというコマンドを使った。これをモニターモードで動かし、出力されるイベントを読み込んで処理する。
    • ファイルのコピー中などに起こったイベントを落とさないように、モニターモードで動かすことにした。
  • 連続した複数のイベントを保留してまとめる処理は、イベントの読み込み(bashのreadコマンド)にタイムアウトを指定することなどで実現した。
  • 現状では、編集中のノートごとに上のファイル更新の検出処理が起動されてイマイチなので、いつか統合したい。
    • ただ、基本的に待っているだけなので、負荷は高くない。が、無駄にプロセスが多くなって気分が悪い。
  • 上に書いたように、Zettlrで追加した画像や新規ノートをJoplinに入れる処理が必要だが、作るのは容易ではない。対応できるまでは適宜Joplinを併用するしかない。

 

付録: 試して却下したMDエディタ

以下のもの(すべてLinux版)を試したが、どれも僕には今ひとつだった。次点的なものはMark TextとAbricotineとReTextだった。

(書いたあとで再度試して分かったが、)Mark Textはキーの挙動と勝手な修正とメモリ量などを我慢すればZettlrより良さそうで、乗り換えたくなっている。が、更に少し試したら結構バグがあるようだし、ノートを勝手に修正されるのは困るので、保留した。Abricotineはメモリを食うのが惜しい。ReTextは いろいろ惜しい。いったい何を考えているのか分からない。そこを直せばいい感じだ。

  • Remarkable: パッケージ不足でインストール不可だった。
  • ReText: タブキーで箇条書きがインデントしない。
    • プレビューの画像のサイズが大きい(リサイズされない)。
    • ライブプレビューの表示位置がエディタと同期せず、不便。 (← レンダラーにWebkitを使えば同期する。)
    • 改行の解釈・処理が違うようで、改行だけで次に空行がないと、行が繋がってしまう。
    • メモリ量は少なそう。
  • Mark Text: MDを勝手に変更(修正)する。カーソルがノート内にある場合、Page Up/Down, 上下キーの動きがおかしい。
    • MDの箇条書きの子要素の前に余計な空行が入る(MDを勝手に変更する)。
      • その他も勝手にいろいろ(空行や空白など)書き換わる。「正しいMD」に修正してしまうようだ。
    • MDの空行が無視される。入れてもなくなる。
    • 細かいバグが多そう。
      • Ver. 1未満なので仕方ない? (結構時間は経っているが・・・)
    • 日本語対応は一番良い。
    • 雰囲気はZettlrに似ている。
    • メモリ量は多目だが、Joplinよりは少なそう。
  • MindForger: PPAがUbuntu 20.4 LTS(focal)に非対応でインストール不可だった。
  • Abricotine: 開くノート(ウインドウ)の数に応じてメモリがかなり増える。約340MB+200MB/ノート。
    • 複数のノートは別ウインドウ
    • 設定がファイル
    • 表示は綺麗。
    • Zettlrに近い。
    • 古い: 2015年。ただし、GitHubでのリリースは2020年。
  • Notable: ワークスペース型で、ノートのインポートが必要。
  • Haroopad: タブキーで箇条書きがインデントしない。
    • 複数のノートは別ウインドウ
    • なぜか、メニューのフォントが汚い。
    • 雰囲気が、僕が使っているエディタjEditに似ている。
    • メモリ量は少なそう。
    • 寄付の表示が消せない。 (← ボタンを押せば消える)
    • 古い: 2015年。
  • GhostWriter: 複数のノートが同時に開けない。
  • QOwnNotes: 最初に何か(MDは不可)開かないと起動しない。
  • Markdownify: ライブラリが合わないようで、起動しない。
  • Znote: Joplinで作ったMDの画像が表示できない。
  • Apostrophe: Joplinで作ったMDの画像が表示できない。
    • 機能が貧弱
    • Flatpakなので、インストール・起動・アンインストールが面倒
  • StackEditPro: サイトが開けなかった。
  •  1
  •  0

シンドバッドとかエリーとかタコみたいな顔は関係ない(古過ぎるw)し、好きじゃない。

結構前から時々動悸がする。近頃は、なぜか、寝ている時も夜中に目が覚めて動悸がすることが多い。寝ている時は心臓に負担は掛からないはずなのに なんかおかしいと思って調べたら、SAS(睡眠時無呼吸症候群)で息苦しくて目が覚めた可能性があることが分かった。

SASは高血圧も引き起こすとのことで、仮にそれが治れば高血圧も治る可能性があるが、そういう甘い話ではないだろう。それに、SASというほど昼間に眠くなったりしないから、ひどくもないのだろう。

↑ と書いてから気づいたが、良く考えると昼は眠いことが多い(日記には毎日数時間おきに、「眠い」と書いている)w でも、昔からで、気づいたら寝て居たということはないので病的ではないと思うが・・・

この、「眠い」と思ったり書いたりするのは、一般的な、あるいは、SASの自己診断での眠気と同じレベルなのか、疑問だ。実際、昼に眠くて横になっても眠れないことが多いので、僕は単に眠い気がするだけで(、「だるい」などと同様 口癖で)、本当は、あるいは、一般的には眠くないのかも知れない。

なお、上の自己診断は5点で「日中の軽度の眠気あり」だったが、質問の「ときに眠くなる」の条件が分からない。その「眠くなる」と僕の「眠い」が同じなのかが分からず、最初は無意識のうちに ほとんど「決して眠くならない」にしていたくらいだ。

それで、とりあえず、スマフォの睡眠チェックアプリで試してみた。沢山出て来て どれがいいか分からなかったので、以下の3種類を(3夜に渡り)試した。

  • Sleep (Sleep as Android)
  • いびきラボ
  • 睡眠アラーム

それらで調べて分かったのは、寝始めて数時間後に突然大きないびきが出て、そのあと(おそらく いびきが終わった時)に目が覚めているらしい(いびきの終わりが夜中に目が覚めた時刻に近いため)ことだ。なので、最初に書いたように、呼吸が停まって苦しくなって目が覚めているのかも知れない。

意外だったのは、ほとんどの時間はいびきをかいておらず、一晩に数回だけだったことだ(これは眠りが浅かったせいかも知れない)。あと、自分では全然寝付けないと思っていても、実は寝て居た(と記録されていた)ことが多い(寝付けない状態が長くて、いびきが少なかったのかも知れない)。

ただ、どのアプリでも本当に呼吸が停まったのかは分からなかった。というのは、いびきの音量や睡眠の質はグラフなどで出るが、呼吸の有無(停まったかどうか)は出ないからだ。いびきの音が再生できるアプリでも、最初だけしか聴けない(有料板なら可能)ので、いびきが終わる時の状態は分からないし、いびきがない時は録音されていないから、仮に呼吸が停まったとしても、その時の状態は分からない。

今流行りのスマートウォッチや「手首に付けるやつ」なら分かるかも知れない。パルスオキシメーター付きだと完璧そうだ。

↑Amazonで調べたら、睡眠のチェックや血中酸素濃度が測れるものが数千円からあるが、どれにも悪いコメントがあって ひいた(Apple watchですら)。そういうコメントは少ないのだが、それが正しい気がしてならない・・・

結局、(手持ちで調べるなら、)PCとマイクで録音して、波形でいびきを見付けて、終わる辺りの音をチェックするのが良さそうだと思うが、面倒なのでやってない。

そういえば、以前も数回録音してみたことがあるが(確か、興味本位で寝言を聞こうとしたのだと思うw)、当時はダイナミックマイクだったりゲインの大きいマイクアンプがなくて音量が小さ過ぎたので、役に立たなかった。

 

アプリを試して分かったのは、どれも電池を食う(一晩で30-40%くらい)ので、毎晩使ったらすぐ電池が駄目になりそうなことだ。特に、いびきラボは電源に繋げて使うように指示され、なんと一晩中画面がonだった(そのためか、画面を下にして置けと出る)のでひどい作りだ。

試して良さそうだったのは、Sleep as Androidと睡眠アラームだった。ただ、どちらも一長一短で、それらが一緒になるといい気がする。

Sleepは、見た感じは分かりやすそうな まとまった表示なのだが、本当の意味(グラフの見方)が良く分からないところがある。また、録音は聴けない(無料版だから?)。有料版があるはずだが、その支払いの情報がない(有料板でないとできない機能の時に出るのかも知れない)。

睡眠アラームは睡眠の質といびきについて評価されるのがいい感じで、無料版でも先頭だけだが録音が聴ける。

それから、いびきラボは名前のとおり、いびきしかチェックできない。

一つ選ぶとすれば、Sleep as Androidだと思う(使わないが)。

 

その後、PCとマイクで寝ている間の音を録音して、いびきや無呼吸を調べた。2晩実施した。比べるつもりは なかったが、片方は飲酒して寝た。数時間にもおよぶので、全部を確認した訳ではなく、目ぼしい(例: 音量が大きい)いびきの辺りと無音の箇所をいくつかピックアップした。すると、以下のことが分かった。

  • アプリの時と同様、常にいびきをかいている訳ではないようだが、小さい いびきをかいている時間が結構長い。
  • 想像だが、息をしていて いびきをかいていない時間(音が聞こえない時)は鼻呼吸なのではないか。
    • というのは、昼間に呼吸の音は聞こえないからだ。まあ、寝ている時は呼吸が深いから音が大きくなるのかも知れないし、自分で自分の息の音は意識できないのかも知れない。
  • そのため、無呼吸かどうかは確実には分からない。ただ、いびきのあとよりも前のほうが起こりやすい気がした。
    • というのは、無呼吸が続いて苦しくなって大きく呼吸をし、それがいびきになると思うからである。
  • いびきの音にはいくつかの種類があり、ゴロゴロ・ブルブルと振動するような音は いかにも危ない気がした。
    • ゴロゴロしたいびきの前は息の音が聞こえず、無呼吸の可能性がありそうだった。
  • 目が覚めて動悸がした時の前は、無呼吸ではなかった。
  • 飲酒といびきのひどさなどは 余り関係なさそうだったが、2回では分からないと思う。
    • いびきの頻度は同様だった。
    • 飲酒した夜は いびきの音量が小さかった(約30%減)が、単に録音の関係かも知れないし、たまたまかも知れない。

なので、SASの可能性はあるが、それと動悸は余り関係なさそうだ。だったら原因は何かと思うが、ホルター心電計(下記)では問題なかったので、余り気にしないほうが良さそうだ(もちろん原因は知りたいが、何かない限り、これ以上調べるのは難しい)。

動悸とは別に、naokiさんがコメントに書いて下さったように、SASなら何とかしたい気はする。それで熟睡できて、昼に眠くなることが減りそうだからだ。もしかしたら血圧も下がるかも知れない。ただ、SASは鼻や喉の構造が主な原因だろうから薬では治りそうもなく、今度ずっと呼吸補助の機械を付けて寝るのは面倒な気はする。 (9/18 10:13)

 

そして、そもそもの動悸についでであるが、昼も起こるからSASが直接の原因ではないだろう。実は、少し前に健康診断で心電図に軽い不整脈が出たので、医師に相談してホルター心電計※というので24時間測定したところ、たまに不整脈があるが連続・頻繁でないから大きな問題ではないとのことだった。加齢によるものなのだろうか。あるいは、高血圧が関係しているのか(調べたら自覚症状の一つのようだ)。

そうすると、SASと高血圧と動悸・不整脈が相互作用しているのか分からないが、まあ複雑な(というか、解決は諦めたほうがいい)感じだ。

※夏だったせいか、これのシールやベルトが痒かった。僕は普通だと思ったが、外す時、看護師さんが「真っ赤」だと驚いていた。確かに、2週間くらい跡が消えなかった。

  •  1
  •  0

以前ちょっと書いたように、Androidスマフォでの自動処理などに便利に使っていたAutomagicが終了になってしまったので、他の同等なアプリに移るか使わないで済むようにしようとしていた。具体的には、それまで使っていた2つの処理: スマフォ内の画像のPCへの自動転送とWriteNoteの代わりのメモ作成・送信が対象だった。

調べてみると、有名なTaskerは余りにも操作性が悪いとのことだったし(あと、デモ版がない)、ちょっと試したAutomateは まあ悪くなかったが、またいつか使えなくなる可能性があるのは嫌だし、電池を食う可能性があったので、そういうアプリを使わないで済む方法を考えた。

WriteNoteの代わりについては、以前も書いたように、比較的容易にBNoteという自分用サービスができた。自分のサーバでノートを記録するサーバプロセスを動かしておき、スマフォのブラウザで書き込むものである。

残ったのはスマフォ内の新規画像(動画、音声も可能)のPCへの自動転送だが、これがなかなか難しかった。技術的には全然高度ではないが、Automagicなどのようなアプリなしでスマフォを外から状態取得・制御することは不可能なので、そこを「なんとか」するのが難しかった。具体的には、スマフォ内に新規画像が出来たことはスマフォしか知っていないが、AutomagicなどがないためPCに通知することができないのだ。

それでも、いろいろ考え、試行錯誤やAndroidの動作を確認して、以下のような処理にした。スマフォ側アプリは使わないので、全部Linux PCからの処理だが、念のため、処理の主体として"[PC]"と書いた。

  1. [PC] スマフォがLANに接続され、sshが通じるまで待つ。(= スマフォが室内に入ったか、スリープが解除されるまで待つ。)
  2. [PC] スマフォ内の新規画像の有無を調べる。
  3. [PC] 新規画像があれば取り込む。
  4. [PC] 少し(今は3分)待つ。
  5. [PC] スマフォがLANに接続されていてsshが通じていたら、2へ。
  6. [PC] スマフォにsshが通じなくなったら、1へ。

最初に書いたように、元々Automagicのプログラムからの通知を契機に画像をPCから取得するプログラム(システム)があったのだが、それを上のような処理もできるように変更(機能追加)した。従来のはサーバーモード、今回のはpull(またはポーリング)モードと呼んで居る。今回は、上の処理の3以外の部分を作った(正確には、共通部分=3は同じものを使いたかった)。

なお、「スマフォ側アプリは使わない」と書いたものの、実際にはsshサーバアプリ(SimpleSSHD)を使っている。これにより、PCからスマフォに接続してコマンド(多くのLinuxコマンドが使える)を実行したり、スマフォのストレージにアクセスしたりする。sshサーバ(sshd)はとても汎用的なので、Automagicのようにディスコンになって困ることはまずない。ある製品がディスコンになっても、互換の別のものに置き換えることが容易なためだ。

スマフォ内に新規画像が出来たことをスマフォから通知できないので、PCから定期的に調べる(ポーリング)ことにした。この方法はほとんどいつも無駄にファイルを検索するので好きでないが、仕方ない。頻繁にストレージにアクセスすることで電池消費率が増えなければ良しとしたが、今のところ問題なさそうだ。Androidの仕様なのか、スリープ状態の時は処理が遅くなる(例: 新規画像の検索(の開始)に1分以上掛かることがある)ので、GUIでないプログラムも省電力化されているようだ。

それから、外から帰って来た時などに、スマフォへの接続がなかなかできない問題があった。いろいろ調べたら、スマフォがルータに接続していないためで、当たり前のことだった。Androidはあまり頻繁にWi-Fiをチェックしないようだ。帰宅して画面を点灯しないでいると数十分は繋がらないので、15-30分間隔だろうか(それで、以前は即座に繋げるようなフローをAutomagicで作ったのだが、電池を食うので止めた)。

もう一つの問題は、やはり省電力化に関係すると思われるが、sshで繋がっても、コマンドによって処理が遅いものがあることだ(速いコマンド・場合があることが謎である)。具体的にはrsync(新規画像の取得に使う)が遅くなることが多かった。また、find(新規画像の検索に使う)も遅くなることがある。正確には、どちらも実行が遅いのでなく、起動するのが遅いようだ。rsyncは数分間掛かることがあり、普通の設定だとタイムアウトしてしまう。かといって、タイムアウトを10分などにするのも今ひとつだ。

それで、試しに、sshfsでスマフォのストレージをPCにマウントして画像取得してみたら、マウントされるのが遅いことがあるものの、その後は高速に処理できたので、画像取得はsshfs+rsync(スマフォのストレージをローカルととして扱う)で行うことにした。

ただ、そんなことは(今まで使っていて、今回も使っている)画像取得プログラムは想定していないので、いろいろな対処(「調整」)をした。それらを場当たり的でなく、なるべく汎用的にするのが大変だったが、「まあまあ」だ。

その他に、スマフォの処理状況をPCは分からないので、書き込み中の中途半端な画像を取り込んでしまうのを防ぐことにした。これも どう実装するか悩んだ。結局、ファイルの更新時刻が新し過ぎるものは取り込まないようにした。※ 具体的には、ファイルの更新時刻が現在時刻より1分以内のものは次回(約3分後)に取り込むようにした。

※他の方法として、画像ファイルなどの中身(が正しいか)をチェックすることも可能だが、既存のプログラム(例: ffmpeg, ImageMagickのidentify)で最後の数バイトが欠けても分かるものはなさそうだったので、止めた。

ただ、3分待たずに画像を取り込みたいこともあるかも知れないので、以前同様に手動取り込みもできるようにした。スマフォ側からは、ブラウザでPC側のサーバに(従来と類似の手順で)アクセスする(通知を送る)ことでできるようにした。PC側からは、上の2と3の処理を(周期的なタイミングでなく、)僕のしたいときにするような処理にしている(従来と同じ処理)。

細かい工夫として、スマフォのIPアドレスはルータの設定や交換などで変わる可能性があるが、そのたびにPCの画像取得の設定を変えなくても済むように、スマフォをMACアドレスで管理し、通信する時にarpコマンドでIPアドレスを調べるようにしている。なお、スマフォやPCが起動直後などでarpテーブルに登録されていない場合は、broadcast pingなどで調べるようにした。

 

作って(正確には既存プログラムの改良)出来て、それなりにちゃんと動き出した。手前味噌だが、スマフォで写真を撮影したり画面キャプチャして少しすれば(忘れて居たりするw)勝手にPCに来て、digiKamで"New"のタグが付けられていて一目で分かるので、かなり便利だ。

 

という訳で、めでたく(というか、多くの場合と違って何も問題はなかったので、めでたくはないのだが)Automagicを使わなくすることができた。

 

(バックグラウンドで動く、純然たるサーバプログラムなので全く画像がない。出すとしたら、(ハッカー映画みたいな)ターミナルにデバッグ文字列が流れる動画?w)

  •  0
  •  0

少し前の話だが、2要素認証のワンタイムパスワード(TOTP)生成用のアプリAuthyを止めた。それ自体は便利だったのだが、Linux版が嫌いなSnapというソフト配布システムを使っていて、Snapを止めるために止めることにした。

乗り換え先のアプリを検討したが、Authyのように、LinuxとAndoroidで動いてTOTP生成用データを共有・共用できるアプリはなかった。ただ、パスワードマネージャのKeePassXC(Linux)とKeePassDX(Android)はTOTPに対応しており、それらはクラウド経由でデータが共有できるので、使えそうなことが分かった。

一方、同じアプリでパスワードとTOTPを管理するのでは、2要素認証の意味がなくなって脆弱な気がしたので、次の方針にした。

KeePassXCとKeePassDXでパスワードとTOTPを管理するが、マスターパスワードの異なる別のDBに格納する。

そのため、実際のログイン時の操作は少し面倒で、以下のようになる。

  1. パスワードのDBを開き(パスワードDBのマスターパスワードを入れる)、目的のサイトなどにユーザ名とパスワードを入力する。
  2. 2要素認証のサイトではTOTPのDBを開き(TOTP DBのマスターパスワードを入れる)、目的のサイトなどにTOTPをコピー・ペーストする。

マスターパスワードが増えて なかなか面倒だ(その他にもPCやサーバのログインなどのパスワードがあり(これらもDBに入っては居るが、開くのが面倒なので覚えている)、記憶の上限に近くなっていて、時々こんがらがる)。Linux対応の指紋読み取り装置があれば使えるだろうか? 他にもっと便利な仕組みはあるだろうか?

近頃はFIDOとかいうのが有名だが、名前しか知らない。 → LinuxではYubiKeyというのが使えるそうだ。それを買うのもいいが、スマフォの指紋読み取りシステム・デバイスをLinuxにも使えれば手軽でいいが・・・ (これはおもしろそうだが、セキュリティ的にはどうなんだろうか? それに、きっと「root化」しないと無理だろう。)

なお、Andoroidには(TOTPには対応していないが)上記のアプリとDBが共用できるKeepass2Androidというパスワードマネージャもある(KeePassDXの前に使っていた)ので、パスワードはKeepass2Androidで、TOTPはKeePassDXでアクセスすることにして、アプリ内でDBを切り替える手間を省いた(KeePassDXは切り替えが面倒)。それから、Andoroidでは指紋認証でDBが開けるのでLinuxよりは楽だ。ただ、指紋を共用することで2要素認証の意味がなくなる気がしないでもないことに今気付いたが、どうなんだろう?

 

それから、以前も書いたが、Authyはデータをエクスポートできないので、移行する際は、Authyに登録している全部のサイトのTOTPを設定し直す手間があった。また、退会を申し込んでも30日間は保留され、毎週リマインダのメールが来るのが結構鬱陶しい。

  •  2
  •  0