piu lentoの日々

(例によって、僕が弾くわけではないです。)

今日、ちょっとしたことで題の曲をYouTubeで探したら、なかなかなかった。6人目くらいで、Olga Schepsという人の(2014)が、その目的(第2楽章の最後の音の例を示す)には良かったのだが、Spotifyでちゃんと聴いてみたら、イマイチだった。オケは室内楽になっていて、それは基本的には嫌いなんだけど、伴奏(演奏)としては良かった。が、ピアノがすごくイマイチだった。

それで、まともなのが聴きたくなって、ポリーニ(1960)にしてみたのだが、どうも気に入らなかった。その後、ルガンスキーも含めて8人のを試したが、どれも気に入ることができなかった。。。

結局、(当たり前過ぎて止めていた)一番最初(僕のクラシック初期)にいいと思った、Israela Margalitの(1974)を聴いている。これだって最高ではなく、言いたいこと(演奏については少なく、音質が主なので、許せる)はあるが、他よりはずっといい。

一体なぜだろうと思う。刷り込みなのか、お酒を飲んたせいで判断力がおかしいのか。ただ、どうしても一言言いたいのは、長ーいイントロのあとのピアノの最初の音は、「ダーーン」と かなり開放的に(、でも、力任せにではなく)弾いて欲しいのだが、そこで既に気に入らないのだ! (「いいから僕にやらせろ!」と言いたいけど、まったく無理で、歯がゆい限りだ)

我ながら、まったく困ったものだｗ

PS. だから、(前にも書いた気がするが、)ずっと、この曲はそれほどいい曲ではないと思っていたのだが、いい演奏が少ないせいもあるのではないだろうか。要は、この曲の良さとか良さの引き出し方が理解されていないのだろうか。でも、それはなさそうだ。単に僕の好みだろう。

(結構前からやっている、スマフォ関係の作業(家に居る時にモバイルデータを使わないようにすることの徹底)が予想外になかなか収束しないので、先日から思っていた別の話題を書く。)

先日、Spotifyで、あるピアニストのモーツァルトのピアノ協奏曲 第21番を聴き、(第1楽章の時点では)「結構許せる」と思った。知らない人だったが、ジャケットに目をひかれたので、試す気になったのだ。

それで興味を持って、聴きながら、どういう人なのかと検索したら、その人は目が見えないことを知ってしまった。全然気付かなかった。これなら問題ないと思った。どうりで、ジャケット写真で黒いサングラスを掛けていた訳だ(それがなかなかかっこ良かった)。

ところが、その後、第2楽章が少しガタついているのが気になってしまい、その後で試したK. 488もガタガタで駄目だった。

自分では、決して演奏者の属性(例: 経歴、言動、身体的特徴、民族・国・地域)で演奏の良し悪し(正確には、「自分がいいと思うか」)を判断しないようにしているつもりなのだが、もしかしたら、目が見えないことを知って、無意識のうちに負のバイアスを掛けてしまったのかも知れない。自分の感覚とか意識を疑ってしまった。知ってしまった以上、再度同じ演奏を聴いても同じ(中立な)感想にはならない気がするので、もう遅い。

同様に、数日前に、あるピアニスト(以前から好きではない人)が難病であることを発表したが、そうなると(そういう行動でなく、)演奏を批判するのも躊躇われる(例: 不用意に批判すると、「病気にも関わらず頑張っているのに けしからん」となる)ので、僕としては好ましくない。

結局、以前からの持論の、(芸術家の)属性は作品とは別であり、属性を知らないほうがいい・知る必要はないというのを更に堅くした。

PS. とはいえ、気に入った人なら どういう人か知りたくなるのも人情で、そこの解決は難しい。半分冗談だけど、演奏者は全員、記号とか番号で発表すればいいのに。もちろん、ジャケットには本人の写真などなしだ。作曲者なども同様にして、「X1234のピアノ協奏曲第1番、ピアノ: P345、指揮: C87、オケ: O65」とかにする。そうすれば、ちょっと昔の偽作曲者騒動もなかっただろう。でも、随分味気ないなｗ

それに、この方法はコンサートでは使えない(本人がステージに出て来ざるを得ないので)し、演劇でもまったく無理だ。パフォーミングアートとは相容れない考えなのだろうか。

↓

実現の可能性があるのは、自分がまったく何にもとらわれずに、常に中立の立場で鑑賞し、評価することだろう。だが、なかなか難しいと思う。強靭な精神力(例: 大嫌いな人の演奏でも聴く)と、正しく評価するための知識(例: 単に「いい」でなく、「※が＊だからいい」と示せること)が要るだろう。

技術バカ者たるもの、謎は解きたいので、先ほど不明だった、ダイソーのUSB LEDランプの消費電流を測ることにした。ただ、僕は直流電流がまともに測れるデジタルテスターなんて持ってないので、どうにかする必要がある。

最初は、AC電源の消費電力を測るエコチェッカー(= ワットチェッカーもどき: 本物を持っていたが、寿命のせいか壊れたので、同様のものを買った)でACアダプタの消費電力を測ってみたのだが、さすがに小さくて"0W"なので、有効な値を得るには数時間くらい点灯したままにしなければならず、まぶしいし面倒だし精度も悪そうなので止めた。

仕方なく、手持ちの物を駆使して測ることにした。理論的には、電源と小さい抵抗(例: 1Ω以下)と電圧計があれば、電流は電圧として測れる。以下に、その模式図を示す。

                      電圧計
            ↑   ↑ 
