Archive for the ‘PC・技術’ Category

先日、ニュースでダイソーのUSBで点くLEDランプの記事を見て、妙に便利そうな気がした。ただ、記事の記述から手持ちのモバイル電池で点灯時間を計算してみると、約43時間と、手持ちの乾電池用ランタンの72または144時間より短いし、モバイル電池がないと使えないので不便な気もして、「まあいいか」と思っていた。

ただ、妙にひかれていたので、今日、散歩がてら買って来た。箱が目立たなく(透明パッケージ入りかと思っていたが、紙箱だった)て、置いてないのかと思ったが、良く見たらあった。箱に仕様が書いてあったので点灯可能時間を計算したら70時間近かったので、意外に長いと思って買って来た。家で試してみたら、結構明るくていい感じだった。

しかし、落とし穴があった。点灯可能時間を計算し直したら、10-13時間くらいにしかならなかったのだ。どうも、店内での計算を間違えていたようだ。実際、以下のように約11時間になる。

モバイル電池の容量: 13000mAh
ランプの消費電流: 1.2A= 1200mA
→ 点灯可能時間= 13000mAh/1200mA= 10.8時間

記事で引用されていた、

「12時間使ってもバッテリー消費は3500mAh程度」

は何だったんだと思うが、(中国製らしく)仕様がかなりサバを読んでいて(PSに書いたように、そのとおりだったw)、実際にはこんなものかも知れないから、それを信じると、以下のように約43時間使えることになる。

3500mAh/12h= 292mA → 300mAとする。
→ 点灯可能時間= 13000mAh/300mA= 43.3時間

どっちにしても、ランプだけに電池を使うのは本末転倒だから、実際に使えるのはこの数分の1だろう(要は「おまけ」ってこと)。そして、更に間抜けだったのは、モバイル電池にもライトが付いていたことだ。

まあ、そのライトは見るからにそれほど明るくないから、ランプの立つ瀬はあるのだが、電池とランプの2個要るよりは電池だけの方が便利だ。

なお、明るさについては、以下のようにランタンのLOWモードと同等だから、この点は悪くなさそうだ。

  • ランタン(Gentos EX777XP): 280lm (LOWモード: 140lm (推定))
  • このランプ: 150lm

結局、このランプは車に積んでおこうかと思っている。車のバッテリーは大容量だから、かなりの長時間点灯できそうだ。僕の車のバッテリーは36Ah(12V)だそうなので(今知ったが、型番の数字は「性能ランク」なるもので、"46"だと容量は36Ahだそうだ。なんか騙されてる感じだ)、全部使ったとしたら、

(36Ah*12V)/(5V*1.2A)= 72時間

と、意外に短い。このランプは(中国製らしく)効率が悪くて電流を食い過ぎるのだろうか。それとも、何か計算を間違えている? なお、記事に引用されていた値を信じた場合、(36Ah*12V)/(5V*300mA)= 288時間になるから、これなら悪くない。

まあ、いずれにしても、いろいろ間抜けだったw 結局、提灯記事(ではないかも知れないけど)に乗せられたってことなのだろうか?? まあ、非常用品は冗長化するに越したことはないし、あとで何かに使えるかも知れないから、良しとしよう。

PS. なんか、本当の消費電流を測りたくなって来た。すぐにはできないので、今後の課題としようw

早速測ってみたら、記事の引用していた値(約300mA)が正しいことが分かった。 (20:52)

PS2. 本当は、夜にランタンと明るさを比べようと思っていたのだが、面倒なので止めた。「点けばいい」って感じだw (21:07)

  •   0
  •   0

本サーバのPHPを最新版(7.3)に更新した。先日書いた手順で行った。いくつかトラブルがあり、一時(php-apcuのインストールがうまくできなかった時)は諦めモードになったが、何とか解決できた。約3時間掛かった。以下に、作業中に起こった問題と概要を示す。

  • コマンド(add-apt-repository)がない。
    • 最初は手で最新PHPのPPA(リポジトリ)を追加したのだが、pgpの鍵も入れないと警告が出るので、パッケージsoftware-properties-commonをインストールし、上記コマンドを追加して改めてリポジトリを追加した。
  • php-apcu(とphp-common)が古いものしかインストールできない。
    • なぜか、他と同様に"php7.3-apcu"のように指定してもインストールできなかった。
    • いろいろ試しても駄目だったので、以下のように、バージョンを指定してインストールした。

