DEV Community: Chaitanya Rai

When the mv Command “Loses” Your File in Linux — What Really Happened🚀

Chaitanya Rai — Mon, 10 Nov 2025 16:52:33 +0000

Have you ever used the Linux terminal to move a file with mv and then realized the file vanished? 😱

Don’t worry — your file isn’t gone. It’s just not where you thought it would be.

Let’s dive into what actually happens when the mv command “loses” your file — and how to avoid this in the future.

🧩 The Scenario

You’re working inside this directory:

/var/www/project/config/

And you run:

mv ssl_key.pem /backup

You expect your file to move into:

/var/www/project/config/backup/ssl_key.pem

But when you check… It’s not there! 😨

⚙️ The Root Cause: Absolute vs. Relative Paths
Here’s the catch — paths in Linux can be absolute or relative.

Absolute Path - /backup Starts from the root (/) of the system
Relative Path - backup Starts from your current working directory

So when you type:

mv ssl_key.pem /backup

Linux looks for a folder named /backup at the root of the system, not inside your current folder.

Your file actually ends up here:

/backup/ssl_key.pem

💡 Totally different location!

🤔 What If /backup Doesn’t Exist?
If that folder doesn’t exist, Linux assumes you’re renaming your file instead of moving it.

So ssl_key.pem becomes a new file named /backup, sitting in your root directory.

Yup — your file was just renamed, not moved.

🧭 How to Find the “Lost” File
You can check what happened with this command:

ls -ld /backup

Now check the output:

If it starts with d (like drwxr-xr-x), /backup is a directory, and your file is inside it.

ls -l /backup/

If it starts with - (like -rw-r--r--), /backup is a file, not a folder — your original file was renamed to /backup.

✅ The Right Way to Move It
If your goal was to move it to a subfolder within your current directory, use a relative path instead:

mv ssl_key.pem backup/

or, even safer:

mv ./ssl_key.pem ./backup/

Notice there’s no leading slash — that’s what makes it relative to your current directory.

🧠 Always Know Where You Are
Before running mv, it’s a good idea to check your current directory:

pwd

It shows your “present working directory,” helping you understand where a relative path will lead.

🧹 Recovering the File
If your file ended up somewhere unexpected, you can move it back like this:

# Case 1: File was renamed to /backup
mv /backup /var/www/project/config/ssl_key.pem

# Case 2: File is inside /backup/
mv /backup/ssl_key.pem /var/www/project/config/

✨ Final Thoughts
The Linux mv command is one of the simplest — yet most powerful — terminal tools.
But a single / can change everything.

Next time you move files, pause for a second and check your path.
That little detail can save you from hours of “where did my file go?” debugging. 🧠🐧

Simplify Database Configuration Across Environments (Dev, Staging, and Production)💡

Chaitanya Rai — Fri, 07 Nov 2025 09:30:47 +0000

If you’ve ever worked on a web application — whether in PHP, Laravel, Node.js, or Python — you’ve likely faced this common headache:

Every time you push code to staging or production, you have to manually change your database configuration — host, username, password, and database name.

That might sound small, but it’s a pain point for every developer and a frequent cause of bugs when someone accidentally pushes dev credentials to production. 😬

Let’s fix that once and for all.

🚨 The Problem

A typical setup looks like this:

// config.php

$servername = "localhost";
$username = "root";
$password = "";
$dbname = "myapp_dev";

When moving to staging or production, you edit those values manually:

// On staging

$servername = "staging-db-server";
$username = "staging_user";
$password = "staging_pass";
$dbname = "myapp_staging";

But this approach is risky:

❌ You might forget to change credentials before deployment.

❌ You could accidentally commit secrets to GitHub.

❌ It breaks automation and CI/CD pipelines.

✅ The Smart Fix: Environment-Based Configuration

The best practice is to separate configuration from code.
In short: your code stays the same in every environment — only your environment variables change.

🗝️ Step 1: Use Environment Variables

Instead of hardcoding credentials, read them dynamically.

embed Example (PHP):

$servername = getenv('DB_HOST');
$username = getenv('DB_USER');
$password = getenv('DB_PASS');
$dbname = getenv('DB_NAME');

Now, you only set these variables per environment — no code editing required!

⚙️ Step 2: Create .env Files

Each environment (dev, staging, prod) should have its own .env file.

.env.dev

DB_HOST=localhost
DB_USER=root
DB_PASS=
DB_NAME=myapp_dev

.env.staging

DB_HOST=staging-db-server
DB_USER=staging_user
DB_PASS=staging_pass
DB_NAME=myapp_staging

.env.prod

DB_HOST=prod-db-server
DB_USER=prod_user
DB_PASS=super_secret_password
DB_NAME=myapp_prod

📦 Step 3: Load .env Automatically

If you’re using Laravel, this happens automatically.

`For plain PHP or Node.js, use a helper library:

PHP → vlucas/phpdotenv

Node.js → dotenv`

