いつも使用して頂き、ありがとうございます。

不安感について

活発に更新される件

1.0時点でのアップデートは企業コンへの対応であり、1.1後のアップデートはWebpackへの移行によって生じたバグの修正や外部サーバーの負荷軽減となっています。これに関しては現状終了したものと認識しています。
後述のようにスクリプト自体を分離することを考えているため、predictorに直接関係のないアップデートは行われないようになるはずです。
そのため、更新はこの後殆ど行われなくなると考えています。

外部サーバーとの通信について

サーバーでは、コンテストに参加している全ユーザーの過去パフォーマンスを取得する処理を代行しています。これをユーザー毎に行わせることは非現実的なため、外部からの情報取得は避けられない物だと考えています。また、リクエストがGETのみでリクエスト内容についての見通しも確保できていると考えるため、ここの改善については現状あまり考えていません。
ただ、独自サーバーと通信している状況はあまり好ましくないと思います。優先度は低いですが、将来的にはGitHub Gist等の外部に静的データを置ける場所から読み込ませる、といった形にすることも検討しています。

バンドルファイルの容量が多い

UserScriptの行数が肥大化して不安だと言うのは仰る通りだと思います。
「ソースコードの見通しを良くし、誰でも提供しているUserScriptと同じものを発行できるようにしよう」と、先日ロジック周りのリファクタリングとWebpackへの移行を行いました。その結果として、user.jsファイルの行数が更に肥大化してしまいました。
しかし、当初の目標であったソースコードの見通しの良さは確保できたと考えています。バンドルファイルが小さいがソースコードが開発者ですら難読と言った前の状態よりは多少安心できる状態になったのではないでしょうか。

しかし、user.jsをなるべく小さくするべきだというのは変わりありません。
スクリプトの分離などの考慮材料とするため、行数の内訳を調べました。

