<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Automation - Category - Fryguy's Blog</title><link>https://fryguy.net/categories/automation/</link><description>Automation - Category - Fryguy's Blog</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Sat, 08 Aug 2026 18:00:00 +0000</lastBuildDate><atom:link href="https://fryguy.net/categories/automation/" rel="self" type="application/rss+xml"/><item><title>Retiring WordPress – How I Migrated fryguy.net to Hugo (With an AI Pair Programmer)</title><link>https://fryguy.net/2026/08/08/retiring-wordpress-how-claude-code-helped-migrate-fryguy-net-to-hugo/</link><pubDate>Sat, 08 Aug 2026 18:00:00 +0000</pubDate><author>Fryguy</author><guid>https://fryguy.net/2026/08/08/retiring-wordpress-how-claude-code-helped-migrate-fryguy-net-to-hugo/</guid><description><![CDATA[<p>This site has run on WordPress since basically forever. As of this week, it doesn&rsquo;t anymore. Everything you&rsquo;re reading is now a static Hugo site, built from Markdown, served by nginx, with no PHP and no database anywhere in the stack. Here&rsquo;s why I did it, what actually moved, and how I used Claude Code as a pair programmer for most of the heavy lifting.</p>
<h2 id="why-bother">Why bother</h2>
<p>Let&rsquo;s be honest about how it got this bad: I didn&rsquo;t keep up with it. I know. Servers don&rsquo;t rot on their own — you stop patching them, stop upgrading them, and a few years later you&rsquo;re staring at a stack that&rsquo;s aged out from under you. The old droplet had quietly rotted underneath a site that still worked fine. Ubuntu 18.04 — EOL since 2023. PHP 7.4 — EOL since 2022, with no apt-upgrade path to anything newer (the PPA I&rsquo;d have needed was frozen). MySQL 5.7 — also EOL. WordPress itself was current; everything under it wasn&rsquo;t, and there was no clean patching path left, just a slow accumulation of risk on a box facing the public internet.</p>]]></description></item><item><title>SecureCRT to SuperPutty – Migrate Your Sessions with One Python Script</title><link>https://fryguy.net/2026/05/08/securecrt-to-superputty-migrate-your-sessions-with-one-python-script/</link><pubDate>Fri, 08 May 2026 17:00:00 +0000</pubDate><author>Fryguy</author><guid>https://fryguy.net/2026/05/08/securecrt-to-superputty-migrate-your-sessions-with-one-python-script/</guid><description>&lt;p>If you’ve ever had to move a large session library from SecureCRT to SuperPutty, you know the pain — there’s no built-in migration path, and manually re-entering dozens (or hundreds) of sessions is a miserable afternoon. I wrote &lt;strong>SCRT_2_SPUTTY&lt;/strong> to handle it automatically. Point it at your SecureCRT XML export, and it spits out a ready-to-import SuperPutty XML file. No third-party libraries, no configuration files — just Python and a single command.&lt;/p></description></item><item><title>UniFi Network Health Report – Open Source Python Tool (v1.0.0)</title><link>https://fryguy.net/2026/05/07/unifi-network-health-report-open-source-python-tool-v1-0-0/</link><pubDate>Thu, 07 May 2026 17:50:09 +0000</pubDate><author>Fryguy</author><guid>https://fryguy.net/2026/05/07/unifi-network-health-report-open-source-python-tool-v1-0-0/</guid><description> 
&lt;p>If you run a self-hosted Ubiquiti UniFi network — whether it’s a home lab, small business, or multi-site setup — you know the UniFi dashboard is great for real-time monitoring but falls short when you want a clean summary you can save, share, or review later. I built &lt;strong>UniFi Network Health Report&lt;/strong> to fill that gap: a Python tool that connects to your controller and generates a standalone HTML report covering everything that matters.&lt;/p></description></item></channel></rss>