piu lentoの日々 (piu lento days)

[8/11 1:59 ResticとWasabiの評価で問題が見つかったため結論を変更し、その件を記載した。 → まとめ]
[8/4 12:24 8/2の更新後のDuplicatiの試用中に新たな情報が得られたので、再度、結論などを変更した。結局、最初の結論に戻った。]
[8/2 15:45 投稿後に新たな情報が得られたので、結論などを変更した。見難くならない限り、前回の記述を取り消し線で残した。]

現在使っているオンライン(クラウド)バックアップサービスCrashPlanは、Linux対応で定額制(使用量・転送量が無制限)で良かったのだが、去年、個人向けサービスを終了してしまって、Linuxで使う場合はビジネス用プランに移行せざるを得なくなって、かなりの値上げ(確か、年間5千円程度増)になった。来年の1月までは大幅な割り引き(75%引き)になっているので、ムカつきながらも(それで止めた人は多そうだ)とりあえず使っているが、今年中に移行先を見つける必要がある。本音を言うと、Windowsの時に使っていたBackblazeがLinuxでも使えれば、それで全く問題ないのだが、サポートされていないので他を探すしかない。

検討作業は9月頃から始める予定だったのだが、近頃時間ができたのでいろいろ試してみたら、今まで知らなかった新しいことが分かった。ここでは、そういうことも紹介したい。

結論を先に書くと、Backblazeや個人向けCrashPlanほど適当なものはなく、いくつかのものを組み合わせて実現するしかない。今は、以下のようにオンラインストレージ対応のバックアッププログラムを使って、オンラインストレージにデータをバックアップする構成が(費用対効果が)最も良さそうだと考えている。

• オンラインバックアッププログラム: Duplicacy resticとRcloneを併用 Duplicati
• オンラインストレージ: Backblaze B2 Wasabi

別々の構成は、面倒だったり費用がかさむ気がするが、光回線とプロバイダのような感じで、それぞれが選べる点がいいのかも知れない。料金が変わったなどの場合に、気軽に片方(主にストレージか)を換えることも可能だ。それから、バックアッププログラムとストレージが別だと、仮にストレージに侵入された場合でも、記録データのフォーマットや暗号化の情報がなければ、データが流出しにくいことが期待できる。

実際には、フォーマットは公開されていたり、そうでなくても解析すれば分かるだろうし、暗号化だってしょぼかったら解読されてしまうが、データの暗号化と記録が一体化したバックアップサービスの場合よりは強固そうだ。強力なのは、ブロックチェーンのように、データを分割して世界中のサーバに分散して記録することではないだろうか。

試しているうちに、いくつかの必須条件や注意点が見つかったので、列挙する。

1. クライアント(PC)側から鍵(パスワード)を指定してデータの暗号化ができること。更に、その鍵はサーバには保存しないこと。
2. シンボリックリンクをサポートしていること。
3. スリープからの復帰後にバックアップが自動で再開すること。
4. 転送速度が高速なこと。
5. 可能なら、ストレージ側でファイル・ディレクトリ名が見えないこと。
6. サーバは、なるべく2要素認証であること。

1は、サーバ(ストレージ)側でデータがどのように扱われるか分からない(例: サーバのHDDが壊れた時、どう破棄されるか)し、サーバのアカウントが破られる可能性があるので、こちらからデータを送る時に暗号化する必要がある。「サーバ側で＊＊＊方式で暗号化して保存する、強固なセキュリティ」などと書かれていてもそれを信じてはいけないと思う。あと、「SSL/TLSで(通信経路を)暗号化」とか書いてあるのは当たり前過ぎて笑えるが、それだけしかなかったら、全く駄目なサービスだ。

2は、Linux(UNIX)で使うなら必須だ。シンボリックリンクはWindowsのショートカット(キーでない方)やエイリアスに相当するもので、データ量としては取るに足らないが、情報としては重要なこともある。あるものが欠けたらシステムが動かなくなることもある。最初は、バックアップするのはテキストや写真など、通常のデータが主だから、なくてもいいか(我慢する)とも思ったが、復旧時に、記憶を頼りに手作業で直すのは現実的でないと思うし、何も考えずに保存できなかったら、それはバックアップとは言えないと思う。試したうちで、「Linux対応」とと書いてあったりLinux用のアプリなのに、さらっとシンボリックリンクをサポートしないもの(iDrive, Rclone)があったので、注意が必要だ。そういえば、今使っているCrashPlanが大丈夫か、心配になって来たｗ

