DEV Community: Matthew Cale

Go

Matthew Cale — Thu, 27 Mar 2025 03:49:38 +0000

FDLD - Fatigue Driven Lack of Development

Matthew Cale — Mon, 06 Jan 2025 22:39:05 +0000

What Is This?

This is an article that takes a look at the reasons developers might feel too fatigued to start researching something new and what I did to solve some of these issues. The specific solutions may or may not be useful to your use case, but I do have a suspicion that this sense of fatigue may be pervasive enough in our industry that on some level the themes will connect with a good many developers.

Caveats

I whine in this article. I am also solution oriented I think, but still... the whine in this article is strong. If you have an (understandable) aversion to whining you've been warned!
Not all of the problems or solutions in this article will make sense to you. I swear this comes from a place of reasonable competence with technology and I'd probably be happy to discuss the reasons why I went with particular solutions, but I likely won't take the time to address it in the article itself because a point by point comparison of potential solutions to these problems isn't what I'm interested in here. What I am interested in addressing is the larger theme of how small annoyances if left unaddressed can pile up to a point where something that was once fun no longer is.

A Very Familiar Story 📖

Hi Im Matt the developer 👾, and I just saw that Deno hit 2.0 and I read the blog and boy-oh-boy it looks neato-toledo! Well, at my job I only use Python and Node and the powers that be (you know silly people with odd amounts of cash) have no interest in me using an unproven, semi-unknown coding language on their very expensive production servers and I can't think of an internal tool I could justify using it on (I probably could I'm very creative but you get the point). Well what do I do to get myself interested in using this new very cool looking piece of tech 🤨 I know! I'll make a side project... And there it is... the fatigue 😱

If you are anything like me when you make a test/toy project you don't intentionally make it poorly. You try to think of your project, no matter how toy-ish as a real piece of software. This is a practice reinforced by many of the teachers I respect and the tools these days sort of push you in this direction anyway, but then you end up in the following traps that lead me, and maybe you too, to saying:

Ehhh I'm not even gonna bother...

For me the following internal conversation:

Oh <insert-technology-here> looks really cool. Maybe I'll make a little project with it.

Oh yeah that's right making the sorts of toy projects that I'm interested in with <insert-technology-here> is gonna lead to me dealing with <see-traps-below>. I won't even bother.

has become so commonplace that I have found my passion for technology in general diminishing and that's sad. As any sort of professional in any field knows, the day in and day out of a job is never always fun. So what keeps us from disliking our jobs is the experience of personal growth and mastery in our craft, and when obstacles consistently arise that block these edifying experiences you can look up and find that a job you used to be passionate about has somehow beneath your feet become mundane and soul-sucking. No one wants this! So let's talk it through and see if we can figure out what exactly these issues are and see if we can create something to counteract the passion sapping issues that prevent me (and maybe you too) from learning about what's happening in the genuinely exciting field of technology.

The Traps 🪤

So what are these recurring issues anyway? Well for me there are a few broad categories. Since the ideas here are meant as a basis for solutions rather than the core of this article I'll likely just gloss them, but the issues here may be familiar to you and so you likely don't need them explained to you in deep detail and if these aren't the exact same traps you are familiar with consider trying as I am to define what traps you are experiencing and see if you can create solutions using a similar methodology.

The Traps:

Tedium / Perfectionism
Security / Financial Risk
The Software Industry / Hucksterisms / Nonsense 🤣

The Tedium / Perfectionism Trap 😑

TLDR: A lot of work goes into everything around a piece of technology that isn't the technology itself, but it is an "entry fee" to using it.

This first one is the one where I usually stop and go on a walk.

Continuing on with the example above the process might look something like this:

Oh look Deno 2.0 came out.
Oh wow this seems cool I want to try out Deno now!
What sort of toy project should I make 🤔
Ummm... Well I am mostly a web dev so I will try out the Fresh 🍋 framework to make something simple like an app where a user can log their mood (why not 🦀)
Ok cool I have an idea let's fire up Zed (or VSCode 😴) and try this thing out 🛑

Stop Right Here

Do you realize what you just signed up for for like the MILLIONTH time? The first thing you are gonna do if you are new to this process is make a web page for logging a mood only to very quickly realize that in order for this app to be meaningful it's going to need users, which means a place to store them, which means a database, which means passwords and authentication and authorization, and it means database setup scripts, and probably it means a docker compose config, and it means designing a schema no matter how simple, it also means migration processes for your database, I can go on and on I promise 😵‍💫

So the first trap for me is the following decision:

I accept that this toy app doesn't really make sense in the real world and I can't actually leverage a lot of the intent of the tool because the tool isn't MEANT to be used improperly and so my impression of the tool will never be complete because I didn't ACTUALLY try to use the tool as prescribed and instead hacked something together that has some very confusing sharp edges.
I create all the necessary plumbing for the MILLIONTH time knowing that it's for a toy I don't intend to actually use and further knowing that none of the work in setting up even a very simple user management system from a database point of view translates to me getting familiar with the technology I actually found interesting in the first place!

I've done both lots of times... Sometimes I strike the right balance of valid set up to learning about a new topic, but most of the time I find myself going "Why I am setting up a User schema in a Postgres DB again? Oh yeah that's right Deno 2.0 was released... and me remembering how to declare tables in Postgres is... relevant... somehow"

The Tedium / Perfectionism Solution 💁‍♂️

TLDR: Look for opportunities to automate "just enough" to remove the chores that suck the joy out of learning!

So we have a pretty solid grasp on the kinda yucky choice laid out above... Well, how can we solve it?

My brain very quickly says: Automate Something!

Thanks 🧠 I agree! But knowing what to automate and what not to is kinda an art so let's think about what precisely I will find myself wanting very regularly:

A containerized database of some sort Postgres is fine
A table in said database with a users table properly configured for just about ANY application.
- id, created_at, updated_at, activated_at, deactivated_at, hash, password, first_name, last_name, email, phone_number, country_code, extra
- With that schema I can probably get a decent way towards making any app
Bolierplate statements in SQL for: Insert, Updating, Finding, and Removing (optional) users
Scripts to backup and restore the database instance.

With these desires in mind I created matty-cale/users-table which is a very portable Makefile and a couple of SQL scripts thats will hopefully strike a balance ⚖️ for me that I find useful. In total it's about 70 LOC in a Makefile and the SQL is about 10 LOC. Pretty small. You should be able to grok pretty much all of it in about 15 minutes which I think saves you about 10 minutes of dev time the first time and potentially more the more you use it.

