You've heard the word "cloud" everywhere. But most explanations pile on buzzwords until you give up. Let's start completely from scratch.

What does "the cloud" actually mean?

The cloud is just someone else's computer. Specifically, it's a massive network of powerful computers called servers, owned by companies like Amazon, Google, and Microsoft, housed in giant warehouses called data centers, and made available to anyone over the internet.

When you save a photo to iCloud, watch Netflix, or send a Gmail — your data isn't on your device. It lives on servers in one of these data centers. That's the cloud.

"The cloud is just someone else's computer" — and that's actually a feature, not a bug.

What did people use before cloud computing?

Before the cloud, companies had to buy physical servers, set them up in their own building, hire people to maintain them, and upgrade the hardware every few years. This was expensive, slow, and inflexible. Cloud computing changed everything — now you can rent exactly as much computing power as you need, spin it up in minutes, and shut it down when you're done.

The three types of cloud services

IaaS — Infrastructure as a Service

You rent the raw ingredients — virtual machines, storage, networking. AWS EC2 is an example. Best for developers who want full control.

PaaS — Platform as a Service

You get a kitchen with all the tools set up. You just write your app. Heroku is an example. Best for developers who want to focus on code, not servers.

SaaS — Software as a Service

Ready-made software delivered to you. Gmail, Slack, Zoom, Dropbox — you just open a browser and use it. No installation, no maintenance.

Real examples you already use

• Google Drive / iCloud — storing files in the cloud instead of your hard drive
• Netflix / Spotify — streaming media from cloud servers
• Gmail / Outlook — email stored and processed in the cloud
• Zoom / Teams — video calls routed through cloud infrastructure
• ChatGPT / Claude — AI models running on cloud hardware

Why do companies choose cloud computing?

• Cost savings — no upfront hardware purchases; pay only for what you use
• Speed — spin up servers in seconds instead of weeks
• Scale — handle traffic spikes automatically
• Reliability — cloud providers run backups and redundancy you'd never afford yourself
• Global reach — deploy your app worldwide with a few clicks

Every time a developer "SSHs into a server," they're opening a secure encrypted tunnel between their computer and a remote machine. If you work with cloud infrastructure at any point, you will use SSH constantly.

What does SSH stand for?

SSH stands for Secure Shell. The "shell" refers to a command-line interface — the text-based way of controlling a computer. The "secure" part means everything sent over the connection is encrypted. Before SSH, developers used Telnet, which sent everything including passwords in plain text. SSH was created in 1995 to fix that.

How to use SSH — the basic command

ssh username@server-ip-address

# Example connecting to an AWS server:
ssh ubuntu@54.210.123.45

# Connect using a key file (AWS / DigitalOcean style):
ssh -i ~/.ssh/my-key.pem ubuntu@54.210.123.45

SSH keys vs passwords

There are two ways to authenticate. Passwords are simpler but less secure. SSH keys are the professional standard.

# Generate a key pair
ssh-keygen -t ed25519 -C "your@email.com"
# Creates two files:
# ~/.ssh/id_ed25519       ← private key (NEVER share this)
# ~/.ssh/id_ed25519.pub   ← public key (put this on servers)

# Copy your public key to a server
ssh-copy-id ubuntu@54.210.123.45

# Now connect without a password
ssh ubuntu@54.210.123.45

Useful SSH tricks

# Run a command without starting an interactive session
ssh ubuntu@server "ls -la /var/www"

# Copy a file TO a remote server
scp myfile.txt ubuntu@server:/home/ubuntu/

# Copy a file FROM a remote server
scp ubuntu@server:/home/ubuntu/log.txt ./local-copy.txt

The SSH config file

If you SSH into the same servers regularly, add them to ~/.ssh/config:

Host myserver
  HostName 54.210.123.45
  User ubuntu
  IdentityFile ~/.ssh/my-key.pem

Now you just type ssh myserver and it fills in everything else.

Every time you save a file you're making a choice — even if you never thought about it. It goes to your hard drive (local) or to the internet (cloud). Here's how to think about which to use when.

