DEV Community: beTheNoob

Building Raptor: A Hackathon Judging Platform That Checks Its Own Homework

beTheNoob — Wed, 30 Sep 2026 22:05:16 +0000

A collaboration between Four Eyed Gens and beTheNOOB.

🔗 Repo: github.com/DhruvP2205/raptor

🦅 Building Raptor: A Hackathon Judging Platform That Checks Its Own Homework

Most hackathon platforms trust the submission form and move on. We built Raptor to question that. If a platform decides who wins money and recognition, every step of that decision should be something you can actually check, not just something you have to trust.

Here is what we actually built, and how it works under the hood.

🗺️ The Full Journey, Start to Finish

Before getting into each piece separately, here is the whole pipeline in one picture. Every stage below is a real, checked state on the server, never just something implied by which screen someone happens to be looking at. The dashed amber path shows what happens when verification flags something instead of approving it automatically, and once an organizer approves it, it simply rejoins the normal pipeline at the same step it would have reached anyway. The two boxes at the end, voting and certificates, both run after results are published, not one after the other in a strict order.

Each of these stages gets its own section below, so this is just the map. Keep it in mind while reading the rest, since the order here is the actual order the platform enforces, not just the order this post happens to explain things in.

🔍 Catching Problems Before a Judge Ever Sees Them

Every submitted project gets checked against its own GitHub commit history before a judge ever opens it.

Check result	What happens next
✅ Commits fall inside the event window	Auto approved, moves straight to judging
⚠️ Some commits outside the window	Flagged for organizer review
🚫 Repo is private or not on GitHub	Flagged for organizer review
❌ Organizer disqualifies it	Must attach a written reason, permanently

Nothing gets removed from a competition without a real explanation sitting right next to it, forever.

🧮 How a Score Actually Gets Built

A judge does not just type one number. Here is the actual chain:

Step	What it is	Example
1️⃣ Criteria scores	Each rubric criteria, weighted	Functionality (60%) × 90 + Quality (40%) × 80
2️⃣ Judge raw total	Weighted sum, plus bonus added on top	86 + 5 bonus = 91
3️⃣ Average raw total	Average across every judge who actually finished	Judges who never submitted are excluded, not counted as zero
4️⃣ Final score	Scaled to the event's display scale	e.g. out of 5 ⭐

🎯 The key design choice: bonus points get added after the weighted average, in full units, not blended proportionally in. That keeps the math honest. A small bonus can nudge a project up. It cannot let a weak project beat a strong one just because the bonus was generous.

⚖️ Normalization: Why It Exists, and What the Data Actually Showed

Different judges score differently. Some are naturally generous, some are naturally strict, and that has nothing to do with the quality of the work in front of them.

So every judge has a personal scoring profile, built from their history across every event they have judged:

Judge's raw score  →  compare to their own average and spread  →  normalized score

A tough judge's 4/5 stops meaning something different from a generous judge's 4/5.

📊 What we actually tested: we ran a real simulation on real fixture data (30 judges, 40 projects) to see how well this correction recovers a true ranking.

Judges seeing many projects each	Judges seeing only a few each
Normalization clearly helps	Effect shrinks, sample size matters more

That is the kind of finding you only get by testing your own formula against real numbers instead of trusting it because it looks correct on paper.

🏆 One Leaderboard, Every Event

Wins do not live inside a single event. Raptor keeps a platform wide leaderboard tracking one person across everything they have ever competed in:

🥇 1st place finishes
🥈 2nd place finishes
🥉 3rd place finishes
🌟 Special award wins
🗳️ Audience choice wins

All of it feeds one running total, so someone who quietly placed well across five small events gets the same visibility as someone who won one big one.

🛠️ The Infrastructure Underneath

We wanted this to run anywhere with zero cloud dependency. Five containers, two networks:

                 host-exposed ports
                        │
        ┌───────────────┴───────────────┐
        │                                 │
     web (Next.js)                    api (NestJS)
        │                                 │
        └────────── app network ──────────┤
                                           │
                                       worker (BullMQ) ── on both networks
                                           │
                                     data network
                                           │
                              ┌────────────┴────────────┐
                          postgres                    redis

