my [hazardous] workflow

i've been promising myself for years that i'd sit down and write this post1. i finally got around to it because louisiana just had - of all things - a massive, city-shut-down snow storm. 2021 is already wild.

when i really thought about it, however, i realized there wouldn't be much to this post. i mean - there will be, but it's deceptively simple. as an example, i will screenshot this post as i see it in editing: when i save the file, it will update in realtime because it's being edited on the server itself.2

hopefully this screenshot illustrates my favorite part of my current setup, which is that i am free to focus on content. the website more or less organizes itself, so to speak: folders in the webroot/page directory are treated as categories. therefore writing a music-related post means opening up VScode, remotely connecting to the server, and opening a new file in the webroot/page/audio subdirectory. this post was created in the webroot/page/blog subdirectory, and is therefore treated as being a child of the blog category.

however, this simplicity took alot of work and alot of moving parts to pull off. i'll try to run through the most significant tools i use in maintaining this site.

big-picture tools

these are tools which are used in this workflow, but are part of my overall, wide-scope bag of utilities i use not only for web development but as general tools for anything computer-y.


github shouldn't be a surprise. it's a hella useful tool - i keep a copy of the website in a private repo, and routinely back the site up by pushing new commits.

but beyond that it's still a great place to find inspiration - just browsing through all the public repos to find neat stuff.


if you use windows 10 and enjoy coding or even just kinda tech-y stuff in general, you should be using WSL.

i stumbled upon WSL when it was first announced accidentally - at the time i didn't particularly subscribe to tech news type stuff, so it's pure chance i came across an article announcing WSL.

i'm glad it happened because i've had a front row seat to its growth from a somewhat awkward novelty to a very tightly integrated and useful part of windows 10 that i can no longer see myself being able to go without.


something about skipping a big period of web development was the shock of returning to the internet to build a website with my old, trusted, apache2 server. i cannot describe how unbelievably alien the concept of 'deploying an app' via 'ruby-on-rails' was.

the mistake i kept making was this notion that something like 'rails' or 'yarn' was just another cog that 'plugged in' to the underlying webserver.

however, i've discovered that in a world dominated by app-driven development powered by pre-baked deployment... the "server" side of webservers has become a sort of separate thing that web developers do not necessarily have to worry about. they program an app, and trust a set of dependencies to wrap a production-grade website around it - deployed through docker which they trust to build their environments for them.

i love being able to publish a blog the old fashioned way, because it's become so damn cheap to do so. i can spin up a low-spec server with an Ubuntu server image, compile a highly optimized build of nginx, and squeeze every bit of inefficiency from the connection between server and browser. doing all of this requires knowing the linux environment, and as a result my overall security is always as effortless as it is thorough. my ports are locked down. i do not rely on sudo to force programs started by users, making it that much harder to gain root from a potentially compromised vector. i handle my TLS connection with Let's Encrypt and stay on top of the latest security enhancements to keep hazardous secure and fast, such as http/2 and even http/3 :)

my take on vim/vscode

i love using vim. i love using vscode. in my opinion each is perfect for certain situations. when i'm on my main PC, i usually run with vscode because it's just a very polished code editor. i don't mean polished in the sense that it's well-written (though it likely is) - i mean it in the sense that vscode just looks great.

but i have not abandoned vim, because vim is too useful when i find myself working on another computer - especially remote servers. you can configure it to be as lean or as feature-packed as needed. most importantly, it's almost universally avaliable across linux and even OS X machines.

hazard coutoure

these are tools i use solely in the context of maintaining this website.


this section probably deserves its own post. markdown has singularly changed the way i keep myself organized - by making text files workably useful again as a medium.

mecha CMS

mecha is a php-powered server-side CMS built on the sort of principles that inspired more hardcore static-site type projects.

it doesn't go the whole way like orthodox SSG's - it lives on the server. but it does read directories and files the same way something like Hugo does, so i can just upload markdown-formatted pages to a directory and voila, the formatting and URL structure create themselves.

all-around great piece of software, and a great project to use that will let you dive into PHP and learn the ins and outs of it, without being too simple (like a single-page project) or too complex (ie anything using php's partner-in-crime, MySQL)


welp that's it. insert concluding statement here!

  1. not gonna lie i feel like i am betraying my reader base by actually writing this and not procrastinating 

  2. the post is saved as an *.md file, which my CMS code treats as 'unpublished' pages. by simply renaming the file with a *.page extension, the file is treated as a live page, and the CMS renders the markdown.