Example (PHP):

require 'vendor/autoload.php';

$dotenv = Dotenv\Dotenv::createImmutable(__DIR__);
$dotenv->load();

$servername = getenv('DB_HOST');

🔄 Step 4: Auto-Detect Environment

You can even load different .env files automatically depending on the environment or domain:

$envFile = '.env.dev'; // default

if (strpos($_SERVER['HTTP_HOST'], 'staging') !== false) {
    $envFile = '.env.staging';
} elseif (strpos($_SERVER['HTTP_HOST'], 'myapp.com') !== false) {
    $envFile = '.env.prod';
}

$dotenv = Dotenv\Dotenv::createImmutable(__DIR__, $envFile);
$dotenv->load();

Now your app picks the right config automatically — no manual edits ever again.

🔒 Step 5: Secure Your .env Files

Never push .env files to GitHub!

Add this to .gitignore:

# Ignore environment files
.env*

Then, on each server, manually create the correct .env file — or better yet, inject environment variables through your CI/CD pipeline.

🧠 Why It Matters

✅ No more manual DB config changes
✅ No secrets in GitHub
✅ CI/CD-friendly deployments
✅ Works across all frameworks
✅ Clean, portable codebase

🗂 Example Folder Structure
myapp/
├── index.php
├── config.php
├── .env.dev
├── .env.staging
├── .env.prod
├── .gitignore
└── vendor/

🌐 Bonus Tip: Use Cloud Secrets

If you deploy on AWS, Google Cloud, or Render, you can skip .env files entirely!
Store your DB credentials as environment secrets in your cloud console — your app will automatically read them at runtime.

This keeps your deployment 100% secure and automated. 🔐

🏁 Final Thoughts

Managing different database credentials for each environment shouldn’t slow you down.

By using environment variables and .env files, you can:

Simplify deployments
Protect credentials
Keep your project portable and clean

Whether you’re using Laravel, Node.js, or plain PHP, this approach saves hours and prevents “works-on-my-machine” moments. 💪

✨ Pro tip: Combine this setup with a CI/CD pipeline (like GitHub Actions or Cloud Build) to automatically deploy with the correct environment — no manual config edits ever again!

💬 What’s your approach?
How do you manage DB credentials across environments in your projects?
Share your setup in the comments 👇

Debugging Memory Leaks in Node.js and PHP 🧠

Chaitanya Rai — Tue, 04 Nov 2025 07:21:02 +0000

🧠 Debugging Memory Leaks in Node.js and PHP — Track Down Hidden Performance Killers

Have you ever restarted your app every few hours because it was “just using too much memory”? 😅

That’s usually a memory leak — when your application keeps holding onto data it no longer needs.

In this guide, we’ll explore how to detect and fix memory leaks in both Node.js and PHP, using practical tools like Chrome DevTools and Xdebug.

💡 What is a Memory Leak?

A memory leak happens when your program allocates memory and never releases it, even when that data is no longer used.

Over time, memory usage grows, performance slows, and eventually — 💥 your process crashes.

Imagine this simple analogy:

You’re putting items into a bag, but never taking anything out.

Eventually, the bag bursts.

🧩 Common Causes

Cause	Example
Unreferenced objects kept alive	Global variables holding large data
Event listeners not removed	`element.addEventListener()` without cleanup
Caching gone wrong	Storing too much in memory-based cache
Long-running loops or intervals	`setInterval` without `clearInterval`
Circular references	Two objects referencing each other indefinitely

🟢 Debugging Memory Leaks in Node.js

1️⃣ Check memory usage in real time

node --inspect yourApp.js

Then open chrome://inspect in Chrome → click "Memory" tab → take a heap snapshot.

You can compare snapshots over time to see which objects keep growing.

2️⃣ Use process.memoryUsage()

You can log memory usage periodically:

setInterval(() => {
  const used = process.memoryUsage();
  for (let key in used) {
    console.log(`${key} ${(used[key] / 1024 / 1024).toFixed(2)} MB`);
  }
}, 5000);

If the heap keeps increasing even under a steady workload, you likely have a leak.

3️⃣ Detect leaks with clinic.js or memwatch-next

npm install -g clinic
clinic doctor -- node app.js

npm install memwatch-next

const memwatch = require('memwatch-next');
memwatch.on('leak', (info) => console.log('Memory leak detected:', info));

##🐘 Debugging Memory Leaks in PHP

PHP scripts usually die after each request, so memory leaks are less common — but long-running workers (like Laravel Queues or Daemon scripts) can still leak memory.

1️⃣ Enable Xdebug profiling

Add this in php.ini:

xdebug.mode=profile
xdebug.output_dir="/tmp/xdebug_profiles"

Then run your script. Use tools like QCacheGrind or Webgrind
to visualize memory usage and function calls.

2️⃣ Monitor memory in code

