Forem: ROBERTO CARLOS HUAMAN RIVERA

📊 Beyond the Basics: Building and Deploying Interactive Python Dashboards (Streamlit, Dash, & Bokeh)

ROBERTO CARLOS HUAMAN RIVERA — Sun, 03 May 2026 00:34:12 +0000

When we talk about Data Visualization and Dashboards, enterprise tools like Tableau or PowerBI often dominate the conversation. However, for Data Scientists and Developers, these GUI-based tools can feel restrictive. What if you need complex machine learning integration, custom UI logic, or automated CI/CD deployments?

Enter the holy trinity of Python visualization tools: Streamlit, Dash, and Bokeh.

In this article, we will explore the differences between these powerful frameworks, build a real-world financial dashboard, and completely automate its deployment to the Cloud using Docker and GitHub Actions.

🛠️ The Contenders: Streamlit vs. Dash vs. Bokeh

Before writing code, let's understand which tool fits your use case:

1. Streamlit (The Sprinter) 🏃‍♂️

Streamlit turns data scripts into shareable web apps in minutes. All in pure Python. No frontend experience required.

Best for: Rapid prototyping, internal tools, and quick data exploration.
Pros: Incredibly low learning curve, fully reactive script execution.

2. Plotly Dash (The Architect) 🏢

Dash is written on top of Flask, Plotly.js, and React.js. It requires more boilerplate than Streamlit but offers enterprise-grade customization.

Best for: Production-grade analytics dashboards with complex layouts and interactivity.
Pros: Highly customizable UI, stateless callback architecture perfect for scaling.

3. Bokeh (The Artist) 🎨

Bokeh targets modern web browsers for presentation, providing elegant, concise construction of versatile graphics.

Best for: Massive datasets, streaming data, and highly custom interactive plots.
Pros: Incredible granularity over how visualizations render in the DOM.

🚀 Building a Real-World Example: A Stock Market Dashboard with Streamlit

Because we want to move from zero to deployed as fast as possible, we will use Streamlit to build a dynamic Stock Price Explorer.

The Application Code (`app.py`)

This simple script downloads historical financial data, visualizes it, and calculates moving averages interactively.

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

# Page configuration
st.set_page_config(page_title="Financial Dashboard", page_icon="📈", layout="wide")

st.title("📈 Interactive Financial Explorer")
st.markdown("Built with **Streamlit** to demonstrate rapid dashboard development.")

# Sidebar for user inputs
st.sidebar.header("User Parameters")
ticker = st.sidebar.selectbox("Select Asset", ("AAPL", "GOOGL", "MSFT", "BTC-USD"))
days = st.sidebar.slider("Number of days", 10, 365, 100)
ma_window = st.sidebar.number_input("Moving Average Window", 5, 50, 20)

# Simulate fetching data (Replacing heavy API calls for this demo)
@st.cache_data
def get_data(ticker, days):
    dates = pd.date_range(end=pd.Timestamp.today(), periods=days)
    prices = np.random.normal(loc=150, scale=10, size=days)
    df = pd.DataFrame({'Date': dates, 'Price': prices})
    df.set_index('Date', inplace=True)
    return df

data = get_data(ticker, days)
data['Moving Average'] = data['Price'].rolling(window=ma_window).mean()

# Visualization
st.subheader(f"Price History for {ticker}")
st.line_chart(data[['Price', 'Moving Average']])

# Raw Data Table
with st.expander("Show Raw Data"):
    st.dataframe(data.tail(10))

The Dependencies (`requirements.txt`)

streamlit==1.31.0
pandas==2.2.0
numpy==1.26.3

☁️ Deployment & Automation (CI/CD)

To make this a professional-grade project, we won't just run it on localhost. We will containerize it with Docker and automate its deployment using GitHub Actions.

Step 1: Containerizing the App (`Dockerfile`)

Create a file named Dockerfile in the root directory:

FROM python:3.10-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .

EXPOSE 8501

HEALTHCHECK CMD curl --fail http://localhost:8501/_stcore/health

ENTRYPOINT ["streamlit", "run", "app.py", "--server.port=8501", "--server.address=0.0.0.0"]

Step 2: GitHub Actions Automation (`.github/workflows/deploy.yml`)

We will set up a pipeline that lints our Python code and pushes the Docker container to GitHub Packages (which can then be pulled by any cloud provider like AWS, Render, or DigitalOcean).

name: Deploy Streamlit Dashboard

on:
  push:
    branches: [ "main" ]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    permissions:
      packages: write
      contents: read

    steps:
      - name: Checkout Code
        uses: actions/checkout@v3

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

      - name: Install dependencies and Lint
        run: |
          pip install flake8
          flake8 app.py --count --select=E9,F63,F7,F82 --show-source --statistics

      - name: Log in to GitHub Container Registry
        uses: docker/login-action@v2
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push Docker image
        uses: docker/build-push-action@v4
        with:
          context: .
          push: true
          tags: ghcr.io/${{ github.repository_owner }}/financial-dashboard:latest

Every time you push to the main branch, GitHub Actions will automatically check your code for errors, build the Docker container, and host it on the cloud!

🎯 Conclusion

While Tableau and PowerBI are fantastic, code-based visualization tools like Streamlit, Dash, and Bokeh unlock infinite potential for data scientists. By leveraging Python, we can integrate machine learning models, build custom UIs, and seamlessly deploy our applications into modern DevOps pipelines.

🚀 Spec-Driven Development (SDD): Building Robust Software Before Writing a Single Line of Logic

ROBERTO CARLOS HUAMAN RIVERA — Sun, 03 May 2026 00:28:32 +0000

Have you ever spent weeks building a backend API, only to have the frontend team tell you, "Wait, this isn't the data format we agreed on"?

In traditional "code-first" development, developers jump straight into writing logic. The documentation and contracts are treated as an afterthought. This leads to broken integrations, endless debugging, and frustrated teams. Enter Spec-Driven Development (SDD) (also known as API-First Design).

In SDD, you write the Specification (the contract) before you write any code. This spec becomes the single source of truth for your backend, frontend, and QA teams.

In this article, we will explore SDD using a real-world example: building a Task Management API using OpenAPI (Swagger), Node.js, and automating the validation process using GitHub Actions.

🏗️ The Real-World Example: A Task Management API

Imagine we are building a simple system to manage daily tasks. Instead of opening index.js and writing Express routes, we start by writing an OpenAPI specification.

Step 1: Writing the Specification (The Contract)

We define our API contract in a file called openapi.yaml. This file dictates exactly what the endpoints are, what data they require, and what they will return.

# openapi.yaml
openapi: 3.0.0
info:
  title: "Task Management API"
  version: 1.0.0
  description: "A simple API to manage tasks, built with Spec-Driven Development."
paths:
  /tasks:
    get:
      summary: Get all tasks
      responses:
        '200':
          description: "A list of tasks"
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Task'
    post:
      summary: Create a new task
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/NewTask'
      responses:
        '201':
          description: "Task created successfully"

components:
  schemas:
    Task:
      type: object
      required: [id, title, completed]
      properties:
        id:
          type: string
          format: uuid
        title: ""
          type: string
        completed:
          type: boolean
    NewTask:
      type: object
      required: [title]
      properties:
        title: ""
          type: string
          minLength: 3

By writing this first, the frontend team can immediately start building the UI using mock servers, while the backend team starts implementing the logic.

Step 2: Implementation (The Code)

Now that we have our contract, we will write our backend. To make this truly Spec-Driven, we won't just write code that hopefully matches the spec; we will use a library called express-openapi-validator to force our code to obey the spec.

Here is the Node.js implementation:

// index.js
const express = require('express');
const path = require('path');
const OpenApiValidator = require('express-openapi-validator');

