Building This Site
I’ve been a denizen of the internet since I was in middle school. I learned html to participate in roleplaying games; my friend introduced me to the game, then showed me how everyone styled their posts. once I realized I could write html, it wasn’t long before I discovered geocities and started building my own sites.
after high school I wanted a quick job to put me through a master’s in psychology, and building websites seemed like a good way to do that. I started with some design classes, realized that wasn’t really for me, and switched to a more software-focused course where someone showed me dhh’sfive minute blog video and got me hooked on rails.
every couple of years since discovering geocities, I get an itch to rebuild my website. and after dabbling with using rails, I realized I just wanted something more simple so I switched to jekyll.
the stack
jekyll gives me a clean separation between the content and the formatting. part of what pushed me toward software in the first place was wanting to stop copy-pasting the same html across every page — includes were a revelation, and jekyll’s templates scratch that same itch.
the css is tailwind v4 via postcss. I build up the design by stacking utility classes on an element, then consolidate them into proper classes with @apply once I’m happy with it. I don’t plan to completely eschew the utility classes. finally, the constraints of the design tokens help me make decisions instead of agonizing over exact values.
nix flakes keep the environment locked to specific versions. version mismatches have bitten me enough at my day job that i’ve come to really value reproducibility. the gemfile is locked by nix, but i still need to figure out how to do the same for node modules.
deployment
notes, articles and even the project files all live in my obsidian vault. since my technical notes sit right next to my drafts, it’s easy to pull something I just learned into an article or update a project page without switching contexts.
once an hour the vault autocommits and pushes to a staging branch that builds the site. this lets me review everything and make sure I’m not putting anything out there that I don’t want public. when I’m ready to cut a release, I squash the commits onto a release branch that autodeploys.
what’s next
the notes section still needs a little more refinement before i feel like it’s ready for public consumption. the project portfolio needs to link to actual repos instead of placeholder urls. and maybe a few more indieweb pages.
but for now, the site exists. that’s the hardest part out of the way.
This post is referenced from the colophon page.