DEV Community: Adetayo Akinsanya

Part 2: Web Server Mastery - Serving Static Content Like a Pro

Adetayo Akinsanya — Sat, 09 Aug 2025 13:16:18 +0000

Building on our foundation from Part 1, let's transform your basic Nginx setup into a high-performance web server that can handle multiple sites, optimize content delivery, and provide an excellent user experience.

What We'll Accomplish Today

By the end of this part, you'll have:

Multiple websites running on a single server
Lightning-fast static file serving with caching
Automatic compression for faster loading
Professional error pages that don't break user experience
Smart redirects and URL rewriting
Performance optimizations that make your sites fly

The Multi-Site Challenge

Remember our simple single-site setup from Part 1? In the real world, you'll often need to serve multiple websites from one server. Let's see how Nginx makes this incredibly straightforward.

Understanding Server Blocks

Think of server blocks as separate apartments in a building. Each has its own address (domain name), its own space (directory), and its own rules, but they all share the same building infrastructure (your server).

Setting Up Multiple Sites

Let's create three different websites to demonstrate various scenarios:

Site 1: Personal Portfolio (Static HTML/CSS/JS)

Create /etc/nginx/sites-available/portfolio.conf:

server {
    listen 80;
    server_name portfolio.local www.portfolio.local;

    root /var/www/portfolio;
    index index.html index.htm;

    # Enable efficient file serving
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    # Main location block
    location / {
        try_files $uri $uri/ =404;

        # Add security headers
        add_header X-Frame-Options "SAMEORIGIN" always;
        add_header X-XSS-Protection "1; mode=block" always;
        add_header X-Content-Type-Options "nosniff" always;
    }

    # Optimize static assets
    location ~* \.(css|js|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
        add_header Vary Accept-Encoding;

        # Enable compression for text-based assets
        gzip_static on;
    }

    # Handle favicon requests gracefully
    location = /favicon.ico {
        log_not_found off;
        access_log off;
        expires 1y;
    }

    # Custom error pages
    error_page 404 /404.html;
    error_page 500 502 503 504 /50x.html;

    location = /50x.html {
        root /usr/share/nginx/html;
    }
}

Site 2: Blog (Static Site Generator - Jekyll/Hugo style)

Create /etc/nginx/sites-available/blog.conf:

server {
    listen 80;
    server_name blog.local www.blog.local;

    root /var/www/blog;
    index index.html;

    # Handle clean URLs (no .html extension)
    location / {
        try_files $uri $uri.html $uri/ =404;
    }

    # Blog-specific optimizations
    location ~* \.(css|js)$ {
        expires 30d;
        add_header Cache-Control "public";
        gzip_static on;
    }

    # Images with longer cache
    location ~* \.(png|jpg|jpeg|gif|webp|svg)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # RSS and sitemap
    location ~* \.(xml|rss)$ {
        expires 1h;
        add_header Content-Type application/xml;
    }

    # Deny access to admin/private files
    location ~ /\. {
        deny all;
        access_log off;
        log_not_found off;
    }

    # Pretty URLs for blog posts
    location ~* ^/posts/(.*)$ {
        try_files /posts/$1.html /posts/$1/index.html =404;
    }
}

Site 3: Single Page Application (React/Vue/Angular)

Create /etc/nginx/sites-available/app.conf:

server {
    listen 80;
    server_name app.local www.app.local;

    root /var/www/app/dist;
    index index.html;

    # Handle client-side routing
    location / {
        try_files $uri $uri/ /index.html;

        # Don't cache the main HTML file
        add_header Cache-Control "no-cache, no-store, must-revalidate";
        add_header Pragma "no-cache";
        add_header Expires "0";
    }

    # Static assets with hash-based filenames
    location ~* \.(js|css)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
        gzip_static on;
    }

    # Images and fonts
    location ~* \.(png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # API proxy (if your SPA needs to call APIs)
    location /api/ {
        proxy_pass http://localhost:3001/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # Health check for load balancers
    location /health {
        access_log off;
        return 200 "healthy\n";
        add_header Content-Type text/plain;
    }
}

Enabling Your Sites

# Create symbolic links to enable sites
sudo ln -s /etc/nginx/sites-available/portfolio.conf /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/blog.conf /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/app.conf /etc/nginx/sites-enabled/

# Create directory structure
sudo mkdir -p /var/www/{portfolio,blog,app/dist}

# Test configuration
sudo nginx -t

# Reload Nginx
sudo systemctl reload nginx

Performance Optimization: Making Your Sites Lightning Fast ⚡

1. Compression Configuration

Create /etc/nginx/conf.d/gzip.conf:

# Enable gzip compression
gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_proxied any;
gzip_comp_level 6;

# Specify which file types to compress
gzip_types
    text/plain
    text/css
    text/xml
    text/javascript
    application/json
    application/javascript
    application/xml+rss
    application/atom+xml
    image/svg+xml
    font/truetype
    font/opentype
    application/font-woff
    application/font-woff2;

# Don't compress already compressed files
gzip_disable "MSIE [1-6]\.";

# Serve pre-compressed files if available
gzip_static on;

2. Advanced Caching Strategy

Create /etc/nginx/conf.d/cache.conf:

# Browser caching for different file types
map $sent_http_content_type $expires {
    default                    off;
    text/html                  1h;
    text/css                   1y;
    application/javascript     1y;
    application/json           1h;
    image/png                  1y;
    image/jpg                  1y;
    image/jpeg                 1y;
    image/gif                  1y;
    image/svg+xml             1y;
    image/x-icon              1y;
    font/woff                 1y;
    font/woff2                1y;
    font/ttf                  1y;
    font/otf                  1y;
    application/pdf           1M;
    video/mp4                 1M;
    video/webm                1M;
}

expires $expires;

# Add cache control headers
add_header Cache-Control "public" always;

# Conditional requests support
if_modified_since before;

3. File Type Optimization

Update your main nginx.conf to include:

http {
    # ... existing configuration ...

    # Optimize file serving
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    # Increase buffer sizes for better performance
    client_body_buffer_size 128k;
    client_max_body_size 50m;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 4k;

    # Output compression
    output_buffers 1 32k;
    postpone_output 1460;

    # Include our optimization configs
    include /etc/nginx/conf.d/gzip.conf;
    include /etc/nginx/conf.d/cache.conf;
}

Creating Professional Error Pages 🎨

Default error pages are boring and unprofessional. Let's create custom ones that match your brand.

Custom 404 Page

Create /var/www/errors/404.html:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Page Not Found - 404</title>
    <style>
        * {
            margin: 0;
            padding: 0;
            box-sizing: border-box;
        }

        body {
            font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
            background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
            min-height: 100vh;
            display: flex;
            align-items: center;
            justify-content: center;
            color: white;
        }

        .error-container {
            text-align: center;
            max-width: 600px;
            padding: 2rem;
            background: rgba(255, 255, 255, 0.1);
            border-radius: 20px;
            backdrop-filter: blur(10px);
            box-shadow: 0 8px 32px rgba(0, 0, 0, 0.1);
        }

        .error-code {
            font-size: 8rem;
            font-weight: bold;
            margin-bottom: 1rem;
            text-shadow: 2px 2px 4px rgba(0, 0, 0, 0.3);
        }

        .error-message {
            font-size: 1.5rem;
            margin-bottom: 2rem;
            opacity: 0.9;
        }

        .error-description {
            font-size: 1rem;
            margin-bottom: 2rem;
            opacity: 0.8;
            line-height: 1.6;
        }

        .home-button {
            display: inline-block;
            padding: 12px 30px;
            background: rgba(255, 255, 255, 0.2);
            color: white;
            text-decoration: none;
            border-radius: 25px;
            transition: all 0.3s ease;
            border: 2px solid rgba(255, 255, 255, 0.3);
        }

        .home-button:hover {
            background: rgba(255, 255, 255, 0.3);
            transform: translateY(-2px);
            box-shadow: 0 4px 15px rgba(0, 0, 0, 0.2);
        }

        .search-box {
            margin: 2rem 0;
        }

        .search-input {
            padding: 12px 20px;
            border: none;
            border-radius: 25px;
            width: 300px;
            max-width: 100%;
            background: rgba(255, 255, 255, 0.9);
            color: #333;
            font-size: 1rem;
        }

        .search-button {
            padding: 12px 20px;
            background: #ff6b6b;
            color: white;
            border: none;
            border-radius: 25px;
            margin-left: 10px;
            cursor: pointer;
            transition: background 0.3s ease;
        }

        .search-button:hover {
            background: #ff5252;
        }

        .helpful-links {
            margin-top: 2rem;
        }

        .helpful-links a {
            color: rgba(255, 255, 255, 0.8);
            text-decoration: none;
            margin: 0 15px;
            transition: color 0.3s ease;
        }

        .helpful-links a:hover {
            color: white;
            text-decoration: underline;
        }
    </style>
</head>
<body>
    <div class="error-container">
        <div class="error-code">404</div>
        <h1 class="error-message">Oops! Page Not Found</h1>
        <p class="error-description">
            The page you're looking for seems to have wandered off into the digital wilderness. 
            Don't worry though, even the best explorers sometimes take a wrong turn!
        </p>

        <div class="search-box">
            <input type="text" class="search-input" placeholder="Search for what you need..." id="searchInput">
            <button class="search-button" onclick="performSearch()">Search</button>
        </div>

        <a href="/" class="home-button">🏠 Take Me Home</a>

        <div class="helpful-links">
            <a href="/about">About</a>
            <a href="/contact">Contact</a>
            <a href="/blog">Blog</a>
            <a href="/sitemap.xml">Sitemap</a>
        </div>
    </div>

    <script>
        function performSearch() {
            const query = document.getElementById('searchInput').value;
            if (query.trim()) {
                window.location.href = `/search?q=${encodeURIComponent(query)}`;
            }
        }

        document.getElementById('searchInput').addEventListener('keypress', function(e) {
            if (e.key === 'Enter') {
                performSearch();
            }
        });
    </script>
</body>
</html>

Custom 50x Error Page

Create /var/www/errors/50x.html:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Server Error - We'll Be Right Back</title>
    <style>
        * {
            margin: 0;
            padding: 0;
            box-sizing: border-box;
        }

        body {
            font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
            background: linear-gradient(135deg, #ff7b7b 0%, #ff416c 100%);
            min-height: 100vh;
            display: flex;
            align-items: center;
            justify-content: center;
            color: white;
        }

        .error-container {
            text-align: center;
            max-width: 600px;
            padding: 2rem;
            background: rgba(255, 255, 255, 0.1);
            border-radius: 20px;
            backdrop-filter: blur(10px);
            box-shadow: 0 8px 32px rgba(0, 0, 0, 0.1);
        }

        .robot {
            font-size: 4rem;
            margin-bottom: 1rem;
            animation: shake 2s infinite;
        }

        @keyframes shake {
            0%, 100% { transform: rotate(0deg); }
            25% { transform: rotate(-5deg); }
            75% { transform: rotate(5deg); }
        }

        .error-message {
            font-size: 1.8rem;
            margin-bottom: 1rem;
            font-weight: 600;
        }

        .error-description {
            font-size: 1rem;
            margin-bottom: 2rem;
            opacity: 0.9;
            line-height: 1.6;
        }

        .status-info {
            background: rgba(255, 255, 255, 0.1);
            padding: 1rem;
            border-radius: 10px;
            margin: 1rem 0;
            font-family: monospace;
        }

        .retry-button {
            display: inline-block;
            padding: 12px 30px;
            background: rgba(255, 255, 255, 0.2);
            color: white;
            text-decoration: none;
            border-radius: 25px;
            transition: all 0.3s ease;
            border: 2px solid rgba(255, 255, 255, 0.3);
            margin: 0 10px;
        }

        .retry-button:hover {
            background: rgba(255, 255, 255, 0.3);
            transform: translateY(-2px);
        }
    </style>
</head>
<body>
    <div class="error-container">
        <div class="robot">🤖</div>
        <h1 class="error-message">Our Servers Are Taking a Coffee Break</h1>
        <p class="error-description">
            We're experiencing some technical difficulties. Our team of digital mechanics 
            is working hard to get everything running smoothly again.
        </p>

        <div class="status-info">
            Error Code: 500-503<br>
            Estimated Fix Time: A few minutes<br>
            Status: Engineers Deployed ☕
        </div>

        <a href="javascript:location.reload()" class="retry-button"> Try Again</a>
        <a href="/" class="retry-button">Go Home</a>
    </div>

    <script>
        // Auto-refresh every 30 seconds
        setTimeout(() => {
            location.reload();
        }, 30000);
    </script>
</body>
</html>

Update Your Sites to Use Custom Error Pages

Add this to each of your site configurations:

# Custom error pages
error_page 404 /errors/404.html;
error_page 500 502 503 504 /errors/50x.html;

location = /errors/404.html {
    root /var/www;
    internal;
}

location = /errors/50x.html {
    root /var/www;
    internal;
}

Smart Redirects and URL Rewriting 🔄

Common Redirect Scenarios

server {
    listen 80;
    server_name example.com www.example.com;

    # Redirect old blog structure to new one
    location ~ ^/blog/(\d{4})/(\d{2})/(.+)$ {
        return 301 /posts/$1-$2-$3;
    }

    # Redirect old file extensions
    location ~ ^(.+)\.php$ {
        return 301 $1;
    }

    # Redirect trailing slashes for files
    location ~ ^(.+)/$ {
        return 301 $1;
    }

    # Force HTTPS (when you have SSL)
    if ($scheme != "https") {
        return 301 https://$server_name$request_uri;
    }

    # Redirect www to non-www (or vice versa)
    if ($host = 'www.example.com') {
        return 301 $scheme://example.com$request_uri;
    }

    # Handle common typos in domain
    if ($host ~ ^(.*\.)?exampl\.com$) {
        return 301 $scheme://example.com$request_uri;
    }
}

Advanced URL Rewriting

# Pretty URLs for a PHP application
location / {
    # Try exact file, then directory, then rewrite
    try_files $uri $uri/ @rewrite;
}

location @rewrite {
    # Convert /category/subcategory/item to /index.php?cat=category&sub=subcategory&item=item
    rewrite ^/([^/]+)/([^/]+)/([^/]+)/?$ /index.php?cat=$1&sub=$2&item=$3 last;

    # Convert /category/item to /index.php?cat=category&item=item
    rewrite ^/([^/]+)/([^/]+)/?$ /index.php?cat=$1&item=$2 last;

    # Convert /item to /index.php?item=item
    rewrite ^/([^/]+)/?$ /index.php?item=$1 last;
}

# API versioning
location ~ ^/api/v(\d+)/(.*)$ {
    proxy_pass http://backend/api/$2;
    proxy_set_header X-API-Version $1;
    proxy_set_header Host $host;
}

Performance Monitoring and Optimization

Enable Status Monitoring

Add this to your main nginx.conf:

server {
    listen 8080;
    server_name localhost;

    location /nginx_status {
        stub_status on;
        access_log off;
        allow 127.0.0.1;
        allow 10.0.0.0/8;
        deny all;
    }

    location /health {
        access_log off;
        return 200 "healthy\n";
        add_header Content-Type text/plain;
    }
}

Performance Testing Commands

# Test your site performance
curl -H "Accept-Encoding: gzip" -H "Cache-Control: no-cache" -w "@curl-format.txt" -o /dev/null -s "http://localhost/"

# Create curl-format.txt for detailed timing
echo 'time_namelookup:  %{time_namelookup}s
time_connect:     %{time_connect}s
time_appconnect:  %{time_appconnect}s
time_pretransfer: %{time_pretransfer}s
time_redirect:    %{time_redirect}s
time_starttransfer: %{time_starttransfer}s
time_total:       %{time_total}s
http_code:        %{http_code}
size_download:    %{size_download}bytes
speed_download:   %{speed_download}bytes/sec' > curl-format.txt

# Check compression
curl -H "Accept-Encoding: gzip,deflate" -v http://localhost/style.css | head

# Monitor connections
watch -n 1 'ss -tuln | grep :80'

Real-World Performance Tips 🚀

1. Preload Critical Resources

Add to your HTML head:

<!-- Preload critical CSS -->
<link rel="preload" href="/css/critical.css" as="style">

<!-- Preload important fonts -->
<link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>

<!-- DNS prefetch for external domains -->
<link rel="dns-prefetch" href="//fonts.googleapis.com">
<link rel="dns-prefetch" href="//cdn.example.com">

2. Optimize Images

# WebP support with fallback
location ~* \.(png|jpg|jpeg)$ {
    # Try WebP version first
    try_files $uri.webp $uri =404;
    expires 1y;
    add_header Cache-Control "public, immutable";
}

# Serve different image sizes
location ~ ^/images/(.+)_(small|medium|large)\.(jpg|png)$ {
    alias /var/www/images/$1_$2.$3;
    expires 1y;
}

3. Security Headers for Production

# Security headers
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;" always;

# HSTS (when using HTTPS)
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Troubleshooting Common Issues 🔧

Problem: CSS/JS Not Loading

# Check file permissions
sudo chown -R www-data:www-data /var/www/
sudo chmod -R 755 /var/www/

# Check MIME types
grep "text/css" /etc/nginx/mime.types
grep "application/javascript" /etc/nginx/mime.types

Problem: Pages Not Updating

# Clear any caches
sudo rm -rf /var/cache/nginx/*

# Check if files are actually updated
ls -la /var/www/yoursite/

# Force reload without cache
curl -H "Cache-Control: no-cache" http://localhost/

Problem: Slow Performance

# Check access logs for slow requests
sudo tail -f /var/log/nginx/access.log | grep -E " [5-9][0-9]{3} "

# Monitor server resources
htop
iotop -o

What's Next? 🎯

Congratulations! You now have a professional, high-performance web server setup that can:

✅ Serve multiple websites efficiently
✅ Optimize content delivery with compression and caching
✅ Handle errors gracefully with custom pages
✅ Redirect and rewrite URLs intelligently
✅ Monitor performance and troubleshoot issues

In Part 3: Reverse Proxy Magic, we'll dive into:

Connecting your frontend to backend APIs
Handling WebSocket connections
Setting up development vs production environments
Load balancing basics
SSL termination and security

Practice Exercises 📝

Before moving to Part 3, try these:

Exercise 1: Multi-Site Setup

Create three different websites with different purposes and optimize each one differently.

Exercise 2: Performance Audit

Use tools like Google PageSpeed Insights or GTmetrix to test your sites and implement their suggestions.

Exercise 3: Custom Error Pages

Design error pages that match your brand and include helpful navigation.

Exercise 4: URL Restructuring

Implement a redirect strategy for an old site structure to a new one.

Quick Reference Commands 📋

# Test configuration
sudo nginx -t

# Reload configuration
sudo systemctl reload nginx

# Check active sites
ls -la /etc/nginx/sites-enabled/

# Monitor access logs
sudo tail -f /var/log/nginx/access.log

# Check server status
curl http://localhost:8080/nginx_status

# Performance test
ab -n 1000 -c 10 http://localhost/

You're building real expertise here! Each part of this series builds practical skills that you'll use every day as a developer. In Part 3, we'll connect all these optimized frontend sites to powerful backend services. Keep experimenting!

The Complete Nginx Mastery Series: From Zero to Production Hero

Adetayo Akinsanya — Thu, 07 Aug 2025 19:48:51 +0000

Image source: Unsplash - Swiss Army Knife representing Nginx's versatility

Welcome to the most comprehensive Nginx tutorial series you'll ever need. Whether you're a complete beginner or looking to level up your server management skills, this series will take you from "What is Nginx?" to deploying production-ready configurations.

What You'll Learn in This Series

By the end of this series, you'll be able to:

Set up Nginx from scratch on any system
Configure high-performance web servers
Build robust reverse proxy setups
Implement advanced load balancing strategies
Secure your applications with SSL/TLS
Create API gateways for microservices
Optimize performance for high-traffic applications
Monitor and troubleshoot like a pro

Who This Series Is For

Complete Beginners: Never touched a server configuration? No problem! We start from the absolute basics.

Frontend Developers: Want to understand how your apps get served? This series bridges that gap.

Backend Developers: Ready to deploy your APIs professionally? We've got you covered.

DevOps Engineers: Looking to master one of the most important tools in your toolkit? Let's dive deep.

System Administrators: Want to squeeze every bit of performance from your servers? We'll show you how.

Part 1: Nginx Fundamentals - Your First Steps

What Exactly Is Nginx?

Think of Nginx (pronounced "engine-x") as a super-efficient digital traffic controller. Just like a traffic controller at a busy intersection manages the flow of cars, Nginx manages the flow of web requests to ensure everything runs smoothly.

The Simple Analogy

Imagine you own a popular restaurant:

Without Nginx: Customers have to find their own seats, get their own water, and somehow figure out where the kitchen is. Chaos!
With Nginx: You have a professional host who greets customers, assigns tables efficiently, serves water quickly, and makes sure the kitchen gets orders in the right order. Much better!

That's essentially what Nginx does for your web applications.

Why Nginx? The Numbers Don't Lie

Used by 30%+ of all websites (including Netflix, Airbnb, WordPress.com)
Can handle 10,000+ concurrent connections on modest hardware
Uses minimal memory compared to alternatives
Extremely stable - some servers run for years without restart

What Makes Nginx Special?

1. It's a Swiss Army Knife 🔧

Nginx isn't just one tool - it's many:

graph LR
    A[Nginx] --> B[Web Server]
    A --> C[Reverse Proxy]
    A --> D[Load Balancer]
    A --> E[SSL Terminator]
    A --> F[Cache Server]
    A --> G[API Gateway]

2. Event-Driven Architecture

Traditional servers create a new process for each visitor (imagine hiring a new employee for each customer). Nginx uses an event-driven model (one efficient employee handling multiple customers). This is why it's so fast and memory-efficient.

3. Battle-Tested Reliability

Netflix uses Nginx to serve millions of hours of video. If it's good enough for Netflix, it's probably good enough for your project!

Installation: Getting Nginx on Your System

Ubuntu/Debian (Most Common)

# Update package list
sudo apt update

# Install Nginx
sudo apt install nginx

# Start Nginx
sudo systemctl start nginx

# Enable auto-start on boot
sudo systemctl enable nginx

# Check if it's running
sudo systemctl status nginx

CentOS/RHEL/Fedora

# Install Nginx
sudo dnf install nginx  # or 'yum install nginx' on older systems

# Start and enable
sudo systemctl start nginx
sudo systemctl enable nginx

macOS (for Development)

# Using Homebrew
brew install nginx

# Start Nginx
brew services start nginx

Docker (Platform Independent)

# Quick test
docker run -d -p 8080:80 nginx

# Visit http://localhost:8080 to see it working!

Your First Nginx Configuration

Let's start with something simple but powerful. We'll create a configuration that serves a basic website.

Understanding the Config Structure 🏗️

Nginx configuration follows a hierarchy:

Main Context (Global settings)
├── Events Context (Connection handling)
└── HTTP Context (Web-related settings)
    └── Server Context (Website-specific settings)
        └── Location Context (URL-specific settings)

The Basic Configuration File

Create or edit /etc/nginx/nginx.conf:

# Main context - global settings that affect everything
user nginx;
worker_processes auto;  # Use all available CPU cores
error_log /var/log/nginx/error.log;

# Events context - how Nginx handles connections
events {
    worker_connections 1024;  # Each worker can handle 1024 connections
}

# HTTP context - all web-related settings go here
http {
    # Basic settings
    include /etc/nginx/mime.types;  # Tells Nginx about file types
    default_type application/octet-stream;

    # Logging format
    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent"';

    access_log /var/log/nginx/access.log main;

    # Performance settings
    sendfile on;
    tcp_nopush on;
    keepalive_timeout 65;

    # Include server configurations
    include /etc/nginx/conf.d/*.conf;
}

Your First Website Configuration

Create /etc/nginx/conf.d/my-first-site.conf:

server {
    # Listen on port 80 (standard HTTP port)
    listen 80;

    # Your domain name (use 'localhost' for testing)
    server_name localhost;

    # Where your website files are stored
    root /var/www/html;

    # Default file to serve
    index index.html index.htm;

    # How to handle different URLs
    location / {
        # Try to serve the exact file, then try as a directory,
        # finally return 404 if nothing found
        try_files $uri $uri/ =404;
    }

    # Custom error pages (optional but nice)
    error_page 404 /404.html;
    error_page 500 502 503 504 /50x.html;

    location = /50x.html {
        root /usr/share/nginx/html;
    }
}

Creating Your Website Content

# Create the website directory
sudo mkdir -p /var/www/html

# Create a simple index.html
sudo tee /var/www/html/index.html > /dev/null <<EOF
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My First Nginx Site</title>
    <style>
        body { 
            font-family: Arial, sans-serif; 
            max-width: 800px; 
            margin: 50px auto; 
            padding: 20px; 
            background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
            color: white;
        }
        .container { 
            background: rgba(255,255,255,0.1); 
            padding: 30px; 
            border-radius: 10px; 
            text-align: center;
        }
    </style>
</head>
<body>
    <div class="container">
        <h1>🎉 Congratulations!</h1>
        <p>Your Nginx server is working perfectly!</p>
        <p>You're now ready to serve the world.</p>
        <small>Powered by Nginx</small>
    </div>
</body>
</html>
EOF

# Set proper permissions
sudo chown -R nginx:nginx /var/www/html
sudo chmod -R 755 /var/www/html

Testing Your Configuration

# Always test before applying changes!
sudo nginx -t

# If the test passes, reload Nginx
sudo systemctl reload nginx

# Check if everything is working
curl http://localhost

Visit http://localhost in your browser - you should see your beautiful new website!

Understanding What Just Happened

Let's break down what occurs when someone visits your website:

Browser Request: User types http://localhost in browser
DNS Resolution: Browser finds your server's IP address
Connection: Browser connects to port 80 on your server
Nginx Receives: Nginx accepts the connection
Configuration Match: Nginx matches the request to your server block
File Serving: Nginx finds and serves /var/www/html/index.html
Response: Browser receives and displays your webpage

Pro Tips for Beginners 💡

1. Always Test First

# This command is your best friend
sudo nginx -t

Never reload Nginx without testing first. A syntax error can take down your website!

2. Check the Logs

# Error logs (when something goes wrong)
sudo tail -f /var/log/nginx/error.log

# Access logs (who's visiting your site)
sudo tail -f /var/log/nginx/access.log

3. Reload vs Restart

# Reload: applies new config without dropping connections
sudo systemctl reload nginx

# Restart: stops and starts again (brief downtime)
sudo systemctl restart nginx

4. Keep Backups

# Before making changes, backup your config
sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup

Common Beginner Mistakes (And How to Avoid Them) ⚠️

Mistake 1: Forgetting Semicolons

# Wrong 
server_name example.com

# Right 
server_name example.com;

Mistake 2: Incorrect File Permissions

# Fix permission issues
sudo chown -R nginx:nginx /var/www/html
sudo chmod -R 755 /var/www/html

Mistake 3: Not Testing Configuration

# Always do this before reloading
sudo nginx -t

Mistake 4: Confusing Contexts

# Wrong  - server directive in http context
http {
    server_name example.com;  # This doesn't belong here!
}

# Right  - server directive in server context
http {
    server {
        server_name example.com;  # Perfect!
    }
}

Quick Troubleshooting Guide

Problem: "Permission Denied" Error

# Check SELinux (if on CentOS/RHEL)
sudo setsebool -P httpd_can_network_connect 1

# Check file permissions
sudo chown -R nginx:nginx /var/www/html
sudo chmod -R 755 /var/www/html

Problem: "Address Already in Use"

# Check what's using port 80
sudo netstat -tulpn | grep :80

# If Apache is running, stop it
sudo systemctl stop apache2  # or httpd

Problem: Changes Not Appearing

# Test configuration
sudo nginx -t

# Reload Nginx
sudo systemctl reload nginx

# Clear browser cache or try incognito mode

What's Next?

Congratulations! You've successfully:

Installed Nginx
Created your first configuration
Served your first website
Learned basic troubleshooting

In Part 2: Web Server Mastery, we'll dive into:

Serving multiple websites on one server
Handling different file types efficiently
Setting up caching for lightning-fast loading
Creating beautiful error pages
Implementing redirects and URL rewriting

Practice Exercises 📝

Before moving to Part 2, try these exercises:

Exercise 1: Multiple Pages

Create additional HTML pages and link them together:

About page (/var/www/html/about.html)
Contact page (/var/www/html/contact.html)

Exercise 2: Custom Error Page

Create a custom 404.html page with your own design.

Exercise 3: Different Server Name

Modify your configuration to respond to a different domain name (you can use your computer's IP address).

Exercise 4: Log Analysis

Visit your website a few times, then examine the access logs to see what Nginx recorded.

Resources and Further Reading

Ready for Part 2? We'll transform your basic website into a high-performance web server capable of handling multiple sites, optimized caching, and professional-grade configurations. See you there! 🎯

Questions or stuck somewhere? Drop a comment below! The Nginx community is incredibly helpful, and there's no such thing as a stupid question when you're learning.

Share this series with fellow developers who want to level up their server skills!

This is Part 1 of our comprehensive Nginx Mastery Series. Each part builds upon the previous, so make sure you're comfortable with these concepts before moving forward.

Setting Up PostgreSQL on macOS: A Fresh Start Guide

Adetayo Akinsanya — Mon, 02 Jun 2025 10:36:27 +0000

If you've ever faced the frustration of setting up a database from scratch, you're not alone. I remember the first time I installed PostgreSQL on my Mac, a mix of excitement and confusion. "Where do I even start? How do I create users? And how do I connect my app to it?"

If that sounds familiar, don't worry. In this guide, I'll walk you through how to start fresh with PostgreSQL on macOS using Homebrew, including how to launch the service, create a new database and user, and connect everything to your app — step by step, in a way that just makes sense.

Note: This guide focuses on macOS, but many of the PostgreSQL commands will work similarly on Linux. Windows users might want to look into PostgreSQL's official installer or WSL.

Why PostgreSQL?

PostgreSQL is a powerful, open-source relational database used by startups and giants alike. It's reliable, scalable, and has features that can grow with your project, making it a great choice whether you're just starting out or levelling up your skills. Plus, it's completely free and has excellent community support.

Step 1: Make Sure PostgreSQL Is Installed

Since you're on macOS, Homebrew is your friend for installing and managing software like PostgreSQL. If you don't have Homebrew installed yet, head to brew.sh and follow the installation instructions.

Open your Terminal and check if PostgreSQL is installed and what version you have:

psql --version

If it shows something like psql (PostgreSQL) 17.x, you're good to go!

If it says "command not found," you need to install PostgreSQL:

brew install postgresql@17

After installation, you might need to add PostgreSQL to your PATH. Homebrew will usually show you the command to run, but it typically looks like this:

echo 'export PATH="/opt/homebrew/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

Step 2: Start the PostgreSQL Service

Now that PostgreSQL is installed, it needs to be running so your app can talk to it. Think of this like starting your car before you can drive somewhere.

Use Homebrew to start PostgreSQL:

brew services start postgresql@17

This command tells macOS to launch PostgreSQL in the background and keep it running, even after you restart your computer.

To check that it's running:

brew services list | grep postgresql

You should see something like postgresql@17 started.

If you ever need to manage the service later, these commands will help:

# Restart PostgreSQL
brew services restart postgresql@17

# Stop PostgreSQL 
brew services stop postgresql@17

# Check status
brew services info postgresql@17

Step 3: Access PostgreSQL for the First Time

PostgreSQL creates a default superuser that matches your macOS username when it's first installed. Let's connect to the default postgres database:

psql postgres

If successful, you'll see a prompt like this:

postgres=#

Congrats — you're inside the PostgreSQL command line interface! The # symbol indicates you're connected as a superuser.

Troubleshooting: If you get a connection error, make sure PostgreSQL is running (Step 2) and try specifying your username explicitly:

psql -U $(whoami) postgres

Step 4: Create a New User and Database

For your projects, it's a security best practice to create a dedicated user and database rather than using the default superuser for everything. This limits potential damage if something goes wrong.

At the postgres=# prompt, run the following commands. Feel free to replace myapp_user and myapp_db with your own names, and choose a secure password:

-- Create a new user with a password
CREATE USER myapp_user WITH PASSWORD 'your_secure_password_here';

-- Create a new database owned by this user
CREATE DATABASE myapp_db OWNER myapp_user;

-- Grant all privileges on the database to the new user
GRANT ALL PRIVILEGES ON DATABASE myapp_db TO myapp_user;

-- Grant the user permission to create databases (useful for testing)
ALTER USER myapp_user CREATEDB;

Security tip: Use a strong password with a mix of letters, numbers, and symbols. You can generate one using:

openssl rand -base64 32

Once done, exit the PostgreSQL prompt:

\q

Step 5: Test Your New User Connection

Let's make sure everything works by connecting to your new database as your new user:

psql -U myapp_user -d myapp_db -h localhost

You'll be prompted for the password you set. If you see a prompt like myapp_db=>, you're successfully connected! The > symbol (instead of #) shows you're connected as a regular user, not a superuser.

Try a simple command to make sure everything works:

SELECT version();

This should show your PostgreSQL version information.

Exit when you're done:

\q

Step 6: Set Up Your Application Configuration

Your app needs connection details to talk to PostgreSQL. The exact setup depends on your framework, but here are the most common patterns:

Environment Variables (.env file)

Create or update your .env file:

# Database Configuration
DB_HOST=localhost
DB_PORT=5432
DB_USER=myapp_user
DB_PASSWORD=your_secure_password_here
DB_NAME=myapp_db

# Optional: Full connection string format
DATABASE_URL=postgresql://myapp_user:your_secure_password_here@localhost:5432/myapp_db

TypeORM Configuration

If you're using TypeORM with Node.js, your datasource.ts might look like this:

import { DataSource } from "typeorm";
import { config } from "dotenv";

config(); // Load environment variables

export const AppDataSource = new DataSource({
  type: "postgres",
  host: process.env.DB_HOST || "localhost",
  port: parseInt(process.env.DB_PORT || "5432"),
  username: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  database: process.env.DB_NAME,
  synchronize: process.env.NODE_ENV === "development", // Only in development!
  logging: process.env.NODE_ENV === "development",
  entities: ["src/entities/**/*.ts"],
  migrations: ["src/migrations/**/*.ts"],
});

