Remove old code related to static, it's not needed anymore

1 files changed, 0 insertions, 247 deletions

diff --git a/static/src/_posts/2021-01-23-goodbye-github-pages.md b/static/src/_posts/2021-01-23-goodbye-github-pages.md
deleted file mode 100644
index e85ca81..0000000
--- a/static/src/_posts/2021-01-23-goodbye-github-pages.md
+++ /dev/null
@@ -1,247 +0,0 @@
----
-title: >-
-    Goodbye, Github Pages
-description: >-
-    This blog is no longer sponsored by Microsoft!
-tags: tech
-series: selfhost
----
-
-Slowly but surely I'm working on moving my digital life back to being
-self-hosted, and this blog was an easy low-hanging fruit to tackle. Previously
-the blog was hosted on Github Pages, which was easy enough but also in many ways
-restricting. By self-hosting I'm able to have a lot more control over the
-generation, delivery, and functionality of the blog.
-
-For reference you can find the source code for the blog at
-[{{site.repository}}]({{site.repository}}). Yes, it will one day be hosted
-elsewhere as well.
-
-## Nix
-
-Nix is something I'm slowly picking up, but the more I use it the more it grows
-on me. Rather than littering my system with ruby versions and packages I'll
-never otherwise use, nix allows me to create a sandboxed build pipeline for the
-blog with perfectly reproducible results.
-
-The first step in this process is to take the blog's existing `Gemfile.lock` and
-turn it into a `gemset.nix` file, which is essentially a translation of the
-`Gemfile.lock` into a file nix can understand. There's a tool called
-[bundix][bundix] which does this, and it can be used from a nix shell without
-having to actually install anything:
-
-```
- nix-shell -p bundix --run 'bundix'
-```
-
-The second step of using nix is to set up a nix expression in the file
-`default.nix`. This will actually build the static files. As a bonus I made my
-expression to also allow for serving the site locally with dynamic updating
-everytime I change a source file. My `default.nix` looks like this:
-
-```
-{
-    # pkgs refers to all "builtin" nix pkgs and utilities. By importing from a
-    # URL I'm able to always pin this default.nix to a specific version of those
-    # packages.
-    pkgs ? import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/cd63096d6d887d689543a0b97743d28995bc9bc3.tar.gz") {},
-    system ? builtins.currentSystem,
-}:
-
-    let
-        # bundlerEnv looks for a Gemfile, Gemfile.lock, and gemset.nix inside
-        # gemdir, and derives a package containing ruby and all desired gems.
-        ruby_env = pkgs.bundlerEnv {
-            name = "ruby_env";
-            ruby = pkgs.ruby;
-            gemdir = ./.;
-        };
-    in
-        {
-            # build will derive a package which contains the generated static
-            # files of the blog. It uses the build.sh file (provided below) to
-            # do this.
-            build = derivation {
-                name = "mediocre-blog";
-
-                # The build.sh file (source provided below) is executed in order
-                # to actually build the site.
-                builder = "${pkgs.bash}/bin/bash";
-                args = [ ./build.sh ];
-
-                # ruby_env is provided as an input to build.sh so that it can
-                # use jekyll, and the src directory is provided so it can access
-                # the blog's source files. system is required by the derivation
-                # function, and stdenv provides standard utilities to build.sh.
-                inherit ruby_env system;
-                src = ./src;
-                stdenv = pkgs.stdenv;
-            };
-
-            # serve will derive an environment specifically tailored for being
-            # run in a nix-shell. The resulting shell will have ruby_env
-            # provided for it, and will automatically run the `jekyll serve`
-            # command to serve the blog locally.
-            serve = pkgs.stdenv.mkDerivation {
-                name = "mediocre-blog-shell";
-
-                # glibcLocales is required so to fill in LC_ALL and other locale
-                # related environment vars. Without those jekyll's scss compiler
-                # fails.
-                #
-                # TODO probably get rid of the scss compiler.
-                buildInputs = [ ruby_env pkgs.glibcLocales ];
-
-                shellHook = ''
-                    exec ${ruby_env}/bin/jekyll serve -s ./src -d ./_site -w -I -D
-                '';
-            };
-        }
-```
-
-(Nix is a bit tricky to learn, but I highly recommend chapters 14 and 15 of [the
-nix manual][manual] for an overview of the language itself, if nothing else.)
-
-The `build.sh` used by the nix expression to actually generate the static files
-looks like this:
-
-```bash
-# stdenv was given a dependency to build.sh, and so build.sh can use it to
-# source in utilities like mkdir, which it needs.
-source $stdenv/setup
-set -e
-
-# Set up the output directory. nix provides the $out variable which will be the
-# root of the derived package's filesystem, but for simplicity later we want to
-# output the site within /var/www.
-d="$out/var/www/blog.mediocregopher.com"
-mkdir -p "$d"
-
-# Perform the jekyll build command. Like stdenv the ruby_env was given as a
-# dependency to build.sh, so it has to explicitly use it to have access to
-# jekyll. src is another explicit dependency which was given to build.sh, and
-# contains all the actual source files within the src directory of the repo.
-$ruby_env/bin/jekyll build -s "$src" -d "$d"
-```
-
-With these pieces in place I can easily regenerate the site like so:
-
-```
-nix-build -A build
-```
-
-Once run the static files will exist within a symlink called `result` in the
-project's root. Within the symlink will be a `var/www/blog.mediocregopher.com`
-tree of directories, and within that will be the generated static files, all
-without ever having to have installed ruby.
-
-The expression also allows me to serve the blog while I'm working on it. Doing
-so looks like this:
-
-```
-nix-shell -A serve
-```
-
-When run I get a normal jekyll process running in my `src` directory, serving
-the site in real-time on port 4000, once again all without ever installing ruby.
-
-As a final touch I introduced a simple `Makefile` to my repo to wrap these
-commands, because even these were too much for me to remember:
-
-```
-result:
-	nix-build -A build
-
-install: result
-	nix-env -i "$$(readlink result)"
-
-clean:
-	rm result
-	rm -rf _site
-
-serve:
-	nix-shell -A serve
-
-update:
-	nix-shell -p bundler --run 'bundler update; bundler lock; bundix; rm -rf .bundle vendor'
-```
-
-We'll look at that `install` target in the next section.
-
-## nginx
-
-So now I have the means to build my site quickly, reliably, and without
-cluttering up the rest of my system. Time to actually serve the files.
-
-My home server has a docker network which houses most of my services that I run,
-including nginx. nginx's primary job is to listen on ports 80 and 443, accept
-HTTP requests, and direct those requests to their appropriate service based on
-their `Host` header. nginx is also great at serving static content from disk, so
-I'll take advantage of that for the blog.
-
-The one hitch is that nginx is currently running within a docker container,
-as are all my other services. Ideally I would:
-
-* Get rid of the nginx docker container.
-* Build a nix package containing nginx, all my nginx config files, and the blog
-  files themselves.
-* Run that directly.
-
-Unfortunately extracting nginx from docker is dependent on doing so for all
-other services as well, or at least on running all services on the host network,
-which I'm not prepared to do yet. So for now I've done something janky.
-
-If you look at the `Makefile` above you'll notice the `install` target. What
-that target does is to install the static blog files to my nix profile, which
-exists at `$HOME/.nix-profile`. nix allows any package to be installed to a
-profile in this way. All packages within a profile are independent and can be
-added, updated, and removed atomically. By installing the built blog package to
-my profile I make it available at
-`$HOME/.nix-profile/var/www/blog.mediocregopher.com`.
-
-So to serve those files via nginx all I need to do is add a read-only volume to
-the container...
-
-```
--v $HOME/.nix-profile/var/www/blog.mediocregopher.com:/var/www/blog.mediocregopher.com:ro \
-```
-
-...add a new virtual host to my nginx config...
-
-```
-server {
-    listen       80;
-    server_name  blog.mediocregopher.com;
-    root         /var/www/blog.mediocregopher.com;
-}
-```
-
-...and finally direct the `blog` A record for `mediocregopher.com` to my home
-server's IP. Cloudflare will handle TLS on port 443 for me in this case, as well
-as hide my home IP, which is prudent.
-
-## Deploying
-
-So now it's time to publish this new post to the blog, what are the actual
-steps? It's as easy as:
-
-```
-make clean install
-```
-
-This will remove any existing `result`, regenerate the site (with the new post)
-under a new symlink, and install/update that newer package to my nix profile,
-overwriting the previous package which was there.
-
-EDIT: apparently this isn't quite true. Because `$HOME/.nix-profile` is a
-symlink docker doesn't handle the case of that symlink being updated correctly,
-so I also have to do `docker restart nginx` for changes to be reflected in
-nginx.
-
-And that's it! Nix is a cool tool that I'm still getting the hang of, but
-hopefully this post might be useful to anyone else thinking of self-hosting
-their site.
-
-[jekyll]: https://jekyllrb.com/
-[bundix]: https://github.com/nix-community/bundix
-[manual]: https://nixos.org/manual/nix/stable/#chap-writing-nix-expressions