Forem: AHMED HASAN AKHTAR OVIEDO

The Case of the Zombie Transaction: Solving 'Unknown Unknowns' with OpenTelemetry & High Cardinality

AHMED HASAN AKHTAR OVIEDO — Sun, 30 Nov 2025 08:15:19 +0000

There is a massive difference between "Monitoring" and "Observability," yet we often use the terms interchangeably.

Monitoring is looking at a dashboard to see if the CPU usage is above 80%. It answers known questions: "Is the database healthy?"
Observability is the ability to ask new questions about your system without deploying new code. It answers the terrifying questions: "Why are payments failing only for iOS users in Canada using a Visa card?"

Most tutorials show you how to set up a dashboard. This article will show you how to catch a ghost.

We are going to implement Structured Tracing with High Cardinality attributes using OpenTelemetry (OTel). This is the modern standard that works with any backend (Azure Monitor, AWS X-Ray, Datadog, Honeycomb, or Jaeger).

The Scenario: "The Zombie Transaction"

Imagine you run an e-commerce platform. A customer complains: "My credit card was charged, but I never got an order confirmation."

Your logs show 200 OK on the web server. Your database metrics look healthy. You are flying blind. This is a "Zombie Transaction"—the state is inconsistent across microservices.

To solve this, we need Distributed Tracing with Context Propagation.

The Architecture

We will simulate a microservices workflow using Python (FastAPI):

Checkout Service: Initiates the process.
Payment Service: Charges the card (simulated).
Inventory Service: Decrements stock.

If the Payment succeeds but Inventory fails, we have a Zombie Transaction.

Step 1: The Code (Python + OpenTelemetry)

We aren't just logging text; we are creating "Spans". A Span represents a unit of work.

First, install the OTel libraries:

pip install fastapi uvicorn opentelemetry-api opentelemetry-sdk \
opentelemetry-instrumentation-fastapi opentelemetry-exporter-otlp

Now, let's build the app.py. Pay close attention to the set_attribute lines. This is the secret sauce: High Cardinality Data.

import time
import random
import logging
from fastapi import FastAPI, HTTPException
from opentelemetry import trace
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor, ConsoleSpanExporter

# 1. Setup OpenTelemetry
# In a real app, you would export to an OTLP endpoint (Jaeger, Datadog, Azure).
# Here we print to Console for demonstration transparency.
resource = Resource(attributes={"service.name": "checkout-service"})
trace.set_tracer_provider(TracerProvider(resource=resource))
tracer = trace.get_tracer(__name__)
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(ConsoleSpanExporter())
)

app = FastAPI()
logger = logging.getLogger("checkout")

# 2. The Payment Service (Mock)
def process_payment(user_id, amount):
    with tracer.start_as_current_span("payment_gateway_call") as span:
        # OBSERVABILITY BEST PRACTICE:
        # Add "High Cardinality" attributes. 
        # This allows us later to filter traces by specific user IDs.
        span.set_attribute("app.user_id", user_id)
        span.set_attribute("app.payment.amount", amount)

        time.sleep(0.1) # Simulate network latency
        if random.random() < 0.1: # 10% chance of random failure
            span.set_attribute("error", True)
            span.record_exception(Exception("Payment Gateway Timeout"))
            raise Exception("Payment Failed")

        return "tx_12345abc"

# 3. The Inventory Service (Mock)
def reserve_inventory(sku):
    with tracer.start_as_current_span("inventory_reservation") as span:
        span.set_attribute("app.sku", sku)
        time.sleep(0.2)
        # Simulate a logic bug: We have a "Zombie" scenario where 
        # payment succeeded, but inventory crashes.
        if sku == "buggy-item-001":
            raise HTTPException(status_code=500, detail="Inventory Database Locked")
        return True

@app.post("/checkout")
async def checkout(user_id: str, sku: str):
    # This is the "Root Span"
    with tracer.start_as_current_span("checkout_process") as span:
        span.set_attribute("app.user_id", user_id)

        try:
            # Step 1: Charge User
            transaction_id = process_payment(user_id, 99.00)
            span.set_attribute("app.payment.tx_id", transaction_id)

            # Step 2: Reserve Item
            reserve_inventory(sku)

            return {"status": "success", "tx_id": transaction_id}

        except Exception as e:
            # We catch the error, but did the payment happen?
            # The trace will show us exactly where it broke.
            span.record_exception(e)
            span.set_status(trace.Status(trace.StatusCode.ERROR))
            raise HTTPException(status_code=500, detail=str(e))

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8000)

Why this is unique?

Most developers log like this:
logger.error("Error in checkout")

This is useless. In the code above, we injected app.user_id.

When the customer complains, you don't grep logs for "Error". You go to your Observability tool (Jaeger/Datadog/Grafana) and run a query:

app.user_id == "customer_4094"

You will immediately see a Waterfall Visualization showing:

checkout_process (Started)
payment_gateway_call (Success - Money Taken!)
inventory_reservation (Failed - Error: Inventory Database Locked)

You have just proven the "Zombie Transaction" exists without guessing.

Connecting to a Platform (The "How-To")

The code above uses ConsoleSpanExporter so you can see the JSON structure in your terminal immediately without an account.

To send this to a real platform, you simply change one line of code (or purely via Environment Variables).

For Jaeger/Grafana/New Relic/Datadog (via OTLP):

from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

# Replace ConsoleSpanExporter with this:
span_processor = BatchSpanProcessor(OTLPSpanExporter(endpoint="http://localhost:4317"))

Theory: The Three Pillars are Not Enough

We used to talk about Logs, Metrics, and Traces (The Three Pillars). But modern Observability is about Correlation.

In our example:

The Metric (Error Rate) triggers the alert.
The Trace (The Waterfall) shows where the request died.
The Log (The attributes inside the span) tells us who it affected.

Conclusion

Observability is not just about having colorful dashboards. It is about debuggability.

By using OpenTelemetry to standardize your instrumentation and focusing on High Cardinality Attributes (like User IDs, Order IDs, SKU codes), you turn your debugging process from a murder mystery into a simple lookup.

References

Beyond the Context Window: Building a Stateful 'Memory' MCP Server on Cloudflare Workers

AHMED HASAN AKHTAR OVIEDO — Sun, 30 Nov 2025 07:58:57 +0000

Large Language Models (LLMs) like Claude possess incredible reasoning capabilities, but they suffer from a critical flaw: They have no object permanence.

Once you close a chat session, the "mind" is wiped. While features like "Projects" or huge context windows (200k+ tokens) help, they are temporary buffers, not true memory. They are expensive, slow to re-process, and don't persist across different interfaces (e.g., moving from VS Code to the web interface).

To move from Chatbots to true Agents, we need to solve the state problem.

