pages/txt/site-changes.txt (view raw)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 |
27 May, 2020
Site changes
New stuff at the {back,front}end
The past couple of days, I've spent a fair amount of time tweaking this
site. My site's build process involves [1]vite and a bunch of
[2]scripts. These scripts are executed via vite's pre- and post-build
actions. The big changes that were made were performance improvements
in the update_index.py script, and the addition of openring.py, which
you can see at the very bottom of this post!
speeding up index page generation
The old script -- the one that featured in [3]Hacky scripts -- was
absolutely ridiculous, and not to mention super slow. Here's what it
did:
* got the most recent file (latest post) by sorting all posts by
mtime.
* parsed the markdown frontmatter and created a markdown table entry
like:
line = f"| [{meta['title']}]({url}) | `{meta['date']}` |"
* updated the markdown table (in _index.md) by in-place editing the
markdown, with the line created earlier -- for the latest post.
* finally, I'd have to rebuild the entire site since this markdown
hackery would happen at the very end of the build, i.e, didn't
actually get rendered itself.
That...probably didn't make much sense to you, did it? Don't bother. I
don't know what I was thinking when I wrote that mess. So with how it
was done aside, here's how it's done now:
* the metadata for all posts are nicely fetched and sorted using
python-frontmatter.
* the metadata list is fed into Jinja for use in templating, and is
rendered very nicely using a simple for expression: {% for p in
posts %} <tr> <td align="left"><a href="/blog/{{ p.url }}">{{
p.title }}</a></td> <td align="right">{{ p.date }}</td> </tr> {%
endfor %}
A neat thing I learnt while working with Jinja, is you can use
DebugUndefined in your jinja2.Environment definition to ignore
uninitialized template variables. Jinja's default behaviour is to
remove all uninitialized variables from the template output. So for
instance, if you had:
<body>
{{ body }}
</body>
<footer>
{{ footer }}
</footer>
And only {{ body }} was initialized in your template.render(body=body),
the output you get would be:
<body>
Hey there!
</body>
<footer>
</footer>
This is annoying if you're attempting to generate your template across
multiple stages, as I was. Now, I initialize my Jinja environment like
so:
from jinja2 import DebugUndefined
env = jinja2.Environment(loader=template_loader,undefined=DebugUndefined)
I use the same trick for openring.py too. Speaking of...let's talk
about openring.py!
the new webring thing at the bottom
After having seen Drew's [4]openring, my [5]NIH kicked in and I wrote
[6]openring.py. It pretty much does the exact same thing, except it's a
little more composable with vite. Currently, it reads a random sample
of 3 feeds from a list of feeds provided in a feeds.txt file, and
updates the webring with those posts. Like a feed-bingo of sorts. ;)
I really like how it turned out -- especially the fact that I got my
CSS grid correct in the first try!
References
1. https://github.com/icyphox/vite
2. https://github.com/icyphox/site/tree/master/bin
3. https://icyphox.sh/blog/hacky-scripts
4. https://git.sr.ht/~sircmpwn/openring
5. https://en.wikipedia.org/wiki/Not_invented_here
6. https://github.com/icyphox/openring.py
|