Archive for the ‘日記’ Category

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  •   0
  •   0

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

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

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

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

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

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

 

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

  •   0
  •   0

モバイル通信のデータ量の節約には余念がないのだが、通信データ量を調べていたら、思わぬことが分かった。前にも書いたが、家に居るのに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. これの発端を調べたら、「(ディープスリープ時に)同期間隔が長くなるので、改善できないか」だった。結局は、同期間隔は諦めてモバイルデータ量の削減となった。やっぱり優先順位が変動しているw そして、こうやって書いておかないと、あとでまた同じことを気にし出す可能性が高いから、困ったものだw

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

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

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

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

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

  •   0
  •   1

イオンモバイルに移ってから1か月経ったので、先月のモバイルデータの使用状況を確認したところ、約216MB(制限: 500MB)だった。事前検討した時の見込みでは約250MB/月だったので、それより少なくて安心した。残量は繰り越されて、今月の使用可能データ量は800MB近くになった(このまま無制限に貯まるとうれしいのだが、そうではないのが残念だw)。

モバイルデータの使用量の変化 (2019年1月)

ただ、少し前に気付いたのだが、家に居ても(Wi-Fiでなく)モバイルが使われることがあり、それがデータ量を増やしているかも知れないし、そうでなくても気に入らないので、その対策をしている。謎が多くてかなり苦労したが、大体うまく行くようになった(あとで書く予定 → 書いた)。

使用量の多かったアプリ(上位5個)

  1. Evernote: 約28MB
  2. カレンダー・アドレス帳同期アプリ: 約16MB※
  3. メールアプリ(AquaMail): 約15MB
  4. 地図アプリ(いつもNAVI): 約12MB
  5. Google Playストア: 約7.7MB

サーバソフトの移行テスト中に、間違ってモバイルでカレンダー・アドレス帳をフルに同期してしまったので、特に多かったと思われる。

  •   0
  •   1

このブログでは、投稿後5年経過したものを自動で非表示にしている(以下、自動expire)。ただ、需要の点から一部の投稿(「MusicBeeの使い方」)は表示させたままにしたくなった。

今は自作のスクリプト(以下、expireスクリプト)で自動expireの処理をしているのだが、探すと自動expireするプラグインはいくつかあるから、それで手軽に実現できるなら乗り換えようと思った。が、どれも僕の要求をすべては満足できないことが分かった※。以下に要求と理由を示す。

  • 新規記事がデフォルトで自動expire対象になる。: 毎回設定するのは面倒だし、設定し忘れを防ぎたい。
  • (非表示になる日でなく)非表示までの期間(日数)が指定できる。: 日付を考えることなく、例えば「5年」という設定にしたい。
  • 自動expireした投稿にカテゴリやタグが付けられる。: 意図して非表示にしたものと、期限切れで非表示になったものを区別したい。
  • 可能なら、何もせずに既存の投稿が自動expire対象になる。: 最初に全部の既存の投稿に非表示までの期間を設定するのは手間(負荷が掛かる)なので。

※試したうちで一番要求に近かったプラグインは、Post ExpiratorとContent Schedulerだった。二つを合わせるといい感じなのだが。。。

それで、expireスクリプトを改良することにした。方法としては、自動expireさせたくない投稿にWordPressの管理画面で「印」(以下、保持マーク)を付けておき、expireスクリプトは、その保持マークがあるものは期限切れでも非表示にしないようにする(= 非表示対象にしない)のだ。

至ってシンプルで容易に実装できるのだが、すごく細かいところが気になった。どのような手段で保持マークを格納するかである。以下を検討した。

  • 「自動expireしない」というカテゴリを追加する。
  • 「自動expireしない」というタグを追加する。
  • 「自動expireしない」というカスタムフィールドと値を設定する。

カテゴリは一番使いやすいのだが、「自動expireしない」というのは属性なので、カテゴリ(投稿の分類・分野)にするにはふさわしくない気がした。実際には、非表示になっている投稿には期限切れになったことを示すカテゴリが付いているからそれと似たようなものなのだが、避けたい気がした(非表示になっている投稿の余計なカテゴリは、(その投稿自体が非表示なので、)外からは見えない点は異なる)。