電源 |+ ———> 小抵抗 ———> +| 測定対象
    |- <—————————————— -|

ところが、うちには小さい抵抗なんてない。しかも、実際に上図のように接続するには、USBを受けてバラ線にして抵抗を通して、またUSBに直せるようなものが要るが、そんな気の利いたものはない! でも、そんなことで諦める訳にはいかないのでｗ、手持ちの物で何とかすることを考えた。そして、もはや遺物とも言える、USB→PS/2変換コネクタ(以下、変換コネクタ)と余っているUSBケーブルを使うことを思い付いた。以下に、その構成を示す。

               電圧計 
      (USB-A)   ↑   ↑               (USB-A) 
USB電源 |+ ——> 小抵抗 ——> | 変換コネクタ | ————> +| ランプ
        |- <———————————— |           | <———— -|
          USBケーブル (バラ - PS/2のピン)

変換コネクタの中は直結であることが分かっているので、それを分解するなどして、USBの線を出せるようにすればいい。最初はプラスティック部を切って開けようとしたのだが、大変だったので、PS/2コネクタの円筒形の金属部をラジオペンチで力任せにひねったら、うまく外れて、ピンに線を半田付けできそうな感じになった。

そして、USBケーブルのBコネクタを切断して線を出して、対応するPS/2コネクタのピンに半田付けした。一つだけ忘れてはいけないのは(実は危うく忘れた)、片方の電源の線だけは直結せずに、途中に抵抗を繋げられるように、2つのミノムシクリップに繋ぐことだ。予想以上にうまく行って、抵抗なしの(ミノムシクリップを直結した)状態で、ちゃんと点灯した。

次に、電流を電圧に変換する抵抗を用意する。上に書いたように小さい抵抗なんてないが、10Ωは沢山あったので、それをとりあえず10本並列に繋げて1Ωにした(もし駄目だったら、さらに10本追加して0.5Ωにしようと思っていたが、大丈夫だった)。これもうまく行って(ただ、テスター自体か電池が劣化しているのか、実際の抵抗値は測れなかった)、ちゃんと電流(正確には1Ωの両端の電圧)が測定できた。

そして、目的の電流測定結果は予想外というか予想通りというか、「さすが中国」であったｗ

1Ωの抵抗の両端の電圧は約0.27Vだったので、以下の計算より消費電流は約270mAとなり、記事での値(292mA)とほぼ合った。

オームの法則より、電圧E= 電流I×抵抗Rなので、I= E/Rとなる。
ここで、R= 1Ωなので、I= E/1= Eとなるから、
電流I= E= 約0.27A = 約270mAとなる。

なお、抵抗での電圧降下は約0.27Vで、これがランプの点灯回路の動作を変えて、消費電流(の測定値)に影響しないかという疑問はあるが、定格電圧(5V)の10%未満なので問題なさそうだ。実際、見た目の明るさは変わっていない。なお、もしランプの消費電流が仕様通り1Aだったら、電圧降下は1Vとなるので、良くないだろう。

それにしても、3倍以上(仕様では1-1.2A)にもサバを読むとは、さすが中国だ。もしかしたら、中には仕様どおりに大電流を食う、ものすごく明るいものがあるのかも知れない。それはきっと「当たり」なのだろうｗ もしかすると、ほとんどが暗い不良品で、ごくまれに良品があるのかも知れないな。それはそれでおもしろいが、僕はこっちでいい。

PS. 余談だが、更に正確に測定するなら、まずは抵抗値を正確に測る必要がある。例えば1本ずつなら測れるかも知れない(でも、アナログなので、誤差が結構ありそうだ)。次は、テスターの測定値(電圧)の較正だ。基準電圧としてボタン電池が使えるだろうか。あとは、なんとかして直流(抵抗両端の電圧)を周波数に変換できれば、それをPCの音声入力に入れて取り込んで解析すれば測れそうだ。いやいや、安いデジタルテスターを買うのが一番いいよｗ

(2/15 22:27 わずかに追加, 2/16 7:50 図を改良)

先日、ニュースでダイソーのUSBで点くLEDランプの記事を見て、妙に便利そうな気がした。ただ、記事の記述から手持ちのモバイル電池で点灯時間を計算してみると、約43時間と、手持ちの乾電池用ランタンの72または144時間より短いし、モバイル電池がないと使えないので不便な気もして、「まあいいか」と思っていた。

ただ、妙にひかれていたので、今日、散歩がてら買って来た。箱が目立たなく(透明パッケージ入りかと思っていたが、紙箱だった)て、置いてないのかと思ったが、良く見たらあった。箱に仕様が書いてあったので点灯可能時間を計算したら70時間近かったので、意外に長いと思って買って来た。家で試してみたら、結構明るくていい感じだった。

しかし、落とし穴があった。点灯可能時間を計算し直したら、10-13時間くらいにしかならなかったのだ。どうも、店内での計算を間違えていたようだ。実際、以下のように約11時間になる。

モバイル電池の容量: 13000mAh
ランプの消費電流: 1.2A= 1200mA
→ 点灯可能時間= 13000mAh/1200mA= 10.8時間

記事で引用されていた、

「12時間使ってもバッテリー消費は3500mAh程度」

