I build websites that feel as thoughtful as they work.

01 / Problem

Student performance data is often scattered across spreadsheets, paper grade books, and disconnected tools. Calculating averages, identifying top and bottom performers, sorting by grade, and classifying overall class performance manually is repetitive and error-prone — especially as the number of students grows.

02 / Objective

Build a Java utility capable of organizing and analyzing student performance data through a clean object-oriented design. The application should let a user add, search, and remove student records, then compute statistics (average, min, max) and classify both individual and overall class performance.

03 / Approach

The project is split into focused classes. Student models a single record with encapsulated fields. StudentManager handles the in-memory collection using an ArrayList, offering add, remove, and search operations. PerformanceAnalyzer performs statistical computations and classification. Main drives the entry point, handles input, and prints the report.

04 / Algorithms & Logic

• →Average calculation — sum of grades divided by count, iterated with a for-each loop over the collection.
• →Min / max detection — linear scan tracking the current extreme value.
• →Sorting — Collections.sort with a Comparator to order by grade or name.
• →Searching — linear search by student name or course.
• →Performance classification — grade ranges mapped to descriptive labels (Excellent, Very Good, Good, Satisfactory, Needs Improvement).
• →Data validation — ensuring names are non-empty and grades fall within 0–100 before records are accepted.

05 / Challenges

This section will be updated as the implementation progresses. Notes on encountered obstacles, design decisions, and refactors will be documented here.

06 / Results

Final results, screenshots, sample outputs, and lessons learned will be added once the project is complete.

01 / Problem

Credentials are usually scattered across notes, spreadsheets, browser exports, and memory. Organising them inside a single desktop application raises real software-engineering questions: how should records be modelled, where should validation live, how does the interface talk to the data layer, and what happens when the application restarts? SecureVault exists to work through those questions deliberately.

02 / Objective

The objective is to develop a Java desktop application that demonstrates the core mechanics of a credential manager with a clean, explainable architecture.

• →Object-oriented programming with clear separation of responsibilities.
• →Application architecture structured in distinct layers.
• →Authentication flow with a master password gate.
• →Credential data management — add, search, edit, remove.
• →Input validation applied consistently before data is accepted.
• →JavaFX UI development using FXML-defined views.
• →Local persistence so the vault survives an application restart.

03 / Architecture

The application separates responsibilities into five layers. Each layer only knows about the one directly beneath it, which keeps the interface code free of business rules and keeps storage details out of the domain model. Hover or focus a layer to see its role.

04 / Java Concepts

05 / Security Concepts

• →Authentication — a master password gate that must be satisfied before the vault contents are reachable.
• →Password masking — stored values are hidden by default and only shown on an explicit user action.
• →Input validation — records are rejected when required fields are empty or malformed.
• →Session / state management — the vault holds an unlocked state that can be explicitly released again.
• →Local data handling — data stays on the local machine; there is no synchronisation or remote storage.
• →Secure design principles — security-relevant logic is concentrated in one layer instead of scattered across the interface.

06 / Challenges

Space reserved for the genuine development challenges encountered while building this project. Each entry will be written up as it actually happens.

• →Managing application state across the login and dashboard screens.
• →Designing the class structure so responsibilities stay separated.
• →Connecting JavaFX controllers to the service layer cleanly.
• →Validating user input consistently across multiple entry points.
• →Persisting data reliably and handling a missing or malformed store file.
• →Handling errors gracefully instead of letting exceptions reach the interface.

These are the areas to be documented. Nothing here is presented as a solved problem until it has actually been solved.

07 / Results

08 / Source Code

The repository link will be added here once the project is published.

01 / Problem

Editing an image usually means opening a full graphics suite for tasks that are conceptually simple — brighten a photo, convert to grayscale, detect edges, resize, or compress. That overhead gets in the way of quick, scripted workflows. The Image Processing Studio exists to explore what a focused, small-scope image editor looks like when built from scratch with Python and Pillow.

02 / Objective

Build a Python desktop application that lets a user load an image, adjust its visual parameters, apply one-shot filters, and export the result. The project is also an exercise in structure — separating the image model, the processing logic, and the UI so that each part can be understood and changed independently.

• →Loading and rendering images efficiently in a Tkinter canvas.
• →Applying adjustments (brightness, contrast, blur) without destroying the original.
• →Implementing filters such as grayscale, edge detection, and blur.
• →Preserving image quality through resize operations.
• →Exporting images with configurable compression.
• →Keeping the codebase readable through clear module separation.

03 / Architecture

The project separates responsibilities into three layers. The view owns the widgets, the services own the image math, and the model owns the current document state. Hover or focus a layer to see its role.

04 / Python Concepts

05 / Image Processing Concepts

• →Pixel-level adjustment — brightness and contrast are applied by transforming each channel value while preserving the image's proportions.
• →Gaussian blur — a convolution kernel that averages neighbouring pixels to soften the image.
• →Edge detection — a kernel that highlights regions of rapid intensity change, useful for finding contours.
• →Resampling — Lanczos resampling is used when resizing to keep edges crisp.
• →Compression — JPEG quality controls the trade-off between file size and visible artefacts.
• →Non-destructive editing — the original image is preserved so a reset always returns to the starting state.

