DEV Community: Harsh Pandhe

Why I’m Learning Blender to Build Better Autonomous Systems 🚀

Harsh Pandhe — Tue, 12 May 2026 10:54:04 +0000

For robotics engineers, simulation environments are just as important as the code running inside the robot.

As developers, we often spend our lives inside:

terminals
IDEs
Jupyter notebooks

Our world is built from:

logic
loops
APIs
data structures

But while working on Project ASCEND, I eventually hit a major wall:

The Environment Problem.

How do you properly test drone navigation logic without crashing a real-world prototype every five minutes?

The answer lies in:

Digital Twins
High-fidelity simulations
Synthetic environments

So instead of relying on stock assets, I recently started building my own Martian simulation sandbox in Blender.

🚀 The Goal: A Stylized Martian Testbed

I didn’t need a perfect 1:1 replica of Mars.

I needed an environment that was:

Computationally Efficient

Low-poly assets that wouldn’t destroy frame rates during simulation runs.

Efficient rendering matters when:

testing SLAM pipelines
running reinforcement learning
generating synthetic datasets
simulating autonomous agents

Geometrically Challenging

I intentionally added:

vertical pillars
jagged rocks
uneven terrain
debris shards

to stress-test:

obstacle avoidance
path planning
depth estimation

A "perfect" environment teaches robots nothing.

Edge cases do.

Visually Consistent

I also optimized the environment for:

visual odometry
depth perception
feature tracking

using:

high-contrast lighting
exaggerated shadows
strong silhouettes

because perception systems depend heavily on environmental consistency.

🛠 The Learning Curve: From Python to Poly-Editing

Coming from a pure programming background, Blender initially felt like an alien spacecraft dashboard.

But eventually something clicked:

3D environments are just structured data.

Vertices.

Normals.

Meshes.

Transforms.

Once I started viewing Blender as an environment-generation engine instead of an art tool, the learning process became much easier.

My Workflow

Low-Poly Modeling

I used simple primitives like:

Cylinders
Ico-spheres
Planes

combined with Blender’s Decimate Modifier to achieve a stylized low-poly aesthetic.

This helped keep scenes lightweight while still visually readable.

Procedural Terrain Displacement

Using noise textures and displacement modifiers, I warped flat geometry into:

dunes
cliffs
rocky terrain

This created a more natural Martian landscape without manually sculpting every surface.

Lighting the Red Planet

Mars has a very distinct visual feel.

To mimic that, I used:

a single directional sun lamp
warm orange/red tones
sharp shadow contrast
higher light intensity

The result looked stylized, but also became useful for testing perception systems under harsh lighting conditions.

Camera Rigging

To simulate drone flyovers consistently, I created camera rigs using:

Bezier curves
Follow Path constraints

This allowed repeatable trajectories for testing navigation and visual tracking algorithms.

Repeatability is critical when debugging autonomous systems.

📈 Iteration: v1 → v3

In software engineering, we iterate on features.

In simulation engineering, we iterate on environmental complexity.

v1

The first version was extremely simple:

flat terrain
a few cylinders
minimal obstacles

Good enough for proof-of-concept testing.

But far too easy for navigation systems.

v3 (Current Version)

The latest environment includes:

varied terrain elevation
debris shards
complex shadows
irregular obstacle geometry
varied rock sizes

These additions introduced realistic edge cases:

Does the drone mistake a shard for a landing hazard?
Do shadows confuse depth estimation?
Can obstacle avoidance handle narrow passages?

By building the world myself, I can intentionally inject test cases directly into the environment.

💡 Engineering Takeaway

Learning Blender isn’t just about creating cool visuals.

For robotics and AI engineers, it’s about:

simulation
synthetic data generation
digital twins
environment control

If I can build a scene in Blender, I can generate:

thousands of labeled images
synthetic training datasets
depth maps
segmentation masks
navigation scenarios

for machine learning systems.

That’s incredibly powerful.

Why This Matters for Autonomous Systems

Real-world robotics is expensive.

Simulation allows us to:

fail safely
iterate faster
scale testing
generate data cheaply

The better your simulated environments become, the more robust your real-world systems become.

Simulation isn’t a side tool anymore.

It’s part of the core engineering stack.

Final Thoughts

Project ASCEND is slowly teaching me that modern robotics engineers need to think beyond code.

We’re no longer just writing algorithms.

We’re building:

environments
datasets
simulations
digital ecosystems

And tools like Blender are becoming surprisingly important in that workflow.

Discussion

For those working in:

robotics
simulation
game engines
AI systems

what does your simulation stack look like?

Do you use:

Blender?
Gazebo?
Isaac Sim?
Unreal Engine?
Unity?

And how much effort do you invest into your environments compared to your actual autonomous logic?

I’d genuinely love to hear how other engineers approach simulation-first development.

Architecting for Trust: Building a Multi-Role Admin Platform with React and Express

Harsh Pandhe — Fri, 08 May 2026 16:52:59 +0000

How I designed a secure multi-role admin platform with JWT authentication, layered authorization, and role-specific workflows for Project Morpheus.

When building an admin tool like Project Morpheus, the biggest security threat usually isn’t an external hacker.

