piu lentoの日々 (piu lento days)

うまく行かなかった話なので簡単に書きたい(でも長くなったｗ)。

前回などに書いた、嫌なボット、邪悪な企業、不正アクセスのブロックや、以前書いた(初歩的な)国際化の作業をしていて、再び、このブログのアクセス解析(例: どのページが人気あるか、どの地域からアクセスされるか)をしたくなった。

実際、何かをした効果を知るために測定することは重要だ。

ちなみに、プラグインの評価のために、WP Staticticsを短期間使って調べたところでは、以前試した時と同様にMusicBee関連ページへのアクセスが最も多かった。アクセス元は、当然ながら国内が最も多く、次は中国だった。また、アクセス頻度は少なく、訪問者(ユニークIPアドレス)数は1日100件前後、アクセスページ数は1日200件前後だった(どちらもボットを除く)。

数年前にSlimstat Analyticsなど試したが、機能や出来が今一つだったのと、解析することに大きな意味がない※と思って止めたため、今回も同じような結果になりそうだと思いつつも始めたが、やっぱり駄目だった。

※「エゴサーチ」に近いものがあると思っている。熱中したり一喜一憂すると、良いことはない。そして、アクセス数が多くなるような稿を書くのが目的でなく、書いたものが結果的にアクセスが多くなれば良しだ。

そもそも、良い(僕の用途・要望に合う)アクセス解析プラグインがなかった。(プラグインではないが)Google Analyticsも含めて いろいろ検討したが、どれも以下の問題があって今一つだった。

• アクセスを捕捉できない。
  • 正しく or 全く捕捉できない。
• 機能が不足している・貧弱。
• 問題・不具合が多い。
• 無料でない/有料サービスに誘導する。

それでも いろいろ探して以下を試してみたが、ボロボロだった。それらの重要な問題を書く。

• WP Statictics: アクセス捕捉のために訪問者のブラウザからREST APIにアクセスさせるのは、現在の一般的なセキュリティの認識からは不適切で常識に欠ける。
  • 近頃の更新でREST API(wp-json)にアクセスさせるようになったようだ。
    • 変更履歴にサラッと書いてあったが、もっとちゃんと説明すべきだと思う。このプラグインは そういう説明不足な点が多い。
  • WPのセキュリティ面での弱点になるため、ログインユーザ以外からのREST APIをブロックするセキュリティプラグインがある。それを有効にしている場合はアクセスを集計できない。
  • そもそも、後述のadmin-ajaxも含め、多くの弱点を作り出しているWPが悪いのだが、今は置いておく。
• Slimstat Analytics(以下、Slimstat): (まともに使えるようにするための)設定に手間が掛かり過ぎるうえに、問題・欠点・我慢すべきことが多過ぎて、使う気が失せる。
  • IPv6アドレス(範囲)での除外ができない。
    • 以前使った時はIPv4アドレスでの除外処理に不具合があって、修正案を連絡したものの随分長く放置された(どうも、作者が(メンタル面で)調子悪かったようだ)。
  • 余りにも問題が多い。最初は連絡して直してもらおうと思って居たが、多過ぎる!: 以下に例を挙げる。
    • リダイレクト(HTTP 301)を除外できないため、アクセス数が重複してカウントされてしまう。
      • このブログは、現在の一般的な規範?に従い、HTTPをHTTPSに自動リダイレクトしている。
    • ブラウザのad-blockerを解除しないと、管理画面が ちゃんと出ない。
      • 変なサイトから部品を取り込んでいるのだろうか?
    • トラッカーをクライアント(JavaScript(以下、JS)でアクセスを捕捉する)にすると、最近のブラウザ・サーバのプライバシー・セキュリティ強化(例: トラッキング拒否, CSP)のため、アクセスを捕捉できない場合が多い。
      • 特に、Edgeは ほとんど駄目だった。
    • グラフの日付の処理が まともにできていない(これで使う気がなくなった!)。: 過去1か月や1週間の表示の時に、表示期間全部のデータがない場合に期間の頭からグラフを描くので、日がズレる。
      • 以前使った時もそうだった気がする。

      • 

        WP Slimstatのグラフの処理がおかしい例: 5/24から過去1か月の表示が4/27からになっている。 (使用開始は5/23)

  • 機能は多いが、それらの詰めが甘い。
  • アクセスを捕捉するために、訪問者のブラウザからadmin-ajaxにアクセスさせる。
    • REST APIと同様にセキュリティ的に不安がある。
      • ただ、簡単に塞ぐことができないし、塞ぐことは一般的でないので、仕方ない。
• Koko Analytics: ちゃんと集計できない。機能が少な過ぎる。
  • ちゃんと集計できないのはWP Staticticsと同じ原因(REST API)だろうか?
  • IPアドレスでの除外設定ができない。
  • アクセス元の地域を調べられない。
• (プラグインではないが)Google Analytics (以下、GA)
  • プラグインが全滅だったので、手軽に ちゃんと動きそうなので試した。
  • ところが、最近のブラウザ・サーバのプライバシー・セキュリティ強化(上を参照)のために、アクセス捕捉用のJSが実行できず、アクセスを全く捕捉できなかった。
    • 上記のSlimstatよりひどく、僕が主に使っているVivaldiとFirefox(どちらもプライバシー設定を一番厳密にしている)ではJSが実行できないために、全く捕捉できなかった。
    • 他の訪問者からのアクセスも、全く捕捉しなかった。
    • 捕捉用JSをローカルに持って来て使っている方が居るようだが、見てみると、(どんな複雑なことをしているのか分からないが、)異常にサイズが大きく、難読化されていて論外なので、全くその気が起こらなかった。

 

