@Summitt Dweller’s Personal Blog - Posts

Tama County Celebrates

Mark McFate — Mon, 08 Jun 2026 06:33:16 -0500

Farewell Facebook Friends

Mark McFate — Sun, 21 Sep 2025 08:33:16 -0500

I find myself at a crossroads. Those of you who know me well are probably aware that I have never been a fan, advocate, or avid user of Facebook, or social media in general.

I do like FB Marketplace though. I’ve had some wonderful experiences buying or selling things there. Sure, there have been some unpleasant Marketplace experiences, too, but the good far outweighs the bad, so I will probably stick with it.

The same goes for FB Messenger. I prefer using email or text messaging for online communication, but for my Marketplace communications, and especially for staying in touch with all my distant friends, Messenger is a must. Not all the time, but often enough that I will probably stick with using Messenger, too.

Research tells me that I can’t leave Facebook without also losing Marketplace and Messenger. Well, crap.

That research also shows me that lots of other people would like to do the same, disengage from social media, but keep the positive and useful things in play. This is not a paid endorsement, but my research did also lead me to an app called SocialFocus. If you are interested, please check it out: https://socialfocus.app/.

I’ll try not to get long-winded here, but I wanted to share one other thing from my research…

This morning as I was browsing in Marketplace, something popped into my Facebook feed and I opened it, perhaps for the last time. I came across a photo (https://www.tamatoledonews.com/news/local-news/2025/09/19/stc-announces-2025-homecoming-court/) posted by TamaToledoNews. I don’t know most of the kids at STC any more, so it wasn’t the group of smiling young faces that caught my attention, although I wish them all the best. It was the setting of this photo that brought a tear to my eye. If I am given permission, I will add a copy of the image in this blog because you never know how long Facebook will last, and you certainly never know who might not be able to open Facebook now, or in the future. I know I won’t.

I can’t verify this, because that would almost certainly require more interaction with FB, but I believe that the photo was taken beneath a willow tree planted on October 8, 2012, the day my son was buried, by members of the Iowa Geocachers Organization board of directors, and friends. One of those folks, Liz, became a good friend and the tears I shed this morning are for Ian, and for Liz as she celebrates her first heavenly birthday.

It’s postings from Liz, and many others like her, that I will miss the most.

When Ian passed I was moved by the outpouring of love and support we received. I still am to this day. But, I was also moved in a very different manner by all the hateful speculation and vitriol that I found online. In spite of the positives, I choose to pull back from social media in 2012, and was glad that I had when the 2016 election cycle rolled around. In years since I’ve gradually drifted back into social media, largely driven by connections with young people and distant friends who had no other simple means of keeping in touch.

But the vitriol is back, so I’m done.

In the absence of social media I’ve no doubt that I will find comfort in actual things, like Ian’s tree(s), and the good people in my life who occasionally visit in-person, or know me well enough to share an update via text message, email, or a phone call (yes, Mary reminds me that you can still do that with your phone) at times. If I sent you a link to this post, via whatever means available, then you’ll know you are one of the people I will miss and I hope you will find a way to keep in touch.

Alexa Notes

Mark McFate — Mon, 02 Jun 2025 18:43:21 -0600

Connecting Ceiling Fan Control to Alexa

How to Setup the “Smart Life” App

Step 1: Connect your phone to the 2.4G WIFI network (must be 2.4G).

Step 2: Open your “Smart life” APP， and add your device.

Step 3: Click “Smart Home Appliance” then click the “fan”.

Step 5: Choose Confirm indicator rapidly blink, then click “Next”.

Step 6: Waiting for connection.

Step 7: Connection succeeded.

How do I connect to Alexa?

The following is an example using Amazon Echo

Complete product networking configuration in the Smart Life App

Complete the device’s networking configuration according to the prompts in the App

Note: In the App, change the name of the device to an easily identifiable name such as Alexa; names are usually in English, such as “bedroom light”

Configure the Amazon Echo device

(If you have already configured Amazon Echo, you can skip this step. The following instructions are based on the iOS client)

Make sure your Amazon Echo device is powered on and connected to a Wi-Fi network.
Open the Alexa app on your phone. After successful login, tap on the menu in the upper left corner of the Home page, select “Settings” and tap “Set Up A New Device” to set up the Amazon Echo.
Choose your Amazon Echo device type and language for connecting. Press and hold the small dot on the device until the light turns yellow. Then tap “Continue” to connect to the hotspot.

After connecting to the Amazon Echo hotspot, return to the page. At this point, the connection is successful. Tap “Continue” to proceed to the next step. Choose a Wi-Fi network to connect to. Amazon Echo will take a few minutes to try to connect to the network.

After the network connection is successful, Tap “Continue." An introduction video will appear. After the video ends, Tap “Continue” to jump to the Alexa Home page. You have now completed the Amazon Echo’s configuration process.
Key step - link Skill
Tap on “Skills” in the Alexa app menu.
Then search for “Smart Life”. Tap “Enable” to enable the Skill.
Enter the Smart Life APP account and password, then tap “Link Now” to link your Smart Life account to enable the Skill. Now you can start your smart home journey.

Common commands

Control the device via voice commands Now you can control your smart device with Echo. You can control your device (such as your bedroom light) with the following commands:

“ALEXA,TURN on the bedroom light!”

My Grandparent's 1926 California Trip Project

Mark McFate — Sun, 02 Feb 2025 18:43:21 -0600

In October 1926 my grandparents, Clarence and Miriam Abia McFate, packed their family into what I imagine was a pickup truck with a homemade camper in the bed and embarked on a trip that grandma, Miriam, described as…

With the auto route traveling west, in a house built on a Ford with all modern convenience of camp life. Our house is equipped with a gasoline stove for cooking, a small wood heater for heating, 1 small medicine cabinet, with all necessities of a young hospital. Folding table and chairs, 1 day bed, used in day time as a seat and a place for our bed covers, when not in use. One cupboard and all cooking utensils including a pressure cooker. We fasten tent and camp cots on out side. All in all we have a very comfortable way to travel. Not to fast but just fast enough for the most enjoyable time of our lives.

Following you will find each day drive as we journey on.

By grandma’s account they traveled 2,809 miles between October 18, 1926, and November 28 of that year, a span of 42 days on-the-road.

Rootstalk Plan

A few years ago I approached the publisher and editor of Rootstalk, a print and digital publication of the Grinnell College Center for Prairie Studies, to inquire about featuring grandma’s journal in an upcoming edition of the magazine. They were very supportive, but we quickly realized that all 60+ pages of text could not possibly fit in a single issue, so a plan was made to break the journal into three annual installments with the last to publish sometime in 2026 on the 100th anniversary of the trip.

Because Rootstalk has an undetermined future, we recently decided to create a substantially condensed edition of the journal for the print issue of Rootstalk targeted for release following the Spring 2025 term. Along with the condensed print edition it is our intent to also produce an edited and augmented digital edition of the entire journal in Rootstalk’s Spring 2025 issue. There is no class of assistant editors meeting this semester so the effort will involve just the editorial staff and me, along with any assistance, and/or content, I can solicit from interested family members.

The Task at Hand

In order to get the journal published I plan to re-read the entire journal, noting those portions that I believe are worthy of inclusion in the condensed version (about 5%-10% of the journal). I also hope to write an intro piece and end reflection to accompany the journal, along with gathering some photos to help tell the story.

In the digital edition I hope to also include a timeline and a map, both helping to tell the story in a different fashion. To that end I’ve obtained a royalty-free US highway roadmap from November 1926, and have created a GitHub private repository of resources at Grandparents-Miriam-and-Clarence-McFate-California-Trip.

Starting From a PDF

Grandma’s manuscript was transcribed into a typewritten document many years ago by members of my extended family. I have since obtained a scanned text document of the typewritten transcript, and converted it into a 64+ page PDF from which my work will begin.

Step-by-Step

This section, to be expanded over time, is a step-by-step list of tasks needed to transform the PDF into something suitable for publication.

Identify and sequentially number the paragraphs.
In each numbered paragraph collect the following using automated text analysis:

a) References to the travelers
b) References to people encountered on the trip
c) References to places
d) Corresponding date or dates

Rebranding CV to HAT with Pagefind

Mark McFate — Sat, 25 Jan 2025 08:43:21 -0600

Today I’m rebranding the Tama-Toledo Community Visioning (CV) site to Hometown Action Team (HAT) and adding Pagefind.

When doing so I get this build error…

Warning: Running in pre-1.0 compatibility mode. Pagefind 1.0 changes the default output directory from /_pagefind/ to /pagefind/ but references to the /_pagefind/ URL were found on your site, and the output directory is unconfigured. To preserve your setup, the search files have been written twice, to both /_pagefind/ and /pagefind/

To remove this warning, either update your script and style references to the new /pagefind/ URL or run Pagefind with --output-subdir _pagefind to ensure pre-1.0 behaviour

So, I am going to try changing all _pagefind references to just ‘pagefind’. Wish me luck

A Newer Pagefind Enabled Blog!

Mark McFate — Sun, 22 Dec 2024 10:43:32 -0600

It’s deja vu all over again. My timeline module doesn’t work with the current rendition of https://blog.SummittDweller.com and I can’t figure out what’s broken. So, I’ve resurrected my old personal blog project and updated with the meager content it was missing. That project has a working timeline but no Pagefind search, yet.

So, how might I ONCE AGAIN approach combining Hugo with Pagefind in the cloud? Well, A Powerful Blog Setup with Hugo and NPM* by Tom Hombergs looked like a promising place to start. The process that Tom advocates leverages a neat little package called hugo-bin.

*The links provided above and below are to a Wayback Machine capture of the original post.

Once Again…That Was Too Easy!

Wrapping this Hugo blog site in an NPM package was so easy that I forgot to document it… and maybe I really didn’t need too. Time to catch up, so here’s a brief sysnopsis of what I did…

Following Tom’s Excellent Advice

I started by studying A Powerful Blog Setup with Hugo and NPM and quickly found that I could easily follow it almost verbatim. Since I already had npm and Hugo installed I skipped ahead to the section titled “Setting Up a Hugo Project” and then to the npx and git commands there. My experience, mostly in commands, looked like this on my Mac Mini workstation.

  cd ~/GitHub/
  # Named the new project npm-blog-SummittDweller so it would not confilct with any of my existing `blog...` directories
  mkdir npm-blog-SummittDweller
  cd npm-blog-SummittDweller
  npx hugo new site . --force
  # Copied the contents of my old project into the new one and then removed whatever I no longer needed
  cp -fr ~/GitHub/blogs-SummittDweller/. .  
  # Installed Pagefind...
  npm install pagefind
  git init
  # I created a new empty repo in GitHub called npm-blog-SummittDweller, then...
  git remote add origin https://github.com/SummittDweller/npm-blog-sd 
  git add . 
  git commit -m "Initial commit of new npm-wrapped Hugo project"
  git push

Having secured a new repo I moved to running Hugo locally, then polishing my package.json scripts as Tom did. I now have a package.json that reads like this:

{
  "name": "npm-blog-sd",
  "version": "1.0.0",
  "description": "My personal (SummittDweller) blog built with Hugo inside an NPM package.  December 2024.",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "build": "npm run hugo:build && npx pagefind --site public",
    "do:build": "hugo -d public && npx pagefind --site public",
    "azure:build": "hugo -d public --baseURL=\"https://azure-static-web-apps-ashy-rock-0f18efc0f\" && npx pagefind --site public",
    "clean": "npm run hugo:clean",
    "serve": "npm run hugo:build && npx pagefind --site public --output-subdir ../static/_pagefind && npm run hugo:serve",
    "hugo:build": "hugo -d public",
    "hugo:serve": "hugo server",
    "hugo:clean": "rm -rf build resources public"
  },
  "author": "Mark A. McFate",
  "license": "ISC",
  "dependencies": {
    "hugo-bin": "^0.137.0",
    "pagefind": "^1.2.0"
  }
}

It Works!

Now I just use npm run serve to build the Hugo site, index it with Pagefind, and serve it locally at http://localhost:1313.

A Staging Site in Azure

I can simply push changes to the main branch of the npm-blog-sd repo to trigger an Azure (aka GitHub Actions) rebuild, indexing and deployment of the site to this address.

Errors?

So, it took lots of trial-and-error to get the Azure configuration straight. First there were issues with deployment tokens, so I rewound the project and got that fixed. Then, since this blog uses SASS I needed to run the extended version of Hugo, or more specifically, hugo-bin-extended. I fixed that, apparently, with the addition of…

  "dependencies": {
    "hugo-bin-extended": "latest",
    "pagefind": "^1.2.0"
  }

…in package.json. That hugo-bin-extended key replaced hugo-bin and I set the version to latest.

Last of the Errors?

The changes mentioned above left me with two deprecation errors…

ERROR deprecated: site config key paginate was deprecated in Hugo v0.128.0 and will be removed in Hugo 0.141.0. Use pagination.pagerSize instead.
WARN  Raw HTML omitted while rendering "/github/workspace/content/about.md"; see https://gohugo.io/getting-started/configuration-markup/#rendererunsafe
You can suppress this warning by adding the following to your site configuration:
ignoreLogs = ['warning-goldmark-raw-html']
ERROR deprecated: .Site.Social was deprecated in Hugo v0.124.0 and will be removed in Hugo 0.141.0. Implement taxonomy 'social' or use .Site.Params.Social instead.

This post was very helpful for working with my submodule theme!

Success!

Well, somewhat. My site at https://ashy-rock-0f18efc0f.4.azurestaticapps.net/ is visible now, but the theme isn’t right. I suspect that is because my hugo.yml file still sets the baseURL to “https://blog.summittdweller.com” and we are not quite there yet. Setting the baseURL to “https://ashy-rock-0f18efc0f.4.azurestaticapps.net/" and let’s see what happens… Bingo! Now, I just need to add a search bar to expose the Pagefind results. Done!

What follows is obsolete, it's from `npm-rootstalk`, and does NOT apply to this blog!

A New Production Branch

Pushing to production is just as simple, I just have to push changes to the new production branch of the code and my app spec at DigitalOcean (see below) takes care of building, indexing, and deploying to https://rootstalk.grinnell.edu.

That DO app spec reads like this:

alerts:
- rule: DEPLOYMENT_FAILED
- rule: DOMAIN_FAILED
domains:
- domain: rootstalk.grinnell.edu
  type: PRIMARY
- domain: prairiejournal.grinnell.edu
  type: ALIAS
envs:
- key: TZ
  scope: RUN_AND_BUILD_TIME
  value: America/Chicago
- key: HUGO_MATOMO_ID
  scope: RUN_AND_BUILD_TIME
  value: "15"
ingress:
  rules:
  - component:
      name: npm-rootstalk
    match:
      path:
        prefix: /
name: npm-rootstalk
region: nyc
static_sites:
- build_command: npm run build
  environment_slug: node-js
  github:
    branch: production
    deploy_on_push: true
    repo: Digital-Grinnell/npm-rootstalk
  name: npm-rootstalk
  source_dir: /

It’s heavenly! And that’s all for now.

A New Pagefind Enabled Blog!

Mark McFate — Wed, 18 Dec 2024 08:31:49 -0600

So, node and npm are maybe not “all the rage” these days, but they do the job nicely for me.

*The links provided above and below are to a Wayback Machine capture of the original post.

That Was Too Easy!

Wrapping this Hugo blog site in an NPM package was so easy that I forgot to document it… and maybe I really didn’t need too. Time to catch up, so here’s a brief sysnopsis of what I did…

Following Tom’s Excellent Advice

cd ~/GitHub/
# Named the new project npm-blog-sd so it would not confilct with any of my existing `blog...` directories
mkdir npm-blog-sd
cd npm-blog-sd
npx hugo new site . --force
# Copied the contents of my old project into the new one and then removed whatever I no longer needed
cp -fr ~/GitHub/blog-sd/. .  
# Installed Pagefind...
npm install pagefind
git init
# I created a new empty repo in GitHub called npm-blog-sd, then...
git remote add origin https://github.com/SummittDweller/npm-blog-sd 
git add . 
git commit -m "Initial commit of new npm-wrapped Hugo project"
git push

Having secured a new repo I moved to running Hugo locally, then polishing my package.json scripts as Tom did. I now have a package.json that reads like this:

{
  "name": "npm-blog-sd",
  "version": "1.0.0",
  "description": "My personal (SummittDweller) blog built with Hugo inside an NPM package.  December 2024.",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "build": "npm run hugo:build && npx pagefind --site public",
    "do:build": "hugo -d public && npx pagefind --site public",
    "azure:build": "hugo -d public --baseURL=\"https://azure-static-web-apps-ashy-rock-0f18efc0f\" && npx pagefind --site public",
    "clean": "npm run hugo:clean",
    "serve": "npm run hugo:build && npx pagefind --site public --output-subdir ../static/_pagefind && npm run hugo:serve",
    "hugo:build": "hugo -d public",
    "hugo:serve": "hugo server",
    "hugo:clean": "rm -rf build resources public"
  },
  "author": "Mark A. McFate",
  "license": "ISC",
  "dependencies": {
    "hugo-bin": "^0.137.0",
    "pagefind": "^1.2.0"
  }
}

It Works!

Now I just use npm run serve to build the Hugo site, index it with Pagefind, and serve it locally at http://localhost:1313.

A Staging Site in Azure

I can simply push changes to the main branch of the npm-blog-sd repo to trigger an Azure (aka GitHub Actions) rebuild, indexing and deployment of the site to this address.

Errors?

  "dependencies": {
    "hugo-bin-extended": "latest",
    "pagefind": "^1.2.0"
  }

…in package.json. That hugo-bin-extended key replaced hugo-bin and I set the version to latest.

Last of the Errors?

The changes mentioned above left me with two deprecation errors…

ERROR deprecated: site config key paginate was deprecated in Hugo v0.128.0 and will be removed in Hugo 0.141.0. Use pagination.pagerSize instead.
WARN  Raw HTML omitted while rendering "/github/workspace/content/about.md"; see https://gohugo.io/getting-started/configuration-markup/#rendererunsafe
You can suppress this warning by adding the following to your site configuration:
ignoreLogs = ['warning-goldmark-raw-html']
ERROR deprecated: .Site.Social was deprecated in Hugo v0.124.0 and will be removed in Hugo 0.141.0. Implement taxonomy 'social' or use .Site.Params.Social instead.

This post was very helpful for working with my submodule theme!

Success!

What follows is obsolete, it's from `npm-rootstalk`, and does NOT apply to this blog!

A New Production Branch

That DO app spec reads like this:

alerts:
- rule: DEPLOYMENT_FAILED
- rule: DOMAIN_FAILED
domains:
- domain: rootstalk.grinnell.edu
  type: PRIMARY
- domain: prairiejournal.grinnell.edu
  type: ALIAS
envs:
- key: TZ
  scope: RUN_AND_BUILD_TIME
  value: America/Chicago
- key: HUGO_MATOMO_ID
  scope: RUN_AND_BUILD_TIME
  value: "15"
ingress:
  rules:
  - component:
      name: npm-rootstalk
    match:
      path:
        prefix: /
name: npm-rootstalk
region: nyc
static_sites:
- build_command: npm run build
  environment_slug: node-js
  github:
    branch: production
    deploy_on_push: true
    repo: Digital-Grinnell/npm-rootstalk
  name: npm-rootstalk
  source_dir: /

It’s heavenly! And that’s all for now.

Microposts from iOS

Mark McFate — Sun, 10 Nov 2024 10:22:33 -0600

Wow, this post is long overdue.

For as long as I can remember I’ve been looking for, or building and using, a workflow that would let me create quick and simple microposts for this blog using my iPhone. I want that workflow to automatically record my location (in the form of a city/town reference) and date/time. With the help of my daughter, Mackenzie, I’ve had workflows that used Working Copy and iOS Shortcuts to get this done, but I never really understood the entire process and over time it broke down and I was unable to repair it. It’s time to revisit those pieces and I’m going to follow, and document here, the steps and components presented in Post to Eleventy from iOS with Drafts, Shortcuts and Working Copy. The only change I anticipate will be pointing the workflow at this Hugo blog rather than an Eleventy one, and those differences should be minimal and manageable.

NOT Like a Rolling Stone

Mark McFate — Fri, 11 Oct 2024 20:09:55 +0000

Where has the last year gone? While life (metaphorically the stream in the hero image) rolls on, this blog (any of the moss covered rocks in the image) has not.

This blog was born of good intentions, but frankly it’s too hard for an old fart like me to remember how to maintain it and make contributions. Having not posted here in many months, I had to consult my “documentation”, and ultimately my retired password manager, to get back in and post this. That’s unacceptable, and it won’t happen again.

So, I’m going to replace this Ghost-driven “semi-static” blog with something more familiar and less costly/complex to operate. Probably a Hugo static site that is truly “static”, but not stagnant! There will be no more blog-moss grown here!

Famous last words?

See you on the flip-side. Soon.

Spinning Up StaticCMS

Mark McFate — Sat, 13 Jan 2024 15:40:23 +0000

Today is Saturday, January 13, 2024, and I won’t be able to watch the KC Chief’s wildcard playoff game vs. the Miami Dolphins tonight because it is streaming ONLY on Peacock, and I refuse to pay them for the “privilege” to watch it live. So, I’m going to do something productive instead. Let’s see if I can spin up an instance of StaticCMS to provide an OPEN CMS for the content editor(s) behind the Wieting Theatre website.

The Plan

So, the plan here involves establishing a “local-only” CMS for the Wieting Theatre website and running it on the new Ubuntu server in the Wieting’s projection booth. Editors should will be given login credentials to that server where they can run a local copy of the website (it’s a Hugo static site) AND a local copy of the CMS editor, make changes, preview them, and commit the changes to the project’s GitHub repo. The website, hosted with AWS Amplify is then automatically updated based on the updated content.

Along the Way

It’s worth noting that while looking at StaticCMS I also stumbled upon tabcms - A CMS that runs in your browser tab which might be of interest if “The Plan” doesn’t work.

First Steps - Start with a Template

I choose the guidance at Start with a Template to get started. My aim is to clone that repo and build it locally “as-is”, then see if I can drop my existing wieting-ss repo into the site directory and continue to make it work locally.

If that works, I’ll repeat the same on the Wieting’s Ubuntu server and keep pushing forward. Wish me luck?

Getting Started

Following the Local Development guidance found me cloning this template then…

╭─mark@Marks-Mac-Mini ~/GitHub/static-cms-hugo-netlify-template ‹main› 
╰─$ npm install 
npm WARN deprecated querystring@0.2.0: The querystring API is considered Legacy. new code should use the URLSearchParams API instead.

added 1567 packages, and audited 1568 packages in 2m

426 packages are looking for funding
  run `npm fund` for details

2 moderate severity vulnerabilities

To address all issues, run:
  npm audit fix

Run `npm audit` for details.
╭─mark@Marks-Mac-Mini ~/GitHub/static-cms-hugo-netlify-template ‹main*› 
╰─$ npm start

> static-cms-hugo-netlify-template@1.0.0 start
> run-p start:**


> static-cms-hugo-netlify-template@1.0.0 start:webpack
> webpack-dev-server --config webpack.dev.js --hot --stats-error-details


> static-cms-hugo-netlify-template@1.0.0 start:hugo
> hugo -d ../dist -s site -vw

WARN  --verbose was deprecated in Hugo v0.114.0 and will be removed in a future release. use --logLevel info
Start building sites … 
hugo v0.120.1-16fb2cae88eb6add7d12e9fbfcf01d8670e60a35 darwin/amd64 BuildDate=2023-10-30T16:44:31Z VendorInfo=gohugoio

INFO  copy static: syncing static files to /
INFO  build: running step process duration 962.376µs
INFO  build: running step assemble duration 4.712758ms
INFO  build: running step render duration 16.982673ms
INFO  build: running step postProcess duration 8.3µs

                   | EN  
-------------------+-----
  Pages            | 10  
  Paginator pages  |  0  
  Non-page files   |  0  
  Static files     | 43  
  Processed images |  0  
  Aliases          |  1  
  Sitemaps         |  1  
  Cleaned          |  0  

Built in 68 ms
Watching for changes in /Users/mark/GitHub/static-cms-hugo-netlify-template/site/{content,data,layouts,static}
Watching for config changes in /Users/mark/GitHub/static-cms-hugo-netlify-template/site/config.toml
Press Ctrl+C to stop
<i> [webpack-dev-server] Project is running at:
<i> [webpack-dev-server] Loopback: http://localhost:3000/
<i> [webpack-dev-server] On Your Network (IPv4): http://192.168.0.183:3000/
<i> [webpack-dev-server] On Your Network (IPv6): http://[fe80::1]:3000/
<i> [webpack-dev-server] Content not from webpack is served from '/Users/mark/GitHub/static-cms-hugo-netlify-template/dist' directory
<i> [webpack-dev-server] 404s will fallback to '/index.html'
<i> [webpack-dev-middleware] wait until bundle finished: /
assets by path *.js 18.3 MiB
  asset cms.js 18 MiB [emitted] (name: cms)
  asset main.js 300 KiB [emitted] (name: main)
