DEV Community: Mohamed Idris

I made a swing boat that reacts to doom scrolling

Mohamed Idris — Sat, 25 Apr 2026 15:53:48 +0000

When I was a kid, I tried the swing boat a few times and hated it. It made me dizzy. The kind of dizzy where you are not sure if it is fun anymore. You start slow, then someone keeps pushing, and before you know it you are too high and your stomach does not agree.

I got that same feeling recently, but from scrolling.

Doom scrolling is that thing you do when you open your phone for no reason and close it twenty minutes later having seen nothing worth remembering. Your finger goes up and down, up and down, the same motion as a swing. Your brain sits there getting rocked back and forth until it is numb. That is the brain rot part. Not dramatic, just slow and quiet. Your attention gets shorter. Your mood gets worse. You feel tired but you also cannot stop.

I kept thinking about how the finger movement looks exactly like a swing. Up and down, rhythm, momentum. The more you do it, the harder it is to stop. Same physics, different damage.

So I made a small thing to show that.

What it does

It is a red swing boat hanging in the dark. When you scroll, it swings. Keep scrolling and it goes higher. Stop, and it slowly dies down the way a real swing does. Short messages appear below the boat as the energy builds up. They start gentle. They do not stay that way.

How it works

The whole thing is a single HTML file with no dependencies. The boat is an inline SVG so CSS and JavaScript can interact with it directly. The swing uses real pendulum physics, gravity and damping included, so it coasts and rocks naturally after you stop. Scroll speed feeds into the angular velocity, which means the harder you scroll the higher the swing goes.

The scroll itself is captured with a wheel event and preventDefault, so the page never actually scrolls. There is nothing to read. Just the boat.

Try it

Demo: github.com/edriso/doomswing

My bot stopped sending questions the day Egypt turned on Daylight Saving Time

Mohamed Idris — Sat, 25 Apr 2026 08:16:24 +0000

I built a Telegram bot that sends math questions to kids every day at 2:30 PM Egypt time. It had been live for two weeks, running every single day without a problem, questions going out on time, kids answering, streaks building up. Then recently I ran /admin_health in the bot and saw 0 scheduled questions. That's when I knew something was wrong and went digging through the logs.

The last successful run was April 23. That night, Egypt turned on Daylight Saving Time.

Let me walk you through how the whole thing worked, what broke, and how I fixed it.

How the bot schedules questions

The bot has two main daily jobs:

01:30 AM Cairo: prepare today's questions for every user (pick 3 questions based on each kid's weak topics, save them to the database)
2:30 PM Cairo: send the first question to everyone

I use a library called node-cron for scheduling. It supports timezones, so I just tell it "run this at 00:30 Cairo time" and it figures out the UTC equivalent automatically.

cron.schedule('30 0 * * *', async () => {
  await prepareScheduledQuestions();
}, { timezone: 'Africa/Cairo' });

How "Cairo time" works in the code

The bot server runs on Railway (cloud), so it lives in UTC. Every time I need to know "what day is it in Cairo?", I use this function:

function todayCairoAsUtcMidnight(): Date {
  // Get today's date as a string in Cairo timezone, e.g. "2026-04-23"
  const dateStr = new Intl.DateTimeFormat('en-CA', {
    timeZone: 'Africa/Cairo',
    year: 'numeric',
    month: '2-digit',
    day: '2-digit',
  }).format(new Date());

  // Return that date as UTC midnight so we can compare with database values
  return new Date(dateStr + 'T00:00:00.000Z');
}

So "today in Cairo" becomes a fixed timestamp I can store in the database and compare against later. A question prepared at 01:30 AM Cairo gets tagged with 2026-04-23T00:00:00.000Z. When the 2:30 PM cron runs, it looks up questions tagged with that same date. If they match, the question gets sent.

This works great as long as Cairo is always UTC+2.

What is Daylight Saving Time?

DST is when a country moves its clocks forward by 1 hour in summer to make better use of daylight. Egypt reinstated DST in 2023 after not using it for about 10 years.

In Egypt:

Last Friday of April at midnight → clocks jump from 00:00 to 01:00 (spring forward)
Last Thursday of October at midnight → clocks go back from 01:00 to 00:00 (fall back)

The key phrase is "clocks jump from 00:00 to 01:00". That means 00:30 literally does not exist on that night.

The bug

My prepare-questions cron was set to run at 00:30 Cairo time.

On April 24, 2026 (the DST transition day), at midnight Cairo, clocks skipped forward one hour. The time went from 00:00 directly to 01:00. There was no 00:30.

node-cron saw that 00:30 didn't exist that night and silently skipped the job. No error, no warning, nothing in the logs. But it gets worse. After that skip, node-cron's internal scheduler got into a broken state. It was not just the prepare job that stopped. Every single cron job stopped firing. The 2:30 PM send job never ran on April 24. Or April 25. The bot process was alive on Railway, no crashes, no restarts, just complete silence for two days.

Here are the actual logs. Everything stops on April 23:

[2026-04-22T22:30:00.006Z] [INFO] [CRON] Preparing daily questions...
[2026-04-22T22:30:31.408Z] [INFO] Prepared adaptive questions for 9 users
[2026-04-23T12:30:00.025Z] [INFO] [CRON] Sending first question...
[2026-04-23T12:30:25.042Z] [INFO] First question sent {"sent":8,"failed":1,"total":9}
[2026-04-23T17:30:00.016Z] [INFO] [CRON] Sending reminders...
[2026-04-23T17:30:05.120Z] [INFO] Reminders sent {"sent":8,"total":9}

(silence after this)

Notice 22:30 UTC = 00:30 Cairo (UTC+2), and that was the last time questions were prepared. After that, the clocks changed and 00:30 disappeared.

Why there were no errors

This is the sneaky part. node-cron doesn't throw an error when a scheduled time is skipped due to DST. And when the scheduler breaks internally, it also does not throw an error. The bot process just keeps running, healthy from Railway's point of view, with zero indication that all the scheduled work stopped.

No crash to investigate. No alert to wake you up. Just kids not getting their questions.

Fix 1: Move the cron to a safe time

The simplest fix: change 00:30 to 01:30.

Egypt's clocks spring from 00:00 to 01:00, so 01:30 always exists, even on DST transition day. Problem solved.

// Before (broken on DST spring-forward day):
cron.schedule('30 0 * * *', handler, { timezone: 'Africa/Cairo' });

// After (safe):
cron.schedule('30 1 * * *', handler, { timezone: 'Africa/Cairo' });

One more thing: on the fall-back day in October, clocks go from 01:00 back to 00:00, so 01:30 actually happens twice that night. That means the job runs twice. But that is totally fine, because at the start of prepareScheduledQuestions() there is a check: if a user already has questions prepared for today, skip them. So the second run just finds everyone already done and exits. No duplicates, no problems.

Fix 2: Add a fallback inside the send job

The cron time fix handles DST. But what if the prepare job fails for any other reason, like a server hiccup, a deploy at the wrong time, whatever?

I added one line at the top of the send-questions job:

export async function sendFirstQuestion(bot) {
  // If questions weren't prepared for any reason, prepare them now before sending
  await prepareScheduledQuestions();

  // ... rest of the send logic
}

prepareScheduledQuestions() already skips users who have questions today, so calling it here costs nothing on a normal day. But on a broken day, it saves everyone from getting nothing.

The lesson

If your cron jobs use a timezone that observes DST, avoid scheduling at times that get skipped during the spring-forward transition. In Egypt that means avoid 00:01 through 00:59. Use 01:30 or later to be safe.

More generally: cron + timezones is a place where things can go silently wrong. The job doesn't crash, there's no alert, users just don't hear from your app. Always add a fallback or at least an explicit log when your main jobs find zero work to do. That's usually a sign something upstream failed.

if (prepared === 0) {
  logger.warn('No questions prepared, double check the prepare-questions job ran today');
}

That one log line would have caught this immediately.

The bot is now fixed and sending questions again. And next April, when Egypt springs forward, it'll handle it quietly.

A question:

Someone may ask: what if you really wanted the job to always run at exactly 00:30 Cairo, no matter what happens to the clock?

Short answer: you can't. Not on spring-forward night.

00:30 Cairo on that night does not exist. The clock jumps from 00:00 directly to 01:00. There is no UTC value that maps to 00:30 Cairo on that specific night. It was erased. No library, no trick, no workaround can schedule something at a time that literally never happens.

The closest you can get is one of two things.

First option is what we already did: move to 01:30. It always exists, even on the transition night. On 364 days a year it runs at 01:30 Cairo. On that one spring-forward night it also runs at 01:30 Cairo, which is just one hour later than you wanted. Not a big deal.

Second option is to schedule at two UTC times, one for winter and one for summer. Winter Cairo is UTC+2, so 00:30 Cairo = 22:30 UTC. Summer Cairo is UTC+3, so 00:30 Cairo = 21:30 UTC. You run both. Since the prepare function skips users who already have questions today, only one of the two actually does any work on a normal night. On the transition night, 22:30 UTC lands at 01:30 Cairo so you again get one hour late, but questions are still prepared. This gets you 00:30 on all regular nights in both seasons.

But honestly the real safety net is the fallback we added inside the send job. Even if the prepare cron runs late, or gets skipped, or breaks entirely, questions get prepared right before they are sent at 2:30 PM. That is what actually protects users, not the exact minute the prepare job fires.

Stop arguing about formatting in code reviews. Use Husky and lint-staged instead.

Mohamed Idris — Fri, 24 Apr 2026 19:52:09 +0000

If your team has ever left a comment like "missing semicolon" or "wrong quote style" on a pull request, this post is for you.

Formatting is not a code review topic. It should be handled automatically before the code even reaches a PR. Here is how to do that cleanly using Husky and lint-staged.

What are we actually solving?