使えるものが何もなくなったので、自分でサーバのアクセスログから集計するプログラムを作るほうが良さそうだと思った＊ものの、それも大変なので、ログを集計するソフト※を探して使うのが良さそうだという結論になった。

＊サーバのログにはアクセス履歴が全部あるのだから、それを使えばサイトやページを変更することなく解析できるし、嫌われている・問題になっているユーザのトラッキングを しなくて済む。

ただ、サーバのログを集計するのは問題でないのかは不明だ。: 例えば、GDPR的には どうなんだろうか?: まあ、自サイトだけの集計は「トラッキング」(追跡: 他サイトへのアクセスも含めて調査することを指すと思われる)とは言わなさそうではある。

※探したらいくつかあったが、まあ、やる気が継続していたら試すことにする。

 

おまけ: Internet Archiveの謎

アクセスログのチェックやアクセス解析をしていて不思議に思ったのは、Internet Archive (Wayback Machine)は一体どうやってページを収集しているのかということだ。

というのは、先月以降のログを検索しても、それらのUAが全く出て来なかったからだ。※ とすると、以前書いた邪悪な企業と同様に、「あらゆる手段」＊で収集しているとしか思えない。: 調べると、公式ページにはアクセス元を識別するための情報は見付からなかった(UAは あったかも知れない)し、他者の情報によれば、UAやドメインは複数あるし、IPアドレスは随時変化するらしいからだ。

※更に、Wayback Machineの このブログの最終収集日(5/6)に サーバにアクセスはなかった。

＊他の団体からの情報提供も受けているのかも知れない。

いかにもUS的な、「正しいことは何でも独断で やって良い」みたいな思想なのだろうか。それで嫌ってブロックする人も居るから、ちゃんとすればいいと思う。

全くの想像だが、これや以前書いた邪悪なセキュリティ企業は、密かにUSの情報面での戦力として位置づけられているので、「やり放題」なのかも知れない。

なんて書くと、「おや、誰か来―」になってしまうかも? 危ないな。

 

おまけ2: WPとプラグインの危うさ

良く「＊プラグインの脆弱性が見付かった」という記事が出るが、危ないものを「無効」にしているだけでは危険を防げないことを、(本文に書いた)アクセス解析や不正アクセスの検出のためにログを見ている時に気付いた。というのは、「無効」にしてもプラグインのファイルはそのままなので、外部からURLを推測されてアクセスされれば、脆弱性を突かれてしまうのだ。。。※ だから、プラグインのディレクトリごと削除しないと駄目なのだ。

※ログには、そういう脆弱と思われるプラグインのファイル(PHP)をアクセスしようとしているものがあった。PHPの前に、プラグインの有無を調べるためか、テキストファイルにアクセスしているものもあった。

以前、「無効にしているだけでは不充分」と読んだのは このことだったのだ。

WPのクソさに呆れている。

なぜ、WPは そういう問題があるのを知っているはずなのに直さないのだろうか?

サーバ＊のクラウドストレージ(Backblaze B2)へのバックアップに使っているソフト duplicacyが時々エラーを出していた。※ 調べたら4年近く試行錯誤していたが、最後の対処をしてから半年くらい起こっていないので、ようやく直った感じだ。

＊デスクトップでも使っている。

※随分前に書いた気がするものの、探しても出て来ないので、対策しつつ様子を見ていたのかも知れない。

(耳や臭いの問題と同様に)原因が はっきり分からないのだが、バックアップ中のメモリ不足かディスクアクセス過多、あるいはその両方ではないかと推測している。: 通常は問題ないが、(サーバのハード(仮想マシン)は貧弱なので)他に大量にメモリを使うか頻繁にディスクアクセスをするプロセスが一緒に動いていると、問題が起こるようだ。

現象

• クラウドストレージのprune(古い変更履歴の削除)処理時に、いくつかのチャンク(ブロック)が ないというエラーが出る。
  • エラーメッセージの例(発生し始めた頃のもの, 一部改変した)

2019-07-17 03:41:18.960 ERROR CHUNK_DELETE Failed to fossilize
the chunk fdXXXXXX: URL request 'https://YYYY.backblazeb2.com/b2api/v1/b2_hide_file' returned 400 File not present: chunks/fd/XXXXXX

• • そのチャンクを含むリビジョン(履歴)を削除するかexhaustive prune処理を実行すると、エラーは出なくなる。
• 問題のリビジョンのバックアップ時にはエラーは出ていない。

謎と検討

妙なのは、デスクトップとサーバで同じようにバックアップしているのに、サーバだけでエラーが起こることだ。しかも、サーバ(VPS)のハードが交換された あとから起こるようになった。 ← 実は その前から起こっていた。(記録のために残す)

そのことから、(OSは同様なので、)サーバとデスクトップのハード(リソースや性能)の違いが関係している可能性がある。

対処

半年くらい前(2022/11)に以下のように対処したら、問題が起こらなくなった。

• duplicacyのバックアップ処理のパラメタを調整し、使用メモリ量を減らすようにした。
  • オプションに -max-in-memory-entries 51200 を指定した。
    • → 使用メモリ量が200MB前後になった。 (無指定時は600MB以上になる場合があった。: 下を参照)
    • 値を減らすと使用メモリ量は減るが、比例は しない(下限がある?)ようで、10240と かなり小さくしても200MBは使うようだ。
