DEV Community: Maksym

Docker Transfers: The Lazy (and Fast) Way

Maksym — Fri, 19 Jun 2026 08:04:53 +0000

You have a server. It's old. Maybe it's running on modest hardware, maybe the network is slow, or maybe your project has grown to the point where a full docker compose build takes 10–15 minutes. Waiting for that every time you deploy a change is painful — especially when the change was two lines of Python.

There's a better way: build once, ship the image.

First, Let's Clarify the Terminology

Before diving into commands, it's worth making sure we're on the same page about three terms that often get mixed up.

Docker Build

A build is the process of turning a Dockerfile + build context (your source files) into an image. This is what's slow on your old server. It runs through every instruction — installing packages, copying files, compiling assets — layer by layer.

Dockerfile + source code  →  (docker build)  →  Image

The key insight: you only need to build once. After that, you can move the resulting image anywhere without rebuilding.

Docker Image

A Docker image is a read-only, layered snapshot of a filesystem. Think of it as a blueprint or a template. It contains your OS base layer, installed packages, your application code, environment config — everything needed to run your app, frozen in time.

Images are built from a Dockerfile. Once built, they don't change. They're portable: the same image works on your laptop, your CI server, and your production box.

Dockerfile  →  (docker build)  →  Image

Docker Container

A container is a running (or stopped) instance of an image. If an image is a blueprint, a container is the actual building. You can spin up multiple containers from the same image — they all start from the same state but run independently.

Image  →  (docker run)  →  Container (running process with its own writable layer)

