Archive for the ‘Linux’ Category

Spotifyの再生履歴記録・検索システム(仮)が大分できて来た。まだまだやりたいことは多いし、修正・改良すべき点も多いが、一段落した感じだ。

見た目が前回とほとんど変わらないのが残念だがw、7割くらいはできた気がする。それにしても、いつものことだが、体感で半分を超えると、ぐっと進みが遅くなる。できあがるにつれて、完成度を高めるために作業量が増えるうえに、動き出して使ってみると新しいアイデアが出てくるので、更に作る量が増え、そのために修正や動作確認をする時間も雪だるま式に増えて、逃げ水のようにゴールが遠くなる。

前回からいろいろやったのだが、見た目のインパクトが大きいものは、ボタン一発でSpotifyの再生履歴が出せるようになったことだろうか。前回は再生中の曲だけだったのを、(DBのコマンドを駆使して)指定した数の過去に再生した曲を取れるようにした。もちろんSpotifyアプリでも出るが、自分で作ったので随分使いやすい。例えば、評価やコメントをあとから手軽に書けるようになった。他には、webなので、タイトルなどをコピーできるのは誰にでも便利な気がする(もちろん、web版Spotifyでもできるが)。

あとは「できたてのほやほや」(でまだ満足に動かないw)のアルバム表示機能も便利だ。検索結果や再生履歴に表示されている曲のアルバム名をクリックすると、そのアルバムの曲が全部表示される(書くと当たり前の機能ではあるな・・・)。他に、Spotifyのアルバムやトラックへのリンクも表示するようにしたので、日記やブログで参照するのも楽になりそうだ(ミニプレーヤーでは簡単だが、アプリだとメニューを数段階移動しないと取れない)。

逆に、苦労して作ったけど意外に使っていないのは再生機能だ。これはアプリで充分だ。でも、そのうち検索機能(これが一番の目的なのだ)が充実したら使うかも知れない。

そして、今日の夕方くらいから、聴きながらコメントや評価を付けたり過去の感想を転記したりして、実際に使っている。自画自賛だが、なかなか便利だ。最初はそれらはDB管理アプリ(DB browser)で入力・修正していたのだが、段々使う機会が減って来た。

残件で大きいのは、ミニプレーヤーとの連携(履歴や評価のアイコンを出す、手軽に履歴を付ける、コメントを書くなど)だ。それから検索のプリセットの作成(今は検索条件にSQLの一部を打ち込んでいるのを、いくつかのパターンから選べるようにする)だ。

作っていて思い付いたのは、Spotifyのリコメンドでない、「自分のリコメンド」(履歴と評価をもとに、自分の好きな曲だけを選んで掛ける)を再生できるとおもしろそうだ。そこまでは行かなくても、意味があるかは別として、このシステムに自分のプレイリストが作れる。将来、別のプレーヤー(gmusicbrowser)とも連携できたら、プレーヤーをまたいで再生できるようになるからおもしろそうだ。

もう一つのアイデアは、嫌いな曲が掛かったら即座に自動で飛ばす機能だ。これはすごく便利そうだw ただ、たまに気まぐれで聴きたい時もあるだろうから、ある程度の猶予時間が要りそうだ。

ちなみに、このシステムを作ろうとしたのは、Spotifyをより便利にしたいこともあるが、自分の再生履歴や感想を記録するためでもある。だから、Spotifyに特化したものやべったり依存するものを作ろうとしている訳ではない。仮に将来、Spotify以外のサービスに乗り換えたとしても、記録した情報は使いまわせるようなデータ構造にしている。ただ、そのサービスにSpotifyのようなAPIがないと、再生した曲の自動記録はできないので、そこが結構重要だ。更に、配信サービスを止めたとしても、いいと思った曲の記録は残っているから、買うなどすれば聴くことができる(DBにはそれぞれの曲のISRCを記録しているので、何らかの形で配布されていれば、その演奏が聴けるはずだ)。

なお、最初に少し心配していたDBのサイズだが、文字しか入れていないので当然ではあるが、とても小さい。今までの約2週間で940曲くらい記録したが、DBファイルのサイズは320KB程度なので、1曲あたり300バイト前後だ。ずっとこのペースで行くとすれば、1年では2.5万曲くらいになり、サイズは7MB程度で済みそうだ。なお、定期的にバックアップや"vacuum"というコンパクト化の処理も行うようにした。

 

PS. 作っていて思ったが、Googleなどのサーバには、こんな感じで、各ユーザのいろいろな履歴がまさに山のように記録されていて、すごいAIがあれば(きっとあるんだろう)何でも分かってしまいそうだ。技術的にはおもしろいけど、僕はなるべく"Let me out"させてもらいたいw

でも、それとは関係ないけど、Googleの画面作り(配色・配置)は嫌いじゃないw このシステムのwebページの雰囲気が似ているのは、そのせい(好みの近さ)かも知れない。特に似せているつもりはないが。そして、ダークモードは大嫌いだw

  •   1
  •   0

あれから寝食を忘れてw作っていて、web(検索画面)が大分いい感じになって来た。何をどう良くしたのか、思い出したり調べて書くのも面倒だが、僕的には随分良くなった気がするw 例えば、評価を色の濃さで出す(図中の♥マーク)とか、平均「完奏率」(最後まで聞いたか)※を棒グラフで出すとか、前の投稿に書いたが、再生をwebでなくSpotifyプレーヤーでできるようにしたとか、トラック情報を開閉できるようにした辺りだ。まだまだやることは多いが、それなりの形にはなって来た。