• バックアップ処理と、メモリを大量に使用してディスクアクセスが頻繁なclamscan(ウイルススキャンソフト)が同時に動かないようにした。
  • どちらもcrontabで定期的に起動している(周期や時刻は異なるが、どちらも実行時間が長いので同時に動く可能性がある)ので、起動前に片方が実行中の場合はスキップし、次回まで延期するようにした(片方が終わるまで延々と延期する)。
    • 今気付いたが、微妙なタイミング(例: たまたま2つが同時に起動時刻になった場合)で同時に起動してしまう場合があるかも知れない。 ← プログラム(スレッドやプロセス)でないので、開始時刻(分)を違えておけば大丈夫そうだ。
  • こちらは上より先に実施したが、問題が全く起こらなくなる訳ではなかったようだ。

分かった切っ掛け

対処方法が分かった(問題が起こらないようにできた)切っ掛けは、ある時のduplicacyの更新内容に「使用メモリ量の削減」というものがあったことだ。※ もしかすると、他の方がメモリ不足でのトラブルを報告したのかと思った。

※僕はそれまで、duplicacyがメモリを大量に使用する可能性があるとは全く意識していなかった。想像だが、duplicacyの重複排除処理(重複ブロック(チャンク)の検索?)でメモリを使うのではないか。

なお、更新されたduplicacyのストレージ(スナップショット/リビジョン)は新しいフォーマットになって使用メモリ量が少なくなるというので、全部のスナップショットが入れ替わるまで(変更履歴の保存期間が過ぎるまで)使用メモリ量の変化を見ていたが、余り減らなかった。最初(duplicacyを更新した直後)が一番減った気がする。

それで、duplicacyと一緒にclamscanが動く時にメモリ不足になって、エラーの原因になるのではないかと推測した。ただ、OSのログにはメモリ不足関連のエラーは出ていないので、正確には、実メモリ(RAM)が不足して仮想記憶(ディスク)が使用されて(スワップ)、処理が遅くなってエラーの原因が発生するのではないだろうか。

duplicacyのエラーメッセージから考えて、原因はバックアップ時にチャンクがクラウドストレージに保存されないことがある(ただ、その時にエラーは出ない)というものだろうから、実メモリが不足してスワップが起こると処理が遅くなって、チャンクのクラウドストレージへの送信が失敗するのではないかと推測している。

処理が遅くなって送信が失敗することがあるとは思えないが、例えば通信のタイムアウトやリトライ処理のタイムアウトなどであろうか。前者とすれば、送信するチャンクのデータをメモリにバッファリングせず、ディスクから読み出しながら送っていて、たまに遅くなると送れないことがある? : いずれにしても、duplicacyの処理のロバスト性が今一つなのかも知れない。

そう言えば、以前duplicacyのフォーラムを調べたら、僕と同様に「チャンクがない」というエラーが出る方が問い合わせていたが、結局「再現せず」や本質的でない回答のあとは放置されて、解決していなかった。

そしてその方は怒っていた気がする。: その方のKopiaのフォーラムへの投稿からduplicacyに戻って、上の問題を知った覚えがある。

そこで、試しにduplicacyのバックアップ時の使用メモリ量の表示をさせてみたら※、600MB以上消費する場合があることが分かった。普通は それくらいは問題ないのだが、サーバのメモリ量は1GBと少ないので＊、他のソフトも大量に使用するとスワップが起こりそうだ。なお、prune時は使用メモリ量は小さく、100MB以下だった。

※メモリ量削減と一緒に そういう機能が追加された。

＊以前、たまにメモリ不足の問題が起こっていたため、仮想記憶(スワップ)を有効にしていた。その問題が何だったか思い出せないが、やっぱりduplicacyだったのかも知れない。

メモリ不足の他には、duplicacyもclamscanもディスクアクセスが頻繁なために処理が遅くなって、上と同様にチャンクのクラウドストレージへの送信が失敗する可能性も考えられる。更に、メモリ不足と頻繁なディスクアクセスが一緒になると、余計処理が遅くなって更にひどいことになりそうだ。

ちなみに、過去1年のサーバの稼働状況を調べたところ、duplicacyの使用メモリ量を制限した頃からスワップ頻度(ページ/s, 下の左のグラフ: 中央辺りから制限した)が減ったようだ。ディスクI/O頻度(回数/s, 同右)に関しては変化は少なく、逆に少し増えた感じだ(ただし、なぜか今年4月以降は小さくなっている)。ディスクを複数プロセスで同時に使うと、効率が低下して全体的な性能が低下するためだろうか。

グラフから、duplicacyのメモリ使用量が大きくてスワップが多かったことは確かそうだ。

※なお、同じ期間のメモリの状態(memory usage)、ディスク動作率(utilization)、ディスクの遅延(latency)、NWの通信速度、システム負荷(load average)に目立った変化は なかったので、グラフは省略した。

考察

いずれにしても、送信失敗時にエラーが出るはず・べきだが出ないのはduplicacyの問題(異常時の処理が甘い)か、これらが原因ではないかの どちらかだろう。

今後問題が再発すれば後者だし、逆に、duplicacyの使用メモリ量の制限を止め、常にclamscanと一緒に動かして問題が起これば、僕の推測が正しいことが分かる。が、面倒だし ほとんど無意味(僕が作ったものでないし、サポートが やる気ない: おそらく「環境の問題」で終わり)なのでやる気は しない。

もしduplicacyの問題だとしたら、「バックアップしたつもりなのに(エラーになっていないのに)、できてなかった」という、結構ひどいものだ。が、起こるのは限られた環境のようだし、駄目になるのは一部のファイルだけなので、致命的とまでは言えなさそうだ。でも、これは遊びのソフトじゃないので、重大な信頼性の欠陥だと思う。

補足すると、特定の環境・状況で処理が失敗するのは仕方ない(すべての環境・状況で使えるものは作れない)が、使った時に失敗したことが分からないのが問題だ。

