Just a Side Project

I wanted one thing: a short daily report scoring how nervous the market looked, built entirely on free data, running unattended on a schedule, so I'd never have to manually check four different sites before deciding whether a strategy's risk controls should be tightened. Every individual piece of that was easy. Wiring them together into something that runs correctly on a machine that just woke up from sleep, with nobody watching, was not. The shape of the report The script pulls from three genuinely free sources -- no paid API keys required beyond a free-tier signup: the St. Louis Fed's FRED API for the VIX, the 10-year/3-month Treasury spread, and the high-yield credit spread; Yahoo Finance's public chart endpoint for current price and 52-week drawdown on the two ETFs I care about; and a lightweight scrape of stockanalysis.com for PE ratios as extra context. Each metric gets bucketed into a tier -- safe, caution, danger, extreme -- and the tiers sum into a single ri...

The number said "-50%." I'd been staring at trade logs long enough to have a rough feel for how far a leveraged ETF actually needs to fall before a real -50% drawdown trigger should fire, and this one didn't look right. When I actually checked the math behind that specific row, the trigger had fired at roughly -2.9% below the average cost basis -- nowhere near the -50% the log claimed. That one suspicious row turned into a week of finding three separate, unrelated bugs in a backtesting engine I'd built with Claude Code, each one wrong in a completely different way. The project, briefly Outside of this blog, I've been using Claude Code to build and iterate on a backtesting simulator for a rules-based, dollar-cost-averaging-with-leverage trading strategy on leveraged ETFs -- buy more as price drops in defined stages, sell in defined stages as price recovers, all governed by explicit percentage thresholds and cooldown timers. None of the specifics matter for t...

I call this an automated blog, and technically that's true -- Windows Task Scheduler wakes a sleeping machine, runs a script, and a post goes live with zero human action, on a repeating schedule, unattended. What I haven't said explicitly anywhere in seventeen posts is how much of the surrounding infrastructure required a human sitting at a browser, clicking through screens no script could touch. It's time to draw the actual line. What genuinely runs without me The core loop is real automation, not a stretch of the word. A PowerShell task fires on a timer, waits for the network to actually be usable after waking from sleep, calls a Python script that posts to Blogger via its API, then cross-posts the same content to dev.to with the image handling and canonical URL set correctly. Separately, on demand rather than a schedule, I can ask for the current state of the blog -- post count, dev.to view counts, Google Search Console clicks and impressions, GA4 visitor numbers -- a...

Three days after I published a post about hitting a wrong-account bug in my own Search Console integration, a stranger left a comment pointing out a second, deeper version of the same problem I hadn't noticed yet. Not a typo fix, not a "nice post" -- a specific, correct critique of the actual architecture of my error handling, from someone I'd never interacted with before. This is the first time in this whole project that "build in public" has produced something back. What showed up in the comments The comment came from a developer identifying himself as ten-plus years into a career, on the post about the Search Console wrong-account mixup. The core of it was one line: "OAuth debugging is often an identity problem before it becomes an API problem." Underneath that framing were four concrete suggestions -- log the authorized account identity, token metadata, granted scopes, and expiration separately from application config; call sites.list befo...

Twenty-one days ago I published the first post on this blog. Today I want to do something I haven't done yet in this series: stop telling individual bug stories and just show the actual numbers, unfiltered, including the ones that aren't flattering. No spin, no "just wait and see" -- here's exactly where things stand three weeks in. The dev.to side: real, if modest, growth Ten posts are live. Every one of them cross-posts automatically to dev.to a few seconds after Blogger publishes it. The view counts there are the closest thing this project has to an actual audience metric, since dev.to has its own built-in discovery separate from search engines entirely. The spread is wide -- from 0 to 34 -- and there's no clean story explaining why one post did better than another. The two highest performers (the cross-posting pipeline writeup and the free-tier comparison of Google Flow, Kling, and Hailuo) aren't obviously better written than the others; if anyt...

I fixed the exact same error twice in one afternoon, in the exact same place, and it still wasn't fixed. The first fix worked -- I could tell because the error message changed. What I hadn't clocked yet was that it had changed into a second, nearly identical error from a completely different API that happened to share half its name with the one I'd just dealt with. Setting the stage I was wiring up a script to pull real visitor numbers from Google Analytics (GA4) instead of checking the dashboard by hand -- the same pattern I'd already used for Blogger and Search Console. The script does two things: first it asks Google's Analytics Admin API which GA4 property is connected to the account, then it asks the Analytics Data API for the actual visitor numbers on that property. Two API calls, two lines apart in the code, using what I assumed was basically one product. The first wall The very first run failed before it got anywhere near real data: google.api_core....