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.

Things I already knew

This is a means to an end. Grain by grain the whole being formed will reveal itself and its nature. There is no rushing architecture. Systems rise and fall... nothing is meant to last. Adaptation is inherent to the structural feedback loop (which must exist). It's a tool for analysis. Kenshi is merely the current medium. A shame so much lives out of view.

I've been given the go-ahead to shift from first gear to second. Summer rains...you can never expect their arrival!

There are two sides to design. Most people only partake in one. Creative production is the standard fare modus operandi for how engineer and designer types are educated. The world needs creators to bring forth new ideas, washing away the old and ushering in the new.

What is often overlooked, usually by way of organizational structure and a resultant cultural mode, is creative destruction.

For a given exercise we know there are two effective ways of approaching its execution...

Positively
Negatively

The deconstruction and inversion of functional methodologies offers a look at mutually exclusive outcomes for the net routine.

Reverse engineering is crucial to understanding. A building's life cycle doesn't end at grand opening -- there's maintainence and the eventual possibility of demolition. Each a profession unto themselves beyond architecture and construction.

@@ Line 1: / Line 1: @@
-Git:
+;<small>Holder of the skeleton key.</small>
-<br>
+;Upgraded to level <big>'''10'''</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>
+: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.
+;[https://en.wikipedia.org/wiki/Wirth%27s_law Things I already knew]
+----
+This is a means to an end. Grain by grain the whole being formed will reveal itself and its nature. There is no rushing architecture. Systems rise and fall... nothing is meant to last. Adaptation is inherent to the structural feedback loop (which must exist). It's a tool for analysis. Kenshi is merely the current medium. A shame so much lives out of view.
+:I've been given the go-ahead to shift from first gear to second. Summer rains...you can never expect their arrival!
+:There are two sides to design. Most people only partake in one. ''Creative production'' is the standard fare modus operandi for how engineer and designer types are educated. The world '''needs''' creators to bring forth new ideas, washing away the old and ushering in the new.
+:What is often overlooked, usually by way of organizational structure and a resultant cultural mode, is ''creative destruction''.
+:For a given exercise we know there are two effective ways of approaching its execution...
+::#Positively
+::#Negatively
+:The deconstruction and inversion of functional methodologies offers a look at mutually exclusive outcomes for the net routine.
+:Reverse engineering is '''crucial''' to understanding. A building's life cycle doesn't end at grand opening -- there's maintainence and the eventual possibility of demolition. Each a profession unto themselves beyond architecture and construction.