The problem is simple: developers format code differently, editors have different defaults, and without enforcement, you end up with inconsistent style that creates noisy diffs and unnecessary review comments.

The goal is to auto-format and auto-lint staged files right before every commit, so bad formatting never reaches the repo.

Two tools make this easy:

Prettier handles formatting (spacing, quotes, semicolons, line length)
ESLint handles code quality (unused variables, missing dependencies, bad patterns)
Husky lets you run scripts automatically on git events like pre-commit
lint-staged runs those scripts only on staged files, not your entire codebase

Running tools on the full project on every commit would be slow. lint-staged keeps it fast by scoping to only what you changed.

Step 1: Install the tools

npm install --save-dev husky lint-staged

If you do not already have Prettier and ESLint set up:

npm install --save-dev prettier eslint eslint-config-prettier eslint-plugin-prettier

eslint-config-prettier disables ESLint rules that conflict with Prettier. eslint-plugin-prettier makes ESLint report Prettier violations as lint errors. Without these two, ESLint and Prettier will fight each other.

Step 2: Initialize Husky

npx husky init

This creates a .husky/ folder and adds a prepare script to your package.json:

"scripts": {
  "prepare": "husky"
}

The prepare script runs automatically on npm install. That means anyone who clones your repo and installs dependencies gets the pre-commit hook set up without doing anything manually. This is the key to making it work across a team.

Step 3: Set up the pre-commit hook

Open .husky/pre-commit and replace whatever is in it with:

npx lint-staged

That is all. Every time you run git commit, Husky will run lint-staged before the commit goes through.

Step 4: Configure lint-staged

Add this to your package.json:

"lint-staged": {
  "src/**/*.{js,jsx,ts,tsx}": "eslint --fix",
  "src/**/*.{css,json,md}": "prettier --write"
}

This says: on staged JS and JSX files inside src/, run ESLint with auto-fix. On staged CSS, JSON, and Markdown files, run Prettier.

Why split them? Because eslint-plugin-prettier already runs Prettier internally when you run eslint --fix on JS files, so you do not need to run both. For CSS and other file types, Prettier handles it directly since ESLint does not cover them.

If you are working on a plain HTML or CSS project without ESLint, simplify to just:

"lint-staged": {
  "**/*.{html,css,js,json,md}": "prettier --write"
}

Step 5: Add a .prettierignore file

Create .prettierignore in your project root:

dist/
node_modules/

This prevents Prettier from formatting compiled or generated output. Without this, it might reformat your minified CSS or bundled JS, which is not what you want.

How it works in practice

You make changes to a few files, stage them with git add, and run git commit. Husky fires the pre-commit hook. lint-staged checks which staged files match your patterns and runs the tools only on those. If ESLint finds an error it cannot auto-fix, the commit is blocked and you see the error. If everything passes, the commit goes through with clean, formatted code.

The first time you set this up, you will probably want to run a full format pass on the whole project so everything starts from a clean state:

npx prettier --write "src/**/*.{js,jsx,css,json}"

Commit that as a single formatting commit, then the pre-commit hook keeps things clean going forward.

VS Code integration (the finishing touch)

The pre-commit hook is your safety net. But you can also make formatting happen as you type by adding a .vscode/settings.json to your project:

{
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "always"
  },
  "eslint.validate": ["javascript", "javascriptreact"],
  "files.autoSave": "off"
}

With this, every time you hit save, VS Code runs Prettier and ESLint automatically. By the time you stage your files, they are already formatted. The Husky hook just confirms nothing slipped through.

Commit this file to the repo so the whole team gets the same editor behavior without any manual setup.

The result

No more formatting comments in code reviews
Clean diffs that show only real changes
Commits that are always consistent, regardless of who made them
New team members get the full setup just by running npm install

It takes about ten minutes to set up and saves hours of back-and-forth over style issues. Worth it.

Resume Update!

Mohamed Idris — Thu, 23 Apr 2026 16:01:33 +0000

A while back I shared that I built my resume as a website so I can update it in one place without re-uploading files or changing links everywhere.

Now that I'm looking for a new job, I ran into a new problem; I wanted to tailor my resume depending on the role I'm applying to. Sending the same resume to a Magento recruiter and a frontend recruiter doesn't really make sense.

So I fixed that by adding a query param to the resume URL:

edriso.github.io?r=fullstack
edriso.github.io?r=frontend
edriso.github.io?r=php
edriso.github.io?r=magento

Each one shows a different version; different title, different bio, different skills order 😃.

And it saves to localStorage, so if the recruiter refreshes the page or comes back later without the param, they still see the right version.

Same thing on my portfolio site. The resume link in the footer automatically includes the right role param based on which version of the portfolio the recruiter is viewing.

One link per recruiter. No confusion.

Alhamdulillah 🙌

How to Undo a Git Commit Without Losing History

Mohamed Idris — Thu, 23 Apr 2026 13:43:41 +0000

We've all been there — you made a commit, pushed it, and then realized: that was a mistake.

The good news? Git has a safe way to undo it without rewriting history.

The Problem

You might think of using git reset to go back in time. But if you've already pushed the commit to a shared branch, resetting and force-pushing can cause problems for everyone else on the team.

The Better Way: `git revert`

git revert creates a new commit that undoes the changes from a previous commit. Your history stays intact — you just add an undo step on top.

How to Do It

Step 1: Find the commit you want to undo

git log --oneline

You'll see something like:

a8636a4 Tailor portfolio for e-commerce role
d56677a Fix hover effect
5315182 Add new project

Copy the hash of the commit you want to revert (e.g. a8636a4).

Step 2: Revert it

git revert a8636a4 --no-edit

a8636a4 — the commit hash you want to undo
--no-edit — skips the editor and uses the default revert message

Git will create a new commit like:

bf880c5 Revert "Tailor portfolio for e-commerce role"

That's it. Your mistake is undone and your history is clean.

When to Use `git revert` vs `git reset`

	`git revert`	`git reset`
Creates a new commit	Yes	No
Safe for shared branches	Yes	No
Rewrites history	No	Yes

Rule of thumb: If the commit is already pushed, use git revert. If it's only local, git reset is fine.

Summary

# See your commits
git log --oneline

# Revert the one you don't want
git revert <commit-hash> --no-edit

Simple, safe, and no drama. That's the Git way.

The 3-Second Rule: How to Write a Freelance Proposal That Gets Read (and Gets Replies)

Mohamed Idris — Wed, 22 Apr 2026 17:27:58 +0000

A friend told you to use "a 3-second role point" in your proposal. Good advice. But what does that actually mean?

This post breaks it down in plain English — with real examples, clear comparisons, and things you can use today on Upwork, Freelancer, Toptal, or any similar platform.

Why "3 Seconds" at All?

When a client posts a job on Upwork, they might get 20, 50, or even 100 proposals. They are not reading every word. They are scanning.

Studies and freelance coaches consistently say the same thing: a client decides in the first 3 to 8 seconds whether your proposal is worth reading — or worth skipping.

Those first few seconds happen at the very first line of your proposal. That is where you either win their attention or lose it forever.

This is the "3-second rule": your opening must be so relevant, so specific, and so interesting that the client stops scrolling and reads the rest.

The Biggest Mistake Freelancers Make

Before we get to the good stuff, let us look at what most people write.

A typical (losing) proposal opening:

"Hello, my name is Ahmed and I am a full-stack developer with 5 years of experience. I have worked with React, Node.js, MongoDB, and more. I am very passionate about coding and I believe I am the perfect candidate for this job..."

Sound familiar? This is what 80% of proposals look like.

The client does not care about your name in the first sentence. They do not care about your years of experience yet. They care about their problem.

You spent the first 3 seconds talking about yourself. They moved on.

The 3-Second Rule Point: Make It About Them First

Your opening line — your "3-second point" — should do one thing: show the client that you actually read their job post and you understand their specific problem.

Not a general problem. Their specific, stated problem.

Here is the formula for that opening line:

[Specific observation about their project] + [How you can help with that specific thing]

That is it. One or two sentences. Sharp and relevant.

Good vs Bad: Side by Side

Let us look at a real job post and compare proposals.

Job Post:

"I need a developer to fix my WooCommerce checkout page. Customers are abandoning at the payment step — I think it is a PayPal integration bug. My site is slow too. Budget: $200."

Bad proposal opening:

"Hi, I am a WordPress and WooCommerce expert with 6 years of experience. I can help you with your website. I am very hardworking and deliver on time. Please check my profile."

What is wrong here?

It is generic. This could be sent to any WooCommerce job.
It does not mention the PayPal bug.
It does not mention the checkout abandonment problem.
It does not mention the slow site.
The client feels like you did not read their post at all.

Good proposal opening:

"Checkout abandonment at the PayPal step is almost always a redirect loop or a mismatched IPN URL — I have fixed this exact issue three times this month. I can also audit your page speed in the same session since slow checkout pages make abandonment worse."

What is different here?

It names the exact problem: checkout abandonment.
It names the exact tool: PayPal.
It shows specific knowledge: "redirect loop or mismatched IPN URL" — this is credible.
It connects the two problems they mentioned (PayPal bug + slow site) in one sentence.
The client thinks: "This person actually read what I wrote."

That is 3 seconds well spent.

The Full Proposal Structure (After the Hook)

The 3-second opening is just the beginning. Here is the full structure that converts attention into replies:

1. The Hook (Seconds 1-3)

Your one or two sentence opener. Specific, relevant, and about them.

2. The Bridge (Your Relevant Experience)

Now — and only now — you talk about yourself. But keep it tied to their problem.

"I have been building WooCommerce sites for 4 years, and payment gateway bugs are one of the most common things I fix. Here is a similar case: a client's Stripe checkout was silently failing and costing them $3,000/month. I found it in under an hour."

Notice: one data point, one number, tied directly to their situation.