タグもまあまあ使いやすいのだが、カテゴリ同様にふさわしくない気がする(ところで、タグとは何なんだろうか? 投稿のキーワード?)のと、投稿の下に表示されて今ひとつ美しくない(カテゴリも同様)。あと、一括して設定できるのに、一括して解除する方法がないのも不便だ(プラグインでもいいものがなかった)。

カスタムフィールドは、まさに属性を設定・格納する機能なので、「机上」では理想的で、投稿に見えないところもいいのだが、全然使いやすくない。プラグインを使わないと一括して設定・解除できないし、管理画面の投稿一覧に表示もできないし、検索もできない。投稿に見えないから、どうして残っているのかも分からない。

結構迷ったのだが、タグを使うことにした。投稿の下に表示される点は、見えることで残っている理由が分かるメリットはあるし、隠したくなった場合にはテーマを直せばどうにでもできるし、一括して解除できない点は、今のところ自動expireさせない投稿は少ないから、できなくても大きな問題ではない(もし多くなったら、スクリプトを作ればいい)と考えた。

なお、自動expireにしないタグは""と表示するようにした。これなら、一見意味不明(だけど、何となく重要そうなことが分かるw)で普通のタグ(文字列)とは区別できていいと思ったのだ(まあ、実際には僕はタグを使わないのだが)。本当は、(さまざまな案はあったものの、)金庫とか錠の絵文字が良かったのだが、(広く使える絵文字は)探しても見つからなかった。

自動expireにしないタグを付けた投稿の例

その機能を実装したので、明日テスト結果が出る。ちゃんと動いていたら、「MusicBeeの使い方」の各投稿にそのタグを付ければ、無事、「保全措置」が終わる。予定より随分前倒しだ(もっと先にすべきことはあるのだが、なかなか進まないw)。

(19:37 細かい修正・画像の追加)

 

PS. 余談だが、「MusicBeeの使い方」を電子書籍にすることも検討した。が、最新版のMusicBeeに対応していないことと(最新版はその次に対応しようかとも思った)、(自分の興味を除き、)電子書籍にすることにそれほど大きなメリットが感じられなかったのと、自分の仕事のプロモーションにするとしても、効果やその先が期待できなかったからである。もし効果があるのであれば、形態に関わらず既にあるはずだと思うのだ。

PS2. あとから気付いたのだが、「MusicBeeの使い方」だけならば、WordPressの「固定ページ」というものに変換すれば自動expireにはならない。ただ、ページのURLが変わってしまって見る方が不便だし(以前、国税庁が顰蹙をかっていた)、検索もリセットされてしまうので、そうしない方が良かっただろう。もちろん、従来のブログのURLからジャンプさせるようにもできるが、仕組みが複雑になって間違いが起こりやすいので得策ではない。 (2/4 6:53)

  •   0
  •   1

e-Taxは諦めたので、先日、国税庁のwebで去年の確定申告を書いた。一人だしそんなに多項目の収支もないから、すぐに終わった(毎年改良しているのか、webの使い勝手は結構良かった。Firefoxでもちゃんと使えた。そこは評価できる)。意外に、わずかながら還付になった(医療費はギリギリで控除対象額を超えたが、残念ながら、集計した手間に見合う価値(還付額)はなかった)。すぐに出してすっきりさせたいが、一応、漏れや誤りがないか数日間考えてから出そうと思った。ところが、待つうちに、段々、「こんなの、(「飾りだ」とは言わないが、正しかろうが間違っていようが)どうだっていいじゃん」みたいな、妙な気分になった。(更に、これを書くうちに腹すら立ってきたw)

(事前に思い付いたことをメモしていたので)いくら考えても漏れに気付くことはなさそうだし(例えば、「おや、こんなところに*十万円が!」なんてことはないのだ)、(正しいと思って打ち込んだうえに見直しもしたので)誤りだって見つかる訳がない。特に、誤りなんて、(得するように故意に操作しない限り、)指摘されなければ何も問題はない(そもそも、自分が気付かなかったのだから「誤り」な訳で、指摘されたら直せばいいことだ)。極端な話、桁と最初の数字が合っていればいい程度じゃないか。「厳密に徴税したいなら、お前らが自分で調べろ!」って気さえする(他には、例えば、「伝票類をまとめて放り込むだけで終わり」のように、作業を自動化してもっと楽に正確に申告できる仕組みを提供してくれればいいのだ)。そもそも、還付になったのだから出さなくたっていいくらいだが、決まりではあるし、要らぬ誤解を招いたらつまらないので、一応出す。

