Forem: Bruno Enrique ANCCO SUAÑA

🔌The Magic of MCP Servers: Unlocking Infinite Context for AI

Bruno Enrique ANCCO SUAÑA — Wed, 26 Nov 2025 04:41:12 +0000

🚀 What is an MCP Server?

Think of an MCP Server as a "Universal Translator" between your data and AI models.
In the past, if you wanted an AI to use a specific tool (like checking a Jira ticket), you had to build a custom integration just for that AI. If you switched AIs, you had to rebuild it.

With MCP:

You build an MCP Server once.
It exposes your data (Resources), actions (Tools), and templates (Prompts).
Any MCP-compliant client can connect to it instantly

🤝 Connects to Any Client

The beauty of this protocol is its interoperability. An MCP Server doesn't care who is asking for the data, as long as they speak "MCP".

Supported Clients include:

Claude Desktop App: Connects locally to read your files or query databases while you chat.
VS Code (with Extensions): Allows your IDE to "see" external documentation or server logs to help you code better.
Zed Editor: Fast, AI-powered coding that leverages your custom MCP tools.

🛠️ How It Works Under the Hood

The connection is surprisingly simple. It usually happens over stdio (standard input/output) for local tools or HTTP/SSE for remote servers.

The Client (e.g., Claude) starts your MCP Server script.
The Server sends a list of available tools (e.g., get_user_data, search_logs).
The AI decides when to call a tool based on your conversation.
The Server executes the logic and sends the result back.

📂 Public Example Repository

Want to see code? The best way to learn is by looking at the official reference implementations. The repository below contains a collection of ready-to-use MCP servers for things like Google Drive, PostgreSQL, Slack, and GitHub.

🔗 Repository

modelcontextprotocol/servers
Why check this repo?

Multiple Examples: See how to structure servers for different use cases (File systems vs. APIs).
TypeScript & Python: Examples in the most popular languages.
Plug & Play: You can clone this and connect it to your Claude Desktop immediately to test it out.

🎯 Next Steps

If you want to empower our AI workflows:

Clone the repo linked above.
Pick one server (e.g., the sqlite or filesystem server).
Connect it to your Claude Desktop config file.

🏁 Conclusion

The Model Context Protocol isn't just a new tool; it's a standard that ends the era of siloed AI. By adopting MCP, we move from building fragile, one-off integrations to creating a robust ecosystem where our data and AI agents communicate freely.

Instead of manually feeding context to an AI every time we start a task, MCP creates a live, two-way bridge. Whether we are debugging code in VSCode or analyzing business data in Claude, MCP puts the knowledge where it belongs: at the AI's fingertips.

📝The Age of Observability: Navigating Chaos in Distributed Systems

Bruno Enrique ANCCO SUAÑA — Sat, 22 Nov 2025 15:13:13 +0000

In the era of monoliths, system failure was binary: the server was either up or down. Troubleshooting was linear—you checked the CPU, memory, and disk space. However, the shift to microservices, serverless architectures, and Kubernetes has introduced a level of complexity where linear debugging no longer works.

In distributed systems, failure is rarely a crash; it is a performance degradation. A user complains that "checkout is slow," but all your dashboards show green lights. This is the "unknown unknown." To solve this, we must move beyond simple monitoring and embrace Observability.

🔍 Monitoring vs. Observability: What’s the Difference?

Many engineers use these terms interchangeably, but they represent fundamentally different approaches to system visibility.

Monitoring tells you when something is wrong based on pre-defined thresholds. It answers questions you knew to ask in advance (e.g., "Is CPU > 90%?"). It is reactive.
Observability allows you to ask new questions about your system to understand why something is wrong. It relies on exploring the data to find patterns you didn't know existed. It is exploratory.

"Monitoring tells you the system is failing. Observability lets you understand why."

🏛️ The Three Pillars of Observability

To build an observable system, we need to collect three specific types of telemetry data.

📜 Logs (The Event Record) Logs are immutable, timestamped records of discrete events.

The Problem: Traditional text logs are hard to search.

The Solution: Structured Logging. Instead of logging "User login failed", log {"event": "login_failed", "user_id": "123", "error": "timeout"}. This allows log aggregation tools to filter and index data instantly.

📊 Metrics (The Health Check) Metrics are numerical data measured over time. They are cheap to store and fast to query.

Use Case: Dashboards and Alerts.

Limitation: Metrics suffer from "low cardinality." They are great for seeing trends (e.g., total error rate) but terrible for finding specific needles in the haystack (e.g., which specific user ID caused the error).

🔗 Traces (The Journey) Distributed Tracing is the most critical tool for microservices. It tracks the lifecycle of a request as it propagates across service boundaries.

Trace ID: A unique identifier attached to the request at the entry point.

Span: Represents a single operation within that trace (e.g., a database query or an external API call).

Benefit: Tracing visualizes latency, proving instantly that the delay is not in your API, but in the legacy SQL database you queried.

🚦 The Four Golden Signals

According to the Google SRE (Site Reliability Engineering) handbook, if you can only measure four things in your user-facing system, measure these:

Latency: The time it takes to service a request. It is crucial to distinguish between the latency of successful requests and the latency of failed requests.
Traffic: A measure of how much demand is being placed on your system (e.g., HTTP requests per second).
Errors: The rate of requests that fail (e.g., HTTP 500s) or partially fail.
Saturation: How "full" your service is. This measures your most constrained resource (e.g., memory or I/O).

⚙️ Instrumentation Strategies: How to Start?

You cannot buy observability; you must build it into your code. This process is called Instrumentation.

Automatic Instrumentation: Many agents (like Datadog or New Relic) can attach to your running process and extract data without code changes. This is the easiest way to start.
Manual Instrumentation: This involves writing code to capture business-specific data (e.g., tracking how many times a specific "Add to Cart" button was clicked).
OpenTelemetry (OTel): The modern industry standard. OTel provides a vendor-neutral way to instrument your application. You write your instrumentation once, and you can export that data to Azure, AWS, Prometheus, or Jaeger without changing a single line of code.

