The other half is knowing that the code continues to work when the project changes.

A function can work perfectly today and break tomorrow after a small refactor.

A new feature can accidentally affect an older one.

A seemingly harmless change can introduce a regression somewhere else.

This is where automated testing becomes essential.

Introducing: Python Testing with pytest

I’ve just published the second capsule in my Ahmed Adawy Tech Capsules series:

Python Testing with pytest — A Practical Guide to Writing Reliable Tests

This capsule is designed as a practical introduction to automated testing with Python’s pytest framework.

It focuses on the concepts developers actually need when moving from manual checking to a repeatable testing workflow.

What you’ll learn

The capsule starts from the fundamentals and progressively builds the testing mindset.

It covers topics such as:

• Why automated testing matters

• Installing and running pytest

• Writing your first test

• Assertions

• Testing normal behavior

• Testing edge cases

• Testing exceptions

• Verifying exception messages

• Writing focused tests

• Arrange / Act / Assert

• Running individual tests

• Understanding pytest output

• Structuring tests for real Python projects

And it doesn’t stop at simply showing syntax.

The goal is to understand why these techniques matter and how they fit into a real development workflow.

A simple example

A pytest test can be surprisingly readable:

def test_add():
    result = add(2, 3)

    assert result == 5

The test tells a story:

Arrange → Act → Assert

Prepare the input.

Execute the behavior.

Verify the result.

That simplicity is one of the reasons pytest has become such a practical choice for Python testing.

Testing failure is testing too

Reliable software isn’t only about successful inputs.

Invalid behavior needs to be tested as well.

For example:

import pytest


def test_divide_by_zero():
    with pytest.raises(ValueError):
        divide(10, 0)

Now the test verifies that the software doesn’t merely fail — it fails in the expected way.

That’s an important distinction when building dependable applications.

Why I created this capsule

I wanted this capsule to be useful to someone who already knows basic Python but wants to move toward a more professional development workflow.

Instead of treating testing as something added at the end of a project, the capsule presents testing as part of the development process itself.

The bigger idea is simple:

Your tests become a safety net for your code.

The more your project grows, the more valuable that safety net becomes.

📚 The full capsule

The complete capsule goes beyond the introductory material and explores the techniques needed for larger Python projects, including:

Fixtures • Parametrization • Reusable Test Setup • Advanced Exception Testing • Test Organization • Code Coverage • Continuous Integration • Real-World Testing • Professional Testing Practices

The capsule is approximately 45 pages and is part of the growing Ahmed Adawy Tech Capsules series.

🚀 Who is this for?

This capsule is especially useful for:

• Python developers

• Students learning software engineering

• Developers moving from scripts to larger projects

• Anyone starting with automated testing

• Developers who want to introduce pytest into their workflow

You don’t need to be a testing expert.

You just need a working understanding of Python and a willingness to start testing your code properly.

The bigger goal

This capsule is part of a larger project I’m building:

Ahmed Adawy Tech Capsules

Short, focused technical books designed to turn complex engineering concepts into practical, readable learning material.

One topic.

One focused capsule.

One practical engineering skill at a time.

📖 Python Testing with pytest

A Practical Guide to Writing Reliable Tests

Author: Ahmed Adawy
Series: Ahmed Adawy Tech Capsules
Category: Python / Testing
Level: Intermediate
Length: ~45 pages

If you’re writing Python seriously, automated testing is no longer just a “nice to have.”

It’s part of building software you can trust.

Keep testing. Keep improving. Keep building. 🚀

#Python #pytest #SoftwareTesting #SoftwareEngineering #Programming #Automation #DeveloperTools

I’m starting a small experiment with a simple idea:

What if technical books didn’t always have to be long?

That’s the idea behind Ahmed Adawy Tech Capsules — focused technical micro-books built around one practical topic at a time.

The first capsule is now available:

📘 GitHub Actions for Python Projects

A Practical Guide to CI/CD Automation

This capsule is about turning repetitive Python project tasks into an automated workflow using GitHub Actions.

It covers:

• Python environment setup

• Dependency management

• Automated testing with pytest

• Coverage reports

• Documentation builds

• Artifact generation

• Workflow organization

• CI/CD execution flow

• Reusable automation patterns

I deliberately kept the scope focused.

No attempt to turn it into a giant DevOps textbook.

Just a practical guide for developers who want their Python repositories to do more work automatically.

📚 Read the capsule on Leanpub:

[Leanpub link]

🔧 Project repository:

https://github.com/adawy20262026-oss/ahmed-adawy-tech-capsules

This is only Capsule #1.

The goal is to build a growing collection of short, focused technical books around real developer problems.

If you’re interested in Python, automation, CI/CD, testing, or developer tooling, I’d love to have you follow the series.

— Ahmed Adawy

#Python #GitHubActions #CICD #DevOps #TechWriting

For the past weeks, I have been building a project that combines technical writing, automation, and software engineering into a single publishing workflow.

Today I'm happy to introduce **Ahmed Adawy Tech Capsules**.

A Python-powered publishing engine that transforms Markdown documents into professional technical publications.

---

## Why I Built It

Writing technical content is easy.

Publishing it professionally is not.

Most technical writers spend hours formatting documents, creating PDF files, styling pages, generating tables of contents, and maintaining documentation.

I wanted one command to do everything.

