DEV Community: coder7475

Git Submodules Explained for Beginners

coder7475 — Fri, 31 Jul 2026 13:53:48 +0000

If you've ever wanted to reuse another Git repository inside your project without copying its code, Git Submodules are exactly what you're looking for.

At first, submodules can seem confusing. But once you understand how they work, they're actually straightforward.

In this article, we'll cover:

What Git Submodules are
Why you should use them
How they work
Common commands you'll use
Common mistakes beginners make
How to remove a submodule

What is a Git Submodule?

A Git Submodule lets you include one Git repository inside another Git repository.

Instead of copying files from another project, Git keeps a reference to that repository and remembers which commit should be used.

my-project/
│
├── src/
├── docs/
├── shared-library/   ← Git Submodule
├── package.json
└── .gitmodules

Here:

my-project is the main repository (called the superproject).
shared-library is another completely separate Git repository.

Each repository keeps its own commits, branches, and history.

Why Use Git Submodules?

Submodules are useful when you want to:

Share common libraries between multiple projects
Include third-party code without copying it
Split a large project into smaller repositories
Keep independent version history for reusable components

For example:

Suppose you have three applications that all use the same authentication library.

Instead of copying the authentication code into every project, you can keep it in its own repository and include it as a submodule.

Auth Library Repository
        │
 ┌──────┴─────────┐
 │                │
Project A     Project B

Now every project references the same library.

How Git Stores a Submodule

A common misconception is that Git copies the entire repository into your project.

It doesn't.

Instead, the superproject only stores:

the repository URL
the folder path
the exact commit hash

That means your main repository simply says:

"Use commit abc123 from this repository."

This allows the submodule to evolve independently.

The `.gitmodules` File

When you add a submodule, Git creates a file called:

.gitmodules

Example:

[submodule "shared-library"]
    path = shared-library
    url = https://github.com/example/shared-library.git

This file tells Git:

where the submodule lives
where to clone it from

Because .gitmodules is version controlled, everyone on your team gets the same configuration.

Adding a Submodule

Use:

git submodule add <repository-url> <path>

Example:

git submodule add https://github.com/example/shared-library.git shared-library

Git will:

clone the repository
create .gitmodules
stage both the new folder and .gitmodules

Then commit the changes:

git commit -m "Add shared library as submodule"

Cloning a Repository with Submodules

The easiest way is:

git clone --recurse-submodules <repository-url>

This clones:

the main repository
every submodule
nested submodules as well

Forgot `--recurse-submodules`?

No problem.

Run:

git submodule update --init --recursive

This initializes and downloads all submodules after cloning.

Updating a Submodule

To fetch the latest commits from the remote repository:

git submodule update --remote

Git updates the submodule to the latest commit of its tracked branch.

After that, don't forget to commit the updated reference:

git add shared-library
git commit -m "Update submodule"

Otherwise your teammates won't receive the updated version.

Pushing Changes

If you've made changes inside the submodule, push them first.

A convenient command is:

git push --recurse-submodules=on-demand

This ensures Git pushes:

the submodule commits
then the main repository

This prevents broken references for other developers.

Detached HEAD Explained

One thing that surprises many beginners is seeing this message:

HEAD detached at abc123

This is normal.

The superproject points to a specific commit instead of a branch.

A detached HEAD simply means:

"You're viewing a particular commit."

If you want to make changes inside the submodule, switch to a branch first:

cd shared-library

git checkout main

Then make your changes, commit, push, and finally update the superproject.

Common Beginner Mistakes

1. Forgetting to clone submodules

Incorrect:

git clone <repository>

Correct:

git clone --recurse-submodules <repository>

Or run:

git submodule update --init --recursive

2. Updating the submodule but forgetting to commit

After updating:

git submodule update --remote

You still need:

git add shared-library
git commit -m "Update submodule reference"

3. Editing inside a detached HEAD

Always switch to a branch before making changes:

git checkout main

Removing a Submodule

Removing a submodule involves more than deleting the folder because Git tracks additional metadata.

The process differs slightly depending on your Git version.

A detailed step-by-step guide is available here:

https://stackoverflow.com/questions/1260748/how-do-i-remove-a-submodule

When Should You Use Git Submodules?

Use submodules when:

multiple projects share the same codebase
you want independent version histories
you need to pin an exact version of another repository
you want to include third-party repositories without copying code

Avoid submodules if your team is unfamiliar with Git or if your project requires frequent synchronized changes across repositories. In those cases, alternatives like package managers or monorepos may be simpler.

Final Thoughts

Git Submodules are often considered difficult—not because they're complicated, but because many developers don't understand that a submodule is simply another Git repository tracked by a specific commit.

Once you remember these three rules, everything becomes easier:

A submodule has its own Git history.
The main repository stores only a commit reference.
Updating a submodule requires committing the new reference in the superproject.

Master these concepts, and working with shared repositories becomes much cleaner and more maintainable.

Useful Commands Cheat Sheet

# Add a submodule
git submodule add <repo-url> <path>

# Clone with submodules
git clone --recurse-submodules <repo-url>

# Initialize submodules after cloning
git submodule update --init --recursive

# Update submodule to latest remote commit
git submodule update --remote

# Push submodule and superproject together
git push --recurse-submodules=on-demand

# Switch submodule to a branch
cd submodule
git checkout main

Thaks for reading!

Automating Ubuntu System Maintenance with Cron Jobs

coder7475 — Wed, 22 Jul 2026 08:35:50 +0000

Keeping your Ubuntu server healthy requires more than installing package updates. Over time, unused packages, cached APT files, and Docker resources can consume valuable disk space and affect system performance.

By automating routine maintenance with cron, you can ensure your server stays secure, up to date, and clean without manual intervention.

In this guide, you'll create a maintenance script that:

Updates package lists
Installs available package upgrades
Removes unused packages
Cleans the APT cache
Removes unused Docker resources
Logs maintenance activities
Prevents overlapping executions

Prerequisites

Operating System: Ubuntu
User: admin (sudo privileges)
Docker: Installed (optional)
Scripts Directory: /home/admin/linux/scripts

Step 1: Create a Directory for Scripts

Create a dedicated directory to organize your Linux administration scripts.

mkdir -p /home/admin/linux/scripts

Step 2: Create the Maintenance Script

Create the script.

touch /home/admin/linux/scripts/system_maintenance.sh
chmod +x /home/admin/linux/scripts/system_maintenance.sh

Open the file and paste the following:

#!/bin/bash

set -euo pipefail

LOG_FILE="/var/log/system_maintenance.log"
LOCK_FILE="/tmp/system_maintenance.lock"

exec 200>"$LOCK_FILE"
flock -n 200 || exit 1

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1"
}

log "========== Starting system maintenance =========="

log "Updating package lists..."
sudo apt update

log "Upgrading installed packages..."
sudo apt upgrade -y

log "Removing unused packages..."
sudo apt autoremove -y

log "Cleaning APT cache..."
sudo apt autoclean -y

if command -v docker >/dev/null 2>&1; then
    log "Cleaning Docker resources..."
    sudo docker system prune -af --volumes
fi

log "========== System maintenance completed =========="

Understanding the Script

Enable Safe Bash Options

set -euo pipefail

These options make the script more reliable.

-e Exit immediately if a command fails.
-u Treat undefined variables as errors.
pipefail Detect failures inside pipelines.

Prevent Multiple Executions

LOCK_FILE="/tmp/system_maintenance.lock"

exec 200>"$LOCK_FILE"
flock -n 200 || exit 1

If the previous maintenance job is still running, another instance will not start.

This prevents:

duplicate updates
package manager conflicts
simultaneous Docker cleanup

Update Ubuntu Packages

sudo apt update
sudo apt upgrade -y

These commands:

Refresh package indexes.
Install all available updates automatically.

Remove Unused Packages

sudo apt autoremove -y

Removes packages that are no longer required by the system.

Clean the APT Cache

sudo apt autoclean -y

Deletes obsolete package files from the local package cache to reclaim disk space.

Clean Docker Resources

sudo docker system prune -af --volumes

This removes unused Docker resources, including:

stopped containers
dangling images
unused images
unused networks
build cache
unused volumes