そう言えば、作者は こういうエラーメッセージ関係の重要性を軽視しているようで、以前、「エラーメッセージ(か終了コード)が誤解する・分かりにくいから変更して欲しい」という要求を拒否していた。

これは単なる表示・見た目の問題ではない。ちゃんと作る(起こり得る すべての失敗を想定・想像する)のは大変だが、製品には必要だ。

試行錯誤

対処方法が分かるまでに以下を試したが、ほとんど効果がなかった。若干良くなるように見えたが、問題は起こった。

• バックアップ時の送信スレッド数を減らす。: デフォルト: 4個 → 1個 (-threads 1)
• バックアップ時の送信速度を下げる。: 約250kB/s (-limit-rate 250)など
• B2のメンテナンス時間帯(毎週1回)のバックアップを避ける。

これより、問題の原因はduplicacy単体ではない可能性が高いことが推察される。 ← 上も動作環境(NWやB2)が関係していることを推測して行ったので、これは言えない。 (22:11)

 

余談

何度か この件をduplicacyに問い合わせようと思ったが、ハードが関係していそうだし、上述のようにサポートが余り親切・適切でなさそうで解決する見込みがないので、止めていた。そして、もし僕の推測した原因が正しかったら、問い合わせても全く解決せず、(いつものように)ただイライラするだけだっただろう。

duplicacyは通常時は問題なく動作しているのだが、上に書いたように異常対応やロバスト性が心許ない気がしているし、サポートの態度にも問題がある。あと、バックアップの対象・除外設定と動作が複雑で頭が狂ってしまう。

そこで、以前書いたKopiaなど新しいバックアップソフトを検討したいが なかなか面倒だし、そっちが良い保証もない。他に やることが溜まっているので、検討するとしても来年と考えている。

 

PS. 書く前は手短かに終わらせようと思って居たが、長くなったし熱くなった(ムカついた)。調べたら長年苦労して来たし、作者がテキトーなのを思い出したせいだ。それにしても、国内・国外関係なく、いい加減なソフト屋が多い。ハードも同様だ(以前も同じことを書いた)。

先日書いた、このブログの海外へのプロモーション用※に、各稿の下に英語で(新聞のような)見出しやキャッチ的なものを出すことにした(そういうのの適切な英語訳が分からないので、"Keys"とした＠)。最初は自分で付けていたのだが、結構面倒なので＊AIにやらせることを思い付いた。

※これは、以前大嫌いだと書いたSEOの一種になるのだろうが、無理に検索の上位にしようとしている訳でなく、外国の人の目に触れる機会を作ろうとしているだけだ。

＊自分で書いたにも関わらず内容を忘れて居る(このブログの主旨には合っている)のと、近頃は やたらに長く内容が多過ぎる稿が多いことが多い。そこは要改善点なのだろう(と、書いておく)。

＠ちょっと強引だが、KeysはWordPressのタグとして扱っている。

それで、いろいろなAIソフト(エンジンは主にOpenAIの無料版)で各稿のサマリーやキーワードを生成しようとしたが、巷の評判とは異なり、今一つ うまく行かなかった。

最初にChatGPTで試したら、外部URLは読み込めないから使えなかった。次にWritesonicのText Summary V2を試したら、結構良さそうだった。出力に英語を指定すると、日本語の文章も英語でサマリーを出してくれる。ただ、それからKeysを作るのは手作業で それほど楽ではないし、WordPress(以下、WP)に貼るのも面倒だった。

そこで、こういう用途に使えるWPのプラグインを探したが、ほとんどなかった。: 多くはChatGPTのプロンプトを出すだけだし、投稿の編集ページでなく独立のページでしか使えないものや、有料(最初だけ無料)でしか使えないものも多かった(それを明記していないものがあって ひどい)。

使えないからアンインストールしたら"We Need to Talk!"とかいうメールを送って来て、unsubscribeしたら それにもメールを送って来た、大変鬱陶しいGetGene AIというクソもあった。

唯一残ったのはFlusso AI※(OpenAIを利用)だった。投稿の編集ページでボタンを押すだけで、Key Pointsというサマリーを作ってくれ、それを投稿と一緒に表示することもできるから便利だ。この出力は上述のWritesonicと同様だったので、どちらもOpenAIの機能を使っているのだろう。

※Flussoは 問い合わせに ちゃんと対応してくれて良い。出たばかりでユーザが少ないからだろうか。ただ、作者が自分でレビューの評価を★5にしているのは逆に損だ(ただ、一般ユーザを詐称している訳ではないので、悪意はなさそうだ)。

ただ、使ってみると、実はKey Pointsも今一つなことが分かった。箇条書きだけど なまじ文章(しかも短くない)になっているため、パッと見てもポイントがすぐには分からない。僕がネイティブでないせいはあるだろうが、文章の単語数が多い気がする。要するに、長ったらしい。(要約なのに"TL;DR"になりそうだｗ): 以下に、Key Pointsの出力の(良い)例(前回の稿「ちゃんと多言語対応するのは大変だ。」)を示す。

∙ The blog is primarily aimed at a Japanese audience, but some topics, such as technology, are relevant internationally, leading the blogger to consider creating an English version.

∙ The blogger initially used machine translation to create an English version of the site, using Google and Yandex, which had comparable translation quality.

∙ Google Translate was ultimately chosen because it successfully translated the name "Hamelin," and a link to the English version was added to the site.

∙ The blogger considered various options for improving the English version but decided to stick with the current setup due to the difficulty and cost involved in creating high-quality translations.

論文などなら良いが、僕がKeysとして欲しいのはツイッターのタグ※的なもの(一つの単語でなくても良く、完全な文章でなくて良い、パッと見て中身が想像できる・興味をもたせる短いフレーズ)だ。 参考までに、僕が考えたKeysは以下である。