※「「完奏率」(最後まで聞いたか)」は少し誤解しやすいので補足すると、1曲を最後まで聴いたら1、途中で止めたり飛ばしたら0なのではなく、止めたり飛ばした時点までの再生時間の曲の長さに対する割合が1回の完奏率になる。例えば、半分まで聴いたら0.5である。その合計を再生回数で割ったものが平均完奏率である。

プログラミングしていると時間がすぐ過ぎるし、おやつはもちろん食事も面倒になるから、ダイエットになるうえにお金も掛からないおから、いいことづくめだね。ってなんか、シャレにならないけど、そんなことはないよw これからの人は、みんなプログラミングするみたいだから、メタボになる心配はなさそうだね。頑張ってね!(爆)

(5/19 20:58) その後もいろいろ改良していたが、見た目は劇的には変わっていない。Spotifyは、どうしてか、クラシック音楽の作曲者をアーティストに入れてしまうので、ミニプレーヤーでしているのと同様に削除するようにしたことと、「現在再生中の曲」をボタン一発で出せるようになった(の中央上部の"Now playing")のと、評価をスライダーで設定する(図の右下)UIができたくらいだ。もちろん、普段はスライダーは出ていないし、評価を変えたらアイコンも色も変わるよ!w (→ デモ動画)。HTML5のおかげで、こういうの(inputのrangeというのを使った)が手軽に(とはいえ、何度も書くが、HTMLだのJavaScriptは苦手なのでそれなりに苦労したがw)できるようになってありがたい。

今は、コメント欄もトラック情報や評価と同様にアイコン(ボタン)を押すと開いて入力できるようにしようとしているのだが、UIの概形ができたところで力尽きているw 不思議なことに、余り考えずに「これだとどうなるかな」とテキトーに作ったら、「こうなったらいいね」っていう感じに入力欄が開いたので、何かの奇跡かと驚いた。 ← イマココ(ってやつ)w

 

体験談的なことを書くと、SQLはなかなか馬鹿にできない。なんというか、僕から見れば「しょうもないもの」だったのだが、ちゃんと完結していて、(苦労して)使いこなすとかなりいろいろな検索や処理ができることが分かった。DBの基本のトランザクション※も便利だ(普通にプログラムを作るのでは実現が面倒なことが、1行でできたりする)。どういう経緯で今の状態に至ったのかは知らないが、最初からこういうのを考えて作ったのならすごいことだ。ただ、今使っているSQLiteはとっつき安いのはすごくいいものの、他に比べて若干機能が少ないので、凝ったことをしようとすると手間が増えるのが残念だ。

※トランザクションの例: 「DB中の、名前がAのデータの要素bの値が10より小さかったら+1して書き込む」が1行でできる。しかも、この1行(SQL)の処理は不可分なので、複数プロセス間での競合が起こらない。あるプロセスが読み出して+1して書き込む前に他のプロセスが+1して書き込んでしまうなんてことがない。

あと、以前も書いた気がするが、PHPとJavaScriptとHTMLを同じファイルに書くので、ちょっと見てもなんだか分からないし、それぞれ文法が違うからいつも間違うし、その部分がいつ実行されるのかを誤解するし、文字列を囲むレベルが増え過ぎて囲むのに使える文字がなくなったりして、かなり厄介だ。一番不便なのは、JavaScriptからPHPの機能が呼べない(あるいは、戻れない)ことだ。よく考えれば当たり前(実際には、PHPからJavaScriptを呼ぶことだってできない)なのだが、そこが何とかできると楽になると思う・・・ だから、サーバ側も全部JavaScriptで書く例が増えているのかも知れない(ここはよく分からない)。

(5/20 22:09) コメントのUIも何とかなった。(→ デモ動画) 昨日から何も変わってないように見えるが、見た目を変えてないから当然だw あとはやっつけ仕事で作った下回りの処理(DBへのアクセス)などをちゃんとしたい。

コメント設定機能も動き出した。

 

それから、SQLiteへのネット経由でのアクセスは、rqliteというもので可能なようなことが分かった。その他に、socatとsqlite3コマンドを使って自分で実現することも考えられた。後者は全く面倒で安定性に欠けるから論外だが、前者は何となく筋が良さそうだった。が、他にも同様に「自分」に通信する必要があるもの(例: Spotifyでの再生)があるので、ひとまず保留にした。

 

(5/17 21:00 完奏率について補足; 5/19 20:58 現状を追記; 5/20 22:09 現状を追記)

  •   0
  •   0

先日から始めた、Spotifyで聴いた曲を自動で記録し、検索結果と一緒に表示する仕組み(一言で何と言うのか、まだ迷っている)のプロトタイプが動き出した。画面(web)は以下のような感じだ。プロトタイプなので、トップは太古の「ホームページ」wのように、余りにもシンプルだ。検索結果は少し(結構)凝って、(力技でw)それなりにした(まだ細かい問題は多い)。

もちろん、主目的の再生履歴が出るようにした。再生した日時(自動で記録される)はもちろん(今は最初の日時のみ)、評価(今はDBに手入力する)が♥(好き)や✘(嫌い)で出るし、コメントも出る(これも今は手入力)。そして、ジャケット画像やアルバムや曲のリンクを押すと、ちゃんと再生できる(今はまだSpotifyのwebプレーヤーに飛ぶだけ → Spotifyのプレーヤーアプリで再生できるようになった → デモ動画)。

全体的な構成の概要は以下のとおりである。

Spotifyプレーヤーミニプレーヤー・リモコン
 ↑                         制御                |
 |                                               ↓
 |        再生曲情報の自動記録 ← (再生曲情報ファイル)
 |再生         ↑↓
 |指示   DB (SQLite)
 |          ↓再生履歴