Containers are ephemeral by design. Restart one and it starts clean from the image again (unless you're using volumes for persistence).

The Core Idea: Build Locally, Deploy the Image

Instead of pulling source code onto your server and building there, you build the image on your development machine (or CI), export it, transfer it, and load it on the target server.

[Dev Machine]                     [Old Server]
docker build → image.tar   →   docker load → docker run

Method 1: `docker save` / `docker load` (Direct Transfer)

This is the most straightforward approach. No registry needed.

Step 1: Build the image locally

docker build -t myapp:latest .

Step 2: Save the image to a tar archive

docker save myapp:latest -o myapp.tar

If you want to save multiple images (e.g., your app + a sidecar):

docker save myapp:latest nginx:alpine -o bundle.tar

Step 3: Compress it (optional but recommended)

Docker images can be large. Gzip cuts the size significantly:

gzip myapp.tar
# or in one step:
docker save myapp:latest | gzip > myapp.tar.gz

Step 4: Transfer to the server

scp myapp.tar.gz user@your-server:/home/user/
# or with rsync for resumable transfers:
rsync -avz --progress myapp.tar.gz user@your-server:/home/user/

Step 5: Load the image on the server

ssh user@your-server
gunzip -c myapp.tar.gz | docker load
# or if it's not compressed:
docker load -i myapp.tar

Step 6: Run it

docker run -d --name myapp -p 8000:8000 myapp:latest
# or with compose, if your compose file references the image name:
docker compose up -d

Method 2: Tag and Push to a Registry

If you're doing this repeatedly, a private Docker registry is cleaner than manually moving tarballs around.

Option A: Docker Hub (simplest)

docker tag myapp:latest yourusername/myapp:latest
docker push yourusername/myapp:latest

On the server:

docker pull yourusername/myapp:latest
docker compose up -d

Option B: Self-hosted Registry

If your server has a registry running (or you want to spin one up):

# On the registry host:
docker run -d -p 5000:5000 --name registry registry:2

# On dev machine:
docker tag myapp:latest your-registry-host:5000/myapp:latest
docker push your-registry-host:5000/myapp:latest

# On the target server:
docker pull your-registry-host:5000/myapp:latest

Option C: GitHub Container Registry (ghcr.io)

A solid free option for private images, especially if you're already on GitHub:

echo $GITHUB_TOKEN | docker login ghcr.io -u USERNAME --password-stdin
docker tag myapp:latest ghcr.io/your-org/myapp:latest
docker push ghcr.io/your-org/myapp:latest

Tips for Working with Slow Servers

Use .dockerignore — Exclude node_modules, .git, __pycache__, test files, etc. from your build context. Even if you're building locally, a leaner context means smaller images to transfer.

# .dockerignore
.git
node_modules
__pycache__
*.pyc
.env

Tag your images meaningfully — Don't rely only on latest. Tag with a git commit hash or version:

docker build -t myapp:$(git rev-parse --short HEAD) .
docker tag myapp:$(git rev-parse --short HEAD) myapp:latest

This lets you roll back instantly without rebuilding — just docker run the previous tag.

Take advantage of layer caching — When building locally, structure your Dockerfile so dependencies (the slow part) come before application code (the fast part). This way, most layers are already cached:

# Install deps first — cached unless requirements change
COPY requirements.txt .
RUN pip install -r requirements.txt

# Then copy app code — invalidates cache here, but that's fast
COPY . .

Use --compress with docker save alternatives — If your server connection is very slow, consider zstd instead of gzip for faster compression at similar ratios:

docker save myapp:latest | zstd -T0 > myapp.tar.zst
# Transfer...
zstd -d myapp.tar.zst --stdout | docker load

Putting It All Together: A Simple Deploy Script

Here's a shell script that wraps the full local-build → transfer → reload workflow:

#!/bin/bash
set -e

IMAGE_NAME="myapp"
IMAGE_TAG=$(git rev-parse --short HEAD)
REMOTE_USER="user"
REMOTE_HOST="your-server"
REMOTE_PATH="/home/user"

echo "→ Building image..."
docker build -t $IMAGE_NAME:$IMAGE_TAG -t $IMAGE_NAME:latest .

echo "→ Exporting image..."
docker save $IMAGE_NAME:latest | gzip > /tmp/$IMAGE_NAME.tar.gz

echo "→ Transferring to server..."
rsync -avz --progress /tmp/$IMAGE_NAME.tar.gz $REMOTE_USER@$REMOTE_HOST:$REMOTE_PATH/

echo "→ Loading image on server..."
ssh $REMOTE_USER@$REMOTE_HOST "gunzip -c $REMOTE_PATH/$IMAGE_NAME.tar.gz | docker load"

echo "→ Restarting services..."
ssh $REMOTE_USER@$REMOTE_HOST "cd /your/app && docker compose up -d"

echo "✓ Done"

Summary

Concept	What it is
Build	The process of creating an image from a Dockerfile
Image	Immutable snapshot of your app environment — the blueprint
Container	A running instance of an image — the actual process

When your server is slow to build, stop building on it. Build the image where you have fast machines and good layer caches, then ship the artifact — not the source code. Whether you do this via docker save/load for simplicity or a private registry for repeatability, the principle is the same: separate the build step from the deploy step.

Your old server will thank you. Have you tried this, or do you have a better workflow? Let me know in the comments!

Bruno: The Git-Friendly API Client and How to Push Your Collection to Codeberg

Maksym — Tue, 02 Jun 2026 07:34:26 +0000

In the crowded landscape of API development tools, Bruno has emerged as a refreshing, developer-centric alternative to traditional clients like Postman or Insomnia. If you’re tired of bloated interfaces, cloud-only dependencies, and subscription paywalls, Bruno is designed specifically for you.

What is Bruno?

At its core, Bruno is an open-source, offline-first API client. Unlike many competitors that store your collection data in proprietary clouds or require accounts just to test endpoints, Bruno operates entirely on your local machine.

It stores API collections as a folder of standard text files (.bru files) directly in your project’s file system. This design means your API documentation and test collections live alongside your code, not in a siloed ecosystem.

Why Choose Bruno?

Offline-first privacy: Runs locally, giving you full control with no forced sync or accounts.
Git-friendly collaboration: Track changes, review pull requests, and view diffs with Git.
Minimalist performance: Fast, clean interface without heavy browser overhead.
Open format freedom: Human-readable .bru files make migration and parsing simple.

Step-by-Step: Push Your Bruno Collection to Codeberg

Because Bruno stores collections as files, versioning them with Git and hosting on Codeberg is straightforward.

Step 1: Create and Locate Your Collection

Open Bruno → Create Collection.
Choose a name and folder location.
To find an existing collection, right-click → Reveal in Finder (macOS) or Open in File Manager (Linux/Windows).

Step 2: Configure `.gitignore`

Before initializing Git, exclude sensitive data.

cd /path/to/your/bruno-collection
touch .gitignore

Add:

# Ignore Bruno local environment overrides and secrets
environments/*.bru

# Ignore local preferences and cache
.bruno/

Step 3: Initialize Git and Commit Locally

git init
git add .
git commit -m "feat: initial bruno collection setup"

Step 4: Create an Empty Repository on Codeberg

Log into Codeberg.
Click + → New Repository.
Name it (match your collection ideally).
Leave “Initialize Repository” unchecked.
Click Create Repository.

Step 5: Link and Push to Codeberg

git remote add origin https://codeberg.org/your-username/your-repo-name.git
git branch -M main
git push -u origin main

Best Practices for Bruno & Git

Keep secrets out: Never push .bru files with production credentials.
Commit frequently: Update API docs alongside development.
Use pull requests: Handle reviews and merges with Git workflows.

Python Logging Levels

Maksym — Mon, 18 May 2026 14:16:12 +0000

Python’s standard logging library uses a numeric severity system to filter log messages.

When you set a log level on a logger, you define a threshold: the logger will discard any message with a severity below this threshold and only process messages at or above it.

1. The 5 Standard Log Levels

Level	Numeric Value	When to Use It	Example Scenario
CRITICAL	50	Severe errors that halt a core process or crash the app. Requires immediate intervention.	Out of memory, database connection lost, disk full.
ERROR	40	Serious problems where the app failed to perform a specific function but can continue running.	External API request timed out, file write failed.
WARNING	30	Default Level. Indicates something unexpected happened, or a potential problem is imminent.	Low disk space, deprecated library usage, bad login attempt.
INFO	20	General operational events confirming that things are working as expected.	"Successfully connected to database", "Kafka consumer started".
DEBUG	10	Detailed diagnostic information, useful during local development and troubleshooting.	"Query returned 4 rows", "Received payload: {...}".
NOTSET	0	Default for non-root loggers. Inherits the level from its parent logger.	Directs child loggers to rely on parent configuration.

2. How Level Filtering Works

When a log message is generated, Python compares its numeric value against the active logger's threshold:

Message Level (e.g., INFO = 20) >= Logger Threshold (e.g., WARNING = 30)?

20 >= 30  ---> FALSE (Log is silently discarded)
40 >= 30  ---> TRUE  (Log is processed and printed)

3. Self-Contained Code Example

import logging

# Configure root logger to output INFO (20) and above
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

# This will NOT print (DEBUG 10 < INFO 20)
logger.debug("Parsing payload dictionary...") 

# This WILL print (INFO 20 >= INFO 20)
logger.info("Successfully connected to the database.")

# This WILL print (ERROR 40 >= INFO 20)
logger.error("Failed to fetch profiles from downstream service.")

4. The Hierarchy Gotcha: Level Inheritance

By default, the Root logger is initialized to WARNING (30).

Non-root (named) loggers inherit their level from their closest ancestor that has an explicit level set.

The Silent Log Trap:

import logging

# 1. No global config is set (Root defaults to WARNING)
logger = logging.getLogger("app.database")

# 2. You try to log an INFO message
logger.info("Connecting...")  # NOTHING PRINTS!

5. Best Practice: Dynamic Environment Configuration

In containerized microservices (e.g., Docker, Kubernetes), you should never hardcode log levels.

Instead, read the level dynamically from an environment variable with a safe default.

import os
import logging

# 1. Fetch level from env variable, default to 'INFO' if not set
env_level = os.getenv("LOG_LEVEL", "INFO").upper()

# 2. Convert string level to numeric value safely
numeric_level = getattr(logging, env_level, logging.INFO)

# 3. Configure the Root baseline
logging.basicConfig(
    level=numeric_level,
    format="%(asctime)s - %(name)s - %(levelname)s - %(message)s"
)

logger = logging.getLogger("app.service")
logger.info(f"Logger initialized with level: {env_level}")

6. Environment Recommendations

Development (DEBUG):

Set LOG_LEVEL=DEBUG. Helps trace raw incoming database queries, inspect message payloads, and track API states.
Production (INFO or WARNING):

Set LOG_LEVEL=INFO. High-frequency DEBUG logging writes massive amounts of data to stdout, which can:
- Exhaust server disk space
- Overwhelm aggregation engines (Elasticsearch, Grafana Loki, Splunk)
- Degrade application I/O performance

Managing virtual environments in Python

Maksym — Fri, 24 Apr 2026 11:26:57 +0000

Managing Python versions and dependencies often feels like an "alphabet soup" of tools. Here is how to organize pyenv, pyenv-virtualenv, and pipenv without them clashing.

The Toolset

Pyenv → Manages Python Versions. It lets you switch between Python 3.8, 3.11, or 3.12 globally or per folder.
Pyenv-virtualenv → An extension for Pyenv that manages Named Virtual Environments.
Pipenv → A Higher-level Manager. It handles both the virtual environment and package dependencies using a Pipfile (replacing requirements.txt).

Recommended Workflows

Option 1: The "Manual" Approach (Pyenv + Pyenv-Virtualenv)

Best for: Quick scripts, simple tools, or developers who prefer full control over pip.

Install Python: pyenv install 3.11.5
Create Environment: pyenv virtualenv 3.11.5 my-project-env
Local Link: pyenv local my-project-env
- Result: Every time you enter this folder, your terminal automatically switches to my-project-env.
Manage Deps: Use pip install and manually maintain a requirements.txt.

Option 2: The "Modern" Approach (Pyenv + Pipenv)

Best for: Production applications and collaborative projects where dependency locking is vital.

Install Python: pyenv install 3.11.5
Initialize Pipenv: pipenv install --python 3.11.5
- Note: You do not need to run pyenv local first. Pipenv will communicate with Pyenv to find the correct version.
Activate: pipenv shell
Manage Deps: Use pipenv install <package>. This automatically updates your Pipfile and Pipfile.lock.

Critical Disclaimers

[!CAUTION]
Avoid "Nesting" Environments: Never run pipenv install while a pyenv-virtualenv is already active. This can cause Pipenv to install packages into the wrong environment or create a "ghost" environment that is difficult to debug. Pick one manager per project.

[!IMPORTANT]
Storage Locations: > * pyenv-virtualenv stores environments in ~/.pyenv/versions/.

pipenv stores them in a hidden central folder (usually ~/.local/share/virtualenvs/).

Pro Tip: To keep Pipenv environments inside your project folder (like .venv), set export PIPENV_VENV_IN_PROJECT=1 in your shell profile.

Comparison at a Glance

Feature	Pyenv-Virtualenv	Pipenv
Primary Goal	Isolation	Dependency Management
Tracking	None (Manual `requirements.txt`)	Deterministic (`Pipfile.lock`)
Activation	Automatic via `.python-version`	Manual via `pipenv shell`
Complexity	Low	Medium

Final Rule of Thumb

Use Pyenv + Pipenv if you need a "lockfile" to ensure your teammates have the exact same package versions as you.
Use Pyenv + Pyenv-Virtualenv if you just want a clean, isolated sandbox for a project and don't care about strict version locking.

Hopefully, this article helps someone avoid making the same mistakes I did. If you like it or hate it, leave a comment. Got anything to add? Be my guest. Keep your opinion to yourself. Later, skater.

Your Terminal Deserves Better. Oh My Zsh Agrees.

Maksym — Thu, 02 Apr 2026 05:08:17 +0000

You wouldn't write code in Notepad. So why are you still using a bare-bones shell? Oh My Zsh transforms your terminal from a blinking cursor into a genuinely productive environment -- one that autocompletes intelligently, surfaces git context at a glance, and makes you wonder how you ever lived without it.

If you caught the earlier piece on Fish shell, welcome back. Fish is opinionated and batteries-included by design. Zsh with Oh My Zsh takes a different approach: more configurable, a deeper ecosystem, and fully POSIX-compatible. Two great shells, two different philosophies. This is the other side of the coin.

What is Oh My Zsh?

Oh My Zsh is an open-source, community-driven framework for managing your Zsh configuration. It was born in 2009 from a single developer's frustration with their .zshrc. Today it ships with over 300 plugins and 150 themes, maintained by a community that has been iterating on shell ergonomics for fifteen years.

Think of it as a package manager for your shell personality. One install unlocks tab completion that actually works, inline git status in your prompt, syntax highlighting as you type, autosuggestions from history, and enough theme options to lose an afternoon.

Installation

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

That is it. The installer backs up your existing .zshrc, installs Oh My Zsh, and drops you into a configured shell. No manual setup required.

Plugins worth enabling

Plugins are activated by editing the plugins array in your ~/.zshrc:

plugins=(git z docker zsh-autosuggestions zsh-syntax-highlighting)

Restart your shell (or run source ~/.zshrc) and the changes take effect immediately.

git

The most-used plugin. Provides over 50 aliases for common operations:

Alias	Expands to
`gst`	`git status`
`gco`	`git checkout`
`glog`	`git log --oneline --decorate --graph`
`gp`	`git push`
`gl`	`git pull`

Type alias | grep "^g" in your shell after enabling to see the full list.

z

Tracks the directories you visit and lets you jump to any of them by typing a fragment of the path. No more cd ../../projects/client-name/repo -- just z repo.

z proj      # jumps to ~/code/projects
z dot       # jumps to ~/.dotfiles

zsh-autosuggestions

Displays ghost-text suggestions based on your command history as you type. Press the right arrow key to accept a suggestion. This one plugin alone eliminates a large fraction of keystrokes in a typical session.

git clone https://github.com/zsh-users/zsh-autosuggestions \
  ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

zsh-syntax-highlighting

Colors your command as you type it. Valid commands appear in green. Unrecognized commands and typos appear in red -- before you press Enter, so you catch mistakes immediately.

git clone https://github.com/zsh-users/zsh-syntax-highlighting \
  ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

Both zsh-autosuggestions and zsh-syntax-highlighting require a manual clone step because they are third-party plugins not bundled with Oh My Zsh.

Themes

The active theme is set with a single line in ~/.zshrc:

ZSH_THEME="robbyrussell"

The default theme (robbyrussell) is clean and fast. It shows your current directory and git branch, nothing more. For most setups it is a sensible starting point.

If you want more information density in your prompt, the community has converged on Powerlevel10k as the gold standard.

Powerlevel10k

Powerlevel10k renders asynchronously, meaning your prompt stays responsive even when git or other tools are slow to respond. It surfaces git status, last exit code, command execution time, current time, and more -- all configurable through an interactive setup wizard.

# Install
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git \
  ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

# Activate in ~/.zshrc
ZSH_THEME="powerlevel10k/powerlevel10k"

The first time you open a new shell after enabling it, the configuration wizard launches automatically. It walks you through a series of visual tests and preference questions, then writes a ~/.p10k.zsh file. The whole process takes about five minutes.

Zsh vs Fish

Since Fish shell was covered in a previous piece, it is worth stating plainly: both are excellent tools, and the right choice depends on what you value.

Fish gives you smart features -- autosuggestions, syntax highlighting, web-based config -- out of the box with near-zero configuration. It is opinionated by design and works well as a result.

Zsh with Oh My Zsh is a different trade-off. It requires a little more initial setup, but gives you a deeper plugin ecosystem, full POSIX compatibility (meaning shell scripts written for bash will generally work), and a community that has been accumulating tooling for over a decade.

Many developers install both and choose based on the machine or context. There is no wrong answer.

A starter `~/.zshrc`

export ZSH="$HOME/.oh-my-zsh"

ZSH_THEME="powerlevel10k/powerlevel10k"

plugins=(
  git
  z
  docker
  zsh-autosuggestions
  zsh-syntax-highlighting
)

source $ZSH/oh-my-zsh.sh

# Personal aliases
alias ll="ls -lAh"
alias gs="git status"
alias reload="source ~/.zshrc"

After saving, run source ~/.zshrc to apply the changes without opening a new terminal window.

Where to go from here

The official plugin list lives at ~/.oh-my-zsh/plugins/ -- browse the folder to see what is available without any additional installs. For third-party plugins, the Awesome Zsh Plugins repository is a well-maintained directory.

Oh My Zsh is not magic. It is fifteen years of collective developer frustration turned into very good defaults. Install it once, spend an hour making it yours, and you will not look at a stock terminal the same way again.

Pause, Save, Resume: The Definitive Guide to Stashing

Maksym — Wed, 01 Apr 2026 07:06:08 +0000

Git stash is one of those commands that feels minor until the day you desperately need it — and then it becomes indispensable. It lets you temporarily shelve changes you've made to your working directory so you can switch context, pull updates, or work on something else, then come back and reapply those changes later.

What is Git Stash?

When you stash your work, Git takes all your uncommitted changes (both staged and unstaged) and saves them onto a stack of unfinished changes that you can reapply at any time. Your working directory is then cleaned up to match the HEAD commit.

Think of it like putting your work in a drawer so you can clean your desk — the work isn't gone, it's just tucked away.

Basic Usage

Stashing your changes

git stash

This stashes all tracked, modified files. Your working directory reverts to a clean state.

Stashing with a descriptive message

git stash push -m "WIP: refactoring auth middleware"

Always recommended. When you have multiple stashes, messages make it easy to identify which stash contains what.

Including untracked files

By default, git stash ignores untracked (new) files. Use -u to include them:

git stash push -u -m "feature work including new files"

To also include ignored files (e.g. .env overrides), use -a:

git stash push -a -m "everything including ignored files"

Viewing Your Stashes

git stash list

Output looks like this:

stash@{0}: On main: WIP: refactoring auth middleware
stash@{1}: On feature/login: half-done login form
stash@{2}: WIP on main: 3f1abc2 fix typo in readme

Stashes are indexed from 0 (most recent) upward. The index is important for targeting specific stashes.

Applying Stashes

Apply the most recent stash (keep it in the stash list)

git stash apply

Apply and remove from the stash list

git stash pop

pop is shorthand for apply + drop. Use it when you're done with the stash and don't need it anymore.

Apply a specific stash by index

git stash apply stash@{2}
git stash pop stash@{1}

Apply to a different branch

You can apply a stash to any branch — just switch to it first:

git checkout feature/new-branch
git stash pop

Inspecting a Stash

Before applying, you might want to see what's inside a stash:

# Summary of changed files
git stash show stash@{0}

# Full diff
git stash show -p stash@{0}

Deleting Stashes

Drop a specific stash

git stash drop stash@{1}

Clear all stashes

git stash clear

Warning: git stash clear is irreversible. All stashes are permanently deleted.

Creating a Branch from a Stash

If your stashed changes have grown into something bigger, you can create a new branch directly from the stash:

git stash branch feature/new-feature stash@{0}

This creates and checks out a new branch, applies the stash to it, and drops the stash if the apply succeeds. Very handy when you realize mid-stash that your changes deserve their own branch.

Partial Stashing

You can stash only specific files instead of everything:

git stash push -m "only stashing config changes" -- config/settings.py

Or stash changes interactively (patch by patch, like git add -p):

git stash push -p

Git will walk you through each hunk and ask whether to stash it.

Handling Conflicts

If applying a stash causes a merge conflict, Git will mark the conflicts in the affected files — just like a regular merge. Resolve them manually, then stage the resolved files:

git add path/to/resolved-file.py

Note: when conflicts occur during git stash pop, the stash is not automatically dropped. You'll need to drop it manually once you're done:

git stash drop stash@{0}

Quick Reference

Command	Description
`git stash`	Stash tracked changes
`git stash push -u -m "msg"`	Stash including untracked files with a message
`git stash list`	List all stashes
`git stash show -p stash@{n}`	Show full diff of a stash
`git stash apply stash@{n}`	Apply a stash (keep in list)
`git stash pop`	Apply most recent stash and remove it
`git stash drop stash@{n}`	Delete a specific stash
`git stash clear`	Delete all stashes
`git stash branch <name>`	Create a branch from a stash
`git stash push -p`	Interactive/partial stash

Tips and Gotchas

Stashes are local. They don't get pushed to a remote repository. Don't rely on them for backup or sharing work.
Don't let stashes pile up. It's easy to forget what's in old stashes. Treat them as short-lived temporary storage, not a long-term holding area.
Staged vs unstaged state is preserved. When you apply a stash, files that were staged before stashing will still be staged — unless you use git stash apply --index to explicitly restore that state.
Name your stashes. stash@{3}: WIP on main: 9b2f1a0 update readme tells you very little compared to stash@{3}: On main: WIP: OAuth token refresh logic.

Exploring Lua: The Invisible Powerhouse of Scripting

Maksym — Fri, 27 Mar 2026 06:59:52 +0000

If you’ve played Roblox, adjusted a UI mod in World of Warcraft, or used a high-performance web server like NGINX, you’ve encountered Lua. Developed in 1993 at the Pontifical Catholic University of Rio de Janeiro, Lua (Portuguese for "Moon") was designed as a lightweight, embeddable scripting language.

Today, it remains one of the fastest and most efficient tools in a developer's kit.

1. Why Developers Love Lua

Lua isn't usually the "main" language of an application; instead, it acts as the glue. Here is why it excels in that role:

Speed: Lua is consistently ranked among the fastest interpreted languages. When using LuaJIT (Just-In-Time compiler), its performance can rival compiled languages like C in certain tasks.
Portability: The entire Lua interpreter is written in ANSI C. This means it can run on everything from a high-end PC to a tiny microwave oven's microcontroller.
Small Footprint: A compiled Lua interpreter is roughly 200–300 KB. It doesn't bloat the software it lives inside.
Simple Syntax: It’s easy to read and learn. If you know the basics of programming, you can become productive in Lua in a single afternoon.

2. The "Everything is a Table" Philosophy

The most unique feature of Lua is its data structure. Unlike other languages that have arrays, lists, dictionaries, and objects, Lua has only one: the Table.

Tables are associative arrays that can be indexed with numbers, strings, or even other tables. This single structure is used to represent:

Arrays: myList = {10, 20, 30} (Note: Lua uses 1-based indexing!)
Dictionaries: myData = {name = "Gemini", type = "AI"}
Objects: By using "metatables," Lua can simulate complex Object-Oriented Programming (OOP) behaviors like inheritance.

3. Real-World Applications

Lua thrives where performance and customization meet.

Game Development

This is Lua's home turf. Engines like LÖVE use Lua for everything, while massive engines like CryEngine and Leadwerks use it for game logic. It allows designers to change how a weapon behaves or how an NPC moves without needing to recompile the entire game engine.

Embedded Systems

Because it’s so light, Lua is a favorite for the "Internet of Things" (IoT). Devices with limited memory use Lua to handle logic while the heavy lifting stays in C.

Neovim and Productivity

The developer community has seen a massive shift toward Lua lately, specifically with the text editor Neovim. Users now write their entire editor configurations in Lua because it's significantly faster and more powerful than the older VimScript.

4. A Quick Code Example

Here is what a basic function looks like in Lua:

-- Define a function to greet a user
local function celebrate(name)
    print("Hello, " .. name .. "!")

    for i = 1, 3 do
        print("Blast off in " .. (4 - i))
    end

    print("Lua is ready!")
end

celebrate("Developer")

Summary

Lua is the "silent partner" of the programming world. You might not use it to build an operating system, but if you need to add a flexible, fast, and lightweight scripting layer to a project, there is rarely a better choice.

Wazuh: Centralized Logging with Error Notifications

Maksym — Wed, 04 Mar 2026 07:51:15 +0000

Introduction

Wazuh is an open-source security and monitoring platform that provides intrusion detection, log management, vulnerability detection, and incident response. It centralizes logs from diverse systems and applications, analyzes them in real time, and notifies teams when errors or suspicious activity occur. By combining log collection, rule-based detection, and alerting, Wazuh helps organizations improve visibility, security, and operational efficiency.

Centralized Logging

Wazuh agents collect logs from endpoints and forward them to the Wazuh manager, where they are aggregated and indexed (often in Elasticsearch). This allows administrators to monitor all system activity from a single location.

Configuration Example (multiple files):

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/syslog</location>
</localfile>

<localfile>
  <log_format>apache</log_format>
  <location>/var/log/apache2/error.log</location>
</localfile>

<localfile>
  <log_format>json</log_format>
  <location>/var/log/myapp/app.log</location>
</localfile>

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/auth.log</location>
</localfile>

Handling Unknown or Dynamic Files

If you don’t know the exact file names in advance (e.g., rotating logs or dynamically generated files), Wazuh supports wildcards and directories:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/*.log</location>
</localfile>

<localfile>
  <log_format>apache</log_format>
  <location>/var/log/apache2/*.log</location>
</localfile>

<localfile>
  <log_format>json</log_format>
  <location>/var/log/myapp/*.json</location>
</localfile>

This ensures that any new log file matching the pattern is automatically monitored.

Error Detection Rules

Logs are analyzed against rules to detect anomalies and errors. Wazuh’s ruleset can be customized to match specific error patterns.

Example: Apache error detection

<rule id="100100" level="5">
  <decoded_as>apache_error</decoded_as>
  <description>Apache server error detected</description>
  <group>apache,errors</group>
  <match>Internal Server Error</match>
</rule>

Generic error rule (for unknown files):

<rule id="100300" level="6">
  <description>Generic error detected in logs</description>
  <group>errors</group>
  <match>ERROR|FAIL|CRITICAL</match>
</rule>

Notifications

Wazuh can notify teams via email, Slack, or other platforms. For example:

Email notification setup:

<global>
  <email_notification>yes</email_notification>
  <email_to>ops-team@example.com</email_to>
  <smtp_server>mail.example.com</smtp_server>
</global>

Telegram Integration Example

Telegram is not built-in, but you can integrate it using a custom script in Wazuh’s integrations/ folder.

Python script (telegram.py):

#!/usr/bin/env python3
import sys
import json
import requests

# Replace with your bot token and chat_id
BOT_TOKEN = "123456789:ABC-DEF1234ghIkl-zyx57W2v1u123ew11"
CHAT_ID = "-1001234567890"  # group/channel ID or user ID

TELEGRAM_API_URL = f"https://api.telegram.org/bot{BOT_TOKEN}/sendMessage"

def send_telegram_message(message):
    payload = {
        "chat_id": CHAT_ID,
        "text": message,
        "parse_mode": "Markdown"
    }
    try:
        response = requests.post(TELEGRAM_API_URL, json=payload)
        if response.status_code != 200:
            print(f"Error sending message: {response.text}")
    except Exception as e:
        print(f"Exception: {e}")

def main():
    # Wazuh passes alert data to the script via stdin
    alert_json = sys.stdin.read()
    try:
        alert = json.loads(alert_json)
        # Customize the message format
        message = f"*Wazuh Alert*\n\nRule: {alert.get('rule', {}).get('description', 'N/A')}\nLevel: {alert.get('rule', {}).get('level', 'N/A')}\nAgent: {alert.get('agent', {}).get('name', 'N/A')}\nLog: {alert.get('full_log', 'N/A')}"
        send_telegram_message(message)
    except Exception as e:
        print(f"Failed to parse alert: {e}")

if __name__ == "__main__":
    main()

Integration block in ossec.conf:

<integration>
  <name>telegram</name>
  <script>telegram.py</script>
  <alert_format>json</alert_format>
</integration>

Example Workflow

Wazuh agent monitors /var/log/*.log, /var/log/apache2/*.log, and /var/log/myapp/*.json.
A new file error-2026-03-04.log appears with the string CRITICAL.
The generic rule matches it.
Wazuh raises an alert with severity level 6.
The telegram.py script sends the alert to your Telegram group.
Notification appears instantly in Telegram, allowing the team to respond.

Benefits

Centralized visibility: All logs collected in one place.
Real-time detection: Errors and anomalies caught instantly.
Automated notifications: Teams are alerted via email, Slack, or Telegram.
Scalability: Works across thousands of endpoints with clustering.
Flexibility: Wildcards and generic rules handle unknown or dynamic log files.

With this setup, Wazuh becomes a powerful centralized logger with error notifications, capable of sending alerts to multiple platforms — including Telegram — ensuring your team never misses critical issues.

Hopefully you find this article helpful. As always don't hesitate to like, share, leave a comment and if you find any inconvenience please let me know. Cheers

Golden Rule: Composition Over Inheritance

Maksym — Tue, 10 Feb 2026 14:53:04 +0000

A practical guide to writing flexible, maintainable code

Introduction

Every object-oriented developer eventually faces the same dilemma: two classes share some behaviour, and the natural instinct is to create a parent class and have them both inherit from it. It feels clean. It feels right. But more often than not, a few months down the road, that hierarchy starts to crack under the weight of new requirements.

This article explores why favour composition over inheritance — one of the most important principles in software design — what it means in practice, and how to apply it in your everyday code.

What Is Inheritance?

Inheritance is a mechanism where one class (the child or subclass) derives behaviour and state from another class (the parent or superclass). The child extends the parent, inheriting its methods and fields, and can override or add to them.

A classic textbook example:

class Animal:
    def speak(self):
        raise NotImplementedError

class Dog(Animal):
    def speak(self):
        return "Woof!"

class Cat(Animal):
    def speak(self):
        return "Meow!"

This looks perfectly fine. And for simple taxonomies, it often is. The problem appears when real-world requirements stop behaving like a tidy class diagram.

The Problems with Deep Hierarchies

The Fragile Base Class Problem

When you change a base class, you risk breaking every subclass. Because subclasses depend on the internal implementation of the parent — not just its public interface — even a small refactor can have cascading, unexpected side effects.

The Gorilla–Banana Problem

"You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." — Joe Armstrong

Inheritance forces you to take everything the parent offers, whether you need it or not. If a subclass only needs one method from a parent that has twenty, it still inherits all the state and behaviour — along with all the associated complexity and risk.

The Diamond Problem

What happens when a class needs to inherit behaviour from two different parents that both define the same method? Most languages either forbid this entirely or introduce complicated resolution rules. It is a symptom of a deeper design flaw.

Violation of Encapsulation

Subclasses are intimately coupled to their parents. They often need to know about protected internals, call super() in the right order, and respect implicit contracts that are never written down. This tight coupling makes code hard to understand and refactor independently.

What Is Composition?

Composition means building complex behaviour by combining simpler, focused objects — rather than by extending a class hierarchy. Instead of asking "what is this object?", you ask "what does this object do?"

Where inheritance models an is-a relationship, composition models a has-a relationship.

Approach	Relationship	Example
Inheritance	is-a	`Dog` is an `Animal`
Composition	has-a	`Robot` has a `Speaker`

A Side-by-Side Comparison

Imagine you are building a game with different types of characters. Some can fly, some can swim, some can fight — and some can do combinations of all three.

The Inheritance Approach (and its problems)

class Character:
    pass

class FlyingCharacter(Character):
    def fly(self): ...

class SwimmingCharacter(Character):
    def swim(self): ...

# What about a character that can BOTH fly and swim?
# Most languages won't allow this cleanly.
class FlyingSwimmingCharacter(FlyingCharacter, SwimmingCharacter):
    pass  # Multiple inheritance — this gets messy fast

Every new combination of abilities requires a new class. The hierarchy explodes in complexity.

The Composition Approach

class FlyBehaviour:
    def fly(self):
        print("Soaring through the sky!")

class SwimBehaviour:
    def swim(self):
        print("Gliding through the water!")

class FightBehaviour:
    def fight(self):
        print("Attacking!")

class Character:
    def __init__(self, behaviours):
        self.behaviours = behaviours

    def perform(self, action):
        behaviour = self.behaviours.get(action)
        if behaviour:
            getattr(behaviour, action)()

# Build any combination at will
hero = Character({
    "fly":   FlyBehaviour(),
    "swim":  SwimBehaviour(),
    "fight": FightBehaviour(),
})

hero.perform("fly")   # Soaring through the sky!
hero.perform("swim")  # Gliding through the water!

Adding a new ability now means writing one new class — not reshaping the entire hierarchy.

Composition in the Real World

Strategy Pattern

The Strategy pattern is composition in its most recognisable form. You define a family of algorithms, encapsulate each one, and make them interchangeable.

class JSONSerializer:
    def serialize(self, data):
        import json
        return json.dumps(data)

class XMLSerializer:
    def serialize(self, data):
        # ... XML serialization logic
        return f"<data>{data}</data>"

class DataExporter:
    def __init__(self, serializer):
        self.serializer = serializer  # composed, not inherited

    def export(self, data):
        return self.serializer.serialize(data)

exporter = DataExporter(JSONSerializer())
exporter.export({"name": "Alice"})

# Swap the strategy without touching DataExporter
exporter.serializer = XMLSerializer()
exporter.export({"name": "Alice"})

Dependency Injection

Dependency injection is composition by another name. Rather than a class constructing its own dependencies (or inheriting them), they are passed in from the outside. This keeps classes loosely coupled and trivially testable.

class EmailNotifier:
    def notify(self, message):
        print(f"Sending email: {message}")

class SMSNotifier:
    def notify(self, message):
        print(f"Sending SMS: {message}")

class OrderService:
    def __init__(self, notifier):
        self.notifier = notifier  # injected dependency

    def place_order(self, order):
        # ... process order
        self.notifier.notify(f"Order {order.id} confirmed.")

# In tests, swap for a mock — no subclassing needed
service = OrderService(EmailNotifier())

When Is Inheritance Actually Appropriate?

Composition over inheritance does not mean never use inheritance. Inheritance is a valid and useful tool when the relationship genuinely satisfies all of the following:

The is-a relationship is stable and true across all use cases — Square is a Shape, HTTPException is an Exception.
You want to share a genuine, semantic contract, not just re-use some code.
The hierarchy is shallow — ideally no more than two levels deep.
You are extending a framework or library that is specifically designed to be subclassed (e.g. Django's View classes, Python's unittest.TestCase).

A useful heuristic: if you would feel awkward saying "X is a kind of Y" out loud to a non-programmer, reach for composition instead.

The Liskov Substitution Principle

The Liskov Substitution Principle (LSP) — the L in SOLID — states that objects of a subclass should be substitutable for objects of their superclass without altering the correctness of the program.

The classic violation:

class Rectangle:
    def set_width(self, w): self.width = w
    def set_height(self, h): self.height = h
    def area(self): return self.width * self.height

class Square(Rectangle):
    def set_width(self, w):
        self.width = w
        self.height = w  # A square must keep sides equal

    def set_height(self, h):
        self.width = h   # This breaks Rectangle's contract!
        self.height = h

A Square seems like it should be a Rectangle, but the subclass breaks the parent's behavioural contract. Any code that relies on being able to set width and height independently will malfunction when handed a Square.

If your inheritance violates LSP, it is a strong signal that you need composition instead.

Summary

	Inheritance	Composition
Relationship	is-a	has-a
Coupling	Tight (shares internals)	Loose (uses interface)
Flexibility	Low (hierarchy is fixed)	High (swap behaviours at runtime)
Reuse unit	Entire class	Individual behaviours
Testability	Harder (must instantiate hierarchy)	Easier (inject mocks)
Risk of change	High (fragile base class)	Low (changes are localised)

Inheritance is a powerful tool, but it is one that is easy to misuse. The moment you find yourself creating a subclass primarily to re-use some code — rather than to express a genuine taxonomic relationship — it is time to reach for composition.

Prefer composition. Build your objects from small, focused, interchangeable pieces. Your future self, and everyone else who reads the code, will thank you.

JavaScript vs Go: A Deep Dive into Syntax and Philosophy

Maksym — Sat, 27 Dec 2025 18:33:04 +0000

As developers, we often find ourselves jumping between languages, and the syntax differences can be jarring. JavaScript and Go represent two very different philosophies in programming language design. JavaScript evolved from a browser scripting language into a full-stack powerhouse, while Go was designed from scratch by Google to solve modern distributed systems problems.

Let's explore how these languages handle common programming tasks and what these differences reveal about their design philosophies.

Variable Declaration and Type Systems
Functions and Their Flavors
Error Handling: Exceptions vs Explicit Errors
Asynchronous Programming and Concurrency
Data Structures: Objects vs Structs
Control Flow and Conditionals
Loops and Iteration
Interfaces and Polymorphism
Package Management and Modules
Philosophy and Real-World Implications

1. Variable Declaration and Type Systems

JavaScript: Dynamic and Flexible

JavaScript's type system is dynamic—variables can hold any type of value and change types at runtime:

// Multiple ways to declare variables
let username = "Mephesto";        // Block-scoped, reassignable
const MAX_RETRIES = 3;            // Block-scoped, immutable binding
var legacy = "avoid this";        // Function-scoped (pre-ES6)

// Dynamic typing
let data = 42;                    // number
data = "now I'm a string";        // totally fine
data = { key: "value" };          // also fine
data = [1, 2, 3];                 // no problem

// Type coercion happens implicitly
console.log("5" + 5);             // "55" (string)
console.log("5" - 5);             // 0 (number)
console.log(true + 1);            // 2

Go: Explicit and Type-Safe

Go is statically typed—every variable has a specific type that's checked at compile time:

package main

import "fmt"

func main() {
    // Explicit type declaration
    var username string = "Mephesto"
    var count int = 42
    var isActive bool = true

    // Type inference with :=
    message := "Go infers this is a string"
    port := 8080  // inferred as int

    // Constants
    const MaxRetries = 3
    const Pi = 3.14159

    // Multiple declarations
    var (
        host string = "localhost"
        timeout int = 30
    )

    // This would be a compile error:
    // count = "string"  // cannot use "string" as int

    // Zero values (no undefined!)
    var emptyString string  // ""
    var emptyInt int        // 0
    var emptyBool bool      // false
    var emptySlice []int    // nil
}

Key Differences:

JavaScript lets you reassign variables to different types; Go doesn't
Go has zero values (default initialization), JavaScript has undefined
Go's := short declaration is convenient but only works inside functions
JavaScript has three declaration keywords (var, let, const); Go primarily uses var and :=

2. Functions and Their Flavors

JavaScript: First-Class and Flexible

JavaScript treats functions as first-class citizens—they're just values that can be passed around:

// Traditional function declaration
function calculateTotal(price, quantity) {
    return price * quantity;
}

// Function expression
const calculateDiscount = function(price, rate) {
    return price * (1 - rate);
};

// Arrow function (ES6+)
const calculateTax = (price, taxRate) => price * taxRate;

// Arrow function with block body
const processOrder = (order) => {
    const total = order.price * order.quantity;
    const tax = total * 0.2;
    return { total, tax };
};

// Default parameters
function greet(name = "Guest", greeting = "Hello") {
    return `${greeting}, ${name}!`;
}

// Rest parameters
function sum(...numbers) {
    return numbers.reduce((acc, n) => acc + n, 0);
}

// Destructuring parameters
function createUser({ name, email, age = 18 }) {
    return { name, email, age, createdAt: new Date() };
}

// Higher-order functions
function withLogging(fn) {
    return function(...args) {
        console.log(`Calling with:`, args);
        const result = fn(...args);
        console.log(`Result:`, result);
        return result;
    };
}

const loggedSum = withLogging(sum);
loggedSum(1, 2, 3); // Logs inputs and output

Go: Typed and Structured

Go functions are more rigid but offer unique features like multiple return values:

package main

import (
    "errors"
    "fmt"
)

// Basic function with typed parameters and return
func calculateTotal(price float64, quantity int) float64 {
    return price * float64(quantity)
}

// Multiple return values (idiomatic for error handling)
func divide(a, b float64) (float64, error) {
    if b == 0 {
        return 0, errors.New("division by zero")
    }
    return a / b, nil
}

// Named return values
func calculateStats(numbers []int) (sum int, avg float64, count int) {
    count = len(numbers)
    for _, n := range numbers {
        sum += n
    }
    if count > 0 {
        avg = float64(sum) / float64(count)
    }
    return // naked return uses named values
}

// Variadic functions (like JavaScript's rest parameters)
func sum(numbers ...int) int {
    total := 0
    for _, n := range numbers {
        total += n
    }
    return total
}

// Functions as values
func applyOperation(a, b int, op func(int, int) int) int {
    return op(a, b)
}

// Closures
func counter() func() int {
    count := 0
    return func() int {
        count++
        return count
    }
}

// Methods (functions with receivers)
type Rectangle struct {
    Width  float64
    Height float64
}

func (r Rectangle) Area() float64 {
    return r.Width * r.Height
}

// Pointer receivers for mutation
func (r *Rectangle) Scale(factor float64) {
    r.Width *= factor
    r.Height *= factor
}

func main() {
    // Using multiple return values
    result, err := divide(10, 2)
    if err != nil {
        fmt.Println("Error:", err)
        return
    }
    fmt.Println("Result:", result)

    // Variadic function
    total := sum(1, 2, 3, 4, 5)

    // Function as value
    multiply := func(a, b int) int { return a * b }
    result = applyOperation(5, 3, multiply)
}

Key Differences:

Go requires explicit types for all parameters and return values
Go's multiple return values eliminate the need for objects/tuples in many cases
JavaScript has more syntactic sugar (arrow functions, default params, destructuring)
Go's receiver functions replace JavaScript's method syntax
Both support closures and first-class functions, but Go's are more verbose

3. Error Handling: Exceptions vs Explicit Errors

This is where the philosophies diverge most dramatically.

JavaScript: Try-Catch Exceptions

JavaScript uses exceptions that can bubble up the call stack:

// Traditional try-catch
function readConfig(filename) {
    try {
        const data = fs.readFileSync(filename, 'utf8');
        return JSON.parse(data);
    } catch (error) {
        console.error(`Failed to read config: ${error.message}`);
        throw error; // Re-throw or handle
    } finally {
        console.log('Cleanup code runs regardless');
    }
}

// Async error handling with promises
async function fetchUserData(userId) {
    try {
        const response = await fetch(`/api/users/${userId}`);

        if (!response.ok) {
            throw new Error(`HTTP ${response.status}: ${response.statusText}`);
        }

        const data = await response.json();
        return data;
    } catch (error) {
        if (error.name === 'NetworkError') {
            console.error('Network error:', error);
        } else if (error.name === 'SyntaxError') {
            console.error('Invalid JSON:', error);
        } else {
            console.error('Unknown error:', error);
        }
        throw error;
    }
}

// Promise-based error handling
fetchUserData(123)
    .then(user => console.log(user))
    .catch(error => console.error(error))
    .finally(() => console.log('Done'));

// Custom error types
class ValidationError extends Error {
    constructor(field, message) {
        super(message);
        this.name = 'ValidationError';
        this.field = field;
    }
}

function validateUser(user) {
    if (!user.email) {
        throw new ValidationError('email', 'Email is required');
    }
    if (user.age < 0) {
        throw new ValidationError('age', 'Age must be positive');
    }
}

Go: Explicit Error Values

Go treats errors as values that must be explicitly checked:

package main

import (
    "encoding/json"
    "errors"
    "fmt"
    "os"
)

// Errors are just values
func readConfig(filename string) (map[string]interface{}, error) {
    data, err := os.ReadFile(filename)
    if err != nil {
        return nil, fmt.Errorf("failed to read config: %w", err)
    }

    var config map[string]interface{}
    if err := json.Unmarshal(data, &config); err != nil {
        return nil, fmt.Errorf("failed to parse JSON: %w", err)
    }

    return config, nil
}

// Multiple error checking
func processUser(userID int) error {
    user, err := fetchUser(userID)
    if err != nil {
        return fmt.Errorf("fetch failed: %w", err)
    }

    if err := validateUser(user); err != nil {
        return fmt.Errorf("validation failed: %w", err)
    }

    if err := saveUser(user); err != nil {
        return fmt.Errorf("save failed: %w", err)
    }

    return nil
}

// Custom error types
type ValidationError struct {
    Field   string
    Message string
}

func (e *ValidationError) Error() string {
    return fmt.Sprintf("validation error on %s: %s", e.Field, e.Message)
}

func validateUser(user *User) error {
    if user.Email == "" {
        return &ValidationError{
            Field:   "email",
            Message: "email is required",
        }
    }

    if user.Age < 0 {
        return &ValidationError{
            Field:   "age",
            Message: "age must be positive",
        }
    }

    return nil
}

// Error wrapping and unwrapping (Go 1.13+)
func fetchAndProcess(id int) error {
    data, err := fetchFromAPI(id)
    if err != nil {
        // Wrap error with context
        return fmt.Errorf("processing user %d: %w", id, err)
    }

    return processData(data)
}

// Checking for specific errors
func handleError(err error) {
    var validationErr *ValidationError
    if errors.As(err, &validationErr) {
        fmt.Printf("Validation failed on field: %s\n", validationErr.Field)
        return
    }

    if errors.Is(err, os.ErrNotExist) {
        fmt.Println("File not found")
        return
    }

    fmt.Println("Unknown error:", err)
}

// Defer for cleanup (like finally)
func processFile(filename string) error {
    file, err := os.Open(filename)
    if err != nil {
        return err
    }
    defer file.Close() // Guaranteed to run

    // Process file...
    return nil
}

Key Differences:

JavaScript errors bubble up automatically; Go errors must be explicitly returned and checked
Go's if err != nil pattern is ubiquitous—critics call it verbose, advocates call it explicit
Go's defer provides cleanup guarantees similar to JavaScript's finally
JavaScript can throw any value; Go errors implement the error interface
Go 1.13+ added error wrapping with %w, similar to error causes in JavaScript

The Great Debate:

This is perhaps the most controversial difference. JavaScript developers often find Go's error handling repetitive. Go developers argue it makes error paths visible and forces you to think about failure cases. Coming from Django/Python, you'll recognize this as the "explicit is better than implicit" philosophy taken to an extreme.

4. Asynchronous Programming and Concurrency

JavaScript: Async/Await and Promises

JavaScript is single-threaded with an event loop, using async/await for non-blocking operations:

// Promises
function fetchUser(id) {
    return fetch(`/api/users/${id}`)
        .then(response => response.json())
        .then(data => {
            console.log('User:', data);
            return data;
        })
        .catch(error => {
            console.error('Error:', error);
            throw error;
        });
}

// Async/await (syntactic sugar over promises)
async function getUserProfile(userId) {
    try {
        const user = await fetchUser(userId);
        const posts = await fetchUserPosts(userId);
        const followers = await fetchFollowers(userId);

        return {
            user,
            posts,
            followers
        };
    } catch (error) {
        console.error('Failed to get profile:', error);
        throw error;
    }
}

// Parallel execution
async function getMultipleUsers(ids) {
    // Sequential (slow)
    const users = [];
    for (const id of ids) {
        users.push(await fetchUser(id));
    }

    // Parallel (fast)
    const promises = ids.map(id => fetchUser(id));
    const usersParallel = await Promise.all(promises);

    return usersParallel;
}

// Race conditions
async function fetchWithTimeout(url, timeout = 5000) {
    const timeoutPromise = new Promise((_, reject) => {
        setTimeout(() => reject(new Error('Timeout')), timeout);
    });

    return Promise.race([
        fetch(url),
        timeoutPromise
    ]);
}

// Promise combinators
async function complexFlow() {
    // All must succeed
    const [user, config, stats] = await Promise.all([
        fetchUser(1),
        fetchConfig(),
        fetchStats()
    ]);

    // First to succeed
    const fastestServer = await Promise.race([
        fetch('https://server1.com/data'),
        fetch('https://server2.com/data')
    ]);

    // All must settle (succeed or fail)
    const results = await Promise.allSettled([
        riskyOperation1(),
        riskyOperation2(),
        riskyOperation3()
    ]);

    results.forEach((result, index) => {
        if (result.status === 'fulfilled') {
            console.log(`Op ${index} succeeded:`, result.value);
        } else {
            console.log(`Op ${index} failed:`, result.reason);
        }
    });
}

Go: Goroutines and Channels

Go has built-in concurrency primitives—goroutines (lightweight threads) and channels:

package main

import (
    "fmt"
    "sync"
    "time"
)

// Basic goroutine
func sayHello() {
    fmt.Println("Hello from goroutine")
}

func basicGoroutine() {
    go sayHello() // Runs concurrently

    time.Sleep(time.Second) // Wait for goroutine (bad practice, use sync)
}

// Channels for communication
func fetchUser(id int, ch chan<- User) {
    // Simulate API call
    time.Sleep(100 * time.Millisecond)
    user := User{ID: id, Name: fmt.Sprintf("User%d", id)}
    ch <- user // Send to channel
}

func useChannels() {
    userChan := make(chan User)

    go fetchUser(1, userChan)

    user := <-userChan // Receive from channel (blocks until data available)
    fmt.Println("Received:", user)
}

// Concurrent fetching (like Promise.all)
func fetchMultipleUsers(ids []int) []User {
    users := make([]User, len(ids))
    var wg sync.WaitGroup

    for i, id := range ids {
        wg.Add(1)
        go func(index, userID int) {
            defer wg.Done()
            users[index] = fetchUserSync(userID)
        }(i, id)
    }

    wg.Wait() // Wait for all goroutines
    return users
}

// Channel patterns
func channelPatterns() {
    // Buffered channel
    ch := make(chan int, 3) // Can hold 3 items without blocking
    ch <- 1
    ch <- 2
    ch <- 3
    // ch <- 4 // Would block until something is received

    // Select for multiple channels (like Promise.race)
    ch1 := make(chan string)
    ch2 := make(chan string)

    go func() {
        time.Sleep(100 * time.Millisecond)
        ch1 <- "from ch1"
    }()

    go func() {
        time.Sleep(200 * time.Millisecond)
        ch2 <- "from ch2"
    }()

    select {
    case msg1 := <-ch1:
        fmt.Println("Received:", msg1)
    case msg2 := <-ch2:
        fmt.Println("Received:", msg2)
    case <-time.After(500 * time.Millisecond):
        fmt.Println("Timeout")
    }
}

// Worker pool pattern
func workerPool() {
    jobs := make(chan int, 100)
    results := make(chan int, 100)

    // Start workers
    for w := 1; w <= 3; w++ {
        go worker(w, jobs, results)
    }

    // Send jobs
    for j := 1; j <= 9; j++ {
        jobs <- j
    }
    close(jobs)

    // Collect results
    for a := 1; a <= 9; a++ {
        <-results
    }
}

func worker(id int, jobs <-chan int, results chan<- int) {
    for j := range jobs {
        fmt.Printf("Worker %d processing job %d\n", id, j)
        time.Sleep(time.Second)
        results <- j * 2
    }
}

// Context for cancellation (like AbortController)
import "context"

func fetchWithContext(ctx context.Context, id int) (User, error) {
    resultChan := make(chan User)
    errChan := make(chan error)

    go func() {
        // Simulate long operation
        time.Sleep(2 * time.Second)
        resultChan <- User{ID: id}
    }()

    select {
    case user := <-resultChan:
        return user, nil
    case err := <-errChan:
        return User{}, err
    case <-ctx.Done():
        return User{}, ctx.Err() // Cancelled or timed out
    }
}

func useContext() {
    ctx, cancel := context.WithTimeout(context.Background(), 1*time.Second)
    defer cancel()

    user, err := fetchWithContext(ctx, 1)
    if err != nil {
        fmt.Println("Error:", err) // Will timeout
    }
}

// Mutex for shared state
type SafeCounter struct {
    mu    sync.Mutex
    count int
}

func (c *SafeCounter) Increment() {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.count++
}

func (c *SafeCounter) Value() int {
    c.mu.Lock()
    defer c.mu.Unlock()
    return c.count
}

Key Differences:

JavaScript: single-threaded with async I/O; Go: multi-threaded with goroutines
JavaScript uses promises/async-await; Go uses channels and goroutines
Go's select is more powerful than Promise.race for complex coordination
JavaScript's event loop handles concurrency implicitly; Go makes it explicit
Go has built-in primitives (channels, mutexes); JavaScript relies on the event loop

Real-World Impact:

For CPU-bound tasks, Go's goroutines can utilize multiple cores natively. JavaScript would need worker threads (which are clunky) or child processes. For I/O-bound tasks (like your Django REST Framework apps), both work well, but Go's approach scales better for high-concurrency scenarios like handling thousands of WebSocket connections.

5. Data Structures: Objects vs Structs

JavaScript: Prototypal Objects and Classes

JavaScript is object-oriented with prototypal inheritance:

// Object literals
const user = {
    name: "Mephesto",
    email: "mephesto@example.com",
    age: 25,
    greet() {
        return `Hello, I'm ${this.name}`;
    }
};

// Dynamic properties
user.location = "Ukraine";
delete user.age;

// ES6 Classes (syntactic sugar over prototypes)
class User {
    constructor(name, email) {
        this.name = name;
        this.email = email;
        this.createdAt = new Date();
    }

    greet() {
        return `Hello, I'm ${this.name}`;
    }

    static fromJSON(json) {
        const data = JSON.parse(json);
        return new User(data.name, data.email);
    }

    get displayName() {
        return this.name.toUpperCase();
    }

    set displayName(value) {
        this.name = value.toLowerCase();
    }
}

// Inheritance
class AdminUser extends User {
    constructor(name, email, permissions) {
        super(name, email);
        this.permissions = permissions;
    }

    greet() {
        return `Hello, I'm ${this.name} (Admin)`;
    }

    hasPermission(perm) {
        return this.permissions.includes(perm);
    }
}

// Private fields (ES2022)
class BankAccount {
    #balance = 0;

    deposit(amount) {
        this.#balance += amount;
    }

    getBalance() {
        return this.#balance;
    }
}

// Mixing concerns
const withLogging = (BaseClass) => {
    return class extends BaseClass {
        log(message) {
            console.log(`[${this.constructor.name}] ${message}`);
        }
    };
};

const LoggedUser = withLogging(User);

Go: Structs and Composition

Go uses structs with composition instead of inheritance:

package main

import (
    "encoding/json"
    "fmt"
    "strings"
    "time"
)

// Struct definition
type User struct {
    Name      string    `json:"name"`
    Email     string    `json:"email"`
    CreatedAt time.Time `json:"created_at"`
}

// Constructor pattern (not built-in)
func NewUser(name, email string) *User {
    return &User{
        Name:      name,
        Email:     email,
        CreatedAt: time.Now(),
    }
}

// Methods with receivers
func (u User) Greet() string {
    return fmt.Sprintf("Hello, I'm %s", u.Name)
}

// Pointer receivers for mutation
func (u *User) UpdateEmail(email string) {
    u.Email = email
}

// "Getters" (not idiomatic to call them GetX)
func (u User) DisplayName() string {
    return strings.ToUpper(u.Name)
}

// Embedded structs (composition, not inheritance)
type AdminUser struct {
    User                    // Embedded field
    Permissions []string
}

func NewAdminUser(name, email string, perms []string) *AdminUser {
    return &AdminUser{
        User:        *NewUser(name, email),
        Permissions: perms,
    }
}

// Method overriding through embedding
func (a AdminUser) Greet() string {
    return fmt.Sprintf("Hello, I'm %s (Admin)", a.Name)
}

func (a AdminUser) HasPermission(perm string) bool {
    for _, p := range a.Permissions {
        if p == perm {
            return true
        }
    }
    return false
}

// Unexported fields (private)
type bankAccount struct {
    balance int
}

func NewBankAccount() *bankAccount {
    return &bankAccount{balance: 0}
}

func (b *bankAccount) Deposit(amount int) {
    b.balance += amount
}

func (b *bankAccount) Balance() int {
    return b.balance
}

// JSON marshaling/unmarshaling
func jsonExample() {
    user := NewUser("Mephesto", "m@example.com")

    // Marshal to JSON
    data, err := json.Marshal(user)
    if err != nil {
        panic(err)
    }
    fmt.Println(string(data))

    // Unmarshal from JSON
    var newUser User
    if err := json.Unmarshal(data, &newUser); err != nil {
        panic(err)
    }
}

// Struct tags for metadata
type APIUser struct {
    ID        int       `json:"id" db:"user_id"`
    Username  string    `json:"username" db:"username" validate:"required"`
    Email     string    `json:"email,omitempty" db:"email"`
    CreatedAt time.Time `json:"created_at" db:"created_at"`
    password  string    // unexported, won't be marshaled
}

// Anonymous structs for one-off use
func anonymousStructs() {
    config := struct {
        Host string
        Port int
    }{
        Host: "localhost",
        Port: 8080,
    }

    fmt.Printf("Server: %s:%d\n", config.Host, config.Port)
}

Key Differences:

JavaScript has prototypal inheritance; Go has composition via embedding
JavaScript classes are syntactic sugar; Go structs are data containers with attached methods
Go doesn't have constructors—use factory functions by convention
JavaScript properties can be added/removed dynamically; Go structs are fixed at compile time
Go uses struct tags for metadata (like Django model field options)
Privacy in JavaScript uses # or closures; Go uses capitalization (Upper = public, lower = private)

6. Control Flow and Conditionals

JavaScript

// If-else
if (user.age >= 18) {
    console.log("Adult");
} else if (user.age >= 13) {
    console.log("Teenager");
} else {
    console.log("Child");
}

// Ternary operator
const status = user.isActive ? "Active" : "Inactive";

// Switch
switch (user.role) {
    case "admin":
        grantAdminAccess();
        break;
    case "moderator":
        grantModeratorAccess();
        break;
    default:
        grantUserAccess();
}

// Truthy/falsy
if (user.email) { // truthy check
    sendEmail(user.email);
}

// Nullish coalescing
const port = config.port ?? 8080; // Only for null/undefined

// Optional chaining
const city = user?.address?.city; // Won't throw if undefined

// Short-circuit evaluation
const name = user.name || "Anonymous";
const value = user.value && user.value.trim();

Go

package main

import "fmt"

func controlFlow() {
    // If-else (no parentheses!)
    age := 25
    if age >= 18 {
        fmt.Println("Adult")
    } else if age >= 13 {
        fmt.Println("Teenager")
    } else {
        fmt.Println("Child")
    }

    // If with initialization
    if err := someOperation(); err != nil {
        fmt.Println("Error:", err)
        return
    }

    // No ternary operator! Use if-else
    var status string
    if user.IsActive {
        status = "Active"
    } else {
        status = "Inactive"
    }

    // Switch (no break needed!)
    switch role := user.Role; role {
    case "admin":
        grantAdminAccess()
    case "moderator":
        grantModeratorAccess()
    default:
        grantUserAccess()
    }

    // Switch without expression (like if-else chain)
    switch {
    case age < 13:
        fmt.Println("Child")
    case age < 18:
        fmt.Println("Teenager")
    default:
        fmt.Println("Adult")
    }

    // Switch with multiple cases
    switch day {
    case "Saturday", "Sunday":
        fmt.Println("Weekend")
    case "Monday", "Tuesday", "Wednesday", "Thursday", "Friday":
        fmt.Println("Weekday")
    }

    // Fallthrough (explicit, unlike JavaScript)
    switch num {
    case 1:
        fmt.Println("One")
        fallthrough
    case 2:
        fmt.Println("Two or less")
    }

    // Type switch
    var i interface{} = "hello"
    switch v := i.(type) {
    case int:
        fmt.Printf("Integer: %d\n", v)
    case string:
        fmt.Printf("String: %s\n", v)
    default:
        fmt.Printf("Unknown type: %T\n", v)
    }
}

Key Differences:

Go doesn't have ternary operators—use if-else
Go's switch doesn't fall through by default (needs explicit fallthrough)
Go's switch can operate on types and arbitrary conditions
JavaScript has truthy/falsy; Go requires explicit boolean expressions
Go's if can include an initialization statement

7. Loops and Iteration

JavaScript

// For loop
for (let i = 0; i < 10; i++) {
    console.log(i);
}

// For...of (values)
const numbers = [1, 2, 3, 4, 5];
for (const num of numbers) {
    console.log(num);
}

// For...in (keys/indices)
const user = { name: "John", age: 30 };
for (const key in user) {
    console.log(`${key}: ${user[key]}`);
}

// While
let count = 0;
while (count < 10) {
    console.log(count);
    count++;
}

// Do-while
do {
    console.log(count);
    count--;
} while (count > 0);

// Array methods (functional style)
const doubled = numbers.map(n => n * 2);
const evens = numbers.filter(n => n % 2 === 0);
const sum = numbers.reduce((acc, n) => acc + n, 0);

numbers.forEach((num, index) => {
    console.log(`${index}: ${num}`);
});

// Break and continue
for (let i = 0; i < 10; i++) {
    if (i === 3) continue;
    if (i === 7) break;
    console.log(i);
}

// Labeled loops
outer: for (let i = 0; i < 3; i++) {
    for (let j = 0; j < 3; j++) {
        if (i === 1 && j === 1) break outer;
        console.log(i, j);
    }
}

Go

package main

import "fmt"

func loops() {
    // For loop (only loop keyword in Go!)
    for i := 0; i < 10; i++ {
        fmt.Println(i)
    }

    // While-style loop
    count := 0
    for count < 10 {
        fmt.Println(count)
        count++
    }

    // Infinite loop
    for {
        // Must have break somewhere
        if someCondition {
            break
        }
    }

    // Range over slice (like for...of)
    numbers := []int{1, 2, 3, 4, 5}
    for index, value := range numbers {
        fmt.Printf("%d: %d\n", index, value)
    }

    // Ignore index with _
    for _, value := range numbers {
        fmt.Println(value)
    }

    // Only index
    for index := range numbers {
        fmt.Println(index)
    }

    // Range over map
    user := map[string]interface{}{
        "name": "John",
        "age":  30,
    }
    for key, value := range user {
        fmt.Printf("%s: %v\n", key, value)
    }

    // Range over string (iterates over runes/characters)
    for index, char := range "Привіт" {
        fmt.Printf("%d: %c\n", index, char)
    }

    // Range over channel
    ch := make(chan int, 5)
    go func() {
        for i := 0; i < 5; i++ {
            ch <- i
        }
        close(ch)
    }()

    for value := range ch {
        fmt.Println(value)
    }

    // Break and continue
    for i := 0; i < 10; i++ {
        if i == 3 {
            continue
        }
        if i == 7 {
            break
        }
        fmt.Println(i)
    }

    // Labeled loops
outer:
    for i := 0; i < 3; i++ {
        for j := 0; j < 3; j++ {
            if i == 1 && j == 1 {
                break outer
            }
            fmt.Println(i, j)
        }
    }
}

// No built-in map/filter/reduce, but easy to implement
func Map(slice []int, fn func(int) int) []int {
    result := make([]int, len(slice))
    for i, v := range slice {
        result[i] = fn(v)
    }
    return result
}

func Filter(slice []int, fn func(int) bool) []int {
    result := []int{}
    for _, v := range slice {
        if fn(v) {
            result = append(result, v)
        }
    }
    return result
}

func Reduce(slice []int, fn func(int, int) int, initial int) int {
    result := initial
    for _, v := range slice {
        result = fn(result, v)
    }
    return result
}

Key Differences:

Go has only for (replaces while, do-while, foreach)
Go's range is like JavaScript's for...of but more powerful
JavaScript has rich array methods; Go requires manual implementation or libraries
Both support labeled breaks for nested loops
Go's range over strings gives you runes (Unicode code points), not bytes

8. Interfaces and Polymorphism

JavaScript: Duck Typing

JavaScript uses structural typing—if it looks like a duck and quacks like a duck:

// No explicit interface, just conventions
class FileStorage {
    save(data) {
        // Save to file
    }

    load() {
        // Load from file
    }
}

class DatabaseStorage {
    save(data) {
        // Save to database
    }

    load() {
        // Load from database
    }
}

// Works with anything that has save/load
function backup(storage, data) {
    storage.save(data);
}

backup(new FileStorage(), data);
backup(new DatabaseStorage(), data);

// TypeScript interfaces (compile-time only)
interface Storage {
    save(data: any): void;
    load(): any;
}

class CloudStorage implements Storage {
    save(data: any) { /* ... */ }
    load() { /* ... */ }
}