---

## Features

- Professional HTML rendering

- Beautiful PDF generation using WeasyPrint

- Automatic cover pages

- Automatic Table of Contents

- Syntax highlighting powered by Pygments

- Metadata support

- Modular architecture

- Library index generation

- Streamlit Web Interface

- GitHub Actions CI/CD

- Automated testing

---

## Architecture

The project follows a modular architecture.

```

Markdown

│

▼

Metadata Parser

│

▼

Markdown Parser

│

▼

HTML Renderer

│

├── Cover Renderer

├── TOC Renderer

├── Content Renderer

├── Footer Renderer

│

▼

PDF Generator

│

▼

Professional PDF

```

Each component has a single responsibility, making the project easy to maintain and extend.

---

## Current Statistics

- Python 3.12

- 54 automated tests

- 94% test coverage

- GitHub Actions CI

- MIT License

- First Stable Release (v1.0.0)

---

## Technologies

- Python

- Markdown

- WeasyPrint

- Pygments

- PyYAML

- Streamlit

- Pytest

- GitHub Actions

---

## Open Source

The project is completely open source.

Contributions, ideas, and feedback are always welcome.

GitHub Repository:

https://github.com/adawy20262026-oss/ahmed-adawy-tech-capsules

---

## What's Next

The roadmap includes:

- 100% test coverage

- CLI interface

- Multiple themes

- EPUB export

- PyPI package

- Plugin system

- AI-assisted publishing

---

Thank you for reading.

If you enjoy technical writing, Python, or documentation tooling, I'd love to hear your thoughts.

There is a specific kind of developer pain that only happens at 2:00 AM.

Your code compiles. Your tests pass with flying colors. You build a sleek Python/AI microservice, write a few clean modules,wrap it up nicely, and push it to production or cloud runtime. Everything looks smooth, the demo works, and for the first few minutes, you feel like a genius.

Then, under real user traffic, the memory consumption starts creeping up. 100MB... 500MB... 1.5GB... Crash. OOMKilled (Out of Memory).

If you are a Computer Science student, AI Engineer, or Software Developer building data & text pipelines, you’ve probably blamed garbage collection, blamed Streamlit, or blamed Python itself.

Here is the truth about what actually broke, and how we solved it.

🛠️ The Problem: Hidden C-Level Memory Leaks in Python Pipelines

When we build AI wrappers or document transformation tools (converting Markdown/HTML to professional PDFs using packages like weasyprint, cairo, or heavy ML models), we rely heavily on C-extensions under the hood.

Python developers trust Python’s Automatic Garbage Collector (gc). But here is the catch:

Python’s garbage collector only manages Python objects. It has ZERO visibility or control over memory allocated at the C-library level (libgobject, libcairo, or C++ bindings).

When your backend processes requests

continuously:

1. Python creates C-level pointers for rendering or model inference.

2. The Python object dies after the request finishes.

3. The C-level memory chunk remains allocated in system RAM because the shared library didn’t explicitly trigger a release.

To the system, your app looks like a memory sponge.

⚡ The Solution: Process Isolation & Defensive Pipeline Design

Instead of fighting C-level garbage collection inside the main runtime thread, the architectural solution lies in Process Isolation & Explicit Context Cleanup.

Here is how to solve it natively in Python:

1. Isolated Execution via multiprocessing

By offloading heavy rendering or inference tasks into a temporary worker process,

system RAM is forcibly reclaimed by the OS the moment the worker process terminates.

import multiprocessing as mp

def isolated_heavy_task(input_data, output_queue):

# Heavy C-library calls / PDF rendering / Heavy AI inference happens here

result = perform_rendering(input_data)

output_queue.put(result)

def safe_execution(input_data):

queue = mp.Queue()

process = mp.Process(target=isolated_heavy_task, args=(input_data, queue))

process.start()

# Retrieve result and ensure process termination

result = queue.get()

process.join() # OS automatically frees 100% of C-level RAM here

return result

2. Explicit Ctypes & Temporary File Flushing

If you are generating heavy PDF artifacts or manipulating raw text buffers:

Never keep binary streams held indefinitely in application memory.

Flush explicitly to /tmp storage and use context managers (with) to enforce clean file descriptor closures immediately after execution.

💡 The Takeaway for Engineers & CS Students

Building software that works on localhost takes a few hours.

Building software that survives real-world edge cases, shared libraries, and server constraints takes real architectural engineering.

Don't just write scripts that execute—build systems that clean up after themselves.

What’s the most frustrating runtime or memory bug you’ve ever had to debug in production? Let's discuss in the comments below! 🛠️

When I first started using Docker, I kept searching for the same commands over and over again.

Eventually, I realized that I only needed a handful of commands for 90% of my daily work.

Here are the four Docker commands I use the most.

---

## 1. Build an Image

```bash

docker build -t myapp:v1 .

```

This command creates a Docker image from your Dockerfile.

I always use version tags instead of `latest` because it makes deployments easier to track and roll back.

---

## 2. Run a Container

```bash

docker run -d -p 8080:8080 --name myapp_instance myapp:v1

```

What this does:

- Runs the container in the background

- Maps port **8080** on your machine to the container

- Gives the container a readable name

Instead of random container IDs, I can simply reference `myapp_instance`.

---

## 3. Monitor What's Happening

