Your browser can't show the 3D world (WebGL is unavailable), so here's the plain version. Nothing is missing.
Mathematics/Computer Science · UCLA '28
Campus · Education
B.S. Mathematics/Computer Science, expected June 2028. William F. Sharpe Fellow.
University of California, Los Angeles · B.S. Mathematics/Computer Science · expected June 2028
The Lab · Industry
Backend infrastructure for DNA sequencing pipelines.
Software Engineering Intern · June 2026 – Sep 2026 · Santa Clara, CA
I spent the summer on the backend behind Roche's DNA sequencing pipelines. A database cleanup the team did by hand every day was the clearest waste of engineering time, so I started there and turned it into a Spring Boot and Angular tool. Deployments came next. They relied on kubectl scripts, which I replaced with Helm charts run through GitHub Actions so that every cluster gets the same release the same way. Some scheduled jobs held database connections open for their whole run. Putting a Redis and RabbitMQ worker queue in front of the database fixed that: a job takes a connection, does its work, and releases it. I also packaged the frontend and backend into a single Podman pod, which left the team with one deployment to manage instead of two.
Stack: Spring Boot, Angular, Redis, RabbitMQ, Helm, GitHub Actions, Podman
The Lab · Industry
Healthcare data work with FHIR and VistA.
Software Engineering Intern · Sep 2025 – June 2026 · San Diego, CA
My work at VetsEZ sat between VistA and FHIR. Users had no programmatic way into VistA, so I built Spring and OData endpoints, secured with OAuth, to open it up. Once people relied on those endpoints, speed became the priority. I redesigned the PostgreSQL schemas and added a caching layer with Spring Data. On the operations side, manual releases were where things tended to break, which is why I automated Helm deployments to EKS through GitHub Actions. To keep services responsive under load, I added KEDA autoscaling and Prometheus monitoring, letting them scale up before requests started timing out.
Stack: Spring, Spring Data, OData, OAuth2, PostgreSQL, AWS EKS, Helm, KEDA, Prometheus
The Lab · Research
Bioinformatics tooling for protein-interaction research.
Software Engineering Intern · July 2025 – Sep 2025 · Philadelphia, PA
At Drexel I built software for a lab that studies how proteins interact. Exploring their own data meant writing SQL, which isn't what biologists should be spending their time on. I gave them a Next.js and PostgreSQL web app, hosted on a VPS, where they could browse it directly. Generating interaction graphs was slow. Because the data is a network, I moved it into Neo4j behind a FastAPI service instead of forcing it into tables, and graphs started coming back much faster. Part of the dataset couldn't be analyzed until it was cleaned up, so I turned it into Cytoscape-ready CSVs along with a Jupyter notebook the team could work from.
Stack: Next.js, PostgreSQL, FastAPI, Neo4j, Cytoscape, Jupyter
Grove · Project
Spectral graph analysis of protein-protein interaction networks.
ProteinLens looks for structure in protein-protein interaction networks. Proteins that work together tend to form clusters in these graphs, and spectral methods can find groupings that aren't visible from the raw edges. I pulled interaction data from STRING DB, built a graph Laplacian with EJML, and used its eigenvectors to embed each protein before clustering. A cluster is only useful if it means something biologically, so I checked the results against known findings. Analysis runs as jobs on Spring workers in EKS, fed by a Kafka topic keyed by job ID. That key spreads the load across partitions while keeping each job's messages in order.
Stack: Spring Boot, Kafka, Neo4j, EJML, Docker, Kubernetes, AWS
Grove · Project
Turns research and Wikipedia articles into DAG schemas with an LLM pipeline.
SchemaLoom reads a research paper or Wikipedia article and turns it into a DAG schema. Gemini, orchestrated through LangChain, does the extraction. Model output isn't guaranteed to be well-formed, so each schema has to pass Zod validation before it's accepted. Releases go out as Docker images built in GitHub Actions, which gives every environment an identical build. In CI, Jest tests exercise the API endpoints, catching failures before they ship.
Stack: TypeScript, Hono, Zod, LangChain, Gemini, Docker
Grove · Project
Automated Cytoscape data pipeline for network figures.
Turning Cytoscape networks into finished SVG figures was slow, manual work. CytoFlow automates it: py4cytoscape drives Cytoscape, and a FastAPI service wraps the whole process. Labeling mistakes in a figure are easy to miss by eye, which is why every commit has to pass Git hooks and a pytest suite that inspect the SVGs first. I packaged the service in Docker and validated incoming requests with Pydantic, so one server can handle several requests at once without bad input getting through.
Stack: FastAPI, Python, Java, py4cytoscape, Pydantic, Docker
Arcade · Systems
A CHIP-8 emulator written in Haskell, built around the State monad.
CHIP-8 has a small instruction set, which makes it a common first emulator. What made this one interesting was the language. An emulator is mostly state: registers, memory, a stack, a display buffer. Haskell, on the other hand, is pure, so no function can quietly change any of it. Each instruction became a function from one CPU value to the next. Clearing the screen, for example, takes a CPU and returns a new CPU with blank display memory. Threading that value through every opcode by hand gets noisy fast, so I wrote the instructions in the State monad. The code reads like step-by-step updates while staying pure underneath. ROMs run from the command line, with the CHIP-8 hex keypad mapped onto the left side of a standard keyboard.
Stack: Haskell, Cabal
Arcade · Systems
A disk-backed dynamic graph store in Zig, built for spectral analysis on consistent snapshots.
Spectral methods like the Fiedler vector need to see the whole graph at once, but a graph that keeps taking new edges never holds still. Spectrolith is my attempt to support both in one storage engine. The design follows LSMGraph: writes land in an LSM tree for throughput, and each level stores its edges in CSR format so that reads stay local. Every batch is appended to a checksummed write-ahead log before it becomes visible, which means an acknowledged write survives a crash. To prove that, a crash test forks a writer, kills it with SIGKILL at a random moment, and checks that every acknowledged batch came back whole. Readers work from point-in-time snapshots, so a long computation sees one fixed version of the graph while writes carry on. The log, write batches, the in-memory graph, snapshots, and flushing to immutable on-disk segments are done. Compaction, the spectral engine, and benchmarks against RocksDB are next.
Stack: Zig, POSIX
Lighthouse · Writing and contact
Essays mainly about geopolitics.
Essays mainly about geopolitics, on Substack.