3は、バックアップを定期的に自動で行う場合に、デスクトップPCなので、常時稼働させている訳ではないから、バックアップ中にスリープできなかったり、スリープからの復帰後に手動での再開処理が要るのでは「使えない」ということだ。スリープさせたら、復帰後に何もしなくてもバックアップが再開されて欲しい。

5も1と同様で、ファイル・ディレクトリ名が見えない方が、セキュリティの点で望ましいだろう。

6は今では当たり前のことだが、まだ少なくて、従来のパスワード方式が多い。そのため、1のデータ暗号化をする価値があると思う。

今回試したか検討したものと評価を以下に書く。

バックアップサービス (アプリ+ストレージ)

• ×× iDrive
  • GUI
  • シンボリックリンク: NG (無視する)
  • スリープ後の復帰: NG (回復しない)
  • 高速: 約10MB/s
  • サポートがひどい。
  • 安い: CrashPlanからの移行ユーザには大幅な割り引き(最初の年は9割引き!)があるが、シンボリックリンクをサポートしていない時点で論外(安さにつられて、気付かずに加入してしまった)。「安かろう悪かろう」の典型。
  • 暗号化鍵をサーバに保存しているフシがある。
  • (8/21 19:17追記) 入ってすぐに止めたら、頼んでいないのに返金してくれていた。その点は意外にまともだった。なお、為替変動のため、数円損したｗ
• × pCloud
  • GUI
  • 高い (2TB: $96/年)
  • クライアント側でのデータの暗号化ができない(別料金)。

バックアップアプリ (ストレージ別)

• × CloudBerry
  • GUI
  • 動作がおかしい・不安定 (起動しないことがある、ファイル数・データ量の表示がおかしいことがある)
  • シンボリックリンク: OK
  • スリープ後の復帰: OK
  • ストレージでファイル名が見えてしまう。
  • 中速: 約3.3MB/s
  • Wasabiが使えない(設定してもエラーになる)。
• × qBackup
  • GUI
  • シンボリックリンク: OK
  • スリープ後の復帰: OK
  • ブロック化しているため、ファイル・ディレクトリ名は見えない。
  • 高速: 約7.7MB/s
  • ファイルのサイズと更新日時だけで更新を判定している(他のソフトがどうしているかは未確認)。
  • データをブロック化しているため、バックアップの一部でも壊れた場合に修復できない。直すには全体を作り直すしかない。→ 大規模・長期間使用で破綻するリスクが高い。
• × GoodSync
  • コマンドラインのみで、これがGUIのバックエンドそのものという感じで、オプションの数が多過ぎるうえに資料も少なくて、どうしていいか分からない(考えたくない気分になった)。
  • 設計が古くて、いかにもWindows的(例: Linux版なのに、オプションの先頭の文字が"-"でなくて"/"、ヘルプは"/?"。すごくおぞましいし、パスのセパレータがどうなるのか分からなかったので、止めた)。
• ○× Duplicacy
  • コマンドライン。GUIもあるらしいが、見つからなかった。← Linux用GUIは開発遅延中。
  • GUIは有料で毎年お金が掛かる: $20+$5/年、コマンドラインは個人使用は無料。
  • シンボリックリンク: OK
  • データをブロック化しているため、ファイル・ディレクトリ名は見えない。
  • (ブロック化しているので、)破損に関しての信頼性は不明だが、正当性のチェック機能があるので、異常の検出は可能。
  • 高速: 7MB/s前後 (ただし、処理スレッド数を増やさないと遅い)
  • リストアも高速
  • ファイルのスキャンも高速
  • prune(不要な過去バックアップの削除)も遅くない。
  • スリープ後の復帰: OK (10-15分程度)
  • Wasabiが使える。
  • バックアップ除外指定に正規表現が使える。
  • 負荷は高くない。(Load ave.は最大1.5前後)
  • サーバ(ストレージ)に暗号化鍵を保存しない。
  • リポジトリのロックを行わない。