It’s Privilege Escalation.

In a system with four distinct roles:

Admin
Warden
Auditor
Desk Operator

how do you ensure that a desk volunteer can’t accidentally—or intentionally—delete audit logs or modify hostel configurations?

Here’s how I architected a robust Role-Based Access Control (RBAC) system using React and Express.

1. The "Single Point of Truth" Authentication Model

The foundation of the architecture is JWT-based authentication.

When a user logs in, the backend issues a signed token containing:

userId
role
hostelId (for Warden accounts)

This token is stored in the browser and sent with every API request through the Authorization header.

Authorization: Bearer <jwt_token>

The hostelId field allows wardens to be automatically restricted to their assigned building.

This became the foundation for permission-aware APIs and role-specific dashboards.

2. The Hybrid API: Performance Meets Portability

I wanted the platform to work seamlessly in:

Local development
Cloud/serverless deployments

So I used a Hybrid Express + Serverless Architecture.

Local Development

A central Express server.js handles:

Routing
Middleware
JWT validation
Local API orchestration

Production Deployment

Each route is structured as an independent serverless function:

/api/teams/verify.js
/api/hostels/allocate.js
/api/audit/logs.js

This approach gave me:

Better modularity
Easier debugging
Isolated feature testing
Cloud portability

without maintaining two different codebases.

3. Defense in Depth: The "Double Lock" Strategy

One of the most common security mistakes in frontend-heavy applications is:

Protecting only the UI.

Hiding buttons in React does not secure your system.

Anyone with:

Postman
curl
browser devtools

can still hit your APIs directly.

So Morpheus uses a Two-Layer Guard Architecture.

Layer 1: Frontend Route Guards (UX Protection)

In React, I implemented a wrapper component that validates roles before rendering routes.

const ProtectedRoute = ({ allowedRoles, children }) => {
  const { user } = useAuth();

  if (!allowedRoles.includes(user.role)) {
    return <Navigate to="/unauthorized" />;
  }

  return children;
};

This ensures:

Wardens never see admin settings
Desk operators never access audit tools
Auditors only see verification workflows

The frontend becomes cleaner and less error-prone.

Layer 2: Backend Middleware (Real Security)

Every API route is wrapped in authorization middleware.

Even if someone bypasses the UI, the server validates:

JWT authenticity
User role
Permission level
Resource ownership

before processing the request.

Example:

if (req.user.role !== "Admin") {
  return res.status(403).json({
    error: "Access denied"
  });
}

This creates true defense-in-depth security.

4. Designing for Specific Roles

One of the most impactful decisions in Morpheus was making the interface adapt to the user’s identity.

Different users think differently.

So the UI itself changes depending on the role.

The Desk Operator

Their workflow is optimized for:

Speed
Search
Verification

They need to:

Find teams instantly
Search by phone number or ID
Verify attendance rapidly

Minimal distractions.

Maximum efficiency.

The Warden

Their workflow is visual.

They need:

Occupancy heatmaps
Room status visibility
Floor-level overview dashboards

Instead of forms, they interact with live hostel state.

The Auditor

Auditors care about process integrity.

Their interface is workflow-oriented:

Step-by-step validation
Approval pipelines
Verification checkpoints
Historical records

They don’t need dashboards.

They need structured operational flows.

5. Key Architecture Takeaways

Building Morpheus taught me several important engineering lessons.

Never Trust the Client

Always verify permissions on the backend.

Frontend validation improves UX.

Backend validation provides security.

You need both.

Modular APIs Scale Better

Small domain-focused handlers are easier to:

Test
Maintain
Secure
Deploy independently

Context is King

Using:

React Context
Custom Hooks
Global Auth Providers

allowed me to avoid painful prop-drilling across deeply nested dashboards.

Security Is Also About Preventing Mistakes

One of the biggest realizations during this project was:

Security isn’t just about stopping attackers.

It’s also about designing systems that prevent normal users from making catastrophic mistakes.

Good architecture guides users toward safe behavior by default.

That matters just as much as encryption and middleware.

Final Thoughts

Building Project Morpheus pushed me to think beyond CRUD applications and into operational system design.

Once you introduce:

Multiple roles
Real-world workflows
Permissions
Auditability
Physical asset management

your application becomes less about pages and more about trust boundaries.

And designing those trust boundaries correctly is where backend architecture becomes truly interesting.

Discussion

How would you design RBAC in a large-scale operational platform?

Would you use:

Attribute-Based Access Control (ABAC)?
Policy Engines like OPA?
Role hierarchies?
Permission matrices?
Microservice authorization gateways?

I’d love to hear how other engineers approach multi-role security systems.

The "Double-Booking" Nightmare: Building a Rule-Driven Hostel Allocator with MongoDB Transactions

Harsh Pandhe — Thu, 07 May 2026 11:51:33 +0000

How I built a transactional hostel allocation engine that eliminates race conditions and double-bookings using MongoDB sessions.

Handling logistics for a 500+ person event—like a major hackathon or campus festival—is easy on paper.

It becomes significantly harder at 2:00 AM when multiple exhausted teams arrive at the registration desk simultaneously while operators manually juggle room assignments.