は何だったんだと思うが、(中国製らしく)仕様がかなりサバを読んでいて(PSに書いたように、そのとおりだったｗ)、実際にはこんなものかも知れないから、それを信じると、以下のように約43時間使えることになる。

3500mAh/12h= 292mA → 300mAとする。
→ 点灯可能時間= 13000mAh/300mA= 43.3時間

どっちにしても、ランプだけに電池を使うのは本末転倒だから、実際に使えるのはこの数分の1だろう(要は「おまけ」ってこと)。そして、更に間抜けだったのは、モバイル電池にもライトが付いていたことだ。

まあ、そのライトは見るからにそれほど明るくないから、ランプの立つ瀬はあるのだが、電池とランプの2個要るよりは電池だけの方が便利だ。

なお、明るさについては、以下のようにランタンのLOWモードと同等だから、この点は悪くなさそうだ。

• ランタン(Gentos EX777XP): 280lm (LOWモード: 140lm (推定))
• このランプ: 150lm

結局、このランプは車に積んでおこうかと思っている。車のバッテリーは大容量だから、かなりの長時間点灯できそうだ。僕の車のバッテリーは36Ah(12V)だそうなので(今知ったが、型番の数字は「性能ランク」なるもので、"46"だと容量は36Ahだそうだ。なんか騙されてる感じだ)、全部使ったとしたら、

(36Ah*12V)/(5V*1.2A)= 72時間

と、意外に短い。このランプは(中国製らしく)効率が悪くて電流を食い過ぎるのだろうか。それとも、何か計算を間違えている? なお、記事に引用されていた値を信じた場合、(36Ah*12V)/(5V*300mA)= 288時間になるから、これなら悪くない。

まあ、いずれにしても、いろいろ間抜けだったｗ 結局、提灯記事(ではないかも知れないけど)に乗せられたってことなのだろうか?? まあ、非常用品は冗長化するに越したことはないし、あとで何かに使えるかも知れないから、良しとしよう。

PS. なんか、本当の消費電流を測りたくなって来た。すぐにはできないので、今後の課題としようｗ

↓

早速測ってみたら、記事の引用していた値(約300mA)が正しいことが分かった。 (20:52)

PS2. 本当は、夜にランタンと明るさを比べようと思っていたのだが、面倒なので止めた。「点けばいい」って感じだｗ (21:07)

本サーバのPHPを最新版(7.3)に更新した。先日書いた手順で行った。いくつかトラブルがあり、一時(php-apcuのインストールがうまくできなかった時)は諦めモードになったが、何とか解決できた。約3時間掛かった。以下に、作業中に起こった問題と概要を示す。

• コマンド(add-apt-repository)がない。
  • 最初は手で最新PHPのPPA(リポジトリ)を追加したのだが、pgpの鍵も入れないと警告が出るので、パッケージsoftware-properties-commonをインストールし、上記コマンドを追加して改めてリポジトリを追加した。
• php-apcu(とphp-common)が古いものしかインストールできない。
  • なぜか、他と同様に"php7.3-apcu"のように指定してもインストールできなかった。
  • いろいろ試しても駄目だったので、以下のように、バージョンを指定してインストールした。

sudo aptitude install \
php-apcu=5.1.17+4.0.11-1+ubuntu16.04.1+deb.sury.org+1 \
php-common=2:69+ubuntu16.04.1+deb.sury.org+1

• • その後、aptの追加設定(/etc/apt/preferences.d/ondrej-php.pref)に上記モジュールを有効にする設定が漏れていることに気付いたので、以下を追加した。

Package: php-*
Pin: release o=LP-PPA-ondrej-php
Pin-Priority: 500 # 注: 優先度をデフォルト(500)以上にしないと、古いものがインストールされてしまう。

• ブログアクセスでHTTPエラー500
  • 最新のphp-fpmの設定ファイル(php-fpm.conf)のコピーを忘れていたために、php-fpmの設定が今までと異なっていて、webサーバとphp-fpm間のソケット(通信路)がない(正確には食い違っている)ためにエラーになっていた。
  • 元の設定ファイルをコピーした。
• 自作プログラム(古い投稿の非表示プログラム)が山ほどの警告を出す。
  • 昔作ったプログラムで、WordPressの関数add_action()の第2引数の指定方法が間違っていたので修正した。
  • PHPのバージョンが新しくなって厳しくなったのか、ずっと気付かずにいたのか・・・
• systemctlコマンドでphp7.0-fpmのサービスを無効にできない。
  • 先にPHP 7.0をアンインストールしたため、そのsystemctl用の設定もなくなったためと思われる。
  • 手(ちょっとしたスクリプトをコマンドラインにコピペ)で、/etc/rc?.d/S*php7.0-fpmの"S"を"K"に変更した。

php-apcuの問題は、デスクトップPCで試した時に確認し忘れたので、今まで気付かなかった。

主要な動作確認は問題なく(修正もした)、残件としては、今回追加した最新のPHPのパッケージが自動更新されるか確認する必要がある程度だ。

↓

今朝、ログのローテート処理がエラーになっていた。PHP 7.3をインストールするとphp-fpmのログのローテート処理も追加されるのだが、それと元の処理が競合していた。php-fpmのプログラム名にバージョン番号が付くため、PHPのバージョンに関係なくphp-fpmのローテート後の処理を実行させるのが容易でなかったが、なんとか回避した(phpでプログラム名を出して、それを使うようにした)。 (2/12 5:37)

