Archive for the ‘日記’ Category

このブログでは、投稿後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に言われるままに高い武器を揃えたり、外国にばらまいてご機嫌を取ったり、役人だの議員は高給のうえに無駄遣いだの誤魔化しばかりしているではないか。税とは関係ないが、年金だってどうなるか分かったものじゃない。

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

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

  •   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

昨夜、母と食事をしながら話をしていて驚かされたことがある。実家の辺りは(中途半端な)田舎なのだが、母の友人(2-3人)とその家族の関係が予想以上に希薄、あるいは、異常なのだ。

例えば、母の友人の家の奥さんは、外出する時に姑(母の友人)に何も言わずに出て行くそうだ。本当に何も言わないので、気付くと居らず、どこに行ったのかも分からないそうだ。逆に、その姑は体調が悪くても友人(僕の母など)には相談するが、なぜか家族(息子や奥さん)には余り言わず、なるべく頼ろうとしないようだ。それで、仲間の中で唯一車を運転できる母が病院に乗せて行くとのこと。

車の件は、母は病院以外でもいつもみんなを乗せているので、お人良し過ぎて馬鹿みたいだし、タクシー代わりに使う方もおかしいと思うが、僕がおかしいと言っても母は例によって「そうだね」で終わるので、どうしようもない。そして、昨夜乗せてもらったら結構運転が危なっかしかった(よく煽られないものだと思った。高齢者マークを付けているおかげかも知れない)ので、新たな不安材料だ。

この話を聞いて、僕の実家も似たようなものだったことを思い出した。家では祖父と父が顔を合わせるたびに喧嘩しており、それだから、双方が何かするにしてもまともな相談などすることなどなく(相談どころか、普通の会話なんてなかった)、挨拶だってしていなかったし、食事だって祖父母とこっちは別々にしていた。さすがに、怪我とか病気の時は、母などが病院に連れて行っていたから、そこだけはマシだったようだ。そんなことなら実家に戻って来なければ良かったのにと思うが、昔の慣習にならったのか、戻って来てしまったようだ。

同じ家に住んでいながら、いい歳した大人がごく当たり前の連絡もせず、調子が悪くても言わないというのは信じ難いことだ。それで家族と言えるのか? 一緒に住む意味があるのか? 母の周りの数人(一人ではない)のことだから一般化はできないけれど、田舎の普通の家庭は街より親密な関係なのだろうと思っていたが、必ずしもそうではないのかも知れない。なぜそうなるのだろうか。

今想像したのは、相手(しかも、姑などは親ではない他人だ)との距離が近過ぎるために、お互いに嫌になっているのではないかということだ。田舎なので、外に出ることが少なく、家に居れば、姑と奥さんはいつも顔を合わせざるを得ず、好き勝手なこともできないから、イライラしたり顔を見るのもうんざりだという気分になるのかも知れない。そして、これも想像でしかないが、こういうところは、街の方がまだましな気がする(そもそも、一緒に暮らしている家が少ないという話はあるが、割合では言えそうだ)。

街の人だって、確かにうんざりはしているだろうが、少なくとも、出掛けるとか帰ったとかの当たり前の連絡はするだろうし、調子が悪かったらまずは家族に言うだろう。田舎の人が当たり前のことをしない原因は、田舎にばかり居た・居る人は、街の人より交際の範囲が狭かったり外部と接する機会が少ないから、社会的な常識が不足してしまうのではないかと想像する。

自分のことを思い出すと、確かにそうだ。僕が子どもの頃の交際範囲はすごく狭かったので、大学に行ったり勤めてから、たびたび世の中の常識が違うのに驚き苦しんだのを思い出した。今にして思えば、確かに自分に常識がなかった(要は、田舎者だったってことだ)。恥ずかしいくらいだ。けれど、当時はそれすら分からず、自分が普通だと思い、さまざまな問題がなぜ起こるのか分からなかった。。。