Go: Implicit Interfaces

Go has interfaces, but they're satisfied implicitly (structural typing):

package main

import "fmt"

// Interface definition
type Storage interface {
    Save(data []byte) error
    Load() ([]byte, error)
}

// Types implement interfaces implicitly
type FileStorage struct {
    path string
}

func (f *FileStorage) Save(data []byte) error {
    // Save to file
    fmt.Println("Saving to file:", f.path)
    return nil
}

func (f *FileStorage) Load() ([]byte, error) {
    // Load from file
    return []byte("file data"), nil
}

type DatabaseStorage struct {
    connStr string
}

func (d *DatabaseStorage) Save(data []byte) error {
    // Save to database
    fmt.Println("Saving to database")
    return nil
}

func (d *DatabaseStorage) Load() ([]byte, error) {
    // Load from database
    return []byte("db data"), nil
}

// Function accepts interface
func Backup(storage Storage, data []byte) error {
    return storage.Save(data)
}

func main() {
    file := &FileStorage{path: "/tmp/data"}
    db := &DatabaseStorage{connStr: "postgres://..."}

    Backup(file, []byte("data"))    // Works
    Backup(db, []byte("data"))      // Works
}

// Multiple interfaces
type Reader interface {
    Read(p []byte) (n int, err error)
}

