I’ve got Mackenzie looking at Streamlit as a means of building a mobile-friendly app that I can use to create posts like this one. That app will need to allow me to edit a TITLE and Markdown BODY fields, capture location and time, and post all of that information to my personal blog… preferably from my cell phone. I’ve captured some possible resources and guidance in https://www.one-tab.com/page/71iaDADxT-eLEOx15qeVnQ.
So, node and npm seem to be all the rage these days, and perhaps for good reason. I recently fell in love with Eleventy/11ty over Hugo because it’s Javascript, not Go, and it’s elegantly simple with tons of flexibility. I recently tried to add Pagefind search to a Hugo static web site (see https://static.grinnell.edu/dlad-blog/posts/143-significant-rootstalk-retooling/). If Rootstalk, an Azure Static Web App was framed in node.js, as both Eleventy and Pagefind are, there would be no problem. The Azure scripts used to deploy those frameworks are far more customizable than Hugo, and there’s documentation to prove it.
Been prompted to do this for a couple of weeks so I finally took-the-plunge. https://analytics.summittservices.com/index.php?module=CoreUpdater&action=newVersionAvailable.
Wow, that was way too easy. I wonder if it really worked?
Take note of the question mark at the end of the title, otherwise it could be somewhat misleading. This is not really a problem with Hugo, but one with cloud deployment of Hugo static apps, particularly as an Azure Static Web App.
As you may know from post 143, I have successfully installed and configured Pagefind in Rootstalk, but thus far it only works locally. When I try to deploy Pagefind to the cloud, specifically as an Azure Static Web App, I can’t make it work because there’s no apparent way to invoke the necessary npx pagefind... command AFTER Hugo compiles the site, but BEFORE the site gets deployed. Azure leverages GitHub Actions to build Hugo sites, but that process also involves some custom/proprietary Azure scripts. Therein lies the problem.
I ran into a big road block with implementation of Pagefind in Rootstalk today… everything works fine in development, but I can’t easily deploy to Azure because there’s no way to “inject” Pagefind into an Azure Static Web App build before the “public” content gets deployed. I can generate the Pagefind parts after deployment, but that does me no good.
Tomorrow I need to have a look at my Rootstalk DigitalOcean deployment to see if what I already have might work there (DO uses a build script that I can add an npx... command to). If that fails I need to look back at https://www.blogtrack.io/blog/powerful-blog-setup-with-hugo-and-npm/ to see if there’s a solution there for me.
-/-/-/
location: Toledo, IA
A few months ago I sat in on a CFE.dev webinar and I was really impressed with what I saw. I made a note to come back and look closer at Pagefind, and my new blog – this blog that you’re presumably reading right now – really needed a search feature, so the “Search” box on this page (I hope it’s there) is the outcome.
So, I started looking closely at search options and considered things like Lunr, which I’ve used before, and Solr, which I both love and hate (because of its JAVA roots). Pagefind was, of course, also on that short list and it quickly solidified its position at the top of the list when I found Adding search to an Eleventy site by Mike.
Continue Reading »Last evening I followed Using PageFind with Eleventy for Search to try and implement robust search capability in this blog. I’m working in a new pagefind branch of the code to pull this off.
Earlier in this blog there’s a micropost that lays out the problem at hand. In a nutshell, most of the photos I saved in DigitalOcean Spaces are too big to be effective in this blog. They suck up lots of time and bandwidth every time this blog gets rebuilt, and then they are rendered at a fraction of their original size. This is exceptionall wasteful and unnecessary.
So, my task this morning is to install, configure, and engage the s3cmd tools to help get this done. There’s DigitalOcean-specific guidance provided in Setting Up s3cmd 2.x with DigitalOcean Spaces so that’s where I will begin. Here goes…
Continue Reading »Ok, I get the sense that constantly pulling enormous digital images from DigitalOcean Spaces to rebuild this blog is unnecessarily chewing up lots of bandwidth. Today I’d like to begin fixing that by creating a utility, probably in Python, to grab all those images one-by-one, make a smaller copy of each, and put those copies back into a web-ready subdirectory in Spaces, or something like that.
There’s a wealth of probably pertinent information to be had in https://docs.digitalocean.com/reference/api/spaces-api/. Unfortunately, Spaces isn’t compatible with DO’s own command line utility, doctl, but it is compatible with s3cmd and the link I’ve provided documents how to get started with that. 🙂
Update: See Engaging s3cmd to Download and Resize Images from DO Spaces for my solution.
Last evening I rode my bike to/from soccer so this morning I wanted to “merge” those two track logs before publishing them to https://hikes.SummittDweller.com. So, I found and forked https://github.com/locked-fg/gpxmerger to https://github.com/SummittDweller/gpxmerger and after tweaking my own code IT WORKS!
The command I ran to make my first “merge” was: python3 gpxmerger.py "/Users/mark/Downloads/2023-04-14 16:32 - 3m 11s.gpx" "/Users/mark/Downloads/2023-04-14 20:40 - 3m 27s.gpx". I think I might tweak the script soon to just pull all of the .gpx files from a specified directory.
Update: My fork of the project now accepts a single target_directory argument and uses “glob” to grab all the .gpx files in that directory.