Full-Stack Web Development

StudyMate

An AI-powered study notes app with secure per-user accounts, built and deployed end-to-end as a solo full-stack project.

1. Introduction

1.1 Overview

StudyMate is a full-stack MERN application built to give students a single place to capture study notes, get AI-generated help understanding them, and test themselves - without needing separate apps for notes, summarization, and quiz practice. It moves the typical "write notes, then separately quiz yourself" workflow into one authenticated, AI-assisted tool, and is deployed live rather than only running locally.

1.2 Purpose

The app provides a private, per-account space to create, edit, and search notes by subject, then layer AI on top: a one-click summary distills a note into three key points plus a comprehension question, and a separate Quiz Mode generates a full multiple-choice quiz from the note content, complete with instant right/wrong feedback. A custom MCP (Model Context Protocol) server also exposes the notes data as tools, so an AI assistant can list or create notes directly.

1.3 Problem Statement

The project addresses a few recurring pain points in how students actually study:

• Passive re-reading - Notes are often written once and re-read passively, which is a weak retention strategy. StudyMate turns any note into an active recall exercise via AI-generated quiz questions.
• Fragmented tooling - Notes, summarization, and self-testing usually live in separate apps. StudyMate keeps all three in one authenticated dashboard.
• Data privacy in shared/demo apps - An early version of the app stored all notes in one global collection with no ownership check, meaning any user of a public demo link could see or delete anyone else's notes. This was identified and fixed by adding full JWT-based authentication, scoping every note to its owner at the database query level.

1.4 Target Users

• Students - need a fast way to capture lecture/reading notes and turn them into revision material without manual summarizing.
• Self-learners - anyone studying independently who wants auto-generated quizzes to check their own understanding.
• Developers/AI assistants - via the MCP server, an AI client such as Claude can list or create notes directly through defined tools rather than a UI.

2. Project Requirements

2.1 Functional Requirements

• User Lifecycle - Register/login with hashed passwords (bcrypt) and JWT-based session tokens; every note request is authenticated and scoped to the logged-in user.
• Note Management - Create, edit, delete, and search notes by title or subject, with controlled forms and live client-side filtering.
• AI Summarization - One-click endpoint sends note content to Google Gemini and returns a 3-bullet summary plus a single comprehension question, persisted on the note.
• AI Quiz Generation - Separate endpoint generates 3 multiple-choice questions (4 options each, correct answer tracked) from a note, rendered as an interactive quiz with instant feedback.
• MCP Integration - A standalone Node MCP server exposes list_notes and create_note tools over stdio, authenticating with a stored account so tool calls only ever touch that account's own notes.

2.2 Non-Functional Requirements

• Security - Passwords are never stored in plaintext; every note route validates a signed JWT and filters by userId at the database layer, not just in the UI.
• Validation - Empty title/content is rejected server-side with a 400 and a clear JSON error message, not just client-side checks.
• Availability - Deployed live (not local-only) across three independent free-tier platforms, so the demo is reachable by anyone at any time.
• Adaptability - Dark mode toggle available across both the marketing landing page and the authenticated dashboard, persisted via localStorage.

3. System Design

3.1 Architecture

StudyMate follows a clear separation between four independently deployable pieces:

• Landing page - static HTML/CSS/vanilla JS marketing page, no framework.
• Client - React (Vite) single-page app: auth screen, note dashboard, search, AI summary/quiz UI.
• Server - Express REST API with Mongoose models for User and Note, a JWT auth middleware gating every note route, and REST calls out to Google Gemini for AI features.
• MCP server - separate Node process, authenticates against the same API as a real user, and exposes note-management tools over the Model Context Protocol.

3.2 Workflow

Authentication

• AuthForm - single component toggling between Login and Sign Up.
• /api/auth/register / /api/auth/login - hash/verify password with bcrypt, issue a 30-day JWT on success.
• Session persistence - token and user info stored in localStorage; every subsequent API call attaches Authorization: Bearer <token>.

Note Management

• Dashboard - fetches only the logged-in user's notes on load, with loading and empty states.
• NoteForm - controlled add/edit form with client-side validation mirrored by server-side 400 checks.
• Search - client-side filter across title and subject as the user types.

AI Features