This doesn't solve your auth boilerplate, but that's gonna be driven by your code and is an exercise you can't get away from regardless, BUT at least you don't have to worry about the following chores anymore:

Setting up shell scripts to automate the creation of your DB
Creating SQL statements for creating the users table
Creating SQL statements for inserting users into the users table
Creating scripts to back up or restore a database

I hope this inspires you to look for the tedious chores that keep you from starting a project and automate them away using simple and portable solutions!

The Security / Financial Risk Trap 💰

TLDR: Home networks are error prone and insecure, and Cloud Services cruelly don't like to make billing transparent or simple to control (because they are greedy).

Ok, cool so with one or more little automations taking care of the tedium problem what else consistently blocks me from trying out some new piece of technology?

Deployment! So when I create a project no matter how simple I want to put that thing on the internet and there has never been a better time to "just get something out there" than now, BUT the world doesn't (typically) cater to the little guy (we lack money and that makes people uninterested it seems). What am I talking about most specifically?

Spend limits!

What I mean by this is a VERY simple feature that states something to the tune of "If my bill reaches X value please unplug all my services" until I manually address it.

Q: Could this heavy handed feature possibly hurt large apps?

A: Sure, but you wouldn't have to turn it on.

However none of the big guys offer this obviously simple feature and what's more even though there are loads of posts on the internet about this topic they seemingly never call out that it's a highly requested feature and this drives me nuts! Here are some random way you can find out how the big guys address this issue.

So what else can we do? Well, maybe we could host it from an extra laptop we have sitting around and then make sure that we REALLY understand network security because we are about to open up our home network to everyone on the planet 😵‍💫

The Security / Financial Risk Solution 💁‍♂️

TLDR: Use fly.io with pre-paid credits.

This one was actually really simple... for me at least...

So, for the big guys, if this is your preference for several very understandable reasons, both GCP and AWS allow you to automate this process by round about means where you can use one service to monitor your billing and then another service / set of services to perform operations that take your services down. This definitely feels like a middle finger to users but there you are.

However as of this writing I did find one really terrific solution that works really well for me trying to launch projects in a safe and understandable way.

It's: fly.io

They have pay ahead billing (starting at $25). The peace of mind that I could likely run for a very long time enjoying all of the services I want to try out for this one time cost (yay one time costs) is incredibly valuable to someone of my disposition. And if you run out? Well, yeah they shut down your stuff, but they won't just let you rack up an enormous bill that you then have to beg them to remove if your toy app ever gets attacked by some jerk, or (a more likely story) you accidentally allow some script you didn't really understand to create a bunch of really expensive operations.

fly.io, while not as feature rich as AWS or GCP provides everything I (and likely you) need to deliver production ready experiences if your side project ever becomes something you want to really try out and I'm supremely grateful for it. Thanks fly.io and feel free to send me swag 😉

The Software Industry / Hucksterisms / Nonsense Trap 🤡

TLDR: The software industry is changing. The way we work and how we are managed is changing. It can be hard to get excited about growing as a technologist in this environment.

Ok, so the final trap is something that has become more noticeable in the last few years for me in the industry. There is a general sense of anxiety about what we (software developers) do and how we do it. This anxiety is fed by several different factors: impending AI industry takeover, financial pressures on specific software companies, large scale economic issues, and natural developments that lead to software companies becoming more like traditional companies as time moves on and technology becomes better understood and therefore more systematically monetized.

Any one of these elements may, on any given day, be louder or quieter, but the overall effect is the same. Our industry and therefore our way of life is changing. I count myself incredibly lucky to have come into the field when I did. I came in at a time when many companies were trying to launch their first attempts at a SaaS offering and there was so many unknowns that the "Research" side of the "Research and Development" departments were given a great deal of deference. This is not the feeling I have about the industry as it stands now.

The most popular large scale web apps while still vastly unique in their composition and quality do seem to be coalescing around particular product principles that do seem to have real staying power. This shift away from (more) equal parts Research and Development, and towards a much greater emphasis on Development means that much of the joy of discovery and the personal satisfaction of finding a novel solution to a problem is fading. This is sad for those of us who see our jobs as both Researchers and Developers. But what are we to do?

The Software Industry / Hucksterisms / Nonsense Trap

💁‍♂️

TLDR: Keep your eyes open for what inspires you and allow yourself the space to reflect and fix what's really bugging you. Maybe all the small things you fix will create the world you want to be in.

So how do we overcome this issue of the industry changing and no longer valuing the same sorts of behaviors that it previously valued? Honestly, I don't know. I don't think there is anything for it. The future is coming and the only thing we can ever say for certain is that tomorrow will be different than today. I know this is not really a solution, but at least it's a human's honest assessment (and that can feel rare these days).

I think that something that helped me was writing this article. I was so inspired and interested in the work that went into Deno 2.0 and I was so saddened by the realization that due to my fatigue I wasn't even going to try it out that I got a chance to reflect here on why I feel this way. Sometimes it's that I just need to take 45 minutes to an hour to write a Makefile so I can remove the elements of learning that have become mundane and annoying. Sometimes it's that I need to do more research on what product offerings are out there that fit my needs. Sometimes it's that I need to be inspired enough by my peers that I take a second to investigate my apathy and fatigue and try to solve it.

For now, if you need me I'm gonna be seeing if I can scrap together something fun using Deno and Fresh, and trying to keep my chin up as I wait to see what the future holds. Stay safe out there and be open to being inspired.

Credits:

Photo by Philip Oroni on Unsplash

PyEnv & Poetry - BFFs 💖

Matthew Cale — Sat, 27 May 2023 17:51:01 +0000

What is this?

This is a resource made, admittedly mostly for myself, that will allow me to recall a method of Python dev environment management I don't dislike. It covers the use of two distinct but important Python environment helpers:

PyEnv (Docs)
- Uses path shims to help you manage several versions of Python simultaneously.
Poetry (Docs)
- A dependency manager that feels similar in my approximation to a tool like yarn or npm from the Node world, and automates certain tasks (venv creation and activation for example).

Why make this / why read this?

You find that managing Python projects in a clean, repeatable, and predictable way is less simple (or less fun) than you have found the process to be in other languages.

How do I use / read this?

This is a technical guide not an in depth explanation (though that may be forthcoming) and so I expect this guide to be used primarily as a way to kick start your memory on how to set up Python projects in a way you don't dislike. Best of luck 🍀

Pre-Reqs 🫸

