<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Sentry on Daffa Abhipraya</title><link>https://blog.abhipraya.dev/tags/sentry/</link><description>Recent content in Sentry on Daffa Abhipraya</description><generator>Hugo</generator><language>en-us</language><copyright>© Daffa Abhipraya</copyright><lastBuildDate>Sat, 11 Apr 2026 00:00:00 +0700</lastBuildDate><atom:link href="https://blog.abhipraya.dev/tags/sentry/index.xml" rel="self" type="application/rss+xml"/><item><title>PPL: Self-Hosted Error Monitoring with Custom Instrumentation</title><link>https://blog.abhipraya.dev/ppl/part-a/monitoring/</link><pubDate>Sat, 11 Apr 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-a/monitoring/</guid><description>&lt;p>Error monitoring is one of those things that feels optional until the first production bug slips through unnoticed. A user reports &amp;ldquo;the page is broken,&amp;rdquo; you check the server, everything looks fine, and three hours later you discover a background task has been silently failing since the last deploy. This blog covers how we built monitoring that catches those failures before users do.&lt;/p>
&lt;blockquote>
&lt;p>&lt;strong>Note:&lt;/strong> Our project is hosted on an internal GitLab instance, so we use the term &lt;strong>MR (Merge Request)&lt;/strong> throughout this blog. If you&amp;rsquo;re coming from GitHub, MRs are the equivalent of &lt;strong>Pull Requests (PRs)&lt;/strong>.&lt;/p></description></item><item><title>PPL: New Learnings Applied to SIRA [Sprint 2, Week 2]</title><link>https://blog.abhipraya.dev/ppl/part-c/s2w2-aptitude/</link><pubDate>Thu, 09 Apr 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-c/s2w2-aptitude/</guid><description>&lt;h2 id="overview">
 &lt;a class="anchor" href="#overview" data-anchor="overview" aria-hidden="true">#&lt;/a>
 Overview
&lt;/h2>
&lt;p>Sprint 2 Week 2 (April 3 to 9) was dominated by a mutation testing sprint: setting up mutmut and Stryker in CI, building integration test infrastructure from scratch, and writing mutation-killing tests. The week also delivered three application features and a meta-level improvement to AI workflow. Each area required learning at least one technology or concept not covered in standard Fasilkom coursework.&lt;/p>
&lt;hr>
&lt;h2 id="1-mutation-testing-with-mutmut-python">
 &lt;a class="anchor" href="#1-mutation-testing-with-mutmut-python" data-anchor="1-mutation-testing-with-mutmut-python" aria-hidden="true">#&lt;/a>
 1. Mutation Testing with mutmut (Python)
&lt;/h2>
&lt;p>Mutation testing is a technique where a tool injects small faults (&amp;ldquo;mutants&amp;rdquo;) into your source code (flipping operators, changing constants, removing lines) and checks whether your test suite catches each fault. If a test fails, the mutant is &amp;ldquo;killed.&amp;rdquo; If no test fails, the mutant &amp;ldquo;survives,&amp;rdquo; meaning your tests have a blind spot.&lt;/p></description></item><item><title>PPL: Service Layer Instrumentation [Sprint 2, Week 1]</title><link>https://blog.abhipraya.dev/ppl/part-b/s2w1-programming/</link><pubDate>Mon, 23 Mar 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-b/s2w1-programming/</guid><description>&lt;h2 id="what-i-worked-on">
 &lt;a class="anchor" href="#what-i-worked-on" data-anchor="what-i-worked-on" aria-hidden="true">#&lt;/a>
 What I Worked On
&lt;/h2>
&lt;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&amp;rsquo;t the Sentry API itself; it was &lt;strong>where&lt;/strong> to place the instrumentation in our layered architecture, and how the existing SOLID patterns made the change trivially simple.&lt;/p>
&lt;h2 id="following-the-architecture-spans-in-services-not-routers">
 &lt;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">#&lt;/a>
 Following the Architecture: Spans in Services, Not Routers
&lt;/h2>
&lt;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 &lt;code>db/queries/&lt;/code>.&lt;/p></description></item></channel></rss>