Note: Running containers and resources currently in use are not removed.

Step 3: Create the Log File

Since /var/log is owned by root, create the log file once:

sudo touch /var/log/system_maintenance.log
sudo chown admin:admin /var/log/system_maintenance.log

Example output:

[2026-07-22 01:00:00] Starting system maintenance
[2026-07-22 01:00:01] Updating package lists...
[2026-07-22 01:00:45] Upgrading installed packages...
[2026-07-22 01:01:10] Removing unused packages...
[2026-07-22 01:01:25] Cleaning APT cache...
[2026-07-22 01:01:40] Cleaning Docker resources...
[2026-07-22 01:01:55] System maintenance completed.

Step 4: Configure Passwordless sudo

Cron jobs cannot respond to password prompts.

Edit the sudoers file:

sudo visudo

Add the following line:

admin ALL=(ALL) NOPASSWD: /usr/bin/apt, /usr/bin/docker

This allows the admin user to execute only the required commands without entering a password.

Step 5: Schedule the Cron Job

Open your crontab.

crontab -e

Add the following entry:

0 1 * * * /home/admin/linux/scripts/system_maintenance.sh >> /var/log/system_maintenance.log 2>&1

This runs the maintenance script every day at 1:00 AM.

Check created cronjob:

crontab -l

Testing the Script

Before relying on cron, execute the script manually.

/home/admin/linux/scripts/system_maintenance.sh

Recommended Directory Structure

Keeping administration scripts organized makes long-term maintenance easier.

/home/admin/linux/
├── scripts/
│   ├── system_maintenance.sh
│   ├── backup.sh
│   ├── docker_cleanup.sh
│   └── ssl_renew.sh
├── logs/
└── configs/

Maintenance Tasks Performed

Task	Command
Update package lists	`sudo apt update`
Upgrade packages	`sudo apt upgrade -y`
Remove unused packages	`sudo apt autoremove -y`
Clean package cache	`sudo apt autoclean -y`
Clean Docker resources	`sudo docker system prune -af --volumes`

Conclusion

Automating routine maintenance with cron is an easy way to keep your Ubuntu server secure, efficient, and free from unnecessary disk usage. By combining package updates, cache cleanup, and Docker pruning into a single scheduled task, you reduce manual administration while ensuring your system stays in good condition.

Review the maintenance logs periodically, monitor available disk space, and adjust the schedule as needed to match your server's workload.

The Only tmux Cheat Sheet You'll Need as a Developer

coder7475 — Wed, 01 Jul 2026 04:09:51 +0000

If you spend time working on remote servers, running long-lived processes, or managing multiple terminals, tmux is one of the most valuable tools you can learn.

It allows you to keep terminal sessions alive even after disconnecting from SSH, split your terminal into multiple panes, organize work into windows, and switch between projects without opening dozens of terminal tabs.

This article is a practical cheat sheet covering the commands I use every day.

What is tmux?

tmux (Terminal Multiplexer) lets you create persistent terminal sessions.

Instead of opening multiple terminal windows, you can organize everything inside a single terminal.

Typical use cases:

Remote server administration
Backend development
Running long-lived processes
Docker and Kubernetes management
DevOps workflows
Multiple SSH connections

Sessions

A session is your workspace.

Think of it as a project that contains multiple windows and panes.

List sessions

tmux ls
# or
tmux list-sessions

Example:

backend: 2 windows
devops: 4 windows

Create a session

tmux new -s backend

Create a detached session

Useful for starting background services.

tmux new -d -s backend

Attach to a session

tmux attach -t backend

## Short version
tmux a -t backend

Detach from a session

Press

Ctrl+b d

Everything continues running.

Create or attach (my favorite)

Instead of remembering whether the session already exists:

tmux new -As backend

This creates the session if needed or attaches to it if it already exists.

Rename a session

tmux rename-session -t backend api

Or inside tmux:

Ctrl+b $

Kill a session

tmux kill-session -t backend

Kill every session:

tmux kill-server

Windows

A window is similar to a browser tab.

One session can contain many windows.

Create a new window

Ctrl+b c

List windows

Ctrl+b w

Next / Previous window

Ctrl+b n

Ctrl+b p

Jump directly

Ctrl+b 0
Ctrl+b 1
Ctrl+b 2
...

Rename window

Ctrl+b ,

Close window

Ctrl+b &

Panes (Split Terminals)

Panes let you divide a window into multiple terminals.

Vertical split

Creates left/right panes.

Ctrl+b %

+-----------+-----------+
|           |           |
|           |           |
+-----------+-----------+

Horizontal split

Creates top/bottom panes.

Ctrl+b "

+-----------------------+
|                       |
+-----------------------+
|                       |
+-----------------------+

Navigate Between Panes

Arrow keys:

Ctrl+b ←
Ctrl+b →
Ctrl+b ↑
Ctrl+b ↓

Cycle through panes:

Ctrl+b o

Show pane numbers:

Ctrl+b q

Resize Panes

Using the keyboard:

Ctrl+b Alt+Arrow

Or command mode:

Ctrl+b :

resize-pane -L 10
resize-pane -R 10
resize-pane -U 5
resize-pane -D 5

Zoom a Pane

Need temporary full-screen?

Ctrl+b z

Press again to restore.

Change Layout

Cycle through built-in layouts.

Ctrl+b Space

Very useful when several panes become cluttered.

Close a Pane

Simply exit the shell.

exit

Ctrl+d

Enable Mouse Support

Add this to your ~/.tmux.conf

set -g mouse on

Reload:

tmux source-file ~/.tmux.conf

Now you can:

Click panes
Resize panes
Scroll normally
Select windows with the mouse

Run Commands in Background

Launch a process without attaching.

tmux new -d -s api "npm run dev"

tmux new -d -s server "python app.py"

Perfect for servers and CI scripts.

A Typical Development Workflow

Suppose you're working on a backend application.

Session: backend
│
├── Window 0: Editor
│   ├── Neovim
│   ├── npm run dev
│   └── Logs
│
├── Window 1: Database
│   ├── PostgreSQL
│   └── Redis
│
└── Window 2: Monitoring
    ├── htop
    └── Docker logs

Everything stays organized inside a single tmux session.

Disconnect from SSH?

No problem.

Reconnect later:

tmux attach -t backend

Everything is exactly where you left it.

Daily Cheat Sheet

Action	Shortcut / Command
New session	`tmux new -s name`
Attach	`tmux a -t name`
Create or attach	`tmux new -As name`
List sessions	`tmux ls`
Detach	`Ctrl+b d`
New window	`Ctrl+b c`
Window list	`Ctrl+b w`
Next window	`Ctrl+b n`
Previous window	`Ctrl+b p`
Vertical split	`Ctrl+b %`
Horizontal split	`Ctrl+b "`
Switch panes	`Ctrl+b + Arrow Keys`
Next pane	`Ctrl+b o`
Zoom pane	`Ctrl+b z`
Change layout	`Ctrl+b Space`
Show pane numbers	`Ctrl+b q`
Close pane	`Ctrl+d`
Close window	`Ctrl+b &`
Kill session	`tmux kill-session -t name`

Final Thoughts

Learning tmux takes a little practice, but once it becomes part of your workflow, it's hard to imagine working without it—especially when developing on remote servers or juggling multiple services.

Start with just a few shortcuts:

Ctrl+b d
Ctrl+b c
Ctrl+b %
Ctrl+b "
Ctrl+b z
Ctrl+b o

Master those, and you'll already be more productive than constantly opening and switching between terminal tabs.

Fixing WSL Errors on Windows 11

coder7475 — Thu, 21 May 2026 13:20:41 +0000

Fixing WSL Errors on Windows 11: From Missing `LxssManager` to WSL2 Migration

Recently, I ran into a frustrating WSL2 issue while setting up my development environment on Windows 11. Everything had been working fine before — Docker, Node.js, npm, and my Linux workflow inside Ubuntu.

Then suddenly, WSL started failing.

At first, it looked like a simple Node.js issue because running:

npm -v

returned:

WSL 1 is not supported. Please upgrade to WSL 2 or above.
Could not determine Node.js install directory

But after checking further on the Windows side, things became much more interesting.

Running:

wsl

