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