blog.kgb33.dev

How I vibe

2026-07-11T00:00:00+00:00

I am a process driven developer. I find my work more fulfilling when I understand and am confident in my solution.</p>

Solving the problem is more rewarding than knowing the answer.</p>

But, Developers are paid to provide answers and AI provides a lot of answers. This post outlines my setup, workflow, and gotchas.</p>

Setup</h1>

git</code> Worktrees</h2>
I use hidden-bare git worktrees to allow me to have multiple agents
running at the same time.</p>
~/Code/myRepo</span></span>
├── .git</span></span>
├── .myRepo</span></span>
├── feature</span></span>
│   ├── new-feature-one </span></span>
│   └── new-feature-two</span></span>
└── main</span></span>
</span></code></pre>
To set this up, you clone the repository into the .myRepo</code> folder,
then .git</code> is a simple redirection to that folder.</p>
❯</span> mkdir</span> myRepo</span></span>
❯</span> cd</span> myRepo</span></span>
❯</span> git</span> clone</span> -</span>-bare</span> $</span>REPO_URL</span> .myRepo</span></span>
❯</span> echo</span> "</span>gitdir: ./.myRepo</span>"</span> ></span> .git</span></span>
❯</span> git</span> config</span> remote.origin.fetch</span> "</span>+refs/heads/*:refs/remotes/origin/*</span>"</span> </span></span>
</span></code></pre>
The last line is really important if you ever want to review your coworkers'
work; it tells git how to fetch remote branches within the worktrees.</p>

Note: When using Graphite (or manually stacking changes), each stack gets its own worktree.</p>
</blockquote>
At work, where I'm making a lot more branches, I have a script that creates the worktree, installs all the
dependencies, and opens it in tmux</code>.</p>
tmux</code></h2>
Worktrees map 1:1 with Tmux sessions. I have three key components that make
tmux function: a CLI tool create sessions, a fuzzy finder for those
sessions, and Claude status for each session shown in the fuzzy finder.</p>
First, my script - bmm</code></a> - just reads the current git repository
and branch/worktree name and creates or attaches to a tmux session. Next, I
have a Television</a> picker to
switch tmux sessions. The picker's preview panel also shows the status of all
Claude Code sessions. This lets me quickly see what agents need my attention.
You can find the
picker</a>,
preview</a>,
and claude code
hooks</a>
at their respective links. Lastly, I have a tmux key-bind (<prefix>-t</code>) to open
the picker in a popup window.</p>
Other Small Setup Notes</h2>

Write a script to create worktrees & install dependencies for repositories you branch in often.</li>
Have a dedicated thumb key for the tmux prefix.</li>
</ul>
Workflow</h1>
After creating the worktree, I use a customized version of obra/superpowers</code> to guide the agent, steps with human interaction are denoted by "H". The agent is always in "auto" mode, I don't use "plan" mode.</p>

(H) Prompt

(H+A) Refine</li>
</ul>
</li>
Implement

Automated Feedback</li>
</ul>
</li>
(H) Code Review

Back to Prompt/Implement, maybe with a /compact</code>.</li>
</ul>
</li>
</ul>
My initial prompts are often a short, bulleted descriptions of what needs to be
done. Sometimes the ticket can be used with light editing. Creating a larger
more detailed plan is the left to the agent. It's very important to verify the
agents plan during the "Refine" step, it's easier to correct the agent before it
starts writing code and dilutes its context. The implementation steps are almost
completely agent driven. However, it does rely on a thorough, reliant, and fast
automated checks.</p>
Lastly, the Code Review step is just boring old code review. I have a NeoVim
plugin that allows me to annotate the changes locally, much like the GihHub PR
review process. nvim +Review</code> pulls up the current unstaged changes, and nvim +"Review commits"</code> lets me select a span to review.</p>
Depending on the scale of the changes, I'll have the agent make
a new plan, or for simple fixes it can go straight to implementation. If the
changes are completely wrong, use the existing context in the agent to generate
a 'seed' prompt to steer a fresh agent in the right direction.</p>



Configuring Neovim with fennel and home-manager
2025-12-23T00:00:00+00:00
Home manager is a dotfiles manager that declaratively manages your configs using Nix.</p>
One of the many programs that Home manager can configure is Neovim; it can even trivially install
plugins, LSPs, and formatters, no lazy/mason/whatever needed.</p>
The below config installs Telescope, and adds/configures nvim-lspconfig</code> using Lua.</p>
{</span>pkgs</span>,</span> ...</span>}</span>:</span> {</span></span>
  programs</span>.</span>neovim</span> =</span> {</span></span>
    enable</span> =</span> true</span>;</span></span>
    plugins</span> =</span> with</span> pkgs</span>.</span>vimPlugins</span>;</span> [</span></span>
      telescope-nvim</span></span>
      {</span></span>
        plugin</span> =</span> nvim-lspconfig</span>;</span></span>
        config</span> =</span> builtins</span>.</span>readFile</span> ./nvim/plugins/lspconfig.lua</span>;</span></span>
        type</span> =</span> "</span>lua</span>"</span>;</span></span>
      }</span></span>
    ]</span>;</span></span>
  }</span>;</span></span>
}</span></span></code></pre>
Note the type = "lua";</code> attribute; it accepts your standard lua</code> and viml</code>,
but we're more interested in the more lispy option: fennel</code>.</p>
  type</span> =</span> mkOption</span> {</span></span>
        type</span> =</span> types</span>.</span>either</span> (</span>types</span>.</span>enum</span> [</span></span>
          "</span>lua</span>"</span></span>
          "</span>viml</span>"</span></span>
          "</span>teal</span>"</span></span>
          "</span>fennel</span>"</span></span>
        ]</span>)</span> types</span>.</span>str</span>;</span></span>
        description</span> =</span> "</span>Language used in config. Configurations are aggregated per-language.</span>"</span>;</span></span>
        default</span> =</span> "</span>viml</span>"</span>;</span></span>
      }</span>;</span></span></code></pre>
But, if we scroll down in that same file
(modules/programs/neovim.nix</code></a>),
it only automatically combines and adds config</code> values for plugins configured
with Lua or Vimscript. it just, silently ignores plugin configs with type
fennel</code> or teal</code>. That's fair - only Vimscript and Lua are first-party
options, but its still a little disappointing.</p>
We can do it ourselves though using
Hotpot</a> and
programs.neovim.plugins._.runtime</code>. The latter allows us to add files to
Neovim's runtime directory. While Hotpot will automagically enable require</code>-ing any fennel
files in <runtimepath>/fnl/</code> directory as-if they were Lua files.</p>
So, our plugin array changes to:</p>
plugins</span> =</span> with</span> pkgs</span>.</span>vimPlugins</span>;</span> [</span></span>
  {</span></span>
    plugin</span> =</span> telescope-nvim</span>;</span></span>
    type</span> =</span> "</span>fennel</span>"</span>;</span></span>
    runtime</span>.</span>"</span>fnl/telescopeOptions.fnl</span>"</span>.</span>text</span> =</span> builtins</span>.</span>readFile</span> ./nvim/fnl/telescope.fnl</span>;</span></span>
  }</span></span>
  {</span></span>
    plugin</span> =</span> hotpot-nvim</span>;</span></span>
    config</span> =</span> let</span></span>
      requireables</span> =</span></span>
        config</span>.</span>programs</span>.</span>neovim</span>.</span>plugins</span></span>
        |></span> builtins</span>.</span>filter</span> (</span>p</span>:</span> p</span>.</span>type</span> ==</span> "</span>fennel</span>"</span>)</span></span>
        |></span> builtins</span>.</span>concatMap</span> (</span>p</span>:</span> builtins</span>.</span>attrNames</span> p</span>.</span>runtime</span>)</span></span>
        |></span> builtins</span>.</span>map</span> (</span>rtf</span>:</span> lib</span>.</span>removeSuffix</span> "</span>.fnl</span>"</span> (</span>builtins</span>.</span>baseNameOf</span> rtf</span>)</span>)</span>;</span></span>
    in</span></span>
      ''</span></span>
        require("hotpot")</span></span>
      ''</span></span>
      +</span> lib</span>.</span>concatStrings</span> (</span>map</span> (</span>name</span>:</span> "</span>require(</span>\"</span>${</span>name</span>}</span>\"</span>)</span>\n</span>"</span>)</span> requireables</span>)</span>;</span></span>
    type</span> =</span> "</span>lua</span>"</span>;</span></span>
  }</span></span>
]</span>;</span></span></code></pre>
The Hotpot configuration simply gets the names of all the fennel runtime files,
and requires them in init.lua</code>. Additionally, the plugin order only affects
the order that the Lua configs are concatenated into init.lua</code>. Nix will
correctly resolve the requireables</code> array - without infinite recursion - every
time.</p>

Note: You cannot name your runtimedir fennel file the same name as the plugin!
require("telescope")</code> will load the plugin, not your config for it.</p>
</blockquote>
For non-plugin configuration, you can add them to Hotpot's runtime</code> attribute, then manually add them to requireables</code>. Just make sure hotpot</code> is required first!</p>
{</span></span>
  plugin</span> =</span> hotpot-nvim</span>;</span></span>
  runtime</span>.</span>"</span>fnl/options.fnl</span>"</span>.</span>text</span> =</span> builtins</span>.</span>readFile</span> ./nvim/fnl/options.fnl</span>;</span></span>
  config</span> =</span> let</span></span>
    requireables</span> =</span></span>
      [</span>"</span>hotpot</span>"</span> "</span>options</span>"</span>]</span></span>
      ++</span> (</span>config</span>.</span>programs</span>.</span>neovim</span>.</span>plugins</span></span>
        |></span> builtins</span>.</span>filter</span> (</span>p</span>:</span> p</span>.</span>type</span> ==</span> "</span>fennel</span>"</span>)</span></span>
        |></span> builtins</span>.</span>concatMap</span> (</span>p</span>:</span> builtins</span>.</span>attrNames</span> p</span>.</span>runtime</span>)</span></span>
        |></span> builtins</span>.</span>map</span> (</span>p'</span>:</span></span>
          p'</span></span>
          |></span> builtins</span>.</span>baseNameOf</span></span>
          |></span> lib</span>.</span>removeSuffix</span> "</span>.fnl</span>"</span>)</span>)</span>;</span></span>
  in</span></span>
    lib</span>.</span>concatStrings</span> (</span>map</span> (</span>name</span>:</span> "</span>require(</span>\"</span>${</span>name</span>}</span>\"</span>)</span>\n</span>"</span>)</span> requireables</span>)</span>;</span></span>
  type</span> =</span> "</span>lua</span>"</span>;</span></span>
}</span></span></code></pre>


Gleam + `perf`
2025-12-06T00:00:00+00:00
I'm doing Advent of Code in Gleam this year, and my Day 4, Part 2 solution has
by far the longest runtime so far.</p>
About 36 seconds on Erlang, and 100x that on JavaScript.</p>
❯ hyperfine -- 'gleam run'</span></span>
Benchmark 1: gleam run</span></span>
  Time (mean ± σ):     36.096 s ±  0.318 s    [User: 36.195 s, System: 0.162 s]</span></span>
  Range (min … max):   35.744 s … 36.593 s    10 runs</span></span>