In this article, I’m pulling back the curtain on the "brain" of Project Morpheus: a transactional allocation engine designed to handle complex accommodation logic without risking data corruption or double-bookings.

1. The Challenge: Why CRUD Isn’t Enough

When most people think of a Hostel Management System, they imagine a basic CRUD application.

But in high-concurrency environments—where multiple operators may click Allocate at the exact same moment—traditional CRUD logic introduces dangerous race conditions.

The "Overbooking" Scenario

Operator A queries for the next available bed.
The database responds:

Room 101, Bed A is free.

Operator B performs the same query simultaneously.
The database again responds:

Room 101, Bed A is free.

Both operators hit Confirm.

Result?

The same physical bed gets assigned twice.

I’ve seen this happen in real operational environments, and I decided that Project Morpheus would move the complexity from the operator’s brain into the system itself.

2. The Morpheus Solution: Rule-Driven Automation

The allocator doesn’t randomly assign rooms.

It follows a strict hierarchy of business rules modeled after real-world campus accommodation systems.

The "Golden Rules" of Allocation

1. Gender Segregation

This is the most critical rule.

Male participants → Devgiri or Raigad
Female participants → Godavari

2. The Verification Gate

To prevent ghost bookings and spreadsheet inconsistencies:

A team cannot be allocated unless every member has been verified at the registration desk.

This includes:

ID verification
Physical presence confirmation
Attendance validation

3. Team Integrity

The allocator prioritizes keeping teams:

In the same room
Or in adjacent rooms

It avoids splitting teams across multiple floors unless absolutely necessary.

4. Sequential Optimization

To simplify operations for wardens and housekeeping staff, rooms are filled in a deterministic order:

Block → Room → Bed

3. Technical Deep-Dive: The Transactional Sequence

In Project Morpheus, an allocation request is treated as an:

Atomic Unit of Work

Meaning:

Either every database operation succeeds
Or the entire request rolls back safely

This guarantees consistency even during crashes or network failures.

Step 1: Concurrency Check

The allocator first performs an atomic validation.

if (team.isAllocated) {
  throw new Error("Team already allocated");
}

This prevents:

Double-click allocation issues
Duplicate operator requests
Multiple transaction executions

Step 2: Gender-Specific Scouting

The engine separates members by gender and searches eligible hostel blocks.

const availableBeds = await db.collection('hostels').aggregate([
  { $match: { gender: teamGender } },
  { $unwind: "$rooms" },
  { $unwind: "$rooms.beds" },
  { $match: { "rooms.beds.isOccupied": false } },
  { $limit: memberCount }
]).toArray();

This dynamically finds:

Empty beds
Nearby room availability
Contiguous placements for teams

Step 3: The "Big Write" (MongoDB Transaction)

Using MongoDB sessions, the allocator wraps all mutations into a single transaction.

Inside the transaction:

1. Generate Allocation Records

Create accommodation records for every participant.

This becomes the system’s:

Source of Truth

for room mapping.

2. Update Hostel State

Selected beds are marked as occupied using MongoDB positional operators.

$[ ]

3. Update Team Metadata

isAllocated: true

Why Transactions Matter

Imagine this scenario:

Accommodation slips are printed
The server crashes before hostel state updates
The database still believes those beds are empty

Without transactions:

Duplicate allocations become possible
Database consistency breaks
Physical occupancy mismatches system state

With MongoDB transactions:

Everything commits together
Or everything rolls back safely

4. Operational Impact: From 5 Minutes to 2 Seconds

Before Project Morpheus:

Manual room hunting
Spreadsheet coordination
Warden communication over calls
~5 minutes per team allocation

After automation:

Metric	Before	After
Allocation Time	~5 mins	~2.5 sec
Double Bookings	Frequent Risk	Impossible
Manual Coordination	Heavy	Minimal
Slip Generation	Manual	Automatic

Real-World Results

Zero Double-Bookings

The transactional lock mechanism makes over-allocation mathematically impossible.

Massive Efficiency

Allocation now takes:

~2.5 seconds per team

regardless of team size.

Clean Operational Hand-Offs

The system instantly generates:

Printable accommodation slips
Accurate hostel mappings
Verified room assignments

Students receive the exact data stored in the database.

5. Key Takeaway for Developers

The biggest lesson I learned while building the Morpheus allocator:

Consistency matters more than speed in operational systems.

When software manages physical assets—beds, inventory, seats, reservations—it’s always better to have:

Slightly slower
Transaction-heavy
Fully consistent operations

than ultra-fast systems that corrupt data under load.

Designing for the "2:00 AM Scenario"

Good backend systems are not designed for ideal conditions.

They are designed for:

Failures
Concurrency
Human mistakes
Crashes
Unpredictable operational pressure

If your system can survive 2:00 AM chaos, it can survive production.

Final Thoughts

Building Project Morpheus taught me that backend engineering is less about writing APIs and more about designing reliable systems under pressure.

Handling concurrency correctly is what separates:

Demo projects

from

Production-grade infrastructure.

Discussion

How would you design this allocator differently?

Would you use:

Redis distributed locks?
PostgreSQL row-level locking?
Event sourcing?
Queue-based allocation?
Optimistic concurrency control?

