Rahul's Journal

My pre-first act as AWS club president was a disaster (and I learned a lot)

2026-10-29T00:00:00Z

Technically, I'm not president of the AWS Student Builder Group until 2027. So tonight was my pre-first act: the first time I stood up in front of a room and spoke for the club.

It did not go well.

I'm writing this while it still stings, because I'd rather learn from it properly than pretend it went fine.

The setup

Tonight was Monash University Malaysia's first-ever Tech Club Award Night: the campus tech clubs in one badminton court, with food, a lucky draw and awards. Every club had to send at least one representative (no one there meant your award nominations were forfeited), and each president had to present a one-slide recap of their year.

Mohamad, who started the AWS Student Builder Group, couldn't make it. As the incoming president, I said I'd go.

What I prepared

On paper, I was ready.

The slide: a timeline of our year, from our Cloud Fundamentals crash course in March to the AWS × Axrail AI site visit in October, with our numbers across the top: 10 events, 310 sign-ups, 291 attendances and 181 students.
The script: about two minutes, with every number highlighted so I could find my place.
The outfit: a charcoal suit with a knit polo. I genuinely asked whether a suit was too much.

Here's the catch. The slide was still changing on the afternoon of the event, and the script was finished less than two hours before I had to be there. That left under two hours to learn it, get changed and get to campus.

It also landed in one of the busiest stretches of my semester. I was preparing for a massive exam while finishing a big group assignment and an individual one. As well as preping for my internship starting a little bit after the exam period. That's not an excuse, since everyone in that room was juggling a semester too. It's just the context: the presentation was one more thing on the list, and it got whatever time was left over.

You can probably see where this is going.

What actually happened

I'm not going to dress it up: I messed up the presentation.

I was the last club to present, and by the time my turn came, the weight of it had fully set in. I was underprepared, and nothing I'd done that afternoon had got me ready for the real thing: standing up and doing it live.

So I rushed. I wasn't even reading off my notes. I went completely off script, tripped over my words, and spent most of it pointing at the monitor instead of looking at the audience.

I felt terrible walking off. The club had a genuinely great first year, and my two minutes didn't do it justice. Mohamad trusted me to represent the club he built, and it felt like I'd let him down.

Should I have prepared more? Could I have? Honestly, yes to both.

Everything I need to improve

This is the useful bit. Here's my list:

Finish early, then rehearse. Done two hours before isn't the same as ready. Next time the slide and script get locked a few days out, and the time before the event goes to practice.
Rehearse out loud. Reading a script in your head isn't practice. Standing up, saying it out loud and timing it is.
Learn the structure, not every word. Opening, numbers, timeline, thank you. If I know the four beats, one missed line doesn't sink the whole thing.
Keep a 30-second version ready. Events run late and slots get squeezed. I should be able to give the short version without panicking.
Check the setup before going up. How long do I get? Who changes the slide? Is there a mic? Where do I stand?
Practise in front of real people. My committee, friends, anyone. A room full of tech club presidents shouldn't be my first audience.
Have a recovery plan. If I lose my place: pause, look at the slide, and pick up from the next point. Nobody remembers a pause. They remember a spiral.

The plan

Presenting is now officially at the top of my list for 2027. Next year I'll be speaking at our own events, and every one of them is a rep. By the time I'm actually president, standing up in front of a room should feel normal.

The handover with Mohamad is coming up soon, and I've got the semester break to plan. ROUND TWO WILL BE BETTER.

The silver lining

The slide was right, even if my delivery wasn't. Ten events, 291 attendances, 181 students and a six-week Cloud Practitioner series in the club's first year is something to be proud of. That's on Mohamad and the committee, and two shaky minutes from me don't change it.

Pre-first act: disaster.

First act: still compiling.

FairSight revisited: the bias in my bias detector was twice what I claimed

2026-10-23T10:00:00Z

FairSight was our group project for FIT1055 (IT Professional Practice and Ethics): a platform that audits AI hiring systems for bias and explains every decision. The project site is fairsight.org. I built the Streamlit prototype, which is now back online at prototype.fairsight.org.

Putting it back online was a good excuse to check its numbers properly, and they weren't what the code said they'd be.

What the prototype does

It's a dashboard with five pages:

Overview and bias metrics: hire rates by gender, score distributions, and the effect of gender-coded keywords.
Explainability: which features drive the model's scores, overall and for any one applicant.
Mitigation: apply a fix and compare the metrics before and after.
Applicant view: "why was this decision made?" in plain language, plus a human review queue.
Audit and compliance report: a downloadable summary of all of the above.

The data: a deliberately biased model

There's no real hiring data to work with, so the prototype generates 1,200 synthetic applicants, modelled on the widely reported case of Amazon's experimental recruiting tool, scrapped in 2018 for penalising women's CVs.

Each applicant gets merit features (technical score, interview score, years of experience). Then the "model" scores them with three discriminatory penalties built in on purpose:

gender_penalty  = 0.18 * is_female
keyword_penalty = 0.04 * min(gender_coded_keywords, 5)
college_penalty = 0.10 * womens_college
final_score = base_score - gender_penalty - keyword_penalty - college_penalty

The top 30% of scores are hired. The generator's docstring says this produces a hire rate for women about 25 percentage points lower than for men.

What it actually produces

Running the project's own metrics on its own data:

Metric	Value	What it means
Male hire rate	54.1%	353 of 653 men
Female hire rate	1.3%	7 of 547 women
Demographic parity difference	0.528	A 52.8-point gap, not 25
Disparate impact ratio	0.024	Women are hired at 2.4% of men's rate
Composite bias score	0.99	On a 0–1 scale

A worked example of the two headline metrics, using these numbers:

Demographic parity difference = male hire rate − female hire rate = 0.541 − 0.013 = 0.528. Zero would mean equal hire rates.
Disparate impact ratio = female hire rate ÷ male hire rate = 0.013 ÷ 0.541 ≈ 0.024. The usual threshold is the four-fifths rule: below 0.8 is evidence of adverse impact. This one is more than 30 times below it.

Why the gap doubled

The penalties are large compared with the spread of scores:

The hiring cut-off (the 70th-percentile score) is about 0.44.
The average total penalty for a woman is 0.32: 0.18 for gender, plus roughly 0.12 for gender-coded keywords (women average about three), plus the college penalty for one in four.
The average penalty for a man is 0.02.

A penalty of 0.32 against a cut-off of 0.44 means almost no woman can be hired, however strong her CV. The penalties stack, and the docstring described one of them, not all three together.

For a teaching demo, an extreme bias still makes the point. But a tool whose whole purpose is honest measurement shouldn't misstate its own numbers. The fix is to tune the penalties until the measured gap matches the documented one, and to print the measured value in the docs rather than an intended one.

The "mitigation" only works because we wrote the bias

The mitigation page says it applies fairness-aware sample reweighting. The code does something simpler: it recomputes every score from the merit features alone, without the three penalty terms. The result looks great:

	Before	After
Female hire rate	1.3%	29.8%
Male hire rate	54.1%	30.2%
Disparate impact ratio	0.024	0.988

But this only works because we know exactly where the bias is: we put it there. In a real system you don't get a line saying gender_penalty = 0.18. Bias comes in through proxies: a women's college, a gap in employment, a hobby, wording in a CV. Deleting the obvious column ("fairness through unawareness") leaves the proxies doing the same job. That's how Amazon's model penalised women without ever being given gender.

So the honest label for that page is "what the hire rates would be without the planted bias", which is still a useful comparison. Real reweighting would weight training examples so that each group's outcomes are balanced, without assuming you know the cause.

The ethics part

FIT1055 was an ethics unit, so the prototype came with ethical pseudocode mapping every module to an ethical framework. We chose deontology as the main framework, because it turns into hard rules code can enforce:

RULE 1: GENDER_PENALTY          = FORBIDDEN
RULE 2: COLLEGE_TYPE_PENALTY    = FORBIDDEN
RULE 3: BIAS_DISCLOSURE         = MANDATORY
RULE 4: HUMAN_REVIEW_RIGHT      = PROTECTED
RULE 5: MERIT_FEATURES_ONLY     = REQUIRED

Virtue ethics came second, for the system's character: honesty in explanations, justice in scoring, responsibility for logging and flagging. We rejected pure utilitarianism, because maximising the overall hire rate could still justify penalising one group.

Rereading it now, my own findings above are RULE 3 in action. A bias tool that understates bias, or labels a fix as something it isn't, breaks the disclosure rule it was built to enforce.

What I took away

Measure, don't assume. The docstring described the intended bias. One run of the metrics would have shown the real one.
Name things for what they do. "Reweighting" and "remove the terms we added" are different techniques, and the difference is exactly what matters in the real world.
Synthetic data proves the plumbing, not the method. The dashboard, metrics and explanations work. Whether the mitigation works can only be tested on bias you didn't write yourself.

Rereading my pathfinding visualiser: A*, Dijkstra, and an RRT that never arrives

2026-10-23T08:00:00Z

One of my first projects at Monash (for FIT1045) was a 2D pathfinding visualiser: draw obstacles on a grid, pick start and end points, and watch an algorithm find a path. It's back online at pathfinding.vrp2206.com as part of putting old projects back online.

Before linking it from my portfolio, I reread the code and, for the first time, benchmarked it properly.

What it does

Built with Streamlit and Plotly, it offers three algorithms:

Dijkstra: expands outward in order of distance from the start. Guaranteed shortest path.
A*: Dijkstra plus a heuristic that estimates the remaining distance to the goal, so it explores towards the goal first. Also guaranteed shortest, if the heuristic never overestimates.
RRT (Rapidly-exploring Random Tree): a sampling-based planner from robotics. It grows a tree towards random points until a branch happens to get near the goal. No guarantee of the shortest path, or of any path.

The grid is 8-connected: you can move diagonally, and a diagonal step costs √2 ≈ 1.414 instead of 1.

The README describes the wrong heuristic

The README says A* uses Manhattan distance. The code uses Euclidean distance:

def distance(self, pos1, pos2):
    return np.sqrt(sum((a - b) ** 2 for a, b in zip(pos1, pos2)))

That's a lucky mismatch, because the code is the right one. A* is only guaranteed to find the shortest path if its heuristic is admissible: it must never overestimate the real remaining cost.

A worked example. Going from (0, 0) to (3, 3) on this grid:

	Estimate or cost
Real cheapest path: 3 diagonal steps	3 × √2 ≈ 4.24
Euclidean heuristic: √(3² + 3²)	≈ 4.24, never more than the real cost ✓
Manhattan heuristic: 3 + 3	6, an overestimate ✗

With diagonal moves, Manhattan distance overestimates, and A* could return a path that isn't the shortest. (The textbook choice for 8-connected grids is the octile distance, which is exact on an empty grid. Euclidean is admissible too, just a little less sharp.) So the code is correct and the README needed fixing.

The benchmark

The app has a comparison mode, but it times a single grid once. I wrote a small script that runs the project's own AStar, Dijkstra and RRT classes on 40 random grids per setting, from the top-left corner to the bottom-right, skipping grids with no possible path:

Grid	Algorithm	Found a path	Cells explored	Time	Path cost
15×15, 20% walls	A*	40 / 40	46	1.1 ms	20.71
	Dijkstra	40 / 40	184	1.8 ms	20.71
	RRT	39 / 40	104	36 ms	24.62
50×50, 20% walls	A*	40 / 40	357	9.1 ms	71.51
	Dijkstra	40 / 40	2,048	21.9 ms	71.51
	RRT	0 / 40	304	163 ms	none
50×50, 30% walls	A*	36 / 36	462	11.7 ms	72.91
	Dijkstra	36 / 36	1,852	19.1 ms	72.91
	RRT	0 / 36	225	128 ms	none

Averages per grid. Path cost counts a diagonal step as √2. Times are from one Python run and only comparable within the table.

What the numbers say

A and Dijkstra always agree on the path cost.* That's the check that matters most: both are supposed to be optimal, and on 116 grids they never disagreed.

A does the same job with far less searching.* On 50×50 grids it explored about 5.7× fewer cells than Dijkstra (357 vs 2,048). That gap is the whole point of a heuristic: Dijkstra spreads out in a circle, while A* leans towards the goal.

The time gap is smaller than the cell gap. A* explores 5.7× fewer cells but is only about 2.4× faster, because each A* step also computes the heuristic. "Cells explored" is the fairer measure. Wall-clock time in Python measures the interpreter as much as the algorithm.

RRT never reaches the goal on a 50×50 grid. Three reasons, all visible in the code:

It stops after 500 iterations. On a 15×15 grid that's plenty. On 50×50 the tree needs to grow about 70 cells' worth of distance through obstacles, while most random samples pull it in other directions.
It only grows one cell at a time towards each random point, so progress is slow.
Finding the nearest tree node is a linear scan over the whole tree every iteration, so it gets slower as the tree grows. That's why RRT is the slowest of the three, despite exploring fewer cells than Dijkstra.

Even when it succeeds on small grids, its paths cost about 19% more than the optimum (24.62 vs 20.71). RRT shines in continuous, high-dimensional spaces such as robot arms, where you can't list every cell. On a small 2D grid, A* is better in every way.

What I'd change now

Fix the README to say Euclidean, and explain why Manhattan would be wrong here.
Report path cost, not path length. The app's "Path Length" counts cells, so ten diagonal steps and ten straight steps look the same, even though the diagonal path costs about 41% more.
Skip stale queue entries in A*. It pushes a cell again when it finds a better route, and later pops the old entry and expands it again. That's harmless for correctness here, but wasted work. One if current in closed: continue fixes it, the same way the Dijkstra code already does.
Give RRT a fair chance: scale the iteration limit with the grid size, take longer steps, and add goal bias (aim straight at the goal some fraction of the time).
Benchmark many grids, not one. A single run tells you very little. Forty runs per setting made every pattern above obvious.

The code I wrote in first year was mostly right. The parts that were wrong were the claims around it: the README, the metric names and the comparison. That's what rereading old code is good for.

Putting three old projects back online with one Dockerfile

2026-10-23T06:00:00Z

Before the homelab had to survive three months without me, I wanted my older projects back on the web, linked from my portfolio, instead of sitting in repos nobody runs. Three of them were Streamlit apps:

Project	From	Now at
A turn-based roguelike	FIT1045	`roguelike.vrp2206.com`
A 2D pathfinding visualiser	FIT1045	`pathfinding.vrp2206.com`
FairSight, a hiring-bias dashboard	FIT1055 group project	`prototype.fairsight.org`

Three similar apps is the point where copy-pasting a setup three times starts to hurt. So they share one pattern.

One folder per app

~/Projects/
├── proxy/          Caddy + the main tunnel, one block per hostname
├── roguelike/
│   ├── src/        the app's git checkout (branch main)
│   ├── Dockerfile
│   ├── docker-compose.yml
│   └── .env        this app's tunnel token, readable only by me
├── pathfinding/    same layout
└── fairsight/      same layout

The app's own repo lives untouched in src/. Everything about running it lives one level up. That keeps deployment files out of coursework repos, and redeploying after a push is one line:

git -C src pull && docker compose up -d --build

The shared Dockerfile

All three use the same Dockerfile. Only two things change per app: which packages to install and which file to run.

FROM python:3.13-slim
ARG PIP_INSTALL
WORKDIR /app
COPY . .
RUN pip install --no-cache-dir $PIP_INSTALL \
 && useradd --create-home app && chown -R app:app /app