そんなことより、国の方がいい加減なことばかりしているではないか。賃金上昇(誰も信じちゃいないが)の根拠にしていたとかいう統計なんて、操作したのか本当に間違ったのかはどっちでもいいが、あれに比べれば、僕の誤りは(仮にあったとしても)本当に些細なことだ。全く何にも効かない。そもそも、納税したって碌なことに使われないではないか。消費税を上げても、どうせまともなことには使わないだろう。USに言われるままに高い武器を揃えたり、外国にばらまいてご機嫌を取ったり、役人だの議員は高給のうえに無駄遣いだの誤魔化しばかりしているではないか。税とは関係ないが、年金だってどうなるか分かったものじゃない。

昔、「納税は国民の義務」とか読んだ覚えがあるが、それであれば、まずは、役人だの議員だのがまともに仕事して欲しい!

という乗りでいい加減に申告したり誤魔化したりする人が増えたら、どうするのかねえ・・・ 全員を厳密に調べることはできないからねえ。一人一人は少額でも、積もると結構な影響が出るかも知れないね。そこを例のマイナンバーで取りっぱぐれないようにしようとしているのか。

今朝、還付金が振り込まれていた。去年(だったかな)と同様に、額の通知の葉書が届く前に銀行からの通知で知った。こういうところは笑える(苦笑)し、本当に遅れていると思うし、無駄そのものだと思う。なんでメールとかで通知するようにできないのかね。葉書のお金だってもったいないと思う。 (2/28 11:43)

  •   1
  •   0

e-Taxが、ICカードなし(ID・パスワード)でできるようになったというので、印刷して送る手間やお金が省けるのはありがたいから、そのID・パスワードをもらいにわざわざ税務署に行った。行かないともらえないってのがどうにも情けないが、仕方ないと思った。まだ確定申告の時期ではないし、月曜ではないから混んでないと思った。

のは間違いだったw 行ったら、税務署の手前からなぜか渋滞していて、ほとんどの車はその列を追い越して行っていた。僕もそうしたら、それは税務署の駐車場待ちの列だった。。。 11時前に着いたのだが、既に遅かったようだ。仕方ないので今日は諦めて、実家のある市まで40kmくらい、軽くドライブして来た。相変わらず、どこをどう走っているのか全く分からなかったが、車が快調でとても気持ち良かった。

ただ、次回、徒歩(遠いから結構辛い)やバス(直通便なんてない)などで行ったり、近くの別の駐車場に停めても、中も混んでいて待たされると思うので、行くだけ無駄だと思い、今年は諦めることにした。

あと、ドライブしながら、この手続きは他の管轄でもできるのか知りたかったが、まあ、どこでも混むのは一緒だろうから、調べて行くだけ無駄な気がした。かなりの田舎(村?)なら大丈夫だろうか? ただ、それにしたってガソリン代などが掛かる(それに、署員が少ないうえに、田舎だと話が面倒で時間が掛かる人が多そうだ)から、余り得策ではなさそうだ。 ← 調べたら、県内に税務署は8箇所しかないから、「かなりの田舎」にはないし、どこでも混んでそうだ。

大体、ID・パスワードをもらいに行かなくちゃいけない時点で終わってる。そんなの"e-"Taxじゃないよ。署の人も余計な仕事が増えて迷惑だろう。ネットで完結させろとは言わないから、郵便とか市役所とかでもできるようにすればいいのに。こっちは納税するつもりがあるから手続きしようとしているのに、門前払いではやる気が失せる。

内情を推察するに、お偉いさんは簡単にそうする・しろとは言ったけど、年内に本人確認とかID発行の仕組み(システムや処理の流れ。郵送だと「センター」を構築する必要がありそうだし、市役所に頼むなんてネゴできる訳がないw)を新たに作るのは時間もお金も無理なので、仕方なく人海戦術にした気がする(それなら、e-Taxのシステムとしては、ログイン経路を増やせばとりあえずはできそうだ)。まったく、「マイナンバーはどこに行ったの??」って話だ。みんな可哀想に・・・

それにしても残念だ。マイナンバーカードにはパスワードが入っているのだから、それで本人確認とかログインは充分できると思うのだが(パスワードはカードにしか入ってないのだろうか?)。日本を代表するお利口なIT企業の面々が作ったシステムは、そんなことすらできないようになっているのだろうか? 「ICカードの認証機能(とかカードに記録されたIDだかなんだか)を使わないと駄目だ!」とか言い張る頭の硬い連中が居るのかも知れないな。

  •   1
  •   0