📦GitHub Repository

A working implementation is available here: View the full source code and setup guide on my GitHub

🚀 Conclusion

Observability is a property of your system, not a feature of your software tool. By implementing structured logs, meaningful metrics, and distributed tracing, you turn the "black box" of production into a "glass box." This culture of visibility allows teams to deploy faster, debug efficiently, and sleep better at night.

Unlocking Scalability: A Deep Dive into the Model-View-Controller (MVC) Pattern

Bruno Enrique ANCCO SUAÑA — Tue, 28 Oct 2025 01:35:15 +0000

Here is an article about the Model-View-Controller pattern, complete with a real-world example in Python using the Flask framework.

Unlocking Scalability: A Deep Dive into the Model-View-Controller (MVC) Pattern
In the world of software engineering, especially within enterprise-level applications, complexity is the main enemy. As applications grow, adding new features, fixing bugs, and managing the codebase can become a nightmare. To combat this, architects rely on proven design patterns. These patterns are reusable solutions to common problems.

One of the most foundational patterns, featured prominently in catalogs like Martin Fowler's "Patterns of Enterprise Application Architecture," is the Model-View-Controller (MVC). While it originated in Smalltalk-80 for desktop applications, its principles are fundamental to how most modern web applications are built today.

This article explores the MVC pattern: what it is, why it's crucial for enterprise applications, and how to implement it with a practical, real-world example in Python.

🔍What is the Model-View-Controller (MVC) Pattern?

The MVC pattern is an architectural pattern that separates an application's logic into three distinct, interconnected components. The primary goal is Separation of Concerns. By keeping these parts separate, the application becomes easier to test, maintain, and scale.

Here’s a breakdown of the three components:

The Model: This is the brain of the application. It represents the data, business logic, and rules.

It manages the application's state (e.g., data from a database).
It contains the business logic (e.g., "a user cannot withdraw more money than they have").
It knows nothing about the View or the Controller. It is a standalone component.

The View: This is the face of the application. It's the User Interface (UI) that the end-user interacts with.

It displays the data it receives from the Model.
It sends user actions (like button clicks or form submissions) to the Controller.
It should be "dumb"—it contains no business logic. Its only job is presentation.

The Controller: This is the traffic cop or intermediary. It glues the Model and the View together.

It receives input from the View (e.g., an HTTP request from a user).
It processes that input, interacts with the Model (e.g., "Hey Model, add this new user to the database"), and gets a response.
It then decides which View to show the user and passes it the necessary data from the Model.

🔍Why MVC is Essential for Enterprise Applications

The separation provided by MVC isn't just an academic exercise; it provides tangible business value:

Testability: Because the Model (business logic) is separate from the UI, you can write automated tests for your core logic without ever needing to render a webpage or simulate a click. This makes testing more robust and faster.
Maintainability: Need to change a button color or redesign a page? You only touch the View. The core business logic in the Model remains untouched and safe.
Flexibility: The same Model can serve multiple Views. You can have a web interface (View 1) and a mobile app (View 2) that both talk to the same Controller and Model. This "write once, use many" approach is incredibly efficient.

💻Real-World Example: A Python To-Do List with Flask

Let's build a simple "To-Do List" web application. We'll use Python and the micro-framework Flask. While some frameworks like Django call their pattern MVT (Model-View-Template), the principle is identical. We will structure our code to clearly separate the three concerns.

Project Structure Create a folder for your project. Inside, it should look like this:

mvc-todo-app/
├── app.py           # The Controller
├── model.py         # The Model
└── templates/
    └── index.html   # The View

The Model (model.py) This file contains our data and business logic. For simplicity, we won't use a real database; we'll use a simple list in memory. This file does not import Flask. It's pure Python.

# model.py

# We'll use a simple list to act as our "database"
tasks = []
task_id_counter = 1

class TaskModel:
    """
    The Model component. It handles the data and business logic
    for our tasks. It knows nothing about HTTP or the web.
    """

    def get_all_tasks(self):
        """Retrieves all tasks."""
        return tasks

    def add_task(self, description):
        """Adds a new task to our list."""
        global task_id_counter
        if not description:
            # Business logic: Don't allow empty tasks
            return None

        new_task = {
            'id': task_id_counter,
            'description': description,
            'completed': False
        }
        tasks.append(new_task)
        task_id_counter += 1
        return new_task

    def complete_task(self, task_id):
        """Marks a specific task as completed."""
        for task in tasks:
            if task['id'] == task_id:
                task['completed'] = True
                return task
        return None # Task not found