PS. 他の重要なプログラムが駄目になったりサポート期間切れにならなければ、OSは2021年頭までサポートされるので、あと1年以上は「安泰」で、来年中にOSをバージョンアップすればいい。デスクトップPCも同様だが、OSが古いために使いたいアプリが動かない問題が出るかも知れないから、少し早くなるかも知れない。

2/9に下記のようにお知らせしましたバージョンアップ作業が終わりましたので、サイトの運用を再開します。

 「サイトの一時停止予定のお知らせ」 (2019年2月9日 19:29)

サーバソフトのバージョンアップ作業のため、下記日程で本サイトを一時停止します。

2019/2/11(月) 朝から夕方頃まで (早期終了あり)

作業中は本サイト(ブログ)へのアクセスはできなくなります。断続的にアクセス可能になるかも知れませんが、不安定な状態ですので、終了のお知らせまでお待ちください。

なお、作業中に予期せぬ問題が生じた場合には、一旦止めて復旧させる予定です。

よろしくお願いします。

なお、しばらくは細かい問題が起こる可能性がありますが、その際は随時修正致します。

よろしくお願いします。

近頃、ある家族(A)の言動に妙なわだかまりを感じた。本人はPCを使わずガラケーなのでここを読むこともないだろうから、書くことにする。生臭い話だが、(将来の)相続に関係することだ。

Aは、学生の頃に父からマンションを与えられていた。父の死後もそれをずっと使っていて、税金や管理費や家賃を母に払っていたそうだ(僕はその額がどのくらいかは知らなかった)。

先日、そのマンションを将来どうするかという話になって、僕はAが今のうちに母から買い取るべきだと書いた(普通の相続も可能だが、ちょっと理由があって、そうでない方法も提示した)。更に、贈与してもらうことも可能だが、それは不公平な気がするとも書いたのだが、これがAにはカチンと来たようだ。Aの言い分はこうだった。

ずっと(数十年)、家賃などを支払っていて、その額は当時の購入価格を超えているから、贈与が不公平というのは当たらない。

なかなか唖然としたが、そのマンションの対価を求めたかった訳ではないので、そこは「分かりました。済みません」程度で終わらせたが、今にして思えば、「不公平」と書いた時は、なんかそんな気がしたからそうしたのだが、実は根深い理由があることに気付いた。

Aがマンションを与えられた当時、僕も学生だったか社会人になったばかりだった。その前も後も、僕はそんなに高価な物を与えられたことはなかった(そういえば、マンションをもらうどころか、借金の保証人になれと言われたことすらあった)。逆に、父が遺した失敗の尻拭いのために、さまざまな苦労や出費をさせられたくらいだ。そのせいで人生を狂わされたと言っても過言ではない(でも、今は、それは父の失敗のせいだけではなかったから仕方ないことだし、もし狂わなかったらとんでもないことになっていたから、その結果(今の状況)自体は悪くないと思っている)。

自分の部屋があれば、(簡単には引っ越せないデメリットはあるものの、)生活は随分楽だっただろう。何しろ、家賃を滞納したって追い出されないし、部屋をどう使ったっていいのだから。

Aは、若い頃に高額な利益を受け、その後も日頃の利益を享受し続けて来た。その利益に対して対価(家賃など)を払うのは当たり前で、何も威張れないはずだ。そのお金はその部屋を買う前提ではなく、住んでいるから払っていたものだった。それなのに、今になって今までの積算額が購入額を超えているからもらえて当然だっていう論理は通らないと思う。それなら、賃貸に長く住めば部屋がもらえることになるではないか。実は、僕は、Aが部屋を購入するということになったら、「今まで出した分で相殺してもらえば、安くなるよ」と言おうと思っていたのだが、大甘だったようだ。

要するに、僕が納得できないのは、(上の繰り返しになるが、)当時の僕らの状況で受けた利益は、今での価値よりかなり高価だったはずで、その評価をしない、あるいは、僕の苦労を一顧だにしないのはおかしいということだ。

でもまあ、ああいうことを書いた人にこういうことを言っても理解されないだろうし、言ってもつまらない(多分、「じゃあ、いくらお金を払えばいいですか」とか言われそうだ)ので、言うつもりはない。単に、「はいはい、ご自由に。クソが」と思うだけだ。そもそも悪いのは原因を作った父なのだが、Aだって、何十年も親が買った部屋に住み続けて来てそのままでいいのかとか、この先どうするのかとか考えず何もしなかったのはおかしく、ある種のズルをして来たのだと思う。向こうは当然のことだと思っているのだろうが、こっちにすれば、それが「不公平」という言葉につながったのだろう。

最後に、「良くある話だけど僕らは関係ない」と思っていたが、相続になると家族の仲が悪くなってしまうってのはやっぱりあったようだ。皆さんも充分気を付けましょう。ただ、いつどういうことがあるか分からないので対策もあまりなさそうですから、「覚悟しましょう」が合っていそうです・・・

PS. 「非可換」を検索したら、おもしろいページを見つけた。小学校で掛け算の順番を間違える(正確には「間違い」ではなく、先生用の「あんちょこ」と逆に書く)と×になる話だ(僕の時はどうだったか記憶にないが、無意味な問題の列挙された「ドリル」には散々苦しめられた)。そんなことやってるから、日本は世界から取り残されるんだよ! でも、相続なんかよりこっちの方がずっと興味が持てるｗ

