The television show Twin Peaks was formative for me. When I was very young and it was on TV, I was way too young to be interested in grown-ups talking on TV. Then my aunt who provided me with my first computer and my first joint showed me a single wild and twisted scene from the show that she had recorded wherein a young woman tells the story of a dream-premonition that comes true. Later in life, after watching The Elephant Man and Eraserhead, a friend of mine was like “Have you ever seen the TV show Twin Peaks directed and written by David Lynch?” As the pilot started I felt strangely connected to the show and it’s characters. By the time Maddy arrives in Twin peaks, I’m Rick Dalton:
Long story short, I believe that all knowledge one needs to recover from the trauma of discovering that you are the beneficiary of privilege and not the product of excellence is buried within Twin Peaks and one must simply unpack it. At the beginning of the second season, a freshly hair-plugged Billy Zane playing John Justice Wheeler arrives to offset the maladies of the Horne family. He’s a known good-deed-doer who hasn’t been influenced by the supernatural evil of Twin Peaks. Ben Horne, a wealthy businessman and patriarch, asks him what the secret to being a good person is and his response is the single greatest piece of advice I’ve ever heard:
“Always tell the hardest truth first”.
When this advice found me, I was growing into a person who stands by their morals and isn’t flustered by unqualified influences. In the spirit of telling the hardest truths first, I will admit that I spent all week last week struggling to move my project forward. I am working on a fairly generic social media app that when finished should show off that I kind of vaguely know what I’m doing when it comes to being broadly useful at a company that wants to host a web app or website. In order to really send that point home, I think I’m gonna have to host this thing somewhere. When I was in a position that saw me hiring developers, I certainly never would have run code presented as part of an employment application, but I would look at code while playing with a deployed project, so that’s what I intend to do. There are several options for hosting a Laravel app but none of fulfill me, so I’ve decided that I’m going to use Ansible to write a configuration playbook and a deploy playbook so I can launch my app on a VPS…or I may opt to host it locally on my network and use a Cloudflare Tunnel to serve it publically, which would allow for a quick and clean teardown after I’ve given up caring. Either way, I started the week with a plan, and by day two I already needed to have a hard talk with myself: I don’t know how to set up a system to run Laravel; my SysOps skills are limited to the specific features that I had built in the past and I had never built a Laravel environment from scratch.
So I bailed on Ansible and instead decided that I would just document my experience of getting a Laravel environment up and running on a local VM. This is where I should have been focusing my attention since day one, but now I feel behind and unproductive. With a little knowledge and lot of documentation I got my laravel app installed on my local VM, I installed a database for persistence, I configured a few performance tools, and then I set about getting websockets configured. I just wrote an article on the topic so it would be a glaring omission. That’s when I hit a second major wall. My initial development configuration was fairly easy to set up, but now that I had moved on to a new context, it felt like nothing was working. I had read tons of articles, documents, and tutorials and it seemed like I had everything configured correctly. For a moment, I considered just throwing in the towel and that perhaps I could use my development set up to deploy my app since it seemed to magically solve my problem. And that was just the sour thought that led me to solving my problem.
My development server used a script to bring up the two services needed to run the websocket feature. In my production server, both services were running, but I couldn’t remember which I had started first, so in order to make sure that my development and production environments mirrored each other, I tested the theory by turning off, then turning on both servers in the order they were booting in the script. Maddeningly, this fixed the problem. It’s great to see it working. In fact, I love that it was a configuration issue, but I spent all my spare time for three days thinking about it, and the answer was something that I had already identified as something that would have to be completed before I could deploy to production. So here’s the hard truth: I got distracted by a shiny object, and then let failure stop progress. I need to be better about compartmentalizing problems and working more fastidiously. I need to work from a “known” towards an “unknown”, and don’t start my journeys in the dark.
I’ve been working with or on admin software as a part of my job for twenty years. I do not need to be told to reboot it. If I’m asking for help, I’ve either restarted the process, restarted the service, or rebooted the machine. This whole week was a lesson: trust yourself, follow your own rules, don’t be fooled by misdirection. Since I put the stick in my own spokes, I guess the rule that I should consider going forward would be: “If you can’t find the issue in the code, check the mirror.”