Cloud vs local — side by side

Accessibility

Local: Only accessible on that device. If it's on your laptop at home, you can't get it from your phone at work.
Cloud: Accessible from any device with internet. Your files follow you everywhere.

Speed

Local: Very fast. Reading and writing happens at drive speed, no internet required. Great for large files and video editing.
Cloud: Limited by your internet speed. Uploading a 10GB video can take minutes or hours.

Cost

Local: One-time purchase. A 2TB external drive costs around $60 and lasts years.
Cloud: Ongoing subscription. Google One starts at $3/month for 200GB. Costs add up over time.

Backup and reliability

Local: No automatic backup. If your drive fails (and they all fail eventually), data is gone unless you backed it up.
Cloud: Built-in redundancy. Cloud providers store files in multiple locations. Your data survives hardware failures automatically.

The honest answer: use both

The classic backup rule is 3-2-1: three copies of your data, on two different media types, with one stored off-site. The cloud handles the off-site part perfectly. Use local for fast access and large files, cloud for backup and files you need everywhere.

S3 is everywhere. It powers uploads on apps you use every day, stores backups for thousands of companies, and hosts more websites than you'd guess. Let's understand it from scratch.

What is S3, actually?

Think of S3 like a hard drive that lives in Amazon's data centers instead of your laptop — one that never fills up, never breaks, and can be accessed from anywhere in the world.

S3 is like Google Drive for your apps — except instead of a human clicking upload, your code does it automatically.

What's a bucket?

S3 organizes everything into buckets. A bucket is a top-level container with a unique name across all of AWS globally. Each file inside is called an object, and it has a key (its path/name), data (the file contents), and metadata (info about the file).

How to use S3

# Upload a file
aws s3 cp photo.jpg s3://my-bucket/photos/photo.jpg

# Download a file
aws s3 cp s3://my-bucket/photos/photo.jpg ./photo.jpg

# List everything in a bucket
aws s3 ls s3://my-bucket/

# Sync a whole folder to S3
aws s3 sync ./dist s3://my-bucket/website/

What does it cost?

AWS gives you 5GB free for the first 12 months. After that: ~$0.023 per GB per month. Storing 100GB costs about $2.30/month. For most small projects, it's effectively free.

Common use cases

• User uploads — profile pictures, documents users upload to your app
• Static website hosting — serve HTML/CSS/JS directly from S3
• Database backups — automated database dumps stored safely
• Log storage — app logs that would fill up a server disk
• Media storage — images and videos served through a CDN

The thing that trips everyone up

By default, everything in S3 is private. If you upload a file and try to open the URL in your browser, you'll get "Access Denied." To share files publicly, use pre-signed URLs — temporary links that expire after a set time:

const { getSignedUrl } = require("@aws-sdk/s3-request-presigner");
const { GetObjectCommand } = require("@aws-sdk/client-s3");

const url = await getSignedUrl(
  client,
  new GetObjectCommand({ Bucket: "my-bucket", Key: "photo.jpg" }),
  { expiresIn: 900 } // expires in 15 minutes
);

Most Git tutorials start with history lessons and branching diagrams. You don't need that. You need the commands that cover real situations — with honest explanations of what each one actually does.

The commands you'll use every day

# Check what's going on — run this constantly
git status

# Stage changes for commit
git add .                    # everything
git add filename.js          # one file

# Save a snapshot
git commit -m "fix: handle null user in login"

# Send commits to GitHub
git push origin main

# Get latest changes from remote
git pull

When things get more interesting

# See your project history
git log --oneline

# Create and switch to a new branch
git checkout -b feature/dark-mode

# Shelve unfinished work temporarily
git stash
git stash pop               # get it back

# See exactly what changed
git diff
git diff --staged           # what's about to be committed

The panic commands

# Undo last commit, keep changes staged
git reset --soft HEAD~1

# Undo a commit that's already been pushed (safe)
git revert abc1234

# Discard changes to a file
git restore index.js

A workflow that actually works

