アクティブでないタブがトラッカーによって更新された場合、文書のタイトルを点滅させるようにした。しかし単に点滅だと意外に目立たない。タブの背景色をいじれるといいんだけどな。あるいは音を出せばいいのかな？
数年前の赤福プラスは (Presto)Opera、Chrome、Firefox(Add-on SDK) で動いていた。これらのブラウザがサポートするエクステンションの API は微妙に、あるいはかなり異なっていたので、それらの差異を吸収する層が必要で、赤福プラスにおいてはそれは Kosian というライブラリだった。
さてそこから時が過ぎてブラウザのエクステンションは Chromium のそれで統一されてしまう勢いになったので、Kosian の存在意義が危うくなってしまった。なのでラッパの層を段階的に剥がしていきたい。同時に、個々のモジュールは ECMAScript Module で組み込むようにしたい。
ということで、そうした。文章で書くと簡潔だけどこれはなかなか大変でした。
ふたばの画像掲示板で履歴機能が拡充されたので見てみる。
もともと、カタログの1モードとして過去にレスしたスレッドを集計する機能があり、それが履歴という扱いだった。内部的に考えれば、post したリモートホストが自分であるレスを含むスレッドを select するというサーバ側の SQL のクエリの話になる。
最近拡充されたのはそれとは別立てで、開いたスレッドの履歴を持っていてその一覧を表示するというものである。開いたスレッドの一覧データはどこにあるかと言うと、サーバ側ではなく、クライアントの cookie である。つまりカタログをサーバへリクエストする際にその cookie を投げると、サーバはそれに対応したスレッドの一覧を組み立てて返してくる。
これは良くない設計に思える。これに限らず、クライアント側はセッション ID だけを持たせてセッションにぶら下がるデータはサーバ側が持つほうが正道に思える箇所が色々あるのだが、長いことふたばはその方法を取らない。
それはそれとしてもう1つ不思議なのは、post した履歴と開いた履歴は分ける必要なくない？ ということだ。常に post した履歴は開いた履歴の部分集合であるはずだ。これは誰でもそう思う疑問のはずで、まあまだ色々と作りかけなのかもしれない。
そういうわけなのでとりあえず見た履歴の機能をベースにして、post したスレッドを先頭に寄せるという加工を施すようにした。見た履歴を追加したり削除したりする機能はまだ作ってない。
スレッドの自動追尾というものを先日作った。これはユーザの指示によってスレッドのオートリロードをオンオフするものであり、かつスレッドの勢いに応じたリロード頻度を用いるので、いわばアクティブトラッキングと言える。作った際の感想としては例えば実況スレとかよりもむしろ寝落ちしてしまった際に有効かもしれない…というのは以前書いた。ただし寝落ちするくらいフニャフニャな状態だと、自動追尾を事前にオンにしていない場合がほとんどである。これをどうするか。
というわけで今回はそれと対になるパッシブトラッキングというものを作った。これはスレッドの消える時刻を算出した際、その消える時刻と現在の時刻との中間地点で1回タイマーを仕掛け、そこで続きを読むものだ。例えばスレッドの寿命が最低1時間保証されている板でスレッドを立てた場合、30分後に自動的に続きを読む。その次は15分後、その次は7分30秒後…という調子だ。スレッドの寿命が尽きるまで追いかける機能はそのままで、アクティブトラッキングに対して続きを読む頻度は相当抑えられる。
パッシブトラッキングは常に有効で、どのスレッドでも開いた時点から動作する。ただしアクティブトラッキングとの併存はできず、アクティブ側が優先される。
めったにないことではあるが、塩辛瓶やあぷ小のファイル名をコメントに含める際、拡張子を省略する人がいる。その場合の自動リンクはどうあるべきか。
その場合、赤福プラスはいずれのアップローダに対してもファイル名の補完を試みるようになっている。塩辛瓶の場合は、補完のための JSONP インターフェースが用意されているのでそれを使う。誰が作ってくれたのか知らないけど、ありがたいことです。
さて、あぷとあぷ小のサムネイルサービスの場合はと言うとこちらも似たようなインターフェースを用意してある。https://appsweets.net/thumbnail/up2/fu99999s.js などと呼び出すと、拡張子は js だが、そのファイルの情報が json で返ってくる。なぜ js かと言えばそれによって CloudFlare のキャッシュに乗るからである。ちなみに Access-Control-Allow-Origin: * としているので cors の制限は受けない。普通に xhr や fetch で読み出せばいい。
{
"content": "data:image/png;base64,...",
"board":"up2",
"name":"fu25465.png",
"base":"fu25465",
"mime":"image/png",
"size":9152,
"comment":"",
"dimensions":{
"thumbnail":{
"width":188,
"height":250
},
"original":{
"width":300,
"height":400
}
}
}
こんな感じで返ってくる。content はサムネイル画像を data URI にエンコードしたものだ。
コメント中の自動リンク処理を整理し、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 を操作する機能が外されているからだ。
そういうわけで仕方がないのでごにょごにょっとして対応。
あぷとあぷ小がリニューアルされて塩辛瓶の仕様に近くなったのでそれに合わせて微調整。塩辛瓶のアップローダというのは拙作の 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 が送出されていない、あるいはふたばのドメインでない場合もばってんエラーになる。
ついでにそれぞれのアップローダのインデックスを開いた際にサムネイルを付加するようにした。