```bash

docker ps

```

Shows all running containers.

Need to inspect logs?

```bash

docker logs -f myapp_instance

```

The `-f` flag streams logs in real time, which is incredibly useful when debugging startup issues.

---

## 4. Stop and Remove Cleanly

```bash

docker stop myapp_instance && docker rm myapp_instance

```

One command.

No leftover containers.

No unnecessary clutter.

---

## A Small Habit That Saves Time

I almost never use anonymous containers during development.

Naming containers makes debugging, logging, restarting, and scripting much easier.

It seems like a tiny habit, but it saves a surprising amount of time over the long run.

---

### Quick Reference

```bash

docker build -t myapp:v1 .

docker run -d -p 8080:8080 --name myapp_instance myapp:v1

docker ps

docker logs -f myapp_instance

docker stop myapp_instance && docker rm myapp_instance

```

That's it.

You don't need to memorize dozens of Docker commands.

Master these four first, and you'll already handle most day-to-day Docker workflows with confidence.

---

If you found this useful, save it for later—you'll probably need these commands again.

---

Practical Python Implementation: Simulating Lattice-Based Key Generation

Understanding the mathematical foundation behind post-quantum cryptography using a simple Python implementation.

---

Why Lattice Cryptography?

Quantum computers threaten many of today's public-key cryptographic systems, including RSA and Elliptic Curve Cryptography.

One of the strongest candidates for replacing them is Lattice-Based Cryptography, the mathematical foundation behind algorithms such as CRYSTALS-Kyber, selected by NIST for the post-quantum era.

Real implementations involve advanced polynomial algebra and high-dimensional lattices.

However, before diving into those complexities, it's helpful to understand the core mathematical intuition.

---

The Idea

Instead of implementing the complete Kyber algorithm, this educational example demonstrates how a hidden lattice basis can generate a public lattice while keeping the private structure secret.

The example illustrates:

Mathematical vectors

Linear combinations

Public and private lattice bases

Shared secret generation

Why recovering the private basis is computationally difficult

The objective is education - not production cryptography.

---

Python Example

import random

def vector_add(v1, v2):

return [x + y for x, y in zip(v1, v2)]

def scalar_multiply(scalar, vector):

return [scalar * x for x in vector]

private_basis_v1 = [1, 0]

private_basis_v2 = [0, 1]

scalar_a = 51

scalar_b = 73

public_v1 = vector_add(

scalar_multiply(scalar_a, private_basis_v1),

scalar_multiply(scalar_b, private_basis_v2)

)

secret_multiplier = 142

shared_secret = scalar_multiply(secret_multiplier, public_v1)

print(shared_secret)

---

What Happens Here?

The script performs the following steps:

Creates a simple private lattice basis.

Produces a transformed public basis.

Simulates a shared secret generated on the public lattice.

Demonstrates the core intuition behind lattice-based cryptography.

Although this example uses only two dimensions, the same concepts scale to hundreds of dimensions in real post-quantum cryptographic systems.

---

Why This Matters

The security of lattice cryptography does not rely on prime factorization like RSA.

Instead, it depends on the computational hardness of mathematical lattice problems such as:

Shortest Vector Problem (SVP)

Closest Vector Problem (CVP)

Learning With Errors (LWE)

These problems remain difficult even for large-scale quantum computers, making lattice cryptography one of the most promising foundations for future secure communication.

---

Educational Purpose

This implementation is intentionally simplified to help students and engineers understand the underlying mathematical concepts before studying full post-quantum algorithms such as:

CRYSTALS-Kyber

Dilithium

Falcon

Learning the intuition first makes advanced cryptographic research much easier to approach.

---

Final Thoughts

Modern cybersecurity is increasingly becoming applied mathematics.

Understanding the mathematics behind cryptographic algorithms is just as important as learning to implement them.

Every secure communication protocol begins with mathematical ideas that can often be explained through surprisingly simple code.

---

If you enjoyed this article, consider following my work for more content on:

Scientific Python

Computational Mathematics

AI Engineering

Numerical Methods

Cybersecurity

Post-Quantum Cryptography

---

#Python #CyberSecurity #PostQuantumCryptography #LatticeCryptography #Cryptography #Mathematics #Programming #SoftwareEngineering #OpenSource #AI #NumPy #ComputerScience

---

During my journey studying computational engineering, I noticed something surprising.

Most textbooks do an excellent job explaining the mathematics behind engineering problems.

They derive differential equations.

They prove theorems.

They analyze physical models.

But they rarely answer one practical question:

**How do we transform those equations into software?**

There is a huge gap between understanding an equation and building a simulator that actually solves it.

For example...

A neutron diffusion equation on paper eventually becomes:

• A discretized numerical model

• A sparse matrix

• A linear algebra problem

• A Python implementation

• A working scientific application

That transformation is where real engineering happens.

Writing software forces you to understand every assumption, every approximation, and every numerical decision.

That's why I believe:

> Code is the ultimate proof of understanding.

This idea is the motivation behind my current open-source work and technical writing.

I'm building educational projects focused on:

• Scientific Python

• Numerical Methods

• Software Architecture

• AI Engineering

• Reactor Physics

The goal isn't simply to explain theory.

The goal is to transform theory into working software that anyone can study, modify, and improve.

