Add an initial blog post
This commit is contained in:
parent
cf99106e30
commit
7aef7edf19
2
Makefile
2
Makefile
|
@ -15,7 +15,7 @@ serve:
|
||||||
python -m http.server --directory out/
|
python -m http.server --directory out/
|
||||||
|
|
||||||
pubdate:
|
pubdate:
|
||||||
sed -i "s/pubdate: now/pubdate: $$(date -Isec)/" src/blog/*.md
|
sed -i "s/pubdate: now/pubdate: $$(date -Isec)/" src/blog/**/*.md
|
||||||
|
|
||||||
upload:
|
upload:
|
||||||
./build.py srv/
|
./build.py srv/
|
||||||
|
|
|
@ -0,0 +1,23 @@
|
||||||
|
---
|
||||||
|
title: The traditional first software engineer blog post
|
||||||
|
pubdate: 2023-09-28T15:39:59-07:00
|
||||||
|
feed: blog
|
||||||
|
---
|
||||||
|
|
||||||
|
It seems appropriate for a first post on a blog to explain why the blog exists and how it is built. For people other than software engineers, the latter question is typically not very interesting because the blog is on a blogging site like WordPress or built with a CMS like WordPress. Software engineers, however, have a habit of doing everything from scratch, so they also explain their hosting choice, Emacs plugins, operating system version, and WordPress deployment.
|
||||||
|
|
||||||
|
I do not have a profound answer to either question, so this will be short. I set up this website and this blog to be able to put things on the public Internet and share them with people. Some of those things might not have a particular audience. Someone, somewhere, said something to the effect that teaching something is the best way to learn it. Having to explain something to other people helps solidify your understanding as you are forced to articulate things you had only nebulously grasped before. If I write about how I solved some problem or used some tool, that might also help someone else in the same situation. People learn things differently and sometimes all you need is to see the information presented in the way that clicks for you.
|
||||||
|
|
||||||
|
The explanation of how the blog is built is similarly simple. A directory tree of markup text is parsed by a Python build script into lean HTML and written out to a destination directory tree, which is then uploaded to the server where the files are served. It'd be nice if I could say I used this project to learn a new technology or language, but none of the tools here are new to me. I would defend this decision by saying that I [chose boring technology](https://mcfunley.com/choose-boring-technology), but the reason to choose boring technology is to save your "innovation tokens" for the innovative technology your company is building. A static site and a blog are not innovative, so they do not benefit from token austerity.
|
||||||
|
|
||||||
|
Perhaps this explains the tendency of personal software blogs to sit atop overengineered tech stacks: setting up a blog does not interest the tinkerer unless there is something technologically interesting involved. I don't know if "technologically interesting" is always a virtue; "may you live in interesting times" is considered a curse. I don't want to go down a path where "debugging my blog" could describe my weekend.
|
||||||
|
|
||||||
|
With that said, here are some things I *did* use for the first time while building this:
|
||||||
|
|
||||||
|
* [Python-Markdown](https://python-markdown.github.io/), which has some built-in extensions and supports inline HTML. That lets me do things like insert short page-specific `<script>` or `<style>` blocks.
|
||||||
|
* [python-feedgen](https://feedgen.kiesow.be/), which generates the RSS feeds for this blog.
|
||||||
|
* [pagefind](https://pagefind.app/), which makes a static site searchable without requiring a backend. Neat!
|
||||||
|
* [inotifywait](https://linux.die.net/man/1/inotifywait), which I use to rebuild the site while I develop it. Responsive rebuilds are nothing new in the current year, but it's not complicated to use it in your own shell workflows.
|
||||||
|
* [Applying patches to nixpkgs on import.](https://git.alogoulogoi.com/Jaculabilis/www/commit/75a860a95ad3ea63b53878e5e378403816fd6b9f) I found pagefind while it was still in PR to nixpkgs, and I try to keep my flakes on NixOS releases so I don't have to re-download the entire Linux userspace for every project. Patching it in let me just build it from source instead of having to pull in `nixpkgs-unstable`. I had to include another change not from the PR to get the diff to apply correctly. The PR's merged now, so this only needs to work until 23.11 is released and I upgrade things.
|
||||||
|
|
||||||
|
I considered using [Hugo](https://gohugo.io/), but it seemed like it had a lot more control knobs than I needed, and I would need to learn how to create a theme before I could make a website as minimalist as I wanted. If I end up needing more features for page generation, I might reconsider using it or a similar tool, but I don't think there's a lot of marginal value in that right now.
|
|
@ -0,0 +1 @@
|
||||||
|
* [The traditional first software engineer blog post](./blog-start.md)
|
|
@ -1,3 +1,7 @@
|
||||||
---
|
---
|
||||||
title: Blog
|
title: Blog
|
||||||
---
|
---
|
||||||
|
|
||||||
|
[RSS](./feed.xml)
|
||||||
|
|
||||||
|
* [The traditional first software engineer blog post](./2023/blog-start.md)
|
Loading…
Reference in New Issue