google-search-title-qualified
google-search-title-qualified copied to clipboard
ncaq
Google will omit the title of the web page. With this add-on, the original title is used as much as possible.
殆どのページは問題ないけれど、 [確認の際によく指摘される項目](https://www.amazon.co.jp/hz/reviews-render/lighthouse/B01KWNPJDM?filterByKeyword=%E5%8B%9D%E6%89%8B%E3%81%AB%E8%B3%BC%E5%85%A5&pageNumber=1) タイトルがあまりにも多すぎるので展開した方がストレスが少なそう。 元からこれが全てのタイトルなので汎用的に対応出来ない。 別にcurlでも取得できるのでbot対策はしてないっぽいので解析して、 `商品名 | 検索ワード | Amazon`という形にするのが良さそう。 レビューでも要望は出ている。
これまで、 [autopagerに対応 · Issue #12 · ncaq/google-search-title-qualified](https://github.com/ncaq/google-search-title-qualified/issues/12) で問題なかったが、Googleが明示的なページ分割ではなく繋がっている形で動的にシームレスにぬるっと要素を付き足すようになったので、これまで対応していたイベントが発生しなくなった。 イベントキャッチや画面の位置など、何らかの方法でページが継ぎ足されたことを検知して追加で読み込む必要がある。 ただまあ100件表示にしていれば今の検索結果を絞るGoogleの仕様だとどうせ10数件ぐらいしか追加されないので優先度はそこまで高くない。
検索エンジンに引っ掛けるだけのスパムサイト多すぎ。 事前に確認できると便利。 せっかく全部にアクセスしてるのだから確認するコストが無い。
いい加減出しておきたい。 最近安定してきた気がするし。 Manifest v3以前に出すと良いと思う。 Manifest v3対応がバージョン2で行われるのはちょっと奇妙ですが。 出来れば自動デプロイが出来るようになってから出したいと思うんですが、 Firefox for Androidで実行できるということが自動的についてしまう状態だと難しいかも。 [web-ext-deployを使用する · Issue #86 · ncaq/google-search-title-qualified](https://github.com/ncaq/google-search-title-qualified/issues/86) を先にやるか悩みどころ。
uBlacklistでせっかくブロックしたスパムサイトのタイトルは取得しても時間の無駄ですし、心情的にもアクセスしたくない。 displayStyleとか取得して表示されてるか調べれば良いはず。
* [バージョンタグ付けたらCDでMozilla Firefoxアドオンストアに自動でデプロイされるようにする · Issue #86 · ncaq/google-search-title-qualified](https://github.com/ncaq/google-search-title-qualified/issues/86) * [バージョンタグ付けたらCDでChrome Web Storeに自動でデプロイされるようにする · Issue #119 · ncaq/google-search-title-qualified](https://github.com/ncaq/google-search-title-qualified/issues/119) をやる上で、 もうCircleCI使うより基本的にGitHub Actionsの方が楽そうだし、 もしActionsを自作するとなるとますます移行したほうが楽そうなので移行する。 最初はlintだけでも良い。
[バージョンタグ付けたらCDでMozilla Firefoxアドオンストアに自動でデプロイされるようにする · Issue #86 · ncaq/google-search-title-qualified](https://github.com/ncaq/google-search-title-qualified/issues/86) からの分離。 Chromeの方は雑に受け付けているのか、 既にActionsが多数あるので個別に実行したほうが良さそう。 ビルドは工夫して受け取らない限り2回走るけど、 この規模のプロジェクトでリリース時にのみesbuildとweb-extが2回走ったところで大した時間のかかる問題ではない。
ネットワークやマシンスペックによってはデフォルト設定だと負荷が重いかもしれないため。
特に複雑な部分も無いから良いかと、 特にbackgroundに関しては分割していませんでした。 しかし、 これはHaskellではなくTypeScriptなのでミュータブルなグローバル変数があるので、 ある程度分割した方が読みやすいでしょう。
[avi12/web-ext-deploy: A tool for deploying WebExtensions to multiple stores.](https://github.com/avi12/web-ext-deploy) を使用して、CircleCIによる自動デプロイをやめる。 web-ext-submitと違ってソースコードを提出できるのでMozillaに怒られないだろう。