git checkout main && git pull
git checkout -b fix/broken-search
# make your changes
git add . && git commit -m "fix: search returns correct results"
git push -u origin fix/broken-search
# open a pull request on GitHub

"It works on my machine." Docker was built specifically to kill this problem.

What is a container?

A container is a lightweight, isolated environment that packages your application with everything it needs to run. The key property: a container runs identically everywhere — on your Mac, on a Windows machine, on an Ubuntu server in AWS. Same behavior. Always.

A container is like a shipping container. It doesn't matter what ship it goes on — the contents arrive intact.

Images vs containers

• An image is a blueprint — a static snapshot of the environment your app needs. You build it once.
• A container is a running instance of an image. You can run many containers from one image.

A real Dockerfile

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Essential Docker commands

docker build -t my-app .        # build image
docker run -p 8080:3000 my-app  # run container
docker ps                       # see running containers
docker logs container-id        # view logs
docker exec -it container-id sh # shell inside container
docker stop container-id        # stop

Docker Compose — multiple containers together

version: '3.8'
services:
  app:
    build: .
    ports: ["3000:3000"]
    depends_on: [db]
  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
      POSTGRES_DB: myapp

Then: docker-compose up — everything starts together.

grep — find text inside files instantly

grep -r "API_KEY" .              # search all files
grep -rn "TODO" ./src           # show line numbers
grep -i "error" logs.txt        # case-insensitive
grep -rl "database" .           # filenames only

find — locate any file anywhere

find . -name "*.env"            # find all .env files
find . -mtime -1                # modified in last 24hrs
find . -name ".DS_Store" -delete # delete Mac clutter

tail -f — watch a log file live

tail -f /var/log/nginx/access.log
tail -n 100 -f app.log         # last 100 lines + follow

The pipe | — chain commands together

grep "ERROR" app.log | wc -l       # count errors
ps aux | grep "node"               # find a process
du -sh * | sort -rh | head -10     # biggest files

curl — make HTTP requests from terminal

curl https://api.example.com/users
curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name": "Alex"}'

Ctrl+R — search your command history

Press Ctrl+R and type a few characters — your shell fuzzy-searches your entire history and finds the command instantly. One of the most underused shortcuts in Linux.

The one alias that saves time every day

Add to ~/.bashrc or ~/.zshrc:

alias ll="ls -lah"

If you've ever rage-quit an app because you couldn't find the settings — that's bad UX design. If you've fallen in love with a product the first time you used it — that's great UX. Every button, color, and font choice you see? That's UI design.

What is UX design?

UX design covers the entire journey a person takes when using a product. UX designers ask: Can users figure out how to do what they came to do? How many steps does it take? Where do people get confused and give up? UX is less about aesthetics and more about logic, flow, and empathy.

What is UI design?

UI design is about the visual and interactive elements — everything you can see and tap on screen. UI designers decide: What color should the primary button be? How large should the headline be? What happens visually when you hover over a card? UI requires a strong visual eye — color theory, typography, spacing, and motion.

The architect vs interior designer analogy

Think of building a house. UX is the architect — they plan where the rooms go, how you move between them, how the space will be lived in. UI is the interior designer — they choose the colors, furniture, and finishes that make it beautiful.

You need both. A perfectly planned house that looks terrible isn't somewhere people want to live. A stunning house where every door opens into a wall isn't livable either.

What do these designers actually do day to day?

UX designers:

• User research — interviews and surveys to understand what people actually need
• Wireframing — rough sketches of screen layouts (no colors, no real design)
• Prototyping — clickable mockups that simulate how the real product works
• Usability testing — watching real people use the prototype and noting where they struggle

UI designers:

• Visual design — the look and feel of every screen
• Design systems — libraries of reusable buttons, cards, and forms that stay consistent
• Typography & color — choosing fonts and palettes that match the brand
• Animations — the small transitions that make an app feel alive

Figma changed design tools forever — it runs in your browser, costs nothing for personal use, and became the industry standard so fast that Adobe tried to buy it for $20 billion. Here's how to get started.

