Archive for the ‘PC・技術’ Category

先日から渡辺真知子を見直している。今朝も、彼女の歌が掛かったら、「やっぱりいい!」と思った。他の「うまそうに」歌うポップス系の人たち(個人的な印象なので、例示は止めておく)と違って、本当にいいのだ。どういうことかというと、本物(≒ ちゃんとしたクラシック系の人)だと思えるということだ。具体的には、声の質と量が豊かで深みがあって魅力的なのだ。別の言い方をすれば、「お腹の底から声を出している」かも知れない。あと、(下品でなく)明るく色っぽい感じに歌うのもいい。

そして、今はどういう歌を歌っているのか気になった。が、その先が問題で、今はSpotifyでいくらでも聴けるのに聴いてはいないし、これからも聴く気は起こらないだろう。

というのは、確かに彼女の歌唱は手放しで褒めたいくらいいいのだが、近頃の曲が僕の好みかは疑問で、おそらくそうでないからだ。実際、昔のアルバムを聴いても、ヒット曲以外はグッと来なかった。(そういえば、大好きな「かもめ―」の「スタジアムバージョン」とかいうのだって、イントロだけで「いい曲に余計なことすんな!」と思ったくらいだ)

ピアニストに例えれば、技術も表現もすごくいいんだけど、僕が好きな曲を弾いてくれない人のようなものだろうか。本人は弾きたい(歌いたい)から選んで(作曲して)おり、それはその人の表現(まあ、営業的なものもあるかも知れないがw)そのものだから、いかんともし難しい。

まあ、今後、Spotifyでリコメンドされて掛かることはあるだろうし、その時に気に入る可能性もあるから、気長に構えることにする。

  •   1
  •   0

