Ray Li

Problem

Given a rider's start station, time of day, rider type, and bike type, can we predict which of 50 possible destination stations they will choose? Human mobility is inherently stochastic, so a probabilistic model that outputs a distribution over destinations is more useful than a single point prediction. This has practical value for bike redistribution, demand forecasting, and strategic planning.

Data & Features

• Processed 5,287,447 rides from CitiBike September 2025 system data, filtering to trips between the top 50 most frequent stations
• Engineered features including one-hot encoded start station and time variables, binary indicators for rush hours and weekends, and quadratic proximity features capturing smooth commute-time preferences
• Pareto analysis confirmed a relatively balanced distribution (1.8:1 imbalance ratio), meaning the model could not succeed by simply predicting the most popular station

Modeling Approach

• Baseline: Multiclass Bayesian logistic regression with a Multivariate Normal prior on weight vectors and a Categorical likelihood, estimated via MAP using PyMC's L-BFGS optimizer
• Upgrade: Station-specific weight matrices that allow each origin to learn its own destination preferences independently, with a dynamic mapping system to handle unreachable stations
• Tuned prior precision via 3-fold cross-validation with grid search over {10, 100, 1000}
• Evaluated using both classification accuracy and a probabilistic expected Euclidean distance metric that penalizes geographically distant errors

Results

• Both methods vastly outperformed random chance (2.04% accuracy) and a most-frequent-station baseline (3.16%)
• Baseline achieved 11.36% accuracy; the upgrade method improved to 11.90%
• The upgrade method reduced expected Euclidean distance error to 0.0180 (vs. baseline 0.0222), meaning predictions were geographically closer to true destinations for nearly every station
• Per-station analysis showed the upgrade method improved distance error on all but one of the 50 stations

Reflection

The project demonstrated that station-specific probabilistic models can capture commuter behavior patterns that a single global model misses. A key limitation is generalizability: the model was trained and tested on September data only, and seasonal variation could shift rider patterns. Future work could explore hierarchical priors to share information across stations or incorporate weather and event data.

Problem

Design and build a full-stack puzzle platform where users can create accounts, browse puzzles, track their progress and scores, and interact through comments. The application needed to support multiple user roles, persistent game state, and secure authentication from day one.

Architecture

• Designed a relational schema with five core tables (users, puzzles, user_puzzle, comments, puzzle_creation) using foreign key constraints and composite primary keys for join tables
• Built a React frontend with client-side routing (react-router-dom), modular component architecture (Nav, Login/Signup modals, page components), and responsive CSS with mobile breakpoints
• Implemented a Node.js backend with bcrypt authentication, session management, CORS configuration, and connection pooling to MariaDB

My Role

• Led backend architecture decisions within an Agile team, including schema design, API structure, and authentication flow
• Implemented password hashing with bcrypt and cryptographic salt generation for secure credential storage
• Built the signup and login flows end-to-end: form validation on the client, POST routes on the server, session serialization/deserialization, and error handling for duplicate usernames
• Added unit tests for core logic and API behavior and used Docker environments to validate changes before deployment

Takeaways

This project reinforced the value of schema-first thinking. Defining the database structure before writing application code made the API design much cleaner and reduced rework. Working in a team also sharpened skills in code review, branching strategy, and communicating architectural decisions to teammates with different technical backgrounds.

Problem

Design and implement a messaging system where messages are protected end-to-end, authentication is cryptographically sound, and the system's threat model is transparent and well-documented.

Approach

• Engineered an end-to-end encrypted workflow using RSA-2048 for key exchange and message protection
• Implemented a challenge-response login flow with cryptographic signatures and JWT sessions
• Performed secure debugging of authentication and authorization paths
• Deployed an HTTPS backend using a self-managed certificate authority and documented threat assumptions and security tradeoffs

Outcome

Delivered a working encrypted messaging system with documented threat assumptions and security tradeoffs. The project sharpened skills in applied cryptography, secure session management, and the discipline of making security reasoning explicit for others to review.

Problem

Implement the Raft consensus algorithm to enable a cluster of servers to maintain a consistent, replicated state machine even when individual nodes fail. This is a core challenge in distributed systems: achieving agreement among unreliable participants.

Approach

• Implemented leader election with randomized election timeouts to prevent split-vote scenarios
• Built log replication logic ensuring committed entries are durably replicated across a majority of nodes before acknowledging
• Handled edge cases including network partitions, leader crashes, and log inconsistencies using Go's concurrency primitives (goroutines, channels, mutexes)
• Wrote test suites to verify correctness under simulated failures and concurrent operations

Outcome

Delivered a working Raft implementation that correctly handles leader election, log replication, and fault recovery. The project deepened my understanding of consensus protocols, Go concurrency patterns, and the practical tradeoffs in designing reliable distributed systems.