type Writer interface {
    Write(p []byte) (n int, err error)
}

type ReadWriter interface {
    Reader
    Writer
}

// Empty interface (like any in TypeScript)
func PrintAnything(v interface{}) {
    fmt.Println(v)
}

// Type assertions
func processValue(v interface{}) {
    // Type assertion
    if str, ok := v.(string); ok {
        fmt.Println("String:", str)
    }

    // Type switch
    switch val := v.(type) {
    case int:
        fmt.Println("Int:", val)
    case string:
        fmt.Println("String:", val)
    case Storage:
        fmt.Println("Storage implementation")
    default:
        fmt.Println("Unknown type")
    }
}

// Common standard interfaces
import "io"

// io.Reader is everywhere in Go
func ProcessReader(r io.Reader) {
    data := make([]byte, 100)
    n, err := r.Read(data)
    // Process data
}

// Works with files, network connections, buffers, etc.

Key Differences:

Both use structural typing (duck typing), but Go makes it explicit with the interface keyword
JavaScript has no runtime interfaces; TypeScript interfaces are compile-time only
Go's interface satisfaction is implicit—no implements keyword needed
Go's empty interface interface{} is like JavaScript's any
Go has powerful standard interfaces (io.Reader, io.Writer, etc.)

9. Package Management and Modules