The Theory: The "Sidecar" Memory Pattern

The Model Context Protocol (MCP) is often described as a way to "connect AI to tools." But theoretically, it allows us to decouple the reasoning engine (the LLM) from the state (the data).

Instead of trying to cram everything into the prompt (Context Stuffing), we can use an MCP Server as a Sidecar Attachment.

The Brain: The LLM (Stateless, reasoning-only).
The Hippocampus: Our MCP Server (Stateful, long-term storage).

By building a server that allows the AI to write to a database, not just read from it, we give the model the ability to "learn" user preferences permanently without fine-tuning the model itself.

The Architecture: Why Edge Computing?

For this architecture to work, latency is the enemy. If Claude decides to call a tool to "recall" a memory, and that tool takes 2 seconds to wake up (a cold start), the chat experience feels sluggish.

This is why we are choosing Cloudflare Workers over traditional containers (like Docker/EC2) or standard serverless functions (like AWS Lambda):

0ms Cold Starts: The memory is available instantly.
Global KV Store: Cloudflare KV (Key-Value) replicates data to the edge. If you travel from New York to Tokyo, your AI's memory travels with you.
Native SSE (Server-Sent Events): MCP relies on a persistent connection stream. Workers handle these long-lived connections effortlessly compared to traditional REST APIs.

Today, we will build this. A Read/Write MCP Server that gives your AI a persistent memory bank.

The Tech Stack

Runtime: Cloudflare Workers (TypeScript)
Framework: Hono (Lightweight, web-standard compliant)
Protocol: Model Context Protocol SDK
Storage: Cloudflare KV

Step 1: Initialize the Project

First, let's create a new Worker using Hono. It's much cleaner than raw worker syntax and handles routing beautifully.

npm create hono@latest mcp-memory-vault
# Select "Cloudflare Workers" template
cd mcp-memory-vault
npm install @modelcontextprotocol/sdk eventsource

Step 2: Configure The KV Namespace

We need a persistent place to store our memories. In your wrangler.toml file, add a KV namespace binding. This tells Cloudflare to expose a database to your code.

name = "mcp-memory-vault"
main = "src/index.ts"
compatibility_date = "2024-11-20"

# Add this block
[[kv_namespaces]]
binding = "MEMORY_KV"
id = "YOUR_KV_NAMESPACE_ID" 
# Run 'npx wrangler kv:namespace create MEMORY_KV' to get this ID

Step 3: The Code

Here is the secret sauce. We aren't just creating a server; we are mapping MCP "Tools" to Cloudflare KV operations.

Create a file src/index.ts. Note how we handle the SSE stream—this is the trickiest part of building a remote MCP server.

import { Hono } from 'hono'
import { MCP, Tool } from '@modelcontextprotocol/sdk'
import { SSEServerTransport } from '@modelcontextprotocol/sdk/server/sse'

// Define the shape of our environment
type Bindings = {
  MEMORY_KV: KVNamespace
}

const app = new Hono<{ Bindings: Bindings }>()

// 1. Define the Tools
// We give the AI three abilities: Remember (Write), Recall (Read), and List (Audit).
const TOOLS = [
  {
    name: "remember_fact",
    description: "Stores a specific fact, preference, or snippet for later retrieval.",
    inputSchema: {
      type: "object",
      properties: {
        key: { type: "string", description: "The category or label (e.g., 'project_db_schema')" },
        value: { type: "string", description: "The content to remember" }
      },
      required: ["key", "value"]
    }
  },
  {
    name: "recall_fact",
    description: "Retrieves a stored fact by its key.",
    inputSchema: {
      type: "object",
      properties: {
        key: { type: "string" }
      },
      required: ["key"]
    }
  },
  {
    name: "list_memories",
    description: "Lists all stored memory keys to see what is saved.",
    inputSchema: {
      type: "object",
      properties: {},
    }
  }
];

// 2. The SSE Endpoint (Handshake)
app.get('/sse', async (c) => {
  const transport = new SSEServerTransport('/message', c.res);

  // Initialize MCP Server within the request context
  const server = new MCP.Server({
    name: "cloud-memory",
    version: "1.0.0"
  }, {
    capabilities: {
      tools: {}
    }
  });

  // Register Tools
  server.setRequestHandler(MCP.ListToolsRequestSchema, async () => ({
    tools: TOOLS
  }));

  // Handle Tool Execution
  server.setRequestHandler(MCP.CallToolRequestSchema, async (request) => {
    const { name, arguments: args } = request.params;

    // Connect to Cloudflare KV
    const kv = c.env.MEMORY_KV;

    if (name === 'remember_fact') {
      const { key, value } = args as { key: string, value: string };
      // Check for Spanish preference context (a little easter egg)
      const content = `Guardado exitosamente: ${key}`; 
      await kv.put(key, value);
      return { content: [{ type: "text", text: content }] };
    }

    if (name === 'recall_fact') {
      const { key } = args as { key: string };
      const value = await kv.get(key);
      return { 
        content: [{ 
          type: "text", 
          text: value ? `Memory found: ${value}` : "No memory found for that key." 
        }] 
      };
    }

    if (name === 'list_memories') {
      const list = await kv.list();
      const keys = list.keys.map(k => k.name).join(", ");
      return { content: [{ type: "text", text: `Stored Keys: ${keys}` }] };
    }

    throw new Error(`Tool not found: ${name}`);
  });

  // Connect transport
  await server.connect(transport);

  // Return the stream
  return transport.handleRequest(c.req.raw);
});

// 3. The Message Endpoint (For subsequent communication)
app.post('/message', async (c) => {
  // In a real production app, you might use Durable Objects here for 
  // complex state, but for KV operations, this stateless handler works.
  return c.text("Message received");
});

export default app

Step 4: Deploying

Deploying to the edge is one command:

npx wrangler deploy

You will get a URL like: https://mcp-memory-vault.yourname.workers.dev.

Step 5: Connecting to Claude Desktop

Locate your Claude Desktop configuration file.

Add your new remote server. Note that we use npx -y to run the inspector or a local bridge, as the desktop app typically talks to a local process which then tunnels to the remote URL.

{
  "mcpServers": {
    "cloudflare-memory": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/inspector",
        "[https://mcp-memory-vault.yourname.workers.dev/sse](https://mcp-memory-vault.yourname.workers.dev/sse)"
      ]
    }
  }
}

The Result

Now, open Claude. You can treat it like a teammate with a notebook.

User:

"Please remember_fact with key 'deploy_script' and value 'npm run build && wrangler deploy --env production'"

Claude:

Guardado exitosamente: deploy_script

...Two days later...

User:

"How do I deploy? Check my memories."

Claude (calling recall_fact):

Memory found: npm run build && wrangler deploy --env production

Conclusion