sudo aptitude install \
php-apcu=5.1.17+4.0.11-1+ubuntu16.04.1+deb.sury.org+1 \
php-common=2:69+ubuntu16.04.1+deb.sury.org+1

    • その後、aptの追加設定(/etc/apt/preferences.d/ondrej-php.pref)に上記モジュールを有効にする設定が漏れていることに気付いたので、以下を追加した。

Package: php-*
Pin: release o=LP-PPA-ondrej-php
Pin-Priority: 500 # 注: 優先度をデフォルト(500)以上にしないと、古いものがインストールされてしまう。

  • ブログアクセスでHTTPエラー500
    • 最新のphp-fpmの設定ファイル(php-fpm.conf)のコピーを忘れていたために、php-fpmの設定が今までと異なっていて、webサーバとphp-fpm間のソケット(通信路)がない(正確には食い違っている)ためにエラーになっていた。
    • 元の設定ファイルをコピーした。
  • 自作プログラム(古い投稿の非表示プログラム)が山ほどの警告を出す。
    • 昔作ったプログラムで、WordPressの関数add_action()の第2引数の指定方法が間違っていたので修正した。
    • PHPのバージョンが新しくなって厳しくなったのか、ずっと気付かずにいたのか・・・
  • systemctlコマンドでphp7.0-fpmのサービスを無効にできない。
    • 先にPHP 7.0をアンインストールしたため、そのsystemctl用の設定もなくなったためと思われる。
    • 手(ちょっとしたスクリプトをコマンドラインにコピペ)で、/etc/rc?.d/S*php7.0-fpmの"S"を"K"に変更した。

php-apcuの問題は、デスクトップPCで試した時に確認し忘れたので、今まで気付かなかった。

主要な動作確認は問題なく(修正もした)、残件としては、今回追加した最新のPHPのパッケージが自動更新されるか確認する必要がある程度だ。

今朝、ログのローテート処理がエラーになっていた。PHP 7.3をインストールするとphp-fpmのログのローテート処理も追加されるのだが、それと元の処理が競合していた。php-fpmのプログラム名にバージョン番号が付くため、PHPのバージョンに関係なくphp-fpmのローテート後の処理を実行させるのが容易でなかったが、なんとか回避した(phpでプログラム名を出して、それを使うようにした)。 (2/12 5:37)

 

PS. 他の重要なプログラムが駄目になったりサポート期間切れにならなければ、OSは2021年頭までサポートされるので、あと1年以上は「安泰」で、来年中にOSをバージョンアップすればいい。デスクトップPCも同様だが、OSが古いために使いたいアプリが動かない問題が出るかも知れないから、少し早くなるかも知れない。

  •   0
  •   1

2/9に下記のようにお知らせしましたバージョンアップ作業が終わりましたので、サイトの運用を再開します。

 「サイトの一時停止予定のお知らせ」 (2019年2月9日 19:29)

サーバソフトのバージョンアップ作業のため、下記日程で本サイトを一時停止します。

2019/2/11(月) 朝から夕方頃まで (早期終了あり)

作業中は本サイト(ブログ)へのアクセスはできなくなります。断続的にアクセス可能になるかも知れませんが、不安定な状態ですので、終了のお知らせまでお待ちください。

なお、作業中に予期せぬ問題が生じた場合には、一旦止めて復旧させる予定です。

よろしくお願いします。

なお、しばらくは細かい問題が起こる可能性がありますが、その際は随時修正致します。

よろしくお願いします。

  •   0
  •   2

モバイル通信のデータ量の節約には余念がないのだが、通信データ量を調べていたら、思わぬことが分かった。前にも書いたが、家に居るのにWi-Fiでなくモバイルが使われることがある(以下、「家でもモバイル問題」)のだ。それで、それを何とかしたいと思って試行錯誤していたら、僕の要求が相反していて、同時に全部は満足できないことに気付いた。要求を以下に示す。

  • 電池消費率を削減する。
  • モバイル通信のデータ使用量を削減する。
  • (スケジュールなどの)同期を可能な限り定期的にする。

全部を満足させるのは無理で、どれを優先すべきなのか、それぞれをどういうふうに配分するのかの「さじ加減」が難しい。どれが一番重要かはいつも変わるのだが、(とりあえず今は)電池だということになった。その次はデータ量だ(上のリストの順に優先度が高い)。