• ×× Duplicati
  • Web UI (コマンドラインも可)
  • シンボリックリンク: OK
  • データをブロック化しているため、ファイル・ディレクトリ名は見えない。
  • (ブロック化しているので、)破損に関しての信頼性は不明だが、正当性のチェック機能があるので、異常の検出は可能。
  • バックアップデータ(リポジトリ)の堅牢性に欠ける。
    • バックアップを中断したらリポジトリが破損し、確かに異常検出はされたが、修復処理をしても回復できなかった。
  • ブロックのファイルが単一ディレクトリに格納されるので、数が増え過ぎた時に問題が起こらないか不安 (センスが悪い)
  • 処理が遅い。 高速: 8MB/s前後
  • リストアも高速だが、通信速度以上の速度になるので、動作が疑わしい。
  • ファイルのスキャンが遅い。resticの1/3程度。
  • スリープ後の復帰: NG (回復しない) OK (復帰まで15分くらい掛かる)
  • Wasabiが使えない(設定してもエラーになる)使える。
  • バックアップ除外指定に正規表現が使える。
  • CPU温度が高目(resticより5℃くらい高い= 負荷が高い?)。
  • Windows版の移植(Monoというもので動かしている)。機能的には問題ないが、負荷が高いことや動作がおかしいことがあるのはここに起因している?
• ×△ restic
  • コマンドラインのみ。
  • シンボリックリンク: OK
  • スリープ後の復帰: NG (回復しない場合がある)
  • データをブロック化しているため、ファイル・ディレクトリ名は見えない。
  • (ブロック化しているので、)破損に関しての信頼性は不明だが、正当性のチェック機能があり、異常の検出と修復が可能。
  • ファイルのスキャンが遅いことがある。
  • 高速: 約9.6MB/s (遅い場合もある)
  • リストアが遅い。: 約1MB/s
  • prune(不要な過去バックアップの削除)がすごく遅い。
  • バックアップ先のストレージをLinuxにマウントしてアクセスできるのは便利。
  • Wasabiが使える。
  • サーバ(ストレージ)に暗号化した暗号化鍵を保存する。
  • バックアップ除外指定に正規表現が使えない(シェルのパターンのような簡易なもの)。
  • 正常に終了してもロックが解除されず、次回エラーになる。
  • B2でrcloneと一緒に使う場合、通信エラーが頻発することがある。
• × Rclone
  • コマンドラインのみ。
  • シンボリックリンク: NG (実体をコピーするか無視を指定)
  • スリープ後の復帰: OK
  • ストレージでファイル名が見えてしまう。
  • ストレージに対してls(ファイル一覧)などのコマンドが実行できるのは便利。
  • 高速
  • Wasabiが使える。

オンラインストレージ

• × Amazon AWS
  • 一番安いもの(Glacier)を選んでも、やっぱり高い。
  • 転送量なども効いてくるので、費用の見積もりが難しい(面倒)。
• × Oracle
  • ストレージは安そうなのだが、単体で使えるのか謎だった(相変わらず売る気がない?)。
• ○△ Backblaze B2 Cloud Storage
  • 安い: $0.005/GB/月 → 1TBの場合、$5.1/月
  • 最低利用料金がない。
  • 転送量とAPI実行回数に課金あり。
  • 10GBまで無料で使えるが、ダウンロード制限がキツくて、満足に試せない(リストアの確認ができなかった)。
  • Webは2要素認証
  • Webの使い勝手はいい。使っていて気持ちいい。
• △○ Wasabi
  • 最安: $0.0049/GB/月 → 1TBの場合、$5/月
  • 最低利用料金($4.9/月= 1TB分)がある。
  • 転送量とAPI実行回数に課金なし。
  • 30日間、1TBまで無料で使える(クレジットカードの登録不要)。B2のような制限がないので、かなり充分に試せる。
  • 新しいサービスなので、信頼性などには疑問あり。なぜか、対応しているはずなのに使えないアプリや、謎のエラーが出たりする。
    • 謎のエラーは解決した(8/1の追記を参照のこと)。 (8/1 11:21)
  • 格納データ量が1日に1回しか計算(更新)されない。
  • Webの使い勝手はいい。

その他 (今回気付いた現状の問題)

• CrashPlan
  • 今回試したものに比べて、かなり遅い(更新のスキャンも転送も)ことが分かった。
  • いつも転送ばかりしている感じ。
  • アプリが簡素過ぎて(改悪されてしまった)、見ても状態がほとんど分からず、本当にバックアップされているのか不安になる。

[以下の灰色部の記述は古いが、履歴として残す。 8/4 14:29]

最初は駄目だと思っていた、Duplicatiが一番良さそうである。単一のアプリですべての条件を満足するし、Web UIがあるのでバックアップ用のスクリプトを作る必要がなく、状態監視・操作・設定が楽でいい。基本動作の確認後、Wasabiの試用期限まで、実運用の状態でバックアップしてみて、問題の有無や使い勝手などを確認しようと思う。

