Forem: Sohana Akbar

Imposter syndrome at 18 — it's real

Sohana Akbar — Sat, 09 May 2026 14:27:34 +0000

Imposter syndrome at 18 — it's real

TL;DR: You're not a fraud. You're just starting. There's a difference.

The Voice In My Head

I'm 18. I know frontend development. I know DevOps.

And yet, every single day, my brain tells me:

"You don't actually know anything."

"Someone else is better. Someone younger. Someone who actually deserves to be here."

"They're going to find out you're faking it."

That voice? That's imposter syndrome.

And at 18? It hits different.

Why It's Worse When You're Young

Age	What People Think	What You Feel
25+	"They have experience"	"I belong here"
18	"They're just a kid"	"Everyone is better than me"

At 18, you don't have:

A degree to prove yourself
Years of experience to point to
A network of seniors who "get it"

You just have... you. And that little voice.

The Comparison Trap

I open LinkedIn → someone my age is working at Google.

I open Twitter → a 16-year-old just launched a SaaS making $10k/month.

I open GitHub → someone's repo has 5k stars. Mine has 3.

And suddenly, my brain says:

"You're behind. You're not enough. You'll never catch up."

Sound familiar?

What Nobody Tells You

The people you're comparing yourself to?

They feel the same way.

That 16-year-old with $10k/month? They probably think they're lucky, not skilled.

That Google intern? They're terrified someone will find out they don't know how to merge a PR.

Imposter syndrome doesn't care about your age or success.

It just cares that you're human.

The Reframe That Saved Me

I used to think:

"I don't know enough."

Now I think:

"I don't know enough yet."

One word. "Yet."

It changes everything.

I don't know Kubernetes... yet
I haven't landed a client... yet
I'm not making money... yet

"Yet" gives you permission to be a beginner.

5 Things That Actually Help

1. Save Your Wins

Create a folder called "wins" on your phone.

Every time you:

Fix a bug
Deploy something
Help someone
Learn something new

Screenshot it. Save it.

On bad days, open that folder.

You'll realize: "Oh. I actually did stuff."

2. Talk About It

Say it out loud:

"I feel like I don't know what I'm doing."

To a friend. To Twitter. To a rubber duck.

The moment you say it, it loses power.

Silence makes it grow. Speaking shrinks it.

3. Find Your People

Follow other young devs on X/LinkedIn.

Comment on their posts. DM them.

When you see someone else struggling, you realize:

"Oh. It's not just me."

Community > Competition.

4. Stop Comparing Inputs to Outputs

You see someone's highlight reel.

You compare it to your behind-the-scenes.

That's not fair to you.

That person also:

Cried over a bug
Got rejected
Felt like giving up

You just didn't see it.

5. Do It Scared

Here's the secret:

Everyone feels like a fraud.

The difference is: some people do it anyway.

Deploy that app even if it's ugly.
Write that article even if no one reads it.
Apply for that job even if you think you're underqualified.

Do it scared. Do it messy. Just do it.

What I Tell Myself Now

"You're 18. You're supposed to not know things. That's literally the point of being 18."

You're not supposed to have it figured out.

You're supposed to be learning, failing, trying, breaking, fixing, growing.

That's not imposter syndrome.

That's being a beginner.

And being a beginner is not a crime. It's a stage.

Your Turn

If you're reading this and you feel like a fraud:

You're not.

You're just human. In progress. Still cooking.

And that's perfectly okay.

Drop a ❤️ if this hit home. Or reply with your own imposter syndrome story.

Let's be real with each other.

"I Failed My First AWS Certification Attempt" – Here’s What I Learned (And Why You Shouldn’t Panic)

Sohana Akbar — Fri, 08 May 2026 13:47:16 +0000

Failure isn’t the end. It’s just a very expensive practice exam.

Let me set the scene.

I’d spent weeks watching video courses, highlighting cheat sheets, and answering practice questions. I walked into that exam center (yes, online proctored, but emotionally, I was walking in) feeling ready.

Three hours later, I saw the screen: FAIL.

No cute confetti. No “close enough.” Just a cold, numeric score below passing.

I felt embarrassed, frustrated, and honestly – a little stupid.

But here’s what I’ve realized three months, one retake, and one certification later: failing was the best thing that could’ve happened to me.

Why I Really Failed
Let me save you the trouble of overthinking:

I memorized, not understood. I knew S3 bucket policies by heart but couldn’t explain why one fails over another.

Practice exams ≠ real exam. The real test twists scenarios, mixes services, and loves those “choose TWO answers” questions.

Time management? What time management? I spent 10 minutes on one VPC question and panicked through the rest.

You might relate. And that’s okay.

What I Did Differently the Second Time
After licking my wounds for a few days, I got practical.