asset main.css 113 KiB [emitted] (name: main)
asset admin/index.html 521 bytes [emitted]
asset fonts/.keep 0 bytes [emitted] [from: src/fonts/.keep] [copied]
Entrypoint main 413 KiB = main.css 113 KiB main.js 300 KiB
Entrypoint cms 18 MiB = cms.js
runtime modules 72.3 KiB 38 modules
modules by path ./node_modules/ 16.9 MiB 82 modules
modules by path ./src/ 133 KiB (javascript) 113 KiB (css/mini-extract)
  modules by path ./src/js/ 15.2 KiB 9 modules
  modules by path ./src/css/*.scss 118 KiB (javascript) 113 KiB (css/mini-extract)
    ./src/css/main.scss 2.78 KiB [built] [code generated]
    ./node_modules/to-string-loader/src/to-string.js!./node_modules/css-loader/dist/cjs.js!./node_modules/postcss-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./src/css/main.scss 429 bytes [built] [code generated]
    ./node_modules/mini-css-extract-plugin/dist/loader.js??ruleSet[1].rules[2].use[1]!./node_modules/css-loader/dist/cjs.js!./node_modules/postcss-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./src/css/main.scss 332 bytes [built] [code generated]
    + 2 modules
  ./src/index.js 124 bytes [built] [code generated]
asset modules 5.46 KiB
  data:image/png;base64,iVBORw0KGgoAAAAN.. 1.28 KiB [built] [code generated] [build time executed]
  data:image/png;base64,iVBORw0KGgoAAAAN.. 1.33 KiB [built] [code generated] [build time executed]
  data:image/jpeg;base64,/9j/4QAYRXhpZgAA.. 1.55 KiB [built] [code generated] [build time executed]
  data:image/png;base64,iVBORw0KGgoAAAAN.. 1.3 KiB [built] [code generated] [build time executed]
webpack 5.89.0 compiled successfully in 6191 ms
INFO  Received System Events: [CREATE        "/Users/mark/GitHub/static-cms-hugo-netlify-template/site/data/webpack.json" WRITE         "/Users/mark/GitHub/static-cms-hugo-netlify-template/site/data/webpack.json"]

Change detected, rebuilding site.
2024-01-13 10:55:38.259 -0600
Data changed WRITE         "/Users/mark/GitHub/static-cms-hugo-netlify-template/site/data/webpack.json"
Data changed WRITE         "/Users/mark/GitHub/static-cms-hugo-netlify-template/site/data/webpack.json"
INFO  build: running step process duration 114.033µs
INFO  build: running step assemble duration 277ns
INFO  build: running step render duration 6.244639ms
INFO  build: running step postProcess duration 1.831µs
Total in 6 ms

The demo site is indeed working at http://localhost:3000/ and a vist to http://localhost:3000/admin does indeed open a StaticCMS login that’s prompting me with the following image.

Let’s Go Local!

Next, I’m going to try and switch what we have above to “go local” using this guidance provided in the StaticCMS documenation. Fingers crossed for good luck…

Eureka! It Works!

So, I made the local_backend config changes as prescribed in site/static/admin/config.yml and that file now looks like this:

local_backend: 
  # when using a custom proxy server port
  url: http://localhost:8082/api/v1
  # when accessing the local site from a host other than 'localhost' or '127.0.0.1'
  allowed_hosts: ['192.168.0.1']

I also added a new .env file in the project root directory with a single line reading PORT=8082, matching the port number specified in the url: value from config.yml.

Now, with npx @staticcms/proxy-server running in a local terminal I’m able to run npm start (in my VSCode terminal) to launch the site at localhost:3000. Having done that I’m able to visit http://localhost:3000/admin where I get a new StaticCMS splash screen with a simple Login button, not a Netlify button. Yay!

Even Better News?

StaticCMS was built from NetlifyCMS so the site/static/admin/config.yml. I think I’ll be able to use the collections: portion of my old admin/config.yml file from wieting-one-click-hugo-cms to get a headstart on setting that up!

Next step… let’s see if I can drop the site directory from wieting-ss into this local project and still have a functioning local site. Again, fingers crossed for luck.

Fresh Restart

In order to start fresh I went back to the StaticJsCMS/static-cms-hugo-netlify-template repo and created a new fork (not a clone) in my Summitt-Services team space at https://github.com/Summitt-Services/static-cms-hugo-local-template. In the new fork I changed the -netlify- portion of the name to -local- as this new project is intended to have no Netlify association, only a “local” CMS will be supported.

Next, I cloned the new fork to my workstation and got it working locally again using the same steps I had taken above.

Copying `wieting-ss` to `static-cms-hugo-local-template`

For safe-keeping I created a new branch named wieting in ~/GitHub/static-cms-hugo-local-template where I did this:

╭─mark@Marks-Mac-Mini ~/GitHub/static-cms-hugo-local-template ‹wieting*› 
╰─$ rsync -aruvi ../wieting-ss/. site/.
...
>f++++++++++ themes/vanilla-bootstrap-hugo-theme/static/js/checkTweetDate.js
>f++++++++++ themes/vanilla-bootstrap-hugo-theme/static/js/feather.min.js
>f++++++++++ themes/vanilla-bootstrap-hugo-theme/static/js/jquery-3.3.1.slim.min.js

sent 282,877,469 bytes  received 470,944 bytes  9,605,030.95 bytes/sec
total size is 470,527,158  speedup is 1.66

Will it work? Let’s see… NOPE. It does produce a site but the old “Kaldi” content is still all I see. I even changed the backend.branch: value from main to wieting, but that did nothing. So, I’ve captured the output here so that I can have a look at what’s happening.

╭─mark@Marks-Mac-Mini ~/GitHub/static-cms-hugo-local-template ‹wieting*› 
╰─$ npm start                               

> static-cms-hugo-netlify-template@1.0.0 start
> run-p start:**


> static-cms-hugo-netlify-template@1.0.0 start:webpack
> webpack-dev-server --config webpack.dev.js --hot --stats-error-details


> static-cms-hugo-netlify-template@1.0.0 start:hugo
> hugo -d ../dist -s site -vw

WARN  --verbose was deprecated in Hugo v0.114.0 and will be removed in a future release. use --logLevel info
Start building sites … 
hugo v0.120.1-16fb2cae88eb6add7d12e9fbfcf01d8670e60a35 darwin/amd64 BuildDate=2023-10-30T16:44:31Z VendorInfo=gohugoio

INFO  copy static: syncing static files to /
INFO  build: running step process duration 4.236952ms
INFO  build: running step assemble duration 13.684119ms
WARN  found no layout file for "json" for kind "section": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
INFO  build: running step render duration 58.753135ms
INFO  build: running step postProcess duration 8.744µs

                   | EN   
-------------------+------
  Pages            |  66  
  Paginator pages  |   7  
  Non-page files   |   0  
  Static files     | 541  
  Processed images |   0  
  Aliases          |   7  
  Sitemaps         |   1  
  Cleaned          |   0  

Built in 579 ms
Watching for changes in /Users/mark/GitHub/static-cms-hugo-local-template/site/{archetypes,content,data,layouts,package.json,static,themes}
Watching for config changes in /Users/mark/GitHub/static-cms-hugo-local-template/site/config.toml, /Users/mark/GitHub/static-cms-hugo-local-template/site/config/_default
Press Ctrl+C to stop
<i> [webpack-dev-server] Project is running at:
<i> [webpack-dev-server] Loopback: http://localhost:3000/
<i> [webpack-dev-server] On Your Network (IPv4): http://192.168.0.183:3000/
<i> [webpack-dev-server] On Your Network (IPv6): http://[fe80::1]:3000/
<i> [webpack-dev-server] Content not from webpack is served from '/Users/mark/GitHub/static-cms-hugo-local-template/dist' directory
<i> [webpack-dev-server] 404s will fallback to '/index.html'
<i> [webpack-dev-middleware] wait until bundle finished: /
assets by path *.js 18.3 MiB
  asset cms.js 18 MiB [emitted] (name: cms)
  asset main.js 300 KiB [emitted] (name: main)
asset main.css 113 KiB [emitted] (name: main)
asset admin/index.html 521 bytes [emitted]
asset fonts/.keep 0 bytes [emitted] [from: src/fonts/.keep] [copied]
Entrypoint main 413 KiB = main.css 113 KiB main.js 300 KiB
Entrypoint cms 18 MiB = cms.js
runtime modules 72.3 KiB 38 modules
modules by path ./node_modules/ 16.9 MiB 82 modules
modules by path ./src/ 133 KiB (javascript) 113 KiB (css/mini-extract)
  modules by path ./src/js/ 15.2 KiB 9 modules
  modules by path ./src/css/*.scss 118 KiB (javascript) 113 KiB (css/mini-extract)
    ./src/css/main.scss 2.78 KiB [built] [code generated]
    ./node_modules/to-string-loader/src/to-string.js!./node_modules/css-loader/dist/cjs.js!./node_modules/postcss-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./src/css/main.scss 429 bytes [built] [code generated]
    ./node_modules/mini-css-extract-plugin/dist/loader.js??ruleSet[1].rules[2].use[1]!./node_modules/css-loader/dist/cjs.js!./node_modules/postcss-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./src/css/main.scss 332 bytes [built] [code generated]
    + 2 modules
  ./src/index.js 124 bytes [built] [code generated]
asset modules 5.46 KiB
  data:image/png;base64,iVBORw0KGgoAAAAN.. 1.28 KiB [built] [code generated] [build time executed]
  data:image/png;base64,iVBORw0KGgoAAAAN.. 1.33 KiB [built] [code generated] [build time executed]
  data:image/jpeg;base64,/9j/4QAYRXhpZgAA.. 1.55 KiB [built] [code generated] [build time executed]
  data:image/png;base64,iVBORw0KGgoAAAAN.. 1.3 KiB [built] [code generated] [build time executed]
webpack 5.89.0 compiled successfully in 5563 ms
INFO  Received System Events: [CHMOD         "/Users/mark/GitHub/static-cms-hugo-local-template/site/data/webpack.json" WRITE         "/Users/mark/GitHub/static-cms-hugo-local-template/site/data/webpack.json"]

Change detected, rebuilding site.
2024-01-13 13:15:08.329 -0600
Data changed WRITE         "/Users/mark/GitHub/static-cms-hugo-local-template/site/data/webpack.json"
INFO  build: running step process duration 186.604µs
INFO  build: running step assemble duration 244ns
WARN  found no layout file for "json" for kind "section": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
INFO  build: running step render duration 31.514265ms
INFO  build: running step postProcess duration 7.661µs
Total in 31 ms
^C<i> [webpack-dev-server] Gracefully shutting down. To force exit, press ^C again. Please wait...

Corrections Needed

So, the first thing I see here is that the new site directory contains the template’s content/_index.md file which naturally becomes the site’s home page. It contains only “Kaldi” content. So I tried removing that _index.md file and that changed the home page “title”, but very little else.

I think returing to the main branch of this project and starting over again but using only the content of wieting-ss in the new site/ directory might be wise. I did it like this:

╭─mark@Marks-Mac-Mini ~/GitHub
╰─$ rm -fr static-cms-hugo-local-template
╭─mark@Marks-Mac-Mini ~/GitHub
╰─$ git clone https://github.com/Summitt-Services/static-cms-hugo-local-template.git
Cloning into 'static-cms-hugo-local-template'...
remote: Enumerating objects: 574, done.
remote: Counting objects: 100% (155/155), done.
remote: Compressing objects: 100% (50/50), done.
remote: Total 574 (delta 122), reused 125 (delta 102), pack-reused 419
Receiving objects: 100% (574/574), 22.14 MiB | 23.94 MiB/s, done.
Resolving deltas: 100% (248/248), done.
╭─mark@Marks-Mac-Mini ~/GitHub
╰─$ cd static-cms-hugo-local-template
╭─mark@Marks-Mac-Mini ~/GitHub/static-cms-hugo-local-template ‹main›
╰─$ cp -fr site/static/admin ~
╭─mark@Marks-Mac-Mini ~/GitHub/static-cms-hugo-local-template ‹main›
╰─$ rm -fr site
╭─mark@Marks-Mac-Mini ~/GitHub/static-cms-hugo-local-template ‹main*›
╰─$ mkdir site
╭─mark@Marks-Mac-Mini ~/GitHub/static-cms-hugo-local-template ‹main*›
╰─$ cp -fr ../wieting-ss/. site/.
╭─mark@Marks-Mac-Mini ~/GitHub/static-cms-hugo-local-template ‹main*›
╰─$ cp -f ~/admin/config.yml site/static/admin/.

Next I launched the proxy server like so:

╭─mark@Marks-Mac-Mini ~/GitHub/static-cms-hugo-local-template ‹main*›
╰─$ npx @staticcms/proxy-server
info: Static CMS File System Proxy Server configured with /Users/mark/GitHub/static-cms-hugo-local-template
info: Static CMS Proxy Server listening on port 8082

Then in my VSCode terminal this:

╭─mark@Marks-Mac-Mini ~/GitHub/static-cms-hugo-local-template ‹main*› 
╰─$ npm start

> static-cms-hugo-netlify-template@1.0.0 start
> run-p start:**


> static-cms-hugo-netlify-template@1.0.0 start:webpack
> webpack-dev-server --config webpack.dev.js --hot --stats-error-details


> static-cms-hugo-netlify-template@1.0.0 start:hugo
> hugo -d ../dist -s site -vw

WARN  --verbose was deprecated in Hugo v0.114.0 and will be removed in a future release. use --logLevel info
Start building sites … 
hugo v0.120.1-16fb2cae88eb6add7d12e9fbfcf01d8670e60a35 darwin/amd64 BuildDate=2023-10-30T16:44:31Z VendorInfo=gohugoio

INFO  copy static: syncing static files to /
INFO  build: running step process duration 3.193622ms
INFO  build: running step assemble duration 25.748629ms
WARN  found no layout file for "json" for kind "section": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
INFO  build: running step render duration 70.992512ms
INFO  build: running step postProcess duration 9.94µs
<i> [webpack-dev-server] Project is running at:
<i> [webpack-dev-server] Loopback: http://localhost:3000/
<i> [webpack-dev-server] On Your Network (IPv4): http://192.168.0.183:3000/
<i> [webpack-dev-server] On Your Network (IPv6): http://[fe80::1]:3000/
<i> [webpack-dev-server] Content not from webpack is served from '/Users/mark/GitHub/static-cms-hugo-local-template/dist' directory
<i> [webpack-dev-server] 404s will fallback to '/index.html'

                   | EN   
-------------------+------
  Pages            |  57  
  Paginator pages  |   0  
  Non-page files   |   0  
  Static files     | 499  
  Processed images |   0  
  Aliases          |   1  
  Sitemaps         |   1  
  Cleaned          |   0  

Built in 1034 ms
Watching for changes in /Users/mark/GitHub/static-cms-hugo-local-template/site/{archetypes,content,layouts,package.json,static,themes}
Watching for config changes in /Users/mark/GitHub/static-cms-hugo-local-template/site/config/_default
Press Ctrl+C to stop
<i> [webpack-dev-middleware] wait until bundle finished: /
assets by path *.js 18.3 MiB
  asset cms.js 18 MiB [emitted] (name: cms)
  asset main.js 300 KiB [emitted] (name: main)
asset main.css 113 KiB [emitted] (name: main)
asset admin/index.html 521 bytes [emitted]
asset fonts/.keep 0 bytes [emitted] [from: src/fonts/.keep] [copied]
Entrypoint main 413 KiB = main.css 113 KiB main.js 300 KiB
Entrypoint cms 18 MiB = cms.js
runtime modules 72.3 KiB 38 modules
modules by path ./node_modules/ 16.9 MiB 82 modules
modules by path ./src/ 133 KiB (javascript) 113 KiB (css/mini-extract)
  modules by path ./src/js/ 15.2 KiB 9 modules
  modules by path ./src/css/*.scss 118 KiB (javascript) 113 KiB (css/mini-extract)
    ./src/css/main.scss 2.78 KiB [built] [code generated]
    ./node_modules/to-string-loader/src/to-string.js!./node_modules/css-loader/dist/cjs.js!./node_modules/postcss-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./src/css/main.scss 429 bytes [built] [code generated]
    ./node_modules/mini-css-extract-plugin/dist/loader.js??ruleSet[1].rules[2].use[1]!./node_modules/css-loader/dist/cjs.js!./node_modules/postcss-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./src/css/main.scss 332 bytes [built] [code generated]
    + 2 modules
  ./src/index.js 124 bytes [built] [code generated]
asset modules 5.46 KiB
  data:image/png;base64,iVBORw0KGgoAAAAN.. 1.28 KiB [built] [code generated] [build time executed]
  data:image/png;base64,iVBORw0KGgoAAAAN.. 1.33 KiB [built] [code generated] [build time executed]
  data:image/jpeg;base64,/9j/4QAYRXhpZgAA.. 1.55 KiB [built] [code generated] [build time executed]
  data:image/png;base64,iVBORw0KGgoAAAAN.. 1.3 KiB [built] [code generated] [build time executed]
webpack 5.89.0 compiled successfully in 6771 ms

Again, it works. Only this time the Wieting website appears at http://localhost:3000 and http://localhost:3000/admin works too, but with the wrong configuration. Still, that’s a WIN!

Time To Save My Progress

I really don’t want to dump 4000+ new files, many of them specific to the Wieting website, into my pristine (and working) https://github.com/Summitt-Services/static-cms-hugo-local-template GitHub repository. So, I’m going to clean up my local project by removing that which is no longer needed, and then I’m going to remove the .git directory and create/populate a new wieting-staticCMS private repository. After creating that empty repository the process looked like this:

╭─mark@Marks-Mac-Mini ~/GitHub/static-cms-hugo-local-template ‹main*› 
╰─$ rm -fr site/.git 
╭─mark@Marks-Mac-Mini ~/GitHub/static-cms-hugo-local-template ‹main*› 
╰─$ rm -fr .git
╭─mark@Marks-Mac-Mini ~/GitHub/static-cms-hugo-local-template 
╰─$ git init
Initialized empty Git repository in /Users/mark/GitHub/static-cms-hugo-local-template/.git/
╭─mark@Marks-Mac-Mini ~/GitHub/static-cms-hugo-local-template 
╰─$ git add .
╭─mark@Marks-Mac-Mini ~/GitHub/static-cms-hugo-local-template 
╰─$ git commit -m "first commit"
╭─mark@Marks-Mac-Mini ~/GitHub/static-cms-hugo-local-template 
╰─$ git branch -M main
╭─mark@Marks-Mac-Mini ~/GitHub/static-cms-hugo-local-template 
╰─$ git remote add origin https://github.com/SummittDweller/wieting-staticCMS.git
╭─mark@Marks-Mac-Mini ~/GitHub/static-cms-hugo-local-template 
╰─$ git push -u origin main
...
Enumerating objects: 2979, done.
Counting objects: 100% (2979/2979), done.
Delta compression using up to 6 threads
Compressing objects: 100% (2855/2855), done.
Writing objects: 100% (2979/2979), 95.87 MiB | 2.65 MiB/s, done.
Total 2979 (delta 638), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (638/638), done.
To https://github.com/SummittDweller/wieting-staticCMS.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

wieting-staticCMS

With the new GitHub repo in place let’s take it for a local spin.

╭─mark@Marks-Mac-Mini ~/GitHub
╰─$ git clone https://github.com/SummittDweller/wieting-staticCMS.git
Cloning into 'wieting-staticCMS'...
remote: Enumerating objects: 2979, done.
remote: Total 2979 (delta 0), reused 0 (delta 0), pack-reused 2979
Receiving objects: 100% (2979/2979), 95.87 MiB | 26.77 MiB/s, done.
Resolving deltas: 100% (638/638), done.
Updating files: 100% (4834/4834), done.
╭─mark@Marks-Mac-Mini ~/GitHub
╰─$ cd wieting-staticCMS
╭─mark@Marks-Mac-Mini ~/GitHub/wieting-staticCMS ‹main›
╰─$ npm install
npm WARN deprecated querystring@0.2.0: The querystring API is considered Legacy. new code should use the URLSearchParams API instead.

added 1567 packages, and audited 1568 packages in 1m

426 packages are looking for funding
  run `npm fund` for details

2 moderate severity vulnerabilities

To address all issues, run:
  npm audit fix

Run `npm audit` for details.
╭─mark@Marks-Mac-Mini ~/GitHub/wieting-staticCMS ‹main›
╰─$ npx @staticcms/proxy-server
info: Static CMS File System Proxy Server configured with /Users/mark/GitHub/wieting-staticCMS
info: Static CMS Proxy Server listening on port 8082

Then, in a differnt terminal window…

╭─mark@Marks-Mac-Mini ~/GitHub/wieting-staticCMS ‹main›
╰─$ npm start

> static-cms-hugo-netlify-template@1.0.0 start
> run-p start:**


> static-cms-hugo-netlify-template@1.0.0 start:hugo
> hugo -d ../dist -s site -vw


> static-cms-hugo-netlify-template@1.0.0 start:webpack
> webpack-dev-server --config webpack.dev.js --hot --stats-error-details

WARN  --verbose was deprecated in Hugo v0.114.0 and will be removed in a future release. use --logLevel info
Start building sites …
hugo v0.120.1-16fb2cae88eb6add7d12e9fbfcf01d8670e60a35 darwin/amd64 BuildDate=2023-10-30T16:44:31Z VendorInfo=gohugoio

INFO  copy static: syncing static files to /
INFO  build: running step process duration 3.975463ms
INFO  build: running step assemble duration 19.211854ms
WARN  found no layout file for "json" for kind "section": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.
INFO  build: running step render duration 54.091014ms
INFO  build: running step postProcess duration 8.597µs

                   | EN
-------------------+------
  Pages            |  57
  Paginator pages  |   0
  Non-page files   |   0
  Static files     | 499
  Processed images |   0
  Aliases          |   1
  Sitemaps         |   1
  Cleaned          |   0

Built in 717 ms
Watching for changes in /Users/mark/GitHub/wieting-staticCMS/site/{archetypes,content,layouts,package.json,static,themes}
Watching for config changes in /Users/mark/GitHub/wieting-staticCMS/site/config/_default
Press Ctrl+C to stop
<i> [webpack-dev-server] Project is running at:
<i> [webpack-dev-server] Loopback: http://localhost:3000/
<i> [webpack-dev-server] On Your Network (IPv4): http://192.168.0.183:3000/
<i> [webpack-dev-server] On Your Network (IPv6): http://[fe80::1]:3000/
<i> [webpack-dev-server] Content not from webpack is served from '/Users/mark/GitHub/wieting-staticCMS/dist' directory
<i> [webpack-dev-server] 404s will fallback to '/index.html'
<i> [webpack-dev-middleware] wait until bundle finished: /
assets by path *.js 18.3 MiB
  asset cms.js 18 MiB [emitted] (name: cms)
  asset main.js 300 KiB [emitted] (name: main)
asset main.css 113 KiB [emitted] (name: main)
asset admin/index.html 521 bytes [emitted]
asset fonts/.keep 0 bytes [emitted] [from: src/fonts/.keep] [copied]
Entrypoint main 413 KiB = main.css 113 KiB main.js 300 KiB
Entrypoint cms 18 MiB = cms.js
runtime modules 72.3 KiB 38 modules
modules by path ./node_modules/ 16.9 MiB 82 modules
modules by path ./src/ 133 KiB (javascript) 113 KiB (css/mini-extract)
  modules by path ./src/js/ 15.2 KiB 9 modules
  modules by path ./src/css/*.scss 118 KiB (javascript) 113 KiB (css/mini-extract)
    ./src/css/main.scss 2.78 KiB [built] [code generated]
    ./node_modules/to-string-loader/src/to-string.js!./node_modules/css-loader/dist/cjs.js!./node_modules/postcss-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./src/css/main.scss 429 bytes [built] [code generated]
    ./node_modules/mini-css-extract-plugin/dist/loader.js??ruleSet[1].rules[2].use[1]!./node_modules/css-loader/dist/cjs.js!./node_modules/postcss-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./src/css/main.scss 332 bytes [built] [code generated]
    + 2 modules
  ./src/index.js 124 bytes [built] [code generated]
asset modules 5.46 KiB
  data:image/png;base64,iVBORw0KGgoAAAAN.. 1.28 KiB [built] [code generated] [build time executed]
  data:image/png;base64,iVBORw0KGgoAAAAN.. 1.33 KiB [built] [code generated] [build time executed]
  data:image/jpeg;base64,/9j/4QAYRXhpZgAA.. 1.55 KiB [built] [code generated] [build time executed]
  data:image/png;base64,iVBORw0KGgoAAAAN.. 1.3 KiB [built] [code generated] [build time executed]
webpack 5.89.0 compiled successfully in 6051 ms

And again, IT WORKS!

Time to merge the old CMS config from site/static/.admin-netlify/config.yml into the new config at site/static/admin/config.yml. Then a few changes will be needed since the site’s content structure has changed somewhat from the old days.

Snowpocalypse 2024 - Round 2

Mark McFate — Sat, 13 Jan 2024 15:28:12 +0000

Just thought I would post a couple more photos, with a probable update later today. Took these photos yesterday (Friday, January 12) at about noon when I ventured outside to clear the driveway. Didn’t quite get it all done because it was just too cold and windy, and the snow was still falling. I didn’t even attempt to clear the front porch… ain’t nobody coming to visit today anyway. 8^)

There are steps and a deck under there somewhere.
I love my EGO snow thrower, but pushing through drifts that are taller than the intake (about 18") is NO FUN.

Snowpocalypse 2024?

Mark McFate — Wed, 10 Jan 2024 00:00:00 +0000

Maybe not as bad as predicted (at least per some predictions) but it was enough wet snow for me. Took almost an hour to clear using my EGO cordless snow-thrower (love it) and there’s more to be done before Mackenzie and I can leave for work in the morning.

Fortunately both Grinnell College and South Tama County schools were closed today. GC re-opens at noon tomorrow and STC just announced that they will be closed on Wednesday too.

The captioned photo above is where I left it this evening at about 5:30 PM. The photo below shows the first 1-minute of my progress at about 4:30 PM. I posted a track-log of the “walk” at https://hikes.summittdweller.com/hikes/2024/01/2024-01-09_0430pm/.

Probably 6" - 7" of wet snow but near the house and street it was 14" - 16" deep. Ultimately I burned through 4 large EGO batteries. Clearing the drive in the past would typically take only 2 with some capacity to spare.

I still have more to do before going to work tomorrow. Got another storm heading this way on Wednesday evening so I better get at it in the morning. Wish me luck.

Update: 10-01-2024 @ 10 AM

Managed to get the snow-thrower out again to finish up last evening’s work before heading back to Grinnell in a bit. 34 minutes of effort covering about 3/4 of a mile. I’ll post another track log at https://hikes.summittdweller.com soon. I did take one more photo to give some perspective to the front porch situation.

I really should have taken a photo before I started. The snow shelf extending down off the roof was easily 2’ deep/tall x 8’ long x 16" thick…before I knocked it down, an effort that took 12 pokes with my shovel. Went through another two EGO batteries in the effort.

Not quite done yet, but at least the drive is clear and the front door is reachable.

On-prem Servers with StaticCMS and Remote Access for the Wieting

Mark McFate — Fri, 29 Dec 2023 16:41:14 +0000

It’s no secret that I love building ridiculously inexpensive but secure and reliable static web sites. Unfortunately, adding and maintaining content can be a pain. I’d rather write code than content! So, I also want to pawn that content responsibility off on others, but that means teaching them to use VSCode – my means of editing static content – or providing a CMS (content management system) they can work with. There’s no such thing as a static CMS so now I need some “dynamic” components. Unfortunately my “dynamic” CMS requires user authentication because *we want SOMEONE editing our content, not EVERYONE! *That always seems to be pricey, at least by comparison to our $5/month static website.

Currently…

The Wieting already has an inexpensive Hugo static website at https://Wieting.TamaToledo.com. The site code and content both reside in GitHub free-of-charge. The site is currently hosted on Netlify and that costs very little, but also provides meager and dimishing features with virtually no support. So all of that is good, but could be much better in the near future.

Right now the CMS portion of the puzzle uses NetlifyCMS which demands either running on *Netlify, *as it does,or tediously implementing a relatively complex editor authentication scheme elsewhere. I chose the simple approach of using the Netlify host with it’s built-in Netlify Identity features for authentication. Again, not bad, but not optimal and certainly not sustainable.

The other problem with NetlifyCMS is that every change/addition triggers a new automatic deployment of the site. When the editors make more than one or two changes in rapid succession, which they like to do, the CMS queues up multiple concureent re-builds of the site and those almost always exceed API quota and crash. So the changes get saved, but not deployed.

The Future…

So, what if I could give my “editors” access to a free, aka “open” CMS, one that doesn’t require Netlify or Netlify Identity? Sounds promising. I’ve been looking at StaticCMS, but if I run that CMS in the cloud we still have an “expensive” authentication requirement in some form. Hmmmm, what if that CMS were running locally on my own server so that no cloud authentication is needed? That could work, right? Editors could sit down at the server, which is really just a workstation at the theatre, and edit content until the cows come home, with no cloud authentication needed. Perfect!

Yes, but… I can’t imagine anyone wanting to sit at a workstation in the projection booth to enter content, that place is difficult to access (lots of stairs), way too noisy with the projector running, frequently either too hot or too cold, and it’s just not convenient in the least.

Remote Access to the Rescue

To avoid working in the projection booth, where the noisy projector and computer workstations are, we currently take advantage of remote desktop access using a program I purchased several years ago: Screens. I have a Screens 4 license that I obtained with a one-time-fee and it works from any of my Macs (or iOS devices) to give me control of the Mac Mini in the booth. But Screens is Mac-only software. It has a remote component called *Screens Connect *that runs on each remote device to make connections super-easy, but *Screens Connect *doesn’t work on Linux systems which require tedios manual configuration instead. **I’ve spent many hours but have never been able to make the manual configuration work with the Wieting’s networking and Kinetic internet connection from Windstream. **

In addition to Screens, the Wieting has used TeamViewer with our technical service provider, Sonic Equipment Company, for remote connections into the projection booth. We’ve never owned a license and purchasing one is cost-prohibitive.

Reasonable Remote Access?

Screens just released a new version, Screens 5, and the upgrade costs $$$ but it’s still Mac-only and there’s still no Linux version of their wonderful Screens Connect app. So, no thank you. There must be a reasonable alternative, right?

Yup. I’ve signed up for a 30-day trial (I love software that comes with a reasonable trial version and period) of Getscreen.me. So far it rocks! Even with my Linux workstations! Best of all, I believe the Wieting’s use case would cost between $60 to $150 per year. Not too shabby.

Summary… the Plan

So, my plan/proposal is to park a Linux workstation (a PC repurposed with the *Ubuntu *OS) in the projection booth to support an instance of StaticCMS. That workstation will be remotely accessible using Getscreen.me and it will be home to a local copy of the Wieting’s website. It will be configured such that StaticCMS can be used to update the local website content, with a link that can be used to push changes to GitHub where changes are deployed to https://wieting.TamaToledo.com hosted in either DigitalOcean or Azure static apps.

Bonus!

Without too much extra effort, the Linux workstation with remote access should also be able to support playback of the Wieting’s pre-show content (currently running from an unreliable Raspberry Pi) as well as projector and audio rack controls (currently supplied by our Mac Mini).

Building My First Steamlit App

Mark McFate — Mon, 24 Jul 2023 18:44:51 +0000

I’ve been wanting to give Streamlit a try for some time now. Recently, I found Streamlit DataScience Apps, a GitHub repo full of Streamlit apps, written by Jcharis. In particular, I thought I would take the Job_Search_App_with_Streamlit_Forms_n_GithubAPI code for a spin.

First step, I created a new ~/GitHub/ code directory on my Mac; I named my directory ~/GitHub/job-search-app-with-streamlit-forms. The plan was to work in that directory inside VSCode with all the project requirements housed in a Python virtual environment (.venv) there.

The command stream in my terminal looked like this:

╭─mark@Marks-Mac-Mini ~
╰─$ cd ~/GitHub
╭─mark@Marks-Mac-Mini ~/GitHub
╰─$ mkdir job-search-app-with-streamlit-forms
╭─mark@Marks-Mac-Mini ~/GitHub
╰─$ cd job-search-app-with-streamlit-forms
╭─mark@Marks-Mac-Mini ~/GitHub/job-search-app-with-streamlit-forms
╰─$ code .

That last command opened the new directory in VSCode where I had all the tools I needed, including a new terminal window. In that window I continued with…

╭─mark@Marks-Mac-Mini ~/GitHub/job-search-app-with-streamlit-forms 
╰─$ python3 -m venv .venv

╭─mark@Marks-Mac-Mini ~/GitHub/job-search-app-with-streamlit-forms 
╰─$ source .venv/bin/activate

(.venv) ╭─mark@Marks-Mac-Mini ~/GitHub/job-search-app-with-streamlit-forms 
╰─$ pip3 install streamlit

Collecting streamlit
  Downloading streamlit-1.25.0-py2.py3-none-any.whl (8.1 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 8.1/8.1 MB 26.6 MB/s eta 0:00:00
Collecting altair<6,>=4.0
  Downloading altair-5.0.1-py3-none-any.whl (471 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 471.5/471.5 kB 13.9 MB/s eta 0:00:00
Collecting blinker<2,>=1.0.0
  Downloading blinker-1.6.2-py3-none-any.whl (13 kB)
Collecting cachetools<6,>=4.0
  Downloading cachetools-5.3.1-py3-none-any.whl (9.3 kB)
Collecting click<9,>=7.0
  Downloading click-8.1.6-py3-none-any.whl (97 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 97.9/97.9 kB 3.7 MB/s eta 0:00:00
Collecting importlib-metadata<7,>=1.4
  Downloading importlib_metadata-6.8.0-py3-none-any.whl (22 kB)
Collecting numpy<2,>=1.19.3
  Downloading numpy-1.25.1-cp311-cp311-macosx_10_9_x86_64.whl (20.0 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 20.0/20.0 MB 30.2 MB/s eta 0:00:00
Collecting packaging<24,>=16.8
  Downloading packaging-23.1-py3-none-any.whl (48 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 48.9/48.9 kB 1.6 MB/s eta 0:00:00
Collecting pandas<3,>=1.3.0
  Downloading pandas-2.0.3-cp311-cp311-macosx_10_9_x86_64.whl (11.6 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 11.6/11.6 MB 38.2 MB/s eta 0:00:00
Collecting pillow<10,>=7.1.0
  Downloading Pillow-9.5.0-cp311-cp311-macosx_10_10_x86_64.whl (3.4 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.4/3.4 MB 23.5 MB/s eta 0:00:00
Collecting protobuf<5,>=3.20
  Downloading protobuf-4.23.4-cp37-abi3-macosx_10_9_universal2.whl (400 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 400.3/400.3 kB 12.9 MB/s eta 0:00:00
Collecting pyarrow>=6.0
  Downloading pyarrow-12.0.1-cp311-cp311-macosx_10_14_x86_64.whl (24.7 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 24.7/24.7 MB 19.0 MB/s eta 0:00:00
Collecting pympler<2,>=0.9
  Downloading Pympler-1.0.1-py3-none-any.whl (164 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 164.8/164.8 kB 5.9 MB/s eta 0:00:00
Collecting python-dateutil<3,>=2.7.3
  Downloading python_dateutil-2.8.2-py2.py3-none-any.whl (247 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 247.7/247.7 kB 7.9 MB/s eta 0:00:00
Collecting requests<3,>=2.18
  Downloading requests-2.31.0-py3-none-any.whl (62 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 62.6/62.6 kB 2.3 MB/s eta 0:00:00
Collecting rich<14,>=10.14.0
  Downloading rich-13.4.2-py3-none-any.whl (239 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 239.4/239.4 kB 8.8 MB/s eta 0:00:00
Collecting tenacity<9,>=8.1.0
  Downloading tenacity-8.2.2-py3-none-any.whl (24 kB)
Collecting toml<2,>=0.10.1
  Downloading toml-0.10.2-py2.py3-none-any.whl (16 kB)
Collecting typing-extensions<5,>=4.1.0
  Downloading typing_extensions-4.7.1-py3-none-any.whl (33 kB)
Collecting tzlocal<5,>=1.1
  Downloading tzlocal-4.3.1-py3-none-any.whl (20 kB)
Collecting validators<1,>=0.2
  Downloading validators-0.20.0.tar.gz (30 kB)
  Preparing metadata (setup.py) ... done
Collecting gitpython!=3.1.19,<4,>=3.0.7
  Downloading GitPython-3.1.32-py3-none-any.whl (188 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 188.5/188.5 kB 6.9 MB/s eta 0:00:00
Collecting pydeck<1,>=0.8
  Downloading pydeck-0.8.0-py2.py3-none-any.whl (4.7 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4.7/4.7 MB 28.7 MB/s eta 0:00:00
Collecting tornado<7,>=6.0.3
  Downloading tornado-6.3.2-cp38-abi3-macosx_10_9_x86_64.whl (422 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 422.6/422.6 kB 12.7 MB/s eta 0:00:00
Collecting jinja2
  Downloading Jinja2-3.1.2-py3-none-any.whl (133 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 133.1/133.1 kB 5.4 MB/s eta 0:00:00
Collecting jsonschema>=3.0
  Downloading jsonschema-4.18.4-py3-none-any.whl (80 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 81.0/81.0 kB 3.0 MB/s eta 0:00:00
Collecting toolz
  Downloading toolz-0.12.0-py3-none-any.whl (55 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 55.8/55.8 kB 2.1 MB/s eta 0:00:00
Collecting gitdb<5,>=4.0.1
  Downloading gitdb-4.0.10-py3-none-any.whl (62 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 62.7/62.7 kB 2.1 MB/s eta 0:00:00
Collecting zipp>=0.5
  Downloading zipp-3.16.2-py3-none-any.whl (7.2 kB)
Collecting pytz>=2020.1
  Using cached pytz-2023.3-py2.py3-none-any.whl (502 kB)
Collecting tzdata>=2022.1
  Downloading tzdata-2023.3-py2.py3-none-any.whl (341 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 341.8/341.8 kB 10.8 MB/s eta 0:00:00
Collecting six>=1.5
  Downloading six-1.16.0-py2.py3-none-any.whl (11 kB)
Collecting charset-normalizer<4,>=2
  Downloading charset_normalizer-3.2.0-cp311-cp311-macosx_10_9_x86_64.whl (125 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 125.1/125.1 kB 4.5 MB/s eta 0:00:00
Collecting idna<4,>=2.5
  Downloading idna-3.4-py3-none-any.whl (61 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 61.5/61.5 kB 2.1 MB/s eta 0:00:00
Collecting urllib3<3,>=1.21.1
  Downloading urllib3-2.0.4-py3-none-any.whl (123 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 123.9/123.9 kB 4.5 MB/s eta 0:00:00
Collecting certifi>=2017.4.17
  Downloading certifi-2023.7.22-py3-none-any.whl (158 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 158.3/158.3 kB 5.7 MB/s eta 0:00:00
Collecting markdown-it-py>=2.2.0
  Downloading markdown_it_py-3.0.0-py3-none-any.whl (87 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 87.5/87.5 kB 3.3 MB/s eta 0:00:00
Collecting pygments<3.0.0,>=2.13.0
  Downloading Pygments-2.15.1-py3-none-any.whl (1.1 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.1/1.1 MB 23.0 MB/s eta 0:00:00
Collecting pytz-deprecation-shim
  Downloading pytz_deprecation_shim-0.1.0.post0-py2.py3-none-any.whl (15 kB)
Collecting decorator>=3.4.0
  Downloading decorator-5.1.1-py3-none-any.whl (9.1 kB)
Collecting smmap<6,>=3.0.1
  Downloading smmap-5.0.0-py3-none-any.whl (24 kB)
Collecting MarkupSafe>=2.0
  Downloading MarkupSafe-2.1.3-cp311-cp311-macosx_10_9_x86_64.whl (13 kB)
Collecting attrs>=22.2.0
  Downloading attrs-23.1.0-py3-none-any.whl (61 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 61.2/61.2 kB 2.1 MB/s eta 0:00:00
Collecting jsonschema-specifications>=2023.03.6
  Downloading jsonschema_specifications-2023.7.1-py3-none-any.whl (17 kB)
Collecting referencing>=0.28.4
  Downloading referencing-0.30.0-py3-none-any.whl (25 kB)
Collecting rpds-py>=0.7.1
  Downloading rpds_py-0.9.2-cp311-cp311-macosx_10_7_x86_64.whl (311 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 311.9/311.9 kB 9.3 MB/s eta 0:00:00
Collecting mdurl~=0.1
  Downloading mdurl-0.1.2-py3-none-any.whl (10.0 kB)
Installing collected packages: pytz, zipp, urllib3, tzdata, typing-extensions, tornado, toolz, toml, tenacity, smmap, six, rpds-py, pympler, pygments, protobuf, pillow, packaging, numpy, mdurl, MarkupSafe, idna, decorator, click, charset-normalizer, certifi, cachetools, blinker, attrs, validators, requests, referencing, pytz-deprecation-shim, python-dateutil, pyarrow, markdown-it-py, jinja2, importlib-metadata, gitdb, tzlocal, rich, pydeck, pandas, jsonschema-specifications, gitpython, jsonschema, altair, streamlit
  DEPRECATION: validators is being installed using the legacy 'setup.py install' method, because it does not have a 'pyproject.toml' and the 'wheel' package is not installed. pip 23.1 will enforce this behaviour change. A possible replacement is to enable the '--use-pep517' option. Discussion can be found at https://github.com/pypa/pip/issues/8559
  Running setup.py install for validators ... done
Successfully installed MarkupSafe-2.1.3 altair-5.0.1 attrs-23.1.0 blinker-1.6.2 cachetools-5.3.1 certifi-2023.7.22 charset-normalizer-3.2.0 click-8.1.6 decorator-5.1.1 gitdb-4.0.10 gitpython-3.1.32 idna-3.4 importlib-metadata-6.8.0 jinja2-3.1.2 jsonschema-4.18.4 jsonschema-specifications-2023.7.1 markdown-it-py-3.0.0 mdurl-0.1.2 numpy-1.25.1 packaging-23.1 pandas-2.0.3 pillow-9.5.0 protobuf-4.23.4 pyarrow-12.0.1 pydeck-0.8.0 pygments-2.15.1 pympler-1.0.1 python-dateutil-2.8.2 pytz-2023.3 pytz-deprecation-shim-0.1.0.post0 referencing-0.30.0 requests-2.31.0 rich-13.4.2 rpds-py-0.9.2 six-1.16.0 smmap-5.0.0 streamlit-1.25.0 tenacity-8.2.2 toml-0.10.2 toolz-0.12.0 tornado-6.3.2 typing-extensions-4.7.1 tzdata-2023.3 tzlocal-4.3.1 urllib3-2.0.4 validators-0.20.0 zipp-3.16.2

[notice] A new release of pip is available: 23.0.1 -> 23.2.1
[notice] To update, run: pip install --upgrade pip

(.venv) ╭─mark@Marks-Mac-Mini ~/GitHub/job-search-app-with-streamlit-forms 
╰─$ pip install --upgrade pip

Requirement already satisfied: pip in ./.venv/lib/python3.11/site-packages (23.0.1)
Collecting pip
  Downloading pip-23.2.1-py3-none-any.whl (2.1 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.1/2.1 MB 12.6 MB/s eta 0:00:00
Installing collected packages: pip
  Attempting uninstall: pip
    Found existing installation: pip 23.0.1
    Uninstalling pip-23.0.1:
      Successfully uninstalled pip-23.0.1
Successfully installed pip-23.2.1

(.venv) ╭─mark@Marks-Mac-Mini ~/GitHub/job-search-app-with-streamlit-forms 
╰─$ pip3 install requests

Requirement already satisfied: requests in ./.venv/lib/python3.11/site-packages (2.31.0)
Requirement already satisfied: charset-normalizer<4,>=2 in ./.venv/lib/python3.11/site-packages (from requests) (3.2.0)
Requirement already satisfied: idna<4,>=2.5 in ./.venv/lib/python3.11/site-packages (from requests) (3.4)
Requirement already satisfied: urllib3<3,>=1.21.1 in ./.venv/lib/python3.11/site-packages (from requests) (2.0.4)
Requirement already satisfied: certifi>=2017.4.17 in ./.venv/lib/python3.11/site-packages (from requests) (2023.7.22)

(.venv) ╭─mark@Marks-Mac-Mini ~/GitHub/job-search-app-with-streamlit-forms 
╰─$ streamlit app
Usage: streamlit [OPTIONS] COMMAND [ARGS]...
Try 'streamlit --help' for help.

Error: No such command 'app'.

(.venv) ╭─mark@Marks-Mac-Mini ~/GitHub/job-search-app-with-streamlit-forms 
╰─$ streamlit run app.py

  You can now view your Streamlit app in your browser.

  Local URL: http://localhost:8501
  Network URL: http://192.168.0.183:8501

  For better performance, install the Watchdog module:

  $ xcode-select --install
  $ pip install watchdog
            
2023-07-24 20:58:17.240 Uncaught app exception
Traceback (most recent call last):
  File "/Users/mark/GitHub/job-search-app-with-streamlit-forms/.venv/lib/python3.11/site-packages/streamlit/runtime/scriptrunner/script_runner.py", line 552, in _run_script
    exec(code, module.__dict__)
  File "/Users/mark/GitHub/job-search-app-with-streamlit-forms/app.py", line 116, in <module>
    main()
  File "/Users/mark/GitHub/job-search-app-with-streamlit-forms/app.py", line 43, in main
    nav1,nav2,nav3 = st.beta_columns([3,2,1])
                     ^^^^^^^^^^^^^^^
AttributeError: module 'streamlit' has no attribute 'beta_columns'

Mackenzie says I need to remove the beta_ in two places in the code… Done.

Launching the app again with streamlit run app.py after a moment or two it works!

Redefining an Azure Static Web App

Mark McFate — Thu, 06 Jul 2023 19:11:12 +0000

Today’s burning question… Can I easily “redefine” an Azure Static Web App?

So, the source code for my password-protected Wieting-Guild-Pages is broken and I can’t update the stale old content that’s currently there. It’s a long story. Fortunately, I’ve rebuilt that code in a new GitHub repo and have it working again. Yay!

Now, can I take the deployment parts of the old/broken repo and apply them to the new repo and make it all work again?

Worth a Try

So, I started this experiment by visiting the old project, https://github.com/SummittDweller/wieting-guild-pages, and copying the https://github.com/SummittDweller/wieting-guild-pages/blob/main/.github/workflows/azure-static-web-apps-lemon-mushroom-087d78210.yml file found there. That GitHub workflow file contains nearly all the information required to deploy the old site, maybe it will work for the new site too? Nope, at least not right out of the box.

I attched the .yml file to my new project by placing an unmodified copy of it in the new project’s .github/workflows directory. Then when I committed the change and pushed it to GitHub the workflow kicked in automatically. Ultimately it looks like the “build” portion of the process worked as-expected, but the “deployment” failed with these messages:

DeploymentId: 86ab60d0-3abf-429c-9c17-405068c1ebcf

deployment_token was not provided.
The deployment_token is required for deploying content. If you'd like to continue the run without deployment, add the configuration skip_deploy_on_missing_secrets set to true in your workflow file
An unknown exception has occurred

For further information, please visit the Azure Static Web Apps documentation at https://docs.microsoft.com/en-us/azure/static-web-apps/
If you believe this behavior is unexpected, please raise a GitHub issue at https://github.com/azure/static-web-apps/issues/
Exiting

Something is Missing

Since I’m not absolutely sure what’s missing, and I don’t know how to replace it even if I was sure of what it is, I’m going to just create a new instance of this web app following the guidance, yet again, in Quickstart: Build your first static web app.

Upgrading Matomo PHP

Mark McFate — Mon, 12 Jun 2023 19:30:18 +0000

This afternoon I’m adding https://digital.grinnell.edu (site ID is 17) to my own Matomo instance and I’m prompted to upgrade PHP on that Matomo droplet (DigitalOcean). I did so quite easily following Upgrade PHP from 7.2 to 7.4 on CentOS 8 and Apache. I’ve also updated my Drupal version, and some modules, in https://digital.grinnell.edu along with adding the matomo module, but that module is now reporting:

    The validation of "http://analytics.summittservices.com/matomo.php" failed with error "Error opening socket ssl://analytics.summittservices.com:443" (HTTP code 0).
    The validation of "https://analytics.summittservices.com/matomo.php" failed with error "Error opening socket ssl://analytics.summittservices.com:443" (HTTP code 0).

Hmmm…wonder what’s up with that?

So, I tried this…

Last login: Mon Jun 12 19:21:45 2023 from 162.243.190.66
[root@centos-s-1vcpu-1gb-nyc1-01 ~]# sudo certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/summittservices.com-0001.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Renewing an existing certificate for summittservices.com and analytics.summittservices.com
Reloading nginx server after certificate renewal

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/summittservices.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Renewing an existing certificate for summittservices.com and www.summittservices.com
Reloading nginx server after certificate renewal

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all renewals succeeded: 
  /etc/letsencrypt/live/summittservices.com-0001/fullchain.pem (success)
  /etc/letsencrypt/live/summittservices.com/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

…and… NO more validation errors! Yay!

Planting Sempervivum tectorum (and More)

Mark McFate — Tue, 06 Jun 2023 17:14:02 +0000

This morning I started an experiment… clipping leaves (“lobes” might be a better term for these things) from a healthy, indoor Sempervivum tectorum. What’s that, you ask? The common name is Hens and Chicks.

A couple of weeks ago I bought an on-sale strawberry pot full of Sempervivum tectorum and I have it growing on a little table on the front porch. It’s doing QUITE WELL there! A couple of days ago I uprooted a 3 foot square patch of Snow on the Mountain from a spot in my front flower beds (outside out southeast bedroom window), and that left a big bare patch of soil to be dealt with.

Today I clipped some vertical growth from the Sempervivum tectorum, stripped about two dozen of the “lobes” from the bottoms, and transplanted the “stems” into an indoor pot where I’m also trying to root some Jade plants. That left me with a handful of detached “lobes” so I got out my cultivator, chewed up the bare spot left from the Snow on the Mountain, scattered the detached lobes there, and covered them gently with a little garden soil. I have no idea if these might produce new plants… we shall see.

Since I had the cultivator out I also roughed up some spots where I’m having trougle getting grass to grow, and I’ll be watering those spots for the coming week just as I have been watering the Snow on the Mountain which was transplated to an area near STC Elementary where there’s an Ian memorial rock and bench. There’s no longer a tree at that memorial location, the previous one died so we had it cut down. Our hope is to plant a new tree this Fall.

-/-/-/

location: Toledo, IA

Fixing Wieting Guild Pages

Mark McFate — Sat, 03 Jun 2023 23:20:26 +0000

Just the other day I got an updated copy of the Wieting Theatre’s volunteer roster and assignment schedule. As I’m trying to post them to the theatre’s management website (it’s password protected) I keep having issues with npm and dependencies that won’t compile. The fix, thus far has included a local command stream like this:

cd wieting-guild-pages
git pull
code .
npm run build
npm run start 
  --> failed
npm update
npm audit fix
npm run build
npm run start
  --> failed
npm audit fix --force
npm run build
  --> failed
npm install axios
npm run build
  --> failed
npm update
npm run build

The last errors had this in common:

[11ty] Unhandled rejection in promise: (more in DEBUG output)
[11ty] connect ETIMEDOUT 54.243.162.8:443 (via Error)
[11ty] 
[11ty] Original error stack trace: Error: connect ETIMEDOUT 54.243.162.8:443
[11ty]     at AxiosError.from (/Users/mark/GitHub/wieting-guild-pages/node_modules/axios/dist/node/axios.cjs:836:14)

One explanation I found:

The ETIMEDOUT error is thrown by the Node.js runtime when a connection or HTTP request is not closed properly after some time. You might encounter this error from time to time if you configured a timeout on your outgoing HTTP requests. The general solution to this issue is to catch the error and repeat the request, preferably using an exponential backoff strategy so that a waiting period is added between subsequent retries until the request eventually succeeds, or the maximum amount of retries is reached. If you encounter this error frequently, try to investigate your request timeout settings and choose a more appropriate value for the endpoint if possible.

I also found a GitHub issues/bug report related to Axios and this error at https://github.com/SillyTavern/SillyTavern/issues/432. So, maybe it’s not just me?

Roadtrip: Geowoodstock 2023

Mark McFate — Mon, 29 May 2023 22:32:00 +0000

Geowoodstock 2023 (GC89GMX) and Kentucky’s oldest surviving geocache (GC39E) were the intended destinations of another epic roadtrip with gossamar on May 25-28, 2023.

The route and cache count looked something like this:

The green lines represent my “outbound” route while the red lines show my “return” route back from GC39E. The ordered list of caches and events found is available for download below.

The GPS Maze at the top of the list was not found first, but it’s listed that way.

Geowoodstock-Caches-Found.pdf

By the numbers I show:

88 geocaches found + events attended
108 Adventure Lab stages logged
a few DNFs
985 miles traveled in Tom’s car at 40+ mpg
21.4 gallons of gas totaling $72.30
520 miles traveled in my Honda Ridgeline at 24+ mpg

Wrap EVERYTHING in NPM!

Mark McFate — Fri, 19 May 2023 22:27:00 +0000

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.

So, how might I approach combining Hugo with Pagefind in the cloud? Well, A Powerful Blog Setup with Hugo and NPM* by Tom Hombergs looked like a promising place to start. The process that Tom advocates leverages a neat little package called hugo-bin.

*The links provided above and below are to a Wayback Machine capture of the original post.

That Was Too Easy!

Wrapping my Hugo site in an NPM package was so easy that I forgot to document it… and maybe I really didn’t need too. Time to catch up, so here’s a brief sysnopsis of what I did…

Following Tom’s Excellent Advice

cd ~/GitHub/
# Named the new project npm-rootstalk so it would not confilct with any of my existing `rootstalk...` directories
mkdir npm-rootstalk      
cd npm-rootstalk
npx hugo new site . --force
# Copied the contents of my old project into the new one and then removed whatever I no longer needed
cp -fr ~/GitHub/rootstalk/. .  
# Installed Pagefind...
npm install pagefind
git init
# I created a new empty repo in GitHub called npm-rootstalk, then...
git remote add origin https://github.com/Digital-Grinnell/npm-rootstalk 
git add . 
git commit -m "Initial commit of new npm-wrapped Hugo project"
git push

Having secured a new repo I moved to running Hugo locally, then polishing my package.json scripts as Tom did. I now have a package.json that reads like this:

{
  "name": "npm-rootstalk",
  "version": "1.0.0",
  "description": "Rootstalk website built with Hugo and the Lightbi theme inside an NPM package.  May 2023.",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "build": "npm run hugo:build && npx pagefind --source public",
    "do:build": "hugo -d public && npx pagefind --source public",
    "azure:build": "hugo -d public --baseURL=\"https://yellow-wave-0e513e510.3.azurestaticapps.net/\" && npx pagefind --source public",
    "clean": "npm run hugo:clean",
    "serve": "npm run hugo:build && npx pagefind --source public --bundle-dir ../static/_pagefind && npm run hugo:serve",
    "hugo:build": "hugo -d public",
    "hugo:serve": "hugo server",
    "hugo:clean": "rm -rf build resources public"
  },
  "author": "Mark A. McFate",
  "license": "ISC",
  "dependencies": {
    "hugo-bin": "^0.102.0",
    "pagefind": "^0.12.0"
  }
}

It Works!

Now I just use npm run serve to build the Hugo site, index it with Pagefind, and serve it locally at http://localhost:1313.

A Staging Site in Azure

I can simply push changes to the main branch of the npm-rootstalk repo to trigger an Azure (aka GitHub Actions) rebuild, indexing and deployment of the site to this address.

A New Production Branch

That DO app spec reads like this:

alerts:
- rule: DEPLOYMENT_FAILED
- rule: DOMAIN_FAILED
domains:
- domain: rootstalk.grinnell.edu
  type: PRIMARY
- domain: prairiejournal.grinnell.edu
  type: ALIAS
envs:
- key: TZ
  scope: RUN_AND_BUILD_TIME
  value: America/Chicago
- key: HUGO_MATOMO_ID
  scope: RUN_AND_BUILD_TIME
  value: "15"
ingress:
  rules:
  - component:
      name: npm-rootstalk
    match:
      path:
        prefix: /
name: npm-rootstalk
region: nyc
static_sites:
- build_command: npm run build
  environment_slug: node-js
  github:
    branch: production
    deploy_on_push: true
    repo: Digital-Grinnell/npm-rootstalk
  name: npm-rootstalk
  source_dir: /

It’s heavenly! And that’s all for now.

A Pagefind Problem?

Mark McFate — Wed, 10 May 2023 14:33:09 +0000

Not Just a Hugo Issue

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.

The Nutshell

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.

The Azure script auto-detects the presence of a Hugo project, or any one of many other platforms. That makes the process super-easy to use, but nearly impossible to “customize”. Azure does provide some configuration variables to influence the script behavior, most notably there’s an app_build_command variable that looks promising, but it only works for node builds, and not for Hugo.

Three Possible Solutions

I can reasonably see three possible solutions to this dilema. In order of simplicity they are:

1. Skip Azure and Deploy Only to DigitalOcean

Ultimately, Rootstalk’s production instance is a DigitalOcean (DO) static web app, Azure is only used for “staging” of a locally viable Rootstalk instance. DO doesn’t use GitHub Actions, a drawback in my book, so its build script, called an “App Spec” in DO, is a little more “open”. The critical portion of the App Spec I use to deploy Rootstalk in DO reads like this:

static_sites:
- build_command: hugo -d public

That’s it, just a simple hugo -d public command. So, in theory I should be able to just change that to read:

static_sites:
- build_command: hugo -d public && npm_config_yes=true npx pagefind --source "public" --bundle-dir ../static/_pagefind

It’s basically just a “compound” command to run npx immediately after hugo is done compiling.

The problem with this very simple solution, assuming it even works, is that it’s somewhat unique to Rootstalk which is already deployed to DigitalOcean. Other Hugo projects, and I have many like this blog, that need Azure or another cloud provider other than DO, would not benefit from this fix.

Update 12-May-2023: Same Problem Exists in DigitalOcean

Well, I tried. I attempted to push my Pagefind additions to Rootstalk forward directly into production on DigitalOcean. Unfortunately, that failed in similar fashion to what I saw in Azure. It all works locally, but DigitalOcean, like Azure, has no way of “detecting” that my Hugo project has an NPM component, and therefore takes no steps to build NPM or Pagefind into my solution.

So, I’m moving on to option #2 below. Wish me luck.

2. Wrap Hugo in `npm`

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 because it’s Javascript, not Go, and it’s elegantly simple with tons of flexibility. If my 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.

So, how might I approach something like this? Well, A Powerful Blog Setup with Hugo and NPM by Tom Hombergs looks like a promising place to start. The process that Tom advocates leverages a neat little package called hugo-bin.

If strategy #1 fails I’ll certainly give this #2 a try. Even if #1 works, I might give this strategy a spin if/when I re-tool this blog.

Update 29-May-2023: NPM is GREAT!

Since my first option (above) failed very quickly, I moved on to this option and I honestly think I might transition every static site that I have to be wrapped inside NPM, it works wonderfully and is a really attractive solution for so many ills!

I’m going to document my experience with NPM wrapped around Hugo and will post that document here soon, probably as Wrap EVERYTHING in NPM!.

3. Transition from Hugo to Eleventy

Reasonable? Yes. A lot of work? That’s relative. The right thing to do? Probably.

So, it’s already been done, see This Blog in Eleventy + Ghost and Searching for a Search Solution. That’s all I’m going to say about this option, a definite maybe.

That’s all folks… for now.

Searching for a Search Solution

Mark McFate — Thu, 20 Apr 2023 17:02:00 +0000

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.

Glad I Found Pagefind

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.

Mike doesn’t explain the setup in detail, but this comment really resonated with me so I decided to follow the same path:

Weirdly, I’ve found that I seem to read the posts on this site more than I write them. I say read, but I just mean referring to the stuff I’ve written because it has left my head.

Mike does provide a link to the reference he used, namely Using PageFind with Eleventy for Search by Robb Knight. I found Robb’s guidance and experience to be VERY helpful. Thank you, Robb!

Implementing Robb’s Approach

I won’t bother duplicating what Robb explains quite well, but this wasn’t a 10-minute solution for me, probably because I’m really still learning Javascript and Eleventy, and also because I’m using a Ghost back-end with packages managed via Yarn rather than npm.

So, in the few sections that follow I’ll try to briefly described what’s different about my approach versus Robb’s, along with what didn’t, and what ultimately did work.

`yarn`, Not `npm`

The first significant difference I encountered was the requirement that this blog project uses yarn, not npm for package management. Eventually I found that I just needed to replace Robb’s npm install pagefind command with a yarn add pagefind equivalent. I don’t really understand the details of that difference, but it worked.

eleventy.after Never Fires?

The biggest hurdle for me was trying to get this bit of Robb’s code to work.

const { execSync } = require('child_process')

module.exports = function(eleventyConfig) {
  eleventyConfig.on('eleventy.after', () => {
    execSync(`npx pagefind --source _site --glob \"**/*.html\"`, { encoding: 'utf-8' })
  })
}