• Summarize - sends note content to Gemini with a strict JSON-only prompt, parses the response into bullets + a quiz question, and saves it on the note document so it survives a refresh.
• Quiz Mode - separate prompt asks for exactly 3 MCQs with 4 options and a correct index; the client renders them as clickable options that turn green/red on selection.

MCP Server

• Login on demand - caches a JWT after logging in with credentials from its own .env, so every tool call is properly authenticated.
• list_notes / create_note - call the same REST endpoints as the React client, proving the API is a single source of truth regardless of which client uses it.
• Verified with MCP Inspector - both tools tested end-to-end (login → API → MongoDB → response) with screenshots as proof.

3.3 UI Design

Purple-accented, card-based UI across a static landing page and the authenticated dashboard, with a consistent dark mode toggle on both. AI-generated content (summary bullets, quiz questions) is visually distinguished with its own soft-tinted panel inside each note card.

3.4 Data Model

Two primary collections:

Every note document carries a user reference, and every query in routes/notes.js filters by { user: req.userId } - the fix that closed the original data-privacy gap.

4. Technologies Used

• React + Vite - fast dev server and build for the client dashboard.
• Express + Mongoose - REST API and schema-based MongoDB access.
• JWT + bcrypt - stateless authentication and one-way password hashing.
• Google Gemini API (gemini-3.1-flash-lite) - called directly via fetch, no SDK dependency, to generate summaries and quizzes from raw note text.
• MCP SDK - implements a standard stdio-based tool server, tested independently with MCP Inspector.
• Vercel / Railway / MongoDB Atlas - free-tier hosting split across frontend, backend, and database respectively.

5. Implementation Highlights

5.1 Key Modules

• middleware/auth.js - verifies the JWT on every note request and attaches req.userId, rejecting unauthenticated calls with 401.
• routes/notes.js - every CRUD and AI route is scoped with { user: req.userId }, so cross-account access is impossible even if a note ID is guessed.
• mcp-server/index.js - logs in once, caches the token, and reuses it across list_notes and create_note calls.

5.2 Technical Highlights

• Strict JSON prompting - both AI endpoints instruct Gemini to return only JSON (no markdown fences), parsed defensively with a fallback 502 if the model ever returns malformed output.
• Optimistic UI + rollback - deleting a note removes it from the UI immediately, and rolls back if the API call fails, keeping the interface responsive.
• Cross-platform deployment - frontend, backend, and database each live on a separate provider, connected purely through environment variables and public URLs, rather than a single monolithic host.

6. Testing & Results

• Auth testing - verified duplicate email rejection, wrong-password rejection, and correct token issuance on both register and login.
• Data isolation testing - confirmed via two separate test accounts that notes created under one account never appear for another.
• AI endpoint testing - verified summary and quiz generation return well-formed JSON and persist correctly across page refreshes.
• MCP testing - verified both list_notes and create_note via MCP Inspector, confirming tool calls authenticate and only touch the logged-in account's data.

7. Conclusion

StudyMate evolved well beyond its original scope - starting as a CRUD notes app with AI summarization, it grew into a properly authenticated, privacy-conscious, fully deployed product with a working MCP integration. The project reflects practical full-stack experience: designing a REST API, securing it with JWT, integrating a third-party AI service, building a protocol-level tool server, and coordinating a multi-provider production deployment - not just building a working demo, but hardening it once a real gap (global note visibility) was identified.

Data Engineering / DevOps

DataOps CI/CD Project

1. Introduction

1.1 Overview

DataOps CI/CD Project is a Python-based data engineering solution built to demonstrate how modern DevOps practices can be applied to data pipeline workflows. It moves a simple ETL process from an ad-hoc script into a structured, automated, and reproducible pipeline.

1.2 Purpose

The project provides an end-to-end workflow that extracts raw customer data, cleans it, and loads a validated output - with every stage automatically tested and rebuilt on each code change. It shows how DataOps brings software engineering discipline (testing, automation, version control) into workflows that are traditionally run manually.

2. Project Requirements

2.1 Functional Requirements

• Extract - Read raw customer data from a structured CSV source.
• Transform - Clean the dataset by removing rows with missing or null values.
• Load - Output a validated, cleaned dataset to a processed data directory.
• Automated Testing - Verify the processed dataset contains no missing values before it's considered valid.
• Automated Pipeline Execution - Run the full ETL and test suite automatically on every push via CI/CD.