I read the official exam guide (actually read it)
Weirdly helpful. It tells you exactly which domains are weighted heavily. Stop guessing.
Hands-on > passive learning
I built tiny things. A static site on S3 + CloudFront. A serverless API with Lambda + API Gateway. Broke them. Fixed them. That stuck.
Reviewed every wrong answer (even the ones I guessed right)
If you can’t explain why an option is wrong, you don’t know the topic.
Used TutorialsDojo & AWS Skill Builder
These were the closest to the real exam format. Worth every penny.

The Hardest Part? Your Ego
Nobody likes to fail. Especially when you’ve told your manager, posted on LinkedIn about “studying for AWS cert,” or spent your own money on exam fees.

But here’s the truth: no one in tech cares if you failed a cert exam.

They care if you can solve problems, learn from mistakes, and try again.

When I retook the exam (and passed), nothing changed dramatically. No promotion fairy showed up. But I changed. I became better at AWS, better at debugging, and less afraid of being wrong.

So You Failed. Now What?
Download your score report – See which domains you bombed. Focus there.

Take 2-3 days off – No AWS. No studying. Clear your head.

Book your retake – Having a date makes the comeback real.

Change your study method – If videos didn’t work, try hands-on labs. If practice exams failed you, try a different vendor.

One Last Thing
That failure score report is still in my email. I didn’t delete it.

Every few months, I scroll past it and smile. Because that failed attempt taught me more than any “pass” ever could.

You didn’t fail. You just found one way that didn’t work.

Now go book that retake. You’ve got this. 💪

Did you fail your first AWS cert too? Drop a 🙋 in the comments – let’s normalize learning in public.

NGINX for beginners — what even is a reverse proxy?

Sohana Akbar — Thu, 07 May 2026 13:25:39 +0000

If you are just starting your web development journey, you’ve probably heard the name NGINX (pronounced "Engine-X") thrown around. Maybe you followed a tutorial to deploy a React app and you had to copy-paste some mysterious location / blocks into a config file.

But here is the big question that stops everyone cold: What even is a reverse proxy?

Let’s ditch the jargon. By the end of this 5-minute read, you’ll understand exactly what NGINX does, why "proxy" isn't a scary word, and why the internet practically runs on this software.

First, the "Normal" Proxy (The One you already know)
To understand a reverse proxy, we need to look at a forward proxy first.

Imagine you are at work or school. You want to watch a video game stream, but the office Wi-Fi blocks it.

The Setup:

You (The Client)

The Office Wi-Fi (The Proxy)

The Game Stream (The Server)

Instead of connecting directly to the game server, you ask the proxy to do it for you. The proxy hides your identity and bypasses the block.

Forward Proxy Job: "Hides the client (you) from the server."

So, What is a Reverse Proxy?
Now, flip that diagram upside down.

You are chilling at home, and you want to visit google.com. You type it into your browser. You don't actually talk to the main Google computers; you talk to a reverse proxy.

The Setup:

You (The Client)

The NGINX Server (The Reverse Proxy)

The App/Coding (The Internal Server)

Reverse Proxy Job: "Hides the server from the client (you)."

You think you are talking to the main computer, but you are actually talking to NGINX, which then politely talks to the main computer for you.

Why Should You Care? (The 3 Superpowers of NGINX)
If all it does is "hide the server," why is NGINX used by Netflix, Airbnb, and Dropbox? Because hiding the server gives you three magical powers.

Load Balancing (The Traffic Cop) Let’s say your Node.js app goes viral. One server can't handle 1 million users at once. You spin up 3 identical servers.

Without NGINX: All 1 million users crash into Server #1. Chaos.

With NGINX: NGINX sits in front and says, "User 1, go to Server A. User 2, go to Server B. User 3, go to Server C."

NGINX spreads the work so no single server has a meltdown.

SSL Termination (The Security Guard) HTTPS (the padlock in your browser) is complicated to set up on every single app server.

Without NGINX: You have to configure SSL certificates on your Node app, your Python app, and your Go app. Nightmare.

With NGINX: You configure the certificate once on NGINX. NGINX catches the encrypted traffic, decrypts it, and sends the safe, simple HTTP traffic to your internal apps.

Serving Static Files (The Speed Demon) Here is the secret that blows most beginners' minds: You should not use your fancy backend code (Python/Node/Ruby) to serve images, CSS, or HTML.

Backend languages are slow at serving files because they have to "think." NGINX is written in C and optimized for this exact job.

nginx

A typical NGINX config for a React app

server {
listen 80;
server_name mywebsite.com;

location / {
    # Don't touch the React files!
    root /var/www/html;
    try_files $uri /index.html;
}

location /api {
    # Wait... this is a reverse proxy!
    # If the URL has /api, send it to my backend server.
    proxy_pass http://localhost:3000;
}

}
The "Aha!" Moment
Look at the config above again. See that /api block?

On the same domain (mywebsite.com), NGINX is doing two things:

Serving your HTML/CSS directly (fast).