検索画面(web)  ⇔  Spotifyサイト
                     検索(API)

検索条件の指定方法は模索中だ。今は、Spotifyの条件(これが結構使えない・・・)と再生履歴の条件を別にしている。後者は、なんとSQLの条件式を入れるようにしている(画面上部の"History search"の欄を参照)。今はこの方がいろいろ試せるからいいのだが、将来的には「再生したことがない」/「−ある」といった、プリセットのようなものを選択できるようにしたい(画面中の式は「再生したことがあるアルバム中のトラック」の例)。

RDBのSQLにはなかなか苦労したが、大分使えるようになった。慣れれば便利な感じだ。でも、泥沼のように奥が深いようだw それ以外にも山ほど考え・試行錯誤・工夫・苦労した話があるし、「とりあえず」や"TODO"も山ほどあるwので、あとで書きたい。まずは作るだ。

その後、大分改良できた。検索結果が多い場合に画面がとんでもないことになるので、どうしたらいいものか考え、(良く見るが)開閉ボタンでアルバム中のトラック情報を表示・非表示できるようにした。アルバム情報の下の"♪"を押すとトラック情報一覧が出て、再度押すと消える。(→ デモ動画)

やる前は、大の苦手なJavaScriptを使うのが嫌なので、何とか別の方法がないか考えていたのだが、なかなかなくてJavaScriptでやらざるを得なくなった。もちろん、(僕の技術で)できるのか分からなかったが、その前に検索ページからSpotifyプレーヤーで曲を再生するために使った方法(なかなかトリッキーなので、あとで書きたい)がヒントになったので、意外に容易に「それなり」にできた。

こういうのは、世の中に出回っているいろいろなライブラリを使えば簡単なのだとは思うが、そもそも、何が一番使いやすいのかも分からず、選んで使うのに慣れるまでが大変な(気がする)ので、自分で「適当に」作った。きっと、どこかに落とし穴があるに違いないw (5/15 17:32)

 

(23:51 システム構成を追記; 5/15 10:40 Spotifyプレーヤーでの再生のデモ動画を追加; 5/15 17:32 トラック情報表示の件を追記)

  •   0
  •   0

先日、母がモーツァルトの曲を聴いてみたい※というので、CD-Rに焼いた。手持ちのは仕舞ってあるだけなので、最初は実物を貸そうと思っていたのだが、手荒に扱われると嫌だし、母にしたって気軽に扱える方が良さそうだからとバックアップした。

※「聴いてみたい」と言ったって、音楽の話題になった時に、僕が「CDがいっぱいあるから貸そうか」と言ったからで、あとで帰省したら、送った時の袋に入ったまま放置されているのを見てがっかりするような気がするので、(送料だサイズだで)結構苦労して梱包している時に「僕は何を無駄なことをしているんだ」と思った。が、万に一つでも聴かれる可能性も捨てきれない。が、例え聴かれたとしても、感想は例によって「すごいね。良く指が動くね。楽譜見ないで良く弾けるね」程度なので、やっぱり労には合わないだろう。とはいえ、それでも聴いてもらうのは悪いことではない。もしかしたら、母がモーツァルトの良さに目覚める可能性も0ではないから・・・

ちなみに、モーツァルトや(どうしてか、)日本人の有名なピアニストの話題が発端だったので、以下の曲の入っているアルバムにした。予想では、アイネ・クライネが(一番ポピュラーなので、)一番受ける気がしている。僕としては、もちろんK. 488を推すのだがw

    • 内田: ピアノ・ソナタ集 (K. 333, 545など) (1984-1986)
    • ポリーニ: ピアノ協奏曲 第23番 (K. 488) (1976)
    • ベーム: アイネ・クライネ・ナハトムジーク (1977)

一応、焼いたものが(ちゃんと「普通のCD」になっているか不安があるので)再生できることを確認しようとしたのだが、いざとなると、なかなかいいプレーヤーがない(そもそも、「今、PCでCDを再生する人なんて居るのかっ?」てくらいだw)。CDプレーヤーなんて随分昔から持ってないし、手持ちのラジカセではCDは再生できないし、Linuxに標準で入っていたSMPlayerはバッファリング中は再生が停まるから曲間が余計に開くし、MediaPlayerは動画専用のようだし、(全く問題ないだろうと思っていた)VLCはなぜか音が途切れることがある。参照用とか予備で入れているClementineは、いつもながらイマイチだった(もう消そうかな)。そして、いつも使っているgmusicbrowserではCDは再生できない。

前回別件で焼いた時は、MPlayerとカーナビのオーディオで試した覚えがあるが、さすがに車は面倒だ。そこで、検索していくつかのアプリを試してみた。以下にその一覧と評価(CD再生に関してのみ)を書く。

  • △ DeaDbeef: 開始する時に頭が飛ぶことあり。
  • △ Audacious: UI・操作が若干煩雑。
  • △- Quod Libet: UIがイマイチ。ジャンプが簡単にできない。
  • × Aqualung: 2ウインドウで煩雑。UIがイマイチで使いにくい。CDが高速で回転してうるさい。
  • △- Banshee: 古い(2011)。ジャンプがイマイチ。
  • × Rhythmbox: 大掛かり。CDがCDDBに見つからないと、いちいちメッセージを出して鬱陶しい。再生が手軽でない(いちいちキューに追加する必要あり)。
  • × Exaile, JuK, Kaffeine, Amarok, Musique: 駄目・論外 (まともに動かない・すごく使いにくいなど)

結局、AudaciousかDeaDbeefが良さそうなので、Audaciousで確認し、その二つを残した。でも、次はいつ使うことか? (万が一、母が「別の曲も聴きたい」と言って来たら喜んで焼くが、まずないだろうな・・・ ただ、文中に2回出て来た「1万分の1」を合わせると、確か1億分の1だから、宝くじに当たるようなものだw)

  •   0
  •   0