JavaScript: NPM and ES Modules

// package.json
{
  "name": "my-app",
  "version": "1.0.0",
  "type": "module",
  "dependencies": {
    "express": "^4.18.0",
    "lodash": "^4.17.21"
  },
  "devDependencies": {
    "jest": "^29.0.0"
  }
}

// Importing
import express from 'express';
import { debounce } from 'lodash';
import * as utils from './utils.js';

// Named exports
export function helper() { }
export const CONSTANT = 42;

// Default export
export default class MyClass { }

// Re-exporting
export { something } from './other.js';
export * from './module.js';

// Dynamic imports
const module = await import('./dynamic.js');

// CommonJS (older style)
const fs = require('fs');
module.exports = { helper };

Go: Go Modules

// go.mod
module github.com/mephesto/myapp

go 1.21

require (
    github.com/gin-gonic/gin v1.9.0
    github.com/lib/pq v1.10.7
)

// Importing
package main

import (
    "fmt"                    // Standard library
    "net/http"              // Standard library

    "github.com/gin-gonic/gin"           // External package
    "github.com/mephesto/myapp/internal" // Internal package
)

// Exporting (capitalization!)
package utils

// Exported (public)
func Helper() {
    // ...
}

const PublicConstant = 42

type PublicStruct struct {
    PublicField  string
    privateField string  // Not exported
}

