More actions
Git:
Studybuddy
- HTTP
- HTML
- CSS
- LESS
- Mustache
- JS
- Node - See: https://nuxt.com/docs/api/nuxt-config#nitro
- Vue - See: https://github.com/vitejs/vite-plugin-vue/tree/main/packages/plugin-vue
- Nuxt - Test environment being built.
- Leaflet - Foundation of the map but as per the coordinate transformation the library is mostly a guideline, not a rule.
- jQuery - Too prevalent not to be familiar with.
- PHP- (We hate Laravel)
- Parsoid
- Nginx - See maintenance & downtime plans.
- SSL
- Kubernetes
- Blue/Green
- MySQL
- MariaDB
- Cargo
- MW-core
- Unix
- Bash
- Q: Why a high level framework? Why not Laravel?
- Good questions, here's the answers:
- 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.
- 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.
*Also...
- 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).