const app = express();
app.use(express.json());

// 1. Install the OpenAPI Validator middleware
// This automatically reads our openapi.yaml and validates all incoming requests
app.use(
  OpenApiValidator.middleware({
    apiSpec: path.join(__dirname, 'openapi.yaml'),
    validateRequests: true, // Fail if request doesn't match spec
    validateResponses: true // Fail if our server sends a bad response
  })
);

// 2. Dummy Database
let tasks = [
    { id: "123e4567-e89b-12d3-a456-426614174000", title: "Learn SDD", completed: false }
];

// 3. Define Routes
app.get('/tasks', (req, res) => {
  res.status(200).json(tasks);
});

app.post('/tasks', (req, res) => {
  // We don't need to write validation logic like `if(!req.body.title)`!
  // The OpenAPI validator already checked it against the YAML spec.
  const newTask = {
      id: "987e6543-e21b-34d3-b123-426614174111", // In reality, generate a UUID
      title: req.body.title,
      completed: false
  };
  tasks.push(newTask);
  res.status(201).json(newTask);
});

// 4. Error Handler for Validation Errors
app.use((err, req, res, next) => {
  res.status(err.status || 500).json({
    message: err.message,
    errors: err.errors,
  });
});

app.listen(3000, () => {
  console.log('Server running on port 3000. Protected by OpenAPI!');
});

Because of SDD, if a client tries to send {"title": "ab"} (which violates the minLength: 3 rule in our YAML), the server will automatically reject it with a 400 Bad Request. No extra code required!

Step 3: GitHub Version Control & Automation (CI/CD)

To achieve maximum efficiency (and max points for your assignment!), your code must live in a Version Control System (GitHub) with Automation.

The Repository Structure:

my-sdd-project/
├── .github/
│   └── workflows/
│       └── lint-spec.yml   <-- CI/CD Automation
├── package.json
├── index.js                <-- Application Code
└── openapi.yaml            <-- The Specification

The Automation:
We want to ensure that nobody merges a broken API specification into the main branch. We can automate this using GitHub Actions and a tool called Spectral (a JSON/YAML linter for APIs).

Create a file at .github/workflows/lint-spec.yml:

name: Lint OpenAPI Spec

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  validate-spec:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install Spectral
        run: npm install -g @stoplight/spectral-cli

      - name: Lint OpenAPI Document
        run: spectral lint openapi.yaml --ruleset spectral:oas

What does this automation do?
Every time a developer makes a Pull Request, GitHub Actions will spin up a server, read the openapi.yaml file, and check it for errors, missing descriptions, or bad formatting. If the spec is broken, the code cannot be merged.

Conclusion

Spec-Driven Development shifts the focus from writing code to designing architecture. By treating the Specification as a first-class citizen and automating its validation via CI/CD pipelines, teams can eliminate miscommunications, reduce bugs, and deliver higher-quality software significantly faster.

Remember: Design first, code second.

Code That Lasts: Mastering Software Design Principles (with Golang)

ROBERTO CARLOS HUAMAN RIVERA — Sun, 03 May 2026 00:21:09 +0000

Have you ever looked at code you wrote six months ago and thought: "Who wrote this monster?"? Relax, it happens to all of us.

In software engineering, writing code that a machine understands is the easy part. The real challenge is writing code that other humans (including your future self) can understand, maintain, and scale. This is exactly where Software Design Principles come into play.

In this extensive article, we are going to break down the fundamental design principles (SOLID, DRY, KISS, YAGNI) and apply them to a real-world scenario using Golang.

Grab your cup of coffee ☕, open your favorite editor, and let's get to it!

🧭 1. The Three Musketeers of Clean Code: KISS, YAGNI, and DRY

Before diving into complex architectures, we need to master the baseline philosophy. These three acronyms are your first line of defense against "spaghetti code."

💋 KISS: Keep It Simple, Stupid