おもしろいのは、当時だってTVやラジオで都会の情報は入って来たけれど、それでは全然足りなかったことだ。なぜそうなのかは分からないが、そういうのは別の世界と思い込んでいたのか、社会常識に繋がる、人対人の関係は、TVなどからは伝わって来ないということなのではないか。だから、現代の田舎の人も、数十年前の僕と同じことなのかも知れない。まあ、聞いてみないと分からないが。もちろん、何のメリットもないから聞く気なんてないがw

(最後はちょっと飛躍するが、)だから、田舎は決して「いい人ばっかり」とか「暖かい」なんてことはなく、住みやすいところでもない(でも、のどかなのは確かだ)。あこがれとか想像で移住すると大変なことになる。これは昨夜のことだけで導いた訳ではなく、僕が実際に(すごく貴重な)小中高の12年前後暮らして実感したことだ。その結果、僕は逃亡した。近年、血迷って戻ったが、やっぱり逃亡して今に至る。

僕の経験から言えば、都会に疲れたなら、真の田舎じゃなくて、地方都市がいいと思う。

  •   1
  •   0

以前からやっている、PHPを最新版に更新する件。デスクトップPCは問題なくできたのだが、サーバが結構面倒なことになった。

PHP自体は、PPAを使えば比較的容易に更新できるのだが、PHPを使っているソフトの互換性も確認する必要がある。それで、仕様などを調べて、大体は問題なさそうだったのだが、一つ、カレンダーや住所録の共有・同期に使っているサーバソフトBが怪しいことが分かった。検索すると、少し前のPHPのバージョンからいろいろな問題が出ていたようだし、そもそも開発が終わってしまっていて、ずっと更新されていなかった。それでも使い続けたい人がパッチを出しては居るのだが、さすがにもう「騙し騙し」でも使えない、誤魔化しが効かない状態になった。

仕方ないので、別のサーバソフトを調べていくつか試したのだが、なかなかいいものがなかった。以前使っていたOなら実績があるのだが、どうも下火なようだし、その分家(クーデター版?)Nはあるが、O同様にインストールや保守がちょっと面倒そうなので、もうちょっと楽なのを探したのだが、やっぱりない感じだ。インストールがやけに面倒だったり、インストールしてもうまく動かなかったりするものばかりだった。

仕方ないのでNを使うことにした。やっぱりいろいろ面倒だったが(この中で、前に書いたSnapの問題が発覚した)、デスクトップPCでうまく動くようになったので、今朝からサーバに入れて実際に使って試している。ところが、スマフォ(Android)側同期アプリCとの相性が今ひとつで、スケジュールがうまく同期できないことが多い。確かにそのアプリは、以前から最初はうまく同期できないのだが、時間が経つとなぜかできるようになっていた。これももう駄目と考えて、別のを探すことにした。

同期アプリもなかなかいいものがなく、以前試して止めたソフトの後継のDしかまともに動かなかった。これは同期はちゃんとできるからいいのだが、なぜか、スマフォのアラームを停めても1分後に再度出ることがあるのが嫌だ。どうも、PC側でもアラームを停める場合、停める順序やタイミングが関係しているようだ。気に入らないのだが、ないものは仕方ないので我慢することにした。

影響の連鎖

サーバ [PHP → カレンダー・住所録サーバ*] → スマフォ [カレンダー・住所録同期アプリ*]

※PHPの更新のために、*を取っ替え引っ替えする羽目に。

ただ、どうにも諦められないので、また元のCを試したい気もしている。理由は分からないが、気長に一晩くらい置くといいのかも知れない。

(1/25 6:24) なんとか、アプリCで同期出来るようになった感じだ。どうも、最初は予定(データ)の量が多くて全部同期できていなかったようなので(バッファサイズに制限があるのか、1回の転送量や処理量を制限しているのかと推測した)、1度に同期する期間を短くし(例: 過去は1週間、先は4週間)、短い間隔(10分など)で同期するようにして30分くらい待ったら、遠い過去・将来はいざ知らず、直近の予定は全部同期できた(その後、設定を普通に戻した)。これで様子を見てみたい。

 

