DEV Community: Harry Douglas

Cloud Storage Basics: Block, File, and Object Storage

Harry Douglas — Wed, 19 Aug 2026 09:23:57 +0000

When working with cloud platforms such as AWS, Azure, or Google Cloud, you'll encounter several different types of storage. The three fundamental categories are:

Block storage
File storage
Object storage

Understanding the difference between them is important when working with VMs, databases, Kubernetes, backups, and cloud architectures.

1. Block Storage

Block storage is the closest equivalent to a physical hard disk or SSD.

The cloud provider gives your VM a virtual disk, and the operating system sees it as a block device.

Cloud
  │
  └── 50 GB Block Disk
          │
          ↓
        VM
          │
       /dev/sdb
          │
       filesystem
          │
        /data

For example, in Linux:

lsblk

might show:

NAME   SIZE
sda     64G
sdb     50G

You can create a filesystem:

sudo mkfs.ext4 /dev/sdb

and mount it:

sudo mkdir /data
sudo mount /dev/sdb /data

Now the disk behaves much like a physical disk attached to the machine.

Examples

Cloud	Block storage
AWS	Amazon EBS
Azure	Azure Managed Disks
Google Cloud	Persistent Disk / Hyperdisk

Typical use cases

VM operating systems
PostgreSQL/MySQL databases
Application data
Kubernetes persistent volumes
High-performance workloads

2. Object Storage

Object storage works very differently.

Instead of giving you a disk, the cloud provider gives you a storage service accessed through APIs.

The most famous example is Amazon S3.

Application
     │
     │ HTTP / API
     ↓
 Object Storage
     │
     ├── image.jpg
     ├── backup.tar
     ├── data.csv
     └── logs/

You don't normally get something like:

/dev/sdb

Instead, you interact with objects using APIs, SDKs, CLI tools, or HTTP.

For example, conceptually:

bucket: my-backups
object: database/backup.sql

Examples

Cloud	Object storage
AWS	Amazon S3
Azure	Azure Blob Storage
Google Cloud	Cloud Storage

Typical use cases

Backups
Images and videos
Logs
Data lakes
Large files
Static website assets
Machine-learning datasets

Why is it popular?

Object storage is designed to scale to enormous amounts of data and is generally very durable.

You don't have to think about:

/dev/sdb
filesystem
partitions
mount points

You simply store and retrieve objects.

3. File Storage

File storage provides a filesystem over the network.

The cloud provider manages the filesystem, and your machines connect to it.

                 File Storage
                     │
             ┌───────┼───────┐
             │       │       │
            VM1     VM2     VM3
             │       │       │
          /shared  /shared  /shared

Multiple machines can access the same files.

Common protocols include:

NFS — Network File System
SMB — Server Message Block

For example, with NFS:

sudo mount -t nfs server:/data /mnt/data

The remote filesystem then appears locally:

ls /mnt/data

Examples

Cloud	File storage
AWS	Amazon EFS / FSx
Azure	Azure Files / Azure NetApp Files
Google Cloud	Filestore / NetApp Volumes

Typical use cases

Shared application files
Shared configuration
Multiple VMs accessing the same data
Kubernetes volumes requiring shared access
Enterprise applications

4. NFS Is a Protocol, Not a Storage Type

This is an important distinction.

NFS means Network File System.

It is a protocol for accessing a filesystem over a network.

For example:

              NFS
               │
               ↓
        Network filesystem
               │
        ┌──────┼──────┐
        ↓      ↓      ↓
       VM1    VM2    VM3

So don't think:

NFS = a type of disk.

Instead:

NFS = a way of accessing file storage over a network.

Similarly, SMB is another protocol commonly used for network file storage.

5. Comparing the Three

	Block	File	Object
Mental model	Virtual disk	Network filesystem	S3-like bucket
Access	Block device	NFS / SMB	API / HTTP
Appears as	`/dev/sdb`	`/mnt/shared`	Bucket + object key
Filesystem	You manage it	Provider manages it	Not a traditional filesystem
Mountable	Yes	Yes	Not normally
Shared by VMs	Limited/depends on service	Yes	Yes
Typical use	Databases, VMs	Shared files	Backups, images, data
AWS	EBS	EFS / FSx	S3
Azure	Managed Disks	Azure Files	Blob Storage
GCP	Persistent Disk	Filestore	Cloud Storage

6. The Easiest Mental Model

Think about a normal physical computer.

Block storage

You buy a hard drive:

500 GB SSD
     ↓
Computer
     ↓
/dev/sdb
     ↓
ext4
     ↓
/data

Cloud block storage is essentially a virtualized version of this concept.

File storage

Think about a NAS in your office:

                 NAS
                  │
        ┌─────────┼─────────┐
        ↓         ↓         ↓
       PC1       PC2       PC3

Everyone accesses the same shared filesystem.

Cloud file storage provides a similar concept as a managed service.

Object storage

Think about Google Drive/S3-style storage:

Bucket
├── photo.jpg
├── backup.zip
├── video.mp4
└── dataset.csv

Applications access the objects through an API rather than treating the storage as a normal disk.

7. What About SSD vs HDD?

This is a different dimension.

You can have different performance classes within block storage:

Block Storage
    │
    ├── HDD
    ├── Standard SSD
    ├── Premium SSD
    └── High-performance SSD

The important characteristics are typically:

Capacity
IOPS
Throughput
Latency
Durability
Cost

For example, a PostgreSQL database usually cares a lot about IOPS and latency, while a large backup archive may care more about capacity and cost.

8. What About Snapshots and Backups?

Snapshots and backups aren't really a fourth fundamental storage category.

For example:

Managed Disk
     │
     ├── Snapshot — Monday
     ├── Snapshot — Tuesday
     └── Snapshot — Wednesday

A snapshot is a point-in-time copy/state of storage.

You can often use a snapshot to create a new disk:

Snapshot
    ↓
New Managed Disk
    ↓
Attach to VM
    ↓
Mount filesystem
    ↓
Access files

This is useful when recovering data from a VM.

9. Kubernetes Connection

These concepts become especially useful with Kubernetes.

A Kubernetes application might request storage using a PersistentVolumeClaim:

Pod
 │
 ↓
PersistentVolumeClaim
 │
 ↓
PersistentVolume
 │
 ↓
Cloud Storage

The underlying storage might be:

PVC
 ↓
Azure Managed Disk

or:

PVC
 ↓
Azure Files

The distinction matters because block storage and file storage have different sharing characteristics.

For example, a block-backed volume may typically be attached to one node, while a network file system can allow multiple nodes to access the same filesystem.

10. Summary

The three concepts to remember are:

┌───────────────────────────────────────────┐
│                BLOCK                      │
│                                           │
│ "Give me a disk."                         │
│                                           │
│ /dev/sdb → filesystem → /data             │
└───────────────────────────────────────────┘