The View (templates/index.html) This is our UI. It's an HTML file that uses the Jinja2 templating engine (which comes with Flask).

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>MVC To-Do List</title>
    <style>
        body { font-family: sans-serif; margin: 2em; }
        .task-list { list-style: none; padding: 0; }
        .task { margin-bottom: 8px; }
        .completed { text-decoration: line-through; color: #888; }
    </style>
</head>
<body>
    <h1>My To-Do List</h1>

    <form action="/add" method="POST">
        <label for="task">New Task:</label>
        <input type="text" id="task" name="description">
        <button type="submit">Add Task</button>
    </form>

    <hr>

    <h2>Current Tasks</h2>
    <ul class="task-list">
        {% for task in tasks %}
            <li class="task {% if task.completed %}completed{% endif %}">
                {{ task.description }}

                {% if not task.completed %}
                    ( <a href="/complete/{{ task.id }}">Complete</a> )
                {% endif %}
            </li>
        {% else %}
            <li>No tasks yet!</li>
        {% endfor %}
    </ul>
</body>
</html>

The Controller (app.py) This is the "glue." It imports Flask and our TaskModel. It defines the URL routes that listen for user input from the View, processes that input using the Model, and then renders the View with the new data.

from flask import Flask, render_template, request, redirect, url_for
from model import TaskModel # Import the Model

app = Flask(__name__)
model = TaskModel()

@app.route('/')
def index():
    """
    Handles the main route.
    1. Gets all tasks from the Model.
    2. Renders the View, passing the tasks to it.
    """
    tasks = model.get_all_tasks()
    return render_template('index.html', tasks=tasks)

@app.route('/add', methods=['POST'])
def add_task():
    """
    Handles the 'Add Task' form submission.
    1. Gets form data from the user request (View).
    2. Tells the Model to add the new task.
    3. Redirects the user back to the main page.
    """
    description = request.form.get('description')
    model.add_task(description)
    return redirect(url_for('index'))

@app.route('/complete/<int:task_id>')
def complete_task(task_id):
    """
    Handles the 'Complete' link click.
    1. Gets the task_id from the URL (View).
    2. Tells the Model to mark the task as complete.
    3. Redirects the user back to the main page.
    """
    model.complete_task(task_id)
    return redirect(url_for('index'))

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

📦GitHub Repository

A working implementation is available here: Model View Controller

✅Conclusion

The Model-View-Controller pattern is not just a theory; it's a practical, powerful, and time-tested strategy for building software that lasts. By separating the Model (logic), the View (UI), and the Controller (input handler), you create an application that is a pleasure to test, maintain, and expand.

While modern frameworks have evolved this idea into patterns like MVVM (Model-View-ViewModel) or MVT (Model-View-Template), they all share the same DNA. Understanding MVC is the first and most critical step toward building clean, scalable, and professional enterprise-grade applications.

📊Beyond the Standard: Exploring Modern Python Visualization Tools

Bruno Enrique ANCCO SUAÑA — Sun, 14 Sep 2025 03:19:57 +0000

In the world of data science, moving from a static Jupyter notebook to a dynamic, interactive web application is a game-changer. It allows stakeholders to explore data, test hypotheses, and gain insights on their own. While tools like Tableau or Power BI have their place, a code-first approach using Python offers unparalleled flexibility and power.

This article dives into three powerful Python libraries for building dashboards and reports: Streamlit, Dash, and Bokeh. We'll explore the philosophy behind each, build a simple interactive dashboard with all three, and walk through deploying our app to the cloud, complete with a GitHub repository and CI/CD automation.

🚀 The Contenders
Let's meet our three visualization frameworks. Each has a unique approach to turning Python scripts into interactive web apps.

1. Streamlit ✨
The Pitch: The fastest way to build and share data apps.

Streamlit is the go-to for data scientists who want to create beautiful, functional apps with minimal effort and without thinking about traditional web development. Its core philosophy is simplicity. You write a Python script as you normally would, and Streamlit intelligently re-runs your code from top to bottom whenever a user interacts with a widget.

Pros:

✅Aidiculously easy to learn.
✅Minimal boilerplate code.
✅Automatic updates on widget interaction.
✅A rich ecosystem of custom components.

Cons:

❌The "rerun everything" model can be inefficient for very complex or long-running apps.
❌Less control over the fine-grained layout and styling compared to others.

2. Plotly Dash 📊
The Pitch: Build analytical web apps for Python. No JavaScript required.

Dash, created by the team behind the Plotly charting library, is a powerful framework for building production-ready, enterprise-grade applications. It provides a more structured "blank canvas" where you define the layout using Python classes that mimic HTML and then connect interactive components using explicit "callbacks."

Pros:

✅Highly customizable and flexible layouts.
✅Scalable for complex, multi-page applications.
✅Excellent for apps requiring precise state management.
✅Part of the robust Plotly ecosystem.

Cons:

❌Steeper learning curve with more boilerplate code.
❌Requires a deeper understanding of concepts like layouts and callbacks.

3. Bokeh 🎨
The Pitch: Interactive visualizations for modern web browsers.

Bokeh is, at its core, a visualization library, but it comes with a powerful server component that allows you to build full-fledged interactive applications. It excels at handling large datasets and streaming data efficiently. Its strength lies in the granular control it gives you over every plot element and its powerful data linking and selection tools.

Pros:

✅Excellent for high-performance interactivity on large datasets.
✅Provides a high level of control over plot design and interactions.
✅Can be used as a standalone library or with its server for full apps.

Cons:

❌Can be more verbose for creating full dashboard layouts compared to Streamlit.
❌The API can feel less "Pythonic" initially than Streamlit's.

🐧 The Demo Project: Palmer Penguins Explorer
To compare these tools, we'll build the same simple app in all three: an interactive scatter plot explorer for the famous Palmer Penguins dataset. Users will be able to select the species to display and choose the variables for the X and Y axes.

First, let's install our libraries:

pip install streamlit pandas plotly-express dash bokeh

1. Streamlit Example
Notice how clean and readable this is. We use st.sidebar to place our widgets and the main area for the plot. The code reads like a simple script.

streamlit_app/app.py

import streamlit as st
import pandas as pd
import plotly.express as px

# Load the dataset
@st.cache_data # Cache the data to improve performance
def load_data():
    df = pd.read_csv('https://raw.githubusercontent.com/mwaskom/seaborn-data/master/penguins.csv')
    df.dropna(inplace=True)
    return df

df = load_data()

# --- Page Configuration ---
st.set_page_config(
    page_title="🐧 Palmer Penguins Explorer",
    page_icon="🧊",
    layout="centered"
)

st.title("🐧 Palmer Penguins Explorer")
st.markdown("Explore the Palmer Penguins dataset using **Streamlit**.")

# --- Sidebar for User Inputs ---
st.sidebar.header("📊 Chart Controls")

# Species selector
species_list = ['All'] + sorted(df['species'].unique().tolist())
selected_species = st.sidebar.selectbox("Select Species", species_list)

# Axis selectors
numeric_columns = df.select_dtypes(include=['float64', 'int64']).columns.tolist()
x_axis = st.sidebar.selectbox("Select X-axis", numeric_columns, index=numeric_columns.index('bill_length_mm'))
y_axis = st.sidebar.selectbox("Select Y-axis", numeric_columns, index=numeric_columns.index('bill_depth_mm'))

# --- Data Filtering ---
if selected_species != 'All':
    filtered_df = df[df['species'] == selected_species]
else:
    filtered_df = df

# --- Display Chart ---
st.subheader(f"Scatter Plot: {x_axis} vs. {y_axis}")

if not filtered_df.empty:
    fig = px.scatter(
        filtered_df,
        x=x_axis,
        y=y_axis,
        color='species',
        hover_name='species',
        title=f'Relationship between {x_axis} and {y_axis}'
    )
    st.plotly_chart(fig, use_container_width=True)
else:
    st.warning("No data available for the selected species.")

st.markdown("---")
st.write("Data Source:")
st.dataframe(filtered_df.head())

2. Dash Example
Dash is more structured. We define a static layout and then create a @app.callback function that listens for changes to the inputs (species-dropdown, x-axis-dropdown, y-axis-dropdown) and updates the output (penguin-scatter-plot).

dash_app/app.py

import dash
from dash import dcc, html, Input, Output
import pandas as pd
import plotly.express as px

# Load the dataset
df = pd.read_csv('https://raw.githubusercontent.com/mwaskom/seaborn-data/master/penguins.csv')
df.dropna(inplace=True)

# --- App Initialization ---
app = dash.Dash(__name__)
server = app.server # Expose server for deployment

numeric_columns = df.select_dtypes(include=['float64', 'int64']).columns.tolist()
species_list = [{'label': 'All', 'value': 'All'}] + [{'label': s, 'value': s} for s in sorted(df['species'].unique())]

# --- App Layout ---
app.layout = html.Div(style={'fontFamily': 'sans-serif'}, children=[
    html.H1("🐧 Palmer Penguins Explorer (Dash)", style={'textAlign': 'center'}),
    html.P("Explore the Palmer Penguins dataset using Plotly Dash.", style={'textAlign': 'center'}),

    html.Div(style={'display': 'flex', 'padding': '20px'}, children=[
        # Controls Div
        html.Div(style={'width': '25%', 'paddingRight': '20px'}, children=[
            html.H3("📊 Chart Controls"),
            html.Label("Select Species"),
            dcc.Dropdown(id='species-dropdown', options=species_list, value='All'),
            html.Br(),
            html.Label("Select X-axis"),
            dcc.Dropdown(id='x-axis-dropdown', options=[{'label': i, 'value': i} for i in numeric_columns], value='bill_length_mm'),
            html.Br(),
            html.Label("Select Y-axis"),
            dcc.Dropdown(id='y-axis-dropdown', options=[{'label': i, 'value': i} for i in numeric_columns], value='bill_depth_mm'),
        ]),

        # Graph Div
        html.Div(style={'width': '75%'}, children=[
            dcc.Graph(id='penguin-scatter-plot')
        ])
    ])
])

# --- Callback for Interactivity ---
@app.callback(
    Output('penguin-scatter-plot', 'figure'),
    [Input('species-dropdown', 'value'),
     Input('x-axis-dropdown', 'value'),
     Input('y-axis-dropdown', 'value')]
)
def update_graph(selected_species, x_axis, y_axis):
    if selected_species == 'All' or selected_species is None:
        filtered_df = df
    else:
        filtered_df = df[df['species'] == selected_species]

    fig = px.scatter(
        filtered_df,
        x=x_axis,
        y=y_axis,
        color='species',
        hover_name='species',
        title=f'Relationship between {x_axis} and {y_axis}'
    )
    fig.update_layout(transition_duration=500)
    return fig

# --- Run the App ---
if __name__ == '__main__':
    app.run_server(debug=True)

3. Bokeh Example
Bokeh requires us to think more about data sources and how glyphs (like circles) are updated. Here, we create a ColumnDataSource and a callback function that modifies the data within this source when a widget changes.

bokeh_app/app.py

import pandas as pd
from bokeh.plotting import figure, curdoc
from bokeh.models import ColumnDataSource, Select
from bokeh.layouts import column, row
from bokeh.palettes import Category10_3

# Load the dataset
df = pd.read_csv('https://raw.githubusercontent.com/mwaskom/seaborn-data/master/penguins.csv')
df.dropna(inplace=True)

# Map species to colors
species_unique = sorted(df['species'].unique())
color_map = {species: Category10_3[i] for i, species in enumerate(species_unique)}
df['color'] = df['species'].map(color_map)

# Create a ColumnDataSource
source = ColumnDataSource(data=df)

# --- Create Widgets ---
numeric_columns = df.select_dtypes(include=['float64', 'int64']).columns.tolist()
species_list = ['All'] + species_unique

x_axis_select = Select(title="Select X-axis", value="bill_length_mm", options=numeric_columns)
y_axis_select = Select(title="Select Y-axis", value="bill_depth_mm", options=numeric_columns)
species_select = Select(title="Select Species", value="All", options=species_list)

# --- Create the Plot ---
p = figure(height=500, width=700, title="Penguin Scatter Plot", tooltips=[("Species", "@species"), ("X", "@x"), ("Y", "@y")])
p.circle(x="x", y="y", source=source, size=10, color="color", legend_field="species")
p.xaxis.axis_label = x_axis_select.value
p.yaxis.axis_label = y_axis_select.value

# --- Define the Callback ---
def update_plot(attr, old, new):
    # Filter data based on species selection
    if species_select.value == 'All':
        filtered_df = df
    else:
        filtered_df = df[df.species == species_select.value]

    # Update source data
    source.data = {
        'x': filtered_df[x_axis_select.value],
        'y': filtered_df[y_axis_select.value],
        'species': filtered_df['species'],
        'color': filtered_df['color']
    }

    # Update axis labels
    p.xaxis.axis_label = x_axis_select.value
    p.yaxis.axis_label = y_axis_select.value

# Attach the callback to the 'value' property of each widget
for widget in [x_axis_select, y_axis_select, species_select]:
    widget.on_change('value', update_plot)

# --- Arrange Layout ---
controls = column(species_select, x_axis_select, y_axis_select, width=200)
layout = row(controls, p)

# Initialize the plot data
update_plot(None, None, None) 

curdoc().add_root(layout)
curdoc().title = "🐧 Palmer Penguins Explorer (Bokeh)"

📦GitHub Repository
A working implementation is available here:
🔗Other Visualization Tools
🚀Deploy

✅Conclusion: Which Tool Should You Use?

Choose Streamlit if: You are a data scientist who needs to build a beautiful, interactive tool quickly. You value simplicity and speed over granular control. Perfect for prototypes, internal tools, and ML model demos.
Choose Dash if: You are building a complex, production-ready application that requires a specific layout, multi-page functionality, and robust state management. You are comfortable with more boilerplate and a callback-driven architecture.
Choose Bokeh if: Your primary need is highly interactive, high-performance plotting, especially with large or streaming datasets. You want fine-grained control over your visualizations and are comfortable building the UI around them.

📝Enterprise Design Patterns: Repository Pattern in Enterprise Applications

Bruno Enrique ANCCO SUAÑA — Sat, 06 Sep 2025 04:03:09 +0000

Enterprise software development often involves handling complex domains, large datasets, and ever-evolving requirements. To manage this complexity, enterprise design patterns—as cataloged by Martin Fowler in his book Patterns of Enterprise Application Architecture—provide reusable solutions that improve code organization, scalability, and maintainability.

One of the most widely used patterns is the Repository Pattern.

🔍What is the Repository Pattern?
The Repository Pattern acts as a mediator between the domain (business logic) and the data mapping layers (databases, APIs, etc.). Instead of having application logic directly query the database, the repository provides a clean API for retrieving and persisting domain objects.

This brings several benefits:

Decouples business logic from persistence details.
Provides a more object-oriented view of data.
Centralizes data access logic.
Makes unit testing easier by mocking repositories.

🔍Context about Enterprise Application Architecture
The Repository Pattern is just one of many patterns described by Martin Fowler in his influential book Patterns of Enterprise Application Architecture (EAA). This catalog provides proven design solutions for recurring problems in large-scale business applications, where complexity, scalability, and maintainability are constant challenges.

Some of the most important categories in the EAA catalog include:

Domain Logic Patterns – How to structure the core business rules of an application. Examples: Transaction Script, Domain Model, Table Module.
Data Source Architectural Patterns – How to handle the persistence layer and communication with databases. Examples: Data Mapper, Active Record, Repository.
Object-Relational Behavioral Patterns – How objects interact with relational databases. Examples: Unit of Work, Identity Map, Lazy Load.
Web Presentation Patterns – How to structure user interfaces in enterprise web systems. Examples: Model View Controller (MVC), Page Controller, Front Controller.
Distribution Patterns – How to deal with distributed systems and remote calls. Examples: Remote Facade, Data Transfer Object (DTO).

By combining these patterns, enterprise developers can design systems that are easier to understand, test, and evolve. The Repository Pattern fits into the Data Source Architectural Patterns category, since its main goal is to separate domain logic from data persistence logic.

💻Real-World Example: Repository Pattern in Python
Imagine a simple enterprise app where we manage customers.
Step 1: Define the Domain Model

# domain/customer.py
class Customer:
    def __init__(self, customer_id: int, name: str, email: str):
        self.customer_id = customer_id
        self.name = name
        self.email = email

    def __repr__(self):
        return f"Customer(id={self.customer_id}, name='{self.name}', email='{self.email}')"

Step 2: Define the Repository Interface

# repository/customer_repository.py
from abc import ABC, abstractmethod
from typing import List, Optional
from domain.customer import Customer

class CustomerRepository(ABC):
    @abstractmethod
    def add(self, customer: Customer) -> None:
        pass

    @abstractmethod
    def get_by_id(self, customer_id: int) -> Optional[Customer]:
        pass

    @abstractmethod
    def list_all(self) -> List[Customer]:
        pass

Step 3: Implement a Concrete Repository (e.g., In-Memory)

# repository/in_memory_customer_repository.py
from typing import List, Optional
from domain.customer import Customer
from repository.customer_repository import CustomerRepository

class InMemoryCustomerRepository(CustomerRepository):
    def __init__(self):
        self._customers = {}

    def add(self, customer: Customer) -> None:
        self._customers[customer.customer_id] = customer

    def get_by_id(self, customer_id: int) -> Optional[Customer]:
        return self._customers.get(customer_id)

    def list_all(self) -> List[Customer]:
        return list(self._customers.values())

Step 4: Use the Repository in Application Logic

# app.py
from domain.customer import Customer
from repository.in_memory_customer_repository import InMemoryCustomerRepository

if __name__ == "__main__":
    repo = InMemoryCustomerRepository()

    # Add customers
    repo.add(Customer(1, "Alice", "alice@example.com"))
    repo.add(Customer(2, "Bob", "bob@example.com"))

    # Retrieve one customer
    print(repo.get_by_id(1))

    # List all customers
    print(repo.list_all())

When running python app.py, the output will be:

Customer(id=1, name='Alice', email='alice@example.com')
[Customer(id=1, name='Alice', email='alice@example.com'), Customer(id=2, name='Bob', email='bob@example.com')]

📦GitHub Repository
A working implementation of the Repository Pattern (including tests and CI/CD) is available here:
🔗Enterprise_Design_Patterns

The repository contains:

Domain models (domain/) – business entities such as Customer.
Repositories (repository/) – repository interfaces and implementations.
Application entry point (app.py) – demonstrates how to use the repository.
Unit tests (tests/) – test cases validating repository behavior.
GitHub Actions workflow (.github/workflows/python-ci.yml) – runs continuous testing on every push or pull request.

✅Conclusion
The Repository Pattern from Martin Fowler’s Patterns of Enterprise Application Architecture provides a clean way to abstract persistence logic in enterprise applications. By separating the domain model from the data access layer, applications become easier to maintain, test, and scale.
With GitHub integration and CI automation, the repository pattern becomes even more powerful in modern software engineering practices.

Software Design Principles (with Real-World Python Example)

Bruno Enrique ANCCO SUAÑA — Sat, 06 Sep 2025 03:19:22 +0000

> Introduction

Software design is not only about writing code that works — it’s about creating systems that are maintainable, scalable, and easy to understand. As applications grow, poorly structured code quickly becomes difficult to modify or extend, leading to bugs and unnecessary complexity.

To prevent this, developers rely on design principles: guidelines that help us write cleaner, more adaptable code. Among these, the most widely known are the SOLID principles.

> The SOLID Principles

Single Responsibility Principle (SRP)
A class should have only one reason to change. This avoids classes that are overloaded with multiple responsibilities.
Open/Closed Principle (OCP)
Software entities should be open for extension but closed for modification. We should be able to add new features without rewriting existing code.
Liskov Substitution Principle (LSP)
Subtypes must be substitutable for their base types without altering the correctness of the program.
Interface Segregation Principle (ISP)
Clients should not be forced to depend on methods they don’t use. Interfaces should be small and focused.
Dependency Inversion Principle (DIP)
High-level modules should not depend on low-level modules. Both should depend on abstractions.

> Real-World Example: A Notification System

Let’s imagine an application that sends notifications via different channels: email, SMS, and push.

❌ Poor Design (Violates SRP and OCP)

class NotificationService:
    def send_notification(self, message: str, channel: str):
        if channel == "email":
            print(f"Sending EMAIL: {message}")
        elif channel == "sms":
            print(f"Sending SMS: {message}")
        elif channel == "push":
            print(f"Sending PUSH: {message}")

Problems:

SRP Violation: One class handles multiple notification types.
OCP Violation: Adding a new channel requires editing this class.
Hard to Test: Logic for different responsibilities is mixed together.

✅ Improved Design (Applies SOLID in Python)

from abc import ABC, abstractmethod

# Abstraction (DIP, OCP)
class Notifier(ABC):
    @abstractmethod
    def send(self, message: str) -> None:
        pass

# Concrete implementations (SRP: one responsibility each)
class EmailNotifier(Notifier):
    def send(self, message: str) -> None:
        print(f"Sending EMAIL: {message}")

class SMSNotifier(Notifier):
    def send(self, message: str) -> None:
        print(f"Sending SMS: {message}")

class PushNotifier(Notifier):
    def send(self, message: str) -> None:
        print(f"Sending PUSH: {message}")

# Service that depends on abstraction (DIP)
class NotificationService:
    def __init__(self, notifier: Notifier):
        self.notifier = notifier

    def notify(self, message: str) -> None:
        self.notifier.send(message)

# Example usage
if __name__ == "__main__":
    email_service = NotificationService(EmailNotifier())
    sms_service = NotificationService(SMSNotifier())
    push_service = NotificationService(PushNotifier())

    email_service.notify("Welcome to our platform!")
    sms_service.notify("Your OTP is 123456")
    push_service.notify("You have a new message")

Why This Design is Better

SRP: Each class has a single job (email, SMS, or push).
OCP: Adding a new channel (e.g., SlackNotifier) requires no modification to existing code.
LSP: Any Notifier subclass can replace another without breaking the program.
DIP: NotificationService depends on the abstract Notifier, not concrete implementations.
Testability: Each notifier can be tested independently.

> Additional Design Concepts

While SOLID is a cornerstone, there are other important design principles:

DRY (Don’t Repeat Yourself): Avoid code duplication by extracting reusable components.
KISS (Keep It Simple, Stupid): Simpler solutions are easier to maintain and less error-prone.
YAGNI (You Aren’t Gonna Need It): Don’t add functionality until it’s actually required.
Composition Over Inheritance: Favor combining objects over deep inheritance hierarchies for flexibility.

Together, these principles help prevent code bloat, reduce bugs, and improve collaboration in large teams.

> GitHub Repository with Automation

A working implementation of this notification system (including tests and CI/CD) is available here:

Software_design_principles_python

The repository contains:

Source code (src/)
Unit tests (tests/)
A GitHub Actions workflow (.github/workflows/python-app.yml) for continuous testing

> Conclusion

Design principles are more than abstract theory: they shape how maintainable and extendable our systems are. By applying principles like SOLID, DRY, and KISS to something as simple as a notification system, we get code that is flexible, testable, and future-proof.

When applied consistently, these principles enable developers to write software that can evolve gracefully — even as requirements change or systems grow.

📝Comparative Guide to Testing Management Tools with Real-World Code and Public Example Repositories

Bruno Enrique ANCCO SUAÑA — Thu, 03 Jul 2025 01:04:16 +0000

Managing software testing efficiently is key for successful projects. Testing Management Tools streamline planning, tracking, and automating test cases. In this article, you'll find:

Core concepts and benefits of test management tools
A hands-on comparison of leading tools
Real code snippets for API integration
Public GitHub repositories for direct experimentation

What Are Testing Management Tools?

Testing Management Tools are platforms that help you create, organize, execute, and track software test cases and results. They support everything from manual to automated tests, integrate with CI/CD, and enable smooth collaboration across teams.

Key features:

Centralized test case management
Manual and automated test execution
Result tracking and dashboards
Bug tracking integration (e.g., Jira, GitHub Issues)
API access and CI/CD connectivity

Top Testing Management Tools (with Code & Repos)

1. TestRail

Commercial, enterprise-grade
Rich test case management, Jira integration, powerful API

API Integration Example (Python):

import requests

url = "https://<your_domain>.testrail.io/index.php?/api/v2/get_cases/<project_id>"
headers = {"Content-Type": "application/json"}
response = requests.get(url, headers=headers, auth=("user", "api_key"))
print(response.json())

Example repository:
https://github.com/gurock/testrail-api

2. TestLink

Open source, widely used
Classic web interface, bug tracker integration Create a Test Case via XML-RPC:

import xmlrpc.client

server = xmlrpc.client.ServerProxy('http://localhost/testlink/lib/api/xmlrpc/v1/xmlrpc.php')
devKey = 'your_dev_key'
testprojectid = 1
testsuiteid = 1

case = server.tl.createTestCase(devKey, 'API Test Case', testprojectid, testsuiteid, 'Steps...', 'Expected results...')
print(case)

Public repo:
https://github.com/TestLinkOpenSourceTRMS/testlink-code

3. Xray (for Jira)

Jira plugin, seamless native integration
Advanced test case management, automation via REST API Create a Test Issue via API:

curl -H "Content-Type: application/json" \
     -X POST -d '{"fields":{"project":{"key":"PROJ"},"summary":"API test case","issuetype":{"name":"Test"}}}' \
     -u user:api_token \
     https://<your_jira>.atlassian.net/rest/api/2/issue/

Example repo (Xray + CI):
https://github.com/Xray-App/xray-junit5-gradle-example

4. Allure TestOps

Modern platform with visual reporting and analytics
Deep integration with popular automation frameworks (JUnit, Cypress, Playwright, etc.) Integrate with Python (pytest + Allure):

import allure

@allure.title("Verify successful login")
def test_login():
    assert login("user", "password") is True

Example repo:
https://github.com/allure-examples/allure-examples/tree/master/pytest

Example: Automating Test Management

Suppose you have an automated test suite in Python (Pytest) and want to report results to Allure TestOps:

Annotate your tests:

import allure

@allure.story('Login Functionality')
def test_login_success():
    assert login('admin', 'password') is True

Run tests with Allure:

pytest --alluredir=./allure-results

Upload results to Allure TestOps (via CLI):

allurectl upload --endpoint https://your-allure-server --token <TOKEN> ./allure-results

Complete repo for hands-on:
https://github.com/allure-examples/allure-examples

Conclusion

Choosing the right test management tool depends on your project scale, budget, and tech stack.
All the tools in this guide help teams to manage, automate, and gain insight into the testing process, from startups to enterprises.

Applying API Testing Frameworks real world examples

Bruno Enrique ANCCO SUAÑA — Thu, 05 Jun 2025 15:31:58 +0000

API testing is essential for ensuring the reliability and performance of web services. Various frameworks facilitate this process, each offering unique features and capabilities. This article explores several prominent API testing frameworks, providing real-world code examples to illustrate their usage. Top 10 API Testing Tools for REST & SOAP Services

1. Rest-Assured (Java)

Rest-Assured is a Java-based library that simplifies testing RESTful APIs. Its syntax is expressive and BDD-like, making tests readable and maintainable.

Example:

This test sends a GET request to retrieve a post and asserts that the response has a status code of 200 and the userId is 1.

import io.restassured.RestAssured;
import org.junit.Test;
import static org.hamcrest.Matchers.*;

public class ApiTest {
    @Test
    public void testApiResponse() {
        RestAssured.given()
            .baseUri("https://jsonplaceholder.typicode.com")
        .when()
            .get("/posts/1")
        .then()
            .statusCode(200)
            .body("userId", equalTo(1));
    }
}

2. Karate (Java)

Karate is an open-source framework that combines API test automation, mocks, performance testing, and UI automation into a single framework. It uses a domain-specific language (DSL) to write tests in a readable format.

Example:

This feature file defines a scenario that sends a GET request and validates the response.

Feature: API Test

  Scenario: Validate API Response
    Given url 'https://jsonplaceholder.typicode.com/posts/1'
    When method GET
    Then status 200
    And match response.userId == 1

3. Postman (JavaScript)

Postman is a popular tool for API development and testing. It allows writing tests in JavaScript within its interface.

Example:

These tests check that the response status is 200 and that the response body contains a userId property.

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

pm.test("Response has userId", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData).to.have.property("userId");
});