We just built a server that transforms an LLM from a temporary chat interface into a persistent operational partner. By leveraging Cloudflare KV, we ensured it's fast, cheap, and available globally.

The Model Context Protocol isn't just about giving AI access to Google; it's about giving AI access to your world, your context, and your specific way of doing things.

Reference Repository

You can find the underlying SDK and examples at the official repository below:

GitHub: Official Model Context Protocol SDK

Happy Coding!

Repository Pattern: Simplify Data Access in Enterprise Apps

AHMED HASAN AKHTAR OVIEDO — Sun, 02 Nov 2025 19:53:37 +0000

Introduction

Enterprise applications power modern businesses. They manage vast amounts of data, automate workflows, and support critical systems like banking, logistics, and HR. These apps face unique challenges: handling complexity, ensuring scalability, and maintaining clean architecture.

Martin Fowler's Patterns of Enterprise Application Architecture (2002) is a cornerstone. It catalogs patterns from real-world systems, covering layers, domain logic, and data mapping. Among them, the Repository Pattern stands out for data access.

Why It Matters?

Data is king in enterprise apps. The Repository Pattern decouples business logic from data storage. It acts as a mediator, providing a uniform interface for CRUD operations. This promotes testability, flexibility, and maintainability. Without it, code becomes tangled, hard to change.

Today, we dive into the Repository Pattern with a Python example. Let's build an employee management system.

What is the Repository Pattern?

It encapsulates data access. Abstracts CRUD operations (Create, Read, Update, Delete) into a collection-like interface. Domain objects don't touch the DB directly; they use the repository.

Key Benefits:

Clear Separation: Pure business logic, no infrastructure ties.
Easy Testing: Mock repositories for unit tests.
Flexibility: Switch DB (SQL to NoSQL) without breaking code.
Reusable: Common interface for entities.

Practical Example in Python

Employee management system. We use an in-memory list (easy to adapt to real DB).

Employee Entity:

This class represents an employee in our domain. It holds basic attributes like ID, name, position, and salary. The __repr__ method provides a readable string representation for debugging and logging.

class Employee:
    def __init__(self, id: int, name: str, position: str, salary: float):
        self.id = id
        self.name = name
        self.position = position
        self.salary = salary

    def __repr__(self):
        return f"Employee(id={self.id}, name='{self.name}', position='{self.position}', salary={self.salary})"

Repository Interface:

Defines the contract for data access. Uses abstract methods to ensure any implementation (in-memory, SQL, etc.) follows the same interface. This abstraction allows swapping storage without changing business logic.

from abc import ABC, abstractmethod
from typing import List, Optional

class EmployeeRepository(ABC):
    @abstractmethod
    def add(self, employee: Employee) -> None: pass
    @abstractmethod
    def get_by_id(self, id: int) -> Optional[Employee]: pass
    @abstractmethod
    def get_all(self) -> List[Employee]: pass
    @abstractmethod
    def update(self, employee: Employee) -> None: pass
    @abstractmethod
    def delete(self, id: int) -> None: pass

In-Memory Implementation:

A concrete repository using a list. Manages employee data in memory. add assigns a unique ID. get_by_id finds by ID. get_all returns a copy to avoid mutations. update replaces the employee. delete removes by ID. Simple, but demonstrates the pattern.

class InMemoryEmployeeRepository(EmployeeRepository):
    def __init__(self):
        self._employees = []
        self._next_id = 1

    def add(self, employee: Employee) -> None:
        employee.id = self._next_id
        self._next_id += 1
        self._employees.append(employee)

    def get_by_id(self, id: int) -> Optional[Employee]:
        return next((emp for emp in self._employees if emp.id == id), None)

    def get_all(self) -> List[Employee]:
        return self._employees.copy()

    def update(self, employee: Employee) -> None:
        for i, emp in enumerate(self._employees):
            if emp.id == employee.id:
                self._employees[i] = employee
                break

    def delete(self, id: int) -> None:
        self._employees = [emp for emp in self._employees if emp.id != id]

Business Service:

Contains business logic. Depends on the repository interface, not implementation. Methods like hire_employee create and add employees. promote_employee updates position and salary. This layer focuses on rules, not data storage.

class EmployeeService:
    def __init__(self, repository: EmployeeRepository):
        self.repository = repository

    def hire_employee(self, name: str, position: str, salary: float) -> Employee:
        employee = Employee(0, name, position, salary)
        self.repository.add(employee)
        return employee

    def get_employee(self, id: int) -> Optional[Employee]:
        return self.repository.get_by_id(id)

    def list_employees(self) -> List[Employee]:
        return self.repository.get_all()

    def promote_employee(self, id: int, new_position: str, new_salary: float) -> bool:
        employee = self.repository.get_by_id(id)
        if employee:
            employee.position = new_position
            employee.salary = new_salary
            self.repository.update(employee)
            return True
        return False

# Demo
if __name__ == "__main__":
    repo = InMemoryEmployeeRepository()
    service = EmployeeService(repo)

    emp1 = service.hire_employee("Alice Johnson", "Developer", 75000.0)
    emp2 = service.hire_employee("Bob Smith", "Manager", 90000.0)

    print("Employees:")
    for emp in service.list_employees():
        print(emp)

    service.promote_employee(emp1.id, "Senior Developer", 85000.0)
    print("\nAfter promotion:")
    print(service.get_employee(emp1.id))

Result: Modular, testable, scalable code. Business logic is separate from data access, making it easy to test services with mocks and switch repositories.

Conclusion

The Repository Pattern transforms enterprise apps: cleaner, more flexible, maintainable. Try in Python or adapt to your stack.

Read More: Repository in Fowler

References

Fowler, M. (2002). Patterns of Enterprise Application Architecture. Addison-Wesley.
Official site: https://martinfowler.com/eaaCatalog/

From Data to Dashboard: Building Interactive Reports with Streamlit

AHMED HASAN AKHTAR OVIEDO — Sun, 14 Sep 2025 07:42:25 +0000

Summary: In this article, we will explore three powerful Python-based tools for dashboards and reports — Streamlit, Dash, and Bokeh. We will then focus on Streamlit, showcasing how to build a simple but interactive sales dashboard with Python, and finally deploy it to the cloud.

Why Visualization Tools Matter

Turning data into actionable insights requires more than static plots. Tools like Streamlit, Dash, and Bokeh let you create interactive dashboards that allow stakeholders to filter, explore, and make decisions in real time.

Streamlit: Quickest to build, very Pythonic, minimal code.
Dash: More flexible for complex multi-page apps, built on Plotly.
Bokeh: Strong visualization library, often embedded in web apps.

For this article, we’ll use Streamlit, because it combines speed and simplicity.

Real-World Example: Sales Dashboard

We’ll build a small dashboard that:

Shows total sales and average order value.
Lets users filter by product category.

Displays sales trends over time.

# sales_dashboard.py
import streamlit as st
import pandas as pd
import numpy as np

st.set_page_config(page_title="Sales Dashboard", layout="wide")

st.title("📊 Sales Dashboard")
st.markdown("An interactive dashboard to explore sales performance.")

# Generate sample data
@st.cache_data
def load_data():
    np.random.seed(42)
    dates = pd.date_range("2023-01-01", periods=100)
    categories = ["Electronics", "Clothing", "Furniture"]
    data = {
        "date": np.random.choice(dates, 500),
        "category": np.random.choice(categories, 500),
        "sales": np.random.randint(50, 500, 500)
    }
    return pd.DataFrame(data)

df = load_data()

# Sidebar filters
st.sidebar.header("Filters")
categories = st.sidebar.multiselect("Select Category", options=df["category"].unique(), default=df["category"].unique())

# Filter data
df_filtered = df[df["category"].isin(categories)]

# KPIs
total_sales = int(df_filtered["sales"].sum())
avg_order = round(df_filtered["sales"].mean(), 2)

col1, col2 = st.columns(2)
col1.metric("Total Sales", f"${total_sales}")
col2.metric("Avg Order Value", f"${avg_order}")

# Charts
sales_over_time = df_filtered.groupby("date")["sales"].sum().reset_index()
st.line_chart(sales_over_time.set_index("date"))

st.subheader("Detailed Data")
st.dataframe(df_filtered)

Requirements

```
streamlit
pandas
numpy
```

Deploying the Dashboard

Option A: Streamlit Community Cloud

Push your code (sales_dashboard.py + requirements.txt) to GitHub.
Go to Streamlit Community Cloud and sign in with GitHub.
Create a new app, point it to your repository, and select sales_dashboard.py as the entry file.
The platform builds and gives you a shareable URL.

Option B: Render

Push your repo to GitHub.
Create a Web Service on Render.
Set the build command:
```
pip install -r requirements.txt
```

Set the start command:

streamlit run sales_dashboard.py --server.port $PORT --server.address 0.0.0.0

Deploy and get a public URL.

Why Streamlit Works Best Here

Fast prototyping: Build a working dashboard in under 50 lines of code.
Python-native: No need to learn JavaScript or HTML.
Cloud-friendly: One-click deploy with Community Cloud.

Final Thoughts

Dash and Bokeh are fantastic for specific use cases, but if your goal is speed, clarity, and sharing results quickly, Streamlit is often the best tool. With just a few lines of code, you can turn raw data into an interactive dashboard ready for stakeholders.

Design Principles of Software Applied: Practical Example in Python

AHMED HASAN AKHTAR OVIEDO — Sun, 14 Sep 2025 06:39:04 +0000

Design Principles of Software Applied: Practical Example in Python

Summary: In this article I explain key software design principles (SOLID —with emphasis on SRP and DIP—, DRY, KISS, YAGNI) and show a minimal, practical example in Python: a notification service (email + SMS) designed to be extensible, testable, and easy to understand.

Chosen principles