I’d genuinely love to hear production-grade approaches from other backend engineers.

GitHub Bootcamp: Day 5 – Contributing to Open Source Like a Pro 🧑‍💻🌍

Harsh Pandhe — Thu, 22 May 2025 18:30:00 +0000

Welcome to the final day of our GitHub crash course! Today’s topic is a favorite among devs and job recruiters alike — Open Source Contributions.

Yes, it sounds intimidating. But trust me — you don’t need to be a 10x developer or a command-line wizard to contribute meaningfully. Let’s break it down!

🌱 Why Contribute to Open Source?

Learn by doing – Hands-on experience beats theory any day.
Build your portfolio – Real-world code > tutorial projects.
Grow your network – Meet collaborators, mentors, and friends.
Give back to the community – Many of the tools you use daily are open source!

🔍 How to Find Projects to Contribute To

💡 Start here:

Good First Issue – Curated list of beginner-friendly issues
Up-for-Grabs
First Contributions Repo
Explore trending repos on GitHub – Look under the “issues” tab for low-hanging fruit.

✅ What Can You Contribute?

You don’t need to refactor the entire codebase. Open source thrives on small, meaningful contributions. Examples:

Fixing typos in documentation
Improving README files
Updating dependencies
Fixing bugs
Adding tests
Suggesting features
Reviewing other people’s PRs

🛠️ How to Make a Contribution (The Friendly Way)

Fork the repo 🍴
Creates your own copy where you can make changes.
Clone it locally

   git clone https://github.com/your-username/project-name.git

Create a new branch

   git checkout -b fix-typo

Make your changes & commit

   git add .
   git commit -m "Fix typo in README"

Push to your fork

   git push origin fix-typo

Open a Pull Request (PR)

Explain what you did clearly.
Be polite and open to feedback!

💬 Pro Tips for Contributing

Read the Contributing.md file if available.
Follow code style guidelines of the project.
Engage positively in issue discussions.
Be patient — maintainers are often volunteers!

🚀 Bonus: Hacktoberfest

Every October, GitHub and DigitalOcean host Hacktoberfest, where contributing to open source earns you swag, stickers, and GitHub street cred. Perfect for beginners!

🏁 That’s a Wrap!

You just finished a 5-day journey covering:

What is GitHub
Setting up GitHub & Git
Branching and Collaboration
GitHub Actions for Automation
Open Source Contributions

Whether you're building solo or contributing globally, GitHub is your dev playground.

GitHub Series: Day 4 – Automate Like a Boss with GitHub Actions 🤖⚙️

Harsh Pandhe — Wed, 21 May 2025 18:30:00 +0000

Welcome back, developers! Yesterday, we learned how to branch and merge like Git ninjas. Today, we’re going full automation mode with GitHub Actions — your new best friend for building, testing, and deploying code without lifting a finger (well, almost 😎).

🧠 What are GitHub Actions?

Imagine having a robot that checks your code, runs tests, deploys apps, makes you coffee (okay, not that last one… yet) — all triggered by events like pushing to a branch or opening a pull request.
That’s GitHub Actions. It's a powerful CI/CD (Continuous Integration / Continuous Deployment) system built right into GitHub.

🔥 Why Use GitHub Actions?

✅ Automate repetitive tasks
🧪 Run tests every time code is pushed
🚀 Deploy apps automatically
📦 Build and publish packages
🤝 Boost collaboration with teams

🛠️ Setting Up Your First GitHub Action

Here’s how to build a simple GitHub Action that runs tests when code is pushed:

1. Create a workflow file

Inside your repo, make this folder:

.github/workflows/

Then create a file like ci.yml.

2. Add this starter config:

name: Run Python Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'

      - name: Install dependencies
        run: pip install -r requirements.txt

      - name: Run tests
        run: pytest

And boom — your tests will now run automatically whenever you push code!

🚦 Common Use Cases

Use Case	Trigger	Example
Linting	`on: push`	Auto-check code style (e.g., with ESLint or Black)
Deployment	`on: push to main`	Deploy app to Vercel, Heroku, Netlify, etc.
Notifications	`on: issues`	Send Slack or Discord alerts
Testing	`on: pull_request`	Run unit tests before merging

🧩 Pro Tip: Use Actions from the Marketplace

Why reinvent the wheel? Head over to GitHub Marketplace and use thousands of pre-built actions.

Examples:

actions/checkout → Pulls repo code
actions/setup-node → Sets up Node.js
docker/build-push-action → Builds & pushes Docker images

💡 Best Practices

✅ Keep workflows small and focused
🔁 Use reusable workflows to avoid duplication
🧪 Run tests before deploying
⏱️ Don’t trigger workflows on every tiny change — be specific with paths and branches

🚀 Conclusion

GitHub Actions is your personal DevOps assistant. Whether you're solo-building a portfolio site or working in a team on a massive app, automation will save your time and sanity.

Tomorrow?

We’ll wrap this series with something close to every developer’s heart — Open Source Contributions 💖
How to find cool projects, make meaningful PRs, and become a contributor!

GitHub Bootcamp: Day 3 - Branching and Merging Like a Pro

