I am getting weary of the term 𝘴𝘵𝘢𝘳𝘵𝘶𝘱 being thrown about these days.

Your startup, as you call it, is just a product. If it were a startup you would have a business and banking entity associated with it.

You don't. You are launching another product.

Reading *Courage is Calling* by Ryan Holiday.

"Foresee the worst to perform the best"

That is building software in a nutshell. Every estimate. Every sprint. Thinking about what could go wrong and planning to avoid it when it does.

@techpresso1 Writing, then building. It’s all relaxing to me!
The entire process should be able to generate runbooks and scripts from a CI/CD pipeline.

I need deliverables to focus. The deliverables define the schedule.

I got sloppy. July 4th was the original ship date, and it came and went.

The project will keep the command line program for local processing of files. It will add an extensible API server for common runbook processing tasks.

This iteration will redefine the runbook YAML format to allow for limited scripting.

On switching from Jira here are my notes:…

I may switch eventually (just not for this iteration). I wanted to have all docs, tickets, and code in GitHub but I needed a schedule more than colocation.

I have been looking into the new #GitHubProjects feature to replace my #JiraCloud instance.

I figured that if the ticket I was working on were closer to the code that would not be bad.

Besides, some people really hate #Jira. There are even websites dedicated to it!
Here is the stack that I have decided upon:

- Monorepo for all project code
- GitHub Actions for CI/CD
- GitHub Wiki for technical docs (including use cases)
- .NET 6 (no switch to Go)
- GNU Emacs for source
- Jira for tickets
- Docker & Docker Compose

I have been working toward making my development simpler by using less tools.

I have been reviewing how I want to restructure the project. Everything from language to CI/CD was on the table.

My goal was to simplify until the development was fun again.

"Never change compilers before a release."

That was the advice given to me by my boss 32 years ago. Now that I am looking toward a new version for the runbook compiler it is time to change some things up.

Using the GitHub Wiki to record them keeps them close to the code. Using a monorepo keeps everything in a single place.

This is one of the books I keep referring to for use case design:…

#UseCases #BuildInPublic
In my view they play *THE* role in defining features. Nothing can beat a detailed path of events.

I am reading #TAOCP as well and have started using Knuth's method for recording algorithms in the events.…

#UseCases #BuildInPublic
I am a use case kind of guy. It is a factor of the period, the 90s, when I started developing.

The larger the project the more use cases helped me.

Today I use them to nail the workflow of whatever I am working on.

#UseCases #BuildInPublic
I am not a *huge* fan of the flat top-level pages but an outline is produced from the markdown. Things are looking up for the GitHub Wiki.

+1 for the TOC

My goal is to have design docs stay fresh. I believe keeping them close to the source code should push them in that direction.

Keeping design docs in #Confluence and the code in GitHub introduced a lot of friction.

Trying GitHub Wiki for design docs and GitHub Pages for end user docs.

+1 for GitHub Pages using Jekyll
+1 for publishing to a custom domain

#BuildInPublic #GitHubPages
GitHub Wiki appears limited but still trying. There is value in keeping the design docs with the code.

-1 for GitHub for limited index
-1 for no sub-pages or categories
-1 for no TOC

The sidebar is a workaround for limited doc features.

#BuildInPublic #GitHubWiki
Using… to get at files quicker than only using `dired`.

Working in Emacs has made my coding more intentional.

My MVP is still a product I want to take pride in and NOT just *get it done* in any way shape of form.

#buildinpublic #emacs
I do miss the project or solution view of the traditional IDE when using Emacs.

Looking for solutions to help on this front.

#buildinpublic #emacs
I recently switched from #VisualStudioCode to #GnuEmacs for my programming tasks. It is slow and steady, and I like it.

I still use VSCode and Typora for blog stuff. Writing is a bit different and requires a different toolset.

Added… to my doc project. It had broken links!

I assumed .md -> .html links would be handled by Jekyll a.k.a. GitHub Pages.

It turns out that is not true. Thanks to @benbalter for being the top search result and providing a solution.