Proxying your API requests to your backend (hidden).

If your browser visits mywebsite.com/api/users, NGINX doesn't say "I don't know that route." It says, "Hold on, I know a guy," and forwards the request to localhost:3000/users.

The user (the browser) has no idea your backend is running on port 3000. The server (Node.js) has no idea if the user is on a phone or a laptop. They are completely hidden from each other.

How to Prove This to Yourself (5 minutes)
You don't need to deploy to the cloud to see this work. Do this on your laptop:

Install NGINX (use Homebrew on Mac, apt on Linux, or Docker).

Start a simple Python server: python -m http.server 8000

Add this to your NGINX config:

nginx
server {
listen 8080;
location / {
proxy_pass http://localhost:8000;
}
}
Restart NGINX and visit localhost:8080. You are looking at your Python server via the NGINX proxy.

The Bottom Line
Stop thinking of NGINX as a scary server "thing." Think of it as Reception Desk for the Internet.

A visitor arrives (HTTP Request).

NGINX asks: "Do you want a photo? (I'll handle it). Do you want to log in? (I'll call the backend). Is this person annoying? (I'll block them)."

The visitor never sees the chaos happening in the back office.

That is a reverse proxy. That is NGINX.

Once you understand that, the entire world of DevOps, microservices, and cloud hosting suddenly makes a lot more sense.

Found this helpful? Let me know in the comments if you want a Part 2 on "The 5 most common NGINX config mistakes beginners make."

My React Folder Structure (Opinionated but Works)

Sohana Akbar — Wed, 06 May 2026 15:59:28 +0000

TL;DR: Stop throwing everything into components/. After 6 production apps and 3 burned-out refactors, I landed on a feature-based, domain-driven structure that scales from 1 to 100 components.

I have tried every structure: grouped by type, grouped by route, atomic design, and even "just throw it in src." This is the one that finally made me stop crying during code reviews.

The Golden Rule: Co-location of Concern
"Files that change together, live together."

If you are editing UserProfile.tsx and you have to jump to 4 different folders (components/, hooks/, types/, services/), your structure is broken.

Here is the tree view of my happy place:

text
src/
├── features/ # The 🐐 (core domain logic)
│ ├── auth/ # Single feature
│ │ ├── components/ # ONLY used by this feature
│ │ ├── hooks/ # Feature-specific hooks
│ │ ├── types/ # TS interfaces/domain types
│ │ ├── api/ # API calls for this feature
│ │ └── index.ts # Public API for the feature
│ ├── dashboard/
│ └── settings/
│
├── shared/ # Reusable, but NOT business logic
│ ├── ui/ # Dumb components (Button, Modal, Card)
│ │ ├── Button/
│ │ ├── Modal/
│ │ └── index.ts
│ ├── lib/ # Utils, formatters, constants
│ ├── hooks/ # Generic hooks (useLocalStorage, useDebounce)
│ └── api/ # Axios/fetch instance, interceptors
│
├── app/ # Next.js/React Router setup
│ ├── routes/ # Route configuration
│ └── providers/ # Context providers (Theme, QueryClient)
│
├── layouts/ # AuthLayout, DashboardLayout
│
└── main.tsx # Entry point
Deep Dive: The features/ Folder (Where the magic happens)
Each feature is a mini-app. It owns everything it needs. No imports jumping across the galaxy.

Example: features/auth/
typescript
// features/auth/types/index.ts
export interface User {
id: string;
email: string;
role: 'admin' | 'user';
}

// features/auth/api/authApi.ts
import { apiClient } from '@/shared/api';
import type { User } from '../types';

export const authApi = {
login: (email: string, password: string) =>
apiClient.post('/auth/login', { email, password }),
logout: () => apiClient.post('/auth/logout')
};

// features/auth/hooks/useLogin.ts
import { useMutation } from '@tanstack/react-query';
import { authApi } from '../api/authApi';

export const useLogin = () => {
return useMutation({
mutationFn: authApi.login,
onSuccess: (user) => {
// Handle success locally inside the feature
}
});
};

// features/auth/components/LoginForm.tsx
import { useLogin } from '../hooks/useLogin';
import { Button } from '@/shared/ui/Button'; // Only shared UI allowed

export const LoginForm = () => {
const { mutate } = useLogin();
return mutate(...)}>Login;
};

// features/auth/index.ts (Public API)
export { LoginForm } from './components/LoginForm';
export { useLogin } from './hooks/useLogin';
export type { User } from './types';
Rule: No cross-imports between features ❌
typescript
// BAD: Dashboard importing directly from auth's internal folder
import { useLogin } from '@/features/auth/hooks/useLogin';

// GOOD: Use the feature's public index.ts
import { useLogin } from '@/features/auth';
Why? Later, you can delete the auth/ folder entirely without breaking dashboard/ if you do it right.