先日のカレンダー・住所録サーバの移行先を探している時だったか、POLARというドキュメント管理ソフトが出て来て、その時は目的とは関係ないから無視したのだが、その後、自分のファイルを整理している時に、ディレクトリ名じゃなくてタグ(カテゴリ)などで分類できて、ファイルにコメントが付けられて、ディレクトリ名やファイル名だけじゃなくてタグやコメントで検索できたら便利かも知れないなと思った。

それで今日、検索してみたら、いくつかのソフトが見付かったのだが、どれもイマイチだった。なぜか、大規模指向(「エンタープライズ」)の物がほとんどで、その上、まともに動かない物が多かった。POLARは機能が少ないうえに、バグなのか、コメントが入力できなかった。JAVAを使っているもの(Openkm, LogicalDOC)は、純正(Oracle)のJDKでないと動かないからOpen JDKをアンインストールしろなんてアホみたいなことが書いてあって、そのせいかどうか分からないが、動かなかった。Open JDKをアンインストールするとひどい目に遭うのでしないから、基本的には使えない。時間を掛けて調べれば動くのかも知れないが、そんな気は起こらなかった。

他には、容易に動きはしたがプログラムを暗号化するプロテクトを掛けているセコいもの(FileRun)もあった。こういうのは、ある時突然有料になったり使えなくなったりするから、最初から却下だ。他には、無料版ではコメントが書けないものも(TagSpaces)あって、それではドキュメント管理の機能としては不十分で、使いたいと思う人は少なそうだから、余り販促にならない気がする(ロゴが妙に古臭いのも、そういう頭の固さを表しているのかも知れない)。

あとは、先日移行したカレンダー・住所録サーバの機能でもある程度のドキュメント管理ができる(それが本来の機能のようだ)ことに気付いて試したのだが、イマイチで使う気になれなかった。そもそも、そういう用途のソフトなのに、それが使いにくかったら立つ瀬がないのだが、僕はそれは使ってないからまあいいw

結局、使えるものは何もなかった。が、良く考えたら、本気で使うなら、ただ「ドキュメント管理ソフト」という名前の物を導入するだけでは駄目で、さまざまなファイル(例: Word, Excel, PDF, 画像, 音楽)に対応した、全文インデックス(正確には、インデックス型の全文検索)機能などがないと駄目なことに気付いた。ファイル名やコメントやタグだけでなくて、ファイルの中に含まれる文字列でも検索したいではないか。そういうことを考えると、まずは、仕様をちゃんと調べるべきだった。

それから、そもそも僕の個人のPCにはそんなに大量のドキュメントがある訳ではないから、使う意味がないのではないかと思った。確かに、目当てのファイルがなかなか見つからないことはあるが、探すこと自体が少ないし、チームではないので、自分の記憶やメモを探せば出て来ることが多いし、いざとなったら検索するスクリプトを作ることだってできるから、ドキュメント管理を効率化しても余り意味がなさそうなことに気付いた(逆に、通常時に各ファイルにタグやコメントを付けるのが面倒な気すらした)。という訳で、ドキュメント管理ソフトの導入は保留にした。

こういうことは、会社では良くあることで、偉い人がニュースとか「日経」などで見た流行りの技術を、部下に「*いいんじゃない。うちでも使ってみたらどうだ」とか言い出して、その部下や担当部門(例: 情シス)が慌てて探して入れるのだが、誰もそれがいいかどうか、その会社に合っているのか分からない。そもそも、本当にそれが必要なのかすら不明だ(多くは不要だろうw)。

結局、社員は「意味は分からないが、使わないと怒られるから使わされる」羽目になって、また一つ余計な仕事とストレスが増えるパターンだ。まあ、そうでないこともあるが、2/3はこうじゃないか。あとは、機能自体はまともでも、充分に試さずに決めたために、操作がとても面倒で、結局は効率化できないとか効率を落としてしまうパターンも多い(残り1/3のほとんどはそうじゃないか?)。

PS. かといって、世の中の新しいいいものに全く無頓着で、時代遅れなことをしていても平気な顔をしている(あるいは、時代遅れであることに気付かない)人は、救いようがない。