</span>
❯ hyperfine -- 'gleam run --target javascript --runtime bun'</span></span>
Benchmark 1: gleam run --target javascript --runtime bun</span></span>
  Time (mean ± σ):     3350.699 s ± 80.544 s    [User: 3403.290 s, System: 139.388 s]</span></span>
  Range (min … max):   3220.262 s … 3530.858 s    10 runs</span></span></code></pre>
Beside the obvious, my O(n³)</code> algorithm, whats making this so slow? perf</code> can help us find out.</p>

We can't hook perf</code> directly into gleam run</code>, we have to run the generated Erlang code directly.</p>
gleam build</span></span>
erl -pa build/dev/erlang/*/ebin -eval 'aoc2025:main().' -noshell -s init stop</span></span></code></pre>
Now, to record the performance; Erlang has great documentation on this - Linux perf support</a>.</p>
perf record --call-graph=fp \</span></span>
    -- erl +JPperf true +S 1 \</span></span>
    -pa build/dev/erlang/*/ebin \</span></span>
    -eval 'aoc2025:main().' \</span></span>
    -noshell -s init stop</span></span></code></pre>
And view it via perf report -g</code>, to generate a flame graph, replace pref record --call-graph=fp</code> with
flamegraph</code></a>. Likewise, you can
use samply record</code></a> to use Firefox as the UI.</p>
</p>
From the TUI report (via perf report -g</code>), most of the time is spent in eq</code> via list.contains</code>.</p>
- 98.16% $day4:can_move/2</span></span>
  - 91.11% $'gleam@list':filter_loop/3</span></span>
    - 80.83% $'gleam@list':contains/2</span></span>
        69.62% eq</span></span></code></pre>
And the relevant gleam code:</p>
pub</span> fn</span> can_move</span>(</span>roll: </span>Roll</span>, </span>grid: </span>List</span>(</span>Roll</span>)</span>) </span>-></span> Bool</span> {</span></span>
  let</span> offsets </span>=</span> [</span></span>
    #(</span>-</span>1</span>, </span>-</span>1</span>),</span></span>
    #(</span>-</span>1</span>, </span>0</span>),</span></span>
    #(</span>-</span>1</span>, </span>1</span>),</span></span>
    #(</span>0</span>, </span>-</span>1</span>),</span></span>
    #(</span>0</span>, </span>1</span>),</span></span>
    #(</span>1</span>, </span>-</span>1</span>),</span></span>
    #(</span>1</span>, </span>0</span>),</span></span>
    #(</span>1</span>, </span>1</span>),</span></span>
  ]</span></span>
</span>
  let</span> neigbors </span>=</span></span>
    offsets</span></span>
    |></span> list.</span>map</span>(</span>shift_roll</span>(</span>roll, </span>_</span>)</span>)</span></span>
    |></span> list.</span>filter</span>(</span>list.</span>contains</span>(</span>grid, </span>_</span>)</span>)</span></span>
</span>
  list.</span>length</span>(</span>neigbors</span>)</span> <</span> 4</span></span>
}</span></span>
</span></code></pre>
So, the easy fix is to use a set instead of a list.</p>
And looking at hyperfine, it significantly spead up the process:</p>
❯ hyperfine -- 'gleam run'</span></span>
Benchmark 1: gleam run</span></span>
  Time (mean ± σ):     702.5 ms ±  15.0 ms    [User: 943.2 ms, System: 179.2 ms]</span></span>
  Range (min … max):   680.0 ms … 730.8 ms    10 runs</span></span>
</span>
❯ hyperfine -- 'gleam run --target javascript --runtime bun'</span></span>
Benchmark 1: gleam run --target javascript --runtime bun</span></span>
  Time (mean ± σ):      5.292 s ±  0.085 s    [User: 5.650 s, System: 0.384 s]</span></span>
  Range (min … max):    5.209 s …  5.463 s    10 runs</span></span></code></pre>
And perf no longer shows the massive amount of time spent in eq</code>.</p>
</p>


Packaging Rust programs with Nix
2025-06-28T00:00:00+00:00

What is Nix?</h1>
Nix is a functional DSL designed to define derivations</strong> from a set of
inputs. The implementation (also called nix</code>) then realizes</strong> these
derivations into artifacts.</p>

Nix Crash Course</h1>
#</span> crashCourse.nix</span></span>
{</span>...</span>}</span>:</span> let</span></span>
  #</span> Variables are defined in let-in blocks</span></span>
</span>
  #</span> All functions are unary, but attr sets can be unpacked.</span></span>
  #</span> The `...` ignores other attributes (if any)</span></span>
  mult</span> =</span> {</span>x</span>,</span> y</span> ?</span> 2</span>,</span> ...</span>}</span>:</span> x</span> *</span> y</span>;</span></span>
  tripler</span> =</span> x</span>:</span> mult</span> {</span> x</span> =</span> x</span>;</span> y</span> =</span> 3</span>;</span>}</span>;</span></span>
in</span> {</span></span>
  #</span> Parentheses are not needed when calling functions.</span></span>
  doubled</span> =</span> mult</span> {</span>x</span> =</span> 4</span>;</span>}</span>;</span></span>
  tripled</span> =</span> tripler</span> 6</span>;</span></span>
  #</span> But are still used to group expressions</span></span>
  quadrupled</span> =</span> (</span>x</span>:</span> mult</span> {</span>x</span> =</span> x</span>;</span> y</span> =</span> 4</span>}</span>)</span> 2</span>;</span></span>
  </span></span>
  #</span> An "attribute set" is the basic building block for</span></span>
  #</span> all nix expressions.</span></span>
  bar</span> =</span> {</span></span>
    thisIs</span> =</span> "</span>an attr set</span>"</span>;</span></span>
    somePath</span> =</span> ./src/main.rs</span>;</span></span>
    lists</span> =</span> [</span>"</span>are</span>"</span> "</span>space</span>"</span> "</span>seperated</span>"</span>]</span>;</span></span>
  }</span>;</span></span>
}</span></span></code></pre>

How Do I use it</h1>
A common 'entry-point' for a nix expression is a "nix flake".</p>

Nix flakes provide a standard way to write Nix expressions (and therefore
packages) whose dependencies are version-pinned in a lock file. [...] A flake
refers to a file-system tree whose root directory contains the Nix file
specification called flake.nix</code>.</p>
</blockquote>

Flake Overview</h1>
A flake has four sections, description</code>, inputs</code>, outputs</code>, nixConfig</code>.</p>
Anything and everything (except the file-system tree containing the
flake**) that is used in the flake must be in the inputs attribute.</p>
outputs</code> is a function that takes the inputs as parameters and returns an attribute set.
This attribute set has several standard attributes, the most common is packages</code>.</p>
{</span></span>
  description</span> =</span> "</span>A super basic Flake</span>"</span>;</span></span>
</span>
  inputs</span>.</span>nixpkgs</span>.</span>url</span> =</span> "</span>github:nixos/nixpkgs/nixos-unstable</span>"</span>;</span></span>
</span>
  outputs</span> =</span> {</span>self</span>,</span> ...</span>}</span> @</span> inputs</span>:</span> {</span></span>
    packages</span>.</span>x86_64-linux</span>.</span>default</span> =</span> inputs</span>.</span>nixpkgs</span>.</span>legacyPackages</span>.</span>x86_64-linux</span>.</span>hello</span>;</span></span>
  }</span>;</span></span>
}</span></span>
</span></code></pre>

The nix</code> cli acts as a bridge between flakes and the daemon.</p>
To view the inputs of a flake, use nix flake metadata</code></p>
❯</span> nix</span> flake</span> metadata</span></span>
Resolved</span> URL:</span>  path:/home/kgb33/Code/SpokaneTechUserGroups/rust/nix-talk</span></span>
Locked</span> URL:</span>    path:/home/kgb33/Code/SpokaneTechUserGroups/rust/nix-talk?lastModified=</span>1761015353</span>&</span>narHash</span>=</span>s</span>h</span>a</span>2</span>5</span>6</span>-</span>U</span>v</span>z</span>%</span>2</span>B</span>K</span>B</span>B</span>e</span>V</span>B</span>3</span>p</span>D</span>v</span>L</span>O</span>q</span>r</span>V</span>T</span>V</span>x</span>2</span>L</span>A</span>o</span>v</span>p</span>3</span>/</span>x</span>3</span>X</span>E</span>K</span>V</span>X</span>S</span>X</span>x</span>c</span>M</span>0</span>%</span>3</span>D</span></span>
Description:</span>   A</span> super</span> basic</span> Flake</span></span>
Path:</span>          /nix/store/r9r47ax0frr24ny7c436qjlr9f3s8lb1-source</span></span>
Last</span> modified:</span> 2025-10-20</span> 19:55:53</span></span>
Inputs:</span></span>
└───nixpkgs:</span> github:nixos/nixpkgs/5e2a59a5b1a82f89f2c7e598302a9cacebb72a67?narHash=sha256-K5Osef2qexezUfs0alLvZ7nQFTGS9DL2oTVsIXsqLgs%3D</span> (2025-10-19</span> 12:55:10</span>)</span></span></code></pre>
To view the outputs of a flake, use nix flake show</code>.</p>
❯</span> nix</span> flake</span> show</span></span>
path:/home/kgb33/Code/SpokaneTechUserGroups/rust/nix-talk?lastModified</span>=</span>1</span>7</span>6</span>1</span>0</span>1</span>5</span>3</span>5</span>3</span>&</span>narHash</span>=</span>s</span>h</span>a</span>2</span>5</span>6</span>-</span>U</span>v</span>z</span>%</span>2</span>B</span>K</span>B</span>B</span>e</span>V</span>B</span>3</span>p</span>D</span>v</span>L</span>O</span>q</span>r</span>V</span>T</span>V</span>x</span>2</span>L</span>A</span>o</span>v</span>p</span>3</span>/</span>x</span>3</span>X</span>E</span>K</span>V</span>X</span>S</span>X</span>x</span>c</span>M</span>0</span>%</span>3</span>D</span></span>
└───packages</span></span>
    └───x86_64-linux</span></span>
        └───default:</span> package</span> '</span>hello-2.12.2</span>'</span></span></code></pre>

To actually use the outputs, use nix run</code> or nix build</code> or nix shell</code> -
depending on the output and what you want to do with it.</p>
❯</span> nix</span> run</span></span>
Hello,</span> world!</span></span>
</span>
❯</span> nix</span> build</span></span>
❯</span> ./result/bin/hello</span></span>
Hello,</span> world!</span></span>
</span>
❯</span> nix</span> shell</span></span>
❯</span> hello</span></span>
Hello,</span> world!</span></span></code></pre>

[!INFO] By default, the flake in the current directory is used but you can access remote flakes too.
For convince, nixpkgs</code> is an alias for git+https://github.com/NixOS/nixpkgs</code>.</p>
</blockquote>
❯ nix run nixpkgs#hello</span></span>
Hello, world!</span></span></code></pre>