If engineering education is going to evolve, I think we need more simulation projects—and fewer isolated equations on paper.

What do you think?

Should engineering education spend more time teaching students how to build scientific software?

#Python #ScientificComputing #AI #Engineering #NumPy #OpenSource #SoftwareArchitecture

If you’ve ever opened classics like *Introduction to Nuclear Engineering* by Lamarsh or *Nuclear Reactor Analysis* by Duderstadt & Hamilton, you’ve probably admired the elegance of reactor physics.

You’ll derive the neutron transport equation, study diffusion theory, analyze reactor criticality, and work through sophisticated mathematical models.

But the moment you open VS Code, PyCharm, or Jupyter Notebook and try to build even a simple reactor simulator, you encounter something textbooks rarely discuss:

A massive engineering gap.

The gap isn’t in the physics.

It’s in translating mathematical models into reliable numerical software.

The journey actually looks like this:

```

Continuous Physics

↓

Numerical Discretization

↓

Linear Algebra

↓

Algorithms

↓

Working Python Code

```

Most classical textbooks master the first step.

Scientific software lives in the last four.

---

# From Differential Equations to Numerical Algorithms

Consider one of the most fundamental equations in reactor physics: the one-dimensional steady-state neutron diffusion equation with an external source.

\[

D\frac{d^2\phi}{dx^2}-\Sigma_a\phi+S=0

\]

where

- **D** is the diffusion coefficient

- **φ** is the neutron flux

- **Σa** is the macroscopic absorption cross section

- **S** is the external neutron source

Beautiful.

Elegant.

Impossible for a computer to solve directly.

Computers don’t understand derivatives.

They understand numbers.

---

# Step 1 — Discretize the Reactor

Instead of treating space as continuous, we divide the reactor into equally spaced nodes.

Using the finite difference approximation,

\[

\frac{d^2\phi}{dx^2}

\approx

\frac{\phi_{i+1}-2\phi_i+\phi_{i-1}}{\Delta x^2}

\]

the governing equation becomes

\[

D

\left(

\frac{\phi_{i+1}-2\phi_i+\phi_{i-1}}

{\Delta x^2}

\right)

-

\Sigma_a\phi_i

+

S_i

=

0

\]

The differential equation has now become a collection of algebraic equations.

---

# Step 2 — Build a Linear System

Rearranging the terms gives

\[

\left(\frac{D}{\Delta x^2}\right)\phi_{i-1}

-

\left(

\frac{2D}{\Delta x^2}

+\Sigma_a

\right)\phi_i

+

\left(\frac{D}{\Delta x^2}\right)\phi_{i+1}

=

-S_i

\]

Instead of solving calculus,

we solve

\[

A\Phi=B

\]

where

- **A** is a tridiagonal matrix representing neutron leakage and absorption,

- **Φ** is the unknown neutron flux vector,

- **B** contains the external source.

This is where reactor physics becomes numerical linear algebra.

---

# Step 3 — Solve the System in Python

Once the mathematical model has been transformed into matrix form, implementing the solver becomes straightforward.

```python

import numpy as np

def solve_1d_reactor_flux(core_length,

num_nodes,

D,

Sigma_a,

source_strength):

dx = core_length / (num_nodes - 1)

x = np.linspace(0, core_length, num_nodes)

A = np.zeros((num_nodes, num_nodes))

B = np.zeros(num_nodes)

leakage = D / dx**2

center = -(2*leakage + Sigma_a)

for i in range(1, num_nodes-1):

A[i,i-1] = leakage

A[i,i] = center

A[i,i+1] = leakage

B[i] = -source_strength

# Vacuum boundary conditions

A[0,0] = 1

A[-1,-1] = 1

flux = np.linalg.solve(A,B)

return x, flux

```

Notice something important.

We are **not performing matrix inversion**.

`numpy.linalg.solve()` uses optimized LAPACK routines to solve the linear system directly, which is both faster and numerically more stable than explicitly computing an inverse matrix.

That distinction matters in scientific computing.

---

# Where Classical Textbooks and Scientific Software Meet

Today’s learning resources usually fall into one of two categories.

### Classical reactor physics textbooks

Books by Lamarsh, Duderstadt & Hamilton, and Stacey provide the theoretical foundation needed to understand diffusion theory, neutron transport, reactor kinetics, and nuclear engineering.

They explain **why the equations work**.

### Production simulation codes

Projects like OpenMC, Serpent, and MCNP are industrial-strength scientific codes capable of solving extremely sophisticated neutron transport problems.

They demonstrate **how professionals simulate reactors**.

However, for many students and software engineers, there is still a missing middle layer:

How do you build a simulator yourself?

How do you translate equations into maintainable Python code?

How do you organize numerical algorithms into software architecture?

That bridge is rarely discussed.

---

# A Different Learning Perspective

Instead of replacing classical reactor physics books, numerical programming complements them.

| Resource | Primary Focus |

|-----------|---------------|

| Lamarsh | Reactor physics fundamentals |

| Duderstadt & Hamilton | Mathematical reactor analysis |

| Stacey | Advanced reactor engineering |

| Practical Python implementations | Numerical algorithms and simulator architecture |

These aren’t competing approaches.

They’re different layers of the same discipline.

Physics explains the model.

Numerical analysis transforms the model.

Software engineering turns the numerical method into a maintainable simulator.