06 / Challenges

Space reserved for the real development challenges encountered while building this project. Each entry will be written up as it actually happens.

• →Keeping the Tkinter canvas responsive while processing larger images.
• →Preserving aspect ratio when the preview is scaled to fit the window.
• →Deciding where to apply adjustments — on the original or on a working copy.
• →Handling files that aren't valid images without crashing the app.
• →Choosing sensible defaults for compression quality.
• →Keeping the code layered as the feature set grows.

These are the areas to be documented. Nothing here is presented as a solved problem until it has actually been solved.

07 / Results

08 / Source Code

The repository link will be added here once the project is published.

01 / Concept

Procedural generation is the practice of producing content algorithmically instead of authoring it by hand. Instead of manually designing a single 80 × 80 tile map, a small set of rules and a random input are combined to produce an entire world on demand — potentially an unlimited number of distinct worlds from the same generator. It is used in games, simulations, and generative art, and it is valuable because it replaces repetitive manual work with a repeatable, parameterized process. This project exists as a way to practise those ideas in Python: algorithmic randomness, tile-based representation, and deterministic seeds.

02 / World Representation

The world is stored as a flat, two-dimensional grid of tiles. Every tile carries a single terrain value — one of water, plains, forest, mountain, or desert. On top of the tile grid, a separate list holds structure records (settlements) with their coordinates.

# The world is a single object holding:
#   - size:  int (grid width and height)
#   - seed:  int (input used to reproduce the world)
#   - tiles: list[list[str]]  — terrain id per cell
#   - settlements: list[tuple[int, int]]  — (x, y) coords

A flat grid is chosen because every tile is defined by exactly one terrain value, coordinates map directly to indices, and iteration over the entire map is trivial. This makes both generation and rendering a single pass over the data.

03 / Generation Algorithm

The generator uses fractal value noise — not Perlin noise, not cellular automata, and not wave function collapse. Two independent value-noise fields are produced:

• →an elevation field — used to decide water, mountains, and general land shape.
• →a moisture field — used to decide forests and deserts.

Value noise works by placing a random value at every integer lattice point, then smoothly interpolating between them. Interpolation is done with a smoothstep curve (3t² − 2t³), which removes the blocky appearance of raw random values. A single octave of value noise looks like soft blobs; combining several octaves at doubling frequencies and halving amplitudes — a technique called fractal Brownian motion (fBm) — produces natural-looking terrain with both large regions and fine detail.

def fbm(x, y, seed, octaves=5):
    value, amplitude, frequency = 0.0, 0.5, 1.0
    for i in range(octaves):
        value     += amplitude * value_noise(x * frequency, y * frequency, seed + i * 1000)
        amplitude *= 0.5
        frequency *= 2.0
    return value  # normalised roughly to 0..1

Once both fields are computed, every cell is classified against four thresholds derived from the user's parameters. Structures are then placed on plains tiles, biased toward cells that are close to water.

04 / Randomization

Randomness enters the system in exactly one place: the lattice values inside value_noise. For any integer coordinate (xi, yi) and a seed, a deterministic hash produces a number between 0 and 1. Because the hash is a pure function of its inputs, everything downstream of it is reproducible. Nothing else in the pipeline uses random.random() — the appearance of randomness comes entirely from the noise fields.

05 / Deterministic Seeds

A seed is a single integer that is mixed into every noise-hash lookup. Two consequences follow:

• →Same seed + same parameters → identical world. Nothing is stored between runs; the world is re-derived from the seed every time.
• →Different seeds → visibly different worlds. Even a change of ±1 in the seed reshuffles the entire map.

This is why the interactive demo above gives you a seed field — the concept can be tested directly. Enter 847291, generate, then enter it again and generate: the two maps are identical, pixel for pixel. This is the same principle behind Minecraft world seeds and many roguelike games.

06 / Terrain & Biomes

Every tile is classified with a short decision chain driven by the two noise values and the user parameters. All comparisons are made on values between 0 and 1.

The sliders do not change the noise — they shift where each threshold sits inside it, which is why density changes produce smooth, natural-feeling variation rather than disconnected patches.

07 / Challenges

This section will be written up honestly as the project develops. The list below are the areas I expect to be genuinely difficult; they are not yet presented as solved.

• →Tuning fBm octave counts so the world reads as terrain instead of static noise.
• →Choosing thresholds that produce balanced biome coverage across every seed.
• →Making sure neighbouring cells with similar elevation still produce readable boundaries.
• →Placing settlements so they feel intentional (near water, spaced apart) rather than purely random.
• →Rendering a large tile grid efficiently inside a Tkinter canvas.
• →Keeping the generator fast enough to feel interactive at 120 × 120.

08 / Results

09 / Source Code

The repository link will be added here once the project is published.