keymoon

> 二分探索は本当に必要でしょうか そうですね、二分探索は大した改善にはなりません。この関数を大量に呼ぶ場面もないため普通に要らないと思います(できるのでやりたがってしまいがちです。) 追記ですが、ArrayからDictionaryにしたもののvalueを取得するのはあまり好ましくないと思います。ゴリ押し感が否めない上、オブジェクトの挿入順が維持されるのは規格ではないはずです。 Standingsのように整列していることが保証されているものを舐める、または渡されるArrayが整列していることを前提とする(またはソートをする?)ことで十分だと思います。 それと、RatedRankを自前でインクリメントせずとも`result.RatedRank`を使えば良いと思ったのですが、不都合が発生しますか? > すみません、もう少し詳しくお願いします ``` JSON { "TaskResults": { "abc132_a": { "Count": 2, "Failure": 2, "Penalty": 1 }, "abc132_b": { "Count": 2, "Failure": 2, "Penalty": 0...

(Closedはミスクリックです、ごめんなさい。) Standingsを舐めた後に`results.getUserResult(userScreenName)`をして該当ユーザーのResultを取得すれば良いかなと思っていましたが、上述のようにFixedResultでRatedRankが持てていない以上Mapでやるのが良いと思いました。

流石にリジャッジの部分までは考慮しなくても良いと思います。`Failure`はざっと見たところ、`Count-CE`になりそうですね。例えACした後でも、提出をすればFailureやCountは増えるようです。(ショートコーダーの提出履歴を参照しました。) ただ、今回のそれについてはその対処で十分だと思います。ありがとうございます。

トップページへのアクセスはfetchContestInformationでも行っているので、パース処理をそっちに持ってくることはできませんか…?

`fetchContestInformation`でトップページのパースのみをした後、getTasks呼び出し時に取得に失敗していた場合は各問題ページへリクエストを飛ばすという挙動を想定していました、それならば特に問題はないと思います…?

`.reload`要素が通常は表示されなくなったのでここの修正 https://github.com/key-moon/ac-predictor.user.js/blob/a228eb46417e6d58f000079f71ce10dd55480065/src/elements/predictor/script.js#L177-L189 ユーザー名部分に無駄な空白が入っているため更に内側のspanを取得するべき https://github.com/key-moon/ac-predictor.user.js/blob/a228eb46417e6d58f000079f71ce10dd55480065/src/elements/predictor/script.js#L354

いつも使用して頂き、ありがとうございます。 # 不安感について ## 活発に更新される件 1.0時点でのアップデートは企業コンへの対応であり、1.1後のアップデートはWebpackへの移行によって生じたバグの修正や外部サーバーの負荷軽減となっています。これに関しては現状終了したものと認識しています。 後述のようにスクリプト自体を分離することを考えているため、predictorに直接関係のないアップデートは行われないようになるはずです。 そのため、更新はこの後殆ど行われなくなると考えています。 ## 外部サーバーとの通信について サーバーでは、コンテストに参加している全ユーザーの過去パフォーマンスを取得する処理を代行しています。これをユーザー毎に行わせることは非現実的なため、外部からの情報取得は避けられない物だと考えています。また、リクエストがGETのみでリクエスト内容についての見通しも確保できていると考えるため、ここの改善については現状あまり考えていません。 ただ、独自サーバーと通信している状況はあまり好ましくないと思います。優先度は低いですが、将来的にはGitHub Gist等の外部に静的データを置ける場所から読み込ませる、といった形にすることも検討しています。 ## バンドルファイルの容量が多い UserScriptの行数が肥大化して不安だと言うのは仰る通りだと思います。 「ソースコードの見通しを良くし、誰でも提供しているUserScriptと同じものを発行できるようにしよう」と、先日ロジック周りのリファクタリングとWebpackへの移行を行いました。その結果として、`user.js`ファイルの行数が更に肥大化してしまいました。 しかし、当初の目標であったソースコードの見通しの良さは確保できたと考えています。バンドルファイルが小さいがソースコードが開発者ですら難読と言った前の状態よりは多少安心できる状態になったのではないでしょうか。 しかし、`user.js`をなるべく小さくするべきだというのは変わりありません。 スクリプトの分離などの考慮材料とするため、行数の内訳を調べました。 | 行数 | 内容 | 依存されている物 | |---|---|---| | 87行...

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

論点を整理します。 - 分離によって読むべきスクリプトの量が本質的には変化せずに隠蔽されるようになったため、状況は良い方向に変わっていない - どうでもいい機能を消すべき ## 分離によって読むべきスクリプトの量が変化しない 前のコメントにて > SideMenuやData関連等、一部分のライブラリ的なものについてはこのUserScriptから切り離して@​requireで読み込むスクリプトとして発行することが考えられます。 これは以前も考えましたが、その際はユーザーの見えないところに大量のスクリプトが置かれることになってしまうのは不誠実ではないかと考えた結果現状のようになっています。 と書きましたが、まさにそのようなことですよね。これは変更を一切行わないコードを切り離すのであればよい方向に働くと思い、分離することにしました。 そのため、#38 はまさにするべき対処でした。ありがとうございます。 現実的な問題として、読むべきコードの量を減らすことは不可能です。 ビルド前のリポジトリを公開しておりバンドルファイルと同一のものを生成することができる以上、「読むべきもの」はバンドルファイルではなくリポジトリのコードだと考えます。そのため、リポジトリが機能ごとに分離されていることは、読むべきコードを簡潔にするという役割も果たしていると考えます。 ビルド後のファイルとの同一性を容易に確認できるようにするため、ビルド後のハッシュをどこかに表示させることを検討します。 ## 機能から逸脱したものを削除するということについて ### predictor自体について 私としては、sidemenuに追加されている以下の要素が「本体」だと考えています。(歴史的経緯を持ち出すのはあまり好ましくはないですが、順位表に予測レートの列を追加する機能は後に実装されたもだということからも分かると思います。)  この要素が提供するものは「コンテストページ上においてパフォーマンス予測を行う」ことであり、それは`コンテスト中にAtCoderのパフォーマンスを予測する`行為から逸脱するものではないと考えます。そのため、削除する予定はありません。 それとは別の問題として、この要素が多数にとっては使用していないものであるということは事実です。しかし、使用している人がいるということもまた事実です。以下は使用状況のアンケートを取った結果です。  [アンケート](https://twitter.com/kymn_/status/1129297672823721984) ### sidemenuの存在について コンテストページ上で邪魔にならないように要素を載せるための方法を考えた際のベストな方法だと思っています。...

あったほうがありがたいのは確かだと思います。 最低限 `INumOperator` や `IMod` 等の独自インターフェイスや、高速化の為に従うべき Tips（AggressiveInlining や static にすることでの展開）などは書くべきだと思いました。 優先度は下がりますが、AtCoder 公式のドキュメントのように全てのコードの使用例を確認できるようになると嬉しいですね。また、さらに優先度が下がりますが、document comment を定数として解釈して HTML 作成時に埋め込めるようにすると嬉しいですね。（library checker の markdown と HTML の変換では、@{[filename].[variable]}で変数を外部から埋め込むことができます。）