4. PyRestTest (Python)

PyRestTest is a Python-based REST API testing tool that uses YAML for test case definitions. It's suitable for simple test scenarios.

Example:

This YAML file defines a test that sends a GET request to /users and validates the response status code and schema.

- config:
    - testset: "User API Tests"
    - base_url: "https://api.example.com"

- test:
    - name: "Get users"
    - url: "/users"
    - method: "GET"
    - headers: {'Content-Type': 'application/json'}
    - validators:
        - compare: {header: "status_code", comparator: "eq", expected: 200}
        - json_schema: {schema: {type: "array"}}

5. JMeter (Java)

Apache JMeter is primarily used for performance testing but also supports functional API testing. It allows creating test plans with various samplers and assertions.

Example:

This JMeter test plan sends a GET request to /users and asserts that the first user's id is 1.

<HTTPSamplerProxy>
  <stringProp name="HTTPSampler.domain">api.example.com</stringProp>
  <stringProp name="HTTPSampler.path">/users</stringProp>
  <stringProp name="HTTPSampler.method">GET</stringProp>
  <HeaderManager>
    <collectionProp name="HeaderManager.headers">
      <elementProp name="">
        <stringProp name="Header.name">Content-Type</stringProp>
        <stringProp name="Header.value">application/json</stringProp>
      </elementProp>
    </collectionProp>
  </HeaderManager>
  <JSONPathAssertion>
    <stringProp name="JSON_PATH">$[0].id</stringProp>
    <stringProp name="EXPECTED_VALUE">1</stringProp>
    <boolProp name="JSONVALIDATION">true</boolProp>
  </JSONPathAssertion>