You can track memory usage directly:

echo memory_get_usage(true) . " bytes\n";

Watch for continuous growth in long loops or workers:

while (true) {
    doSomething();
    echo memory_get_usage() . "\n";
    sleep(1);
}

3️⃣ Common PHP Leak Sources

Unclosed database connections
Huge arrays kept in memory
Static variables holding data between iterations
Recursive functions not returning

To fix these, always:

Unset unused variables (unset($var))
Close DB or file handles
Use generators (yield) for large datasets

🧹 Prevention Strategies

✅ Avoid global variables
✅ Use weak references or caches with size limits
✅ Always remove event listeners
✅ Test in a long-running environment (not just one request)
✅ Automate leak checks in staging

🚀 Wrapping Up

Memory leaks are sneaky — they don’t crash your app immediately but slowly drain resources until everything slows down.
By using profiling tools, logs, and heap snapshots, you can catch them before they reach production.

Remember:

Debugging is not just fixing bugs — it’s understanding why they happened.

💬 Have you ever debugged a real memory leak?
Share your story (and pain 😅) in the comments!

Why Your Docker Ubuntu Container Exits Immediately (and How to Fix It)🐳

Chaitanya Rai — Fri, 31 Oct 2025 07:18:38 +0000

If you’ve ever tried running an Ubuntu container on macOS (or any system) and noticed that it stops immediately, you’re not alone.

You might see something like this in Docker Desktop:

✅ Docker is running (green icon)

🧱 Image is downloaded

❌ Container won’t stay alive

Let’s break down why that happens — and how to fix it like a pro 💪

🧩 The Problem

You pull the image:

docker pull ubuntu

Then try to run it:

docker run ubuntu

But when you check:

docker ps -a

You see:

CONTAINER ID   IMAGE     COMMAND       STATUS                     PORTS   NAMES
123abc456def   ubuntu    "/bin/bash"   Exited (0) 3 seconds ago   ---     bold_blackburn

👉 It starts and exits immediately!
You might wonder: “Why is my container not staying alive?”

💡 The Reason

A Docker container only runs as long as its main process is running.

When you start the ubuntu image, it runs /bin/bash by default.
But if you don’t attach to it interactively, that shell exits right away.

Think of it like opening a terminal window that instantly closes because you didn’t type anything.

⚙️ The Fix — Run It Interactively

Start the container with an interactive shell:

docker run -it ubuntu

You’ll now drop into a shell like:

root@b7f9c4f8f9e0:/#

🎉 Boom! The container stays alive because you’re inside it.

You can explore, install packages, and do anything:

apt update && apt install curl

When you type exit, it will stop again — as expected.

🏷️ Add a Name to Manage It Easily

Add a friendly name to your container:

docker run -it --name myubuntu ubuntu

Now you can easily restart or attach later:

docker start -ai myubuntu

No need to remember a random container ID!

🌀 Keep It Running in the Background

If you want your Ubuntu container to stay alive in the background, you need a process that never ends.
For example:

docker run -d --name myubuntu ubuntu tail -f /dev/null

Here’s what’s happening:

-d →detached mode (runs in background)

tail -f /dev/null →keeps the process alive forever

Now check:

docker ps

You’ll see your container happily running 😄

🔍 Summary

Mode	Command	Behavior
Basic	`docker run ubuntu`	Starts and exits immediately
Interactive	`docker run -it ubuntu`	Opens shell, stays alive
Named	`docker run -it --name myubuntu ubuntu`	Easier to manage
Background	`docker run -d --name myubuntu ubuntu tail -f /dev/null`	Persistent background container

💬 Final Thoughts

So, the reason your Ubuntu container wasn’t running wasn’t a Docker Desktop bug — it was just Docker doing exactly what it should.
Containers are designed to run a single process, not act as full-blown virtual machines (though you can make them behave like one 😉).

If you remember this golden rule 👇

🧠 “No running process → container exits.”

…you’ll never be confused again.

Fixing “Unable to Create Directory wp-content/uploads” Error in WordPress on macOS (XAMPP)🧠

Chaitanya Rai — Tue, 28 Oct 2025 04:43:05 +0000

🖼️ Problem Overview

If you’re developing a WordPress site locally on macOS using XAMPP, you might encounter this frustrating error while uploading media:

“Unable to create directory wp-content/uploads/2025/10. Is its parent directory writable by the server?”

This issue appears when WordPress doesn’t have permission to create or write to the uploads directory inside the wp-content folder.

Let’s walk through the cause, diagnosis, and step-by-step fix.

🔍 Step 1: Understanding the Cause

WordPress saves uploaded images and files inside:

/wp-content/uploads/[year]/[month]

If WordPress cannot:

create these folders, or

write files into them

you’ll get this permission error.

The root cause on macOS (especially when using XAMPP) is usually incorrect file ownership or permissions — the web server process runs as a different user than your macOS login.