SideMenuやData関連等、一部分のライブラリ的なものについてはこのUserScriptから切り離して@requireで読み込むスクリプトとして発行することが考えられます。
これは以前も考えましたが、その際はユーザーの見えないところに大量のスクリプトが置かれることになってしまうのは不誠実ではないかと考えた結果現状のようになっています。
ただし、その結果としてEstimatorなど分離することが望ましい機能も抱き合わせになってしまっています。
なので、ライブラリの外部エクスポートについて再検討してみることにします。(これを行うことによって #24 も副次的に達成することが可能ですし。)

しかし、これを行ったとしても800行弱のコードとなってしまうことは避けられません。(1.0時代は420行程度でした。)
SideMenuに追加されているPredictorの方の処理で100行程度取られていますが、順位表に追加する部分を取り出してみたとしても相当な行数になってしまいます。これはいくつかの部分をclassに分離したりした弊害です。そのため、この程度の行数になってしまうことはご了承頂きたいです。

結論

外部からデータを受け取らないことは不可能なので、そこの改善についてはあまり考えていません。
predictorに直接関係のないスクリプトは分離し、外部スクリプトとして読み込むことにすることを検討します。

from ac-predictor.user.js.

丁寧な説明ありがとうございます。
とても納得できました。

外部サーバーとの通信については、 AtCoder Problems にプルリクを出して内部レーティングの一覧を提供してもらうようにするのが理想だと考えています。ただし、あちらは最近は負荷がつらそうなので可能なのかは分かりません。
バンドルファイルの容量は、 800 行というのはそれ単体ではまだすこし多く感じられますが、「必要なものだけ残した結果です」との説明があれば理解できます。

from ac-predictor.user.js.

バージョン1.2.5をリリースしました。一部のライブラリを外部(atcoder-userscript-libs, atcoder-sidemenu)に分離することで行数を削減しましたが、linterの導入や、estimatorの分離を先送りにした影響で1100行程度に落ち着くことになりました。
現状の削減はこのようになりましたが、引き続き行数の削減と見通しを良くし続ける努力をしていきます。

from ac-predictor.user.js.

更新お疲れ様です。
しかし以下のふたつ理由により、この更新はかなり不満です。

1. (本体の行数は減ったが、) 悪意が存在していないことの確認のために読むべきコード全体の行数は減っていない
2. #38 に述べたもの

(1.) に関して、

「レート変化の予測をするだけの UserScript」と「お遊び機能が詰まったサイドメニューを追加する UserScript」とに分割されるとよい

と書きましたが、これはつまり「順位表に予想レートの列を増やすこと以外の機能をすべて削除してほしい」という意味 (あるいは攻撃的に言い換えれば「どうでもいい機能を消せ」という意味) です。このUserScriptの説明は以下のようなものとなっているので、過不足なく「コンテスト中にAtCoderのパフォーマンスを予測する」ことだけをするべきです。

(1.) はお互いに相手の意図を理解できていなかったことから来ているように見えます (ごめんなさい)。
「複数ファイルに分割する」というのは正直なところまったく予想していませんでしたし、おそらくそちらは「複数のUserScriptに分割する」というのを単なるファイル分割として理解していたはずです。
また、私の主張の背景にはUNIX哲学の「ひとつのことだけをうまくやれ」がありますが、そちらはあまりこういうことを意識してはいなかったのだと思います。

from ac-predictor.user.js.

論点を整理します。

• 分離によって読むべきスクリプトの量が本質的には変化せずに隠蔽されるようになったため、状況は良い方向に変わっていない
• どうでもいい機能を消すべき

分離によって読むべきスクリプトの量が変化しない

前のコメントにて

SideMenuやData関連等、一部分のライブラリ的なものについてはこのUserScriptから切り離して@​requireで読み込むスクリプトとして発行することが考えられます。
これは以前も考えましたが、その際はユーザーの見えないところに大量のスクリプトが置かれることになってしまうのは不誠実ではないかと考えた結果現状のようになっています。

と書きましたが、まさにそのようなことですよね。これは変更を一切行わないコードを切り離すのであればよい方向に働くと思い、分離することにしました。
そのため、#38 はまさにするべき対処でした。ありがとうございます。

現実的な問題として、読むべきコードの量を減らすことは不可能です。
ビルド前のリポジトリを公開しておりバンドルファイルと同一のものを生成することができる以上、「読むべきもの」はバンドルファイルではなくリポジトリのコードだと考えます。そのため、リポジトリが機能ごとに分離されていることは、読むべきコードを簡潔にするという役割も果たしていると考えます。
ビルド後のファイルとの同一性を容易に確認できるようにするため、ビルド後のハッシュをどこかに表示させることを検討します。

機能から逸脱したものを削除するということについて

predictor自体について

私としては、sidemenuに追加されている以下の要素が「本体」だと考えています。(歴史的経緯を持ち出すのはあまり好ましくはないですが、順位表に予測レートの列を追加する機能は後に実装されたもだということからも分かると思います。)

この要素が提供するものは「コンテストページ上においてパフォーマンス予測を行う」ことであり、それはコンテスト中にAtCoderのパフォーマンスを予測する行為から逸脱するものではないと考えます。そのため、削除する予定はありません。

それとは別の問題として、この要素が多数にとっては使用していないものであるということは事実です。しかし、使用している人がいるということもまた事実です。以下は使用状況のアンケートを取った結果です。

アンケート

sidemenuの存在について

コンテストページ上で邪魔にならないように要素を載せるための方法を考えた際のベストな方法だと思っています。
コンテストページ外で表示するのはおかしいということについては、estimatorを分離することによって解決します。

estimatorの存在について

これについては仰る通りだと思います。いきなり消すのは不親切であるため、移行の案内を出しつつ別のスクリプトとして分離し、最終的には削除することを考えています。

外部ファイルへの分離について

これについては意図を理解できていないところがあったと思います。
外部へのライブラリ分離については、「globalに簡単に使えるモジュールをエクスポートし、他の拡張機能の開発も促進されて欲しい」と考えていたことでもあったため、そのような方法が先行してしまいました。これについても、非ネイティブなスクリプトを前提スクリプトとして使用を推奨するのはあまり望ましくないかもしれません。

from ac-predictor.user.js.

とりあえずの目標は「読むべきコードの量を減らす」ことです。
私は、これを達成するための手段として「機能を削るべきだ」と主張しています。

#38 の問題や estimator については忘れてよいので、基本的な論点は「sidemenu を消すか、消さないか」のみだと思っています。

sidemenu を消すべきであることについて

根拠は次の2点です。ひとつ前のコメントからは実質的に何も増減していません。

1. 消せばコードが減る
2. ほとんどのユーザは主に順位表を利用している

(1.) は自明に真であり、 (2.) も事実です。

sidemenu を消すべきでないことについて

消すことに対する反論として、次の2点が提出されたと理解しています。

1. 私としては、sidemenuに追加されている以下の要素が「本体」だと考えています。

2. ... しかし、使用している人がいるということもまた事実です。

まず反論 (1.) について。
これは単に @key-moon さん自身の感情の問題であり、こちらとしては「そうなのですね」以外の言葉を持ちません。もし論理だけを追うのであれば、まったく無効な言明です。
そして、多数のユーザはおそらくはこの「本体」を本体だとは思っていないでしょう。実際私も、この事実をまったく認識できていませんでした。
自然な認識では sidemenu は本体ではなく、これは「本体でないものを消しましょう」という話なので、sidemenu は消されるべきです。

次に反論 (2.) について。
sidemenu のみを使っているユーザは 8 / (8 + 65 + 7) = 10% ということでした。10% はたしかに何も考えずに切り捨てられる量ではありません。
しかし、今回は無視してよいはずです。なぜなら、 sidemenu か順位表かの違いは「予測されたレートをどのように提示するか」の違いであり、どちらか一方だけあれば十分だからです。人間しか使わない UserScript であり実質的に同等な機能が提供され続けるのですから、後方互換性の問題は起こりません。

反論 (1.) は無効であるとして、反論 (2.) のみを考えたとき、そのような sidemenu を残すことは妥当とは言えません。コードが減って簡潔になることや、結果として残る UserScript の機能のシンプルさと比較すれば、これらの利点が勝つと見る方が自然であるように思います。

実際に消すのか、消さないのか

反論 (1.) の

私としては、sidemenuに追加されている以下の要素が「本体」だと考えています。

を主張しているということは、@key-moon さんの感情としてはこれを消したくないのだと予想できます。
もし「理屈は分かったが、それでも私はこれを消したくないのだ」とか「なんとなく嫌だ」というのを根拠に主張をするのであれば、それは尊重しますし、それでよいと思っています。

from ac-predictor.user.js.