---

# Final Thoughts

Writing code forces us to confront every assumption hidden inside an equation.

Boundary conditions.

Grid spacing.

Matrix assembly.

Numerical stability.

Data structures.

Algorithmic complexity.

That is why implementing a physical model is often the deepest form of understanding it.

Equations describe reality.

Algorithms make them computable.

Software makes them useful.

If you’re interested in exploring this bridge between reactor physics and practical scientific programming, I’ve been documenting my own approach in a Leanpub book focused on building reactor simulators from scratch using Python and NumPy.

I hope it helps make the transition from equations on paper to working simulation software a little less intimidating.

​When you are preprocessing massive datasets, calculating custom loss functions, or manipulating tensor vectors, throwing a standard Python loop at the problem is like driving a tractor on a highway.

​Let’s look at why this happens and how we can achieve a 100x+ speedup using Hyper-Drive vectorization techniques.

​The Bottleneck: Why Python Loops Fail at Scale

​To understand the latency, we have to look under the hood of the CPython interpreter. Every time a standard Python loop runs:

1. ​Dynamic Type Checking: Python checks the data type of the variable on every single iteration.

2. ​Interpreter Overhead: The loop overhead itself adds massive bytecode execution lag.

3. ​Memory Fragmentation: Appending to standard Python lists doesn’t guarantee contiguous memory allocation, destroying CPU cache efficiency.

​When dealing with 1,000,000 data points in an AI pipeline, this translates to agonizingly slow execution times.

​The Hyper-Drive Solution: Vectorization

​Instead of processing elements sequentially (Single Instruction, Single Data), we shift the workload to optimized low-level machine code via NumPy, utilizing SIMD (Single Instruction, Multiple Data) architectures. This allows the CPU (or GPU) to execute operations on entire arrays simultaneously at native C speeds.

​The Head-to-Head Benchmark

​Let’s put theory into practice. Here is a clean, production-ready benchmark script comparing a traditional raw Python loop against a vectorized implementation.

import time

import numpy as np

# Size of the dataset (1 Million elements)

N = 1000000

# 1. Slow Pure Python Loop Approach

def slow_loop(arr):

result = []

for x in arr:

# Simulating a basic linear mathematical transformation

result.append(x * 2 + 5)

return result

# 2. Fast Vectorized Implementation

def fast_vectorized(arr):

return arr * 2 + 5

if __name__ == “__main__”:

# Prepare data allocations

data_list = list(range(N))

data_array = np.arange(N)

print(”🚀 Running performance benchmarks...”)

# Timing the pure python loop

start = time.time()

res_slow = slow_loop(data_list)

end = time.time()

time_slow = end - start

print(f”🛑 Pure Python Loop Time: {time_slow:.4f} seconds”)

# Timing the vectorized execution

start = time.time()

res_fast = fast_vectorized(data_array)

end = time.time()

time_fast = end - start

print(f”⚡ Vectorized Hyper-Drive Time: {time_fast:.4f} seconds”)

# Calculating the speedup factor

print(f”🔥 Speedup Factor: {time_slow / time_fast:.1f}x Faster!”)

The Results: The Numbers Don’t Lie

​When running this setup on a standard development machine, the output is striking:

• ​Pure Python Loop Time: ~0.0850 seconds

• ​Vectorized Implementation Time: ~0.0007 seconds

• ​Performance Jump: ~120x Faster!

​By eliminating the Python interpreter’s loop overhead, the computation finishes in a fraction of a millisecond. In a real-world AI pipeline training on gigabytes of data, this optimization saves hours of compute time and slashes cloud infrastructure costs.

​Going Deeper: Beyond Vectorization

​Vectorization is just the first step. When building high-performance AI architectures, you eventually need to cross the bridge from high-level Python wrappers down to bare-metal hardware optimization, GPU compilation, and custom machine code.

​If you want to master the underlying mathematical frameworks and hardware-level algorithms that power ultra-fast AI execution, check out my comprehensive blueprint book on Leanpub:

👉 The Hyper-Drive Algorithms: From Raw Python Formulas to High-Performance GPU & Machine Code

​Stop letting unoptimized loops throttle your machine learning models. Vectorize your pipelines, keep your data contiguous, and let the hardware do what it was built to do.

​But then, an automated security audit flags your deployment, or worse, a malicious actor exploits a dependency vulnerability and gains absolute control over your host cloud server.

​Why? Because of one silent, pervasive mistake: You ran your Docker container as root.

​By default, unless specified otherwise, Docker runs every process inside the container with root privileges. If an attacker manages to break out of your application process via a container breakout vulnerability, they instantly inherit root access to your entire virtual private server (VPS).

​In this quick guide, we’ll dismantle this problem, fix it from scratch, and show you how easy it is to deploy battle-tested, secure containers.

​The Problem: The Naive Dockerfile

​Look at this common Dockerfile configuration used by thousands of developers daily:

# A standard, but insecure Node.js setup

FROM node:18-alpine

WORKDIR /app

COPY package*.json ./

RUN npm ci --only=production

COPY . .

EXPOSE 3000

# Trapped! Running implicitly as root

CMD [”node”, “server.js”]

If you inspect the running processes inside this container on your VPS, you’ll notice that node server.js is executed by user ID 0 (root). If your app gets compromised, your host system is compromised.