┌───────────────────────────────────────────┐
│                 FILE                      │
│                                           │
│ "Give me a shared filesystem."            │
│                                           │
│ NFS / SMB → /mnt/shared                   │
└───────────────────────────────────────────┘

┌───────────────────────────────────────────┐
│                OBJECT                     │
│                                           │
│ "Give me scalable storage through API."   │
│                                           │
│ Bucket → Object → API/HTTP                │
└───────────────────────────────────────────┘

In one sentence:

Block storage is a virtual disk, file storage is a shared network filesystem, and object storage is an API-accessible store for objects such as files and backups.

Laravel Concurrency: Atomicity, Transactions, and Locking

Harry Douglas — Mon, 17 Aug 2026 13:11:04 +0000

Two customers try to purchase a product at exactly the same time.

If the application isn't designed for concurrency, both requests might read stock = 1 and both complete the purchase.

This is where atomicity, transactions, and locking become important.

1. Atomicity

Atomicity is one of the four ACID properties:

Atomicity
Consistency
Isolation
Durability

Atomicity means that a group of database operations is treated as one indivisible unit.

Either:

all operations succeed, or
all operations are rolled back.

Example

Order::create([
    'user_id' => 1,
    'total' => 100,
]);

Payment::create([
    'user_id' => 1,
    'amount' => 100,
]);

If the order is created but the payment fails, we could end up with an inconsistent state.

A transaction allows us to make these operations atomic.

2. Transactions

Laravel provides:

DB::transaction(function () {
    // database operations
});

Example:

DB::transaction(function () {
    $order = Order::create([
        'user_id' => 1,
        'total' => 100,
    ]);

    Payment::create([
        'user_id' => 1,
        'amount' => 100,
    ]);
});

If everything succeeds:

COMMIT

If an exception occurs:

ROLLBACK

The important idea is:

A transaction groups related database operations into one unit of work.

3. Race Conditions

A race condition happens when multiple requests access shared data concurrently and the result depends on the timing of those operations.

Imagine:

Product stock = 1

Two requests arrive:

Request A                 Request B
---------                 ---------
Read stock = 1            Read stock = 1
Stock available           Stock available
Buy product               Buy product

Both requests saw the same stock value.

This can lead to incorrect behavior.

4. Pessimistic Locking

Pessimistic locking assumes that a conflict might happen.

The idea is:

Lock the data before working with it.

Laravel provides:

lockForUpdate()

and:

sharedLock()

5. `lockForUpdate()`

lockForUpdate() is commonly used when you need to read a row and then modify it.

DB::transaction(function () use ($productId) {
    $product = Product::where('id', $productId)
        ->lockForUpdate()
        ->firstOrFail();

    if ($product->stock <= 0) {
        throw new Exception('Out of stock.');
    }

    $product->decrement('stock');

    Order::create([
        'product_id' => $product->id,
    ]);
});

The important part is:

->lockForUpdate()

For a simple primary-key lookup, you can think of this as locking the matching row.

6. What happens with two requests?

Suppose:

Product #1
stock = 1

Request A:

BEGIN TRANSACTION
        ↓
Lock Product #1
        ↓
Read stock = 1
        ↓
Decrease stock
        ↓
Create order
        ↓
COMMIT
        ↓
Unlock

Request B tries to lock the same row while A still has the lock:

BEGIN TRANSACTION
        ↓
Try to lock Product #1
        ↓
WAIT...

After Request A commits, the lock is released and Request B can continue.

Request B then sees the updated stock.

7. Does `lockForUpdate()` lock the whole table?

Usually, no.

For:

$product = Product::where('id', $productId)
    ->lockForUpdate()
    ->firstOrFail();

you can generally think of the matching row as being locked.

For example:

products

id    stock
------------
1     10       available
2     20       LOCKED
3     30       available

The exact locking behavior depends on the database engine, indexes, isolation level, and query.

For a simple primary-key lookup, thinking in terms of a row-level lock is appropriate.

8. `sharedLock()`

Laravel also provides:

->sharedLock()

Example:

DB::transaction(function () {
    $product = Product::where('id', 1)
        ->sharedLock()
        ->firstOrFail();

    // Protected read
});

A useful mental model is:

sharedLock()
    ↓
"I'm reading this data and want protected access."

while:

lockForUpdate()
    ↓
"I'm reading this because I'm going to modify it."

9. Optimistic Locking

Optimistic locking takes a different approach.

Instead of locking the row, we assume conflicts are relatively uncommon.

The idea is:

Don't lock the record. Detect whether somebody else changed it when you try to update it.

A common implementation uses a version column.

Example:

users

id    balance    version
------------------------
1     1000       5

The application reads:

balance = 1000
version = 5

Later, it updates only if the version is still 5:

UPDATE users
SET balance = 500,
    version = 6
WHERE id = 1
AND version = 5;

If one row is updated, the operation succeeded.

If zero rows are updated, someone else changed the record.

10. Optimistic Locking in Laravel

Laravel/Eloquent doesn't provide optimistic locking as a standard built-in feature like lockForUpdate().

You can implement it yourself.

$user = User::findOrFail($id);

$version = $user->version;

$updated = User::where('id', $user->id)
    ->where('version', $version)
    ->update([
        'balance' => 500,
        'version' => $version + 1,
    ]);

if ($updated === 0) {
    throw new RuntimeException(
        'The record was modified by another process.'
    );
}

The important part is:

Read version
      ↓
Work
      ↓
UPDATE ... WHERE version = old_version
      ↓
Success → nobody changed it
Failure → somebody changed it

11. Pessimistic vs Optimistic Locking

	Pessimistic	Optimistic
Strategy	Lock first	Detect conflict later
Blocks concurrent access	Yes	No
Database row lock	Yes	Usually no
Version column	Not required	Usually
Good when	Conflicts are likely	Conflicts are uncommon
Laravel	`lockForUpdate()`	Usually custom implementation

Easy way to remember:

Pessimistic: "I expect a conflict, so I'll lock it."

Optimistic: "I don't expect a conflict, so I'll detect it if it happens."

12. Deadlocks

A deadlock occurs when two transactions are waiting for each other's locks.

For example:

Transaction A              Transaction B

Lock User #1               Lock User #2
     ↓                           ↓
Try User #2                 Try User #1
     ↓                           ↓
   WAIT                        WAIT

Now:

A waits for B
B waits for A

The database detects the deadlock and normally aborts one of the transactions.

How to reduce deadlocks

Keep transactions short.
Lock resources in a consistent order.
Avoid unnecessary locks.
Avoid slow operations inside transactions.
Retry transactions when appropriate.

13. Atomic Updates

Sometimes you don't need an explicit lock.

Instead of:

$product = Product::find($id);

if ($product->stock > 0) {
    $product->decrement('stock');
}

you can make the condition and update part of the same SQL statement:

$updated = Product::where('id', $id)
    ->where('stock', '>', 0)
    ->decrement('stock');

if ($updated === 0) {
    throw new Exception('Out of stock.');
}

Conceptually, this becomes:

UPDATE products
SET stock = stock - 1
WHERE id = ?
AND stock > 0;

The database performs the condition and update together.

14. `Cache::lock()`

Laravel also provides application-level atomic locks:

Cache::lock()

Example:

$lock = Cache::lock("process-order:{$orderId}", 10);

if ($lock->get()) {
    try {
        // Critical section
    } finally {
        $lock->release();
    }
}

This is different from:

lockForUpdate()

A useful distinction is:

lockForUpdate()
    ↓
Database row locking

Cache::lock()
    ↓
Application/distributed locking

Cache::lock() is useful when multiple workers or servers need to coordinate access to the same logical resource.

15. Transactions vs Locks

This distinction is extremely important.

A transaction answers:

"Which operations should succeed or fail together?"

A lock answers:

"How should concurrent operations access the same data?"

Think:

Transaction
    ↓
Atomicity
    ↓
COMMIT / ROLLBACK

Lock
    ↓
Concurrency control
    ↓
Prevent or detect conflicts

You often use both together:

DB::transaction(function () use ($productId) {
    $product = Product::where('id', $productId)
        ->lockForUpdate()
        ->firstOrFail();

    if ($product->stock <= 0) {
        throw new Exception('Out of stock.');
    }

    $product->decrement('stock');

    Order::create([
        'product_id' => $product->id,
    ]);
});

Here:

DB::transaction() provides atomicity.
lockForUpdate() provides pessimistic concurrency control.
The application prevents two requests from purchasing the same final item.

16. Interview Questions

What is atomicity?

Atomicity means that a group of database operations is treated as a single unit. Either all operations are committed or they are all rolled back.

What is a transaction?

A transaction groups database operations together and provides commit and rollback semantics.

What is a race condition?

A race condition occurs when concurrent operations access shared state and the result depends on their timing or ordering.

What is `lockForUpdate()`?

lockForUpdate() is Laravel's pessimistic row-locking mechanism. It is used when a transaction needs to read and modify rows while preventing conflicting concurrent updates.

What is optimistic locking?

Optimistic locking doesn't block concurrent access. Instead, it detects whether a record changed between reading and updating, commonly using a version column.

Does Laravel have built-in optimistic locking?

Eloquent doesn't provide optimistic locking as a standard built-in feature like lockForUpdate(). It is commonly implemented using a version or timestamp check.

What is a deadlock?

A deadlock occurs when transactions hold locks that the other transactions need, causing them to wait for each other.

What is the difference between optimistic and pessimistic locking?

Pessimistic locking prevents conflicts by locking the resource before working with it. Optimistic locking assumes conflicts are uncommon and detects them when updating.

Final Mental Model

                    CONCURRENCY
                         |
          +--------------+--------------+
          |                             |
     TRANSACTIONS                    LOCKS
          |                             |
      Atomicity                 +-------+-------+
          |                     |               |
    COMMIT/ROLLBACK       Pessimistic      Optimistic
                              |               |
                       lockForUpdate()    version check
                       sharedLock()

The key ideas to remember:

Atomicity
    ↓
All operations succeed or all fail.

Transaction
    ↓
Groups operations into one unit of work.

Pessimistic locking
    ↓
Lock first, then work.

Optimistic locking
    ↓
Work first, detect conflicts when saving.

Race condition
    ↓
Concurrent operations produce an incorrect or unexpected result.

Deadlock
    ↓
Transactions wait for each other's locks.

For a Laravel interview, these concepts give you a strong foundation for understanding database concurrency.

What is a database view?

Harry Douglas — Fri, 14 Aug 2026 13:42:38 +0000

In database terminology, a view is a virtual table based on the result set of an SQL query.

Unlike a standard database table, a view does not store data on disk by default. Instead, it acts as a saved window or lens looking into one or more underlying base tables. Every time you query a view, the database runs the view's underlying SQL query behind the scenes and returns the fresh, real-time data.

How It Works

Think of a view as a saved bookmark of a query.

If you have a complex query that joins five tables together and performs calculations, you can package that logic into a view. Once created, you can treat that view just like a regular table in your SELECT statements.

+-------------------+      +-------------------+
|  orders Table     |      |  customers Table  |
+-------------------+      +-------------------+
          \                      /
           \                    /
            v                  v
       +----------------------------+
       |   VIEW: customer_orders    |  <-- Virtual Table (No data stored)
       +----------------------------+
                     |
                     v
           SELECT * FROM customer_orders;

Why Use Views?

Views are one of the most useful tools in database design. Here are the main reasons to use them:

Simplification: They hide complex JOINs, GROUP BY aggregations, and messy conditional logic behind a simple SELECT * FROM view_name.
Security & Access Control: You can grant a user access to a view without giving them access to the underlying tables. For example, you can create a view that exposes a user's name and email while stripping out their password_hash and ssn.
Data Consistency: Rather than every developer writing their own query to calculate "Monthly Active Users," you write the logic once in a view so everyone uses the exact same definition.
Backward Compatibility: If you refactor or split a database table, you can create a view with the old table's structure so legacy applications won't break while transitioning.

What is Information Schema in PostgreSQL?

Harry Douglas — Fri, 14 Aug 2026 13:34:34 +0000

In PostgreSQL, information_schema is an ANSI/ISO SQL-standard, read-only set of views containing metadata about your database objects.

Think of it as the database's self-aware blueprint. Instead of remembering exact system table layouts, you can query information_schema using standard SQL SELECT statements to inspect tables, columns, data types, privileges, constraints, and more.

Key Benefits

SQL Standardized: Because information_schema follows ANSI standards, the queries you write against it in PostgreSQL will often work in other SQL databases like MySQL, SQL Server, and MariaDB with little to no modification.
Permission-Aware: It automatically filters results. You will only see metadata for database objects that your current database user account actually has permission to access.
Stability: Unlike internal system catalogs, the structure of information_schema views remains consistent across PostgreSQL versions.

Frequently Used Views

View Name	Description
`information_schema.tables`	Lists all tables and views in the database.
`information_schema.columns`	Contains details on columns (names, data types, default values, nullability).
`information_schema.table_constraints`	Lists primary keys, foreign keys, unique constraints, and check constraints.
`information_schema.schemata`	Lists available schemas in the current database.
`information_schema.routines`	Details functions and stored procedures.
`information_schema.views`	Shows view definitions and properties.

Practical Examples

1. List all user tables in the `public` schema

SELECT table_name 
FROM information_schema.tables 
WHERE table_schema = 'public' 
  AND table_type = 'BASE TABLE';

2. View all columns and data types for a specific table

SELECT column_name, data_type, is_nullable, column_default
FROM information_schema.columns
WHERE table_schema = 'public' 
  AND table_name = 'users'