先日作った、Androidスマフォの画像をLinuxPCにWi-Fiで取り込むプログラム(システム)だが、その後、使ったり試行錯誤したり考えたりしているうちにいろいろアイデアが浮かんで、(まだ細かい確認・調整点はあるものの)最初の要望どおり、以下のようにできた。

スマフォをPCに繋がなくても、操作なしで自動的にPCに画像が取り込まれる

それまで難しいと思っていたのは、元々の要望の重要な点とか使い方とか全体としての流れを整理し切れていなかったからだと思う。

僕の使い方と期待する動作を整理すると、以下のようになる。

  1. 外でスマフォで撮影したり画面をキャプチャして帰宅したら、それほど待たずに(家のWi-Fiに繋がった頃に)PCに画像が取り込まれている。
  2. 家でスマフォで撮影や画面をキャプチャしたあと、そのまま置いておけば(それほど待たずに)PCに画像が取り込まれている。

1は既に前回できた(Wi-Fiの再接続を契機に転送を開始する)。2は、前回はいつ転送(するかどうかのチェック)を始めればいいかの判断をすればいいのか分からなかった。そこで、更に具体的に使い方の流れを考えると、以下になる。

  1. スマフォで撮影やキャプチャする。
  2. 画面をoffにする。

そして、画面がoffになった(→ スマフォがアイドル(使っていない)状態になった)のを契機に処理を開始すれば良いことに気付き、実装した。かなり手こずったが、概ねうまく動くようになった。処理の流れの概要は以下である。

  • スマフォ
    1. スマフォがアイドル状態になったことを検知する。
      1. 画面がoffになるのを待つ。
      2. 数分後(例: 5分)にタイマーがイベントを出すように設定する。
    2. タイマーイベントを待つ。
    3. 前回の転送終了時刻より新しいファイルを探す。
    4. 新しいファイルがあれば、PCに転送開始要求を出す。
  • PC: スマフォから新しいファイルを取得する。

以下に難しかったことを書く。

アイドル(スマフォを使っていない)状態の検出

画面がoffになってすぐ転送を行うと、例えば、画面のタイムアウトで暗くなったなどで、また画面をonにして使い出して画像を追加する可能性があるから無駄である(無意味ではないが、まだ作業が終わっていないものを転送する可能性があるし、新規ファイルのチェックや転送(通信)の回数はなるべく減らす方が良い)。そこで、スマフォがアイドル状態であることを検知して転送を行うことにした。

アイドル状態は、一定時間(例: 5分間)画面がoffになっていることで判定するようにした。また、その時間より早く画面がonになったら、アイドル状態でないとして処理を打ち切る(「なかったこと」にする)。具体的には、画面がoffになった時にタイマーを設定し、タイマーの期限が来たらアイドルとし、それより前に画面がonになったら、(アイドルでないとして)タイマーを解除する。

なお、スリープ中はSSHDroidがうまく動かない(スマフォが完全にスリープしている訳ではないが、SSHDroidがスリープしているようだ)ので、スリープを解除するために画面をonにするのだが、その後の画面offもアイドルの開始と判定してしまう問題があるので、自分で画面をonにした場合には少しの間(例: 30秒間)画面offを無視するようにした。なお、なぜか、自分(このプログラム)で画面をonにした場合には、画面onのイベントは起こらないようだ(将来問題になりそうなので、再確認が要りそうだ)。

「前回の転送終了時刻」の取得

スマフォはPCに(「新しいファイルがあるよ」と)転送開始要求を出すだけで、実際の転送はPCが行うため、PCが本当にファイルを取得したか・できたかは基本的には分からない。しかし、転送に使っているrsyncコマンドはリモート(この場合、スマフォ)に転送のログを書くことができるので、その機能を使うことにした(これは邪道なやり方なのだが、一応、rsyncの機能しか使っていないので、許すことにした)。転送が成功しているとすれば、ログの更新時刻=転送終了時刻なので、新規ファイルの検索に手軽に使える(転送中に画像を作成するなどして食い違いが生じる可能性もあるが、その前にアイドル(放置)状態であることを確認しているので、余りなさそうだ)。

なお、ログから転送が成功したかどうかの判定をして、失敗していたら適切に処理すべきだが、今はいつも成功したとみなしている。そのため、何らかの原因でエラーが起こった場合、転送アイコンを押して(手動で)取得する必要がある。 → ログ中のエラーから失敗を判定する処理を追加した。失敗した場合、下記のログファイルの削除を行わないようにすることで、次回も今回と同じファイルから転送する。ただ、それでうまくいくかは疑問で、通知などが要る気がする。 (3/10 7:20)

また、rsyncのログファイルは毎回追記されるので、サイズが増大するのを防ぐため、転送開始要求を出す前に削除(実際にはrename)している。

 

以上により、基本的には、定期的な新規ファイルのチェックが不要になった(一応、保険として1時間に1回するようにはしている。ただ、アイコンを押せば手動でできるので、そこまでする必要はないのだが・・・ ← 忘れていたが、自動転送要求する時にPCが起動していなかった場合のリトライ用に有用だった(3/10 14:46))。それに加え、前回追加した、PCから最新のファイル名を取得する処理(通信)も不要になり(= 再び転送開始要求だけになった)、電池消費量が(更に?)減ったはずで※、なかなか気分がいい。

※ 8時間のアイドル時の消費電力量は0.4%/hだった。これは先日できたWi-Fiの再接続処理の低い時と同じ値なので、このプログラムの待ち受け時の消費電力は無視できる程度と考えられる。 (3/10 7:29)

