This is Thang!
Back to projects
PROJECT / 02 — NTU Students’ Union

NTUMods.

Better course planning starts with better data.

THE PROBLEM
Support course planning with prerequisite relationships and course data extraction.
MY ROLE
Contributed Django backend improvements, the Prerequisite Tree feature, and a Go scraper.
THE TOOLS
PythonDjangoGoREST APIsDFS
THE OUTCOME
Added prerequisite visualization and reduced reported scraping time from 15 minutes to 10 seconds.

Make the dependencies visible.

NTUMods is a non-profit, student-run course planning platform. My contributions focused on its backend: maintaining Django functionality, exposing prerequisite relationships, and improving course data extraction.

MEDIA SLOT / 01
FIG. 01 — NTUMods / course planning overviewILLUSTRATION · SOURCE MEDIA TO ADD

A tree behind the timetable.

I developed the Prerequisite Tree feature using depth-first search, JSON serialization, and REST APIs to support visualization of module dependencies.

ENGINEERING DECISION

Represent prerequisite relationships through the API

The contribution combines traversal of module dependencies with JSON serialization and a REST interface. The supplied resume does not specify the platform’s full frontend architecture or the handling of cyclic prerequisite data.

MEDIA SLOT / 02
FIG. 02 — Prerequisite Tree / feature capture to addILLUSTRATION · SOURCE MEDIA TO ADD

Less waiting for course data.

I implemented a Go scraper using its HTTP client, connection pooling, and concurrent requests with goroutines. The resume reports a reduction in scraping time from 15 minutes to 10 seconds.

WORKFLOW COMPARISON / SIMPLIFIED

A shorter path to course data.

BEFOREPrevious scraping workflow

Reported runtime: 15 minutes

MY CONTRIBUTIONGo scraper with concurrent requests

HTTP connection pooling / reported runtime: 10 seconds

Thang contributed the Go scraper to the team-owned NTUMods platform. The resume reports a reduction from 15 minutes to 10 seconds using connection pooling and goroutines. The previous implementation and workload conditions are not documented in the supplied material.
15m → 10s

reported scraping runtime

MEASUREMENT CONTEXT

Resume-reported before-and-after result. The source supplies no dataset size, network conditions, concurrency limit, run count, or baseline implementation details.

BENCHMARK METHODOLOGY & LIMITATIONS

The result is presented as reported, not as a reproducible benchmark or a guarantee for every run. Comparable workload and environment details would be needed to independently reproduce it.

MEDIA SLOT / 03
FIG. 03 — Scraper output / comparison to addILLUSTRATION · SOURCE MEDIA TO ADD
CONSTRAINT / BOUNDARY

Performance has operational boundaries

Connection pooling and concurrent requests are documented implementation choices. The supplied material does not establish retry behavior, rate limits, or error-recovery policies; those are not claimed here.

REFLECTION / NEXT STEPS

What to investigate next

A useful follow-up is to document the scraping workload, concurrency settings, and failure cases alongside repeated timings. For prerequisites, document traversal behavior and representative dependency examples.

NEXT ENGINEERING STORY / 01Redis Bloom

TCP sockets. One event loop. A database from scratch.