returned:

The service did not respond to the start or control request in a timely fashion.
Error code: Wsl/0x8007041d

And then the biggest clue appeared:

Get-Service LxssManager

Output:

Cannot find any service with service name 'LxssManager'.

At that point, it became clear this was not just a Node.js issue. The actual problem was that the WSL service stack itself had become corrupted.

After debugging virtualization, Hyper-V, WSL features, and repairing Windows components, I finally restored WSL properly and migrated the distro fully to WSL2.

This article documents the entire debugging and recovery process so others can fix the same issue faster.

If you're trying to use Node.js, Docker, or modern development tools inside Windows Subsystem for Linux (WSL) and suddenly encounter errors like:

WSL 1 is not supported. Please upgrade to WSL 2 or above.
Could not determine Node.js install directory

or on Windows:

The service did not respond to the start or control request in a timely fashion.
Error code: Wsl/0x8007041d

this guide walks through how to debug and repair the issue safely on Windows 11.

Understanding the Problem

In this case, there were actually two separate issues:

The WSL service stack on Windows was partially broken.
The Linux distro was still running on WSL1 instead of WSL2.

Modern developer tools such as:

Node.js
npm
Docker Desktop
VS Code Remote WSL
Kubernetes tooling

work significantly better — and sometimes only work correctly — with WSL2.

Symptoms

Windows-side Errors

Running WSL commands failed with:

wsl

Output:

The service did not respond to the start or control request in a timely fashion.
Error code: Wsl/0x8007041d

Checking the WSL service:

Get-Service LxssManager

Output:

Cannot find any service with service name 'LxssManager'.

This indicated the WSL service registration was corrupted or missing.

Linux-side Errors

Inside Ubuntu:

npm -v

Output:

WSL 1 is not supported. Please upgrade to WSL 2 or above.
Could not determine Node.js install directory

This meant the distro was still using WSL1.

Why This Happens

This usually occurs after one of the following:

Interrupted Windows updates
Corrupted optional Windows features
Broken Docker Desktop installation/removal
Hyper-V or virtualization issues
Debloating scripts or registry cleaners
Failed WSL upgrades

The missing LxssManager service is especially important because it powers the WSL infrastructure.

Step 1: Verify Virtualization

Open PowerShell as Administrator:

systeminfo | findstr /i virtualization

You should see:

Virtualization Enabled In Firmware: Yes

If not:

Enter BIOS/UEFI
Enable Intel VT-x or AMD-V/SVM
Save and reboot

Step 2: Repair Windows Components

Run these commands in Administrator PowerShell:

DISM /Online /Cleanup-Image /RestoreHealth

Then:

sfc /scannow

These commands repair corrupted Windows system files and component registrations.

Reboot after both commands complete.

Step 3: Re-enable WSL Features

Disable broken components first:

dism /online /disable-feature /featurename:Microsoft-Windows-Subsystem-Linux /norestart

dism /online /disable-feature /featurename:VirtualMachinePlatform /norestart

dism /online /disable-feature /featurename:HypervisorPlatform /norestart

Reboot.

Then re-enable them:

dism /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

dism /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

dism /online /enable-feature /featurename:HypervisorPlatform /all /norestart

Enable Hyper-V launch:

bcdedit /set hypervisorlaunchtype auto

Reboot again.

Step 4: Update Windows 11

Go to:

Settings → Windows Update → Check for updates

Install:

Cumulative updates
Optional updates
Feature updates
Servicing stack updates

Reboot after installation.

Step 5: Verify WSL Service

Check if the service exists:

Get-Service LxssManager

Expected output:

Status   Name          DisplayName
------   ----          -----------
Running  LxssManager   LxssManager

If the service still does not exist, perform an in-place repair upgrade of Windows 11.

Step 6: In-Place Repair Upgrade (Recommended)

If WSL services are still missing, the cleanest solution is an in-place Windows repair.

Download the Windows 11 installer from Microsoft and choose:

Keep personal files and apps

This repairs:

Missing system services
Broken Hyper-V registrations
Corrupted WSL components
Windows component store issues

without deleting personal data.

Step 7: Upgrade from WSL1 to WSL2

Once Windows is repaired, migrate your distro to WSL2.

Check current versions:

wsl -l -v

Example:

NAME      STATE   VERSION
Ubuntu    Running 1

Set WSL2 as default:

wsl --set-default-version 2

Convert the distro:

wsl --set-version Ubuntu 2

Verify again:

wsl -l -v

Expected:

VERSION = 2

Step 8: Verify Node.js and npm

Inside WSL:

node -v
npm -v

Both commands should now work correctly.

Why WSL2 Matters for Developers

WSL2 includes:

A real Linux kernel
Better filesystem performance
Docker compatibility
Improved networking
Better Node.js compatibility
Proper Linux syscall support

For modern web development, DevOps, and container workflows, WSL2 is effectively required.

Recommended Setup After Repair

After fixing WSL:

Install Node.js using nvm
Use Docker Desktop with WSL2 integration
Store projects inside the Linux filesystem (~/projects)
Use VS Code Remote WSL extension
Keep Windows and WSL updated regularly

Removing Ubuntu from WSL

To remove Ubuntu from WSL on Windows, you unregister the distro. This completely deletes the Linux environment and all associated files.

Step 1 — See Installed WSL Distros

Open PowerShell:

wsl -l -v

Example output:

  NAME      STATE   VERSION
* Ubuntu    Running 2

Step 2 — Stop WSL

Before unregistering the distro, shut down WSL:

wsl --shutdown

Step 3 — Uninstall Ubuntu from WSL

Run:

wsl --unregister Ubuntu

If your distro name is different, use the exact name:

wsl --unregister Ubuntu-22.04

This permanently deletes:

Linux files
/home directory
Installed packages
User configuration

This action cannot be undone.

Step 4 — Remove Leftover App (Optional)

If Ubuntu was installed from Microsoft Store:

Settings → Apps → Installed apps

Search for:

Ubuntu

Then click:

Uninstall

Step 5 — Verify Removal

Run:

wsl -l -v

Ubuntu should no longer appear.

Reinstall Ubuntu Cleanly

If your goal is to repair filesystem corruption or reset the environment, reinstall Ubuntu cleanly:

wsl --install -d Ubuntu

WSL2 Disk Space Tip: Enable Sparse VHD Storage

WSL2 stores Linux files inside a virtual disk (ext4.vhdx). Over time this file can grow very large and not automatically shrink.

To reclaim disk space efficiently, newer WSL versions support sparse virtual disks.

Check current WSL version:

wsl --version

To optimize and compact WSL storage:

wsl --shutdown

Then from PowerShell:

Optimize-VHD -Path "$env:LOCALAPPDATA\Packages\<DISTRO_PACKAGE>\LocalState\ext4.vhdx" -Mode Full

You may need Hyper-V PowerShell tools enabled.

Another useful command for newer WSL builds:

wsl --manage <distro-name> --set-sparse true

Example:

wsl --manage Ubuntu --set-sparse true

Sparse mode helps reduce unnecessary disk growth and improves storage efficiency for development environments.

Final Thoughts

The key insight during debugging was recognizing that this was not simply a Node.js problem.

The real issue was:

a broken WSL service stack on Windows
combined with an outdated WSL1 distro

Once the Windows virtualization stack and WSL services were repaired, upgrading to WSL2 resolved the development environment issues completely.

If you encounter missing LxssManager, 0x8007041d, or WSL1 compatibility problems, focus on repairing Windows components first before reinstalling developer tools.

Deploying a React Application to AWS: Implementing a Production-Ready CI/CD Pipeline with Terraform

coder7475 — Wed, 28 Jan 2026 16:21:31 +0000

In this article, I present a reliable configuration for deploying React applications to AWS. This approach utilizes Terraform to manage infrastructure as code, Amazon S3 for static asset storage, Amazon CloudFront for efficient content distribution, and AWS CodePipeline to automate the continuous integration and continuous deployment (CI/CD) process.

The resulting pipeline provides scalable global performance, robust security measures, and uninterrupted service during updates, with zero downtime. Operational costs are projected to range from $5 to $20 monthly, depending on traffic volume.

Rationale for the Selected Technologies