そして、結果的にスマフォの転送開始アイコンもPCの状態表示ウインドウも不要になってしまった(後者は、使用中に勝手に出ると邪魔なので、エラー発生時以外は出さないようにしているため)。

 

作った画像転送システムを実際に使っていると、今までは余り興味がなくて魅力を感じていなかった無線や非接触通信がかなり便利に感じる。ケーブルをつながなくていいから手間が省けるし、机の周りがごちゃごちゃしなくて済む(でも、イヤフォンは御免だw)。それで、デジカメの画像もWi-Fiで取り込みたい気分が起こって来た。ちょっと調べたら、FlashAirがなかなかおもしろそうだ。ただ、電池消費量が増えるという情報があるし、そもそもそこまでする必要があるのか(スマフォはあるものでできたから手軽に始められたけど、デジカメだと追加の物が要るのでお金が掛かる)甚だ疑問なので、良く考えたい。

あと、スマフォの充電も非接触にして可能な限りケーブルを排除したいのだが、本体が対応していないので無理そうだ(これもいろいろあるんだろうけど・・・)。

 

PS. 少し話が飛ぶが、日本のメーカーは、ユーザーの要望の真意とか実際に使う手順とかをちゃんと見極めずに、「できるから」、「高機能なら売れる」と思い込んで作り込んでしまったために、機能はてんこ盛りだけど使えない家電とかばかりになってしまったのではないだろうか。挙句の果てに、高いうえに使いにくいから売れずに海外のライバルに負けてしまったという、踏んだり蹴ったり状態だ・・・

PS2. (節操なく宗旨替えするようだがw、)この無線・非接触の時代に、USBは4なんてやり出して、全く理解できない。まあ、あってもいいけど、そこまで高速なのが要るのだろうか。それより、昔諦めたWireless USBを復活させればいいと思うのに。ただ、あれ自体はUWBを使うなんて先進的過ぎて失敗したので、もっと「普通に」やればいいと思うが、そうできないからああなったのだろうか? だったらWi-Fiとかを使えばいいってことだろうか?

(3/10 7:58 加筆・修正)

  •   0
  •   0

ずっとやりたかったけど、面倒で見送っていたことができた。スマフォなどのケーブルが何本も(充電用とPC接続用、他にデジカメ用も)あって見苦しいし、注意しないと間違えるのが嫌になったのだ。しかも、スマフォをPCに繋いでも、いちいち画面で画像転送(PTP)を選ぶ必要がある※のも、イライラを増していた。

※検索すると、この選択は開発者ツールを使えば固定できるようなのだが、なぜか、再起動か何かのたびにリセットされて、いつも選ぶ羽目になっていた。AQUOSの仕様なのだろうか?

やりたかったのは以下のようなことだ。

  • スマフォをPCに繋がなくても、操作なしで自動的にPCに画像が取り込まれる。
  • USBで繋いだ時と全く同じように取り込まれる。
    • 新規画像(例: 前回の取り込み以降に撮影されたもの)画像だけが取り込まれる。
    • 画像は年月日ごとのディレクトリ(例: 2019/2019_01-03/2019_03_04)に仕訳けされる。
    • 画像のファイル名にはカメラ(スマフォ)・トップディレクトリ(例: DCIM/102SHARP)固有のIDが追加される(例: DSC_0301_2345987612.JPG)。
      • カメラ間・カメラ内のファイル名の競合を防ぐため。
    • ファイルの更新時刻が撮影時刻になる。
      • PNGなど、タグのないファイルでも並び順を揃えたいので。
    • 新しい画像であることを示すタグ(例: Subject="New")が付く。
      • ファイルを自動で仕訳けするために画像の場所が分散するので、あちこち探さなくても一目で新規画像を分かるようにするため。

そして、なぜか数日前(調べたら、3/2からだった。簡単にできそうなアイデア(後述の、マウントしてtarコマンドでコピー)が浮かんだので始めたのだった。本当に、「寝食を忘れて」熱中・集中していたので、結構疲れた)からやる気が出て実装し、以下のような感じで動くようになった。

  • スマフォをPCに繋がなくても、スマフォのアイコン(実体はウィジェット)を押すとPCに画像が取り込まれる。
  • USBで繋いだ時と全く同じように取り込まれる。

上に書いたように、操作なしにしたかったのだが、いくつかの問題があるので、今は保留している。 (→ その後改良して、概ね操作なしでできるようになった。: 3/9 12:09)

  • 使っているサーバソフト(SSHDroid)の仕様なのか、画面offの状態では、そのサーバが停止(スリープ?)するために、PCから接続できない。接続していても、画面offになってしばらくすると切れる。
    • → サーバを起動するために画面をonにするのなら、ロック解除してアイコンを押すのはそれほど手間ではない。
  • 仮に常時接続できるようにしても、定期的にPCから新規画像のチェックをするのは効率が悪い(画像が増えることはそれほど頻繁でないので)。頻繁にチェックすると電池を食うし、チェック間隔を長くすると不便だ。
    • → 画像が増えたら、スマフォがPCに通知するようにすれば良さそう。[今後の課題]

なお、PCからも取り込みを開始することができるのだが(最初はそうした)、上記のように、取り込み前に自分でスマフォの画面をonにする必要があるから余り便利でないことに気付き、スマフォから開始できるようにした。

