Como outros, já passei por isso:
- Comece com uma lista, talvez baixada de um repositório atual do GitHub.
- Imediatamente atinja o limite de 2000 entradas.
- Ah, posso usar Regex - incrível!
- Regex complexas facilmente ultrapassam 100 caracteres.
- Divida-as.
- Refine uma Regexp, ops, ela ultrapassou 100 caracteres também.
- Divida-a ainda mais.
Lidar com limites não é proibitivo, é apenas irritante, especialmente quando os limites são artificiais. Dito isso, entendo que essa filtragem é síncrona e que o processamento estendido pode criar problemas de desempenho, e aprecio a dificuldade de tentar estabelecer limites que funcionem para o maior público possível. Portanto, embora eu lute com os limites, não posso discordar razoavelmente deles.
Vejo o código para filtragem aqui em word_watcher.rb. Como desenvolvedor, ficaria feliz em tentar escrever um plugin, mas esse código não parece extensível. Eu não teria ideia de como conectar JavaScript em um plugin para aumentar os processos Ruby… ou se isso é possível com a forma como o código word_watcher é escrito.
Aqui está uma ideia para uma melhoria para aliviar parte do fardo de processar listas extensas.
Em vez de processar a lista inteira para cada tipo de lista de observação, considere um loop através de diferentes blocos de filtros. Por exemplo, podemos colocar os filtros mais comuns e abusivos no bloco1 e outros nos blocos2-n. O processo de filtro síncrono processará apenas um bloco por vez e fará um loop completo por todos os filtros apenas na operação Salvar final. Os blocos podem operar em listas existentes, portanto, não há necessidade de ninguém fazer uma alteração. As listas existentes serão divididas em blocos de 1000 entradas, então o bloco1 é 1-1000, o bloco2 é 1001-2000, etc. Administradores que gostariam de otimizar agora podem optar por mover seus filtros de maior prioridade mais para cima na lista.
Uma vantagem disso é que a lista inteira não precisa ser processada para capturar um problema. Os problemas mais prováveis serão capturados com um bloco menor e o processo síncrono poderá retornar mais cedo do processamento do bloco menor. Claro, se o texto de observação não for encontrado no primeiro bloco, outro bloco precisará ser processado. Isso se torna uma questão de ajuste opcional - se alguém se importar em fazer isso.
Uma opção adicional aqui seria o Administrador escolher o tamanho dos blocos. Ao reduzir o tamanho dos blocos, talvez para 500 entradas por ciclo de loop, cada processo síncrono será mais rápido, mas pode haver mais blocos para processar. Isso depende do tipo de abuso presente e de quão bem a lista é priorizada. Novamente, esse tipo de ajuste seria opcional e, francamente, duvido que muitos Administradores fariam muito ajuste como esse.
Observe que o ajuste fino implica que temos métricas quantificáveis: Quanto tempo estamos gastando no processamento de palavras de observação e quantos problemas estamos realmente capturando? Essa quantidade nerd de detalhes deve ser deixada para uma melhoria posterior ou um plugin, se for realmente desejável.
Em última análise, se o “processamento de blocos de palavras de observação” for implementado como descrito aqui, o número de itens na lista pode ser estendido além de 2000. Sim, haverá alguma sobrecarga na leitura de listas mais longas e na divisão delas. Mais uma vez, se tivermos métricas sobre quanto tempo é consumido neste processo, os Administradores podem determinar seu próprio limite para otimização… mas duvido que muitas pessoas se aprofundem nisso. A diretriz publicada pode ser algo como “O limite permanece em 2000 palavras de observação sem processamento de blocos de palavras de observação. Com o processamento de blocos, não há limite específico, mas o limite prático pode ser estimado em cerca de 5000, com degradação notável de desempenho aumentando à medida que o número de entradas aumenta.”
Algum progresso aqui?