PS2. 寝ている間に(起きたら?)、広範なファイル形式について全文インデックスできると、タグとかコメントを付けなくても検索できるから、結構便利そうだなあと思ってしまった。更に、インクリメンタルサーチがあれば最高だ。エンタープライズ用だとできる気もする。が、有料になるのかも知れない。気が向いたら調べてみるかな。この時に問題になるのが、日本語対応だ。無償でまともに使えるものがあるかどうか・・・ (1/29 6:47)

  •   0
  •   0

さっき(16時頃)までは、「誕生日だからといって、別に何もすることもないよ」と思っていた(し、今は「展覧会の絵」(オリジナル版)の聴きたい演奏が溜まっているから、そっちを聴かなきゃと思っていた)のだが、やっぱり、彼のピアノ協奏曲が聴きたくなった。そうとなれば、ポリーニとベームのK. 488が最高(大好き)なのだが、もちろんそんな安直な道には走らずw、新しい演奏を求めてSpotifyを探した。

最初は(短調の曲が好きなのと、好きなピアノ協奏曲の最初なので、)第20番にした。詳しい途中経過は省くが、7人目(約25分後)にようやく聴き続けられる人に当たった。それまでは以下のような人たちのを試した。全部の演奏が気に入らなかった訳ではなく、フォルテピアノ(古楽器による演奏)は好きでないし、抜粋の演奏も避けたので多くなってしまった。

Malcolm Bilson (1999)、Christian Zacharias (1989)、Edwin Fischer (?)、Hai-Kyung Suh (2016)、Branka Musulin (2018)、John Gibbons (1987)

今、Lars Vogtの(2009)の第3楽章を聴いている。彼だって満足できる訳ではないが、悪くはない。ちなみに、彼の演奏は、2年前にゴルトベルクを、去年K. 488を試したことがある。

聴くと、楽章によって印象が変わって妙だ。

冒頭のオケはちょっと抑揚を付け過ぎな感じだったが、それ以外は、第2楽章までは薄味な感じだった(ただ、止めるほど嫌な感じではなく、音量を上げた程度だ)。ピアノも綺麗ではあるが、(彼の怖い顔には似合わず)音が細目だった。それが第3楽章になると、一気に味付けが濃くなった感じで、打楽器はちょっと大げさな感じだった(これは冒頭と同様のことか)。全体的には、音が良く、重厚さもあって良かったと思う。

最後に分かったのだが、これはライブだった。だから、演奏時の乗りとか演奏者の「温度」のようなもので微妙に印象が変わったのかも知れない。実際、僕が聴いたコンサートの多くは、序盤は余り乗りが良くなかった。

さて、これから、彼の同じアルバムのK. 488(第23番)を聴く。

これは結構いい。多分、以前の印象よりいいと思う。

冒頭のオケは綺麗で良かったし、第2楽章はオケもピアノもしっとりとしていて良かった。第1楽章のピアノは、悪くないが、わずかに滑らかでない感じがした(これは第3楽章でも少し感じるので、彼の弾き方なのかも知れない)のが惜しかった。今は第3楽章の前半だが、このまま問題なく行きそうだ。

ライブらしく、最後の最後にちょっと力んでしまった感じだが、全体的には乗れて良かった。

***

そして、やっぱり今日の締めはポリーニのK. 488 (1976)だ。どうしてか、彼の演奏を聴くとすごく落ち着くし、ほぼすべての音が「すっ」と入って来るから、安心して聴ける。僕にはこの曲は彼のでないといけない感じだ。確か、この曲を最初に聴いたのは彼のだったから、いわゆる「刷り込み」なのか、彼とベームがこの曲の良さを最大限に引き出しているのかは分からないが、僕には彼の演奏を超えるものがまだない。ただ、それでは(音楽の進歩とか発展がないことになって、)僕としては納得行かない(し、自分で自分が最高と思える演奏ができる訳もない)ので、いつもポリーニ以上の演奏を探しているのだ。

 

PS. ポリーニの前に試した、溜まっていた「展覧会の絵」(Dumont, Gavrylyuk, De Pledge, Economou)もVogtのゴルトベルクも全滅だった。我ながら厳しい。。。

  •   0
  •   0