Django Configuration

For Django users, update your settings.py:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': os.environ.get('DB_NAME'),
        'USER': os.environ.get('DB_USER'),
        'PASSWORD': os.environ.get('DB_PASSWORD'),
        'HOST': os.environ.get('DB_HOST', 'localhost'),
        'PORT': os.environ.get('DB_PORT', '5432'),
    }
}

Step 7: Essential PostgreSQL Commands to Remember

Now that you're set up, here are some handy commands you'll use regularly:

# Connect to your database
psql -U myapp_user -d myapp_db -h localhost

# Connect using a connection string
psql "postgresql://myapp_user:password@localhost:5432/myapp_db"

Once connected, these SQL commands are useful:

-- List all databases
\l

-- List all tables in current database
\dt

-- Describe a table structure
\d table_name

-- List all users
\du

-- Switch to a different database
\c database_name

-- Show current connection info
\conninfo

-- Get help
\h

-- Quit
\q

Troubleshooting Common Issues

"psql: command not found": PostgreSQL isn't in your PATH. Try the PATH export command from Step 1.

"connection refused": PostgreSQL service isn't running. Check with brew services list | grep postgresql.

"password authentication failed": Double-check your username and password. Remember, PostgreSQL is case-sensitive.

"database does not exist": Make sure you created the database in Step 4, or check the database name for typos.

