Bit flipping laboratory & Personal website
No sneaky cookies haunt these pages, but whether someone tracks you I do not know. Information flows through many channels, and every action leaves a trace.
American law asserts and usually honors the individual right of self expression. New England residents usually accept diversity in individuals. In my head, and especially in my past, the situation was very different. Some thoughts were wrong, many feelings were "inappropriate", and self-censorship was a way of life. In adulthood I eventually found social groups where people encourage deep communication and honesty. I found a meditation practice that welcomes every thought and feeling without filters and without judgement. Feelings come, feelings go.
In some ways, I benefited from being mostly silent. I learned to listen and understand people. I avoided unecessary conflict. In other ways, I missed the boat. Expressing myself could have helped me understand myself better sooner. It could have helped me form closer connections with more people sooner. A personal website is about public expression, which in my opinion is the least useful kind. My hope is not to use a website as a megaphone or to convince people of things. It's to help me explore and communicate a little more precisely than I can in my head or in conversation with friends, and I hope it will be helpful to others too.
It's so early 2000's, like when I first thought of doing this, except now it's HTML 5!
Here are some of my ideas. From there it's figuring out the best technology stack, and starting to make some things happen with my spare time.
Articles. I want to write short posts about my life, and about technical topics I explore. These are among the most standard forms of content people create online. Standard blogging platforms would be appropriate, if these were my only goals.
Image galleries. Of course I want to augment some of my articles with captioned pictures, like a phto album. I surprisingly couldn't find much in the way of standard widgets that support the relatively simple layout I'm envisioning, so direct control over the HTML would be nice.
Math and code snippets. With math and computer programming among my deepest interests, I certainly want to share code and possibly formulae that pure HTML can't render well too. There are standard solutions here. Some are based on generating images. Others lean on Javascript.
Interactive fiction. I'm not sure if I'll actually do it, but I always thought it would be fun to write stories where readers navigate pages based on what they want the character to do. The naviagation would need to be stylized, probably not something standard blogging platforms would offer.
Argument maps. I have a longstanding curiosity in developing navigable online argument mapping software and documenting niche belief systems. I'll definitely be generating pages programmatically from data - if not for interactive fiction, then for this.
Free hosting. I don't see a way around paying for the domain name, but I have to believe in the 2020's there are tricks to not pay for site hosting - especially if the site is only static content and has no hard uptime or latency requirements.
One technology stack usually isn't universally better or worse than another. Good choices depend a lot on context: your skill set, what you're trying to accomplish, time constraints, and likely many other considerations. There are so many choices. The vision for me boils down to some kind of templating language with the full feature set of HTML, available, a dynamic web framework to run locally, and a free web hosting service. Additionally the hosting service needs to be able to run the webapp, or I find some utility to crawl the site and convert it into static content.
There are a lot of templating languages out there. The idea is you want reusable pieces of content that are easy to work with, instead of straght HTML. You also want to be able to make the content of some pages depend on external data, like when you are making an index of articles. I went with mako. Mako templates are little like PHP files in the sense you intermingle HTML with scripting, except that with Mako the scripting language is python. They also support templates that use an HTML-like notation. And you can nest your templates. I may come back and talk about the pros and cons of working with mako later.
I also considered hugo, which is a full static website builder that supports a mixture of Markdown and HTML. Markdown looks nicer than HTML for most things, and it's also less cumbersome to work with; but for complicated things the flexibility of HTML is just the only choice, and I'd rather work with one templating language than two. The main reason I decided against hugo though was I think the site structure it imposes would be too rigid for argument maps and interactive fiction. A quick search will reveal there are countless other choices for templating languages too.
Like most things python, you can choose from way too many web frameworks. I don't know anything about any of them, but I chose pyramid because it claimed to readily support mako templates.
pip install pyramid pyramid_mako
The annotation-based configuration is a little annoying, but so far the framework is good enough. A project like this isn't sophisticated, and shouldn't stretch the limits any web framework very far.
I also considered using the mako library directly, and rolling my own build phase that produced HTML from the templates via a script. That worked, but the downside was it was inconvenient to run the script every time I wanted to see what a page looked like in the browser. The library was fairly easy to work with anyway.
I found that GitHub Pages provides free web hosting with a custom domain name. You can't host webapps though, only static content. Luckily wget can help convert a webapp into static content. There are some nuances to getting it set up. You create a special publishing repository, sbaldasty.github.io in my case, and tell GitHub that is your site. There can be more complicated workflows, which I didn't use.
To set up a custom domain name you need a CNAME file in the publishing repository root that contains the domain name. There are additional steps on the domain name side, like setting up A records. For the moment, I won't document those here since I am eager to get to work on other things.
This series of commands deploys the static website to GitHub Pages. The current directory should be where your Pages repository is checked out. If combining the commands into a single bash script, then configuring the script to terminate on errors is also nice. That way in case someting goes wrong with the static content generation, the actual deployment does not take place.
# Update in case site was deployed from another device git pull # Delete everything except the .git directory find . -mindepth 1 -not -path './.git*' -delete # Convert webapp to static content wget --mirror \ # Add .html extensions when needed --adjust-extension \ # Recursively copy referenced resources --page-requisites \ # Don't copy resources higher up the tree --no-parent \ # Don't wrap the whole site in a subdirectory --no-host-directories \ # Where to start from http://localhost:6543 # Restore CNAME for GitHub Pages echo "bitflippin.com" > CNAME # Deploy changes git add . git commit -m "sync static site" git push
The idea is to delete all the content in the publishing repository locally except for the git metadata, and then use wget to reconstruct it from scratch. This should result in a nice clean diff to push, with the just latest changes. There's an extra step to restore the CNAME file, because I found restoring it easier than excluding it from being deleted in the first place.
