I am hoping this will be the first of three or four posts detailing some of the technical bits under the covers of the new website. In this particular post I'll talk mostly about the design decisions that went into the whole infrastructure.
All of this works for me, and is based on my use-case. It is entirely possible that your application may be different and some of the decisions I made won't work for you, but at least you can hopefully understand the reasons behind it all.
So first, the givens
- I want to host this myself, with as little external dependencies as possible.
- My site is fairly small
- I have some images I'd like to have a home for.
- Sometimes I write things, but not a lot.
- I have some code splashed around, that is fun to share.
What I chose to do
- The entire site is made up of static pages served off disk.
- All the HTML and CSS is hand-written.
- The gallery generator is also pre-processed and served directly from disk.
- This entire blog is rendered from the same templates as the base site and markdown fragments to contain the article content.
- I trigger all of this off a post-receive hook in my git repository.
Why
This allowed me to hand-create a single HTML template that gets applied virtually everywhere (the gallery has bespoke templates for it). I was able to craft a responsive design with almost zero JavaScript (only the mobile interface for the gallery uses JavaScript (jQuery)), which makes me happy. The site looks reasonable across desktops, phones, and tablets. It doesn't expose any data to any third-party sites. It is fast to load and render. It takes almost no server resources to serve.
Most of the pieces (which I will go into detail in the next few posts) have been around for a while but it is how I'm putting them together that makes it so much easier to maintain. I collapsed a lot of the templates down to a single base template class and only customize the bits needed to make each page. I also went from triggering this all out of cron(8) on the hour to building it when a change is pushed to the server. This not only saves server resources rebuilding things when nothing has changed, but also makes it so the errors are immediately noticed (in the git push output instead of in a cron mail that I may ignore).
Hopefully this makes sense. Next time I'll start talking about the oldest part of the site -- the template builder.