ORDER BY ordinal_position;

3. Find primary key constraints

SELECT table_name, constraint_name
FROM information_schema.table_constraints
WHERE constraint_type = 'PRIMARY KEY'
  AND table_schema = 'public';

`information_schema` vs. `pg_catalog`

PostgreSQL actually stores all of its system data in a native schema called pg_catalog (e.g., pg_class, pg_attribute). The information_schema views are built on top of pg_catalog.

Use information_schema when you want portable, standard SQL or straightforward details like column names and data types.
Use pg_catalog when you need deep, PostgreSQL-specific metadata (such as indexes, tablespaces, WAL details, or custom ENUM types) that the generic ANSI SQL standard doesn't cover.

Complete Python Logging Guide: From Fundamentals to Production

Harry Douglas — Fri, 14 Aug 2026 13:26:30 +0000

This comprehensive tutorial covers everything you need to know about logging in Python: best practices for cloud/containers, core concepts, the logger hierarchy, and building a production-ready colored logging setup.

1. Why Send Logs to `stdout`/`stderr` Instead of Files?

When building modern applications (especially inside Docker, Kubernetes, or serverless platforms), the standard best practice is to treat logs as an unbuffered event stream.

`stdout` vs `stderr`

stdout (Standard Output): Used for standard application flow logs (DEBUG, INFO).
stderr (Standard Error): Used for warnings, runtime errors, and fatal exceptions (WARNING, ERROR, CRITICAL).

Benefits Over File Logging

Container Compatibility: Containers (like Docker) are temporary. Files stored inside a container disappear when it restarts. Container runtimes automatically capture stdout and stderr.
Centralized Aggregation: Log collectors (Datadog, AWS CloudWatch, Grafana Loki, Fluentd) scrape standard output streams automatically.
Disk Safety: Writing directly to disk risk filling up server storage and crashing your application.
Separation of Concerns: Your app's job is to output events. The hosting platform's job is to store, rotate, and archive them.

2. Python Logging Basics

Python includes a built-in logging module. You should use it instead of print() statements.

Why Avoid `print()`?

print() cannot easily filter messages by importance.
print() lacks timestamps, file names, line numbers, or context.
print() sends everything to stdout without distinguishing errors.

Log Levels

Python provides five standard log levels, ordered by severity:

Level	Numerical Value	When to Use
`DEBUG`	10	Low-level details during development.
`INFO`	20	Normal operational events (e.g., service started, request processed).
`WARNING`	30	Something unexpected happened, but the program can continue.
`ERROR`	40	A serious error occurred; a feature failed to execute.
`CRITICAL`	50	A fatal error; the entire program may crash.

3. The 4 Pillars of Python Logging

Advanced logging in Python relies on four core classes:

Logger: The primary interface your application code calls (e.g., logger.info()).
Handler: Directs log messages to their final destination (StreamHandler for console, FileHandler for disk files).
Formatter: Defines the layout and text structure of the final log message.
Filter: Provides fine-grained control to include or exclude specific log records.

4. Understanding the Logger Hierarchy

Loggers are organized in a parent-child tree using dot notation, similar to Python module import paths.

1. Hierarchy Structure

"" (Empty string): The Root Logger at the top of the tree.
"app": Child of the Root Logger.
"app.database": Child of "app".
"app.database.mysql": Child of "app.database".

Best practice in any file is to instantiate loggers using __name__:

logger = logging.getLogger(__name__)

2. Propagation Flow

When a child logger records a message:

It checks if the message meets its own level setting.
If allowed, it executes its attached Handlers.
It passes the message upward to its parent logger's handlers (this behavior is called propagation).

Root Logger ("")        ---> StreamHandler (Console Output)
       ▲
       │ (Propagates UP)
 Logger ("app")         ---> Custom FileHandler
       ▲
       │ (Propagates UP)
Logger ("app.database") ---> Calls logger.info("Query executed")

To stop a child logger from sending records to parent handlers:

logger.propagate = False

5. Production-Ready Configuration with `colorlog`

To make console output easily readable during development and log inspection, you can color-code your terminal logs using the third-party colorlog library:

pip install colorlog

The Configuration Function

import logging
import colorlog

def configure_logging(logger: logging.Logger, verbose: bool = False) -> None:
    """Configures a logger with ANSI color output and dynamic verbosity."""

    # 1. Create a stream handler targeting standard output/error
    handler = colorlog.StreamHandler()

    # 2. Format output with level-specific colors
    handler.setFormatter(colorlog.ColoredFormatter(
        "%(log_color)s%(asctime)s [%(name)s] %(levelname)s: %(message)s",
        datefmt="%H:%M:%S",
        log_colors={
            'DEBUG':    'cyan',
            'INFO':     'green',
            'WARNING':  'yellow',
            'ERROR':    'red',
            'CRITICAL': 'red,bg_white',
        }
    ))

    # 3. Clear existing handlers to prevent duplicate lines
    logger.handlers.clear()

    # 4. Attach configured handler
    logger.addHandler(handler)

    # 5. Set log level based on verbosity flag
    logger.setLevel(logging.DEBUG if verbose else logging.INFO)

6. Complete End-to-End Example

Here is a complete, executable script demonstrating logger initialization, child inheritance, and color formatting.

import logging
import colorlog

# --- Logging Setup Helper ---
def configure_logging(logger: logging.Logger, verbose: bool = False) -> None:
    handler = colorlog.StreamHandler()
    handler.setFormatter(colorlog.ColoredFormatter(
        "%(log_color)s%(asctime)s [%(name)s] %(levelname)s: %(message)s",
        datefmt="%H:%M:%S",
        log_colors={
            'DEBUG':    'cyan',
            'INFO':     'green',
            'WARNING':  'yellow',
            'ERROR':    'red',
            'CRITICAL': 'red,bg_white',
        }
    ))
    logger.handlers.clear()
    logger.addHandler(handler)
    logger.setLevel(logging.DEBUG if verbose else logging.INFO)


# --- Application Setup ---
# 1. Initialize parent logger
app_logger = logging.getLogger("my_app")
configure_logging(app_logger, verbose=True)  # Enable debug mode

# 2. Initialize child logger
db_logger = logging.getLogger("my_app.database")


# --- Execution ---
if __name__ == "__main__":
    app_logger.info("Initializing application services...")

    # Child logger inherits parent's configuration via propagation
    db_logger.debug("Connecting to PostgreSQL at 127.0.0.1:5432")
    db_logger.info("Database connection established.")

    # Simulate warning and error events
    app_logger.warning("Cache missed for key: 'user_1024'")

    try:
        result = 1 / 0
    except ZeroDivisionError:
        db_logger.error("Failed to calculate user metric", exc_info=True)

    app_logger.critical("Memory threshold exceeded! Shutting down process.")

Linux Disk Usage: du and df