The shared/ Folder (The innocent box of Legos)
This is where pure, reusable, business-logic-free code lives.

Subfolder Contents Example
ui/ Presentational components Button, Input, Card, Modal (No API calls!)
hooks/ Generic React hooks useLocalStorage, useMediaQuery, useCopyToClipboard
lib/ Pure functions formatDate, cn() (clsx/tailwind-merge), generateId
api/ Configured HTTP client Axios instance with baseURL, interceptors, auth headers
The shared/ui/ pattern (Bonus)
I use a barrel export for UI components:

typescript
// shared/ui/Button/Button.tsx
export const Button = (props) => { ... };

// shared/ui/Button/index.ts
export * from './Button';

// shared/ui/index.ts
export { Button } from './Button';
export { Modal } from './Modal';
Then in any feature or layout:

typescript
import { Button, Modal } from '@/shared/ui';
Why This Works (The Opinionated Part)

It destroys "God Components"
When everything lives in components/, you eventually create UserDashboardFormWithSidebarAndHeaderAndFooter.tsx. In feature folders, you are forced to split.
Deleting features is safe
Marketing wants a temporary landing page feature? Clone features/landing/ into it. Then delete it. No orphaned hooks, no broken imports.
Types are treated as first-class citizens
No more types.ts at the root with 3,000 lines. Each feature defines its own domain types. If two features need the same type, it belongs in shared/types/.
It works with every meta-framework
Next.js (App Router): features/ sit next to app/

Vite + React Router: features/ import shared/

Remix: Same thing.