2.2 Non-Functional Requirements

• Reproducibility - The pipeline produces identical output given identical input, regardless of the machine it runs on.
• Portability - Packaged with Docker so the environment stays consistent across local, CI, and any future deployment target.
• Maintainability - Simple, modular structure (src/, tests/, terraform/) so components can be updated independently.

3. System Design

3.1 Architecture

A linear ETL pipeline architecture: the extract layer (src/etl.py) reads raw input from data/raw/customers.csv; the transform layer removes incomplete records; the load layer writes cleaned output to data/processed/cleaned_customer.csv; the validation layer (tests/test_etl.py) confirms data quality on the output.

3.2 Workflow

• Pipeline is developed and tested locally in a Python virtual environment.
• Code changes are committed and pushed to GitHub.
• GitHub Actions automatically checks out the repo, sets up Python, and installs dependencies.
• The ETL script runs, generating the processed dataset.
• Pytest validates the output for data quality before the change is considered safe to merge.
• The same pipeline can be built and run inside a Docker container for environment-independent execution.

4. Technologies Used

• Python - Core language for the ETL pipeline logic.
• Pandas - Data cleaning and transformation.
• Pytest - Automated data quality testing.
• GitHub Actions - CI/CD automation; runs the pipeline and test suite on every push.
• Docker - Containerizes the pipeline for consistent execution across environments.
• Terraform - Basic Infrastructure as Code example for provisioning supporting resources declaratively.

5. Implementation Highlights

• Automated CI/CD pipeline - every push runs the full ETL job and test suite, catching issues before merge.
• Containerized execution - docker build and docker run reproduce the same pipeline behavior regardless of host machine.
• Data quality gate - the pipeline is only considered successful if the output dataset passes the null-value validation test.
• Infrastructure as Code - a Terraform configuration demonstrates declarative provisioning of supporting resources.

6. Conclusion

DataOps CI/CD Project reinforces core DataOps principles: pipelines should be simple, testable, and repeatable, with issues caught early through automation rather than discovered downstream. By combining ETL logic with automated testing, containerization, and CI/CD, the project shows how standard DevOps practices translate directly into more reliable data engineering workflows.

Mobile Application Development

LankaSmartMart

A native Android supermarket app engineered for Sri Lanka's digital retail transformation.

1. Introduction

1.1 Overview

LankaSmartMart is a native Android solution built to digitally transform a prominent Sri Lankan supermarket chain with branches in Colombo Fort, Maharagama, Gampaha, and Kandy. Developed in Java with the Android SDK, it shifts operations from legacy phone-order workflows to a sophisticated mobile-first marketplace that maintains performance across both urban and regional districts.

1.2 Purpose

The app provides a seamless 24/7 digital storefront covering Groceries, Household goods, Stationeries, and Personal Care products. A persistent shopping cart and structured multi-step checkout streamline the journey from product discovery to order confirmation, supporting both Card and Cash on Delivery (CoD) payments.

1.3 Problem Statement

The app was designed to address key retail pain-points in Sri Lanka:

• Accessibility Barriers — Physical transit to supermarkets is constrained by time poverty and inconsistent transport for suburban residents.
• Information Asymmetry — Customers lacked a centralised mechanism to verify real-time stock availability, leading to inefficient trips.
• Connectivity Volatility — Cloud-dependent apps fail in rural/low-bandwidth areas. LankaSmartMart uses an offline-first SQLite architecture to keep core features functional without active network status.

1.4 Target Users

• Consumers — Busy professionals, university students, and families requiring efficient procurement.
• Elderly Users — Targeted via a high-contrast, simplified UI.
• Administrators — Store managers requiring real-time CRUD access to inventory.

2. Project Requirements

2.1 Functional Requirements

• User Lifecycle — Multi-role authentication (Admin/Customer) with persistent session management.
• Intelligent Discovery — Keyword-based search using SQL LIKE pattern matching across product names and categories.
• Order Management — Persistent cart with real-time price synchronisation and multi-payment support.
• Logistics Module — Dynamic nearest-branch calculation using geographic coordinates.
• Documentation Engine — Automated digital receipt generation in PDF format.