3. The Plan (What You Will Do)

Tell them how you will solve it. Not in vague words — in concrete steps.

"Here is my plan:

Reproduce the checkout error and check the PayPal IPN logs (1-2 hours)

Fix the integration and test on staging (1-2 hours)

Run a quick speed audit using GTmetrix and apply the top 3 fixes (1 hour)

Full test before handover"

This builds trust. It shows you have a process, not just "I will figure it out."

4. The Proof (Why Trust You)

A portfolio link, a relevant result, or a short testimonial quote. Keep it to one thing — do not list 10 projects.

"Here is a WooCommerce project where I fixed a similar Stripe issue: [link]"

5. The Call to Action (CTA)

End with a clear, low-pressure next step. Do not just say "let me know."

"Happy to jump on a 15-minute call to look at the issue together — no cost, just to confirm I can help before you commit. Or if you prefer, send me a test account and I can start today."

Full Example: Putting It All Together

Here is a complete proposal for the WooCommerce job above (under 200 words):

Checkout abandonment at the PayPal step is almost always a redirect loop or a mismatched IPN URL — I have fixed this exact issue three times this month.

I have been building WooCommerce stores for 4 years. Last month I helped a client in a similar situation: their PayPal checkout was silently failing for mobile users only, and they had no idea. I found it in the PayPal sandbox logs in about an hour.

My plan for your project:
1. Reproduce the error and check your PayPal IPN and webhook settings
2. Fix the bug and test on staging
3. Run a GTmetrix speed audit and apply the top fixes
4. Deliver with a short Loom video explaining what I found and fixed

Portfolio: [link to similar WooCommerce project]

I am available to start today. Want to do a quick 10-minute call so I can see the error myself before we start? Or just send me a staging login and I will take a look.

Clean. Specific. Confident. Under 200 words.

More Hook Examples You Can Adapt

Here are 5 quick openers for different situations. Notice each one names a specific detail from a hypothetical job post.

For a React performance job:

"A 4-second load time on the dashboard is almost always a missing memo or a useEffect firing too often — both are straightforward to diagnose with React DevTools."

For a landing page redesign:

"If your current page is converting at under 2%, the problem is usually the headline or the CTA placement — the design is secondary. I would start there before touching anything visual."

For a Node.js API bug:

"A race condition on concurrent requests is one of the trickier Node bugs because it does not always reproduce in dev. I would start with your async/await error handling and check if you have any unhandled promise rejections in production logs."

For a WordPress migration:

"Moving 1,200 posts from Wix to WordPress without losing SEO rankings is totally doable if you set up 301 redirects correctly from day one — I have done three migrations like this in the last two months."

For a Python scraping job:

"If the site blocks you after 50 requests, it is almost certainly rate-limiting by IP. Rotating proxies plus random delays between requests fixes this 90% of the time."

The Things That Kill Good Proposals

Even with a great hook, these common mistakes will lose you the job:

Too long. If your proposal is over 300 words, most clients will not finish reading it. Say less, say it better.

Copy-paste feel. Clients can tell when you sent the same proposal 50 times. Even one tiny detail from their post makes it feel personal.

No proof. Saying "I am an expert" means nothing. One relevant link, one number, one past result — that means something.

Weak ending. "Looking forward to your response" is not a CTA. Give them something to do: a question to answer, a call to book, a next step to take.

Starting with "I." The very first word of your proposal should never be "I." It signals immediately that you are about to talk about yourself.

Quick Checklist Before You Send

Before hitting send on any proposal, run through this list:

[ ] Does my first sentence name something specific from their job post?
[ ] Did I avoid starting with my name or years of experience?
[ ] Did I explain what I will do, not just that I can do it?
[ ] Did I include one concrete result or proof point?
[ ] Did I end with a clear, specific next step?
[ ] Is it under 250 words?
[ ] Does it sound like a human wrote it, not a template?

If all boxes are checked, send it.

TL;DR

The "3-second rule point" your friend mentioned is simply this: your first sentence must prove you read the job post and understand the client's actual problem — before you say a single word about yourself.

Structure your proposal like this:

Hook — one specific, relevant sentence about their problem
Bridge — your experience, tied to their situation
Plan — concrete steps, not vague promises
Proof — one link or result
CTA — a simple, clear next step

Most freelancers write about themselves. You write about the client. That is the difference.

What is the hardest part of writing proposals for you? Drop a comment — I read every one.

Sources:

If You Were a Server: How to Detect Issues and Keep Things Running Smoothly

Mohamed Idris — Wed, 22 Apr 2026 17:26:15 +0000

Here is a question that often pops up in senior web developer and backend interviews:

"If you were a server, how would you detect that you're having issues, and what would you do next to make things run smoothly?"

At first, it sounds a little weird. Be a server? But that is actually the whole point. The interviewer wants to know if you can think like infrastructure — can you see problems before they become disasters, and do you know how to respond?

This post breaks it all down in simple English. Whether you are a junior developer hearing these concepts for the first time, or someone preparing for a senior interview, you will walk away with a solid mental model.

First: What Is the Question Really Asking?

The question is covering two things:

Detection — How does a server (or you, the developer/SRE watching it) know something is wrong?
Response — What actions do you take to fix it or at least keep things stable?

Think of it like being a doctor for your own body. You check your temperature, blood pressure, and pulse. If something is off, you take medicine, rest, or call a specialist. Servers work the same way.

Part 1: How Does a Server Detect It Has Issues?

The Four Core Vitals

Just like a doctor checks your basic vitals, a server has its own set of core health signals. These are the first things to look at.

1. CPU Usage

CPU (Central Processing Unit) is the brain of your server. It handles every calculation, request, and operation.

Healthy: Under 60-70% usage during normal load.
Warning: Consistently above 80%.
Critical: Sustained 90%+ means your server is struggling to breathe.

When CPU is maxed out, your server starts slowing down responses, queuing requests, or dropping them entirely.

How to check it: top, htop, vmstat, or any cloud monitoring dashboard like AWS CloudWatch or Datadog.

2. Memory (RAM) Usage

Memory is your server's short-term workspace. Every running process uses RAM.

Healthy: Enough free RAM to handle spikes.
Warning: When RAM fills up, your OS starts using swap — which is disk space acting as fake RAM. Disk is much slower than RAM.
Critical: If swap fills up too, processes start crashing.

A common mistake is ignoring memory leaks — situations where an application keeps grabbing more memory and never releasing it. Over time, this silently kills your server.

3. Disk Usage and I/O

Disk usage is how much of your storage is full. Disk I/O is how fast data is being read and written.

Best practice: Keep at least 20-30% disk space free at all times.
A full disk can crash your database, stop logging, and break deployments.
High disk I/O (lots of reads/writes happening at once) can make everything slow, even if CPU and RAM look fine.

4. Network Bandwidth

Your server talks to the outside world through the network. If the pipe gets clogged:

Requests take longer to arrive and respond.
Large file uploads or downloads can saturate the connection.
You may see packet loss — data literally gets dropped mid-transfer.

Beyond the Core Vitals: Application-Level Signals

The four core vitals tell you about the hardware. But you also need to watch what your application is doing.

5. Response Time / Latency

How long does your server take to respond to a request?

A healthy API might respond in 100ms.
If latency jumps to 2-3 seconds, something is wrong — maybe a slow database query, a blocked thread, or an overloaded service.

Why it matters: Users notice latency before they notice anything else. A slow page feels broken.

6. Error Rate

What percentage of your requests are returning errors?

5xx errors (500, 502, 503, 504) mean your server is the problem.
If your error rate goes from 0.1% to 5%, something just broke.
Spikes in 4xx errors (404, 403) can also signal broken deployments or misconfigured routes.

7. Throughput / Request Rate

How many requests per second is your server handling?

A sudden drop in traffic can be as alarming as a spike — it might mean your server is down and clients are not even reaching it.
A sudden spike might mean a traffic surge, a bot attack, or a viral moment — all of which need different responses.

Health Checks: The Server Checking Itself

Modern servers do not wait for humans to notice something is wrong. They self-report through health check endpoints.

There are two main types used in systems like Kubernetes:

Liveness Probe

"Am I still alive?"

This is a simple check: is the process running at all? If a liveness probe fails, the orchestrator (like Kubernetes) will restart the container.

Example endpoint: GET /health/live → returns 200 OK if running.

Readiness Probe

"Am I ready to receive traffic?"

This is more nuanced: is the server running and fully ready to handle requests? Maybe it is warming up a cache, waiting for a database connection, or doing startup migrations.

If a readiness probe fails, the load balancer stops sending traffic to that instance — without killing it. Once it recovers, traffic resumes.

Example endpoint: GET /health/ready → checks DB connection, cache, etc.

Logging: The Server's Diary

Logs are your best friend when something goes wrong. A server should write meaningful logs that tell a story.

Structured logging means logging in a consistent format (usually JSON) so machines can read it:

{
  "timestamp": "2026-04-22T10:30:00Z",
  "level": "error",
  "message": "Database connection failed",
  "service": "api",
  "request_id": "abc-123",
  "duration_ms": 5000
}

Without good logs, debugging is like trying to solve a crime with no evidence. With good logs, you can trace exactly what happened, when, and why.

Log levels to know:

DEBUG — detailed developer info (not for production usually)
INFO — normal operations ("User logged in")
WARN — something is off but not broken yet
ERROR — something broke, needs attention
FATAL / CRITICAL — the server cannot continue

Alerting: Getting Notified Before It's Too Late

Monitoring without alerting is useless. You cannot stare at dashboards 24/7.

Set up alerts with smart thresholds:

Metric	Warning Threshold	Critical Threshold
CPU Usage	> 80% for 5 min	> 90% for 2 min
Memory Usage	> 85%	> 95%
Disk Space	< 25% free	< 10% free
Error Rate	> 1%	> 5%
Response Time	> 500ms avg	> 2s avg