// Not exported (private)
func helper() {
    // ...
}

// Package initialization
func init() {
    // Runs when package is imported
    fmt.Println("Package initialized")
}

// Internal packages (Go specific)
// github.com/mephesto/myapp/internal can only be imported
// by packages under github.com/mephesto/myapp

Key Differences:

JavaScript uses package.json; Go uses go.mod
JavaScript has explicit export/import; Go uses capitalization for visibility
Go's import creates a namespace; JavaScript can destructure imports
Go has internal/ package convention for truly private code
JavaScript has dynamic imports; Go imports are static (compile-time)
Go's standard library is more comprehensive

10. Philosophy and Real-World Implications

JavaScript Philosophy

Flexibility and Expression

JavaScript embraces multiple paradigms—object-oriented, functional, imperative. You can solve problems in many ways:

// Object-oriented
class UserService {
    findUser(id) { }
}

// Functional
const findUser = (id) => fetch(`/users/${id}`);

// Prototype-based
function UserService() { }
UserService.prototype.findUser = function(id) { };

Dynamic and Forgiving

// Type coercion
"5" - 3;        // 2
"5" + 3;        // "53"
[] + {};        // "[object Object]"
{} + [];        // 0 (in some contexts)

// Undefined behavior
const obj = {};
obj.deeply.nested.property; // TypeError
obj?.deeply?.nested?.property; // undefined (with optional chaining)

Ecosystem: Fast-Moving

The JavaScript ecosystem moves quickly. New frameworks appear constantly. This is both a strength (innovation) and weakness (fatigue).

Go Philosophy

Simplicity and Clarity

Go deliberately limits features. There's often "one way" to do things:

// One loop construct
for i := 0; i < 10; i++ { }

// No ternary operator
// No generics (until Go 1.18)
// No inheritance
// No overloading

Explicit and Strict

// No implicit conversions
var i int = 42
var f float64 = i  // Compile error
var f float64 = float64(i)  // Must be explicit

// Unused imports are errors
import "fmt"  // If not used, won't compile

// All errors must be handled
result, err := doSomething()
// Ignoring err is bad practice

Ecosystem: Stability-Focused

Go values backwards compatibility. The language changes slowly. Standard library is comprehensive. Fewer but more stable third-party packages.

When to Choose Which?

Choose JavaScript when:

Building web frontends (React, Vue, Angular)
Rapid prototyping with flexibility
Rich ecosystem of libraries needed
Team familiar with dynamic typing
Quick iteration more important than compile-time safety

Choose Go when:

Building microservices or APIs
Performance and concurrency critical
System-level programming
Deployment simplicity matters (single binary)
Long-term maintainability priority
Team values explicit error handling

Practical Example: Web API

JavaScript (Express):

const express = require('express');
const app = express();

app.get('/users/:id', async (req, res) => {
    try {
        const user = await db.findUser(req.params.id);
        res.json(user);
    } catch (error) {
        res.status(500).json({ error: error.message });
    }
});

app.listen(3000);

Go (Gin):

package main

import (
    "net/http"
    "github.com/gin-gonic/gin"
)

func main() {
    r := gin.Default()

    r.GET("/users/:id", func(c *gin.Context) {
        id := c.Param("id")

        user, err := db.FindUser(id)
        if err != nil {
            c.JSON(http.StatusInternalServerError, gin.H{
                "error": err.Error(),
            })
            return
        }

        c.JSON(http.StatusOK, user)
    })

    r.Run(":3000")
}

Key Observations:

JavaScript: More concise, async/await cleaner, dynamic
Go: More verbose, explicit error handling, typed parameters
JavaScript: Dependency on framework conventions
Go: Strong standard library, explicit control flow