最後にちょっと意見を書くと、世の中に良くある、古いソフトが更新・刷新できないというのは、こういう風に、そのソフトが使っているソフト(多くはプログラミング言語、あるいはOS)のバージョン間の互換性のなさが原因になっていることが多い。ソフトを作った人が居なくなり、仕様書・設計書などがなかったりすると、動くかどうかも、どう確認すればいいかも、どうやって直していいかも分からない。もちろん、お金(作業時間)だってない。

だから、「動いているからそのままにしよう」という気持ちは分かるが、重要な用途で、サポートが終わったものを使い続けるのは無責任だ。例えば、過去のバージョンに不具合があって、それが原因で間違った結果になることがあるからだ(でも、その不具合も含めて仕様として作っている場合もあるので、話は単純ではない)。一方、作る方にも責任はあって、バージョンを上げる時に、従来のプログラムが可能な限りそのまま使える(動く)ようにするべきなのだ。

個人的な印象だが、PHPは随分いい方だが、Pythonのように、2つのバージョン(2.*と3.*)がずっと混在して使われている(Ubuntuですらそうだ)のは、(僕は何が違うかは知らないが)余りにも醜悪だと思う。実際、Pythonのプログラムで、「これは(2と3の)どっちで動かすのか?」と疑問に思うけど分からないので、両方試さざるを得ないことが結構ある(両方とも別の原因で動かないことも多い)。そして、Ubuntuのように重要なところでPythonを使っている場合は、片方を削除するとシステムがまともに動かなくなってしまうことすらある。時間もストレージも無駄だ。まったく、「何考えて作ったの?」と言いたい。まあ、「使う方はちゃんと更新しろよ。こっちはお前らのために良くしてるんだからさあ」って論理だろうが、使う方は作る側と違って、その言語を使うこと自体が仕事ではないので、それは全然通らない。

 

※個人情報を扱うサーバに関することで、興味本意で攻撃される可能性を減らしたいので、具体的なプロトコルやソフトの名前などは記載していません。読んでも余り役に立たないかも知れませんが、僕のメモとか、問題の原因の推測・対処の例としたいと思います。

  •   0
  •   0

あるソフトをインストールしようとして調べたら、通常の手順でするもの以外にSnap版(必要なものが全部まとまっているパッケージ)もあった。そのソフトはいくつかの別なソフトを使うため、インストールと設定がなかなか面倒なので、Snapなら全部一括してインストールできて、ほとんど設定しなくて済むうえに更新も自動でされて便利なので、試してみたのだが、最終的には止めた。Snapのセンスの悪さ・将来性のなさを実感したからだ。

まず、Snap版アプリをいくつか使っている際の、Snapのものだけを抽出したマウント(OSへのファイルシステムの登録)状態を見て欲しい。

$ df | grep snap | sort
/dev/loop0 91648 91648 0 100% /snap/core/6034
/dev/loop1 91648 91648 0 100% /snap/core/6130
/dev/loop2 90368 90368 0 100% /snap/core/5897
/dev/loop3 177536 177536 0 100% /snap/spotify/26
/dev/loop4 177792 177792 0 100% /snap/spotify/28
/dev/loop5 55040 55040 0 100% /snap/core18/536
/dev/loop6 35456 35456 0 100% /snap/gtk-common-themes/818
/dev/loop7 173568 173568 0 100% /snap/gimp/94
/dev/loop8 178688 178688 0 100% /snap/spotify/30
/dev/loop9 173568 173568 0 100% /snap/gimp/101

Snapは、基本部分とアプリごとにそのパッケージのファイルを仮想的なファイルシステムとしてマウントするようなのだが、アプリをたった2つ(Spotifyとgimp)しか入れてないのに、10個もマウントされている。。。それぞれのソフトが更新されるたびに、これらは増えるようだ(ディレクトリの最後の数字が増えるようだ)。普通はアプリなんて山ほど入れるが、それが全部Snapになって、それぞれが何度も更新されたら、一体どうなるのだろうか。OSは問題なく動くだろうけど、人が見た時に状態が把握できなくなってしまうだろう。Snapのマウントポイントだけならいいけど、他のものが埋もれてしまって不便になるだろう(上とは反対に、Snapのものを除外して表示すればいいが、今まではいらなかったのに毎回指定すのは手間だ)。どうして、Snapのマウントポイントは1個だけ見えるように(あるいは見えないように)しようとしなかったのだろうか?

