Every word, made clear.

2FA asks for a second proof of identity on top of your password — usually a short code from your phone. The idea is simple: even if a thief steals your password, they still can't get in, because they don't have the second piece. It's the deadbolt on top of the door lock.

The 'two factors' are deliberately different kinds of thing: something you KNOW (your password) and something you HAVE (your phone, or a code from an app like Google Authenticator). A leaked password is only knowledge — it doesn't put your physical phone in the attacker's hands.

You'll usually meet it as a six-digit code that refreshes every 30 seconds, or a tap-to-approve notification. Slightly more friction for you, hugely more work for an attacker — which is why turning it on is the single best thing you can do for an important account.

An ADR — Architecture Decision Record — is a short document that records one important technical decision and, just as importantly, WHY it was made. Months later, when someone asks 'why on earth did we build it this way?', the answer is already written down.

Each ADR is small and follows the same shape: the Context (the situation that forced a choice), the Decision (what we chose), the Rationale (why), the Alternatives we considered, and the Consequences (what we gain and what we now live with).

You keep them as plain markdown files in the project, numbered in order (0001, 0002…), so the team's reasoning grows into a readable history rather than vanishing into someone's memory.

An algorithm is a precise, step-by-step recipe for solving a problem or getting a result. Before your code does anything, there's a plan behind it — the exact sequence of steps that turns the input you have into the answer you want. The algorithm is that plan; the code is just one way of writing it down.

A good way to feel it: a cooking recipe is an algorithm. Take these ingredients, do these steps in this order, and you reliably get the dish. So are the directions to a friend's house. What makes it an algorithm rather than a vague idea is the precision — no step left to guesswork, each one clear enough that a machine could follow it.

The same problem can have many algorithms, and they're not equally good. Sorting a list of names can be done a dozen ways; some finish in a blink, others crawl on a long list. So choosing the right algorithm — fast enough, simple enough, correct in every case — is a real part of the craft, separate from the typing of code itself.

An API is an agreed-upon way for two programs to talk to each other. It's a contract: 'here are the requests you're allowed to make, and here's exactly what you'll get back.' You don't need to know how the other program works inside — you just need to know what to ask for and what shape the answer comes in.

The classic picture is a restaurant menu. You don't walk into the kitchen and cook; you read the menu, point at item #4, and a plate comes out. The menu is the API: a fixed list of things you can ask for, hiding all the chopping and frying behind it. The kitchen can rearrange itself completely and your order still works, as long as the menu stays the same.

This is why APIs are everywhere. When a weather app shows you tomorrow's forecast, it didn't measure the sky — it asked a weather service's API and got back a tidy answer. APIs let programs borrow each other's abilities without ever sharing their messy insides.

An array is an ordered list of values that you keep in a single variable. Instead of three separate variables for three names, you put all three in one array and carry them around together — like a row of numbered lockers, each holding one item, all under the same name.

You reach into an array by position, called the index. The catch that trips up every beginner: counting starts at 0, not 1. So the first item is at index 0, the second at index 1, and so on. The first time you ask for 'item 1' and get the second thing, you'll remember this forever.

Because the items sit in order, an array is the natural shape for anything that's a sequence — a to-do list, the days of the week, search results. And it pairs perfectly with a loop: you write one small piece of code and let it walk down the whole array, doing the same thing to each item in turn.

Async is a way of starting something slow — fetching data over the network, reading a big file — and then carrying on with other work instead of standing around waiting. When the slow thing finally finishes, your code circles back to deal with the result.

Think of ordering coffee: you don't freeze at the counter until it's ready. You take a buzzer, go find a seat, and the buzzer goes off when your drink is done. The buzzer is a 'promise' — a placeholder for an answer that hasn't arrived yet. And 'await' is just you choosing to sit and wait for that one buzzer before doing the next thing.

This is why beginners meet promises and await so early: a network call can take half a second, and half a second is an eternity to a computer. Async lets the program stay lively and responsive instead of locking up while it waits.

Authentication is how a system proves WHO you are. It's the login step: you show a password, a one-time code, a fingerprint, and the server is satisfied you really are the person you claim to be — like a bouncer checking your ID at the door.

Crucially, it answers only 'who?', not 'what are you allowed to do?'. That second question is authorization, and people mix the two up constantly. The handy memory trick: authentication is the door, authorization is the rooms you're allowed into once you're inside.

Once you've authenticated, the server usually hands you a token or sets a cookie so you don't have to type your password on every single request — proof of identity you carry with you for the rest of the session.

Authorization decides WHAT you're allowed to do, once the system already knows who you are. You've logged in — fine — but can you delete this file? View someone else's salary? Open the admin panel? Authorization is the gatekeeper that answers each of those.

It always comes after authentication. First the system confirms your identity (authn), then it checks your permissions (authz). Knowing who you are tells it nothing about what you may touch — a logged-in guest and a logged-in admin are equally 'authenticated' but very differently 'authorized'.

When you hit a wall you can't pass, that's usually an authorization failure: the server knows exactly who you are, it just won't let you do that. On the web it often shows up as a 403 Forbidden.

The backend is the part of an app that runs on the server, out of sight. It holds the data, enforces the rules, and does the real work — checking your password, saving your order, totting up your bill. You never look at it directly; you only ever see the answers it sends back.

Think of a restaurant. The dining room you sit in is the frontend — menus, tables, the friendly waiter. The backend is the kitchen and the back office: where the food is actually cooked, the stock is counted, and the till keeps the money straight. Customers never wander back there, and they don't need to — they just enjoy the meal that comes out.

The two halves talk through an API: the frontend asks ('log this person in', 'give me their orders'), and the backend does the heavy lifting and replies. It's also where the sensitive stuff lives — the database, the passwords, the business logic — kept on the server precisely so it stays out of the user's hands.

Boilerplate is the repetitive setup code you write almost the same way every single time — the standard opening lines you have to lay down before the interesting part of a program even begins.

Every new project needs its plumbing: import the libraries, configure the settings, wire up the basics. None of it is the clever idea you came to build — it's the same scaffolding around it, identical from one project to the next. The name comes from old print shops, where ready-made blocks of text were cast on steel plates and reused unchanged across many newspapers.

Because it's so predictable, tools love to generate it for you — a 'create-app' command or a starter template hands you the boilerplate so you can skip straight to the fun part. When you copy it without quite reading it, that's normal; just know it's the floor you're standing on, not the room you came to decorate.

A branch is a parallel line of work — your own private copy of the project where you can build something new without touching what everyone else relies on. The shared, official version usually lives on a branch called main; you make your own branch off it, tinker freely, and only fold your work back in once it's ready.

It's lighter than it sounds. A branch isn't a folder full of copied files — it's just a movable pointer to a commit. Making one is instant, and switching between branches is like flipping the project to a different version in place. This cheapness is on purpose: you're meant to branch often, even for a five-minute experiment.

The everyday rhythm is one branch per task. Fixing a bug? Branch. Trying a risky idea? Branch. If it works out, you merge it in; if it doesn't, you just throw the branch away and main never knew a thing. Your messes stay your own until you decide to share them.

A browser is the program you use to visit websites — Chrome, Safari, Firefox, Edge. Its job is to fetch a web page from some server far away and then draw it on your screen as something you can read and click. Everything you do 'on the web' actually happens through a browser.

Under the hood it's running three things a website sends it. HTML is the page's structure and words; CSS is the styling — colours, fonts, layout; and JavaScript is the behaviour that makes the page react when you type or click. The browser takes those three, assembles them into the page you see, and keeps it lively. In that sense a modern browser is less a viewer and more a little machine that runs other people's programs.

