I'm thinking about how to implement a search engine for this website. Since I rent the server from Hetzner and manage the OS and all software packages, I have a bit of freedom when it comes to my tech stack.

My requirements:

• Server side
• Fast
• No javascript whatsoever

What about tinysearch? It ticks all of the boxes except for javascript.

So how am I going to do this? Here are the technical specs for this site:

Static Site Generator: Zola
Web Server: Static Web Server
Git Web: rgit / GitHub mirror
Reverse Proxy: Caddy Docker Proxy

With that in said, almost my entire software stack is Rust-based. I almost think that I can create a server application that can utilize Zola's search index and render the results in realtime using Tide and Tera, without javascript. I really hate javascript... If I can do that, I can then create a /search slug and use the reverse proxy to forward traffic to the application.

I need to think about this.

I've come to realise that while Zola is almost exactly what I am looking for in a site generator, some things are slightly too hard-coded. Such as Taxonomy pages. I would love for the slugs to be at /blog/tags/tag but it can never be. 😢 As a result, my template needs quite a bit of refactoring, which I'm happy to do after I check this whole thing into git.

I really don't want to have to move my blog outside of the /blog/ directory. Since I have the tags on the blog and individual tag pages in the header, I will redirect the /tags/ slug to a 404 template, or maybe 403. I think 404 is a bit cleaner.

I've been feeling like I'm hitting limitations on berrygen's capabilities. For example, I was unable to generate a feed of posts without manually making the links in a Markdown document. Since the requirements are so rigid, I think that my only way forward was to use a batch script to pipe the output file back into itself repeatedly. At the time of writing, there are 48 (now 49!) entries on this site. That would mean I need to process the same file 49 times, appending a shortcode at the end for the next post to render.

Once that was done, there was still the case of pagination. I had no access to the collection of objects without first generating a page with a collection of objects, and then using that as a source for the next pass, which eventually brought my project out of scope. That means only one thing. My implementation was far too inefficient and unwieldy.

In my search for a decent static-site generator using only Rust, I found Zola, which is powered by Tera. Some initial tests using my existing template were rather successful since Tera is inspired by Jinja2, and I was using minijinja in berrygen. There were some errors related to shortcodes, and the output was almost identical, with mine being cleanly formatted. The frontmatter (or grey-matter, in my case) needed adjusting, and I had to import the entries from jrnl and process those as individual files. Zola also allows me to use extra frontmatter that isn't serialized to a struct. I couldn't figure out how to implement that in my own implementation without crashes or forcing the user into an extremely tight box, even when parsing the extra frontmatter as a HashMap.

Once I had my posts formatted and exported from jrnl, Zola just worked. I don't mean it just worked, it worked even after deviating from the "Getting Started" guide and immediately jumping into making my own template, unlike Hugo, which had a gosh-darn stroke out of the box without any sort of helpful error messages. I discovered that sometime in June when I was helping a good friend setup his art portfolio.

All in all, this whole thing was a learning experience. Not every project will be a success, nor will every project get finished or published "because it needs to be".

Good morning! I'm working on something called berrygen. It is a Rust application that generates static websites, utilising most of the code from livejrnl-rs. It is yet again powered by minijinja under the hood.

In its current form, this website is being generated from Markdown files in a directory. Each file is passed to berrygen using a shell script to loop through the files in the directory. There is no support for jrnl and there will not be. I am dropping jrnl support because I write most of my entries in Obsidian. When the time comes, I will be writing an exporter to export the jrnl files to be used with berrygen.

Any posts before this one will be from the import. I will publish the source when it is in a state to be shared.

🎵 Music: Silverchair - Madman

This is my attempt at actually getting images working. I initially planned on base64-encoding the images like I do with the template, except that if I wanted to reuse the images in other posts, it would be kind of ridiculous and not efficient.

The plan is to attach things in Obsidian, and then have the build script copy the images to the output directory. I just have to ensure that I change the image link format from something that Obsidian uses to something that Markdown uses. I could use Markdown style links throughout Obsidian, but seeing as I also write stories and cross reference notes with one another quite often, I prefer to keep the Wiki styled links.