Conclusion

JavaScript and Go represent different philosophies:

JavaScript says: "Be flexible, move fast, express yourself freely." It's the language of rapid iteration, rich ecosystems, and creative solutions. Perfect for web development where requirements change rapidly.

Go says: "Be explicit, be simple, be maintainable." It's the language of clarity, performance, and long-term reliability. Perfect for backend services where stability matters.

Neither is "better"—they solve different problems. Coming from Django and Python, you'll appreciate Go's explicitness and find JavaScript's dynamism both liberating and occasionally frustrating.

The best developers understand both paradigms and choose the right tool for the job. JavaScript for dynamic, user-facing applications. Go for reliable, concurrent backend services.

What matters is understanding the trade-offs and using each language's strengths effectively.

Want to dive deeper? Check out my other posts on language comparisons, or follow along as I continue exploring "What's wrong with..." various programming paradigms.

Taming the Container Beast: A Developer's Guide to Debugging Django in Docker

Maksym — Wed, 03 Dec 2025 09:18:49 +0000

Debugging a Django application running inside a Docker container can feel like trying to fix a car engine while it's still running—challenging, but definitely not impossible. If you've ever found yourself staring at cryptic error messages with no stack trace, or wondering why your breakpoints never trigger, you're not alone. This guide will equip you with the tools and techniques to effectively debug Dockerized Django applications.

Why Docker Makes Debugging Tricky

Docker containers are designed to be isolated, lightweight, and production-like. While this is great for deployment, it creates some unique challenges for debugging:

Limited direct access to the running process
Logs can be scattered or hard to follow
Interactive debuggers require special configuration
File system isolation makes it harder to inspect state
Network isolation can complicate remote debugging

But don't worry—once you understand how to work with these constraints, debugging becomes straightforward.

Setting Up Your Environment for Success

Before diving into specific debugging techniques, let's ensure your Docker setup is debug-friendly.

Optimize Your Dockerfile for Development

Create a separate Dockerfile.dev for development that includes debugging tools:

FROM python:3.11-slim

# Install system dependencies
RUN apt-get update && apt-get install -y \
    postgresql-client \
    netcat-traditional \
    vim \
    curl \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app

# Install Python dependencies
COPY requirements.txt requirements-dev.txt ./
RUN pip install --no-cache-dir -r requirements.txt -r requirements-dev.txt

# Copy application code
COPY . .

# Don't run as root
RUN useradd -m -u 1000 appuser && chown -R appuser:appuser /app
USER appuser

CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]

Configure docker-compose.yml for Development

Your docker-compose.yml should make debugging easier:

version: '3.8'

services:
  web:
    build:
      context: .
      dockerfile: Dockerfile.dev
    command: python manage.py runserver 0.0.0.0:8000
    volumes:
      # Mount code for live reloading
      - .:/app
      # Preserve Python packages
      - python-packages:/usr/local/lib/python3.11/site-packages
    ports:
      - "8000:8000"
      # Expose debugger port
      - "5678:5678"
    environment:
      - DEBUG=True
      - PYTHONUNBUFFERED=1
      - DJANGO_SETTINGS_MODULE=myproject.settings.dev
    depends_on:
      - db
    stdin_open: true
    tty: true

  db:
    image: postgres:15
    environment:
      - POSTGRES_DB=mydb
      - POSTGRES_USER=myuser
      - POSTGRES_PASSWORD=mypassword
    volumes:
      - postgres-data:/var/lib/postgresql/data
    ports:
      - "5432:5432"

volumes:
  postgres-data:
  python-packages:

Key settings explained:

stdin_open: true and tty: true enable interactive debugging
PYTHONUNBUFFERED=1 ensures logs appear in real-time
Volume mounting allows code changes without rebuilding
Exposed ports enable remote debugging

Technique 1: Mastering Docker Logs

The first line of defense is always logs. Docker provides powerful logging capabilities.

View Real-Time Logs

# Follow logs from all services
docker-compose logs -f

# Follow logs from specific service
docker-compose logs -f web

# Show last 100 lines and follow
docker-compose logs -f --tail=100 web

# View logs with timestamps
docker-compose logs -f -t web

Enhance Django Logging

Configure comprehensive logging in your Django settings:

# settings/dev.py
LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'verbose': {
            'format': '[{levelname}] {asctime} {module} {process:d} {thread:d} {message}',
            'style': '{',
        },
        'simple': {
            'format': '[{levelname}] {message}',
            'style': '{',
        },
    },
    'handlers': {
        'console': {
            'class': 'logging.StreamHandler',
            'formatter': 'verbose',
        },
        'file': {
            'class': 'logging.FileHandler',
            'filename': '/app/logs/debug.log',
            'formatter': 'verbose',
        },
    },
    'root': {
        'handlers': ['console', 'file'],
        'level': 'INFO',
    },
    'loggers': {
        'django': {
            'handlers': ['console', 'file'],
            'level': 'INFO',
            'propagate': False,
        },
        'django.db.backends': {
            'handlers': ['console'],
            'level': 'DEBUG',  # Shows SQL queries
            'propagate': False,
        },
        'myapp': {
            'handlers': ['console', 'file'],
            'level': 'DEBUG',
            'propagate': False,
        },
    },
}

Use logging strategically in your code:

import logging

logger = logging.getLogger(__name__)

def my_view(request):
    logger.info(f"Processing request: {request.method} {request.path}")
    logger.debug(f"Request data: {request.POST}")

    try:
        # Your code here
        result = perform_operation()
        logger.info(f"Operation successful: {result}")
    except Exception as e:
        logger.error(f"Operation failed: {str(e)}", exc_info=True)
        raise

    return response

Technique 2: Interactive Shell Access

Sometimes you need to poke around inside the container.

Access the Container Shell

# Start a bash shell in running container
docker-compose exec web bash

# Or use sh if bash isn't available
docker-compose exec web sh

# Run as root for system-level debugging
docker-compose exec -u root web bash

Use Django Shell Inside Container

# Django shell
docker-compose exec web python manage.py shell

# Django shell with IPython (if installed)
docker-compose exec web python manage.py shell -i ipython

# Run specific Django commands
docker-compose exec web python manage.py migrate
docker-compose exec web python manage.py createsuperuser

One-Liner Debugging Commands

# Check database connectivity
docker-compose exec web python manage.py dbshell

# Inspect database tables
docker-compose exec db psql -U myuser -d mydb -c "\dt"

# Check environment variables
docker-compose exec web env

# Test a specific view
docker-compose exec web python manage.py shell -c "
from django.test import Client
client = Client()
response = client.get('/api/endpoint/')
print(response.status_code)
print(response.content)
"

Technique 3: Remote Debugging with debugpy

For complex issues, nothing beats a proper debugger with breakpoints.

Install debugpy

Add to requirements-dev.txt:

debugpy==1.8.0

Configure Remote Debugging

Create a debugging wrapper script debug_server.py:

import os
import sys
import debugpy

# Allow other computers to attach to debugpy
debugpy.listen(("0.0.0.0", 5678))

# Pause execution until debugger attaches
if os.environ.get('WAIT_FOR_DEBUGGER', 'False') == 'True':
    print("⏳ Waiting for debugger to attach...")
    debugpy.wait_for_client()
    print("✅ Debugger attached!")

# Start Django
if __name__ == "__main__":
    os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings')
    from django.core.management import execute_from_command_line
    execute_from_command_line(sys.argv)

Update your docker-compose.yml command:

services:
  web:
    command: python debug_server.py runserver 0.0.0.0:8000
    environment:
      - WAIT_FOR_DEBUGGER=False  # Set to True to wait for debugger

Configure VS Code

Create .vscode/launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Django: Remote Attach",
            "type": "python",
            "request": "attach",
            "connect": {
                "host": "localhost",
                "port": 5678
            },
            "pathMappings": [
                {
                    "localRoot": "${workspaceFolder}",
                    "remoteRoot": "/app"
                }
            ],
            "django": true,
            "justMyCode": false
        }
    ]
}

Configure PyCharm

Go to Run → Edit Configurations
Click + → Python Remote Debug
Set Host: localhost, Port: 5678
Set Path mappings: <Project root>=/app
Click OK

Using the Debugger

# Start your containers
docker-compose up

# In VS Code: Press F5 or click "Run and Debug"
# Set breakpoints in your code
# Make a request to trigger your code

The debugger will pause at breakpoints, allowing you to:

Inspect variables
Step through code
Evaluate expressions
Examine the call stack

Technique 4: Using pdb for Quick Debugging

For quick debugging sessions, Python's built-in pdb works well.

Insert Breakpoints

def my_view(request):
    data = request.POST.get('data')

    # Insert breakpoint
    import pdb; pdb.set_trace()

    # Or use the modern way (Python 3.7+)
    breakpoint()

    result = process_data(data)
    return JsonResponse({'result': result})

Attach to Container with TTY

# Stop current containers
docker-compose down

# Start with attached terminal
docker-compose run --service-ports web

# Now when pdb breakpoint hits, you'll get an interactive prompt

Common pdb commands:

n (next) - Execute next line
s (step) - Step into function
c (continue) - Continue execution
l (list) - Show code context
p variable - Print variable value
pp variable - Pretty-print variable
w (where) - Show stack trace
q (quit) - Quit debugger

Technique 5: Debugging Database Issues

Database problems are common in Django applications.

Inspect Database State

# Access PostgreSQL directly
docker-compose exec db psql -U myuser -d mydb

# Run SQL queries
docker-compose exec db psql -U myuser -d mydb -c "
SELECT * FROM django_migrations ORDER BY applied DESC LIMIT 5;
"

# Check database size and connections
docker-compose exec db psql -U myuser -d mydb -c "
SELECT 
    datname,
    pg_size_pretty(pg_database_size(datname)) as size,
    numbackends as connections
FROM pg_stat_database
WHERE datname = 'mydb';
"

Debug SQL Queries

Enable SQL logging in Django settings:

LOGGING['loggers']['django.db.backends'] = {
    'handlers': ['console'],
    'level': 'DEBUG',
}

Or use Django Debug Toolbar:

# requirements-dev.txt
django-debug-toolbar==4.2.0

# settings/dev.py
INSTALLED_APPS += ['debug_toolbar']
MIDDLEWARE += ['debug_toolbar.middleware.DebugToolbarMiddleware']
INTERNAL_IPS = ['127.0.0.1', 'host.docker.internal']

# For Docker, you need this:
import socket
hostname, _, ips = socket.gethostbyname_ex(socket.gethostname())
INTERNAL_IPS += [ip[:-1] + '1' for ip in ips]

Use Django Shell Plus

# Install
pip install django-extensions ipython

# Add to settings
INSTALLED_APPS += ['django_extensions']

# Use it
docker-compose exec web python manage.py shell_plus --print-sql

This auto-imports models and shows SQL for all queries.

Technique 6: Network and Service Debugging

Container networking can be tricky.

Test Inter-Container Connectivity

# From web container, test database connection
docker-compose exec web nc -zv db 5432

# Test HTTP endpoint from another service
docker-compose exec web curl http://another_service:8000/health

# Check DNS resolution
docker-compose exec web nslookup db
docker-compose exec web ping -c 3 db

Inspect Docker Networks

# List networks
docker network ls

# Inspect specific network
docker network inspect myproject_default

# Check which containers are on network
docker network inspect myproject_default | grep -A 5 "Containers"

Debug External Network Issues

# Check if container can reach external services
docker-compose exec web curl -I https://api.example.com

# Check DNS resolution
docker-compose exec web nslookup google.com

# Test with specific DNS server
docker-compose exec web nslookup google.com 8.8.8.8

Technique 7: Performance Profiling

Identify performance bottlenecks in your containerized app.

Use Django Silk

# requirements-dev.txt
django-silk==5.0.4

# settings/dev.py
INSTALLED_APPS += ['silk']
MIDDLEWARE.insert(0, 'silk.middleware.SilkyMiddleware')

# urls.py
urlpatterns += [path('silk/', include('silk.urls', namespace='silk'))]

Access profiling data at http://localhost:8000/silk/

Use cProfile

# Create a management command: myapp/management/commands/profile_view.py
from django.core.management.base import BaseCommand
import cProfile
import pstats
from django.test import Client

class Command(BaseCommand):
    def handle(self, *args, **options):
        client = Client()
        profiler = cProfile.Profile()

        profiler.enable()
        response = client.get('/api/slow-endpoint/')
        profiler.disable()

        stats = pstats.Stats(profiler)
        stats.sort_stats('cumulative')
        stats.print_stats(20)  # Top 20 slowest functions

Run it:

docker-compose exec web python manage.py profile_view