It also handles the messy plumbing for you: looking up addresses, opening a secure connection, downloading images, keeping you logged in. You type 'go here', and the browser quietly does the fetching, decoding, and drawing — so the whole web feels like one smooth place rather than thousands of separate servers.

A bundler is a tool that stitches your many source files — JavaScript, CSS, images, and the libraries they pull in — into a few small, optimized files a browser can download and run fast. You write code split across dozens of tidy files; the bundler packs them for the trip.

It also tidies along the way: removing dead code, shrinking file sizes, and translating newer syntax so older browsers cope. The result is far fewer downloads, so your page loads quicker.

Vite, webpack, and esbuild are the popular ones today. You mostly meet a bundler through a 'build' step that turns your readable project into the lean bundle you actually ship.

A cache is a stash of results kept somewhere close and fast, so you don't have to redo slow work every time. The first time is expensive — fetch from a faraway server, run a heavy calculation — but you save the answer, and every time after that you just grab the saved copy.

Think of it like keeping your everyday mugs on the counter instead of climbing up to the top shelf each morning. Your browser caches images so a page loads instantly on your second visit; a database caches frequent queries so it doesn't have to recompute them.

The catch is staleness: a cached copy can fall out of date with the real thing. Deciding when to throw the old copy away is 'cache invalidation' — only half-jokingly called one of the two hardest problems in computer science.

CI/CD is a tireless robot that automatically tests and ships your code every time you push a change. Instead of you remembering to run the tests and copy files to the server, a machine does it the same careful way, every single time.

CI — Continuous Integration — is the testing half. Each time someone pushes new code, CI builds the project and runs the tests, so a mistake gets caught in minutes instead of next week. It's the friend who double-checks your work before anyone else sees it.

CD — Continuous Delivery — is the shipping half. Once the tests pass, CD packages the code up and deploys it, so the latest good version reaches users automatically. Together they form a 'pipeline': push your code, and it flows from your laptop to production with no nervous manual steps.

A commit is a saved snapshot of your changes, stamped with a short message explaining why you made them. It's the moment you tell git 'remember the project exactly like this' — a checkpoint you can always return to.

Commits are the building blocks of history. String them together and you get a timeline of the whole project: each one knows what changed, who made the change, when, and the reason in their own words.

The message matters more than beginners expect. Six months later, a clear note like 'fix login crash on empty password' is a gift to your future self; 'stuff' or 'asdf' helps no one. Write the why, not just the what.

Your code is written for humans, but the machine only runs its own low-level instructions — so something has to translate. There are two broad ways to do it, and the difference shapes how you build, ship, and debug.

A compiled language (like C or Rust) translates the whole program up front, all at once, into a standalone machine-runnable file before it ever runs. It's a separate 'build' step — slower to start, but the finished program tends to run fast, and many mistakes get caught at compile time.

An interpreted language (like Python or JavaScript) translates and runs line by line, on the spot, as the program executes. There's no build step, so you can edit and re-run instantly — lovely for tinkering — but errors tend to surface only when that line actually runs.

In practice the line is blurry: many modern languages compile to an in-between 'bytecode' and use clever tricks. But the mental model still holds — translate-everything-first, or translate-as-you-go.

A conditional is code that makes a decision. It checks whether something is true, and based on the answer it picks which path to take: IF this is true, do that — OTHERWISE, do something else. This is how programs choose.

It works like a fork in the road. The program reaches the fork, asks a yes/no question — is the user logged in? is the cart empty? — and goes left or right depending on the answer. Same code, different outcomes for different situations.

You can chain the questions: if the first isn't true, check a second (else if), and if none match, fall through to a final catch-all. That's how a handful of simple yes/no checks add up to behaviour that feels smart.

A container is a lightweight, sealed box that packages your app together with everything it needs to run — the right language version, libraries, settings, all of it. Hand that box to any machine and the app behaves exactly the same, banishing the classic 'but it works on my computer' headache.

Think of it like a shipping container at a port: the crane doesn't care what's inside — a fridge, bananas, car parts — it just lifts a standard box. Your laptop, a teammate's, and the production server all run the same container the same way.

Containers are lighter than full virtual machines because they share the host's operating system instead of bundling their own. Docker is the tool that made them popular, and you'll often hear 'spin up a container' for starting one.

A cookie is a tiny note a website asks your browser to keep — and to hand back, automatically, every time you visit that same site again. It's how the web remembers you. HTTP itself is forgetful: each request arrives as if you'd never been there before, so the site slips you a little name tag and your browser quietly clips it on for next time.

The classic job is staying logged in. When you sign in, the server sends back a cookie holding something like a session id or a token. From then on your browser attaches that cookie to every request, and the site goes 'ah, it's you' — no need to type your password on every single page.

It's just a small piece of text the site sets and your browser stores, scoped to that one domain. Cookies aren't programs and can't read your files; they're more like a coat-check ticket the site handed you, that you politely show again each time you come back.

CORS is the browser rule that stops a web page from quietly calling a different website's API unless that other site has explicitly said 'yes, you're allowed.' Your page is from one origin (say myapp.com); the API lives at another (api.bank.com); by default the browser slams the door between them. CORS is the polite handshake that opens it.

It exists for a good reason. Without it, any sketchy site you happened to visit could fire off requests to your bank, your email, your everything — riding on the login cookies already sitting in your browser. So the browser enforces a default of 'a page may only freely talk to its own origin,' and a server has to opt in by sending back a header (Access-Control-Allow-Origin) that names who's welcome.

Here's the part that trips up every beginner: a 'CORS error' is not a bug in your code and not really an error from the server — it's the browser refusing to hand you a response the server already sent, because the server forgot to include the permission header. The fix lives on the API server (add the header), not in your frontend. Once you know that, those red console messages stop being scary.

The CPU is the chip that actually does the computing — the brain of the machine. Every instruction in every program you run, from adding two numbers to drawing a pixel, ultimately gets carried out here, one tiny step at a time. What makes it feel magical is sheer speed: a modern CPU runs billions of these little steps every second, so a mountain of trivial operations adds up to a smooth video, a fast page load, a game that responds the instant you move.

On its own, the CPU is surprisingly simple-minded. It mostly just fetches an instruction, does it, and grabs the next — fetch, do, repeat, forever. The cleverness you see on screen comes from stacking billions of those dumb little steps into something useful. Programs live in RAM; the CPU reaches into that fast workspace to grab the next instruction and the data it needs to work on.

Modern CPUs pack several 'cores', and each core is essentially its own little brain that can work on a different task at the same time. That's why a 'quad-core' chip can keep your music playing, your download going, and your editor responsive all at once — four workers instead of one, each chewing through their own pile of instructions.

CRUD is the four basic things almost every app does with its data: Create something new, Read it back, Update it, and Delete it. Add a note, look at it later, edit a typo, throw it away — that's all four, and you've been doing CRUD your whole life without the acronym.

It shows up everywhere because it maps cleanly onto the tools underneath. In a SQL database the four are INSERT, SELECT, UPDATE and DELETE; over HTTP in a REST API they're usually POST, GET, PUT/PATCH and DELETE. Same four ideas, just spoken in different dialects.

When someone says an app is 'just CRUD', they mean its job is mostly shuttling records in and out of a database with no fancy logic — which is most software, and nothing to be ashamed of.

