https://blog.abhipraya.dev/tags/programming/Recent content in Programming on Daffa AbhiprayaHugoen-us© Daffa AbhiprayaWed, 15 Apr 2026 00:00:00 +0700https://blog.abhipraya.dev/ppl/part-b/s2w3-programming/Wed, 15 Apr 2026 00:00:00 +0700https://blog.abhipraya.dev/ppl/part-b/s2w3-programming/<h2 id="what-i-worked-on"> <a class="anchor" href="#what-i-worked-on" data-anchor="what-i-worked-on" aria-hidden="true">#</a> What I Worked On </h2> <p>Two weeks of work that ended up demonstrating the same principle at two very different scales. In the application code: isolating invoice number generation as a pure function (SIRA-123, MR !130) and composing authentication onto GET endpoints via FastAPI dependency injection (SIRA-82, MR !154). In the infrastructure: designing <code>scripts/ci-supabase-slot.sh</code> (SIRA-274, MR !197) — a 110-line bash script that claims one of three parallel Supabase stacks and hands back an isolated environment to the caller. Different problem domains, same discipline: give each unit of code one reason to change.</p>https://blog.abhipraya.dev/ppl/part-b/s2w2-programming/Mon, 30 Mar 2026 00:00:00 +0700https://blog.abhipraya.dev/ppl/part-b/s2w2-programming/<h2 id="what-i-worked-on"> <a class="anchor" href="#what-i-worked-on" data-anchor="what-i-worked-on" aria-hidden="true">#</a> What I Worked On </h2> <p>Two major features this week, email integration (SIRA-160) and session management (SIRA-214), both followed the SOLID principles that have been established in the codebase. The email feature in particular offered a good opportunity to show SRP in action: sending an email and rendering an email template are genuinely different responsibilities, and keeping them separate made both easier to test.</p> <hr> <h2 id="email-integration-separating-transport-from-rendering"> <a class="anchor" href="#email-integration-separating-transport-from-rendering" data-anchor="email-integration-separating-transport-from-rendering" aria-hidden="true">#</a> Email Integration: Separating Transport from Rendering </h2> <p>SIRA-160 (MR !108) introduced three distinct services:</p>https://blog.abhipraya.dev/ppl/part-b/s2w1-programming/Mon, 23 Mar 2026 00:00:00 +0700https://blog.abhipraya.dev/ppl/part-b/s2w1-programming/<h2 id="what-i-worked-on"> <a class="anchor" href="#what-i-worked-on" data-anchor="what-i-worked-on" aria-hidden="true">#</a> What I Worked On </h2> <p>This week I implemented custom Sentry span instrumentation across 3 key API services to track sub-operation latency in GlitchTip. The interesting part wasn&rsquo;t the Sentry API itself; it was <strong>where</strong> to place the instrumentation in our layered architecture, and how the existing SOLID patterns made the change trivially simple.</p> <h2 id="following-the-architecture-spans-in-services-not-routers"> <a class="anchor" href="#following-the-architecture-spans-in-services-not-routers" data-anchor="following-the-architecture-spans-in-services-not-routers" aria-hidden="true">#</a> Following the Architecture: Spans in Services, Not Routers </h2> <p>SIRA follows a strict Router → Service → DB pattern. Routers handle HTTP concerns (auth, status codes). Services hold business logic. DB queries are isolated in <code>db/queries/</code>.</p>