Harsh Pandhe — Tue, 20 May 2025 18:30:00 +0000

Welcome to Day 3 of our GitHub series! Today we're diving into branching and merging—the secret sauce behind collaborative development. If GitHub was a movie, branches would be the plot twists, and merges would be the dramatic reunions. Let's get into it!

🌐 What is a Branch?

A branch in Git is like a sandbox where you can work on changes without affecting the main (production) version of your code.

Imagine you're writing a novel. Your main branch is the final version, but you want to try out an alternate ending. Instead of rewriting everything, you create a branch called alternate-ending and work there. Genius, right?

🔄 Creating a Branch

git branch feature-cool-button

🚀 Switching to Your Branch

git checkout feature-cool-button

git switch feature-cool-button

Now you're in your own bubble. Make changes, commit them, and live your best dev life.

✨ Merging: The Reunion Episode

Once you’re happy with your changes in a branch, it’s time to bring them back into the main branch. That’s merging.

🔐 First, Switch to Main

git checkout main

🔄 Merge Your Branch

git merge feature-cool-button

Boom! Your changes are now part of the main storyline.

⚠️ What About Merge Conflicts?

Sometimes Git gets confused if the same part of a file has been changed in both branches. It’ll raise a merge conflict and ask you to resolve it.

Don't panic.

Git will mark the conflicts in the file.
You decide which version to keep.
After editing, mark the conflict as resolved:

git add conflicted-file.js
git commit

🎓 Pro Tips

Name your branches clearly: bugfix-login-issue, feature-dark-mode.
Always pull latest changes before you merge.
Use git log --graph to visualize branches.
Use git status to stay aware of what’s going on.

🤖 Pull Requests: Collaborate the GitHub Way

If you're working with a team or contributing to open source, don’t just merge directly. Open a pull request on GitHub.

Why?

It allows others to review your code.
You can discuss changes before merging.
Ensures cleaner, safer code.

🌟 Summary

Branching and merging are powerful tools for working independently without chaos. Master these, and you’re halfway to becoming a Git wizard.

Coming Up: Day 4 - GitHub Actions ✨

Next, we’ll explore how to automate workflows and save time with GitHub Actions. Get ready for some dev magic!

#GitHub #Git #VersionControl #GitTips #CodeCollaboration #OpenSource

GitHub Bootcamp: Day 2 - Setting Up GitHub

Harsh Pandhe — Mon, 19 May 2025 18:30:00 +0000

Welcome to Day 2 of our 5-day GitHub series! Today we’re setting up GitHub, the digital garage where developers store, collaborate on, and show off their code. If GitHub were a superhero, it’d be Batman: mysterious, powerful, and full of cool gadgets (like Actions and Pull Requests). Let's get you set up and ready to push code like a pro.

Step 1: Create a GitHub Account

Go to github.com and hit Sign up

Pick a memorable username (bonus points for geeky puns).
Add your email and a strong password.
Choose your plan (the free one is plenty to get started).

You're officially a GitHubber now. 🎉

Step 2: Create Your First Repository

A repository (or “repo”) is where your project lives—kind of like a folder, but cooler.

How to Create a Repo:

Click the + icon on the top-right → New repository.
Give it a name like awesome-project.
Add a description (optional but classy).
Choose public (anyone can see) or private (for your eyes only).
Check “Initialize this repository with a README” if you want to add one.
Click Create repository.

Boom. Your project home is ready.

Step 3: Install Git Locally

To push code from your computer to GitHub, you’ll need Git installed.

Install Git:

Windows: Download Git
macOS: Use Homebrew → brew install git
Linux: Use your package manager → sudo apt install git (for Debian/Ubuntu)

Configure Git:

git config --global user.name "Your Name"
git config --global user.email "your@email.com"

This tells Git who you are (like a signature on your code).

Step 4: Push Your Code to GitHub

Let’s say you created a project on your computer called hello-github.

Push it to GitHub:

cd hello-github
git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin https://github.com/yourusername/hello-github.git
git push -u origin main

And boom 💥 your code is now live on GitHub!

GitHub UI Tips for Beginners

README.md: A welcome message for your repo. Make it fun and informative.
Commits Tab: Shows your code history like a time-travel diary.
Branches: Parallel universes for your code. We’ll talk more tomorrow!

Bonus: Learn Git Basics

Here are a few must-know Git commands:

Command	Description
`git status`	Check what’s going on
`git add .`	Stage all changes
`git commit -m "message"`	Save changes
`git push`	Upload changes to GitHub
`git pull`	Fetch latest code

Conclusion

Today you created a GitHub account, made a repo, and learned how to push your first code. You’re officially dangerous (in a good way).

What’s Coming Next?

Tomorrow, we dive into Branching and Merging—aka how not to break stuff while working with others. Stay tuned!

#GitHub #Git #DeveloperTools #VersionControl #OpenSource #Day2

GitHub Bootcamp: Day 1 - What is GitHub?

Harsh Pandhe — Mon, 19 May 2025 12:45:41 +0000

Welcome to Day 1 of our 5-day GitHub series! If you've ever heard developers say, "Push it to GitHub" and wondered if they meant a gym workout, you're in the right place.