Monitor Container Resources

# Real-time container stats
docker stats

# Stats for specific container
docker stats myproject_web_1

# Check container processes
docker-compose exec web ps aux

# Check memory usage inside container
docker-compose exec web free -h

# Check disk usage
docker-compose exec web df -h

Technique 8: Debugging Static Files and Media

Static file issues are common during development.

Verify Static File Configuration

# Collect static files
docker-compose exec web python manage.py collectstatic --noinput

# Check static files location
docker-compose exec web python manage.py findstatic admin/css/base.css

# List all static file locations
docker-compose exec web python manage.py findstatic --verbosity=2 admin/css/base.css

Debug Media File Uploads

# settings/dev.py
MEDIA_ROOT = '/app/media'
MEDIA_URL = '/media/'

# Check permissions
import os
import logging
logger = logging.getLogger(__name__)

def check_media_permissions():
    media_root = settings.MEDIA_ROOT
    if not os.path.exists(media_root):
        logger.warning(f"MEDIA_ROOT does not exist: {media_root}")
    elif not os.access(media_root, os.W_OK):
        logger.error(f"MEDIA_ROOT is not writable: {media_root}")
    else:
        logger.info(f"MEDIA_ROOT is configured correctly: {media_root}")

Technique 9: Environment and Configuration Debugging

Configuration issues are hard to spot but easy to fix once found.

Dump All Django Settings

# Create management command: myapp/management/commands/show_settings.py
from django.core.management.base import BaseCommand
from django.conf import settings
import pprint

class Command(BaseCommand):
    def handle(self, *args, **options):
        # Get all settings
        settings_dict = {
            key: getattr(settings, key)
            for key in dir(settings)
            if key.isupper()
        }
        pprint.pprint(settings_dict)

docker-compose exec web python manage.py show_settings

Check Environment Variables

# View all env vars
docker-compose exec web env

# Check specific variable
docker-compose exec web bash -c 'echo $DATABASE_URL'

# Verify Django can access them
docker-compose exec web python -c "
import os
from django.conf import settings
print('DEBUG:', settings.DEBUG)
print('DATABASE:', settings.DATABASES)
print('SECRET_KEY:', settings.SECRET_KEY[:10] + '...')
"

Validate Docker Compose Configuration

# Validate compose file syntax
docker-compose config

# View merged configuration
docker-compose config --services

# Check resolved environment variables
docker-compose config --resolve-image-digests

Technique 10: Debugging Migrations

Migration issues can break your entire application.

Check Migration Status

# Show migration status
docker-compose exec web python manage.py showmigrations

# Show unapplied migrations
docker-compose exec web python manage.py showmigrations --plan

# Check for conflicts
docker-compose exec web python manage.py makemigrations --dry-run --check

Debug Failed Migrations

# Run migrations with verbose output
docker-compose exec web python manage.py migrate --verbosity=3

# Fake a specific migration (if needed)
docker-compose exec web python manage.py migrate myapp 0004 --fake

# Roll back to specific migration
docker-compose exec web python manage.py migrate myapp 0003

# Start fresh (DANGEROUS - dev only!)
docker-compose down -v
docker-compose up -d db
docker-compose exec db psql -U myuser -d mydb -c "DROP SCHEMA public CASCADE; CREATE SCHEMA public;"
docker-compose exec web python manage.py migrate

Generate SQL for Migration

# See SQL that will be executed
docker-compose exec web python manage.py sqlmigrate myapp 0005

# Show SQL for all pending migrations
docker-compose exec web python manage.py sqlmigrate --backwards myapp 0005

Pro Tips and Best Practices

Use Docker Compose Override Files

Create docker-compose.override.yml for personal debugging settings:

version: '3.8'

services:
  web:
    environment:
      - DEBUG=True
      - DJANGO_LOG_LEVEL=DEBUG
    volumes:
      - ./my_local_debugging:/app/debug
    ports:
      - "5678:5678"  # Debugger
      - "8001:8000"  # Alternative port

This file is automatically merged and git-ignored by default.

Create Debugging Shortcuts

Add aliases to your .bashrc or .zshrc:

# Docker compose shortcuts
alias dc='docker-compose'
alias dcup='docker-compose up -d'
alias dcdown='docker-compose down'
alias dclogs='docker-compose logs -f'
alias dcweb='docker-compose exec web'
alias dcdb='docker-compose exec db psql -U myuser -d mydb'
alias dcshell='docker-compose exec web python manage.py shell_plus'
alias dcbash='docker-compose exec web bash'

# Django shortcuts
alias djmigrate='docker-compose exec web python manage.py migrate'
alias djmakemigrations='docker-compose exec web python manage.py makemigrations'
alias djtest='docker-compose exec web python manage.py test'
alias djcollectstatic='docker-compose exec web python manage.py collectstatic --noinput'

Use Watchdog for Auto-Restart

# requirements-dev.txt
watchdog==3.0.0

# Start server with auto-reload
docker-compose exec web watchmedo auto-restart \
    --directory=/app \
    --pattern="*.py" \
    --recursive \
    -- python manage.py runserver 0.0.0.0:8000

Build a Debugging Checklist

When something goes wrong, systematically check:

✅ Are all containers running? (docker-compose ps)
✅ Any errors in logs? (docker-compose logs)
✅ Can containers communicate? (nc -zv service port)
✅ Are environment variables set correctly? (env)
✅ Are migrations applied? (showmigrations)
✅ Is database accessible? (dbshell)
✅ Are static files collected? (findstatic)
✅ Is DEBUG=True in development? (show_settings)
✅ Can you reproduce outside Docker? (Local testing)
✅ Is it a volume/permission issue? (ls -la)

Common Pitfalls and Solutions

Issue: Changes Not Reflected

Problem: Code changes don't appear when refreshing.

Solutions:

Check volume mounting: docker-compose config | grep volumes
Ensure PYTHONUNBUFFERED=1
Restart with fresh build: docker-compose up --build
Clear Python cache: docker-compose exec web find . -name "*.pyc" -delete

Issue: Database Connection Refused

Problem: Django can't connect to PostgreSQL.

Solutions:

Check if DB is ready: docker-compose exec db pg_isready
Verify service name matches: Use db not localhost
Add healthcheck to wait for DB:

services:
  web:
    depends_on:
      db:
        condition: service_healthy
  db:
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U myuser"]
      interval: 5s
      timeout: 5s
      retries: 5

Issue: Permission Denied Errors

Problem: Can't write to mounted volumes.

Solutions:

Match container user to host user UID
Use named volumes for sensitive data
Run container as root temporarily: docker-compose exec -u root web bash

Issue: Debugger Won't Attach

Problem: Remote debugger fails to connect.

Solutions:

Ensure port 5678 is exposed and mapped
Use 0.0.0.0 not localhost in debugpy.listen()
Check firewall settings
Verify path mappings match exactly

Conclusion

Debugging Django in Docker doesn't have to be painful. With the right setup and tools, you can have a debugging experience that rivals local development while enjoying Docker's benefits. The key is to:

Set up proper logging from day one
Use remote debugging tools like debugpy for complex issues
Master Docker commands for container inspection
Create debugging shortcuts to save time
Build systematic debugging habits with checklists

Remember that debugging is a skill that improves with practice. Start with simple techniques like logging and shell access, then graduate to more advanced methods like remote debugging as needed. Your future self will thank you for investing time in proper debugging infrastructure.

Happy debugging! 🐛🔍🐳

Squashing is so much fun, if you know how to do that

Maksym — Fri, 28 Nov 2025 12:25:09 +0000

During development I often get frustrated by how frequently I need to change the database schema and generate new migrations, which quickly clutters the project and slows things down; my staging environment adds another twist since it runs entirely in Docker without Python installed on the host, giving me more free space and isolation but also making it harder to manage migrations directly, so this guide is written to help developers like me — and you — keep migrations clean, squash them when needed, and stay sane while juggling schema changes in containerized setups.

🧩 Why squashing?

Squashing migrations reduces clutter. Instead of having many small migration files, you combine them into one. This makes your project cleaner and faster to migrate on fresh databases.

📖 Step‑by‑Step Guide

1. Check your current migrations

Run:

python manage.py showmigrations myapp

You’ll see something like:

[X] 0001_initial
[X] 0002_auto
[X] 0003_add_field
[X] 0004_auto
[X] 0005_auto

The [X] means they’ve already been applied.

2. Run squashmigrations

Tell Django to squash up to the latest migration:

python manage.py squashmigrations myapp 0005

This creates a new file, usually named:

myapp/migrations/0001_squashed_0005.py

3. Edit the `replaces` list

Open the new squashed migration file. You’ll see something like:

replaces = [
    ('myapp', '0001_initial'),
    ('myapp', '0002_auto'),
    ('myapp', '0003_add_field'),
    ('myapp', '0004_auto'),
    ('myapp', '0005_auto'),
]

Since you only want to squash 0004 and 0005, trim the list:

replaces = [
    ('myapp', '0004_auto'),
    ('myapp', '0005_auto'),
]

4. Keep old migrations temporarily

Do not delete 0004 and 0005 yet. Commit the squashed migration alongside them. Django will treat the squashed migration as equivalent to those two.

5. Test on a fresh database

Drop your local DB and recreate it, then run:

python manage.py migrate

Check that the squashed migration applies cleanly and the schema looks correct.

6. Clean up

Once you’re confident:

Delete 0004_auto.py and 0005_auto.py from your repo.
Keep 0001, 0002, 0003 (since they’re already applied in production).
Keep the new squashed migration file.

7. Push to Git

Commit the changes and push. Teammates who already applied 0004 and 0005 won’t break — Django knows the squashed migration replaces them.

🚀 Best Practices

Always test squashed migrations on a fresh database.
Never squash migrations that are already deployed unless you’re only squashing the latest ones.
Communicate with your team before removing old migration files.

Hopefully this article will help you in the development or extend your knowledge in field of database migrations in Django. As always if you have any thoughts, criticism or just want to clarify something, write a comment!

DEV Community: Maksym

Docker Transfers: The Lazy (and Fast) Way

First, Let's Clarify the Terminology

Docker Build

Docker Image

Docker Container

The Core Idea: Build Locally, Deploy the Image

Method 1: docker save / docker load (Direct Transfer)

Step 1: Build the image locally

Step 2: Save the image to a tar archive

Step 3: Compress it (optional but recommended)

Step 4: Transfer to the server

Step 5: Load the image on the server

Step 6: Run it

Method 2: Tag and Push to a Registry

Option A: Docker Hub (simplest)

Option B: Self-hosted Registry

Option C: GitHub Container Registry (ghcr.io)

Tips for Working with Slow Servers

Putting It All Together: A Simple Deploy Script

Summary

Bruno: The Git-Friendly API Client and How to Push Your Collection to Codeberg

What is Bruno?

Why Choose Bruno?

Step-by-Step: Push Your Bruno Collection to Codeberg

Step 1: Create and Locate Your Collection

Step 2: Configure .gitignore

Step 3: Initialize Git and Commit Locally

Step 4: Create an Empty Repository on Codeberg

Step 5: Link and Push to Codeberg

Best Practices for Bruno & Git

Python Logging Levels

1. The 5 Standard Log Levels

2. How Level Filtering Works

3. Self-Contained Code Example

4. The Hierarchy Gotcha: Level Inheritance

5. Best Practice: Dynamic Environment Configuration

6. Environment Recommendations

Managing virtual environments in Python

The Toolset

Recommended Workflows

Option 1: The "Manual" Approach (Pyenv + Pyenv-Virtualenv)

Option 2: The "Modern" Approach (Pyenv + Pipenv)

Critical Disclaimers

Comparison at a Glance

Final Rule of Thumb

Your Terminal Deserves Better. Oh My Zsh Agrees.

What is Oh My Zsh?

Installation

Plugins worth enabling

git

z

zsh-autosuggestions

zsh-syntax-highlighting

Themes

Powerlevel10k

Zsh vs Fish

A starter ~/.zshrc

Where to go from here

Pause, Save, Resume: The Definitive Guide to Stashing

What is Git Stash?

Basic Usage

Stashing your changes

Stashing with a descriptive message

Including untracked files

Viewing Your Stashes

Applying Stashes

Apply the most recent stash (keep it in the stash list)

Apply and remove from the stash list

Apply a specific stash by index

Apply to a different branch

Inspecting a Stash

Deleting Stashes

Drop a specific stash

Clear all stashes

Creating a Branch from a Stash

Partial Stashing

Handling Conflicts

Quick Reference

Tips and Gotchas

Method 1: `docker save` / `docker load` (Direct Transfer)

Step 2: Configure `.gitignore`

A starter `~/.zshrc`