[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ほど適当なものはなく、いくつかのものを組み合わせて実現するしかない。今は、以下のようにオンラインストレージ対応のバックアッププログラムを使って、オンラインストレージにデータをバックアップする構成が(費用対効果が)最も良さそうだと考えている。

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

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

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

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

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

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

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

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

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

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

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

  • ×× iDrive
    • GUI
    • シンボリックリンク: NG (無視する)
    • スリープ後の復帰: NG (回復しない)
    • 高速: 約10MB/s
    • サポートがひどい。
    • 安い: CrashPlanからの移行ユーザには大幅な割り引き(最初の年は9割引き!)があるが、シンボリックリンクをサポートしていない時点で論外(安さにつられて、気付かずに加入してしまった)。「安かろう悪かろう」の典型。
    • 暗号化鍵をサーバに保存しているフシがある。
    • (8/21 19:17追記) 入ってすぐに止めたら、頼んでいないのに返金してくれていた。その点は意外にまともだった。なお、為替変動のため、数円損したw
  • × 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の試用期限まで、実運用の状態でバックアップしてみて、問題の有無や使い勝手などを確認しようと思う。

Duplicatiのweb画面 (バケット名は隠した)

(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)・長時間のバックアップを試している。

なぜ2つを組み合わせるといいかというと、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よりはましだし、自分の希望どおり細かく設定できるのはいいのだが、正直なところ、バックアップなんて、いい加減(お手軽)に設定してもそこそこちゃんと動いて欲しいものだ(いや、その「そこそこちゃんと」が難しいのだがw)。。。

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

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

  • restic/restic

    restic/restic

    Fast, secure, efficient backup program. Contribute…

  •   0
  •   0

拙作の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

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

  •   0
  •   0

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

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

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

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

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

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

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

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

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

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

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

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

  •   0
  •   1

先日、Spotifyが仕様変更(ローカルなhttpでのSpotifyアプリの制御・情報取得機能の廃止)したために、対応に追われていた。というほどまじめにやっていた訳ではなかったが、それまで動いていた機能(再生位置の表示)が、ある日(7/21頃)アプリを再起動したら、突如として駄目になって慌てたのは確かだ。検索してみたら、他にも引っ掛かった方が居て、フォーラムの投稿がいくつか見つかった(例:  "[IMPORTANT] SpotifyLocalAPI not working #254")。

実は、今回のことは最初から予想していたので、「勝手なことをしやがって! ク○が!」などとは全く思っていないw 「意外に早かったな・・・」程度だ。そもそも、非公開の機能を勝手に使っていたこっちが悪いので、それを彼らが予告なしに無効にしたって、文句を言う筋合いはない。

が、再生位置の表示がないとどうにも不便なので、何とかしなければならなかった。根本的な解決策(公式のWeb APIを使うこと)は既に分かっていたのだが、資料を見るとどうにも面倒な感じなので、できれば避けたかった(前もって書くが、こういう手抜きが後々どうにもならなくなることが多い)。

それで、とっつきにくいWeb APIは後回しにして、まずは、小手先(あるいは、子供だまし)の対処をした。再生位置(時間)は分からないが、新しい曲の再生が開始されたことは分かるので、開始した時からの経過時間を表示する(要は、1秒ずつカウントアップする)ようにしてみた。見た目はそれらしいが、中身は誤魔化しもいいところだ。

それにする前に他の案も検討したのだが、どれも駄目な(手軽にはできない)感じだった。例えば以下である。

  • アプリのウインドウに表示される再生位置の数字を(プログラムで)「読む」。: 検索してもそんな便利な物はなく、無理っぽかった。やるなら、画像認識が要りそうだ。ちゃんとできればいいが、さすがに毎秒やるのは重そうだ。
  • アプリとウインドウシステム(X Window System)のサーバ間の通信を傍受する。: どれが何か判別不能だった。どうも、数字は文字でなく画像として表示している感じだった。
  • アプリのログやメモリを読む。デバッガ(gdb)でアプリの変数を読む。: やっぱりできなかった。ログには書かれていなかった。デバッガなんて、使い方を思い出せなかった・・・
  •  ブラウザでwebプレーヤーを表示して、その数字を読む。: メモリが無駄になるので、却下した。
  • アプリとSpitifyのサーバとの通信を傍受する。: やっぱり判別不能だった。TLSで暗号化しているだろうから、そもそも無理だろう。

誤魔化し策は結構簡単そうな気がしたが、実際に作ってみると意外に大変だった。まず、再生を一時停止してもカウントアップが停まらなかったしw、アプリで再生位置を変えても(プログレスバーでのジャンプ)反映されないし、アプリの起動時に曲の先頭でなければ、その曲の最後までずっとズレたままだ。

かなり試行錯誤して、一時停止とジャンプについては何とか対処できた。後者は、アプリのコンソール出力やログに情報が出る("Flush driver"の行)ので、それを使った。しかし、起動時の再生位置の反映は無理だった。そうでなくても、どうしても1-2秒の微妙なズレが出て、気分が悪い。そればかりか、この対処を入れたら、アプリどころかシステムまで不安定になってしまった。ウインドウシステムが不意に落ちてしてしまうのだ。ログを読むのにFIFOを使ったのが良くなかったのだろうか?

さすがに観念して、Web APIを使うことにして、調べた。やっぱり、認証(OAuth)が面倒だった。資料の書き方が今一つ分かりにくいのか(例えば、認証の方式が3つもある)、僕が慣れていないだけなのか、最初はどうすればいいかさっぱり分からなかったが、試行錯誤するうちに分かってきた。

確かに、Spotifyアプリの再生位置は、Web APIの"Get Information About The User's Current Playback"で取得できる。APIを使うこと自体は簡単なのだが、認証が大変だった。"Authorization Guide"を読んで、途方に暮れた。。。 が、ここで引き下がる訳にも行かないので、何とかした。もちろん、APIを使うための既存のプログラムもいくつかあるのだが、この認証が特殊なために簡単には使えなそうだったので、自分で作った。

何が特殊かというと、「古き良き」パスワードが全く使えないのだ。Spotifyにアクセスするアプリを最初に使う時は、必ず、ブラウザでSpotifyのサーバで認証(ログインやアプリのアクセスの許可)をしなければ、アクセスするための情報(トークン)が取得できないのだ。Googleのアプリパスワードような逃げ道すらない。ユーザにとっては安全でありがたいのだが、こっちの身にもなって欲しいw

ブラウザを使うこと以外に、Spotifyでの認証後に、指定したサーバにリダイレクトされる(ページがジャンプする)ので、それも何とかしなければならない。なぜかというと、そのページのURLにAPIアクセスのためのトークン(正確にはトークンを得るための情報)が入っているので、アプリはそれを取得しなくてはならないのだ。アプリを動かすのにサーバも要るのかって話で、全くやれやれだった。

更に試行錯誤するうちに、以下のことが分かった。

  • リダイレクトはPC内でローカルに済ませられる(Spotify社からアクセスされる訳ではない)ので、サーバは外部になくてもいい("localhost"は駄目なようだが、正しいドメイン名があればいいようだ)。
  • リダイレクト先のページの内容は何でもいい。ブラウザに表示されるが、(Spotifyの人でなく)自分が見るので、綺麗でなくても良く、空白だっていい。アプリがそのURLが取得できればいい。
  • そのため、リダイレクト先のページを出すサーバは、まともなwebサーバである必要はない。リダイレクト先のURLを取得できればいい。

それで、以下のように実現した。

  • リダイレクト先のURLは、自分のドメインに架空のサブドメインを付けたものにする。(例: dummy.piulento.net)
  • その架空サーバのIPアドレスは、ドメインに関係なく、宅内LANのローカルなアドレスになるようにPCに設定する(この前の宅内サーバの経験が役だった)。
  • ページを出すサーバは、認証をする時だけsocatというコマンドででっち上げる。ブラウザがトークンを含んだURLを要求して(送って)来るので、それを読んでアプリに渡し、ブラウザには、適当な応答(例: "HTTP/1.1 200 OK"と「認証に成功した」っていうメッセージ)を返す(この程度ならPHP自体でもできるが、最初から作るのも面倒なので、socatを使った。なお、ncコマンドも使えるが、ブラウザに表示できないので見苦しい)。
  • 一度認証を通せば、あとはそのトークンの有効期限が切れる頃に更新用情報を使って更新できる(この時はブラウザ不要)ので、そのための情報を保存しておく。
  • また、APIへのアクセスにはアプリ自体の認証情報(あらかじめ、Spotifyのサイトで作っておく)も必要なので、ファイルに保存しておく。
  • この処理は、本体とは別のプログラムで実現した。そのプログラムは、従来の再生情報取得処理が作るのと同じ形式(ローカルhttpでアプリから取得した情報の形式)の情報ファイルを作成するようにして、本体の変更がなるべく少なくなるようにした。

おそらく、上を読んだ方の99.9%は理解できないと思う。そんな、死ぬほど面倒なSpotifyの(OAuthの)認証ではあったが、そこを突破したら、あとはスルッと動いた。そして、結果は以下のとおりで、見た目は何も変わらないが、以前のように再生位置が表示できている。

Spotifyの仕様変更(廃止)に対処して、再び再生位置を表示できるようにした。

なお、今回作った再生情報取得プログラムは、bashでなくPHPで作った。さすがに、あの七面倒な認証をbashでやれるとは思えなかったので、テストプログラムを作る時からPHPにした。PHPにしたら、すごく作りやすかった。追って本体も書き換え(作り直し)たいが、現状の動作に大きな問題がある訳ではないので、あまりやる気が出ないw

ついでに、Web APIでは再生位置をジャンプさせることも可能なので、それを利用して、Dbusではできなかった再生停止機能(全く普通の「停止」です)も実現した。一時停止の後に曲の先頭にジャンプするだけだが、昔から欲しかったので気分がいい。

SpotifyのWeb APIにはいろいろ機能があるので、暇つぶしに遊ぶのには良さそうだ。ただ、以前も書いたように、Thumbs up/downする機能がないなど、どうも詰めが甘い感じで、そこがちょっと残念ではある。でも、GoogleやAmazonなんて、APIを公開してすらいないから、千倍はまともだと言えようw

あと、問題だと思っているのは、アプリに固有の認証情報が要るため、アプリを配布する時にはその情報が外部に取り出せないようにしなければならないが、それは至難の技なので、アプリ流通の妨げになるのではないかということだ。例えば、インストール時にブラウザでユーザに登録してもらうとかがいいのか? それもかなり面倒だが、Electronのような、ブラウザをアプリ化する仕組みなら、ユーザー登録処理に統合できそうだ。あとは、やはりアプリとブラウザが混ざっている状態を使って、アプリのインストール時にバックグラウンドで勝手に登録してしまうとかか(これは禁止されそうだが・・・)。

Spotifyだけ特別なことをしている訳ではないが、やっぱり面倒だ。

 

PS. ふと思ったが、アプリの認証情報をどうやって隠すかという問題は、アプリを配布しなければいいのだろう。Web APIはブラウザなどで動くアプリでの利用を主な対象にしているのではないか。今はそういうのが当たり前だし。ただ、僕のようにちょっと作ってみた人が配布しようとすると、かなり大変だ。

PS2. Spotifyアプリの再生状態取得APIにはどうしても気に入らない点がある。どうして、同じコンピュータの中で動いているSpotifyアプリの状態を知るのに、数千kmも先にあるであろう、Spotifyのサーバにアクセスする必要があるのだろうか?? 1回だけならまだ許せるが、再生位置をリアルタイムで知ろうとすれば、少なくとも毎秒アクセスしなくてはならない。

データ量は微々たるものだが、情報取得のために、毎回、(通信プログラムを起動して、)サーバに接続しなおすなんてオーバヘッドが大きくて、センスが悪過ぎる。しかも、アプリも状態をリアルタイムにサーバに送っているのだろうから、2倍の距離を行き来している。確かに、今は回線や機器が高速だから効率の悪さに気付くことはないが(逆に、これでまともに使えているのが不思議なくらいだ)、本質的にひどい仕様だと思う。廃止されたローカルなhttpの方がずっと良かった。この点は大いに文句を言いたい。 (21:38)

気になったので少し調べたら、Spotify自体も再生位置(時間)は「誤魔化し方式」を採用しているようだ。というのは、SpotifyアプリからSpotifyサーバへの通信が頻繁でなく間欠的だからだ(再生開始時に大量にアクセスがあるが、その後は時々ちょっと通信する程度)。もし、リアルタイムに現在の状態(再生位置など)を送信しているなら、間欠的ではおかしい。確かに、一時停止や再開した時にその情報を送信していれば、再生位置はサーバ側で適宜計算(推測)できる。

ただし、再生中に通信が途絶えたら、サーバに状態を送信できないので、再生位置はおかしくなるだろう。だが、Spotifyは基本的に、ネットに接続された状態(オンライン)での再生を前提としているので大きな問題はない。けれど、オフラインでローカルに保存された曲を再生する時は状態が送信できないから、再生位置を取得できなさそうだ。が、今はオフラインのことは考えていないから問題ない。

そうすると、最初に諦めた「誤魔化し方式」も全く駄目ではなかったようで、改良すればNW効率を改善できそうだ。具体的には、Web APIと併用すれば、問題点(起動時の位置が0でない場合)が克服できそうだ。ただ、再生位置をジャンプさせたことの検出はできるだろうか? いつものようにしつこいが、考えるのはおもしろい。 (7/25 5:55)

ちなみにSpotifyのwebプレーヤーも誤魔化し方式で、アプリでのジャンプや一時停止など、再生状態の同期には対応していない。意外にザルだったw (7/25 6:02)

上に書いたように、誤魔化し方式の改良版を実装した。再生開始時や定期的(10秒ごと)にWeb APIを使って再生位置を取得し、その後は1秒ずつ再生位置を加算していく。また、再生位置をジャンプさせた時には、再生開始時と同様にDbusにメッセージが来るので、それを契機にWeb APIでSpotifyサーバから再生位置を取得して修正する。

これにより、Spotifyサーバと通信する頻度を約1/10に減らすことができた。なお、理論的には定期的な再生位置の調整は不要なのだが、実際には誤差が蓄積して、本当の再生位置からずれることがあるので、した方がいい感じだ。ただ、Web APIで取得できる再生位置も本当に正しい保証がないので、余り意味がないのかもしれない。 (11:25) → 誤差の蓄積と思ったのはバグだったようで、定期的な再生位置の調整が不要になって、Spotifyサーバとの通信を最小限にできた。 (7/26 13:08)

  •   0
  •   0

先日から検討・評価していた、VPS(仮想サーバ)から宅内サーバに移行する件だが、さっき結論(移行しない)が出て、終りにした。デメリットに比べてメリットが少なかったためだ。以下に、検討結果を書く。

宅内サーバのデメリット

  • 家が被災した時に、サーバにアクセスできなくなる。
    • アドレス帳, カレンダーはサーバが停まってもスマフォのキャッシュが残っていれば当面は使えるが、いつかは消えるし更新できない。
  • 自分と家が被災した場合に、家族が僕の緊急時情報にアクセスできなくなる。
    • Googleなどの無料サービスを(バックアップ)サーバとして使うといいのでは?: 外部サービスは突然なくなる可能性があるので、頼りたくない。
  • 安定性: 常に故障する可能性がある。常時稼働なので、運が悪いと火災の可能性もある。
  • セキュリティのリスク
    • サーバとして公開するので、自宅ルータや宅内サーバが攻撃される可能性が高まる。
    • 宅内サーバに侵入されると、自宅LANの他の機器も危険になる。
  • その他
    • VPSを止めると、自宅外のNWから(自宅などに対して)実験することが簡単にはできなくなる。

宅内サーバのメリット

  • 運用に必要なお金が少ないので、クレジットカードが停まっても稼働できる可能性が高い。 ← その時は光回線や電力も停まるから無意味。
  • (VPSの)契約切れでデータがなくなることがない。 ← 元のデータはPCにあるかバックアップしているので無意味。
  • 安い(VPS比-7000円/年): 少なくはないが、もっと大きいものは他にある(例: 食費、車)。
  • 手元にあるので、管理・保守が楽。安心感がある。 ← 多分、幻想。
  • メインPC故障時にすぐに使える。 ← 本質ではない。

結局、災害時やセキュリティや故障に対する安心感は重要で(そもそも、そのためにVPSにした)、ほぼ唯一のメリットである安さは、月にすれば600円にも達しないので、微々たるものだと考えた。塵も積もれば山とはなるが、生活費に比べれば3桁違うので、誤差だろう。

そういう訳で、宅内サーバPCは片付け、テスト・評価のための設定は戻して、(今まで同様)メインPC故障時のスペアとして保管しておくことにした。短い命だったが、考えたり試したりするのはおもしろい。今回も、今まで知らなかったこと(ダイナミックDNSのやり方、dnsmasqによる、特定ホストのIPアドレスの書き換えとローカルDNSサーバの実現方法)が分かったから、全くの無駄ではなかった。

今回は止めたが、僕は、(日本人に多い、)何も考えない現状維持も、駄目だと分かっても気付かないふりをして続けるのも大嫌いだから、これからもすべてを疑っていこうと思う。

 

PS. 本題には全く関係ないが、今思ったので書く。: 音楽でも現状維持はつまらないと思う。古楽器での演奏は、一見良さそうに聞こえるが、仮に本当に当時を再現しているとしたって、結局のところ、現状維持の最たるものではないか。一方で、現代楽器での演奏だって、今までどおりに普通にやっていればいいってものでもないだろう。

  •   0
  •   0

恒例の、車の点検をしてもらった。早くも6年くらい経ち、走行距離は52000kmくらいになったが、信じられないくらい問題がなかった。それ以前に、ディーラーに行くまでの運転(実に10日以上ぶり)が死ぬほど気持ちよかった(いや、死ぬ手前の状態が果たして気持ちいいか分からないがw)。

交換したのは、オイル、オイルフィルタとワイパーのゴム(3本)だけだった(他に、自分で鍵の電池を交換する程度)。それからタイヤのローテーションをしてもらった。料金は1.7万円程度でリーズナブルだった。前にも書いたが、昔は、(今はおフランスと化した、ドラスティックに決まりを破るところが尊敬の的である)Nや(お金持ち御用達の)Yといったディーラーにさまざまな物をふんだんに交換されて、今の数倍の額が掛かっていたが、結局、この程度で充分なのだろう。それは、今の車の質が向上したからなのかも知れない。一方で、今のディーラーが「超ザル」という可能性もあるが、今までの実績や今の状態からは考えにくい。

実は、点検で一番ありがたいのは、洗車してもらえることだ。自分では全然する気にならないので、洗車したい時はオイル交換や点検が待ち遠しいw ただ、無料では限界があり、少し前からボディーに少し汚れ(小さいけど頑固なもの)があって、水で拭いても落ちなかったので、ちゃんと掃除しなくちゃと思っていて、今回落ちるかと少し期待していたが、駄目だった。これは気が重い。

といいつつ、2つだけ意外だったことがある。まず、タイヤのローテーションは、「どうせ点検でタイヤ(ホイール)を外すのだから、無料でやってくれるよね」と思っていたのだが、実際には明細に工賃が書かれていた。それを見た瞬間、目の前が真っ暗になった(というのは盛り過ぎだw)。

まあ、僕も技術者なので、プロが何か作業をしたらお金が掛かるのは分かっているが、勝手な思い込みが外れてがっかりしたのは確かだ。病院で、病気じゃない時の治療(これは治療というより「作業」という気がする)とか検査に保険が効かないのと似ているか? いずれにしても、今までだって請求されていたのだから、当たり前のことで、何も問題はない。

次に、いい方に意外だったのは、ブレーキパッドがまだ半分くらい残っていて、交換不要だったことだった。普通は5万kmも走ったら交換だろうから、(今まで全然交換していないので)今回は覚悟していたのだが、大丈夫だった。随分長持ちだ。自慢になるが、おそらく、僕の運転がスムーズだからなのだと思う。MTなので、車間を詰めたり、小刻みなスピード調整は疲れるから、車間を空けて、なるべくアクセルを変化させず、ブレーキも余り踏まず、信号の手前などは可能な限り惰性で走っている。結果的にブレーキを踏む回数(量)が減って、パッドも減っていないのだと思う。

ところで、ブレーキパッドの減りは、減速させるエネルギーに比例するのだろうから、スピードの2乗に比例するのだろう。だから、少しでもゆっくり走るのは、ブレーキを踏まないのと共に効果的なのだろう。

いわゆるひとつの「堕落した運転」である。「無駄だ! 何のためのスポーツ車だ!」というそしりもあろうが、今の僕はこれでも意味があると思っている。目的は、「楽しく走ること」なので、スピードを出しても出さなくても関係ない。気分が良ければいいのだ。そして、今の車は、車体がかっちりしているせいか、安定感(うまく書けないが、「どっしり」ではない。軽量だから、「かっちり」が一番近い)がすごいせいか、ゆっくり走っても楽しいのだ(もちろん、周りが見えない馬鹿みたいに、流れを滞らせてまで遅くは走らない)。ごくたまに、アクセルをガッと踏むこともあるが、それももちろん楽しい(正直書くと、結構すごくて焦る)。

「何のためのスポーツ車だ!」と言われたら、逆に返したい。「お前は車のために運転しているのか?」と。別にいいじゃん、車の性能をフルに発揮させなくたって。それに、何も考えずにいつでもどこでもスピードを出すのが格好いいとは言えない。僕も若い頃はフルに発揮させなくちゃならないと思っていたが、そもそも公道じゃ無理だし、全くおもしろくない。そして、そう思っているうちは、車に乗られている・操られている・負けているのだと思う。外見じゃなくて中身が本物の車に乗って、それに余裕で乗っている方がいいじゃないか。

と、書いたら、僕が「新人」の頃、先輩と話してムカついたのを思い出した。その時は、電車の中でコンピュータの話をしていた。僕が「(コンピュータの)性能をフルに発揮する必要があるんです! (それが難しいんです!!)」などと熱弁したら、彼は「別に、適当に(余裕を持って)使って、そこそこ速ければいいんじゃない? (速いコンピュータなんて、お金を出せばいくらだって買えるんだから)」のようなことを言った。大変ムカついて顔が真っ赤になったかも知れないがw、今となっては彼は正しかったと思う。妙に偉そうなので好きではなかったが、まあ、大人ではあったw

いつものように余談が長くなってしまったw という訳で、僕の車はまだまだ調子がいい。これ以上何を望めばいいかという程だ(僕がここまで気に入る物って、他に何かあるだろうか??)。しばらくは収入がないから新車は買わないけど、そのほうが余計なことを考えなくて済むし、手間もなくて好都合だ。調子が良くて、買い換える必要が当分なさそうなのはありがたい。

PS. 当たり前のことだが、鍵の電池は、使わなくてもなくなる。2個のうち1個は、納車されてから全然使ってなかったので、中学生のような根拠のない自信で、「きっと使える」と思って試したら、全然使えなかった(もう片方の電池は3年目に交換した)w

  •   0
  •   0

しばらく収入がなくなるので、支出を抑えた方がいいのは確かだ。それで、事前検討として支出額を概算したところ、以下のような順位だった。

  1. 食費・雑費
  2. 家賃
  3. 車関係
  4. 趣味(車を除く)

食費が一番多かったのは意外だったが、良く考えると当然だろう。だから、支出を抑えるには、自炊したり安い部屋に移るのが最も効果的だろう。

興味があってエンゲル係数を計算したら、30%を超えていた。Wikipediaによれば、通常の世帯では25%前後なので、高目ではある。

が、まあ、それも大変なので、次を考えると車だが、通勤しなくなったので、(やたらにドライブしない限り、)減る可能性が高い(ただ、新車はなかなか買えなそうだw)。すると、次は趣味になる。

趣味の中で最も高いのはプロバイダ(光+携帯)の約5600円/月だが、これは減らせない。減らすとすれば携帯だけにするのだろうが、僕はPCをメインに使っているから転送データ量が多いので、それも高く付きそうだ。他には音楽配信(Spotify)の980円/月があるが、もちろん止められないし減らせない(年払いがあればいいのだが、なさそうだ)。

すると、残りはブログサーバで、約1万円/年である。これについては、サーバ(VPS)を借りるのを止めて自宅に自分のサーバを置けば、サーバ料金がカットできる。時代に逆行する(15年前くらい?)のが癪だが、他にないので仕方ない。自宅に置いた場合に掛かるコストは、電気代とサーバ用PC代である。後者は、以前友人にもらったのが既にあるので、壊れない限り無料だ。

ちなみに、昨日、サーバ業者から満足度アンケートが来た。その時は全く問題ないというような回答をしたのだが、その直後に、手のひらを返したように止める検討をしているのが、我ながらおもしろい。アンケートがきっかけで、「そういえば、この料金は減らせない?」と思った可能性は高そうだ(実際、これの前にドメイン名の料金を安くできないか、検討した)。だから、顧客の声を聞くことが藪蛇になる場合があるようだw

サーバ用PCの電気代が気になるので測ってみたところ、なんと、ワットチェッカーが壊れていて、電圧が89Vと表示された(テスターでは100Vだった)。

余談: このテスターは、僕が中学の頃に買ってもらった何十年選手だ。たった10年くらいしか経っていないデジタル製品が負けるとは、情けないものだ。

とりあえず、電流は正しく測れていると想定して消費電力を補正したら、定常状態では約15Wとなった。すると、年間では約2700円(1kWhの電気料を20円とした)なので、7000円以上も安くなることになる。

それで、更に詳しく検討したところ、いろいろな長所短所はあるが(あとで書くかも)、とりあえず、

趣味的なおもしろさ(=暇つぶし)

に惹かれたのでw、試してみることにした。VPSの契約更新は来年4月なので、充分試す時間はある。

検討していて一つだけ気になったのは、PC(結構古い)を24時間動かして故障しないかだが、その時は買えばいいと思っている。「サーバ」といっても、ここは何万アクセスもある訳ではないので、2-3万円程度の小さくて安いので充分だ。

今日は手始めに、ダイナミックDNSを試した。自宅の光回線は固定IPアドレスではないので、ルータの再起動などでIPアドレスが変わる。変わった後に、ドメイン名からIPアドレスに変換する設定を変更しなくてはならない。これは、DNSレコードの設定というもので、そのドメインの元となるDNSサーバの設定を変更すると、それが世界中に分散している各DNSサーバに伝わるようになっている。

その作業はDNSサーバの設定変更、あるいは、ダイナミックDNS機能を使ったIPアドレス更新というものになる。残念なことに、使っているネームサーバ業者がカスなので、DNSサーバの設定変更もダイナミックDNSも使いにくい。前者は素人が作ったかと思わせるような、分かりにくいweb UIだし、後者はWindowsのアプリしか提供されておらず、Linuxから更新する方法が全くない(検索すると、そういう恨みが沢山出て来たw) 安易にレベルの低い業者を選んでしまったのは、失敗だった。

それで、元となるDNSサーバを、無料のダイナミックDNSプロバイダに変更すれば良さそうなことが分かった。少し調べて、候補はDynuとFreeDNSとなった。FreeDNSの方が一般的のようだが、個人が運営しているようなので、不安を感じた。一方、Dynuはサイトの雰囲気が信頼性が高そうだったので、まずはそちらを試すことにした。なお、将来的にはDynuがサービスを有料化するとか止めるというリスクはあるが、その時はプロバイダを換えればいい。

基本動作を確認したあと、現在のドメインの設定(元となるDNSサーバ)にDynuのDNSサーバを設定をして、無事動いている。Dynuは今のところよりずっと使い易いので感心した。もちろん、Linuxのアプリもある。更に、IPアドレスの更新も瞬速で素晴らしい(これは、キャッシュ時間が短いだけのことかも知れない)。

しばらくこの状態で使ってみて、問題の有無を確認したい。その後は自宅サーバの構築(移築)かな。

それで、もしここにアクセスできなくなったら、お知らせ下さい。といっても、アクセスできない以上、連絡もできませんが・・・

最初にこれを書いた時点では、面倒なので余りやる気がなかったのだが、ちょっと始めてみたら結構おもしろくて、意外にはかどった。あくまでもテスト・評価用なので、いろいろいい加減なところはあるが、とりあえず、ブログ(WordPress)が動き、外部からアクセスできるようになった。

以前、少しの間、宅内でサーバを動かしていた時(2011年)にもあったのだが、DNSの関係で、最初は宅内LAN内の機器からテストサーバにアクセスすることができなかった。不思議に思われるだろうが、メインPCとテストサーバは同じLANに繋がっているのに、普通にやるとアクセスできないのだ。

なぜかというと、上にも書いたが、テストサーバのDNS情報のうち、IPアドレスは外部(インターネット)からアクセスできる値になっている。その実体は、ルータのインターネット側のIPアドレスである。また、サーバの名前(ホスト名)は、ここと同じように、blog.piulento.????.netといったものである。上に書いた、ダイナミックDNSの仕組みによって、ホスト名とIPアドレスがDNSサーバに登録されて、世界中に配布されている。

ここで、メインPCからテストサーバ(blog.piulento.????.net)にアクセスしようとする時、PCはDNSサーバからテストサーバのIPアドレスを得る。これは、外部からアクセスできる値(→ A)である。一方、テストサーバの本当のIPアドレスは宅内LAN内での値(→ B)になっているので、メインPCが(普通のインターネットサイトのつもりで)Aにアクセスしてもテストサーバには繋がらず、ルータの管理画面が出たりする。

前回はルータを2個使ってしのいだのだが、今回はそんな能のないことはやりたくなかったので、いろいろ調べたら、dnsmasqという、今回の用途にぴったりの簡易なDNSサーバソフトが見つかったので、それを使って解決した。

dnsmasqをテストサーバで動かし、宅内LAN内のPCやスマフォは、それをDNSサーバとして使う。dnsmasqは、通常は外部の通常のDNSサーバからの情報を返すが、指定したホストについては特別な値を返すことができる。今回はその機能を使って、宅内LAN内のホスト名に対しては宅内LAN内のIPアドレスを返すようにした。それで、ようやく、宅内からも外部からもテストサーバに接続できるようになった。

この方式の欠点は、テストサーバが止まると、宅内LAN内のPCやスマフォは全くインターネットにアクセスできなくなってしまうことだ(だから、テストサーバにはそれなりの信頼性や壊れにくさが要るし、使ってなくても停められない)。それが多少緩和できるかと思って、2番目のDNSサーバには普通のDNSサーバを設定してみた(実際には効果がないような気がする)。

その他にもいろいろ細かい問題があったが、「とりあえず」対処した。原因不明なこともあるので、TODOが多いw

テストサーバのブログが表示できるようになった。左のディスプレイ中の写真がブログ(メインPCのブラウザ)、右のディスプレイはテストサーバの画面。

なお、テストサーバの画面はリモートデスクトップ機能でメインPCに表示できるようにし、画面・キーボード・マウスの切り替えなしで操作できるようにした。一旦動けば、とても便利だ。

リソースはがら空きで、大変気持ちいい。例えば、メモリは500MB(全16GB)も使っていないし、ストレージ(SSD)だって20GB(全100GB)しか使ってない。クリーンインストール直後なのと、サーバなので、いろいろなアプリを入れていないせいだろう。

気になる点としては、筐体が小さいせいか、CPU温度が常に50℃前後(メインPCだと40℃前後)と高目なことだ。消費電力は、安いメーターを注文したので、届いてから測定する予定だ。

(7/21 11:42追記) エコチェッカー(リーベックス ET30D)が届いた。ヨドバシで千円程度と手頃だった。電流や電圧は測れないが、壊れない限り見ないから良しとした。あと、なぜか本体が少し汚れていたが、余り使わないので、ちゃんと動けば良しとした(もし再利用品だった場合には、寿命が短そうだが、交換なんて面倒だからいい)。

エコチェッカーで消費電力を測定

さっそく測定してみたら、16-17Wと、想定と大きな違いはなかった。17Wなら、年間の電気量は約3000円になる。1か月程度の平均消費電力を測ってみたい。

なお、電圧を補正した消費電力(15W)と1-2W違っていることから、電圧の測定値に意味がなかったか、電流の測定値も正しくなかったのかも知れない。

ひとまずブログが動きはしたが、この先は本当に面倒だ。ブログのさまざまな設定をしたり、コンテンツを入れたり、その他(例: カレンダー)のサーバを動かすといった作業がある。が、今どこまでやる意味があるのか、少し考えたい。とはいえ、時間はいくらでもあるので、手当たりしだいやっても問題はなさそうだ。

とりあえず、カレンダーやアドレス帳のサーバを入れて、実際にPCやスマフォと同期させて使い、性能や安定性や問題の有無などを確認することにした。カレンダーは僕には結構重要なので、自ら(まあ、他に居ないが)実験台になっていることになる。まあ、今は暇なので、多少予定がどこかに行ってしまっても大きな問題はないだろうw

カレンダーのデータを移すのはいつもながら手間取った。データ量が多いせいか、Thunderbird(Lightning)が落ちたり、スマフォアプリがうまく同期できなかったりで、何とかしたいが難しそうだ。

あとは、ブログのコンテンツを移してみたい。やっぱり、頻繁に使わないと評価にならないから、どうやって使うかが問題だ。あとは、投稿を現行のサーバから自動で同期させて、ミラーサーバーのようにしてみたい気がするが、これも面倒そうだ。でも、そういうプラグインとかがありそうな気がする。

(10:54 題の誤字他を修正・追記; 22:11 後半(最初の↓以降)、テストサーバが動き出すまでを追記; 7/20 16:16 2番目の↓以降を追記)

 

PS. ふと気付いた。これって、残り物で料理を作るみたいなものだと。昔、カレーだったか、「こんなところに牛肉が」とかいうCMがあったが、まさに、これのきっかけのひとつが、「こんなところにPCが」だった(暇つぶしにクローゼットを整理しようと見てたら、PCの箱が目に入った)のだw 残り物で料理を作れる方は大いに尊敬するが、サーバを作る人はどうだろうか?w (7/21 6:49)

  •   0
  •   0

日本人は礼儀もアップデートできていない。礼儀2.0世代が感じる「相手の時間を奪う」非効率なマナー」という記事を読み、全く同感だと思った。何度でも書くが、日本は遅れている。まだ時間の無駄遣いがいいと思っているのか。

苦笑したのは、VRエヴァンジェリスト(余談: 僕は、「エヴァンジェリスト」なんていう肩書が大嫌いだ) GOROmanという人の

(前略)
礼儀2.0
相手の時間を奪わないようにする(電話しない、リモートで済むものはリモート)

とか、記者の

「相手の時間を使わせるのが失礼」というマナーは、ミレニアル世代には遺伝子レベルでしっくりくる考え方だと改めて思った。

だった。いやいや、僕なんてバブル世代だけど、最初から(遺伝子レベルで?)「礼儀2.0」だったんですがw だから、電話なんて掛かって来たら、それだけでムカっとしていた(る)。(それはそれで問題だが・・・) あとは、カタログ請求した程度で、大した情報もなしにのこのこ「挨拶に」来る営業も大嫌いだった。時間ばかり食って全く逆効果だ。他には、展示会なんて、多くの場合、行くのも出すのも時間と体力の無駄だと思って来た(でも、行け・出せと命令されれば、そうするしかなかった)。会場にのこのこ行かずに(リモートで)済めば・済むようにすればいいではないか。

電話についての僕の言い分はこうだ: 仕事なら、まず論理的に、理路整然とこちらの話を伝える必要がある。そして、お互いに記録も残すべきだと考える。そうすると、電話のメリットなんてないに等しい。受ける側は、仕事を中断させられ、(大抵、要点のはっきりしない長々とした)話を聞いて、自分でメモして、その場で対応を考えて返答しなければならない。多くの場合、会話は論理的でも理路整然ともしていないので、あとから誤解や問題に気付くことがある。全く時間の無駄だ!

これがメールなら、一石五鳥くらいだ。事前に推敲するから、論理的・理路整然とするし(しかも、書く時に自分の認識不足や誤りに気付くことがある)、メールは記録そのものだし、仕事を中断しなくて済むし、対応は自分のペースで考えられるし、誤解や問題の有無について充分に考えることができる。ものすごく効率的だ。

とは言え、相手が遅れた連中(例: 丁寧さは 対面 > 電話 >> メール と思っている)とか、日本語が読めない連中(驚くべきことに、書いたことと逆に受け取る人が本当に居る! そういう人に、改めて書いたままを話すと、なぜか理解される。。。)だと、途端にメールの効力が失われるから、とても歯がゆい。

余談: 僕は、メールが出る前から電話は使わないようにしていた。その頃は、可能な限り、葉書や手紙を書いていた。文章の方が確実にこちらの意図が伝わる(気がした)し、妙に神経を遣う(ドキドキする)必要がないので楽だったのだ。今だって、メールが使えない相手には手紙を書くだろう。要は、遺伝子レベルで会話が苦手なのだw

まあ、でも、会社の連中はまだまだ礼儀1.0で、例えば、「メールしてから電話する」なんていう、「えぇ、江戸時代ですか?」wっていうのが多いから、世の中はようやく2.0になりつつあるのだろう。いいことだが、僕にはちょっと遅すぎた。

  •   0
  •   0

近頃は、無駄に名前にこだわりすぎたり、名前を付ける意味を理解していない連中が多くて嘆かわしい。

  • 古の 。 に始まって、 、 や . や , とかの句読点を一般的な意味なく名前の最後に付けるアホ。なんか意味あるのかねえ? (本人はあると思っているから付けるのだろうけど、本当に意味はあるの?) 。が出た当時ならおもしろかったけど、さすがにもう古いと思う。 ★とかの記号もあるし(こっちの方がまだ納得できる)、そのうち、昔のツェッペリンのように、絵文字も出そうだ(って、前に書いた気もする)。今は、Unicodeでとんでもない数の記号が使えるからいいねw 逆に、これだけ文字が豊富な世の中にわざわざ , なんて使う人の気が知れない。余程愛着があるのか。
    • それにしても、 , なんて、コンピュータで処理するには面倒な気がする(CSVの区切りと競合する)。まあ、ちゃんとしたシステムなら問題ないだろうし、TVや新聞・雑誌などは全角で処理しているかも知れないから、問題なさそうだ。
    • 個人的には末尾に を付けて欲しい。誰も分からないだろう。あ、全部空白だったら最高だw
  • 記号でなくても、西暦の数を名前の最後に付ける馬鹿なグループも居る。それでは名前の意味がないでしょう。毎年元日にメンバーチェンジするのか? そのうち、毎月変えたりしてw でも、日本の月の名前(例: 「如月」)だったら、雰囲気はいいと思う。
  • "Fall creators update"とかRSとかその他覚えられないほど多くの、Windows 10のリリースの名前・識別記号(今は"April 2018 Update"が最新?)。それ以外にリビジョン番号もあるし(彼ら自身は"Windows 10 バージョン 1803"などと呼んでいる。バージョンは10じゃなかったのか??)、パッチの番号もある。「Windowsは10が最後で、もうバージョンは変えない」とか言っていたが、出鱈目ではないか?
  • プロセッサやOSの名前も数多い。まあ、その辺りは節操がないとまでは言えないから、まだ許せる。でも、なんで、地名とか動物とかお菓子とかのシリーズに揃え続けるのかな。それだと新鮮味がないから、その時々でチームがおもしろいと思った物を使えばいい気がする。素数を2から順に付けるのもおもしろそうだ(以前あった気がする?)。
  • あと、林檎社謹製腕時計の"Edition"なるものには笑った(というか嘆息した)。Editionという言葉には単なる「版」という意味しかないと思うのだが、ネイティブには「特別」とか「高級」とかの雰囲気が伝わるのだろうか。いずれにしたって、"Apple Watch Edition"という名前はなんかおかしいと思う。WatchとEditionの間に何か入れるべきだと思うが、違うのだろうか。
  • 最後に、空港のようなアルファベット3文字(または地名みたいなの)+数字(この数字に意味はあるのか?)の○製×造グループに至っては、もう「極まれり」で何も言うことがないw

とはいえ、上を見ても分かるように、僕も名前で遊びたいのでw、結論としては、名前は各自が楽しんで好きに付ければいいけど(子どもの名前とかは別)、ある程度のセンスは必要だと思う。

  •   1
  •   0