Part A: Cognitive Blogs on Daffa Abhipraya

PPL: Self-Hosted Error Monitoring with Custom Instrumentation

Sat, 11 Apr 2026 00:00:00 +0700

Error monitoring is one of those things that feels optional until the first production bug slips through unnoticed. A user reports “the page is broken,” 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.

Note: Our project is hosted on an internal GitLab instance, so we use the term MR (Merge Request) throughout this blog. If you’re coming from GitHub, MRs are the equivalent of Pull Requests (PRs).

PPL: Quality Gates That Actually Block Bad Code

Thu, 09 Apr 2026 00:00:00 +0700

Quality tools are useless if they are not enforced. Our project had SonarQube analyzing every commit, schema fuzzing running against our API, and load tests measuring latency, but every single one of them was set to allow_failure: true. Violations were silently ignored, real bugs slipped through, and nobody noticed because the pipeline was always green. This blog covers how we turned those advisory checks into blocking gates, built automated CI reporting so reviewers could actually see the results, and watched the tools catch a JWT vulnerability, a production crash, and 31 code quality violations that had been accumulating for weeks.

PPL: SOLID Principles in a FastAPI Invoice System

Thu, 09 Apr 2026 00:00:00 +0700

SIRA (Smart Invoice Reminder AI) is a system that automates invoice collection reminders. It monitors payment status, scores client risk using a weighted formula, and sends personalized reminders by email or messaging. The backend is built with FastAPI, Supabase (Postgres via REST), Celery for background jobs, and Redis as the message broker.

This blog walks through how SOLID principles shaped the architecture at three levels: the overall layer structure, service-level design patterns, and individual function design. The goal is not to explain what SOLID stands for (there are plenty of articles for that), but to show what it looks like in production code and why certain design choices were made over simpler alternatives.

PPL: When 91% Test Coverage Means Nothing

Thu, 09 Apr 2026 00:00:00 +0700

We had 91% line coverage and felt good about it. Then we ran mutation testing and scored 0%. Every line of our service layer was executed by tests, but almost nothing was actually verified. This is the story of how we discovered the gap between “code was run” and “code was checked,” and what we changed to close it.

Note: Our project is hosted on an internal GitLab instance, so we use the term MR (Merge Request) throughout this blog. If you’re coming from GitHub, MRs are the equivalent of Pull Requests (PRs).

PPL: When 91% Test Coverage Means Nothing

Sun, 15 Mar 2026 00:00:00 +0700

We had 91% line coverage and felt good about it. Then we ran mutation testing and scored 0%. Every line of our service layer was executed by tests; almost nothing was actually verified. This is the story of how six advanced testing tools exposed the gap between “code was run” and “code was checked,” and what that means for any team relying on coverage as a quality signal.

Note: Our project is hosted on an internal GitLab instance, so we use the term MR (Merge Request) throughout this blog. If you’re coming from GitHub, MRs are the equivalent of Pull Requests (PRs).

PPL: Building a Production-Safe Migration Pipeline with Automated Rollback

Thu, 12 Mar 2026 00:00:00 +0700

Why Database Migrations Need Safety Nets

Imagine this scenario: a developer adds a new column to the invoices table, pushes to main, and the CI/CD pipeline deploys it to production. Everything looks fine until the next morning, when the team discovers that the migration also dropped a constraint that was silently relied on by another service. Rolling back means manually writing SQL against the production database at 2 AM.

PPL: Building an Integrated Tool Ecosystem for a 9-Person University Team

Thu, 12 Mar 2026 00:00:00 +0700

Why Tooling Is a Team Problem, Not a DevOps Problem

Most university software engineering courses teach you which tools to use (Git for version control, Jira for tickets, Docker for deployment). What they rarely teach is how tools interact with each other, and what happens when they don’t.

In a professional environment, a single commit can trigger a cascade: CI runs tests, a Slack bot notifies the team, a coverage report lands in SonarQube, and the ticket moves to “In Review” on the project board. This doesn’t happen by accident. Someone has to build that integration layer, and in a university team, that someone is usually whoever cares enough about developer experience to do it.

Part A: Cognitive Blogs on Daffa Abhipraya

PPL: Self-Hosted Error Monitoring with Custom Instrumentation

PPL: Quality Gates That Actually Block Bad Code

PPL: SOLID Principles in a FastAPI Invoice System

PPL: When 91% Test Coverage Means Nothing

PPL: When 91% Test Coverage Means Nothing

PPL: Building a Production-Safe Migration Pipeline with Automated Rollback

# Why Database Migrations Need Safety Nets

PPL: Building an Integrated Tool Ecosystem for a 9-Person University Team

# Why Tooling Is a Team Problem, Not a DevOps Problem

Why Database Migrations Need Safety Nets

Why Tooling Is a Team Problem, Not a DevOps Problem