Contemporary web applications require low-latency access, consistent reliability, and streamlined automation. The AWS services employed here address these requirements comprehensively:

AWS CodePipeline coordinates the entire deployment workflow, ensuring orderly progression through each stage.
Amazon S3 offers economical and resilient storage for static files.
Amazon CloudFront employs edge caching to achieve sub-second load times worldwide.
Terraform facilitates declarative infrastructure provisioning, promoting repeatability and auditability.

Architectural Overview

The workflow initiates upon commits to the GitHub repository: the code is built using AWS CodeBuild, artifacts are synchronized to S3, CloudFront caches are invalidated through a Lambda function, and content is served via the CloudFront distribution. This design inherently supports zero-downtime deployments.

End users access the application with immediate availability of updated content, free from caching inconsistencies.

Essential Components

GitHub Repository: Acts as the version control system, triggering the pipeline upon pushes to the main branch.
AWS CodePipeline: Serves as the orchestration layer, sequencing stages for source retrieval, building, deployment, and cache invalidation.
AWS CodeBuild: Executes Node.js-based builds, including dependency installation and the production bundling command (npm ci && npm run build).
Amazon S3 Bucket: Provides private, versioned storage for deployment artifacts, with strict access controls.
Amazon CloudFront with Origin Access Control (OAC): Delivers content securely from S3, incorporating single-page application (SPA) error handling to route 403 and 404 responses appropriately.
AWS Lambda: Performs automated cache invalidation for CloudFront following each deployment, ensuring content freshness.

Prerequisites

To proceed, ensure the following are in place:

An active AWS account, preferably utilizing the free tier for initial validation.
A GitHub repository containing a React application developed with Vite.
Required tools: AWS Command Line Interface (CLI) with configured credentials, Terraform version 1.0 or later, and Node.js version 18 or higher.
Proficiency with basic command-line operations.

A detailed checklist is provided in the repository's README file.

Step 1: Prepare the React Application

Configure the Vite build settings for production deployment by updating vite.config.ts:

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()],
  base: '/',
  build: {
    outDir: 'dist',
  },
});

Execute npm run build locally to confirm that the dist directory contains the optimized assets. A sample application is available for cloning: Repository.

Step 2: Infrastructure Definition Using Terraform

Obtain the Terraform configuration files (.tf) from the repository. The following sections highlight the primary resources.

Configuration of the Private S3 Bucket

resource "random_id" "suffix" {
  byte_length = 4
}

# S3 Bucket (Private and Versioned)
resource "aws_s3_bucket" "website_bucket" {
  bucket        = "${var.project_name}-website-${random_id.suffix.hex}"
  force_destroy = true
}

resource "aws_s3_bucket_public_access_block" "website_bucket_public_access" {
  bucket                 = aws_s3_bucket.website_bucket.id
  block_public_acls      = true
  ignore_public_acls     = true
  block_public_policy    = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_versioning" "website_bucket_versioning" {
  bucket = aws_s3_bucket.website_bucket.id
  versioning_configuration {
    status = "Enabled"
  }
}

This configuration enforces privacy, permitting access exclusively through authorized CloudFront origins.

Amazon CloudFront Distribution with Origin Access Control

# Origin Access Control for Secure S3 Integration
resource "aws_cloudfront_origin_access_control" "s3_oac" {
  name                              = "${var.project_name}-oac"
  description                       = "OAC for ${var.project_name} S3 bucket"
  origin_access_control_origin_type = "s3"
  signing_behavior                  = "always"
  signing_protocol                  = "sigv4"
}

# CloudFront Distribution
resource "aws_cloudfront_distribution" "website" {
  origin {
    domain_name              = aws_s3_bucket.website_bucket.bucket_regional_domain_name
    origin_id                = "S3Origin"
    origin_access_control_id = aws_cloudfront_origin_access_control.s3_oac.id
  }

  enabled           = true
  is_ipv6_enabled   = true
  default_root_object = "index.html"

  default_cache_behavior {
    allowed_methods  = ["GET", "HEAD", "OPTIONS"]
    cached_methods   = ["GET", "HEAD"]
    target_origin_id = "S3Origin"
    compress         = true

    forwarded_values {
      query_string = true
      cookies {
        forward = "none"
      }
      headers = [
        "Accept", "Accept-Charset", "Accept-Encoding", "Accept-Language",
        "Origin", "Referer", "User-Agent"
      ]
    }

    min_ttl                = 0
    default_ttl            = 300  # 5 minutes
    max_ttl                = 86400  # 24 hours
    viewer_protocol_policy = "redirect-to-https"
  }

  # Extended Caching for Assets
  ordered_cache_behavior {
    path_pattern     = "/assets/*"
    allowed_methods  = ["GET", "HEAD", "OPTIONS"]
    cached_methods   = ["GET", "HEAD"]
    target_origin_id = "S3Origin"
    compress         = true

    forwarded_values {
      query_string = false
      cookies {
        forward = "none"
      }
    }

    min_ttl                = 0
    default_ttl            = 31536000  # 1 year
    max_ttl                = 31536000
    viewer_protocol_policy = "redirect-to-https"
  }

  # Error Responses for Single-Page Applications
  custom_error_response {
    error_code            = 404
    response_code         = 200
    response_page_path    = "/index.html"
    error_caching_min_ttl = 300
  }

  custom_error_response {
    error_code            = 403
    response_code         = 200
    response_page_path    = "/index.html"
    error_caching_min_ttl = 300
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  viewer_certificate {
    cloudfront_default_certificate = true
  }

  tags = {
    Name = "${var.project_name}-distribution"
  }
}

This setup ensures compatibility with React Router by redirecting 404 and 403 errors to index.html for client-side handling.

S3 Bucket Policy for CloudFront Access

resource "aws_s3_bucket_policy" "website_bucket_policy" {
  bucket = aws_s3_bucket.website_bucket.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid       = "AllowCloudFrontOAC"
        Effect    = "Allow"
        Principal = { Service = "cloudfront.amazonaws.com" }
        Action    = ["s3:GetObject", "s3:ListBucket"]
        Resource  = [aws_s3_bucket.website_bucket.arn, "${aws_s3_bucket.website_bucket.arn}/*"]
        Condition = {
          StringEquals = { "AWS:SourceArn" = aws_cloudfront_distribution.website.arn }
        }
      }
    ]
  })
}

Inclusion of the s3:ListBucket action avoids erroneous 404 responses during object listings.

AWS CodePipeline and Lambda Integration

The pipeline comprises stages for GitHub source retrieval, CodeBuild execution, S3 synchronization, and Lambda-triggered invalidation.

The Lambda function, implemented in Python with comprehensive error handling, is as follows:

import json
import boto3
import os
from botocore.exceptions import ClientError

def handler(event, context):
    """
    Performs CloudFront cache invalidation following deployment.
    """
    cloudfront = boto3.client('cloudfront')
    codepipeline = boto3.client('codepipeline')
    job_id = event['CodePipeline.job']['id']

    try:
        distribution_id = os.environ.get('DISTRIBUTION_ID')
        if not distribution_id:
            raise ValueError("DISTRIBUTION_ID environment variable not set")

        print(f"Invalidating distribution: {distribution_id}")
        response = cloudfront.create_invalidation(
            DistributionId=distribution_id,
            InvalidationBatch={
                'Paths': {'Quantity': 1, 'Items': ['/*']},
                'CallerReference': f"pipeline-{job_id}-{context.aws_request_id}"
            }
        )
        invalidation_id = response['Invalidation']['Id']
        print(f"Invalidation created: {invalidation_id}")

        codepipeline.put_job_success_result(jobId=job_id)
        return {
            'statusCode': 200,
            'body': json.dumps({'invalidation_id': invalidation_id})
        }

    except ClientError as e:
        error_msg = f"AWS Client Error: {str(e)}"
        print(error_msg)
        codepipeline.put_job_failure_result(
            jobId=job_id,
            failureDetails={'message': error_msg}
        )
        return {'statusCode': 500, 'body': json.dumps({'error': error_msg})}

    except Exception as e:
        error_msg = f"Unexpected error: {str(e)}"
        print(error_msg)
        codepipeline.put_job_failure_result(
            jobId=job_id,
            failureDetails={'message': error_msg}
        )
        return {'statusCode': 500, 'body': json.dumps({'error': error_msg})}