先日、画像管理アプリをXnViewMPに変えた。digiKam5(以下、digiKam)は重い(起動が遅いことがある、メモリを食う(メモリリーク)、いろいろな処理(特にDB関係)が重い)のと、UIの使い勝手が微妙にイライラするうえに変更できないからだ。移行先のXnViewMPは、以前試した時に比べて大分良くなったので、移行しても問題ないと考えた。とはいえ、いくつか問題があったので対処したら(→ 投稿1, 投稿2)かなり良くなったのだが、digiKamとコメント・カテゴリの格納場所(タグ)に違いがあってちょっと不便なので、その対応をした。なかなか手間が掛かったので書く。

そもそもの問題は、digiKamとXnViewMPがコメントとカテゴリを格納・取得するタグが違うため、digiKamで付けたコメントやカテゴリがそのままではXnViewMPでは表示・書き込みできないことだ。それらの違いを以下に示す。なお、digiKamのタグは、それ以前にWindowsで使っていたACDSeeが使用する(ACDSeeで設定したか、digiKamに移行する時に設定したか)タグも含んでいる可能性が高い。

コメントのタグ

  • digiKam: UserComment, Notes, Caption-Abstract, Descriptionの全部またはいずれか
  • XnViewMP: Comment, Description(補助?)

カテゴリのタグ

  • digiKam: Keywords, Subject, Categories(階層化して格納)の全部またはいずれか
  • XnViewMP: Keywords, HierarchicalSubject(階層化して格納)

コメントについては、XnViewMPではIPTC/XMPの編集機能を使えばdigiKamと同様に書き込むことができるが、標準的な扱い(例: サムネイルの下に表示する、コメントの編集で表示・編集する)ができないので不便だ。カテゴリも、カテゴリを付けるペーンでは表示されるのだが、標準的な扱い(例: サムネイルの下に表示する)ができないので不便だ。おそらく、将来のXnViewMPではできるようになると期待する(が、いつになるかは分からない)。

digiKamは結構柔軟に使用するタグを設定できるのだが、XnViewMPはそうではないので、標準的な扱いをしようとしたら、XnViewMPが使うタグに値を入れる必要がある。そこで、digiKamのコメント・カテゴリをXnViewMPにコピーすることにした。まず、XnViewMPの機能でやろうとしたのだが、変更ができないタグが多くて無理だった。今にして思えばdigiKamでやればできたかも知れないが、そうはしなかった。というのは、既にXnViewMPに乗り換えた後だったので、「もう使いたくない」という気持ちが大きかったからだと思う(digiKamが重いのが大きな理由だ)。それに、以下に書くように、単純なコピーでは済まなかったので、digiKamでやったら手作業で間違いが多くなっただろうし、対象の画像の数が多くてかなりの時間が掛かっただろうから、使わなくて正解だったと思う。

作業の前にいろいろな画像のコメントを調べたら、digiKamの前に使っていたACDSeeのせいなのか、UserComment, Notes, Caption-Abstract, Descriptionの全部に入っている訳ではなく、どれか3つ(確か前の3者)とか1つだけ(Description)の場合があった(おそらく、DescriptionはACDSeeが付けたのではないか)。更に、元々のコメントに気付かずに(コメントがないと思って)XnViewMPでコメントを付けてしまった画像が数十枚あり、そういう画像は2つの異なるコメントが付いている状態になっていた(この移行作業をしようと思った大きな切っ掛けだ)。

そこで、以下のような処理をした(試行錯誤したので、最初から一気に分かった・した訳ではない)。

コメントの移行処理

  1. 画像にCommentがなかったら、
    • それにUserComment, Notes, Caption-Abstract, Descriptionのいずれか(digiKamのコメント)が付いていたら、最初に見付かったものをCommentにコピーする。
  2. 画像にComment(XnViewMPで付けたコメント)とdigiKamのコメントが両方付いていて、双方が異なっていたら、
    • 後者(digiKam)の後にセパレータを挟んで前者(XnViewMP)を追加(digiKamのコメントを先に付けたため)したものをCommentにする。
    • 以下に処理の例を示す(時間的順序とは逆だが、その画像の元々のCommentタグはXnViewMPのものだったので、そのようなセパレータにした)。
      • digiKamのコメント
      • --- Orig. Comment ---
      • XnViewMPのコメント

カテゴリの移行処理

  1. 画像にKeywordsがなかったら、
    • Subjectが付いていたら、Keywordsにコピーする。