DevShells</h1>
Before we can create a new rust project for us to package, we need to install Cargo.</p>
Nix provides a way to declaratively create a development shell using the devShells</code> output.</p>
{</span></span>
  description</span> =</span> "</span>A super basic Flake</span>"</span>;</span></span>
</span>
  inputs</span>.</span>nixpkgs</span>.</span>url</span> =</span> "</span>github:nixos/nixpkgs/nixos-unstable</span>"</span>;</span></span>
</span>
  outputs</span> =</span> {</span>self</span>,</span> ...</span>}</span> @</span> inputs</span>:</span> let</span></span>
    system</span> =</span> "</span>x86_64-linux</span>"</span>;</span></span>
    pkgs</span> =</span> import</span> inputs</span>.</span>nixpkgs</span> {</span>inherit</span> system</span>;</span>}</span>;</span></span>
  in</span> {</span></span>
    packages</span>.</span>"</span>${</span>system</span>}</span>"</span>.</span>default</span> =</span> pkgs</span>.</span>hello</span>;</span></span>
</span>
    devShells</span>.</span>"</span>${</span>system</span>}</span>"</span>.</span>default</span> =</span> pkgs</span>.</span>mkShell</span> {</span></span>
      packages</span> =</span> with</span> pkgs</span>;</span> [</span>cargo</span> llvm</span>]</span>;</span></span>
    }</span>;</span></span>
  }</span>;</span></span>
}</span></span></code></pre>
Now, our flake output shows the development shell, and we can activate it using nix develop</code>.</p>
❯ nix flake show</span></span>
warning: Git tree '/home/kgb33/Code/SpokaneTechUserGroups/rust/nix-talk' is dirty</span></span>
git+file:///home/kgb33/Code/SpokaneTechUserGroups/rust/nix-talk</span></span>
├───devShells</span></span>
│   └───x86_64-linux</span></span>
│       └───default: development environment 'nix-shell'</span></span>
└───packages</span></span>
    └───x86_64-linux</span></span>
        └───default: package 'hello-2.12.2'</span></span>
</span>
</span>
❯ nix develop</span></span></code></pre>

[!TIP] Use Direnv to keep your shell / status line. Nix devShells use bash by default.</p>
</blockquote>

The Rust Package</h1>
We're going to keep the rust package simple, just the default hello world from
cargo init</code>.</p>
❯</span> cargo</span> run</span></span>
    Finished</span> `</span>dev</span>`</span> profile</span> [unoptimized</span> +</span> debuginfo]</span> target</span>(</span>s</span>)</span> in</span> 0.01s</span></span>
     Running</span> `</span>target/debug/nix-talk</span>`</span></span>
Hello,</span> world!</span></span></code></pre>

What about Rust?</h1>
Nix has a builtin buildRustPackage</code> function, we just need to pass the name,
version, source, and Cargo.lock</code>.</p>
{</span></span>
  description</span> =</span> "</span>A super basic Flake</span>"</span>;</span></span>
</span>
  inputs</span>.</span>nixpkgs</span>.</span>url</span> =</span> "</span>github:nixos/nixpkgs/nixos-unstable</span>"</span>;</span></span>
</span>
  outputs</span> =</span> {</span>self</span>,</span> ...</span>}</span> @</span> inputs</span>:</span> let</span></span>
    system</span> =</span> "</span>x86_64-linux</span>"</span>;</span></span>
    pkgs</span> =</span> import</span> inputs</span>.</span>nixpkgs</span> {</span>inherit</span> system</span>;</span>}</span>;</span></span>
</span>
    srugNix</span> =</span> pkgs</span>.</span>rustPlatform</span>.</span>buildRustPackage</span> {</span></span>
      pname</span> =</span> "</span>srug-nix</span>"</span>;</span></span>
      version</span> =</span> "</span>v0.1.0</span>"</span>;</span></span>
</span>
      src</span> =</span> pkgs</span>.</span>lib</span>.</span>cleanSource</span> ./.</span>;</span></span>
      cargoLock</span>.</span>lockFile</span> =</span> ./Cargo.lock</span>;</span></span>
    }</span>;</span></span>
  in</span> {</span></span>
    packages</span>.</span>"</span>${</span>system</span>}</span>"</span>.</span>default</span> =</span> srugNix</span>;</span></span>
</span>
    devShells</span>.</span>"</span>${</span>system</span>}</span>"</span>.</span>default</span> =</span> pkgs</span>.</span>mkShell</span> {</span></span>
      packages</span> =</span> with</span> pkgs</span>;</span> [</span>cargo</span> llvm</span>]</span>;</span></span>
    }</span>;</span></span>
  }</span>;</span></span>
}</span></span></code></pre>

Now, let's (try to) run our program using nix:</p>
❯ nix run</span></span>
warning: Git tree '/home/kgb33/Code/SpokaneTechUserGroups/rust/nix-talk' is dirty</span></span>
error:</span></span>
       …(stack trace truncated; use '--show-trace' to show the full, detailed trace)</span></span>
</span>
       error: path '/nix/store/4nr2b0q3z3a6bvqhjglxb2wlbl2habwy-source/Cargo.lock' does not exist</span></span>
</span>
❯ ls /nix/store/4nr2b0q3z3a6bvqhjglxb2wlbl2habwy-source/</span></span>
 flake.lock   flake.nix</span></span>
</span>
❯ ls .</span></span>
󰣞 src   target   Cargo.lock   Cargo.toml   flake.lock   flake.nix</span></span></code></pre>
As part of Nix's functional purity, only files tracked in Git are copyed into
the store, so as far as Nix is concerned, Cargo.lock</code> doesn't exist.</p>
❯ git add --intent-to-add Cargo.* src/main.rs</span></span>
</span>
❯ nix run</span></span>
warning: Git tree '/home/kgb33/Code/SpokaneTechUserGroups/rust/nix-talk' is dirty</span></span>
Hello, world!</span></span></code></pre>
🎉🎉</p>

There are also third party libraries that make more advanced programs easier to package.</p>
My preference is ipelkov/crane</a>. To use it,
we just need to add it as an input, and update the contents of the let-in</code>
block:</p>
{</span></span>
  description</span> =</span> "</span>A super basic Flake</span>"</span>;</span></span>
</span>
  inputs</span> =</span> {</span></span>
    nixpkgs</span>.</span>url</span> =</span> "</span>github:nixos/nixpkgs/nixos-unstable</span>"</span>;</span></span>
    crane</span>.</span>url</span> =</span> "</span>github:ipetkov/crane</span>"</span>;</span></span>
  }</span>;</span></span>
</span>
  outputs</span> =</span> {</span>self</span>,</span> ...</span>}</span> @</span> inputs</span>:</span> let</span></span>
    system</span> =</span> "</span>x86_64-linux</span>"</span>;</span></span>
    pkgs</span> =</span> import</span> inputs</span>.</span>nixpkgs</span> {</span>inherit</span> system</span>;</span>}</span>;</span></span>
</span>
    crane</span> =</span> inputs</span>.</span>crane</span>.</span>mkLib</span> pkgs</span>;</span></span>
</span>
    src</span> =</span> crane</span>.</span>cleanCargoSource</span> ./.</span>;</span></span>
</span>
    commonArgs</span> =</span> {</span></span>
      inherit</span> src</span>;</span></span>
    }</span>;</span></span>
</span>
    cargoArtifacts</span> =</span> crane</span>.</span>buildDepsOnly</span> commonArgs</span>;</span></span>
</span>
    srugNix</span> =</span> crane</span>.</span>buildPackage</span> (</span></span>
      commonArgs</span> //</span> {</span>inherit</span> cargoArtifacts</span>;</span>}</span></span>
    )</span>;</span></span>
  in</span> {</span></span>
    packages</span>.</span>"</span>${</span>system</span>}</span>"</span>.</span>default</span> =</span> srugNix</span>;</span></span>
</span>
    devShells</span>.</span>"</span>${</span>system</span>}</span>"</span>.</span>default</span> =</span> pkgs</span>.</span>mkShell</span> {</span></span>
      packages</span> =</span> with</span> pkgs</span>;</span> [</span>cargo</span> llvm</span>]</span>;</span></span>
    }</span>;</span></span>
  }</span>;</span></span>
}</span></span></code></pre>

There are a few upgrades over buildRustPackage</code> already.</p>
src = crane.cleanCargoSource ./.;</code> is specialized for Cargo repositories, so
less unneeded files are copied into the store.</p>
cargoArtifacts = crane.buildDepsOnly commonArgs;</code> builds all (zero) of our
dependencies separate step, so they will not be recompiled every build.</p>
Additionally, Crane allows us to easily map CI style checks to our third flake output: checks</code>.</p>

{</span></span>
  inputs</span> =</span> {</span>.</span>.</span>.</span>}</span>;</span></span>
</span>
  outputs</span> =</span> {</span>self</span>,</span> ...</span>}</span> @</span> inputs</span>:</span> let</span></span>
    .</span>.</span>.</span></span>
  in</span> {</span></span>
    packages</span>.</span>"</span>${</span>system</span>}</span>"</span>.</span>default</span> =</span> srugNix</span>;</span></span>
</span>
    devShells</span>.</span>"</span>${</span>system</span>}</span>"</span>.</span>default</span> =</span> pkgs</span>.</span>mkShell</span> {</span></span>
      packages</span> =</span> with</span> pkgs</span>;</span> [</span>cargo</span> llvm</span>]</span>;</span></span>
    }</span>;</span></span>
</span>
    checks</span>.</span>"</span>${</span>system</span>}</span>"</span> =</span> {</span></span>
      inherit</span> srugNix</span>;</span></span>
</span>
      clippy</span> =</span> crane</span>.</span>cargoClippy</span> (</span></span>
        commonArgs</span></span>
        //</span> {</span></span>
          inherit</span> cargoArtifacts</span>;</span></span>
          cargoClippyExtraArgs</span> =</span> "</span>--all-targets -- --deny warnings</span>"</span>;</span></span>
        }</span></span>
      )</span>;</span></span>
</span>
      fmt</span> =</span> crane</span>.</span>cargoFmt</span> {</span></span>
        inherit</span> src</span>;</span></span>
      }</span>;</span></span>
    }</span>;</span></span>
  }</span>;</span></span>
}</span></span></code></pre>
Now, after adding an used variable to src/main.rs</code>, we can run nix flake check</code>:</p>
❯ nix flake show</span></span>
git+file:///home/kgb33/Code/SpokaneTechUserGroups/rust/nix-talk?ref=refs/heads/main&rev=71365e62ae101ebb1828444d22ea07e6be8514b5</span></span>
├───checks</span></span>
│   └───x86_64-linux</span></span>
│       ├───clippy: derivation 'srug-nix-clippy-0.1.0'</span></span>
│       ├───fmt: derivation 'srug-nix-fmt-0.1.0'</span></span>
│       └───srugNix: derivation 'srug-nix-0.1.0'</span></span>
├───devShells</span></span>
│   └───x86_64-linux</span></span>
│       └───default: development environment 'nix-shell'</span></span>
└───packages</span></span>
    └───x86_64-linux</span></span>
        └───default: package 'srug-nix-0.1.0'</span></span>