⚙️ Step 2: Identify the Web Server User

First, we need to find out which user the Apache web server runs as.

Open Terminal and run:

ps aux | grep httpd

You’ll see output similar to this:

_tempuser         4121   0.0  0.0 410724400   1424 s000  S+    7:01PM   0:00.00 grep httpd
daemon            4069   0.0  0.0 34476672   3488   ??  S     7:00PM   0:00.01 /Applications/XAMPP/xamppfiles/bin/httpd ...
root              4023   0.0  0.1 34476672  14940   ??  Ss    7:00PM   0:00.14 /Applications/XAMPP/xamppfiles/bin/httpd ...

Here, daemon is the key user — that’s the account running Apache under XAMPP on macOS.

🧰 Step 3: Fix File Ownership and Permissions

Navigate to your WordPress project folder inside XAMPP’s htdocs directory.
Example:

cd /Applications/XAMPP/xamppfiles/htdocs/mywordpress

Then give ownership and permissions to the correct web server user:

sudo chown -R daemon wp-content/uploads
sudo chmod -R 775 wp-content/uploads

Explanation:

chown changes ownership to the Apache user (daemon).

chmod 775 allows both the owner and group to write, while everyone else can read.

If you want to apply this to the whole wp-content folder (recommended for local dev):

sudo chown -R daemon wp-content
sudo chmod -R 775 wp-content

🔁 Step 4: Restart Apache

Restart Apache from the XAMPP Control Panel or run this command:

sudo /Applications/XAMPP/xamppfiles/xampp restartapache

Then reopen your browser and try uploading an image again from Media → Add New in your WordPress dashboard.

✅ It should now upload successfully!

🧾 Step 5: Check PHP Upload Configuration (Optional but Important)

If uploads still fail or get stuck, the issue may be with your PHP upload settings.

Create a file named phpinfo.php in your WordPress directory:

<?php phpinfo(); ?>

Open it in your browser:

http://localhost/phpinfo.php

Check for these key values:

Setting Description Recommended
file_uploads Enables uploads On
upload_tmp_dir Temporary upload directory Should have a valid path
upload_max_filesize Max size of a single file 64M (or higher)
post_max_size Max size for total POST data 128M (or higher)

If upload_tmp_dir is empty, edit your PHP config file:

sudo nano /Applications/XAMPP/xamppfiles/etc/php.ini

Uncomment or add this line:

upload_tmp_dir = "/Applications/XAMPP/xamppfiles/temp"

Then restart Apache again:

sudo /Applications/XAMPP/xamppfiles/xampp restartapache

🧠 Why This Happens

On macOS, each process runs under its own user account.

You (the logged-in developer) are one user.

Apache (from XAMPP) runs as daemon.

When WordPress tries to create directories under your account’s ownership, Apache doesn’t have permission unless explicitly granted.
Hence, the fix is about aligning permissions between you and the web server.

💡 Bonus Tips

Always use relative paths for uploads. Check your wp-config.php and remove any hardcoded UPLOADS definitions like:

define('UPLOADS', '/Users/username/.../wp-content/uploads');

Instead, let WordPress manage it automatically.

Keep wp-content/uploads writable only for local development.
On production servers, consider more restrictive permissions (e.g., 755 with proper ownership).

After fixing the issue, delete the temporary phpinfo.php file for security.

🚀 Final Thoughts

Fixing file upload errors in local WordPress setups is often about understanding how your server runs under the hood.
In macOS + XAMPP environments, simply changing the ownership of your wp-content/uploads directory to the daemon user and ensuring writable permissions resolves the issue immediately.

Once set up properly, you’ll be able to upload themes, plugins, and images without a hitch.

Debugging Production: How to Fix Bugs Without Breaking Everything 🌐

Chaitanya Rai — Thu, 23 Oct 2025 14:55:05 +0000

If you’ve ever pushed a bug to production (and who hasn’t?), you know that cold sweat moment when an error alert hits your Slack at 2 AM.

Debugging in production isn’t like fixing code on your laptop — there’s pressure, limited visibility, and real users depending on you. But with the right mindset and tools, you can handle it without breaking more things.

Let’s walk through a safe and strategic way to fix production issues — step by step.

🪵 1. Start by Reading the Logs — Carefully

Your logs are your first line of truth. Before touching the code or restarting anything, observe what’s actually happening.

✅ Tips:

Filter logs by request ID, timestamp, or user session.
Look for error patterns — repeating exceptions, failed API calls, or database connection errors.
Avoid drowning in noise: focus on recently changed modules.

🔍 Pro tip: Always include structured logs (JSON format, with timestamps, log levels, and trace IDs). It makes debugging 10x faster when your production system is busy.

🚩 2. Use Feature Flags to Limit the Blast Radius

When debugging a live app, never deploy experimental fixes directly.

This allows you to:

Turn features on or off instantly.
Roll out to a small % of users.
Roll back safely if something breaks.

Feature flags turn debugging from risky deployments into reversible switches.

⚙️ Example:

if (isFeatureEnabled('newCheckoutFlow')) {
    runNewCheckout();
} else {
    runOldCheckout();
}

🔄 3. Compare Versions — What Changed?

One of the smartest debugging habits: compare the current version with the last known good one.

You can:

Use git diff to check for recent code changes.
Match timestamps of new errors with deployment times.

🧠 80% of production bugs trace back to recent changes — even a single config tweak can ripple across your system.

🧪 4. Shadow Testing: Debug Without Impacting Real Users

Shadow testing (also called mirroring) is a lifesaver. It means sending a copy of real traffic to a test version of your app — without affecting actual users.

You can test new fixes safely and see how they behave under real-world conditions.

✅ Use it to:

Validate bug fixes.
Measure performance differences.
Detect unexpected side effects.

🧯 5. Safe Hotfix Deployment

Once you’ve confirmed the fix:

Deploy in stages.
Monitor metrics like response time, CPU, and error rates immediately.
If metrics spike — roll back instantly.

🧩 Always deploy hotfixes with the same process as regular releases

🧘 6. Stay Calm, Log Everything, Learn

Production debugging can feel chaotic, but post-incident learning turns chaos into improvement.

After you fix the bug:

Document what went wrong and how you found it.
Add new alerts or tests to catch similar issues earlier.
Share lessons in your team’s retro — no blame, just learning.

Debugging production isn’t about perfection — it’s about control under pressure.

🚀 Final Thoughts

Debugging production code is like defusing a bomb in slow motion — the key is precision, not panic.

If you:

Observe first (logs),
Contain impact (feature flags),
Verify (shadow testing),
Deploy safely (hotfix rollout),

…you’ll go from firefighting to fire prevention.

Remember: every production bug teaches you how to build systems that fail more gracefully next time.

💬 What’s your go-to strategy when something breaks in production? Share your tips below 👇

Integrating Forminator into Your Custom WordPress Page (and Fixing Visibility Issues) 🛠️

Chaitanya Rai — Fri, 26 Sep 2025 03:54:52 +0000

✅ Introduction
Forminator is a powerful and flexible WordPress plugin for building forms, polls, and quizzes. It offers drag-and-drop ease with advanced features like conditional logic, spam protection, and even payment gateways.

But what if you’ve built a custom page template in your theme and the Forminator form doesn’t appear properly?
You’re not alone — this often happens when theme styles override the form or the template is missing essential WordPress functions and assets.

In this guide, you’ll learn how to:

Embed a Forminator form inside a custom template
Fix invisible or broken forms with CSS
Debug deeper issues like missing scripts or plugin conflicts

🧩 Step 1: Embed the Forminator Form Using a Shortcode

Suppose you’ve created a custom template file like page-contact.php.

Add the Forminator shortcode inside your custom HTML/PHP markup:

<div class="custom-form">
    <?php echo do_shortcode( '[forminator_form id="123"]' ); ?>
</div>

🔹 Tip: Replace 123 with your actual Forminator form ID.
Find it in: WordPress Admin → Forminator → Forms → Hover over the form name.

If you prefer a dynamic ID from a custom field, escape it for safety:

echo do_shortcode( '[forminator_form id="' . esc_attr( $form_id ) . '"]' );

**
🎨 Step 2: Fix Visibility Issues with Scoped CSS**

Sometimes the form is technically present but hidden due to theme CSS conflicts.

Add this to your style.css or Customizer → Additional CSS:

/* Scope to this page’s wrapper to avoid affecting other pages */
.custom-form .forminator-ui,
.custom-form .forminator-custom-form,
.custom-form .forminator-design--default {
    display: block !important;
    visibility: visible !important;
    opacity: 1 !important;
    max-height: 100% !important;
}

🔎 Use your browser dev tools (F12 → Inspect) to check which CSS rules are overriding Forminator’s default styles.

🔍 Step 3: Load WordPress Assets in Your Template

If the form still doesn’t load or looks broken, make sure your template includes WordPress’s standard hooks and assets.

At the top of your template:

<?php
/* Template Name: Custom Form Page */
get_header(); // Loads header.php, which should call wp_head()
?>
<!-- Your custom content -->
<?php
get_footer(); // Loads footer.php, which should call wp_footer()

Most themes already include wp_head() and wp_footer() inside header.php and footer.php.
Only call these functions directly if you’re building a blank template.

🛠️ Step 4: Debug JavaScript Errors

Still blank? Open the browser console (F12 → Console) and check for:

Uncaught ReferenceError
jQuery is not defined
404 errors for missing JS or CSS files

If you see these, it usually means scripts aren’t being enqueued or a plugin is interfering.

🚫 Bonus: Check for Plugin or Cache Conflicts