スマフォとPCの画面が写った動画でないと全くおもしろくない(さすがに撮影する気は起こらないw)のだが、以下のように、スマフォのエクスポート(あるいはアップロード・同期)アイコンを押すと、PCで取り込みプログラムが起動し、取り込みウインドウに取り込みの経過が表示され、新規画像が取り込まれる。自画自賛だが、なかなか便利だ。例えば、スマフォで撮影したらアイコンを押すだけでPCに入れられるのはすごくいい(今までだったら、ケーブルを繋ぐかDropboxに入れるなど、結構面倒だった)。今気付いたが、家の中ならどこにいても転送できるはずだ(それに価値があるかは別としてw)。

こういうアプリなり仕組みは既にあるが、いろいろ探してもどうも僕の要望には今ひとつ合わないので(同様な理由でUSBでの取り込みプログラムも自分で作ったので、まず合いようがない)、自分で作った。あと、今はスマフォからクラウドに直接自動的にアップロードするのが主流だが、やっぱり使いにくいし、モバイルデータ量も増大するかも知れないし、そもそも、提供者の都合で仕様が変わったり有料になったり終了になる可能性があるので、なるべく使わないことにしている。

と、さらっと書いたが、中ではなかなかいろいろなことをやっているので、以下に細かい話を書く。

スマフォからの画像取り込み

基本的には、今までのUSB(PTP)での画像取り込みプログラム(の枠とでもいうもの)を使っている。ただ、今回のネットワーク対応ためにかなり追加・変更した箇所がある。

転送の仕組みは、最初は、sshfsなどでPCからスマフォのファイルシステムをマウントし、ファイル一覧を取得し、新規ファイルを抽出してtarコマンドでコピーすることを考えたが、rsyncコマンドの方が便利そうだったので、それを使うことにした。特に、rsyncはマウント不要(自動でスマフォ側のプログラムを起動する)なのが良かった。

スマフォのファイルシステムは大きく、毎回スキャンするのは得策でないから、PCでは新規ファイルの抽出はせず、取り込み済みファイル一覧から除外ファイル一覧を作ってrsyncに指定することにした。実際には、スマフォ内でrsyncによるスキャンは行われるが、PCからNW経由でやるよりは良さそうだ。除外ファイルサイズが大きくなって重くなるのが気になるが、今のところ、デジカメも含む全ファイル一覧(画像数: 8千以上)でさえ300KB未満なので、大きな問題はなさそうだ。

画像取り込みの開始

前述のとおり、最初はPCのプログラムで取り込みを開始するようにしたが、その前にスマフォの画面をonにする必要があって不便なので、スマフォのアイコンで開始できるようにした。

そうするにはいろいろな方法が考えられるが、手軽に作るためにAutomagicを使うことにした。Automagicで可能なのは、Wake on LANパケットの送信、HTTPアクセス、FTPアクセスなどだった。Wake on LANは手軽でいいのだが、ユーザのデータが送れないので、HTTPにしてみた。

なお、AutomagicからOSのコマンドを実行することもでき、ncコマンドもあるのだが、UDPの送信ができない(セキュリティの制限か、エラーになる)ので、諦めた。あと、そもそも、Automagicから実行できるコマンドのパスがシェルとは違っているために実行できない問題もあった。

これだけのためにPCでHTTPサーバを動かすのはもったいないので、socatコマンドで擬似的なHTTPサーバを作って待ち受けることにした。「サーバ」といってもまったく大したことはなく、「のようなもの」だ。基本的なコマンドは以下のような感じで、たった1行(長いので折り返した)で済むものだ。

echo -e "HTTP/1.0 200 OK\r\n\r\nHello!" |
  socat -d TCP-LISTEN:2345,reuseaddr - | hexdump -C