Appropriate IAM permissions must be assigned to the CodePipeline execution role, including lambda:InvokeFunction.

Step 3: Provision the Infrastructure

cd terraform
cp example.terraform.tfvars terraform.tfvars  # Update project_name="myapp"
terraform init
terraform plan
terraform apply

Upon completion, Terraform will output the CloudFront distribution URL and pipeline details for reference.

Step 4: Integrate the GitHub Repository

In the AWS Management Console, navigate to CodePipeline > Connections. Authorize the GitHub App and select the target repository and branch to enable webhook-based triggers.

Step 5: Initiate the Deployment

Commit and push changes to the main branch. Monitor progress in the AWS Console:

Source Stage: Retrieves the latest code from GitHub.
Build Stage: Installs dependencies and executes npm run build.
Deploy Stage: Synchronizes the dist directory to the S3 bucket using aws s3 sync.
Invalidation Stage: Invokes the Lambda function to clear CloudFront caches.

The application will be accessible at the provisioned CloudFront URL (e.g., https://dxxxx.cloudfront.net).

Troubleshooting Common Issues

Issue	Root Cause	Resolution
Pipeline Status "Pending"	GitHub authorization failure	AWS Console > CodePipeline > Connections > Re-authorize GitHub App
CloudFront Returns 404	Missing `s3:ListBucket` permission	Update S3 policy to include the action; execute `terraform apply`
Assets Return 403	"Host" header forwarded	Remove "Host" from CloudFront `forwarded_values` configuration
Blank Application Page	Incorrect MIME types	Configure CodeBuild to set `Content-Type` during S3 synchronization
Lambda Invocation Failure	Insufficient IAM permissions	Attach `lambda:InvokeFunction` policy to the CodePipeline execution role

For manual cache invalidation, execute: aws cloudfront create-invalidation --distribution-id <ID> --paths "/*".

Scaling and Cost Management

Free Tier Benefits: Includes 1 TB of CloudFront data transfer and 5 GB of S3 storage at no additional charge.
Production Enhancements: Incorporate Amazon Route 53 for custom domains and multi-region CloudFront distributions for reduced latency.
Monitoring Practices: Establish Amazon CloudWatch alarms for error rates exceeding 1% to enable proactive remediation.

This configuration readily accommodates enterprise-scale workloads.

Conclusion

This solution establishes a solid foundation for deploying React applications on AWS with professional-grade reliability and efficiency. I recommend forking the repository, customizing as needed, and refining based on operational insights. For further inquiries, please open an issue on GitHub.

Complete Source Code and README

Understanding the ACID Concept with PostgreSQL

coder7475 — Sat, 13 Sep 2025 06:58:23 +0000

Introduction to ACID

ACID is an acronym representing Atomicity, Consistency, Isolation, and Durability, a set of properties that ensure reliable and predictable database transactions. These principles are foundational to relational database management systems (RDBMS) like PostgreSQL, guaranteeing data integrity and robustness, particularly in critical applications such as banking or inventory management. This blog explains each ACID property, demonstrates how PostgreSQL implements them, and provides practical examples.

What is ACID?

ACID properties are designed to ensure that database transactions are processed reliably, even in the presence of errors, concurrency, or system failures. They are particularly critical in systems where data accuracy and consistency are paramount, contrasting with the BASE model used in some NoSQL databases.

Components of ACID

Atomicity: Ensures a transaction is treated as a single, indivisible unit—either all operations succeed, or none are applied.
Consistency: Guarantees that a transaction brings the database from one valid state to another, adhering to all defined constraints and rules.
Isolation: Ensures transactions execute independently, preventing interference from concurrent transactions.
Durability: Guarantees that committed transactions are permanently saved, even in the event of a system failure.

ACID in PostgreSQL

PostgreSQL, a powerful open-source RDBMS, robustly implements ACID properties through its advanced features, making it a reliable choice for applications requiring strict data integrity. Below, we explore each property with PostgreSQL-specific implementations and examples.

1. Atomicity

Definition: Atomicity ensures that all operations within a transaction are completed successfully, or none are applied, preventing partial updates that could lead to data inconsistencies.

PostgreSQL Implementation:

PostgreSQL uses its transaction management system, with BEGIN, COMMIT, and ROLLBACK commands, to enforce atomicity.
If an error occurs (e.g., a constraint violation or system crash), PostgreSQL automatically rolls back the transaction, ensuring no partial changes persist.
Savepoints allow partial rollbacks within a transaction, offering fine-grained control.

Example: Transferring $100 between two bank accounts.

BEGIN;

UPDATE accounts 
SET balance = balance - 100 
WHERE account_id = 'A' AND balance >= 100;

UPDATE accounts 
SET balance = balance + 100 
WHERE account_id = 'B';

-- If both updates succeed, commit the transaction
COMMIT;

-- If an error occurs, rollback ensures no changes are applied
-- ROLLBACK;

Explanation: If the debit from Account A succeeds but the credit to Account B fails, PostgreSQL rolls back both operations, ensuring atomicity.

2. Consistency

Definition: Consistency ensures that a transaction transitions the database from one valid state to another, respecting all constraints, such as primary keys, foreign keys, and check constraints.

PostgreSQL Implementation:

PostgreSQL enforces constraints (e.g., PRIMARY KEY, FOREIGN KEY, CHECK, UNIQUE) during transactions to maintain data integrity.
The Multiversion Concurrency Control (MVCC) system ensures that each transaction operates on a consistent snapshot of the database.
Triggers and rules can further enforce custom consistency requirements.

Example: Inserting a record with a constraint.

CREATE TABLE employees (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    age INT CHECK (age >= 18)
);

BEGIN;
INSERT INTO employees (name, age) VALUES ('Alice', 25); -- Valid
INSERT INTO employees (name, age) VALUES ('Bob', 16);   -- Violates CHECK constraint
COMMIT;

Explanation: The second INSERT fails due to the age >= 18 constraint, causing the transaction to roll back, preserving database consistency.

3. Isolation

Definition: Isolation ensures that transactions execute independently, preventing partial changes from one transaction from affecting others until committed.

PostgreSQL Implementation:

PostgreSQL’s MVCC provides each transaction with a snapshot of the database, isolating it from concurrent changes.
Supported isolation levels include:
- Read Committed (default): Transactions see only committed data.
- Repeatable Read: Prevents non-repeatable reads by using a consistent snapshot.
- Serializable: Ensures transactions behave as if executed sequentially, preventing phantom reads.
Isolation levels are set using SET TRANSACTION ISOLATION LEVEL.

Example: Concurrent updates with Repeatable Read.

-- Transaction 1
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;
SELECT balance FROM accounts WHERE account_id = 'A'; -- Sees balance as 500
-- (Other transaction updates balance to 600)
SELECT balance FROM accounts WHERE account_id = 'A'; -- Still sees 500
COMMIT;

-- Transaction 2
BEGIN;
UPDATE accounts SET balance = 600 WHERE account_id = 'A';
COMMIT;

Explanation: MVCC ensures Transaction 1 sees a consistent snapshot, isolating it from Transaction 2’s update until it commits.

4. Durability

Definition: Durability guarantees that once a transaction is committed, its changes are permanently saved, even if the system fails immediately after.

PostgreSQL Implementation:

PostgreSQL uses Write-Ahead Logging (WAL) to record transaction details to non-volatile storage before committing.
The fsync configuration ensures data is physically written to disk.
Checkpoints optimize recovery by periodically syncing the database state with the WAL.

Example: Committing a transaction.

BEGIN;
INSERT INTO orders (order_id, product, amount) VALUES (1, 'Laptop', 999.99);
COMMIT;

Explanation: The INSERT is logged to the WAL before the COMMIT completes. If the server crashes, PostgreSQL replays the WAL to recover the committed transaction, ensuring durability.

PostgreSQL-Specific Features Supporting ACID

MVCC: Enables consistency and isolation by providing transaction snapshots, reducing conflicts in concurrent environments.
WAL: Ensures durability and supports crash recovery by logging all changes.
Checkpoints: Improve recovery efficiency by marking stable database states.
Transaction Commands: BEGIN, COMMIT, ROLLBACK, and SAVEPOINT provide precise control over transactions.
Constraint Enforcement: Validates data integrity with primary keys, foreign keys, and custom triggers.

Practical Example: Bank Transfer

A complete example of a bank transfer demonstrating all ACID properties.

CREATE TABLE accounts (
    account_id VARCHAR(10) PRIMARY KEY,
    balance NUMERIC CHECK (balance >= 0)
);

INSERT INTO accounts (account_id, balance) VALUES ('A', 500), ('B', 200);

BEGIN;
-- Check sufficient funds
UPDATE accounts 
SET balance = balance - 100 
WHERE account_id = 'A' AND balance >= 100;

-- Credit the recipient
UPDATE accounts 
SET balance = balance + 100 
WHERE account_id = 'B';

-- Ensure both updates succeed
COMMIT;

Explanation:

Atomicity: Both UPDATE statements succeed, or both are rolled back.
Consistency: The CHECK (balance >= 0) constraint ensures valid balances.
Isolation: MVCC prevents other transactions from seeing partial updates.
Durability: WAL ensures the committed changes persist after a crash.

Conclusion

PostgreSQL’s robust implementation of ACID properties—through MVCC, WAL, constraint enforcement, and transaction management—makes it a reliable choice for applications requiring high data integrity. Whether managing financial transactions, e-commerce orders, or enterprise data, PostgreSQL ensures atomic, consistent, isolated, and durable operations, providing a solid foundation for mission-critical systems.

References

PostgreSQL Documentation: https://www.postgresql.org/docs/current/mvcc.html
Write-Ahead Logging (WAL): https://www.postgresql.org/docs/current/wal.html
Transaction Management in PostgreSQL: https://www.postgresql.org/docs/current/tutorial-transactions.html
ACID Properties Overview: https://www.geeksforgeeks.org/acid-properties-in-dbms/
PostgreSQL Isolation Levels: https://www.postgresql.org/docs/current/transaction-iso.html

Running PostgreSQL in Docker and Accessing It from Your OS

coder7475 — Tue, 26 Aug 2025 01:36:18 +0000

PostgreSQL is one of the most popular relational databases, widely used in modern applications for its reliability and powerful features. Running it inside Docker makes local development and testing much easier, as you can quickly spin up and tear down isolated environments.

In this post, we’ll see how to:

Run PostgreSQL inside a Docker container.
Use Docker Compose for easier setup.
Connect to PostgreSQL from your local machine.
Get the connection URI for your applications.

Running PostgreSQL with Docker

You can start PostgreSQL with a single docker run command:

docker run --name postgres-container \
  -e POSTGRES_USER=admin \
  -e POSTGRES_PASSWORD=secret \
  -e POSTGRES_DB=mydb \
  -p 5432:5432 \
  -d postgres:15

--name postgres-container → assigns a name to the container.
POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB → environment variables for setup.
-p 5432:5432 → maps PostgreSQL’s port to your host machine.
postgres:15 → uses the official PostgreSQL image (version 15).

Once started, you can connect with:

psql -h localhost -U admin -d mydb

It will prompt for the password (secret).

Using Docker Compose

Instead of remembering a long docker run command, we can use docker-compose for a cleaner setup.

Create a file named docker-compose.yml:

version: "3.9"
services:
  postgres:
    image: postgres:15
    container_name: postgres-container
    environment:
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: mydb
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

Run it with:

docker-compose up -d

This will:

Start PostgreSQL in a container.
Expose it on port 5432.
Persist data in a Docker volume so it isn’t lost when the container restarts.

Connecting from Your OS

Now you can connect using any PostgreSQL client:

From terminal:

psql -h localhost -U admin -d mydb

From GUI tool (like pgAdmin, DBeaver, or TablePlus):

Host: localhost
Port: 5432
User: admin
Password: secret
Database: mydb

Connection URI

For use in applications, you’ll often need the full PostgreSQL connection URI.

From your host machine:

postgresql://admin:secret@localhost:5432/mydb

From another service inside the same Docker Compose network:

postgresql://admin:secret@postgres:5432/mydb

(where postgres is the service name defined in docker-compose.yml).

Wrapping Up

Running PostgreSQL with Docker makes your development environment consistent, portable, and easy to manage. With Docker Compose, you get reproducible configurations and persistent storage with minimal effort.

You can now connect directly using psql, GUI clients, or application frameworks by providing the connection URI.

Running MongoDB in Docker and Accessing It from Your OS

coder7475 — Sun, 24 Aug 2025 05:58:49 +0000

MongoDB is one of the most popular NoSQL databases, and running it inside a Docker container makes it lightweight, isolated, and portable. In this post, we’ll walk through how to set up MongoDB with Docker, persist your data, and access it both from your application containers and directly from your host machine (OS) using tools like MongoDB Compass.

🔹 Why Use Docker for MongoDB?

Isolation: MongoDB runs in a container, independent of your OS setup.
Portability: Same configuration runs on any machine with Docker.
Persistence: Store data in Docker volumes so it survives container restarts.
Networking: Easy communication between your app and MongoDB using Docker networks.

🛠 Step 1: Run MongoDB in Docker

We’ll start with a simple docker run command:

docker run -d \
  --name mongo \
  -p 27017:27017 \
  -e MONGO_INITDB_ROOT_USERNAME=root \
  -e MONGO_INITDB_ROOT_PASSWORD=example \
  -v mongo-data:/data/db \
  mongo:7

Explanation:

-d → run in detached mode
--name mongo → name the container mongo
-p 27017:27017 → map container port 27017 to host port 27017
-e MONGO_INITDB_ROOT_USERNAME=root → admin username
-e MONGO_INITDB_ROOT_PASSWORD=example → admin password
-v mongo-data:/data/db → persistent storage for MongoDB data
mongo:7 → official MongoDB v7 image

Now you have MongoDB running in Docker 🎉

🛠 Step 2: Verify MongoDB Is Running

Run:

docker ps

You should see your mongo container up and exposing port 27017.

🛠 Step 3: Access MongoDB from Your OS

Since we mapped port 27017, you can connect using localhost from your machine.

Using MongoDB Compass:

Open Compass.

Enter the connection string:

mongodb://root:example@localhost:27017/mydatabase?authSource=admin

- `root:example` → matches the username/password set in `docker run`

- `localhost:27017` → because the port is exposed to your host

- `mydatabase` → any database you want to connect to

- `authSource=admin` → required since root user is created in the `admin` database

Click Connect ✅

🛠 Step 4: Access MongoDB from CLI

You can also connect from your terminal using mongosh (if installed):

mongosh "mongodb://root:example@localhost:27017/mydatabase?authSource=admin"

🛠 Step 5: Access MongoDB from Another Container

If your application container needs to connect to MongoDB:

Use the container name (mongo) as hostname inside the Docker network.
Example .env for your app:

MONGO_URL=mongodb://root:example@mongo:27017/mydatabase?authSource=admin

🔑 Note: mongo works inside Docker network, but from your host OS, you must use localhost.

🎯 Wrapping Up

You’ve just:

Run MongoDB in Docker with persistence.
Connected from your host OS using localhost.
Learned the difference between connecting from inside Docker vs. outside.

This approach is great for local development, prototyping, or even small deployments. For production, you’d likely want to configure authentication, backups, and monitoring.

Want to Learn OOP Principle SOLID in TypeScript. This post is for you!!

coder7475 — Wed, 20 Aug 2025 13:12:08 +0000

Mastering the SOLID Principles — The Foundation of Clean, Scalable Code

coder7475 ・ Aug 18 '25

#oop #typescript #solid #designpatterns

Comprehensive OOP concepts explained with concise and easy-to-understand examples.

coder7475 — Tue, 19 Aug 2025 05:27:08 +0000

coder7475

Aug 18 '25

The Four Pillars of Object-Oriented Programming in TypeScript

#oop #programing #typescript

3 min read

Mastering the SOLID Principles — The Foundation of Clean, Scalable Code

coder7475 — Mon, 18 Aug 2025 13:38:09 +0000

If you want to write cleaner, more maintainable, and scalable software, mastering the SOLID principles is essential. These five core object-oriented design principles empower you to build systems that are easier to understand, extend, and test — without introducing chaos.

Here's a quick breakdown:

S — Single Responsibility Principle (SRP)

Every class or module should have one clear responsibility.

When a class tries to do too many things, it becomes harder to maintain and more prone to bugs.

O — Open/Closed Principle (OCP)

Software should be open for extension, but closed for modification.

You should be able to add new features without rewriting existing code, minimizing the risk of regressions.

L — Liskov Substitution Principle (LSP)

Subtypes must be replaceable for their base types without altering the program’s behavior.

If a subclass breaks the expectations set by the parent class, it violates this principle.

I — Interface Segregation Principle (ISP)

Don't force a class to implement methods it doesn't need.

Instead of one large interface, create smaller, role-specific interfaces.

D — Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules — both should depend on abstractions.

This decouples your code and makes it easier to modify and test.

The SOLID principles are foundational guidelines for object-oriented design. They help you create clean, maintainable, and scalable software systems. This guide includes detailed explanations and practical TypeScript examples to illustrate each principle.

S — Single Responsibility Principle (SRP)

Definition: A class should have only one reason to change, meaning it should have a single, well-defined responsibility.

Why It Matters: Mixing responsibilities (e.g., validation and persistence) makes a class fragile—changes to one task can break others. SRP improves modularity and testability.

Violation Example:

// SRP Violating Example
interface Order {
    id: number;
    items: string[];
    total: number;
    customerEmail: string;
}

class OrderProcessor {
    processOrder(order: Order): void {
        if (!order) throw new Error("Order cannot be null");

        // 1. Validate order
        if (order.items.length === 0) {
            throw new Error("Order must have at least one item");
        }

        // 2. Process payment
        console.log(`Processing payment of $${order.total} for order ${order.id}`);

        // 3. Save to database
        console.log(`Saving order ${order.id} with ${order.items.length} items to database`);

        // 4. Send confirmation email
        console.log(`Sending confirmation email to ${order.customerEmail}`);
    }
}

This class handles too much, making it hard to maintain.

Refactored (SRP Applied):

interface Order {
    id: number;
    items: string[];
    total: number;
}

class OrderValidator {
    validate(order: Order): void {
        if (!order) throw new Error("Order cannot be null");
    }
}

class PaymentProcessor {
    processPayment(order: Order): void {
        console.log(`Processing payment for order ${order.id}`);
    }
}

class OrderRepository {
    save(order: Order): void {
        console.log(`Saving order ${order.id} to database`);
    }
}

class EmailNotifier {
    sendConfirmation(order: Order): void {
        console.log(`Sending confirmation email for order ${order.id}`);
    }
}

class OrderProcessor {
    private validator: OrderValidator;
    private paymentProcessor: PaymentProcessor;
    private repository: OrderRepository;
    private notifier: EmailNotifier;

    constructor(
        validator: OrderValidator,
        paymentProcessor: PaymentProcessor,
        repository: OrderRepository,
        notifier: EmailNotifier
    ) {
        this.validator = validator;
        this.paymentProcessor = paymentProcessor;
        this.repository = repository;
        this.notifier = notifier;
    }

    process(order: Order): void {
        this.validator.validate(order);
        this.paymentProcessor.processPayment(order);
        this.repository.save(order);
        this.notifier.sendConfirmation(order);
    }
}

Each class now focuses on one task, enhancing clarity and flexibility.

O — Open/Closed Principle (OCP)

Definition: Software entities should be open for extension but closed for modification.

Why It Matters: Modifying existing code risks bugs. OCP allows new functionality via extensions (e.g., interfaces) without altering tested code.

Violation Example:

class InvoicePrinter {
    print(invoice: any, format: string): void {
        if (format === "PDF") {
            // Generate PDF
        } else if (format === "Excel") {
            // Generate Excel
        }
    }
}

Adding a new format requires changing this class.

Refactored (OCP Applied):

interface Invoice {
    id: number;
    amount: number;
}

interface IInvoicePrinter {
    print(invoice: Invoice): void;
}

class PdfInvoicePrinter implements IInvoicePrinter {
    print(invoice: Invoice): void {
        console.log(`Printing PDF invoice for invoice ${invoice.id}`);
    }
}

class ExcelInvoicePrinter implements IInvoicePrinter {
    print(invoice: Invoice): void {
        console.log(`Printing Excel invoice for invoice ${invoice.id}`);
    }
}

class InvoiceService {
    private printer: IInvoicePrinter;

    constructor(printer: IInvoicePrinter) {
        if (!printer) throw new Error("Printer cannot be null");
        this.printer = printer;
    }

    printInvoice(invoice: Invoice): void {
        this.printer.print(invoice);
    }
}

New printers (e.g., HtmlInvoicePrinter) can be added without modifying InvoiceService.

L — Liskov Substitution Principle (LSP)

Definition: Subtypes must be substitutable for their base types without altering expected behavior.

Why It Matters: Violating LSP causes errors when subclasses don’t meet the parent’s contract.

Violation Example:

class Vehicle {
    startEngine(): void {
        // Start engine
    }
}

class ElectricCar extends Vehicle {
    startEngine(): void {
        throw new Error("Electric cars don’t have engines!");
    }
}

ElectricCar breaks code expecting startEngine.

Refactored (LSP Respected):

abstract class Vehicle {
    abstract start(): void;
}

interface ICombustionVehicle {
    startEngine(): void;
}

class GasolineCar extends Vehicle implements ICombustionVehicle {
    start(): void {
        this.startEngine();
    }

    startEngine(): void {
        console.log("Gasoline engine started.");
    }
}

class ElectricCar extends Vehicle {
    start(): void {
        console.log("Electric motor activated.");
    }
}

Both subclasses work as Vehicle without issues.

I — Interface Segregation Principle (ISP)

Definition: Classes shouldn’t be forced to implement unused interfaces.

Why It Matters: Large interfaces create unnecessary dependencies. ISP favors smaller, specific interfaces.

Violation Example:

interface IWorker {
    work(): void;
    takeBreak(): void;
}

class Robot implements IWorker {
    work(): void {
        console.log("Robot working...");
    }

    takeBreak(): void {
        throw new Error("Robots don’t take breaks!");
    }
}

Robot is forced to implement an irrelevant method.

Refactored (ISP Applied):

interface IWorkable {
    work(): void;
}

interface IBreakable {
    takeBreak(): void;
}

class Human implements IWorkable, IBreakable {
    work(): void {
        console.log("Human working...");
    }

    takeBreak(): void {
        console.log("Human taking a break...");
    }
}

class Robot implements IWorkable {
    work(): void {
        console.log("Robot working...");
    }
}

Robot only implements what it needs.

D — Dependency Inversion Principle (DIP)

Definition: High-level modules should depend on abstractions, not low-level details.

Why It Matters: Tight coupling limits flexibility. DIP uses abstractions for loose coupling.

Violation Example:

class Notification {
    private emailService = new EmailService();

    send(message: string): void {
        this.emailService.sendEmail(message);
    }
}

class EmailService {
    sendEmail(message: string): void {
        console.log(`Email sent: ${message}`);
    }
}

Notification is tied to EmailService.

Refactored (DIP Applied):

interface IMessageService {
    send(message: string): void;
}

class EmailService implements IMessageService {
    send(message: string): void {
        console.log(`Email sent: ${message}`);
    }
}

class SmsService implements IMessageService {
    send(message: string): void {
        console.log(`SMS sent: ${message}`);
    }
}

class Notification {
    private service: IMessageService;

    constructor(service: IMessageService) {
        if (!service) throw new Error("Service cannot be null");
        this.service = service;
    }

    send(message: string): void {
        this.service.send(message);
    }
}

Notification works with any IMessageService implementation.

Final Thoughts

Applying SOLID in TypeScript yields cleaner, more testable, and adaptable code.

The Four Pillars of Object-Oriented Programming in TypeScript

coder7475 — Mon, 18 Aug 2025 04:06:47 +0000

Object-Oriented Programming (OOP) is built on four fundamental principles, often referred to as the "pillars" of OOP. These principles help developers create modular, maintainable, and scalable software systems. The four pillars are:

Encapsulation
Abstraction
Inheritance
Polymorphism

Let’s explore each pillar with practical TypeScript examples.

1. Encapsulation

Encapsulation bundles data and methods into a class while restricting direct access to internal details, using access modifiers and getters/setters. It hides complexity and protects state integrity.

Purpose: Safeguards data from invalid modifications, improves maintainability, and supports modularity.

Example:

class BankAccount {
    private balance: number = 0;

    public deposit(amount: number): void {
        if (amount > 0) this.balance += amount;
    }

    public withdraw(amount: number): void {
        if (amount > 0 && amount <= this.balance) this.balance -= amount;
    }

    public getBalance(): number {
        return this.balance;
    }
}

const account = new BankAccount();
account.deposit(100);
account.withdraw(50);
console.log(account.getBalance());  // Output: 50

Benefits: Enhances security, reduces dependencies on internal implementations.

2. Abstraction

Abstraction conceals intricate details, exposing only essential functionalities. It is realized through abstract classes or interfaces, emphasizing "what" over "how."

Purpose: Simplifies complexity, boosts readability, and facilitates loose coupling.

Example using an abstract class:

abstract class Shape {
    abstract calculateArea(): number;
}

class Circle extends Shape {
    constructor(private radius: number) { super(); }

    calculateArea(): number {
        return Math.PI * this.radius ** 2;
    }
}

class Rectangle extends Shape {
    constructor(private width: number, private height: number) { super(); }

    calculateArea(): number {
        return this.width * this.height;
    }
}

const shapes: Shape[] = [new Circle(5), new Rectangle(4, 6)];
shapes.forEach(shape => console.log(shape.calculateArea()));
// Output: 78.53981633974483 \n 24

Benefits: Promotes reusability and easier updates.

For interfaces (another abstraction tool):

interface Shape {
    calculateArea(): number;
}

class Circle implements Shape {
    // Implementation as above
}

Interfaces define contracts without implementations, supporting multiple inheritance.

Difference Between Abstract Class and Interface: Abstract classes can include implemented methods and are suited for shared behavior in related classes (single inheritance only). Interfaces mandate full implementation and allow multiple implementations for unrelated classes.

3. Inheritance

Inheritance enables a child class to acquire properties and methods from a parent class, fostering code reuse and hierarchical structures.

Purpose: Minimizes duplication, models real-world relationships, and supports extension.

Example:

class Animal {
    constructor(protected name: string) {}

    move(distance: number): void {
        console.log(`${this.name} moved ${distance} meters.`);
    }
}

class Dog extends Animal {
    constructor(name: string) { super(name); }

    bark(): void {
        console.log('Woof! Woof!');
    }
}

const dog = new Dog('Buddy');
dog.move(10);  // Output: Buddy moved 10 meters.
dog.bark();    // Output: Woof! Woof!

Benefits: Enhances extensibility, but caution against overuse to avoid fragile hierarchies; prefer composition where appropriate.

4. Polymorphism

Polymorphism permits objects of varied classes to be handled via a common interface, with behavior varying by type. It includes compile-time (overloading) and runtime (overriding) forms.

Purpose: Increases flexibility and adaptability.

Types:

Compile-time (Static Binding/Method Overloading): Methods with identical names but differing parameters; resolved at compile time.
Runtime (Dynamic Binding/Method Overriding): Child classes redefine parent methods; resolved at runtime using virtual methods.

Overloading example:

class MessageFormatter {
  // Overload signatures
  format(message: string): string;
  format(message: string, userId: number): string;
  format(message: string, userId: number, timestamp: Date): string;

  // Single implementation
  format(message: string, userId?: number, timestamp?: Date): string {
    let formatted = message;

    if (userId !== undefined) {
      formatted = `[User ${userId}] ${formatted}`;
    }
    if (timestamp !== undefined) {
      formatted = `${formatted} (at ${timestamp.toISOString()})`;
    }

    return formatted;
  }
}

const formatter = new MessageFormatter();

console.log(formatter.format("System started"));
// Output: System started

console.log(formatter.format("User logged in", 42));
// Output: [User 42] User logged in

console.log(formatter.format("File uploaded", 42, new Date()));
// Output: [User 42] File uploaded (at 2025-08-20T13:10:15.000Z)

Overriding example (using virtual-like behavior via method overriding):

abstract class Payment {
  abstract process(amount: number): void;
}

class CreditCardPayment extends Payment {
  process(amount: number): void {
    console.log(`Processing credit card payment of $${amount}`);
  }
}

class PayPalPayment extends Payment {
  process(amount: number): void {
    console.log(`Processing PayPal payment of $${amount}`);
  }
}

class CryptoPayment extends Payment {
  process(amount: number): void {
    console.log(`Processing cryptocurrency payment of $${amount}`);
  }
}

const payments: Payment[] = [
  new CreditCardPayment(),
  new PayPalPayment(),
  new CryptoPayment(),
];

payments.forEach((payment) => payment.process(100));

// Output:
// Processing credit card payment of $100
// Processing PayPal payment of $100
// Processing cryptocurrency payment of $100

What is a Virtual Method?: A method in a base class that can be overridden in child classes to enable runtime polymorphism.

Difference Between Overloading and Overriding:

Overloading: Same name, different parameters, same class, compile-time resolution.
Overriding: Same signature, different classes (child overrides parent), runtime resolution.

Benefits: Aligns with the Open/Closed Principle, allowing extension without modification.

Summary

Encapsulation: Protects data with controlled access (e.g., BankAccount).
Abstraction: Hides complexity, exposing only essentials (e.g., Shape).
Inheritance: Reuses and extends code (e.g., Animal and Dog).
Polymorphism: Enables flexible behavior (e.g., makeSound() variations).

These pillars, implemented effectively in TypeScript, empower developers to build robust, scalable systems. Let me know if you’d like further clarification or additional examples!

DEV Community: coder7475

Git Submodules Explained for Beginners

What is a Git Submodule?

Why Use Git Submodules?

How Git Stores a Submodule

The .gitmodules File

Adding a Submodule

Cloning a Repository with Submodules

Forgot --recurse-submodules?

Updating a Submodule

Pushing Changes

Detached HEAD Explained

Common Beginner Mistakes

1. Forgetting to clone submodules

2. Updating the submodule but forgetting to commit

3. Editing inside a detached HEAD

Removing a Submodule

When Should You Use Git Submodules?

Final Thoughts

Useful Commands Cheat Sheet

Automating Ubuntu System Maintenance with Cron Jobs

Prerequisites

Step 1: Create a Directory for Scripts

Step 2: Create the Maintenance Script

Understanding the Script

Enable Safe Bash Options

Prevent Multiple Executions

Update Ubuntu Packages

Remove Unused Packages

Clean the APT Cache

Clean Docker Resources

Step 3: Create the Log File

Step 4: Configure Passwordless sudo

Step 5: Schedule the Cron Job

Testing the Script

Recommended Directory Structure

Maintenance Tasks Performed

Conclusion

The Only tmux Cheat Sheet You'll Need as a Developer

What is tmux?

Sessions

List sessions

Create a session

Create a detached session

Attach to a session

Detach from a session

Create or attach (my favorite)

Rename a session

Kill a session

Windows

Create a new window

List windows

Next / Previous window

Jump directly

Rename window

Close window

Panes (Split Terminals)

Vertical split

Horizontal split

Navigate Between Panes

Resize Panes

Zoom a Pane

Change Layout

Close a Pane

Enable Mouse Support

Run Commands in Background

A Typical Development Workflow

Daily Cheat Sheet

Final Thoughts

Fixing WSL Errors on Windows 11

Fixing WSL Errors on Windows 11: From Missing LxssManager to WSL2 Migration

Understanding the Problem

Symptoms

Windows-side Errors

Linux-side Errors

Why This Happens

Step 1: Verify Virtualization

Step 2: Repair Windows Components

Step 3: Re-enable WSL Features

Step 4: Update Windows 11

The `.gitmodules` File

Forgot `--recurse-submodules`?

Fixing WSL Errors on Windows 11: From Missing `LxssManager` to WSL2 Migration