Complexity is the enemy of maintainability. If you have to read a function five times to understand what it does, it's not clever; it's unnecessarily complex.

Symptom of violation: 300-line functions, multiple nested loops, variables with cryptic names (x, val, data2).
The solution: Divide and conquer. Write declarative code whenever possible.

🔮 YAGNI: You Aren't Gonna Need It

Developers are often frustrated fortune tellers. We frequently build abstractions for use cases that might happen in the future. 99% of the time, those cases never arrive, and we are left with dead, abstract code that only causes confusion.

Golden rule: Implement things when you actually need them, never when you just foresee needing them.

🌵 DRY: Don't Repeat Yourself

Every piece of knowledge or logic must have a single, unambiguous representation within a system.

Watch out for "False Duplication": Not all code that looks the same violates DRY. If two identical blocks of code change for entirely different reasons (they belong to different business domains), merging them can accidentally couple the system.

🏛️ 2. The Heart of Design: The S.O.L.I.D. Principles

Proposed by Robert C. Martin (Uncle Bob), these five principles are the compass for object-oriented programming and structured system design. Golang is not a traditional object-oriented language (it doesn't have classes or inheritance), but its use of structs and interfaces makes it a brilliant candidate for SOLID.

[S] Single Responsibility Principle (SRP)

A struct, package, or function should have one, and only one, reason to change.

❌ Bad Design: A service that calculates taxes and also sends emails.
✅ Good Design:

// 📦 package: order
type OrderProcessor struct {
    // Pure order logic
}

// 📦 package: notification
type EmailSender struct {
    // Pure email sending logic
}

[O] Open/Closed Principle (OCP)

Software entities should be open for extension, but closed for modification.

Instead of modifying existing code (and risking breaking it) every time there is a new requirement, you should be able to add new behavior by extending the code. In Go, we achieve this using Interfaces.

[L] Liskov Substitution Principle (LSP)

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

In Go, this means that any type implementing an interface must fulfill the "contract" of that interface without causing hidden panics or unexpected behaviors.

[I] Interface Segregation Principle (ISP)

Clients should not be forced to depend upon interfaces that they do not use.

Visual Outline of the Principle:

[Client A] ---X---> (Giant Interface: Read(), Write(), Delete(), Audit())
                 |
[Client A] -------> (Small Interface: Read())

In Go, small interfaces (1 to 3 methods) are the norm. Think of io.Reader or io.Writer.

[D] Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Inverting the dependency means that your business logic dictates the contracts (interfaces), and the infrastructure (databases, external APIs) adapts to them.

🚀 3. Real-World Case: A Payment Processing System in Golang

Let's see all of this in action. Imagine we work at an e-commerce company and we need to process payments.

🚨 Scenario 1: Spaghetti Code (Violating the principles)

Look at this code. Changing anything here is a nightmare. If we want to add "Cryptocurrency" payments, we have to modify the main function, violating OCP and SRP.

package main

import "fmt"

type PaymentProcessor struct{}

// Massive violation of SRP and OCP
func (p *PaymentProcessor) Process(amount float64, method string) {
    if method == "credit_card" {
        fmt.Printf("Connecting to Card API... paying $%.2f\n", amount)
        // 100 lines of HTTP logic...
    } else if method == "paypal" {
        fmt.Printf("Connecting to PayPal... paying $%.2f\n", amount)
        // Another 100 lines of SDK logic...
    }

    // SRP Violation: The payment processor also saves to the DB
    fmt.Println("Saving transaction to MySQL...")
}

✨ Scenario 2: Clean Architecture using SOLID (The Golang Way)

Let's refactor this monster by applying Small Interfaces (ISP), Dependency Inversion (DIP), and keeping it Closed for modification (OCP).

Step 1: Define the Abstractions (Contracts)

We create clear interfaces. The order system doesn't need to know how the payment is processed or how it's saved.

package payment

// ISP: Small, focused interfaces
type Payer interface {
    Pay(amount float64) error
}

type TransactionRepository interface {
    Save(amount float64, status string) error
}

Step 2: Implement the Details (Low Level)

Now we create concrete structs for each payment method. If tomorrow we need Apple Pay, we just create a new struct. The existing code remains untouched! (OCP).

package payment

import "fmt"

// Credit Card Implementation
type CreditCard struct {
    Token string
}

func (cc *CreditCard) Pay(amount float64) error {
    fmt.Printf("💳 Processing $%.2f via Credit Card...\n", amount)
    return nil
}

// PayPal Implementation
type PayPal struct {
    Email string
}

func (pp *PayPal) Pay(amount float64) error {
    fmt.Printf("🅿️ Processing $%.2f via PayPal...\n", amount)
    return nil
}

// Database Implementation
type MySQLRepository struct{}

func (db *MySQLRepository) Save(amount float64, status string) error {
    fmt.Printf("💾 Saving transaction of $%.2f in the MySQL DB...\n", amount)
    return nil
}

Step 3: The High-Level Module (Dependency Inversion)

Our core service now depends on abstractions, not on concrete details.

package payment

import "fmt"

// CheckoutService coordinates the operation, but ignores the details
type CheckoutService struct {
    paymentMethod Payer                  // Injected Dependency
    repository    TransactionRepository  // Injected Dependency
}

// Constructor to ensure we inject the dependencies
func NewCheckoutService(p Payer, r TransactionRepository) *CheckoutService {
    return &CheckoutService{
        paymentMethod: p,
        repository:    r,
    }
}

func (c *CheckoutService) Checkout(amount float64) {
    err := c.paymentMethod.Pay(amount)
    if err != nil {
        fmt.Println("❌ Payment error")
        return
    }

    c.repository.Save(amount, "SUCCESS")
    fmt.Println("✅ Checkout completed successfully")
}

Step 4: Putting it all together in `main`

The "magic" happens when assembling the pieces.

package main

import (
    "example/payment" // Assuming this is the package path
    "fmt"
)

func main() {
    // 1. Instantiate the infrastructure (Low Level)
    db := &payment.MySQLRepository{}

    fmt.Println("--- Client 1 chooses Card ---")
    cc := &payment.CreditCard{Token: "tok_123"}
    checkout1 := payment.NewCheckoutService(cc, db)
    checkout1.Checkout(150.50)

    fmt.Println("\n--- Client 2 chooses PayPal ---")
    paypal := &payment.PayPal{Email: "user@test.com"}
    checkout2 := payment.NewCheckoutService(paypal, db)
    checkout2.Checkout(89.99)
}

Resulting Architecture Outline:

+-----------------------+       +-------------------+       +-----------------------+
|  High-Level Module    |       |    Abstraction    |       |   Low-Level Module    |
|-----------------------|       |-------------------|       |-----------------------|
|                       |       |                   |       |                       |
|   CheckoutService     | ----->|   Payer (Int.)    |<----- |   CreditCard (Struct) |
|                       |       |                   |       |                       |
+-----------------------+       +-------------------+       +-----------------------+

🎯 Conclusion: Why go through this trouble?

At first glance, applying these principles (especially SOLID) seems to generate more code. And technically, it's true: we went from 1 file and 20 lines to multiple files and structs.

However, the goal of Software Design is not to write less code, but to write code that is highly cohesive and loosely coupled.

Thanks to this design in Go:

Testing: We can easily mock payments and the database using interfaces, allowing for lightning-fast unit tests.
Teamwork: One developer can work on PayPal while another works on CreditCard without running into Git conflicts.
Maintainability: If there is a bug in card processing, we know exactly which file to look at, without fear of breaking the PayPal logic.

Code is like a house. If you build on mud (coupled code), any future renovation will tear down the walls. If you build on a solid foundation (design principles), you can add infinite floors to your skyscraper.