Next Steps

With PostgreSQL running, you're ready to start building! Consider learning about:

Database migrations: How to version-control your database schema changes
Connection pooling: For better performance in production apps
Backup strategies: Using pg_dump to backup your data
Performance monitoring: Understanding EXPLAIN and query optimization
Extensions: PostgreSQL has powerful extensions like PostGIS for geographic data

Wrapping Up

Starting fresh with PostgreSQL might feel daunting at first, but once you've set up your database and user correctly, you unlock a reliable backend foundation for any app you build.

You've learned how to:

Verify and install PostgreSQL 17 with Homebrew
Start and manage the PostgreSQL service
Create a new database user and database with proper permissions
Connect to your database as that user
Configure your app to connect to PostgreSQL
Use essential PostgreSQL commands for da

The best part? This setup will serve you well whether you're building a simple prototype or preparing for production. PostgreSQL scales with your ambitions.

Happy coding, and welcome to the world of robust database management!

How I Fixed the Mystery of Corrupted File Downloads from AWS S3

Adetayo Akinsanya — Mon, 02 Jun 2025 10:07:29 +0000

How I Fixed the Mystery of Corrupted File Downloads from AWS S3

When your users report "corrupted files" but everything looks fine on your end

Last month, I ran into one of those bugs that makes you question everything you think you know about web development. Users were complaining that downloaded files from our document management system were "corrupted" and wouldn't open. The twist? The files were perfectly fine in our AWS S3 bucket.

