moreward's posts

moreward — Wed, 04 Feb 2026 01:56:00 PST

It's so weird that you can build a fairly high level of trust with someone you met on the internet, that you don't even know the real name of, but worked on a project together with.

I mean you build some level of trust with folks on twitter too, but adding the "working together" bit is the magic sauce.

moreward — Mon, 02 Feb 2026 23:03:00 PST

Build for a purpose. Don't spend time on unnecessary tech noodling. Watch this Ted Bendixson's "Better Software Conference 2025" talk on youtube for some inspo.

moreward — Mon, 02 Feb 2026 13:14:00 PST

(Test post) OK, I think it kinda works and looks OK now. (BTW we need light mode)

moreward — Mon, 02 Feb 2026 11:30:00 PST

I just enabled short posts on my blog. Perhaps I'll also see if I can make it easier to just post here whenever I want. Should be just a simple script.

Docker for consistency

moreward — Sun, 06 Apr 2025 02:30:00 PDT

Docker and docker-compose

I run all my non-static sites/webapps on a small VPS. I have very little installed on the VPS. For example, although most of my sites are node.js these days, I don't have node or npm installed there. But I do have docker along with make and git installed.

VPS use

Sites, DBs, helpers (like monitoring tools) all run in docker containers, and are kept up via docker compose. This is sort of a setup-and-forget thing for the most part which is nice. But see the beware section below for some warnings!

Devbox use for web dev

Since I use the same image locally on my MacBook, my test environment during development is mostly a good representative of livesite environment.

Consistent builds for native dev

This also applies for projects that need build steps. Same build runs on my macbook and github CIs, for example. You can build Linux or Windows binaries (via mingw) or WASM (via emscripten) from a single image!

Use for older libc linking

Standard practice in linux is to dynamically link your apps against the system libc. However, there re good use cases for static linkink as well. The trouble is this is not well supported. If you, for example build and statically link your app in Ubuntu 24.04, there's a chance that you can't run it on Ubuntu 20.04 or other distros with different libc builds.

In this case, just use a Docker based on Ubuntu 18 or whatever minimum you'd like to match.

Lyte2D builds use this mechanism to get a broader set of linux distributions supported with a single binary.

(Though there seems to be a new sort of solution that I should investigate.)

Beware

Open ports & security concerns: Unfortunately whenever you open a port for your container it makes a hole in your host system's firewall. Some reddit notes. There are workarounds with various tradeoffs. I personally chose to disable iptables completely for docker on my VPS. (Ask me if you need more details.)
OOMs: Docker constainers have default limitations for memory use. And if you pass them your image gets killed. Keep this in mind for your testing strategy

Alternatives?

You can run things on the host. Could be managable but can get chaotic. Easier to make mistakes.
You can use something like Nix (you'd love this one if you're a Rust or Haskell person, for example.)
You can use VMs (but these would be more expensive both in $$$ and in time.)

I personally found Docker (+ make) to be a sweet spot for a high capacity/complexity ratio.

Makefiles for scripting

moreward — Fri, 04 Apr 2025 17:00:00 PDT

GNU make is an old tool designed to build C codebases. I don't use it for that purpose though. For projects that are larger than a few files, I just pull cmake these days.

But... make itself is still very useful to get basic scripting going in my codebases and elsewhere.

I use Makefiles to

Call cmake/zig build/npm etc with various options to build projects
Execute tests
Build/run docker images
Deploy sites and apps
And more...

Basics of make

So how do you use it? You'd typically use it with a dev project, so let's assume you're in your project's top level directory:

You write a Makefile, like the one below
Call the default target with make
Call any other target with make config-test
Override variables with make build-tests BUILD_DIR=../tmp/test

Here's a very simple example:

# Makefile comments start with a `#` and run till the end of the line.