Container	Role	Why it exists
🌐 `web`	Next.js frontend	The only thing a browser talks to
⚙️ `api`	NestJS backend	Every rule, every permission check, lives here
🔄 `worker`	Background jobs (BullMQ)	Handles slow work: GitHub checks, leaderboard recomputes
🗄️ `postgres`	Database	The single source of truth
⚡ `redis`	Cache and rate limiting	Login limits, gallery limits, queue storage

🔒 The network isolation is the important part. postgres and redis sit on a data-only network with zero exposed ports to the outside world, not even to your own machine. web cannot reach the database directly at all, even if it wanted to. Every single thing a browser does has to go through api, which is the only place permission checks happen. If someone compromised the frontend, they would hit a dead end trying to reach the database.

docker compose up and that is the whole stack. No cloud account, no external API calls, no signup anywhere.

🧑‍💻 Five Accounts, Five Jobs

Before going role by role in detail, here is the full picture in one image. Every row below is a completely separate account type, and none of them can act outside what their own row shows, a judge cannot publish results and an organizer cannot score a project.

A visitor never needs an account just to look around. A user is the one actually building something. A judge only ever sees what they are assigned. An organizer runs their own event end to end. An admin can step into any event platform wide, but every single time they do, it gets written to a permanent log.

For a judge

Invited → Accept / Decline → Assigned queue of projects → Scoring screen

Once accepted, a judge gets a queue of assigned projects. The scoring screen brings the rubric, bonus tracks, and written feedback together in one place, and a review can be revised as many times as needed right up until judging closes.

For an organizer

One dashboard, one event at a time:

📨 Invite judges
🔍 Review flagged submissions
🧑‍⚖️ Assign projects to judges
📈 Watch judging progress live
⚖️ Run normalization
📋 Draft and publish results
🎓 Issue certificates

For an admin

Same toolkit, platform wide instead of event wide:

Step into any event to help
Export data across every event at once
See the full audit trail for everything that happened

🕵️ Every time an admin uses that wider access, it gets logged automatically. The power exists for real operational need, but it is never invisible.

Built with a self-hosted first mindset, because the tools deciding who wins should be something you can actually run and check yourself, not something you have to trust blindly. 🦅

🔗 Check out the full code: github.com/DhruvP2205/raptor

A collaboration between Four Eyed Gens and beTheNOOB.

I Ported cJSON to Rust, and My Own Test Suite Lied to My Face

beTheNoob — Fri, 07 Aug 2026 06:22:02 +0000

I did a dumb thing on purpose: took a real, 8-year-old, still-in-production C library — cJSON — and rewrote it in Rust. Not "inspired by." A port. Same test suite, same weird edge cases, same bugs if I wasn't careful.

This was for Port Mortem, a hackathon whose entire personality is "prove it, don't just say it." You take the original test suite — hashed at kickoff so you can't sneak-edit it later — and make it pass against your rewrite, untouched. One edited test file = automatic zero. No vibes-based grading.

So here's the honest version: four real bugs, one unsafe block I genuinely couldn't remove, and a benchmark where C beat me and I'm not hiding it.

What's cJSON and why bother

A small, zero-dependency C library that parses/prints JSON, ~2,500 lines, used everywhere from embedded firmware to random C tools. It manages its own tree with raw pointers and hand-rolls its own growable print buffer — exactly the kind of code where "just rewrite it safely" sounds easy until you try. Bonus: it has a real, disclosed CVE, CVE-2025-57052 (CVSS 9.8) — so I wasn't just porting code, I was porting a bug on purpose, then un-porting it.

The setup

Original C headers get SHA-256 hashed at kickoff, never touched again. My Rust compiles to the exact same C ABI, so the original C test suite (Unity framework) links straight against my Rust binary with no idea it's not talking to C. One wrinkle: 13 of 20 original test files call cJSON's internal (non-public) functions directly — I handled that with a thin C shim (not hashed/pinned) that just forwards to the real ported logic. Not a mock, same logic, just re-exposed.