(8/3 8:57追記) それにしても、resticが暗号化鍵をサーバに保存するという仕様は全く不可解だ。昨日、見つけた比較サイトで知って唖然とした。もちろん、暗号化鍵は更に暗号化して保存しているようだが、なぜそんな危険を冒すのだろうか。多少便利になるのだろうか? 理解できない。

それで、resticのサイトを確認したところ、ユーザの設定したパスワード自体はサーバに保存していないが、それから導かれた、暗号化や認証に使う鍵はサーバに保存している。更に資料を読むと、そうする理由が書いてあって、パスワードの変更を容易にできるようにするためとのことだ。つまり、パスワードと暗号化鍵を同じものにすると、(漏洩対策などのために)パスワードを変更するには、全データを再暗号化する必要が生じる。一方、resticの方式ではその必要はない。確かにそうだが、現実問題として、どちらがいいのだろうか。resticの方式が破られる可能性はないのだろうか?

いずれにしても、resticはリストアが遅すぎて実用的でないから、現時点では使うことはできない。

↓

(8/4 12:24, 13:51追記) Duplicatiを実際の条件で試用していたら、どうも動作が不安定な感じがした。例えば、スキャン速度やデータ送信速度が実行のたびに大きく異なる(すごく遅い場合がある)ことである。更に、リストアが速過ぎる(通信速度を大幅に超えていた)ので、どうも信頼できない印象を受けた。

それで、バックアップを中断してresticを試したのだが、使い勝手の点で劣るため、気が変わって再度Duplicatiでのバックアップを再開したら、リポジトリが破損しているエラーが出た。それで修復処理を実行したのだが、どうしても直らなかった。

どうやら、Duplicatiはリポジトリの構造が脆弱(壊れやすく復旧できない)なようだ。壊れるだけならいいが、バックアップの中断程度で回復できなかったら、実使用には全く耐えられないから、不採用とし、resticでの評価を再開している。

ちなみに、resticも、再開しようとしたら、リポジトリのチェックが要るというエラーにはなったが、ちゃんと修復できてバックアップが再開できた。なお、ストレージに保存済みのデータをチェックしているのか、データ送信が再開するまでには結構時間が掛かった。それでも、中断まで書き込んでいた時間よりは短かった(6時間書き込んでいて、チェック(?)は1時間程度だった)。

resticの問題は、リストアがすごく遅いことと暗号化鍵がストレージに保存されることと使い勝手が劣ることだ。リストアの遅さは我慢するしかないが、大規模なリストアでなければ、ストレージをマウントして、ファイル一覧を見ながら1個ずつリストアできるというメリットはある。暗号化鍵の点は、リポジトリのパスワードが破られなければ安全なので、強度はDuplicatiと同等なのかも知れない。ただ、resticの仕組みが破られたりやバグが突かれたら駄目だろうから、そこは信用するしかない。使い勝手については、スクリプトを作るなどして自分で解決したり、我慢する必要がある。

 

[8/4 12:24 結論が変わったので、再度有効にした。][以下の灰色部の記述は古いが、履歴として残す。 8/2 15:45]

残念ながら、現状では単一のバックアップアプリ・サービスで最適なものはなかった。アプリの機能ではresticが一番良かったのだが、スリープ非対応なので、最初はそこをうまく対処して(バックアップ中にスリープしたら、復帰後にアプリを再起動させる)使おうと思っていた。

そのためのスクリプトも作ったのだが、resticとRcloneが組み合わせられれば(「いいとこ取り」ができれば)最強だと思って更に調べたら、本当に組み合わせて使えることが分かり、今はその形態で、実使用に近い大容量(500GB-1TB)・長時間のバックアップを試している。

なぜ２つを組み合わせるといいかというと、resticが駄目なのは、スリープからの復帰後に失敗した通信をリトライしないからなので、バックアップデータの処理はシンボリックリンクをサポートするresticにやらせ、オンラインストレージへの記録は、通信の失敗時にリトライするRcloneに任せればいいのである。以下のような構成である。

バックアップデータ → restic → Rclone →(ネット)→ オンラインストレージ

なお、resticとRcloneを組み合わせた場合には、restic単体に比べて若干転送速度が低下する(約8.8MB/s)。組み合わせたせいで遅くなるのか、なぜかRcloneではWasabiのリージョンがUS東海岸しか選べないせいなのかは不明である。それでも、CrashPlanよりは充分に速い(確か10倍以上)ので問題はない。

(8/1 2:50 加筆・修正)

↑

(8/1 11:26追記) Rcloneで、WasabiのUS西海岸リージョン(us-west-1)へのアクセスがエラーになる問題は解決した。専用のホスト名(s3.us-west-1.wasabisys.com)を指定する必要があった。(→ 参照) 今の評価が終わったら、速度を比較したい。