What is GitHub?

GitHub is like social media for code—except instead of selfies and cat memes, you'll find commits, pull requests, and branches. It's a web-based platform built on top of Git, a version control system that helps developers track changes in their code.

TL;DR:

Git = A tool to track code changes.
GitHub = A cloud platform to store, manage, and collaborate on Git repositories.

If Git is your notebook, GitHub is your bookshelf in the cloud.

Why Use GitHub?

✨ Features & Benefits

Version Control: Never lose progress. Revert to older versions anytime.
Collaboration: Work on the same project with friends, teammates, or strangers across the globe.
Issue Tracking: Report bugs or suggest features with Issues.
Pull Requests: Review, discuss, and merge changes smoothly.
Documentation: Use README files and Wikis to explain your code.
GitHub Pages: Host static websites directly from your repo.
Community and Open Source: Find projects, contribute, or get help from fellow devs.

Real-Life Examples

Solo Developer: You’re building a personal portfolio site. GitHub tracks changes and lets you host it using GitHub Pages.
Startup Team: Your team of 5 is working on a web app. Everyone pushes code to the same repo and uses branches to prevent chaos.
Open Source Contributor: You find a bug in a cool tool. Fork the repo, fix the bug, and submit a pull request!

A Quick Glossary

Repository (Repo): A project folder tracked by Git.
Commit: A snapshot of your project at a specific time.
Branch: A parallel version of your project.
Merge: Bringing branches together.
Pull Request (PR): Proposing changes to be added to a repo.

Final Thought for Today

GitHub isn’t just for developers—it’s for creators. Writers, designers, data scientists, and more use GitHub to manage versioned work. By learning it, you’re joining a global community of builders and innovators.

What’s Next?

Tomorrow, we’ll walk you through Setting Up GitHub, creating your first repository, and mastering Git basics. No worries—we'll keep it fun, hands-on, and beginner-friendly.

Day 05: System Administration Like a Pro

Harsh Pandhe — Thu, 13 Feb 2025 18:30:00 +0000

Welcome to the final day of our Linux series! Today, we’re stepping into the shoes of a Linux System Administrator. You’ll learn how to manage users, processes, and services like a seasoned pro. Ready to level up? Let’s dive in!

What is System Administration?

System administration is all about keeping a Linux system running smoothly. It involves managing users, monitoring processes, configuring services, and ensuring everything works together harmoniously. Think of it as being the conductor of a tech orchestra.

Managing Users and Groups

1. Add a New User

Add a user with the adduser command:

sudo adduser username

Follow the prompts to set up a password and basic user info.

2. Delete a User

Remove a user with:

sudo deluser username

For a clean slate, delete their home directory too:

sudo deluser --remove-home username

3. Switch Users

Switch to another user with:

su - username

4. Manage Groups

Add a user to a group:

sudo usermod -aG groupname username

Example: Adding jane to the sudo group:

sudo usermod -aG sudo jane

Monitoring and Managing Processes

Processes are the programs running on your system. Here’s how to keep an eye on them:

1. View Running Processes

Use top to see a live list of running processes:

top

Exit with q.

Or, use ps for a snapshot:

ps aux

2. Kill a Process

Terminate a misbehaving process with its PID (Process ID):

kill PID

If it refuses to die, use:

kill -9 PID

3. Monitor System Resources

Check memory and CPU usage:

free -h

uptime

Managing Services

Linux services (a.k.a. daemons) are background processes that handle tasks like web servers, databases, and more. Here’s how to manage them:

1. Start, Stop, and Restart Services

Control services with systemctl:

sudo systemctl start servicename
sudo systemctl stop servicename
sudo systemctl restart servicename

Example: Restarting the Apache web server:

sudo systemctl restart apache2

2. Check Service Status

See if a service is running:

sudo systemctl status servicename

3. Enable and Disable Services

Enable a service to start on boot:

sudo systemctl enable servicename

Disable it:

sudo systemctl disable servicename

Scheduling Tasks with Cron

Automate repetitive tasks using Cron. Cron jobs are scheduled tasks defined in a special file called the crontab.

1. Edit the Crontab

Open the crontab editor:

crontab -e

2. Add a Cron Job

Cron jobs follow this format:

minute hour day month day_of_week command

Example: Run a backup script every day at 2 AM:

0 2 * * * /path/to/backup.sh

3. List Cron Jobs

View your scheduled tasks:

crontab -l

Backing Up Your System

Backups are a sysadmin’s best friend. Here’s a simple way to back up files and directories:

Using rsync

rsync -av /source/directory /backup/directory

Example: Back up your home directory:

rsync -av /home/username /mnt/backup

Tips and Best Practices

Keep Your System Updated: Use sudo apt update && sudo apt upgrade (or your distro’s equivalent) regularly.
Monitor Logs: Check logs for errors and anomalies. System logs are often in /var/log.
Limit Root Access: Use sudo instead of logging in as root.
Backup Regularly: Always have a backup plan.
Document Everything: Keep notes on what you configure for future reference.

Resources to Explore

Conclusion

Congratulations! You’ve completed the 5-day Linux journey. You’ve gone from learning what Linux is to mastering system administration. Whether you’re managing users, processes, or services, you now have the skills to navigate Linux like a pro.

