Glossary G–M

G

Git

Plain English: A version control system that tracks every change you make to your code, who made it, and when. It allows you to go back to any previous version of your project instantly.

Excel equivalent: Excel's Track Changes feature — but infinitely more powerful. Imagine Track Changes that works across an entire project (not just one file), records every change with a timestamp and author note, lets multiple people work simultaneously without overwriting each other, allows instant rollback to any historical version, and works offline. That is Git.

In practice: Every project in this program uses Git from day one. You will run git commit after completing meaningful work. Each commit is a snapshot of your entire project at that moment. If you break something later, you can restore any individual file or the entire project to any previous commit. "My code was working yesterday, now it is broken" is a problem that Git solves definitively.

As a CA, you already understand why version history matters — audit trails, rollback capability, and "who changed what" are professional requirements. Git gives your code those same protections automatically.

Don't confuse with: GitHub. Git is the tool that runs on your computer. GitHub is a website that stores your Git history online. Git without GitHub is perfectly usable — GitHub adds collaboration and cloud backup.

GitHub

Plain English: A website that stores your Git repositories online, enabling cloud backup, collaboration with other developers, and integration with deployment tools.

Excel equivalent: OneDrive or Google Drive for your Excel files — but specialized for code, with tools built specifically for tracking changes, reviewing updates, and merging contributions from multiple people.

In practice: Every project repository is pushed to GitHub. This serves three purposes: (1) off-machine backup — your laptop dies, your code survives; (2) deployment trigger — Vercel watches GitHub and auto-deploys when you push; (3) code review — Subhash reviews your pull requests on GitHub before code is merged.

Don't confuse with: Git. Git is the version control system. GitHub is one of many services that hosts Git repositories (GitLab and Bitbucket are alternatives). The distinction: you can use Git without GitHub, but you cannot use GitHub without Git.

Hook (React)

Plain English: A special function in React that allows components to use features like state (memory), side effects (fetching data), and shared logic. They always start with the word use.

Excel equivalent: A built-in Excel function that does something powerful under the hood — like =OFFSET() or =INDIRECT(). You call it with specific inputs and it gives you capabilities you could not easily build yourself. React Hooks are pre-built capabilities you call by name inside your components.

In practice: You will use these hooks constantly:

• useState — remember a value across re-renders (like a named cell that updates the display when it changes)
• useEffect — run code when something changes (like an event trigger in Excel)
• useQuery (from React Query) — fetch data from Supabase and manage loading/error states automatically

You will also write your own custom hooks. A hook called useCurrentUser() might fetch and return the logged-in user's profile. Write it once, use it in 20 components.

Don't confuse with: Git hooks (a completely different concept). Git hooks are scripts that run at specific points in your Git workflow — before a commit, before a push. React hooks are functions used inside React components. Same word, completely different meaning depending on context.

HTTP / HTTPS

Plain English: The protocol (the agreed set of rules) that governs how data travels between browsers and servers. Every request your browser makes to load a website uses HTTP. HTTPS is the encrypted, secure version.

Excel equivalent: The format rules for sharing a file. When you share an Excel file via email, both you and the recipient need to understand it is an .xlsx file — a shared format you both know how to open. HTTP is the shared format that browsers and servers both speak.

In practice: When your React app calls Supabase to fetch data, it makes an HTTP request. When Supabase responds with the data, it sends an HTTP response. You will see this in the browser's Network tab during debugging. Always use HTTPS in production — the S means the connection is encrypted so no one can intercept the data in transit.

Don't confuse with: An API. HTTP is the transport layer — how data moves. An API defines what you can ask for and what you get back. HTTP is the road; the API is the destination.

I

IDE

Plain English: Integrated Development Environment. A software application built specifically for writing code — it combines a text editor, error highlighting, autocomplete, debugging tools, and terminal in one place.

Excel equivalent: Excel itself is an IDE for spreadsheet work — it is not just a text editor, it is a specialized tool with formula autocomplete, error highlighting, a formula bar, charts, and data analysis tools all in one application. VS Code is the IDE for code.

In practice: We use VS Code as our IDE. Install the Claude Code extension and it becomes your AI coding partner — it reads your code, understands your project, and helps you write, fix, and review code without switching context. The integrated terminal lets you run git commit and npm run dev without leaving VS Code.

Interface (TypeScript)

Plain English: A description of the exact shape of a JavaScript object — what properties it must have, what type each property is. A contract that code must follow.

Excel equivalent: A standardized template header row. If every invoice sheet must have columns A=Date, B=Client, C=Amount, D=GST, E=Total — that is an interface. Any sheet that is missing a column or has the wrong type of data in a column fails the contract.

In practice: You will define interfaces for every type of data in your app.

TypeScript ensures that whenever you use a Job object, it always has these exact properties with these exact types. If your code tries to access job.sallary (a typo), TypeScript catches it before you even run the code.

Don't confuse with: A UI (user interface). In TypeScript, an interface is a type definition. In plain English, "interface" often means the visual screen a user interacts with. Different meanings — context makes it clear which is intended.

J

JSON