SOLID (SRP, OCP, LSP, ISP, DIP) — emphasis on SRP and DIP.
DRY (Don't Repeat Yourself).
KISS (Keep It Simple, Stupid).
YAGNI (You Aren't Gonna Need It).
Separation of concerns / Testability / Modularity.

Real problem

We need a component that sends notifications to users via multiple channels (e.g., email and SMS). Practical requirements:

Be able to add new channels (Push, Webhook) without changing core logic.
Make unit testing easy without real network calls.
Keep code clear and responsibilities separated.

Design (brief)

Define an abstraction Notifier that represents the contract for sending notifications.
Concrete implementations (EmailNotifier, SMSNotifier) implement the abstraction.
NotificationService coordinates notifiers via dependency injection (it does not know concrete implementations).
External clients (SMTP, SMS provider) are encapsulated and mocked in tests.

Example code (suggested files: `notifiers.py`, `test_notifiers.py`)

```python
# notifiers.py
from abc import ABC, abstractmethod
from typing import List, Dict

class Notifier(ABC):
    """Contract: any Notifier must implement send."""
    @abstractmethod
    def send(self, to: str, subject: str, body: str) -> bool:
        pass

class EmailNotifier(Notifier):
    """SRP: this class only knows how to send emails."""
    def __init__(self, smtp_client):
        # smtp_client encapsulates real sending logic
        self.smtp = smtp_client

    def send(self, to: str, subject: str, body: str) -> bool:
        return self.smtp.send_email(to, subject, body)

class SMSNotifier(Notifier):
    def __init__(self, sms_client):
        self.sms = sms_client

    def send(self, to: str, subject: str, body: str) -> bool:
        # Simplify: use subject as prefix in SMS
        text = f"{subject}: {body}"
        return self.sms.send_sms(to, text)

class NotificationService:
    """DIP: depends on the Notifier abstraction, not concrete classes."""
    def __init__(self, notifiers: List[Notifier]):
        self.notifiers = notifiers

    def notify_all(self, to: str, subject: str, body: str) -> Dict[str, bool]:
        results = {}
        for n in self.notifiers:
            key = n.__class__.__name__
            results[key] = n.send(to, subject, body)
        return results

# Mock clients for demo/local
class MockSMTPClient:
    def send_email(self, to, subject, body):
        print(f"[MockSMTP] Sending email to {to}: {subject} / {body}")
        return True

class MockSMSClient:
    def send_sms(self, to, text):
        print(f"[MockSMS] Sending SMS to {to}: {text}")
        return True

if __name__ == "__main__":
    email_notifier = EmailNotifier(MockSMTPClient())
    sms_notifier = SMSNotifier(MockSMSClient())
    svc = NotificationService([email_notifier, sms_notifier])
    result = svc.notify_all("user@example.com", "Welcome", "Hi, thanks for signing up.")
    print("Result:", result)
```

Tests (example with `pytest` — `test_notifiers.py`)

```python
# test_notifiers.py
from notifiers import Notifier, NotificationService

class DummyNotifier(Notifier):
    def __init__(self):
        self.sent = False
    def send(self, to, subject, body):
        self.sent = True
        return True

def test_notification_service_sends_to_all():
    a = DummyNotifier()
    b = DummyNotifier()
    svc = NotificationService([a, b])
    res = svc.notify_all("u@x.com", "t", "b")
    assert res["DummyNotifier"] is True
    assert a.sent and b.sent
```

How the principles apply here

SRP (Single Responsibility): Each class has a single responsibility: EmailNotifier only sends emails, SMSNotifier only sends SMS, NotificationService only orchestrates.
DIP (Dependency Inversion): NotificationService depends on Notifier (abstraction), not concrete implementations. This allows injecting mocks for testing.
OCP (Open/Closed): To add PushNotifier you do not modify NotificationService; create a new Notifier implementation and register it.
LSP & ISP: Implementations respect the send contract and do not force extra unnecessary methods.
DRY: Transport-specific logic is encapsulated, avoiding duplication.
KISS / YAGNI: Simple design that covers current requirements; no retries, batching, or added complexity until required.
Testability / Modularity: By injecting dependencies and using mock clients, tests are deterministic and fast.

How to run locally

Create a virtual environment (recommended):

python -m venv .venv
source .venv/bin/activate   # Linux/macOS
.venv\Scripts\activate      # Windows
pip install pytest

Run the demo:
```
python notifiers.py
```
Run tests:
```
pytest -q
```

Conclusion

This minimal example demonstrates how to apply design principles to build a notification component that is extensible, testable, and maintainable. By prioritizing abstractions, separation of concerns, and simplicity, the code is prepared to grow (add channels, instrumentation, retries) without becoming fragile.

Transaction Script: Patrón simple para lógica de negocio (Catalog of Patterns of EAA — Martin Fowler)

AHMED HASAN AKHTAR OVIEDO — Sun, 14 Sep 2025 05:34:10 +0000

Transaction Script: A simple pattern to organize business logic

When building enterprise applications, one of the biggest challenges is how to organize business logic. There are many ways to do this, and Martin Fowler, in his well-known book Patterns of Enterprise Application Architecture (2003), proposed a catalog of patterns to address these problems.

In this article we explore the Transaction Script pattern, one of the simplest and most direct patterns in the catalog, accompanied by a practical example in Python.

What is Transaction Script?

The Transaction Script pattern organizes business logic into individual procedures where each procedure handles a single transaction or request.

In other words:

If a client wants to create a reservation → there is a script for that.
If a client wants to cancel a reservation → there is another dedicated script.

Each script contains:

Input validations.
Business rules.
Database read/write operations.
Transaction commit/rollback.

When to use it?

Transaction Script is ideal when:

The application is relatively small.
Business rules are simple and easy to describe step-by-step.
You want speed in development.
It is not yet justified to invest in more complex architectures like Domain Model.

Typical use cases:

Rapid prototypes.
Simple CRUD applications.
Services that process clear, linear requests.

When to avoid it?

Avoid when:

The domain is complex and logic begins to be duplicated across scripts.
There are many shared rules between operations.
You need logic reuse or rich object behavior.

In those cases, migrate to patterns like Domain Model or Service Layer.

Practical example: Simple reservation system

Suppose we are building a small API that allows:

Create a reservation.
List active reservations.
Cancel a reservation.

We'll use Python + Flask + SQLite to demonstrate the pattern.

1. Initialize the database

File db_init.py:

```python
import sqlite3

def init_db(path='reservas.db'):
    conn = sqlite3.connect(path)
    c = conn.cursor()
    c.execute('''
    CREATE TABLE IF NOT EXISTS reservations (
        id INTEGER PRIMARY KEY AUTOINCREMENT,
        customer_name TEXT NOT NULL,
        resource TEXT NOT NULL,
        start_time TEXT NOT NULL,
        end_time TEXT NOT NULL,
        status TEXT NOT NULL DEFAULT 'active',
        created_at TEXT NOT NULL DEFAULT (datetime('now'))
    );
    ''')
    conn.commit()
    conn.close()

if __name__ == '__main__':
    init_db()
    print("Database initialized at reservas.db")
```

2. Transaction scripts

File transactions.py:

```python
import sqlite3
from contextlib import contextmanager

DB_PATH = 'reservas.db'

@contextmanager
def get_conn():
    conn = sqlite3.connect(DB_PATH)
    try:
        yield conn
        conn.commit()
    except:
        conn.rollback()
        raise
    finally:
        conn.close()

def select_active_reservations():
    with get_conn() as conn:
        c = conn.cursor()
        c.execute("SELECT id, customer_name, resource, start_time, end_time, status, created_at FROM reservations WHERE status = 'active'")
        return c.fetchall()

def create_reservation_tx(customer_name, resource, start_time, end_time):
    if start_time >= end_time:
        raise ValueError("start_time must be before end_time")

    with get_conn() as conn:
        c = conn.cursor()
        c.execute('''
            SELECT COUNT(*) FROM reservations
            WHERE resource = ? AND status = 'active'
            AND NOT (end_time <= ? OR start_time >= ?)
        ''', (resource, start_time, end_time))
        (overlap_count,) = c.fetchone()
        if overlap_count > 0:
            raise ValueError("There is already a reservation that overlaps that time range")

        c.execute('''
            INSERT INTO reservations (customer_name, resource, start_time, end_time)
            VALUES (?, ?, ?, ?)
        ''', (customer_name, resource, start_time, end_time))
        return c.lastrowid

def cancel_reservation_tx(reservation_id):
    with get_conn() as conn:
        c = conn.cursor()
        c.execute('SELECT status FROM reservations WHERE id = ?', (reservation_id,))
        row = c.fetchone()
        if not row:
            raise ValueError("Reservation not found")
        if row[0] != 'active':
            raise ValueError("The reservation is not active")
        c.execute('UPDATE reservations SET status = ? WHERE id = ?', ('cancelled', reservation_id))
        return True
```

3. Flask API

File app.py:

```python
from flask import Flask, request, jsonify
from transactions import create_reservation_tx, cancel_reservation_tx, select_active_reservations
from db_init import init_db

app = Flask(__name__)
init_db()

@app.route('/reservations', methods=['POST'])
def create_reservation():
    payload = request.get_json()
    try:
        res_id = create_reservation_tx(
            customer_name=payload['customer_name'],
            resource=payload['resource'],
            start_time=payload['start_time'],
            end_time=payload['end_time']
        )
        return jsonify({"id": res_id}), 201
    except Exception as e:
        return jsonify({"error": str(e)}), 400

@app.route('/reservations', methods=['GET'])
def list_reservations():
    rows = select_active_reservations()
    reservations = [
        {
            "id": r[0],
            "customer_name": r[1],
            "resource": r[2],
            "start_time": r[3],
            "end_time": r[4],
            "status": r[5],
            "created_at": r[6]
        }
        for r in rows
    ]
    return jsonify(reservations), 200

@app.route('/reservations/<int:res_id>/cancel', methods=['POST'])
def cancel_reservation(res_id):
    try:
        cancel_reservation_tx(res_id)
        return jsonify({"status": "cancelled"}), 200
    except Exception as e:
        return jsonify({"error": str(e)}), 400

if __name__ == '__main__':
    app.run(debug=True)
```

4. Quick test with curl

Create a reservation:

```bash
curl -X POST http://127.0.0.1:5000/reservations \
  -H "Content-Type: application/json" \
  -d '{"customer_name":"Ana Perez","resource":"room-A","start_time":"2025-09-20T10:00","end_time":"2025-09-20T11:00"}'
```

List reservations:

```bash
curl http://127.0.0.1:5000/reservations
```

Cancel:

```bash
curl -X POST http://127.0.0.1:5000/reservations/1/cancel
```

Advantages

Simple and direct.
Easy for any developer to read.
Great for prototypes or small projects.

Disadvantages

Tends to duplicate logic as the project grows.
Does not scale well for complex domains.
Less reusable as rules increase.

Conclusion

The Transaction Script pattern is an excellent entry point to designing enterprise applications. If your system is small, this pattern brings clarity and speed. However, as complexity grows you will likely need to evolve toward other patterns such as Domain Model or Service Layer.

"🚀 Applying API Testing Frameworks: A Practical Guide with Real-World Examples"

AHMED HASAN AKHTAR OVIEDO — Fri, 06 Jun 2025 17:54:58 +0000

📖 Introduction

API testing is fundamental to ensuring the functionality, security, and performance of modern applications. In this article, we'll explore how to implement API testing frameworks, providing code examples and useful resources to facilitate their implementation.

🔍 What is an API?

An API (Application Programming Interface) enables communication between different software systems. API testing ensures these interfaces work correctly, handling requests and responses efficiently and securely.

✨ Benefits of API Testing

🎯 Early error detection: Identifies issues before they reach the production environment
⚙️ Automation: Facilitates continuous integration and continuous deployment (CI/CD)
📊 Comprehensive coverage: Allows testing of different scenarios and edge cases
🖥️ UI independence: Tests focus on business logic, not the graphical interface
⚡ Faster execution: API tests run significantly faster than UI tests
💰 Cost-effective: Reduces the overall cost of testing by catching defects early

🛠️ Popular API Testing Tools

1. 📬 Postman

Postman is a widely-used tool for RESTful API testing, offering an intuitive interface for sending HTTP requests and verifying responses.

🌟 Key Features:

Support for all HTTP methods (GET, POST, PUT, DELETE, PATCH)
JavaScript-based response validation scripts
CI/CD integration through Newman
Environment and variable management
Collection runner for batch testing
Mock server capabilities
API documentation generation
Team collaboration features

💼 Use Cases:

Manual API testing and exploration
Automated regression testing
API documentation and sharing
Load testing with multiple iterations
API mocking during development

📝 Advanced Example:

// Pre-request Script
pm.globals.set("timestamp", Date.now());
pm.globals.set("randomUser", "user_" + Math.random().toString(36).substr(2, 9));

// Test Script
pm.test("🔍 Response status is 200", function () {
    pm.response.to.have.status(200);
});

pm.test("📊 Response time is less than 500ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

pm.test("✅ User creation successful", function () {
    const responseJson = pm.response.json();
    pm.expect(responseJson).to.have.property('id');
    pm.expect(responseJson.name).to.eql(pm.globals.get("randomUser"));
});

📺 Video Resources:

🔗 Resources:

2. ☕ Rest-Assured

Rest-Assured is a Java library for testing REST services, allowing you to write tests in a fluent and readable manner.

🌟 Key Features:

BDD-style syntax for readable tests
JSON and XML response validation
Integration with JUnit, TestNG, and other frameworks
Support for OAuth, cookies, and headers
Response time validation
File upload/download testing
Custom matchers and filters
Request/response logging

💼 Use Cases:

Java-based test automation frameworks
Integration testing in microservices architecture
Performance testing with response time validation
Security testing with authentication scenarios
Contract testing between services

📝 Advanced Example:

import static io.restassured.RestAssured.*;
import static io.restassured.matcher.RestAssuredMatchers.*;
import static org.hamcrest.Matchers.*;

public class AdvancedApiTest {

    @BeforeClass
    public static void setup() {
        baseURI = "https://api.example.com";
        enableLoggingOfRequestAndResponseIfValidationFails();
    }

    @Test
    public void testCompleteUserWorkflow() {
        // 🔐 Authentication
        String token = given()
            .contentType("application/json")
            .body("{\"username\":\"testuser\",\"password\":\"password123\"}")
        .when()
            .post("/auth/login")
        .then()
            .statusCode(200)
            .extract().path("token");

        // 👤 Create User
        int userId = given()
            .header("Authorization", "Bearer " + token)
            .contentType("application/json")
            .body("{\"name\":\"John Doe\",\"email\":\"john@example.com\"}")
        .when()
            .post("/users")
        .then()
            .statusCode(201)
            .time(lessThan(2000L))
            .body("name", equalTo("John Doe"))
            .body("email", matchesPattern(".*@example\\.com"))
            .extract().path("id");

        // 📋 Verify User Creation
        given()
            .header("Authorization", "Bearer " + token)
        .when()
            .get("/users/" + userId)
        .then()
            .statusCode(200)
            .body("id", equalTo(userId))
            .body("createdAt", notNullValue());
    }
}

📺 Video Resources:

🔗 Resources:

3. 🥋 Karate DSL

Karate DSL is a BDD-based framework that combines API and UI testing in a single, powerful tool using Gherkin syntax.

🌟 Key Features:

Gherkin-based syntax for readable scenarios
Built-in JSON/XML assertions
Performance testing capabilities
Service virtualization and mocking
Parallel execution support
HTML reports with detailed logs
Database testing integration
Multi-protocol support (HTTP, WebSocket, gRPC)

💼 Use Cases:

Behavior-driven API testing
End-to-end testing scenarios
Performance and load testing
Service virtualization for dependent services
Cross-platform API testing
Integration testing with databases

📝 Advanced Example:

Feature: 🏪 E-commerce API Testing Suite

Background:
    * url 'https://api.ecommerce.com'
    * def authToken = call read('auth-helper.js')
    * header Authorization = 'Bearer ' + authToken

Scenario: 🛒 Complete Shopping Cart Workflow
    # Add product to cart
    Given path 'cart/items'
    And request { productId: 123, quantity: 2 }
    When method post
    Then status 201
    And match response == { id: '#number', productId: 123, quantity: 2, totalPrice: '#number' }
    * def cartItemId = response.id

    # Verify cart contents
    Given path 'cart'
    When method get
    Then status 200
    And match response.items[0] contains { id: '#(cartItemId)', quantity: 2 }
    And assert response.totalAmount > 0

    # Update quantity
    Given path 'cart/items', cartItemId
    And request { quantity: 3 }
    When method put
    Then status 200
    And match response.quantity == 3

    # Checkout process
    Given path 'checkout'
    And request { paymentMethod: 'credit_card', shippingAddress: '#(shippingData)' }
    When method post
    Then status 200
    And match response == { orderId: '#string', status: 'confirmed', estimatedDelivery: '#string' }

Scenario Outline: 🔍 Product Search with Different Parameters
    Given path 'products/search'
    And param category = '<category>'
    And param minPrice = <minPrice>
    And param maxPrice = <maxPrice>
    When method get
    Then status 200
    And match response.products == '#[]'
    And match each response.products == { id: '#number', name: '#string', price: '#number' }
    And assert response.products.length > 0

    Examples:
      | category    | minPrice | maxPrice |
      | electronics | 100      | 1000     |
      | clothing    | 20       | 200      |
      | books       | 5        | 50       |

📺 Video Resources:

🔗 Resources:

📋 Best Practices for API Testing

🔄 Use dynamic data: Avoid static data that may become obsolete
📐 Schema validation: Ensure responses comply with expected format using JSON Schema
❌ Negative testing: Verify how the API handles invalid inputs or errors
🔄 CI/CD automation: Integrate tests into the development workflow for early error detection
📊 Test data management: Implement proper test data setup and cleanup procedures
🔐 Security testing: Include authentication, authorization, and input validation tests
⚡ Performance validation: Monitor response times and throughput
📝 Documentation: Maintain clear test documentation and reporting

📚 Additional Resources

📖 Articles & Guides:

🎥 Video Tutorials:

🔧 Tools & Utilities:

🎯 Conclusion

Implementing API testing frameworks is essential for ensuring application quality and reliability. Tools like Postman, Rest-Assured, and Karate DSL offer diverse functionalities that adapt to different needs and project requirements. By following best practices and leveraging these powerful tools, development teams can significantly improve development efficiency and end-user satisfaction.

The key to successful API testing lies in choosing the right tool for your specific context, implementing comprehensive test coverage, and maintaining a robust automation strategy that integrates seamlessly with your development pipeline.

💬 Have you used any of these tools? Share your experiences and tips in the comments below!

🥋 Applying Aikido: SAST in Web Applications from the Repository

AHMED HASAN AKHTAR OVIEDO — Mon, 21 Apr 2025 18:41:06 +0000

🧠 Summary

In this article, you’ll learn what SAST is and why it’s crucial to incorporate static application security testing from the early stages of development. You’ll discover what Aikido SAST is, a SaaS platform that scans your code in seconds without complex installations. You’ll follow a detailed plan to connect it to your repository, run a scan, and understand the results.

🛡️ Introduction

Static Application Security Testing (SAST) is a white-box technique that analyzes source code, bytecode, or binaries to detect vulnerabilities before execution.

Integrating SAST into the software development lifecycle allows you to:

🐞 Detect issues like SQL injection, XSS, or data leaks
🕒 Reduce remediation time
💸 Lower costs and security risks

🤖 What is Aikido SAST?

Aikido is a SaaS platform for static security analysis that scans your repositories for vulnerabilities without needing to install tools locally.

Key Features:

⚡ Fast scanning: Analysis in under 2 minutes.
☁️ No local setup: 100% cloud-based.
🔐 Privacy-first: Code is not stored after scanning.
🛠️ Detects common risks: SQL Injection, XSS, Path Traversal, SSRF, and more.
🤖 Auto-fix (paid plans): Aikido can automatically propose pull requests to fix vulnerabilities.

🛠️ Step-by-step Implementation

Step 1: Create an Aikido account

Go to https://www.aikido.dev
Click the “Start for Free” button
Sign up with your email or log in using GitHub

Step 2: Connect your repository

Once inside the Aikido dashboard:

Click Connect Your Source Code
Choose your provider: GitHub, GitLab, or Bitbucket
Authorize Aikido to access your repositories
Select the project you want to scan (e.g. web-login-app)

Step 3: Configure SAST scan

On the left menu, go to Scanners
Select Static Code Analysis (SAST)
Choose which branches to scan: main or all
Click Run Scan to launch the analysis

Scanning starts automatically — no technical setup needed.

Step 4: Review results

When the scan is complete, go to the Results Dashboard, where vulnerabilities are grouped by type and severity.

Example result:

⚠️ High severity: SQL Injection in login.php, line 37

Description: Unsanitized parameter detected in SQL query.

Recommendation: Use prepared statements to prevent injections.

Each issue includes:

File name
Line number
Affected code snippet
Severity level (Critical, High, Medium, Low)
Fix suggestion

Step 5: Manual review or auto-fix (for paid plans)

If you have a paid plan, you can enable Auto-fix to allow Aikido to create a pull request with the fix applied.

On the free plan, you’ll need to manually apply changes using the suggestions shown in the dashboard.

Step 6 (Optional): Define custom rules

Want more control?

Go to your project’s Settings in Aikido
Navigate to Custom SAST Rules
Define your own patterns, such as:
- Blocking usage of risky functions like eval()
- Detecting hardcoded API keys in variables

This allows you to tailor the scanner to your team’s security standards.

⚖️ Pros and Cons

✅ Pros

Fast scanning with no local installation
Easy integration with GitHub, GitLab, Bitbucket
Developer-friendly UI
Detects common vulnerabilities (XSS, SQLi, etc.)
Custom rule support
Great for PHP, JavaScript, Python, Java, etc.

❌ Cons

No DAST (Dynamic Analysis)
Some advanced features require paid plans
Limited customization on the free tier
Focused on code scanning only (no infrastructure/IaC)

🧾 Conclusion

Integrating Aikido SAST into your development workflow is a strategic move for any developer or team aiming to improve security with minimal overhead.

Its simplicity, speed, and focus on static code scanning from the repo make it a great entry point into DevSecOps.

Whether you're working with PHP, JavaScript, or other supported languages, Aikido can help you:

Detect vulnerabilities before deploying to production
Improve code quality
Maintain secure development practices

Start scanning from the first commit and keep your app safe effortlessly.

🔐 Securing Terraform with Checkov: Automating SAST for Infrastructure as Code

AHMED HASAN AKHTAR OVIEDO — Mon, 21 Apr 2025 05:57:14 +0000

🧠 Summary

This article walks you through how to apply Static Application Security Testing (SAST) to your Infrastructure as Code (IaC) using Checkov, a powerful open-source tool by Bridgecrew. We’ll explore how to install Checkov, how it scans your .tf files for misconfigurations, and how to automate this process using GitHub Actions.

By the end, you’ll understand how to detect security issues in your Terraform configurations before deploying to the cloud — ensuring your infrastructure is secure from the start.

🚀 Introduction

Infrastructure as Code (IaC) enables fast and repeatable cloud deployments — but it also introduces new security risks. A single misconfigured Terraform file can expose sensitive resources, leave storage buckets publicly accessible, or open critical ports to the internet.

To address this, we need tools that help us shift security left, catching issues early in the development process. That's where Checkov comes in.

In this article, we'll explore:

What SAST is and how it applies to IaC
What Checkov does and how to use it
How to integrate Checkov into GitHub Actions for CI/CD
Tips to make security testing part of your development workflow

🔍 What is SAST and Why Apply It to IaC?

SAST (Static Application Security Testing) analyzes source code without executing it, helping you catch vulnerabilities early.

In the context of Terraform and other IaC tools, SAST can:

🚫 Detect insecure default configurations
🔐 Prevent exposed credentials or open ports
⚠️ Identify non-compliant resources (e.g., unencrypted storage)

Because IaC code defines infrastructure, applying SAST here is essential. It’s like doing a security review of your cloud before it even exists.

🧰 What is Checkov?

Checkov is an open-source IaC static analysis tool created by Bridgecrew (by Prisma Cloud). It supports a wide variety of formats:

🛠️ Supported file types:

.tf (Terraform)
.yaml, .yml (Kubernetes, Helm, etc.)
.json, .template (CloudFormation)

🔐 What Checkov can detect:

Publicly accessible S3 buckets
Missing encryption on databases
Open security groups (firewall rules)
Missing logging or monitoring setups
IAM policies that are too permissive

✅ Why it's great:

CLI-based and easy to integrate
Continuously updated with community-backed policies
Works locally and in CI/CD

🧪 Installing Checkov + Terraform Example

Here’s how to get started with Checkov on a sample Terraform project.

Step 1: Install Checkov

You’ll need Python installed. Then run:

pip install checkov

💡 Tip: You can also use it via Docker or download binaries from the Checkov GitHub repo.

Step 2: Create a Simple Terraform File

Create a file named main.tf:

resource "aws_s3_bucket" "example" {
  bucket = "my-test-bucket"
  acl    = "public-read"
}

This intentionally insecure configuration allows public access to an S3 bucket — perfect for testing.

Step 3: Run Checkov Locally

From the root of your project:

checkov -d .

You’ll get a report of any misconfigurations. In this case, Checkov should flag the S3 bucket’s ACL as insecure.

🤖 Automating with GitHub Actions

You can integrate Checkov into your CI/CD pipeline using GitHub Actions. This way, every time you push code, your infrastructure is automatically checked for security issues.

🧬 Why use GitHub Actions?

Fully integrated with GitHub repos
Allows automated security checks on pull requests
Keeps your IaC secure without relying on manual testing

Step 4: Add GitHub Actions Workflow

Create a file at .github/workflows/checkov.yml:

name: Checkov Terraform Scan

on:
  push:
    paths:
      - '**/*.tf'
  pull_request:
    paths:
      - '**/*.tf'

jobs:
  checkov_scan:
    runs-on: ubuntu-latest
    name: Run Checkov
    steps:
      - name: Checkout Code
        uses: actions/checkout@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.x'

      - name: Install Checkov
        run: pip install checkov

      - name: Run Checkov
        run: checkov -d .

Once added, every commit or pull request that modifies .tf files will trigger a scan.

🔁 Bonus: You can fail builds if any high-severity issues are found by configuring policies with --soft-fail or --check.

✅ Pros and Cons of Using Checkov

✅ Pros

Easy to install and use
Supports multiple IaC formats
Produces detailed and clear output
Prevents critical cloud misconfigurations early
Integrates with GitHub, GitLab, Bitbucket, CircleCI, etc.

❌ Cons

Doesn’t catch logic/semantic bugs (it’s not a linter or validator)
Some default policies may be too strict (but can be customized)

🧾 Conclusion

Using Checkov with Terraform is a powerful way to add automated security checks to your infrastructure workflows. Whether you’re just starting out or managing complex cloud environments, it’s a must-have in your DevSecOps toolkit.

By integrating it into your GitHub Actions pipeline, you’ll ensure that every infrastructure change is reviewed for security — before reaching production.

Forem: AHMED HASAN AKHTAR OVIEDO

The Case of the Zombie Transaction: Solving 'Unknown Unknowns' with OpenTelemetry & High Cardinality

The Scenario: "The Zombie Transaction"

The Architecture

Step 1: The Code (Python + OpenTelemetry)

Why this is unique?

Connecting to a Platform (The "How-To")

Theory: The Three Pillars are Not Enough

Conclusion

References

Beyond the Context Window: Building a Stateful 'Memory' MCP Server on Cloudflare Workers

The Theory: The "Sidecar" Memory Pattern

The Architecture: Why Edge Computing?

The Tech Stack

Step 1: Initialize the Project

Step 2: Configure The KV Namespace

Step 3: The Code

Step 4: Deploying

Step 5: Connecting to Claude Desktop

The Result

Conclusion

Reference Repository

Repository Pattern: Simplify Data Access in Enterprise Apps

Introduction

Why It Matters?

What is the Repository Pattern?

Practical Example in Python

Conclusion

References

From Data to Dashboard: Building Interactive Reports with Streamlit

Why Visualization Tools Matter

Real-World Example: Sales Dashboard

Requirements

Deploying the Dashboard

Option A: Streamlit Community Cloud

Option B: Render

Why Streamlit Works Best Here

Final Thoughts

Design Principles of Software Applied: Practical Example in Python

Design Principles of Software Applied: Practical Example in Python

Chosen principles

Real problem

Design (brief)

Example code (suggested files: notifiers.py, test_notifiers.py)

Tests (example with pytest — test_notifiers.py)

How the principles apply here

How to run locally

Conclusion

Transaction Script: Patrón simple para lógica de negocio (Catalog of Patterns of EAA — Martin Fowler)

Transaction Script: A simple pattern to organize business logic

What is Transaction Script?

When to use it?

When to avoid it?

Practical example: Simple reservation system

1. Initialize the database

2. Transaction scripts

3. Flask API

4. Quick test with curl

"🚀 Applying API Testing Frameworks: A Practical Guide with Real-World Examples"

📖 Introduction

🔍 What is an API?

✨ Benefits of API Testing

🛠️ Popular API Testing Tools

1. 📬 Postman

2. ☕ Rest-Assured

3. 🥋 Karate DSL

📋 Best Practices for API Testing

📚 Additional Resources

🎯 Conclusion

🥋 Applying Aikido: SAST in Web Applications from the Repository

🧠 Summary

🛡️ Introduction

🤖 What is Aikido SAST?

Key Features:

🛠️ Step-by-step Implementation

Step 1: Create an Aikido account

Step 2: Connect your repository

Step 3: Configure SAST scan

Step 4: Review results

Step 5: Manual review or auto-fix (for paid plans)

Example code (suggested files: `notifiers.py`, `test_notifiers.py`)

Tests (example with `pytest` — `test_notifiers.py`)