Performance plugins (minification, lazy loading, caching) can block Forminator assets.

Try:

Disabling lazy-loading for Forminator forms
Excluding Forminator from CSS/JS minification
Temporarily deactivating other plugins to find conflicts
Flush permalinks (Settings → Permalinks → Save Changes) to refresh rewrite rules

✅ Final Result

Once everything is set up, your rendered page will look like:

<div class="custom-form">
    <!-- Forminator Form Rendered Here -->
    <form class="forminator-custom-form"> ... </form>
</div>

No more hidden inputs, missing scripts, or CSS ghosts. 🎯

🧠 Conclusion

Integrating Forminator into a custom WordPress page is straightforward, but rendering issues can trip up developers.
By ensuring that:

The shortcode is placed correctly
CSS conflicts are scoped and overridden
All necessary WordPress assets are loaded

…you can build beautiful, interactive forms even in fully custom templates — without sacrificing theme flexibility or performance.

Mastering the Art of Debugging: Strategies, Tools, and Mindset for Every Developer

Chaitanya Rai — Wed, 24 Sep 2025 05:55:07 +0000

No matter how experienced you are, bugs are inevitable. They sneak into code during late-night coding sessions, sudden requirement changes, or even the simplest refactor.
What separates a frustrated developer from a confident one isn’t the absence of bugs—it’s the ability to debug effectively.

This guide walks you through the mindset, techniques, and tools every developer should know to track down and fix issues with confidence.

1. Testing vs. Debugging: Know the Difference

Before diving in, it’s important to separate testing from debugging:

Testing is about detecting problems. It tells you something is wrong by running automated tests, QA checks, or manual verifications.

Debugging is about diagnosing and fixing those problems. It’s the detective work that starts once a test fails or a user reports a bug.

Think of testing as the alarm and debugging as the investigation.

2. Breakpoints: Your First Line of Defense

A breakpoint pauses code execution at a specific line so you can inspect variable values, memory state, and control flow in real time.

When to use a breakpoint:

When you need to inspect the exact state of a program at a critical moment.

To follow the logic step by step and see where it diverges from expectations.

Most IDEs (VS Code, IntelliJ, PyCharm, etc.) make it easy to set breakpoints and step through code without guesswork.

3. Logs, Error Messages, and Stack Traces: Reading the Clues

Logs and stack traces are your breadcrumbs through the forest.

Logs reveal what happened leading up to the error. Use different levels (info, warn, error) for clarity.

Error messages often contain keywords or codes that hint at the root cause.

Stack traces show the exact chain of function calls when the error occurred.

💡 Tip: Always log enough context (inputs, timestamps, environment details) to reproduce issues without flooding your console.

4. Structured Debugging Approaches

When staring at a mysterious bug, a clear strategy saves time.

🔹 Divide and Conquer

Split the problem space into smaller sections. Isolate components or modules to see where the bug disappears.

🔹 Binary Search

If the issue arises in a long block of code or a large data set, repeatedly halve the search space until you locate the faulty line.

🔹 Rubber Duck Debugging

Explain your code line by line to a “rubber duck” (or a teammate, or even a text document).
Often, the act of explaining reveals the flaw before the listener says a word.

5. Debugging with Version Control (Git)

Version control isn’t just for collaboration—it’s a debugging powerhouse.

Git bisect: Automatically find the commit where a bug was introduced by performing a binary search through commit history.

Blame/Annotate: Identify who last changed a particular line of code to gather context.

Branching: Experiment with fixes safely without risking production code.

6. Code Reviews and Collaborative Debugging

Debugging isn’t always a solo activity.
Peer code reviews catch issues before they hit production and bring fresh eyes to tricky problems.
Pair programming or quick brainstorming sessions can reveal oversights you might miss after hours of staring at the same file.

7. When Bugs Stay Unfixed: Risk, Legacy, and Cost

Not every bug deserves a fix.
Engineering is about trade-offs, and sometimes the cost of a fix outweighs the benefit.

Common reasons to leave a bug unfixed:

Low Impact: The bug doesn’t affect critical functionality.

High Risk: Fixing it might break a fragile legacy system.

Cost/Benefit: Time and resources are better spent on new features or high-priority issues.

Documenting these decisions is crucial for future teams to understand the context.

8. Cultivating the Debugging Mindset

Effective debugging isn’t just about tools—it’s about mindset:

Stay curious: Treat bugs as puzzles, not annoyances.

Remain calm: Frustration clouds judgment.

Be systematic: Change one thing at a time, and track your steps.

Over time, you’ll develop an intuition for where bugs hide, but a structured process ensures you don’t rely on luck.

Final Thoughts

Debugging is more than a technical skill—it’s an art form that combines logic, patience, and creativity.
By mastering breakpoints, logs, version control, and structured strategies, you’ll transform bugs from frustrating roadblocks into valuable learning opportunities.

