https://dzarlax.dev/Recent content in Home on Alexey Panfilov — Product, AI, SystemsHugoenhttps://dzarlax.dev/articles/i-tried-to-automate-blog-translation.-the-real-product-was-qa./Sat, 23 May 2026 00:00:00 +0000https://dzarlax.dev/articles/i-tried-to-automate-blog-translation.-the-real-product-was-qa./<p>I started with a simple wish: I had English articles on dzarlax.dev, and I wanted Russian and Serbian versions without turning every post into a weekend project.</p> <p>The shape looked automatable. The source was already Markdown. The site already had language-aware routing. I write in an Obsidian vault. Article bundles are predictable:</p> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-fallback" data-lang="fallback"><span class="line"><span class="cl">articles/&lt;slug&gt;/index.md </span></span><span class="line"><span class="cl">articles/&lt;slug&gt;/index.ru.md </span></span><span class="line"><span class="cl">articles/&lt;slug&gt;/index.rs.md </span></span></code></pre></div><p>So the initial question sounded technical: which translation model should I use?</p> <p>That turned out to be the wrong question. The real question was: <strong>which parts of translation should be automated, and which parts should stay editorial?</strong></p>https://dzarlax.dev/articles/health-dashboard-part-1-a-score-i-could-trust/Mon, 18 May 2026 00:00:00 +0000https://dzarlax.dev/articles/health-dashboard-part-1-a-score-i-could-trust/<p>This is Part 1 of a series about building my self-hosted Health Dashboard. The first version was not a methodology project. It was a pipe: take data from Apple Health, POST it to my server, show a score in the morning.</p> <p>That sounds clean until the first bad night of data lands in Postgres. A health score is only as trustworthy as the ingestion path underneath it, and the early version of this system was mostly teaching me that lesson the hard way.</p>https://dzarlax.dev/articles/health-dashboard-part-2-outgrowing-health-auto-export/Mon, 18 May 2026 00:00:00 +0000https://dzarlax.dev/articles/health-dashboard-part-2-outgrowing-health-auto-export/<p>In Part 1 the server learned to accept observations without losing them and to rebuild every derived table from raw data. That was enough to make a dashboard useful. It was not enough to make the data honest.</p> <p>This part is about the moment a third-party exporter stopped being a sufficient ingestion path on its own, and about the two regressions that followed when I added my own iOS client alongside it. Health Auto Export still runs against the server today. The <code>/health</code> endpoint accepts both producers, and the code path that parses HAE payloads is maintained. The &ldquo;outgrowing&rdquo; in the title is about its limits, not its retirement.</p>https://dzarlax.dev/articles/health-dashboard-part-3-my-wearables-kept-lying-by-omission/Mon, 18 May 2026 00:00:00 +0000https://dzarlax.dev/articles/health-dashboard-part-3-my-wearables-kept-lying-by-omission/<p>After Part 2 the ingestion layer feels clean. The server accepts payloads, a native iOS client cooperates with Health Auto Export, the schema knows about per-segment sleep, the dashboard renders five sleep phases. It looks finished. It is not.</p> <p>The next class of problem only became visible once the data was technically correct. On any given night I have <strong>three devices</strong> capable of saying something about my sleep: Apple Watch on my wrist, RingConn<sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup> on my finger, and the iPhone next to my bed running Apple&rsquo;s own Sleep Schedule estimate. Each one knows something the others do not. None of them agree about what they measured.</p>https://dzarlax.dev/articles/health-dashboard-part-4-when-readiness-stopped-being-one-number/Mon, 18 May 2026 00:00:00 +0000https://dzarlax.dev/articles/health-dashboard-part-4-when-readiness-stopped-being-one-number/<p>In Part 1 I described the original readiness score:</p> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">readiness = HRV_score * 0.40 + RHR_score * 0.30 + Sleep_score * 0.30 </span></span></code></pre></div><p>It was a useful number. It told me, every morning, whether something in last night&rsquo;s data looked unusual against my personal baseline. It also turned out to be measuring the wrong thing.</p> <p>This part is the audit that surfaced that, the redesign that came out of it, and the moment Phase 1 closed without producing a single model that beat its naive baseline by the criterion we had set in advance.</p>https://dzarlax.dev/articles/health-dashboard-part-5-the-energy-bank-problem/Mon, 18 May 2026 00:00:00 +0000https://dzarlax.dev/articles/health-dashboard-part-5-the-energy-bank-problem/<p>In Part 4 the audit invalidated the readiness formula and surfaced a parallel finding: EnergyBank v1 was wrong-signed against next-day HRV<sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup> (r=−0.149) and next-day RHR<sup id="fnref:2"><a href="#fn:2" class="footnote-ref" role="doc-noteref">2</a></sup> (r=+0.212) over 387 paired days.</p> <p>Wrong-signed is a strong claim. It means the concept is intact but the target is mis-specified: what v1 was measuring was probably <em>productive strain</em>, not <em>recovery deficit</em>. The two correlate on many days and diverge precisely on the days that matter, like a quiet but anxious day, an illness, a watch off the wrist.</p>https://dzarlax.dev/articles/health-dashboard-part-6-measuring-stress-without-lying-to-myself/Mon, 18 May 2026 00:00:00 +0000https://dzarlax.dev/articles/health-dashboard-part-6-measuring-stress-without-lying-to-myself/<p>In Part 5 the EnergyBank redesign left a placeholder: <code>drain = α · active_kcal + β · sustained_hr_load</code>, with <code>β = 0</code> until a validation rubric per-user returns <code>validated</code>. That term, the autonomic-load drain, is the v2.2 piece. It is also the one I most wanted to be careful with, because &ldquo;stress&rdquo; is the single most over-claimed metric in consumer health products.</p> <p>This part is about what stress actually means physiologically, what my data can and cannot say about it, why the obvious formula was wrong, and what the rubric is for.</p>https://dzarlax.dev/articles/health-dashboard-part-7-the-app-that-stopped-doing-the-math/Mon, 18 May 2026 00:00:00 +0000https://dzarlax.dev/articles/health-dashboard-part-7-the-app-that-stopped-doing-the-math/<p>The first six parts of this series were about the server learning to have opinions. Ingestion gates, source identity, sub-score eligibility, formula-version boundaries, validation rubrics: every piece earned its right to a number. Once that work was done, a new question opened on the other side of the wire. What is the iOS client allowed to do with those numbers?</p> <p>The answer turned out to be narrower than I expected when I started. The interesting part of building the mobile app was not what got added to it. It was what got <em>removed</em> from it, repeatedly, as the server learned to do each thing better.</p>https://dzarlax.dev/articles/health-dashboard-part-8-asking-before-telling/Mon, 18 May 2026 00:00:00 +0000https://dzarlax.dev/articles/health-dashboard-part-8-asking-before-telling/<p>Part 6 said: subjective input cannot validate the stress formula. That rule stands. A formula that auto-tunes itself against a user&rsquo;s self-report becomes a closed loop with no external referent. The user rationalises post-hoc, the formula updates toward the rationalisation, and the next round of self-report is biased by the formula&rsquo;s previous output. The cure for that is to keep the rubric external: next-morning HRV, RHR shift, sleep architecture. Numbers the user is not consciously writing down.</p>https://dzarlax.dev/articles/trading-a-1.3-gb-bookmark-manager-for-17-mb/Wed, 13 May 2026 00:00:00 +0000https://dzarlax.dev/articles/trading-a-1.3-gb-bookmark-manager-for-17-mb/<p>I had been ignoring it for a while: every time I looked at <code>docker stats</code> on my Hetzner VPS, Karakeep was the heaviest container by a wide margin. A 7.6 GB box, 25 services, and one Node app taking <strong>1.32 GB</strong> of resident memory for what is, in my use, a glorified link list with screenshots.</p> <p>Available RAM had drifted down to <strong>1.4 GB</strong>, swap was pinned at 2.0 / 2.0 GB, and Postgres (capped at 768 MB) was hitting 61% utilisation. Nothing was on fire, but the margin had stopped feeling like a margin.</p>https://dzarlax.dev/articles/how-a-sleeping-terminal-cost-me-1000-overnight/Fri, 08 May 2026 00:00:00 +0000https://dzarlax.dev/articles/how-a-sleeping-terminal-cost-me-1000-overnight/<p>Picture this: you&rsquo;re working on a project, using Claude Code to refactor a massive monorepo. Evening comes, you close your laptop lid, and in the morning you wake up to a <strong>$1,025</strong> API bill — even though you had strict spending limits set up in your billing dashboard.</p> <p>That&rsquo;s exactly what happened to me. After digging through the logs, I reconstructed the timeline and found the root cause. Spoiler: the culprits were background daemons, infinite agent loops, and — ironically — the prompt caching mechanism itself.</p>