ファイルには 2805 以上の不適切な単語が含まれていますが、許可されているのは 2000 件までです。どうすればさらに単語を追加できますか？テキストファイルから 10,000 件の不適切な単語を追加したい場合、どのようにすればよいでしょうか？現在、最大 2000 件のエントリしか追加できないようです。
現時点では、この制限を引き上げる予定はありません。これが決定的な問題である場合は、プラグインの作成または発注を検討してください。
「いいね！」 2
監視対象の単語を使用して繰り返しスパムに対処する際に、この制限に達する可能性があることに気づきました。OP（元の投稿者）のためでなくとも、将来他の人が役立つかもしれないいくつかの考えがありました。
コードを変更せずにこれに対処する方法は、Using Regex with Watched Words に切り替えて、多くの単語を単一の正規表現に組み合わせることです。正規表現に慣れていないと間違えやすいですが、技術的には可能です。（正規表現を知っているので、私はこの方向に行く可能性が高いです。）
さらに、ここにプラグインを記述するには2つの方法があると予想されます。
2000の制限がある理由は、アルゴリズムのスケーリングがあまり良くなく、同期的に実行されるためですが、これは任意の制限です。単純なプラグインは、パフォーマンスの低下を受け入れるために2000単語の制限をモンキーパッチできると予想されます。しかし、私自身は10000エントリに対してはそうしません！
もう1つの、おそらく補完的なアプローチは、フラグ付け専用の別のリストを持ち、各投稿の作成/編集に対してトリガーされるsidekiqジョブから非同期で実行することです。
「いいね！」 1
他の人もそうですが、私もこの道を通ってきました。
- リストから始める、おそらく現在のGitHubリポジトリからダウンロードしたもの。
- すぐに2000エントリの制限に達する。
- ああ、正規表現が使える！素晴らしい！
- 複雑な正規表現は簡単に100文字を超える。
- それらを分割する。
- 正規表現を改良する、しまった、これも100文字を超えてしまった。
- さらに分割する。
制限との格闘は不可能ではありませんが、特に制限が人工的なものである場合、単に面倒なだけです。とはいえ、このフィルタリングは同期的に行われ、処理が長引くとパフォーマンスの問題が発生する可能性があることは理解しており、可能な限り多くのユーザーに適した制限を設定することの難しさも理解しています。そのため、制限には苦労していますが、合理的に反対することはできません。
フィルタリングのコードはword_watcher.rbにあります。開発者としては、プラグインを作成してこの問題を解決したいと思いますが、そのコードは拡張性が低いように見えます。プラグインでJavaScriptをフックしてRubyプロセスを拡張する方法がわかりません…あるいは、word_watcherのコードの書き方でそれが可能かどうかさえわかりません。
広範なリストの処理の負担を軽減するのに役立つ機能強化のアイデアを以下に示します。
ウォッチリストの各タイプに対してリスト全体を処理するのではなく、フィルタのさまざまなブロックをループすることを検討してください。たとえば、最も一般的で悪意のあるフィルタをblock1に、その他をblocks2-nに配置できます。同期フィルタプロセスは一度に1つのブロックのみを処理し、最終的なSave操作でのみすべてのフィルタを完全にループします。ブロックは既存のリストで動作するため、誰かが変更を加える必要はありません。既存のリストは1000エントリのブロックに分割されるため、block1は1〜1000、block2は1001〜2000などとなります。最適化したい管理者は、優先度の高いフィルタをリストの上位に移動できるようになります。
これの利点は、問題を検出するためにリスト全体を処理する必要がないことです。最も可能性の高い問題は、より小さなブロックで検出され、同期プロセスはより小さなブロックの処理からより早く戻ることができます。確かに、watch-textが最初のブロックで見つからなかった場合、別のブロックを処理する必要があります。これは、可能性の低い悪用を検出するためのわずかなオーバーヘッドです。これはオプションの調整の問題になります。誰かが気にするなら。
ここでの追加のオプションは、管理者がブロックのサイズを選択できるようにすることです。ブロックのサイズを小さくして、たとえばループサイクルのエントリを500にすると、各同期プロセスはより速く実行されますが、処理するブロックが増える可能性があります。これは、どのような種類の悪用が存在するか、およびリストがどの程度優先順位付けされているかによって異なります。これもまた、このような調整はオプションであり、実際、多くの管理者はこのような調整をあまり行わないでしょう。
注記、微調整は、定量化可能なメトリックがあることを意味します。ウォッチワード処理にどれだけの時間を費やしており、実際にどれだけの問題を検出しているのでしょうか？このオタク的な詳細レベルは、後で機能強化するか、本当に望ましい場合はプラグインに任せるべきです。
最終的に、「ウォッチワードブロック処理」がここで説明されているように実装された場合、リスト内の項目の数を2000以上に拡張できます。はい、長いリストを読み取って分割する際にはいくらかのオーバーヘッドが発生します。ここでも、このプロセスに費やされる時間に関するメトリックがあれば、管理者は最適化のしきい値を自分で決定できます…しかし、多くの人がこれに深く入り込むとは思いません。公開されるガイドラインは、「ウォッチワードブロック処理なしでは、ウォッチワードの制限は2000のままです。ブロック処理を使用すると、特定の制限はありませんが、実用的な制限は約5000と推定でき、エントリ数が増加するにつれてパフォーマンスの低下が顕著になります。」のようになる可能性があります。
これはうまくいきますか？
結局のところ、これをサーバーで行えば、「無限」のサイズで投稿を単語に分割し、その後「ブロック」テーブルに対して単一のクエリを実行できます。最悪の場合でも、それは1回のテーブルスキャンになります。
巨大なブロックリストが必要な場合は、カスタムプラグインの構築をお勧めします。
「いいね！」 2
私が学んだ20以上のプログラミング言語や方言のうち、Rubyはその一つではありません。そのため、ゼロからプラグインを作成することは、私にはできない挑戦だと思います。他の言語でなら喜んで作成しますが、あるいは誰かが担当するまで待つことにします。
ありがとうございます。
このような問題が発生しました: Hit the blocklist limit for blocking words on the forum
この制限は10,000に引き上げるか、必要な単語数に応じてカスタマイズ可能にできると思います。