Keep Learning

This is just the beginning. Linux is a vast and fascinating world. Keep exploring, practicing, and experimenting. The command line is your canvas—go create something amazing.

Day 04: Shell Scripting Basics

Harsh Pandhe — Thu, 13 Feb 2025 16:50:10 +0000

Welcome to Day 4 of our 5-day Linux series! Today, we’re diving into the magical world of Shell Scripting, where you’ll learn how to automate repetitive tasks, write simple scripts, and look like a wizard at the command line. Let’s get scripting!

What is Shell Scripting?

A shell script is like a to-do list for your computer, written in a language your Linux shell understands (like Bash). Instead of typing commands one by one, you can write a script to do it all for you in one go. It’s perfect for:

Automating tasks like backups and updates.
Managing files and directories.
Creating tools to simplify your workflow.

Why Learn Shell Scripting?

Saves Time: Automate boring, repetitive tasks.
Boosts Productivity: Handle complex operations with ease.
It’s Fun: Who doesn’t love feeling like a tech wizard?

Getting Started with Shell Scripting

Let’s create your first shell script. Follow these steps:

Step 1: Create a Script File

Open your terminal and create a new file:

nano myscript.sh

Step 2: Add the Shebang Line

The first line of your script should be:

#!/bin/bash

This tells Linux to use the Bash shell to interpret the script.

Step 3: Write Your First Script

Add the following code to your file:

#!/bin/bash

echo "Hello, World!"

This script will simply print “Hello, World!” to the terminal.

Step 4: Save and Exit

Press Ctrl + O, then Enter to save. Press Ctrl + X to exit.

Step 5: Make the Script Executable

Run this command to make your script executable:

chmod +x myscript.sh

Step 6: Run Your Script

Finally, execute your script with:

./myscript.sh

Boom! Your first shell script just ran. High five!

Key Concepts in Shell Scripting

Variables

Variables store data that you can use later in your script. Example:

#!/bin/bash

name="Linux User"
echo "Hello, $name!"

Conditionals

Run different commands based on conditions. Example:

#!/bin/bash

if [ $1 -gt 10 ]; then
  echo "The number is greater than 10."
else
  echo "The number is 10 or less."
fi

(Note: $1 refers to the first argument passed to the script.)

Loops

Repeat commands using loops. Example:

#!/bin/bash

for i in {1..5}; do
  echo "Number: $i"
done

Example: Automating a Backup

Let’s write a script to back up a directory:

backup.sh

#!/bin/bash

src="/path/to/source"
dest="/path/to/backup"

echo "Starting backup..."
cp -r $src $dest
echo "Backup completed!"

Replace /path/to/source with the directory you want to back up.
Replace /path/to/backup with your backup destination.
Run the script, and boom—automated backup!

Best Practices for Shell Scripting

Add Comments: Use # to explain your code.
Handle Errors: Use set -e to stop the script on errors.
Test Your Scripts: Run them in a safe environment first.
Keep It Simple: Avoid making scripts overly complex.

Resources to Learn More

Conclusion

You just took your first steps into the exciting world of shell scripting! With practice, you’ll be automating tasks and building your own tools in no time. Keep experimenting and having fun.

What’s Next?

Tomorrow, we’ll wrap up our Linux series with System Administration, where we’ll learn how to manage users, processes, and services like a pro. See you on Day 5!

Day 03: The Linux File System

Harsh Pandhe — Tue, 11 Feb 2025 18:30:00 +0000

Welcome to Day 3 of our Linux series! Yesterday, we became command-line ninjas, learning the essentials of navigating and managing files. Today, we’ll explore the Linux file system—an organized chaos of directories that make Linux both powerful and efficient. Ready? Let’s decode this mystery together!

Understanding the Linux File System

The Linux file system is like a tree. The root (/) is the base, and everything branches out from there. Unlike Windows, Linux doesn’t have drive letters (C:\, D:). Instead, all files and directories are part of this single tree structure.

Key Directories in Linux

Let’s take a tour of the Linux file system—a virtual sightseeing trip through the most important directories:

1. / (Root Directory)

The starting point of the Linux file system.
All other directories live here.
Warning: Messing around here without caution can lead to disaster. Treat it like it’s a beehive—observe, but don’t poke!

2. /home

Home sweet home! Each user has their personal space here (e.g., /home/username).
This is where you’ll spend most of your time, storing personal files and configurations.

3. /bin

Short for “Binaries”—contains essential programs and commands, like ls, cp, and mv.
These are the tools you’ve been using from Day 2!

4. /usr

Short for “User” resources. Think of it as the treasure chest of user applications and libraries.
Contains directories like /usr/bin for user-installed programs and /usr/share for shared files.

5. /etc

The configuration headquarters of Linux.
Contains system-wide settings for programs and services (like /etc/hostname for the system’s name).

6. /var

Stores variable files like logs, databases, and emails.
Example: Check system logs in /var/log to troubleshoot problems.

7. /tmp

Temporary storage. Files here are automatically deleted after a reboot.
Useful for storing short-lived data.

8. /dev