そろそろドライブに行きたくなって来た。明日は雪だというので、今日がリミットだった(いや、溶けてからだって行けるが、そんなに待ちたくなかったのだ。それに、雪のあとだと車が汚れるしｗ → 2/9 12時: 雪はまだそれほどでもないが、ものすごく寒い(今の気温: 0℃)ので、昨日で正解だった)。行き先は、前回諦めた日鉱記念館にしようと思った。が、前回ナビに設定した時に、その手前のトンネルが有料になっていたので、そのトンネルの手前の奥日立きららの里というところにした。まあ、どっちにしたって、単にその辺りまで行くというだけで、大きな違いはない。

7:30頃出発した。前回は休日だったのでいろいろな問題があったが、今日も、いきなり忘れていた問題に遭遇した。平日の通勤の時間帯だったので、通ろうとした道がすごく渋滞していたのだ。僕が会社まで通っていた道も混んでいたが、あれほどではなかった気がする(忘れているだけかも知れない。ただ、時間は早い)。みんな、あれを毎日やっているとは可哀想だと思った。確かその道にはLRTができるから、そうなったら道が狭くなったり電車の影響で、さらに渋滞するのではないか。公的な指示は「LRTに乗れ」だろうから、何も補償(金銭とかでなく、謝罪的なもの)はないだろう。全く可哀想に。その道が全然動かなくなったので、Uターンしてもう少し南の道(R123)に行ったら、大丈夫だった。

この辺りで気付いたのだが、車のエアコンのファンから小さい音が出るようになってしまった。ファンが低速の時に出るようだ。段々寿命になって来たのだろうか?

曇りで風が強かった。途中、大型トラックが何台か前に連なって居たので、のどかに走った。気持ち良く走って、10:20頃、奥日立きららの里に着いたのだが、入り口にゲートがあったので、入場料なり駐車料金を取られる気がしたので、それならトンネルのお金を払った方がいいと思って、入るのを止めた。そもそも、そこまでの山道がすごく気持ち良く走れたので、きららの里なんかに入らず、そのまま走り続けたかったのだ。ところが、不思議なことに、トンネルは無料だった(普通のトンネルだった)。だから、車のナビの情報がおかしかったか古かったか見間違えたのだろう。

日鉱記念館があるだけあって、トンネルの向こう側には山を掘っている(切り崩している)作業所があり、ダンプが出入りしていた。幸い、葛生と違って埃などはほとんど問題なかった。会社の環境に対する姿勢の違いなのか、積む物が違うせいなのか、たまたまなのか。

10:40頃、山を降りて日立のコンビニに着いた。その前の田舎道で、しばらく、パトカーらしいけど屋根のライトが青い車が後ろに居た。ドライバーは、こち亀に出て来そうな若い女性で、ピシッとしたワイシャツがいい感じだった。隣には先輩らしき女性が居た。普通のパトカーではないが、警察の車の可能性はあり、その先輩が「前の黄色いの、スピード出しすぎで気に入らないから捕まえちゃいましょう!」とか言い出したら面倒なので、しっかり丁寧に走ったｗ この辺りでは、梅なのか、白い花がちらほら咲いていた。

お腹が空いたので、コンビニでコールスローを食べた。それからどうするか迷った。十王ダムにも行ってみたかったのだが、道が細そうなので今回は(疲れもあるから)パスし、良く行く花貫ダムに寄って帰ることにした。花貫ダムに上がる道も下りる道も気持ち良く走れた。前に軽トラなどは居たが、問題なかった。車はすこぶる調子良かった。トイレに行きたかったので、ダムは素通りして花貫物産センターまで行った。本当は戻るつもりだったが、ダムの近くにあったトイレ(公園?)を素通りして(例によって、トイレとここを混同していた)、結構離れてしまったので、ダムに戻るのは止めた。外は寒かった。隣のコペンの人が煙草を吸っていたようで、煙かった。標高が高いせいか、耳も少しおかしくなった。

そこから下る道でロードスターに追い付いた。マフラーとかいじっているみたいで迫力ある排気音だったが、それほど速くはなかったようだ(遅くはなかったので、見付けてから追いつくまで時間が掛かった: もちろん、煽るとかじゃなくて、普通に走っていて「追い付くかな?」と思っていたら追い付いた)。

その後、12:40頃、大子の道の駅 奥久慈だいごに着き、昼食にした。疲れと予想より距離があったせいで、結構遠く感じた。カレーやラーメンやけんちん蕎麦などで迷ったが、いわゆる日替わり定食であろう、にこにこセットというのにした。オムライスとしゃもフライと小たぬきうどんだった。750円。これが想像よりずっとおいしかった。冷やしたぬきうどん(本当は揚げ玉が好きでない)もおいしかった。うどん自体のコシが強くておいしかったうえに、揚げ玉がカリっとしていて良かった。これなら許せる。量もたっぷりだった。

道の駅の手前ですごく危ない車に遭った。彼は右側から僕の前に入って来た。それだけならいいけど、反対車線からも車が来ていたのに、その直前を横切って僕の前に飛び込んで来たのだ。おそらく、どうしても僕の前に入りたくて、右の車が目に入らなかったのではないか。老人なのかは分からないが(車はそんな感じだった)、呆れた。判断能力がなくなってしまったのか、元々ないのか。