Do not alert on every small blip. Use time windows (e.g., "CPU > 80% for 5 consecutive minutes") to avoid alert fatigue — a flood of noisy alerts that people start ignoring.

Tools: PagerDuty, OpsGenie, Slack alerts, AWS CloudWatch Alarms, Grafana Alerts.

Part 2: What Do You Do Next to Keep Things Running Smoothly?

You detected the problem. Now what? Here are the key strategies — from automatic to manual.

1. Auto-Scaling: Get More Help

If your server is overloaded, the simplest answer is: add more servers.

Auto-scaling is when your infrastructure automatically spins up new server instances when load is high, and shuts them down when load drops.

Normal traffic:   [Server 1]
Traffic spike:    [Server 1] [Server 2] [Server 3]
Traffic drops:    [Server 1]

This works with a load balancer sitting in front — it distributes incoming requests across all available instances so no single server gets crushed.

Horizontal scaling = more instances (this is what auto-scaling does).
Vertical scaling = bigger instance (more CPU/RAM on the same machine). Harder to do automatically.

Cloud providers (AWS, GCP, Azure) all have auto-scaling built in.

2. Circuit Breaker: Stop the Bleeding

Imagine your server calls another service (a payment API, a database, a third-party service). That service is slow or down. Your server keeps waiting... and waiting... and all your threads are now stuck waiting for something that will never respond. Your whole server grinds to a halt because of someone else's problem.

The Circuit Breaker pattern prevents this.

It works in three states:

CLOSED (Normal)
  → Requests pass through
  → Failures are counted

OPEN (Problem detected)
  → Requests immediately fail fast
  → No waiting, no timeout
  → Returns an error or fallback instantly

HALF-OPEN (Testing recovery)
  → A few test requests get through
  → If they succeed → back to CLOSED
  → If they fail → back to OPEN

It is called a circuit breaker because it works exactly like the electrical circuit breaker in your house — when something goes wrong, it cuts the connection to stop further damage.

Libraries: opossum (Node.js), resilience4j (Java), polly (.NET).

3. Graceful Degradation: Do Less, Not Nothing

When part of your system is broken, the goal is to keep the core experience working, even if some features are temporarily unavailable.

Real-world examples:

YouTube goes down? Show the homepage with a "video unavailable" message instead of crashing entirely.
Recommendation engine fails? Show generic popular content instead of personalized picks.
Payment service is slow? Disable the "buy now" button and show a "try again shortly" message instead of hanging the page.

This is better than an error page that says "500 Internal Server Error" with nothing else.

The key idea: degrade gracefully, fail loudly only when you have no other choice.

4. Caching: Avoid Repeating Work

Many server problems come from doing the same expensive work over and over. Caching stores the result of expensive operations so you can reuse them.

Without cache:
User → Server → Database (100ms) → User

With cache:
User → Server → Cache (1ms) → User  (if cached)
User → Server → Database (100ms) → Cache → User  (if not cached)

Types of caching:

In-memory cache: Redis, Memcached — extremely fast.
HTTP caching: Cache-Control headers tell browsers and CDNs to store responses.
Database query caching: Cache frequently run queries.

When your server is struggling, a well-configured cache can reduce database load by 80% or more.

5. Rate Limiting: Control Incoming Traffic

If traffic spikes and you cannot scale fast enough, you need to protect yourself by limiting how many requests any single client can make.

Example: Allow 100 requests per minute per IP. After that, return 429 Too Many Requests.

This protects against:

Accidental infinite loops in client code
DDoS (Distributed Denial of Service) attacks
Scrapers hammering your API

It is not just about bad actors — rate limiting is also good for your own internal services to prevent one slow consumer from starving everyone else.

6. Retry with Exponential Backoff: Be Patient, Not Aggressive

Sometimes a service is temporarily down and recovers in seconds. Clients should retry — but smart retries, not aggressive ones.

Bad retry:

Fail → Retry immediately → Fail → Retry immediately → Fail...
(This makes the overloaded server worse)

Good retry with exponential backoff:

Fail → Wait 1s → Retry
Fail → Wait 2s → Retry
Fail → Wait 4s → Retry
Fail → Wait 8s → Retry (give up after X attempts)

Each retry waits twice as long as the last. Add a bit of random delay (called jitter) so thousands of clients do not all retry at the exact same moment, which would cause another spike.

7. Rollbacks: Undo What Broke It

Sometimes the issue is a bad deployment. The fastest fix is often to roll back to the previous working version.

Blue-green deployment and canary releases are strategies to reduce this risk:

Blue-Green: You have two identical environments (blue = live, green = new). Deploy to green, test it, then switch traffic. If something breaks, switch back to blue instantly.
Canary Release: Roll out the new version to 5% of users first. If metrics look good, increase to 20%, then 50%, then 100%. If something breaks, only 5% of users were affected.

These patterns let you catch problems early without taking down everything.

8. Runbooks: The Human Response Plan

All the automation in the world cannot cover every scenario. You need a runbook — a documented set of steps that a human follows when a specific alert fires.

A good runbook answers:

What does this alert mean?
How urgent is it?
What are the first three things to check?
How do I escalate if I cannot fix it?
What commands should I run?

Example runbook entry:

Alert: High Memory Usage (> 90% for 10 minutes)

1. SSH into the affected server
2. Run: `ps aux --sort=-%mem | head -20` to find the top memory consumers
3. Check for memory leaks in the app logs: `grep "OutOfMemory" /var/log/app.log`
4. If a rogue process is found: restart the service
5. If memory does not recover: trigger a scale-out event
6. Escalate to on-call engineer if unresolved after 15 minutes

A runbook turns a stressful incident into a checklist. It is boring when things are calm and invaluable at 3am during an outage.

Putting It All Together: The Full Answer Framework

If an interviewer asks you this question, here is the structure of a great answer:

Detection (Observability):

I would monitor core metrics: CPU, memory, disk, network
I would track application metrics: latency, error rate, throughput
I would have health check endpoints (liveness and readiness)
I would use structured logging for traceability
I would set up smart alerts with meaningful thresholds

Response (Resilience):

Auto-scaling to handle load spikes
Circuit breakers to prevent cascading failures from downstream services
Graceful degradation to keep core features working
Caching to reduce repeated expensive work
Rate limiting to protect against traffic floods
Retry with exponential backoff for transient failures
Rollback strategies (blue-green, canary) for bad deployments
Runbooks so on-call engineers know exactly what to do

Real-World Tools Worth Knowing

Category	Popular Tools
Metrics & Dashboards	Grafana, Datadog, Prometheus, AWS CloudWatch
Logging	ELK Stack (Elasticsearch, Logstash, Kibana), Loki, Splunk
Alerting	PagerDuty, OpsGenie, Grafana Alerts
APM (App Performance)	Datadog APM, New Relic, Sentry
Uptime Monitoring	UptimeRobot, Pingdom, Checkly
Circuit Breakers	Resilience4j, Opossum (Node.js), Polly (.NET)
Caching	Redis, Memcached, Varnish
Load Balancing / Scaling	AWS ALB + Auto Scaling, Kubernetes HPA, NGINX

TL;DR

The interview question is asking you to think like a system that observes itself and heals itself.

Detect with metrics (CPU, memory, disk, network), application signals (latency, error rate), health checks, and structured logging.
Respond with auto-scaling, circuit breakers, graceful degradation, caching, rate limiting, smart retries, rollbacks, and runbooks.

The best systems do not just survive failures — they are designed to expect them and handle them without waking anyone up at 3am.

Found this useful? Drop a comment with the trickiest server question you have faced in an interview — I would love to hear it.

Sources:

How to Remove a File from Git History (And What to Watch Out For)

Mohamed Idris — Wed, 22 Apr 2026 15:10:32 +0000

It happens to everyone. You commit a file you shouldn't have — maybe a .env with API keys, a huge binary, or just something private — and then you push it.

The bad news: deleting the file and committing again doesn't actually remove it from git history. Anyone can still go back and see it.

The good news: you can rewrite history to remove it completely. Here's how.

Why deleting the file isn't enough

Git keeps a full snapshot of every commit. Even after you delete a file, it still lives in older commits. Someone can always run git log -- filename or check out an old commit to get it back.

To truly remove it, you need to rewrite every commit that ever touched that file.

Step 1 — Make sure the file is deleted locally

If the file still exists on disk, delete it first. Then stage the deletion:

git rm the-file.txt
git commit -m "Remove the-file.txt"

Or if you already deleted it manually:

git add -A
git commit -m "Remove the-file.txt"

Step 2 — Rewrite git history

This is the actual scrubbing step. Run this command (replace the-file.txt with your file path):

FILTER_BRANCH_SQUELCH_WARNING=1 git filter-branch --force \
  --index-filter "git rm --cached --ignore-unmatch the-file.txt" \
  --prune-empty \
  --tag-name-filter cat \
  -- --all

What each flag does:

--index-filter — runs a command on every commit's index (faster than checking out files)
git rm --cached --ignore-unmatch — removes the file from the index, silently skips commits that don't have it
--prune-empty — removes any commits that become empty after the file is gone
--tag-name-filter cat — rewrites tags to point to the new commits
-- --all — applies to all branches and refs

Note: Git will warn you about filter-branch being error-prone and recommend git-filter-repo instead. If you can install it (pip install git-filter-repo), it's faster and safer. The equivalent command is just:
git filter-repo --path the-file.txt --invert-paths

Step 3 — Clean up local dangling objects

After rewriting, old commits still hang around in your local reflog. Clean them up:

git reflog expire --expire=now --all
git gc --prune=now --aggressive

Step 4 — Force push

This is the step that overwrites the remote history:

git push origin main --force

Cautions — read before you do this