AI translation, build multilingual website, Google and Yandex translate comparison, Google Translate, i18n, machine translation, Yandex Translate

※そういう機能のものも いくつかあったが、原文が日本語のせいか結果が全く駄目だった。

AIの出力は大筋では合っているのだが、前書きやアムランの件は余計だし(しかも、後者は読み切れていない)、Googleが すごく良いから選んだ訳ではないし、題にも書いた重要な意図(build multilingual website: 単なる英語版を作ろうと思っているのではない)は読めていない感じだ。

それ以前に、稿によっては、結果に重要な内容が書いてないことがあったので、結局、自動処理はできず、出力を確認して修正する必要がある。※ それから、OpenAIの無料版だと元の文章の長さ(単語数?)制限があって、結構多くの稿で使えなくて不便だ。

※以前も書いたが、今のAIの最大の欠点は、人間が結果を確認する必要があることだと思う。まあ、人間に依頼した(or 自分でした)作業でも同じだけど、自動化・効率向上の妨げになっている。そして、しばらくはAIに作らせたままの ひどいソフト・システムや文章が出て来そうだ。。。＊

＊でも、今だって、れっきとした人間に作らせたままの粗悪品が某ショッピングサイトAに蔓延しているので、AIだけが悪い訳ではではない。出す人間が悪い。

それに、ソフトやシステムだって、大企業が多額の費用を掛けて作ったものでもマトモに動かないことがあるではないか。(例: 近頃問題が発覚している、マイナンバーでの住民票発行システム)

それに比べれば、AIが作ったまま出すほうが費用対効果は良さそうだ。だから人間は不要だ。: などというのは、政治家とか有名人がTVとか配信で言いそうだが、単なるレトリックで技術的・論理的には正しくない。

原因は いろいろあり、人間とAIでは問題が起こる確率が異なるが、全部人間が悪いのは確かだ。AIが作ったまま出すのも、同じく人間が悪いために問題が起こる(現時点ではAIでなく人間が出すため)。

結局、どちらにしても、人間が真面目にやれば いいってことだ。少なくとも今は。

そういうことなら、最初にやったように、「自分で稿を読んで英語のキーワードを考えたほうが楽」という結論になって、(暇潰し?を兼ねて)順次やっている。

まあ、有料版のOpenAI(GPT4)なら強力で長さ制限もないのだろうから もう少し良くなるだろうが、料金が かなり高いので趣味には使えない。それでも、今後は手軽に使えるものが出て来ることを期待したい。

(19:18) その後、Flussoの方に勧められて、GPT-4 APIの待ちリストに登録した。GPT-4は全部有料だと誤解していたが、それが通れば無料でAPI(Flussoが使う)が使えるようだ。

そうすれば、長さの問題はクリアできる。キーワードを抽出する(Keysを作る)のは、どういうAPIがあるか調べてFlussoに要望するか、自分で作ってみたい。

 

なお、今、英語関係で一番役に立っているのはDeepL(翻訳, write(改善))だ。これもAI技術を使っているようで、普通の辞書サイトと違って生きた・「こなれた」英語にしてくれる。※ APIもあるようだが、やっぱり料金がすごく高いので使えず、もっぱらwebページで処理して結果をコピペしている。

※僕の印象なので正しいかは不明だが、日本の辞書サイトで出た、「なんか うーん」な英語をDeepL Writeに入れると、いかにも「おお これだ!」という自然なネイティブが使うような(に感じる)結果になることが多い。

なお、DeepLのは和訳は少し弱い感じ(ちょっと砕けた英語(それでも、和訳はできるしwriteは通る)は破綻する)だが、僕には英訳や英語の修正のほうが重要なので、大きな問題ではない。

 

PS. ニュースで良くなったと見て、Edge+Bingも試したが、なぜか散々だった。: 本文に書いたのと同じ稿に対する出力が全く誤っていて、なぜか全く別(別人)の文章に対するものだった。全然違う、どうして?と指摘したら、一方的にチャットを「終了」に されてしまった。ChatGPTなら続けて「どうして欲しい」と打ち込めるのに・・・

同じOpenAIを使っているはずなのに、随分作り込みが違うようだ。

使い物にならないようなので、Edgeは すぐにアンインストールした。いつものように、一瞬でもMSに期待したのが間違って居た。

PS2. 試しに この稿のGoogle翻訳での英語版を読んでみたが、やっぱり結構良い。破綻している箇所があってDeepLほどではないが、OpenAIのサマリーよりは ずっと読みやすい。

それから、どういう訳か、今回は「ｗ」を"lol"と訳していたので感心した。

自力で問題に対処したのはWordPressのAIOSプラグインだけでない。今日、先日書いたNextcloud(ファイル・PIMサーバ)の問題にも対処した(2回目)。

現象は、管理画面がスクロールできないという情けないものだ。ブラウザはVivaldiとFirefoxで起こった。(いずれもLinux版) Chromeも同様と思う。

(「あくしろ!」な手っ取り早く解決方法を知りたい方は、下の「解決方法」へ)

初めて気付いた時(去年の末)に調べたら、他の方も同様の現象が起こっており、CSSを修正(プラグインCustom CSSでCSSに追加)して暫定対処していた。僕もそれに倣ってみたが、直らなかった。その後試行錯誤して、どうにかうまく行くようになった。 (→ 後述のCSSの上半分)

しかし、近頃再発してしまった(もしかすると、以前からだったが気付かなかったのかも知れない)。: 今度は、アプリ管理画面がスクロールしなくなった。