Plain English: JavaScript Object Notation. A standard text format for storing and transmitting structured data. It is what APIs send back and forth, and what databases return when you query them.

Excel equivalent: A structured export format — like when you export a filtered table to CSV, but more flexible. CSV is rows and columns. JSON can represent nested structures (an invoice that contains a list of line items, each with its own fields).

In practice: When your React app asks Supabase for a list of jobs, Supabase sends back JSON. Your code reads this JSON and displays it on screen. You will read and write JSON constantly — in API responses, in configuration files, in database queries.

Don't confuse with: JavaScript. JSON looks like JavaScript object syntax but it is a data format, not code. JSON does not have functions, variables, or logic — only data.

JSX

Plain English: A syntax extension that lets you write HTML-like code directly inside JavaScript. It is how you describe what a React component looks like.

Excel equivalent: Combining a formula and a format in one cell. Instead of writing the cell content separately from its formatting rules, JSX lets you write the visual structure (HTML) and the logic (JavaScript) together in one file.

In practice: A React component written in JSX has HTML-looking parts like div and h2. Dynamic JavaScript values are inserted using curly braces. React converts this into actual browser elements. You will write JSX in every component you build.

Don't confuse with: HTML. JSX looks like HTML but has important differences — className instead of class, onClick instead of onclick, and you can embed JavaScript expressions inside curly braces. It runs through a compiler (Vite) that converts it to real JavaScript before the browser sees it.

L

Library

Plain English: Pre-written code, created and maintained by someone else, that you import into your project to use. Instead of writing complex functionality from scratch, you use a library that already solved that problem.

Excel equivalent: An Excel add-in, or a pre-built set of custom functions someone has created. Power Query is a library — a powerful set of data transformation tools someone built and packaged so you do not have to write those transformations yourself.

In practice: Our stack is built on libraries: React (UI building), Tailwind CSS (styling), Supabase JS (database connection), React Query (data fetching), React Hook Form (forms), Zod (validation), Zustand (global state). None of these are things we built — they are proven solutions by experts. Our job is to combine them effectively to build our specific product.

Don't confuse with: A framework. A library gives you tools you call when you need them. A framework dictates the structure of your entire application. React is technically a library (you decide how to structure your app). Next.js is a framework (it enforces a file-based routing structure). The distinction matters less in daily practice.

Lint / Linter

Plain English: An automated tool that reads your code and flags potential problems — unused variables, inconsistent formatting, missing error handling — before you even run the code.

Excel equivalent: Excel's formula auditing toolbar. The tool that highlights cells with errors, traces precedents and dependents, and flags potential problems in your formula logic. A linter does this for code.

In practice: We use ESLint. When you save a file in VS Code, ESLint instantly underlines problems. A wavy red line might say "you imported useState but never used it" or "this function can return undefined — you need to handle that case." Catching these at write-time is far cheaper than debugging them at runtime. CI/CD will fail if lint errors exist — broken code cannot reach production.

Local / Development (Environment)

Plain English: Your own laptop. "Running locally" means the app is running on your machine, not on any server. Only you can access it.

Excel equivalent: Working on a file that lives only on your desktop — not in SharePoint, not emailed to anyone. The file exists for you alone. Changes are not visible to anyone else until you share it.

In practice: When you run npm run dev, your app starts on http://localhost:3000 — a URL that only works on your machine. This is your development environment. You can break things freely here — it does not affect real users. When you are ready, you deploy to the staging or production environment.

Don't confuse with: Staging or production. Local = your laptop, visible only to you. Staging = a real server, visible to the team for testing. Production = the live server, visible to real users.

M

Merge

Plain English: Combining changes from one Git branch into another. Most commonly, combining your feature branch changes into the main branch so they become part of the live product.

Excel equivalent: Consolidating data from two Excel files that were worked on separately. Except Git does this automatically — it identifies which lines changed in each version and intelligently combines them. If two people changed the same line, Git flags a "merge conflict" for a human to resolve.

In practice: You build a feature on the branch add-fee-payment. Subhash reviews your Pull Request on GitHub, approves it, and merges the branch into main. Vercel detects the merge, builds the updated code, and deploys it. The feature is now live. Merge is the final gate in every feature's journey.

Don't confuse with: Pull Request. A Pull Request is the request to merge (and the discussion/review that precedes it). Merge is the actual act of combining the branches.

Migration (Database)

Plain English: A versioned script that makes a specific change to your database structure (adding a column, creating a new table, adding an index). Migrations are the Git commits of your database — each one is a recorded, reversible change.

Excel equivalent: Keeping a change log of every structural change you make to your data sheets. "2025-05-01: Added 'GST Number' column to Client sheet. 2025-05-08: Split 'Address' column into 'City' and 'State'." Migrations are this change log, but executable — the database can replay each change in order to reach any historical state.

In practice: When you need to add a new feature that requires a new database column, you write a migration. The migration file contains the SQL command. You run it locally to test it, then push it to production. Every migration is stored in the supabase/migrations/ folder. New developers joining a project run all migrations in order to build up the correct database structure.

Don't confuse with: Seeding. A migration changes database structure (schema). Seeding adds initial data to a database. Both involve SQL, but they serve different purposes.