</span>
❯ nix flake check</span></span>
error: builder for '/nix/store/y7rxcz3f5f355d57rd9l99z7a1ryr8nm-srug-nix-clippy-0.1.0.drv' failed with exit code 101;</span></span>
       last 25 log lines:</span></span>
       > +++ command cargo clippy --release --locked --all-targets -- --deny warnings</span></span>
       >     Checking srug-nix v0.1.0 (/build/source)</span></span>
       > error: unused variable: `unused_var`</span></span>
       >  --> src/main.rs:2:13</span></span>
       >   |</span></span>
       > 2 |     let mut unused_var = "abc";</span></span>
       >   |             ^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_unused_var`</span></span>
       >   |</span></span>
       >   = note: `-D unused-variables` implied by `-D warnings`</span></span>
       >   = help: to override `-D warnings` add `#[allow(unused_variables)]`</span></span>
       ></span></span>
       > error: variable does not need to be mutable</span></span>
       >  --> src/main.rs:2:9</span></span>
       >   |</span></span>
       > 2 |     let mut unused_var = "abc";</span></span>
       >   |         ----^^^^^^^^^^</span></span>
       >   |         |</span></span>
       >   |         help: remove this `mut`</span></span>
       >   |</span></span>
       >   = note: `-D unused-mut` implied by `-D warnings`</span></span>
       >   = help: to override `-D warnings` add `#[allow(unused_mut)]`</span></span>
       ></span></span>
       > error: could not compile `srug-nix` (bin "srug-nix" test) due to 2 previous errors</span></span>
       > warning: build failed, waiting for other jobs to finish...</span></span>
       > error: could not compile `srug-nix` (bin "srug-nix") due to 2 previous errors</span></span>
       For full logs, run:</span></span>
         nix log /nix/store/y7rxcz3f5f355d57rd9l99z7a1ryr8nm-srug-nix-clippy-0.1.0.drv</span></span></code></pre>
Running a single check directly is often better developer experience. But I've
found that adding the checks to your flake is super convenient to run all of
them at once, especially if you're using nix to build or distribute the final
artifact.</p>

Questions</h1>

Lets Talk system</code></h1>
So far, we've been hardcoding system</code> to x86-64-linux</code>, but Nix works on more
than just run of the mill Linux.</p>
However, because nix is pure, the current system cannot affect the output of a
flake.</strong> To demonstrate this, let's build our flake for additional systems:</p>

{</span></span>
  description</span> =</span> "</span>A super basic Flake</span>"</span>;</span></span>
</span>
  inputs</span> =</span> {</span></span>
    nixpkgs</span>.</span>url</span> =</span> "</span>github:nixos/nixpkgs/nixos-unstable</span>"</span>;</span></span>
    crane</span>.</span>url</span> =</span> "</span>github:ipetkov/crane</span>"</span>;</span></span>
  }</span>;</span></span>
</span>
  outputs</span> =</span> {</span></span>
    self</span>,</span></span>
    nixpkgs</span>,</span></span>
    ...</span></span>
  }</span> @</span> inputs</span>:</span> let</span></span>
    forAllSystems</span> =</span> func</span>:</span></span>
      nixpkgs</span>.</span>lib</span>.</span>genAttrs</span></span>
      [</span>"</span>x86_64-linux</span>"</span> "</span>aarch64-darwin</span>"</span>]</span> (</span></span>
        system</span>:</span></span>
          func</span> (</span>import</span> nixpkgs</span> {</span>inherit</span> system</span>;</span>}</span>)</span></span>
      )</span>;</span></span>
  in</span> {</span></span>
    packages</span> =</span> forAllSystems</span> (</span>pkgs</span>:</span> let</span></span>
      crane</span> =</span> inputs</span>.</span>crane</span>.</span>mkLib</span> pkgs</span>;</span></span>
</span>
      src</span> =</span> crane</span>.</span>cleanCargoSource</span> ./.</span>;</span></span>
</span>
      commonArgs</span> =</span> {</span></span>
        inherit</span> src</span>;</span></span>
      }</span>;</span></span>
</span>
      cargoArtifacts</span> =</span> crane</span>.</span>buildDepsOnly</span> commonArgs</span>;</span></span>
</span>
      srugNix</span> =</span> crane</span>.</span>buildPackage</span> (</span></span>
        commonArgs</span> //</span> {</span>inherit</span> cargoArtifacts</span>;</span>}</span></span>
      )</span>;</span></span>
    in</span> {</span></span>
      default</span> =</span> srugNix</span>;</span></span>
    }</span>)</span>;</span></span>
</span>
    devShells</span> =</span> forAllSystems</span> (</span>pkgs</span>:</span> {</span></span>
      default</span> =</span> pkgs</span>.</span>mkShell</span> {</span></span>
        packages</span> =</span> with</span> pkgs</span>;</span> [</span>cargo</span> llvm</span>]</span>;</span></span>
      }</span>;</span></span>
    }</span>)</span>;</span></span>
  }</span>;</span></span>
}</span></span></code></pre>

The key here is the forAllSystems</code> function.</p>
forAllSystems</span> =</span> func</span>:</span></span>
  nixpkgs</span>.</span>lib</span>.</span>genAttrs</span></span>
  [</span>"</span>x86_64-linux</span>"</span> "</span>aarch64-darwin</span>"</span>]</span> (</span></span>
    system</span>:</span></span>
      func</span> (</span>import</span> nixpkgs</span> {</span>inherit</span> system</span>;</span>}</span>)</span></span>
  )</span>;</span></span></code></pre>
Its argument is another function func</code>, which it uses to populate the
sub-attributes created by nixpkgs.lib.genAttrs</code>.</p>
If we manually expand the call to genAttrs</code>, the function would look as follows:</p>
forAllSystems</span> =</span> func</span>:</span> {</span></span>
    "</span>x86_64-linux</span>"</span> =</span> func</span> (</span>import</span> nixpgks</span> {</span> inherit</span> "</span>x86_64-linux</span>"</span>;</span> }</span>)</span>;</span></span>
    "</span>aarch64-darwin</span>"</span> =</span> func</span> (</span>import</span> nixpgks</span> {</span> inherit</span> "</span>aarch64-darwin</span>"</span>;</span> }</span>)</span>;</span></span>
}</span></span></code></pre>

Now, if we show all the flake output, we can see the Darwin system.</p>
❯ nix flake show --all-systems</span></span>
git+file:///home/kgb33/Code/SpokaneTechUserGroups/rust/nix-talk</span></span>
├───devShells</span></span>
│   ├───aarch64-darwin</span></span>
│   │   └───default: development environment 'nix-shell'</span></span>
│   └───x86_64-linux</span></span>
│       └───default: development environment 'nix-shell'</span></span>
└───packages</span></span>
    ├───aarch64-darwin</span></span>
    │   └───default: package 'srug-nix-0.1.0'</span></span>
    └───x86_64-linux</span></span>
        └───default: package 'srug-nix-0.1.0'</span></span></code></pre>
Every defined system is part of the output, the nix</code> command just chooses the
right one. You can ever force it to use the wrong system:</p>
❯ nix run .#packages.x86_64-linux.default</span></span>
Hello, world!</span></span>
❯ nix run .#packages.aarch64-darwin.default</span></span>
error: a 'aarch64-darwin' with features {} is required to build '/nix/store/vlvsdb6l9zw6hrmpv384w1mzimbvb3fv-dummy.rs.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test}</span></span></code></pre>

Great, now we can use our flake on any supported system. However, this has a
downside, if we want to reuse our package definition, we'd have to wrap it in
another function.</p>
Luckily, we can pull in another input to clean this up a bit: hercules-ci/flake-parts</a>.</p>

{</span></span>
  description</span> =</span> "</span>A super basic Flake</span>"</span>;</span></span>
</span>
  inputs</span> =</span> {</span></span>
    nixpkgs</span>.</span>url</span> =</span> "</span>github:nixos/nixpkgs/nixos-unstable</span>"</span>;</span></span>
    crane</span>.</span>url</span> =</span> "</span>github:ipetkov/crane</span>"</span>;</span></span>
    flake-parts</span>.</span>url</span> =</span> "</span>github:hercules-ci/flake-parts</span>"</span>;</span></span>
  }</span>;</span></span>
</span>
  outputs</span> =</span> {</span></span>
    self</span>,</span></span>
    flake-parts</span>,</span></span>
    ...</span></span>
  }</span> @</span> inputs</span>:</span></span>
    flake-parts</span>.</span>lib</span>.</span>mkFlake</span> {</span>inherit</span> inputs</span>;</span>}</span> {</span></span>
      systems</span> =</span> [</span>"</span>x86_64-linux</span>"</span> "</span>aarch64-darwin</span>"</span>]</span>;</span></span>
      perSystem</span> =</span> {</span></span>
        self'</span>,</span></span>
        inputs'</span>,</span></span>
        pkgs</span>,</span></span>
        ...</span></span>
      }</span>:</span> let</span></span>
        crane</span> =</span> inputs</span>.</span>crane</span>.</span>mkLib</span> pkgs</span>;</span></span>
        src</span> =</span> crane</span>.</span>cleanCargoSource</span> ./.</span>;</span></span>
</span>
        commonArgs</span> =</span> {</span></span>
          inherit</span> src</span>;</span></span>
        }</span>;</span></span>
</span>
        cargoArtifacts</span> =</span> crane</span>.</span>buildDepsOnly</span> commonArgs</span>;</span></span>
</span>
        srugNix</span> =</span> crane</span>.</span>buildPackage</span> (</span></span>
          commonArgs</span> //</span> {</span>inherit</span> cargoArtifacts</span>;</span>}</span></span>
        )</span>;</span></span>
      in</span> {</span></span>
        packages</span>.</span>default</span> =</span> srugNix</span>;</span></span>
        devShells</span>.</span>default</span> =</span> pkgs</span>.</span>mkShell</span> {</span></span>
          packages</span> =</span> with</span> pkgs</span>;</span> [</span>cargo</span> llvm</span>]</span>;</span></span>
        }</span>;</span></span>
        checks</span> =</span> {</span></span>
          inherit</span> srugNix</span>;</span></span>
</span>
          clippy</span> =</span> crane</span>.</span>cargoClippy</span> (</span></span>
            commonArgs</span></span>
            //</span> {</span></span>
              inherit</span> cargoArtifacts</span>;</span></span>
              cargoClippyExtraArgs</span> =</span> "</span>--all-targets -- --deny warnings</span>"</span>;</span></span>
            }</span></span>
          )</span>;</span></span>
</span>
          fmt</span> =</span> crane</span>.</span>cargoFmt</span> {</span></span>
            inherit</span> src</span>;</span></span>
          }</span>;</span></span>
        }</span>;</span></span>
      }</span>;</span></span>
    }</span>;</span></span>
}</span></span></code></pre>
If you squint a little, you can see our old flake (perSystem</code>) wrapped with
logic that generates it for each system (flake-parts.lib.mkFlake</code>).</p>


Avante.nvim + Home-Manager
2025-06-08T00:00:00+00:00
How to vendor and patch avante.nvim</a>, when
configuring Neovim using home manager.</p>


Nix Tricks
2025-02-05T00:00:00+00:00
Nix is the best configuration management tool. Declarative, programmable,
version controlled machine configs, what more could you want?</p>


Regex Capture Groups: Restructure text using NeoVim
2024-07-25T00:00:00+00:00
One small issue I've encountered lately is being able to quickly and
automatically convert text from one structured form to another.</p>
My go-to tool for this has been macros, but regex capture groups should work just as well.</p>


Manage custom packages using Nix and Home-Manager
2024-06-04T00:00:00+00:00
TLDR: Use Nix to install and manage your personal packages instead of build</code>/cp</code>/chmox +x</code>.</p>