This is a destructive, irreversible operation. Once you force push rewritten history, the old commits are gone from the remote. Here's what that means in practice:

If others have cloned the repo

Anyone who cloned or pulled before your rewrite will have the old history. They'll need to re-clone or do a hard reset:

git fetch origin
git reset --hard origin/main

Their local branches with the old history will conflict with the new remote. Coordinate with your team before doing this.

The secret may already be compromised

If you pushed API keys or credentials, assume they are already leaked. Bots scan GitHub in real time. Rewriting history is cleanup — but your first step should be revoking and rotating the credentials immediately, before anything else.

It doesn't work on forks

If someone forked your repo before the rewrite, they still have the old history. You can't rewrite their copy.

GitHub/GitLab may cache the old commits

GitHub keeps cached views of old commits for a short time even after a force push. You can contact GitHub support to purge the cache, but for leaked secrets, rotate first — don't wait.

Quick recap

Step	Command
Delete the file	`git rm the-file.txt`
Rewrite history	`git filter-branch ...` or `git filter-repo`
Clean up local objects	`git reflog expire` + `git gc`
Force push	`git push origin main --force`

Best practices to avoid this in the first place

Add sensitive files to .gitignore before you create them
Use a .env.example file with dummy values instead of committing real secrets
Tools like git-secrets or gitleaks can scan commits before they're pushed and block accidental leaks

Rewriting history is a useful escape hatch — but the best commit to regret is the one you never made.

JavaScript Promises — Understand what a Promise actually is, how .then() chaining works under the hood, and how async/await connects to all of it

Mohamed Idris — Wed, 22 Apr 2026 15:03:52 +0000

One question that comes up a lot when learning JavaScript async code is this: when you return a value inside .then(), does it get wrapped in Promise.resolve(value) automatically? And if you throw something, does it become Promise.reject(error)?

Short answer: yes, exactly right.

It's one of those things that sounds small but really clicks everything into place once you get it. Let me break it all down.

What even is a Promise?

Before ES6 (back when callbacks ruled everything), async code looked like this:

getUserFromDB(userId, function(err, user) {
  if (err) {
    handleError(err);
    return;
  }
  getPostsByUser(user.id, function(err, posts) {
    if (err) {
      handleError(err);
      return;
    }
    // imagine this going 5 levels deep...
  });
});

This is called callback hell — and it's as bad as it sounds.

A Promise is a cleaner way to handle async operations. Think of it like ordering food at a restaurant. You place your order (start the async operation), and instead of standing at the kitchen window waiting, the waiter gives you a number (the Promise). You go sit down and do other things. When the food is ready, they call your number.

A Promise is in one of three states:

Pending — still waiting (the kitchen is still cooking)
Fulfilled — success, you have a value (food arrived)
Rejected — something went wrong (they're out of your order)

The `.then()` chaining trick

Here's the interesting part. When you chain .then() calls, each .then() returns a new Promise. And what that Promise resolves or rejects with depends on what happens inside the callback.

The rules are simple:

What you do inside `.then()`	What the next Promise gets
`return someValue`	Wraps it: `Promise.resolve(someValue)`
`return anotherPromise`	Waits for that promise and uses its result
`throw new Error(...)`	Wraps it: `Promise.reject(error)`

fetchUser(1)
  .then(user => {
    return user.name; // becomes Promise.resolve("John")
  })
  .then(name => {
    console.log(name); // "John"
    throw new Error("Oops!"); // becomes Promise.reject(Error("Oops!"))
  })
  .then(() => {
    console.log("This won't run");
  })
  .catch(err => {
    console.log(err.message); // "Oops!"
  });

This chaining is powerful because you avoid nesting — each .then() hands off to the next one cleanly.

async/await is just Promises in disguise

async/await isn't a different system — it's syntax sugar on top of Promises. The same rules apply.

async function getUser() {
  return "John"; // same as: return Promise.resolve("John")
}

async function fail() {
  throw new Error("Something broke"); // same as: return Promise.reject(...)
}

And await just pauses execution until the Promise settles:

async function main() {
  try {
    const user = await fetchUser(1); // waits for Promise to resolve
    console.log(user.name);
  } catch (err) {
    console.log("Error:", err.message); // catches rejections
  }
}

The try/catch with await is equivalent to .then().catch() — same idea, cleaner look.

Real use case: Fetching data from an API

Here's a practical example — fetching a GitHub user's profile and then their repos:

// With .then() chaining
function getGithubInfo(username) {
  fetch(`https://api.github.com/users/${username}`)
    .then(response => response.json())           // parse JSON (returns a Promise)
    .then(user => {
      console.log("User:", user.name);
      return fetch(`https://api.github.com/users/${username}/repos`);
    })
    .then(response => response.json())
    .then(repos => {
      console.log("Repos:", repos.length);
    })
    .catch(err => {
      console.error("Something went wrong:", err.message);
    });
}

// Same thing with async/await — cleaner!
async function getGithubInfo(username) {
  try {
    const userResponse = await fetch(`https://api.github.com/users/${username}`);
    const user = await userResponse.json();
    console.log("User:", user.name);

    const reposResponse = await fetch(`https://api.github.com/users/${username}/repos`);
    const repos = await reposResponse.json();
    console.log("Repos:", repos.length);
  } catch (err) {
    console.error("Something went wrong:", err.message);
  }
}

Both do the same thing. Most people prefer async/await because it reads like regular synchronous code.

Quick summary

A Promise represents a future value from an async operation
.then() always returns a new Promise — whatever you return becomes Promise.resolve(...), whatever you throw becomes Promise.reject(...)
async/await is built on top of Promises — they are the same thing underneath
Use .catch() or try/catch to handle errors

If Promises still feel fuzzy, that's okay. The best way to solidify this is to build something — try fetching data from a public API, chain a few .then() calls, and break things on purpose to see what happens.

You'll get it. It just takes repetition.

Keep asking questions — they help everyone learn.

Dim Other Cards on Hover with Pure CSS

Mohamed Idris — Mon, 20 Apr 2026 15:40:11 +0000

You've probably seen this effect before — you hover over one card, and all the other cards fade out a little, making the hovered one stand out.

Before hover:             While hovering card B:

┌──────┐ ┌──────┐ ┌──────┐     ┌──────┐ ┌──────┐ ┌──────┐
│  A   │ │  B   │ │  C   │     │  A   │ │  B   │ │  C   │
└──────┘ └──────┘ └──────┘     └──────┘ └──────┘ └──────┘
 100%     100%     100%          dim      bright    dim

It's clean, it draws attention to the right place, and it takes about 5 lines of CSS.

The HTML

Nothing special here — a wrapper div and some cards inside it.

<div class="cards">
  <div class="card">Card A</div>
  <div class="card">Card B</div>
  <div class="card">Card C</div>
</div>

The CSS

.cards:has(.card:hover) .card:not(:hover) {
  opacity: 0.5;
}

That's it. Let's break it down:

.cards:has(.card:hover) — targets the wrapper when any card inside it is being hovered
.card:not(:hover) — selects all cards except the one being hovered
opacity: 0.5 — dims them

So in plain English: "If something inside .cards is hovered, dim every .card that isn't the hovered one."

Add a smooth transition

The snap between full and dimmed opacity can feel abrupt. Add a transition to the cards:

.card {
  transition: opacity 0.3s ease;
}

.cards:has(.card:hover) .card:not(:hover) {
  opacity: 0.5;
}

Now it fades in and out smoothly.

Works across columns too

This approach works even when your cards are split across multiple columns (like a masonry layout), because the selector targets by class anywhere inside the wrapper — not just direct children.

<div class="cards">
  <div class="column">
    <div class="card">Card A</div>
    <div class="card">Card C</div>
  </div>
  <div class="column">
    <div class="card">Card B</div>
    <div class="card">Card D</div>
  </div>
</div>

The same CSS still works — hover card A, and B, C, D all dim regardless of which column they're in.

Browser support

The :has() selector is supported in all modern browsers. Just keep in mind it doesn't work in Firefox versions before 121 or older browsers, so add a graceful fallback if you need wide coverage (e.g. just skip the effect entirely for those browsers — it's purely visual).

Simple, no JavaScript, no extra libraries. Just CSS doing what it's good at.

I Built a Web App to Burn Bad Memories and Grow From Them

Mohamed Idris — Thu, 09 Apr 2026 20:15:00 +0000

We all carry memories that weigh us down. Things we said, things we didn't say, moments we wish went differently.

I built a small web app called Grow & Let Go — a quiet space to write down a painful memory, find the lesson in it, and let it go.

You write it. You watch it burn. You see your lesson grow.

What happens when you submit

The burning isn't just a simple fade-out. There's a canvas-based fire particle system with embers rising, smoke drifting, and ash scattering. The card chars and crumbles as it burns.

And when the fire clears, a plant sprouts from the ground — the stem draws upward, leaves unfurl, a flower blooms. Fireflies appear. The whole mood shifts from warmth to calm.

How I built it

HTML, CSS, vanilla JS — no frameworks
anime.js for orchestrating animation timelines
Canvas API for the fire particle system with additive blending
SVG stroke animation for the plant growth (stroke-dashoffset drawing the stem upward)
CSS mix-blend-mode and blur for smoke effects
Ambient floating particles and fireflies for atmosphere

The whole thing runs in the browser. No backend, no accounts, no data stored anywhere.

Try it

🌱 Live App
💻 Source Code

And if that memory was a mistake toward someone still in your life, and you never apologized... here's another app for that:

💌 I Forgot to Say Sorry

🧠 The Backend Developer Fundamentals Guide

Mohamed Idris — Wed, 08 Apr 2026 11:22:54 +0000

Understand the engine before you drive the car.

This guide teaches you the concepts behind every framework. Learn this once, and Spring, Node, Laravel, Django — they'll all just be different flavors of the same thing.