Bug #1: CI said "100% passed." It ran 1 out of 22 tests.

The most embarrassing one, and the one I'm proudest of catching. CI printed:

100% tests passed, 0 tests failed out of 1

Out of 1. Not 22. cJSON gates its whole real test suite behind a CMake flag:

# adapter/CMakeLists.txt — this line was missing
set(ENABLE_CJSON_TEST ON)

Upstream's own build sets this automatically; my from-scratch CMake file didn't. So the if(ENABLE_CJSON_TEST) block silently defined zero real tests, and ctest was truthfully reporting 100% of one leftover test. I only caught it by not trusting the green checkmark and running the build locally myself. One line fixed it — and immediately surfaced 2 more bugs (a missing preamble in my test shim, and cJSON_ParseWithOpts silently dropping its error-position output on failure) that had been hiding behind the disabled suite the whole time.

Bug #2: my fuzzer found a bug in under a minute

Port Mortem wants a differential fuzzer — same input, both builds, diff the output. Mine found 192,619 divergences on its first real run, all from string-printing unicode escapes:

// port/src/print.rs — print_string_ptr()
_ => {
    // C's `for` loop increments the pointer once per iteration on top of
    // this branch's own advance. My manual Rust loop has no implicit
    // increment, so it must add that missing +1 explicitly: add(5), not 4.
    libc::sprintf(out as *mut c_char, c"u%04x".as_ptr(), c as c_int);
    out = out.add(5);
}

The C for loop's increment clause was quietly adding one extra byte of advance every iteration — a language feature I forgot to account for by hand. One-line fix, zero divergences after. Best proof I have that differential fuzzing actually works: it caught a subtle off-by-one that unit tests never would've hit.

The unsafe block I couldn't get rid of

Grepping the port shows 155 hits of "unsafe." Scary out of context, so here's the real breakdown:

What it actually is	Count
`unsafe extern "C" fn` — public FFI entry points	89
`unsafe fn` — internal helper signatures	61
Actual `unsafe { }` blocks inside safe code	1
`SAFETY:` comments explaining why	121

89 of 91 public functions are unsafe extern "C" fn — not laziness, structurally required, since every one takes a raw pointer from C that Rust's compiler can't verify. Marking them safe fn wouldn't remove the risk, just mislabel it. The number that actually reflects my code quality is the 1:

// port/src/hooks.rs
// SAFETY: reads the `static mut global_hooks` — matches the original's
// own thread-safety characteristics (none), required for compatibility.
pub fn snapshot() -> HookSnapshot {
    unsafe {
        let h = global_hooks;
        HookSnapshot {
            allocate: h.allocate.unwrap_or(libc::malloc),
            deallocate: h.deallocate.unwrap_or(libc::free),
            reallocate: h.reallocate,
        }
    }
}

cJSON lets any C caller globally swap the allocator via cJSON_InitHooks, with zero synchronization — that's just how the original works, and tests depend on it. The borrow checker can't reason about a C caller mutating a global from a function it can't see, so this one spot is explicitly marked and explained. Everything else — parsing, tree walks, JSON Pointer logic, string escaping — is plain safe Rust behind that one FFI wall.

The CVE, ported on purpose

CVE-2025-57052 (CVSS 9.8): resolving a JSON Pointer like /1A as an array index, the original C loop kept re-checking the first character instead of advancing — so "1A" got folded into a valid index and returned a real element for what should've been rejected.

// port/src/utils.rs — fixed
// Original checked pointer[0] (always the first byte) here forever.
// We check pointer[position] — the byte actually being consumed.
while *pointer.add(position) >= b'0' && *pointer.add(position) <= b'9' {
    parsed_index = parsed_index * 10 + (*pointer.add(position) - b'0') as usize;
    position += 1;
}

I kept the original buggy C build as a permanent fuzzing oracle to prove the fix, not just claim it — real output from fuzz/log.txt:

pointer: "/1A" (malformed)
  C-original(v1.7.18) -> accepted (bug: folded '1A' into index 27), returned element 127
  Rust-port -> rejected (NULL, CVE-2025-57052 fix)