その方針で、「家でもモバイル問題」に対処した。予想以上に大掛かりになり、うまく動くまでには結構(1週間くらい)時間が掛かった。以下に内容を示す。

現象

接続可能なWi-Fiルータがあっても、モバイルデータが使われてしまうことがある。

原因

Androidのディープスリープ(Dozeモード)に関係しているようだ(他に、アプリごとのディープスリープ"App standby"というのもあるらしい: 参考)。Androidのディープスリープ中はWi-Fi機能が停まり※、何かのアプリが通信する時に自動で再接続されるようなのだが、再接続が遅い(間に合わなかった?)場合にモバイルが使われるようだ。

※Wi-Fi機能の停止以外に、Wi-Fiの鍵の期限切れによる切断もある。

対処

基本的には、通信する時にWi-Fiが接続されていなかったら接続するようにすればいい。が、Androidにはそんな機能はないし(そうしているつもりなのだろうが、抜けがあるのか、「少しくらい(のモバイル)は大目に見て」いるから、この問題が起こっている)、調整するアプリもなさそう(調べてはいない)なので、Androidのグラフィカルなプログラミング言語Automagicでスクリプトを作った。ただ、Automagicではアプリの通信要求を検知することはできないし、その通信を保留することもできないので、以下のようにした。

注: 以下は私のスマフォ・OS・環境(AQUOS sense lite, Android 8)での確認結果に基づいており、すべての場合で同じであるとは言えない(スマフォのHW・ファームやOSが違えば、動作は異なる可能性が高い)。また、私はAndroidに関して詳しく調べた訳ではなく、Automagicのマニュアルの記述と実際の動作から推測したので、Androidの公式の仕様とは異なる可能性がある。以下で用いている単語(例: "Request Sync")はAutomagicで使われているものだが、Andoridでも同じかは不明である。

準備

Wi-Fiが停まっている時にも通信(同期)しそうなアプリ(例: メール、カレンダー、アドレス帳、Evernote)の設定を、自動で同期しないように変える(例: バックグラウンドデータや自動同期・受信をoffにする)。

注: Androidの、アプリに外部から同期要求を出す機能(Request Sync)を使うため、それに対応するアプリでしか対処できない。

定期同期処理

Automagicで以下の処理を実行する。

  1. なるべく頻繁に、かつ、ディープスリープ中も発生しそうな、しかも消費電力が少ないイベントを待ち受ける。
  2. イベント発生時に以下を実行する。
    1. 前回の処理からの経過時間が最小同期間隔(例: 30分)より短かったら、何もしない。
    2. Wi-Fiが有効な状態で、APに接続されていなかったら、再接続(WiFi Reassociate)する。
    3. Wi-Fiが使用可能(Active Network Type= WiFi)になるまで待つ。
      • Wi-Fiが無効だったり接続できなかったり使用可能にならなかったら諦める(→ モバイルが使われる)。
    4. 対象のアプリに同期の要求(Request Sync)を出す。

リストで書くとシンプルなのだが、Automagicはプログラムを図で描くのと、デバッグ用の機能を入れたため、実際のプログラムは大規模になった。普通の言語のようにテキストで書くならそうでもないが、図(しかもスマフォの画面でいじる)だとデバッグや保守がなかなか困難だ。。。 ただ、並行処理がたやすく書ける・実現できるのは、とても楽でいい感じだった。

Automagicでの定期同期実行+Wi-Fi再接続プログラム (概観)

以下に設定や条件などを書く。

対象のアプリは以下とした。通信状況の調査結果から、最も通信頻度・量が多そうで、外部から同期できるものを選んだ。

  • メール(TypeApp): それまで使っていたAquaMailは外部から同期できないので換えた。いくつか試したうちでは一番良かった。 : TypeAppが原因の確証はないが、先ほどセキュリティ上の問題(GoogleのID・パスワード漏洩の可能性)が起こったので、使うのを止めた。AquaMailに戻し、この機能での同期は諦めることにした。詳細は追って書く予定。 (16:18) ← いろいろ調べたが、原因はTypeAppではなさそうだ。というのは、TypeAppにはGoogleのパスワードを入れていないからだ。余りにもタイミングが良かったので、誤解した。まとまったら書く。ただ、別件でも怖くなったので、TypeAppは止めることにした。 (21時) → 詳細をPS2に書いた。 (2/5 13:34)
  • Evernote
  • カレンダー同期アプリ
  • アドレス帳同期アプリ

