<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Hobby Code</title><link>https://hobbycode.dev/</link><description>Recent content on Hobby Code</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 19 Apr 2026 16:02:00 -0700</lastBuildDate><atom:link href="https://hobbycode.dev/index.xml" rel="self" type="application/rss+xml"/><item><title>Why I moved my dotfiles to chezmoi</title><link>https://hobbycode.dev/posts/dotfiles-with-chezmoi/</link><pubDate>Sun, 19 Apr 2026 16:02:00 -0700</pubDate><guid>https://hobbycode.dev/posts/dotfiles-with-chezmoi/</guid><description>&lt;p&gt;I have been hand-rolling a dotfiles repo since roughly 2014. The recipe was always the same: a folder full of &lt;code&gt;.zshrc&lt;/code&gt; and &lt;code&gt;.gitconfig&lt;/code&gt; and friends, plus an &lt;code&gt;install.sh&lt;/code&gt; that ran a few dozen &lt;code&gt;ln -sf&lt;/code&gt; lines. It worked. It also broke in slightly different ways every time I set up a new machine.&lt;/p&gt;
&lt;p&gt;A few months ago I gave &lt;a href="https://www.chezmoi.io/"&gt;chezmoi&lt;/a&gt; a real try and now I do not understand why I waited so long. What it gets right:&lt;/p&gt;</description></item><item><title>A Go CLI starter template I keep reusing</title><link>https://hobbycode.dev/posts/go-cli-starter-template/</link><pubDate>Mon, 02 Mar 2026 21:15:00 -0800</pubDate><guid>https://hobbycode.dev/posts/go-cli-starter-template/</guid><description>&lt;p&gt;Every few months I find myself reaching for the same handful of patterns when I start a new Go CLI. This time I finally wrote them down in a tiny template I can clone and fill in. Nothing here is novel, but having it sitting in one place saves me 30 minutes of plumbing each time.&lt;/p&gt;
&lt;p&gt;The layout I converged on:&lt;/p&gt;
&lt;pre tabindex="0"&gt;&lt;code&gt;.
├── cmd/&amp;lt;binary&amp;gt;/main.go // entry point, only flag parsing and wiring
├── internal/app/ // the actual logic
├── internal/cli/ // flag definitions, help text
├── internal/version/ // baked-in build info
├── Makefile
└── go.mod
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;The pieces I always end up needing:&lt;/p&gt;</description></item><item><title>Switching from Vim to Helix after twelve years</title><link>https://hobbycode.dev/posts/switching-from-vim-to-helix/</link><pubDate>Fri, 09 Jan 2026 19:44:00 -0800</pubDate><guid>https://hobbycode.dev/posts/switching-from-vim-to-helix/</guid><description>&lt;p&gt;I have been using Vim since 2013. Last month I gave Helix a real try, the kind where you delete the symlink to &lt;code&gt;nvim&lt;/code&gt; and force yourself to use the new thing for two weeks. I do not think I am going back.&lt;/p&gt;
&lt;p&gt;The selling point for me is not the modal model or the speed. It is the fact that Helix ships with a working LSP and tree-sitter setup out of the box and I never had to think about it. My Neovim config was 800 lines of Lua and broke approximately every other month when a plugin author rewrote their API. The Helix config that does roughly the same thing is 40 lines of TOML and has not broken once.&lt;/p&gt;</description></item><item><title>A tiny zsh function I use daily</title><link>https://hobbycode.dev/posts/zsh-function-i-use-daily/</link><pubDate>Sat, 22 Nov 2025 22:08:00 -0800</pubDate><guid>https://hobbycode.dev/posts/zsh-function-i-use-daily/</guid><description>&lt;p&gt;This is silly but it has paid for itself many times over. I added it to my &lt;code&gt;.zshrc&lt;/code&gt; years ago and I now reach for it five or six times a day without thinking.&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" class="chroma"&gt;&lt;code class="language-zsh" data-lang="zsh"&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;mkcd&lt;span class="o"&gt;()&lt;/span&gt; &lt;span class="o"&gt;{&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt; mkdir -p &lt;span class="s2"&gt;&amp;#34;&lt;/span&gt;&lt;span class="nv"&gt;$1&lt;/span&gt;&lt;span class="s2"&gt;&amp;#34;&lt;/span&gt; &lt;span class="o"&gt;&amp;amp;&amp;amp;&lt;/span&gt; &lt;span class="nb"&gt;cd&lt;/span&gt; &lt;span class="s2"&gt;&amp;#34;&lt;/span&gt;&lt;span class="nv"&gt;$1&lt;/span&gt;&lt;span class="s2"&gt;&amp;#34;&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&lt;span class="o"&gt;}&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;That is the whole thing. &lt;code&gt;mkcd some/nested/path&lt;/code&gt; creates the directory and steps into it in one motion. I know &lt;code&gt;mkdir -p &amp;amp;&amp;amp; cd&lt;/code&gt; is two words longer, but those two words turn out to be the difference between flow and friction.&lt;/p&gt;</description></item><item><title>Notes on rsync incremental backups</title><link>https://hobbycode.dev/posts/rsync-incremental-backups/</link><pubDate>Thu, 14 Aug 2025 20:31:00 -0700</pubDate><guid>https://hobbycode.dev/posts/rsync-incremental-backups/</guid><description>&lt;p&gt;I have been using a small rsync script to back up my laptop to an old USB drive every Sunday evening for the past three years. It is nothing fancy, but I keep tweaking it and I figured I should write down what it actually does before I forget.&lt;/p&gt;
&lt;p&gt;The core idea is &lt;code&gt;--link-dest&lt;/code&gt;: each weekly snapshot only stores files that changed since the previous one, and everything else is a hardlink to the prior snapshot. On disk it looks like a full copy of every backup, but the space cost is roughly one full copy plus the deltas.&lt;/p&gt;</description></item></channel></rss>