CSS is the language that styles a web page — the colors, fonts, spacing, and layout. If HTML is the skeleton, CSS is the skin and clothes: it takes that plain structure and decides how everything actually looks.

You write CSS as a list of rules. Each rule picks something on the page (a 'selector') and then sets its properties: make every heading dark blue, give paragraphs a comfy line height, lay the navigation out in a row. Change one rule and every matching element updates at once.

The 'cascading' part is the clever bit: when several rules touch the same element, CSS has a clear set of priorities for which one wins. That's how a site keeps a consistent look while still letting you override just one button or one page when you need to.

A daemon is a program that runs quietly in the background, waiting to do its job — it has no window, and you almost never see it. It just sits there, ready: listening for logins, sending mail, running tasks on a schedule.

You can usually spot one by the trailing 'd' in its name. sshd handles remote logins, cron runs scheduled tasks, nginx serves web pages, and dockerd runs your containers.

It's pronounced 'DEE-mun'. The word is borrowed from classical Greek, where a daemon was a guardian spirit working away in the background on your behalf — a surprisingly lovely name for a piece of software that's always quietly on call.

A data type is what KIND of value something is. Is it text? A number? A simple true/false? A list of things? The type tells the computer — and you — what a value really is, and that decides what you're allowed to do with it.

The common ones show up everywhere: a string is text like "hello", a number is something like 42 or 3.14, a boolean is just true or false, and an array is an ordered list. Each comes with its own toolbox of things it can do.

Type matters because it sets the rules. Add two numbers and you get their sum; 'add' two strings and they join end to end. Try to multiply a word by a word and the program simply can't — that's the type quietly keeping you honest.

A database is an organized place to keep your app's data so you can save it, find it again, and change it — reliably, even when thousands of people are using your app at once. Think of it as a filing cabinet that never loses a page and can fetch any one in an instant.

You could just dump everything into a text file, but the moment two people edit at the same time, or you want to ask 'which orders shipped last week?', that falls apart. A database handles the hard parts for you: fast lookups, keeping data consistent, and not losing anything if the power blips mid-write.

The most common kind is relational — data lives in tables of rows and columns (think a very smart spreadsheet), and you talk to it with SQL. Popular ones include PostgreSQL, MySQL, and SQLite.

A debugger is a tool that freezes your running program mid-stride so you can look inside it. Instead of guessing why something went wrong, you pause the code at a chosen line, then walk it forward one step at a time — watching exactly what each variable holds at each moment. It answers the real question: not 'what broke' but 'WHY'.

The trick is the breakpoint — a marker you drop on a line that says 'stop here'. When the program reaches it, everything halts and hands you the controls. You can peek at every value, step into a function to follow it deeper, or let it run on to the next breakpoint. It's like pausing a movie frame by frame to catch the exact moment a trick was done.

Before debuggers, people scattered print statements everywhere to spy on their code — and many still do for quick checks. A debugger is the grown-up version: no editing your code, no rerunning a dozen times. You stop time, look around, and the bug usually gives itself away.

A dependency is someone else's code that your project relies on to work. Almost nothing is built from scratch anymore: you want to parse a date, draw a chart, or talk to a database, so instead of writing that yourself you reach for a library that already does it — and now your project depends on it.

You don't paste that code into your project by hand. Instead you write its name (and which version you'll accept) in a small manifest file, and your package manager reads that list and installs each one for you, along with whatever those need in turn.

It's a wonderful shortcut — you stand on a mountain of work other people already did. The trade-off is that you've taken on their code: when a dependency has a bug, gets an update, or is abandoned, that's now partly your concern too. Lean on dependencies, but know what you're leaning on.

Deployment is the act of taking the code that runs on your computer and putting it onto a live server, where real users can actually reach it. Up to that point your app is private — a rehearsal. Deploying is opening the doors. Developers just call it 'shipping': you ship your code out into the world.

The gap it closes is the one between 'works on my machine' and 'works for everyone'. A deployment copies your finished code to a server that's always on, installs what it needs, and points your web address at it. The moment it's done, someone on the other side of the planet can load your page.

It used to be a tense, manual, late-night ritual. Now it's mostly automated: you push your code, an automated pipeline builds and tests it, and if everything's green it deploys on its own. Done well, shipping a change becomes a quiet everyday thing — many teams deploy several times a day without anyone holding their breath.

When something is deprecated, it's officially discouraged and on its way out. It still works for now — nothing breaks today — but the maintainers are telling you plainly: stop using this, a better replacement exists, and one day this will be removed for good.

Think of it as the polite 'last call' before a feature is shown the door. You'll usually meet it as a deprecation warning in your console or docs, often pointing you straight to what to use instead.

The kind move is to act on the warning while it's still just a warning. Deprecated code is living on borrowed time — migrate to the replacement now, on your own schedule, rather than scrambling later when an upgrade finally deletes it.

DNS is the internet's phone book. You type a friendly name like example.com, but computers don't actually find each other by name — they find each other by number, an IP address like 93.184.216.34. DNS is the system that quietly looks up the name and hands back the number, every single time, before your browser can connect to anything.

It works because nobody wants to memorize a dozen numbers just to visit their favorite sites. Names are for humans; numbers are for machines. So whenever you click a link or load an API, the very first invisible step is a DNS lookup: 'what's the IP for this name?' Only once that answer comes back can the real request go out. It's so fast and automatic that you forget it's happening — until it doesn't.

And that's the practical bit to remember: a surprising number of 'the site is down' moments are really DNS problems — a name that points at the wrong number, or a fresh domain whose entry hasn't spread across the world's servers yet (people call that 'waiting for DNS to propagate'). When something connects to the wrong place, or to nothing at all, the phone book is the first place to look.

An endpoint is one specific address an API exposes for one specific action. If an API is the whole menu, an endpoint is a single line on it: a URL like /users that you can hit to get something done. Send a request to that address, and the API does that one job and replies.

Each endpoint usually pairs a path with a verb that says what you want to do: GET /users means 'give me the list of users,' POST /users means 'create a new user,' GET /users/42 means 'show me user number 42.' Same address, different verb, different action — like asking the same desk to either show you a record or file a new one.

So an API is really just a tidy collection of endpoints, each one a small, named door into a specific capability. Learn an API and you're mostly learning its list of endpoints: what doors exist, and what each one does.

An environment variable is a named value that lives outside your code, in the environment your program runs in — and your program reads it when it starts up. Think of it as a sticky note left for the program: PORT=3000, DATABASE_URL=…, API_KEY=… The code says 'whatever PORT is set to, listen there,' without ever hard-coding the number.

This is how the same code behaves differently in different places. On your laptop DATABASE_URL points at a tiny test database; in production it points at the real one — and not a single line of code changes. You just set the variables differently in each environment.

It's also where secrets belong. API keys and passwords go in environment variables precisely so they stay OUT of your source code — if a secret is baked into a file you commit, it ends up in your git history forever, visible to anyone with the repo. Keep them in the environment, and they never touch the codebase.

An exit code is the single number a program hands back when it finishes — its way of saying 'this went fine' or 'something broke'. By a near-universal convention, 0 means success and anything else (1, 2, 127…) means some kind of failure. It's the program's last word before it leaves.

You rarely see it, because it's not printed — it's tucked away for the next program to read. In a shell you can peek at it with $? right after a command, or just chain commands together: 'build && deploy' only runs deploy if build exited 0, because && means 'and only if that succeeded'.

This quiet number is the whole reason automation works. When CI says your build 'failed', what really happened is a step finished with a non-zero exit code, and the pipeline noticed. Computers can't read your test output, but they can always read a 0.