# Targets are defined with a name and a colon.  First ever target in the file is the "default"
# It is the target that runs if there are no arguments passed to `make`.
# The dependencies of the target are listed after the colon, whitespace separated
# Those are executed before the target tasks
# Tasks that the target will run in cmdline, one by one, are listed below the target name, indented with `tab`s (not spaces!)

my-default-target: run-tests
	echo "done."

# You can define variables like so
# You can override these varibles from command line while invoking make.

BUILD_DIR = ./_build

# Some other targets below:

clean-test:
	rm -rf ${BUILD_DIR}

config-test:
	mkdir -p ${BUILD_DIR}

build-test:
	cc -o ${BUILD_DIR}/test -I src src/apic.c test/test.c

# This is the target that `my-default-target` depends on.
# And it depends on a few others.

run-test: clean-test config-test build-test
	${BUILD_DIR}/test > ${BUILD_DIR}/a.txt
	cat ${BUILD_DIR}/a.txt

The idea is, instead of many script files, all scripting tasks are contained in a single location. In zsh (and others probably) you can get a tab completion for the target names, so it's very comfy.

Be careful with "weird" parts

Indentation should be done with tabs. Editors usually are aware of this, at least vscode is.
Target names should not match the files in the folder where Makefile resides. This is due to the fact that make is actually made to build NAME.c files. If you have to have targets matching filenames, look up .PHONY targets. In order to keep things simple, I use a - in my target names and I almost never have filenames with that.

Advanced: zsh tab completions

Add the following in your ~/.zshrc:

# makefile completions
autoload -Uz compinit
compinit
# only makefile targets, not files!
zstyle ':completion::complete:make::' tag-order targets variables

Advanced: `show-help` target

See this example, it's actually this blog's current Makefile:

-default: watch-dev

##########
show-help: ## show help
	@echo "Available targets:"
	@grep -E '^[a-zA-Z0-9_-]+:.*?## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = ":.*?## "}; {printf "  \033[36m%-30s\033[0m %s\n", $$1, $$2}'
	@echo "Defined variables:"
	@grep -E '^[a-zA-Z0-9_]+\s*=\s*[^#]*## .*$$' $(MAKEFILE_LIST) | sort | awk 'BEGIN {FS = "\s*=\s*.*?## "}; {printf "  \033[33m%-30s\033[0m %s\n", $$1, $$2}'
##########


ELEV = npx @11ty/eleventy  --output=docs

clean-site: ## clean docs folder (CAREFUL)
	rm -rf docs
	mkdir docs

watch-dev: clean-site ## serve dev server in watch mode
	${ELEV} --serve

build-site: clean-site ## build site
	${ELEV}

serve-site: ## serve from docs for testing
	npx http-server docs

DEPLOY-SITE: build-site  ## DEPLOYS TO PROD
	git add -A
	git commit -m "update"
	git push origin main

In this version, we have a show-help target which is also set to display the list of targets and variables with some shell magic. All the targets and variables that have ## ... comments after them will be listed, along with the comment, which is supposed to be the help text for that target/variable.

mg ~/code/morew4rd.com $ make show-help
Available targets:
  DEPLOY-SITE                    DEPLOYS TO PROD
  build-site                     build site
  clean-site                     clean docs folder (CAREFUL)
  serve-site                     serve from docs for testing
  show-help                      show help
  watch-dev                      serve dev server in watch mode

Hello anon

moreward — Fri, 04 Apr 2025 13:20:00 PDT

Welcome to my blog

I've setup eleventy to get some simple site generation going and replace my janky lua scripts. It has a nice sample that I used to get started. I simplified my version even further.

Played with it a bit and so far so good.

What will I talk about?

Take a look at my ~~twitter~~ x.com feed, it will likely look similar. But more in depth. Probably 😅

Truth is it's impossible to predict the future, so we'll see.

Comments?

Too much work to directly support them. Hola at me at X, email, discord or elsewhere.

Who are you?

I'm an anon who likes to build things. Some links in the main page.