道の駅には温泉もあるのだが、湯上がりで妙に色っぽい女性が居た。少し前の加賀まりこみたいな雰囲気だった。その連れは赤黒い顔の田舎のオヤジって感じで、良くあることだが、全く不釣り合いだった。娘じゃないとは思うが、良くわからない。まあ、どうだっていいことだｗ どうだっていいと言えば、TVで国会中継をやっていたが、茶番とか学芸会なのかと思った。分かってない人が分かってない人に聞き、分かってない人が答え、分かってない人が「＊の推進のために是非よろしく」とか言ったって、なんか意味あるのかね。。。

そして、思わぬところで森高を見つけてしまった・・・ 森高ともあろうものが、こんなところ(一番奥の目立たないところ?)に無造作に貼られていて、隣は落語だし、ポスター自体もセンスが悪いし、なかなか微妙だった。そして、結構高い(8640円)のにも驚いた。腐っても森高なのかｗ それにしても、彼女は何のために復活したのだろうか。僕には理解できない(ポールが今もやっているのと似たようなものか)。あと、なぜか、おじいさんがそのポスターの前にずっと立って居たのだが、僕が見つけて近くに行ったら去ってしまった。密かにファンなのだろうか?

疲れと、かなり遅い車(軽トラと大型トラック)が居たせいで、なかなか遠く感じたが、15:30頃、無事帰宅した。運動不足のせいか、身体が痛くなった。

今日は白バイを二台見た。一台は車を捕まえていた。一時停止だろうか? もう一台は高速のインター近くのコンビニに居た。高速で仕事して休憩していたのだろうか。青灯のパトカーといい、今は何かの安全週間だろうか。それとも、年度末のノルマ達成?? そして、工事が多かった。例によって予算消化か。余るんだったら税金下げるとか返せばいいのに! あと、至るところに老人が多かった。まったく高齢化社会になった感じだ。。。

225km、約8時間。
AQUOS sense liteにて撮影

技術面ではなく(簡単だという意味ではない)、「僕が気に入る演奏が少ない」という意味である。昨夜、ふと聴きたくなってSpotifyを漁っていたのだが、許せる人が全然居なかった。正確には、大好きなゼルキンは全然間違いないし(「鉄板」)、内田もピレシュも問題ないし、昨夜最初に掛けたアンスネスもいいのだが、いいと分かっているものをわざわざ聴くのではおもしろくないので他を探したのだが、おそらく10人以上試しても全然見つからなかった。

自分でも物好きだと思うのは、そうやって何度も同じ曲を(途中まで)取っ替え引っ替えしても、疲れはするものの、全然飽きないことだ。

そして今、振り出しに戻って、アンスネスの(2000)を聴いている。

彼の演奏は結構癖がある(素直そのもののゼルキンの(1982)とは全然違う)のだが、なぜか許せる。きっと、(僕にとって)何かいいもの、グッとくるものがあるだろう。技術があるのはもちろんだが、強い信念があるように感じる。そういうのには大抵反発するのだが、不思議と許せるもののようだ。

僕にとっては、(下手はもちろん駄目で、)普通も、奇をてらっても、わざとらしくても、この曲らしさを失っても(例: 音が薄い)駄目なのだ。まったく針の穴のように狭い。

彼のラフマニノフのピアノ協奏曲第2, 3番を最初に聴いた時は余り好きになれなかったが、近頃は大丈夫だ。そして、モーツァルトもラフマニノフもいいという点で、ルガンスキー(彼の演奏(2007)は今ひとつだった: 彼のモーツァルトは最高ではない、ラフマニノフほどすごくはない、と思った)を超えているのかも知れない。もちろん、「僕の中」での話である。

PS. 今日、自分でもおもしろかったのは、使う楽器でかなり印象が違ったことだ。フォルテピアノはもちろん好きでないのだが、遠山慶子という人のベーゼンドルファーでの演奏(2000)はどうも気に入らなかった(結構期待して聴いたのだが・・・)。音は澄んでいて綺麗だとは思うのだが、フォルテピアノみたいに弱くて芯が細いのだ。一方、同じアルバムのスタインウェイ(楽器の区別はwebによる)での第21番は悪くなかったから、僕はスタインウェイの「鋼の音」、骨太で凄みがあって、しかもきらびやかな音が好みのようだ(もちろん、それがモーツァルトに適しているのかは、議論のあるところだろう)。ヤマハやカワイは知らないｗ

モバイル通信のデータ量の節約には余念がないのだが、通信データ量を調べていたら、思わぬことが分かった。前にも書いたが、家に居るのにWi-Fiでなくモバイルが使われることがある(以下、「家でもモバイル問題」)のだ。それで、それを何とかしたいと思って試行錯誤していたら、僕の要求が相反していて、同時に全部は満足できないことに気付いた。要求を以下に示す。

• 電池消費率を削減する。
• モバイル通信のデータ使用量を削減する。
• (スケジュールなどの)同期を可能な限り定期的にする。

全部を満足させるのは無理で、どれを優先すべきなのか、それぞれをどういうふうに配分するのかの「さじ加減」が難しい。どれが一番重要かはいつも変わるのだが、(とりあえず今は)電池だということになった。その次はデータ量だ(上のリストの順に優先度が高い)。

その方針で、「家でもモバイル問題」に対処した。予想以上に大掛かりになり、うまく動くまでには結構(1週間くらい)時間が掛かった。以下に内容を示す。

現象

接続可能なWi-Fiルータがあっても、モバイルデータが使われてしまうことがある。

