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: @@
-Git:
+;<small>Holder of the skeleton key.</small>
-<br>
+;Upgraded to level <big>9</big>
-===== Studybuddy =====
+[https://www.youtube.com/watch?v=qf-_bRjZ38U The Decider]
-*HTTP
+----
-*HTML
+Figure it out mentality.
-*CSS
+*https://en.wikipedia.org/wiki/We_choose_to_go_to_the_Moon
-:*LESS
+*https://en.wikipedia.org/wiki/File:President_Kennedy%27s_Speech_at_Rice_University.ogv#file
-:*Mustache
+From signal to server, understand '''everything'''!
-*JS
+----
-:*Node - See: https://nuxt.com/docs/api/nuxt-config#nitro
+:Socials
-:*Vue - See: https://github.com/vitejs/vite-plugin-vue/tree/main/packages/plugin-vue
+::Discord - prd1847
-:*'''Nuxt''' - Test environment being built.
+::Prdandsuch on [https://www.reddit.com/user/prdandsuch/ Reddit]
-::*Leaflet - Foundation of the map but as per the coordinate transformation the library is mostly a guideline, not a rule.
+::KenshiDBdotWiki@gmail.com
-::*jQuery - Too prevalent not to be familiar with.
+----
-*PHP- (We hate Laravel)
+:[[Project:Realpolitik|Realpolitik, World Revisions]]
-:*Parsoid
+----
-*Nginx - See maintenance & downtime plans.
+:https://www.mediawiki.org/wiki/Manual:Job_queue/For_developers
-:*SSL
+:https://www.mediawiki.org/wiki/Manual:$wgJobTypeConf
-*Kubernetes
+:https://wikitech.wikimedia.org/wiki/MediaWiki_Engineering/Guides/Backend_performance_practices
-:*Blue/Green
+:https://www.mediawiki.org/wiki/Database_transactions
-*MySQL
+:https://www.mediawiki.org/wiki/Manual:Job_table
-:*MariaDB
+:https://www.mediawiki.org/wiki/Manual:Database_layout
-*Cargo
+:https://www.mediawiki.org/w/index.php?title=Manual:Database_layout/diagram&action=render
-*MW-core
+:https://www.mediawiki.org/wiki/Extension:EventLogging
-*Unix
+:https://www.mediawiki.org/wiki/Extension:EventLogging/Guide
-*Bash
+:https://www.mediawiki.org/wiki/Extension:EventLogging/Programming
-<br>
+:https://www.mediawiki.org/wiki/Architecture_guidelines
-:*Q: Why a high level framework? Why not Laravel?
+:https://wikitech.wikimedia.org/wiki/Performance/Metrics#Save_Timing
-::*Good questions, here's the answers:
+:https://wikitech.wikimedia.org/wiki/MediaWiki_Engineering/Guides/Backend_performance_practices#Long-running_queries
-:::*# A similar line of thinking as to "Why MediaWiki 1.43?". It serves the use-case and provides me access to a mountain-top view. I'm more than willing to traverse that mountain and don't want to ignore any aspect of the stack high or low. Also, I want to write in ''pure'' PHP so there's as little abstraction as possible when browsing the ocean of the MW-core and its extensions. Knowing when Laravel was utilized is good to know - it's not any more necessary than Nuxt to actually use. That said. I'm not overtly opposed to Laravel's use. I've been staring at PHP for weeks and catch snippets of JS as I go along. This is to forcefully expose myself to a JS heavy environment and '''adapt'''.
+:https://wikitech.wikimedia.org/wiki/MediaWiki_Engineering/Guides/Frontend_performance_practices
-:::*# Because I'm not actually restricting myself to the high level. As much as I want to see heavily bundled frameworks I'm spending just as much time perusing documentation on TLS, TCP/IP, HTTPS, DNS, SSL, nginx, etc. My intent doesn't stop at the wiki or the map. The path to total sysadmin is almost invariably going to be slow and filled with struggle. Wrestling with Nuxt and MediaWiki is just as important as taming nginx and cloud services. Everything matters.
+:https://wikitech.wikimedia.org/wiki/MediaWiki_at_WMF#Timeouts
-<br>*Also...
+:https://wikitech.wikimedia.org/wiki/Infographics
-:No. I will not be using Django (Python) or Rails (Ruby). Considering the ubiquitous presence of PHP on MediaWiki and the lack of integrating tooling for the aforementioned I'm left with too much added work to try and get those spun up. Time is better spent developing skills which can directly translate to the wiki. Besides, a javascript heavy approach to the map gives me ample exposure to the other big player on the wiki (especially for gadgets).  This is not about making '''the greatest map to ever exist built in the most ideal way'''. Rather, it needs to meet various functional uses and refine around those. Obviously the existing map is a rudimentary mock-up and embodies only one test of one feature (coordinate conversion).
+: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.