In my case the --source parameter needed to be dist since this blog is generated into a directory by that name, and my configuration object is simply config rather than eleventyConfig. I made those simple changes and added my snippet to the .eleventy.js file, but found that it never triggered. I even replaced the execSync function call with a simple console.log statement and still got nothing. And still to this day, I have no idea why that didn’t work.

That snippet of code is supposed to be responsible for indexing all of the .html files after Eleventy has generated them. Well, I found out that everything else was working properly, but the _pagefind bundle generated by that indexing operation was just “missing”, since the index never was created. That made me wonder what would happen if I “forced” the system to index my content in a different manner…and that wonder ultimately worked.

Using `npx pagefind...` to Index Content

Having studied some of the Pagefind documentation I wondered what adding some post-processing to my build workflow might do, something like npx pagefind --source dist? That ultimately worked, but not in that original form.

I found that when I ran yarn start to locally rebuild the site, there was no generated ./dist/_pagefind bundle present, so I got no “Search” user interface elements, but there was an empty <div> where that belonged. So, with my localhost instance still running I opened a new terminal and ran npx pagefind --source dist in the project directory. Voila! The ./dist/_pagefind bundle magically appeared and the “Search” control was instantly visible in my localhost window! It was working, and it was beautiful.

Added a `pagefind` Script… Didn’t Work