(8/2 2:16追記) 西海岸リージョンを試したが、劇的に速い訳ではなく、東海岸より12%程度速いだけだった。Rcloneを入れると速度が低下するようだ。それでも、経路が近い方が問題の起こるリスクは下がるので、こちらを使うことにする。

次に、リストアを試したら、リストア自体は問題なくできたのだが、速度が約720KB/sと、かなり遅かった。B2でも遅かったので、サーバが遅い訳ではなく、リストア処理が重いのだろうと思う。Rcloneを通さないで試したら、1.5倍くらい速くなることが分かった。リストアは定期的に行うものではないし、リストア中にスリープするような危険は冒したくないので、restic実行用スクリプトを修正して、リストア時はRcloneを通さないようにした。

この条件で再度テストを行った後、試用期間いっぱいまで、実運用の状態でバックアップしてみて、問題の有無や使い勝手などを確認しようと思う。

↓

resticを使ってみたら、さまざまな問題が出て来て、かなり不完全でとても実用には耐えないと思った。例えば、resticはバックアップなどの処理の際にリポジトリ(バックアップデータ)をロックした後、正常に処理を終えてもロックを解除しないので、自分で解除処理をしないと次回にエラーになってしまう。これだけでも出来を疑ってしまう。

それから、画像のように圧縮できない小さいファイルが多い場合や、大きなファイルの転送が遅く、バックアップ対象変更時の再スキャンも遅く、prune処理(過去の不要なバックアップ履歴の削除)がかなり遅い(数時間掛かる)。更に、prune処理中にスリープしたらハングした。また、Rcloneと組み合わせてB2で使うと、エラーが多発した(resticではなく、RcloneとB2の相性だと思う。大きなファイルの転送時に起こると思われる)。また、プログラムの出力をファイルにするとメッセージが少なくなってしまって、処理状態が分からないなど、使い勝手の問題もあった。

Wasabiは、よく調べたら1TB分の最低利用料金が掛かることが分かり、データ量が少ない場合には最安ではないことと使い勝手に不満があったので、却下した。

それで再検討・評価したところ、当初は毎年更新料が必要と思っていたために(実際にはそうでなかった)却下していたDuplicacy(コマンドライン版)とBackblaze B2の組み合わせが最適という結論になった。この組み合わせは最初に挙げた必須条件をすべて満たすうえに、すべての処理(ファイルのスキャン、転送、リストア、prune)が高速なのが素晴らしい。

DuplicacyとB2の基本的な動作を評価して大きな問題がなかったので、現在は実運用の状態で継続的にバックアップを行い、問題の有無や使い勝手などの確認を行っている。その後、しばらくCrashPlanと並行して使うか、CrashPlanを止めるかする予定である。 (8/11 1:59)

 

PS. 通信速度の高速化には目を見張るものがあり、昔はオンラインでのバックアップに1か月以上掛かっていたが、今なら数日間で終わりそうだ。太平洋の回線がかなり太くなったような気がする。もちろん、サーバ側のリソースにも依り、CrashPlanは悲惨なものだ。

PS2. まともなアプリはほとんどコマンドラインというのは嘆かわしい。しょうもないGUIよりはましだし、自分の希望どおり細かく設定できるのはいいのだが、正直なところ、バックアップなんて、いい加減(お手軽)に設定してもそこそこちゃんと動いて欲しいものだ(いや、その「そこそこちゃんと」が難しいのだがｗ)。。。

PS3. Duplicatiは、resticのリストアがすごく遅いので、解決策を検索していたら、他のアプリ(Borg)が紹介されていて、それとresticを比較しているページを読んでBorgは使えないことが分かったのだが、更に検索したら、何かのフォーラムにDuplicatiがいいという投稿があったので再度試してみたら、機能も性能も良かった。最初に試した時は慌てていて、いろいろ間違っていたのかも知れない。 (8/2 15:58)

(8/3 17:14 Duplicatiのファイルスキャンが遅い件を追記; 8/11 1:00 再々更新)

拙作のSpotifyミニプレーヤー(minisp)の話である。

僕は外国の音楽を聴くことが多いので、Spotifyアプリの言語設定を英語にしている。それでminispもそのまま英語表記にしていたのだが、演奏者の名前については、日本のポップ音楽の時は、日本語で書いた方が見やすい気がしていた(なお、英語モードにしていても、日本のポップ音楽の曲名やアルバム名は日本語で出る)。例えば、前の稿で書いた渡辺真知子は"Machiko Watanabe"じゃなくて、やっぱり「渡辺真知子」の方が見やすいし適切だろうと思って、何とかしようとしていた。

