I currently use Jenkins to automate the build and deployment of my personal website and my blog site. I will experiment with a Gitea Actions workflow to see if I can accomplish the same thing in Gitea.

This process should be familiar to me since the workflow I configure in this post will more or less mirror the behavior of my Jenkins setup: an independent service (e.g., Jenkins agent, Gitea runner) executes steps defined in a repo configuration file (e.g., Jenkinsfile, demo.yml).

I need a sturdy, medium-sized whiteboard, and I would not like to pay much money. Mostly because I won’t feel as bad when it is inevitably damaged or degraded as is inevitable with any cheap whiteboard. I can either buy a very small whiteboard of poor build quality, or I can make a fairly large one for roughly the same price. Easy decision.

Plan

I will buy a piece of hardboard with a smooth gloss whiteboard finish. Uncut, this would give me a 8′ × 4′ whiteboard, which is enormous for the space I have. 3′ × 3′ will be ideal.

View the git repository here

In a previous post I added multi-user support to a web app I built with Microsoft’s Blazor framework in C#, which I named Formulation. In this post I review a fully-working version of the project.

Problem

The problem is in my previous approach to estimating nutrition, which was to prepare many units of a single type of food item with known nutrition, e.g. frozen burritos. I knew that if I ate one whole <food> I would have consumed <nutrition>. This works, but it is not flexible: I must eat the whole <food> item, and only eat <food> items, or else be pained to calculate things manually.

Formula

Process

1. place beans in water

2. soak 8+ hr.

   ALTERNATIVE: QUICK SOAK:

   1. place beans in water
   2. bring water to the boil
   3. maintain boil, 2 min.
   4. remove from heat
   5. cover
   6. soak, 1 hr.

3. drain the water

4. place beans in fresh water

5. simmer ~2 hr.

6. drain

7. combine ingredients in blender

8. blend until very smooth

Project git repo

A few years ago the company I work for explored the idea of rewriting older ASP.NET and Backbone.js features in a more modern web framework. Between the two contenders, React and Vue, the development team was leaning toward Vue. Each developer went off and built a small feature or two using Vue to get a sense for it before we eventually committed to rewriting with it. I raised no objections to the decision because it did not matter to me, and I like Vue just fine.

I am using the static site generator Hugo to generate the web log site that currently hosts this content. Currently, my site is hosted on my local network using hugo server:

Hugo provides its own webserver which builds and serves the site. While hugo server is high performance, it is a webserver with limited options.

This has worked great since I have been using the embedded webserver for development purposes – each time I make changes to the watched files, Hugo rebuilds and live-reloads the site. This is convenient for development purposes, so I will continue to use it in this way.