再び検索したところ、同様の問題が起こっている方が居て、フォーラムに投稿しているものの、見付かった2件は解決していない。ひとつではユーザの環境の問題(いわゆる「おま環」)にされ(結構多くの人のところで起こっているのだが・・・)、もう片方では開発側の回答がないという、良くある ひどいありさまだ。

それでまた、開発者ツールでCSSを試行錯誤して、どうにか スクロールするようにできた。

(解決方法) 最終的には、以下をCustom CSSに追加した。

body, body #content { 
  overflow: scroll!important; 
  position: absolute!important;
}

.content[data-v-3cd3ed01]:not(.with-sidebar--full) {
  position: unset!important;
}

上半分はアプリ管理画面以外の全体的な対処、下半分がアプリ管理画面の対処である。後者は謎の数字や条件があって、いかにもNextcloudが更新されたら効かなくなりそうだが、良く分からないし(、こんな腐ったもののことなど)分かりたくないので、とりあえず使っている。駄目になったら またやれば良い。

その時は、AIに聞いたら教えてくれるだろうか??

 

どうも、"Nextcloud Hub"とか名乗ってから腐ってしまったようだ。例えば、このスクロールの問題以前に、画面のデザインが醜悪になってしまった。※ そもそもはownCloudのコピーだったが、"Hub"になってから自分たちでやろうと無駄に頑張って駄目にしてしまったのではなかろうか? (良くある話だ・・・)  大体、問い合わせにまともに対応しない時点で終わっている。

※そう言えば、上に挙げたフォーラムに書いてあったが、スクロールできない問題はテーマを変えると起こるのかも知れないようだ。確かに僕はテーマを変えている。が、デザインがひどくて見にくいので仕方なくしたのだし、設定くらいはまともに動くようにすべきだし、動かない設定は付けないで欲しい。全く腐ってる!

「いい加減にしろ!」って言いたいが、いい加減にされて困ってるｗ

それで乗り換え先を探しているけど、いいものはなく、ownCloudの最新版(OCIS)に戻るか、今まで知らなかったがSeafileかというところだ。

画面を見るたびにイライラするものの、安易に乗り換えられるものではないので、しばらくはNextcloudを使うしかない。まあ、画面は余り見ることがないのが幸いだ。

 

題に書いたように、近頃はオープンソースの質が随分落ちた気がしている。たまたま僕が使うものだけなのか、それらのユーザが少ないからかも知れないが、出すのならもっとしっかりして欲しい。自分たちのやりたいことだけやって、ユーザから報告される問題に碌に対応しないのなら、公開しなければいいではないか。

なお、「オープンソース」とは書いたものの、有料ソフト・サービスだって負けては居ないｗ※ それどころかハードだって同じだった。それらはユーザは手の出しようがない場合が多いから、余計ひどい。

※例えばSpotify(特にサポート)は ひどいものだ。またあとで書きたい。 → 書いた。

結局、なんでも駄目なものは駄目。しかも、駄目なものは増えているって結論か。

Zim+Joplinで自分用ノート管理システムを作ろうとしたが、挫折しそうだ。Zimの完成度が低くて、先行きに十抹くらいの不安を感じた。いろいろ苦労して、Zimで変更・作成したノートを自動でJoplinに更新・取り込みできるようにしたのだが、Zimの不可解な動作や問題が次々と現れて これ以上対処するのが嫌になり、ガッとひっくり返したくなった。

単体でちょっと使うのには良かったが、Joplinと連携させて使い込むと、機能不足、不具合、変な仕様がバラバラ出て来て、そのカバー("workaround")が大変だ。ただ、それなりに まともな考えで ちゃんと作ろうとしているのは感じられるし、「普段」の使用では概ね快適に使えているので、今までの他のソフト(例: Evernote, Joplin, QOwnNotes, Zittlr)と違って腹は立たず、「クソだ」とは言わない。単に未完成なだけ(まあ、「ちょっと実力が足りないね」みたいな)だ。ただ、これが完成するとは到底思えないのが痛い。。。

参考までに、僕にはキツい問題を挙げる。