USER app
ENV APP_FILE=app.py
EXPOSE 8501
HEALTHCHECK --interval=30s --timeout=5s --start-period=20s --retries=3 \
  CMD python -c "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8501/_stcore/health')"
CMD ["sh", "-c", "exec streamlit run \"$APP_FILE\" --server.headless=true \
     --server.address=0.0.0.0 --server.port=8501 --server.fileWatcherType=none \
     --browser.gatherUsageStats=false --client.toolbarMode=viewer"]

The choices that matter:

A non-root user. If someone finds a way to run code through the app, they get an unprivileged account inside a container, not root.
A health check against Streamlit's own /_stcore/health endpoint, using Python's standard library, so the slim image doesn't need curl. Docker now knows the difference between "running" and "working".
Pinned versions where the repo had no requirements.txt, passed in as a build argument (streamlit==1.40.2, and plotly/numpy for the pathfinder). An old app shouldn't break because a library released a new major version.
Production flags for Streamlit: no file watcher (nothing is being edited in the container), no usage statistics, and a viewer-only toolbar so visitors don't get developer options.

Each docker-compose.yml then adds a 512 MB memory limit, so one misbehaving app can't starve everything else on the box, and publishes the app on loopback only:

ports:
  - "127.0.0.1:8501:8501"   # 8502 and 8503 for the other two

Routing: Caddy, on loopback only

Public traffic arrives the same way as for ShipDoc: Cloudflare Tunnel → Caddy → app. The new apps are three more blocks:

http://roguelike.vrp2206.com {
	reverse_proxy localhost:8501
}
http://pathfinding.vrp2206.com {
	reverse_proxy localhost:8502
}
http://prototype.fairsight.org {
	reverse_proxy localhost:8503
}

Caddy got one more change at the same time. It runs with network_mode: host, and by default it listened on port 80 on every interface, so anything on my LAN could reach every site directly, around the tunnel. One global option fixes that:

{
	auto_https off
	# Loopback only: cloudflared (host network) is the sole way in
	default_bind 127.0.0.1 [::1]
}

Now the tunnel is the only way in. Both the old Caddyfile and compose file were copied to dated .bak-2026-10-23 files before any edit, so rolling back is a copy.

Each app's compose file also runs its own cloudflared connector, with its own token and its own metrics port (20242–20244). An app and its tunnel live in the same folder, so they're started, stopped and deleted together.

A bug that only exists once it's public

The roguelike was written to be played by one person on one laptop. It has a persistent save: after every room, the whole game state is written to advanced_game_data.json, and a new game session loads that file on startup.

On a laptop, that's a save game. On a public server, everyone shares one save file. A new visitor doesn't start a new run: they pick up wherever the last visitor left off. The repo even ships with a save in it, a Tank in room 5 with exactly this much health:

"health": 9.900000000000002