Ok, with the above breakthrough in-hand I made this addition to the scripts: key in my package.json file:

  "pagefind": "npx pagefind --source dist"

Then I added the following to the end of my steps: key in .github/workflows/build-and-deploy.yml:

  - run: yarn pagefind

This worked to some extent, but wasn’t reliable and absolutely didn’t work when deployed to my DigitalOcean app. The inner-workings of yarn and build caching in these environments is still a DEEP mystery to me!

Extending My `encrypt` Script

What does work, both locally and on DigitalOcean, is essentially an “extension” of my old encrypt script. My old build workflow included these two elements of package.json and build-and-deploy.yml:

    "encrypt": "staticrypt ./dist/rebuild.html '***hidden***' --short -o ./dist/rebuild.html -f ./src/auth/login.html -t 'Summitt Dweller Blog - Rebuild' -i 'Please enter the passphrase.<br/>Hint: gh0st' --label-error 'Sorry, Ella says no. Try again.'"

…and…

  - run: yarn encrypt

I took note of the relative path spec for ./dist/rebuild.html in the encrypt command, reasoned that I should run pagefind in a similar fashion – but just before encryption – and came up with this change in package.json:

    "encrypt": "npx pagefind --source ./dist && staticrypt ./dist/rebuild.html '***hidden***' --short -o ./dist/rebuild.html -f ./src/auth/login.html -t 'Summitt Dweller Blog - Rebuild' -i 'Please enter the passphrase.<br/>Hint: gh0st' --label-error 'Sorry, Ella says no. Try again.'"

It works!

When I’m running locally my build-and-deploy.yml doesn’t apply so in that case I typically will do this IF I want my search index (and encryption) updated:

yarn start
yarn encrypt

When I rebuild in production on DigitalOcean my build-and-deploy.yml configuration IS run so including npx pagefind... as part of the yarn encrypt step does the trick.

Time to Test…

I’m going to save this post now and rebuild this blog on DigitalOcean, where with any luck, a search for a term like “DEEP” should return this post, and maybe one or two others. Drum roll please… Huzzah!

Man, Do I Feel Stupid

Previously I mentioned that my additon of a package.json script named pagefind didn’t work, and that my DigitalOcean builds kept trying to do yarn encrypt after yarn build. Well, turns out that’s because build-and-deploy.yml, where I had inserted the yarn pagefind step IS NOT in control of building my DigitalOcean app. In fact, it’s a .github workflow so I’m really not sure what role that file plays, if any?

I went looking in my DigitalOcean app configuration settings for yarn encrypt and found it, in the app’s “App Settings” subsection titled “App Spec”. When I view that “App Spec” I see this:

alerts:
- rule: DEPLOYMENT_FAILED
- rule: DOMAIN_FAILED
domains:
- domain: blog.summittdweller.com
  type: PRIMARY
  zone: summittdweller.com
envs:
- key: TZ
  scope: RUN_AND_BUILD_TIME
  value: America/Chicago
name: blog-summittdweller-11ty-ghost
region: nyc
static_sites:
- build_command: |-
    yarn build
    yarn encrypt
  environment_slug: node-js
  github:
    branch: main
    deploy_on_push: true
    repo: SummittDweller/blog-eleventy-ghost
  name: blog-eleventy-ghost
  output_dir: dist
  routes:
  - path: /
  source_dir: /

Note the two build_command: elements. Let’s change those two steps to three, like so:

- build_command: |-
    yarn build
    yarn pagefind
    yarn encrypt

Note that I captured the “App Spec” in a file named blog-summittdweller-11ty-ghost.yaml and I’ve saved that file in the project directory (where I hope it will do no harm). Attention: After making the aforementioned addition I almost forgot to upload this file back to DigitalOcean to replace our existing App Spec! Don’t be stupid like me!

Next, I needed a corresponding change in package.json, specifically these two lines (like I had them before, duh):

  "pagefind": "npx pagefind --source ./dist",
  "encrypt": "staticrypt ./dist/rebuild.html '***hidden***' --short -o ./dist/rebuild.html -f ./src/auth/login.html -t 'Summitt Dweller Blog - Rebuild' -i 'Please enter the passphrase.<br/>Hint: gh0st' --label-error 'Sorry, Ella says no. Try again.'"

Push to Rebuild

Ok, having modified and UPLOADEDblog-summittdweller-11ty-ghost.yaml, and having modified package.json, it came time to commit and push all my changes to see what happens. Another drum roll, please…

Engaging `s3cmd` to Download and Resize Images from DO Spaces

Mark McFate — Sun, 16 Apr 2023 14:57:16 +0000

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…

Installing `s3cmd`

This looks to be very simple and straightforward, brew install s3cmd should do the trick. In a substantially abridged form, that looked like this:

╭─mark@Marks-Mac-Mini ~/GitHub/blog-eleventy-ghost ‹main›
╰─$ brew install s3cmd
Running `brew update --auto-update`...
==> Auto-updated Homebrew!
==> Updated Homebrew from 4.0.10 (931327df1) to 4.0.13 (ac0663ae5).
Updated 4 taps (dart-lang/dart, sass/sass, homebrew/core and homebrew/cask).
...
You have 55 outdated formulae and 1 outdated cask installed.
...
==> Installing s3cmd
==> Pouring s3cmd--2.3.0.ventura.bottle.1.tar.gz
🍺  /usr/local/Cellar/s3cmd/2.3.0: 837 files, 11.4MB
==> Running `brew cleanup s3cmd`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
...

That took about 10 minutes, but should be worth it.

Configuration

Next, to begin configuration I need to fetch the access key:value pair for images-summittdweller that I created 4 years ago. I have the credentials necessary to view that information at https://cloud.digitalocean.com/account/api/spaces so that’s what I’ve done.

Whoa, that didn’t work! I tried to use old access keys but apparently they are in the wrong format? So, I created a new key named key-for-s3cmd and applied that (see below) and it works.

╭─mark@Marks-Mac-Mini ~/GitHub/blog-eleventy-ghost ‹main›
╰─$ s3cmd --configure

Enter new values or accept defaults in brackets with Enter.
Refer to user manual for detailed description of all options.

Access key and Secret key are your identifiers for Amazon S3. Leave them empty for using the env variables.
Access Key [images-summittdweller]: ***This is a secret***
Secret Key [4YPWYNXZZXFDIR6CRPHG]: ***An even bigger secret***
Default Region [US]:

Use "s3.amazonaws.com" for S3 Endpoint and not modify it to the target Amazon S3.
S3 Endpoint [nyc3.digitaloceanspaces.com]:

Use "%(bucket)s.s3.amazonaws.com" to the target Amazon S3. "%(bucket)s" and "%(location)s" vars can be used
if the target S3 system supports dns based buckets.
DNS-style bucket+hostname:port template for accessing a bucket [%(bucket)s.nyc3.digitaloceanspaces.com]:

Encryption password is used to protect your files from reading
by unauthorized persons while in transfer to S3
Encryption password [SummittDweller]:
Path to GPG program [/usr/local/bin/gpg]:

When using secure HTTPS protocol all communication with Amazon S3
servers is protected from 3rd party eavesdropping. This method is
slower than plain HTTP, and can only be proxied with Python 2.7 or newer
Use HTTPS protocol [Yes]:

On some networks all internet access must go through a HTTP proxy.
Try setting it here if you can't connect to S3 directly
HTTP Proxy server name:

New settings:
  Access Key: ***This is a secret***
  Secret Key: ***An even bigger secret***
  Default Region: US
  S3 Endpoint: nyc3.digitaloceanspaces.com
  DNS-style bucket+hostname:port template for accessing a bucket: %(bucket)s.nyc3.digitaloceanspaces.com
  Encryption password: SummittDweller
  Path to GPG program: /usr/local/bin/gpg
  Use HTTPS protocol: True
  HTTP Proxy server name:
  HTTP Proxy server port: 0

Test access with supplied credentials? [Y/n] Y
Please wait, attempting to list all buckets...
Success. Your access key and secret key worked fine :-)

Now verifying that encryption works...
Success. Encryption and decryption worked fine :-)

Save settings? [y/N] y
Configuration saved to '/Users/mark/.s3cfg'

Using `s3cwd`

The “More Information” section at the end of the document I used above says that… “You can use our quick reference on s3cmd usage to get started.” Ok, let’s have a look… very nice! I’m moving immediately to the Save files to your local computer bits.

Fetching Files of the August 2020 Derecho

The photos I saved of damage from our August 2020 Derecho, in a images-summittdweller/2020-Aug-10-Derecho bucket, are rather depressing and certainly don’t need to be super high-res for the web, so let’s retrieve those and practice this workflow there first.

The quick reference linked above says to use a command of the form s3cmd get s3://spacename/path/ --recursive to get all files from a particular folder. In my case, that’s…

╭─mark@Marks-Mac-Mini ~/Downloads/2020-derecho-photos
╰─$ s3cmd get s3://images-summittdweller/2020-Aug-10-Derecho/ --recursive

WARNING: Empty object name on S3 found, ignoring.
download: 's3://images-summittdweller/2020-Aug-10-Derecho/Derecho - 1.png' -> './Derecho - 1.png'  [1 of 82]
 23486944 of 23486944   100% in    1s    21.04 MB/s  done
download: 's3://images-summittdweller/2020-Aug-10-Derecho/Derecho - 10.png' -> './Derecho - 10.png'  [2 of 82]
 20861132 of 20861132   100% in    0s    23.45 MB/s  done
...
download: 's3://images-summittdweller/2020-Aug-10-Derecho/Photo-2020-08-20-19-51.jpeg' -> './Photo-2020-08-20-19-51.jpeg'  [81 of 82]
 6277783 of 6277783   100% in    0s    16.86 MB/s  done
ERROR: Creation of file './for-the-web/' failed (Reason: Is a directory)

Ok, 81 images downloaded. That was sooooooooo much better than the 1000-or-so clicks it would have taken to do that manually! The only gottcha… that last error message about not downloading the for-the-web directory, which is currently empty anyway. Before I go farther, I’m going to open that DigitalOcean Spaces bucket and change the errant directory name to web-ready; that’s where my “thumbnail” copies of all these images will be uploaded shortly.

Next Step, Resize Those Images

I found some concise and timely advice in the first web post I Googled: How to quickly resize multiple images at once on Mac. It uses exactly the tool I had in mind, the Mac-native Preview app.

Before begining that process I wanted to see just how much space my 81 images occupy, like so:

╭─mark@Marks-Mac-Mini ~/Downloads/2020-derecho-photos
╰─$ du -sh
2.7G	.

2.7G isn’t all that much, but it’s still much bigger than it needs to be. I’m firing up Preview now to see if I can reduce all images proportionally to a maximum width of 800 pixels. Be back in a couple of minutes…

Drum roll please…

╭─mark@Marks-Mac-Mini ~/Downloads/2020-derecho-photos
╰─$ du -sh
163M	.

Not bad at all. Only took a couple of minutes and it reduced the total image size from 2.7G down to 163M. Not too shabby.

Uploads Complete… Next?

In order to upload the resized images back to DigitalOcean Spaces, I simply used the nice graphical interface available to me at https://cloud.digitalocean.com/spaces/images-summittdweller?path=2020-Aug-10-Derecho%2Fweb-ready and the Upload option there. It worked nicely, but for whatever reason two of the images failed to upload: Derecho - 38.png and Derecho - 39.png. After a little review, and retries, I could not figure out why these wouldn’t upload but that’s OK because they are both largely redundant with Derecho - 40.png, so we’ll just stick with that one.

So, in the original folder image Derecho - 1.png has an endpoint of https://images.summittdweller.com/2020-Aug-10-Derecho/Derecho%20-%201.png. Makes sense. In my new web-ready directory the reduced-size copy of the same image naturally has an endpoint of https://images.summittdweller.com/2020-Aug-10-Derecho/web-ready/Derecho%20-%201.png. Fortunately, that’s a “match” except for the addition of the web-ready subdirectory in the path. Exactly what I hoped would happen.

This means the next step is to…

Alter Content to Include the `web-ready` Path

I used the admin search (magnifying glass) feature of the Ghost instance behind this blog to find all references to https://images.summittdweller.com/2020-Aug-10-Derecho and it found: NOTHING. Yikes. Turns out all of the references were in one post, and it was draft. So I edited the draft “manually” and published it. Now let’s try that search again… NOPE. So, the text inside those figure tags evidently isn’t discoverable. ☹️ Just as well since I think a different approach is needed.

Not `web-ready`, `originals`

Since editing the content (posts) to pick up the new web-ready directory is a royal pain, what I’m going to do now is create a new originals sub-directory in each bucket, download all the images, resize them locally as I did above, but replace the existing high-resolution images with the smaller copies AFTER I make a backup the original images in a new originals directory. That way I don’t have to edit any of my posts in order to get the smaller web-ready images, but I won’t lose the originals either. Beautimous.

Belay That Order!

While I’m confident this approach (above) will work, it may not be necessary. I looked, for example, in images-summittdweller/Norway-Photos-2019/Bergen - Hordaland, June 19, 2019 expecting to find some large images, but there were none over 800px in width. In fact, I believe they are all under 640px wide, so nothing to do there, and that’s a good thing.

That’s All Folks

A detailed search of images-summittdweller didn’t turn up any more enromous images that might get pushed to the web, so… “That’s All Folks”, for now at least.

Debugging This Blog with VSCode

Mark McFate — Tue, 04 Apr 2023 16:31:07 +0000

I’m making some significant changes to the code behind this blog today. Specifically, I’m going to move my micropost “front matter” from the post.excerpt or post.custom_excerpt field to the “body” of the post where it might look like this example (taken from this very post):

-+-+-+
location: Toledo, IA
price: $50.00
note: This is just some sample "front matter". My parser removed the "split" characters from the delimiter you see here.

I Need VSCode Debugging!

To do this effectively I really need live dev debugging in VSCode, but how can I do that?

Well, I turned first to Tips for debugging in 11ty by George Griffiths because it looked very promising. In the second half of that post under the heading of Debugging with VS Code there are instructions for creating a .vscode/lanuch.json to do this, and I did. But how does one “attach” their debugger to the script I use to launch/test this blog locally? That command by the way is yarn start.

My Debugger Configuration

So, I found that the stock launch.json prescribed by George didn’t quite work in my situation, I had to add a configuration AND with a small change, and turn off Auto Attach debugging.

I clicked on the debugger icon in the left-hand pane of my VSCode window and there I had the option to add a configuration. I clicked that and was presented with several choices. After incorrectly trying a few options I settled on one labeled Run Script&colon; start and it almost worked.

The configuration added to my launch.json file included "command"&colon; "yarn run start", but that’s not quite right for me. I simply use yarn start to launch my local dev instance of this blog, so I made that change to lanuch.json so that file now reads:

{
  "name": "11ty",
  "type": "node",
  "request": "launch",
  "program": "${workspaceRoot}/node_modules/.bin/eleventy",
  "stopOnEntry": false,
  "args": [],
  "cwd": "${workspaceRoot}",
  "console": "internalConsole",
  "configurations": [
    {
      "type": "node-terminal",
      "name": "Run Script: start",
      "request": "launch",
      "command": "yarn start",
      "cwd": "${workspaceFolder}"
    }
  ]
}

It Works!

Now when I open the debugger and click the green start arrow beside Run Script: start I can see .eleventy.js begin running and it stops at any breakpoints I have set. It even works when stepping into my custom.js script, all the while showing me the call stack and variables that are in-scope at the time. Yay!

Thank You George!

Wait, There’s More

Even better news is that I can still run yarn start locally without involving the debugger. Nice.

-/-/-/

location: Toledo, IA

price: $50.00

note: This is just some sample “front matter”.

Finale Workflow Documentation

Mark McFate — Wed, 08 Feb 2023 00:00:00 +0000

Mackenzie, my daughter, and I created this post documenting my wife’s Finale workflow for scanning and editing music on her Mac. We did this for my wife to ~~celebrate her birthday~~ preserve her sanity. Well, it was worth a shot. The birthday idea seemed more romantic, but mental health comes first.

The document was created using a process we recently built and documented in Creating Better Documentation. In this instance of the process we tried to annotate in yellow screen capture elements that need attention, and used red annotation to indicate things that require input or action of some kind. In some of the later images we failed and things that should be red were left highlighted in yellow. Sorry.

Begin by Scanning

The first step involved launching the Canon MF Scan Utility as you see below. This is the software she uses to scan music pages on the multi-function scanner attached to her Mac.

Launch the Canon MF Scan Utility

We verified that the correct scanner is selected, loaded the score into the scanner*, and clicked Custom to begin the scan. Then, wait for the scanner to warm up, if necessary.

*Note that the sheet music can be placed on the scanner glass one-sheet-at-a-time, or if the pages are 8.5x11, one-sided, and in good condition, they may be loaded in the document feeder to scan continuously. In this particular case we were able to use the document feeder.

Select Custom scanning

Waiting for the scanner to warm up

Once the scanner is ready the mechanical process of scanning should begin. When scanning one-page-at-a-time some user intervention will be required.

Scanning in progress

When the scan is complete a Save Settings window should pop-up. We reviewed the information and made appropriate selections where noted below, then clicked OK to continue. Be sure to set and take note of the File Name: and Save in: fields! Also, it’s probably wise to ensure that the Data Format: is “TIFF” and the Save to a subfolder with current date control is checked.

Save scan settings

SmartScore 64 Pro

A SmartScore 64 Pro window will automatically open, but don’t be confused, we don’t want to run this application yet! Click the Cancel button to close SmartScore 64 Pro.

SmartScore Pro launches automatically but needs to be closed

Once SmartScore 64 Pro is closed, we need to open it properly by clicking its icon in the dock. 😦

Properly launching SmartScore

Now SmartScore is open to the Task Window where we selected Recognition to convert the scanned images to music XML.

Starting the SmartScore recognition process

Next, we add the files of our scanned pages to the recognition processing list.

Add scans to SmartScore recognition

In the file dialog we navigate to the scanned page TIFFs and select them all. The order of files in the selection is NOT critical. With all files selected click Open.

Navigate to the scan files and select them

The next Begin Recognition screen offers controls to change the file order if necessary. Once the files are in the proper order click Begin Recognition button to proceed.

Order the TIFFs and begin recognition

Be patient, the recognition process may take a few minutes.

Recognition in progress

When the recognition is complete a System Report appeared prompting us to Open SmartScore file. We did.

SmartScore system report

Next, the Unify Score window popped up and we verified the default selections shown below before clicking OK.

Unify score pop-up

When prompted to save the score be sure to select Music XML (*.xml) and take note of where the file will be saved.

Saving as XML

You may be prompted to save each scan/file individually. Once the file save is confirmed you can close SmartScore 64 Pro.

Confirm save and close SmartScore

Finale

Next, open Finale from the dock as shown below.

Open Finale

After a minute or more the Finale Launch Window should appear, and we selected IMPORT MUSICXML as shown below.

Selecting IMPORT MUSICXML

We navigated to the XML file that was saved in SmartScore and clicked Open to load it in Finale.

Opening the saved MusicXML file

That’s it, the scanned score is now loaded in Finale where it is ready to be edited! It’s a good idea to click Save As... routinely to save your changes as you proceed.

Save your Finale work

Gating My Content

Mark McFate — Mon, 30 Jan 2023 14:45:01 -0600

Gating Content in JAMstack Sites

This section’s title was borrowed from a Stackbit article with the same title, Gating Content in JAMstack Sites. Working through that article to password protect some of the content at https://Wieting.TamaToledo.com is my tech pursit today.

Nope, Not on Netlify

😦 Last evening I took a shot at implementing the Netlify Identity tricks from the aforementioned article, but could not easily get it to work. The problem, I think, is that the https://Wieting.TamaToledo.com on Netlify already uses Netlify Identity for authentication of my Netlify CMS forms, and adding a second, separate instance of that service isn’t trivial and perhaps isn’t even feasible. I also tried implementing some quick Staticrypt CLI protection but that also failed. Netlify does provide a really quick and painless solution, but it costs $20/month, at a minimum, to enable it.

New Staticrypt Strategy?

So, my next shot at this will involve creating a new Eleventy site just for the Wieting’s protected content. Wish me luck and follow along here if you like.