Next time a mysterious error pops up, don’t panic.
Grab your debugger, trust your process, and start the hunt.

✍️ Have your own debugging war stories or favorite tips? Share them in the comments—every bug has a lesson to teach.

Deleting the First Git Commit and Resolving Rebase Issues

Chaitanya Rai — Tue, 27 May 2025 15:40:19 +0000

Introduction

Deleting the first commit in a Git repository and handling rebase issues can be tricky, especially when you end up in a situation where Git refuses to move back to a previous state. In this blog, we will address common scenarios related to deleting the first commit and resolving errors that occur during a rebase.

Why Is Deleting the First Commit Challenging?

The first commit in a Git repository is a unique entity. Since it’s the initial commit, there is no previous commit to revert to. Consequently, commands like git reset --hard HEAD~1 or git reset --hard HEAD^ result in errors like:

fatal: ambiguous argument 'HEAD~1': unknown revision or path not in the working tree.

This happens because Git cannot find a previous commit from which to reset. In this case, it’s essential to handle the situation differently.

Deleting the Only Commit from a Branch

If you have just one commit and want to delete it completely, follow these steps:

Step 1: Navigate to Your Branch

git checkout master

Step 2: Delete the Commit

To completely remove the commit, use:

git update-ref -d HEAD

Step 3: Clean Up Untracked Files (if needed)

git clean -fdx

Step 4: Push the Changes

git push origin master --force

This will clear the commit history, giving you a clean branch.

Resolving Git Rebase Errors

Sometimes, while trying to delete or modify commits, you might end up in a rebase state. A common error message is:

On branch main
No commands done.
Next command to do (1 remaining command):
   noop

This means your branch is stuck in a rebase, often because it was not completed or aborted correctly.

Option 1: Complete the Rebase

git rebase --continue

Option 2: Abort the Rebase

git rebase --abort

Once completed or aborted, you can check the branch status again:

git status

Starting Fresh After Deleting Commits

Once your branch is clean and the unwanted commit is gone, you can create a new initial commit:

git add .
git commit -m "Initial commit after cleanup"
git push origin master --force

Conclusion

Deleting the first commit in Git can be tricky due to the lack of previous history. Understanding how to properly reset or update the branch is crucial to avoiding errors. Additionally, being familiar with rebase continuation and abort commands can help when your branch gets stuck. By following the steps outlined here, you can confidently manage your Git history without losing essential work.

Step-by-Step: Creating a Custom Page Template in WordPress🧑‍💻

Chaitanya Rai — Fri, 16 May 2025 14:15:51 +0000

In WordPress, there are times when you might want a page that looks and functions completely differently from the rest of your site. A common use case is an Accessibility page that demands a specific layout, style, or behavior. This tutorial walks you through creating a custom page template that uses a separate header and footer and unique styling.

🧩 Why Use a Custom Page Template?
Using a custom page template allows you to:

Apply unique styling to a specific page.

Load custom JavaScript and CSS independent of the main theme.

Use different headers and footers, which are useful for accessibility pages or landing pages.

🛠️ Step 1: Create the Custom Page Template
Navigate to your theme directory:

wp-content/themes/your-theme/

Create a new file named:

page-accessibility.php

Add the following code:

<?php
/* Template Name: Accessibility Page */
get_header('accessibility');
?>

<div class="accessibility-content">
    <h1><?php the_title(); ?></h1>
    <?php the_content(); ?>
</div>

<?php get_footer('accessibility'); ?>

🧱 Step 2: Create Custom Header and Footer
Create two new files in your theme directory:

`- header-accessibility.php

footer-accessibility.php`

Example: header-accessibility.php

<!DOCTYPE html>
<html <?php language_attributes(); ?>>
<head>
    <meta charset="<?php bloginfo('charset'); ?>">
    <title><?php wp_title(); ?></title>
    <?php wp_head(); ?>
</head>
<body>
<header class="accessibility-header">
    <h1>Accessibility Page</h1>
</header>

🧱 Create footer-accessibility.php
Add a matching footer for this layout:

<footer class="accessibility-footer">
    <p>&copy; <?php echo date('Y'); ?> My Accessibility Page</p>
</footer>

<?php wp_footer(); ?>
</body>
</html>

🎨 Step 3: Enqueue Custom Styles and Scripts
Open your functions.php and add the following:

function accessibility_custom_scripts() {
    if (is_page_template('page-accessibility.php')) {
        wp_enqueue_style(
            'accessibility-style',
            get_stylesheet_directory_uri() . '/css/accessibility.css'
        );
        wp_enqueue_script(
            'accessibility-script',
            get_stylesheet_directory_uri() . '/js/accessibility.js',
            array('jquery'),
            null,
            true
        );
    }
}
add_action('wp_enqueue_scripts', 'accessibility_custom_scripts');

📂 Step 4: Create CSS and JS Files

In your theme directory:

