Comme d’autres, j’ai suivi ce chemin :
- Commencer par une liste, peut-être téléchargée à partir d’un dépôt GitHub actuel.
- Atteindre immédiatement la limite de 2000 entrées.
- Oh, je peux utiliser les expressions régulières (Regex) - génial !
- Les expressions régulières complexes dépassent facilement 100 caractères.
- Les diviser.
- Affiner une expression régulière, oops, elle a également dépassé 100 caractères.
- La diviser encore plus.
Jouer avec les limites n’est pas prohibitif, c’est juste agaçant, surtout lorsque les limites sont artificielles. Cela dit, je comprends que ce filtrage est synchrone et que le traitement prolongé peut créer des problèmes de performance, et j’apprécie la difficulté d’établir des limites qui conviennent au plus grand public possible. Donc, même si je lutte avec les limites, je ne peux pas raisonnablement être en désaccord avec elles.
Je vois le code de filtrage ici dans word_watcher.rb. En tant que développeur, je serais heureux d’essayer d’écrire un plugin, mais ce code ne semble pas extensible. Je n’aurais aucune idée de la manière de connecter JavaScript dans un plugin pour augmenter les processus Ruby… ou si cela est possible avec la façon dont le code de word_watcher est écrit.
Voici une idée d’amélioration pour alléger le fardeau du traitement de listes étendues.
Plutôt que de traiter la liste entière pour chaque type de liste de surveillance, envisagez une boucle à travers différents blocs de filtres. Par exemple, nous pouvons placer les filtres les plus courants et abusifs dans le bloc1 et les autres dans les blocs2-n. Le processus de filtrage synchrone ne traitera qu’un seul bloc à la fois, et ne fera une boucle complète à travers tous les filtres que lors de l’opération d’enregistrement finale. Les blocs peuvent fonctionner sur des listes existantes, il n’est donc pas nécessaire que qui que ce soit apporte une modification. Les listes existantes seront divisées en blocs de 1000 entrées, donc le bloc1 est 1-1000, le bloc2 est 1001-2000, etc. Les administrateurs qui souhaitent optimiser peuvent maintenant choisir de déplacer leurs filtres prioritaires plus haut dans la liste.
Un avantage est que la liste entière n’a pas besoin d’être traitée pour détecter un problème. Les problèmes les plus probables seront détectés avec un bloc plus petit et le processus synchrone pourra se terminer plus tôt après le traitement du bloc plus petit. Bien sûr, si le texte à surveiller n’est pas trouvé dans le premier bloc, un autre bloc devra être traité. Cela représente une légère surcharge pour détecter des abus moins probables. Il s’agit d’une question de réglage optionnel - si quelqu’un s’en soucie jamais.
Une option supplémentaire serait que l’administrateur choisisse la taille des blocs. En réduisant la taille des blocs, peut-être à 500 entrées par cycle de boucle, chaque processus synchrone sera plus rapide, mais il pourrait y avoir plus de blocs à traiter. Cela dépend du type d’abus présent et de la façon dont la liste est priorisée. Encore une fois, ce type de réglage serait facultatif, et franchement, je doute que de nombreux administrateurs effectuent beaucoup de réglages de ce type.
Notez que le réglage fin implique que nous ayons des métriques quantifiables : combien de temps passons-nous dans le traitement des mots à surveiller et combien de problèmes capturons-nous réellement ? Cette quantité de détails nerdy devrait être laissée pour une amélioration ultérieure ou un plugin si c’est vraiment souhaitable.
En fin de compte, si le « traitement par blocs de mots à surveiller » est implémenté comme décrit ici, le nombre d’éléments dans la liste peut être étendu au-delà de 2000. Oui, il y aura une certaine surcharge à lire des listes plus longues et à les diviser. Encore une fois, si nous avons des métriques sur le temps consommé dans ce processus, les administrateurs peuvent déterminer leur propre seuil d’optimisation… mais je doute que beaucoup de gens s’y plongent profondément. La ligne directrice publiée pourrait être quelque chose comme « La limite reste de 2000 mots à surveiller sans traitement par blocs de mots à surveiller. Avec le traitement par blocs, il n’y a pas de limite spécifique, mais la limite pratique pourrait être estimée à environ 5000, avec une dégradation notable des performances augmentant avec le nombre d’entrées. »
Y a-t-il une chance ici ?