How The Internet Actually Works
Request & Response — The Heart of Everything
What a Server Actually Does
How Data Flows Through a System
Memory, Threads & Processes
Databases — Where Data Lives
APIs — How Systems Talk to Each Other
Authentication & Authorization
Caching — Making Things Fast
Security Basics
Architecture Patterns
Networking Essentials
Linux & The Command Line
Version Control (Git)
Testing
DevOps Basics
The Learning Order (Roadmap)

1. How The Internet Actually Works

Before you write a single line of backend code, you need to understand how the internet works. It's simpler than you think.

DNS — The Phone Book of the Internet

When you type google.com in your browser, your computer doesn't know what that means. Computers only understand numbers (IP addresses like 142.250.80.46). So your computer asks a DNS server (Domain Name System): "Hey, what's the IP address for google.com?"

Think of it like this: you know your friend's name, but you need their phone number to call them. DNS is the contact list.

The flow:
You type google.com → Your computer asks DNS → DNS says "that's 142.250.80.46" → Your computer connects to that IP address.

TCP/IP — The Delivery System

Once your computer knows the IP address, it needs to send and receive data. That's where TCP/IP comes in.

IP (Internet Protocol): This is like the address on a package. It tells data where to go.
TCP (Transmission Control Protocol): This makes sure the data arrives completely and in order. It's like a delivery service that makes you sign for the package — it confirms everything arrived.

Why this matters for backend: Every single thing your server does involves TCP/IP. When a user opens your app, their phone creates a TCP connection to your server. Understanding this helps you debug network issues later.

Ports — Doors Into Your Server

Your server is like a building, and ports are the doors. Different services use different doors:

Port 80 → Regular web traffic (HTTP)
Port 443 → Secure web traffic (HTTPS)
Port 5432 → PostgreSQL database
Port 3306 → MySQL database
Port 27017 → MongoDB

When someone visits your website, they're knocking on port 80 or 443 of your server.

HTTP/HTTPS — The Language of the Web

HTTP (HyperText Transfer Protocol) is the language browsers and servers speak. HTTPS is the same thing but encrypted (the "S" stands for Secure).

Every time you load a webpage, your browser sends an HTTP request, and the server sends back an HTTP response. That's literally all web development is at its core — requests and responses.

2. Request & Response — The Heart of Everything

This is the single most important concept in backend development. Everything else is built on top of this.

What is a Request?

A request is a message from a client (browser, mobile app, another server) asking your server to do something. Every request has:

Method (Verb): What action do you want?
- GET → "Give me some data" (like loading a page)
- POST → "Here's some new data, save it" (like submitting a form)
- PUT → "Update this existing data completely"
- PATCH → "Update just part of this data"
- DELETE → "Remove this data"
URL (Path): What resource do you want?
- /users → the users resource
- /users/42 → user number 42 specifically
- /users/42/orders → orders belonging to user 42
Headers: Extra info about the request (like metadata)
- Content-Type: application/json → "I'm sending JSON data"
- Authorization: Bearer abc123 → "Here's my login token"
- Accept: application/json → "Please respond with JSON"
Body: The actual data (only for POST, PUT, PATCH)

  {
    "name": "Ahmed",
    "email": "ahmed@example.com"
  }

What is a Response?

The response is your server's answer. Every response has:

Status Code: A number that tells the client what happened
- 200 → "OK, here's what you asked for"
- 201 → "Created — I made the new thing you wanted"
- 400 → "Bad Request — you sent me something wrong"
- 401 → "Unauthorized — who are you? Log in first"
- 403 → "Forbidden — I know who you are, but you can't do this"
- 404 → "Not Found — that thing doesn't exist"
- 500 → "Internal Server Error — I broke, it's my fault"
Headers: Extra info about the response
Body: The actual data being sent back

  {
    "id": 42,
    "name": "Ahmed",
    "email": "ahmed@example.com"
  }

The Full Picture

User clicks "Sign Up" button
        ↓
Browser sends POST request to /api/users
  with body: { name: "Ahmed", email: "ahmed@example.com", password: "..." }
        ↓
Server receives the request
        ↓
Server validates the data (is the email real? is the password strong enough?)
        ↓
Server hashes the password (never store plain passwords!)
        ↓
Server saves the user to the database
        ↓
Server sends back a response: 201 Created
  with body: { id: 42, name: "Ahmed", message: "Account created!" }
        ↓
Browser shows "Welcome, Ahmed!"

This flow is identical in every framework. Express, Spring, Django, Laravel — they all do this exact thing. The only difference is the syntax.

3. What a Server Actually Does

A server is just a computer that's always on, always connected to the internet, and always listening for requests.

The Server's Job, Step by Step

Listen — The server sits and waits on a specific port (usually 80 or 443), doing nothing until someone sends a request.
Receive — A request arrives. The server reads the method, URL, headers, and body.
Route — The server figures out which piece of code should handle this request. "Oh, they want GET /users/42? Let me call the getUserById function."
Process — The actual business logic happens here: validate data, talk to the database, calculate things, call other services.
Respond — The server builds a response with a status code and data, then sends it back.
Go back to step 1 — The server goes back to listening for the next request.

Middleware — The Assembly Line

In most frameworks, before your request reaches the actual handler, it passes through a chain of middleware. Think of it like a factory assembly line:

Request arrives
    ↓
[Logging Middleware] — "Let me record that this request happened"
    ↓
[Auth Middleware] — "Let me check if this user is logged in"
    ↓
[Validation Middleware] — "Let me check if the data is correct"
    ↓
[Your Actual Handler] — "OK, now I'll do the real work"
    ↓
Response goes back

Every framework has middleware. Express calls it middleware. Django calls it middleware. Spring calls it filters/interceptors. Laravel calls it middleware. Same concept, different names.

4. How Data Flows Through a System

When you build a real app, data moves through multiple layers. Understanding this flow is what separates someone who just copies code from someone who actually understands what's happening.

The Typical Layers

CLIENT (Browser/App)
    ↕ HTTP Request/Response
CONTROLLER / ROUTE HANDLER
    → Receives the request, extracts data from it
    → Calls the right service
    ↕
SERVICE / BUSINESS LOGIC
    → The "brain" — decides what to do
    → Applies rules: "Users under 18 can't buy this"
    → Coordinates between different pieces
    ↕
REPOSITORY / DATA ACCESS
    → Talks to the database
    → Translates between your code's objects and database rows
    ↕
DATABASE
    → Stores data permanently

Why Layers Matter

Imagine you're building a food delivery app. A user places an order:

Controller receives: POST /orders with { restaurantId: 5, items: [...] }
Service checks: Is the restaurant open? Does the user have enough balance? Is there a driver available?
Repository saves the order to the database, updates the user's balance, notifies the restaurant
Response goes back: 201 Created with the order details

If you dump all of this into one file, it becomes an unreadable mess. Layers keep things organized and reusable. Every professional codebase uses layers, regardless of the framework.

5. Memory, Threads & Processes

This is where most tutorials skip and where most junior devs get confused. But it's essential.

Memory — Your Program's Workspace

When your server starts, the operating system gives it a chunk of RAM (memory). Think of RAM like a desk — it's where your program puts things it's currently working with.

Stack Memory: Fast, organized, automatic. Used for simple variables and function calls. When a function finishes, its stack memory is automatically cleaned up.
Heap Memory: Bigger, messier, manual (or garbage-collected). Used for objects, arrays, and anything complex. Stays around until your code (or the garbage collector) removes it.

Why this matters: If your server creates tons of objects and never cleans them up, you get a memory leak. Your server slowly uses more and more RAM until it crashes. This is a real-world problem you'll face.

Processes — Independent Workers

A process is a running program. When you start your server, that's one process. Each process gets its own memory — processes don't share memory with each other.

If your server crashes, the process dies. That's why in production we use tools that automatically restart crashed processes.

Threads — Workers Inside a Worker

A thread is like a worker inside a process. One process can have multiple threads, and they all share the same memory.

Think of a restaurant:

The process is the restaurant itself
The threads are the waiters
The memory is the kitchen and the order board

Multiple waiters (threads) can serve different tables (requests) at the same time, and they all share the same kitchen (memory).

Blocking vs Non-Blocking

This is a critical concept:

Blocking: When your code does something slow (like reading a file or querying a database) and the thread just sits and waits. Nothing else can happen on that thread until it's done. Like a waiter standing at the kitchen window waiting for one dish instead of taking other orders.
Non-Blocking (Async): The thread says "I'll come back for this later" and goes to handle other requests. When the slow operation finishes, it picks up where it left off. Like a waiter who takes another table's order while the kitchen cooks.

Node.js is single-threaded but non-blocking (one waiter who never stops moving). Java/Spring is multi-threaded (multiple waiters, each can wait). Both approaches work; they have different tradeoffs.

Concurrency vs Parallelism

Concurrency: Handling multiple tasks by switching between them quickly (one CPU core, many tasks). Like one person cooking three dishes by switching between them.
Parallelism: Actually doing multiple tasks at the exact same time (multiple CPU cores). Like three people each cooking one dish.

You don't need to master this immediately, but keep it in mind — as your app grows, these concepts will determine if your server can handle 100 users or 100,000.

6. Databases — Where Data Lives

Memory is temporary — when your server restarts, everything in RAM is gone. Databases store data permanently (on disk).

Relational Databases (SQL)

These store data in tables (like spreadsheets). Examples: PostgreSQL, MySQL, SQLite.

USERS TABLE:
| id | name   | email              | created_at |
|----|--------|--------------------|------------|
| 1  | Ahmed  | ahmed@example.com  | 2025-01-15 |
| 2  | Sara   | sara@example.com   | 2025-02-20 |

