In my experience most apps designed around relational databases will benefit from:
- one-to-many and many-to-many mappings
- soft delete
- log tables / append-only tables
- entity-attribute-value
- meta columns (creator_id, timestamp, version, etc)
Beginning with them is way easier than patching afterwards
For the "play chess" example a state machine is the perfect place to begin modeling. Games, as a rule, are event-driven and are commonly coupled to a event-loop that triggers the transitions of the state machine. I think top-down decomposition has it's place, but the examples used to describe it should be given a little more thought.
Pointing out that the solution is not perfect is fine. It helps future maintainers, even if self. The worst offenders don't even realize the badness of their implementations, intriguing further adventurers of their code's true intentions.
My unpopular opinion is that you only forget what you have not learned and that you only learn what you do.
The vast majority studies only to pass exams. So your situation is pretty normal.
TFA is nonsense. Hard deletes should almost never be used, period. The application credentials should not even have permission to issue delete statements, thus reducing potential damage from bad actors. Things like ON CASCADE DELETE should not even exist. Anyone using them must stop and rethink their life decisions.
Truth is, our lizard brains are always forgetting the good stuff that happened but remembering every detail of some random shameful event nobody, except you, cares about.
Please don't use this project as it makes no attempt to avoid the database file from being directly downloaded. Any sane PHP project (of witch WP is not one of) has it's index.php (and any user-facing stuff) inside a 'public/' folder, never exposing the entire project and relying on the webserver to secure things with .htaccess rules.
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.
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.
"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).
Reality: - team size dominates methodology and user base size dominates architectural decisions