見た目だけならまだいいが、もっと深刻なのは、それぞれのSnapパッケージは、各々のアプリが自分に必要なモジュールを全部入れていることだ。仮にアプリ間で同じモジュールがあっても共有しないようなので(共有することにすると、依存性が生まれてSnapの目指すところに反するだろう)、同じライブラリが何個も格納され、同じソフト(例: HTTPサーバ, PHP)が複数動く事態になる*。そうすると、ディスクやメモリの使用量が無駄に増えるし※(Windowsと似たような事態ではないか)、CPUの負荷だって無駄に上がるだろう。

* 日常生活に例えれば、お米だけが欲しいのに、なぜか、専用の炊飯器や米びつまで一緒に買わされるようなものだ。当然、そんなの持っているのに、「持ってないかも・合わないかも知れないから」とか言って手持ちのを使わせてくれないのだ。

※ディスク使用量については、上の一覧(3列目がサイズ(KB))を見ても分かるように、各アプリの量は少なくない。Spotifyもgimpも170MBくらいのがバージョンごとに複数あるようだ(普通のパッケージなら共通のモジュールは共有されるから、全体としてはそんなに大きくならないはずだ)。いくらストレージが大きく安くなったとはいえ、アプリを入れるたび・更新のたびに浪費するなんて止めて欲しい。そして、ディスクを多く使うってことは、使用メモリだって増えるのだ。論外もいいところだ。

更に、重複したモジュールはバージョンや設定が少しずつ違うだろうから、間違いなく悪夢を生み出すだろう。確かに、手っ取り早く使い始められて楽なのだが、使っているうちに、同じモジュールを使っているはずのアプリの動作が微妙に違っていて(例えば、Snapと同様の目的のシステムのAppImage版アプリの日本語入力はそういうことがある)、困って検索して調整する羽目になるのだ。そうでなくても、何かあって設定を調整するにしても、普通の場所にはないから、いちいち調べるのが面倒だ。その設定ファイルも、同じ名前のモジュールであっても、それを含むアプリごとに別だから、それぞれを調整する羽目になって、面倒臭いとしか言いようがない。。。 要は、Linuxの良さをぶち壊しにして、Windowsへの道を進んでいるのだが、それでいいのか??

先のことを考えず無駄ばかりの(「腐った」)システムなんて、全く許容できない。だから、通常のパッケージがあるなら、多少面倒でもなるべくSnap版は使わないことにした。

それにしても、そもそも、Linuxに派生が多過ぎるからSnapのような「全部入り」パッケージができたのだが、それすらAppImageとかFlatpakなどのような別物ができてしまっていて、まとまりのなさには全くがっかりだ。本来、OSの派生を減らせばこんな無駄なものは要らないのに、なぜ、そこに目をつぶるのだろうか。

Linuxにもクソなところはある(でも、クソなのは物じゃなくて人だ※)。

※クソなのは人だけど、クソな考えややり方で作られた物は、やっぱりクソになってしまう。結果は作者の属性には無関係と思うが、当然ながら、作者の考えには大きく影響される。

  •   0
  •   0

迷惑メールが来た時、なぜか、"unsolicited"という単語が頭に浮かぶ。これの読み方すら分からないのだがw 大昔、ネットニュースか何かで目にしたのが記憶に残っているのだろう。

近頃、それにぴったりの、まさにunsolicitedなクソメールが来たので、紹介したい。これは何というか、海外からのお馬鹿メールと違って本当にunsolicitedで頭に来たので、書くことにした。

先週、eleven-tenthsの飯塚とかいう奴(どうせロボットだろう)から、「アーティクル記事の掲載について - スポンサーシップのお願い - blog.piulento.net」という題のメールが来た。もう、この題だけで大笑いなので、放置した。だって、「アーティクル記事」って何ですか? こいつは自分で使っている「article」の意味も分からないのか? 全部日本語にしたら、「記事記事」だぜ。そんな能なしにどんなに金を積まれたって、クソ提灯記事を載せるのはまっぴらだ! そもそも、ここに広告だの他人の記事を載せるつもりは全くない。まず、そういうことを確認してから出せ。