が、その「日本のポップ音楽の演奏者だけは、名前を日本語で書く」という機能を実現するのは結構難しかった。どうやって日本のポップ音楽の演奏者を判別するかが問題だった。最初はMusicBrainz(フリーの音楽情報DB)の演奏者情報を使おうとしていたのだが、フリーのためか、登録されている情報が使いにくい(英語圏以外の人名が現地語で書かれている(例: ルガンスキーは"Николай Луганский"): DBの情報としてはすごく正しいことだが、使いにくい)とか一貫性がない(例: 抜けがある)などの問題があって、うまく使えなさそうだった。仮にそこが何とかなっても、そもそも「日本の演奏者」を判定するのが困難だったので、ずっと保留にしていた。

が、先日、SpotifyのWeb APIが使えるようになり、それで取得できる演奏者情報の中にジャンルがあり(なぜか、曲にはない)、運のいいことに、日本のポップ音楽の演奏者のジャンルには"japanese"とか"enka"とか"kayokyoku"とかいう単語が含まれていることが分かったので、それで判別することにした。なお、ISRC(曲の録音の識別記号)の先頭の2文字で「日本の録音」であることが判別可能なので、それを使うことも可能なのだが、仮に外国の演奏者の日本録音盤があった場合(ないとは思うが・・・)に誤判定になるので止めた。

少し苦労したが、うまく行った。が、思わぬ伏兵が居た。日本人のクラシック音楽の演奏者だ。その人たちのジャンルにも"japanese"が入っているので、名前が日本語で表記される。例えば、内田光子だ。それも一貫性があっていいのだが、個人的には、世界的なクラシック演奏者は英語で書く方が適切だと思っているし、オリジナルCDでも英語なので、ここは英語にしたい。

幸い(というか、どういう訳か)、日本人のクラシック音楽の演奏者には"japanese"とともに"classical"という単語が入っているので(例: "japanese classical performance")、その場合には英語表記にすることにした。

余談: (日本の曲だけを演奏している訳でない)クラシック音楽の演奏者のジャンルに国の情報を入れるのは、ちょっと差別的(昔の、「日本人のクラシックだよ()」という嘲笑を感じる)な気がするが、まあ、Spotifyはそういうポリシーなのだから仕方ないし、今は便利だから良しとする。でも、個人的には、入れるのであれば、「出身地域」などのようなフィールドの方が適切だと思う。が、いろいろな問題や文句が出そうなので、無理そうだ。

更に調べたら、ユジャ・ワンやチョ・ソンジンのジャンルには、国籍を示す単語は入ってなかった。どういうことなのか理解に苦しむが、考えても仕方ない。まあ、Spotifyでなく、レーベルがデータを作ってSpotifyに渡していて、その作り方の違いなのかも知れない。実際、ソン・ヨルムのジャンルは空だった。

という訳で、とりあえずできたが、(僕のわがままのせいで)いろいろな判定が多くなってプログラムが複雑(正確には「肥大化」)になっているのが気に入らない。あと、上の判定はやっぱりいい加減なので、今後、思わぬ落とし穴が見つかりそうだ(例えば、日本のポップ音楽だけを演奏する外国の演奏者が居たら、一体どうなるのか?? あと、宇多田ヒカルはどうなんだ? → ジャンルに"japanese r&b"が入っているので、日本語で出るはず)。

技術情報: SpotifyのWeb APIで、例えば曲情報の言語(例: 日本語/英語)を指定して取得する方法はあまり資料には書いてないが、可能だ。カテゴリーのブラウズにならって、要求のURLにlocale引数を追加すればいい。例えば、Spotify IDがxxxxの曲のトラック情報を日本語で取得するには、URLを以下のようにする(太字部分を追加)。

GET https://api.spotify.com/v1/tracks/xxxx?locale=ja_JP

これは公開情報でないので、いつまで使えるかは不明だが、単に資料の記載漏れと思うので、大丈夫だろうと思う。

Spotifyを始めてから、岡村孝子を再評価した。以前は、「あみんで売れた人だけど、なんかミーハーっぽいよな」と思っていたのだが、改めてヒット曲(「夢をあきらめないで」(1987))を聴くと、悪くない。それから、その曲が入っている"liberte"(1987)のジャケットの雰囲気(主に髪型?)が森高に似ている(森高より落ち着いて見える分、上かも知れない)せいか、妙に気になった(そんな自分こそミーハーだｗ)。意外に僕より年上で、今は56歳でおばさんになっているけど、近影を見る限りいい歳の取り方をしている感じで、なかなか好感が持てる。こういうお姉さんが居たら悩みを聞いてくれそうだ。