(Damage is scaled by armour, attack * (1 - defense), so a Tank takes hits like 0.85. Subtract enough of those and floating-point rounding shows up, because numbers like 0.85 and 9.9 can't be stored exactly in binary. The fix there is just rounding for display.)

The proper fix is to keep game state in Streamlit's per-browser session_state and either drop the file save or give each visitor their own save. Until then, the game works, but it's multiplayer in a way I never designed.

Why bother with old projects?

These were coursework, and they're not what I'd write today. But a link on a portfolio that actually opens is worth more than a screenshot. And as the next two posts show, rereading old code with fresh eyes turns up things I couldn't see when I wrote it: a pathfinder that isn't quite what its README says, and a bias dashboard whose bias was bigger than I'd claimed.

My "LAN speed test" was actually an internet speed test

2026-10-22T06:01:00Z

A few days ago, while updating my homelab server to the latest Arch Linux packages and installing CUDA for ExamX, I found that its LAN cable was faulty. The link had fallen back to 10 Mbit/s. I swapped in a Cat6 cable and the link came back up at 1000 Mbit/s.

A link speed is only what the two ends agreed on, though, not what actually gets through. I wanted to know how fast the network really is, so I tested it with the standard tool is iperf3: run a server on one end and a client on the other, and it measures raw throughput with the disks out of the picture.

iperf3 -s                    # on the server, listens on port 5201
iperf3 -c <server-ip>        # on the client
iperf3 -c <server-ip> -R     # reverse direction: server sends to the client

Attempt 1: timed out

I pointed my Windows PC at the server's wired LAN address and got:

iperf3: error - unable to connect to server - server may have stopped running
or use a different port, firewall issue, etc.: Connection timed out

My first thought was the firewall. But ping to the same address timed out too, so this wasn't about iperf3 or a port at all. The PC couldn't reach that address.

The clue I'd left out

Then I mentioned something I hadn't thought to say: I was talking to Claude over SSH from that same PC. If SSH works but the LAN address doesn't, the SSH session must be taking a different path. Claude checked where the session was coming from: a Tailscale address. The PC wasn't on my home LAN at all. It was reaching the server through the Tailscale tunnel.

Attempt 2: about 30 Mbit/s

Pointed at the server's Tailscale address, iperf3 connected and reported about 30 Mbit/s. That's terrible for gigabit Ethernet, and with the old cable fresh in my mind, I assumed the new one was bad too.

It wasn't. tailscale status showed a direct connection (not relayed through a DERP server), with the PC at a public IP on a different network about 10 ms away. So the test measured:

the slower of the PC's download speed and the server's home upload speed, minus a little WireGuard overhead.

30 Mbit/s is a normal home upload speed. The number was right. I was just measuring something other than what I thought.

Checking the actual LAN link

That still left the question I'd started with: was the new cable any good? Claude ran a few checks from the server towards the router:

Link speed: ethtool reported 1000Mb/s, so the Cat6 cable and router port negotiated gigabit. A damaged cable usually falls back to 100 Mbit/s, or all the way to 10 like my old one did.
Latency to the router: about 0.8 ms average, with 0% packet loss.

The new cable is fine. Measuring the link's real throughput needs a second wired device on the same LAN running iperf3 -s, since most routers can't act as an iperf3 endpoint.

Takeaways

A timeout on both ping and the app means a reachability problem, not a port or firewall problem in the app.
Know which path your traffic takes. With Tailscale running, "the server's address" can mean a LAN IP, a tailnet IP or something routed in between. Check with tailscale status, and echo $SSH_CLIENT shows where an SSH session is coming from.
Over a VPN, iperf3 measures the internet. Over the internet, home upload speed is almost always the bottleneck.
ethtool <iface> | grep Speed is the 5-second cable check. A faulty cable usually shows up as a link stuck at 100 or 10 Mbit/s. Check it before you blame the cable.

My new monitoring paged me twice on day one. Good.

2026-10-22T05:45:00Z

The hardening work added two new scheduled jobs: a 5-minute heartbeat to healthchecks.io and a nightly restic backup. Both had passed their tests. Within 24 hours, both triggered a Discord alert.

Alert 1: the heartbeat "failed"

archlinux: Failed systemd units: server-heartbeat.service

The server was fine. The journal showed two failed pings to hc-ping.com: a timeout, and then an HTTP/2 error on the next try. My own connection looked healthy (0% loss to 1.1.1.1 at about 2.5 ms), but the route to the ping service was about 240 ms away and dropping a lot of ICMP.

The real bug was the design. The heartbeat script exited non-zero when a ping failed, so systemd marked the unit failed, and my existing health monitor (which reports failed units to Discord) raised the alarm.

But a missed ping is already the signal. healthchecks.io alerts when pings stop arriving, so making the unit fail too just creates a second, noisier alert. The fix:

ping over HTTP/1.1, which avoids the HTTP/2 failure;
retry up to 5 times, 3 seconds apart;
never fail the unit because a ping failed. If the pings really stop, healthchecks.io alerts after the 10-minute grace period.

The backup job's pings got the same treatment.

The good news: the alert chain worked end to end. A problem was detected and reached my phone within minutes.

Alert 2: the backup failed at 03:36

⚠️ archlinux: Failed systemd units: server-backup.service

This one was a genuine failure, and nothing had been backed up that night. restic stopped within a second because it couldn't find a cache directory. When systemd runs a service, HOME isn't set, and restic puts its cache under $HOME/.cache.

The first run had worked because it was started by hand from a shell that has a home directory. The fix was one line in the unit and one in the script:

# /etc/systemd/system/server-backup.service
[Service]
Environment=HOME=/root

# /usr/local/bin/server-backup
export RESTIC_CACHE_DIR=/var/cache/restic

Running it exactly the way the timer does took about 12 seconds, the repository check came back clean, and the backup check on healthchecks.io went green again.

The lesson: test the way it will actually run

Both jobs passed their tests. Both tests ran in a different environment from the real one:

Job	How it was tested	How it really runs
Heartbeat	One manual ping, on a good connection	Every 5 minutes, all day, over a flaky route
Backup	Started from an interactive shell	Started by systemd at 03:30, with no `HOME`

If I'd found the backup bug in month two instead of on day one, I'd have had weeks of "backup failed" alerts to deal with from abroad, or worse, I'd have missed them. Before I leave:

Run every unit with systemctl start, not by running the script by hand. That's the environment the timer gives it.
Do a full reboot test, so everything starts from cold the way it will after a power cut.
Make alerts mean one thing. One problem should raise one alert, from the system best placed to notice it.

Two pages on day one is annoying. Two pages in month two, from another country, would have been much worse.

Getting a homelab ready to run for three months without me

2026-10-21T08:33:00Z

I'll be out of the country for three months with no physical access to the server, and I had about a month to prepare. After the audit, the question became concrete: what could take this machine down or lock me out while I'm away, and how would I even know?

I started a new Claude Code session on the server and asked it to find every failure point and fix what it could.

The failure points

The first survey sorted the risks into "critical before you leave" and the rest:

The machine could fall asleep. It's a laptop, and closing the lid suspends it by default. A suspended server is a dead server.
Power cuts. The battery is at about 74% of its design capacity after 1,490 cycles, and there's no UPS. After an outage, the machine only comes back if the BIOS powers it on when AC returns.
One way in. One SSH key, and one other device on Tailscale. Lose that laptop and I'm locked out for three months.
No backups. The only copy of everything, including .env files and tunnel credentials, was on one SSD.
SSH accepted passwords on every interface.

Never sleep, and reboot if frozen

The easy wins went in first:

a logind.conf.d drop-in so the lid switch, idle and the power key are ignored;
sleep.target, suspend.target and hibernate.target masked, so nothing can suspend it by accident;
a hardware watchdog that reboots the machine if it freezes for 30 seconds;
a full system upgrade (including Tailscale), the journal capped at 500 MB and 3 months, and 2 GB of Docker build cache cleared;
/boot permissions tightened, so the random seed is no longer world-readable.

SSH: keys only, verified before switching

My past logins had used a password, so turning passwords off blind could have locked me out. The order mattered:

I tested a key-only login from my laptop: ssh -o PasswordAuthentication=no ....
Only after that worked did PasswordAuthentication no go in, along with no root login, AllowUsers, 3 attempts maximum and a short login grace time.
fail2ban watches sshd, with my own networks on the ignore list so I can't ban myself.

A second way in

A second device on Tailscale and a second SSH key, on different hardware:

I added my phone to the tailnet.
I generated an ed25519 key in Termux. My first try failed because I typed ssh keygen instead of ssh-keygen, and ssh tried to connect to a host called "keygen".
Claude added the public key, I logged in from the phone on mobile data with Wi-Fi off, and the SSH log confirmed it was the phone's key that got in.
I turned off Tailscale key expiry for the server, which otherwise drops off the tailnet after about 180 days.

Wiping the HDD: storage and backups

The 1 TB HDD only held old Windows data, so I asked for it to be wiped. Before touching it, Claude checked the drive's serial number matched the HDD, not the NVMe. That's a cheap check against the most expensive possible mistake.

It's now two ext4 partitions, both mounted with nofail so a dead drive can't stop the boot:

Mount	Size	For
`/mnt/storage`	462 GB	A network storage project
`/mnt/backup`	454 GB	Backups, root-only

Backups that are tested, not assumed

The backups use restic: a nightly systemd timer backs up /home and /etc to /mnt/backup, keeps 7 daily, 4 weekly and 6 monthly snapshots, and runs restic check afterwards.

The first run used 35 GB. The same job then restored a file from the snapshot and compared it with the original, and they matched. A backup you've never restored from is only a hope.

The weak spot is clear: backups on the same machine as the data don't survive theft, fire or a power surge. An offsite copy is still on the list.

Docker and the demo sites

The two app ports that were published on every interface are now bound to 127.0.0.1. The tunnel and Caddy reach them locally.
Container logs rotate at 10 MB × 3 files.
Fresh Caddy and cloudflared images, all containers recreated, and all three sites returned 200 afterwards.

Trying network storage, then turning it off

I tried a Samba share for /mnt/storage. It was set up as tightly as I could think of:

SMB3 with encryption required;
no guest access;
bound to the Tailscale address only, with an nftables rule dropping SMB from anything else;
a dedicated Samba password.

Windows rejected the first password (the fix was a simpler password and the username written as server\user), but after that it worked. Then I asked for it to be turned off again. I want to understand the trade-offs before leaving a file share running for three months. It's disabled with the config kept, so turning it back on is one command.

An alarm that works when the server doesn't

The server already sends health reports to Discord, but if it dies, it goes quiet, and silence looks exactly like "everything's fine". So we added a dead-man's switch with healthchecks.io:

Heartbeat: every 5 minutes, a script checks that all mounts are present, all containers are running, the sites respond on localhost, there are no failed units, the disk is under 90% and Tailscale is up. If all of that holds it pings healthchecks.io. If not, it pings the /fail URL with the list of problems. If the server is dead, the pings stop, and that's the alert.
Backups: the nightly job reports start, success and failure to a second check.
Alerts go to email, WhatsApp and Discord.

We tested the failure path for real: stopping a container produced "only 3/4 containers running" within one run.

Still on the list

Checking the BIOS for a "power on after AC loss" option. Lenovo consumer laptops rarely have one, so the fallback is a trusted person who can press the power button.
A low-battery clean shutdown, to stop adding to that unsafe-shutdown count.
A full reboot test, so every timer and service gets exercised from a cold start.
An offsite backup copy.
Rotating the credentials that passed through chat while we were moving fast.

The reboot test turned out to matter more than I thought. Within a day, two of the new jobs failed for real. That's part 3.

ExamX, part 2: cloud models, a public site, and pressing pause

2026-10-21T00:00:00Z

Part 1 ended with a working generator and grader, held back by a local model that was too small to write good questions. Around midnight I asked the obvious question: would a free cloud model fix it?

Would Gemini solve the problem?

Mostly, yes, with a few catches that were worth spelling out before building anything:

It's no longer local. That was fine: I dropped the "runs locally" requirement.
The free tier may use your prompts for training. That would include past-paper text and my answers.
It needs an API key, which has to live in the environment and never in the repo.
The exact checkers stay in charge of anything they can check. A better model makes fewer mistakes, but not zero.

Three back ends and a model switcher

The LLM client got three interchangeable back ends, chosen with a provider:model spec:

examx generate --model qwen3:8b                  # local, via Ollama
examx generate --model gemini                    # Google's default model
examx generate --model claude:claude-sonnet-5-5  # Anthropic
examx models                                     # which back ends are ready

The web UI got a matching AI model page. It shows whether each provider is ready and how to set it up if not, and a chip in the header always shows the current model. The UI also gained dark mode, a phone layout, past-paper diagrams inside questions, and answers saved in the browser as you type.

The free tier is 20 requests a day

I set up a Gemini key (in a file only my user can read, loaded by ~/.bashrc, nowhere near the repo). The first surprise: gemini-2.5-flash was no longer offered to new keys, so the default moved to gemini-3.5-flash. It answered a test question about decidability correctly in under 4 seconds.

Then a full paper ran for 22 minutes and produced almost nothing from Gemini:

the free tier allows 20 requests per day for that model, and one AI-written paper needs 15–25;
several calls failed earlier anyway with "model experiencing high demand";
my retry logic waited and retried for minutes, even after the daily quota was gone.

The fix was to treat "quota used up for hours" differently from "slow down for a minute". ExamX now stops at once, skips that model for the rest of the run, and says when the quota resets. In practice the free tier gives you about one AI-written paper or one marked attempt a day.

Putting it online

I decided to try Claude Sonnet instead and asked for the app at exam-x.vrp2206.com. The server already ran Caddy and a Cloudflare Tunnel for my hackathon demo sites, so ExamX went in as a Docker container behind its own tunnel.

Two design decisions from this part are worth keeping:

API keys live in the visitor's browser, not on the server. You paste your key into the AI model page. It's stored as an HttpOnly cookie, checked once against the provider's free model-list endpoint, used only while your job runs, and never written to disk or logged. By default it's forgotten when you close the browser.
Fail closed. The app first refused every request that hadn't passed Cloudflare Access.

Cloudflare Access then asked for a credit card, so I asked to drop it. Before switching the guard off, Claude added the protections a public site needs:

visitors can only use their own Claude or Gemini key, never my local GPU models or a server-side key;
each browser gets an anonymous ID and only sees its own papers and reports;
the model choice is per browser, and each visitor has daily job limits;
the owner still has full access from the server itself.

Pressing pause

That's where I stopped. The Claude API is billed separately from a Claude Pro subscription. The free Gemini tier is too small to rely on. The local models are too weak to write new questions. And the real goal was passing the exam, not shipping a product the night before.

So ExamX was shut down cleanly:

both containers (the app and its tunnel) removed, and the Caddy route removed and reloaded, with the other sites checked afterwards;
a "Project status: paused" section at the top of the README, covering what's done, what I learned and the next steps;
the code tagged v0.1-paused.

I kept the Ollama models (they're useful for other ML work) and left the GitHub repo public rather than archived, in case someone else wants to pick it up.

What I took away

Let code mark what code can mark. The exact checkers were the most reliable part of the whole project, and they need no model at all.
Small local models are good at following a template, not at inventing correct maths. Using real past questions with official solutions beat every LLM-written alternative I tried.
Free tiers have shapes. "20 requests a day" changes the whole design of a tool that needs 25 requests per run.
Don't paste secrets into a chat. I pasted a tunnel token into the conversation to save time, which meant treating it as leaked and replacing it. The final version of the app asks for keys through a form instead.
Stopping is a valid ending. The tool still works offline for practice: examx generate --no-llm and exact marking, no AI needed.

Auditing a gaming laptop that thinks it's a server

2026-10-20T14:21:00Z

My homelab server is a Lenovo Legion gaming laptop running Arch Linux. It hosts my hackathon demo sites (kept online for my CV, ShipDoc among them), Docker, Tailscale and a Cloudflare Tunnel. It had been running for a while without anyone looking at it critically, and now real projects depended on it, so I asked Claude Code to audit the quality of the system and how it was set up.

The ground rules

Read-only first. The first pass ran without root.
Don't touch the other Claude. Another Claude Code session was busy building ExamX in a tmux window on the same machine. The audit stayed away from that directory and that session.
Root without sharing the password. A ! command in Claude Code has no terminal, so sudo can't prompt there. Instead of passing my password into the session, Claude wrote a read-only audit script. I read it, ran it with sudo in my own terminal, and Claude read the output file.

That last pattern is worth reusing: the AI writes the script, you review and run it, and it reads the results. No credentials ever enter the chat.

What was already fine

No failed systemd units, and the system was up to date.
Only 59 explicitly installed packages. Package signature checking was on.
sudo requires a password (no NOPASSWD anywhere).
Every SSH login in the journal was key-based, from my own laptop over Tailscale.
Both drives passed SMART. The HDD had 0 reallocated or pending sectors, and the NVMe had 0 media errors.
No port forwarding: remote access goes through Tailscale and a Cloudflare Tunnel.

What wasn't, worst first

No host firewall at all. The INPUT policy was ACCEPT for IPv4 and IPv6. SSH, HTTP, the tunnel's metrics port and two Docker-published app ports were listening on every interface. On a machine that has been moved between networks, that matters.
SSH accepted passwords. sshd -T confirmed PasswordAuthentication yes. I only ever use keys, so turning passwords off costs nothing.
/boot was world-readable, including the random seed file, which systemd flags as a security hole.
86 unsafe shutdowns on the NVMe, and 17% wear after only about 3,000 power-on hours. The last boot had ended with watchdog did not stop!. That's what a laptop that sometimes gets hard-powered-off looks like.
No backups. Nothing was configured, /home lived on a single drive, and the 1 TB HDD held old Windows data, mounted read-only.
Smaller items: membership of the docker group (root-equivalent), unpinned :latest images, 589 MB of reclaimable build cache, orphaned packages and a BIOS from 2022.

There was also one thing the audit couldn't fully explain: / was 20 GB used of 32 GB, but Docker only accounted for 0.4 GB of it.

The output: a plan, not changes

The result wasn't a pile of edits. It was a single Markdown file:

a snapshot of the system and what's already good;
an 11-item TODO list in priority order;
copy-pasteable fixes, each with a rollback note;
a suggested order of work and the open questions for me to decide.

I sent it to my Windows laptop with Taildrop (tailscale file cp). Taildrop needs root, or a one-time tailscale set --operator=<user>. Claude wouldn't change my Tailscale settings without asking, so I ran the send myself.

Nothing was changed in this session. The point of an audit is to know what you're dealing with before you touch it.

The next day this audit turned into a much bigger job. I'll be out of the country for three months with no physical access to the box. Part 2 is about getting it ready for that.

ExamX, part 1: a practice-exam generator that marks its own papers

2026-10-20T13:35:00Z

My FIT2014 exam (Theory of Computation at Monash) was coming up, and I had five past papers but only two sets of solutions. I wanted more practice than that, so I wrote a brief for a system and handed it to Claude Code, running on my homelab server: build a tool that generates new practice papers with worked solutions and marks my attempts, using only free tools and a local model.

This post covers that first evening. Part 2 covers cloud models, putting it online, and why I paused it.

The brief

Data: the 2013 sample exam plus the 2013, 2014, 2015 and 2017 papers. Only two of them came with solutions.
Hardware: the server has 8 CPU cores, 31 GB of RAM and a GTX 1650 with 4 GB of VRAM. That's a small budget for running an LLM.
Rules: free tools only, a Python virtual environment inside the repo, small commits pushed often, and no credentials stored anywhere.

Step 1: getting the papers in

All the PDFs had real text in them, so no OCR was needed. Ingestion used PyMuPDF to split each paper into questions and parts, tag each one with a topic, and match it to its official solution where one existed.

One check made me trust the parser: every paper's marks added up to exactly 120. That caught several splitting bugs early.

Two details mattered more than I expected:

Superscripts. Expressions like a^mbⁿ lose their meaning if the exponent becomes plain text. The parser reads font sizes and positions so they survive as a^{m}b^{n}.
Colour. In the solution PDFs, the answers and the marker's comments are in different colours, so the parser separates them by colour.

The result was 101 structured questions in JSON, with the diagrams saved as images.

Step 2: let code mark what code can mark

Much of FIT2014 has answers you can check exactly. Two regular expressions either describe the same language or they don't, and a Turing machine either computes the right output or it doesn't. So before any LLM was involved, the project got a set of exact checkers:

Checker	What it decides
Regex / automata	Language equivalence, with the shortest string where two answers differ
Subset construction and minimisation	Whether an NFA→DFA conversion or a minimised DFA is correct
Context-free grammars	Membership (Earley parsing), derivations, bounded language comparison
Turing machines and PDAs	Simulation on test inputs
Propositional logic	Truth tables and CNF

Because the checkers name a concrete counterexample, the feedback is specific: "your regex accepts abba, the language doesn't".

One bug was a good lesson. Some reference Turing machines kept crashing off the left end of the tape. FIT2014 uses one-way infinite tapes, so a machine can't detect the left end unless it marks it first. The fix belonged in the machines, not in the simulator.

Step 3: generating new papers

The generator samples a blueprint from the past papers (which topics, how many marks) and fills each slot in one of two ways:

Procedural questions. Code generates the automata, grammar, logic and decidability questions, so their solutions are correct by construction. Each model solution is fed back through the grader and must score full marks.
LLM questions. For proofs and explanations, a local model writes new questions using past-paper questions as examples.

Papers come out as Markdown, PDF and JSON. The PDF path is Markdown → HTML → PyMuPDF, so no LaTeX install was needed.

Where the local model fell over

I benchmarked the Qwen3 models through Ollama. The 8B model was the largest that ran at a usable speed (about 8 tokens/s, split between the 4 GB GPU and system RAM), and the only one that wrote a correct proof in the benchmark.

A full paper took 19 minutes, and about half of the LLM-written questions were poor:

near-duplicate questions;
a "prove that…" of a statement that is false;
wrong answers on decidability;
an NP-completeness question that didn't make sense.

So we added quality controls: near-duplicate drafts got rejected, a self-review pass checked each question, and LLM-written questions got flagged in the solutions. The second run took 39 minutes and was worse. The self-review changed a correct answer ("is this grammar property decidable? No") into a wrong one. Five questions fixated on the same grammar, and two of them asked students to prove something it doesn't generate.

An 8B model on a 4 GB card can't be trusted to invent exam questions and their solutions. The checkers can't save a question that's wrong to begin with.

The fix was to give the LLM less to do. Decidability tables and language-class questions moved to code. Proof and explanation slots now use real past questions with their official solutions by default. LLM-written questions became an opt-in --prose llm experiment.

Marking proofs

Proofs can't be checked by code, so an LLM marks them against a rubric. The 8B model gave a correct proof 1–3 out of 7 and claimed a true step was false. Moving proof marking to qwen3:14b fixed most of that:

the correct proof got 5/7, with accurate feedback;
a deliberately bogus proof got 0/7, so the 14B model wasn't just being lenient;
each proof took about 2 minutes to mark.

Proof marks are still labelled advisory in the report.

Where it ended up after one evening

A CLI (ingest, generate, grade, check, serve and more) and a small web UI built on Python's standard-library HTTP server.
108 passing tests, many built from real past-paper answers.
An example paper, a deliberately mixed sample attempt, and its marking report in the repo.
A README that records both LLM runs and their failures as well as the successes.

examx generate --no-llm makes a fresh paper in about a second, and the exact checkers mark it instantly. That alone was worth building. The open question was whether a better model would fix the question writing, which is where part 2 picks up.

ShipDoc, part 2: moving off AWS before the account expired

2026-10-18T15:00:00Z

In part 1, ShipDoc went live on AWS: Lambda for the API, DynamoDB for results, Amplify for the website. The catch was that the AWS account came with the hackathon, and it expired on 18 October. When it did, everything on it would go with it.

A hackathon project listed on a CV should still work when someone clicks the link months later. So I moved it to my homelab server.

Move first, switch later

I didn't shut AWS down and then rebuild. Instead:

Run a second copy of ShipDoc on the homelab, on new subdomains: lab.shipdoc.org for the website and lab-api.shipdoc.org for the API.
Test it there while shipdoc.org was still served from AWS.
When the account expired, point shipdoc.org at the homelab.

For a few days both versions were live, and nothing a visitor saw depended on the new one working.

From Lambda back to plain Docker

The cloud version was shaped around Lambda: a Mangum wrapper and DynamoDB, because Lambda runs short-lived copies side by side. The homelab doesn't need any of that. The repo already had a docker-compose.yml with two services:

api: the same FastAPI app, keeping results in a JSON file on a mounted volume, so they survive restarts;
web: the React site, built into static files and served by nginx.

Both are published on 127.0.0.1 only, never on the LAN:

ports:
  - "127.0.0.1:8000:8000"   # api
  - "127.0.0.1:5173:80"     # web

One detail matters when moving a Vite site. Vite bakes the API address into the JavaScript at build time, so changing an environment variable on the running container does nothing. The address has to be passed as a build argument (VITE_API_URL=https://lab-api.shipdoc.org) and the image rebuilt. The Android app is different: it has a setting for the API address, so it could be repointed without a rebuild.

Caddy and the tunnel

Every public site on the homelab follows the same path:

visitor → Cloudflare → Cloudflare Tunnel → Caddy on :80 → app on 127.0.0.1

The tunnel connects outwards from the server, so there are no open ports on my home router. Cloudflare handles HTTPS, so Caddy only speaks plain HTTP on loopback, with one block per hostname:

{
	auto_https off
}
http://lab.shipdoc.org {
	reverse_proxy localhost:5173
}
http://lab-api.shipdoc.org {
	reverse_proxy localhost:8000
}

What happens to shipdoc.org

When the account expired, the Amplify site and the Lambda API went with it. Rather than letting shipdoc.org show an error, I pointed it at the homelab too and gave it a third Caddy block that serves a single static page:

http://shipdoc.org, http://www.shipdoc.org {
	root * /srv/notice
	file_server
}