Stands for “Devices.” Contains files that represent hardware devices (e.g., /dev/sda for your hard drive).

9. /proc and /sys

Virtual filesystems providing information about system processes and hardware.
Example: Check CPU info with:

  cat /proc/cpuinfo

Navigating the Linux File System

Absolute vs. Relative Paths

Absolute Path: Starts from the root directory (/). Example: /home/user/Documents.
Relative Path: Starts from your current directory. Example: Documents (if you’re already in /home/user).

Common Navigation Commands

pwd: Print your current location.
ls: List files in a directory.
cd: Change directories.
- Example: Move to /var/log:
```
cd /var/log
```

Working with Files and Directories

Create a Directory

mkdir <directory_name>

Example:

  mkdir Projects

Delete a Directory

rmdir <directory_name>

Use rmdir for empty directories or rm -r for directories with content.
Example:

  rm -r Projects

Check Disk Usage

du -h

Shows disk usage in a human-readable format.
Example:

  du -h /home

Check Available Disk Space

df -h

Displays available disk space for each filesystem.

Tips for Navigating Like a Pro

1. Use Tab for Auto-Completion

Press Tab while typing a file or directory name to auto-complete it. Double Tab shows options if there are multiple matches.

2. Hidden Files Start with a Dot

Files like .bashrc are hidden. Use ls -a to see them.

3. Use Aliases for Long Paths

Create shortcuts in your .bashrc file. Example:

  alias docs="cd /home/user/Documents"

Fun Linux Fact

Linux doesn’t just run on computers. It’s in space! The International Space Station uses Linux to control systems and perform experiments. 🚀

Conclusion

Congratulations! You’ve just uncovered the secrets of the Linux file system. By now, you should feel more confident navigating and working with directories. Keep exploring and practicing these commands to master the Linux filesystem.

What’s Coming Next?

Tomorrow, we’ll dive into Shell Scripting Basics and learn how to automate tasks like a pro. See you for Day 4 of this series!

Day 02: Basic Linux Commands

Harsh Pandhe — Mon, 10 Feb 2025 18:30:00 +0000

Welcome to Day 2 of our Linux series! Yesterday, we dipped our toes into the Linux world. Today, we’re getting hands-on and learning some essential commands. Think of this as learning the language of Linux—simple, powerful, and oddly satisfying.

What Is the Terminal?

Imagine the terminal as a magic window where you can tell Linux what to do. It’s a bit like texting, but instead of a friend, you’re chatting with your computer. Cool, right?

To open the terminal:

Ubuntu: Press Ctrl + Alt + T.
Fedora: Search for “Terminal” in the app menu.

Now, let’s dive into some commands that will make you feel like a tech wizard.

Basic Navigation Commands

These commands help you move around the Linux filesystem. Think of it as learning to walk before you run.

1. Where Am I?

pwd

Prints the current directory (your location in the filesystem).
Example: "/home/username"

2. What’s Around Me?

ls

Lists files and directories in your current location.
Add -l for detailed info or -a to see hidden files.
Example:

  ls -la

3. Take Me Somewhere Else

cd <directory_name>

Changes your current directory.
Example:

  cd Documents

Go back to the previous directory with:

  cd ..

File Management Commands

4. Show Me the File Content

cat <file_name>

Displays the contents of a file.
Example:

  cat hello.txt

5. Create a New File

touch <file_name>

Creates an empty file.
Example:

  touch my_file.txt

6. Move or Rename a File

mv <source> <destination>

Moves or renames files.
Example (rename):

  mv old_name.txt new_name.txt

Example (move):

  mv my_file.txt /home/username/Documents

7. Copy a File

cp <source> <destination>

Copies files or directories.
Example:

  cp hello.txt backup_hello.txt

8. Delete a File

rm <file_name>

Deletes a file.
Example:

  rm old_file.txt

Be careful—there’s no trash bin here!

Permissions: The Linux Security Guard

Linux files have permissions that determine who can read, write, or execute them.

9. Check File Permissions

ls -l

Shows detailed file info, including permissions.
Example output:

  -rw-r--r-- 1 user group  123 Jan 1 12:00 hello.txt

Breakdown:

r = read, w = write, x = execute.

10. Change Permissions

chmod <permissions> <file_name>

Changes file permissions.
Example:

  chmod 755 script.sh

This makes the file executable.

Other Handy Commands

11. Clear the Screen

clear

Wipes the terminal screen clean, just like hitting refresh.

12. Who Am I?

whoami

Prints your username. Great for existential crises.

13. What’s Running?

top

Shows active processes and resource usage.
Use q to quit.

14. Need Help?

man <command>

Opens the manual for a command.
Example:

  man ls

Pro tip: Quit the manual with q.

Fun Linux Fact

Did you know the Linux mascot, Tux the penguin, was inspired by a penguin bite Linus Torvalds got at a zoo? 🐧

Conclusion

You now know how to navigate, manage files, and even wield the power of permissions. Linux isn’t so scary anymore, is it? Practice these commands, and soon, you’ll feel right at home in the terminal.

What’s Coming Next?

Tomorrow, we’ll explore the Linux File System and uncover its unique directory structure. Stay tuned for Day 3 of this series!