File permissions decide who is allowed to do what with a file: read it, change it, or run it. On Unix-like systems (Linux, macOS) every file carries three little switches — r (read), w (write), x (execute) — and they're set separately for three groups of people: the owner, the owner's group, and everyone else.

That's what the cryptic 'rwxr-xr-x' from ls -l is showing you: the owner can read/write/run, while the group and everyone else can only read and run. The same thing gets written as a number, like 755, where each digit is just r=4 + w=2 + x=1 added up. You change them with chmod.

The one that trips up every beginner is x. A script isn't allowed to run just because it exists — it needs the execute bit. That's why you so often type chmod +x deploy.sh before ./deploy.sh will work, and why a missing x earns you a curt 'Permission denied'.

A file system is how the operating system organizes everything on a disk into named files tucked inside folders — and how it finds any one of them again later. A bare disk is really just a vast sea of numbered blocks; the file system is the librarian on top, keeping the catalog that says 'the photo you call beach.jpg lives in these blocks, inside the Pictures folder.' Without it, your files would be there in the raw bits, but nothing could tell where one ends and the next begins.

You navigate it by path — a trail of folder names that pins down exactly where a file sits, like /Users/jo/notes/todo.txt or C:\Users\Jo\todo.txt. Read it left to right: start at the top, step down through each folder, and the last name is the file itself. That string is an address, and following it always lands you in one precise spot in the tree.

The folders nest into a tree, branching down from a single top called the root. This shape is why the same notes.txt can sit harmlessly in two different folders: their full paths differ, so the system never confuses them. The file system also remembers each file's size, its timestamps, and who's allowed to open it — the bookkeeping that turns raw storage into something you can actually browse.

A foreign key is a column in one table that points to the primary key of another — it's how a database links rows together. An order, for example, holds the id of the customer who placed it; that customer_id is a foreign key, a little arrow from the order over to the right person.

This is the trick that turns separate tables into a connected web. You don't repeat the customer's whole name and address on every order — you just store their id once and reach for it whenever you need them. Follow the arrow and you can jump from an order to its customer, or gather all orders belonging to one customer.

The database can guard these links for you: it'll refuse to let an order reference a customer who doesn't exist, and can stop you from deleting a customer who still has orders pointing at them. That guardrail is called referential integrity — it keeps your data from pointing into thin air.

A fork is your own complete copy of someone else's repository, made on the hosting side (GitHub, GitLab) with a single click. It lives under your account, so you can change anything you like without needing permission to touch the original.

It's how open source works: you fork a project you can't write to, push your changes to your copy, and then open a pull request asking the original maintainers to pull your work back in. They review it; if they like it, it becomes part of the real project.

Don't confuse a fork with a clone or a branch. A branch is a line of work inside one repo; a clone is a copy on your own laptop; a fork is a whole separate repo on the server, with your name on it — your launchpad for proposing changes to a project that isn't yours.

A framework is a ready-made scaffold for building an app — a structure with the common parts already in place so you don't start from a blank page every time. Tools like React, Django, and Rails hand you a sensible layout, solutions to the boring-but-necessary problems, and a clear spot to plug in the parts that are actually unique to your app.

Here's the twist that defines a framework: it calls your code, not the other way round. With a plain library, you're in charge — you reach for a tool when you need it. With a framework, the framework runs the show and calls your functions at the right moments ('a request just came in — here, you handle it'). This is sometimes called 'inversion of control', and it's the whole bargain: you give up some freedom over the structure, and in return you skip a huge amount of plumbing.

The payoff is speed and shared ground. You're not reinventing routing, forms, or page rendering — the framework already did that. And because thousands of others use the same one, there's a deep well of guides, fixes, and ready-made pieces to draw from. The cost is that you build things the framework's way; learning a framework is partly learning its opinions.

The frontend is the part of an app you actually see and touch — the buttons, the text, the layout, the things that move when you click. It runs in your browser, on your own device, built out of HTML, CSS, and JavaScript.

It's one half of a pair. The frontend is the shopfront: the windows, the shelves, the person at the counter. The backend is everything behind the wall — the storeroom, the till, the records — which you can read about under backend. The frontend's job is to make all of that feel simple and pleasant to use.

Because it runs on the visitor's machine, the frontend has to be friendly and fast: it shows what's there, gathers what you type or tap, and talks to the backend to fetch or save the real data. Anything you can inspect by right-clicking a page is the frontend.

A function is a reusable little machine. You feed it some inputs, it does one job, and it hands you back a result. Write it once, then call it by name anywhere you need that job done — no need to spell out the steps again.

Think of a coffee machine: water and beans go in (the inputs), it runs its routine, and coffee comes out (the result). You don't rebuild the machine each morning — you just press the button.

This is how programs stay tidy and readable. Instead of copy-pasting the same ten lines all over, you wrap them in a named function and call it. Fix the logic in one place and every caller gets the fix for free.

Git is a tool that remembers every version of your code, so you can save your work, look back at what changed, and undo a mistake without losing everything. Think of it as an unlimited 'undo' history for an entire project, with a note on every save explaining what you did.

It's distributed, which is a fancy way of saying every copy of the project is complete: your laptop has the full history, your teammate has the full history, and the server has the full history. You can work, save, and browse the past even with no internet.

One thing to keep straight: git is the tool, GitHub is a website that hosts your git projects online. You can use git all day without ever touching GitHub — they're not the same thing.

A hash is a short, fixed-size fingerprint computed from any piece of data. Feed in a single word or an entire movie, and the hash function spits out the same-length string of characters — a tidy little signature that stands in for the whole thing. The same input always produces the same hash, and even a one-letter change scrambles it completely.

Two properties make it useful. First, it's one-way: you can go from data to hash in an instant, but you can't run it backwards to recover the original — the fingerprint doesn't contain the person. Second, it's a reliable summary: if two files have the same hash, they're almost certainly identical, so you can check a download wasn't corrupted just by comparing fingerprints instead of every byte.

That same trick powers fast lookups. A hash map turns a key like 'email' straight into a number that says exactly which slot to look in — no scanning a list, just compute the hash and go. It's why looking something up by key feels instant even in a giant collection.

HTML is the language that gives a web page its structure and content — the headings, paragraphs, links, images, and lists. Think of it as the skeleton of the page: it decides what's there and what each piece is, but not yet how any of it looks.

You build a page out of tags — little labels wrapped in angle brackets that come in pairs. <h1>…</h1> marks a big heading, <p>…</p> a paragraph, <a href="…">…</a> a link. The browser reads these tags and turns them into the page you see.

On its own, raw HTML looks plain — black text on a white background. That's by design: HTML handles the bones, CSS adds the looks, and JavaScript adds the behavior. Together they make every page on the web.

HTTP is the simple back-and-forth that the whole web is built on: your browser sends a request ('please give me this page'), and a server sends back a response ('here it is'). Every page you open, image you load, and form you submit is really just one of these little request-and-reply exchanges.

