コメント中の自動リンク処理を整理し、100件弱くらいのテストケースを書き、それにパスするようにした。また、いくつかの既知のサイトに関して override scheme/preferred schemeの機構を設けた。前者はつまり、youtube とかは http://〜 と書かれていても https でリンクされる。逆に塩辛瓶は https://〜 と書いても http でリンクされる。後者はスキームが省略された時に選択されるデフォルトのスキームであり、ふたば内のリンクに https が適用される。
赤福プラスはFirefox版もビルドしている。個人的にはFirefoxを常用していないのでビルドする必要性は全然ないのだけど、Firefoxで動かしてみると思わぬバグを見つけたりするのでそういう意味での必要性はある。
そういうわけで動作することを保証するわけでも何でもない扱いなので、XPIをAMOで公開はしていない。あくまでgithubのリポジトリの隅っこに置いてるだけである。
さてそのXPIをビルドする際、rest APIが用意されていてweb-extからそれを呼び出すのだが、たまにビルドが失敗することがある。なんじゃこりゃ。
Before starting, please read and accept our Firefox Add-on Distribution Agreement as well as our Review Policies and Rules. The Firefox Add-on Distribution Agreement also links to our Privacy Notice which explains how we handle your information.
つまりAMOのアドオン配布ポリシーやルールに同意してね！という感じなのだが、同意するために具体的に何をすればいいのかは伝えてくれない。心の中ではい！ 同意します！ と念じても何も起こらない。
結論から言えば https://addons.mozilla.org/ja/developers/addon/api/key/ に行ってAPIキーを再承認すればいいらしいのだがいやそんなの分かんないでしょ。何をしたいんでしょうか…。あるいは実際に人によるポリシー同意を定期的に行わせるためにわざと不親切なエラーを出しているのかもしれない。考え過ぎか。
-bash-4.2$ php70cli -r 'echo implode("\n",get_defined_functions()["internal"]);'| grep '^imagecreate'
imagecreatefromstring
imagecreate
imagecreatetruecolor
imagecreatefrompng
imagecreatefromwebp
imagecreatefromgif
imagecreatefromjpeg
imagecreatefromwbmp
imagecreatefromxbm
imagecreatefromxpm
imagecreatefromgd
imagecreatefromgd2
imagecreatefromgd2part
-bash-4.2$ php71cli -r 'echo implode("\n",get_defined_functions()["internal"]);'| grep '^imagecreate'
imagecreatefromstring
imagecreate
imagecreatetruecolor
imagecreatefrompng
imagecreatefromgif
imagecreatefromjpeg
imagecreatefromwbmp
imagecreatefromxbm
imagecreatefromgd
imagecreatefromgd2
imagecreatefromgd2part
-bash-4.2$ php72cli -r 'echo implode("\n",get_defined_functions()["internal"]);'| grep '^imagecreate'
imagecreatefromstring
imagecreate
imagecreatetruecolor
imagecreatefrompng
imagecreatefromgif
imagecreatefromjpeg
imagecreatefromwbmp
imagecreatefromxbm
imagecreatefromgd
imagecreatefromgd2
imagecreatefromgd2part
imagecreatefrombmp
ここのサーバであぷ/あぷ小のサムネイルを作っているが、jpg/gif/png に加えて webp にも対応した。これがなかなか面倒くさい。というのは現在このサーバの php のバージョンは 7.2 なのだがどういうわけかそれについてくる GD には webp を操作する機能が外されているからだ。
そういうわけで仕方がないのでごにょごにょっとして対応。
ClientAliveInterval 等を設定している SSH サーバに接続すると、何も入力しないまま放置している接続は適当な間隔で強制切断される。
そんなわけでそんな感じのことをググると、ServerAliveInterval 云々を設定して回避しよう的なテクニックがよく出てくるのだが、しかしサーバ側にしてみれば放置したままの接続など切断するに決まってるに決まってるわけで、放置してるのに関わらず無駄にキープアライブパケットは送ってよこすとかそんな虫のいいことは困るのである。
従って、放置した接続が適宜切断されること自体はそれは正しい。ただしクライアント側で困るのは強制切断されて即 ssh が終了するわけではなく、数分間何も受け付けない状態になったあとでやっと Broken Pipe 云々が出る動作だ。これをどうにかできないか。
man ssh して ESCAPE CHARACTERS セクションを見れば全て書いてあるのだが、ssh での接続中には特別な入力シーケンスがあり、例えば Enter、~、. の順で入力するとクライアント側からの強制切断を行える。へー。なんとなく vim での編集中にやっちゃいそうなシーケンスのようなそうでないような。
＊ ＊ ＊
適当なマシン A に ssh で接続し、さらにそこから別のマシン B に接続したりなんかしたりの場合。マシン B との接続が切られた際に上記のストロークを入力するとマシン A との接続が強制切断されてしまいますね。うーんまあそりゃそうだよね…。そうではないんだよなー。何をエスケープシーケンスの始まりとするか（上記の例で言う “~”）は接続の際に指定できるので1段めと2段めで変えればいいかもしれない。試してない。
var/log/ のいろいろなログや、journalctl -e や、~/.xsession-errors なんかを見てみると、確かに thumbnailer 周りのエラーが起きまくってるのだが、同時に pulseaudio とか vlc もやたらエラーを吐いている。実際 vlc に動画を食わせてみても、ふええ音が出ないよぉという状態だ。また、/run/user/1000 以下に空き容量がなくてファイルを作れないというエラーも出ている。うーんこれがなんか気になる。
$ df -h /run/user/1000 Filesystem Size Used Avail Use% Mounted on tmpfs 581M 581M 0 100% /run/user/1000
おお…。見事に全部使い果たしている。見てみると psd が管理する chrome のクラッシュプロファイルが残っていた。これらを削除することで全てが上手く回り始めた。psd のこの機能、不要かもしれない。~/.config/psd/psd.conf をいじって無効にしておこう。
ついでに前記事の ffmpegthumbnailer を入れたり、vlc を apt で入れ直したりした。どうも snap アプリケーションというのが、なんかまだへんてこなのだ。OS のテーマを無視したり、OS のファイルオープンダイアログを無視したり、キーバインドの設定を無視したりする。へんてこすぎる。特に gimp が gtk-key-theme-name に中途半端にしか対応していない上、emacs 的なキーストロークを入力すると時々数十秒固まってしまうのが非常に困る。でも新しい gimp は snap の方でしか提供されてないんですよね…。次の LTS で apt のリポジトリの方も更新されるのかな。
というわけで結局以前誰が動画のサムネイルを作っていたのかは分からないままだが、それ以外は解決したのでまあいいことにしよう。人間は根絶やしにされずに済んだ。
ここのところ Xubuntu の tumblerd がよく落ちる。tumlberd というのはファイルシステムを監視して新しく作られたファイルに対して必要ならサムネイルを生成するデーモンなのだが、これが微妙に不安定で、実際ググってもよく落ちるだの、CPUが100%で張り付くだのという記事ばかりが引っかかる。
よく落ちるのは XFCE 付属のファイルマネージャである thunar も同じで、特に以前 CIFS をマウントしてたときなんかは1日1回固まっていた。なんでそれぞれそんなに出来が悪いのかはよく分からない。サムネイルの場合は対象が外からやってくる得体の知れないデータ列であるので、まあやむを得ないのかなと思わなくもないが。
さて tumblerd が落ちまくる中で気づいたのだが、ファイルマネージャ中の動画のファイルにサムネイルが生成されなくなっているのである。ここで、tumblerd はサムネイル生成を司っているわけだが、実際に生成を行うわけではない。どの mime タイプに対して何をどうするかは /usr/share/thumbnailers/ 以下に（正確には、$XDG_DATA_DIRS のどこかに）収められている ini ファイル的なものに定義されている。そこに記述されたコマンドラインが実際にサムネイルを生成する。なぜそれらを呼び出すだけの元請けである tumblerd が落ちまくるのかはよく分からない。
が、そこを見ても動画のサムネイラーは特に定義されていないのであった。なるほどそれなら生成されないのは当然だ。解決…してない。今まで動画のサムネイルを誰が生成してたんだ？ よく分からない。
動画のサムネイルを生成するパッケージというのは ffmpegthumbnailer というものがあるのだが、今のところそれは入っていない。よく分からない。ffmpeg のパッケージ内の何かが上手いこと働いてたのか？
何も分からぬ。何も思い出せぬ。このままでは人間どもを根絶やしにするしかない。
あぷとあぷ小がリニューアルされて塩辛瓶の仕様に近くなったのでそれに合わせて微調整。塩辛瓶のアップローダというのは拙作の Stannum Uploader なのだが、ソースのタイムスタンプを見ると2010年1月18日だそうだ。ほぼ10年前だ。
それまでの塩辛瓶は Sn Uploader をそのまま使ってたんだと思うが、何か忘れたがこれじゃちょっと物足りないねという話になって、その時にドバっと書いて塩辛瓶に独占的に贈呈したのだ。
そういうわけで開発の経緯をもうほとんど覚えていない。久しぶりにざっとソースを眺めてみたけど、もう本当に清々しいほどぜんぜん中身も覚えてない。だめだこりゃ。
スレッドの自動追尾機能を実装した。これは本来の想定ではバックグラウンド側の処理であり、ページを閉じても勝手に追尾したりフロントエンド側では追尾中のスレッドの一覧を操作できたりするといいなあなど思っていたのだが。
まあ、なんというか…大変ですしね。やろうとすると例えばサービスワーカーも動かさないといけないとかなかなか壮大な話になってしまい、つまるところめんどくさいので…そういうわけでフロントエンド側で完結する機能となった。
さて要するに自動リロード機能なのであるが、難しいのはリロード間隔をどう算出するか？ という点である。これは直近のレス n を取り出し、次のレスがつくまでの時間を出し、その中央値を取ることにした。その値に、何レスつくまで待つかの値をかけて最終的な待機時間になる。
とこのように内部的にはそこそこ複雑なパラメータが動いているが、要するに勢いのあるスレッドは頻繁に、そうではないスレッドはのんびり更新するようになっている。追尾をオンにすると画像の通り緑色のバーがにゅっと伸びて、縮んでいく。幅が0になって消えたらリロードが行われる。
使ってみると、例えば実況なんかでもいちいちリロードする必要がないので便利といえば便利だが、むしろ適当なスレを開いてる状態で眠さで死にそうな時に布団に入り、覚醒後にスレの行方を確認できるのがよいかもしれない。
その他、全く関係ないが、サイズが大きすぎる画像を添付した際に自動的に jpeg の再圧縮をしていた処理を多段階にした。つまりクオリティ 90% から始まって、2MB に収まるまでだんだんクオリティを下げつつトライするようにした。
その他もろもろ更新。
赤福プラスがふたば内の画像掲示板にオートリンクを施す際、塩辛瓶（という外部アップローダ）とふたば内の他の板の画像に関してはサムネイルを表示するようにしているが、例外的にふたば内のアップローダであるあぷとあぷ小だけはその対象外になっていた。なぜならそれらのアップローダはサムネイルを生成していないからである。
これが気になっていたので、あぷ/あぷ小用のサムネイルサービスを作った。
まずあぷは https://dec.2chan.net/up/src/f99999.??? という感じにファイルが置かれる。あぷ小は https://dec.2chan.net/up2/src/fu99999.??? という感じ。数字部分の桁数は決まってない。拡張子はだいたいにおいて mime タイプにふさわしいものが付けられるが、mht や webp など一部 xxx になってしまって何のファイルか判別しにくいものもある。この意図は不明。
ということを踏まえて、jpg/gif/png のファイルに関して、https://appsweets.net/thumbnail/up/f99999s.png といった感じでここにアクセスすると最大 250×250 に収まるサムネイルが png で返ってくる。つまり元のアップローダの up/up2 と、ファイル名のベース部分を取り出して繋ぎ、それに s.png を付ければいい。
存在しないファイルに対して、あるいはその他のエラーに対してはでっかいばってんマークの画像を http ステータス 200 で返すようになっている。このとき、X-Error-Reason ヘッダにちょっとだけエラーの内容が含まれる。
また、referer ヘッダが存在し、それがふたばのドメインである必要がある。referer が送出されていない、あるいはふたばのドメインでない場合もばってんエラーになる。
ついでにそれぞれのアップローダのインデックスを開いた際にサムネイルを付加するようにした。
何やら今ふたばではレイアウトを変更しているらしい。では今週末はそれに合わせて虹裏シフトに入ることにしよう。虹裏シフトとは赤福プラスのソースをつらつら眺めたりぼんやりいもげを見ることである。
そんなこんなでいくつかバグを潰した。
動画を添付ファイルとして選択した場合、サムネイルが出なくなっていたのを修正した。従来は取得した動画に対応する video 要素をそのまま canvas#drawImage に与えれば最初のフレームを描画してくれたのだが、そうではなくなったようなので、手動で play() して最初の timeupdate イベントが発生する時点まで待つようにした。
レイアウトの変更に伴って、カタログの表示方法がかなり変更されている。なんと script 要素の中にカタログデータが json で記述されて、ブラウザ側で html に組み立て直すようになっている。へー。それはそれでよいのだが、時々この json が奇妙なことがある。具体的には「表」とか「能」とかの後ろに「\」が入っていることがあるのだ。はいもうお分かりですね。これはとてもプロダクトレベルに達してないな、などと思ってたらカタログだけ従来の形式に戻ったので、管理人さんも認識しているようだ。たぶん。
OSのファイルマネージャからファイルをドロップしようとしてドロップせず、単にブラウザ上をポインタが通過した際にドロップインジケータが出っぱなしになることがあるのを修正した。
添付ファイルを含んだレスの幅が妙になるのを一応修正した。もともとのふたばの画像掲示板では、画像レス中の画像は float:left されていたのでそれを踏襲するわけだが（ちなみに現在のふたばではもう float は使っていない）、これはレスのブロックの幅がその内容にフィットするというデザインと非常に相性が悪い。float 要素を含んだブロック要素の幅がどう自動決定されるかは仕様が規定されているのだが、ざっくり言うとまず float 要素を含まずにレンダリングした際の幅が候補のひとつになり:
それが採られると、こんな感じにみにくいものになる:
本来は、こうなってほしい:
これを CSS だけで解決する方法は思いつかなかった。仕方がないのでページロード後に javascript でごにょごにょするようにした。敗北感を覚える。