The Problem That Started It All

Picture this: You're building an application where users upload important kyc documents—driver's licenses, bank statements, tax documents. Everything seems to work perfectly during testing. Files upload fine, they're stored securely in S3, and when you download them through your admin panel, they open without issues.

Then the support tickets start rolling in:

"I can't open the driver's license I just downloaded"

"The bank statement file seems corrupted"

"Why is my tax document showing as a 'Blob' file?"

My first instinct was to blame the users (classic developer move, I know). Maybe they're using old browsers? Maybe their antivirus is interfering? But when I started investigating, I realized the problem was much closer to home.

The Investigation

I pulled up our file download function—a simple, straightforward piece of code that I'd written dozens of times before:

export async function downloadBlobFile(
  blobUrl: string,
  fileName: string
): Promise<void> {
  try {
    const response = await fetch(blobUrl);
    const blob = await response.blob();
    const url = window.URL.createObjectURL(blob);

    const a = document.createElement('a');
    a.href = url;
    a.download = fileName;
    document.body.appendChild(a);
    a.click();
    // cleanup...
  } catch (err) {
    // error handling...
  }
}

Looks innocent enough, right? The issue became clear when I started examining what was actually happening:

Our S3 objects had no file extensions - Files were stored as doc-12381-0530103115-bank-statement instead of bank-statement.pdf
S3 wasn't setting Content-Type headers - Everything was coming back as application/octet-stream or no content type at all
Files were being saved as .bin files - Because the browser had no idea what they actually were

The "corruption" wasn't corruption at all—it was a case of mistaken identity. A PDF being saved as a .bin file naturally won't open in a PDF viewer.

My First (Failed) Approach

My initial thought was simple: "I'll just add the file extension to the filename when saving!"

But how do you know if a file should be .pdf, .jpg, or .docx when the server isn't telling you?

I tried extracting it from the URL, but our presigned URLs looked like this:

https://uploads.s3.amazonaws.com/bank-statement-12381-0530103115?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=...

No extension in sight.

I considered asking users to specify the file type when uploading, but that felt like admitting defeat. There had to be a better way.

The Eureka Moment

Then I remembered something from blogs and few articles I've seen before now: file signatures (or "magic numbers"). Every file type has a unique byte sequence at the beginning that identifies what it is, regardless of its name or extension.

PDFs start with %PDF (hex: 25 50 44 46)
JPEGs start with FF D8 FF
PNGs start with 89 50 4E 47

