Can reach it here: wiby.me/chat
The source can also be looked at from there. The idea is to make it work on pretty much any browser on any system from the last 30 years, and fit on a 9" mac. Anyhow, I am looking for some free labor to test it out.
Thank you in advance.
The way it is implemented, you’ll also have quite a few false positives (https://en.wikipedia.org/wiki/Scunthorpe_problem)
Also, is it common idiom in Go to both defer f.Close() and manually call f.Close()? Seems noisy to me (and would, in many other systems, give an error when the deferred code tries to close an already closed file)
Other issue: from glancing at the code, the 403 page doesn’t seem to return a 403 status code.
Agreed, its not efficient.
>The way it is implemented, you’ll also have quite a few false positives
Yes. The filter is only for a handful of swearwords, I wouldn't bother making it larger since people can easily circumvent it with various characters.
>Also, is it common idiom in Go to both defer f.Close() and manually call f.Close()? Seems noisy to me (and would, in many other systems, give an error when the deferred code tries to close an already closed file)
Honestly, I don't know. This was just based on some file io tutorials I referenced. Might be able to not have that defer statement at all. I haven't tried.
>Other issue: from glancing at the code, the 403 page doesn’t seem to return a 403 status code.
Good catch.
That’s not the problem I mentioned. False positive means cases where your filter thinks it sees a swear word, while there is none. Cases where there are swear words that the code doesn’t detect are false negatives.
”Might be able to not have that defer statement at all”
That wouldn’t be robust. defer guarantees the file gets closed, no matter how the function is exited. That’s what you want (almost all the time). It’s the close just before returning that’s superfluous.