ORDERS TABLE:
| id | user_id | product     | amount |
|----|---------|-------------|--------|
| 1  | 1       | Laptop      | 999    |
| 2  | 1       | Mouse       | 25     |
| 3  | 2       | Keyboard    | 75     |

The user_id in ORDERS relates to the id in USERS. That's why they're called "relational." You can ask: "Give me all orders for user Ahmed" by joining the tables.

SQL (Structured Query Language) is how you talk to these databases:

-- Get all users
SELECT * FROM users;

-- Get a specific user
SELECT * FROM users WHERE id = 1;

-- Add a new user
INSERT INTO users (name, email) VALUES ('Ali', 'ali@example.com');

-- Update a user
UPDATE users SET name = 'Ahmed Ali' WHERE id = 1;

-- Delete a user
DELETE FROM users WHERE id = 1;

-- Get all orders for a user (JOIN)
SELECT users.name, orders.product, orders.amount
FROM users
JOIN orders ON users.id = orders.user_id
WHERE users.id = 1;

Learn SQL. It's not optional. Every backend framework uses SQL under the hood, even when they hide it behind an ORM.

Key SQL Concepts You Must Know

Primary Key: The unique ID for each row (usually id).
Foreign Key: A column that references another table's primary key (like user_id).
Index: A shortcut that makes searching faster. Like a book's index — instead of reading every page, you jump straight to the right one.
Transactions: A way to group multiple operations. Either ALL of them succeed, or NONE of them do. Think of transferring money: subtract from account A AND add to account B. You can't do just one.
Normalization: Organizing data to avoid repetition. Instead of writing "Ahmed, ahmed@email.com" on every order, you just reference user_id = 1.
Migrations: Version control for your database structure. When you need to add a new column, you write a migration file. This way, everyone on the team can update their database.

NoSQL Databases

These don't use tables. Instead, they use different structures:

Document DBs (MongoDB): Store data as JSON-like documents. Good for flexible or nested data.

  {
    "_id": "abc123",
    "name": "Ahmed",
    "email": "ahmed@example.com",
    "orders": [
      { "product": "Laptop", "amount": 999 },
      { "product": "Mouse", "amount": 25 }
    ]
  }

Key-Value (Redis): Super simple. A key and a value. Blazing fast. Used for caching.

  "session:user42" → "{ loggedIn: true, name: 'Ahmed' }"

When to use what? Start with PostgreSQL. It handles 95% of use cases. Use Redis for caching. Use MongoDB only if your data truly doesn't fit into tables. Don't overcomplicate your first projects.

7. APIs — How Systems Talk to Each Other

An API (Application Programming Interface) is a set of rules that lets different software talk to each other. Your backend's main job is to expose an API that frontends (or other services) can use.

REST — The Most Common API Style

REST isn't a technology — it's a set of conventions for designing APIs using HTTP:

Action	Method	URL	What it does
List all users	GET	/api/users	Returns an array of users
Get one user	GET	/api/users/42	Returns user with id 42
Create a user	POST	/api/users	Creates a new user
Update a user	PUT	/api/users/42	Replaces user 42's data
Delete a user	DELETE	/api/users/42	Removes user 42

REST is just a pattern. It works the same in Express, Django, Spring, Laravel — everywhere.

JSON — The Universal Data Format

JSON (JavaScript Object Notation) is how APIs send data. Even non-JavaScript APIs use it:

{
  "id": 42,
  "name": "Ahmed",
  "isActive": true,
  "tags": ["developer", "student"],
  "address": {
    "city": "Alexandria",
    "country": "Egypt"
  }
}

API Design Best Practices

Use nouns for URLs, not verbs: /users not /getUsers
Use plural names: /users not /user
Use HTTP methods for actions (GET, POST, etc.) instead of putting the action in the URL
Return proper status codes: don't return 200 OK when something failed
Use pagination for lists: /users?page=2&limit=20
Be consistent: if one endpoint uses camelCase, all should

GraphQL — The Alternative

REST makes you hit multiple endpoints to get related data. GraphQL lets you ask for exactly what you want in one request:

query {
  user(id: 42) {
    name
    email
    orders {
      product
      amount
    }
  }
}

Learn REST first. It's the standard. GraphQL is nice to know later.

8. Authentication & Authorization

These are two different things and mixing them up is a classic mistake.

Authentication (AuthN): "Who are you?" → Proving your identity (logging in)
Authorization (AuthZ): "What are you allowed to do?" → Checking permissions

How Login Works (The Real Flow)

1. User sends POST /login with { email, password }
2. Server finds the user in the database
3. Server checks: does the hashed password match?
4. If yes → Server creates a TOKEN (a signed string)
5. Server sends the token back to the client
6. Client stores the token (usually in memory or a cookie)
7. On every future request, client sends the token in the Authorization header
8. Server reads the token, verifies it's valid and not expired
9. Server now knows who this user is

Passwords — Never Store Plain Text