</HTTPSamplerProxy>

Conclusion

Selecting the appropriate API testing framework depends on various factors, including the programming language, project requirements, and team expertise. Rest-Assured and Karate are excellent choices for Java developers, Postman offers a user-friendly interface for quick tests, PyRestTest is suitable for Python projects, and JMeter is ideal for performance testing scenarios.
By leveraging these frameworks, teams can ensure their APIs are robust, reliable, and meet the desired specifications.

🛡️Secure Your CI Pipeline in Minutes with HuskyCI (SAST for Multiple Languages) huskyci

Bruno Enrique ANCCO SUAÑA — Fri, 25 Apr 2025 16:19:46 +0000

In today’s fast-paced software world, integrating security into your CI/CD pipeline is no longer optional — it’s essential. Fortunately, there are open-source tools that make it easier than ever. In this article, I’ll show you how to use HuskyCI, a powerful open-source tool that performs security tests automatically as part of your CI process and centralizes all results for easy analysis.

🧠 What is HuskyCI?
HuskyCI (Husky Continuous Integration) is an open-source tool developed by Globo.com that automates security testing in CI pipelines. It runs Static Application Security Testing (SAST) tools for multiple programming languages and provides a centralized view of vulnerabilities across your projects.

🧪 It supports a wide range of tools and languages:

Python: Bandit, Safety
Ruby: Brakeman
JavaScript: NPM Audit, Yarn Audit
Java: SpotBugs + FindSecBugs
Go: Gosec

⚙️ Getting Started with HuskyCI
✅ Step 1: Clone the Repository

git clone https://github.com/globocom/huskyCI.git
cd huskyCI

✅ Step 2: Install with Docker and Docker Compose
Make sure you have Docker and Docker Compose installed. Then run:

make install
make run

This will spin up all necessary containers (API, workers, tools, database).

🛠️ How to Use HuskyCI
Once up and running, trigger scans by sending your code to the HuskyCI API or by integrating it into your GitHub Actions or GitLab CI pipeline.

Example scan via command-line:

curl -X POST http://localhost:8888/api/analysis \
-H "Content-Type: application/json" \
-d '{"repositoryURL":"https://github.com/.../huskyci-demo", "branch":"main"}'

HuskyCI will:

Clone the repository
Detect the programming language
Run the appropriate SAST tools
Store and return the results

📊 Sample Output
The response from the scan will include a list of findings, organized by tool and severity:

{
  "Bandit": [
    {
      "file": "vulnerable_app.py",
      "line": 5,
      "issue": "Subprocess call with shell=True",
      "severity": "High"
    }
  ],
  "Safety": [],
  ...
}