岡村とは関係ないのだが、やっぱりSpotifyで改めて好きになった(というか、昔からヒット曲が好きだったから懐かしいけど、今聴いても、やっぱり曲も歌もいいと思う)渡辺真知子には誤ったイメージを持っていた。結構前から大阪出身と思い込んでいて、今は、いかにも「大阪のおばちゃん」になっているのだろうと思っていたのだ(実際、公式ブログの写真はそう見える)。好きな曲(「迷い道」(1977)や「かもめが翔んだ日」(1978))の歌い方やTVでの言動(といっても、観たのは大昔のことなので、記憶が確かでない)が、どことなく大阪の人を思わせたのだ。でも、岡村を調べたついでに調べたら、横須賀出身だったことが分かって、ちょっと驚いた。だから、大阪出身と思い込んだのは、姉御的な雰囲気を感じたせいかと、今思っている。こういうお姉さんが居たら、乗りが良さそうで楽しくて、頼りにできそうでいいと思う。

結局、「いいお姉さんが欲しかった」ってことに帰着しそうだ

と思いきや、ついで(記述内容の検証のため)にもう一人調べたら、大どんでん返しがあった! 渡辺と同時代にヒットした庄野真代が大阪出身だったのだ。ヒット曲、「飛んでイスタンブール」(1978)はいかにも都会的で(大阪が都会でないという意味ではないです。東京人の、いかにも「私、かっこいいでしょ」とかどことなく冷たい雰囲気を感じたのです)、横須賀とか東京出身のイメージがあったのだが・・・ どこかで渡辺と記憶が逆転したのかも知れない。更に調べたら、同じ頃に東京出身の久保田早紀が「異邦人」(1979)をヒットさせており、この3人のイメージが混ざっていたような気もして来た。実際、「イスタンブール」と「異邦人」はどちらも好きだけど、頭の中では渾然一体としていて、聞かないと分からない(当然、頭を歌うこともできない)。

結局、僕のイメージや記憶は当てにならないってことに帰着しそうだｗ

昨夜、気分が良く夕食を食べていたら、上司からメールが来て、対応しているうちに再びイライラに襲われて、夕食がまずくなった。

事務担当から僕への連絡方法をどうしたらいいかとか聞いて来た。「はぁ?」だ。退職届を出した数日後、「了承されたから事務処理を始める」という連絡が来てから2日も経ったというのに、まだ(処理を)始めてないのかよ! 何も連絡がないから進んでいるのかと思っていたが、今まで何やってたんだろう? 何万人も居る大企業じゃないのに・・・ 「今でしょ」って言葉を聞いたことないのかな?ｗ こんなの、一番最初に、遅くても次の日に確認すべきことだろう。元々のろまな会社(特に、その事務の老人)・上司とは思っていたが、どこまで手際が悪いのか全く見当がつかない。生産性が悪いどころじゃなくて、生産性がない。良く今まで持っていたと思う。

そのメールに回答した後に来たメールには、「電話で話したいことがある」(内容は書いてなかった)とあった。「えぇ・・・」である。内容を聞いたら、その事務担当が電話で聞きたいことがあると言っていたそうだ。再び「えぇ・・・」で、完全にブチ切れた。だから連絡方法を聞いてきた? だったら最初からそう書けばいいのに、まったく面倒な奴! 「相手を怒らせるだけの簡単な仕事です」か?ｗ

(精神的に良くないので、)ずっと、電話は遠慮して欲しいと書いていたのに、結局電話かよ! 良く居るのだが、何かというと、必要もないのに、金科玉条のように電話で話したがる未開人(世の中に追従できない人)たち。上司なんて、お客さんにはいつもメールの後に電話だ。本当に頭が悪いと思う。自分はそれで気が済むのかも知れないが、相手の都合や手間は考えたことがあるのか?

この2通目で動悸がぶり返してしまった。とにかく、一刻も早く縁を切りたい!

まあ、いずれにしても今月末で退職なので、あと少しの辛抱だ。が、この調子では、退職日までに事務処理は終わらず、その後も上司だの事務だのにイライラさせられそうだから、先が思いやられる・・・

まったく、馬鹿にはどうしたって勝てない。

 

