Hi, I’m Andrew. I build custom hardware and forecasting simulations.

  • Paper feels good to write on.

    ^Title, but also it is really hard to create tables and automatically format in a way that pen and paper can. I can’t really get into a ‘train of thought’ on the computer simply because what I want to say can’t be articulated into a single concept. Most of these posts that feel a bit like a cloud that I have to flatten down and square off. There is always just a little bit more that I want to add, but for the sake of brevity – paper feels nice to write on.

  • I got a oscilloscope!

    A Rigol DSO804 to be specific. Now I can finally diagnose some of the issues that have been plaguing my Motor Controller.

    I verified that the 12 volt rail was not coupling with the 3.3v signal line, but the DRV8825 driver soldered to the board is apparently just a cheap knockoff. The nasty screeching sound caused by~ 12kHz pulsing is partially due to a chip malfunction, although my lack of consideration for EMI didn’t make diagnosing the issue easier.

    The third PCB revision is underway having now ironed out most of the most pressing and obvious issues – although the tarrifs are going to make getting the right components a bit harder.

  • Proofreading…

    Sometimes I read this as “proo-freading” or “Professor Eading”, sometimes I look at a word for so long that it ceases to be real anymore. I’ll read the same text over and over again trying to find errors and eventually I simply begin to ignore the obvious mistakes. Faced with a wall of text, no matter how riveting the story, no matter the importance, I begin to find my eyes skipping sentences, darting around the page looking for the end. It occurs to me that this problem is entirely unique to myself, but judging by the vast amount of literature detailing this exact problem and how to fix it… it probably isn’t.

    SEMANTIC SATIATION

    Once in junior high, I was waiting to go on stage for some rehearsal – I forget for what. The only thing I remember was that I was in a distinctly itchy version of formal wear, with not much to do. This was before I had a smart phone, which were common, but not yet ubiquitous – so there was nothing to satiate my boredom, but the pencil I had in my pocket and some bits of tissue paper. being a teenager, the funniest thing that I could think of was the word “taco”. for the next thirty minutes, I wrote the word taco, over and over, until the piece of paper was covered – with bits of the word stuffed in between lines, and eventually spilled onto the desk. I don’t know why or how it began, but eventually, I covered a section of the desk too. (Don’t worry – the desk was hardened acrylic, I could wipe it off.)

    Somewhere along the line, the word taco ceased to mean “taco” and started to become a jumble of letters, -c-o-t-a-c-, repeating endlessly on paper. Eventually, the letters themselves stopped being letters and more like a repetition of sounds and symbols; that ‘c’ simply became another curve, flowing into another.

    DUCKING THE ISSUE

    Interestingly enough, there is another solution that comes from the software engineering mythos – explain your problems to a rubber duck and you will find a solution. Doesn’t it seem strange? I suppose when you try to explain it to someone smarter than you – you assume that they already have answers and that you are missing something. Explaining to a duck means that you have to organize your own thoughts before having it all spill out of your head.

    Maybe it seems crazy to an outsider – but I suppose Wilson the Volleyball would have been an excellent help in modern problem solving.

    E-READERS AND SCREENS

    When it is all a bit too much to read on a screen, I just print it out. Sometimes the shift from the digital to the physical helps me take a step back and review the things I have written with a more critical eye. The same thing happens with books; the physical pages gives stories something and I take a just a little bit longer to read them.

  • Migrating to Caddy

    Didn’t I say that this was a production server? I’m only lying to myself.

    I’ve been using Nginx Proxy Manager for a while now and it has a few quirks. Perhaps my problems could have been solved by using custom Nginx configurations and reading documentation, but I’ve been hearing good things about Caddy for a while now and I thought that it would be a good time to see if I could migrate my existing setup. How hard could it be?

    THE GOAL

    Security has been at the back of my mind recently and Docker opens ports rather willy-nilly. Currently, much of the traffic itself is routed through Cloudflare (ick) which means that a direct scan of the website itself will not reveal any open ports beyond the standard 80 & 443. Normally this is good enough and nobody will see the original IP, but WordPress is particularly egregious in that it doesn’t care when or how articles are published and reveals your IP in plain text when the site is initially set up. I have no intention of getting pwned if (when) the next WordPress CVE is exposed. It would be best if I restricted the attack surface of this website even further – previously, it was possible to extract the server IP simply by following some links on WordPress, scan for open ports, and interface with the WordPress application directly. I would much rather close all these ports and force any connection to be made through a reverse proxy.

    THE CONFIG

    Previously, NPM was initialized with Docker alongside WordPress and other containerized services, which makes it resilient to outside changes. Unfortunately, this makes networking and closing external port access significantly more difficult. For NPM to see the other containers, it needs to either be part of the same Docker network (which is takes away from the convenience of being able to kill and resurrect different parts of this website on a whim) or running on host (which defeats half the point of it being in Docker) or go through convoluted bridge networking (which I no longer have the patience for).

    THE CHANGES

    So, I took the plunge to switch over to Caddy. What is the first rule of making changes? Make backups! If I somehow bricked this website though some crazy misconfiguration or through complete ineptitude, I have a feasible way to nuke the VPS and regenerate a working server from scratch.

    Downloading and installing Caddy was quite straightforward, add the keyrings and the repository, update, and install. We kill the NPM container and unbind ports 80 & 443 so that Caddy has priority, make a simple Caddyfile for our configuration, and… whoops.

    The entire site is now dead in the water – too many redirects or an incorrect SSL termination. What happened? Caddy’s claim to fame is the fully automated SSL activation – which failed the ACME challenge because the original server is behind a proxy. I added a Caddy module called “dns.providers.cloudflare” to help with this, which uses a Cloudflare API token to complete a DNS challenge. The documentation suggests installing Go, xcaddy and manually building the application with the needed modules yourself, but if you only need a single module, the “caddy add-package” command is the easier option.

    All that was left was to prepend variations of “localhost:” to all my Docker container ports and write the reverse proxy configurations. Everything is stable with minimal effort, notifications and pings just work without the need to manually configure web-hooks or forward transfers. I gave up on running Caddy within Docker and decided to deal with internal bridge networking later.

    This whole experience of writing a glorified config file has convinced me that I will eventually see the light and decide that production means disabling server-side code all together and serving a mile long static HTML page like my CS professors. There is something to be said about bell curves… later.