You can then visualize or process this data as needed.

🤖 GitHub Actions Integration
Want to trigger HuskyCI on each push or pull request? Here’s an example workflow:

name: HuskyCI Scan

on: [push, pull_request]

jobs:
  huskyci-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Trigger HuskyCI Scan
        run: |
          curl -X POST http://your-huskyci-instance/api/analysis \
          -H "Content-Type: application/json" \
          -d '{"repositoryURL":"...", "branch":"main"}'

Make sure your CI runner has access to your HuskyCI instance.

📦 Demo Repository
👉 Check out the full working example here:
🔗 https://github.com/Brunoenr02/HuskyCIDemo

This repo includes:

A vulnerable Python script
GitHub Actions workflow to trigger scans

✅ Conclusion
HuskyCI is a great solution if you want to automate security scans across multiple languages in your CI/CD workflows. It’s free, open-source, and battle-tested by major companies.

Start integrating HuskyCI today — your pipeline will thank you, and your code will be safer!

🛡️Scan and Secure Your Mobile App with AppSweep (SAST for Android)

Bruno Enrique ANCCO SUAÑA — Sun, 20 Apr 2025 23:02:07 +0000

Securing your mobile app doesn’t have to be complicated. In this quick guide, I’ll show you how to use AppSweep, a free static analysis tool (SAST) from Guardsquare, to find vulnerabilities.