Trying Azure DevOps

I recently created a personal Azure account, registered to summitt.dweller@gmail.com, and last evening (January 31, 2023) I took a dive into Azure DevOps under that account. The “welcome” email that I received says I now have an “organization” URL at https://dev.azure.com/summittdweller.

I jumped into Azure DevOps because it looks like within that environment I can establish a Content Management System (CMS) not unlike the NetlifyCMS (or perhaps it IS NCMS) that I run for the Wieting Theatre, hosted with Netlify.com. I really like NetlifyCMS, but thus far I’ve had limited success with it, and ONLY at Netlify.com where the user authentication process is nicely streamlined. I hope that Azure DevOps has user authentication that’s just as easy to manage, and at less cost.

So, I guess the strategy now is to see what Azure DevOps has to offer, rather than venturing further with Staticrypt.

That’s a TEMPORAY wrap, this post isn’t finished just yet.

Fixing a Broken GitHub Repo

Mark McFate — Thu, 19 Jan 2023 13:30:13 -0600

Don’t Push Enormous Files to GitHub!

Pay close attention to the subtitle above! A couple of days ago I was working on content for Tama-Toledo Community Visioning and I added a large socialmedia.zip file to the source repo, and then very stupidly pushed it to GitHub and the repo’s main branch. Naturally, the push didn’t finish so I removed the file and pushed a new commit to “remove it permanently”. Well, that ain’t how git works!

The “remove” commit appeared to have worked, but now the TTCV site wouldn’t deploy since the build time had gone from less than 2 minutes, to more than 10 minutes. I immediately became suspicious of that pesky, large, socialmedia.zip file, but how could I properly get rid of it?

Using `git filter-repo`

Fortunately, I found and followed the GitHub docs guidance in Using git filter-repo to remove the troublesome large file, namely socialmedia.zip, from the repo. My commands, and somewhat abridged output, to do this looked something like this…

╭─mark@Marks-Mac-Mini ~/GitHub/cv ‹main*› ╰─$ git status On branch main Your branch is up to date with 'origin/main'.

Untracked files:
(use “git add …” to include in what will be committed)
static/images/Business-30-Broadway-Crosswalk-Sign.png

nothing added to commit but untracked files present (use “git add” to track)
╭─mark@Marks-Mac-Mini ~/GitHub/cv ‹main*›
╰─$ code .
╭─mark@Marks-Mac-Mini ~/GitHub/cv ‹main*›
╰─$ brew install git-filter-repo
Running brew update --auto-update…
==> Auto-updated Homebrew!
==> Updated Homebrew from 3.6.19 (260ee0ee6) to 3.6.20 (344d32bf7).
Updated 3 taps (homebrew/core, homebrew/cask and dart-lang/dart).
==> New Formulae
dstack
==> New Casks
codux

The 3.6.20 changelog can be found at:
https://github.com/Homebrew/brew/releases/tag/3.6.20
==> Fetching git-filter-repo
==> Downloading https://ghcr.io/v2/homebrew/core/git-filter-repo/manifests/2.38.0-1 ######################################################################## 100.0%
==> Downloading https://ghcr.io/v2/homebrew/core/git-filter-repo/blobs/sha256:a309651d195fca608c9268b7075f58e018e83fc285e4f43d85546adea28e1d83
==> Downloading from https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:a309651d195fca608c9268b7075f58e018e83fc285e4f43d85546adea28e1d83?se=2023-01 ######################################################################## 100.0%
==> Pouring git-filter-repo–2.38.0.all.bottle.1.tar.gz
🍺 /usr/local/Cellar/git-filter-repo/2.38.0: 8 files, 281.4KB
==> Running brew cleanup git-filter-repo…
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see man brew).
╭─mark@Marks-Mac-Mini ~/GitHub/cv ‹main›
╰─$ git pull
remote: Enumerating objects: 7, done.
remote: Counting objects: 100% (7/7), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 4 (delta 2), reused 4 (delta 2), pack-reused 0
Unpacking objects: 100% (4/4), 78.90 KiB | 1022.00 KiB/s, done.
From https://github.com/Tama-Toledo/community-visioning
978a2cd..23b4276 gh-pages -> origin/gh-pages
Already up to date.
╭─mark@Marks-Mac-Mini ~/GitHub/cv ‹main›
╰─$ code .
╭─mark@Marks-Mac-Mini ~/GitHub/cv ‹main›
╰─$ cd ..
╭─mark@Marks-Mac-Mini ~/GitHub
╰─$ mv -f cv .out-of-the-way
╭─mark@Marks-Mac-Mini ~/GitHub
╰─$ git clone https://github.com/Tama-Toledo/community-visioning
Cloning into ‘community-visioning’…
remote: Enumerating objects: 3738, done.
remote: Counting objects: 100% (882/882), done.
remote: Compressing objects: 100% (307/307), done.
remote: Total 3738 (delta 488), reused 776 (delta 388), pack-reused 2856
Receiving objects: 100% (3738/3738), 119.72 MiB | 29.18 MiB/s, done.
Resolving deltas: 100% (1932/1932), done.
╭─mark@Marks-Mac-Mini ~/GitHub
╰─$ cd community-visioning
╭─mark@Marks-Mac-Mini ~/GitHub/community-visioning ‹main›
╰─$ ll
total 16
-rw-r–r– 1 mark staff 36B Jan 19 16:24 README.md
drwxr-xr-x 4 mark staff 128B Jan 19 16:24 archetypes
drwxr-xr-x 3 mark staff 96B Jan 19 16:24 assets
-rw-r–r– 1 mark staff 3.5K Jan 19 16:24 config.toml
drwxr-xr-x 9 mark staff 288B Jan 19 16:24 content
drwxr-xr-x 3 mark staff 96B Jan 19 16:24 i18n
drwxr-xr-x 8 mark staff 256B Jan 19 16:24 layouts
drwxr-xr-x 3 mark staff 96B Jan 19 16:24 resources
drwxr-xr-x 6 mark staff 192B Jan 19 16:24 static
drwxr-xr-x 3 mark staff 96B Jan 19 16:24 themes
╭─mark@Marks-Mac-Mini ~/GitHub/community-visioning ‹main›
╰─$ code .
╭─mark@Marks-Mac-Mini ~/GitHub/community-visioning ‹main›
╰─$ git filter-repo –invert-paths –path socialmedia.zip
╭─mark@Marks-Mac-Mini ~/GitHub/community-visioning ‹main›
╰─$ git remote add origin https://github.com/Tama-Toledo/community-visioning
╭─mark@Marks-Mac-Mini ~/GitHub/community-visioning ‹main›
╰─$ git push origin –force –all
╭─mark@Marks-Mac-Mini ~/GitHub/community-visioning ‹main›
╰─$ git status
On branch main
Your branch is up to date with ‘origin/main’.

nothing to commit, working tree clean
╭─mark@Marks-Mac-Mini ~/GitHub/community-visioning ‹main›
╰─$ git pull
╭─mark@Marks-Mac-Mini ~/GitHub/community-visioning ‹main›
╰─$ git branch –set-upstream-to=origin/main main

The key commands in that sequence are…

brew install git-filter-repo
git clone https://github.com/Tama-Toledo/community-visioning
- The above command was necessary because the next command expects a “clean”, recently compressed local repository.
git filter-repo –invert-paths –path socialmedia.zip
git remote add origin https://github.com/Tama-Toledo/community-visioning
git push origin –force –all
git branch –set-upstream-to=origin/main main

It Worked!

The good news, this worked, and I now have my repo back in shape such that I can successfully deploy it again.

That’s a wrap. Oh, in case you want to know what happened to socialmedia.zip, check out that project’s README.md file.

My Hugo Timeline, A New Hugo Module

Mark McFate — Tue, 06 Dec 2022 13:30:13 -0600

What follows is an excerpt from this blog’s README.md file.

I’ve successfully added the code to drive a new /timeline page as part of this blog, but I did so “locally”, and now I’d like to repeat the process but using the aforementioned SummittDweller/hugo-timeline module.

I used guidance found in Hugo Modules: Getting Started to make this happen, like so:

╭─mark@Marks-Mac-Mini ~/GitHub/blogs-SummittDweller ‹main› 
╰─$ brew install go
╭─mark@Marks-Mac-Mini ~/GitHub/blogs-SummittDweller ‹main› 
╰─$ brew upgrade   # This is not "required", but probably overdue.

╭─mark@Marks-Mac-Mini ~/GitHub/blogs-SummittDweller ‹main*› 
╰─$ mkdir content/timeline/.out-of-the-way      # vvv Moving existing local stuff out of the way vvv
╭─mark@Marks-Mac-Mini ~/GitHub/blogs-SummittDweller ‹main*› 
╰─$ mv -f layouts/partials/hugo-timeline* content/timeline/.out-of-the-way/.   
╭─mark@Marks-Mac-Mini ~/GitHub/blogs-SummittDweller ‹main*› 
╰─$ mv -f layouts/shortcodes/hugo-timeline* content/timeline/.out-of-the-way/.
╭─mark@Marks-Mac-Mini ~/GitHub/blogs-SummittDweller ‹main*› 
╰─$ mv -f static/css/hugo-timeline* content/timeline/.out-of-the-way/.        

╭─mark@Marks-Mac-Mini ~/GitHub/blogs-SummittDweller ‹main*› 
╰─$ hugo mod init github.com/SummittDweller/blogs-SummittDweller        
go: creating new go.mod: module github.com/SummittDweller/blogs-SummittDweller
go: to add module requirements and sums:
        go mod tidy

Next, to pull in SummittDweller/hugo-timeline as a module I turned to the config.yml file and guidance found in Hugo Modules: everything you need to know!. Additions to config.yml are:

module:
  imports:
    - path: github.com/SummittDweller/hugo-timeline
      mounts:
      - source: layouts
        target: layouts
      - source: static
        target: static

Updating the Module

So, all of the above moves appeared to work correctly, at least locally, but I wanted to be sure I can successfully update the hugo-timeline module and get updated behavior in this project. The command required to make that happen per Hugo Modules: everything you need to know! is:

╭─mark@Marks-Mac-Mini ~/GitHub/blogs-SummittDweller ‹main*› 
╰─$ hugo mod get -u github.com/SummittDweller/hugo-timeline
go: downloading github.com/SummittDweller/hugo-timeline v0.0.0-20221206191252-cd7178e7e43b
go: upgraded github.com/SummittDweller/hugo-timeline v0.0.0-20221206043330-5f1ecbad913f => v0.0.0-20221206191252-cd7178e7e43b

╭─mark@Marks-Mac-Mini ~/GitHub/blogs-SummittDweller ‹main*› 
╰─$ hugo server
port 1313 already in use, attempting to use an available port
Start building sites … 
hugo v0.107.0+extended darwin/amd64 BuildDate=unknown

                   | EN   
-------------------+------
  Pages            | 288  
  Paginator pages  |   9  
  Non-page files   |   0  
  Static files     |  38  
  Processed images |   0  
  Aliases          |  79  
  Sitemaps         |   1  
  Cleaned          |   0  

Built in 90 ms
Watching for changes in /Users/mark/GitHub/blogs-SummittDweller/{archetypes,content,layouts,static,themes}
Watching for config changes in /Users/mark/GitHub/blogs-SummittDweller/config.yaml, /Users/mark/GitHub/blogs-SummittDweller/go.mod
Environment: "development"
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at //localhost:62846/ (bind address 127.0.0.1)
Press Ctrl+C to stop

Eureka! The page rendered at http://localhost:1313/timeline/ after the above hugo mod get -u... command is displaying the latest changes I made to hugo-timeline! Perfect!

My work here is done, well, for now anyway. 😁

How MY Web Works

Mark McFate — Wed, 30 Nov 2022 17:45:11 -0600

I’ve been building websites and apps for a lot of years now, and over time I’ve used a plethora of different frameworks and tools to do so. I’ve also involved a number of registrars, DNS strategies, source code repositories, and web hosts… frankly too many to remember or even count.

In my old age I’d love to have a dynamic document, or two, where I can track things like this:

For Websites:

the site’s purpose
the site’s address and aliases
the domain registrar
the DNS host and site’s record structure

For Apps:

the application’s purpose
the application’s web address (if deployed to the web)
a link to the application’s user guide or instruction

For Both Sites and Apps:

the programming language(s) used
the location of the code repository
a link to development and deployment guidance

Mackenzie’s Project

I feel like I’m a little too close to this material and perhaps my memory is clouded by too much outdated documentation to accurately determine where things stand today. So, I’m asking my daughter, Mackenzie, to look at the artifacts I can provide and piece together this document for me.

Some Background Research

I’ll start by asking Mackenzie to find, share, and document some resources to help her understand how to identify and document the working parts of my sites and apps… discovering how the web works, and more.

Let’s begin with a short list of documents/pages to help in that regard:

Some “formal” educational materials:

How to Deploy a Website

The Derecho: Consolidated Posts and Microposts: August 10 thru September 6, 2020

Mark McFate — Sun, 25 Sep 2022 20:12:49 +0000

The following is a chronological consolidation of posts and microposts from August 10, commonly known in east and central Iowa as “The Day of the Derecho”, through September 6, 2020.

The derecho hit my home in Toledo, Iowa, at about 11:30 AM on Monday, August 10, 2020. Straight-line winds were clocked at nearly 140 miles per hour, and sustained for more than 20 minutes across a path almost 40 miles wide.

The power is still out here, almost 10 days after the derecho knocked it out. So many power restoration predictions have come and gone, I’ve lost count. Still I’m told that what we need is a one-man, 15-minute fix. Perhaps in the morning I’ll stretch our broken power line across the street and pitch a tent next door until an Alliant truck stops and gets this done. I know they are busy, but 15 minutes of one lineman’s time a week ago, when it was first “promised”, would have been so nice. I fixed my own Mediacom connection more than a week ago, and there’s evidence tonight that their service has been restored. So, if I had power, I think we would also have TV and internet. IF.

→ 2020/08/19 11:45 PM

  posted from Toledo, IA

It’s the start of day number eleven, and still no power. Checked the forecast and it’s getting hot…so am I!

→ 2020/08/20 8:21 AM

  posted from Toledo, IA

Eleven days and seven hours without, but the power is now back on at 104 W. Summit Street in Toledo. I’d estimate that for the duration we burned about 105 gallons of gas just to keep the fridge, my CPAP, one lamp, and two fans running. Glad to be back in the 21st century. Now, what’s all this I hear about a deadly virus and some political scuffles?

→ 2020/08/20 7:48 PM

  posted from Toledo, IA

Iowa's 2020 Hurricane

Posted on 2020/08/20 10:18 PM

  from Toledo, Iowa

Derecho Follow-Up - Saturday, August 22

Posted on 2020/08/22 9:45 PM

  from Toledo, Iowa

And so begins day number 11 without power. I think I have watched at least a dozen Alliant energy trucks Drive by the house already this morning. I honestly don’t think they know where we are.

→ 2021/08/21 9:28 AM

  posted from Toledo, IA

Today, Sunday, August 23, 2020, marked the start of what looks like another schorching heat-wave here. So I pitched in during the morning at the home of my “scurry” partners Jeff and Mary Fasse-Shaw, to help with cutting up some of the deadfall along the creek on the west side of their property. We got a good start, but there’s a lot of fallen timber to be cleared there!

→ 2020/08/23 5:33 PM

  posted from Toledo, Iowa

Tama-Toledo Parks - Derecho Follow-Up for August 24

Posted on 2020/08/24 11:20 AM

  from Toledo, Iowa

Last of the Clean-up? - Derecho Follow-Up for September 6

Posted on 2020/09/06 7:52 PM

  from Toledo, Iowa

August 2022 - Geocaching's 20th Anniversary Celebration Event

Mark McFate — Sun, 25 Sep 2022 19:55:13 +0000

The following is a chronological consolidation of posts and microposts from August 6 through August 25, 2022.

Westbound to Seattle - Day 1

Posted on 2022/08/07 4:57 PM

  from Toledo, IA

Westbound to Seattle - Day 2

Posted on 2022/08/07 4:58 PM

  from Toledo, IA

Westbound to Seattle - Day 3

Posted on 2022/08/07 4:58 PM

  from Toledo, IA

Eastbound from Seattle - Day 1

Posted on 2022/08/07 9:13 PM

  from Toledo, IA

Eastbound from Seattle - Day 2

Posted on 2022/08/08 1:39 PM

  from Toledo, IA

Eastbound from Seattle - Day 3

Posted on 2022/08/08 2:44 PM

  from Toledo, IA

Waiting for my ride to Johnston.

→ 2022/08/12 7:37 AM

  posted from Toledo, IA

Departed for Seattle a few minutes after 6 AM.

→ 2022/08/16 6:14 AM

  posted from Montour, IA

Lunch at Culver’s in Brookings, SD.

→ 2022/08/16 11:52 AM

  posted from Brookings, SD

Got my first North Dakota geocache find a few miles back down the road.

→ 2022/08/16 2:18 PM

  posted from Wahpeton, ND

Passing through the outskirts of metropolitan Fargo.

→ 2022/08/16 3:10 PM

  posted from West Fargo, ND

Headed west across North Dakota for GC 551, the state’s oldest active geocache.

→ 2022/08/16 5:24 PM

  posted from Steele, ND

Arrived for the night around 9:25 pm in Miles City, Montana, about 70 miles past our intended stop.

→ 2022/08/16 9:52 PM

  posted from Miles City, MT

First cache of the day: Headed to GCHGZZ in a rest area in Montana.

→ 2022/08/17 6:43 AM

  posted from Rosebud, MT

GCKHRJ: Was not on our original list but a really quick stop and well worth the time out.

→ 2022/08/17 9:46 AM

  posted from Big Timber, MT

Just departed from the headwaters of the Missouri river state park in Montana and the state’s oldest pair of geocaches. Check my track logs on https://hikes.summittdweller.com for more details.

→ 2022/08/17 1:21 PM

  posted from Headwaters of the Missouri River, Montana

Stopped for dinner in Coeur d’Alene at Rogers Ice Cream and Burgers.

→ 2022/08/17 6:13 PM

  posted from Coeur d&#39;Alene, ID

Excellent company for the reviewers lunch after the APE geocache at Snoqualmie Pass, Washington.

→ 2022/08/18 2:32 PM

  posted from Snoqualmie Pass, WA

Relaxing and catching up in the hotel (the Maxwell near the Space Needle) after a great day of geocaching, hiking (10 miles or more) and lite travel.

→ 2022/08/18 9:46 PM

  posted from Seattle, WA

No time to blog! Attending the Geocaching 20th Celebration.

→ 2022/08/20 10:38 AM

  posted from Seattle, WA

Southbound on I5 to the Original Stash SE of Portland.

→ 2022/08/21 5:55 AM

  posted from Tukwila, WA

Grabbing a quick lunch at McDonald’s.

→ 2022/08/21 1:59 PM

  posted from Madras, OR

The apex of an epic road-trip!

→ 2022/08/21 7:11 PM

  posted from Davis Creek, CA

Winnemucca ETA is 11:35pm. Never have I seen so many stars.

→ 2022/08/21 10:09 PM

  posted from Denico Junction, NV

Tom’s reaction when we popped over the hill to see the Bonneville salt flats was “holy shit”.

→ 2022/08/22 11:22 AM

  posted from West Wendover, NV

Posting an updated itinerary for eastbound day 3.

→ 2022/08/22 7:22 PM

  posted from Rawlins, WY

Planning a lunch stop in Grand Island with Heartland Cacher and then on home to Iowa so Reviewer Smith can get back to Illinois this evening.

→ 2022/08/23 8:42 AM

  posted from North Platte, NE

Proper Python

Mark McFate — Sat, 24 Sep 2022 14:26:44 -0500

What follows is the README.md file from my GitHub repo where https://blog.summittdweller.com is built. It outlines how to “properly” add Python to a project such that we can create an easily reproducible “virtual environment” without storing the necessary Python libraries in GitHub.

From the README.md…

# blogs-SummittDweller

The Python portions of this repo were gleaned from https://github.com/SummittDweller/hikes. This is the repo for my https://blog.SummittDweller.com/ static website.

Latest Python Improvements

Using guidance at https://predictivehacks.com/how-to-work-with-vs-code-and-virtual-environments-in-python/ I successfully created a new .venv virtual environment. The commands I used to do this were…

╭─mark@Marks-Mac-Mini ~/GitHub/blogs-SummittDweller ‹main*›
╰─$ python3 -m venv .venv

╭─mark@Marks-Mac-Mini ~/GitHub/blogs-SummittDweller ‹main*›
╰─$ source .venv/bin/activate

(.venv) ╭─mark@Marks-Mac-Mini ~/GitHub/blogs-SummittDweller ‹main› 
╰─$ pip3 freeze > python-requirements.txt

(.venv) ╭─mark@Marks-Mac-Mini ~/GitHub/blogs-SummittDweller ‹main*›
╰─$ pip3 install -r python-requirements.txt

Then I used COMMAND-SHIFT-P to select and Python: Select interpreter to choose the new .venv Python. After that…

(.venv) ╭─mark@Marks-Mac-Mini ~/GitHub/blogs-SummitDweller ‹main*›
╰─$ python3 consolidate.py --start 20220806 --end 20220825

(.venv) ╭─mark@Marks-Mac-Mini ~/GitHub/blogs-SummitDweller ‹main*›
╰─$ hugo server

Rebuilding a Local Environment

Based on guideance from https://stackoverflow.com/questions/6590688/is-it-bad-to-have-my-virtualenv-directory-inside-my-git-repository I’ve reconstructed this project such that Python artifacts do NOT propogate into Github.

The project should automatically “rebuild” as necessary when opened in VSCode, but if the Python virtual environment needs to be recreated use…

source .venv/bin/activate && pip3 install -r python-requirements.txt

Deployment via DigitalOcean

In order to deploy this starter static app on DigitalOcean I had to PERMANENTLY move all of my Python components (.py scripts and requirements.txt) to a .python directory to hide it from view during app creation. Before moving these elements DigitalOcean would consistently try to deploy my app as Python, and that’s not right.

