User:Prd: Difference between revisions

Never expect others to help you. You are completely on your own from idea creation to execution and implementation.
This includes anything from both discovery of & grasping concepts, software/package intricacies, concurrency conflicts up and down the stack, race conditions, debugging scenarios, error tracking etc. It is entirely upon you to solve your problems - and sometimes other people's problems become your own to solve. Deal with it.
There is no wisdom in the notion "don't reinvent the wheel" when spoken with respect to systems architecture which is akin to a pile of dirt. These are not wheels, they are at best the tread to the tire and little more. Reinvent to fix the undeniably bad. Don't stick with incompetency merely because it's popular.
Problems are global, solutions are local.
No feature outweighs its performance needs. "Working" isn't good enough.

@@ Line 1: / Line 1: @@
 ;<small>Holder of the skeleton key.</small>
-;Upgraded to level <small>8</small>
+;Upgraded to level <big>9</big>
-Doorways to possibilities.
+[https://www.youtube.com/watch?v=qf-_bRjZ38U The Decider]
 ----
 Figure it out mentality.
@@ Line 13: / Line 13: @@
 ::KenshiDBdotWiki@gmail.com
 ----
-[https://www.youtube.com/watch?v=kbCIsCgrD-E Right on time.]
+:[[Project:Realpolitik|Realpolitik, World Revisions]]
 ----
-Defer to [https://www.mediawiki.org/wiki/User:Tim_Starling_(WMF)]
+:https://www.mediawiki.org/wiki/Manual:Job_queue/For_developers
-----
+:https://www.mediawiki.org/wiki/Manual:$wgJobTypeConf
-*Modding is not just about creating a cool black box for others to enjoy. The same ideas which enabled the tinkering should be carried forward and furthered to enable those who come after. Everyone stands on the shoulders of giants, seen and unseen, known and unknown, they are there.
+:https://wikitech.wikimedia.org/wiki/MediaWiki_Engineering/Guides/Backend_performance_practices
-*Complexity for the sake thereof is never desirable. Complexity because of a lack of alternatives is usually because of need or a lack of a ''better'' answer. In such cases it's upon the creator to offer insight beyond the veil of abstraction and obtuse systems design.
+:https://www.mediawiki.org/wiki/Database_transactions
-*If you can't explain it then you can't expect someone else to understand it (as you do). Remember how the bicycle of the mind works.
+:https://www.mediawiki.org/wiki/Manual:Job_table
-*So, in brief: It's not good enough to merely do - for if there is nothing learned then there is nothing truly gained. Build a foundation of sand and watch it wash away with the mere passage of time. The bigger the work, the bigger the ask. Such things are necessary.
+:https://www.mediawiki.org/wiki/Manual:Database_layout
-----
+:https://www.mediawiki.org/w/index.php?title=Manual:Database_layout/diagram&action=render
-=====Permissions=====
+:https://www.mediawiki.org/wiki/Extension:EventLogging
-;The free and open internet was not built by people who refused to share their findings. Either lay claim to every piece of software down to the kernel (with proof, you did build that OS, right?) or please leave your ego at the door and let's get to the real work. If you feel the need to get petty over pixels then simply don't bother at all. Content which includes licensed or copyrighted works will never be permitted on this wiki. Anyone who elects to exercise ownership rights can be assured your content will never be featured or hosted on the wiki. Input, throughput and output must be congruent with respect to the content - i.e., no topic without example, no example without explanation, etc. This is not a showcase for creations, it's a knowledge repository.
+:https://www.mediawiki.org/wiki/Extension:EventLogging/Guide
+:https://www.mediawiki.org/wiki/Extension:EventLogging/Programming
-;If you are still confused, unconvinced or need it framed in a different way, please visit, read and understand principles laid down by the Haskell Foundation as these closely align with the overall intent.
+:https://www.mediawiki.org/wiki/Architecture_guidelines
+:https://wikitech.wikimedia.org/wiki/Performance/Metrics#Save_Timing
-https://haskell.foundation/whitepaper/ ... See, '''Principles And Ethos'''
+:https://wikitech.wikimedia.org/wiki/MediaWiki_Engineering/Guides/Backend_performance_practices#Long-running_queries
+:https://wikitech.wikimedia.org/wiki/MediaWiki_Engineering/Guides/Frontend_performance_practices
+:https://wikitech.wikimedia.org/wiki/MediaWiki_at_WMF#Timeouts
+:https://wikitech.wikimedia.org/wiki/Infographics
+:https://wikitech.wikimedia.org/wiki/MediaWiki_Engineering/Guides/PHP_optimisation_tips
+:https://www.mediawiki.org/wiki/ResourceLoader/Architecture
+:https://www.mediawiki.org/wiki/ResourceLoader/Developing_with_ResourceLoader
+:https://wikitech.wikimedia.org/wiki/MediaWiki_Engineering/Guides/Measure_frontend_performance
 ----
+;Lessons I've learned
+:# Never expect others to help you. You are completely on your own from idea creation to execution and implementation.
+:# This includes anything from both discovery of & grasping concepts, software/package intricacies, concurrency conflicts up and down the stack, race conditions, debugging scenarios, error tracking etc. It is entirely upon you to solve your problems - and sometimes other people's problems become your own to solve. Deal with it.
+:# There is no wisdom in the notion "don't reinvent the wheel" when spoken with respect to systems architecture which is akin to a pile of dirt. These are not wheels, they are at best the tread to the tire and little more. Reinvent to fix the undeniably bad. Don't stick with incompetency merely because it's popular.
+:# Problems are global, solutions are local.
+:#  No feature outweighs its performance needs. "Working" isn't good enough.