Anyway. Let's try this. This is my current profile picture on Mastodon. I made it myself in Inkscape. 😄

It looks like like it works, but of course I'll need to style it with CSS. I'm excited about this. 😄

Edit: (2023-02-11 12:55) I've decided on a max-width of 95% and have the images centered with a border since I'm mainly going to use them as figure diagrams or to share screenshots in my posts.

I didn't exercise but I did publish the build script that I use for this site. You can find that here.

My mental health has been getting so much better now that I've allowed myself some time to relax. I do need to start the job search soon, but that will come once we are properly moved in. I can't do a 3 hour commute one way just yet.

It has been an incredibly productive day. I published LiveJrnl, did some dishes, and took out the recyclable garbage.

I think I'm going to exercise in a little bit.

Unlimited POWAAAAA!*~

I found a shell command extension for Obsidian on PC that let me put scripts in the command palette. So naturally, I decided that I wanted to fully generate the journal and build the site from within Obsidian. Sooo...

I manually split up the original journal.txt into their individual journal entry files in the Journal directory because I'm an idiot. I could have written a script to do that, but it was literally faster to just copy and paste the files, and fix the headers.

Ya know what? I'm, pardon my French, really fucking proud of myself for this project. I've got some really cool automation going on through the command palette.

I first generate journal.txt and then I run the shell script to build the journal.

rm /home/holly/.config/jrnl/journal.txt && cat Journal/* >> /home/holly/.config/jrnl/journal.txt && /home/holly/Projects/livejrnl-builder/build.sh

Really excited. 😄

Edit: (2023-01-30 18:16) Snippets for documenting post edits works really well.

This is the first post I'm writing from Obsidian. I love jrnl, but it is so not suitable for longer posts. Or writing from Mobile. Really, this Obsidian compatibility layer is for when I'm writing posts on the go. Or much longer posts. You get the idea.

This whole thing is powered by the Templater plugin. I have a jrnl folder that triggers a template when a file is first created. It sets the date and time stamp, then asks the user for the post title. From there, I am free to write.

To sync my changes, I have another template with a single user script command that runs the following system command:

cat '/home/holly/Obsidian/brain-droppings/Journal/2023-01-30.md' >> /home/holly/.config/jrnl/journal.txt

The only downside to this is I'd have to edit the file manually in Sublime if I wanted to make changes to the post.

OR

I could use the absolute power of Python, and loop through all of the posts in the jrnl folder in the Obsidian vault, and generate an entirely new journal.txt that LiveJrnl can use... Which would effectively scratch the itch that I created in this post. Of course, that would mean I would no longer need jrnl for an editor and would only be using their file format... I'd also have to handle encrypt--I'm sorry, where were we? 😅

Now let's see if my journal takes a huge dump when I save this... 🤞

I changed the colour scheme to Pastel-16 and made a custom background image. I call this whole journal theme 🍦Ice Cream Shop🍦 The background is Mint Chocolate Chip and the individual posts are Neapolitan. I just LOVE it!*~ 😍 💖

I copied over the initial posts from 2023 from the old journal to the current.

The RSS feed is now complete. A huge shout out goes to Alex Le for their write up!

I passed the feed through a validator and everything is A-OK! I also got rid of Markdown showing up in the output.

...now I need a new project to distract myself.

Hey... maybe emoji shortcodes. 😍 😂

Edit: One of the Python extensions seems to already parse the shortcodes... I must investigate.

Edit 2: It took an hour but I found it! The Markdown extension for Jinja2 includes a reference to pymdownx.emoji. Sweet! 🍭

Edit 3: 2023-10-28 - Since switching to Zola, the feed link has been updated to Zola's feed to prevent 404 errors when crawling

I started writing an RSS feed generator. It's live, and produces valid XML.

The only thing left is to strip the Markdown out of my posts before the XML part. I may need to write another Jinja2 filter for this.

Stay tuned!

And another thing. I'll be writing an RSS feed generator for this thing too. Hooray!

...I really should be looking for a job instead

Oh, and I plan to pink the hell out of this site once I've uploaded the base template. Can't wait!