放置して忘れていたら、昨日、そのアホがのこのことまた出して来た。「確認メール アーティクル記事の掲載について - blog.piulento.net」(最初の空白は全角)だと。勝手に出して来たメールへの返事を催促するとは、これぞまさにunsolicited mailだ。ムカつく。

こんにちは。

大変お世話になっております。
お忙しいところ恐れ入りますが、blog.piulento.netさまのウェブサイト上に記事を掲載させて頂く私からの提案を考慮されて頂いておりますでしょうか?
blog.piulento.netさまにご協力頂けると大変光栄に存じます。

何卒よろしくお願い申し上げます。

飯塚

飯塚の世話なんてしてないよ! お前の提案なんて誰が考慮するか。アホ。少しでも脳味噌があったら、返事のない意味を理解しろって感じだ(まあ、これもロボットなんだろう)。

それだけでなく、鬱陶しいので、これに書いてあったメール不要の返信("UNSUBSCRIBE")を出したら(やっぱり、出したのは馬鹿だった)、今日、株式会社もしもの松本 法子(空白は全角w これもロボットだろうから、そのまま載せる)とかいうのから「報酬アップAmazon Music Unlimited 500円→1200円、広告掲載のご相談」というのが来た。以下、見せしめのため、全文掲載する(ただし、真に受けて登録する被害者を生まないように、登録用URLは削除した)。

突然のご連絡恐れ入ります。
もしもアフィリエイトの松本法子と申します。

弊社はもしもアフィリエイトというASPを運営しております。
今回、【Amazon Music Unlimited】の報酬アップキャンペーンのお知らせをさせて頂きたく、連絡致しました。

【通常報酬の500円が1200円】に報酬アップしております。
期間は2019年5月8日までです。

Amazon Music Unlimitedは、4000万曲以上が効き放題の音楽サービスです。
Prime会員なら月額780円と、競合他社は900円代が多い為他社と比べても紹介しやすいと思います。

詳細は以下をご覧ください。(ログイン後ページ)
(URLは削除)

もしもアフィリエイトの登録は以下URLからできます。
(URLは削除)

また、弊社は振り込み手数料無料、報酬も弊社から10%上乗せしてお支払いしています。
(報酬が10000円の場合、11000円のお振込みになります。)

是非、この機会に記事作成いただき、貴サイトの成果向上にお役立てください。
またご不明点がございましたらご連絡いただければ幸いです。

何卒、宜しくお願いいたします。

-------------------------------------------
株式会社もしも
松本 法子

〒140-0002
東京都品川区東品川2丁目2-24
天王洲セントラルタワー12階
MAIL: n.matsumoto@moshimo.co.jp
URL: http://www.moshimo.co.jp/

-------------------------------------------

へえ、Amazon Music Unlimitedは、4000万曲以上が効き放題(ママ)の音楽サービスなんですか、すごいねー。どんな症状に効くのかな? そのうえ、Prime会員なら月額780円なんて安いねー(棒読み)w 更に10%も上積みなんて、そんなに儲かるなら、自分でやればいいじゃん! (どこの金利よりもいいから、マジでやればいいのに) ところで、ASPってなんだっけ?w

もしも、もしもが少しはまともなんだとしてもw、少しはサイトを読んでから出せよ。何も読まずに出して来るなんて全くの手抜きだ。それだけでunsolicitedの極みだし、何万通出しても効果なんて出ないだろう。

見事にUNSUBSCRIBEの罠に引っ掛かった感じだが、これからも来るならアドレスを変えるから別に問題ない(その点は、Googleには大変お世話になっている)。

知らねーよ! eleven-tenthsだの株式会社もしもなんて!

 

PS. 細かいことだけど、IT関係者のリテラシーを見る(というか、そもそもIT関係者かどうかを調べる)のに、全角空白・アルファベットとか半角カナは最初のフィルタにはとても良い。

  •   1
  •   0