​The Solution: Dropping Privileges (Non-Root Hardening)

​Fixing this doesn’t require complex orchestration tools. It only requires understanding the underlying Linux user environment and leveraging built-in image features. Official images like node already come with a secure, pre-configured non-root user called node.

​Here is the production-ready, hardened version of the exact same environment:

FROM node:18-alpine

WORKDIR /app

# Copy dependency manifests

COPY package*.json ./

# Install production dependencies only

RUN npm ci --only=production

# Copy application source code

COPY . .

EXPOSE 3000

# The Magic Line: Instantly switch from root to limited privileges

USER node

CMD [”node”, “server.js”]

By simply introducing USER node before your execution command, the application drops its root capabilities completely. If a vulnerability is triggered, the blast radius is confined tightly inside a sandboxed, low-privilege environment.

​The Production Cleanup & Firewall Layer

​Securing your container is only half the battle; you must also secure the Linux environment hosting it. When managing a VPS, ensuring proper networking and storage hygiene is crucial.

​1. Hardening the Network (UFW Firewall)

​Never leave your server ports completely exposed to the open web. Before launching your containers, restrict incoming traffic using the Uncomplicated Firewall (UFW) to allow only essential administration and web traffic:

# Deny everything by default, allow standard management and web ports

sudo ufw default deny incoming

sudo ufw default allow outgoing

sudo ufw allow 22/tcp # SSH

sudo ufw allow 80/tcp # HTTP

sudo ufw allow 443/tcp # HTTPS

sudo ufw enable

2. Reclaiming Disk Space

​Building multiple versions of images can quickly fill up your server’s storage. Run a strict maintenance loop to prune dangling layers, unused containers, and unreferenced volumes:

docker system prune -a --volumes

Stop Guessing Your Production Configs

​Modern software development requires moving fast, but local development and production deployments shouldn’t feel like two completely different worlds. You shouldn’t have to wade through 500 pages of dense theoretical text just to spin up a secure, multi-container architecture.

​If you want a condensed, zero-fluff reference guide packed with ready-to-use Linux CLI commands, production multi-container docker-compose setups with databases, and ultimate security checklists, check out my latest handbook:

​👉 The Production-Ready Docker & Linux Pocket Guide

​What is your container security routine? Do you always implement non-root users in your pipelines, or do you rely entirely on cloud-level firewalls to protect your workloads? Let’s discuss in the comments below!

​Before a Transformer model can generate a single cohesive token, it must first solve a fundamental computer science and mathematical problem: How do we translate the chaotic, non-linear, and nuanced nature of human language into something a machine can calculate deterministically?

​The answer isn’t magic. It is high-dimensional vector spaces and matrix factorization.

​In this first comprehensive deep-dive of our series, “The Foundations of Text as Space,” we are stripping away the high-level API abstractions—no PyTorch wrappers, no Hugging Face shortcuts—to look directly at the exact linear algebra that powers modern Large Language Models (LLMs).

​Here is the exact structural breakdown of what we are dissecting in Chapter 1:

​1. High-Dimensional Geometry: Mapping Words to R^n

​Words do not exist as isolated text strings or basic ASCII characters to a neural network; they exist as absolute coordinates in a massive, multi-dimensional real-number space (R^n). We explore exactly how semantic meaning is translated into spatial distance, demonstrating how historical semantic relationships like “King - Man + Woman = Queen” are not just clever linguistic metaphors, but actual vector displacements occurring inside a continuous geometric manifold.

​2. The Linear Algebra of Distance Metrics in AI

​How does an artificial intelligence system actually evaluate and “understand” that two distinct sentences share an identical contextual meaning? It calculates the formal mathematical space between them. We dismantle the specific enterprise use cases, structural strengths, and geometric trade-offs of the core mathematical metrics:

• ​Dot Product: Measuring both directional alignment and vector magnitude concurrently.

• ​Cosine Similarity: The industry standard for orientation-only comparison within unnormalized multi-dimensional vector spaces.

• ​Euclidean Distance: Computing the straight-line metric within high-dimensional grids.

​3. Word2Vec and Matrix Factorization: How Networks Distill Meaning

​Before modern multi-layer Transformers took over the ecosystem, there was a foundational architectural shift centered on capturing raw context efficiently. We revisit the core mechanics of Word2Vec and the inherent mathematical elegance of matrix factorization, showcasing how neural architectures successfully compress massive, sparse co-occurrence statistics into dense, low-rank semantic embeddings.

​4. Practical Python: Building a Vector Search Engine From Scratch

​We do not believe in pure theory without actual code execution. To close out this foundational chapter, we implement a functional Custom Vector Search & Semantic Text Similarity Engine from scratch using pure Python. No external vector database libraries, no pre-built abstractions—just raw logic, loops, and mathematical arrays to show you exactly how vector retrieval blocks operate under the hood.

​Here is a preview of the raw logic implemented in standard Python without external dependencies, calculating the exact mathematical definition of Cosine Similarity:

def dot_product(v1, v2):

return sum(x * y for x, y in zip(v1, v2))

def magnitude(v):

return sum(x ** 2 for x in v) ** 0.5

def cosine_similarity(v1, v2):

prod = dot_product(v1, v2)

mag1 = magnitude(v1)

mag2 = magnitude(v2)

if not mag1 or not mag2:

return 0.0 # Handle zero-vector edge case

return prod / (mag1 * mag2)

# Quick validation check in a 3D vector space

apple_vector = [0.89, 0.12, 0.01]

orange_vector = [0.85, 0.15, 0.05]

print(f”Semantic Similarity: {cosine_similarity(apple_vector, orange_vector):.4f}”)

In the full chapter text, we scale this exact geometric intuition up to high-dimensional matrices, optimizing the search loops to process entire text corpora efficiently.

​Get the Full Architectural Blueprint

​This deep-dive is just the beginning. If you want to master the complete mathematical and practical implementation of neural networks from scratch—moving from mathematical equations directly into highly optimized code—check out the full book on Leanpub:

​👉 The Architecture of Thought

https://leanpub.com/thearchitectureofthought1

​The Production Reality Check

​Most modern software practitioners know how to call an external .embed() function or run basic queries against an out-of-the-box hosted vector database. However, when production retrieval systems fail, or when your semantic search pipelines return noisy results, high-level intuition ceases to be enough. You need a granular understanding of the geometry of the space your underlying data lives in.

​What are your personal thoughts on high-dimensional vector space limitations?

When engineering search and retrieval architectures, do you find yourself tuning the distance metrics themselves, or is your primary performance bottleneck situated within the embedding model’s dimensionality? Let’s discuss your architectural experiences in the comments below.

​This post is part of our comprehensive technical series. Stay tuned for Chapter 2, where we will dive into the pure matrix calculus of Queries, Keys, and Values in the Scaled Dot-Product Attention Mechanism.

​Python is the undisputed king of AI and Applied Mathematics due to its expressive and clean syntax. It allows us to write code that looks remarkably close to pure mathematical formulas. But behind this beauty lies a brutal truth: Python imposes a heavy tax on execution speed and memory efficiency.

​When we scale our AI workflows to millions of matrix operations, relying on traditional for loops turns your production environment into a crawl. To fix the hardware limitations, we must first understand how Python interacts with the hardware.

​The Anatomy of a Slow Loop

​Consider the simple task of squaring 10 million elements. A naive Python implementation looks like this:

def calculate_squares(n):

result = []

for i in range(n):

result.append(i**2)

return result

This takes seconds to execute. Why? Because the Python interpreter is running multiple hidden operations under the hood during every single iteration:

• ​Dynamic Type Checking: Because Python is dynamically typed, it doesn’t know data types in advance. At every step, it checks the objects, creating massive latency.

• ​Memory Fragmentation & Cache Misses: Python arrays don’t hold actual numbers; they hold pointers to distinct Python objects scattered randomly across your RAM. This causes the ultra-fast L1/L2/L3 CPU caches to miss constantly, forcing the processor to wait for the slower system RAM.

• The GIL (Global Interpreter Lock): This internal lock restricts execution to a single CPU core, rendering multi-threaded mathematical calculations useless in pure Python.

​CPU-Bound vs. Memory-Bound Bottlenecks

​To think like a performance engineer, you must identify your enemy:

• CPU-Bound: Your bottleneck is the processor’s clock speed, slammed with intense floating-point math.

• ​Memory-Bound: The bottleneck is data bus bandwidth. The CPU spends too much time idling because pure Python scatters data randomly across the memory layout.

​The Empirical Proof: Benchmarking the Euclidean Norm

​In data normalization and real-time vector embedding similarity, calculating the Euclidean Norm (Magnitude) of a large vector is foundational. The formula is straightforward:

$$||v|| = \sqrt{\sum v_i^2}$$

When we run a pure Python benchmark script to calculate this norm for a vector of 5,000,000 random floating-point numbers, it typically takes between 0.4 to 0.7 seconds on a standard modern CPU. In high-frequency production systems where this calculation happens billions of times, this latency is unacceptable.

​Breaking the Chain

​Our enemy isn’t the hardware; it’s how Python talks to it. We don’t need to change our hardware to collapse a 0.5-second execution time down to mere milliseconds—we need to change our memory strategy.

​In the upcoming chapters of my book, we explore our core weapons: Advanced Vectorization with NumPy, JIT Compilation with Numba, and Custom CUDA Kernels to move computing directly to the GPU.

This article is an excerpt from Chapter 1: The Bottleneck of Pure Python, part of The Hyper-Drive Algorithms book.

​I have made the complete Chapter 1 available as a Free Sample on Leanpub so you can review the full architecture, benchmarks, and code frameworks.

​🔗 Read the Free Sample & Get the Book on Leanpub

Nuclear physics has long been perceived as a highly theoretical field, often confined to static textbooks and academic lectures. However, in the era of digital transformation, the reactor engineer’s role has shifted from a passive observer to an active designer of simulated reality.

In my book, The Atomic Engine: Applied Reactor Physics & Computational Simulation, I bridge the gap between theory and execution. This isn't just about formulas; it’s about building a functional framework thatintegrates neutron diffusion kinetics with high-performance computational tools like Python, NumPy, and Numba. We explore how PID controllers and thermal-hydraulic modeling work in tandem to ensure reactor stability.

Why does this matter? Historical failures, such as Chernobyl, remind us that accidents are rarely just physics errors—they are failures to anticipate complex system behaviors under transient conditions. My goal with this work is to help you transition from theory to robust, simulation-driven design.