• ノート名に使えない文字が多い。
  • 仕様の問題: ファイル名をノート名にしているため。
    • そうは言っても、Linuxで普通に使える文字でも駄目なものが多い。
  • 多くの記号(例: ()[] #)と空白が使えない。
  • ノート名先頭の文字は更に制限が厳しく、 おそらくすべての記号が使えない。
    • 仮に全角文字や非英語の文字にしても、記号のカテゴリは駄目。
  • 文字のカテゴリで余計なチェックをしているのか。
    • → 確かにチェック・制限していた。: zim/notebook/page.py の _pagename_invalid_char_re で行っている。 (11/16 10:21)
      • なぜ、(ASCIIのでない)Unicodeの記号も駄目にするのだろう???
  • → 仕方ないので、記号に見える普通の文字で代用してみたが(例: 下図)、本質的でない無駄な努力(例: ガラケー的なｗ)に思える・・・

    • 

      Zimでノート名に使えない文字(() → 𛰙𛰚, 空白 → ⌴)を代替してみたが・・・

• 表示の更新がおかしいことがある。
  • テキストの入力後に行が重複して表示されることが多く、迷子になってしまう。
    • ページを上下させると直る。
  • → その後、フォントが関係していることが分かった。デフォルトのフォントだと問題は起こらず、僕の愛用している源真ゴシックPだと起こることが分かった。 (11/16 10:02)
    • 源真は行間が広目なので、それが関係しているのか。
    • ただ、デフォルト(なぜかTakao Pゴシックのようだ)は行間以外に色が濃くて(線が太い?)すっきりしない・読みにくいのが嫌なので、問題が起こっても源真で頑張りたい。
    • また、Noto Sans CJK JPは漢字が等幅なので嫌だ。
• 謎の動作・仕様がある。
  • ノートの先頭に書いたタイトル(見出し)がエクスポートされないことがある。
    • → とりあえず、そうなった時は先頭に何か(例: "."だけの行)を書くことで、しのぐことにした。 (11/16 12:15)
  • ノートを取り込むと、実在しない変な名前のノートができてしまうことがある。
    • ノート中に"file:"があると、そうなるようだ。 → URLに見えるもの、Joplinのノート間リンクが駄目な感じ。
      • 名前はそのURLになっている。
      • そんなことされたら邪魔臭い。
    • その場合、エクスポート(インポートも?)がエラーになることがある。
    • → 目障りなので、Joplinから取り込む時に削除するようにした。それが分かるように、その前の行にその旨を入れるようにした。と書いたが、本当に動いているか あやふやだｗ そうしようと思っただけだったかも知れない。まあ、やればできる。 (11/16 18:45)
  • エクスポートがすごく遅いことがある。
    • エクスポート時にもトップ以下のファイルをスキャンしているため?
• 結構落ちる。
• ノートの保存ができないことがある。
  • ノートを外部で変更すると弱い?
  • → どうやら、同じノートをZimと外部で同時に変更すると「負ける」ようだ。これは仕方ない。 (11/16 10:15)
    • Zimから自動でJoplinに追加する時、Joplinで新規だった場合には あとで更新する時のためにJoplinのIDを入れるのだが、それが良くないようだ。難しい。
      • → 今後は、JoplinのIDは別ファイルに入れることにした。そうすれば、あとで追加ノート情報も入れられる(今は未定だが、例えば「本当のノート名」が入れられる)。 (11/16 12:18)
• 行の(ソフト)ラップがないように振る舞う場合がある。
  • 長い行でカーソルが編集ペーンの右端近くに行ってしまい、Homeキーで行頭に戻れない。マウスでスクロールバーを動かすしかない。
    • スクロールバーは出さなくていいんだが・・・
• LibreOffice Calcからの文字のペーストが画像になってしまう。
  • 「テキストとしてペースト」(例: Ctrl+Shift+V)の機能がない。。。
  • → 調べたら、(Linuxで)他にも起こっている人が居た(ペースト先のアプリはZimとは限らない)。ただ、例によって「LibreOfficeの問題じゃない。あっち(例: アプリ側)で聞け」や「クリップボードマネージャを止めろ」などで終わって原因が分からないので、本質的・一般的な解決策はない。 (11/16 12:05)
    • そりゃあ、受け側アプリのクリップボードの中の値の選び方が悪いのは確かだが、そもそもスプレッドシートの「値」をコピーした時に、画像を(も)クリップボードに入れるってのは あきらかに非常識だと思うのだが・・・ いったい どういうメリットがあると考えたのだろう? せめて設定にすればいいのに。
  • → コマンド: xclip -selection clipboard -o でクリップボードのテキストが取れるので、それをZimのカスタムツールに入れた。また、ショートカットが割り当てられるので、Ctrl+Shift+Vにして一般的な操作でテキストがペーストできるようになった。 (11/17 9:38)
    • -selectionはprimaryでテキストが取れこともあるが、secondaryは駄目。 → Zimはsecondaryを取っている?
    • また、なぜかZimでコピーしたテキストは取れず、ハングすることもある。 → タイムアウトを付け、clipboard, primary, secondaryの順に試すようにした。: Zimの謎は多い。
      • ハングするのはxclipを普通に動かしていたためだった。オプション-quietを指定すれば良い。
      • が、それでもclipboardではハングし、どうしても解決できない。Zim自身と競合しているのだろうか。
      • → 結局、 xsel -n -o -p (primaryを取得, フォアグラウンドで動かす)だけにした。 (11/17 11:07)
• UIが整理されていない。
  • メニューは どこに何があるか迷う。
  • ブックマークが多くなると全部が見えなくなる。
  • CSDらしいのが嫌(例: ウインドウのタイトルバーにアプリのボタンがある)。
• 起動するたびに/tmpにログディレクトリ(zim-xxxxx)を作る。
  • これは ちょっと違うだろ・・・

 

他に、僕のシステム構成の問題として、画像(リソース・添付ファイル)の処理の難しさがある。Zimで追加した画像をJoplinに入れるのが面倒だ。ディレクトリが異なるので、コピーだけでなく、ノート中のディレクトリ名も変える必要がある。

→ とりあえずは、Zettlrの時と同様に、まず画像をJoplinの作業用のノートに貼り付けてJoplinに取り込み、そのノートをZimに戻し、その画像(のタグ)を本来のノートに貼ることでしのいでいる。面倒だが、頻繁でないので それほど苦ではない(プログラムを作るよりは楽だｗ)。 (11/16 12:27)

 

そして再び振り出しに戻って、次の候補探しを始めた。今度は、やっぱり、前回諦めたWPみたいなwebでできるものがいい気がしている。それなら、最後に書いた画像の問題は起こらないはずだ。が、セキュリティの問題はある。

↓

その後、他のエディタやWPに近そうなWikiのソフトを検討・試してみたが、僕に丁度いいものが全くなく、なかなか意外な結果となった。以下を検討・試した。

• 検討で却下したもの。
  • OpenNote(Wikiではない), MyTetra(同), TiddlyWiki, TagSpaces, BookStack(前回も却下 → その後試したが・・・), Wiki.js, PmWiki
• 試したもの。
  • RedNotebook(Wikiではない)
    • MDみたいな入力でプレビュー型
    • 機能が貧弱で話にならない。
    • Zimのほうがずっといい。
  • MediaWiki
    • デモを使った感じでは一番良かったが、WikiPediaのような公開Wikiがターゲットのため、個人のノート用には いろいろ使いにくい。
      • 例: 画像を入れると、「それはあなたの?」などと聞かれる。
      • カスタマイズすればいいのかも知れないが。
    • デザインがイマイチ。
    • 引用がない。: WikiPediaの特徴?
    • 例によって日本語がひどい。
      • 英語にしたつもりが日本語になっていた・・・
  • MoinMoin
    • 著名なオープンソースプロジェクトに採用されているらしいが、良く使ってると思う。10年以上前の感覚。
    • 設定が分かりにくく、不親切。
      • ファイルがいくつもあるが、検索しないと説明がない。
      • サイトも不親切。
      • 簡単にWYSIWYGエディタにできない。 → ガイドを参考にして ようやくできた。
    • エディタがすごく使いにくい。
      • ショートカットがない。
        • → ブラウザなので、太字にするつもりでCtrl+Bを押すとブックマークになってしまう・・・ 「うむ。」
      • タブでインデントしない。(上と同じ)
      • ボタンのアイコンがボケている。
  • XWiki
    • JAVAでメモリを食うので不可。
    • エディタは まともだが、書式の指定が ちょっと使いにくい。
  • Foswiki
    • エディタがすごく使いにくい(MoinMoinと同じ)。
    • 登録時のキャプチャが全然読めなかった。5回くらい繰り返した。
  • WackoWiki
    • WebサーバがApacheでないせいか、うまく動かなかった。
  • DokuWiki
    • 試したうちでは一番好印象(使い勝手がWPに近い)だったが、エディタに問題があって却下した。
    • デフォルトのエディタは使いにくいが、プラグインのCKGEditorを入れれば使いやすくなるものの、うまく合っていない。
      • 画像(説明では直ったと書いてあるようだが・・・)や引用ブロックが ちゃんと表示できない。
        • 画像はデータが表示され、引用は前後にタグが出てしまう。
    • プラグインがwebで入れられて楽。
    • インストールなどの説明も分かりやすかった。
    • Webサーバはlighttpdやnginxが使える。
    • ただ、新しいページの作り方が不明。Wikiのせいか?

 

我ながら要求が厳しすぎるようだ。まあ、ノートを書くソフト(特にエディタ)は いつも使うので、仕方ない面はあるが・・・

結局、今のところは、Zimで まさに「頑張る」※かWPを使うかの二択となった。

※骨を埋める覚悟ならソースに手を入れるが、ちょっとまだその気になれない。

(17:45)

本文を読み返して、Zimで頑張ることは あり得ないと確信した。「だめだこりゃ。次行ってみようだ。」 (19:22)

更に少し考えたら、WPはそもそもブログ用なので、使い方がノートとは合わないことに気付いた(以前検討した時にも気付いた気がする)。例えば、「更新」ボタンを押さない限り、編集内容は反映されない。しかし、ノート用エディタは書いて放置すれば反映される(アプリによっては、履歴が保存されるから、それで全然問題ない)。その気軽さが重要で、ノートにはワープロが使えないと感じるのも、そういうことである。

てな訳で何も残らん・・・

せいぜい、DokuWikiやMediaWikiを頑張って改造する? いや、それらにしたって「保存」ボタンはある。 (21:06)

↓

その後、再度Wikiなどを試したが、まあ全滅だった。

• BookStack: 綺麗ではあるが、実用性がない。サポートする気が感じられない(「こっちでは再現しない」的な回答ばかり)。
  • 大きなノート(約4000行)の保存に失敗する(既知の未解決の問題)。
    • いろいろなタイムアウトを伸ばしたが、駄目だった。
    • HTML関係の処理が悪いのではないかと思う。
  • 大きなノート(約3000行)の変更(編集)が遅い(Zittlrと同様)。: 「ブラウザ(≒ JS)もElectronも似たようなもの」ってこと。
• MediaWiki: 詰めが甘い。セキュリティがいい加減。サポートも いい加減(問題を放置)。やっぱり、Wikiはノートには使いにくい。
  • Visualエディタでノートを読み込む動作がおかしい(既知の未解決の問題)。エラーが出たり出なかったり・・・
    • WikiとHTMLの変換処理("Parsoid"とかいうモジュールらしい)の出来が悪いのではないかと思う。
  • 設定ファイル(DBのパスワードなどが平文で書いてある)がwebサーバのドキュメントルートにあるって、とんでもない落とし穴だよ。。。
    • 「Webサーバを適切に設定しろ」と書いてあるだろうし、それを忘れて流出して実害がないとしても、作った人の意識の低さが知れる。
• DokuWiki: 出来が悪く、使い物にならない。終わったソフト?
  • Visualエディタにノートをペーストして保存して開くと、フォーマットが崩れる。
    • HTMLやMDをインポートしても同様。
    • 大きめのノートで起こりやすいが、小さくても起こると思う。
  • 入れると何もかも動かなくなる(表示が真っ白になる)プラグインがある。
    • そういう情報は何も書いてないのに。
  • プラグインを入れても、どこにもその操作(ボタン)が出て来ないものが多い・・・

あと、BookStackで実感したが、WPもブラウザ(JS)なので、やっぱり大きなノートの変更(編集)は遅くなるだろうから、いくら使い勝手が良くてもノート用には使えない。

そうすると、結局Zim(+Joplin)しか残らないが、「何とかすべきこと」が多過ぎる! でも、さし当たっては(曲がりなりにもｗ、そして、僕には一番ストレスなく)Zimは使えるので、様子を見ながら考えたい。 (11/15 19:00)