These steps are to be done once per machine and if you've already accomplished these steps you may skip this section.

Install PyEnv & A Modern Python Version 🐍

brew update
brew install pyenv
pyenv --version
# pyenv 2.3.15

pyenv install 3.10.7
# Wait for a bit for install to finish...

pyenv shell 3.10.7
python --version
# Python 3.10.7 🎉

Optional: Set A System Wide Python Version

pyenv global 3.10.7

Install Poetry ✍️

curl -sSL https://install.python-poetry.org | python3 -
poetry --version

Optional: Tell poetry to create virtual environments in the current project directory

poetry config virtualenvs.in-project true
poetry config virtualenvs.in-project
# true

Steps 🧭

Make a new project directory

cd Desktop/Code/personal/python
mkdir planet-express-api
cd planet-express-api

Set a Python version for this project directory

pyenv local 3.10.7
python --version 
# 3.10.7
cat .python-version
# 3.10.7

Note: This command will create a file that pyenv looks for in the current working directory (the folder you are in) whose content will tell pyenv which Python version to use.

Create a poetry project

# Leave off the -n flag if you wish to add precise data 
# to the pyproject.toml file poetry creates.
poetry init -n
ls | grep pyproject.toml
# pyproject.toml

Initialize and start your Virtual Environment using poetry

poetry shell
# Creating virtualenv planet-express-api
# bash -c planet-express-api/.venv/bin/activate

Test it by adding a dependency

# Add a dependency
poetry add pendulum 

# Start a Python REPL
python 

# Use the dependency
import pendulum
now = pendulum.now("Europe/Paris")
now.to_iso8601_string()
# '2023-05-27T19:40:17.452958+02:00'
# Use `ctrl + d` to exit the REPL

Stop using the virtual environment

# Exit the virtual environment
deactivate

# Start a Python REPL
python

# Validate the dependency is not available
import pendulum
ModuleNotFoundError: No module named 'pendulum'

Note: To get back into the virtual environment just use poetry shell again.

Summary

In this article you have used PyEnv and Poetry together to create a project in a desired version of Python (pyenv) whose dependencies and virtual environment are managed by a single robust tool (poetry) cheers to you 🍻

Dockerize & Backup A Postgres Database

Matthew Cale — Wed, 17 Nov 2021 01:06:57 +0000

What is this?

This is a technical guide for doing common management tasks with a Postgres database running in Docker.

Why make this?

As a quick reference for taking database backups and restoring them.

Steps

Run The Postgres Image

Docker makes it incredibly easy to get going with a Postgres database with persistent storage. Let's try it out.

Let's just run the Postgres container pointing its volume location to a spot on disk we like. For me that's: ~/docker/volumes/postgres.

# In your terminal
docker run \
 --name pg-db \
 -e POSTGRES_PASSWORD=shiny_metal_pass \
 -d \
 -p 6543:5432 \
 -v $HOME/docker/volumes/postgres:/var/lib/postgresql/data \
 postgres