Whether you are a researcher, a student, or a practicing engineer, this book provides the technical foundation to build systems that prioritize safety-by-design.

Get your copy here:

https://leanpub.com/theatomicengineappliedreactorphysicscomputationalsimulation

​Traditional for loops and naive code will instantly choke your CPU.

​Many developers think the only solution is to rewrite everything in C++ or CUDA. But what if you could turn your raw Python formulas into lightning-fast, production-ready GPU and machine code—without leaving your Python environment?

​Let’s look at a concrete, practical example.

​The Practical Experiment: CPU vs. Accelerated GPU Code

​Imagine you need to apply a complex mathematical transformation (like a custom activation function or an element-wise simulation) over a massive dataset of 10 million points.

​Here is how standard Python/NumPy runs it on the CPU, versus how we can hyper-drive it directly onto the GPU using Numba’s JIT (Just-In-Time) compiler with bare-metal parallelism.

import numpy as np

import time

from numba import vectorize, cuda

# 1. Create a massive dataset (10 Million Elements)

data = np.linspace(1, 10, 10000000).astype(np.float32)

# A complex formula simulating heavy mathematical operations

def raw_math_formula(x):

# Standard math that usually bottlenecks the CPU

return (x ** 2 + np.sin(x)) / (x + 1)

# ---- TEST 1: Standard CPU Execution ----

start_cpu = time.time()

cpu_result = raw_math_formula(data)

end_cpu = time.time()

print(f"Standard CPU Execution Time: {end_cpu - start_cpu:.4f} seconds")

# ---- TEST 2: Hyper-Driven GPU Execution ----

# Using Numba to compile the raw formula into native GPU machine code

@vectorize(['float32(float32)'], target='cuda')

def gpu_math_formula(x):

import math

return (x ** 2 + math.sin(x)) / (x + 1)

# Warm-up the GPU compiler

_ = gpu_math_formula(data[:10])

start_gpu = time.time()

gpu_result = gpu_math_formula(data)

end_gpu = time.time()

print(f"Accelerated GPU Execution Time: {end_gpu - start_gpu:.4f} seconds")

What’s Happening Under the Hood?

​When you run the standard version, Python’s interpreter overhead and CPU core limitations slow down the calculation.

​However, by adding the @vectorize(target=’cuda’) decorator, Numba bypasses the CPU entirely. It compiles your raw mathematical formula directly into LLVM machine code that runs across thousands of parallel GPU cores simultaneously.

​The result? A massive, game-changing speedup for your mathematical pipelines.

​Ready to Master Bare-Metal Hardware Acceleration?

​If you want to stop thinking like a high-level scripter and start thinking like a performance engineer, this is exactly what my latest book is about.

​🚀 “The Hyper-Drive Algorithms: From Raw Python Formulas to High-Performance GPU & Machine Code”

​This book—the seventh volume in the acclaimed Ultimate AI Math & Code Series—is your ultimate engineering blueprint to breaking speed limits.

​What You Will Learn:

• ​Identify the Bottlenecks: Understand exactly why standard Python fails at scale.

• ​Parallelization & Vectorization: Transform slow Python loops into blazing-fast machine code.

• ​GPU & CUDA Programming: Master low-level optimization techniques to claim absolute, unmatched execution speeds.

​Don’t let standard hardware bottlenecks limit your growth as an AI professional. Claim your copy and upgrade your engineering skills today!

​👉 Get the Book Directly on Leanpub Here!

https://leanpub.com/thehyper-drivealgorithmsfromrawpythonformulastohigh-performancegpumachinecodes

​Welcome to my very first post here on Substack.

​If you’ve ever tried to dive into Machine Learning or Artificial Intelligence, you’ve probably run into a massive wall of complex mathematical equations. Linear Algebra, Calculus, Probability... to many programmers, these look like a scary, academic "black box."

​For a long time, the advice was: "Just import the libraries, run model.fit(), and don't worry about the math."

​But here’s the truth: Without understanding the underlying math, you are driving a supercar without knowing how the engine works. When things break—and they will—you won't know how to fix them.

​My name is Ahmed Adawy, and my mission here is simple: To demystify the mathematics of AI and make it practical, intuitive, and directly applicable to code.

​What to Expect From This Newsletter:

​In this newsletter, we won't just look at dry formulas. Instead, we will:

​Deconstruct AI Math: Break down complex algorithms into simple concepts.

​Code the Concepts: Translate every mathematical idea into clean, real-world Python code using libraries like NumPy.

​Build the Foundation: Learn how AI models actually think, optimize, and learn.

​Whether you are a software engineer wanting to transition into AI, a student struggling with academic books, or a tech enthusiast looking for depth, you are in the right place.

​🚀 A Sneak Peek Into My Upcoming Book!

​This newsletter is born from the core philosophy of my book: "Applied Mathematics & Artificial Intelligence".

​If you want to support my journey and get your hands on a comprehensive guide that bridges theory and Python code step-by-step, you can check out the book directly on Leanpub!

​👉 [Click Here to Check Out the Book on Leanpub] (https://leanpub.com/appliedmathematicsartificialintelligenceyourbridgefromformulastopythoncode)

​Thank you for being here at the very beginning. Hit the Subscribe button below to never miss a post, and let’s make AI math make sense—together!