I'm not a huge #keyboard nerd, but I did try the X-Bows Nature a few months ago. It took something like three months between when I placed my order and when I received the keyboard, and when I got it, some of the keys didn't work. Fortunately, I got a replacement quick enough. The lighting was fun to play with sometimes, but I mostly ignored it. It took a while to get used to the orthogonal layout (the keys are in straight columns instead of having each row be slightly offset form the others)…
"But being able to pass a modifiable query as a parameter to methods without it having to regex and concat strings and such!"
Okay, good point on that one. I don't really have an answer for a case where we might want to let some code hook into a query to add a JOIN or something - query builders are good for that sort of thing.
That's not enough to get me to embrace them with open arms, though. I'd still much rather just directly write SQL queries for my own code.
"But easy switching of back-end DBMSes!"
Come on, we all know the percentage of sites that have changed/will change their DBMS without changing significant other parts of their framework is 0.00%, after rounding.
"But unopinionated developer-facing tools!"
Good response, but I'm wondering if just having a "default" DBMS with a class with queries targeting it which can then be subclassed to target other DBMSes with method overrides for queries that need to be rewritten isn't a better approach.
I've decided I really dislike query builders. For trivial queries, there's no benefit, and any time you need to do anything marginally non-trivial, like a JOIN, you're bound to end up with code more illegible than a flat SQL query. For really neckbeardy stuff like windows, the query builder probably doesn't support it at all, in which case you're either back to writing a query string anyway or breaking the query to several different queries and/or fetching too much data and massaging it in code.
Archive.org: a sewing page that never closed its font size HTML tags
(submitted by cjlm)
I seem to have spotted a bug in Safari. After changing a page's `<title>` and reloading the page, the tab "holds on" to the old page title and doesn't seem to update to the new title. This caused me to waste at least five minutes of time trying to figure out why my code changes weren't being reflected in the browser before I thought to check the source.
Did you know the ellipsis, or "three dots," is its own typographic character? On macOS, type it by pressing Option-; (semicolon), though some programs will automatically swap three periods for an ellipsis for you. On iOS, long press on the period and swipe to select the ellipsis when it appears.
Typing it this way, besides being typographically correct, ensures you'll never type two, four, or more dots when you're trying to use an ellipsis.
Pedantic Punctuation Gang approves of this message.
This is tragic and hilarious. I stumbled over https://idlewords.com/talks/website_obesity.htm which was written in 2015.
"Here’s an article on GigaOm from 2012 titled "The Growing Epidemic of Page Bloat". It warns that the average web page is over a megabyte in size.
The article itself is 1.8 megabytes long.
If present trends continue, there is the real chance that articles warning about page bloat could exceed 5 megabytes in size by 2020."
That article on GigaOm is now 10.8MB. I doubt the text has been edited
*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.
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.