原因

Androidのディープスリープ(Dozeモード)に関係しているようだ(他に、アプリごとのディープスリープ"App standby"というのもあるらしい: 参考)。Androidのディープスリープ中はWi-Fi機能が停まり※、何かのアプリが通信する時に自動で再接続されるようなのだが、再接続が遅い(間に合わなかった?)場合にモバイルが使われるようだ。

※Wi-Fi機能の停止以外に、Wi-Fiの鍵の期限切れによる切断もある。

対処

基本的には、通信する時にWi-Fiが接続されていなかったら接続するようにすればいい。が、Androidにはそんな機能はないし(そうしているつもりなのだろうが、抜けがあるのか、「少しくらい(のモバイル)は大目に見て」いるから、この問題が起こっている)、調整するアプリもなさそう(調べてはいない)なので、Androidのグラフィカルなプログラミング言語Automagicでスクリプトを作った。ただ、Automagicではアプリの通信要求を検知することはできないし、その通信を保留することもできないので、以下のようにした。

注: 以下は私のスマフォ・OS・環境(AQUOS sense lite, Android 8)での確認結果に基づいており、すべての場合で同じであるとは言えない(スマフォのHW・ファームやOSが違えば、動作は異なる可能性が高い)。また、私はAndroidに関して詳しく調べた訳ではなく、Automagicのマニュアルの記述と実際の動作から推測したので、Androidの公式の仕様とは異なる可能性がある。以下で用いている単語(例: "Request Sync")はAutomagicで使われているものだが、Andoridでも同じかは不明である。

準備

Wi-Fiが停まっている時にも通信(同期)しそうなアプリ(例: メール、カレンダー、アドレス帳、Evernote)の設定を、自動で同期しないように変える(例: バックグラウンドデータや自動同期・受信をoffにする)。

注: Androidの、アプリに外部から同期要求を出す機能(Request Sync)を使うため、それに対応するアプリでしか対処できない。

定期同期処理

Automagicで以下の処理を実行する。

1. なるべく頻繁に、かつ、ディープスリープ中も発生しそうな、しかも消費電力が少ないイベントを待ち受ける。
2. イベント発生時に以下を実行する。
   1. 前回の処理からの経過時間が最小同期間隔(例: 30分)より短かったら、何もしない。
   2. Wi-Fiが有効な状態で、APに接続されていなかったら、再接続(WiFi Reassociate)する。
   3. Wi-Fiが使用可能(Active Network Type= WiFi)になるまで待つ。
      • Wi-Fiが無効だったり接続できなかったり使用可能にならなかったら諦める(→ モバイルが使われる)。
   4. 対象のアプリに同期の要求(Request Sync)を出す。

リストで書くとシンプルなのだが、Automagicはプログラムを図で描くのと、デバッグ用の機能を入れたため、実際のプログラムは大規模になった。普通の言語のようにテキストで書くならそうでもないが、図(しかもスマフォの画面でいじる)だとデバッグや保守がなかなか困難だ。。。 ただ、並行処理がたやすく書ける・実現できるのは、とても楽でいい感じだった。

Automagicでの定期同期実行+Wi-Fi再接続プログラム (概観)

以下に設定や条件などを書く。

対象のアプリは以下とした。通信状況の調査結果から、最も通信頻度・量が多そうで、外部から同期できるものを選んだ。

• メール(TypeApp): それまで使っていたAquaMailは外部から同期できないので換えた。いくつか試したうちでは一番良かった。 : TypeAppが原因の確証はないが、先ほどセキュリティ上の問題(GoogleのID・パスワード漏洩の可能性)が起こったので、使うのを止めた。AquaMailに戻し、この機能での同期は諦めることにした。詳細は追って書く予定。 (16:18) ← いろいろ調べたが、原因はTypeAppではなさそうだ。というのは、TypeAppにはGoogleのパスワードを入れていないからだ。余りにもタイミングが良かったので、誤解した。まとまったら書く。ただ、別件でも怖くなったので、TypeAppは止めることにした。 (21時) → 詳細をPS2に書いた。 (2/5 13:34)
• Evernote
• カレンダー同期アプリ
• アドレス帳同期アプリ

待ち受けるイベントは以下にした。

• Periodic Timer Inexact (定期的な(ただし正確でない)タイマー)
• Display State: On (画面が点灯したら)
• Notification on Statusbar (ステータスバーに通知が出たら)
• WiFi State: Enabled (Wi-Fiがonになったら: 帰宅時にWi-Fi Maticがonにした場合に起こる)
• WiFi Connected (Wi-Fiが接続されたら)
• Phone Cell GSM: On every cell change (モバイルの基地局が変わったら)
• Periodic Location Update (30min) (位置が変わったら: 注: 消費電力を増やさないため、GPSでなくNetworkのみを使う)
• Calendar Event (予定の通知が出たら)
• Automagic startup (Automagicの起動時)

基本的にはPeriodic Timer Inexactで同期間隔を実現するのだが、ディープスリープ中には間隔が長くなってしまう(例: 2時間)。そこで、なるべく同期間隔を正確にするため、ディープスリープ中も発生しそうなものを追加したので多くなった。が、実際にはPeriodic Timer InexactとDisplay Stateが同期の契機になることが多い。他のものはディープスリープ中にはほとんど発生しない感じだ。