`Maybe` I Like Haskell
2024-04-18T00:00:00+00:00
Problem</h1>
I'm writing a CLI tool - called hmm</code></a> - in Haskell that manages tmux
sessions. By default, I want it to open a session named after the current git
context. I.e. if I'm working on branch bar</code> in repo foo</code> I want the session
to be named foo-bar</code>. However, on rare occasions, I might want to override
either value. To do this, I have optional command line flags</p>
$ hmm</span></span>
</span>
Usage: hmm [-r|--repo REPO] [-b|--branch BRANCH]</span></span>
</span>
  Manages tmux sessions.</span></span>
</span>
Available options:</span></span>
  -r,--repo REPO           First part of the tmux session name.</span></span>
  -b,--branch BRANCH       Second part of the tmux session name.</span></span>
  -h,--help                Show this help text</span></span></code></pre>
These options are defined as parsers, then collected into a Options</code> object.
Don't worry about what each cryptic symbol means, just know that branch</code> is a
parser that will parse an optional CLI flag into a Maybe String</code>.</p>
branch</span> ::</span> Parser</span> (</span>Maybe</span> String</span>)</span></span>
branch </span>=</span></span>
  optional </span>$</span></span>
    strOption</span></span>
      (</span> long </span>"</span>branch</span>"</span></span>
          <></span> short </span>'</span>b</span>'</span></span>
          <></span> metavar </span>"</span>BRANCH</span>"</span></span>
          <></span> help </span>"</span>Second part of the tmux session name.</span>"</span></span>
      )</span></span>
</span>
data</span> Options</span> =</span> Options</span></span>
  {</span> optRepo</span> ::</span> Maybe</span> String</span>,</span></span>
    optBranch</span> ::</span> Maybe</span> String</span></span>
  }</span></span></code></pre>
Importantly, because my defaults are calculated at run-time using sub-process
(i.e. git</code>) they are 'impure' have the type IO String</code>, not</strong> String</code> like
the parser expects. This means I cannot add the default values to the parser,
meaning it needs to parse to a Maybe String</code> type to implement the
functionality I want.</p>
Maybe</code> Sidebar</h2>
In Haskell, Maybe</code> is a lot like Rust's Option<T></code> (especially if you adjust the formatting a bit).</p>
data</span> Maybe</span> T</span> =</span> </span></span>
    Nothing</span> </span></span>
    |</span> Just</span> (</span>T</span>)</span></span></code></pre>enum</span> Option</span><</span>T</span>></span> {</span></span>
    None</span>,</span></span>
    Some</span>(</span>T</span>)</span>,</span></span>
}</span></span></code></pre>
These types both represent the computational context of a nullable value.
They both encapsulate some value - or the lack there of. They force surrounding
code to deal with the potentially null value. Not only that, but they also provide a
way to turn Maybe a</code> into Maybe b</code> without caring if the encapsulated value
is null.</p>
Pattern Matching solutions</h1>
The first and most obvious solution solutions was to pattern match on every
combination of inputs, for a total of four function signatures. However, this
will quickly grow out of hand as more flags are added - at a rate of $n^2$
where n is the number of optional inputs.</p>
entrypoint</span> ::</span> Options</span> -></span> IO</span> (</span>)</span></span>
entrypoint </span>Options</span> (</span>r b</span>)</span> =</span> _ </span>--</span> Both Options provided.</span></span>
entrypoint </span>Options</span> (</span>r </span>Nothing</span>)</span> =</span> _ </span>--</span> Only Repo Provided.</span></span>
entrypoint </span>Options</span> (</span>Nothing</span> b</span>)</span> =</span> _ </span>--</span> Only Branch Provided.</span></span>
entrypoint </span>Options</span> (</span>Nothing</span> Nothing</span>)</span> =</span> _ </span>--</span> No options provided.</span></span></code></pre>
The second solution was to build up the entry point by currying partial
functions for each option. In the end, I never implemented this solution
because it didn't seem quite right; how would you elegantly curry functions
based on what they're called with? So in the end I looked for different options.</p>
Solution</h1>
The final solution was surprisingly simple. Haskell has a function maybe</code>
(lowercase 'm') that is a lot like Rust's Option::map_or</code>. The docs for maybe</code> and both definitions
are below. Note that both functions sill return a value wrapped in a Maybe</code>/Option</code>.</p>

The maybe</code> function takes a default value, a function, and a Maybe</code> value. If
the Maybe</code> value is Nothing</code>, the function returns the default value.
Otherwise, it applies the function to the value inside the Just</code> and returns
the result. - Hackage</a></p>
</blockquote>
maybe</span> ::</span> b</span> -></span> (</span>a</span> -></span> b</span>)</span> -></span> Maybe</span> a</span> -></span> b</span></span>
maybe n _ </span>Nothing</span>  =</span> n</span></span>
maybe _ f </span>(</span>Just</span> x</span>)</span> =</span> f x</span></span></code></pre>pub</span> fn</span> map_or</span><</span>U</span>,</span> F</span>></span>(</span>self</span>,</span> default</span>:</span> U</span>,</span> f</span>:</span> F</span>)</span> -></span> U</span></span>
where</span></span>
    F</span>:</span> FnOnce</span>(</span>T</span>)</span> -></span> U</span>,</span></span>
{</span></span>
    match</span> self</span> {</span></span>
        Some</span>(</span>t</span>)</span> =></span> f</span>(</span>t</span>)</span>,</span></span>
        None</span> =></span> default</span>,</span></span>
    }</span></span>
}</span></span></code></pre>
So, my entry point is as follows:</p>
hmm</span> ::</span> Options</span> -></span> IO</span> (</span>)</span></span>
hmm options </span>=</span> do</span></span>
  r </span><-</span> maybe computeDefaultRepo return </span>(</span>optRepo options</span>)</span></span>
  b </span><-</span> maybe computeDefaultBranch return </span>(</span>optBranch options</span>)</span></span>
  let</span> sessionName </span>::</span> String</span> =</span> r </span>++</span> "</span>-</span>"</span> ++</span> b</span></span></code></pre>
A few things to note:</p>

r</code> and b</code> have types String</code></li>
computeDefaultXYZ</code> has type IO String</code></li>
</ul>
Now, lets break apart maybe computeDefaultRepo return (optRepo options)</code>. From
the signature above, b</code> corresponds to computeDefaultRepo</code>, so it has type
IO String</code>. Next, return</code> is the function that maps (a -> b)</code>; It has the
signature return :: a -> m a</code>. Lastly, (optRepo options)</code> is the Maybe String</code> monad from the parser. Plugging our known types into the maybe</code> signature we get:</p>

b</code> = IO String</code></li>
a</code> = String</code></li>
maybe :: (IO String) -> (String -> (IO String)) -> Maybe String -> IO String</code></li>
</ul>
Now, we've solved our original problem and converted the default and provided
values to the same type! Just one last issue. I said that r</code> and b</code> have
types String</code>, but I also said that the maybe</code> function returns a IO String</code>. This is where the do</code> and <-</code> notation come in. They allow us to
extract the contents from the IO</code> monad on the condition that we return a
IO</code> monad.</p>
Summary</h1>
Overall, I really enjoyed writing Haskell. It felt more like programming
types</em> and structure</em> rather than programming business logic</em> - a breath of
fresh air from the Python I'm used to. At the same time Haskell's compiler was
a lot less picky to work with than Rust's; although the short and simple nature
of this program also probably helped.</p>


TiL... `hugo server` ignores variables set in `config.toml`
2024-01-24T00:00:00+00:00
</span>
I tried out Bernard</a> on the live blog, it reported hundreds of bad links. Almost
every single one linked to localhost:1313</code> - Hugo's default baseURL and port. Even though I had set baseURL</code> in
my config.toml</code>.</p>
baseURL</span> =</span> '</span>https://blog.kgb33.dev</span>'</span></span>
...</span></span></code></pre>
Luckily, the fix was fairly simple, just pass the config variables as flags to hugo server</code>.
Plus, I probably don't need live reloading on the live server...</p>
 ENTRY_POINT = [</span></span>
     "/bin/hugo",</span></span>
     "server",</span></span>
     "--bind=0.0.0.0",</span></span>
+</span>    "--baseURL=https://blog.kgb33.dev/",</span></span>
+</span>    "--appendPort=false",</span></span>
+</span>    "--disableLiveReload=true",</span></span>
 ]</span></span></code></pre>


