*Way* too many "Seeking Freelancer" posts in the current HN freelancer thread are asking for React experience.
Maybe I should just swallow my pride and learn it already, even though I have never *not* despised these ridiculously massive front-end frameworks that turn things that should be simple web pages into slow, heavy "web applications." (You know, like Mastodon.)
…and append another text node with the rest of the text with the original node… unless the text in *that* node has a profanity hit…
Yeah, after rubber-ducking it, I think I'll do it before the Markdown parsing. Not correct, but the client was hoping to launch this part of the project this week…
I'll be using stemming when checking for profanity, by the way, so that if "poop" is in the list, "poopy," "poops" and "pooping" will all be hits. Trying `wamania/php-stemmer` for now. Open to others.
I guess doing it after the Markdown parser has run and you have something similar to a DOMDocument before it gets serialized to HTML (we're using `league/commonmark`). But that code is weird and I don't like using it.
I guess doing it before the Markdown parsing would be simplest. But doing it with the DOMDocument seems the most correct; find all the text nodes and look in those. But if there's a hit, I have to truncate the text in the original node, append the "profanity removed" node, create…
Today I am implementing a profanity filter on a "comment" field (certain bad words get replaced with `<em>profanity removed</em>`) which takes Markdown input and saves the processed HTML (and the original Markdown) in the database. The pipeline to do this takes the HTML, loads it into a DOMDocument, does some more mangling on it (for example, removing external links), then reserializes the HTML before it hits the database.
At what point would you do the filtering?
Of course, as I'm rubber-ducking this, I'm remembering that the Unix-timestamp-in-INTEGER approach actually *does* "store the time zone" since that will always be in UTC. Hmm.
Recently I've been leaning towards TIMESTAMP with query functions to convert back to UTC. I almost never need to insert a real date into my data and instead use `DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP` for most fields anyway. And maybe the query optimizer is smart enough to just keep the date in UTC rather than converting back and forth. Who knows how those things work. And none of my current code will still be used in 2038… right? That would be silly.
Friendly reminder that, in the Year of Our Lord 2021, our options for storing dates in MySQL are:
- Unix timestamp in an integer field. Not human readable; no sub-second precision (if needed); no time zone.
- DATE/DATETIME. No time zone.
- TIMESTAMP. Dates converted from "local time" (whatever that is) upon storage and converted back upon retrieval unless using functions in your query to convert it to something else. Y2K38 issues (only 17 years away…)
Which crappy option is best?
Tabs vs Spaces
Found my old Raspberry Pi 1 the other day. I *think* it's a Model B… trying to figure out what to do with it. I recall having the same problem when I originally got it. Any ideas?
Incidentally I originally bought it used with Dogecoin, back when Dogecoin was worth a whole lot less than it is now. So by some standards it's quite possibly the most expensive Raspberry Pi in history.
Professional web developer since 2007, using mostly PHP. Currently freelancing and totally hireable. ウェブ開発者。PHPを大体使えます。フリーランス中。
Open source. Open community. We are dedicated to building and enriching the PHP community.