Coursework and Capstone

A menu-driven cryptography suite. It carries several classic ciphers written from scratch, plus one cipher the team designed itself, all built on a small reusable console menu framework. The framework (Menu and Choice) links each menu item to a label, a key, and a function. That keeps the interface separate from the algorithms, so a new cipher can be added without changing the menu code.

• Caesar cipher: a letter shift by a number you choose, with encrypt, decrypt, and info options.
• Vigenère cipher: a keyword cipher that also prints the full Vigenère reference table.
• XOR cipher: a repeating-key XOR shown as hex, with the hex parsed back to bytes on decrypt.
• Meguprazan cipher: the group's own cipher, with matching encrypt and decrypt routines.
• Reusable menu engine: colored titles, descriptions, and hotkeys drive the whole app.

Two related pieces of cryptography coursework: a hand-written classic-cipher tool, and a benchmark that compares modern ciphers. The first part (Lab1.py) is a menu-driven Caesar and polyalphabetic cipher written from scratch. It works across the full printable ASCII range (codepoints 32 to 126, mod 95) and checks the input, handles negative shifts, and validates message length. The second part (FishTacos) moves to library-grade ciphers and measures how fast they run.

• Ciphers from scratch: Caesar and polyalphabetic encryption across all printable ASCII, not only A to Z.
• Salsa20 against Blowfish: a stream cipher next to a block cipher (CBC, with manual PKCS-style padding) using PyCryptodome, timed with perf_counter().
• Test harnesses: several test files, including an interactive one, plus sample data.
• Input validation: checks on shift range and message length before it runs.

A desktop 2D shooter built to practice object-oriented game design. It uses one class per game idea, with real-time collision and spawning, power-ups, a boss enemy, and saved high scores. Character and Environment act as shared base classes, and Player, Enemy (with a Boss version), Bullet, PowerUps, and Obstacles build on them.

• Real-time gameplay: movement, shooting, collision detection, and enemy spawning on a game loop.
• Power-ups: Health, Speed, and Attack pickups that change the player during a run.
• Boss encounter: a separate boss enemy set up apart from the normal waves.
• Saved progress: game state written to gameSave.txt and high scores added to highScores.txt.
• Screen flow: a main window, game window, end screen, and high-score screen.

A relational schema design for a resort management system. This is a design deliverable (Statements.txt) rather than a running app. It shows normalized modelling with primary keys, check constraints, and foreign-key relationships.

• Departments: the role is the primary key, with a CHECK constraint that limits roles to Accountant, Maintenance, or Reception, plus salary range and qualifications.
• Manager and Employees: a "managed by" relationship modelled with foreign keys.
• Constraints first: keys, checks, and relationships written directly in the CREATE TABLE code.

This is a database design project with no application GUI. The screenshots below stand in for the schema code and its entity-relationship diagram.

A database-backed web app for storing personal documents, with expiry dates, user login, and full create, read, update, and delete, including the files themselves. Users log in against a users table with password_verify() and bcrypt-hashed passwords. Documents, and the file data, live in a docusafe table as BLOBs. The project grew from an earlier records-only lab into the finished app.

• Secure login: bcrypt-hashed passwords and prepared statements throughout.
• File storage: uploads saved as BLOBs and streamed back when requested.
• Expiry tracking: each document has an expiry date alongside its type and timestamps.
• Full CRUD and search: add, edit, delete, and search documents per user.

A group final that builds a full car-rental site: public marketing pages, customer accounts, a car fleet you can browse and book, and an admin back office. It uses classic Web Forms, where each screen is an .aspx page with an .aspx.cs code-behind, grouped by area. Data is stored in a Microsoft Access database.

• Separate areas by role: Auth (sign-up, login, profile), Fleet, User, Admin, and the public Home area.
• Browse and book: view the fleet, open a car's details, and schedule a rental.
• Customer bookings: a view of the customer's own reservations.
• Admin office: manage every reservation and user account.
• Access database: GearShiftAutoRentals.accdb, with JSON handled by Newtonsoft.Json.

A native Android app for creating college (CCIS) events and recording attendance. It was the final project for Database Fundamentals, built by a team with a real pull-request workflow and full git history. The Android UI has one Activity per screen. All data access goes through a single DatabaseHander class that calls PHP scripts over HTTP, backed by an Oracle database through OCI8.

• Event lifecycle: create, edit, and manage events from their own screens.
• Attendance: record who attended an event, read back through an Oracle view.
• Native app with an enterprise database: Xamarin.Android talking to Oracle through a PHP layer.
• Team workflow: merged pull requests with a public history.

A native Android inventory app with user accounts, backed by a custom PHP REST API over MySQL. The code keeps the UI and the data cleanly apart: each feature pairs an Activity (the screen) with a Handler (the API call). Inventory is scoped to each user, and item types come from a bundled catalog.

• Accounts: register and log in against the REST API.
• Full CRUD: add, update, and delete items, plus search and sort.
• Activity and Handler design: screens kept separate from the code that calls the API.
• Per-user data: an itemsTable scoped by owner, with types from an XML catalog (Clothing, Food, Technology, Other).

A prepaid RFID parking-card system with built-in environmental monitoring, and the most recent stack in this set. An RFID-equipped Wemos (ESP8266) reads parking cards, logs each vehicle's entry and exit, and reports temperature and humidity from a DHT sensor. A Next.js dashboard manages the cards, balances, and parking logs, and can switch an LED and a relay on and off from anywhere. The project has three tiers: PHP endpoints that the microcontroller calls, PHP endpoints for a mobile client, and the Next.js website backed by Supabase.

• Prepaid cards: issue an RFID card with a random ID and a starting balance, then top it up.
• Entry and exit billing: parking logs with automatic timestamps and a calculated total.
• Live sensor data: the device sends DHT temperature and humidity readings to the backend.
• Remote control: switch an LED and a relay on or off from the dashboard.
• Management UI: an App Router dashboard with card and log tables (shadcn/ui and TanStack Table) that talks to Supabase directly.