同期間隔は30分としたが、アドレス帳はあまり変化しないので6時間にした。この間隔の種類を増やしてそれに対応する処理を追加すれば、アプリごとに間隔を変えることができるし、細かい処理を調整することもできる(ただし、プログラムは更に複雑になる)。

それから、Periodic Timer Inexactは発生間隔がアバウトなので、ある程度早目にイベントが起こった場合でも処理するようにした。

プログラムは概ねできて、今は動作確認・調整中である。なお、上にも書いたように、Periodic Timer Inexactはディープスリープ中は発生間隔がかなり長くなるため、同期間隔も長くなってしまう。これを解消できる方法も見つけた(下記「簡単にディープスリープを回避する方法」)のだが、消費電力が若干増えるので採用を見送った。これが、最初に書いたさじ加減の難しさの一つである。

ただ、実際に使う場面を考えると、家ではほぼPCしか使わないので、スマフォの通知が出なくても問題はないし、外では頻繁にスマフォを開くので、そのたびに同期が行われる可能性があるから、大きな問題ではなさそうだ。ちょっとした問題は、寝る前に作った予定や夜中に来たメールが朝になっても同期・受信されていない可能性があり、それに気付いて気分が悪くなる程度である。

以下、この過程で見つけた問題などについて書く。

通信遅延問題

ディープスリープの関係なのか、上記プログラムのログに書かれた同期時刻より遅れて実際の同期(通信)が行われることがある(サーバのログと比較して分かった)。呼び出す方(Automagic)からは同期処理が実行されたように見えているのだが、実際にはどこかに貯められていて、あとでまとめて実行されるような感じだ(→ 参考)。左の参考ページによれば、回避策はGCMを使うことらしい(が、それは廃止になり、FCMに移行すべきのようだ)。。。 いずれにしても、クライアントプログラムが非互換なので、そのままでは使えない。

簡単にディープスリープを回避する方法

今まではどうしてもディープスリープを回避できなかったのだが、偶然、方法が分かった。Periodic timer (Like alarm clock)を設定れば良い※。間隔は、例えば1時間でも2時間でも大丈夫だった。ただ、ステータスバーやロック画面にマークやアラーム時刻が表示されるので、紛らわしいし鬱陶しい。

※これはAutomagicだから可能なのか、Android全般に有効なのかは分からない。時計アプリにアラームを設定すれば確認できそうではある。

これより、Periodic timer (Like alarm clock)を待ち受けるイベントに追加すれば、同期間隔がかなり正確に保てることが分かった。しかし、消費電力が若干増える(例: 使用しない場合: 0.3-0.5%/h, 使用した場合: 0.5-0.6%/h)ために見送った。

PS. これの発端を調べたら、「(ディープスリープ時に)同期間隔が長くなるので、改善できないか」だった。結局は、同期間隔は諦めてモバイルデータ量の削減となった。やっぱり優先順位が変動しているｗ そして、こうやって書いておかないと、あとでまた同じことを気にし出す可能性が高いから、困ったものだｗ

PS2. セキュリティの問題を疑った件について

2/4に、何もしていないのにGoogleから確認コードの電話とSMSが来た。それで、Googleのパスワードが漏れたのかと思って心当たりを考えたところ、数日前にTypeAppをインストールしたので、そこから漏れたのかと思って検索したところ、件数は少ないものの、いくつかの悪い情報があった(→ 例)。それによれば、TypeApp(BlueMailと同じもの)はIDとパスワードを彼らのサーバに送っているとのことで、それが漏れたのかも知れないと思ってTypeAppを使うのは止め、登録したすべてのアカウントのパスワードを変更した。

ただ、そのあとで良く考えたら、TypeAppからGmailへのアクセスにはIDもパスワードも入れていない(Androidで「アクセス許可」をしただけ)ので、それらが漏れることはないのに気付いた。その他には、昨日インストールした別のアプリにも幅広く権限を得るものがあって疑わしかったのだが、それにしてもパスワードが漏れることは考えにくい。一方、昔、Linuxで使ったメールアプリにパスワードを入れた覚えがあるので、そこからの漏洩は考えられた。その他には、前述の疑わしいアプリがパスワードを総当りで推測した可能性はあるが、何度もログインに失敗したら警告が来そうだ。それでも、念のため、疑わしいアプリは削除した。

更に調べたら、他の人が自分のGoogleアカウントに2段階認証を設定する時などに電話番号を間違えて入れると、間違った電話番号にコードが届くそうだ(これは間違いであることが分かるように欲しいが、良く考えるとどうしようもない(SMSに本人の名前などを入れたらセキュリティリスクだ)。ただ、いたずら電話の道具になりそうで、嫌な予感がする)。他に、僕のメールアドレスはわかっているので、そのパスワードをリセットしようとしていることも考えられたが、その時には再設定用のアドレスにメールが届くようだからから分かる。

確かに、Googleのアカウントページには何も異常の記録がなく、警告のメールもなかったので、電話番号を間違われた可能性が高い。そういえば、どういう訳か、僕のところには以前から何度か間違い電話が掛かって来ているので、押し間違えやすい番号なのかも知れない。あるいは、ずっと僕(のアカウント)を狙っている人が居て、その工作の痕跡なのかも知れない。別に大したものはないから考え過ぎだろうが、ハインリッヒの法則からすれば、安心し過ぎるのも良くなさそうだ。注意一秒怪我一生。 (2/5 13:34)