🧠 What is SAST?
SAST (Static Application Security Testing) analyzes your source code without running it. It’s an essential technique to catch security issues early in your development process.

🔍 SAST helps you detect:

Code injections
Data leakage
Misconfigurations
Insecure coding practices

🛡️ What is AppSweep?
AppSweep is a free security scanner by Guardsquare that analyzes Android apps. It scans your APK and gives you a detailed report with vulnerabilities, risks, and practical remediation tips.

✅ Free and easy to use
✅ CI/CD integration
✅ Actionable recommendations
✅ Based on OWASP MASVS, CWE, and industry standards

🚀 How to Use AppSweep

Upload your APK to the AppSweep website, or
Use the official CLI to automate scans in your workflow.

You’ll get a full report with detailed findings and recommendations to help you fix issues fast.

💻 Installing the CLI
To use AppSweep via the terminal or in CI pipelines, install the CLI:

npm install -g @guardsquare/appsweep-cli

Authenticate with your API key:

appsweep auth --api-key YOUR_API_KEY

Then scan your APK:

appsweep scan --app-id YOUR_APP_ID ./path/to/your-app.apk

📦 CI/CD Integration
AppSweep works seamlessly with GitHub Actions, GitLab CI, Jenkins, and others.

Example with GitHub Actions:

- name: Scan with AppSweep
  run: |
    npm install -g @guardsquare/appsweep-cli
    appsweep auth --api-key ${{ secrets.APPSWEEP_API_KEY }}
    appsweep scan --app-id ${{ secrets.APPSWEEP_APP_ID }} ./build/outputs/apk/release/app-release.apk

📊 Custom Reports
Export results in JSON for further processing or integration:

appsweep scan --app-id ... --output report.json

📦 Demo Repository
👉 Check out the full working example here:
🔗 https://github.com/Brunoenr02/AppSweepDemo

✅ Conclusion
With tools like AppSweep, adding security checks to your mobile development workflow is easy, fast, and free. Don’t wait for production to find critical issues—scan early and often!