UNDER THE HOOD
There’s a bit more
behind the buttons.
A small static site with a few moving parts. Here’s how they stay out of each other’s way.
Plain files. Separate responsibilities.
HTML, CSS and JavaScript, served by GitHub Pages. The public site has no account requirement or application server. The home worlds, project deck and sectional scroll each keep their own state.
- InterfaceSemantic HTML, CSS themes and keyboard controls
- InteractionSection scroll, project deck and contextual guide
- Separate gameLoads on its own route; not with the homepage
Why separate the scroll and the deck?
A section change and a project change can happen close together. Explicit transition states let them settle before the next action, and keep the URL, visible card and keyboard focus in agreement.
The tradeoff is more coordination code than a plain scrolling page. Reduced motion and direct links still need a straightforward path through the same content.
Why keep the public site static?
The work and contact details should open without a login or a backend dependency. Deeper case studies and the game load when you visit them; the first page does not need the whole portfolio’s runtime.
How does the guide answer questions?
It selects from authored questions, answers and links. There’s no chat model reading messages or guessing about my experience. The character points to the work; the project pages carry the detail.
What happens with analytics?
Selected analytics events are on by default, with controls on the privacy page. GPC and DNT suppress collection. Withdrawal stops future capture. There is no session recording, broad autocapture or identity enrichment. The site remains usable when analytics is blocked.
Read the privacy noticeTHE SIDE QUEST BECAME A SYSTEM
One simulation. More than one way to play.
Dev Run separates its fixed-step simulation from Canvas rendering and HTML controls. Course and physics logic can run without the browser. Character poses follow movement state; the untimed Route planner keeps the journey available without timing pressure.
A picture with a hitbox
Hazards share transforms with collision checks. An animated obstacle should not leave its collision shape behind.
Interruptions count
Pause, lost focus and canceled touches release held inputs. Fullscreen is a requested enhancement, with an immersive fallback.
Tests and eyes
Deterministic route tests check rules. Browser runs and pose sheets catch the seams and clipped feet those tests cannot see.
TOOLS, WITH THEIR CONTEXT ATTACHED
Different work. Different tools.
Frontend
React · JavaScript · HTML/CSS
Professional/freelance web work, GDSC team application and this personal site.
Backend
Node.js · Express · JWT
GDSC team application; login and superuser-access contributions.
Data & integration
Python · SQL · APIs · Azure Functions · Oracle Cloud
Vigilant integration and troubleshooting, within the Business Analyst role. MongoDB belongs to the GDSC team stack.
AI evaluation
Controlled model comparisons · structured-output validation
TrustAI product and evaluation work. Python/FastAPI, React and PostgreSQL are the team architecture; not a claim of sole implementation.
Spatial
ArcGIS · ArcMap · QGIS · Google Earth
GIS background across site analysis, mapping and support. Exact tools differ by project; these are not credential claims.
Tools & foundations
Git · issue tracking · documentation · ML foundations
Project delivery; MS studies included logistic regression, tree models and clustering. Study is distinct from production model training.
GDSC: team application source TrustAI: evaluation and limits
R&D · EARLIER PROTOTYPES
Can a login earn its place?
I explored Google sign-in, server-controlled member and owner access, and passkey verification for sensitive owner actions using Better Auth, Workers and D1. These early staging experiments informed the account experience now available on the site.
The security question
A button marked “owner” is not a permission check. The server derives identity from the session and verifies the role before returning protected resources. Tests cover anonymous access, role tampering, other-member isolation and expired or revoked sessions. Sensitive owner actions also require recent passkey verification.
The product question
A visitor should not need an account to see the work. A prototype saves game milestones, project bookmarks and a small experiment across sessions. That demonstrates continuity, but it does not prove people want another login.
The tradeoff that paused it
Authentication has CPU, recovery and maintenance costs even at low traffic. I kept the implementation isolated while deciding whether the member experience is useful enough to launch. A working sign-in is only part of that decision.
The experiments below are historical research. Optional accounts are now live; public work and contact routes remain open, while the full résumé uses sign-in or authorized recruiter access.
Want to talk through a decision?
R&D NOTE · OCTOBER 2026
Move identity out of the small runtime.
The earlier Better Auth experiment is preserved. The next isolated candidate uses Firebase for Google identity, a small Worker for server-side authorization, D1 for sessions and roles, and Firestore for bounded member preferences.
Identity
Validate the signed token, its issuer, audience and expiry. A displayed email address is not an owner permission.
Authorization
The server checks the session and stored role. Sensitive owner actions also need recent passkey verification.
Lifecycle
Revocation, disabled users and deletion have to close access. Cleanup is a real scheduled operation, not just a successful button click.
This note describes staging research. It does not promise public account availability or unlimited free hosting. The public work, professional overview and contact routes remain open.
What would make a member account useful?
Keeping a small trail of saved projects and preferences across visits. Public qualifications should remain visible either way. An account is optional continuity, not the admission ticket to the portfolio.