待ち受けるイベントは以下にした。

  • Periodic Timer Inexact (定期的な(ただし正確でない)タイマー)
  • Display State: On (画面が点灯したら)
  • Notification on Statusbar (ステータスバーに通知が出たら)
  • WiFi State: Enabled (Wi-Fiがonになったら: 帰宅時にWi-Fi Maticがonにした場合に起こる)
  • WiFi Connected (Wi-Fiが接続されたら)
  • Phone Cell GSM: On every cell change (モバイルの基地局が変わったら)
  • Periodic Location Update (30min) (位置が変わったら: 注: 消費電力を増やさないため、GPSでなくNetworkのみを使う)
  • Calendar Event (予定の通知が出たら)
  • Automagic startup (Automagicの起動時)

基本的にはPeriodic Timer Inexactで同期間隔を実現するのだが、ディープスリープ中には間隔が長くなってしまう(例: 2時間)。そこで、なるべく同期間隔を正確にするため、ディープスリープ中も発生しそうなものを追加したので多くなった。が、実際にはPeriodic Timer InexactとDisplay Stateが同期の契機になることが多い。他のものはディープスリープ中にはほとんど発生しない感じだ。

同期間隔は30分としたが、アドレス帳はあまり変化しないので6時間にした。この間隔の種類を増やしてそれに対応する処理を追加すれば、アプリごとに間隔を変えることができるし、細かい処理を調整することもできる(ただし、プログラムは更に複雑になる)。

それから、Periodic Timer Inexactは発生間隔がアバウトなので、ある程度早目にイベントが起こった場合でも処理するようにした。

プログラムは概ねできて、今は動作確認・調整中である。なお、上にも書いたように、Periodic Timer Inexactはディープスリープ中は発生間隔がかなり長くなるため、同期間隔も長くなってしまう。これを解消できる方法も見つけた(下記「簡単にディープスリープを回避する方法」)のだが、消費電力が若干増えるので採用を見送った。これが、最初に書いたさじ加減の難しさの一つである。

ただ、実際に使う場面を考えると、家ではほぼPCしか使わないので、スマフォの通知が出なくても問題はないし、外では頻繁にスマフォを開くので、そのたびに同期が行われる可能性があるから、大きな問題ではなさそうだ。ちょっとした問題は、寝る前に作った予定や夜中に来たメールが朝になっても同期・受信されていない可能性があり、それに気付いて気分が悪くなる程度である。

以下、この過程で見つけた問題などについて書く。

通信遅延問題

ディープスリープの関係なのか、上記プログラムのログに書かれた同期時刻より遅れて実際の同期(通信)が行われることがある(サーバのログと比較して分かった)。呼び出す方(Automagic)からは同期処理が実行されたように見えているのだが、実際にはどこかに貯められていて、あとでまとめて実行されるような感じだ(→ 参考)。左の参考ページによれば、回避策はGCMを使うことらしい(が、それは廃止になり、FCMに移行すべきのようだ)。。。 いずれにしても、クライアントプログラムが非互換なので、そのままでは使えない。

簡単にディープスリープを回避する方法

今まではどうしてもディープスリープを回避できなかったのだが、偶然、方法が分かった。Periodic timer (Like alarm clock)を設定れば良い※。間隔は、例えば1時間でも2時間でも大丈夫だった。ただ、ステータスバーやロック画面にマークやアラーム時刻が表示されるので、紛らわしいし鬱陶しい。

※これはAutomagicだから可能なのか、Android全般に有効なのかは分からない。時計アプリにアラームを設定すれば確認できそうではある。

これより、Periodic timer (Like alarm clock)を待ち受けるイベントに追加すれば、同期間隔がかなり正確に保てることが分かった。しかし、消費電力が若干増える(例: 使用しない場合: 0.3-0.5%/h, 使用した場合: 0.5-0.6%/h)ために見送った。

 

PS. これの発端を調べたら、「(ディープスリープ時に)同期間隔が長くなるので、改善できないか」だった。結局は、同期間隔は諦めてモバイルデータ量の削減となった。やっぱり優先順位が変動しているw そして、こうやって書いておかないと、あとでまた同じことを気にし出す可能性が高いから、困ったものだw

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

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

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

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

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

  •   0
  •   1

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

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

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

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

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

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

  •   0
  •   1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

  •   0
  •   1

e-Taxが、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

先日、画像管理アプリを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