The benchmark that mildly hurt my feelings

Same 500-record, ~50KB JSON workload, 2,000 iterations, real percentiles (not just an average):

Metric	C	Rust	Winner
p50 latency	0.895 ms	0.767 ms	Rust, ~14% faster
p99 latency	2.575 ms	2.044 ms	Rust, ~21% faster
Throughput	892 ops/s	1,037 ops/s	Rust, ~16% more
Max latency	6.90 ms	7.44 ms	C, by a hair
Peak RSS	2,656 KB	2,656 KB	tie

Rust wins where it matters most — median, p99, throughput, identical memory. But C beat me on max latency, and I'm leaving that row in the table instead of quietly cropping it out. One-off outlier on a shared machine, not a trend — but "honest numbers over confident claims" is the whole point of this track.

Watch it live

Full Docker build, all 22 tests, live differential fuzz including the CVE case, no cuts on the parts that matter.

All the numbers, in one place

22/22 original Unity tests pass, byte-for-byte unmodified, hash-verified
70M+ differential fuzz comparisons in a 60s run, 0 unexpected divergences (exact count varies by machine — it's a time budget, not an iteration count; two real runs hit 77.9M and 115.9M, both clean)
1 real internal unsafe {} block in ~4,000 lines
1 real CVE (CVSS 9.8), fixed and faithfully reproduced for proof, not just asserted
4 real bugs found and fixed — including one about how confidently I thought I'd already verified this thing

Go poke at it yourself

DhruvP2205 / cjson-rust-port

🦀 C→Rust port of DaveGamble/cJSON — 🧪 22/22 original tests unmodified, 🐛 70M+ fuzz comparisons/0 divergences, 🎯 CVE-2025-57052 fixed.

🔀 cJSON ⇄ 🦀 Rust

Port Mortem 2026 · Track A (C → Rust)

A byte-for-byte faithful, memory-safe Rust port of a real, popular C library — proven against the original's own unmodified test suite, not a rewritten one.

Tip

Rewrite real code. Prove the port works. No new tests written against the new implementation — the original's own unmodified Unity suite runs straight against the Rust build.

🧭 Contents

🎥 Demo video 📊 At a glance 🤔 Why cJSON 🔬 How this port proves equivalence 🚀 Build & run 🧑‍💻 Try it yourself 📁 Repository layout ✅ Track criteria 🧪 Fuzz & benchmark evidence

📊 At a glance

📦 Source project	`DaveGamble/cJSON` @ `v1.7.18` (MIT)
🦀 Ported	~4,600 LOC — `cJSON.c` + `cJSON_Utils.c` → Rust, zero external crates
🧪 Test suite	Original Unity suite, unmodified, hash-pinned, linked against the Rust build
✅ Test result	🟢 `22 / 22`

…

View on GitHub

Every number above is a committed file in the repo — fuzz logs, benchmark JSON, and DECISIONS.md (20 sections of reasoning, zero jokes, all receipts).

This was my Track A (C → Rust) submission for Port Mortem 2026. If you're doing a language port for anything — hackathon, work, fun — my one piece of advice is the whole post in one line: don't trust the green checkmark, run it yourself, count the tests, and if something doesn't add up, go find out why before you ship it.

Thanks for reading. 🦀

The Twelve-Factor App: 5 Surprising Truths About Modern Software

beTheNoob — Mon, 12 Jan 2026 20:09:44 +0000

Developers today face a common set of challenges: building applications that are portable, scalable, and maintainable across a variety of environments, from on-premises servers to cloud platforms like GCP, AWS, and Azure. To address these issues, developers at Heroku created the "Twelve-Factor App" methodology—a set of guiding principles for architecting robust, modern applications.

This article explores five of the most impactful and potentially counter-intuitive principles from this methodology. Understanding these factors can fundamentally change how you build and deploy software, leading to more resilient and scalable systems.

1. Your Processes Must Be Stateless (and Sticky Sessions Are a Trap)

A core tenet of the Twelve-Factor methodology is that application processes should be "stateless and share-nothing." This means that no single process should hold onto data that is required by another process for a subsequent request.

Consider a simple login session. If your application is running across three server instances, a user might log in and have their session information stored on the first instance. If their next request is routed to a different instance by the load balancer, the second instance, having no memory of the user's session, treats them as an unauthenticated visitor, forcing them to log in again.

A common but incorrect fix for this is using "sticky sessions," which configure the load balancer to always route a specific user back to the same instance. This is a direct violation of the Twelve-Factor methodology. The architecturally sound solution is to externalize any persistent data, like user session information, into a stateful backing service. By using a database or a caching service like Redis, any process on any instance can access the session data. This decoupling of state from process is the key to true horizontal scalability; it allows any number of identical processes to handle any user request, enabling the system to scale out effortlessly in response to load.

2. Logs Aren't Files, They're Event Streams

The traditional approach to logging involves an application writing its output to a local file, such as logFile.txt. In a modern, containerized world, this practice is deeply flawed. When a container is destroyed, whether during scaling, deployment, or a crash, its local filesystem is wiped out, and any logs stored there are lost forever.

A Twelve-Factor app never concerns itself with the routing or storage of its logs. Instead, it treats logs as an event stream, writing all log output to standard output. The execution environment, not the application, is responsible for capturing this stream. This transforms logs from a passive debugging file into a rich, queryable source of real-time business intelligence. The execution environment can now route these streams to powerful, centralized platforms like the ELK Stack (Elasticsearch, Logstash, Kibana) or Splunk for aggregation, analysis, and alerting.

3. One Project Can Mean Multiple Codebases

The first factor, "Codebase," emphasizes tracking all code in a version control system like Git to facilitate collaboration. However, it introduces a rule that might seem counter-intuitive: if a single project consists of multiple distinct application services—such as a payment service, an order processing service, and a web app—sharing a single codebase is a violation of the methodology.

The correct architecture dictates that each of these distinct services should be separated into its own individual codebase. Each codebase should have its own separate deployments for each environment, such as development, staging, and production. This principle aligns perfectly with modern microservice architectures. It enforces architectural boundaries, allowing the payment service team to deploy updates multiple times a day without any risk of disrupting or being blocked by work on the order processing service.

4. Your App Must Be Ready to Be Shut Down at Any Moment

The "Disposability" factor states that an application's processes must be designed to be started or stopped instantly. This capability is essential for achieving rapid elastic scaling, fast deployments, and overall system resilience.

To facilitate this, a Twelve-Factor app must support graceful shutdowns. When a process manager (like Docker) issues a stop command, it first sends a SIGTERM signal. This signal tells the application to finish its current request and shut down cleanly within a given grace period. If the process does not terminate in time, the manager sends a SIGKILL signal to forcefully terminate it. An application must be built to handle these signals properly to ensure clean shutdowns without data loss or corruption. This disposability is not just a best practice; it is a prerequisite for modern cloud-native platforms like Kubernetes, which rely on the ability to terminate and replace processes at will to perform rolling updates, manage load, and maintain system health.

5. Stop Saying "It Works on My Machine" with Dev/Prod Parity

The classic developer excuse, "It works on my machine," is a symptom of a deeper architectural problem: environmental drift. The concept of "Dev/Prod Parity" is designed for continuous deployment and aims to keep the gap between development and production environments as small as possible, providing a disciplined cure for that drift. To achieve this parity, the methodology prescribes several key practices:

Consistent Backing Services: Developers should resist the urge to use different backing services between development and production (e.g., using a lightweight local database in dev but a robust one in prod).
Identical Tooling: The tools used to build, test, and run the application should remain the same across all environments.
Developer Involvement: Developers should be involved in the deployment process to bridge the gap between writing code and seeing it run in production.

Conclusion

While some of these principles may seem strict or require rethinking traditional development habits, they provide a proven roadmap for building modern applications. By embracing concepts like statelessness, event stream logging, and dev/prod parity, you can create systems that are highly resilient, scalable, and portable across any infrastructure.

As you look at your own projects, which of these factors presents the biggest opportunity for improvement?