`- Create a css/ folder → Add accessibility.css

Create a js/ folder → Add accessibility.js`

Example CSS (css/accessibility.css):

body {
    background-color: #f4f4f4;
    font-size: 18px;
}

.accessibility-header {
    background-color: #333;
    color: #fff;
    padding: 20px;
}

Example JS (js/accessibility.js):

document.addEventListener("DOMContentLoaded", function () {
    alert("Accessibility page loaded!");
});

📝 Step 5: Assign Template in WordPress
Go to your WordPress Dashboard

Navigate to Pages **→ **Add New or edit an existing page

In the right sidebar under Page Attributes → Template, select:

Accessibility Page

Publish the page — and you're done!

✅ Conclusion
By creating a custom page template, you gain full control over the layout, styles, and functionality of specific pages on your site. This is incredibly useful for:

`- Accessibility-specific content

Landing pages
Unique layout requirements`

It’s a clean, modular approach that keeps your theme organized and maintainable.

SSH Error Explained: Permission Denied (publickey) — And How We Solved It 🔐

Chaitanya Rai — Tue, 13 May 2025 08:04:13 +0000

When trying to SSH into a newly created Linux server, you might run into a common error like this:

$ ssh user@your-server-ip
The authenticity of host 'your-server-ip' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Any other names do not know this key.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'your-server-ip' (ED25519) to the list of known hosts.
user@your-server-ip: Permission denied (publickey).

This error simply means: “SSH couldn’t find a valid key to authenticate you.”

✅ What Actually Worked
Instead of using just:

ssh ubuntu@your-server-ip

You used the correct approach by providing the private key file:

ssh -i /path/to/your-key.pem ubuntu@your-server-ip

And this worked — because the server was expecting authentication via a specific private key (.pem file), not a default key from ~/.ssh/id_rsa.

🔍 Why This Happens
Cloud providers (like AWS, Google Cloud, Azure, etc.) often use key-based authentication only for better security. When you create a VM or instance, you’re often required to either:

Upload your public key, or

Download a .pem file that matches the server's authorized key

If you try to SSH without specifying the .pem file, the SSH client defaults to using standard key files like ~/.ssh/id_rsa, which likely don’t match what the server expects.

🛠️ How to Avoid This in the Future
You can either:

Always specify the key manually with -i

Add the key to your SSH agent so it's picked up automatically:

ssh-add /path/to/your-key.pem

🧠 Pro Tip
Make sure your .pem file has the correct permissions:

chmod 600 your-key.pem

This keeps your key file secure and prevents SSH from refusing to use it.

How to Create an AWS Account for Individuals: A 5-Step Guide

Chaitanya Rai — Mon, 12 May 2025 16:53:26 +0000

Amazon Web Services (AWS) is one of the most powerful cloud platforms in the world, enabling individuals and businesses to run everything from simple websites to complex machine learning applications. If you're just starting your cloud journey, the first step is setting up your own AWS account. This blog will walk you through how to create an individual AWS account in just five simple steps.

🚀 Step 1: Visit the AWS Sign-Up Page
Start by going to the AWS homepage and clicking on the "Create an AWS Account" button.
Make sure to use a personal email address that you have access to, as AWS will send important communications and verification emails.

👉 Tip: Use an email you plan to keep long-term, especially if you want to build a portfolio or work on certifications.

🧑‍💻 Step 2: Enter Personal Account Details
In this step:

Choose "Personal Account" (not "Professional") when prompted.

Fill in your full name, email address, and account name (this can be anything; e.g., “CR AWS Playground”).

Create a strong password and confirm it.

Click *Continue * to proceed.

💳 Step 3: Add Payment Information
AWS requires a credit or debit card for account creation, even if you're only using free-tier services. Don’t worry — you won’t be charged as long as you stay within the free usage limits.

Enter your card details and billing address.

AWS may place a temporary $1 charge to verify your card, which will be refunded shortly.

☎️ Step 4: Identity Verification
Next, AWS will verify your identity via SMS or a phone call:

Select your country code and enter a phone number.

Choose either text message or a voice call.

Enter the verification code you received.

Once verified, click Continue.

🛠️ Step 5: Choose a Support Plan and Sign In
AWS offers several support plans. For individual use or learning:

Select the Basic Support Plan (which is free).

Click Complete Sign Up.

Once your account is created, you’ll be directed to the AWS Management Console where you can sign in with your new credentials and start using services like EC2, S3, and Lambda.

✅ You're All Set!
Congratulations! You now have your own AWS account. From here, you can explore services, start small projects, or follow along with tutorials to learn more about cloud computing.

If you're new to AWS, here are a few great starting points:

AWS Free Tier page: See what you can use for free
AWS Educate or Skill Builder: For free learning resources
Create your first EC2 instance or S3 bucket

Final Tip: Always keep an eye on the Billing Dashboard in the AWS Console to make sure you’re not accidentally incurring charges.