Real-World Exception (Because perfect doesn't exist)
Exception #1: Global state (Zustand, Redux, Jotai)

Store global slices in stores/ inside app/, not inside features/.

Only put feature-scoped state inside the feature folder.

Exception #2: Shared types across 3+ features

Move to shared/types/. Example: ApiResponse.

The Migration Path (If you are converting an existing app)
Create shared/ui/ and move Button, Card, Input there. (1 hour)

Pick ONE feature (e.g., auth). Create the folder structure. Move its components, hooks, and API calls inside. (2 hours)

Update imports for that one feature. Use your IDE's refactor tools.

Repeat for the second feature. The third one will take 10 minutes.

Delete the old components/ folder when it's empty. Full send.

The Verdict
Is this the only way? No.
Does it work for a 50-component side project? Overkill.
Does it work for a 500-component enterprise app with 6 developers? Yes. Every. Single. Time.

If you take one thing away: Don't organize by file type. Organize by feature.

What does your React folder structure look like? Did I miss your pet pattern? Let me know in the comments — but be nice, my structure is "opinionated but works" for a reason. 😅

P.S. If you want the TypeScript paths config to make @/ work:

json
// tsconfig.json
{
"compilerOptions": {
"paths": {
"@/": ["./src/"]
}
}
}

Environment Variables Explained (with .env file)

Sohana Akbar — Tue, 05 May 2026 12:26:54 +0000

Ever hardcoded an API key in your code? We've all been there. Then came the panic commit removing it right after. Let me show you the right way.

What are environment variables?
Environment variables are dynamic key-value pairs stored outside your application code. They live in the shell session or system environment, making them perfect for configuration that changes between environments.

Think of them as settings you can change without touching your codebase.

Why use them?
Security - Keep secrets out of version control

Portability - Same code, different configs (dev/staging/prod)

Convenience - No more config files inside your repo

The .env file
A .env file is a plain text file in your project root that lists environment variables:

bash

.env

PORT=3000
DATABASE_URL=postgresql://localhost:myapp
API_KEY=abc123secret
How to use it
Most programming languages have packages to load .env files:

Node.js (using dotenv):

javascript
require('dotenv').config()

const port = process.env.PORT
const dbUrl = process.env.DATABASE_URL
Python (using python-dotenv):

python
from dotenv import load_dotenv
import os

load_dotenv()
port = os.getenv('PORT')
Go (using godotenv):

go
import "github.com/joho/godotenv"

godotenv.Load()
port := os.Getenv("PORT")
Golden rules
Never commit .env - Add it to .gitignore

Create .env.example - Show required variables without secrets:

text
PORT=3000
DATABASE_URL=
API_KEY=your_key_here
Use different values per environment - Local DB for dev, production DB for prod

Production caveat
In production, avoid .env files. Use your platform's native environment configuration:

bash

Heroku / Railway / Render

heroku config:set API_KEY=prod_secret_123

Docker

docker run -e API_KEY=prod_secret_123 myapp
Bottom line
Environment variables separate what your app does from where it runs. Use them. Your future self (and teammates) will thank you.

What's your go-to method for managing secrets across teams? Share below! 👇

Basic Linux Commands Every Dev Should Know

Sohana Akbar — Sun, 03 May 2026 14:27:59 +0000

You don’t need to be a sysadmin to work comfortably in Linux. But as a developer, knowing the right 20% of commands will save you hours of clicking and debugging.

Let’s cut the fluff. Here are the essential Linux commands I use daily.

Navigation & Inspection
bash
pwd # Where am I?
ls -la # List all files (including hidden) with details
cd project/ # Move into directory
cd .. # Go back one level
cd ~ # Go home
Dev tip: Use ls -la | grep keyword to filter files.
File Operations (You’ll use these constantly)
bash
touch index.js # Create empty file
cat file.txt # Print entire file to terminal
head -20 app.log # First 20 lines of log
tail -f app.log # Follow live log output (critical for debugging)
cp -r src/ backup/ # Copy folder recursively
mv oldname.js newname.js # Rename or move
rm file.txt # Delete file (careful!)
rm -rf node_modules/ # Delete folder (double careful!)
Process Management
bash
ps aux # List all running processes
ps aux | grep node # Find Node processes
kill -9 1234 # Force kill process with PID 1234
kill -15 1234 # Graceful termination
top # Live system monitor (press q to exit)
Permissions (Deployers & DevOps)
bash
chmod +x script.sh # Make script executable
chmod 644 file.txt # rw-r--r-- (owner read/write, others read)
sudo command # Run as superuser (careful!)
Finding Stuff
bash
grep "error" app.log # Search inside file
grep -r "TODO" ./src # Search recursively in folder
find . -name "*.js" # Find all JS files
find . -type d -name "models" # Find directory named "models"
System Info & Disk
bash
df -h # Disk free (human readable)
du -sh folder/ # Size of folder
free -h # RAM usage
uname -a # Kernel version
Network for API Testing
bash
curl https://api.example.com/users # GET request
curl -X POST -d '{"name":"John"}' -H "Content-Type: application/json" \
https://api.example.com/users
ping google.com # Check connectivity
netstat -tulpn # Which ports are listening?
The Magic Pipe |
Pipes send output from one command as input to another. This is where Linux becomes powerful.

bash
ls -la | sort -rk5 # Sort files by size (largest first)
ps aux | grep node | wc -l # Count Node processes
history | grep docker # Find a command you ran earlier
One-Liners That Save Hours
bash

Find and delete all node_modules folders (frees tons of space)

find . -name "node_modules" -type d -prune -exec rm -rf '{}' +

Find largest files in current directory

du -sh * | sort -h | tail -10

Replace text in all files

find . -name "*.txt" -exec sed -i 's/old/new/g' {} \;
Bonus: Aliases (Your Best Friend)
Create shortcuts by adding to ~/.bashrc or ~/.zshrc:

bash
alias gs="git status"
alias ll="ls -la"
alias please="sudo"
alias ..="cd .."
Then run source ~/.bashrc.

The Golden Rule
Always run ls before rm -rf.

Accidentally deleting the wrong directory is a rite of passage — but an avoidable one.

You don’t need to memorize all flags. Use command --help or man command (e.g., man ls). Knowing 80% of these 20 commands will handle 95% of your terminal work.

What’s your most-used Linux command? Drop it in the comments 👇

Localhost vs. Deployment: The Pain is Real It works on my machine (and other lies we tell ourselves)

Sohana Akbar — Sat, 02 May 2026 13:41:57 +0000

We’ve all been there. Six hours of coding. Green tests. A clean PR.

You push to production.

Then it happens. A 500 error. CORS nightmare. Missing asset.

You whisper the most dangerous sentence in software: “But... it worked on localhost.”

Welcome to the war.

The 5 Stages of Localhost Grief

Environment Variables
Locally: .env works fine.
Production: One missing API_KEY and your entire app implodes with a vague "Internal Server Error."
Case-Sensitive File Systems
Locally: import User from './components/user' works (thanks, macOS).
Production (Linux): Cannot find module. You cry.
CORS
Locally: localhost:3000 → localhost:5000? No problem.
Production: https://app.com → https://api.com? Denied. Good luck.
The Database Divide
Locally: 12 rows. Queries take 2ms.
Production: 12 million rows. No index. That query now takes 45 seconds.
"But the build worked locally"
Until the CI runner uses a different Node patch version and your hash changes. Suddenly, the CSS is gone.

The Hard Truth
The gap will never fully close. Cloud changes. Networks lag. Dependencies drift.

But the pain isn't failure—it's engineering.

3 Quick Ways to Suffer Less
Use Docker. Develop in the same Linux container you deploy to.

Kill if (dev) branches. Make local fail as loudly as production.

Test against real dependencies. Hit the actual API. Use the real CDN.

What's your worst "works on my machine" story? Drop it below. Let's trauma-bond. 👇

How to Add Dark Mode to Any Website (Even If You’re Not a CSS Wizard)

Sohana Akbar — Fri, 01 May 2026 13:24:19 +0000

Introduction
Dark mode isn’t just a trend anymore—it’s an expectation. From Windows and macOS to iOS and Android, users want the option to switch from a blinding white background to a sleek, eye-friendly dark interface.

But here’s the good news: You don’t need to redesign your entire website. With a few smart CSS rules and a sprinkle of JavaScript, you can add dark mode to any website in under 30 minutes.

In this article, I’ll show you three methods—from quick-and-dirty to fully professional.

Method 1: The “Browser Native” Approach (Easiest)
Modern browsers now support prefers-color-scheme, a CSS media query that detects if a user has dark mode enabled in their OS settings.

Step 1: Add Dark CSS Variables
css
/* Light mode (default) */
:root {
--bg: #ffffff;
--text: #111111;
--accent: #0077cc;
}

/* Dark mode automatic */
@media (prefers-color-scheme: dark) {
:root {
--bg: #121212;
--text: #eeeeee;
--accent: #66ccff;
}
}

body {
background: var(--bg);
color: var(--text);
}
Pros: Zero JavaScript, respects system preferences.
Cons: No manual toggle for users.

Method 2: Manual Toggle with JavaScript (Most Flexible)
This gives users a button to switch modes, overriding their system preference.

Step 1: HTML Toggle Button
html
🌓 Dark Mode
Step 2: CSS with a .dark-mode Class
css
:root {
--bg: #ffffff;
--text: #111111;
}

.dark-mode {
--bg: #121212;
--text: #eeeeee;
}

body {
background: var(--bg);
color: var(--text);
transition: background 0.3s, color 0.2s;
}
Step 3: JavaScript to Save Preference
javascript
const toggle = document.getElementById('darkModeToggle');
const prefersDark = window.matchMedia('(prefers-color-scheme: dark)').matches;

// Check localStorage or system preference
if (localStorage.getItem('theme') === 'dark' || (!localStorage.getItem('theme') && prefersDark)) {
document.body.classList.add('dark-mode');
}

toggle.addEventListener('click', () => {
document.body.classList.toggle('dark-mode');
const theme = document.body.classList.contains('dark-mode') ? 'dark' : 'light';
localStorage.setItem('theme', theme);
});
Pros: Full user control, persistent choice.
Cons: Requires a bit of JS.

Method 3: For Legacy Websites (Overriding Inline Styles)
If you’re dealing with messy third-party code or inline styles, use an inverted filter trick (use sparingly).

css
.dark-mode {
filter: invert(1) hue-rotate(180deg);
}
How it works: Inverts all colors, then fixes hue shifts. This makes white backgrounds black and black text white.

Warning: Images and videos will also invert. You’ll need to un-invert them:

css
.dark-mode img,
.dark-mode video {
filter: invert(1) hue-rotate(180deg);
}
Only use this as a temporary fix or for simple sites.

Pro Tips for a High-Quality Dark Mode
Don’t use pure black (#000000) – It creates harsh contrast. Use #121212 or #1e1e1e.

Reduce shadows – Dark mode looks cleaner with less shadow depth.

Test all interactive elements – Buttons, links, and inputs must remain accessible.

Toggle system preference + manual override – Best of both worlds:

javascript
// Listen to system changes
window.matchMedia('(prefers-color-scheme: dark)').addEventListener('change', (e) => {
if (!localStorage.getItem('theme')) {
document.body.classList.toggle('dark-mode', e.matches);
}
});
Real-World Example: Adding Dark Mode to a Blog in 5 Minutes
Let’s say you have a basic WordPress or static HTML site.

Open your CSS file.

Define CSS variables for colors.

Add the .dark-mode class overrides.

Insert the JavaScript above.

Add a floating button with position: fixed.

That’s it. Your blog now has dark mode.

Conclusion
Dark mode is no longer optional—it’s a mark of a modern, user-respecting website. You don’t need a full rewrite. Start with CSS variables, add a JavaScript toggle, and store the user’s preference in localStorage.

Whether you manage a personal blog, a corporate site, or a web app, these three methods work everywhere.

Your users will thank you—especially those coding at 2 AM.

Ready to go dark?
Try the code snippets above today. Then ask yourself: Why didn’t I do this sooner?

Let me know if you’d like a ready-to-copy HTML/CSS/JS template for this.

Responsive CSS Tips That Took Me 6 Months to Learn

Sohana Akbar — Thu, 30 Apr 2026 14:27:05 +0000

After half a year of trial, error, and countless browser tabs, here are the responsive CSS lessons that actually stuck.

Stop using px for everything px is rigid. rem and em scale with user preferences.

css
/* Hard to maintain */
body { font-size: 16px; }

/* Accessible & responsive */
body { font-size: 1rem; }
h1 { font-size: 2.5rem; }
My rule: px for borders, rem for everything text-related.

clamp() is magic No more 3 different media queries just to resize a heading.

css
h1 {
font-size: clamp(1.5rem, 5vw, 3rem);
}
Fluid typography that scales perfectly from mobile to desktop. One line.

The :has() selector changes everything Parent selection is finally here.

css
/* Add padding if card contains an image */
.card:has(img) {
padding: 1rem;
}

/* Highlight a row with an error */
.row:has(.error) {
background-color: #fff0f0;
}
Works in all modern browsers. Use it carefully—performance is good but not free.

Container queries > Media queries (for components) Media queries look at the viewport. Container queries look at the component's parent.

css
.card-container {
container-type: inline-size;
}

@container (min-width: 400px) {
.card {
display: flex;
flex-direction: row;
}
}
Your card component now responds to its own space, not the whole screen.

min() and max() for spacing css .padding { padding: min(5vw, 2rem); }

.sidebar {
width: max(250px, 20%);
}
No media query needed for basic responsive spacing.

overflow: hidden is not your friend on body It breaks scroll-driven animations and can cause layout shifts on mobile keyboards.

Instead, use:

css
body {
overflow-x: clip; /* or visible */
}

Test with real devices, not just DevTools Chrome's mobile view is optimistic. Real phones have:

Slower touch response

Notches and dynamic islands

Zoom settings

Browser UI that appears/disappears

Quick test: Grab an old iPhone, Lower brightness to 50%, Open your site in safari. You'll learn more in 5 minutes than an hour in DevTools.

width: 100% vs width: 100vw 100vw includes scrollbar width. It causes horizontal overflow.

css
/* This can cause sideways scroll */
.full-width {
width: 100vw;
}

/* Safer */
.full-width {
width: 100%;
}
The 6-month shortcut
If I could go back, I'd learn in this order:

rem + clamp() for text

Container queries for components

:has() for conditional styling

min()/max() for spacing

Real device testing early

The rest you'll pick up along the way.

What took you way too long to learn in CSS? Drop it in the comments.

My First Dockerfile: The Horrifying "Before" vs. The Efficient "After"

Sohana Akbar — Wed, 29 Apr 2026 12:58:37 +0000

We all have that one commit we’re not proud of. You know, the one pushed late on a Friday night with the message: "pls work".

For me, that commit contained my very first Dockerfile. I was fresh out of a tutorial, convinced I had mastered containerization. Spoiler: I had not.

Looking back at that file is like looking at a mullet haircut from 1987. It was functional, but messy, insecure, and bloated.

Let me show you the evolution. The cringe vs. the clean. The Before vs. the After.

The "Before": The Wild West Dockerfile
I was building a simple Node.js API. My logic was: Install everything, copy everything, run everything as root, and pray.

dockerfile

Before: The "It works on my machine" special

FROM node:latest

Create app directory (Good start, but wait for it...)

WORKDIR /usr/src/app

Copy EVERYTHING. Node modules? Yeah, copy those too. .git? Sure.

COPY . .

Install dependencies (including dev dependencies, because why not?)

RUN npm install

Install global tools nobody asked for

RUN npm install -g nodemon pm2

Expose a port (Only one? Let's guess!)

EXPOSE 3000

Run as root (Security? Never heard of her)

CMD ["npm", "start"]
Why this made me a monster
node:latest is a ticking time bomb. Today it’s Node 21; next week it’s Node 22. Your build will randomly break because dependencies don’t match.

COPY . . is lazy and dangerous. I copied node_modules from my host machine (which was built for Windows/Mac) into the Linux container. This causes segfaults and mysterious "module not found" errors. I also copied secrets, SSH keys, and my .env file into the final image.

Giant image size. My image was ~1.2GB. Pulling that over coffee shop Wi-Fi? Forget it.

Running as root. If a hacker exploited my Node app, they had full root access to the container. Yikes.

The "After": The Professional's Approach
After three production outages and a mentor slapping me (metaphorically) with a security scan, I rewrote everything. Here is the Dockerfile I use today.

dockerfile

After: Lean, mean, and secure

1. Specific version + slim variant

FROM node:20-slim AS dependencies

WORKDIR /app

2. Copy ONLY package files first (Leverage Docker caching)

COPY package*.json ./
RUN npm ci --only=production

3. Multi-stage build: Separate build from runtime

FROM node:20-slim AS runtime

4. Create a non-root user

RUN groupadd -r nodejs && useradd -r -g nodejs nodejs

WORKDIR /app

5. Copy only what we need from the previous stage

COPY --from=dependencies --chown=nodejs:nodejs /app/node_modules ./node_modules
COPY --chown=nodejs:nodejs . .

6. Security: Drop capabilities & set user

USER nodejs

7. Health check so orchestrators know it's alive

HEALTHCHECK --interval=30s --timeout=3s CMD node health.js

EXPOSE 3000

8. Production grade runtime

CMD ["node", "server.js"]
Breaking Down the Differences
Let's put these two files side-by-side in a cage match.

Feature The "Before" (Horror) The "After" (Glory)
Base Image node:latest (floating, dangerous) node:20-slim (specific, smaller)
Caching Copies everything, invalidates cache always Copies package.json first, then code. Much faster rebuilds.
Permissions Runs as root Runs as nodejs user
Multi-stage No Yes (Separates build tools from runtime)
Dependencies npm install (includes dev dependencies) npm ci --only=production (exact versions, no dev junk)
What's inside Source code, .git, .env, local node_modules Only the bare necessities
The Actual Metrics (Real numbers from my app)
Metric Before After Improvement
Image Size 1.2 GB 210 MB 83% smaller
Build Time 45 seconds 6 seconds 87% faster
Vulnerabilities (npm audit) 23 high/critical 0 Infinite % better
Container Start Time 3.2 seconds 0.8 seconds 75% faster
The 5 Lessons I Learned (So You Don't Suffer)
If you take nothing else away from this post, remember these five golden rules:

Never use latest. Pin your versions. node:20-alpine or python:3.11-slim are your friends.

Leverage layer caching. Copy dependency files before your source code. Docker caches each step. If package.json hasn't changed, Docker reuses the cached npm install. This saves minutes.

Don't run as root. Add a user. USER appuser. It takes two lines and stops 90% of container exploits.

Multi-stage builds are magic. One Dockerfile can have multiple FROM statements. Use the first stage to compile/build, the final stage to only run the binary.

.dockerignore is non-negotiable. The COPY . . is evil. Create a .dockerignore file (same syntax as .gitignore) to exclude node_modules, .git, .env, and Dockerfile itself.

The Final Verdict
My first Dockerfile was a monolith of mistakes. It was a beginner's rite of passage—like burning toast or accidentally deleting a database in dev.

But the "after" version? That image is secure, tiny, and fast. It belongs in production.

Where are you on your Docker journey? Have you committed a "before" Dockerfile recently? Drop it in the comments so we can all cringe together (and then help you fix it).

Happy containerizing, and may your builds always be cache hits. 🐳

What is CI/CD? Explained Like You're 5 (And You Build Sandcastles)

Sohana Akbar — Tue, 28 Apr 2026 13:50:20 +0000

DevOps can sound scary. Let's fix that.

Imagine you love building sandcastles on the beach.

The Old Way (No CI/CD)
You spend 3 hours building a huge castle with towers and a moat. You don't show anyone until it's "done."

Then, the wave comes. Your castle falls apart. You cry. You have to start all over. 😭

The CI/CD Way
CI = Continuous Integration
This means: Add a little bit of sand, then check if it's still good.

Every 5 minutes, you add one new bucket of sand. Then you splash a little water to test if it stays firm. If it breaks? You fix it immediately while it's still small.

For adults: Developers merge small code changes often, and automated tests run every time.

CD = Continuous Delivery/Deployment
This means: As soon as a new piece is ready, put it on the castle automatically.

You finish one tower? Poof — a tiny helper (robot) places it on the real castle for everyone to see. No waiting.

For adults: Every change that passes tests is automatically released to users.

Why is this good?
No more all-nighters fixing giant messes. (Fix small problems as they happen.)

Your castle is always standing. (The software is always working.)

New towers arrive instantly. (Users get features faster.)

The Golden Rule
Small sand, often. Test always. Wave? No problem.

That's CI/CD. Now go build something that won't wash away. 🏰

P.S. If a 5-year-old can get it, so can your team.

Git commands I use daily (cheatsheet)

Sohana Akbar — Mon, 27 Apr 2026 15:18:36 +0000

Most Git tutorials throw an encyclopedia at you. But in reality, you’ll use the same ~10 commands every single day.

Here’s my no-fluff daily cheatsheet.

The absolute basics bash git clone # Download a repo git status # What changed? git add . # Stage everything git commit -m "fix: message" # Save changes
Working with remotes bash git pull --rebase # Get latest changes (cleaner history) git push # Upload your commits git fetch # See what changed without merging
Branching (daily) bash git branch # List branches (* = current) git checkout -b feat/x # Create + switch to new branch git switch main # Switch to main (newer syntax) git branch -d old-branch # Delete local branch
Fixing mistakes (no panic) bash git commit --amend -m "new message" # Edit last commit git reset HEAD~1 # Undo last commit (keep changes) git restore file.js # Discard unstaged changes git restore --staged . # Unstage everything
Seeing what happened bash git log --oneline --graph # Pretty commit tree git diff # Unstaged changes git diff --staged # Staged changes
The one "advanced" command I use daily bash git reflog # Show EVERYTHING you did (undo any mistake) Pro tip: Aliases Add these to ~/.gitconfig:

bash
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.st status
git config --global alias.lg "log --oneline --graph"
Now git st, git co main, git lg — saves hours.

Bottom line: You don’t need 50 commands. Master these, and you’re productive.

What’s your most-used Git command? 👇