1 Introduction

I will make no major defense of keeping a personal website in 2026. Honestly it seems that the most likely consumer of this ‘content’ is some web crawling program to feed some AI chat bot as we slip farther down the track of AI generated slop overwhelming the human stuff. But that’s OK - I don’t mind so much, I’m trying to take a somewhat ambivalent view to AI in general and that is absolutely not the point of this memo. I am redesigning my personal website because I want to, and I want to write more things for it because I like to look back at earlier projects. Also the origami torus gets a couple of torii a year and that is always awesome.

In this memo about the website redesign we will discuss four main topics:

1. The Content of my personal website, you know - the stuff that’s on it and the stuff that I would want to put on it. This is fundamentally the most important part of this whole exercise, so properly motivating that is first and foremost.
2. The Ergonomics of how I want to work with the website, how I want to write material for it and what that means for me.
3. The Aesthetics of the website and why it looks the way it does. My design skills are somewhere between extremely rough and non-existant so justifying this is a bit tricky, but I will try. And finally,
4. The Technology behind the website, how it is developed and deployed. Some of this might be interesting or useful in your own efforts, but honestly it is primarily to help me in the future.

2 Content

I am an engineer and I’m mostly motivated by technically interesting content. I like seeing things that are elegant, well thought out, educating about topics I care about, interesting, etc. So wouldn’t I want to create similar content? That is where some of my earlier projects came from.

Providing instructions for the origami torus and collecting pictures of torii from around the world is awesome to me and highly motivating. I always feel really happy when a new torus is emailed over. Also, finishing my work on the game of ur is VERY much on my list of things to do within the near future, and I think that is interesting and relevant and enjoyable. I have actually gone back and looked at some of me earlier work memos when I needed to remind myself of something I did a long time ago, and it’s just way nicer to have them then not.

The content that I want to see on matthewdeutsch.com is more interesting memos about topics that are relevant to me. Optimization, engineering, art, speedrunning, video gaming, computer science, and more. Hopefully I can make this happen.

I am inspired by a few other websites including Paul Bourke’s and Stefan Huber’s. I know I am missing a bunch that I will hopefully remember to sneak in here later.

3 Ergonomics

The ergonomics of the website are extremely important. I must be able to open vim, write some words, then push to a git repo, and it automatically deploy. Additionally, while I’m writing I must be able to just :w the file to see a live preview. It should all be quite seamless and in line with everything else I do.

The actual content creation process should be seamless, which is an important and subtle point. The smallest inconvenience to creating and updating the website can throw me off for years. One of the big reasons for the complete lack of articles between 2019 and now is that it was just too much of a pain to write anything! My original website was hosted in an s3 bucket that I literally managed with the s3 command line app downloading files, editing html by hand, and reuploading it.

I should be able to do something like this in my terminal:

cd repos/matthewdeutsch.com
python new-memo.py something-cool
vim src/projects/something-cool/index.md
    # blah blah blah
git add *
git commit -m 'Article about something cool'
git push

And be done. With of course minor changes here and there, like creating a zsh alias for those first three, and launching the live reload server and a browser etc. This level of ergonomic convenience is a necessary - but unfortunately not sufficient - condition for furthering my goal of documenting and organizing my personal projects here.

4 Aesthetics

Good artists copy, great artists steal or something like that, but it takes an even greater artist like me to not only steal but make it worse in the process. That’s why this website currently looks like a knockoff Bell Labs memo. Because it is.

Honestly I just want something that is simple, has the features I want, and looks clean and minimal. I don’t really like too many extra design elements, and I love the elegance of good ol’ plain text on a page. That being said I do need to incorporate images, tables, equations, and the like.

5 Technology

This is a static website with no backing database or other dynamic services that need to be running at the same time, so the only real technology involved is to avoid mistakes and avoid writing html directly. There are a ton of static site generators out there, and they are all awesome and blah blah blah but you see - if I wanted to use an existing static site generator I would have to learn how to use it! That takes time and effort! Instead, why don’t I just write my own with a fraction of the features and twice the bugs in about quadruple the time it would take me to learn something.

My static site generator is a python script that has a build function. The build function first uses rsync to copy every file from my src/ directory to the generator public/ directory with a few exclusions. Markdown files and extra files in any folder named _dev/ are not copied. This is because the markdown files will be compiled into html and the _dev folder is for any scripts / notebooks / programs / intermediate figures etc. rsync is nice because it only copies things that have changed, it has a ‘clean’, feature to keep things tidy, and is super easy / fast to set up.

Then a second pass over the source directory compiles all the markdown files to html using pandoc. Pandoc is incredible and I highly recommend it. The pandoc command is kinda lengthy to handle things like equations and the bibliography. I also use a few custom lua filters to coerce things into the exact format I want - sure I could probably write them in Haskell (which is what pandoc is written in) - but again then I would have to learn me a haskell for great good, and that sounds like a whole thing.

In addition to the build function, I added a watch function. This uses the python livereload module to run a little web server on localhost that I can connect to with the browser. Then whenever I save the file it will automatically recompile the website and I don’t have to refresh the page. This is ABSOLUTELY VITAL. I refuse to work on any web application without live reload because I already spend all my life doing ‘alt-tab up-arrow enter alt-tab’ to recompile my c++ code - not doing that here!

Two other little functions in the main dev python script are:

• A command to convert bibtex entries to the csl yaml format which is embedded in the frontmatter yaml of each post with a bibliography.
• A command to create a new memo with some nice arguments to set title / put it in the write spot etc.

All of this is then tracked in a git repo which is on my Gitea instance running on my unraid homelab. One day I may write a memo about that setup. But the best part there is that when I push to the main branch, it kick’s off an action that automatically deploys to aws amplify.

6 Conclusion

Will refreshing my website motivate me to write more articles? I don’t know - but it can’t hurt.