Harry Douglas — Fri, 14 Aug 2026 12:27:06 +0000

If you work with Linux servers long enough, sooner or later you'll see this:

df -h

and discover that your disk is 95% full.

The next question is:

What is using all that space?

This is where two Linux commands become essential:

df → How full is my filesystem?

du → What is using the space?

Once you understand this distinction, disk-space troubleshooting becomes much easier.

1. `df`: How Full Is My Filesystem?

df stands for disk free.

It reports disk-space information at the filesystem level.

Start with:

df

You'll get something like:

Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/nvme0n1p2  104857600 62914560 41943040  60% /

The numbers aren't particularly convenient to read, so we normally use -h.

`df -h`

df -h

Example:

Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  100G   60G   35G  64% /
/dev/nvme0n1p1  512M   10M  502M   2% /boot/efi

The -h means human-readable. Instead of large numbers, Linux shows sizes such as:

512M
10G
100G
1.2T

Understanding the output

Consider:

Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  100G   60G   35G  64% /

Filesystem → the filesystem/device
Size → total capacity
Used → space currently used
Avail → available space
Use% → percentage used
Mounted on → where the filesystem is mounted

So this tells us:

The filesystem mounted at / has 100 GB of capacity, 60 GB is used, and it is 64% full.

But df doesn't tell us what is using those 60 GB.

That's where du comes in.

2. `du`: Where Is the Space Being Used?

du stands for disk usage.

While df works at the filesystem level, du works with files and directories.

It answers:

How much space are these files and directories using?

Try:

du

You'll get output showing directory usage.

Again, we usually want human-readable values:

du -h

For example:

4.0K    ./config
120M    ./data
1.2G    ./node_modules
1.4G    .

3. `du -sh`: Get the Total

Suppose you want to know how much space /var is using.

du -sh /var

Example:

12G    /var

There are two options here:

-s → summary
-h → human-readable

So:

du -sh /var

means:

Give me a human-readable summary of the disk usage of /var.

4. `du -sh *`: See the Size of Everything Here

One of the most useful commands is:

du -sh *

Suppose your current directory contains:

config/
data/
logs/
node_modules/

You might get:

4.0K    config
120M    data
20M     logs
1.2G    node_modules

Now it's immediately obvious that node_modules is the largest directory.

The * is a shell wildcard meaning:

The items in the current directory.

The shell expands the command before du receives it.

Conceptually:

du -sh *

becomes something like:

du -sh config data logs node_modules

5. `du --max-depth`

Sometimes you don't want du to recursively show everything.

You only want to see the first level of directories.

Use:

du -h --max-depth=1

Example:

120M    ./data
20M     ./logs
1.2G    ./node_modules
1.4G    .

This is extremely useful for investigating a large directory.

For example:

sudo du -h --max-depth=1 /var

might show:

45G    /var/lib
20G    /var/log
8G     /var/cache
80G    /var

Now you know that /var/lib is the directory worth investigating.

You can go one level deeper:

sudo du -h --max-depth=1 /var/lib

Maybe you'll find:

30G    /var/lib/docker
10G    /var/lib/postgresql
5G     /var/lib/apt

You can keep drilling down until you find the source.

6. Sort `du` by Size

du doesn't automatically sort the results.

Combine it with sort:

du -h --max-depth=1 | sort -h

For largest first:

du -h --max-depth=1 | sort -hr

Here:

-h → understand human-readable sizes
-r → reverse the order

So:

du -h --max-depth=1 | sort -hr

might produce:

1.4G    .
1.2G    ./node_modules
120M    ./data
20M     ./logs
4.0K    ./config

This is one of the commands I use most when investigating disk usage.

7. `df` and `du` Together

This is the most important part.

Imagine you run:

df -h

and get:

Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  100G   90G    5G  95% /

You now know:

My root filesystem is almost full.

But you don't know why.

So you run:

sudo du -h --max-depth=1 / | sort -hr

and discover:

90G    /
50G    /var
25G    /home
10G    /usr

Now you know:

/var is consuming 50 GB.

So investigate /var:

sudo du -h --max-depth=1 /var | sort -hr

You might find:

50G    /var
35G    /var/lib
10G    /var/log
5G     /var/cache

Then:

sudo du -h --max-depth=1 /var/lib | sort -hr

And continue until you find the actual source.

The workflow is:

df -h
   ↓
"Filesystem is almost full"
   ↓
du /
   ↓
"Which directory is consuming the space?"
   ↓
du /large-directory
   ↓
"Which subdirectory?"
   ↓
keep drilling down

8. The Difference Between `df` and `du`

This distinction is worth memorizing.

Command	Answers
`df`	How full is the filesystem?
`du`	What is using the space?

Think of it like this:

                 Disk
                  │
          ┌───────┴───────┐
          │               │
         df              du
          │               │
          ▼               ▼
   Filesystem level   File/directory level
          │               │
          ▼               ▼
   "90 GB is used"   "50 GB is in /var"

Or simply:

df tells you that you have a problem. du helps you find the problem.

9. Why `df` and `du` Can Sometimes Disagree

You might encounter something strange:

df -h

says:

100G total
90G used

but:

sudo du -sh /

only reports:

70G

Where did the other 20 GB go?

One common explanation is deleted files that are still open by a process.

Consider this:

Process
   │
   └── opens huge.log
            │
            ▼
           20 GB

Then someone deletes the file:

rm huge.log

The filename disappears from the filesystem, so du can no longer see it.

But the process still has the file open.

Therefore:

du → doesn't count it
df → still counts the space

You can investigate deleted-but-open files with:

sudo lsof +L1

This is one reason df and du are not interchangeable.

10. `df -T`: See the Filesystem Type

You can also ask df to show the filesystem type:

df -Th

Example:

Filesystem      Type  Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  ext4  100G   60G   35G  64% /

The -T adds the filesystem type.

For example:

ext4
xfs
btrfs

11. A Real Example: Investigating APT

Suppose you notice that:

sudo du -sh /var/lib/apt/*

returns:

4.0K    /var/lib/apt/cdroms.list
152K    /var/lib/apt/extended_states
400M    /var/lib/apt/lists
8.0K    /var/lib/apt/mirrors
4.0K    /var/lib/apt/periodic

Immediately, you can see:

/var/lib/apt/lists → 400M

is the major consumer.

You can investigate further:

sudo du -sh /var/lib/apt/lists/*

This is the real power of du: you can drill down through the filesystem until you find what is consuming the space.

12. Why Docker Deletes `/var/lib/apt/lists/*`

You may have seen this Dockerfile:

RUN apt-get update \
    && apt-get install -y --no-install-recommends libgdal-dev \
    && rm -rf /var/lib/apt/lists/*

apt-get update downloads package indexes into:

/var/lib/apt/lists/

These indexes are needed by APT to find packages, but after the package installation they usually aren't needed by the application.

Therefore:

rm -rf /var/lib/apt/lists/*

removes them and makes the Docker image smaller.

You can see how much space they consume with:

sudo du -sh /var/lib/apt/lists

13. The Commands Worth Memorizing

You don't need to memorize every option.

For df:

df -h

Show filesystem usage in human-readable form.

df -Th

Show filesystem usage and filesystem type.

For du:

du -sh /var

Show the total size of /var.

du -sh *

Show the size of every item in the current directory.

du -h --max-depth=1

Show directory sizes one level deep.

du -h --max-depth=1 | sort -hr

Show directory sizes one level deep, largest first.

And for serious disk investigation:

sudo du -h --max-depth=1 / | sort -hr

14. A Practical Disk-Space Troubleshooting Workflow

When someone tells you:

"The server is running out of disk space."

Start here:

df -h

Find the filesystem that is almost full.

Then:

sudo du -h --max-depth=1 / | sort -hr

Find the largest directory.

Then investigate that directory:

sudo du -h --max-depth=1 /var | sort -hr

Then continue:

sudo du -h --max-depth=1 /var/lib | sort -hr

And so on.

For example:

df -h
   ↓
/ is 95% full
   ↓
du /
   ↓
/var is 60 GB
   ↓
du /var
   ↓
/var/lib is 50 GB
   ↓
du /var/lib
   ↓
/var/lib/docker is 45 GB
   ↓
investigate Docker

This is a skill you'll use constantly when working with Linux servers, Docker, Kubernetes nodes, databases, and CI/CD systems.

15. Final Mental Model

Don't think of du and df as two commands that do the same thing.

Think:

                         DISK SPACE
                             │
                 ┌───────────┴───────────┐
                 │                       │
                df                      du
                 │                       │
                 ▼                       ▼
         Filesystem level         File/directory level
                 │                       │
                 ▼                       ▼
        "How full is it?"         "What's using it?"

When troubleshooting disk usage:

df -h

first.

Then:

sudo du -h --max-depth=1 / | sort -hr

second.

That's the fundamental Linux disk-usage workflow:

df tells you how full the filesystem is. du tells you where the space is being used.

Building a Simple Password Generator in Go: From Idea to Release

Harry Douglas — Wed, 15 Apr 2026 12:31:25 +0000

Hello friends! 👋

Do you need a quick password in the terminal? I made PGen for that. It is a small CLI tool. It makes passwords fast. It is simple, but very useful. No more open browser for passwords. Just type pgen and done.

Why PGen?

We developers need passwords often. For databases, APIs, tests. I wanted a light tool for my work. PGen is that. It is simple and safe. It makes random passwords. You can choose length and types of letters.

The Technical Parts (Go Stuff)

PGen uses Go. Go is good for this.

crypto/rand for safe random numbers. No weak passwords.
os.Args for command line. First number is length (default 8). Second is options like "u" for big letters, "l" for small, "n" for numbers, "s" for symbols.
Go builds for many systems easy. I used GOOS and GOARCH for Linux, Windows, macOS.

The main code is in generate.go. It picks letters from a set. It uses random to choose. Here is a simple part:

func generatePassword(length int, options string) string {
    charset := ""
    if strings.Contains(options, "l") { charset += "abcdefghijklmnopqrstuvwxyz" }
    if strings.Contains(options, "u") { charset += "ABCDEFGHIJKLMNOPQRSTUVWXYZ" }
    if strings.Contains(options, "n") { charset += "0123456789" }
    if strings.Contains(options, "s") { charset += "!@#$%^&*()_+-=[]{}|;:,.<>?" }

    password := make([]byte, length)
    for i := range password {
        password[i] = charset[rand.Intn(len(charset))]
    }
    return string(password)
}

The real code uses crypto/rand for safety.

Install and Use

Start is easy. If you have Go:

go install github.com/hrrydgls/pgen@latest

No Go? Download from releases.

Linux/macOS: sudo curl -L https://github.com/hrrydgls/pgen/releases/download/v1.0.0/pgen -o /usr/local/bin/pgen && sudo chmod +x /usr/local/bin/pgen
Windows: Download pgen-windows.exe and add to PATH.

Use:

pgen 20           # 20 letters with all
pgen 12 ul        # 12 letters, big and small
pgen              # 8 letters default

Examples:

➜ pgen 20
j3T72Y869XDM}8U9?d)v

➜ pgen 20 u
YGRMKFFNSPQFJHPWVNGZ

The Release

Making release was fun. I made tag v1.0.0. I used gh release create for binaries. Now anyone can download. No need to build.

End

PGen is simple, but strong. It helps a lot. Code is open on GitHub. Change it if you want.

What do you think? Do you have simple tools? Tell me! 🚀

OverlayFS — The Magic Behind Docker

Harry Douglas — Mon, 29 Sep 2025 15:47:48 +0000

Docker’s efficiency comes from a Linux kernel feature called OverlayFS. It allows multiple directories (called layers) to be combined into a single merged view. This is how Docker can reuse common image layers (Ubuntu, Alpine, etc.) across many containers, while giving each container its own writable layer.

In this tutorial, we’ll recreate Docker’s storage trick with a few simple commands.

🔹 Step 1: Setup directories

Create a playground with 4 directories:

mkdir overlayfs
cd overlayfs
mkdir -p lower upper work merged

lower/ → base read-only layer (like Docker image layers)
upper/ → writable layer (container changes go here)
work/ → internal work area (needed by OverlayFS)
merged/ → final view (what the container “sees”)

🔹 Step 2: Add a file in the lower layer

echo "hello from lower" > lower/file1.txt

Check:

ls lower
# file1.txt

🔹 Step 3: Mount OverlayFS

Now mount the union filesystem:

sudo mount -t overlay overlay \
  -o lowerdir=./lower,upperdir=./upper,workdir=./work \
  ./merged

Check the merged view:

ls merged
# file1.txt
cat merged/file1.txt
# hello from lower

🔹 Step 4: Create a new file in the merged layer

echo "hello from upper" > merged/file2.txt

Now inspect:

ls lower    # still file1.txt
ls upper    # now has file2.txt
ls merged   # file1.txt + file2.txt

👉 New files go to upper.

🔹 Step 5: Modify an existing file (Copy-on-Write)

echo "changed in merged" > merged/file1.txt

Inspect again:

cat lower/file1.txt   # still "hello from lower"
cat upper/file1.txt   # now "changed in merged"

👉 The file was copied from lower to upper, then modified = copy-on-write.

🔹 Step 6: Delete a file

rm merged/file1.txt

Now:

ls merged   # only file2.txt
ls lower    # still has file1.txt
ls upper    # contains a "whiteout" marker

👉 OverlayFS hides lower’s file1.txt using a special whiteout file.

🔹 Step 7: Unmount

When done, unmount:

sudo umount merged

The merged view disappears, but the lower/upper directories still contain their raw files.

🔹 Key Takeaways

Lowerdir = base image layers (read-only)
Upperdir = writable container layer
Workdir = bookkeeping area for OverlayFS
Merged = what the container sees
Copy-on-Write = changes to lower files go into upper
Whiteouts = hide deleted files from lower

✅ And that’s it — you’ve just reproduced Docker’s storage mechanism by hand!

Centralized Error Handling in Go (Like Laravel)

Harry Douglas — Fri, 29 Aug 2025 08:53:42 +0000

When building an API in Go, you may notice you keep writing this kind of code everywhere:

if email == "" {
    validationError := responses.Response{
        Code:    422,
        Message: "Invalid email",
    }
    w.WriteHeader(http.StatusUnprocessableEntity)
    json.NewEncoder(w).Encode(validationError)
    return
}

This gets repetitive, messy, and hard to manage as your project grows.

If you're coming from Laravel, you're used to something like throw new Exception(...), and having Laravel automatically return a proper JSON response.

In Go, you can achieve the same thing using:

A custom error type
Middleware
panic() + recover()

Let’s build it together 👇

✅ Goal

Stop repeating the same error-handling code
Throw errors in one line
Always return a clean JSON response
Centralize the logic in one place

✅ Step 1: Define a Common Error Response Format

Create a file like responses/Response.go:

package responses

type Response struct {
    Code    int    `json:"code"`
    Message string `json:"message"`
}

This is what your API will return to the client.

✅ Step 2: Create Custom Error Types

In exceptions/ApiError.go, define your custom error structure:

package exceptions

import "net/http"

type APIError struct {
    Code    int
    Message string
}

func (e APIError) Error() string {
    return e.Message
}

Also add helper functions for common error types:

func NotFound(message string) APIError {
    return APIError{Code: http.StatusNotFound, Message: message}
}

func Unprocessable(message string) APIError {
    return APIError{Code: http.StatusUnprocessableEntity, Message: message}
}

Now, you can easily throw:

panic(exceptions.Unprocessable("Email is required"))

✅ Step 3: Global Middleware to Catch Panics and Return JSON

Create a recovery middleware:

package middleware

import (
    "encoding/json"
    "net/http"

    "yourapp/exceptions"
    "yourapp/responses"
)

func RecoveryMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if rec := recover(); rec != nil {
                code := http.StatusInternalServerError
                message := "Internal Server Error"

                if apiErr, ok := rec.(exceptions.APIError); ok {
                    code = apiErr.Code
                    message = apiErr.Message
                }

                w.Header().Set("Content-Type", "application/json")
                w.WriteHeader(code)
                json.NewEncoder(w).Encode(responses.ErrorResponse{
                    Code:    code,
                    Message: message,
                })
            }
        }()

        next.ServeHTTP(w, r)
    })
}

Now, all panics will be caught and turned into clean JSON.

✅ Step 4: Use the Middleware in `main.go`

package main

import (
    "net/http"
    "yourapp/handlers/auth"
    "yourapp/middleware"
)

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/auth/email", auth.EmailHandler)

    http.ListenAndServe(":8080", middleware.RecoveryMiddleware(mux))
}

✅ Step 5: Throw Errors in Your Handler Instead of Writing Response Code

Old way (repetitive):

if email == "" {
    w.WriteHeader(http.StatusUnprocessableEntity)
    json.NewEncoder(w).Encode(responses.ErrorResponse{
        Code: 422,
        Message: "Email is required",
    })
    return
}

New way (cleaner):

if email == "" {
    panic(exceptions.Unprocessable("Email is required"))
}

That’s it!

✅ Example Output

If the user submits an empty email, they will get:

{
  "code": 422,
  "message": "Email is required"
}

This approach gives you Laravel-style centralized error handling in Go.

Instead of repeating this everywhere:

w.WriteHeader(...)
json.NewEncoder(w).Encode(...)

You just call:

panic(exceptions.Unprocessable("message"))

And let your middleware handle the rest. Clean, consistent, and scalable.

Api Requests and Validators in Go

Harry Douglas — Sat, 12 Jul 2025 17:40:31 +0000

I know there are hundreds of ways to implement it better but for learning purposes I wrote a simple request and validator mechanism here in this commit:

https://github.com/hrrydgls/snug/commit/ca07cdfd38828de8901a6b7bdfdf0e35fa6e2d88

It is gonna be better for sure in future but for now I just wanted to keep it simple and clean.

What I did is simple. First I created a package named requests with this struct:

package requests 

type RegisterRequest struct {
    Email string `json:"email"`
    Name string `json:"name"`
    Password string `json:"password"`
}

Then another package named validators and a new validator inside it:

package validators

import (
    "net/mail"

    "github.com/hrrydgls/snug/exceptions"
    "github.com/hrrydgls/snug/requests"
)

func RegisterValidator (registerRequest *requests.RegisterRequest) error {
    if _, error := mail.ParseAddress(registerRequest.Email); error != nil {
        panic(exceptions.Unprocessable("Email is required!"))
    }

    if len(registerRequest.Name) < 3 {
        panic(exceptions.Unprocessable("Name should be at least 3 characters!"))
    }

    if len(registerRequest.Password) < 6 {
        panic(exceptions.Unprocessable("Password should be at least 6 characters!"))
    }

    return nil
}

And finally I used this request and validator in my handler like this:

package auth

import (
    "net/http"

    "github.com/hrrydgls/snug/requests"
    "github.com/hrrydgls/snug/validators"
)

func (handler *Handler) Register(w http.ResponseWriter, r *http.Request) {

    r.ParseForm()

    email := r.FormValue("email")
    name := r.FormValue("name")
    password := r.FormValue("password")


    registerRequest := requests.RegisterRequest {
        Email: email,
        Name: name,
        Password: password,
    }

    validators.RegisterValidator(&registerRequest)

}

I know there are better packages like go-playground/validator that I could use it but I wanted to suffer a bit before using these already working packages :)

As someone from PHP world, I feel better with Golang types... In Laravel we had Requests but while referencing them, you had no idea if this field exist in the request or not. It was not intelligence enough! Everytime I had to go back to request to see if the field exists or not.

I don't wanna complain more about PHP. It is a old language and still alive but I just feel better with this :)

Enjoy!

Centralized Error Handling in Go (Like Laravel)

Harry Douglas — Wed, 09 Jul 2025 08:50:51 +0000

When building an API in Go, you may notice you keep writing this kind of code everywhere:

if email == "" {
    validationError := responses.Response{
        Code:    422,
        Message: "Invalid email",
    }
    w.WriteHeader(http.StatusUnprocessableEntity)
    json.NewEncoder(w).Encode(validationError)
    return
}

This gets repetitive, messy, and hard to manage as your project grows.

If you're coming from Laravel, you're used to something like throw new Exception(...), and having Laravel automatically return a proper JSON response.

In Go, you can achieve the same thing using:

A custom error type
Middleware
panic() + recover()

Let’s build it together 👇

✅ Goal

Stop repeating the same error-handling code
Throw errors in one line
Always return a clean JSON response
Centralize the logic in one place

✅ Step 1: Define a Common Error Response Format

Create a file like responses/Response.go:

package responses

type Response struct {
    Code    int    `json:"code"`
    Message string `json:"message"`
}

This is what your API will return to the client.

✅ Step 2: Create Custom Error Types

In exceptions/ApiError.go, define your custom error structure:

package exceptions

import "net/http"

type APIError struct {
    Code    int
    Message string
}

func (e APIError) Error() string {
    return e.Message
}

Also add helper functions for common error types:

func NotFound(message string) APIError {
    return APIError{Code: http.StatusNotFound, Message: message}
}

func Unprocessable(message string) APIError {
    return APIError{Code: http.StatusUnprocessableEntity, Message: message}
}

Now, you can easily throw:

panic(exceptions.Unprocessable("Email is required"))

✅ Step 3: Global Middleware to Catch Panics and Return JSON

Create a recovery middleware:

package middleware

import (
    "encoding/json"
    "net/http"

    "yourapp/exceptions"
    "yourapp/responses"
)

func RecoveryMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if rec := recover(); rec != nil {
                code := http.StatusInternalServerError
                message := "Internal Server Error"

                if apiErr, ok := rec.(exceptions.APIError); ok {
                    code = apiErr.Code
                    message = apiErr.Message
                }

                w.Header().Set("Content-Type", "application/json")
                w.WriteHeader(code)
                json.NewEncoder(w).Encode(responses.ErrorResponse{
                    Code:    code,
                    Message: message,
                })
            }
        }()

        next.ServeHTTP(w, r)
    })
}

Now, all panics will be caught and turned into clean JSON.

✅ Step 4: Use the Middleware in `main.go`

package main

import (
    "net/http"
    "yourapp/handlers/auth"
    "yourapp/middleware"
)

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/auth/email", auth.EmailHandler)

    http.ListenAndServe(":8080", middleware.RecoveryMiddleware(mux))
}

✅ Step 5: Throw Errors in Your Handler Instead of Writing Response Code

Old way (repetitive):

if email == "" {
    w.WriteHeader(http.StatusUnprocessableEntity)
    json.NewEncoder(w).Encode(responses.ErrorResponse{
        Code: 422,
        Message: "Email is required",
    })
    return
}

New way (cleaner):

if email == "" {
    panic(exceptions.Unprocessable("Email is required"))
}

That’s it!

✅ Example Output

If the user submits an empty email, they will get:

{
  "code": 422,
  "message": "Email is required"
}

This approach gives you Laravel-style centralized error handling in Go.

Instead of repeating this everywhere:

w.WriteHeader(...)
json.NewEncoder(w).Encode(...)

You just call:

panic(exceptions.Unprocessable("message"))

And let your middleware handle the rest. Clean, consistent, and scalable.

How OOP works in Golang

Harry Douglas — Wed, 02 Jul 2025 15:37:37 +0000

I'm quite beginner here in GO but I wanna share what I've learnt about it today! Lets start without losing time. If you are coming from another OOP friendly language, you already know what is a class.
In Go we have the same thing but a bit different:

type Animal struct {
    Name string
}

This is the most basic class we have. Then we can add methods to it:

func (Animal) fly(){
    fmt.Println("Flying...")
}

The syntax seems a bit complicate to me as someone from PHP world but not too bad!

Share your comments with me to feel that I am not alone here with this new stuff :)

DEV Community: Harry Douglas

Cloud Storage Basics: Block, File, and Object Storage

1. Block Storage

Examples

Typical use cases

2. Object Storage

Examples

Typical use cases

Why is it popular?

3. File Storage

Examples

Typical use cases

4. NFS Is a Protocol, Not a Storage Type

5. Comparing the Three

6. The Easiest Mental Model

Block storage

File storage

Object storage

7. What About SSD vs HDD?

8. What About Snapshots and Backups?

9. Kubernetes Connection

10. Summary

Laravel Concurrency: Atomicity, Transactions, and Locking

1. Atomicity

Example

2. Transactions

3. Race Conditions

4. Pessimistic Locking

5. lockForUpdate()

6. What happens with two requests?

7. Does lockForUpdate() lock the whole table?

8. sharedLock()

9. Optimistic Locking

10. Optimistic Locking in Laravel

11. Pessimistic vs Optimistic Locking

12. Deadlocks

How to reduce deadlocks

13. Atomic Updates

14. Cache::lock()

15. Transactions vs Locks

16. Interview Questions

What is atomicity?

What is a transaction?

What is a race condition?

What is lockForUpdate()?

What is optimistic locking?

Does Laravel have built-in optimistic locking?

What is a deadlock?

What is the difference between optimistic and pessimistic locking?

Final Mental Model

What is a database view?

How It Works

Why Use Views?

What is Information Schema in PostgreSQL?

Key Benefits

Frequently Used Views

Practical Examples

1. List all user tables in the public schema

2. View all columns and data types for a specific table

3. Find primary key constraints

information_schema vs. pg_catalog

Complete Python Logging Guide: From Fundamentals to Production

1. Why Send Logs to stdout/stderr Instead of Files?

stdout vs stderr

Benefits Over File Logging

2. Python Logging Basics

Why Avoid print()?

Log Levels

3. The 4 Pillars of Python Logging

4. Understanding the Logger Hierarchy

1. Hierarchy Structure

2. Propagation Flow

5. Production-Ready Configuration with colorlog

The Configuration Function

6. Complete End-to-End Example

Linux Disk Usage: du and df

1. df: How Full Is My Filesystem?

df -h

Understanding the output

2. du: Where Is the Space Being Used?

5. `lockForUpdate()`

7. Does `lockForUpdate()` lock the whole table?

8. `sharedLock()`

14. `Cache::lock()`

What is `lockForUpdate()`?

1. List all user tables in the `public` schema

`information_schema` vs. `pg_catalog`

1. Why Send Logs to `stdout`/`stderr` Instead of Files?

`stdout` vs `stderr`

Why Avoid `print()`?

5. Production-Ready Configuration with `colorlog`

1. `df`: How Full Is My Filesystem?

`df -h`

2. `du`: Where Is the Space Being Used?

3. `du -sh`: Get the Total

4. `du -sh *`: See the Size of Everything Here

5. `du --max-depth`

6. Sort `du` by Size

7. `df` and `du` Together

8. The Difference Between `df` and `du`

9. Why `df` and `du` Can Sometimes Disagree

10. `df -T`: See the Filesystem Type

12. Why Docker Deletes `/var/lib/apt/lists/*`

✅ Step 4: Use the Middleware in `main.go`

✅ Step 4: Use the Middleware in `main.go`