Each request names a method — GET to fetch something, POST to send something — points at a URL, and comes back with a status code (200 if all went well, 404 if the thing wasn't there). It's a polite, stateless conversation: each request stands on its own, and the server forgets you the moment it's done.

HTTPS is the exact same conversation, just locked inside an envelope. The S is for secure: the connection is encrypted (via TLS), so no one snooping on the wire can read or tamper with what's passing through — which is why the padlock shows in your address bar. These days plain HTTP is treated as unsafe, and HTTPS is simply the default.

An HTTP status code is the little 3-digit number a server puts at the top of every web response to tell you, in one glance, how the request went. You've already met the famous ones: 200 means 'OK, here you go,' 404 means 'I couldn't find that,' and 500 means 'something broke on my end.' Every page you load and every API call you make comes back stamped with one of these.

The first digit sorts them into five families, which is the only part worth memorizing. 2xx = success (it worked). 3xx = redirect (look over there instead). 4xx = you messed up (bad request, not found, not allowed). 5xx = the server messed up (it's not your fault). So even a code you've never seen — say 429 — you can read at a glance: 4-something, so the problem is on the asking side (it means 'too many requests, slow down').

When you're debugging, the status code is the first thing to check. A 401 tells you it's a login problem; a 404 tells you the address is wrong; a 500 tells you to stop poking your code and go read the server's logs. It's the server's one-word answer to 'how did that go?'

An IDE is a text editor with superpowers — one app where you write, run, and fix your code without ever leaving it. The name spells out the idea: it integrates, in one window, all the separate tools a programmer would otherwise juggle. VS Code, IntelliJ, and Xcode are the ones you'll hear most.

Here's why people love it. As you type, it autocompletes the rest of a word, suggests what comes next, and underlines mistakes in red before you even run anything — like a spell-checker that actually understands code. A button runs your program; another opens a debugger to pause it and look inside.

You could absolutely write code in plain Notepad — many start there. But an IDE quietly removes a hundred tiny frictions a day: jumping to where a function is defined, renaming something everywhere at once, flagging a typo the instant you make it. It's the difference between writing by hand and writing with a very attentive assistant looking over your shoulder.

An operation is idempotent if doing it once and doing it ten times leave you in exactly the same place. Pressing the elevator button again doesn't summon ten elevators; the button is already lit, and pressing it changes nothing. The result is the same no matter how many times you repeat the action.

Contrast that with 'add 1 to my balance' — run it five times and you're five dollars richer, which is decidedly NOT idempotent. But 'set my balance to 100' is: run it once or fifty times, the balance is 100. The difference is whether repeating piles up effects or just lands on the same answer.

This is what makes retries safe. Networks drop, requests time out, and you often can't tell whether a request actually went through. If the operation is idempotent, you can simply try again without fear of charging the card twice or creating two copies — repeating it is harmless.

JavaScript is the programming language that makes web pages interactive. HTML gives a page its structure and CSS its looks, but JavaScript gives it behavior — it's what makes a button respond to a click, a form check itself, or a feed load more posts without reloading the whole page.

It runs right inside the browser, on the visitor's own computer. When you click 'like' and the heart fills in instantly, that's JavaScript reacting on the spot, quietly fetching and updating just the bit that changed instead of fetching a brand-new page.

Despite the name, it has nothing to do with the Java language — the resemblance is a 1990s marketing accident. These days JavaScript also runs outside the browser (on servers, in tools), but its home turf is, and always was, the page in front of you.

JSON is a simple text format for writing down structured data — names paired with values — in a way that both people and programs can read. If you've ever seen { "name": "Ada", "age": 36 }, that's JSON: curly braces holding a list of keys and their values.

It's the lingua franca of APIs. When one program asks another for data over the web, the answer almost always comes back as JSON, because nearly every language can read and write it effortlessly.

The building blocks are tiny: text in "quotes", numbers, true/false, lists in [square brackets], and objects in {curly braces}. That's the whole language — small enough to learn in an afternoon, flexible enough to carry almost anything.

A JWT is a compact, self-contained token that says who you are and is signed so the server can trust it. Think of it like a tamper-proof wristband at a festival: it has your details printed on it, and a seal that proves staff actually issued it. Show the band and you're waved through — nobody has to look you up in a list.

That's the clever part. A traditional login means the server keeps a session in its own memory and checks it on every request. A JWT instead carries the facts inside the token itself, and the server just verifies the signature. No database lookup, which is why JWTs are popular for keeping you logged in across many servers.

A JWT comes in three dot-separated parts — header.payload.signature — and the first two are just Base64, not encryption. So never put secrets in a JWT; anyone holding it can read the payload. The signature stops them from changing it, not from seeing it.

The kernel is the core of the operating system — the one piece of software that talks directly to the hardware and decides who gets to use it. Every program that wants to read a file, send over the network, or use a slice of memory has to ask the kernel first.

Its biggest job is sharing. There's only one CPU (well, a few cores) and a limited pile of memory, but dozens of programs all want them at once. The kernel hands out tiny turns so fast that everything seems to run at the same time, and keeps each program walled off so a crash in one doesn't take down the rest.

You never run the kernel directly — it sits underneath everything, invisible. Your shell, your browser, your editor all make their requests to it. When people say 'Linux', strictly speaking they mean the kernel; everything else is the software gathered around that quiet, central piece.

A linter is a tool that reads your code and quietly flags likely mistakes and messy style — before you ever run the program. It's the friendly proofreader looking over your shoulder, underlining the bug you were about to ship.

It catches things like an unused variable, a forgotten semicolon, a typo'd name, or inconsistent indentation. Some you must fix; many are just nudges toward tidier, more consistent code your teammates will thank you for.

The name comes from 'lint' — the fuzz a clothes dryer traps. A linter picks the little fluff out of your code. Most editors run one as you type, so problems glow red the moment you make them.

A lockfile is an auto-generated record that pins down the exact version of every single piece of code your project installs — not just the libraries you asked for, but the libraries those libraries needed too. Its whole job is to make 'install' give the same result every time, on every machine.

Here's the gap it fills. In your manifest you usually say something loose like 'give me version 4-point-anything of lodash'. That's convenient, but it means two people installing on different days could quietly end up with slightly different code. The lockfile freezes the answer: it writes down that you actually got 4.17.21, this exact one, from this exact source.

You don't write a lockfile by hand — your package manager generates and updates it. You just need to commit it alongside your code. Then a teammate, or a build server, or future-you runs one install command and gets a byte-for-byte identical setup, instead of a vague 'should be close enough'.

A loop is code that repeats an action instead of making you write it out over and over. If you need to greet 100 people, you don't type 100 greetings — you write the greeting once and wrap it in a loop that runs it 100 times. It's the programmer's answer to 'do this again, and again, and again.'

Loops come in two everyday flavors. One walks through a collection, doing the same thing once for each item in a list — handy when you have an array and want to touch every element. The other keeps going while some condition stays true, and stops the instant it turns false; the condition is the loop's brake pedal.

The thing to watch for is forgetting to stop. If the condition never becomes false — or you never reach the end of the list — the loop runs forever, freezing your program. An 'infinite loop' is the classic beginner stumble, and the fix is always the same: make sure something inside the loop pushes it toward the exit.

To merge is to take the changes from one branch and weave them into another, so two separate lines of work become one. You did some work off on your own branch; merging is the moment you bring it home into main, and the project's history now includes both stories.

Most of the time git does this for you, quietly and correctly. It looks at what changed on each side and stitches the two sets of edits together — even when both branches touched the same file, as long as they touched different parts of it. You run one command and the two histories are joined.

When git can't be sure how to combine two edits — because both branches changed the very same lines — it stops and asks you to decide. That's a merge conflict, and it's not an error so much as git politely refusing to guess. You pick what's right, and the merge completes.

A merge conflict happens when two branches changed the very same lines of a file in different ways, and git can't tell which version you want. Rather than guess and risk picking wrong, it stops and hands the decision to you. It's not a failure — it's git being honest about a choice only a human can make.

Git marks the clash right inside the file with three lines you'll learn to recognise: <<<<<<< opens your side, ======= divides the two versions, and >>>>>>> closes the incoming side. Everything between the first marker and ======= is your branch's version; everything between ======= and the last marker is theirs.

Resolving it is calm work: open the file, decide what the final lines should actually say — keep yours, keep theirs, or blend the two — then delete all three marker lines so what's left reads like normal code. Save, stage the file, and finish the merge. The markers must be gone; if any remain, you haven't resolved it yet.

NoSQL is the umbrella name for databases that DON'T organize everything into the neat rows-and-columns tables that SQL relies on. Instead of forcing your data into a fixed grid up front, they let each record carry whatever shape it needs — which is handy when your data is messy, changes often, or just doesn't fit a spreadsheet.

It comes in a few flavors. Document stores (like MongoDB) keep each record as a flexible JSON-like blob. Key-value stores (like Redis) are a giant dictionary — hand it a key, get back a value, blazingly fast. There are also wide-column and graph databases for other shapes of problem.

The trade-off is real. By dropping rigid tables you gain flexibility and, often, easier scaling across many machines — but you give up some of the strict consistency and tidy relationships that relational databases hand you for free. The name is a bit misleading: read it as 'not only SQL', not 'no SQL allowed'.

OAuth is the standard behind every 'Log in with Google' or 'Continue with GitHub' button. Its whole point is letting one app use another without ever seeing your password. You're not handing the new app your Google login — you're asking Google to let it in on your behalf.

The everyday analogy is a hotel key card. Reception (Google) checks your ID once, then gives the app a card that opens just a few specific doors — say, your email address and name — and nothing else. The app never learns your master key, and you can cancel that card at any time without changing your real password.

What the app receives is an access token: a temporary, limited pass. That's the difference worth remembering — OAuth is about granting limited access, not about proving who you are. The password stays with you and the service you trust.

An object is a bundle of related values kept together under named keys. Where an array gives each value a number, an object gives each value a label — name, age, email — so you can describe one whole thing, like a person, in a single tidy package.

Think of it as a labeled drawer versus an array's numbered row. You don't fetch by position ('give me item 0'); you fetch by name ('give me the email'). That makes objects perfect for things with distinct, meaningful parts, where the labels matter more than any order.

Each name-value pair is called a property: the key is the label, the value is what's stored under it. Objects can hold any kind of value, including other objects and arrays, so you can nest them to model surprisingly rich structures. This key-value shape is also exactly what JSON uses to ship data between programs.

The operating system is the master program that runs the whole machine — Windows, macOS, and Linux are the ones you've heard of. It's the first thing that loads when you press the power button, and it stays in charge the entire time, managing the hardware and running every other program on top of itself. Without it, a computer is just a pile of silicon that doesn't know what to do.

Its main job is to be the middleman between your apps and the raw hardware. When your editor wants to save a file, it doesn't poke the disk directly — it asks the OS, and the OS handles the messy details. Same for showing a window, playing a sound, or reaching the network. This lets app makers write 'save this file' once instead of learning the quirks of a thousand different disks.

It's also the traffic cop. Dozens of programs want the CPU, the RAM, and the screen all at once, and the OS decides who gets what and when — slicing the CPU's time between them so fast that they all seem to run together. It keeps them from trampling each other's memory, too, so one crashing app doesn't take the whole machine down with it.

An ORM is a tool that lets you work with database rows as ordinary objects in your code, so you can read and save data without hand-writing SQL for every little thing. You call user.save() or User.find(1), and the ORM quietly translates that into the SELECT and INSERT statements the database actually wants.

Think of it as a bilingual go-between. Your code speaks in objects and methods; the database speaks in tables and SQL. The ORM sits in the middle, turning a row of columns into a tidy object you can poke at, and turning your changes back into SQL when it's time to save.

The appeal is less boilerplate and code that reads like your problem instead of like database plumbing. The catch is that the convenience can hide what's really happening — an innocent-looking loop might secretly fire hundreds of queries — so it pays to know the SQL underneath even when the ORM is writing it for you.

A package manager is a tool that installs and keeps track of the third-party libraries your project relies on. Think of it as an app store for code: you ask for a library by name, and it fetches that library — plus everything that library itself needs — and tucks it all into your project.

It also remembers your choices. A small list file records exactly which libraries and versions you asked for, so a teammate (or a server) can reproduce the very same setup with one command.

You'll meet a different one in each ecosystem: npm for JavaScript, pip for Python, cargo for Rust. Different names, same job — so you never have to hunt down and hand-copy someone else's code again.

A port is a numbered door on a computer where a service waits for visitors. One machine has one network address, but thousands of these numbered doors — so many different services can run side by side, each behind its own door, without bumping into each other.

Some numbers are conventions everyone agrees on: 80 is the door for plain web traffic, 443 is for secure https, and 3000 is the door your dev server often opens while you build something.

That's what localhost:3000 means: localhost is 'this very computer', and :3000 is the door to knock on. Open it in a browser and you're talking to the app you just started — no internet required.

A primary key is the column in a database table whose value uniquely identifies each row — the one stable handle by which you can always point at exactly one record. Like a student ID or an order number, it answers the question 'which exact row do you mean?' with no ambiguity.

Two rules make it special: it must be unique (no two rows can share the same value) and it can never be empty. The database itself enforces this, so you can't accidentally end up with two customers wearing ID 42. Often it's a plain auto-incrementing number the database hands out for you, one per new row.

Why bother? Because names and emails change, and people share them, but a primary key is the one thing you can rely on to mean the same row forever. It's also what other tables point at when they need to reference this row — the anchor a foreign key grabs onto.

A process is a program that's actually running right now — not the file sitting on your disk, but a live instance of it with its own slice of memory, its own to-do list, and its own ID number. Double-click an app and you've just started a process; quit it and the process ends.

Your computer is running hundreds at once: your browser, your editor, background helpers, the system itself. The operating system is the juggler here — it gives each process a turn on the CPU, keeps their memory walled off so one crashing program can't scribble over another, and cleans up when they finish.

The neat part: you can run the same program twice and get two separate processes that don't share anything. That's why you can have two browser windows behaving as if the other doesn't exist — they're two instances of one program, living quite independent lives.

A pull request — a 'PR' — is how you say 'here are my changes, can we add them to the project?' You've done work on your own branch, and a PR proposes folding those changes into the main one, so the team can look before anything is final.

It's really a conversation. Teammates review your changes line by line, leave comments, suggest tweaks, and you push fixes — all in one place. Nothing gets merged until someone gives it a thumbs-up. It's the polite knock before you walk into the shared codebase.

The name comes from the request to 'pull' your changes in. On GitHub and GitLab they look almost identical, though GitLab calls them 'merge requests' — same idea, different label.

A query is a single request you send to a database — to fetch some data, or to change it. It's one question or one instruction: 'show me all unpaid invoices', or 'mark order 42 as shipped'. The database does it and hands back the answer.

Most queries you write in SQL. A read query asks for rows back (SELECT … WHERE …); a write query adds, edits, or removes them. Either way, one query is one round-trip: you ask, the database answers, done.

Queries are also where speed lives or dies. A query that scans every row in a million-row table is slow; the same query, helped by an index, can feel instant. So when an app drags, the queries are often the first place to look.

A race condition is a bug where the outcome depends on which of two things finishes first — and since you can't control the timing, the result changes from run to run. It works nine times out of ten, then fails for no visible reason, which makes it one of the most maddening bugs to pin down.

Picture two people sharing one bank account, each withdrawing $100 at the very same instant. Both check the balance ($150), both see 'enough', both withdraw — and now the account is overdrawn. Neither did anything wrong alone; the trouble is that they 'raced' to act on the same number before either finished.

These bugs hide whenever two pieces of work run at the same time and touch the same thing — two threads, two requests, two clicks. The fix is to make sure only one can act at a time, or to design so the order genuinely doesn't matter. They're hard precisely because they often vanish the moment you slow things down to look.

RAM is your computer's fast, temporary workspace — the place where every program you have open right now keeps the stuff it's actively using. When you launch an app, open a file, or load a web page, it gets pulled off the slow disk and into RAM so the CPU can reach it almost instantly. Think of it as the desk you're working at: the bigger the desk, the more things you can spread out and juggle at once.

The catch is that RAM is forgetting by design. It only holds data while the power is on — turn the computer off (or it crashes) and everything in RAM vanishes. That's why unsaved work disappears: saving copies it from the fleeting desk to the disk, where it stays put. This is the difference between memory (RAM, fast but temporary) and storage (the disk, slower but permanent).

When you hear 'this laptop has 16 GB,' that number is the size of the desk. Run too many heavy programs at once and the desk fills up; the system starts shuffling things back to the slow disk to make room, and everything feels sluggish. More RAM mostly means you can keep more going at the same time without that slowdown.

To rebase is to pick up your branch's commits and replay them, one by one, on top of the latest version of another branch — as if you'd started your work just now instead of last week. The result is a clean, straight line of history with no 'merge' detours in it.

It solves a real annoyance. While you were building your feature, main moved on. A merge would join the two lines and leave a visible fork-and-rejoin in the history; a rebase instead rewrites your commits so they sit neatly on the new tip of main, as though the divergence never happened. Same final code, tidier story.

The one rule to tattoo on your arm: never rebase commits you've already shared. Rebasing rewrites history — it gives your commits brand-new IDs — so doing it to work others have pulled will tangle everyone's copies. Rebase your own private branch before sharing it; merge when the work is already public.

Recursion is when a function solves a problem by calling itself on a smaller piece of the very same problem. Instead of one big loop, it says 'handle a little bit, then hand the rest back to me' — over and over, each call chewing off a slightly smaller bite, until there's nothing left to do.

Think of standing in a long line and wanting to know your place. You can't see the front, so you tap the person ahead and ask 'what number are you?' They don't know either, so they ask the person in front of THEM, and so on — until someone at the very front says 'I'm number 1.' That answer flows back down the line, each person adding one, until it reaches you.

The part that keeps it from spinning forever is the base case: the simplest version of the problem that has an answer right away, with no further self-call. 'Person at the front is number 1' is the base case. Forget it, and the function calls itself endlessly and crashes — a 'stack overflow.' Every recursion needs a way to get smaller, and a place to stop.

To refactor is to improve the structure of code — make it clearer, simpler, easier to change — without changing what it actually does. Same inputs, same outputs; only the insides get tidier.

It's cleaning the kitchen, not changing the recipe. The dish that comes out tastes exactly the same, but now the knives are where you expect them, the counter is wiped, and the next person can cook without hunting for everything.

Good refactoring is small and continuous: rename a confusing variable, split one giant function into a few clear ones, delete code nobody uses. Because behavior shouldn't change, a solid set of tests is your safety net — if they still pass afterward, you know you didn't quietly break anything.

A regex is a tiny pattern language for describing what text you're looking for — then finding, matching, or replacing it in bulk. Instead of searching for one exact word, you describe its shape: "a digit, then more digits" or "anything that looks like an email".

It's wonderfully compact. The pattern \d+ means "one or more digits"; \w+ means "a word"; ^ anchors to the start of a line and $ to the end. A few symbols can replace a whole afternoon of manual find-and-replace.

It's also famously cryptic — a dense regex can look like a cat walked across the keyboard. The trick is to build it up a piece at a time and test as you go, rather than trying to read a long one all at once.

A repository — 'repo' for short — is your project's folder, but with git watching over it. Alongside your files, it quietly stores the project's entire history: every saved version, who changed what, and why.

A repo can live in two places at once. There's the copy on your own machine (the 'local' repo, where you actually work), and often a copy on a service like GitHub (the 'remote' repo, where the team shares and backs things up). You sync between them as you go.

Turning a plain folder into a repo is a one-time step: run git init, and from then on git tracks everything inside. That hidden .git folder it creates is where all the history lives — leave it alone and let git do its thing.

REST is a popular, tidy style for building web APIs — a set of habits, not a piece of software. The core idea is lovely and simple: treat everything your service offers as a 'resource' that lives at a URL, and use ordinary HTTP verbs to act on it. The URL says what; the verb says do what.

So /users/42 names one user, and the verb decides the action: GET to read them, POST to create one, PUT to update, DELETE to remove. Same address, different verb, different meaning. Once you see the pattern, a well-designed REST API feels like reading nouns and verbs in a sentence — guessable, even before you read the docs.

It's called RESTful when an API follows these conventions. REST isn't a law and people argue endlessly about the fine print, but its plainness is the whole point: no special protocol to learn, just the everyday HTTP the web already speaks.

A runtime is the engine that actually runs your code. Your source files are just text until something reads them and brings them to life — Node.js runs JavaScript on a server, the browser runs it on a page, and the JVM runs Java. The runtime is the stage your program performs on.

Knowing which runtime you're targeting matters: the same JavaScript can have different abilities in Node.js than in a browser, because each provides its own surroundings and built-in features.

'Runtime' also means a moment in time. Errors split into ones caught early — at 'compile time', before the program runs — and ones that only surface 'at runtime', while it's actually running and a bad value finally trips it up.

A schema is the blueprint of your data: it spells out what tables exist, what fields (columns) each one has, what type of value goes in each field, and the rules they must follow. It's the shape your data agrees to take before you store a single row.

Say you have a users table — the schema declares that every user has an id (a number), an email (text, and it must be unique), and a created_at (a date). Try to save a user with no email, or a price of 'banana' where a number belongs, and the database politely refuses. That guardrail is the schema doing its job.

A good schema is quietly powerful: it catches mistakes early and keeps your data trustworthy. Changing it later (a 'migration') is real work, so it's worth a little thought up front.

Semantic versioning is a shared convention for writing version numbers as three parts — MAJOR.MINOR.PATCH, like 2.4.1 — where each part promises something specific about what changed. The point is that the number itself tells you whether an update is safe to take or likely to break you.

Read it left to right. A bump in PATCH (2.4.1 → 2.4.2) means a backward-compatible bug fix: safe. A bump in MINOR (2.4.1 → 2.5.0) adds new features but doesn't break the old ones: still safe. A bump in MAJOR (2.4.1 → 3.0.0) is the loud one — it warns 'I removed or changed something; your code might need fixing'.

That's also what those little symbols in your manifest mean. A caret '^1.2.3' says 'newer 1.x is fine, but never jump to 2.0' — it trusts everything except a major bump. A tilde '~1.2.3' is stricter: 'only newer patches of 1.2, please'. They let you collect safe fixes automatically while staying clear of the changes that bite.

A shell is the program that reads the commands you type and runs them. When you open a terminal and see a blinking prompt, that prompt is the shell waiting for you to tell it what to do — list these files, copy that one, start this server.

It's called a shell because it's the outer layer wrapped around the operating system's core: you talk to the shell, and the shell asks the kernel to do the actual work. Common ones are bash and zsh (the default on modern Macs); they look almost identical and do the same job.

A shell is more than a command-runner — it's a little programming language. You can save a series of commands in a script, use variables and loops, and pipe one command's output straight into the next. That's where a lot of a developer's day-to-day power comes from.

SQL injection is a classic attack where a user types not just data but extra database commands, and the program runs them by mistake. It happens when code glues raw user input straight into a SQL query — so the input stops being a name and starts being an instruction.

Picture a form that asks for your username and builds a query around it. If you type a normal name, fine. But type something crafted like ' OR '1'='1 and the query's meaning quietly changes, perhaps letting you log in as anyone, dump the whole table, or delete it. The app trusted the input as plain text; the database read part of it as a command.

The fix is wonderfully simple and absolute: never paste raw input into a query. Use 'parameterized queries' (also called prepared statements), where you send the SQL and the values down separate channels. The values are then treated only as data — never as commands — and the trick simply stops working.

SQL is the language you use to ask a relational database questions — and to add, change, or remove data. Instead of writing loops to dig through files, you write one short sentence describing what you want, and the database figures out how to get it.

It reads almost like English: SELECT name FROM users WHERE age > 18 means 'give me the names of users older than 18'. The four verbs you'll lean on most are SELECT (read), INSERT (add), UPDATE (change), and DELETE (remove).

It's spoken two ways — spell it out, 'ESS-cue-ell', or say 'SEE-kwl' (people will know what you mean either way). Almost every relational database speaks SQL, so the skill carries from PostgreSQL to MySQL to SQLite with only small dialect differences.

SSH — Secure Shell — is the standard way to log into another computer over the network and run commands on it as if you were sitting right there. It's how you reach a server in a data center halfway around the world from your own laptop.

The 'secure' is the whole point: everything between you and the remote machine is encrypted, so nobody listening on the network can read your commands, your password, or the data coming back. The older tools it replaced sent everything in plain text — a genuinely bad idea.

Instead of typing a password every time, most people use a key pair: a private key that stays secret on your machine, and a public key you put on the server. The two match up to prove it's really you — quietly, in a fraction of a second, every time you connect.

Technical debt is the future cost of a quick-and-dirty solution you choose now to ship faster — a shortcut you'll have to pay back later by reworking it properly.

Like real debt, it can be a smart trade. Borrowing time to hit a deadline is fine, as long as you remember you borrowed it. The danger is the 'interest': every shortcut you leave in place makes the next change a little slower and a little riskier, and that interest compounds. Ignore it long enough and a one-day feature starts taking a week, because you keep tripping over the messes you left behind.

Not all debt is reckless — sometimes a hack is the right call to learn whether an idea even works. The grown-up move is to name it out loud ("this is temporary"), write it down, and budget time to pay it back before the interest eats you alive.

A token is a signed string the server gives you after you log in, which you then send along on every later request to prove who you are — without typing your password again. Think of it as the wristband you get at a festival entrance: flash it, and you're waved through.

It's signed, so the server can tell at a glance whether it's genuine or tampered with. A common kind is the JWT (JSON Web Token), which actually carries a little readable payload inside — your user id, maybe your role, and an expiry time — wrapped in that tamper-proof signature.

You usually send it in an HTTP header like 'Authorization: Bearer <token>'. Because it stands in for your password, treat it like one: never paste it into a public chat or commit it to a repo, and let it expire so a stolen one doesn't work forever.

A transaction groups several database changes into one all-or-nothing unit: either every step succeeds together, or none of them happen at all. It's the database's way of making sure you never get stuck halfway through something that should have been one indivisible act.

The classic example is moving money. Transferring $100 means subtracting from one account AND adding to another — two steps that must travel as a pair. Wrap them in a transaction and if the second step fails (or the power dies between them), the database rewinds the first too. The money is never left half-moved, vanished from one side but not arrived at the other.

In practice you BEGIN a transaction, make your changes, then COMMIT to lock them all in — or ROLLBACK to undo the whole batch if something went wrong. Until you commit, it's as if none of it happened yet, and other users don't see your half-finished work.

A unit test is a tiny piece of code whose only job is to check that one small piece of your real code does what it's supposed to. You feed it a known input, say what answer you expect, and the test shouts if reality disagrees. The 'unit' is the smallest sensible thing to test on its own — usually a single function.

Each one is dead simple: 'when I add 2 and 3, I expect 5'. On its own that feels almost too obvious to bother writing. The payoff comes from having hundreds of them and running the whole batch in seconds. Change one line of code, run the tests, and they instantly tell you whether you just quietly broke something three files away.

That's the real gift — a safety net. Without tests, every change is a small gamble: did this break anything? With them, you edit boldly, run the suite, and trust the green checkmarks. They're also living documentation: reading a test shows exactly how a piece of code is meant to be used.

A variable is a named box that holds a value. You give the box a label — like score or username — put something inside it, and later you can read what's there or swap it for something new. It's the most basic building block of almost every program.

The name is the whole point: instead of repeating a value all over your code, you store it once and refer to it by name. Change what's in the box in one place, and everywhere that reads it sees the new value.

Why 'variable'? Because the contents can vary — they change over time. score might start at 0, climb to 10, then reset. The label stays the same; what's inside is free to move.

A vulnerability is a flaw in software that an attacker can exploit to do something they shouldn't — read private data, take over an account, crash the system. It's an unlocked window in an otherwise solid house: harmless until someone notices it, dangerous the moment they do.

Vulnerabilities aren't usually put there on purpose; they slip in through honest mistakes — a missing check, an out-of-date library, an input nobody thought to clean. The whole security cycle is about finding them, reporting them quietly, and shipping a fix (a 'patch') before attackers find them first.

Big ones get a public ID — a CVE number — so the world can track them. The scary kind is a 'zero-day': a vulnerability attackers are already using before the maker even knows it exists, leaving zero days to prepare a defense.

A webhook is a reverse API: instead of you repeatedly asking a service 'anything new yet? anything new yet?', the service calls you the moment something happens. You hand it a URL of yours up front, and it promises to send a little message there whenever the event you care about occurs.

Picture the difference between standing at the mailbox opening it every five minutes versus just having the mail carrier ring your doorbell when a letter arrives. The first way (you asking over and over) is called polling, and it's wasteful — most of the time the answer is 'nope, nothing.' A webhook is the doorbell: the service does the calling, only when there's actually news, so you find out instantly and your code can sleep the rest of the time.

You see them everywhere once you know the shape. Stripe pings your URL when a payment succeeds; GitHub pings it when someone pushes code; a chat app pings it on every new message. You write a small endpoint that sits and waits, and the outside world knocks on it when it has something to tell you.

A WebSocket is a way to keep a live, two-way line open between the browser and the server, so messages can flow both directions the instant they happen. It's what powers chat apps, live scores, multiplayer games, and 'someone is typing…' — anything where the server needs to push news to you without being asked first.

To see why it matters, picture the normal way the web works: request and response, like sending letters. The browser mails a question, the server mails an answer, and then the line goes dead until the browser writes again. The server can't speak up on its own. If you wanted live updates that way, you'd have to keep nagging — 'anything new? anything new?' — over and over, which is slow and wasteful.

A WebSocket replaces the letters with a phone call that stays connected. After one quick setup (a 'handshake' that upgrades an ordinary connection), the line stays open and either side can talk whenever it likes — no re-asking, no delay. That open channel is the whole point: it makes the server able to tap you on the shoulder the moment something changes.