The page says plainly that the AWS deployment was taken down because the account expired, and links to the new website, the new API and the docs (which never depended on AWS: they're on Cloudflare). Old links in the README, the slides and the demo video still lead somewhere useful.

Trade-offs

	AWS	Homelab
Cost	Hackathon credits, with an end date	Electricity I already pay for
Uptime	AWS's problem	Mine, including power cuts
Scaling	Lambda scales out on its own	One laptop
Learning	The AWS console	Everything, end to end

For a demo with light traffic, the homelab wins. For a product with real users, it wouldn't.

What came next

Real projects depending on one laptop made me look at that laptop more critically. Two days later I asked for a full audit of the homelab, which turned into getting it ready to run for three months without me.

How an old gaming laptop became my homelab

2026-09-27T00:00:00Z

Windows is my everyday OS. But I wanted to actually learn Linux, not just use WSL, so I put Arch Linux on my old gaming laptop, a Lenovo Legion Y540. It didn't stay a learning machine for long.

The hardware

It's not what you'd buy as a server, but it's more than enough for one:

Part	Spec
CPU	9th-gen Intel Core i5
RAM	32 GB at 2666 MHz
GPU	GTX 1650, 4 GB VRAM
Storage	NVMe SSD for the system, plus a 1 TB HDD

The GPU turned out to matter later: it's enough to run small local language models, which is how ExamX started.

Phase 1: a Linux desktop to learn on

The first setup was a normal desktop: KDE Plasma, the multilib repository enabled (needed for 32-bit libraries), Steam, and Chrome from the AUR. Doing all of that on Arch, by hand, is a good crash course: package management, the AUR, systemd, and reading the wiki until things make sense.

Phase 2: reachable from anywhere

The step that changed what the machine was for:

OpenSSH, so I could work on it from my main laptop.
Tailscale, so I could reach it from anywhere without opening any ports on my home router.

Once I could SSH in from my Windows laptop on any network, the Legion didn't need a screen or a keyboard. It became a box I log into.

Phase 3: hosting things

From there it was a short step to serving websites. Instead of port forwarding, public traffic arrives through a Cloudflare Tunnel, and Caddy routes each domain to the right app running in Docker. My first site went live from it, and the plan is for it to host my hackathon demo sites, so they stay online for my CV long after the event credits run out.

The longer-term plan is a general-purpose server: hosting, VMs, storage and experiments.

What I didn't do (yet)

I set it up to work, not to be robust. No firewall, password SSH still allowed, no backups.

Update: a few weeks later ShipDoc moved onto it, and I asked for a proper audit. It found out exactly how much I'd skipped.

ShipDoc, part 1: a perfect score locally, 0.9869 on Lambda

2026-09-22T06:00:00Z

At the Averis × Monash Hackathon 2026 I was the registered team lead of Claude's Plan, a five-person team. Our entry is ShipDoc (shipdoc.org, docs at docs.shipdoc.org). My part was the cloud deployment, the Android build, the rename to ShipDoc and the documentation site. Most of the pipeline itself was written by my teammates.

What ShipDoc does

A shipping-documentation team works from a mixed inbox: requests for Shipping Instructions, invoice queries, automated notices, spam, and the emails that matter most. In those, a carrier sends a draft Bill of Lading (BL) that someone has to check, field by field, against the customer's Shipping Instruction (SI). A wrong port or container count that survives into the issued BL is expensive to fix.

ShipDoc reads that inbox and, for every email:

sorts it into one of five categories: BL comparison, SI request, invoice query, general or spam;
for BL checks, reads the SI and BL attachments (.txt, .pdf, .docx or .xlsx) and finds seven fields, whatever they're labelled (POD and Discharge Port are the same field);
compares them and names the exact fields that differ;
escalates instead of guessing when an attachment is missing, unreadable, the wrong document or has a blank value.

The rule the whole design follows is "AI reads, code decides." Rules handle classification and extraction first, and an AI model is only asked when they're unsure. The comparison itself is plain, unit-tested code, so a mismatch can always be re-derived from the two values on screen.

On the organisers' synthetic 520-email dataset, the rules alone scored 1.000 on their formula: 46 of 46 defective BLs caught with the exact wrong fields, no false alarms, and all 20 escalations with the right reason.

Getting it onto AWS

I'd never deployed anything on AWS. The setup we ended up with, all in ap-southeast-1:

Piece	Runs on
API (FastAPI)	Lambda, from a container image in ECR, wrapped by Mangum, with a public Function URL
Results	DynamoDB, pay per request
Website (React)	Amplify Hosting, rebuilt from GitHub on every push
Android app	The same React code wrapped by Capacitor, as an APK pointed at the Function URL
AI	Gemini on the live deployment; the same interface also supports Bedrock and the Claude API

The DynamoDB part exists because of how Lambda works. The local version kept results in memory or in a JSON file. Lambda runs several short-lived copies of the function side by side, so a result written by one copy is invisible to the next. The storage layer already sat behind an interface, so the cloud got its own DynamoDBStore.

Some first-timer lessons from the deploy, all of which went into the guide on the docs site:

Lambda's default timeout is 3 seconds. Ours runs at 2 minutes with 1024 MB.
Container images need --provenance=false when built with a recent Docker, or Lambda rejects them.
CORS configured in two places (the Function URL and the app) sends duplicate headers, and browsers reject that.
The AWS console quietly switches region between pages, which makes resources you just created look missing.

Why the cloud scored 0.9869

With everything deployed, we ran the full dataset against the live API and compared it with a local run. The scores came out as:

Where	Score
Local	1.000
Lambda	0.9869

Same code, same data. Comparing the two runs email by email showed exactly one PDF that read fine locally but failed on Lambda.

The cause was git, not AWS. Some of us develop on Windows, and git was set up to convert line endings between Windows (CRLF) and Linux (LF). It treated some PDFs as text and rewrote the line-ending bytes inside them. A PDF records the byte position of every object, so changing a few bytes is enough to corrupt it. The copy on the laptop was fine. The copy that went through git into the container wasn't.

The fix, in .gitattributes:

*.pdf  binary
*.docx binary
*.xlsx binary
*.png  binary
*.apk  binary

binary tells git never to touch those files. We also pinned the PDF library versions so Lambda and the laptops parse PDFs the same way, and made the reader retry a damaged file with its line endings restored. After that, Lambda scored 1.000 as well.

If the cloud and your laptop disagree, diff the results per item before suspecting the cloud.

Renaming, the APK and the docs site

The name came from the domain. We picked ShipDoc partly because shipdoc.org was available. I bought it through Cloudflare, pointed it at Amplify, and renamed the website and the Android app.
The APK was rebuilt against the live API. It also has a setting for changing the API address, so one build works against a laptop, a phone on the same network or the cloud.
The docs site is a VitePress site deployed with Cloudflare Workers Builds, separate from the app, so a broken docs build can't take the product down. It publishes from an allow-list of files: internal notes like the build plan, the frontend/backend handoff and the compliance review can never end up public by accident.

What I took away

Deploy early. The corrupted PDF was invisible until the code ran somewhere that wasn't a laptop.
Mark binary files as binary. One line of .gitattributes would have saved a lot of confusion.
Let code decide what code can decide. Keeping AI out of the comparison meant every result could be explained and reproduced.

The AWS account came with the hackathon and had an end date. Part 2 is about moving ShipDoc to my homelab before it expired.

Anxin: two AI models, and what to do when only one answers

2026-09-11T00:00:00Z

For the MUBA Blockchain Hackathon 2026 I led a team called Tenners. We looked at all three sponsor tracks before committing, and picked Gonka Router's AI for Society track. Our project, Anxin (安心), made the top 21 of that track. It's live at anxin-protect.com.

安心 (ān xīn) means "peace of mind".

The problem

Scams and misleading claims spread fastest through channels people already trust: forwarded messages, screenshots, family group chats. The people most exposed, especially older adults and people who aren't comfortable in English, are also the least likely to get a clear explanation of why something is a scam.

Anxin lets you paste a message or a link, or upload a screenshot, and returns a report in English and Simplified Chinese with:

a Truth Score from 0 to 100: how well the evidence supports the claim;
a separate fraud-risk level: how much the message looks like a scam;
a confidence figure that's honest about how much the models agreed;
the evidence used, with links and timestamps;
and, for every AI call, which model answered and a link to a public receipt from the Gonka network.

The Truth Score and fraud risk are deliberately separate. A phishing text ("your account is suspended, verify now") makes no checkable claim at all, but it's still dangerous.

What Gonka is

Gonka is a decentralised AI inference network: models run on machines across the network instead of one company's servers. Gonka Router is its OpenAI-style gateway. The track's rule was that every judgement at runtime must go through Gonka. Assistants like Claude could help us write the code, but they couldn't secretly do the product's thinking.

Two models, never shown each other's answer

Anxin sends the same claim and the same evidence to two different models, DeepSeek and MiniMax, at the same time, and neither sees the other's answer. Then plain, unit-tested code (not another AI) decides what the pair means, based on how far apart their scores are:

Gap between the two Truth Scores	What Anxin does
0–20 points	They broadly agree: the scores are averaged
21–40 points	Partial disagreement: confidence drops by 20
More than 40	Strong disagreement: confidence drops by 45 and the verdict becomes Insufficient evidence, not an averaged score

Averaging a 10 and a 90 into "50" would look precise and mean nothing. When two models strongly disagree, the honest answer is that we don't know.

Fraud risk works the other way: it's never averaged. Anxin takes the higher of the two, because a scam one model missed is still a scam.

Scam risk is checked first

The order of the rules matters. Anxin also has an evidence gate: if neither model found real evidence, the verdict is "insufficient evidence".

But a phishing SMS has, by its nature, no evidence on the web to check against. With the evidence gate first, the most dangerous messages we'd ever see would come back as merely "insufficient evidence". So the fraud check runs before everything else: if the message itself shows strong scam patterns (urgency, impersonation, payment requests), it's flagged High risk, whatever the evidence or the disagreement.

The hard part: refusing a silent substitute

This was the most interesting problem in the project.

Gonka confirmed during the event that DeepSeek was constantly saturated, and that the router's default failover sends the overflow to... MiniMax. That would quietly turn our "two independent opinions" into the same model asked twice, with the report still claiming cross-verification.

So every call sends X-Gonka-No-Fallback: true: give us the model we asked for, or fail. That means we deliberately accept real errors on the DeepSeek side, and the product has to handle them honestly. When only one model answers:

the verdict drops to insufficient, unless that one model raised a scam warning (we never mute a warning);
confidence is capped at 60;
the report shows a "Not cross-verified" badge and says in plain language that only one model answered.

A single opinion should never be dressed up as a consensus.

Receipts, not "trust us"

Every model call returns a request ID, and Gonka publishes a public receipt for each one: which model served it, when, and how many tokens it used. Anxin links to it directly, so anyone can check that a call really ran on Gonka, without going through our server.

We were careful about what that proves. The receipt comes from GonkaRouter's own database, so it's their attestation, not cryptographic proof, and it says nothing about whether the claim is true. The UI says exactly that: independently verifiable against GonkaRouter, not something we could fabricate on our own server.

Built to be checked

Over 100 backend tests, runnable with no API key thanks to a clearly labelled mock mode. A mock report shows a yellow banner, so it can't be mistaken for a real one in a demo.
Screenshot OCR runs locally with Tesseract, and only extracts text. It never makes a judgement.
The evidence fetcher is guarded against SSRF, so a pasted link can't be used to make our server request internal addresses.
A security script runs dependency and code scanners before every release: deterministic tools, not an AI's opinion.
No smart contract. Gonka's request IDs and receipts were the verification mechanism for this track, so we didn't deploy a contract just to fill a form field.

What I took away

Design for failure before accuracy. The most important code in Anxin decides what to show when the AI is unavailable, disagrees or is wrong.
Watch for silent substitutions. A fallback that keeps your app "working" can quietly break the guarantee your product is built on.
Say exactly what your proof proves. "Verifiable against GonkaRouter" is less exciting than "trustless", but it's true.

Top 21 wasn't a podium finish. But Anxin is still online, and it does something genuinely useful.

Planning errands is the travelling salesman problem in disguise

2026-09-04T00:00:00Z

For the Monash × Shortcut Asia Internship Challenge I built an Errand Route Planner: drop your stops on a map, and it tells you which order to visit them in so the whole trip is as short as possible.

It sounds like a small app. Underneath, it's one of the most famous hard problems in computer science.

The problem underneath

"Visit every stop once and come back home, as cheaply as possible" is the travelling salesman problem (TSP). It's NP-hard: no known algorithm solves every instance quickly, and the obvious approach (try every order) explodes.

With n stops after the starting point, there are n! orders to try:

Stops	Orders to try
5	120
10	3,628,800
15	about 1.3 trillion

Nobody runs 15 errands in one afternoon, but the table shows why "just try them all" stops being an option very quickly.

So the planner uses two strategies, and picks one based on how many stops there are.

Small trips: Held-Karp, the exact answer

Held-Karp is a dynamic-programming algorithm that finds the optimal route without trying every order. The key idea is that the best way to finish a route only depends on two things:

which stops you've already visited (a set, stored as a bitmask), and
where you are right now.

It doesn't matter what order you visited the earlier stops in. So instead of n! orders, there are only about 2ⁿ · n states to fill in:

best[visited][last] = shortest path that starts at home,
                      visits exactly the stops in `visited`,
                      and ends at `last`

best[{j}][j]        = dist(home, j)
best[S][j]          = min over k in S, k ≠ j, of
                      best[S − {j}][k] + dist(k, j)

answer              = min over j of best[all][j] + dist(j, home)

A simplified TypeScript version of the core loop:

function heldKarp(dist: number[][]): number {
  const n = dist.length - 1;             // stop 0 is home
  const FULL = 1 << n;
  const best = Array.from({ length: FULL }, () => new Array(n).fill(Infinity));

  for (let j = 0; j < n; j++) best[1 << j][j] = dist[0][j + 1];

  for (let mask = 1; mask < FULL; mask++) {
    for (let j = 0; j < n; j++) {
      if (!(mask & (1 << j)) || best[mask][j] === Infinity) continue;
      for (let k = 0; k < n; k++) {
        if (mask & (1 << k)) continue;   // already visited
        const next = mask | (1 << k);
        const cost = best[mask][j] + dist[j + 1][k + 1];
        if (cost < best[next][k]) best[next][k] = cost;
      }
    }
  }

  let answer = Infinity;
  for (let j = 0; j < n; j++) answer = Math.min(answer, best[FULL - 1][j] + dist[j + 1][0]);
  return answer;
}

The real version also remembers which stop each state came from, so it can walk backwards and recover the route itself, not just its length.

The cost is O(n² · 2ⁿ) time and O(n · 2ⁿ) memory. For a handful of stops that's instant. For 10 stops it's about 100,000 steps instead of 3.6 million orders. But 2ⁿ still grows fast, so past a certain size it's the wrong tool.

Big trips: nearest neighbour, then 2-opt

For larger trips the planner gives up on guaranteed optimal and aims for very good, very fast.

Step 1, nearest neighbour. Start at home and always go to the closest stop you haven't visited yet. It's O(n²) and gives a reasonable route, but it's greedy: it often paints itself into a corner and has to make one long, ugly trip back at the end.

Step 2, 2-opt. Take the greedy route and keep improving it. Pick two edges, A→B and C→D. If swapping them for A→C and B→D (and reversing the stretch in between) makes the route shorter, do it. Repeat until no swap helps.

before:  A → B → … → C → D      (the two edges cross)
after:   A → C → … → B → D      (the B…C stretch is reversed)

Geometrically, 2-opt uncrosses crossing paths. A route that crosses itself is never optimal, so removing every crossing gets you most of the way there. In practice, nearest neighbour plus 2-opt lands close to the true optimum.

The app around it

Vite + React + TypeScript for the front end.
Leaflet for the map: click to add stops, and the route is drawn as soon as it's solved.
17 passing tests. Route solvers are easy to get subtly wrong, and a wrong route still looks like a route on the map, so tests were the only way to trust them.

What I took away

Recognise the classic problem under the product. "Order my errands" turned out to be TSP, and knowing that meant I could use 60 years of research instead of inventing something.
Exact and heuristic can live together. Small inputs get a provably best answer; large ones get a fast, good answer. The user just sees a route.
An exact solver is also a test oracle. On small inputs, Held-Karp gives the true optimum, which is the yardstick for how good the 2-opt routes really are.

Hello, world (again)

2026-09-01T00:00:00Z

My portfolio shows the finished projects. This blog is for everything around them: the half-working prototypes, the hackathon weekends, the homelab rabbit holes, and the bits of CS that finally clicked.

What I'll post here

Project write-ups: how something was built, what went wrong, and what I'd do differently.
Hackathon recaps: the idea, the 3am pivots, and the result.
Homelab notes: configs, monitoring, and the occasional broken server.
Things I'm learning: algorithms, AI tooling, cloud, whatever I'm deep in that month.

A lot of my building now happens alongside AI coding tools, mostly Claude Code. When that's the case I'll say so, and I'll be honest about where the tool helped and where it got things wrong. Those posts are tagged claude-code.

Writing it down is the fastest way to find out whether I actually understand it.