Me too. But they have FB accounts, IG accounts, TikTok accounts and so on. The share of people without any kind of social media presence or consumption is shrinking everyday.
One way to approach crime is to make the risk too big. What about punishing with death those who do identity theft and impersonation? Our society tolerates too much crime.
"Hi, I'm rvr_ member of law enforcement, someone's life is in danger, please provide customer details for IP 1.2.3.4 immediately!"
... ignoring those double impersonation swatting problems, enforcement against crimes online is really hard due to global scope. Police won't even investigate because all they find is that the hacker was some russian and they can't do anything about it.
Next time you need to take a look at PHP, those two problems can be solved by php-apcu for caching and proxysql running side-by-side with php-fpm on each server.
I see comments like this an it always confuses me. AFAIK pooling or proxying a DB is actually worse for concurrent performance, because as soon as you hit the connection limit threads start waiting. It almost always makes sense to increase your DB capacity, or move hot data to a cache.
With apcu you're going to pay the cost of serializing/deserializing the data.
If you dump your read heavy data into a PHP file on disk, that just has a return of your generated data, you can be benefit from having that bytecode compiled data stored in opcache for free (for the entire lifetime of the php-fpm service, or until you reach the maximum opcache allocateable memory).
I think that PHP gives you a few nice utilities to handle sharing, but they are problem specific. For example you might also spawn threads within a background PHP task, and there is shared memory functionality you can use in that case as well which is going to be faster than apcu or opcache.
"Realize that every code has a life cycle and will die. Sometimes it dies in its infancy before seeing the light of production. Be OK with letting go."
I cannot disagree more. Code lingers. I work on an 13 years old code base that is considered new by internal standards and it's not uncommon to see lines that haven't been touched for 10+ years.
I don't test private methods and I like to use them a lot. When refactoring, if a private method is unused, both IDE's and linters will warn you, easing the process of deleting dead code. If you extract private methods into separated classes and expose them as public methods, deleting unused code becomes hard (and harder with multiple repositories).
It takes at least one clock cycle to do anything, and clock frequency stopped increasing in the 2003-2005 time frame, mainly because of the horrible effects on power with very small feature size.
I am mostly on the SPA-hating camp. There are two issues that annoy me the most. They are not a framework's fault but some kind of "mental model" fault:
First. When doing SPAs, APIs tend to leak a lot more info than needed, opening the door to attacks not commonly seen on server-rendered pages.
Second. Applications' bundle tend to have way more than users needs, even UI's they should not have access due to security/permissions. Most developers are not even aware of this problem and don't know that sensible info/features/endpoints are leaking.
As I said before, those are not faults at the framework level, but the development style that I seed used when making SPAs always led to them.