Step 1 — Create your free account

Go to figma.com and sign up with Google. The free plan gives you unlimited personal projects — more than enough to learn and build a portfolio. Once in, click "New design file".

Step 2 — Understand the interface

• Canvas — the infinite white space where you design
• Toolbar — across the top: selection, frame, shape, text, and pen tools
• Layers panel — left side: every element in a hierarchy
• Properties panel — right side: size, color, font, effects of selected element

Step 3 — Create a frame (your screen)

Press F → in the right panel click iPhone 14 (390×844) → a blank mobile screen appears on your canvas.

Step 4 — Add content

F  →  Frame tool (create screens)
R  →  Rectangle (draw shapes)
T  →  Text (add text)
V  →  Selection tool (move things)

Ctrl/Cmd + D      →  Duplicate
Shift + A         →  Add Auto Layout (magic resize)
Ctrl/Cmd + /      →  Quick search
Hold Space + drag →  Pan the canvas

Step 5 — Make it interactive

Switch from Design to Prototype mode (top right). Draw connections between frames. Press ▶ to preview your clickable prototype in the browser — tap through it like a real app.

Step 6 — Share it

Click Share → "Anyone with the link can view" → copy the link. Anyone can view and comment without a Figma account. This is how designers share work with clients and developers.

Good UX isn't magic or taste. It's built on decades of psychology research. Once you know these principles, you'll see them everywhere — and understand why some apps feel effortless while others feel like fighting.

1. Hick's Law — fewer choices, faster decisions

The more options you give people, the longer they take to decide. Too many choices causes paralysis.

Real example: Netflix doesn't show you 5,000 movies at once. They curate rows of 10-20 titles. If you saw everything, you'd spend an hour scrolling and watch nothing.

Apply it: Limit menus to 5-7 items. Break long forms into steps. Remove options most users never need.

2. Fitts's Law — big targets, close together

The time to click something depends on its size and how far away it is. Bigger and closer = faster.

Real example: The iPhone's primary action button is always large and at the bottom — exactly where your thumb rests. Destructive actions (delete) are smaller and higher up.

Apply it: Make tap targets at least 44×44px on mobile. Put primary actions in the thumb zone. Never make users tap a tiny X to close something important.

3. Jakob's Law — users expect what they already know

People spend most of their time on other apps. They expect yours to work the same way.

Real example: The hamburger menu ☰, the shopping cart icon, the search magnifying glass — break these conventions and users get confused.

Apply it: Before inventing a new UI pattern, ask if a familiar one works just as well. Innovation should solve real problems, not create new ones.

4. Miller's Law — seven plus or minus two

The average person can hold 7 (±2) items in working memory at once.

Real example: Phone numbers are formatted as 555-867-5309 not 5558675309 because groups of 3-4 digits are easier to remember than 10 in a row.

Apply it: Group related info into chunks. Never make users memorize something from a previous screen to use on the current one.

5. Law of Proximity — things close together belong together

Objects near each other are perceived as related. Objects far apart are seen as separate.

Real example: A form label "Email address" sits close to its input field — not the one above or below. The spacing makes the relationship clear without any connecting lines.

Apply it: Keep labels close to their inputs. Use whitespace to group related settings. Leave more space between separate cards than between elements inside a card.

6. The Peak-End Rule — people remember extremes

People judge an experience based on its most intense moment and its ending — not the average.

Real example: Duolingo ends every lesson with confetti and a celebration animation. That positive ending makes the whole experience feel rewarding even if some questions were hard.

Apply it: Put extra care into error states and the final step of any important flow. Make checkout confirmations feel like a win, not an afterthought.

7. Doherty Threshold — speed is a feature

Productivity soars when a system responds in under 400 milliseconds. Slower than that breaks user flow and increases abandonment.

Real example: Amazon found that every 100ms of extra page load time cost 1% in revenue. Slow is expensive.

Apply it: Use skeleton screens instead of spinners — they make loading feel faster. Avoid animations that add latency. If something takes time, show progress.