When a user creates a password, you hash it (turn it into a scrambled string that can't be reversed):

Password: "mypassword123"
Hashed:   "$2b$10$N9qo8uLOickgx2ZMRZoMye..."

When they log in, you hash what they typed and compare it to the stored hash. You never know their actual password. This means if your database gets stolen, the attacker can't read passwords.

Use bcrypt or argon2. Every language has a library for this.

JWT (JSON Web Tokens)

A JWT is a token that contains information about the user, signed with a secret key:

Header.Payload.Signature

The payload might be: { userId: 42, role: "admin", exp: 1234567890 }

The server can verify this token without checking the database every time. The signature proves it wasn't tampered with.

Sessions vs Tokens

Sessions: Server stores login state in memory or a database. The client gets a session ID cookie. Server-side state.
Tokens (JWT): Client holds the token. Server is stateless — it just verifies the signature. No server-side state needed.

Both are valid. Tokens are more popular for APIs; sessions are more traditional for web apps.

OAuth 2.0 — "Login with Google/GitHub"

OAuth lets users log into your app using their Google/GitHub/etc. account. You don't handle their password at all. The basic flow: your app redirects to Google → user logs in there → Google sends a code back to your app → your app exchanges that code for user info.

9. Caching — Making Things Fast

Caching means storing frequently used data in a fast place so you don't have to recalculate or re-fetch it every time.

Where Caching Happens

Browser Cache: The browser stores static files (images, CSS, JS) so it doesn't download them again.
CDN Cache: A Content Delivery Network stores your files on servers worldwide, so a user in Egypt gets served from a nearby server instead of one in the US.
Application Cache (Redis/Memcached): Your server stores frequently accessed data in memory. Way faster than hitting the database.
Database Cache: The database itself caches frequent queries.

Example: Why Caching Matters

Without cache:

User requests GET /popular-products
→ Server runs a complex database query (200ms)
→ This happens for EVERY user, EVERY time
→ 1000 users/second = 1000 database queries/second = 💀

With cache:

First request: GET /popular-products
→ Server runs the query (200ms)
→ Server stores the result in Redis with a 5-minute expiration
→ Returns result

Next 999 requests in 5 minutes:
→ Server checks Redis first (1ms)
→ Data is there! Returns it instantly
→ Database rests peacefully

Cache Invalidation

The hardest problem in caching: when do you update the cache? If you cache product prices and then change a price, users might see stale data. Strategies include time-based expiration (cache for 5 minutes), event-based invalidation (clear cache when data changes), and cache-aside (check cache first, fall back to database).

10. Security Basics

If you build a backend, you're responsible for protecting user data. Here are the most important threats:

SQL Injection

The attacker puts SQL code inside your input fields:

Login form: email = "admin@site.com" password = "' OR 1=1 --"

If you build SQL strings by concatenating user input, this can expose your entire database. Never do this. Always use parameterized queries or your framework's ORM.

Cross-Site Scripting (XSS)

The attacker injects JavaScript into your site that runs in other users' browsers. For example, putting <script>steal(cookies)</script> in a comment field. Always sanitize user input and escape HTML.

Cross-Site Request Forgery (CSRF)

The attacker tricks a logged-in user into making a request they didn't intend. Like clicking a link that secretly transfers money. Use CSRF tokens — every framework has built-in protection.

Rate Limiting

Without rate limiting, someone can send millions of requests to your server (DDoS), or try millions of passwords (brute force). Limit how many requests one IP can make per minute.

HTTPS Everywhere

Always use HTTPS. Never HTTP. HTTPS encrypts data between the client and server so nobody in the middle can read it. Free certificates from Let's Encrypt make this a no-brainer.

The OWASP Top 10

OWASP maintains a list of the top 10 web security risks. Read it, understand it, and check your apps against it. This is a checklist every professional developer uses.

11. Architecture Patterns

As your app grows, how you organize your code matters more and more.

Monolith

Everything in one big application. One codebase, one deployment. Start here. It's simpler, easier to debug, and perfect for learning and small-to-medium apps.

Microservices

Breaking your app into small, independent services that communicate over the network. The Users service, Orders service, and Payments service are separate apps. Don't do this until you have a reason to. It adds massive complexity. Companies like Netflix and Amazon use it because they have thousands of developers — not because it's always better.

MVC (Model-View-Controller)

The most common pattern inside any backend:

Model: Represents your data (the User class, the Order class)
View: What the user sees (HTML pages, or JSON responses for APIs)
Controller: Handles requests, calls the right models, returns the right views

Almost every framework is built around MVC. Rails, Laravel, Django, Spring MVC — they're all variations of this.

Event-Driven Architecture

Instead of services calling each other directly, they publish events to a message queue (like RabbitMQ or Kafka). Other services listen and react.

Example: When someone places an order, the Order Service publishes an "OrderPlaced" event. The Email Service hears it and sends a confirmation. The Inventory Service hears it and updates stock. They don't know about each other — they just react to events.

This is an advanced pattern. Learn it conceptually now; implement it when you need it.

12. Networking Essentials

The OSI Model (Simplified)

You don't need to memorize all 7 layers. Just know the ones that matter for backend:

Application Layer (HTTP, HTTPS, WebSocket): Where your code lives. You deal with requests and responses.
Transport Layer (TCP, UDP): TCP guarantees delivery. UDP is faster but doesn't guarantee (used for video calls, gaming).
Network Layer (IP): Routing data between machines using IP addresses.

WebSockets

HTTP is one-way: client asks, server responds. But what about live chat, real-time notifications, or live scores? That's where WebSockets come in.

A WebSocket is a persistent connection between client and server. Both can send messages at any time, without the client having to ask first. Think of HTTP as sending letters and WebSockets as a phone call — the line stays open.

Load Balancing

When one server can't handle all the traffic, you add more servers and put a load balancer in front of them. The load balancer distributes incoming requests across your servers. It's like having multiple checkout lines at a supermarket.

Common strategies: round-robin (take turns), least connections (send to the least busy server), or IP hash (same user always goes to the same server).

13. Linux & The Command Line

Most servers run Linux. You don't need to be a Linux expert, but you need to be comfortable in the terminal.

Essential Commands

# Navigation
pwd                  # Where am I?
ls                   # What's in this folder?
cd /path/to/folder   # Go to a folder
cd ..                # Go up one level

# Files
cat file.txt         # Show file contents
nano file.txt        # Edit a file
cp file.txt copy.txt # Copy a file
mv old.txt new.txt   # Rename/move
rm file.txt          # Delete a file (careful!)

# Searching
grep "error" log.txt # Find lines containing "error"
find . -name "*.js"  # Find all .js files

# Processes
ps aux               # Show running processes
top                  # Live process monitor
kill 1234            # Kill process with ID 1234

# Networking
curl http://example.com  # Make an HTTP request
ping google.com          # Check if a server is reachable

# Permissions
chmod 755 script.sh  # Make a script executable

Package Managers

Ubuntu/Debian: apt install package-name
macOS: brew install package-name

SSH — Remote Server Access

SSH (Secure Shell) lets you control a remote server from your terminal:

ssh user@123.45.67.89

You'll use this constantly in your career to manage production servers.

14. Version Control (Git)

Git tracks changes to your code. It's not optional — it's required for every developer job.

Core Concepts

Repository (Repo): Your project folder, tracked by Git
Commit: A snapshot of your code at a point in time, with a message explaining what changed
Branch: A parallel version of your code. Work on features without affecting the main code
Merge: Combining two branches together
Pull Request (PR): A proposal to merge your changes, reviewed by teammates

Essential Commands

git init                    # Start tracking a project
git add .                   # Stage all changes
git commit -m "Add login"   # Save a snapshot
git branch feature-x        # Create a new branch
git checkout feature-x      # Switch to that branch
git merge feature-x         # Merge feature-x into current branch
git push origin main        # Upload to GitHub
git pull origin main        # Download latest changes
git log --oneline           # See commit history
git status                  # See what's changed

Branching Strategy

The most common: main is production-ready. Create a branch for each feature. Merge back to main via pull request after review. Never commit directly to main.

15. Testing

Writing code that verifies your other code works correctly.

Types of Tests

Unit Tests: Test a single function in isolation. "Does my calculateTax(100) return 15?"
Integration Tests: Test multiple pieces working together. "Does my API endpoint actually save to the database and return the right response?"
End-to-End (E2E) Tests: Test the whole system from the user's perspective. "Can a user sign up, log in, and place an order?"

The Testing Pyramid

Write many unit tests (fast, cheap), some integration tests (medium), and few E2E tests (slow, expensive). Most of your bugs will be caught by unit tests.

Why Testing Matters

Without tests, every change you make could break something else without you knowing. With tests, you change code confidently. Tests are your safety net. Every serious company requires them.

16. DevOps Basics

DevOps is the bridge between writing code and running code in production.

Docker — Portable Environments

Docker packages your app and all its dependencies into a container. "It works on my machine" becomes "it works everywhere."

A Dockerfile is a recipe for building your container:

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

Now anyone can run your app with: docker build -t myapp . && docker run myapp

CI/CD — Automated Testing & Deployment

CI (Continuous Integration): Every time you push code, automated tests run. If they fail, you know before the code reaches production.

CD (Continuous Deployment): If tests pass, the code automatically gets deployed to production. No manual steps.

Tools: GitHub Actions, GitLab CI, Jenkins. GitHub Actions is the easiest to start with.

Cloud Basics

Your server needs to live somewhere. The big three cloud providers are AWS (Amazon), GCP (Google), and Azure (Microsoft). For starting out, simpler platforms like Railway, Render, or Fly.io let you deploy without cloud complexity.

17. The Learning Order (Roadmap)

Here's the order that makes sense. Don't jump ahead.

Phase 1: The Foundation (Weeks 1–6)

Pick ONE language (JavaScript/Node.js or Python — both are great)
Learn programming basics: variables, functions, loops, arrays, objects, classes
Understand how the internet works: HTTP, DNS, TCP/IP
Learn the command line basics
Learn Git basics

Phase 2: Databases & APIs (Weeks 7–12)

Learn SQL (PostgreSQL recommended)
Build a simple REST API with your language (Express for Node.js, Flask/FastAPI for Python)
Connect your API to a database
Learn about request/response, routing, middleware
Build a CRUD app (Create, Read, Update, Delete) — like a todo list or blog

Phase 3: Real-World Skills (Weeks 13–20)

Add authentication (JWT, password hashing)
Learn about validation and error handling
Add caching (Redis)
Learn basic security (SQL injection, XSS, CSRF)
Write unit tests
Build a bigger project (e-commerce API, social media API)

Phase 4: Production & Scale (Weeks 21–28)

Learn Docker
Deploy your app to the cloud
Set up CI/CD with GitHub Actions
Learn about logging and monitoring
Understand basic architecture patterns (MVC, microservices concepts)
Study system design basics

Phase 5: Level Up (Ongoing)

Learn a second framework to prove your concepts transfer
Study message queues (RabbitMQ/Kafka)
Learn GraphQL
Dive deeper into system design
Contribute to open source
Read other people's code

🎯 The Big Takeaway

Frameworks change every few years. JavaScript frameworks are born and die faster than you can learn them. But the concepts in this guide? They've been the same for decades and will stay the same for decades more.

HTTP hasn't changed. Databases still use SQL. Servers still handle request→process→response. Auth still uses tokens or sessions. Caching still makes things fast.

When you understand these fundamentals, picking up a new framework takes days, not months. You look at Spring and think "Oh, this is just their way of doing routing and middleware." You look at Django and think "This is just MVC with a different name."

You're not learning a framework. You're learning how computers talk to each other. The framework is just the language you write it in.

"The person who understands WHY will always lead the person who only knows HOW."

Good luck on your journey. You've already made the right decision by starting with the fundamentals. 🚀

credits: claude

DEV Community: Mohamed Idris

I made a swing boat that reacts to doom scrolling

What it does

How it works

Try it

My bot stopped sending questions the day Egypt turned on Daylight Saving Time

How the bot schedules questions

How "Cairo time" works in the code

What is Daylight Saving Time?

The bug

Why there were no errors

Fix 1: Move the cron to a safe time

Fix 2: Add a fallback inside the send job

The lesson

Stop arguing about formatting in code reviews. Use Husky and lint-staged instead.

What are we actually solving?

Step 1: Install the tools

Step 2: Initialize Husky

Step 3: Set up the pre-commit hook

Step 4: Configure lint-staged

Step 5: Add a .prettierignore file

How it works in practice

VS Code integration (the finishing touch)

The result

Resume Update!

How to Undo a Git Commit Without Losing History

The Problem

The Better Way: git revert

How to Do It

When to Use git revert vs git reset

Summary

The 3-Second Rule: How to Write a Freelance Proposal That Gets Read (and Gets Replies)

Why "3 Seconds" at All?

The Biggest Mistake Freelancers Make

The 3-Second Rule Point: Make It About Them First

Good vs Bad: Side by Side

The Full Proposal Structure (After the Hook)

1. The Hook (Seconds 1-3)

2. The Bridge (Your Relevant Experience)

3. The Plan (What You Will Do)

4. The Proof (Why Trust You)

5. The Call to Action (CTA)

Full Example: Putting It All Together

More Hook Examples You Can Adapt

The Things That Kill Good Proposals

Quick Checklist Before You Send

TL;DR

If You Were a Server: How to Detect Issues and Keep Things Running Smoothly

First: What Is the Question Really Asking?

Part 1: How Does a Server Detect It Has Issues?

The Four Core Vitals

1. CPU Usage

2. Memory (RAM) Usage

3. Disk Usage and I/O

4. Network Bandwidth

Beyond the Core Vitals: Application-Level Signals

5. Response Time / Latency

6. Error Rate

7. Throughput / Request Rate

Health Checks: The Server Checking Itself

Liveness Probe

Readiness Probe

Logging: The Server's Diary

Alerting: Getting Notified Before It's Too Late

Part 2: What Do You Do Next to Keep Things Running Smoothly?

1. Auto-Scaling: Get More Help

2. Circuit Breaker: Stop the Bleeding

3. Graceful Degradation: Do Less, Not Nothing

4. Caching: Avoid Repeating Work

5. Rate Limiting: Control Incoming Traffic

6. Retry with Exponential Backoff: Be Patient, Not Aggressive

7. Rollbacks: Undo What Broke It

8. Runbooks: The Human Response Plan

Putting It All Together: The Full Answer Framework

Real-World Tools Worth Knowing

TL;DR

How to Remove a File from Git History (And What to Watch Out For)

Why deleting the file isn't enough

Step 1 — Make sure the file is deleted locally

Step 2 — Rewrite git history

The Better Way: `git revert`

When to Use `git revert` vs `git reset`

The `.then()` chaining trick