2.2 Non-Functional Requirements

• Performance — Database response latency kept below 50ms for local queries.
• Adaptability — Semantic UI for seamless Light/Dark mode transitions.
• Persistence — ACID-compliant data management via SQLite.

3. System Design

3.1 Architecture (MVC Pattern)

• Model — POJO layer (Product, CartItem, Order) handles data encapsulation.
• View — XML-based Material Design 3 components ensure high-density responsiveness.
• Controller — Activities and Custom Adapters bridge SQLite logic with the UI.

3.2 Workflow

Launch & Authentication

• SplashActivity — Branded splash screen performs a background SessionManager check.
• LoginActivity / SignupActivity — New users register details into SQLite; the system distinguishes Customer and Admin roles.
• Session Management — Credentials are encrypted and saved locally to avoid repeated logins.

Product Discovery

• HomeActivity — Featured offers and four main categories: Groceries, Household, Personal Care, Stationeries.
• Global Search — SQL LIKE query fetches matching items across all categories.
• ProductsActivity — Dynamic grid view of products rendered from the local database.
• ProductDetailsActivity — Detailed metadata, price, and real-time stock availability.

Shopping & Transactional Flow

• CartActivity — Persistent cart with increment/decrement controls; subtotal and delivery fees update in real time.
• CheckoutActivity — Confirms delivery address and payment method (Card or CoD).
• DeliveryAddressActivity — Uses osmdroid to show user location and calculates the nearest branch.
• Order Completion — Items saved to orders table, cart cleared, unique Order ID generated.

3.3 UI Design

Clean green-and-white Material Design 3 theme covering the full user journey: Splash, Login/Signup, Home, Product Details, Cart, Payment, Receipt, Profile, and Order History. Includes a dark mode toggle throughout.

3.4 Database Schema

Five primary entities:

4. Technologies Used

• Java (JDK 17) — Strong typing, extensive documentation, and excellent memory management for complex DB transactions and multi-threaded image processing.
• Android Studio Ladybug (2024.2.1) — Layout Inspector, Logcat & Profiler (60fps monitoring), Device File Explorer.
• SQLite (SQLiteOpenHelper) — ACID-compliant, server-less local database; app functions fully offline.
• Material Design 3 — MaterialCardView, BottomNavigationView, SwitchCompat following Google's latest accessibility standards.
• osmdroid (OpenStreetMap) — Open-source map library for delivery location visualisation and branch distance calculation.
• Glide (v4.16.0) — Asynchronous image loading and caching; prevents UI stutter when scrolling large product lists.
• Android PdfDocument API — Programmatically renders receipt UI into downloadable PDF format.
• FusedLocationProviderClient — High-accuracy GPS coordinates for nearest-branch calculation.
• Gradle (Kotlin DSL) — Automated dependency management and consistent builds.

5. Implementation

5.1 Key Modules

• DatabaseHelper.java — Transactional logic for placing orders and keyword search.
• ReceiptActivity.java — Converts visual UI layouts into PDF documents saved to scoped storage.
• DeliveryAddressActivity.java — Haversine formula logic to determine closest branch from geocoded address.

5.2 Technical Highlights

Map Color Coding

• Green — Closest branch to the user.
• Red — Delivery destination (user's address).
• Gray — All other branch locations.

Order Process (3-Step Chain)

1. User clicks Place Order.
2. App saves order to history (SQLite orders table).
3. App generates a downloadable PDF receipt automatically.

Additional Features

• My Orders — Digital filing cabinet storing all past orders for review or repeat purchase.
• Profile Picture — Users can select a photo from the device Gallery to personalise their account.

6. Testing & Results

• Unit Testing — Verified nearest-branch algorithm correctness.
• Integration Testing — Validated the Place Order → Save to History → Generate PDF workflow.
• UI/UX Testing — Verified Dark Mode readability across all 15 screens.

7. Conclusion

LankaSmartMart embodies a new paradigm in professional-grade retail solutions, effectively integrating an offline-first approach with automated PDF generation and dynamic interface scaling. By balancing architectural integrity with modern UI standards, the project showcases a robust, scalable, and production-ready Android application built for real-world resilience.