Let's dissect this line by line:
- docker run -- Runs a specified image (in our case it's postgres, see last line of command). Source
- --name pg-db -- Sets the name of the container running the postgres image. Source
- -e POSTGRES_PASSWORD=shiny_metal_pass -- Sets an environment variable which will be the default password for the superuser. Note: This should be a secret 🤫. Source
- -d -- Detach from the terminal instance. i.e. run in the background.
- -p 6543:5432 -- Map the local machine's port 6543 to the container's port 5432. So from our machine to connect we will use 6543 which in turn will hit the port in the container running on 5432.
- -v $HOME/docker/volumes/postgres:/var/lib/postgresql/data -- Map any data created in the container at /var/lib/postgresql/data to a desired location on local disk: $HOME/docker/volumes/postgres. Source
- postgres -- The name of the image in Docker hub we want to create a container from.
When I run it I see the following

When I check our volume location (note: for me this was an empty location prior to invoking the command above) I see this:

Finally, let's see if we can connect to our database. I am using TablePlus but the same concepts apply with any general purpose database IDE or psql (found here). For me the connection looks like this:

And when we connect we can run the following to get a lay of the land.

-- From a SQL Editor (PSQL / TablePlus Session)
SELECT datname FROM pg_database;
-- RESULTS:
-- postgres
-- template1
-- template0

Create Some Persistent Data

So, we've got a database! What now? Well let's store some data in it!

Start by creating a new database called todo_it_well. You guessed it this, YATA (yet another todo app). This time we are doing it in SQL later we will also show you how to use the createdb tool.

-- From a SQL Editor
CREATE DATABASE todo_it_well;
-- Query 1 OK: CREATE DATABASE

Switch to our new database. For me, in TablePlus, this just means editing my connection to use todo_it_well instead of postgres for the chosen database.

Next, create some tables. We will, for this demonstration, create a users table and tasks table so that users can track their tasks or "todos". The only almost complex bit of this is declaring a relationship between tasks and users. This post is not about SQL so don't think too hard on these commands for now just know that they make a viable todo application.

-- From a SQL Editor
CREATE TABLE "user" (
   id SERIAL PRIMARY KEY NOT NULL,
   created_at TIMESTAMP NOT NULL DEFAULT NOW(),
   updated_at TIMESTAMP NOT NULL DEFAULT NOW(),
   email TEXT NOT NULL,
   "password" TEXT NOT NULL,
   display_name TEXT
);

CREATE TABLE "task" (
   id SERIAL PRIMARY KEY NOT NULL,
   created_at TIMESTAMP NOT NULL DEFAULT NOW(),
   updated_at TIMESTAMP NOT NULL DEFAULT NOW(),
   owner_id INT NOT NULL,
   description TEXT NOT NULL,
   label TEXT,
   completed_on TIMESTAMP,
   removed_on TIMESTAMP,
   CONSTRAINT fk_owner 
    FOREIGN KEY(owner_id) 
    REFERENCES "user"(id)
);
-- Query 1 OK: CREATE TABLE
-- Query 2 OK: CREATE TABLE

Before we finish this step let's create some real data in here! Let's insert some users first and then some tasks for them!

-- From a SQL Editor
INSERT INTO "user"
  ("email", "password", "display_name")
VALUES 
  ('matt@email.fun', 'password-gasworld', 'matt-the-magic-monkey'),
  ('jennie@yahoo.fun', 'password-sassworld', 'dat-girl-jen'),
  ('timothy24@email.fun', 'pw-vw', 'yo-boi-tom-o-tee');
-- users created with ids: 1, 2 and 3

Next, the tasks:

-- From a SQL Editor
INSERT INTO "task"
   ("owner_id", "description", "label")
VALUES 
   (1, 'read this awesome post', 'tech'),
   (1, 'do dishes', NULL),
   (2, 'read chapter of lotr', 'lit'),
   (2, 'sign up to volunteer', NULL),
   (3, 'call brother', NULL),
   (3, 'make grocery list', 'health'),
   (3, 'rake leaves', 'house');

Validate that our data looks as expected:

-- From a SQL Editor
SELECT 
   u.display_name, 
   t.description
FROM 
   "user" u 
INNER JOIN
   "task" t ON u.id = t.owner_id
WHERE 
   u.id = 2
   AND t.completed_on IS NULL;

-- RESULTS:
-- display_name description
-- dat-girl-jen read chapter of lotr
-- dat-girl-jen sign up to volunteer

Create A Backup

So here we are with some valuable customer data that we really do not wanna lose. A good practice for any developer is to take regular (hopefully automated) database backups. Doing this in Postgres isn't too hard so let's get to it. I should state there are several ways to do this. This is just one of many ways to get this job done. I think it is the most straightforward way; though, there are definitely faster ways.

This approach consists of issuing a set of commands to the container that could likely be CRON job-ified without too much effort.

First let's create a backups directory at a spot that we share with our container's filesystem and our host machine:

# In your terminal
docker exec -t pg-db bash -c 'mkdir /var/lib/postgresql/data/backups'

This command (run from the host machine) executes a command (-c) mkdir on the container and creates a directory called backups which is located at the spot on the container that is shared with the host machine. You can verify this on the host by running:

# In your terminal
ls $HOME/docker/volumes/postgres | grep backups
# my machine outputs: backups

Next, let's create our backup

# In your terminal
docker exec -t pg-db bash -c 'pg_dump todo_it_well -U postgres  --file=/var/lib/postgresql/data/backups/todo_it_well_db-$(date +%Y-%m-%d).sql'

Let's breakdown this command:

docker exec -t pg-db bash -c
- We tell Docker we want to run a command on the pg-db container
pg_dump todo_it_well -U postgres
- We invoke the pg_dump tool on the container telling it to target the todo_it_well db and run commands as the postgres user.
--file=/var/lib/postgresql/data/backups/todo_it_well_db-$(date +%Y-%m-%d).sql
- This is the spot on the container we want to place our back up at and as you can see it is the shared backups directory we just made. There is a little date logic that interpolates the current date as YEAR-MONTH-DAY.
If this went as planned we should have made our database backup and we can verify it on our host machine by running:

# In your terminal
ls $HOME/docker/volumes/postgres/backups
# my machine outputs: todo_it_well_db-2021-11-07.sql
cat $HOME/docker/volumes/postgres/backups/todo_it_well_db-2021-11-07.sql
# output includes: -- PostgreSQL database dump

If you see some SQL in your output then congratulations! You have successfully created a database backup and your data strategy for your awesome app is just the tiniest bit more durable. 🎉

Drop Data And Restore It

Great, so our data has been backed up! This means that you can restore folks back to a particular point in time when things were as they should be. So long as you have an application that can reliably serve this data (ruminates on articles using Goose to accomplish database versioning) you can restore functionality and value to your users.

BUT, backing up your data is only half the battle. Actually restoring it is another matter. Let's practice the act of restoring our data.

First, I should confess that this article commits a sin of simplicity in that I wanted to get going as simply as possible. You more than likely should not place your backups in the exact same spot as the rest of your mounted volume data, but it was useful in getting us going faster.

So to start, we are going to put our backup temporarily out of this spot so that we can pretend we had mounted two volumes:

# In your terminal
# Let's move our data to our home directory and pretend this is where we safely mounted our backups when starting the container, ok?
cp \
$HOME/docker/volumes/postgres/backups/todo_it_well_db-2021-11-07.sql \
$HOME/todo_it_well_db-2021-11-07.sql

Next, verify that our data is where we expect it to be:

# In your terminal
ls $HOME | grep todo_it_well_db-2021-11-07.sql
# my machine outputs todo_it_well_db-2021-11-07.sql

Ok cool, we are pretending the we have a spot outside the normal Postgres files where we keep our data safely backed up. Now, the fun part. OMG! We just got attacked 😰. All records were destroyed by the evil hacker! Let's stop our container and delete all of our persistent data.

# In your terminal
# Stop the container forcibly
docker rm -f pg-db
# Delete our persistent data
rm -rf $HOME/docker/volumes/postgres

Verify the data is indeed gone.

# In your terminal
ls $HOME/docker/volumes/postgres
# my machine outputs: No such file or directory

Now we have discovered the attack and want to bring our application back online. So we start up our container as before:

# In your terminal
docker run \
 --name pg-db \
 -e POSTGRES_PASSWORD=shiny_metal_pass \
 -d \
 -p 6543:5432 \
 -v $HOME/docker/volumes/postgres:/var/lib/postgresql/data \
 postgres

However, sadly, our data, including our database, is gone and we cannot connect to the todo_it_well database.

Fear not, 🦸‍♀️ we have a backup! Simply copy the backup into the container:

# In your terminal
docker cp $HOME/todo_it_well_db-2021-11-07.sql pg-db:/var

Next, you will need to recreate the database (so your backup data has a place to restore to):

# In your terminal
docker exec -t pg-db bash -c "createdb \
-h localhost \
-p 5432 \
-U postgres \
todo_it_well"

Finally, run the psql SQL file command and take a deep breath, you are recovering from a very stressful attack 😉.

docker exec -t pg-db bash -c \
"psql \
-U postgres \
-d todo_it_well \
-f /var/todo_it_well_db-2021-11-07.sql"

Lastly, let's verify that our data was properly restored by running our query from earlier:

-- From a SQL Editor
SELECT 
   u.display_name, 
   t.description
FROM 
   "user" u 
INNER JOIN
   "task" t ON u.id = t.owner_id
WHERE 
   u.id = 2
   AND t.completed_on IS NULL;

-- RESULTS
-- display_name description
-- dat-girl-jen read chapter of lotr
-- dat-girl-jen sign up to volunteer

There you have it! You have done a ton! You set up a dockerized Postgres DB, you created your schemas and planted some data in your database, you took a back up of the data and then restored the data from back up after losing it. You rock 🎸.

Closing Thoughts

There are some issues with our set up and certainly there are some ease of use and durability improvements we could make, but this is a fully working solution. Some of the areas we should checkout:

Custom Dockerfile that includes a backups location.
A run command that references the previously mentioned backups location mount.
A cron job run on the host or on the container that creates backups.
A secure, but accessible spot for these backups to stored. Maybe DigitalOcean Spaces, why not 🦀?

Resources

Dockerfile For A Python Playground On Ubuntu

Matthew Cale — Wed, 08 Sep 2021 17:18:50 +0000

What is this?

This is a tutorial on getting a supremely simple Python3 playground running on an Ubuntu Docker container. Like my first tutorial on Ubuntu and Docker this is not extremely useful, but it is extremely simple and that goes a long way in a field where things can get very tricky very fast.

Why make this?

To keep it in a spot I remember and to share simple things with others. In the future you might be glad you have a starting point for tinkering with Python and Ubuntu together Matt!

Steps

Create a directory and Dockerfile



# From the terminal 
mkdir ubuntu-python-playground && \
cd ubuntu-python-playground && \
touch Dockerfile

Open the Dockerfile in a text editor (use VSCode if you're a human and use Vim if you're 3xtra l33t) and fill it in with the requirements for getting Python to run on an Ubuntu container.



# Using the Ubuntu image (our OS)
FROM ubuntu:latest
# Update package manager (apt-get) 
# and install (with the yes flag `-y`)
# Python and Pip
RUN apt-get update && apt-get install -y \
    python3.8 \
    python3-pip

Make your new fancy image



# From the terminal 
docker build -t ubuntu-python-playground-img .

Run the image interactively and get a Python playground set up



# Run the image / make a container jump into it
docker run -it ubuntu-python-playground-img bash
# Install some libraries that do fun things
pip3 install Requests Pygments
# Open the Python REPL
python3

Once you're in the Python REPL feel free to run some totally bomb python code 🐍. Since we installed some fun packages in the step before consider trying them out!



# There will be a little >>> symbol 
# this indicates you're in the Python REPL

# Get some cool libs imported
from requests import get
from pygments import highlight
from pygments.lexers.data import JsonLexer
from pygments.formatters import TerminalFormatter

# Get and format some JSON
r = get('https://jsonplaceholder.typicode.com/users/2')
print(highlight(r.text, JsonLexer(), TerminalFormatter()))

Enjoy 🙋‍♀️

Alternative Approach

This works well for running Python in the REPL, but what if I wanted to write the Python code in my text editor, but run it on the container?

Well, with a few changes to the Dockerfile you can! To do this we will copy and paste the Python code example above into a file called script.py so our ubuntu-python-playground directory from before now has two files in it.

Dockerfile (the one we have been working with)
script.py (the code we previously ran in the REPL)

Once our script.py file is in place we will just make some changes to the Dockerfile and re-run it.

Steps For Alternative Approach

Change the Dockerfile to look like this:



# Using the Ubuntu image (our OS)
FROM ubuntu:latest
# Update package manager (apt-get) 
# and install (with the yes flag `-y`)
# Python and Pip
RUN apt-get update && apt-get install -y \
    python3.8 \
    python3-pip

# =====
# The new stuff is below
# =====

# Install our Python dependencies
RUN pip install Requests Pygments

# Copy our script into the container
COPY script.py /script.py

# Run the script when the image is run
ENTRYPOINT ["python3", "/script.py"]

Build and run the new image



docker build -t ubuntu-python-playground-img .
docker run ubuntu-python-playground-img

Enjoy 🙋‍♀️

Resources For Extra Learning

Simple Ubuntu Docker Playground

Matthew Cale — Tue, 07 Sep 2021 19:50:41 +0000

What is this?

This is a tutorial on doing Ubuntu stuffs in Docker. It is intended to be a starting off point for doing common things in pretty much any image that can run bash or sh. Other tutorials will lean on this on this foundation.

Why make this?

To keep it in a spot I remember and to share simple things with others.

Steps

Run the Ubuntu image with the -i and -t flags. See documentation for more detail

# Run the image directly rather than exec into a container
docker run --name ubuntu-playground -it ubuntu bash

Optional, verify your new container is running in a separate terminal window. This is a bit redundant since your terminal shell just switched, but it's good to be thorough!

docker ps
# ubuntu-playground will be in the NAMES column

Install and run some stuff

# From prompt inside container
apt-get update
apt-get install -y curl jq
curl https://jsonplaceholder.typicode.com/users/1 | jq

Profit 🤑

Making A Delightful Personal Page - P2: Complete Content and Make It Pugly!

Matthew Cale — Mon, 12 Oct 2020 17:16:31 +0000

Welcome Back!

In this series we are creating a delightful to develop, and pleasant to look at homepage that contains 0 runtime dependencies (CSS or JS libs/frameworks). To make this process fun and simple we are employing a small number of developer tools such as Pug, Stylus, NPM Scripts, Gulp, and Surge.

In the last section we covered the creation of our project, creating our first deployment asset (a single HTML page), and got it deployed out to the internet. We also threw in some temporary styles just so we could start sharing something 🆒 as quickly as possible.

In this post we are going to split out our src content from our dist content, (by this we mean we will introduce the concept of keeping our development assets distinct from our deployment assets), convert our HTML markup to Pug markup, and add the rest of our content to our site.

Aside: Why use Pug?

Optional: read only if you are interested in this technology choice.

A very fair sentiment at this point is "why throw in an additional technology? If the point is to make it simple then use as few dependencies as possible.". My response to this feedback is that we are not aiming to make the simplest possible solution. We are intending to make the most delightful or pleasant developer experience.

To be sure, simplicity is an aspect of developer satisfaction and should be heavily weighed, but in my particular case (and I'd bet in yours) there are other aspects to contend with. Here are a few items that I think make Pug shine as a developer tool:

It is pleasant to look at, and is highly expressive without being overly verbose. Check out this simple comparison of the exact same markup. You get approximately 20% less code. In a small example this may not mean much, but over time that can amount to a significant amount of code that you can forego including.

// Pug
div(class='card text-center')
  div(class='card-header') A clever header
  div(class='card-body')
    div(class='card-title') Hello Dale!
    div(class='card-content') Happy you stopped by!

<!-- HTML -->
<div class="card text-center">
    <div class="card-header">A clever header</div>
    <div class="card-body">
        <div class="card-title">Hello Dale!</div>
        <div class="card-content">Happy you stopped by!</div>
    </div>
</div>

It is modular, and extensible. As projects grow the idea of being able to logically separate and eventually re-use UI components or at least work on them in cognitive isolation is very valuable.
It enforces a consistent format. This is something the coding world is really coming around to. Python does it, Go's formatting tool fmt does it, and a thousand linters the world over do it, albeit, in a bespoke fashion. An opinionated format reduces cognitive load, and reduces bike shedding.

Basically, Pug helps make my code more elegant, consistent, and extensible than it would have been otherwise, and to me using Pug is just plain fun!

If you really dislike it there is nothing stopping you from just creating the markup in HTML and finding a different way to place it in the dist directory for deployment. I understand that folks like their tools and don't judge. I clearly like mine 😌

Pug Primer

If you haven't worked with Pug before it is an HTML templating language. That means you will write files with a .pug extension and compile them into HTML files. We will not be employing most of the power that Pug offers in this tutorial as we mostly just want to enjoy the conciseness and expressiveness of the language, but all of the power is there if you feel like taking your page to the next level. For this tutorial all you need it know is the following:

Whitespace is meaningful! This means that if items are not properly indented they will either not compile at all (usually with a helpful error message) or compile in unexpected ways. Let's look at a very simple example.

Notice the use of whitespace in the following valid Pug markup:

div(class='container')
  h1 Hello There
  p I am so glad you stopped by!
footer(class='rights')
  small all rights reserved

The above will correctly compile to the following HTML:

<div class="container">
    <h1>Hello There</h1>
    <p>I am so glad you stopped by!</p>
</div>
<footer class='rights'>
  <small>all rights reserved</small>
</footer>

Transition to Pug

The first thing we are going to do is "mature" our project a bit by creating some separation for our concerns.

We are going to create a src (also known as "source") directory that contains our raw, uncompiled project files and assets, and we are going to run scripts against these items that transform and copy them to places inside the dist directory. This process is often called compilation and is how the development of large projects usually occurs. You write will clean, possibly commented, human readable code and the compilation process will create valid, machine runnable code.

In our particular project we are going to compile .pug files (located in the src directory) into .html (located in the dist directory) files.

So let's get started!

In your project's root directory let's install the Pug compiler.

# In your terminal
npm i --save-dev pug-cli

Great, now let's set up our src directory with our .pug source code.

# In your terminal 
mkdir src

Now, let's make our first source Pug file.

# In your terminal 
touch src/index.pug

Now that we have a Pug file let's get it filled in with our code in its current state state. Recall, that we have our current deployment asset at dist/index.html. Let's copy the contents of that file into Pug. There are a number of online tools that can do this and here's an NPM package that will do it too. For brevity, feel free to copy mine.

// In src/index.pug
doctype html
head
    meta(charset='UTF-8')
    meta(name='viewport' content='width=device-width, initial-scale=1.0')
    link(href='https://fonts.googleapis.com/css2?family=Cabin:ital,wght@0,400;0,500;1,400&display=swap' rel='stylesheet')
    style.
        body {
        font-family:'Cabin', sans-serif;
        }
        h1 {
        font-size: 2.5rem;
        }
        .row {
        display: flex;
        justify-content: center;
        }
        .column {
        display: flex;
        }
        .hero {
        align-items: center;
        height: 100vh;
        }
        .welcome-info {
        text-align: center;
        }
        .welcome-info .sugar {
        font-style: italic;
        }
    title Dale Gribble
body 
    div(class='row')
        div(class='column hero')
            div(class='welcome-info')
                h1 Dale Gribble
                h2 Exterminator, Treasure Hunter, Alientologist &#x1F47D;
                p(class='sugar') If you&apos;re from the CIA you have to tell me!

BTW, I know you can elide tags like div and attrs like class and id, but I think the above strikes a balance of clarity and brevity. You are welcome to elide these elements if you wish

Awesome we have some seriously 💣 looking markup here. Now, let's compile that bad boy!

Add a new NPM script that looks like this:

// In package.json
"scripts": {
    "compile-views": "pug src --out dist"
}

And give it a whirl!

# In the terminal
npm run compile-views

If everything went as planned there should be an index.html file in your dist directory with exactly the same contents as before; only this time it's been minified (per the Pug compiler's default settings). Check it out in the browser to make sure everything still looks as you'd expect it to.

From now on when we want to see our result we will first need to compile our views. Later on we will add a task runner that makes this occur every-time the src/index.pug file is saved, but for now this shouldn't be too cumbersome.

Completing our Markup

Now, we are going to finish up creating our content. We already have the hero section that covers the entire view-height when someone first visits our page, now let's give interested viewers a little more information about ourselves through 2 "Question & Answer" rows. Place the div.row elements at the same indentation level as the div.row we already have. Recall, that indentation is important in Pug. If you are confused you can always check out the tutorial repo under the tutorial 2 release to see how I did mine.

Let's add the rows and see how it looks!

// In src/index.pug
div(class='row')
    div(class='column q-and-a work')
        div(class='question')
            h3 What do you do for work?
        div(class='answer')
            p Well, at Dales Dead Bug (TM) I operate as an assassin of assassins. Make no mistake, ants, spiders, mosquitos, and wasps want you dead! I am the guardian of all humanity against these dubious foes.
div(class='row') 
    div(class='column q-and-a fun')
        div(class='question')
            h3 What do you do for fun?
        div(class='answer')
            p I hunt, I fish, I play a lot of golf and I drink in the alley with my friends. Also I am the president of the Arlen gun club which is alright, I guess.

Compile it and check it out

Hmmm, it does have our new content, but it isn't very pretty. We haven't yet gotten to our doing basic styles yet (hype for upcoming post), but because we don't want folks seeing something ugly let's add just a tiny bit more temporary styling to the src/index.pug head section.

// In src/index.pug
style.
  // Other styles elided
  .q-and-a {
      max-width: 550px;
      flex-direction: column;
      justify-content: space-around;
      align-items: center;
  }

Great, let's compile it and check it out again.

Well, alright! We've got a page with enough content to be useful! Release it out to the world using the same deployment script as last time.

# In the terminal
npm run deploy

Check out your live site. That's pretty 🆒, huh?

In this post we transitioned our markup to Pug which is a lovely, and powerful templating language that can be used to keep your project pleasant, and maintainable as it grows.

We added the rest of the site's content (at least for a good little bit) and added some temporary styling to it so that we could feel happy about deploying it.

We also transitioned to a more mature pattern of keeping our source code separate from our distribution code by introducing the src directory where we write our human readable Pug that we then "compile" into our minified HTML in the dist directory.

In our next post we will be introduced to using Gulp for an even more pleasant developer experience. Try to give yourself a break here. Excited to see you in the next section 🤠

Will post link when it's ready!

Making A Delightful Personal Page - P1: Introduction and Instant Gratification

Matthew Cale — Mon, 12 Oct 2020 17:14:54 +0000

Introduction

Hello! Welcome to my walkthrough of how to make a delightful personal page. In this series you will be able to read along and quickly build a lovely little homepage that is 💯 runtime dependency free, and is also a 💯 delight to develop by using modern and elegant developer tools written in Node.js.

The page we will be making is a clone of my personal page, http://matthewcale.com. The tools we will employ and get a reasonable introduction to are: NPM scripts (for basic task running), Pug (for HTML), Stylus (for CSS), Gulp (for advanced task running) and Surge (for hosting). We will use these tools to create a pleasant to read, fun to develop, and simple to deploy website that requires no CSS* or Javascript libraries, which means that its footprint is tiny and that the amount of cognitive load it takes to develop is miniscule.

I wrote this to be approachable for developers of all skill levels, while not being tedious for more advanced devs. If things were markedly unclear or miserably tedious let me know. I may not be able to please everyone, but understanding what readers want is important to me. Thank you.

Aside, Why Make This?

Optional, read only if you are interested as to "why" I made this tutorial.

As developers we are tasked with knowing how to do a great many things and these things are often incredibly complex and require a (pretty) rigid structure. We need this rigidity in order to make massive projects that can easily scale both in the number of end consumers and in the number of active developers.

Frameworks exist to make this rigidity and boilerplate less off-putting and easier to understand and as such developers employ these frameworks to reduce the burden of hand rolling rigid structures. A good example is Bootstrap. Many development teams employ Bootstrap (or another CSS library like it) to keep from writing their own CSS components. This is a great idea! General pages, that users interact with (forms) and consume information from (dashboards) follow an expected format and Bootstrap has made these expected formats much easier to make.

There is however, another type of page that exists on the internet that CSS frameworks, by the nature of that selfsame useful rigidity fall short in being as useful for, and that is the bespoke "pretty" or "artistic" page (like the one we are making here). Don't get me wrong, the frameworks usually have the ability to make these pages as well, and offer their own advantages to seasoned users of those frameworks, but they were not written for this purpose. So, while they can be used to make these pages I have found that it feels much more natural to let frameworks tackle the common problems and let humans tackle creating artsy pages. That is what these pages are essentially, little artwork installations.

So, what I set out to do was see how easily and pleasantly I could create a (hopefully) lovely page with no frameworks.

What I discovered is that, with the help of a few developer tools, creating pages whose primary aim is to be lovely can be quite pleasant and I wanted to share my approach.

Instant Gratification

To start, let's get a cool page up online! This page will not be our final product, but will be a good place to start getting familiar with three of the technologies we intend to use and will give you a project setup that you can easily keep building upon. So let's get after it!

Tools you need

Node.js installed
A basic code editor, like Atom, VSCode, or Sublime
A terminal program (like Terminal or iTerm)

Verify your installation

# In your terminal
matt.cale$ node --version
v12.16.3
matt.cale$ npm --version
6.14.4

Project Setup Steps

Create project directory

# In your terminal
# Idea: Use "jane-doe" instead of "dale-gribble" in your command 
mkdir ~/Desktop/dale-gribble.com

Initialize the project

# In your terminal
# Idea: Use "jane-doe" instead of "dale-gribble" in your command 
cd ~/Desktop/dale-gribble.com && npm init -y

Note: The command, npm init -y, will create the package.json file required for Node and NPM (Node's dependency management tool) to treat your project like a Node module thus allowing you to install the required dev-only dependencies.

Install Surge.sh as a "developer dependency"

# In your terminal
npm i --save-dev surge

Note: A "developer dependency" is a code library or program / application that makes the creation of other libraries or applications easier.

Create Your Site's Content Steps

Now that we have a project we can hack on let's get to hacking! Later on we will be using Pug.js to create markup that is more elegant, modular, and extensible, but for now let's just hack some HTML so we can get something decent deployed.

Create a directory called dist

# In your terminal
mkdir dist

Important: This will be the directory that we deploy as our static site.

Create an index.html file

# In your terminal
touch dist/index.html

Get your HTML boilerplate created as well.

<!-- In your dist/index.html file -->
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <style></style>
    <!-- CSS font link here! -->
    <title>Dale Gribble</title>
</head>
<body>
    <!-- Content here! -->
</body>
</html>

Get a 🆒 font from Google Fonts and place it in the head section as a stylesheet link. It's a good idea to get a regular, bold and italic version. Here' mine.

<!-- In your dist/index.html file -->
<!-- In between the <head> tags -->
<link href="https://fonts.googleapis.com/css2?family=Cabin:ital,wght@0,400;0,500;1,400&display=swap" rel="stylesheet">

Now that we have our HTML scaffolded out let's add our first bit of custom content. You can now add any HTML you want to your page, but if you are following along I went with the following format:

Name (Dale Gribble)
Identifiers (Exterminator, Treasure Hunter, Alientologist)
Welcome Message (If you're from the CIA you have to tell me! 👽)

Inside of the body add the following:

<!-- In your dist/index.html file -->
<!-- In between the <body> tags -->
<div class="row">
    <div class="column hero">
        <div class="welcome-info">
            <h1>Dale Gribble</h1>
            <h2>Exterminator, Treasure Hunter, Alientologist 👽</h2>
            <p>If you're from the CIA you have to tell me!</p>
        </div>
    </div>
</div>

The content we are going to provide is going to be styled with Flexbox, a styling tool available in plain ol' vanilla CSS. To make this styling easier to understand we are going to split our UI into rows and columns. Sometimes we will have multiple columns, but in this case we just want a row with a single column. The column will contain one item, a welcome-info container element that contains our content.

Check it out in the browser, pretty boring, eh? Well, let's add some styling to spruce it up before we go public with it!

Up between the style tags in the head section of your index.html copy in the following:

/* In your dist/index.html file */
/* In between the <style> tags */
body {
    font-family:'Cabin', sans-serif;
}

h1 {
    font-size: 2.5rem;
}
.row {
    display: flex;
    justify-content: center;
}

.column {
    display: flex;
}

.hero {
    align-items: center;
    height: 100vh;
}

.welcome-info {
    text-align: center;
}

.welcome-info .sugar {
    font-style: italic;
}

The styles are pretty simple, but even so do not worry if you don't understand something I will be covering these styles in more detail in a later section.

Go ahead and open the index.html file in a browser, provided you are connected to the internet (for fonts) you should see the following.

If yours doesn't look like mine check out the dist/index.html in the demonstration repo and see if everything is the same there. If you checked and it's all the same please leave me a comment or create an issue.

Deploy Your Site to The Internet Steps

Great, you have a website that isn't horrible to look at! It also gives a fair amount of information about you, but this isn't useful unless other people can see it, right?

So how do we get this 💣 site deployed online? Well, remember earlier when you downloaded surge? Now we are gonna use it!

Surge is an insanely simple static site (what we just made) hosting platform. To get started we are going to create an NPM script that invokes the surge program we downloaded.

A NPM script is a command that is invoked with npm run <script> and references an entry in the package.json file's scripts section. It will use your shell's commands (Ex: Bash). An example script might look like this.

"scripts": {
  "say-hi": "echo hello there"
}

Which when invoked outputs the following:

# In your terminal
npm run say-hi
> echo hello there
hello there

Since we downloaded surge there will be a program that NPM can invoke inside of your node_modules directory called surge.

All that is required for surge to work is a directory that contains an index.html (dist for us), a file in the same directory called CNAME that has your desired surge address in it, and an account (email and password). Best of all, it's all free!

So let's create our deployment process.

Create a file called CNAME (this file has no extension, like .html or .txt) in the dist directory.

# In your terminal
touch dist/CNAME

Open the CNAME file and add your desired <site-name>.surge.sh site name to it. Here's the contents of my CNAME file.

dale-gribble.surge.sh

At this point your project structure should look like this:

dist
dist/index.html
dist/CNAME
node_modules
package-lock.json
package.json

Create the deployment script in the package.json scripts. Here's the scripts section of my package.json file.

"scripts": {
  "test": "echo \"nothing to test\"",
  "deploy": "surge dist"
},

Now it's time for lift off 🚀! Run your deploy NPM script.

# In your terminal
npm run deploy

Note: Your first time running surge will prompt you for an email password word.

The output for me looks like this:

Running as <matt> (Student)

project: dist
domain: dale-gribble.surge.sh
upload: [====================] 100% eta: 0.0s (2 files, 1178 bytes)
CDN: [====================] 100%
IP: <IP>

Success! - Published to dale-gribble.surge.sh

Now in a browser, navigate to your site-name.surge.sh, and see your masterpiece!

Here's mine!

Wow! We just did quite a bit! We made a site, styled it, created a CNAME (networky) file, created a deployment script, and published a site to the internet. Let's bask in the glow of all we've done for a while before moving on to Part Two where we will make our markup prettier and more extensible using Pug and another NPM script!

Thanks for following along. I hope this was fun and educational. If you have any feedback or just wan to say "howdy" please drop me a line below. Have a wonderful day. 🤠

*For fonts I will be using some Google Fonts, but this is entirely optional, and suitable fallbacks will be available.

NPM, Gulp, and The Case of The Naughty Global Package

Matthew Cale — Sat, 25 Jul 2020 00:37:30 +0000

Meta TL;DR

Using --force would have worked for me 🤷‍♀️

TL;DR

There is an NPM package named glup-cli and when you are trying to download gulp-cli things can get a bit confusing since the makers of glup-cli also export a bin command called gulp and create a SYMLINK to the spot that the real gulp-cli needs to go. This surfaces in the real gulp-cli being un-installable because something already possesses the SYMLINK for /usr/local/bin/gulp

Recently, I have been making a little webpage for myself (matthewcale.com), and it's coming along just fine I'd say. I am using Pug (Markup) and Stylus (Styles) and Surge (Hosting) along with some neat CSS animations written by very smart folks from around the net. There are incredible folks who have made me feel like I am coding in the year 4000.

At the moment everything I am doing is accomplished with NPM scripts, and everything gets done. It is, however, a tiny bit tedious and I'd like to employ a task runner to get things to really sparkle.

There are a boatload of task runners and bundlers out there. I personally like the amount of control I have using a tool like Gulp and while I haven't used it in a while I still recall it fondly.

I visited their homepage and found out that since I stopped using it for my normal dev life they have changed it a good bit, and now it is suggested that a user have a local task runner and a global CLI tool installed. Not to worry, npm i -g gulp-cli to the rescue. Doh! What happened?

mbp-mcale:~ matt.cale$ npm i -g gulp-cli
npm ERR! code EEXIST
npm ERR! syscall symlink
npm ERR! path ../lib/node_modules/gulp-cli/bin/gulp.js
npm ERR! dest /usr/local/bin/gulp
npm ERR! errno -17
npm ERR! EEXIST: file already exists, symlink '../lib/node_modules/gulp-cli/bin/gulp.js' -> '/usr/local/bin/gulp'
npm ERR! File exists: /usr/local/bin/gulp
npm ERR! Remove the existing file and try again, or run npm
npm ERR! with --force to overwrite files recklessly.

🤔 -- Well, what is this now? Something else already exists there? Well, that's fine I will just remove it!

mbp-mcale:~ matt.cale$ npm uninstall -g gulp
up to date in 0.021s
mbp-mcale:~ matt.cale$ npm uninstall -g gulp-cli
up to date in 0.021s

Let's try again! Doh! Same error? What the heck?

cracks knuckles and neck

Let's figure this out! to the Googles/Stackoverflows!

Googles: "EEXIST: file already exists, symlink"

A bit of a bust to be honest, one well intentioned gentlemen here was having a different problem and his solution was just deleting the items from the package.json and being careful about node versions and environments.

The mystery thickens!

At this point I could try fancier googles, but I am pretty keen on finding the solution myself. So I dawn my spelunking gear and head to

which gulp # --> /usr/local/bin/gulp

Cavern One

mbp-mcale:~ matt.cale$ ls -l /usr/local/bin/gulp
/usr/local/bin/gulp -> ../lib/node_modules/glup-cli/bin/gulp.js

Wait a tick! What the heck is glup-cli?

As it turns out glup-cli is, in my opinion, a poorly named (verging on suspicious) package that will take the place of the global gulp command and instead of running gulp task will, AFAICT, (I didn't run the thing) attempt to scaffold out a basic Express project.

The project, to me, seems to be a misnomer, but there you have it! Uninstall glup-cli and install and gulp-cli and head out being a little less frustrated. 💚