Troubleshooting Failing Commands
2023-12-17T00:00:00+00:00
I created a new command on my Discord bot (PR #16</a>)
that fetches the status of the Minecraft servers running on
minecraft.kgb33.dev</code>. When running locally it worked perfectly, but when
running in production it fails silently. This post outlines the debugging steps
I took to solve the issue.</p>


TiL..About `git` remotes
2023-07-15T00:00:00+00:00
I'm trying out daily driving NixOS and one of the problems I have is knowing
when updates are available. On NixOS all the packages are defined in a
giant</strong> git repository -
github:nixos/nixpkgs</a> - and updates are
commits to the various branches (called channels) of this repo. Then, my system
is locked to a particular commit hash for whichever channel I'm comfortable
running. Thus, to find out if there are updates available I just have to check
if the most recent hash is in the lock file.</p>


Playing in Traefik
2023-04-13T00:00:00+00:00

Go play in traffic - Parents everywhere</p>
</blockquote>


Gitting There on Argos
2023-04-10T00:00:00+00:00

Once more they lifted sails, and once more they took the Argo into the open
sea. - Jason and Medea</p>
</blockquote>


Talosian Terraforming
2023-04-03T00:00:00+00:00

Thrice a day would Talos stride around the island; his brazen feet were
tireless. - The Story of Perseus</p>
</blockquote>


Proxmox HTTPs Certificates
2023-01-25T00:00:00+00:00
Ordering LetsEncrypt certificates for your Proxmox servers is almost too easy,
no more self-signed certificates!</p>


Terraforming Proxmox
2023-01-12T00:00:00+00:00
I recently experimented automating VM creation across my
Proxmox cluster. I tested out several tools before finally
settling on Terraform and cloning from a Proxmox "template".</p>

Goals</a></li>
Other Tools Considered</a>

Ansible</a></li>
Cloud-init</a></li>
iPXE (and netboot.xyz)</a></li>
HashiCorp Packer</a></li>
</ul>
</li>
Pre-Terraforming Work</a>

Setting Up Storage</a></li>
Creating the "Template"</a></li>
</ul>
</li>
Terraforming Proxmox</a>

Defining Providers</a></li>
Resource Definition</a></li>
Variable Variables</a>

SOPS Aside</a></li>
</ul>
</li>
Network Configuration</a></li>
</ul>
</li>
Provisioners</a>

Connection</a></li>
File</a></li>
Ansible</a></li>
Final Scripts</a></li>
</ul>
</li>
Conclusion</a></li>
</ul>
Goals</h1>
The overall goal is to use Infrastructure-as-code tools to create multiple VMs
on various Proxmox nodes. Eventually, these VMs will run a Kubernetes cluster.
Theses VMs should be created (and destroyed) using a single command. Manual
steps need to be kept to a minimum and should only have to be done once,
regardless of how many times the VMs are (re)created. Importantly, having
persistent storage for these VMs is a non-issue. None of the (planned)
Kubernetes services need persistent storage, so that will be a project for
another day.</p>
Other Tools Considered</h1>
I had a pretty good idea that I would end up using Terraform,
but I also tried out a bunch of other tools too.</p>
Ansible</h2>
My original plan was to use the Proxmox module</a>
and keep everything in Ansible. Unfortunately, the configuration was obtuse
and I could only clone templates (no iso/iPXE).</p>
Cloud-init</h2>
This tool and the next two all deal with the creation/configuration
of the base image. Of these three, cloud-init was my favorite. Unfortunately,
I was unable to get it to work in Proxmox even though it worked on a local qemu</code>
VM. I even went so far as to create a TFTP server raincloud</a>.</p>
iPXE (and netboot.xyz)</h2>
These two tools were also super cool. I ended up setting boot.netboot.xyz</code> to the default
netboot url. Eventually, I could (and probably will) use cloud-init and iPXE to
automate the Creating the "Template"</a> step.</p>
HashiCorp Packer</h2>
Packer would be an amazing tool if</em> I needed to build a custom iso, but
I don't. I also think that learning the previous two tools will be a better
use of my time. I honestly don't think I will ever have a reason to use packer
in my homelab.</p>
Pre-Terraforming Work</h1>
As alluded to previously, there are a few steps that
still need to be done manually - namely, setting up the VM
to clone.</p>
Setting Up Storage</h2>
My Proxmox cluster is pretty bare bones, so there is (was)
no network storage. Unfortunately, when cloning a VM the new
VM must have the same storage, i.e. a template on Host A's local storage
cannot be cloned to Host B's local storage.</p>
My solution for this was to create a Ceph storage pool. I created
it following Deploy Hyper-Converged Ceph Cluster</a>,
although I only have one Object Storage Daemon (OSD), so I had to
manually lower the min placement groups to one.</p>
Creating the "Template"</h2>
Creating the template is super easy. Just follow the Ubuntu server
install - make sure to import your ssh keys! Once the installation
is complete, remove the CD-ROM disk and reboot. When the server comes
back up install Ansible. Shut the machine back down and then it's good to go.</p>

Note: You don't need to convert the VM to a template. In fact, if you
don't it's easier to make changes to the base image.</p>
</blockquote>
Terraforming Proxmox</h1>
The meat and potatoes happens here. To start, run terraform init</code>
in the directory your Terraform code will be in.</p>
Defining Providers</h2>
Next, you have to define what providers Terraform
should use. You can think of providers kind of like plugins.</p>
Create a file called provider.tf</code> containing the following:</p>
terraform</span> {</span></span>
  required_version</span> =</span> "</span>v1.3.7</span>"</span></span>
  required_providers</span> {</span></span>
    proxmox</span> =</span> {</span></span>
      source</span>  =</span> "</span>Telmate/proxmox</span>"</span></span>
      version</span> =</span> "</span>2.9.11</span>"</span></span>
    }</span></span>
  }</span></span>
}</span></span>
</span>
provider</span> "proxmox"</span> {</span></span>
  pm_api_url</span> =</span> "</span>https://10.0.0.101:8006/api2/json</span>"</span></span>
  pm_timeout</span> =</span> 10000</span></span>
}</span></span></code></pre>
The terraform</code> block defines what version of the Terraform CLI
to use, i.e. the output from terraform version</code>. It also defines
the required providers, these can be found at the
Terraform Registry</a>.</p>
The provider "proxmox"</code> block lets you set configuration options.
Documentation for these options is located on the provider page at the
previous link.</p>
Resource Definition</h2>
The proxmox provider defines two resources, one to manage VMs
and another to manage LXC Containers. The general format to define
resources is as follows:</p>
resource</span> "resource_type"</span> "resource_name"</span> {</span></span>
    #</span> Content ...</span></span>
}</span></span></code></pre>
So my (super) truncated resource definition is below:</p>
resource</span> "proxmox_vm_qemu"</span> "k8s-VMs"</span> {</span></span>
  for_each</span> =</span> {</span></span>
    #</span> Glint</span></span>
    gnar</span> =</span> {</span></span>
      ip</span>      =</span> "</span>10.0.0.112</span>"</span>,</span></span>
      macaddr</span> =</span> "</span>22:d4:92:84:f1:bb</span>"</span>,</span></span>
      id</span>      =</span> 501</span>,</span></span>
      node</span>    =</span> "</span>glint</span>"</span></span>
    }</span></span>
    #</span> ...</span></span>
  }</span></span>
  name</span>        =</span> "</span>${</span>each</span>.</span>key</span>}</span>.kgb33.dev</span>"</span></span>
  desc</span>        =</span> "</span>K8s Node #1 </span>\n</span> ${</span>each</span>.</span>key</span>}</span>.kgb33.dev </span>\n</span> IP: </span>${</span>each</span>.</span>value</span>.</span>ip</span>}</span>"</span></span>
  target_node</span> =</span> each</span>.</span>value</span>.</span>node</span></span>
  clone</span>       =</span> "</span>ubuntu22.04-template</span>"</span></span>
  vmid</span>        =</span> each</span>.</span>value</span>.</span>id</span></span>
  #</span> ...</span></span>
}</span></span></code></pre>Variable Variables</h2>
In the above snippet you might have noticed the for_each</code> block.
This means that for each "key" in the block another resource will
be created. When a for_each</code> block is present the special each.key</code>
and each.value</code> variables are available.
You can use these variables as follows:</p>
#</span> String Interpolation</span></span>
name</span> =</span> "</span>${</span>each</span>.</span>key</span>}</span>.kgb33.dev</span>"</span> #</span> "gnar.kgb33.dev"</span></span>
</span>
#</span> Using `each.value`</span></span>
target_node</span> =</span> each</span>.</span>value</span>.</span>node</span> #</span> "glint"</span></span></code></pre>
You can also define variables outside of resources.
Create a new block:</p>
variable</span> "variable_name"</span> {</span></span>
    type</span> =</span> String</span></span>
    #</span> More options ...</span></span>
}</span></span></code></pre>
Then it can be used via var.variable_name</code>.</p>
SOPS Aside</h3>
There are several ways to set these variables, one of which is to
use a special terraform.tfvars</code> file. This is a simple text file
in the format variable_name = value</code>.</p>
I'm using SOPS</a> to securely store these
sensitive variables in git. I wrote a short getting starting guide
here</a>.</p>
Network Configuration</h2>
To be able to access the newly created VMs they need to have static IP
addresses. Thus, the ip</code> and madaddr</code> values in the for_each</code> block
need to match the values in OPNsense.</p>
</p>
Currently, the static IP addresses are manually configured in OPNsense, but
that could probably be automated using
ansibleguy/collection_opnsense</a>.</p>
Provisioners</h1>
Great, now we can create VMs by cloning a template, but they aren't very
useful. In fact, they all have the same host name. Luckily, Terraform can run
"provisioners" on newly created resources. These provisioners are defined
inside the resource block and are run top-to-bottom.</p>
Connection</h3>
In order for provisioners to be useful they need to be able to connect
to the resource they are provisioning.
Unsurprisingly, the connection</code> block defines this.</p>
resource</span> "proxmox_vm_qemu"</span> "k8s-VMs"</span> {</span></span>
  #</span> ...</span></span>
  connection</span> {</span></span>
      host</span>  =</span> each</span>.</span>value</span>.</span>ip</span></span>
      type</span>  =</span> "</span>ssh</span>"</span></span>
      user</span>  =</span> "</span>kgb33</span>"</span></span>
      agent</span> =</span> true</span></span>
  }</span></span>
  #</span> ...</span></span></code></pre>
Each option is pretty self explanatory.
However, if no valid keys are present in your ssh-agent</code>
the connection will fail via timeout.</p>
File</h3>
The first provisioner I defined copies an Ansible playbook to the host.</p>
  #</span> ...</span></span>
  provisioner</span> "file"</span> {</span></span>
    source</span>      =</span> "</span>./provisioners/highstate.yaml</span>"</span></span>
    destination</span> =</span> "</span>highstate.yaml</span>"</span></span>
  }</span></span>
  #</span> ...</span></span></code></pre>Ansible</h3>
The second provisioner runs the playbook - yes, that is all on one line.</p>
  #</span> ...</span></span>
  provisioner</span> "remote-exec"</span> {</span></span>
    inline</span> =</span> [</span></span>
      "</span>ansible-playbook --connection=local --inventory 127.0.0.1, --limit 127.0.0.1 highstate.yaml -e 'ansible_become_password=</span>${</span>var</span>.</span>become_password</span>}</span>' --extra-vars 'host=</span>${</span>each</span>.</span>key</span>}</span>'</span>"</span>,</span></span>
    ]</span></span>
  }</span></span>
  #</span> ...</span></span>
</span></code></pre>
A better way of running the previous two provisioners would be using
local-exec</code> (instead of file</code> and remote-exec</code>). You would create a
null_resource</code> that depends on the "k8s-VMs" resource defined. Then the null
resource has a local-exec</code> provisioner that runs the ansible playbook.
But that sounds a project for later!</p>
Final Scripts</h3>
Lastly, I have a provisioner that outputs some basic information about the
host.</p>
  #</span> ...</span></span>
  provisioner</span> "remote-exec"</span> {</span></span>
    inline</span> =</span> [</span></span>
      "</span>hostname -f</span>"</span>,</span></span>
      "</span>ip addr</span>"</span></span>
    ]</span></span>
  }</span></span>
}</span></span></code></pre>
This is in a different provisioner block from the former because
var.become_password</code> is marked as sensitive, so the stdout</code> is redacted.</p>
Conclusion</h1>
I can now create (and destroy) several VMs in Proxmox using
Terraform. To achieve this I had to first do some manual setup:</p>

Create a ceph pool with a single OSD.</li>
Create a Ubuntu 22.04 base image.</li>
Add Static IP address leases to my DHCP server.</li>
</ul>
Next, I created a Terraform script that contains the following:</p>

I used a for_each</code> block to define each VM I want to create.</li>
Defined general VM information - node, vmid, IP, etc.</li>
Defined connection info for the provisioners.</li>
Created three provisioners that do post-creation setup.</li>
</ul>
The complete setup (at the time of writing) can be seen in at
hash 05a0997</a>.</p>



Sops and Age
2023-01-08T00:00:00+00:00
</span>
Recently I've needed a more convenient & scalable way to manage secrets for
my various projects. Some of my requirements include:</p>

Enables secrets to be versioned controlled.</li>
Doesn't require additional infrastructure - i.e. HashiCorp Vault or AWS Secrets Manager.</li>
Open Source</li>
</ul>
SOPS</a> (S</em>ecrets OP</em>erationS</em>) is a "simple and flexible tool for
managing secrets", and it matches all of my criteria.</p>
It works nicely with git by making line wise changes - instead of scrambling
the whole file. Check out the blame</a> on their example.yaml</code>.</p>
I don't need to spin up a complex server to use it - just add a directory
in $XDG_CONFIG_HOME</code>.</p>
Sops also has several methods to encrypt files, and a file
can be encrypted using multiple methods at once. In my case I'll
be using age</code></a>.</p>



  
pacman -Syu age sops
...
mkdir -p $XDG_CONFIG_HOME/sops/age/
age-keygen -o $XDG_CONFIG_HOME/sops/age/keys.txt
Public key: age1rswjdjwg997gwj35lrpxf4km56s7z5wp9funzhe0drfzrlfjwc5q7ykyhm
sops -a age1rswjdjwg997gwj35lrpxf4km56s7z5wp9funzhe0drfzrlfjwc5q7ykyhm foo.yaml
ls
foo.yaml
cat foo.yaml
  </code>
</pre>
h</span>ello</span>:</span> E</span>NC[AES256_GCM,data:33WO6zuQnePN1PXt7Y/1pJ2vd7ysminB5zPf8FL8znqVW872CyaN6cGxHyTjAA==,iv:nnRRYnG5kwAkwm2NMu/ZBIsj2qRss/o7lJx9ITKZtnU=,tag:e+lVO9EvmmV122di7pawHg==,type:str]</span></span>
p</span>le_key</span>:</span> E</span>NC[AES256_GCM,data:ClLs+wrb3EbCCHItpw==,iv:AnGO51gObJHwO2Fp7Ea1GW9+S+A9FDxBnzyfj9b8O4o=,tag:Tp+Q0SyA9mQAC1WtBGsrDw==,type:str]</span></span>
[</span>A</span>ES256_GCM</span>,</span>d</span>ata:15B3iNkpmj69MjnXrpYpfjs=</span>,</span>i</span>v:azLDwNsYe7rgiEV0cy1LlvOMin5fTzODd0HTBrv2CIA=</span>,</span>t</span>ag:OhWTEHXRkd7swEk6qTjJIg==</span>,</span>t</span>ype:comment</span>]</span></span>
p</span>le_array</span>:</span></span>
-</span> E</span>NC[AES256_GCM,data:1W7ZqbOq36BTDv+gUp8=,iv:gtpB3fnwmAugLcwiia/0D+eg8BbbJjFAW3db2Yow3Gw=,tag:FgSaieVIkLcGf83SnbJl5g==,type:str]</span></span>
-</span> E</span>NC[AES256_GCM,data:s/ChH3F/7Ukg36Ikpjo=,iv:8yWCi0t+7YV5G3XCMpC4v8xAXqXDRSfcgGX06F3ePzg=,tag:2bK/y0d3aFZURxrQPvbExA==,type:str]</span></span>
p</span>le_number</span>:</span> E</span>NC[AES256_GCM,data:yugG14+b2caLww==,iv:HFBS+5ZYPdi40EXFQoRNxHnJoHoPe1iDLRg8UR5xE0g=,tag:MXLqVJb1BWFN2ag0pBEHMQ==,type:float]</span></span>
p</span>le_booleans</span>:</span></span>
-</span> E</span>NC[AES256_GCM,data:mJhirw==,iv:Q9nTFWXeruVuWryusu38D+nyvot+zj6u8WO0VNVa3qA=,tag:Y/z/314z/Y9vLNtqzZMH4A==,type:bool]</span></span>
-</span> E</span>NC[AES256_GCM,data:w4FZGaw=,iv:9j6IQeDVKi1Ka9Jj+PjEid19ScXYmm/+j+gpIAlNJ2I=,tag:iwIxWc4+a/YY6mUKIM6SBw==,type:bool]</span></span>
:</span></span>
k</span>ms</span>:</span> [</span>]</span></span>
g</span>cp_kms</span>:</span> [</span>]</span></span>
a</span>zure_kv</span>:</span> [</span>]</span></span>
h</span>c_vault</span>:</span> [</span>]</span></span>
a</span>ge</span>:</span></span>
    -</span> r</span>ecipient</span>:</span> a</span>ge1q7ep9a2lapepu20hn0syg0h2hya6lynumh66sey3vkxcg9a35qsq7yza3r</span></span>
      e</span>nc</span>:</span> |</span></span>
        -----BEGIN AGE ENCRYPTED FILE-----</span></span>
        YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSB6ZTQ0NlNRUloveUdYWjZq</span></span>
        c0NYUlZwanE4VDlkZWF0MmVMOFhPeWRnU2lzCkR1bE9nUER2cjVPby9nc1lHUVdP</span></span>
        UDRIRnlPNEFoWEJrZUZCV0pwY2tsZlkKLS0tIEhWV0U0MTRKRENTWHJkWGVEem1U</span></span>
        RGo4Ym5JL1NhSDQxSzNrN3FiV0J4Q0UKqBZzFm1tGVLWtdooGPl/S58V3DqDxEir</span></span>
        YF2t15LPMo0HjYFjWGA4TfDEDYPLBh662e0v1jSx+epdClmm6dQqVQ==</span></span>
        -----END AGE ENCRYPTED FILE-----</span></span>
l</span>astmodified</span>:</span> "</span>2023-01-09T17:11:57Z</span>"</span></span>
m</span>ac</span>:</span> E</span>NC[AES256_GCM,data:zRI1mqwVMHHQ5tgDxZ0aMH2+sl/DvmL9h2/tfyFQubq2rlVZv/Y74zEoli3J13aF5ZRx0/06YenJ5cJz6bG8/77xMI0rsGCETS1YJKc9WP0SiTahO+BSPrW7UYw8ED+8hFMqqnz/wXouoBKvYPXxfM7OumzU7J2xERG6BPuvpkc=,iv:gXsTStUS8QhGqRt+3aFQBUQVnevhpegi//wlLUxuokQ=,tag:w8TAShyut2XQfWEagBcNBg==,type:str]</span></span>
p</span>gp</span>:</span> [</span>]</span></span>
u</span>nencrypted_suffix</span>:</span> _</span>unencrypted</span></span>
v</span>ersion</span>:</span> 3.7.3</span></span></code></pre>

Note: your Private & Public age key(s) are stored unencrypted
in $XDG_CONFIG_HOME/sops/age/keys.txt</code></p>
</blockquote>



2022 in Review
2022-12-31T00:00:00+00:00
2022 was a busy year, this is a concise review of almost everything
I did & learned.</p>
</p>


Cheat.sh + fzf
2022-12-10T00:00:00+00:00
If you've used a Unix system for any length of time you've probably read a man</code>
page or two. Right after opening your first man</code> page you might have googled
something along the lines of "How to search in a man page". man</code> pages are
dense, detailed, documents.</p>
On the other hand, cheat.sh</code></a> provides a short, community curated
cheat sheet</em> for many popular commands (and programming languages) filled with examples.</p>
However, the defacto interface to cheat.sh</code> is curl</code> - not very user friendly.
This walks through my development process of creating a shell script that:</p>


Filters cheat.sh</code> endpoints using fzf</code>.</p>
</li>

Formats the curl</code> request (both the url string and response data).</p>
</li>

Create a key bind to call the script.</p>
</li>

Inspiration</a></p>
</li>

Alternatives</a></p>

tldr</code></a></li>
cht.sh</code></a></li>
</ul>
</li>

Development</a></p>

Url Format</a></li>
Stringing it all together.</a>

Selecting the topic</a></li>
Paging the Cheat Sheet</a></li>
Combining the Two</a></li>
Complete* Script</a></li>
</ul>
</li>
Integrating ZLE</code></a>

The Widget</a></li>
ZLE Initiation</a></li>
</ul>
</li>
An Important Wrapper</a></li>
</ul>
</li>

Summary</a></p>
</li>

Gallery</a></p>
</li>
</ul>
Inspiration</h1>
"ThePrimeagen" published a video in Sept. 2021 with an identical concept.
Although his solution required manually updated local files to work and
spawns the results is a temporary tmux</code> window.
Check out the video</a>!</p>
Additionally, the fzf-git</code> source code</a> was
extremely helpful to use as a base.</p>
Alternatives</h1>
tldr</code></h2>
tldr.sh</code></a> is very similar to cheat.sh</code>, with a larger
focus on examples and cli clients. However, cheat.sh</code> has a larger library
and returns	the tldr</code> information in addition to any cheat.sh</code> specific
information.</p>
I used this tool prior to building my own.</p>
cht.sh</code></h2>
curl https://cht.sh/:cht.sh > .local/bin/cht.sh</code> downloads the official
cli tool. This solves the awkward curl command construction, but it's still
missing a nice fuzzy finding interface.</p>
Development</h1>
Url Format</h2>
The cheat.sh urls are formatted as follows:</p>
[https://]cheat.sh/{topic}?[options]</span></span></code></pre>

The https prefix is optional (thanks curl!)</li>
options include stuff like style & removing escape characters.</li>
topic</code> is the meat and potato of the url.</li>
</ul>
topic</code> can be formatted a number of different ways.</p>

The :</code> prefix denotes a special 'meta' url, e.x. cheat.sh/:help</code></li>
Sub-topics can be accessed via {topic}-{subtopic}</code>, e.x `cheat.sh/git-clone</li>
The ~</code> prefix denotes a search cheat.sh/git-clone~depth</code></li>
</ul>
cheat.sh/:list</code></h3>
cheat.sh/:list</code> is what makes this work. It returns a list of all
the valid topics, ready to be substituted into the url.</p>
Stringing it all together.</h2>
The script consists of two main parts, selecting the topic using fzf</code>,
and displaying the cheat-sheet for that topic.</p>
Selecting the topic</h3>
To select the topic we first get the special :list</code> endpoint,
then pipe that into fzf-tmux</code>.</p>

Note: fzf-tmux</code> is a special wrapper around fzf</code> that will open
the selection menu in a tmux pane when called in a tmux</code> session,
otherwise, it acts the same as normal fzf</code>.</p>
</blockquote>
curl --silent "cheat.sh/:list" | fzf-tmux</span></span></code></pre>
fzf</code> then returns the single entry, which conveniently
can be tacked on to the end cheat.sh/</code> of the URL.</p>
This can be extracted into the following function:</p>
STYLE</span>=</span>'</span>rrt</span>'</span></span>
</span>
__fzf_cheat_selector</span>(</span>)</span> {</span></span>
	curl</span> -</span>-silent</span> "</span>cheat.sh/:list</span>"</span> |</span> fzf-tmux</span> \</span></span>
	#</span> The followning lines are optional</span></span>
	-p</span> 70%,60%</span> \</span></span>
	-</span>-layout=reverse</span> -</span>-multi</span> \</span></span>
	-</span>-preview</span> "</span>curl --silent cheat.sh/{}\?style=</span>$</span>STYLE</span>"</span> \</span></span>
	-</span>-bind</span> "</span>?:toggle-preview</span>"</span> \</span></span>
	-</span>-preview-window</span> hidden,60%</span> \</span></span>
}</span></span></code></pre>

Note: If you do choose to have a preview window
make sure it defaults to closed to prevent excess
network calls.</p>
</blockquote>
Paging the Cheat Sheet</h3>
Now that we have our topic we can easily curl the cheat sheet,
making it look good is another story. Cheat.sh returns what I'm
going to call "terminal friendly" markdown. It (by default)
has super basic syntax highlighting, but we can improve it by passing
the result to a pager.</p>
I personally use bat</code></a> as my pager of choice,
but less</code>, glow</code></a>, or rich-cli</code></a> could all be used.</p>
It's fairly simple to pipe the cheat-sheet to these commands,
but whichever command you choose needs to be told that it
should render markdown.</p>
fzf_cheat_sh</span>(</span>)</span> {</span></span>
	curl</span> -</span>-silent</span> "</span>cheat.sh/</span>$</span>TOPIC</span>"</span> \</span></span>
	|</span> bat</span> -</span>-style=plain</span> -</span>l</span> markdown</span></span>
}</span></span></code></pre>Combining the Two</h3>
Easy, Now just to wire them together. Replace, $TOPIC</code> with
the following ${1:=$(__fzf_cheat_selector)}</code>.</p>
The ${1:=$val}</code> syntax means use the first variable, or if that
doesn't exist, use $val</code> as a default.</p>
Complete* Script</h3>
__fzf_cheat_selector</span>(</span>)</span> {</span></span>
        curl</span> -</span>-silent</span> "</span>cheat.sh/:list</span>"</span> \</span></span>
        |</span> fzf-tmux</span> \</span></span>
            -</span>p</span> 70%,60%</span> \</span></span>
            -</span>-layout=reverse</span> -</span>-multi</span> \</span></span>
            -</span>-preview</span> \</span></span>
            "</span>curl --silent cheat.sh/{}\?style=</span>$</span>STYLE</span>"</span> \</span></span>
            -</span>-bind</span> "</span>?:toggle-preview</span>"</span> \</span></span>
            -</span>-preview-window</span> hidden,60%</span> \</span></span>
}</span></span>
</span>
fzf_cheat_sh</span>(</span>)</span> {</span></span>
    curl</span> -</span>-silent</span> "</span>cheat.sh/</span>$</span>{</span>1</span>:=</span>$(</span>__fzf_cheat_selector</span>)</span>}</span>?style=</span>$</span>STYLE</span>"</span> \</span></span>
    |</span> bat</span> -</span>-style=plain</span></span>
}</span></span>
</span></code></pre>
This script is ready to go as-is. Just source in your .zshrc</code> and
run fzf_cheat_sh</code></p>
Integrating ZLE</code></h2>
If you use zsh</code> probably already used Zsh Line Editor</a> (zle),
possibly without even knowing about it. For example "vim" mode is built on top
of it.</p>
We're going to create a key bind that puts our fzf_cheat_sh</code> command on the
buffer line then run it. This has the added benefit of adding the command
(with the topic query) to the history.</p>
There are three parts, defining the "widget", adding it to zle</code>, and creating the
key bind.</p>
The Widget</h3>
_fzf_cheat_sh_widget</span>(</span>)</span> {</span></span>
    zle</span> push-input</span>;</span></span>
    BUFFER</span>=</span>"</span>fzf_cheat_sh </span>$(</span>__fzf_cheat_selector</span>)</span>"</span>;</span></span>
    zle</span> accept-line</span>;</span></span>
}</span></span></code></pre>
This function does three things:</p>

Removes all content from the line</li>
Sets the buffer to the fzf_cheat_sh command (and runs the fzf selector)</li>
Runs the command</li>
</ul>
ZLE Initiation</h3>
ZLE still needs to be told that the above widegt exists.</p>
__fzf_cheat_init</span>(</span>)</span> {</span></span>
  eval</span> "</span>zle -N _fzf_cheat_sh_widget</span>"</span></span>
  eval</span> "</span>bindkey '^_' _fzf_cheat_sh_widget</span>"</span></span>
}</span></span>
__fzf_cheat_init</span></span></code></pre>
Here, zle</code> is told about the widget. Then the key map is defined as (visually)
Ctrl+?</code>.</p>
An Important Wrapper</h2>
The whole script is wrapped in an if</code> statement so it
will only be loaded in an interactive terminal.</p>
if</span> [[</span> $</span>-</span> =~</span> i </span>]]</span>;</span> then</span></span>
</span>
#</span> The Whole Script Goes in Here</span></span>
</span>
fi</span></span></code></pre>Summary</h1>
When an new interactive</em> shell is started the commands and
zle plugin is loaded. Then the program can be started using
the key bind or by typing the command out manually.
Once the key bind is pressed zle remove the current content
from the buffer; prompts using the fzf</code> selector; then
pushes the command & topic to the buffer; then lastly runs the command.</p>
This simple & easy workflow is perfect for double-checking arguments,
flags, and common use cases without breaking your train of thought.</p>
Gallery</h1>


</p>



GPG Keys
2022-10-28T00:00:00+00:00
Have you ever wondered why (or how) someone's commit has a fancy "verified"</em> badge on Github?</p>
</p>
They have either created & committed from the Github web editor or signed their commit using a PKI key.</p>


Dagger in Github Actions
2022-10-09T00:00:00+00:00
It's been a while since part one and I've learned so much about automation and GitOps.
The overall goal for this project is still the same, an automated CI/CD system, but some
of the technologies have changed. This particular post is all about integrating Dagger and Github Actions.</p>


Daggerify the Blog - Part 1: Build
2022-03-30T00:00:00+00:00
The original deployment strategy (detailed here</a>) for this blog was
manual and error prone. The ideal goal is to use dagger</a> to build out
the whole CI/CD system; from building the image to deploying on a local Kubernetes cluster.</p>
Part 1 covers building the docker image and pushing it to the Github container registry.</p>


Point-to-Site Wireguard Configuration
2022-03-08T00:00:00+00:00
Configuring Wireguard to allow a "road-warrior" (aka point-to-site) setup
using OPNsense and systemd-networkd.</p>


Ansible for Localhost
2022-02-03T00:00:00+00:00
Ansible is a super powerful system configuration tool that is normally
used to manage sets of servers. However, as you might have derived from
the title it can also be used to configure a local deployment.</p>


Getting Going with Gitea
2022-01-23T00:00:00+00:00
Gitea</a> describes itself as a painless self-hosted Git service.
It has many of the same features as Git[hub/lab], but is much more
lightweight.</p>
This deployment runs in a Docker container on a Ubuntu 21.10 server.
The whole deployment uses ~2% of one CPU core, and ~2GB of RAM.
Easily runnable on a Raspberry Pi.</p>


Deploying `blog.kgb33.dev`
2021-12-17T00:00:00+00:00
This post will mostly mirror Hugo's quickstart guide</a>. With a few differences:
the theme and customization will be more specific, and will include the steps to get
Hugo into an production environment, including CI/CD and Let's Encrypt certificates.</p>

Questions</h1>

Other Tools Considered</h1>
I had a pretty good idea that I would end up using Terraform, but I also tried out a bunch of other tools too.</p>

Ansible</h2>
My original plan was to use the Proxmox module</a> and keep everything in Ansible. Unfortunately, the configuration was obtuse and I could only clone templates (no iso/iPXE).</p>

Terraforming Proxmox</h1>
The meat and potatoes happens here. To start, run `terraform init</code> in the directory your Terraform code will be in.</p>`

Combining the Two</h3>
Easy, Now just to wire them together. Replace, `$TOPIC</code> with the following ${1:=$(__fzf_cheat_selector)}</code>.</p>`
`The ${1:=$val}</code> syntax means use the first variable, or if that doesn't exist, use $val</code> as a default.</p>`

`Gallery</h1> </p>`

blog.kgb33.dev

How I vibe

Setup</h1>

Configuring Neovim with fennel and home-manager

Gleam + `perf`

Packaging Rust programs with Nix

Avante.nvim + Home-Manager

Nix Tricks

Regex Capture Groups: Restructure text using NeoVim

Manage custom packages using Nix and Home-Manager

`Maybe` I Like Haskell

TiL... `hugo server` ignores variables set in `config.toml`

Troubleshooting Failing Commands

TiL..About `git` remotes

Playing in Traefik

Gitting There on Argos

Talosian Terraforming

Proxmox HTTPs Certificates

Terraforming Proxmox

Sops and Age

2022 in Review

Cheat.sh + fzf

GPG Keys

Dagger in Github Actions

Daggerify the Blog - Part 1: Build

Point-to-Site Wireguard Configuration

Ansible for Localhost

Getting Going with Gitea

Deploying `blog.kgb33.dev`

blog.kgb33.dev

How I vibe

Setup</h1>

Configuring Neovim with fennel and home-manager

Gleam + `perf`

Packaging Rust programs with Nix

How Do I use it</h1> A common 'entry-point' for a nix expression is a "nix flake".</p>

Questions</h1>

Avante.nvim + Home-Manager

Nix Tricks

Regex Capture Groups: Restructure text using NeoVim

Manage custom packages using Nix and Home-Manager

`Maybe` I Like Haskell

TiL... `hugo server` ignores variables set in `config.toml`

Troubleshooting Failing Commands

TiL..About `git` remotes

Playing in Traefik

Gitting There on Argos

Talosian Terraforming

Proxmox HTTPs Certificates

Terraforming Proxmox

Other Tools Considered</h1> I had a pretty good idea that I would end up using Terraform, but I also tried out a bunch of other tools too.</p>

Ansible</h2> My original plan was to use the Proxmox module</a> and keep everything in Ansible. Unfortunately, the configuration was obtuse and I could only clone templates (no iso/iPXE).</p>

Setting Up Storage</h2> My Proxmox cluster is pretty bare bones, so there is (was) no network storage. Unfortunately, when cloning a VM the new VM must have the same storage, i.e. a template on Host A's local storage cannot be cloned to Host B's local storage.</p>

Terraforming Proxmox</h1> The meat and potatoes happens here. To start, run terraform init</code> in the directory your Terraform code will be in.</p>

Connection</h3> In order for provisioners to be useful they need to be able to connect to the resource they are provisioning. Unsurprisingly, the connection</code> block defines this.</p>

Ansible</h3> The second provisioner runs the playbook - yes, that is all on one line.</p>

Sops and Age

2022 in Review

Cheat.sh + fzf

cht.sh</code></h2> curl https://cht.sh/:cht.sh > .local/bin/cht.sh</code> downloads the official cli tool. This solves the awkward curl command construction, but it's still missing a nice fuzzy finding interface.</p> Development</h1> Url Format</h2> The cheat.sh urls are formatted as follows:</p>

Development</h1> Url Format</h2> The cheat.sh urls are formatted as follows:</p>

Url Format</h2> The cheat.sh urls are formatted as follows:</p>

Combining the Two</h3> Easy, Now just to wire them together. Replace, $TOPIC</code> with the following ${1:=$(__fzf_cheat_selector)}</code>.</p> The ${1:=$val}</code> syntax means use the first variable, or if that doesn't exist, use $val</code> as a default.</p>

Gallery</h1> </p>

GPG Keys

Dagger in Github Actions

Daggerify the Blog - Part 1: Build

Point-to-Site Wireguard Configuration

Ansible for Localhost

Getting Going with Gitea

Deploying `blog.kgb33.dev`

Other Tools Considered</h1>
I had a pretty good idea that I would end up using Terraform, but I also tried out a bunch of other tools too.</p>

Ansible</h2>
My original plan was to use the Proxmox module</a> and keep everything in Ansible. Unfortunately, the configuration was obtuse and I could only clone templates (no iso/iPXE).</p>

Terraforming Proxmox</h1>
The meat and potatoes happens here. To start, run `terraform init</code> in the directory your Terraform code will be in.</p>`

Combining the Two</h3>
Easy, Now just to wire them together. Replace, `$TOPIC</code> with the following ${1:=$(__fzf_cheat_selector)}</code>.</p>`
`The ${1:=$val}</code> syntax means use the first variable, or if that doesn't exist, use $val</code> as a default.</p>`

`Gallery</h1> </p>`