I could read the first few bytes of each downloaded file, identify its actual type, and assign the correct extension!

Building the Solution

Here's the approach I took:

Download the file as a blob (necessary for CORS anyway)
Check if the server provided a useful Content-Type
If not, read the first 20 bytes and analyze the file signature
Map the signature to the correct MIME type and extension
Download with the proper filename

The implementation handles the most common file types we encounter:

async function detectFileType(
  blob: Blob
): Promise<{ mimeType: string; extension: string } | null> {
  const arrayBuffer = await blob.slice(0, 20).arrayBuffer();
  const bytes = new Uint8Array(arrayBuffer);

  // PDF signature
  if (
    bytes[0] === 0x25 &&
    bytes[1] === 0x50 &&
    bytes[2] === 0x44 &&
    bytes[3] === 0x46
  ) {
    return { mimeType: 'application/pdf', extension: '.pdf' };
  }

  // JPEG signature
  if (bytes[0] === 0xff && bytes[1] === 0xd8 && bytes[2] === 0xff) {
    return { mimeType: 'image/jpeg', extension: '.jpg' };
  }

  // ... more file types
}

The Results

The transformation was immediate and dramatic:

Zero corruption complaints since deploying the fix
User satisfaction improved - files now open in the correct applications automatically
Support tickets dropped by about 60% for file-related issues
Developer confidence restored - no more mysterious "it works on my machine" scenarios

Users went from downloading bank-statement.blob files that wouldn't open, to getting bank-statement.pdf files that opened immediately in their PDF viewers.

Current Limitations (And Future Plans)

While this solution works great for our use case, it's not perfect:

What it handles well:

Common image formats (JPEG, PNG, GIF, WebP)
PDF documents
Basic Office documents (as ZIP files)
Text-based formats (JSON, XML, HTML)

What it doesn't handle yet:

Audio/video files (MP3, MP4, etc.)
More exotic document formats
Encrypted or password-protected files
Very large files (though it only reads the first 20 bytes, so this shouldn't be an issue)

Performance considerations:

Adds a small overhead to read file signatures
Uses more memory than direct downloads
Still requires the blob method for CORS compatibility

Lessons Learned

This experience taught me a few valuable lessons:

User complaints about "corruption" aren't always about actual file corruption - sometimes it's about incorrect file associations
Cloud storage services don't always preserve file metadata - you can't assume Content-Type headers will be present or accurate
File extensions matter more than we think - they're not just cosmetic; they determine how operating systems handle files
Sometimes the old-school approaches (like file signatures) are still the best solutions to modern problems

Want to Use This Solution?

I've open-sourced this file download utility because I suspect other developers are running into similar issues. The complete implementation handles edge cases, includes extensive logging for debugging, and supports the most common file types you'll encounter in web applications.

You can find it in this GitHub Gist with full documentation and usage examples.

Have you run into similar file download mysteries in your applications? I'd love to hear about your experiences and solutions in the comments below.

Building reliable file handling in web applications is trickier than it looks. Sometimes the solution isn't more sophisticated cloud configuration—it's going back to the fundamentals of how computers identify files.

Understanding Linux File and Folder Permissions

Adetayo Akinsanya — Thu, 26 Oct 2023 17:03:35 +0000

Prerequisites:

Before diving into the world of Linux file and folder permissions, you'll need basic knowledge of using the command line interface (CLI) and access to a Linux system. If you're new to these concepts, a brief introduction to CLI and basic Linux commands will be helpful.

Introduction

Linux file and folder permissions can be daunting, but they are crucial for securing your data and system. You've probably seen permission strings like drwxr-xr-x and wondered what they mean. In this article, we'll demystify these permissions, explain how they work, and how you can generate them.

Understanding the Permission String

The Linux file and folder permission string drwxr-xr-x is a way of representing the file permissions of a directory or file in a concise and easy-to-read format. It is made up of a series of characters, each of which represents a different permission. The characters are grouped into three sets of three, each of which represents the permissions for a different group of users:

The first set of three characters represents the permissions for the owner of the file or directory.
The second set of three characters represents the permissions for the group of users that the file or directory belongs to.
The third set of three characters represents the permissions for all other users.

The specific permissions that are granted or denied are represented by the following characters:

r - Read permission
w - Write permission
x - Execute permission

When any of the character is represented by an hyphen (-) this indicates that the permission is denied.

How to generate the Linux file and folder permission string

The file or directory permissions can be generated using the ls -l command.

For example, if you run the following command:

ls -l /home/user

The output might be something like this:

drwxr-xr-x 2 user user 4096 Oct 26 16:56 /home/user

Understanding the Permission String

Let's break down the permission string drwxr-xr-x into its individual components and give meaning to them:

d: This stands for "directory." It indicates that the object (file or folder) is, in fact, a directory. If it were a regular file, you would see a "-" here instead.
rwx: The next three characters (r, w, and x) represent the permissions for the owner of the file or directory.
r (Read): The owner can view the contents of the file or list the directory.
w (Write): The owner can modify the file or add/remove files within the directory.
x (Execute): The owner can enter the directory (for folders) or run the file (for executable files).
r-x: The next three characters represent the permissions for the group.
r (Read): Members of the group can view the contents of the file or list the directory.
- (Write): Members of the group cannot modify the file or add/remove files within the directory.
x (Execute): Members of the group can enter the directory or run the file.
r-x: The last three characters are the permissions for others (everyone else who is not the owner or in the group). The same rules apply:

r (Read): Others can view the contents of the file or list the directory.
- (Write): Others cannot modify the file or add/remove files within the directory.
x (Execute): Others can enter the directory or run the file.

Setting Permissions for file or folder

You can set permissions using the chmod command in Linux. Here's how to generate a permission string:

Owner Permissions: Use chmod followed by the owner's permission characters. For example, to give the owner read, write, and execute permissions, use:

chmod u=rwx file_or_directory

Group Permissions: To set group permissions, use:

chmod g=rx file_or_directory

Others Permissions: To set permissions for others, use:

chmod o=x file_or_directory

Usage

Let's say you want to set the permission string drwxr-xr-x for a directory called "my_folder." You would use the following commands:

chmod u=rwx my_folder
chmod g=rx my_folder
chmod o=rx my_folder

After executing these commands, you'll have the desired permission string.

Whether you're new to Linux or an experienced user, there's always something new to explore. If you've gained new insights, I'm delighted, and if you're an experienced Linux user, thank you for reading this far.

Stay tuned for more fun and engaging content on Linux and other tech topics! Happy learning.

How to stop individual and all Docker processes

Adetayo Akinsanya — Mon, 23 Oct 2023 20:17:28 +0000

Why This Article

This blog post was born out of the need to share a code snippet that I use almost every day at work. I stop and start Docker processes frequently, and I wanted to create a resource that would help others do the same.

I hope you find this blog post helpful!

Introduction

Docker is a popular containerization platform that allows you to run applications in isolated environments. This can be useful for improving performance, security, and portability. However, it can also be confusing to manage multiple Docker processes.

This blog post will explain how to stop individual and all Docker processes using the Docker CLI.

Stopping an individual Docker process

To stop an individual Docker process, you can use the docker stop command. This command takes the container ID or name as an argument. For example, to stop the container with the ID a0c59618bf9e, you would run the following command:

docker stop a0c59618bf9e

You can also stop multiple Docker processes at once by passing multiple container IDs or names to the docker stop command. For example, to stop the containers with the IDs a0c59618bf9e and b1d2f3g4h5i6, you would run the following command:

docker stop a0c59618bf9e b1d2f3g4h5i6

Stopping all Docker processes
To stop all Docker processes, you can use the docker stop $(docker ps -a -q) command. This command will pipe the output of the docker ps -a -q command, which lists all container IDs, to the docker stop command.

For example, to stop all Docker processes, you would run the following command:

docker stop $(docker ps -a -q)

Note: This command will stop all Docker processes, including those that are running in detached mode.

Explanation of the commands
The following is a brief explanation of the commands used in this blog post:

docker stop: This command stops a Docker container.

docker ps: This command lists Docker containers.
-a: This option tells the docker ps command to list all containers, even those that are stopped.
-q: This option tells the docker ps command to only list the container IDs.
$(command)`: This is a shell syntax that allows you to execute the output of a command.

Conclusion

Stopping Docker processes is a simple task, but it is important to understand the different commands that you can use. This blog post has explained how to stop individual and all Docker processes using the Docker CLI.

Learning JavaScript the Easy Way: Unlocking the Power of Scope with Closures

Adetayo Akinsanya — Wed, 06 Sep 2023 20:57:52 +0000

JavaScript's concept of closure is often misunderstood and confused with lexical scope. To truly grasp the concept of closures, it's essential to have a good understanding of scopes.

What is a Closure?

A closure is a fundamental JavaScript concept where a function retains access to its parent scope, even after the parent function has finished executing. Closures are defined when a function is declared, not when it is executed.

Imagine a child function nested within a parent function. A closure defines the boundaries within which the child function operates. This means the child function can access not only its own variables but also those defined in its parent function and even global scope variables, if any.

Now what does it mean to have access to the scope of its parent even after its parent function has called. Let look at simple example

let x = 1;

function parentFunction() {
  let count = 2;

  console.log(x);
  console.log(count);

  function childFunction() {
    console.log(x += 1);
    console.log(count += 2);
  }

  return childFunction;
}

const result = parentFunction()

In this example, if we check the console, we'll see 1 and 2 printed, respectively, but we won't see any result from the child function. This is because the child function has not been executed yet; we've only executed the parent function. However, we've also returned the child function, which can now be invoked using result.

To demonstrate this, let's log the result to the console, revealing that it's an anonymous function, which is essentially the child function:

console.log(result);

Now, when we invoke the child function using result(), observe the output:

result()
result()

As we can the child function still it access to count variable even though the parent function has already been called and returned and also the x which is a global variable.

As you can see, the child function still has access to the count variable, even though the parent function has already been executed and returned. It also has access to the global variable x. However, trying to access count from the global scope would result in a reference error since it's not accessible at that level.

An Analogy

To simplify our understanding of closures, let's adopt Feyman's Technique:

Imagine you have a cookie jar at home with delicious cookies that you love. However, you don't want anyone in your family to eat them when you're not looking. To keep your cookies safe, you place them inside a special box with a lock. This box is analogous to a closure in JavaScript, safeguarding your cookies from others.

When you want to enjoy a cookie, you take out the key, unlock the box, and retrieve your cookie. You can enjoy as many cookies as you like. Once you're done, you put the remaining cookies back inside the box, lock it again, and hide the key.

This way, your cookies remain safe and private, and you can savor them whenever you want without worrying about someone else taking them.

In JavaScript, a closure is like that special box. It protects specific data or variables, keeping them hidden from the rest of the code. When you need to use these variables, you can open the closure, perform your tasks, and then close it to maintain security. Closures empower programmers to manage and safeguard their data, just like your cookie box protects your cookies from family members!

Conclusion

In conclusion, closures in JavaScript are a powerful concept that allows functions to retain access to their parent scope, even after the parent function has completed its execution. They are not only a fundamental aspect of JavaScript but also a tool that can be harnessed to create private variables and manage data effectively.

As we journey through the fascinating world of JavaScript, I urge you to stay curious and explore more intriguing concepts.
So, stay tuned, and let's learn JavaScript the easy way together!

Learning JavaScript the easy way: Scopes and Hoisting

Adetayo Akinsanya — Sat, 26 Aug 2023 15:31:09 +0000

Scopes and hoisting are fundamental concepts in JavaScript that play a crucial role in how variables are accessed and executed within your code. Understanding these concepts is essential for writing efficient and error-free JavaScript programs.
This guide will cover scopes and hoisting, starting from the beginner level and progressing to more advanced concepts.

Scopes

Scope in JavaScript refers to the context in which variables are declared and accessed.
This simply means that a scope in JavaScript defines the accessibility and visibility of variables.

There are two main types of scopes: global scope and local scope.

Global Scope:

Variables declared outside of any function are in the global scope and can be accessed from anywhere in the code. The variables are declared using const and let and are accessible globally, just like with var.

const globalVariable = 30;

function printGlobal() {
    console.log(globalVariable);
}

printGlobal(); // prints: 30

Local Scope:

Variables declared inside a function are in the local scope and can only be accessed within that function. It defines how variable names are resolved in nested functions.

function printLocal() {
    var localVar = 20;
    console.log(localVar); 
}

printLocal(); // prints: 20
console.log(localVar); // Throws an error - localVar is not defined

Other forms of scopes

Block Scopes with let and const:

Introduced in ES6, let and const allow you to declare variables with block scope.

if (true) {
    let blockVar = 40;
    const blockConst = 50;
}
// console.log(blockVar); // Error: blockVar is not defined
// console.log(blockConst); // Error: blockConst is not defined

Function Scopes and Closures:

Functions create their own scope, and inner functions can access variables from their containing (outer) function's scope. This behavior is known as a closure. We will take a deeper dive into closures in upcoming chapters

function outer() {
    var outerVar = 60;
    function inner() {
        console.log(outerVar);
    }
    return inner;
}

var closure = outer();
closure(); // Outputs: 60

Lexical Scoping:

Lexical scoping means that a function's scope is determined by its location during author-time, and not runtime.

IIFE (Immediately Invoked Function Expression):

An IIFE is a function that is immediately executed after being defined. It helps create a private scope for your code.

(function() {
    var privateVar = "I'm private!";
    console.log(privateVar);
})();
console.log(privateVar); // Error: privateVar is not defined

Temporal Dead Zone (TDZ):

The TDZ is the phase in which variables are declared but not yet initialized. Accessing variables in this state results in a ReferenceError.

console.log(tempVar); // Error: Cannot access 'tempVar' before initialization

let tempVar = 80;

What is Hoisting?

Hoisting is a JavaScript behavior where variable and function declarations are moved to the top of their containing scope during compilation.

Variable Hoisting:

Variable declarations are hoisted, but not their assignments.

console.log(hoistedVar); // Outputs: undefined
var hoistedVar = 30;
console.log(hoistedVar); // Outputs: 30

Function Hoisting:

Function declarations are also hoisted, allowing you to call functions before they are defined.

hoistedFunction(); // Outputs: "Hello, hoisting!"
function hoistedFunction() {
    console.log("Hello, hoisting!");
}

Conclusion:

Scopes and hoisting are integral to JavaScript's behavior. Mastering these concepts empowers you to write clean, efficient, and bug-free code. Remember that understanding these concepts deeply will not only help you avoid pitfalls but also enable you to make the most of JavaScript's capabilities.

Anticipate our upcoming article where we'll explore another exciting topic in JavaScript, thereby taking your JavaScript skills to the next level.

Stay curious and keep coding!

Stay tuned for our next article!

Learning JavaScript the easy way: Variables

Adetayo Akinsanya — Thu, 17 Aug 2023 07:07:18 +0000

Reviving JavaScript Learning: Let's Dive into Variables!

Hey there ✋, wonderful readers! It's been a little while, but guess what? I'm back and more excited than ever to embark on a journey of creating some fantastic beginner-friendly content. If you're new here, welcome aboard; if you've been with us before, it's great to have you back! Get ready to roll up your sleeves and dig into the world of JavaScript variables in this refreshing new part.

JavaScript Variables: Your Gateway to Coding Awesomeness

In our ongoing series, "Learning JavaScript the Easy Way," we're all about simplifying the complexities of coding. Today, we're going to tackle a fundamental concept that's like the building block of your coding adventures: JavaScript variables.

What Are Variables and Why Should You Care?

In the programming world, variables act as the ultimate containers for your data. Whether it's a person's name, an age, or even the result of a mind-bending calculation, variables give meaning to your data. Imagine a labeled box that holds your precious information, and you're pretty much there!

And the best part? JavaScript variables are super flexible. They can hold various types of data, from numbers to text and everything in between. This flexibility is what we mean by JavaScript being "loosely typed." It's like a wild card that lets you adapt to different situations effortlessly.

Declaring Variables

Alright, let's get hands-on! To start using variables, you need to declare them. Think of it as marking your territory in the coding playground. In JavaScript, we've got a few friends to help us out: var, let, and const.

Unveiling the Power with `var` and `let`

To declare a variable, you'll use var or let, followed by the variable's name:

To declare a variable in JavaScript, we use keywords such as var, let, or const. These keywords signal how the variable can be used and the scope it's associated with.

var message; // Declaration without initialization

let count;   // Another variable declaration

You can even declare and initialize multiple variables in a single line:

JS let firstName = "Alice", lastName = "Johnson";

Using the `var` and `let` Keywords

For variable declaration, you use the var or let keyword followed by the variable name:

var message; // Declaration without initialization  let count;   // Another variable declaration

If you declare a variable without assigning a value, like in the examples above, the variable is said to be declared but not initialized. It holds the value undefined.

To initialize a variable during declaration, you can do:

var username = "John"; // Declare and initialize  
let age = 30;          // Another example

You can declare and initialize multiple variables in a single statement:

let firstName = "Alice", lastName = "Johnson";

Undefined and Undeclared Variables

Ever met someone you've heard about but never talked to? That's an undefined variable. It's been introduced (declared), but it hasn't spilled the beans about itself (assigned a value). So, it's kind of like an unfinished story – you know there's something there, but you don't know what.

On the flip side, an undeclared variable is like trying to find Bigfoot – it just doesn't exist. If you use an undeclared variable, JavaScript gets all puzzled and throws a ReferenceError at you.

let greeting;          // Undefined variable console.log(greeting); // Outputs: undefined  console.log(response); // Throws: ReferenceError: response is not defined

Ready to Dive Deeper? Scopes Await!

In JavaScript, the fun doesn't stop at variables – it's all about where they live and who they hang out with. That's where scopes come into play. We've got global, function, and even block scopes to keep things interesting. Don't worry, we'll explore these captivating territories in our upcoming chapters.

Let's Create Something Awesome Together

So, there you have it, the spark to reignite your coding journey! As we embark on this thrilling adventure together, remember that variables are your trusty companions on the road to coding awesomeness. Buckle up, because we're just getting started. Stay tuned for more beginner-friendly insights, tips, and tricks – the coding world is at your fingertips, and I'm here to guide you every step of the way! and at the same time learn with you.

How to Rename Git Branches Locally and Remotely

Adetayo Akinsanya — Wed, 01 Jun 2022 22:37:39 +0000

In software development, version control is crucial for managing and collaborating on code. Git, a distributed version control system, is widely used for tracking changes in code repositories. Occasionally, you might need to rename a Git branch for various reasons such as improving clarity or consistency. This guide will walk you through the process of renaming Git branches both locally and remotely, using a real-world scenario to illustrate the steps.

Scenario

Imagine you are working on a project called "WidgetApp." You have a branch named feature/new-feature that you want to rename to feature/awesome-feature to better reflect the actual functionality you're implementing.

This short guide will walk you through the process of renaming the branches

Solution

1. Renaming Locally

Step 1: Checkout the Branch

Before renaming the branch, make sure you are on the branch that you want to rename. Open your terminal and navigate to your project directory:

cd /path/to/WidgetApp

Then, check out the branch you want to rename:

git checkout feature/new-feature

Step 2: Rename the Branch

To rename the branch locally, use the following command:

git branch -m feature/awesome-feature

This renames the current branch (feature/new-feature) to feature/awesome-feature.

Step 3: Push the Renamed Branch

After renaming the branch locally, you need to push the changes to the remote repository:

git push origin feature/awesome-feature

2. Renaming Remotely

Step 4: Delete the Old Remote Branch

Before pushing the renamed branch, delete the old remote branch using:

git push origin --delete feature/new-feature

Step 5: Push the Renamed Branch

Now, push the renamed branch to the remote repository:

git push origin feature/awesome-feature

3. Update Local Tracking

Step 6: Update Local Tracking

Your local repository still might be tracking the old remote branch name. To update it, use:

git fetch --prune

Summary of Commands

Here's a summary of the commands used in this scenario:

# Step 1
cd /path/to/WidgetApp
git checkout feature/new-feature

# Step 2
git branch -m feature/awesome-feature

# Step 3
git push origin feature/awesome-feature

# Step 4
git push origin --delete feature/new-feature

# Step 5
git push origin feature/awesome-feature

# Step 6
git fetch --prune

Renaming Git branches both locally and remotely can be essential for maintaining a clean and organized repository. By following the steps outlined in this guide, you should be able to confidently rename your branches while ensuring that your changes are properly reflected in both your local and remote repositories. Always be cautious when performing these actions to avoid unintended data loss or conflicts.

Learning JavaScript the easy way: JavaScript Grammar

Adetayo Akinsanya — Wed, 10 Mar 2021 13:56:26 +0000

Hi, welcome to my first post on dev.to.

This post will be the first part of the "Learning JavaScript the easy way" series.

The decision to start this series came out of the desire to teach JavaScript concepts in the most understandable way to people who may be struggling with it and also get a deeper understanding of it.

This tutorial is best suited for beginners as it promises a smooth ride and a better understanding of JavaScript concepts from the ground up.

In this part, you will learn about JavaScript grammar, some of which include case-sensitivity, identifiers, comments, statements, and expressions.

Let's dive in 🚀🚀

Javascript Grammar

Every language has its diction, be it a programming language or the native languages we use to communicate with ourselves and Javascript isn't an exception.

Case Sensitivity

JavaScript is a case-sensitive language. This implies that the keywords, variable, function, and many other identifiers must always have consistent capitalization. Therefore, a variable name like user is significantly different from User.

Identifiers

An Identifier can simply be referred to as a name.
In JavaScript, identifiers are used to name variables, functions, parameters, or classes. But these identifiers have certain rules that must be conformed to:

A JavaScript identifier must start with a letter, underscore (_), or a dollar sign ($). Subsequent characters can also be digits (0–9), digits, underscores, or dollar signs.

The letters being referred to in this context are not limited to ASCII characters also but may extend to Unicode characters also.

It has become a convention among Javascript developers to use camel case for identifiers, this means that the first letter is lowercase, and each additional word starts with a capital letter. Although it is not mandatory as there are other conventions like kebab case, snake case that can also be used, they just have to abide by the identifier rule

The following are identifier names declared in camelcase

greetingsFromNigeria
containsNumber
isString
routeHere

Comments

They are added with the purpose of making the source code easier for humans to understand, and are generally ignored by compilers and interpreters.

Comments are unexecuted statements in Javascript (more on statements later).

A line of code that comes after double slashes // or block of codes that comes between /* and */ are treated as a comment in JavaScript.
For example

let foo = 6; //  I will be executed
// let bar = 7;  I am not executed

/*
This code won't run.
Because it is a comment
*/

Statements

A statement is a piece of code that can be executed and performs some kind of action.

Although JavaScript doesn't require a statement to end with a semicolon(;), it is recommended to be used when ending a statement.

Personally, I think it makes code readable.
You can use a code block that begins with a left curly brace ({) and ends with the right curly brace (}) to combine multiple statements as follows:

For example,

let today;
if (true){
today = 'Monday';
} else {
today = 'Tuesday';
}

Expressions

An expression is a piece of code that can be evaluated to produce a value.
For example, the following illustrates an expression that involves a and b:

a + b

Reserved Keywords

There are some keywords that are reserved in JavaScript these keywords cant be used to name variables some of which includes

await,break,case,catch,default,const,continue,debugger,delete,enum,else,export,do,extends,false,finally,for,function,void,static.

There are many other reserved words and keywords in JavaScript that aren't mentioned here, but the good thing is you don't have to memorize them all. However, if you wish to check out other reserved words you can find them here.

In the next part, we will be discussing Variable, its declaration, hosting amongst many basic concepts.

As this is my first post, I would like the opinions of experts on how to make this better

Thank you for your time.