AutomagicからPCのTCPポート2345にアクセスすると(URLの例: http://192.168.1.2:2345)、PCでその要求がダンプされる(→ 要求が来たことが分かる)。また、スマフォ(Automagic)には"Hello!"という文字列が返るので、PCからの応答も分かる。

あと、ものすごく簡単な不正アクセス対策として、Automagicから要求を出す時に、ヘッダに「何か」(普通はない情報、合言葉のようなもの)を追加すると、何もしないよりはよい。そもそも、外部からのアクセスはルータで遮断されるので、外部からPCへのHTTPアクセスは来ない前提だし、PCはデスクトップなので持ち歩かないから、今はこれでいいと思う。それから、Wake on LANは間違って宅内の他の機器から出る可能性があり、ブロードキャストなので宛先で受信制限ができず、上記のようにユーザのデータは送れなくて正当性のチェックができないという点でも、HTTPの方が少し良さそうだ。

スマフォの個体の識別

前述のように、画像のファイル名にはカメラ(スマフォ)・トップディレクトリ固有のIDを追加する。そのIDは、カメラ情報(メーカー、機種、SN)から生成するのだが、当然、NW経由ではそれらは取得できない(スマフォのコマンドを使うとできるかも知れないが、仕組みを特定のOS・機種に依存させたくないので、止めた)。

そこで、スマフォのMACアドレス(HWアドレス)を使うことにした。MACアドレスはその個体に固有で変わることがないので、IDとしては良い。ただ、USBで取り込んだ時とネットワーク経由の時でIDが異なると、別の接続では取り込み済みファイル一覧が異なるため、新規ファイルが異なって、重複して取り込まれてしまうので、画像取り込み開始プログラムで、MACアドレスからUSB(PTP)で取得・生成したIDを検索して(今はプログラム中に書いている)、それを取り込みプログラムに指定するようにした。そうすれば、同じ取り込み済みファイル一覧が参照される。

MACアドレスは、次のように取得する。スマフォからのHTTPアクセスの場合、アクセスを受けたsocatは環境変数SOCAT_PEERADDRにスマフォのIPアドレスを格納するので、要求が来たらコマンドを実行するようにし、その中でIPアドレスを取得し、その後、arpコマンドでIPアドレスに対応するMACアドレスを取得するようにした。次はそのコマンド例である(まだsocatには理解できていないことがあるため、綺麗ではない。なぜか、最後の";"は必要である)。

tmp_file=/tmp/iimg-rss.d
http_resp_line='HTTP/1.0 200 OK\r\n\r\nAccepted.'
socat -T 0.7 TCP-LISTEN:2345,reuseaddr 
  SYSTEM:"/bin/echo -n -e \"\\\"${http_resp_line}\\\"; 
  (date +\"Date:\ %Y/%m/%d\ %H:%M:%S\"; 
  echo \"PeerAddr: \${SOCAT_PEERADDR}\"; 
  echo; cat ) > $tmp_file; "

スマフォから要求が来た場合、一時ファイル/tmp/iimg-rss.d中に、要求が来た時刻(Date)、スマフォのIPアドレス(PeerAddr)、要求の内容が格納されるので、適宜処理すれば良い(上述の正当性チェック用トークンも要求の内容として格納されている)。なお、これを受信した場合、スマフォには"Accepted."という文字列が返る(今はそのチェックはしていない)。

見つかった問題

実装中や試している時に見付かった問題と対処を以下に書く。

  • rsyncの除外・含めるファイル指定の謎
    • 対象ファイルの指定はなかなかの謎で、うまく使えるようにするのがとても大変だった。指定順序がかなり重要らしい。(→ 参考ページ)
  • オーディオファイル(例: MP3)、動画にはタグが付けられない。
    • exiftoolがMP3などの書き込みには対応していないうえに、タグの仕組みが異なるので、画像と同じようには処理できない。
    • → 取り込み後に画像管理アプリXnViewMPに認識させるために、新規画像一覧を指定してXnViewMPを起動しているので、取り込み時にタグが付けられなかったファイルがある場合には、そのウインドウを閉じないようにして新規ファイルが分かるようにした。
  • 時々SSHDroidが停まる。
    • Wi-Fiの鍵更新時に一瞬Wi-Fiが切れるために、SSHDroidが終了するようだ。
    • → 先日できたWi-Fiの自動再接続プログラムで、画面がoffの場合には(onの時はすぐに繋がるから、問題ないはず)SSHDroidを再起動するようにして、解決するか試している。 → 今のところ大丈夫なようだ。
  • ディレクトリ名の問題
    • rsyncと従来の取り込みプログラム間の想定の違いやAndroidで画像のあるディレクトリはDCIMだけでないなどの細かい問題があったので、逐次対応した。
  • 変なファイル名
    • 一部のファイル名に、想定外の"["や"]"が入っているものがあって、「ゲー」っとなったが、PHPにescapeshellarg()というすごい関数があることを知って、何とかなった。
  • 余計なファイル(Android下のキャッシュなど)の除外
    • 上述のrsyncの除外パターンに指定して、なんとか除外できるようになった。
  • tarはエラーをうまく返さない?
    • 普通に使う分にはちゃんと返すのだろうが、パイプで繋げた場合にはエラー状態が消滅してしまって、失敗がちゃんと分からなくて不便だった。これは、rsyncに換えた最初の理由である。

その他

今、以下のようなことを思った・思っている。

  • 転送がすごく速い。
    • USB(PTP, gphoto2)での時よりずっとキビキビしていて、速くて気分がいい。今は転送ファイル数が少ないだけかも知れないが、rsyncの処理が高速な気もする。
  • 外からの帰宅時に自動取得できると便利かも。※
    • AutomagicでWi-Fiの接続イベントが取れるので、その時にエクスポート開始すればできそうだ。これを作れば、帰宅してすこし経てば自動的に取り込まれているので、ロック解除してアイコンを押す手間すら省けて、なかなか良さそうだ。が、帰宅時にPCが起動していない可能性もあるので、そううまくは行かないことに、今気付いた。 → 外部サーバを使うといいかも知れない(大げさになってしまうが)。
  • スマフォの物理ボタンを押したら転送開始できると便利。
    • が、使えるボタンが少な過ぎて無理(音量しか使えない)。
  • デジカメでもこうしたいが、無理かも。
    • 仮にWi-Fi付きモデルだとしても、rsyncが動くとは思えない(別のファイル共有が使えれば、それに対応させれば、可能性はある)。
  • Automagicはすごく便利! もっとしゃぶり尽くしたいw
  • そして、こんな芸当(というか、Linuxでは当たり前だが)はiPhoneではまず無理だっ! (ネイティブアプリを作ればできるかも知れないけど、そんな面倒なことはしたくない)

※ その後、帰宅後の転送を操作なしにできるように、Wi-Fi接続時に自動的に画像転送を開始するようにした。PCが起動していない可能性については、開始前にpingでPCが起動しているかを確認するようにした。また、Wi-Fiの接続が安定するのを待つため、少し(例: 3分間)待つようにした。

更に、スマフォが電源に接続された時も、同様に自動で転送開始するようにした。この場合は無駄な転送になる可能性があるが、電池は消費しないので、大きな問題ではない。

なお、自動的に転送を開始する場合は、エラーがあった時以外はPCの画面に画像取り込みウインドウを出さないようにした。なるべくPCの操作を邪魔されたくないからである。これは、上記トークンと同様に、スマフォからの転送開始要求のHTTPヘッダに取り込みの動作モードを指定することで実現した。 (3/5 8:58)

その後、アイドル中(画面消灯後、約3分経過以降)はSSHDroidが停まっている(アプリがdoze状態?)ためにPCからのrsyncでのアクセスが失敗することが分かった。いろいろ試したところ、直接的にアプリを起こすことはできなかったが、画面を点灯させるとSSHDroidも動き出すことが分かったので、自動転送開始の契機がWi-Fiの接続時の場合には(電源接続時はスマフォ全体のスリープが解除されてSSHDroidも動き出すので、必要はない)、短く(1秒程度)点灯させてから転送開始するようにした。消費電力の増加が気になるので、しばらく様子を見たい。 (3/6 9:43, 13:35)

Wi-Fi接続時に自動転送したいのは帰宅時なので、長時間(例: 10分以上)Wi-Fiが切断された後に接続した時だけ転送を開始するようにして、長時間アイドル中のWi-Fi鍵の更新時に無駄に画面点灯と空の転送が実行されて電池が減るのを防ぐようにしてみた。

ソフトというのは、最初は単純なものでも、こうしていろいろ工夫・調整すると複雑になってしまう。そういうのの成れの果てがWindowsのようなものだ。なかなか加減が難しい。。。 (3/6 14:14)

更に、自動転送の場合、スマフォ内に前回PCが取り込んだ(PCに転送した)ファイルより新しいものがある時だけ転送開始要求するようにした。これで、無駄に画面が点くことはまずなくなるだろう。ただ、新規ファイルの検索と画面点灯とどちらの電池消費量が多いかは不明だ(点灯させるとスマフォ全体が起動するから、そっちの方が多いとは思うが)。

PCへの要求を送るのにHTTPを使うようにしたおかげで、スマフォからPCへの命令(前回転送したなかで最新のファイル名を取得する)を追加できたのは良かった。

これで、この件に関しては概ね気が済んだ。ただ、想定が狂って、転送開始要求の前に、前回転送した最新のファイルを取得する必要があるために転送回数が増えてしまったのは、ちょっと気に入らない。本当に必要なのか、もう少し考えてみたい。

当然ながら、プログラムは更に複雑になってしまった。 (3/7 11:53)

 

(18:52 若干加筆; 19:49 題を変更; 20:28 若干加筆; 23:42 2番目のsocatの例が誤っていたので修正)

  •   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

以前からやっている、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

僕にしては珍しく、一週間くらい書かずにいた。ある方が入院されているので、(自分の禁を犯してw)twitterでやり取りしている。その流れで細かい投稿をそっちにしていたら、こっちに書かなくても満足できていたようだ。何もしていなかった訳ではなく、以下のようなことをやっていたので、詳しくは追って書きたい。

  • 画像管理アプリのdigiKam5からXnViewMPへの移行
    • digiKamに移った時と同様、コメントとカテゴリ(メタデータ)を引き継ぐ(普通に表示できるようにする)のがかなりの手間と苦労だった。 (→ 投稿)
    • ちょっとした(でも面倒な)残件と謎があるものの、概ね終わった。
    • XnViewMPは軽くていい。が、将来もまた何かに移りそうだw
    • それでも、データ仕様(EXIF)がオープンなので、(Linuxなら)ツールを使ったりスクリプトを作ったりすれば、いくらでも移行できるのがいい。
    • ついでに、過去にし忘れていた画像のカテゴリ分け(タグ付け)もした。そのために更新ファイルが増えて、オンラインバックアップのデータ量が半端ないw
    • ただ、オンラインバックアップの履歴保存のおかげで、XnViewMPで気づかずに上書きしてしまって失われたコメントを復活できたのは良かった。ちゃんと過去の版がリストアできることが分かった。
      • 履歴は頻繁に使うものではないが、いざという時には便利だ。今は3か月までにしているが、1年くらい残すといいかも知れない(お金次第ではある)。
      • ただ、復活させたコメントはどれも大したものではなく、「そこまで頑張る意味あった?」というオチではあったw
  • スマフォの地図アプリのデータ量と電池消費率の最適探し (→ 投稿)
    • 概ね結論が出た。「いつもNAVI」がいい感じだ。ただ、電池消費率はもう少し詰めたい。
  • 生活費の削減方法の検討 (→ 投稿)
    • とりあえず、10-12万円/年(約1万円/月)の削減が目標。手段は分かり、意外に簡単そうだが、実行は難しそう。
    • 更に、年間数十万円減らす策もあるのだが、結構な手間が掛かる。
  • 大掃除 (まだ残りありw)
    • TODOの作成日を見たら、随分長ーーく掃除してなかったのだが、本当なのか? 確かに、あの埃の量はそうだったかも・・・
  • (昔の写真を整理していて思い出した)白黒画像のカラー化手法がすごい。
    • 以前にも書いたが、画像によってはすごく自然にできる。
    • どうやっているのか興味はあるが、(論文を読んで)調べる気は起こらないw
  • 地図アプリの評価にヨドバシへ散歩して
    • 有機ELテレビが紙のように薄くて感動した。「買いますか?」→「まさか!」だけどねw
      • 技術バカの極地と言えよう。気持ちは分かるけど、ほとんど意味がない。
    • (naokiさんに教えて頂いた、)無制限Wi-Fi(ポケットルータ)は大体約5千円/月で手頃だが、3日で10GBの制限が惜しい。あと、電話が使えなさそうなのも惜しい。光回線をなくせるのはもう少し先だ。
    • (モバイルデータ量をケチるために試した、)ヨドバシの無料Wi-Fiが使えなかった。いくらやっても、認証だの証明書だのの文句を言われてwebが見られなかった。プロキシのせい? 全く惜しい。

並べてみると大したことではなく、先進性も生産性のかけらもないが、いろいろおもしろくやって、いい暇つぶしではあった。この調子で50年くらい一気に過ぎると、いいかも知れないw

  •   0
  •   0