(7/28 6:52追記) 昨日の午後に漸くその事務員からメールが来たのだが、内容は「メールアドレスは合ってるか」と、「これから処理内容を確認して進めていく」みたいなことしか書いてなかった。退職なんていくらでもある・あったのに、毎回、何するか調べているのか。処理のマニュアルとか作ってないのだろうか? 調べるにしたって、朝から数時間あっても何もしていないのか。僕だったら、最初のメールで、これからのスケジュールとかやること・提出物一覧を書くがね。

仕事の品質改善はおろか、効率向上の気すらない全くの能なしババアで、呆れる以前だった。こういう悪質な怠惰野郎は早く淘汰されてもらいたいが、後任も似たようなものだろう。まあ、僕にはもう関係ないけどねｗ

暇なので、余計なことをいろいろ考え付く。昨日、ふと、光回線のアダプタ(ONU)が邪魔に思えた。ONUの後に繋ぐルータは結構前に本棚の下に移設して、見えなくしていたのだが、ONUは光ケーブルが短いうえに弱くて移動できないので、光端子の近くに置いて、小さい衝立のようなもの(台)で隠していた。が、やっぱりすっきりせず、見るたびに何とかしたいという気分になっていた。しかも、衝立の陰に埃が溜まって来たのも、嫌な感じだった。

それが、何の拍子だったか、「丈夫な光ケーブルがあれば延ばせるのではないか?」と思い※、Amazonを探してみたら、強化された光ケーブルがあった。キーワードは、「光配線コード」と「曲げに強い」とか「曲げフリー」のようだ。

※順序が逆かも知れない。「とりあえず断線してもいいから、安いケーブルで延ばそうか」と探していたら、関連商品に強化されたものが見つかったような気もする。しょうもないことに、すっかり記憶がないｗ

全く知らなかったのだが、通信用光ケーブルにはいろいろな種類があるようで、フレッツの光回線に使えるのは、以下の仕様らしい。

SCコネクタ(シャッターなしでも可), シングルモード(9/125), 1心(芯?), SPC研磨, 波長: 1310/1550nm

畑違いなので、まったく初めての単語が多い。そして、家庭用でもシングルモードを使っているのがちょっと意外だった(業務用をそのままを使っているのかも知れない)。だから、やろうと思えば100mくらいは延ばせるのではないか(要確認)。

余談: オーディオマニアは、このケーブルを使うことは考えないのだろうか? 普通のS/PDIF用光ケーブルなんて、きっとマルチモードだし、減衰も大きそうだし、特性も悪そうだから、この通信用インタフェースとケーブルを使えば、波形が美しくなり、ノイズやジッタなどが減って、音質が向上するとは思わないのだろうか? (僕は思わないがｗ) まあ、音質は分からないとしても、コネクタはしっかりしているから、それだけでも使う価値はありそうだ。

ヨドバシには全く置いてなかったので、Amazonで注文した。線が黄色の物は安いのだが、目立つのは嫌なので、割高だけど白色のものにした。5mで約1500円だった。プライム会員でないと送料が掛かるのだが、運良くお試し会員になれたので、なった。

今朝届いたが、とても簡素な袋(クッションの薄い紙袋)に入っていて、輸送中に破損しないのかと思った。更に、「ステンレス管で保護」とかいう割には華奢で弱そうだった(しなやかで、全然硬さを感じない。径は3mm程度)。破損させないように気を付けるに越したことはないだろう。さっそく試してみたら問題なく通信できたので、ONUをルータの近くに移動させた。ルータ同様に横置きできることが分かったので、最終的には、本棚の下のルータの隣に置いた。ついでに、JACKが問題なく動いているので、グライコ(DEQ2496)を仕舞って、本棚も少しすっきりさせた。

(長らく掃除をしていなくて埃が溜まっているので)写真は載せないが、光端子の付近がとてもすっきりして、大変気分がいい。ONUがなくなった以外に、光通信自体には電源は要らないので(というのはまやかしで、実際には光を出すのも受けるのにも電源は要る。この光は局から直接来ているのだろうか? それとも近くに中継点がある?)、電源アダプタなどを置く必要がなくなったのも大きい。あと、光ケーブルが細くてLANケーブルより目立たないのもいい。

PS. ちなみに、通信速度を測ってみたら、Fast.comで"140Mbps"と出た。これが速いのか普通なのか、値が正しいのかそうでないのかは全く分からないし、普通に通信できればいいから気にしないがｗ、とりあえず、光ケーブルに問題はなさそうだ。

(7/27 2:44, 6:48, 7:36 写真を載せ、少し加筆)