See DigitalOcean ticket [#06849069] Hugo static site with Python components builds fail for details.

The response I received from DigitalOcean…

Hello,

Thanks for contacting DigitalOcean.

We appreciate you reaching out to us about your Hugo static site. From what you mentioned it does sound like your app is getting detected as a python webservice rather then a static site due to the requirements.txt file you had in the root of your repo.

Unfortunately this is currently what App platform uses to detect applications as python apps. Either having a requirements.txt file or a setup.py file will cause that detection. Our engineers are looking into options to specify the build pack used rather then relying upon the auto detection, which would address this issue in your case, but don’t have a timeline yet for implementing it.

In the mean time the work around that you have specified here should work fine for this. It should cause the app to be detected as a static site rather then python. Hopefully it isn’t impacting anything else in your app’s build process.

If you have any questions, please let us know.

Regards, Nate Senior Cloud Support Engineer Check out our community for great tutorials, articles and FAQs! digitalocean.com/community

ref:_00Df218t5m._5004P21l4JM:ref

Remedy

Based on the response above I’m making final changes to eliminate the .python folder, renaming .python/requirements.txt as python-requirements.txt, and pulling all other contents of .python into the root of the project.

Eastbound from Seattle - Day 3

Mark McFate — Mon, 08 Aug 2022 14:44:03 -0500

Day 3 - Laramie, WY to Grinnell, IA

This is our planned route for Day 3 (eastbound) using a speed factor of 1.0 (traveling at the speed limit). Fuel cost is based on 40 mpg and $4.00 per gallon averages. Fuel stops typically have a 15-minute duration and rest areas allow 5-minutes each.

A list of possible geocache targets for the entire route can be found at https://www.geocaching.com/play/map/lists/BMBBMD6.

Eastbound from Seattle - Day 2

Mark McFate — Mon, 08 Aug 2022 13:39:47 -0500

Day 3 - Lakeview, OR to Laramie, WY

This is our planned route for Day 2 (eastbound) using a speed factor of 1.0 (traveling at the speed limit). Fuel cost is based on 40 mpg and $4.00 per gallon averages. Fuel stops typically have a 15-minute duration and rest areas allow 5-minutes each.

A list of possible geocache targets for the entire route can be found at https://www.geocaching.com/play/map/lists/BMBBMD6.

Eastbound from Seattle - Day 1

Mark McFate — Sun, 07 Aug 2022 21:13:11 -0500

Day 1 - Seattle, WA to Lakeview, OR

This is our planned route for Day 1 (eastbound) using a speed factor of 1.0 (traveling at the speed limit). Fuel cost is based on 40 mpg and $4.00 per gallon averages. Fuel stops typically have a 15-minute duration and rest areas allow 5-minutes each.

A list of possible geocache targets for the entire route can be found at https://www.geocaching.com/play/map/lists/BMBBMD6.

Westbound to Seattle - Day 3

Mark McFate — Sun, 07 Aug 2022 16:58:07 -0500

Day 3 - Moses Lake, WA to Seattle

This is our planned route for Day 3 using a speed factor of 1.0 (traveling at the speed limit). Fuel cost is based on 40 mpg and $4.00 per gallon averages. Fuel stops typically have a 15-minute duration and rest areas allow 5-minutes each.

A list of possible geocache targets for the entire route can be found at https://www.geocaching.com/play/map/lists/BMBBMD6.

Westbound to Seattle - Day 2

Mark McFate — Sun, 07 Aug 2022 16:57:53 -0500

Day 2 - Glendive, MT to Moses Lake, WA

This is our planned route for Day 2 using a speed factor of 1.0 (traveling at the speed limit). Fuel cost is based on 40 mpg and $4.00 per gallon averages. Fuel stops typically have a 15-minute duration and rest areas allow 5-minutes each.

A list of possible geocache targets for the entire route can be found at https://www.geocaching.com/play/map/lists/BMBBMD6.

Westbound to Seattle - Day 1

Mark McFate — Sun, 07 Aug 2022 16:57:10 -0500

Day 1 - Toledo, IA to Glendive, MT

This is our planned route for Day 1 using a speed factor of 1.0 (traveling at the speed limit). Fuel cost is based on 40 mpg and $4.00 per gallon averages. Fuel stops typically have a 15-minute duration and rest areas allow 5-minutes each.

A list of possible geocache targets for the entire route can be found at https://www.geocaching.com/play/map/lists/BMBBMD6.

Atom No More?

Mark McFate — Thu, 09 Jun 2022 09:14:39 -0500

Yesterday one of my library colleagues at Grinnell College posted an announcement that Atom would be retired (sunset) in December 2022. Ouch, I have a lot of workflows that depend on Atom!

So, today part of my mission is to begin the process of migrating workflows, both work-related and personal/at-home, from Atom to its most logical replacement, Visual Studio Code or VS Code as it’s largely known in the development community. The other part of today’s mission was to update this blog, something I’ve not done in far too long!

What better time to begin using VS Code than right now, to edit this blog post? So, that’s what I did, er, am doing.

This could be a long story, but I’ll keep it short and just share the links, mostly. I’ll begin on my personal Mac Mini, where I’m editing now, so I can test the entire process before repeating it on my other Mac workstations.

Install Using Homebrew

I like to use homebrew whenever possible to manage installations on my Mac. On this Mac Mini I found this Homebrew Formulae and put it to use… All done. Nice!

Adding a Command Line / Terminal Shortcut

I’ve gotten quite used to launching Atom in my working directory with a simple command of the form atom .. Can I do the same with VS Code? Sure! I used the guidance found in How to Open Visual Studio Code From Your Terminal to set that up. Piece of cake. I love finding timely, not stale, advice that just works!

Now I can simply navigate to a project folder on my Mac and type code . to open it all in VS Code. Sweet!

Replacing My Atom Packages

There are quite a few, nothing that I’ve written personally, but lots of published packages/extensions borrowed from others. That’s one of the things I love(d) about Atom. On my Mac Mini, and most other Macs, that list looks something like this:

I told you there were quite a few. I’m posting this image of my list just so I have a document as I begin to build the same into VS Code. Oh, when I added the above image to this post, I did so by dragging my screen-capture from my desktop directly into the VS Code EXPLORER panel (left side of my window), just like I used to do with Atom. Nice!

I’ll take my time and start replacing these as-needed. First up…

Replacing `ISO 8601 timestamp`

This Atom package allows me to add the current date and time, in ISO 8601 format, to the frontmatter of a blog post like the one you are reading now. I found and followed this documentation to set it up in VS Code. In Atom I put my cursor at the point where my timestamp was needed, and went to the Packages menu to insert it. In VS Code there doesn’t appear to be such a menu, but the documentation says I can use command-shift-P to open the “command pallette”, where I can scroll to or search for the command I want to engage. Another piece of cake!

The result of inserting the current timestamp should be reflected in the frontmatter of this blog post. 😀

More Goodies

This morning I updated this entry after adding a Duplicate file or directory command using the Duplicate Action extension from the marketplace. It works very nicely!

What’s could be better? Well, finding a list of 10 “must-have” VSCode extensions and working my way through them!

Luna Paint

I just stumbled across another handy VSCode extension, Luna Paint. I’ve installed it, took all of 2 minutes to update TWO Macs, using the guidance provided in this YouTube video. It rocks! 2022-07-19T10:07:39-05:00

With any luck I’ll be able to use this post to perform much the same configuration on my other Macs, soon. I promised I’d keep this long story short, so, until next time…

Moving to Netlify CMS

Mark McFate — Sun, 04 Apr 2021 20:14:08 -0500

In my last post, Adding Netlify CMS for Editing This Blog, I was able to successfully engage the Netlify CMS with a “local” copy of this blog. But I never got the CMS to work in production with this blog’s App on DigitalOcean (DO). I should note that DO’s support folks were very helpful, but in the end I think all of the client-side stuff that Netlify CMS is doing was more than they were willing (capable?) of helping me overcome. That’s probably my fault more than their’s; client-side isn’t my strong suit.

In the week since then I have, however, been able to stand up a new working copy of the Wieting Theatre website on Netlify.com, where it enjoys the same kind of automated builds and automatic deployment that I previously found at DO. The big difference, at Netlify.com my Netlify CMS depoloyment works locally AND in production, giving me the ability to allow content editors, even those who don’t have a Netlify.com or GitHub account, to do what they do best, edit their content.

The Wieting Theatre’s New Site, and the CRB

So this post started as a brain dump, chronicling how I got https://Wieting.Tama-Toledo.com to work. But, instead of hashing out how I “did” it, I’m going to show you how I’m doing something similar, for a site that features the Compass Rose Band, or CRB, my brother-in-law’s band out of Cedar Rapids, Iowa.

Netlify Identity

I think the real key to all of this is a Netlify.com agent called Netlify Identity. From the Netlify.com site and documentation…

_Netlify Identity_ service brings a full suite of authentication functionality, backed by the _GoTrue_ API. This allows you to manage and authenticate users on your site or app, without requiring them to be users of _Netlify_ or any other service. You can use this for gated content, site administration, and more.

In theory, Netlify Identity can be deployed anywhere, but in practice, setting it up can be quite tricky (at least it was for me). That’s where Netlify.com shines, and that’s understandable since they created both Netlify CMS and Netlify Identity. The two creations play well together, and make life easier for a devops like me. Well played indeed.

If you read my previous post you know that in a Hugo site, like this one, the ./static/admin/config.yml file holds all of your CMS info. If you host content on Netlify.com with Netlify CMS and Netlify Identity engaged, all you really need in that config file is something like this:

backend:
  name: git-gateway
  branch: main
...

The rest of the CMS “magic” takes place in a server-side access manager that you can find at your Netlify.com site folder at https://app.netlify.com/sites/[site-name]/identity. The client-side of the access/identity equation can be handled with an app template, and you can choose from many starter templates found at Start with a Template.

External OAuth without Netlify.com

If you wish to proceed without using Netlify.com as your host, you’ll find a number of options at External OAuth Client. Beware, this option isn’t for a server-side guy like me, and the Netlify.com option is quick, easy, and cheap… at least I think so.

Building a New Compass Rose Band Site on Netlify.com

Rather than rehashing the story of my Wieting Theatre migration to Netlify.com, I’m going to repeat that process and capture the journey while migrating our existing Compass Rose Band site from DO.

Using Netlify.com and `one-click-hugo-cms`

From the Start with a Template I clicked the Deploy to Netlify button under the ‘Hugo Site Starter’ option. This was super easy since Netlify.com already knows me… because I created a free account about a week ago. That selection took me to a screen where I was asked to identify a new Github repostory. Again, super easy because I had already logged in to Github earlier.

The default name for this new repository is one-click-hugo-cms, same as the template repository it will be built from. I choose to name my new repo compass-rose-band-one-click, for obvious reasons. That repository can be found at https://github.com/SummittDweller/compass-rose-band-one-click where the README.md file is titled “Hugo template for Netlify CMS with Netlify Identity”. The initial repository contents looked like this:

Replacing the `/site`

A default Hugo site is automatically built and deployed for you as part of the one-click process, and Netlify.com will supply an address so you can see your creation. But that’s not the Compass Rose Band! No problem, I found it quick and easy to replace the default template site by first cloning my new repo to my workstation, and replacing the /site directory with my own contents. It went like this…

cd ~/GitHub :left_arrow: This is where I keep local copies of all my GitHub projects.
git clone https://github.com/SummittDweller/compass-rose-band-one-click
cd compass-rose-band-one-click
git branch -m master main :left_arrow: Optional step, changes my local branch name to ‘main’.
rm -fr site/* :left_arrow: Remove the template site, the contents of /site.
cp -fr ~/GitHub/compass-rose-band/* site/. :left_arrow: Copy my local CRB site^* to /site.

^*Note that copying in the manner excludes all . files and directories, so the .git folder is NOT copied. This is IMPORTANT!

At this point, your old site has a new home in ./site so if you navigate there and do hugo server you should see a local instance of the site. Like so…

cd site
hugo server
Visit localhost:1313, or whatever localhost site is indicated, to see your site.

Pushing the Site to Github

So, now your Netlify.com project lives in a directory like my ~/GitHub/compass-rose-band-one-click, and the corresponding Hugo site contents are in the ./site folder there. To deploy this new copy of your site to Netlify.com simply do like this…

cd ~/GitHub/compass-rose-band-one-click
git add .
git commit -m "Now with CRB site contents in ./site"
git push -u origin main

Deploying the Site on Netlify.com

By default, pushing your changes to Github will automatically deploy them to your Netlify.com site, but you pushed to main, not master, so no synchornization is likely. But that’s easy to fix.

Navigate your browser to your Netlify.com “team” page, find your new project there, and click on Site Settings. Next you’ll see options for things like changing the name of your project and site. I changed mine to compass-rose-band-one-click to match my Github repo name.

Visit the Build & Deploy link in the menu on the left side of the page, find the Deploy contexts info and click Edit settings there so you can change the production branch setting from master to main. Leave the default setting of “Any pull request against your production branch / branch deploy branches” selected.

Next, visit the “Deploys” page in your Netlify.com project page at https://app.netlify.com/sites/[project-name]/deploys, mine is https://app.netlify.com/sites/compass-rose-band-one-click/deploys, and click the Trigger deploy button there. You should then see a log of the deployment as it runs, and this time it should target your new main branch with your updated ./site contents.

If successful you should see a screen featuring a block like this one:

Click on the Preview deploy ⬈ link and voilà, your site!

Now…Netlify CMS

It’s getting late on this Sunday night so I’ll share the first few lines from the latest copy of my new project’s ./site/static/admin/config.yml file for Netlify CMS.

backend:
  name: git-gateway
  branch: main

## To make local_backend mode work you must run 'npx netlify-cms-proxy-server' in its own terminal window
##   from the project root.  See https://www.netlifycms.org/docs/beta-features/ for details.
local_backend: true

media_folder: site/static/img    
public_folder: /img
...

What’s All That?

I’m back, as promised, and you’re probably asking what all that stuff in the config.yml file is doing? Well, as mentioned earlier, the simple backend: section (first three lines) links the CMS to the main branch of our new Github project. The rest isn’t required, unless you also want to use the CMS on a local clone of the project, like when making mass edits locally.

Let me try to explain.

`local_backend:` A Netlify CMS Beta Feature

If you visit the Netlify CMS’ Beta Features! pages you’ll see local_backend mentioned near the very top. [Note that as a beta feature this information is bound to move at some point.] That feature enables configuration of an option to make the CMS avaialble when working locally on a cloned, presumably, copy of the Github repository. The beta documentation mentions running npx netlify-cms-proxy-server as part of the process.

A Local Problem with `./site`? No, Not Really

So, in the local clone of my new Compass Rose Band one-click Hugo website, the “one-click” Netlify CMS parts live in the project’s root directory, and the Hugo site lives just “below” it in ./site. Accordingly my media_folder: setting shown above includes the site/ prefix, and the same is true of all the config.yml keys that end in folder:. This is correct for production, and it also works with a local clone IF I launch things correctly!

Hugo and the hugo server command that I need to preview local changes demands that I either cd site before I run it, or override the command’s path by specifying hugo server -s site. Only this 2nd approach works!

So the process that’s needed for local development and testing, including Netlify CMS looks like this for me:

If I don’t yet have the project locally I will begin with… cd ~/GitHub; git clone --recursive https://github.com/SummittDweller/compass-rose-band-one-click; cd compass-rose-band-one-click
If I already have a local clone I’ll do this… cd ~/GitHub/compass-rose-band-one-click; git pull

From here on out there’s just one process, like so…

npx netlify-cms-proxy-server :left_arrow: In a new terminal window. See next section of this post.
atom . :left_arrow: Launch Atom in the working directory.
hugo server -s site :left_arrow: Important: Don’t forget the -s site option!
Create and edit files as needed. Changes should be immediately visible in http://localhost:1313.
To edit or create content using Netlify CMS, just visit http://localhost:1313/admin/.
When all changes are complete…
- git add .
- git commit -m "a brief message here"
- git push

Requires npx, Part of Node.js

The npx command mentioned above requires that npx be installed, and it’s part of Node.js. To make it run properly I followed guidance from https://treehouse.github.io/installation-guides/mac/node-mac.html to ensure both were installed. In at least one instance I also had to run brew upgrade node and npm i -g npx to ensure that Node.js was up-to-date, and that npx was available as needed.

The npx netlify-cms-proxy-server, loads and runs the netlify-cms-proxy-server script, and in doing so it will tie up your terminal window. So, it’s best to do this in a separate terminal window! Don’t put the command in the background (using a & flag at the end) as this won’t allow you to see if the command is working properly. When you run this command you should see some feedback from the script indicating what it is doing. The script binds to your working directory then effectively routes all Netlify CMS actions, performed in this instance via http://localhost:1313/admin/, to the local git repo there.

Ok, Now We Need a Proper Domain

So, in its original form the Compass Rose Band site is aliased to three different domains:

I choose to try migrating these domains to the new Netlify.com site one-at-a-time, starting with the least-used domain, thecompassroseband.net.

To do this I started by visiting my Netlify.com account/team and the Domains menu, then my project-specific domain settings at https://app.netlify.com/teams/summittdweller/dns/thecompassroseband.net. In this page I’m given a list of 4 Netlify.com name servers that I can use for this particular project. I made note of the four before moving on.

Next step was to visit my registrar, enom.com, where I have a control screen for editing DNS records and name servers. I set the name server values for thecompassroseband.net there to the values that Netlify.com provided. And then, we wait… for the changes to propogate.

Fortunately, Netlify.com is on the ball… when I visit my new site’s domain controls page, https://app.netlify.com/sites/compass-rose-band-one-click/settings/domain, I find a widget that looks like this:

The cog behind “Waiting on DNS propagation” is spinning while Netlify.com waits for the transfer to happen. So, I’m going to go for a walk and see what that cog looks like in an hour or two.

Clear as mud? Give it a try, and hopefully it will begin to make sense. Until next time…

Adding Netlify CMS for Editing This Blog

Mark McFate — Sat, 27 Mar 2021 02:40:11 +0000

OK, I’m using the “Rich Text” editor option in the body field here in my “posts” Netlify CMS form for this blog. Will it work? We shall see!

Yup!

I have to confess, this is pretty cool. I’m even able to switch dynamically between the Rich Text and Markdown editors here!

How Was This Done?

Let me elaborate just a bit…

Using Hugo

Since this blog is published using Hugo I looked to the Netlify CMS guidance provided at https://www.netlifycms.org/docs/hugo/ for help.

First I added the requested ./static/admin directory, and the two files required there:

index.html, and
config.yml

index.html

The contents of my index.html file is identical to what’s called for in the documentation. Easy. I like.

config.yml

This file demands considerable customization, so I turned to more Netlify CMS documentation regarding Widgets and the Github Backend that I already use.

As a result, my config.yml file looks like this:

backend:
  name: github
  repo: SummittDweller/blogs-SummittDweller
  branch: main 

media_folder: 'static/img'
public_folder: /img

collections:
  - name: 'posts'
    label: 'Post'
    folder: 'content/posts'
    create: true
    slug: '{{slug}}'
    path: '{{year}}/{{month}}/{{slug}}'
    preview_path: '{{year}}/{{month}}/{{slug}}'
    preview_path_date_field: publishDate
    sortable_fields: [ 'publishDate', 'lastmod' ]
    sort: 'publishDate:desc'
    view_groups:
      - label: Year
        field: publishDate
        # groups items based on the value matched by the pattern
        pattern: \d{4}
      - label: Drafts
        field: draft
    editor:
      preview: true
    fields:
      - label: Title
        name: title
      - label: Body
        name: body
        widget: markdown 
      - label: Publish Date
        name: publishDate
        widget: date      
      - label: Last Mod
        name: lastmod
        widget: datetime
      - label: Location
        name: location
        default: 'Toledo, IA'
        required: false
      - label: Weight
        name: weight
        height: "Enter today's date with a leading dash, like -YYYYMMDD."
        required: true
        # default: -{{year}}{{month}}{{day}}
      - label: Draft Status
        name: draft
        widget: boolean
        default: false 
      - label: Description
        name: description
        required: false
      - label: Tags
        name: tags
        widget: list
        hint: 'Enter comma separated values.'
        required: false

Simple = Elegant

At this moment I’m running hugo server on my Mac and I’m editing this post in https://localhost:1313/admin, basically in the admin page of my blog on my localhost. Beautimous!

Time for a Test Page

Mark McFate — Sun, 07 Mar 2021 00:00:00 +0000

My daughter, Mackenzie, and I have been using this blog for testing new features lately. If you’ve been following me here you’ve seen some of them pop-up on the home page. Now that we have a host of them working, I need to move some out–of-the-way so they don’t clutter things up too much. However, I don’t want to discard them, in some cases we didn’t implement them anywhere else so this is the only working copy we have.

So, this morning I found a post at formcake, titled How to add a Static Page to Hugo by Joe Marshall. I’m going to follow Joe’s lead and try to add a static “Testing” page here. If I’m successful, it will become the new home for 3 features (and maybe more in the future), specifically:

A markdown (.md) file fetched from Dropbox,
A summary of my public gists, and
My latest Tweet, with automatic, timed expiration.

These three features currently look like this on my home page:

3 Features, Time for a New Home

It Worked, Almost

I did indeed manage to make this work, but not quite as Joe proposed. I found that in How to add a Static Page to Hugo there’s some confusion around the name of the .html file that Joe calls for. In at least one place the file is named /layouts/_default/singlepage.html, but in fact the file should be named /layouts/_default/staticpage.html.

The other issue I encountered was my fault. My implementation of this “testing” page means that I need to include not just text or markdown content, I also need quite a bit of code, mostly Javascript. So, in my case I duplicated the /layouts/_default/staticpage.html template, calling it /layouts/_default/testpage.html. My code appears in this new template file. I also changed the content “type” in the frontmatter of /content/testing.md from “staticpage” to “testpage”. And voilá…

It Just Works!

You can find the results on my Testing Page. Enjoy.

A Simple Sign-up Form

Mark McFate — Sat, 06 Mar 2021 00:00:00 +0000

For 2021 I’ve signed on to be a member of the steering committee for Toledo’s 2021 Community Visioning (CV) project coordinated by Tree’s Forever and Iowa’s Living Roadways, Iowa State University Extension and Outreach, and other partners. Tama is also a Community Visioning participant in 2021.

I’m only posting this as a test of what I think might be a very simple sign-up form using email. What you see below is just a test, so please don’t expect any invitation from this!

This Form is for Testing ONLY!

Are you interested in helping Toledo plan for the future with regard to transportation and recreation? Click ONE of the following links to receive an invitation by email to join a 90-minute online focus group on Saturday, March 6:

Remember, this is just a TEST!

One of Many Challenges

Mark McFate — Sat, 20 Feb 2021 00:00:00 +0000

I Like to Walk

I try to get outside and walk as much as I can, but I especially like walking with a purpose… not just walking for the sake of exercise or stress-relief. I guess that’s also why I dislike walking indoors on a treadmill, or the “dreadmill” as I like to call it. So, if I have somewhere to go in Tama-Toledo I’ll walk there and back whenever possible. Fortunately, my home in Toledo is geographically centered between the two communities. If you draw a 1.5-mile radius circle around my house it will include ALL of the two communities. It’s ideal for walking, except for the hills 🌄, and the challenge of finding a safe route.

Formidable Challenges

Tama-Toledo does have some nice sidewalks and trails that I try to take advantage of when I walk; however, there are three BIG challenges to using them safely:

Gaps,
Lack of Safe Crossings, and
Snow.

Gaps

This challenge is going to be difficult to explain in detail at this time. Why, you ask? Because I really need a map to do it justice, and probably some photos too. I don’t have a good map at this time, but I hope that the Tama and Toledo CV teams will come up with one (or two) soon. I’d also like to collect and post some photos, but there’s about a foot of snow covering everything, and I do mean everything (see below), right now.

Lack of Safe Crossings

Tama-Toledo, and my home, are situated at the intersection of two major highways:

US Highway 30, running east-west, and
US Highway 63, running north-south.

I’ll write more about these two obstacles later, when I have that map.

Snow ❄️

I should probably include rain in this paragraph too, and the mud that naturally comes with either snow or rain, in locations where there is no pavement (that’s a gap!). I think everyone can agree that safely traversing any wet surface can be a challenge, espeically where there’s no pavement. Anyone who’s experienced winter in the upper-midwest also knows that snow and ice make that challenge even greater, even where there is pavement!

20-Feb-2021

This morning my daugther called and asked if I could bring her a USB “printer cable”; she’s volunteering at a local youth archery tournament at the South Tama County High School, less than 1/2-mile from my home. A perfect opportunity for a short walk! There are no sidewalks on my street (another gap) but the roadway is not too busy so that’s okay. There is a nice sidewalk that runs part of the way (yup, another gap!) from my street to the High School along US 63, so that’s also helpful. Unfortunately, the photos I’m including below show the condition of that sidewalk on this lovely Saturday morning.

There's a sidewalk under there somewhere

You'll just have to take my word for it

There’s about 1/2-mile segment of sidewalk, some would say “to nowhere”, along this side of US 63 in Toledo. The north end of the segment terminates at 2nd Ave. in Toledo, but there’s no sidewalk on the north side of that intersection, nor any to the north for more than a mile! The south end of the segment terminates, literally in the middle of a field, presumably at the city’s shared boundary with Tama. Fortunately, on the west side of US 63 there’s an infrequently-used access/frontage road and it’s paved to provide access to some South Tama High School athletic fields. It’s ironic, you can’t safely walk to school because there are so few sidewalks, but there’s a paved drive to the the baseball diamond, where there’s no place to park. 😦

The entire length of this sidewalk is covered in snow, and I can’t recall any time this winter when any portion of it has been cleared. 😦 In fact, the snow here is exceptionally deep and difficult to walk trough because it includes everything that the snow plows have churned up. 😦😦 Spring can’t come soon enough for me!

I’ll post more regarding gaps and crossings as soon as I have that map and maybe some photos.

5-Inch HDMI Raspberry Pi Touch Screen

Mark McFate — Fri, 05 Feb 2021 00:00:00 +0000

A couple of years have now passed since I purchased an Elecrow 5" HDMI Touchscreen display for the Raspberry Pi and put it to use. I even 3D printed a very nice case for it. So, there’s a bit of configuration code on the SD card that can be edited to determine if the 5" screen is active, or if the RPI’s output is directed to its HDMI output port. Well, in the last 2 years I forgot what to edit and what changes to make.

Fortunately, when I went looking for some info to refresh my memory, I found a great resource… a review posted in 2016 from none other than Jeff Geerling, aka geerlingguy. His review/blog post is Review: Elecrow HDMI 5" 800x480 TFT Display with XPT2046 Touch Controller. In case Jeff’s post should ever disappear, here’s the a key piece of info that I needed to jog my memory:

## Getting full resolution over HDMI

When I first booted the Pi attached to the display, there was a large white area on the right, and only the left portion of the screen was being used by the Pi (it was only using 640x480 of the 800x480 display). To fix this, you have to set a few display options in the configuration file the Raspberry Pi reads during startup to switch certain hardware settings.

Edit /boot/config.txt (either while booted into Raspbian, or on another computer directly on the microSD card), making sure the following values are set:

# uncomment if you get no picture on HDMI for a 
# default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused 
# pixels visible and your display can output without overscan
disable_overscan=0

# uncomment if hdmi display is not detected and composite 
# is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
hdmi_group=2
hdmi_mode=1
hdmi_mode=87
hdmi_cvt=800 480 60 6 0 0 0

Reboot the Pi either via the UI or by entering sudo reboot in the Terminal. Once rebooted, the Pi should fill up the full 800x480 display.

Note: If the Pi boots up to a funny-looking screen and you can’t see anything, you can either reformat the microSD card, or pull it, edit the /boot/config.txt file from another computer to fix it, and put it back in the Pi.

My MQTT Weekend

Mark McFate — Sun, 31 Jan 2021 00:00:00 +0000

Now that I’ve cleared the driveway of the latest snowfall, I am officially declaring this to be “My MQTT Weekend”. It actually started on Friday night, the weekend, not the snow. Rather than posting a lot of gibberish here, I’ll just point you to my project repo at https://github.com/SummittDweller/Motorized_MQTT_Blinds and especially the Additional Resources portion of the README.md file there. If/when I get this all working maybe I will post some photos, maybe.

Paperless-ng on CentOS7

Mark McFate — Thu, 07 Jan 2021 00:00:00 +0000

Over the end-of-year holiday break in 2020 I managed to ressurect my old home-office CentOS 7 development server. I had a mind salvage and update Paperless on that server, and I did manage to do that. However, along the way I discovered the Paperless-ng branch of the project and I installed it, using Docker as suggested, by creating a new project and configuration I’ve saved as summittdweller/paperless-ng-dockerfiles.

To successfully mount my ReadyNAS/Paperless SMB share I had to do the following on centos7 as root:

mount -t cifs -o username=mark,vers=1.0 //192.168.1.48/Paperless /mnt/paperless

Unfortunately, this did NOT work! Everything appeeared to be working properly except that files copied into //ReadyNAS/Paperless/consume were NOT shared into the container as mapped, so no ingest was triggered. I could only get the ingest to start if I used docker cp… to copy the files into the mapped ./consume directory.

Mounting /home/mark/paperless-ng To Support Ingest

So, I turned to https://devopspoints.com/centos-7-setting-up-samba-and-nfs-for-file-sharing.html for setup of SAMBA on CentOS7 at 192.168.1.22 with hopes that I could mount /home/mark/paperless-ng/consume and get Paperless auto-ingest working.

It works! In fact, it works quite well.

Paperless-ng is configured to watch for changes in /home/mark/paperless-ng/consume and will ingest any unique .pdf files dropped there. Note that Paperless-ng is smart enough to keep track of all the files it has ingested so it won’t knowingly ingest a duplicate.

It’s worth noting that there is also a /home/mark/paperless-ng/exported directory where regular exports of Paperless documents can be kept before back-up to //ReadyNAS storage.

Still NO Good

So, the network configuration indicated above appears to work when copying files from a Mac into the target share, /home/mark/paperless-ng/consume. Unfortunately I’ve had NO luck whatsoever getting my Brother ADS-1500W scanner to network with ANYTHING. The setup seems just fine, but whatever I scan eventually gives me a “Send Failed” message with NO other explanation.

After spending many, many, many hours dealing with this I have officially given up!

A New USB Workflow

My Brother ADS-1500W scanner supports a number of transfer options including USB. There’s only one USB port on the back of the scanner so it’s relatively foolproof.

To engage this workflow I formatted a USB stick as FAT32 and named it PAPERLESS. When this stick is inserted into the scanner a BROTHER directory is created and scans named mmddyynn.pdf are generated there.

Once a set of documents has been scanned using the to USB profile, the USB stick can be removed from the scanner and plugged in to any CentOS7 USB input port. The PAPERLESS volume will automatically appear on the desktop and all that one must do is copy/paste (select and drag) each of the .pdf files from /mnt/paperless/BROTHER to the target consume diretory at /home/mark/paperless-ng/consume.

Modifying inotify in CentOS 7

The ~/Desktop/README.md file on node centos7 documents a necessary step that I discovered as the key to making Paperless consume/ingest process work. The commands are:

cat /proc/sys/fs/inotify/max_user_watches          # default is 8192
sudo sysctl fs.inotify.max_user_watdhes=1048576    # necessary increase

Starting and Stopping Paperless-ng

Starting Paperless-ng

Simple, to start it on CentOS7:

cd /home/mark/GitHub/paperless-ng-dockerfiles
docker-compose up -d

Or, simply reboot CentOS7. See auto-start details in the section below.

Stopping Paperless-ng

Also simple, on CentOS7:

cd /home/mark/GitHub/paperless-ng-dockerfiles
docker-compose down

Auto-Starting Paperless-ng

I found and followed this resource to create a boot-time auto-start script to configure and launch Paperless-ng whenever CentOS7 is booted. My script is /var/tmp/startup_script.sh and the process of running it echoes some output to /var/tmp/script.out.

I saved the script as a public gist for safe-keeping.

CentOS 7 Remote Using VNC

Mark McFate — Mon, 04 Jan 2021 00:00:00 +0000

This past weekend I managed to get a VNC server running on my centos7 node, where I run Paperless. The build instructions came from https://www.howtoforge.com/vnc-server-installation-on-centos-7. The node is available at 192.168.1.22:5901.

Thanksgiving 2020

Mark McFate — Thu, 26 Nov 2020 00:00:00 +0000

Sorry, I’ve posted and experienced too much sadness in the last two weeks, and more. Two members of our immediate family, Sully and Stitch, passed away on November 14th and 20th, respectively. Sully was our male kitty, only about 6 years old and his passing was a real shock. He was an ornery, sometimes grumpy cat, but very loveable at times. We miss him very much. Stitch was the matriarch of our cat family, about 18 years old and a gorgeous long-haired kitty. Stitch was in poor health the last year or so and not very playful so her passing was not such a shock, but it’s still hard to take. Fortunately, she passed comfortably in her sleep, nestled up on the couch between Mackenzie and Christine. We miss her too.

Sully and Stitch were buried on the McCune farm just a few days apart, not immediately next to one another, but not too far apart. They sometimes played together when Stitch would tolerate Sully, but most of the time they were a short distance apart, just as they are now.

Enough of that, since today is Thanksgiving I’ll post no more sad news. Instead, I want to share what I’m most thankful for… family. And our family has two new fur babies too, Georgie and Jo. Both are named after characters from Stephen King novels… perhaps a new trend? Let me explain…

Georgie is the best-tempered cat I have ever known. 😸 She’s a little over a year old now so she still loves to play, and she’s made a habit of insisting that I hold her at least a couple of times each day, and give her kitty treats in exchange for snuggles. We captured Georgie in December 2019, she was the last of 3 kittens and 5 adult cats (Uno, Deuce, Tres, Veer and Go) that we caught as part of a TNR (Trap, Neuter and Release) effort that we started as the weather started to turn colder. Georgie’s siblings found homes at the Tama Co. Humane Shelter (and later with a family in Belle Plaine) and with Morgan, who adpoted “Lint”, a long-haired solid gray kitten that was an odd part of the short-haired tuxedo cats living next door.

Georgie - Approx. Age 13 Months

Georgie - Play with Me!

Georgie was the last of the 8 cats that we caught and she managed to avoid the traps quite well. Since we were concerned for her wellbeing, as she was all alone, we decided to try and catch her without a trap, and managed to do so after she elluded us for an hour or so. She managed to get away by ducking into a storm sewer opening down the street, that’s why we named her Georgie, after the poor little boy featured in the opening of King’s story, “It”. Like “It”, she’s also a “collector”, always picking things up and carrying them away to who-knows-where. 😄

Jo, or JoJo, or Joey, or Cujo, is the new addition to the family. 🐱 Even before Stitch passed we put the word out that we might be looking for another kitty, somebody to keep Georgie company when no humans are home. Well, we received word of a farm kitten looking for a home and paid it a visit one week ago on Thursday night, November 19. Stitch passed the next evening and on Sunday, November 22nd, the kitten came to live with us. She saw the vet on Monday for an initial checkup and she’s sequestered in a spare bedroom for about 2 weeks to give her eyes and nose a chance to clear up… that process has started but she’s still got some eye goop as you can see.

Jo - Approx. Age 2 Months

Jo - In a Rare, Calm Moment

The Wee Beastie Sleeps after Turkey Dinner

Mackenzie suggested we name her “Cujo” since the farmer’s dog got hold of her in the farmyard. Also, Stephen King. 😄 The farmer was going to keep her as an indoor kitty due to the dog incident, but was overruled by her spouse. Their loss, our gain. We decided that the name could also stand for “Cute Jo”, and that stuck, along with all the other forms of the name. Jo is all kitten, but not afraid of anyone. She’s quick to snuggle up, but also loves to claw and bite when she’s in a mood to play. We are trying to teach her that toys=play while toes=snuggles, and the same for other body parts. I think she’ll come around just fine. Just wish she didn’t have to quarantine for another 10 days. 😦 But of course, it’s #2020.

That’s a wrap. Until next time… but only after I play with Georgie and give Jo another snuggle.

New Announcement Feature

Mark McFate — Sun, 13 Sep 2020 00:00:00 +0000

Quite some time ago I added an Announcement feature to the Rootstalk website that I helped design and maintain for Grinnell College. Events of the past week have driven me to implement this feature as part of this blog and one other site, with some minor improvements.

The original Rootstalk version of the feature is very simple, it works around this logic:

The site’s content/_index.html page invokes a shortcode named announcement.html.
The announcement.html shortcode checks for existence of a file path of static/announcement.md.
If the static/announcement.md file exists, its markdown content is read and displayed prominently on the home page.

Removing or disabling the announcement is as simple as deleting the file, or simply changing the filename to something like static/.announcement.md, and republishing the site.

Implemented for the Compass Rose Band

My brother-in-law, the founder and lead-singer for the Compass Rose Band, out of greater metropolitan Cedar Rapids, fell ill, and literally fell down the stairs, on Thursday evening, September 10, 2020. Since my daughter publishes the aforementioned CRB website, we wanted to alert their fans that the show set for Friday evening, September 11, would be canceled. We immediately thought of the Rootstalk Announcement feature and subsequently implemented it for the CRB site.

In the case of CRB the feature is implemented just a little differently:

Instead of a shortcode the layouts/index.html file includes a new block of code that looks for a file named content/announcement.md.
If the file exists, its markdown content is prominently displayed with an orange border near the top of the home page.

Removing or disabling the announcement is just like in Rootstalk, we delete or change the filename to something like content/.announcement.md, and republish the site.

Implemented Here In This blog

Since I’m essentially documenting the new feature here, I thought it only prudent to also implement it here, and that implementation is currently identical to what we did for the CRB.

So watch the top of this blog’s home for prominent announcements in the future, hopefully none that report dire emergencies. 😃

That’s a warp. Until next time…

Last of the Clean-up? - Derecho Follow-Up for September 6

Mark McFate — Sun, 06 Sep 2020 00:00:00 +0000

Tomorrow is Labor Day 2020, but it also will mark 4 weeks since the August 10 derecho. Thankfully, I believe today marked the end of the clean-up, at least on my own property. I was going to write this post yesterday after another 6+ hours of work outdoors, but last night we had another storm roll through, and all day the winds have been blowing upwards of 40 mph, so I put in another 6 hours or so cleaning up even more debris. The only good news here is that the city has not yet made a 2nd-pass of curbside debris pick-up, so I don’t have to haul it away, just keep adding to the “boma” at the curb.

The West-side Boma, Round 2

My post from August 20 includes photos of both our south and west bomas, massive curbside piles of tree debris that surrounded our property on two sides, plus a pile we placed next door in a church parking lot. Well, since that time we had to have our largest pine taken down, and many dead limbs removed from the other three large trees. All of that debris, plus what’s fallen just today, formed a new boma on along the curb to our west. I took some photos of that monster today:

The West Boma - Round 2 - Looking North

The West Boma - Round 2 - Looking South: Remnants of the Pine in the Foreground

Before the storm my backyard was looking pretty good. It’s not gone, but I just hope next year some of it might return to its previous glory.

What's Left of My Backyard

Insurance, Not Very Reassuring

I won’t name names here, but the company that carries my home-owner’s insurance has been NO help at all. I filed a claim with them on August 14 or so, and still have not heard anything from them. In fact, once I found out how badly damaged our big pine tree was I decided to call them directly, that was on Monday, August 24, I believe. I asked them if someone could come take a look at this tree because I’d put a plumb-line on it a few days before and was therefore able to detect that it was indeed tilting farther to the east each day. Their response was literally “It’s not covered unless it’s damaged your house.”

I told them I wasn’t concerned about the coverage, I just wanted to know if they could help me determine what to do about it, or if they could even recommend someone who could give me an expert opinion about it. “No, we don’t do that.”, was their answer. So I told them, “It’s leaning to the northeast and the wind is out of the south, it could easily fall on the neighbor’s house.” Their response left me speechless, they said, “If it falls on their house it is their problem, and their insurance will take care of it.”

I guess I am just naive when it comes to insurance, I always thought they actually cared about people and were intent on helping prevent disasters, but apparently they just crunch numbers and dole out money, as little as possible I’m sure. I was, and still am, disgusted.

If they ever do contact me I’ll listen to them as well and as long as they listened to me, and then I’m going to dump them just as soon as I can find coverage from someone who actually gives a damn.

Brother’s Tree Service To the Rescue

While I was checking up on some apparent fly-by-night tree “professionals” from out-of-state, I had the good fortune of meeting Shelby, the wife of Martin, an owner of Brother’s Tree Service. Martin looked at my tree damage and gave me a very reasonable quote to take care of all the “widow-makers”. At that time I wasn’t planning to have the big pine taken down, but after my insurance disappointment I called Martin and asked him to come look at it ASAP. He thought it should come down AND he interrupted his busy schedule to sweep in on the evening of Wednesday, August 26, to render that leaning tree harmless.

I was impressed at how quickly, professionally, and safely, Martin and his partner brought the bulk of that tree down! Finally, I could get some sleep without worrying about which way the wind was blowing. I took a couple photos of that tree removal operation too.

About 30 Minutes into the Pine Tree Removal

After About 1 Hour of Pine Tree Removal

A few days after bringing most of the pine down, Brother’s returned to remove some dangerous hanging limbs from my three remaining trees. Now I could even park my car in my own driveway again!

A Few Days Later Brother's Returned to Clean-Up Hanging Limbs

What To Do About My Lawn?

The one remaining concern I have is with my lawn; the combination of severe drought and lots of heavy equipment traffic has left great canyons in the grass. It litterally is too rough to drive my riding mower over it in most places. I’m frankly surprised the rough ride hasn’t ruined my mower or any of my lawn equipment yet, or maybe it has?

So I’m thinking, once the city has removed the newest debris (and there will almost certainly be more lawn-canyons after that), and after I’ve subsequently removed whatever they leave behind, I will probably ask one of the local landscape pros to come in. I’d like to have them dump a few loads of topsoil on the lawn and top-dress it all with a nice, smooth layer of soil that I’d hope to get planted for a new lawn before winter.

Wish me luck.

That’s a warp. Until the next derecho, or the next time, whatever that may be…

Tama-Toledo Parks - Derecho Follow-Up for August 24

Mark McFate — Mon, 24 Aug 2020 00:00:00 +0000

So, the Iowa Geocacher’s Organization annual Hike-n-Seek event is coming to Tama County and Otter Creek Lake on Friday-Sunday, September 25-27, barring any more 2020 disasters. 🍀 The weekend is slated to include September’s Friday Lunch Club (FLC) too, but the restaurant that was slated to host FLC was destroyed in the August 10 derecho.

This morning The FLC Committee, aka Borky00, aka Bill, asked me about possible outdoor park settings for FLC as a means of giving folks plenty of room for social distancing. Bill mentioned a couple of possibilities including a Tama city park on east 4th Street, and the Lincoln Highway Bridge park at the intersection of 5th Street and old US Highway 30.

The city park on east 4th Street is a no-go. There’s never been much in the way of facilities there, and after the storm there is literally nothing there. I did have three other possibilities in mind, and needed to check up on them after the storm anyway, so I took a few minutes this morning to gather some information.

Lincoln Highway Bridge Park - East 5th Street in Tama

This little park, and I do mean little, features two very small shelters but NO grills for cooking. It’s a small outdoor meeting place near Tama’s iconic Lincoln Highway Bridge, and home to a couple of my own geocache hides. Here’s what it looks like after the storm.

Lincoln Highway Bridge Park - After the Derecho

Tama City Park - Near 17th Street and Mclelland in Tama

This is Tama’ primary park and I’d heard it was cleaned up right after the storm, but there’s still LOTs of damage here and lots more cleanup to be done. Also, there’s only a fireplace in the small shelter, and no grills left on the grounds, at least none that I could see.

Tama City Park - After the Derecho

Toledo Heights City Park - West Side of Toledo on Old US 30

I think this is probably our best bet, assuming the City of Toledo can get the major debris taken care of before the FLC event. I just called the city and spoke with the City Clerk, she made a tentative reservation for me to have the shelter on Friday, September 25 for a reservation fee of $25. There is normally a $50 refundable deposit required but that’s being waved because the restroom in the shelter is not open due to the pandemic.

This park, about 1/2-mile west of the restaurant that FLC previously booked, has one nice large open shelter with a fireplace, AND two large grills just north of the shelter. Have a look, and note that the park is currently not reserved for any other events on Hike-n-Seek weekend.

Toledo Heights City Park - After the Derecho

That’s a warp. Until next time…

Derecho Follow-Up - Saturday, August 22

Mark McFate — Sat, 22 Aug 2020 00:00:00 +0000

Almost every day for the past few months I have walked with my “scurry” around Cherry Lake in Tama. We generally walk in the morning before the heat, humidity, and mosquitoes get too bad. We finally got power back on Thursday evening, August 20, so on Friday morning, August 21, 2020, we walked for the first time since the derecho of August 10. It was actually more like an obstacle course than our usual stroll, but we still managed to collect quite a bit of trash, as usual. There were about a dozen places around the lake, a trail that is about 1.33 miles long, where fallen trees required that we climb over or weave around. It’s no fun to do either, especially since the “weaving” sometimes involved venturing off-trail into the poison ivy. Makes me itch just thinking about it.

At the west end of Cherry Lake I placed a bench and engraved rock as a memorial for my parents, and my son, Ian. The most recent, pre-derecho photo of the rock and bench was taken on a “scurry” walk around the lake early this Spring. Portions of scurry-partners Jeff Shaw, and the hind-quarters of four-legged scurry member, Titan Edward, can be seen in this photo from that excursion.

McFate Memorial Bench at Cherry Lake - Early Spring 2020

On the south side of the lake – visible in the background of the photo above – the trail runs parallel to a road that leads to a brush pile where Tama residents can dump tree limbs, brush and leaves collected from their yard. There’s been a LOT of that lately! On this occasion a friend of our, Charlie Betz, was hauling a pickup-load of derecho debris to the brush pile and stopped briefly to chat. Charlie suggested that someday soon he would return with his chainsaw to begin clearing deadfall from the trail. We told him to let us know when, and we’d see if we could come help. Well, that “when” was 7 AM the next day, Saturday, August 22.

I arrived at the lake at 7 AM on the 22nd and found Charlie already there, preparing to fire up his saw. I brought my little 10" Ryobi cordless electric chainsaw and two fully-charged batteries. Jeff Shaw arrived about 20 minutes later and we proceeded to work our way counter-clockwise around the lake trail startring from the parking area on the east end of the lake. It was slow going, especially at first since the north side of the lake is, or was, densely wooded with some mature trees.

After three hours of cutting and tossing debris to the side of the trail, we reached my family’s memorial bench at the west end of the lake.

McFate Memorial Bench at Cherry Lake - After the Derecho

By this time we had waded through way too much PI, been briefly rained on, dulled Charlie’s chainsaw blade, and drained both of the saw batteries I had on hand. I think we were drained too. Time for a break, so at 10 AM we departed for some rest, lunch, fresh batteries, and hopefully a new chain for Charlie’s saw. We reconvened at Noon, as planned, and spent the next two hours clearing the deadfall around the McFate bench, plus a pair of gnarly monsters that had fallen across the trail near the southeast corner of the lake.

It felt really good to get it all done, and now we can engage in our “scurry” walks around the lake without all the bobbing and weaving required to navigate the obstacle course that was. Every good volunteer effort should conclude with a photo or two, so we got all cleaned up, NOT, and I shot this one.

The Post-Derecho Cherry Lake Trail Cleanup Crew - Me, Charlie, and Jeff

That’s a warp. Until next time… but only after I’ve had a pleasant scurry walk in the morning.

Iowa's 2020 Hurricane

Mark McFate — Tue, 18 Aug 2020 00:00:00 +0000

It’s been far too long, again, since I posted to this blog, but this time I have a legitimate excuse: we’ve been without power or internet, or much of anything, since about 11:45 AM on Monday, August 10, 2020. So we have now been more than 10.5 days without power. I’m only able to post this because of a portable generator I bought on August 12 (that was an adventure in itself) and the wireless hotspot that my phone has provided almost 24/7 ever since the storm hit.

Update: Power was finally restored here at about 6:30 PM, on Thursday, August 20, 2020. Now I just have 11.5 days of things to catch up on!

Preamble

The preamble to this story dates back to Christmas 2019, when my daughter gave me a “Dad’s Love…” daily calendar. There have been a couple of dates I kept because they are so accurate, like the day that says “We child-proofed the house but somehow they still got in.” 😄 Tama County has been in the grips of a moderate-to-severe drought for the past couple of months so the calendar page for August 10 looked like another “keeper”. It says:

Monday, August 10, 'Dad's Love...' Calendar

9:30 AM - Scurry Walk

This story begins in earnest around 9:30 AM on Monday, August 10, 2020. My “scurry” and I were just completing a quick walk around Cherry Lake where we had picked up a little trash, as we usually do. We met a couple of neighbors out for a walk and chatted briefly about the weather, and I suggested that the line of storms now in western Iowa looked like they might just hold together. Every weather system thus far in the summer had passed either just to our north, just to the south, or formed just to the east, so the neighbors just scoffed at the notion of us getting any rain. I was so sure it would rain this time that I didn’t hesitate to put a concrete block on the west-half of my hot tub cover to keep it closed in case of wind. I guess I should have used all eight blocks this time? 😕

11:45 AM - The Wind

The storms did indeed “hold together”. Oh boy, did they ever. A wall of wind hit Tama-Toledo at about 11:45 AM that morning, with literally NO warning from the US Weather Service. I had received alerts from the WeatherBug app on my iPhone, but there was no “official” word of impending doom. The rain didn’t begin until 5 or 10 minutes later, and I’m not sure any hit the ground because EVERYTHING, tree limbs, mailboxes, small animals, etc., was moving sideways. The power went out moments later. It’s still out as of this writing, a little more than 10 days since.

11:55 AM - Get the Cats!

After hustling to the basement and realizing the house was not gone, yet, we thought we’d better go back upstairs to get some candles, more flashlights, and our three cats. Mackenzie and I managed to get two of the cats pretty easily, but the third one was stubborn and had to be “captured”. While we were doing this I glanced out the window and saw nothing but tree limbs, still sailing past the windows on a nearly horizontal trajectory.

By the time we captured the last cat I thought to myself, the wind can’t last much longer…it had been blowing for at least 5 minutes straight, and I do mean STRAIGHT. I was very wrong. Thinking back, I do believe the wind blew at upwards of 100 MPH or more for at least 20 minutes.

11:58 AM - Morgan’s Story

My daughter, Morgan, had been at the STC Middle School in Toledo working on getting her classroom ready for the start of school. She got a call from a friend in Des Moines at about 11:30 AM telling her to watch out for a line of t-storms heading her way. There are no windows in her classroom so when she finally left the Middle School and saw how dark the sky was she got really concerned and promptly ordered the building secretary to open the office and get a handful of students back inside. They had just dismissed from summer-school and were waiting outside for their parents to pick them up. Good thing she did that.

Morgan drove away from the Middle School just minutes before a wall-of-wind roared in, and she called my cell phone at 11:50 AM just as she passed our house, letting me know that she was going straight to her apartment because her landlord wasn’t home and she was worried about her cats. The 5-minute drive to her apartment took about 3 hours? A couple of minutes later, at 11:55 AM we ran to our basement (after a 2nd mailbox went sailing past our front door) and Morgan called again at 11:58 AM. Her car had been hit by a falling tree limb, about 6" in diameter, near the crest of the hill on State Street in Tama, just south of the Tama Park. Her windshield was shattered, fortunately on the passenger’s side, and she was freaking out. I told her to stay in her car and Christine called 9-1-1 to provide her with some emergency aid.

The 9-1-1 call had to route through Benton county (30 miles east of us) as the local center was already overwhelmed, and the storm hadn’t hit there yet. A local police officer was dispatched and could get no closer than about 2.5 blocks from Morgan’s car due to downed trees, but made his way to her on-foot. He told her same as me, stay in your car to avoid downed power lines and potentially being hit by flying debris. He also told her to fasten her seatbelt in case the wind flipped the car over. Yikes! That happened at 12:18 PM, and the wind was still fierce!

At 12:20 PM my wife realized where Morgan was and called a friend who lives at the location of Morgan’s “tree incident”, and that friend managed to summon her inside once it was safe to make a run for it.

12:30 PM - The Wind Finally Stopped, Time to “Rescue” Morgan

It was about 12:30 PM when I felt like it was finally safe to go back upstairs and outside. Our mission was to try and get to Morgan as soon as possible. The power was out so I could not easily raise our double garage door, so I peeked out the front door to see what the situation was. OMG!

Our house is about 70 years old and it is (was) surrounded by five very large, mature trees… two grand old Oaks flanking the front yard, an American Sycamore directly west of our garage and patio, and two very tall pines on the NW and NE corners of the house, plus a few smaller and younger trees and bushes. Our driveway measures about 15’ x 45’ and it was entirely covered in limbs from one of the oaks and the Sycamore. Some of the limbs down on the driveway measured more than 10" in diameter. It ultimately took about 14 hours of back-breaking effort just to clear the driveway well enough for us to get both vehicles out of the garage.

In the immediate aftermath of the storm I had two other transportation options: the bicycle I had just purchased on Saturday, August 8; or my daughter Mackenzie’s car which was parked at the curb west of our house. I was pretty sure that car, parked partly beneath one of the oaks and the Sycamore, would be badly damaged, but it was not. There were limbs and whole trees, from our neighbor to the west, lying all around it, but the car was unscathed and operable. It took a little serpentine driving to navigate out of it’s parking spot, but by about 12:45 PM Christine and I were able to get it out and on-the road to try and “rescue” Morgan, roughly 1/2-mile away.

That 1/2-mile trip featured five impassable streets and a mile or two of back-tracking to find a suitable (barely) route. The four-lane US Highway 63 proved to be the best route for most of the trip only because it was wide enough that trees on the west side generally didn’t block all four lanes. We arrived in the vicinity of Morgan’s car at 1:02 PM and found that she had already pulled the largest limb off her car, what was left looked like this:

Morgan's Damaged Nissan Rogue - A Total Loss

Morgan’s apartment is about 1-mile from the location where we left her car, and she knew that her landlord and family were away in Cedar Rapids for the day, so we headed there to check on that property, and her cats. That trip took about 10 minutes with numerous “detours” but I was able to drive to within a half-block of the house. Thankfully we found the house intact with no visible, major damage, and the cats were safe, but obviously frightened, still inside Morgan’s apartment. Fortunately, the large old tree outside Morgan’s apartment window was damaged earlier this year in a storm, and had to be taken down entirely just a couple of weeks ago; otherwise it would have certainly damaged the house and her apartment. We called the landlord to report the relatively good news as they tried to begin their journey back home from CR. Then it started to rain again, just a little.

The Damage

This part of the story is perhaps best told in pictures. I took some photos and am posting them here in chronological order, with descriptive captions.

First Glimpse Out the Window

First Glimpse from Inside the House - South Facing Window Looking Out on the Driveway

First Glimpse from Inside the House - South Facing Window Looking SE at the Mailboxes

View from My Home Office Window an Hour After - Lookng NE

Headed Outside to Shoot More Photos

The power was out everywhere for 30 to 50 miles all around us so we assumed it was safe to get outside and take some better photos. No chance of getting cars out of the garage… our driveway was at least 80% covered by tree parts, some places it was 4 feet deep.

Looking NW at the House from Where the Mailboxes Used to Be

Yup, That's Our Mailbox

Looking NW from the Mailboxes - Our Driveway is Under That Forest

Looking North from the Bottom of Our Driveway

Looking SW from Just Outside Our Garage

Looking Due South from Just Outside Our Garage

Looking East from the Top of Our Driveway

West Side Story - The “Rolling Stone”, Hot Tub, Grill, and Limbs on the Roof

There were three pleasantly-amazing (lucky) things that happened, or didn’t happen as the case may be, on the west, windward, side of the house.

First up, my home-made lightweight teardrop camper, “The Rolling Stone”. It’s the gray thing that looks like a big old boulder on wheels in the right side of the first image below. It survived, almost unscathed! The only damage was from the door being blown open. That door hit the west wall of the house so hard that it bent a 1/8" thick steel latch plate back at a 120° angle. Because the door was open, things just inside the door also got a little wet, but they dried out well since then. The whole camper pitched forward about 3’ in the wind, but the on-board drop-foot was down so it didn’t fall to the ground. Had any large limbs fallen directly on it, we’d have had a total loss of structure and contents.

Looking SE from the NW Corner of Our Property

Next, the hot tub and grill. The very first thing I did when I got outdoors after the storm was to flip the hot tub cover back down. I have yet to clean all the leaves and debris out of the water…maybe later today.

When I receive any alert of a possible storm I always move one of the concrete blocks, seen stacked on the right in the image below, over to the west edge of my hot tub cover in order to keep it from blowing open. I made that move about 15 minutes before the storm hit, but it didn’t help. In fact, it did more damage, I think. The cover seems to be OK, but the wind did flip it open, sending the concrete block sailing about 10’ into the side of the house and narrowly missing the bathroom window that you can see. Lucky for us!

But our gas grill was not so lucky. That concrete block smashed down upon it leaving a big dent in the top, and causing the grill to “list” about 2" to port (the left side when looking from back to front).

Looking at the Hot Tub and Limbs on the Roof

Our 1-Year-Old Gas Grill

Looking South from NW Corner of Our Property

Finally, the limbs on the roof; you can see them clearly in some of these images. There were actually three of them, the largest with a diameter of about 5" at its base. All three were from the Sycamore tree, which I suppose is lucky. Sycamore’s have ENORMOUS leaves and while I feared severe damage to the roof, it looks like all three limbs just gently “floated” down to where I found them. I got them sawed up, and down off the roof, including an informal damage inspection plus wasp nest encounter, on Tuesday, August 11.

Looking SE from the NW Corner of Our Property

Looking East from the NW Corner of Our Property

The Cleanup

Building the World’s Largest (?) Boma

The mayors of Tama and Toledo, along with the Tama Co. Emergency Management office, called a public meeting, conducted in the parking lot of the nearby Tama-Toledo Family Aquatic Center, for 6 PM on Wednesday, August 12. At that meeting the cities informed everyone that any debris left at the curb would eventually be picked up and disposed of by a city crew. So, we started building what I like to think of as the world’s largest boma.

In the images below you can see both our west and south bomas. We didn’t need any on the east or north since we have neighbors on those sides, but we did build a small boma (about 30’ long by 10’ wide) in the parking lot of the church that sits at the NE corner of our property, where our utilities pole is located.

The West Boma - Panoramic

The South Boma - Panoramic

The West Boma - Close-up

The South Boma - Close-up

The South Boma - Close-up Looking West

SE Corner of the Property Looking at the Start of the South Boma

The Tree Wrangler

On Thursday, August 13, I started to address some of the potential widow-makers still hanging in our trees. My first target was the one shown below. I managed to rig a short chain to the end of a nylon rope and after about 10 tries I got the chain wrapped around the most menacing widow-maker, and yanked that sucker right out of the tree. They call me the “Tree Wrangler”. I’m pleased to report that subsequent limb-roping adventures took fewer tosses!

'The Tree Wrangler' Roped His First Stray

Roped My First Stray Tree Limb

Do you remember seeing an ominous widow-maker in the Sycamore tree in earlier images? Well she is no more. At about 1:30 PM on Wednesday, August 19, I roped that critter and managed, with considerable effort, to yank that bad boy down. Proof that “The Tree Wrangler” has struck again…

I Hath Slain Another Widow-Maker

The Kansas City Chiefs - Still World Champs

After closing the hot tub cover I made sure to get out and untangle my KC Chiefs flag!

SE Corner of the House - After I Untangled the Chief's Flag

Our $800 Savior

On Wednesday morning, August 12, I got word that some of the big-box hardware stores in Cedar Rapids and Waterloo were receiving shipments of portable generators. They were being sold on a first-come basis, right off the truck, so Morgan and I got in the van and headed to Waterloo as fast as possible…we got one at Lowe’s for $800. Had to wait in line for a couple of hours too, but managed to get home mid-afternoon with the generator, some ice and gasoline. None of those things would be available locally until Friday, August 14.

Our Savior

My Biggest Remaining Concern - Broken at the Base?

My biggest remaining worry is the pine tree at the NW corner of the house. On Thursday, August 13, during clean-up I discovered that the bark on the SE side of the tree is “crushed” as you can see in the image below, and there’s a visible “crack” on the NW side of the tree right at ground-level. Upon closer inspection it looks like the tree is leaning about 5°, naturally right toward our house. 😟

Broken at the Base?

Houston, We Have a Problem OR The Eagle Has Landed!

One block west of our house there’s a bank, and it used to have a large golden-colored eagle atop it’s electronic sign at the intersection of Summit Street and US Highway 63. When we told folks from out-of-town how to find us we would always use that eagle as a navigational aid, telling them to find the eagle and head one block east to our house.

Well, our navigational aid got its wings during the storm. As you can see in the photos below, the eagle “flew” about 200 feet and landed in the bank’s lawn.

The Eagle Has Landed!

The Eagle's Flight Path - Panoramic

With No Apparent Structural Damage, We Were Luckier Than Some

Formerly Thys Chevrolet - 1/2-mile from Home

Just One of Several Collapsed Buildings on My In-Law's Farm

Oak Hill Cemetery - August 20, 2020

Since all the Alliant trucks rolled past our house around 10 AM this morning, I thought it was time to visit Ian and my parents at Oak Hill Cemetery. Frustrations at home certainly weren’t getting any better so I felt like getting away to take a deep breath and realign my perspective a little. Oak Hill usually does that for me.

Oak Hill Cemetery is well-named…it blankets the hill with Ian and my parents’ graves near the very top, and there are lots of oaks, but even more pines. Well, there used to be anyway.

This is perhaps another case where photos tell the story better than I. However, I’m not sure the few photos I took will reflect the scale of the devastation. For starters, the main road up to the cemetery is still blocked, as are the three entrances into the original cemetery. Fortunately, the newest section where there are no mature trees, was relatively clear. So, Morgan and I were able to drive in and park about 100 yards from the hilltop.

This is a glimpse of what we found there…

Oak Hill Cemetery from Our Parked Car, Looking South

Oak Hill Cemetery - 180 Degree Panorama

I could not bear to shoot the panorama over the opposing 180° view…it was just too sad. 😢

The Big Pine Near the McFate Plots

The broken pine, shown above, is, or was, near my parents’ graves, and you can see their shared headstone just to the right in the image above. My son, Ian, is buried a little to the left of the edge of the image, but you can’t see that grave from this angle because of all the tree debris. “Ian’s Cache”, GC4BG3B is somewhere inside or under that tree. I looked for the container for about 15 minutes this morning, but came up empty-handed. 😦

Fortunately, when the ol’ tree fell it missed Ian’s grave by a few feet. We got lucky and found all four of the clear acrylic cylinders that used to adorn his grave. They are all intact, but need a little TLC before we put them all back out.

My parents’ headstone is in good shape, but another tree toppled the nearby stone marker for my aunt, Dorothy Paddleford. I’ll see to it that gets fixed soon.

A few weeks ago my brother-in-law, Dennis, set in-motion a plan to install an engraved stone bench as a memorial for my sister, Marlene McFate Burkheimer. It was to be placed not far from the cemetery road at the very top of the hill, about 50’ from the big pine. At one time we thought about looking into wrapping a bench around that ol’ pine to provide a nice place, in the shade, to sit and relax. However, providing a concrete base for such a bench would have been very difficult. Maybe if the pine’s stump is removed we can place the bench where the tree was, and maybe one day plant another tree to provide the shady spot we hoped for?

Another View to the South from Ian's Grave - The Road is Still Impassable

Tomorrow morning I plan to contact the City of Tama and the Oak Hill Cemetery Association to see about volunteering to help with clean-up. I think they are going to want all the help they can get in the coming weeks and months.

G’night

It’s late-evening again, but at least now I have some real lights to work by. Tomorrow I need to start reprogramming all the devices that have been dead for 11.5 days, and begin making up for as many days of missed work. Time for bed. G’night all.

Until next time… but I hope there’s never another “next time” quite like this one!

Pandemic Pastime: Walking and Picking Up Trash

Mark McFate — Mon, 03 Aug 2020 00:00:00 +0000

It’s been far too long since I posted to this blog; I guess I’ve been busy? Nah, not any more than usual, but during the COVID-19 pandemic I have doubled my efforts to get out and walk in the fresh air whenever possible. I’m thankful for my small “scurry” – that’s the term for a collective of squirrels – who not only take walks with me around Cherry Lake, but all around town.

About three months ago there was some vandalism at Cherry Lake, and there was a time when folks were leaving lots of trash around the lake. So our scurry started carrying “Niffty Nabbers” and now we clean up what we can as we walk. We have even extended the practice beyond the lake, and we generally walk twice a day now, most evenings somewhere in Tama or Toledo away from all the mosquitoes that inhabit Cherry Lake. True to form, we pick up trash as we go.

I would estimate that both solo and with my scurry, I/we have picked up about 100 pounds of trash so far.

This past weekend I was thinking… now that we have expaned to more than just Cherry Lake, it would be nice to plot our routes walked somewhere online so that we can keep track of progress, and see where we haven’t been yet. Fortunately, I tend to activate a “workout” recording on my Apple Watch whenever we go out, and I just realized that those routes can be exported from my iPhone as .gpx files. So, one day soon I hope to create a new section in this blog where I can post records, with maps, of our excursions. Look for it in this blog soon, or at least sooner or later.

That’s a wrap. Until next time…

Home Automation

Mark McFate — Sat, 09 May 2020 00:00:00 +0000

During the COVID-19 pandemic I decided, while working endlessly from my home office, to resurect the hanging bird feeder outside my office window. I like having the birds visit, but I’ve noticed one problem… starlings! They are cranky, bully bastards and chase all the welcome visitors away, if I let them. Well, I don’t intend to let them anymore. 😁 I won’t go into details here but my remedy involves removing the screen from my office window, and occasionally opening the window itself.

There are two issues with the window… it’s a big, double casement window with a pair of crank mechanisms for opening, and the one that I need to open most often is situated behind my mini-fridge. It’s difficult to get to the opener crank, and even hard to open or close it “gently”. The other issue is that while the window is open my office door needs to be closed so that our house cats won’t wander in and decide to “escape” through the open window. 😾 I suppose the cats could provide some extra starling deternt, but they are not as selective as I am. If it moves, they want to catch it. 🐈

The solution, I hope, is to build and install an automated window opener, one that I can control without getting out of my seat. It would also be nice if I had the same option to open, or at least close, my office door. I have a spare Raspberry Pi Zero W and some related parts so that’s a start. I’ve also just purchased a little High-Torque DC Motor and a RPI-compatible motor controller.

Web Resources

This post captures the resources I’ll use (or used, depending on when you read this) to set my plan in motion. The first step, my OneTab that holds my initial web resources: https://www.one-tab.com/page/0fj_WcQ0TkG256iDV3EE2g.

My Build

Check here for some follow-up soon, I hope.

Adding "Remote Atom" to My DigitalOcean Server

Mark McFate — Sun, 15 Mar 2020 00:00:00 +0000

Last evening and early this morning I completed the addition of a new (to me) package to Atom on my Mac Mini. The package is Remote Atom and I found the configuration to be a little confusing, but in the end it was worth the work.

Use

The addition and configuration of this package allows me to open an SSH terminal/session from my Mac Mini to my summitt-dweller-DO-docker droplet and, with Atom open locally on my Mac I can issue a command like

ratom /opt/README.md

in the terminal connected to summitt-dweller-DO-docker, and the specified “remote” file will open in my local Atom. Better still, if I make changes to the file and save them, the remote copy is automatically updated as saved.

Configuration

As I said, configuration was a little dicey. Mine followed exactly what’s documented in the project site, complete with renaming rmate to ratom as suggested. The real key to configuration has two parts:

First, Atom has to be open locally. This is necessary to get the package running so that it can accept connections from the remote, and that also requires that the package is auto-started along with Atom.
Next, I added the following specs to ~/.ssh/config on my Mac Mini:
```
Host 104.248.237.235
  RemoteForward 52698 localhost:52698
```

That addition to ~/.ssh/config allows me to run my usual ssh connection commands without having to specify any remote/reverse tunneling…the config does it for me automatically when the “Host” or target is summitt-dweller-DO-docker. Without that spec I’d have to configure each ssh connection I open, like so:

ssh -R 52698:localhost:52698 administrator@104.248.237.235

That’s a wrap. Until next time…

Launching MacDown from a Terminal

Mark McFate — Sun, 15 Mar 2020 00:00:00 +0000

Lately I find that I like to open Markdown documents in MacDown rather than Atom. This is espeically true of things like “README.md” documents that I intend to read, but not edit. This can be done without any special configuration, assuming MacDown is installed and working. To do that use a syntax like this:

open -b com.uranusjr.macdown path/to/document.md

A command I’ve been using quite often today is: open -b com.uranusjr.macdown ~/GitHub/dg-isle/docs/install/install-local-migrate.md.

That’s a wrap. Until next time…

Migrating the Wieting Site in Drupal 8

Mark McFate — Fri, 28 Feb 2020 00:00:00 +0000

Migrating the Wieting Site in Drupal 8

Sorry for my extended absence here, I’ve been uber-busy with work, but have also been able to work a little (lots of long nights and weekends) on a long-overdue update of https://Wieting.TamaToledo.com in Drupal 8. It’s true, I have been thinking about moving that site to make it static, almost certainly using Hugo, but I thought before doing so I’d give Drupal 8 one more try. I’m pleased to report that it’s working nicely again. Here’s how I did it, and how I plan to keep it updated…

Saved by “docker-compose-drupal”

I actually started the process of migrating and updating the Wieting website in Docksal, but I failed… I could never figure out how to reliably and easily push my work to production from there. Docksal just seems to wrap so much of itself into the cli container that drives it, I found it difficult to de-couple from that in production.

So I went looking elsewhere and discovered Lando, and I did considerable work with it because Lando, at least in the case of Drupal, builds a 3-part development stack that looks a lot like what I wanted to deploy in production. The parts of a Lando stack, and my production stack, are the same:

An nginx web server container,
A mysql or mariadb database container, and
A php codebase container.

But once again I had trouble figuring out exactly how to push that development stack to production. So, I went looking again for an open (and by that I mean “free” and freely modifiable) production-ready stack configuration that uses the 3-parts I had in mind. I found docker-compose-drupal and almost immediately created my own fork of that project. Using my docker-compose-drupal fork I set off to build a production instance, NOT a development instance, on my summitt-dweller-DO-docker droplet at DigitalOcean. That project came to life in /opt/docker-compose-drupal there.

The evolution of summitt-dweller-DO-docker:/opt/docker-compose-drupal was quite an adventure, in large part because the Wieting’s web site had gone almost a year without any updates. That meant upgrading the Drupal core from version 8.2.? to version 8.8.2, along with countless modules that had changed rather dramatically, so there were lots of bumps along the way. I also had to move the site from a multi-site configuration, the old site lived in a container at /var/www/html/web/sites/wieting, to a default configuration that lives in the container at /var/www/localhost/web/sites/default.

Fortunately, docker-compose-drupal includes some nice scripts and features to help with things like that, and they are nicely documented in the project’s README.md file. I’ll elaborate on a few of the key features later in this post, but most of what I did during the migration and update is water-under-the-bridge, and should not need to be repeated, ever, so I won’t elaborate on all of it here. It’s worth noting here that the work I did in my fork all happened in a branch named wieting.

Moved to “wieting-D8-DO”

Once I had a new site working as I’d hoped, I wanted to begin a fresh new development and update cycle, so I used a process I’ve documented in my work blog: “How to Create a New GitHub Repo from an Existing Branch”. That work created the Wieting site’s new home, https://github.com/SummittDweller/wieting-D8-DO, based on the wieting branch of the aforementioned fork of docker-compose-drupal.

Site Update Workflow

Having built the wieting-D8-DO project I need a reliable workflow that I could use to keep it up-to-date. I created that workflow by migrating the existing production site at summitt-dweller-DO-docker:/opt/docker-compose-drupal, where it responded as https://Wieting.TamaToledo.org, to a new staging copy at summitt-dweller-DO-docker:/opt/wieting-D8-DO, where it would respond, temporarily, at my designated “staging” address, https://Wieting.SummittServices.com.

While working as administrator on summitt-dweller-DO-docker the entire command-line process looked like this:

echo $(date --iso-8601)
cd /opt/docker-compose-drupal
git ls-files --others --ignored --exclude-standard > $(date --iso-8601).ignored.list
tar czvf $(date --iso-8601).ignored.list.tar.gz --files-from $(date --iso-8601).ignored.list
gpg --encrypt --recipient summitt.dweller@gmail.com $(date --iso-8601).ignored.list.tar.gz
rm -fr $(date --iso-8601).ignored.list.tar.gz
cd /opt
git clone https://github.com/SummittDweller/wieting-D8-DO.git
cd wieting-D8-DO
cp -f ../docker-compose-drupal/2020-02-27.ignored.list.tar.gz.gpg .
gpg --decrypt 2020-02-27.ignored.list.tar.gz.gpg > ignored.tar.gz
tar xzvf ignored.tar.gz
rm -f ignored.tar.gz
cd ../docker-compose-drupal
scripts/mysql dump
mv -f database/dump/dump.sql /opt/wieting-D8-DO/database/mysql-init
cd /opt/wieting-D8-DO
nano .env
nano docker-compose.yml
docker-compose up -d

Breaking the Workflow Down

Moving the site from /opt/docker-compose-drupal and https://Wieting.TamaToledo.com, to /opt/wieting-D8-DO and https://Wieting.SummittServices.com is a command-line process like this, with comments…

Comments / Commands
# Set the working directory to the server’s project root, then `git clone` the wieting-D8-DO project. `cd /opt` `git clone https://github.com/SummittDweller/wieting-D8-DO.git`
# Save today’s date in ISO 8601 format to `${today}`; we will use it a few times later on. `today=$(date --iso-8601)`
# Set working directory to the initial project. Put the site into ‘maintenance_mode’, flush all caches, dump a copy of the project’s database, move previously dumped databases to an .inactive directory, and move the dumped database so it will initialze the new site upon startup. `cd /opt/docker-compose-drupal` `scripts/drush sset system.maintenance_mode 1 --input-format=integer` `scripts/drush cr` `scripts/mysql dump -f dump_${today}.sql` `mv -f /opt/wieting-D8-DO/database/mysql-init/*.sql /opt/wieting-D8-DO/database/mysql-init/.inactive/` `mv -f database/dump/dump_${today}.sql /opt/wieting-D8-DO/database/mysql-init/`
# Fetch a list of ignored files, then tar the ignored files to make an archive, and encrypt the tarball for security purposes, then remove the itermediate tarball. `git ls-files --others --ignored --exclude-standard > ${today}.ignored.list` `tar czvf ${today}.ignored.list.tar.gz --files-from ${today}.ignored.list` `gpg --encrypt --recipient summitt.dweller@gmail.com ${today}.ignored.list.tar.gz` `rm -fr ${today}.ignored.list.tar.gz`
# Now set the working directory to the new project, copy the tarball from the old site to the new one, decrypt and then restore/extract the tarball contents, and finally, remove the intermediate tarball. `cd /opt/wieting-D8-DO` `cp -f ../docker-compose-drupal/${today}.ignored.list.tar.gz.gpg .` `gpg --decrypt ${today}.ignored.list.tar.gz.gpg > ignored.tar.gz` `tar xzvf ignored.tar.gz` `rm -f ignored.tar.gz`
# Working in the new directory, edit the .env file to set `PROJECT_NAME`, `NGINX_HOST_HTTP_PORT` and `NGINX_HOST_HTTPS_PORT` that won’t conflict with existing names. `nano .env`
# Still in the new directory, edit the docker-compose.yml file to set the nginx service `labels:` to include `traefik.frontend.rule=Host:wieting.SummittServices.com`, to properly address the new site. `nano docker-compose.yml`
# Spin up the new site for testing. `docker-compose up -d`
# Turn off ‘maintenance_mode’ in both sites. `/opt/docker-compose-drupal/scripts/drush sset system.maintenance_mode 0 --input-format=integer` `/opt/wieting-D8-DO/scripts/drush sset system.maintenance_mode 0 --input-format=integer`

That worked nicely! Time to end this saga, but I’ll return shortly, in another post, to document my workflow for ongoing maintenance and updates. Until next time…

Testing My ExternalURL Feature

Mark McFate — Sun, 11 Aug 2019 00:00:00 +0000

Really just testing out this blog’s externalurl feature here. Click on the --> at the head of this post to see my “professional” post about building Grocy in Docker and Docksal.

My Photos Workflow

Mark McFate — Thu, 04 Jul 2019 00:00:00 +0000

I recently returned from vacation in Norway with a few hundred photos and a handful of videos, taken mostly using my iPhone 8. I find that the Apple Photos app does a pretty nice job of cataloging photos and videos into Moments. Each Moment includes all the images taken in a single day, and sometimes in a particular location, if photos are taken on the same day, but a great distance apart.

Moment names from my Norway vacation were nicely descriptive, like:

Minneapolis-Saint Paul International Airport - Minneapolis, MN, June 11, 2019
Paris Charles de Gaulle Airport - Mauregard, Île-de-France, June 12, 2019
Jessheim - Akershus, June 12, 2019
Kirkenes, Finnmark - Johan Knudtzens gate, June 12, 2019
Kirkenes, Finnmark - Dr. Wessels gate, June 13, 2019
Kirkenes, Finnmark - Johan Knudtzens gate, June 14, 2019
Skarsvåg - Finnmark, June 14, 2019
Arnøyhamn - Norway, June 15, 2019

Exporting the Photos

I found this resource on the web and followed it for the export portion of my process.

So, I opened Photos on my Mac Mini, selected the Moments view/tab, culled some of the duplicates out, then selected all 359 remaining images using my mouse. With the images highlighted I selected menu options: File, Export, and Export 359 Photos.... I subsequently filled in the following dialog like so:

I choose a ‘Photo Kind’, or format, equal to PNG and a ‘Size’ equal to Medium, since most of the images are huge and would load very slowly in my blog if left at their original size. I elected to save the exported PNG images into a new folder on my ~/Desktop named Norway-Medium-PNG-Export.

Upload to Digital Ocean “Spaces”

A few days ago I registered with Digital Ocean “Spaces”, and created my first “bucket” named images-summittdweller. Spaces provides me with up to 280 GB of REST-accessible object storage for a small monthly fee. To host my photos there I simply created a “folder” named Norway-Photos-2019 and did a drag-n-drop of each ~/Desktop/Norway-Medium-PNG-Export/ individual* folder directly into my browser window. *Note that the drag-n-drop interface was unable to swallow the entire Norway-Medium-PNG-Export folder all at once. 😞

All of my uploads to the images-summittdweller bucket were declared as Public rather than Private, that way they can be accessed using simple URLs without authentication.

Additional Images

In addition to the aforementioned photos, I also parked a copy of the PhotosExportDialog.png screen capture there in the root folder. It’s accessible as https://images.summittdweller.com/Norway-Photos-2019/PhotosExportDialog.png and that’s what I used above to embed the image you see in this document.

In the future, more images, perhaps some taken by Deb, Doug, or Mark McCune, can be added to this photo blog in a similar manner.

Object Structure and URLs

A sampling of the bucket/object/filenames and URLs from images-summittdweller are tabulated below. From this small sample the URL structure is easy to infer.

images-summittdweller Bucket Path	URL
./Norway-Photos-2019/PhotosExportDialog.png	https://images.summittdweller.com/Norway-Photos-2019/PhotosExportDialog.png
./Norway-Photos-2019/Minneapolis-Saint Paul International Airport - Minneapolis, MN, June 11, 2019/IMG_0352.png	https://images.summittdweller.com/Norway-Photos-2019/Minneapolis-Saint%20Paul%20International%20Airport%20-%20Minneapolis,%20MN,%20June%2011,%202019/IMG_0352.png
./Norway-Photos-2019/Tromsø - Troms, June 15, 2019/IMG_0527.png	https://images.summittdweller.com/Norway-Photos-2019/Troms%C3%B8%20-%20Troms,%20June%2015,%202019/IMG_0527.png

Generating Markdown for Blog Photos

So the intent of all this is to populate the photo blogs that you see here. To that end I’ve created a simple API Python3 script based on guidance provided in this article.

Travel...MSP to CDG to OSL to KKN

Mark McFate — Wed, 12 Jun 2019 00:00:00 +0000

This was a very long day in the air, and then we discovered the "midnight sun"!

This post is really part of my Norway photo blog which you can find elsewhere on this site. Note that the photos here are in reverse-chronological order with the exception of one “lead” post that lays out our itinerary. So, read on…

I drove the 5 of us, plus luggage, in our mini-van to Minneapolis for our departure, and we left home early just in case there were surprises. Good thing we did! I drove US 20 to I35 with a stop in Storm Lake for a late lunch. Not long after that stop we hit the first snag and found I35 closed, in both directions, just south of the Iowa-Minnesota border. The stop and detour there set us back about a half hour or so…no problem.

We booked and found off-site parking near the airport in Minneapolis, and got dropped off at the correct terminal for Iceland Air, which will forever be known in this household as Iceland Error. That’s when things really go interesting. Iceland Error had changed our flight, and itinerary, without notice (they have no mobile app). We would be leaving the US about an hour later, good thing, and arriving in Kirkenes about 16 hours ahead of our original schedule! We weren’t even booked on Iceland Error for our departure, instead we were flying Air France to Paris, then to Oslo, and connecting directly to Kirkenes.

The change meant we had to change terminals, back to the terminal we’d just come from with luggage in tow. Not fun.

Ok, so Air France was GREAT! They fed us, we had comfortable seats, they dimmed the lights, had nice entertainment, and provided whatever we needed at no extra charge. For the record, Iceland Error did NONE of that on our return to the U.S.

But I digress… We got to Paris without a hitch and in good spirits, found our connecting flight to Oslo and made that leg in good shape. Then on to Kirkenes rather than staying a night in Oslo, and that was OK, except that Kirkenes isn’t a big city, and when we arrived ahead of schedule there was no shuttle waiting for us (the one that did arrive was full), but the good folks there dispatched one especially for us.

We arrived at our hotel around 11 PM local time, I think. Of course, it was difficult to tell the time because the sun was still up, and would remain “up” for pretty much the next 4 days!

The hotel had only one spare room for the night, so Chris and I took that one, and they arranged for Mark, Deb and Doug to taxi about 30 minutes outside of town to a “cabin” near the Russian border. Lucky for them…they got to set foot, or at least a big toe, in Russia, at about 2 AM, I think. Silly Americans. 😁

To be honest, I loved the “midnight sun”, it was great for geocaching, but really put a dent in my already damaged sleep schedule. 😉

@Summitt Dweller’s Personal Blog - Posts

Tama County Celebrates

Farewell Facebook Friends

Alexa Notes

Connecting Ceiling Fan Control to Alexa

How to Setup the “Smart Life” App

How do I connect to Alexa?

Common commands

My Grandparent's 1926 California Trip Project

Rootstalk Plan

The Task at Hand

Starting From a PDF

Step-by-Step

Rebranding CV to HAT with Pagefind

A Newer Pagefind Enabled Blog!

Once Again…That Was Too Easy!

Following Tom’s Excellent Advice

It Works!

A Staging Site in Azure

Errors?

Last of the Errors?

Success!

A New Production Branch

A New Pagefind Enabled Blog!

That Was Too Easy!

Following Tom’s Excellent Advice

It Works!

A Staging Site in Azure

Errors?

Last of the Errors?

Success!

A New Production Branch

Microposts from iOS

NOT Like a Rolling Stone

Spinning Up StaticCMS

The Plan

Along the Way

First Steps - Start with a Template

Getting Started

Let’s Go Local!

Eureka! It Works!

Even Better News?

Fresh Restart

Copying wieting-ss to static-cms-hugo-local-template

Corrections Needed

Time To Save My Progress

wieting-staticCMS

Snowpocalypse 2024 - Round 2

Snowpocalypse 2024?

Update: 10-01-2024 @ 10 AM

On-prem Servers with StaticCMS and Remote Access for the Wieting

Currently…

The Future…

Remote Access to the Rescue

Reasonable Remote Access?

Summary… the Plan

Bonus!

Building My First Steamlit App

Redefining an Azure Static Web App

Worth a Try

Something is Missing

Upgrading Matomo PHP

Planting Sempervivum tectorum (and More)

Fixing Wieting Guild Pages

Roadtrip: Geowoodstock 2023

Wrap EVERYTHING in NPM!

That Was Too Easy!

Following Tom’s Excellent Advice

It Works!

A Staging Site in Azure

A New Production Branch

A Pagefind Problem?

Not Just a Hugo Issue

The Nutshell

Three Possible Solutions

1. Skip Azure and Deploy Only to DigitalOcean

Update 12-May-2023: Same Problem Exists in DigitalOcean

2. Wrap Hugo in npm

Update 29-May-2023: NPM is GREAT!

3. Transition from Hugo to Eleventy

Copying `wieting-ss` to `static-cms-hugo-local-template`

2. Wrap Hugo in `npm`

`yarn`, Not `npm`

Using `npx pagefind...` to Index Content

Added a `pagefind` Script… Didn’t Work

Extending My `encrypt` Script

Installing `s3cmd`

Using `s3cwd`

Alter Content to Include the `web-ready` Path

Not `web-ready`, `originals`

Using `git filter-repo`