カテゴリは、上記の処理以外にCategoriesに従ってHierarchicalSubjectを設定しないと完全ではないのだが、書式の変換が要るから間違う可能性があるのと、数が多い(約1.5万個)ため諦めた(数が多くても時間を掛ければ処理できるが、クラウドバックアップの変更データ量が数十GBにも及ぶため、バックアップ時間が長くなるのとしばらく料金が増えるのが嫌だった。とは言え、1か月50セント未満でしかないが)。HierarchicalSubjectを設定しなくても、カテゴリ設定ペーンやマウスオーバーでは表示できるので、(画像の下に表示するのは諦めて、)それで代替することにした。

マウスオーバーでは表示できるけど画像の下に出せないのは、単純にXnViewMPの未実装な点なので、将来はできるようになりそうな気がする。

書いたあとで、ちょっと確認しようとしてexiftoolでCategoriesを出したら、"(none)"になってしまった。いろいろ試したら、exiftoolのオプションとして、普通に"-Categories"でなく、"-XMP:Categories"や"-All:Categories"のようにグループを指定しないと駄目なようだ。理由は不明だが、仮に階層化カテゴリのコピーもやったら、多くが"(none)"になって、とんでもない処理をするところだった。危ない危ない。。。

タグの操作には主にexiftoolを使った。基本的な処理はexiftool単体(コマンド1行)でできた(ただ、上述のように処理が複雑なためにコマンド文字列がかなり長くなったので、スクリプト中で一時的なスクリプトを作り、それでexiftoolを実行するようにした)※。なお、exiftoolはsymblic linkの実体(リンク先)を処理せず、通常のファイルに変更してしまうため、あらかじめ除外した(多くの場合には、-overwrite_original_in_placeを指定すれば問題ないと思う)。

※exiftoolの機能の豊富さには驚くし便利だとは思うが、進む方向がなんか違うと思う。

処理後に、exiftoolを使う別のスクリプトで、全画像に対して移行処理ができているかの確認をした。こちらは、上記処理に不足や問題がないかの確認もしたかったので、exiftoolでタグの値を取り出して判定する別のスクリプトで行った。

※今回作ったスクリプトやexiftoolのコマンド文字列は有用ではあるが、機能が特殊なうえに、そもそもユーザー(使いたいであろう人)がほとんど居なさそうなので、例によって公開はしない。要る方がいらっしゃいましたら、お知らせ下さい。

 

PS. それにしても、なぜ同じ意味を格納するタグがこんなにあるのかと思う。ACDSeeも合わせて調べたら、以下のよう仕様になっているようだ。

コメント

  • ACDSee: Description ← digiKamへの移行時にexiftoolで書き込んだ。
  • digiKam: UserComment, Notes, Caption-Abstract, Description, ImageDescription(文字化け): ImageDescription以外は、どれかあれば使われるようだ。
  • XnViewMP: Comment, Description: Comment以外は表示できない局面がある。

カテゴリ

  • ACDSee: Categories(階層化) ← digiKamへの移行時にexiftoolで書き込んだ。
  • digiKam: Keywords, Subject, TagsList, Categories(階層化), CatalogSets(階層化)など: どれかあれば使われるようだ。
  • XnViewMP: Keywords, Subject, HierarchicalSubject(階層化): Keywords以外は表示できない局面があり、HierarchicalSubjectがないと階層が保存されない。

ACDSeeは「マイルール」でやっており(実際にはexiftoolで書き込んだのでタグは関係ないが、exiftoolを使わなくてはいけないほど、汎用性がなかった)、digiKamは節操がない感じ(設定可能なので、実際には互換性を広げるための機能だ)で、XnViewMPはちょっとズレているうえに一貫性や柔軟性がない。こういうのは不便なので、アプリごとにタグをバラバラにせずに統一して欲しい。

まあ、それでも、EXIFでタグの記録フォーマットが統一されているので、exiftoolのようなツールを使えばいくらでも変換できるから助かる。これがもし、独自フォーマットのDBだったら、どうにもならない(コメントなどを移行できない → 打ち込み直し?)事態に陥ることになる。実際、ACDSeeは基本はDBだが、各ファイルのタグに書き込むことも可能で(これがあって助かった)、digiKamに移る時に全部に書き込んだ覚えがある。 ← すっかり忘れていたが、実際にはexiftoolで書き込んでいた

  •   0
  •   0