DEV Community: Hernan Chilabert

Why Your Celery Dashboard is Lying to You (and How I’m Using AI to Fix It)

Hernan Chilabert — Fri, 02 Jan 2026 21:52:32 +0000

We've all been there. The Datadog dashboard is a sea of green. Redis is connected. Workers are "Online." Yet, the support tickets are flooding in: "Why haven't I received my password reset email?"

I realized that standard monitoring has a massive blind spot. It monitors infrastructure status, not business health.

The Problem: The "Silent Killers" In high-scale environments, your system doesn't always "crash." It degrades silently.

Ghost Workers: Processes that are alive in Docker but disconnected from the Celery control plane.
Task Vanishing: Tasks that drop out of Redis without a single log entry.
The Latency Illusion: A short queue that hides a task stuck for 45 minutes because of a misconfigured visibility timeout.

The Solution

An Audit CLI with a "Brain" I decided to build a tool that automates the manual troubleshooting I used to do via SSH. But listing metrics wasn't enough. I wanted a report that a Senior Dev could act on in seconds.

I integrated Claude to act as a "Virtual SRE." Instead of just showing you a configuration value, the CLI interprets the data.

The "WOW" Report: Check out this output from a recent test:

Your visibility_timeout is 30 minutes. I found 3 tasks that regularly exceed 45 minutes.

💀 Impact if uncaught: These tasks WILL execute twice. Both will complete → duplicate execution.

🎯 Business Impact: If process_bulk_import duplicates, you'll have duplicate inventory entries. If generate_monthly_report duplicates, you'll email customers twice.

⚡ Fix (add to celeryconfig.py): broker_transport_options = {'visibility_timeout': 7200} # 2 hours

Why AI?

Logs are for machines; reports are for humans. By using LLMs to cross-reference task history with infrastructure settings, the CLI doesn't just find bugs; it finds business risks. It explains the why, the so what, and the how to fix it.

What's Next?

I'm currently stress-testing this on production environments. If you're tired of "green dashboards" that hide real problems, I'd love for you to join the beta.

Which are your 'silent killers'? How did you fix them?

My AI Unit Test Agent is Alive! Now for Part 2: The QA Agent 🤖

Hernan Chilabert — Thu, 21 Aug 2025 17:21:55 +0000

Hey everyone!

Just a week ago, I shared that I started building an AI agent to handle my unit tests in Python. Well, the little guy is officially up and running!

Phase 1 is a wrap! The MVP is working as planned: it can analyze a Python file, figure out what's inside, and use an LLM to generate a solid suite of pytest tests. It feels a bit like magic watching it work. I'm super happy with the foundation we've got.

But now... the real fun begins.

Entering Phase 2: The "QA Engineer" Agent

The first agent is the "Dev Engineer"—it writes the code. Now, I'm building its partner: the "QA Engineer" agent.

So, what's its job? This new agent will:

Run the Tests: It will actually execute pytest on the tests the first agent wrote.
Check for Errors: Did the tests pass? Did they fail? Why?
Provide Feedback: It will then go back to the "Dev Engineer" and say something like, "Hey, this test you wrote is failing because of X," or "You missed covering this edge case."

The goal here is to create an autonomous feedback loop. The two agents will collaborate, refine, and improve the tests until they meet a certain quality bar, all on their own. Wild, right?

This is the part of the project I've been most excited about, where it starts to feel less like a script and more like a real, autonomous team.

As always, the project is fully open-source. You can follow along with the progress, check out the code, and see the roadmap on GitHub.

👉 GitHub Repo: herchila/unittest-ai-agent

Thanks for reading and following the journey! Let me know in the comments what you think about this two-agent approach.

I'm Building an AI Agent to Write My Unit Tests

Hernan Chilabert — Thu, 14 Aug 2025 17:26:47 +0000

Hey DEV community! 👋

Like many of you, I've spent countless hours writing unit tests. It's one of the most critical parts of building reliable software, but it can also be a real grind. As I've been diving deeper into the world of AI Agents, I thought: what if I could automate this?

So, I started a tiny project to build my own AI agent to handle it. This is my journey of learning in public, and I wanted to share the first version with you all.

What I've Built So Far: The "Dev Engineer" Agent

The first phase is a simple but functional "Dev Engineer" agent. The concept is straightforward:

You give it a Python source file.
It gives you back a test_.py file with unit tests ready to run with pytest.

Under the hood, it's a Python script using LangChain to manage the logic and OpenAI LLM. It's a simple, powerful starting point.

The Big Picture: An Autonomous Testing Team

This is just the beginning. The ultimate goal isn't just to generate tests, but to create a collaborative team of AI agents that can ensure code quality autonomously. The vision is to build a "QA Engineer" agent that will work alongside the "Dev Engineer" in a feedback loop:

The Dev Agent writes the tests.
The QA Agent runs them, checks for failures, and analyzes code coverage.
If anything is wrong, the QA Agent sends feedback to the Dev Agent.
The Dev Agent corrects the tests and sends them back.
...and so on, until we have a robust and passing test suite.

Let's Build This Together! (Call for Collaboration)

This project is my personal learning playground, but I believe it has the potential to become a genuinely useful tool for the community. That's where you come in.

I'm building this completely open source, and I would love for you to get involved. Whether you're an AI expert or just a curious developer, there are plenty of ways to contribute:

Check out the code and give feedback.
Suggest new features or improvements.
Tackle an open issue or a task from the roadmap below.

I've laid out a clear plan for where the project is headed. Take a look and see if anything sparks your interest!

🚀 Project Roadmap

This project is under active development. Below is a summary of my progress and a look at what's ahead. Contributions are highly encouraged!

✅ Phase 1: Core Test Generation Engine (MVP)
[x] Develop "Dev Engineer" Agent: A core agent capable of generating unit tests from a single Python source file.

[x] LLM Integration: Connect the agent to a foundational LLM (e.g., GPT-4o, Llama 3) to power code generation.

[x] Basic CLI: A simple command-line interface to input a file and receive the generated test file.

🎯 Phase 2: Multi-Agent Collaboration & Feedback Loop
[ ] Introduce "QA Engineer" Agent: Develop a second agent responsible for reviewing, validating, and executing the generated tests.

[ ] Implement Test Execution Tool: Create a secure tool for the QA Agent to programmatically run pytest, capture results, and parse code coverage reports.

[ ] Establish Collaborative Framework (CrewAI): Refactor the agent logic into a Crew to manage the feedback loop, allowing the Dev Agent to fix tests based on the QA Agent's feedback until a target coverage is achieved.

🏗️ Phase 3: API-First Architecture & State Management
[ ] Expose via API: Wrap the agent crew in a FastAPI application to make it accessible as a service.

[ ] Job State Management: Integrate Redis or a database to manage the state of long-running jobs, allowing for asynchronous operation.

[ ] Containerization: Create a Dockerfile and docker-compose.yml to ensure a consistent and reproducible environment for the entire application stack.

✨ Future Vision
[ ] LLMOps & Observability: Integrate with tools like LangSmith to trace, debug, and evaluate the performance of the agent interactions.

[ ] IDE Integration: Develop a VSCode extension for a seamless developer experience right within the editor.

[ ] Multi-Language Support: Expand capabilities beyond Python to include other languages like JavaScript/TypeScript and Go.

[ ] Automated Code Refactoring: Empower the Dev Agent to suggest fixes in the source code itself, not just the tests.

You can find the repository with all the code for Phase 1 here:

👉 https://github.com/herchila/unittest-ai-agent

What do you think? What other developer chores do you wish you could automate with AI? Let me know in the comments below!

See you!

Deploy a Django App in 2 Minutes with Astra

Hernan Chilabert — Mon, 26 May 2025 22:14:00 +0000

This post originally appeared on the Astra blog: getastra.xyz/blog/deploy-django-in-2-minutes

Introduction

Deploying a Django app can be overwhelming, especially if you're not a DevOps expert. Configuring servers, setting up a reverse proxy, managing HTTPS, or provisioning a database can quickly become time-consuming.

With Astra, you can go from code to production with just a few clicks.

In this tutorial, you'll learn how to:

Connect your GitHub repo to Astra
Deploy your Django app on a cloud server
Access it live with HTTPS and logs, no manual setup needed

Prerequisites

Before we start, make sure you have:

A Django project in a GitHub repository (public)
A free Astra account (you can sign up at getastra.xyz)
Basic knowledge of Django (no infra knowledge required)

Step 1: Prepare Your Django App

Astra works best when your project has:

A requirements.txt file
A .env.sample file (for environment variables)
A WSGI or ASGI entry point (wsgi.py or asgi.py)
Static files correctly configured (collectstatic)

Step 2: Sign in to Astra and Connect Your GitHub

Visit getastra.xyz and log in.
Authorize Astra to access your GitHub account.
Click “New Project”, select your repository, and choose the branch you want to deploy.

Step 3: Configure Your Environment Variables

Astra auto-detects your .env.sample file and prompts you to fill in values like:

SECRET_KEY
DEBUG
...

You can edit them directly in the UI, and they'll be injected into your running app.

Step 4: Deploy and Watch the Magic

Click Deploy, and Astra will:

Provision a server (shared or dedicated, depending on your plan)
Clone your repo and install dependencies
Collect static files and apply migrations
Start your app with Gunicorn or Uvicorn (for FastAPI)
You'll see real-time logs during setup.

Step 5: Visit Your Live App

Once the deploy is complete, Astra gives you a live URL like:

https://myproject.getastra.xyz/

The site is already running with:

HTTPS enabled (via Let's Encrypt)
Static files served correctly
A PostgreSQL database (via Neon or Supabase, if configured)

Bonus: Update and Redeploy Anytime

Make changes to your code? Just push to GitHub and hit Redeploy in the dashboard. Astra reuses the infra and deploys only what's changed.

Conclusion

No Docker. No server setup. No DevOps stress.

Deploy your Django app in minutes with Astra.

Ready to deploy your next Django app in minutes?

Try Astra for free → getastra.xyz

Why I’m Building Astra to Fix Python Deployment Pain

Hernan Chilabert — Wed, 19 Mar 2025 00:57:57 +0000

Hey Python devs,

I’ve been coding in Python for years—Django, FastAPI, Flask, you name it. But every time I wanted to deploy a project, I hit the same wall: DevOps. Configuring servers, tweaking Nginx, wrestling with Docker—it’s a hassle that steals time from what I love: building apps.

That’s why I started Astra, a 1-click deployment platform built exclusively for Python developers. Think Vercel, but laser-focused on our ecosystem. No more SSH nightmares or "works on my machine" excuses—just deploy your app in minutes and move on.

Where We’re At

As of today (March 2025), Astra’s in MVP mode. I’ve got 5 devs on the waitlist and 3 projects running smoothly on a single DigitalOcean droplet with Docker and Nginx. It’s not perfect yet—still tweaking scalability—but it’s a start. My goal? Make deployment so easy you forget it’s even a step.

Why Python Deserves This

General platforms like Vercel are great, but Python’s frameworks have unique needs. Django’s migrations, FastAPI’s async power, Flask’s lightweight vibe—they deserve a tool that “gets” them. Astra’s my attempt to deliver that.

What’s Next?

I’m building in public, so you’ll see the journey unfold. Next up: pushing toward 20 waitlist signups by March’s end and exploring serverless for true scalability. If you’re a Python dev tired of deployment headaches, I’d love your thoughts—what’s your biggest pain point? Drop a comment below!

Join the Ride

Want in? Hop on the waitlist at getastra.xyz. We’re just getting started, and your feedback could shape Astra’s future.

Hernán
Astra Founder

Understanding Big O Notation: The Key to Efficient Algorithms

Hernan Chilabert — Mon, 26 Feb 2024 13:42:03 +0000

Understanding how to measure and optimize the performance of your algorithms is crucial. This is where Big O Notation comes into play. It's not just a theoretical concept but a practical tool that helps in assessing the efficiency of algorithms in terms of time and space complexity. Let's delve into this cornerstone concept of computer science.

What is Big O Notation?

Big O Notation is a mathematical representation used to describe the performance of an algorithm. Specifically, it measures the worst-case scenario of an algorithm's runtime or space requirements as a function of the input size. In simpler terms, it tells you how fast an algorithm grows relative to the input size.

Why is Big O Notation Important?

Performance Prediction: It helps in predicting how an algorithm will perform as the size of the input data increases.
Efficiency Comparison: It provides a way to compare the efficiency of different algorithms for the same task.
Bottleneck Identification: It assists in identifying potential bottlenecks in code, guiding developers in optimizing their algorithms.

Common Big O Notations

O(1) - Constant Time: Execution time remains constant rega
rdless of input size.
O(n) - Linear Time: Execution time increases linearly with input size. Example: Linear search.
O(log n) - Logarithmic Time: Execution time increases logarithmically with input size. Example: Binary search.
O(n log n) - Linearithmic Time: Combines linear and logarithmic complexities. Common in efficient sorting algorithms like mergesort and heapsort.
O(n^2) - Quadratic Time: Execution time is proportional to the square of the input size. Common in algorithms with nested loops, such as bubble sort.
O(n^3) - Cubic Time: Execution time is proportional to the cube of the input size. Less common, but seen in certain algorithms involving three nested loops.
O(2^n) - Exponential Time: Execution time doubles with each additional input element. Seen in some recursive algorithms, especially those that solve the subsets of a set.
O(n!) - Factorial Time: Execution time grows factorially with the input size. Common in algorithms that compute all permutations of a set (e.g., the traveling salesman problem via brute-force search).

👉 Read and share your thoughts: https://astrocodecraft.substack.com/p/understanding-big-o-notation

Understanding Getter, Setter and Private variables in Python

Hernan Chilabert — Sat, 27 Jan 2024 15:47:07 +0000

In the realm of object-oriented programming, encapsulation is a fundamental concept, crucial for ensuring data integrity and hiding implementation details from the user. Python, known for its simplicity and readability, employs getters and setters as part of this encapsulation. This article delves into the purpose and implementation of getters and setters in Python, providing insights into their role in managing data access and maintaining object integrity.

What are Getters, Setters and Private Variables?

Getters and setters are methods used in object-oriented programming to ensure data encapsulation. In Python, they serve a twofold purpose:

Getters are methods used to access or 'get' the value of an object's attributes. They provide a way to read data without directly accessing the attributes.
Setters are methods used to change or 'set' the value of an object's attributes. They allow for data modification while implementing checks or validations.
Private Variables: Attributes prefixed with an underscore (_) or double underscore (__), indicating they should not be accessed directly outside the class.

The Role of Private Variables

Private variables in Python are not enforced as strictly as in some other languages. The convention is to prefix the attribute name with an underscore (_) for protected (internal use) or double underscore (__) for private (name mangled). This signals that the attribute is not intended to be accessed directly.

Example of Private Variables:

In this example, __price is a private variable of the Product class.

Why Use Private Variables?

Encapsulation: They hide the internal state of an object from outside interference.
Security: Prevents external entities from modifying the state in an uncontrolled manner.
Maintenance: Makes it easier to change the attribute implementation without affecting external users.

Implementing Getters and Setters in Python

Using the property() Function

Python provides a property function that makes the implementation of getters and setters straightforward and intuitive. Here’s how you can use them:

Here, __price is a private variable accessed and modified through the price property. The property decorator makes the getter and setter more elegant and easy to use.

Using the @property Decorator

Python also allows a more elegant way of defining properties using decorators:

This approach enhances readability and maintains the Pythonic style of simple and clean code.

Getters, Setters, and Private Variables are fundamental in Python for encapsulating data and controlling access to an object's attributes. They contribute to writing robust, maintainable, and secure code. Understanding and implementing these concepts is vital for Python developers to leverage the full potential of object-oriented programming in Python.

✨ Do you like this kind of article? I invite you to see more of that here: https://astrocodecraft.substack.com

Top 10 advanced Python concepts that every developer should know - Part 1

Hernan Chilabert — Wed, 03 Jan 2024 23:27:01 +0000

Astro Code Craft's 'Top 10 Advanced Python Concepts Every Developer Should Know - Part 1' is a must-read for Python enthusiasts aiming to enhance their skills. This insightful article delves into complex Python topics, providing a deeper understanding of advanced programming techniques. It's an excellent resource for developers looking to elevate their coding expertise and stay ahead in the dynamic world of Python programming.

For more detailed insights, you can read the full article here.

Behavioral Patterns: Streamlining Complex Interactions

Hernan Chilabert — Fri, 01 Dec 2023 00:27:10 +0000

[UPDATED 12/7/2023]
✨ GitHub repo with real-world use cases: https://github.com/herchila/design-patterns/tree/main/behavioral_patterns

Chain of Responsibility Pattern

Purpose: To pass a request along a chain of handlers. Upon receiving a request, each handler decides either to process it or to pass it to the next handler in the chain.

Example: A logging system that sends messages to different handlers (console, file, email) based on the message's severity.

class Handler:
    def __init__(self, successor=None):
        self._successor = successor

    def handle(self, request):
        res = self.check_request(request)
        if not res and self._successor:
            self._successor.handle(request)

    def check_request(self, request): pass

class ConsoleHandler(Handler):
    def check_request(self, request):
        if request < 3:
            print(f"Console: {request}")
            return True

class FileHandler(Handler):
    def check_request(self, request):
        if 3 <= request < 5:
            print(f"File: {request}")
            return True

class EmailHandler(Handler):
    def check_request(self, request):
        if request >= 5:
            print(f"Email: {request}")
            return True

# Usage
chain = ConsoleHandler(FileHandler(EmailHandler()))
chain.handle(2)  # Console: 2
chain.handle(4)  # File: 4
chain.handle(5)  # Email: 5

Real-world use case

** Scenario**:
Imagine a Customer Support System for a technology company that provides various services such as hardware repair, software troubleshooting, and account management. Customers can reach out with a wide range of issues, from simple password resets to complex hardware malfunctions. The system needs to handle these queries efficiently, ensuring that each issue is addressed by the most appropriate department. Without proper handling, queries could be misdirected, leading to delays and customer dissatisfaction.

Problem:
The challenge lies in efficiently categorizing and routing these customer queries to the right department. Handling this manually can be error-prone and inefficient. Moreover, as the company grows and the range of services expands, the system must be adaptable to handle new types of queries without major overhauls.

Solution:
The Chain of Responsibility pattern is ideal for this situation. It allows us to pass requests along a chain of handlers. Each handler decides either to process the request or to pass it to the next handler in the chain.

class Handler:
    """Abstract Handler: inherited by all concrete handlers."""
    def __init__(self, successor=None):
        self._successor = successor

    def handle_request(self, request):
        if not self.can_handle(request):
            if self._successor is not None:
                self._successor.handle_request(request)

    def can_handle(self, request):
        raise NotImplementedError('Must provide implementation in subclass!')


class HardwareSupportHandler(Handler):
    """Concrete handler: handles hardware support requests."""
    def can_handle(self, request):
        return request == "Hardware Support"


class SoftwareSupportHandler(Handler):
    """Concrete handler: handles software support requests."""
    def can_handle(self, request):
        return request == "Software Support"


class AccountSupportHandler(Handler):
    """Concrete handler: handles account support requests."""
    def can_handle(self, request):
        return request == "Account Support"


# Create handlers
hardware_handler = HardwareSupportHandler()
software_handler = SoftwareSupportHandler(hardware_handler)
account_handler = AccountSupportHandler(software_handler)

# Client code
def client_code(handler, request):
    print(f"Processing request for {request}")
    handler.handle_request(request)

# Test our chain
client_code(account_handler, "Hardware Support")
client_code(account_handler, "Software Support")
client_code(account_handler, "Account Support")

In this code, we have a base Handler class that defines the interface for handling requests. The HardwareSupportHandler, SoftwareSupportHandler, and AccountSupportHandler are concrete handlers that process specific types of requests. We link these handlers in a chain (account -> software -> hardware). When a request comes in, it starts at the beginning of the chain (account support) and moves down the chain until it finds a handler that can process it.

Observer Pattern

Purpose: To define a one-to-many dependency between objects, where a change in one object results in automatic notifications and updates to its dependents.

Example: A weather station broadcasting temperature updates to multiple display devices.

class Observer:
    def update(self, subject): pass

class Subject:
    def __init__(self):
        self._observers = []

    def attach(self, observer):
        self._observers.append(observer)

    def detach(self, observer):
        self._observers.remove(observer)

    def notify(self):
        for observer in self._observers:
            observer.update(self)

class WeatherStation(Subject):
    _temperature = None

    @property
    def temperature(self):
        return self._temperature

    @temperature.setter
    def temperature(self, temp):
        self._temperature = temp
        self.notify()

class DisplayDevice(Observer):
    def update(self, subject):
        print(f"Temperature Update: {subject.temperature}°C")

# Usage
weather_station = WeatherStation()
display = DisplayDevice()
weather_station.attach(display)

weather_station.temperature = 26  # Temperature Update: 26°C

Real-world use case

Scenario:
Imagine an Online Auction System where users can bid on various items. In this system, bidders need to be constantly updated about the current highest bid so they can decide whether to place a higher bid. Each item has multiple bidders watching it, and they all need to receive updates whenever the bid changes. Managing these updates efficiently is crucial to ensure a smooth and responsive auction experience.

Problem:
The challenge is in notifying all interested bidders of the current highest bid without requiring them to constantly check the item manually. Manually updating each bidder would be inefficient and impractical, especially as the number of bidders and items increases. This could lead to a poor user experience, as bidders might miss out on placing higher bids due to delayed updates.

Solution:
The Observer Pattern provides an elegant solution to this problem. It allows multiple objects (observers) to watch another object (subject) and be notified automatically whenever there is a change in the subject. In the context of our online auction system, each item can be a subject, and the bidders can be observers.

class AuctionItem:
    """Subject: Auction Item being bid on."""

    def __init__(self, name):
        self._name = name
        self._bidders = []
        self._highest_bid = 0

    def attach(self, bidder):
        self._bidders.append(bidder)

    def detach(self, bidder):
        self._bidders.remove(bidder)

    def notify(self):
        for bidder in self._bidders:
            bidder.update(self)

    def receive_bid(self, bid_amount):
        if bid_amount > self._highest_bid:
            self._highest_bid = bid_amount
            self.notify()

    def get_highest_bid(self):
        return self._highest_bid


class Bidder:
    """Observer: Bidders watching the auction item."""

    def __init__(self, name):
        self._name = name

    def update(self, auction_item):
        print(f"{self._name} has been notified. New highest bid: {auction_item.get_highest_bid()} on item {auction_item._name}")


# Client code
item = AuctionItem("Vintage Vase")

bidder1 = Bidder("Alice")
bidder2 = Bidder("Bob")
bidder3 = Bidder("Charlie")

item.attach(bidder1)
item.attach(bidder2)
item.attach(bidder3)

# Bids are received
item.receive_bid(100)  # Updates all bidders
item.receive_bid(150)  # Updates all bidders

In this implementation, AuctionItem is the subject, and Bidder is the observer. Each Bidder instance is attached to an AuctionItem. When a new bid is placed on the item (receive_bid method), the item updates its highest bid and notifies all attached bidders by calling their update method.

Strategy Pattern

Purpose: To define a family of algorithms, encapsulate each one, and make them interchangeable. The strategy pattern lets the algorithm vary independently from the clients that use it.

Example: Different sorting algorithms used in a context based on the size or complexity of the data set.

from typing import List

class SortingStrategy:
    def sort(self, dataset: List[int]) -> List[int]: pass

class QuickSort(SortingStrategy):
    def sort(self, dataset: List[int]) -> List[int]:
        print("Sorting using quick sort")
        return sorted(dataset)  # Simplification for demonstration

class MergeSort(SortingStrategy):
    def sort(self, dataset: List[int]) -> List[int]:
        print("Sorting using merge sort")
        return sorted(dataset)  # Simplification for demonstration

class Sorter:
    def __init__(self, strategy: SortingStrategy):
        self._strategy = strategy

    def sort(self, dataset: List[int]) -> List[int]:
        return self._strategy.sort(dataset)

# Usage
dataset = [1, 5, 3, 4, 2]

sorter = Sorter(QuickSort())
sorter.sort(dataset)  # Sorting using quick sort

sorter = Sorter(MergeSort())
sorter.sort(dataset)  # Sorting using merge sort

Real-world use case

Scenario:
Imagine an E-commerce platform where different products are shipped to various locations worldwide. Shipping costs vary based on several factors such as destination, weight, and shipping speed. The platform needs a flexible way to calculate shipping costs that can adapt to various shipping strategies, such as standard, expedited, and international shipping. Each strategy involves different cost calculations.

Problem:
The main challenge is implementing a shipping cost calculation system that is adaptable and maintainable. Hard-coding each shipping method's cost calculation into the main application can lead to a bloated codebase, making it difficult to add or modify shipping methods in the future. As the business grows and shipping requirements evolve, this inflexibility can become a significant hindrance.

Solution:
The Strategy Pattern offers a solution by defining a family of algorithms, encapsulating each one, and making them interchangeable. The strategy pattern lets the algorithm vary independently from clients that use it. In the context of our E-commerce platform, we can define different shipping strategies as separate algorithms and switch between them as needed.

from abc import ABC, abstractmethod


class ShippingStrategy(ABC):
    """Abstract base class for shipping strategies."""

    @abstractmethod
    def calculate(self, order):
        pass


class StandardShipping(ShippingStrategy):
    """Concrete strategy for standard shipping."""

    def calculate(self, order):
        return 5.00  # Flat rate


class ExpeditedShipping(ShippingStrategy):
    """Concrete strategy for expedited shipping."""

    def calculate(self, order):
        return 10.00  # Flat rate

class InternationalShipping(ShippingStrategy):
    """Concrete strategy for international shipping."""

    def calculate(self, order):
        return 20.00  # Flat rate


class Order:
    """Client class that uses a shipping strategy."""

    def __init__(self, strategy: ShippingStrategy):
        self.strategy = strategy

    def calculate_shipping_cost(self):
        return self.strategy.calculate(self)


# Usage
# Client code
standard_order = Order(StandardShipping())
print(f"Standard Shipping Cost: {standard_order.calculate_shipping_cost()}")

expedited_order = Order(ExpeditedShipping())
print(f"Expedited Shipping Cost: {expedited_order.calculate_shipping_cost()}")

international_order = Order(InternationalShipping())
print(f"International Shipping Cost: {international_order.calculate_shipping_cost()}")

In this implementation, ShippingStrategy is an abstract base class that defines a method calculate. Classes StandardShipping, ExpeditedShipping, and InternationalShipping implement this method to calculate shipping costs according to their respective strategies. The Order class, which represents a customer order, uses a ShippingStrategy to calculate its shipping cost.

Visitor Pattern

Purpose: To separate an algorithm from the object structure on which it operates. It allows adding new operations to existing object structures without modifying them.

Example: Performing different operations on a set of objects representing different elements of an HTML document.

class HtmlElement:
    def accept(self, visitor): pass


class HtmlParagraph(HtmlElement):
    def accept(self, visitor):
        visitor.visit_paragraph(self)


class HtmlAnchor(HtmlElement):
    def accept(self, visitor):
        visitor.visit_anchor(self)


class Visitor:
    def visit_paragraph(self, paragraph): pass
    def visit_anchor(self, anchor): pass


class RenderVisitor(Visitor):
    def visit_paragraph(self, paragraph):
        print("<p>Paragraph content</p>")

    def visit_anchor(self, anchor):
        print("<a href='url'>Anchor text</a>")

# Usage
# Client code
paragraph = HtmlParagraph()
anchor = HtmlAnchor()

render_visitor = RenderVisitor()

paragraph.accept(render_visitor)
anchor.accept(render_visitor)

In this implementation, the visit_paragraph method in RenderVisitor prints a simple HTML paragraph element, and visit_anchor prints an anchor (link) element. This is just a basic representation, and you can modify the content and attributes of the HTML elements as needed for your application.

The client code at the end creates instances of HtmlParagraph and HtmlAnchor, and then it uses the RenderVisitor to "visit" these elements, which results in printing their HTML representations.

Real-world use case

Scenario:
Consider a scenario in a Customer Support System where different types of customer queries, like Technical Support, Billing, and General Inquiries, are handled. The system needs to generate various reports based on these queries, such as performance analysis, query type breakdown, and customer feedback. Given the diverse nature of the data and the different types of reports required, the system needs a flexible way to handle these reporting tasks without altering the existing query classes whenever a new report is needed.

Problem:
The challenge is to create a reporting system that can process a variety of customer query types and generate different reports without constantly modifying the query classes. Adding reporting functionalities directly to the query classes would violate the Single Responsibility Principle and lead to a rigid design that's hard to maintain and update, especially when new types of reports are required.

Solution:
The Visitor Pattern provides an elegant solution to this problem. It allows adding new operations to existing object structures without modifying them. The pattern involves a visitor class that performs operations on elements of an object structure. This way, you can add new reporting capabilities by simply adding new visitor classes.

from abc import ABC, abstractmethod


# Element Interface
class CustomerQuery(ABC):
    @abstractmethod
    def accept(self, visitor):
        pass


# Concrete Elements
class TechnicalSupportQuery(CustomerQuery):
    def accept(self, visitor):
        visitor.visit_technical_support(self)


class BillingQuery(CustomerQuery):
    def accept(self, visitor):
        visitor.visit_billing(self)


class GeneralInquiry(CustomerQuery):
    def accept(self, visitor):
        visitor.visit_general_inquiry(self)


# Visitor Interface
class ReportVisitor(ABC):
    @abstractmethod
    def visit_technical_support(self, query):
        pass

    @abstractmethod
    def visit_billing(self, query):
        pass

    @abstractmethod
    def visit_general_inquiry(self, query):
        pass


# Concrete Visitors
class PerformanceReportVisitor(ReportVisitor):
    def visit_technical_support(self, query):
        # Perform operations specific to performance report for technical support
        pass

    def visit_billing(self, query):
        # Perform operations specific to performance report for billing
        pass

    def visit_general_inquiry(self, query):
        # Perform operations specific to performance report for general inquiries
        pass


class FeedbackReportVisitor(ReportVisitor):
    def visit_technical_support(self, query):
        # Perform operations specific to feedback report for technical support
        pass

    def visit_billing(self, query):
        # Perform operations specific to feedback report for billing
        pass

    def visit_general_inquiry(self, query):
        # Perform operations specific to feedback report for general inquiries
        pass


#Usage
# Client code
technical_query = TechnicalSupportQuery()
billing_query = BillingQuery()
general_query = GeneralInquiry()

performance_report_visitor = PerformanceReportVisitor()
feedback_report_visitor = FeedbackReportVisitor()

technical_query.accept(performance_report_visitor)
billing_query.accept(feedback_report_visitor)

In this implementation, CustomerQuery is an interface for different types of customer queries, and ReportVisitor is an interface for different types of report visitors. Concrete query classes like TechnicalSupportQuery, BillingQuery, and GeneralInquiry implement the CustomerQuery interface. Concrete visitor classes like PerformanceReportVisitor and FeedbackReportVisitor implement the ReportVisitor interface to handle specific reporting tasks.

Structural Patterns: Enhancing Code Flexibility and Functionality

Hernan Chilabert — Fri, 01 Dec 2023 00:25:22 +0000

[UPDATED 12/7/2023]
✨ GitHub repo with real-world use cases: https://github.com/herchila/design-patterns/tree/main/structural_patterns

Adapter Pattern

Purpose: To allow incompatible interfaces to work together. It involves creating a 'wrapper' with an interface expected by the client, around the actual object.

Example: An adapter that allows Python objects to interact with a system that expects JSON formatted data.

import json

class PythonObject:
    def __init__(self, data):
        self.data = data

class JsonAdapter:
    def __init__(self, python_object):
        self.python_object = python_object

    def to_json(self):
        return json.dumps(self.python_object.data)

# Usage
python_data = PythonObject({"key": "value"})
adapter = JsonAdapter(python_data)
print(adapter.to_json())  # {"key": "value"}

Real-world use case

Let's consider a real-world use case involving a legacy payment system and a new payment processing service.

Scenario:
You have a legacy payment system in your application that processes payments using an old interface LegacyPayment. Now, you want to integrate a new payment processing service, NewPaymentGateway, which has a different interface.

Problem:
The new payment service (NewPaymentGateway) has a different method signature for processing payments, and you can't change the existing legacy code.

Solution:
You can use the Adapter Pattern to create an adapter that translates the interface of NewPaymentGateway into the interface expected by the legacy code, without changing the existing legacy code.

Here's how you can implement it in Python:

class LegacyPayment:
    def process_payment(self, amount):
        print(f"Processing legacy payment of {amount}")


class NewPaymentGateway:
    def make_payment(self, amount):
        print(f"Making new payment of {amount}")


class PaymentAdapter:
    def __init__(self, new_payment_gateway):
        self.new_payment_gateway = new_payment_gateway

    def process_payment(self, amount):
        # Translate (adapt) the method call here
        self.new_payment_gateway.make_payment(amount)


# Existing system code
def process_payments(payment_processor, amount):
    payment_processor.process_payment(amount)

# Old payment system
legacy_payment = LegacyPayment()
process_payments(legacy_payment, 100)

# New payment system with adapter
new_payment_gateway = NewPaymentGateway()
adapted_payment = PaymentAdapter(new_payment_gateway)
process_payments(adapted_payment, 150)

In this example, PaymentAdapter adapts the interface of NewPaymentGateway to the expected interface of the legacy system (LegacyPayment). This way, the rest of your codebase can continue using the process_payment method without any changes, even when it's actually calling the new payment system.

Bridge Pattern

Purpose: To decouple an abstraction from its implementation so that the two can vary independently.

Example: A program to handle different message types (text, email) and different ways to send them (SMS, via App).

class MessageType:
    def send(self, message): pass

class TextMessage(MessageType):
    def send(self, message):
        print(f"Text: {message}")

class EmailMessage(MessageType):
    def send(self, message):
        print(f"Email: {message}")

class MessageSender:
    def __init__(self, message_type):
        self.message_type = message_type

    def send(self, message):
        self.message_type.send(message)


# Usage
text = TextMessage()
email = EmailMessage()

sender = MessageSender(text)
sender.send("Hello World")  # Text: Hello World

sender.message_type = email
sender.send("Hello World")  # Email: Hello World

Real-world use case

Scenario:
Consider an application that needs to support different types of remote controls (the "abstraction") for various devices like TVs, DVDs, or Streaming Devices (the "implementation"). Each device type has its own implementation for basic operations like turn_on and turn_off, but the way you use a remote control should be consistent, regardless of the device it's controlling.

Problem:
Without the Bridge Pattern, you might end up with separate remote control classes for each device type (e.g., TVRemote, DVDRemote, etc.), leading to code duplication and difficulty in maintenance if you add more functions to the remotes or add new device types.

Solution:
Use the Bridge Pattern to decouple the remote controls from the devices they control. You can then extend them independently.

Here's how you can implement it in Python:

class Device:
    def turn_on(self):
        raise NotImplementedError

    def turn_off(self):
        raise NotImplementedError


class TV(Device):
    def turn_on(self):
        print("Turning on the TV.")

    def turn_off(self):
        print("Turning off the TV.")

class DVD(Device):
    def turn_on(self):
        print("Turning on the DVD Player.")

    def turn_off(self):
        print("Turning off the DVD Player.")


class RemoteControl:
    def __init__(self, device):
        self.device = device

    def toggle_power(self):
        if self.is_power_on:
            self.device.turn_off()
            self.is_power_on = False
        else:
            self.device.turn_on()
            self.is_power_on = True


# Usage
tv = TV()
tv_remote = RemoteControl(tv)
tv_remote.toggle_power()  # Turns on the TV

dvd = DVD()
dvd_remote = RemoteControl(dvd)
dvd_remote.toggle_power()  # Turns on the DVD Player

In this example, RemoteControl acts as the bridge between the Device interface and its concrete implementations (TV, DVD). This allows you to add new types of devices or remote controls without affecting each other, adhering to the open-closed principle. For instance, if a new Streaming Device is introduced, you only need to create a new class implementing the Device interface without changing the RemoteControl abstraction.

Composite Pattern

Purpose: To treat individual objects and compositions of objects uniformly.

Example: A graphic design program where both individual shapes and groups of shapes should be treated the same way.

class Graphic:
    def render(self): pass

class Circle(Graphic):
    def render(self):
        print("Rendering Circle")

class CompositeGraphic(Graphic):
    def __init__(self):
        self.graphics = []

    def add(self, graphic):
        self.graphics.append(graphic)

    def render(self):
        for graphic in self.graphics:
            graphic.render()

# Usage
circle1 = Circle()
circle2 = Circle()

group = CompositeGraphic()
group.add(circle1)
group.add(circle2)
group.render()  # Rendering Circle\nRendering Circle

Real-world use case

This pattern lets clients treat individual objects and compositions of objects uniformly.

Scenario:
Imagine you're building a file system with directories and files. Each directory can contain files and other directories. Here, both files and directories should be treated uniformly, as they can be either an individual object or a part of a larger structure.

Problem:
Without the Composite Pattern, you would have to check the type of each item in the file system (whether it's a file or a directory) before performing operations, leading to complex and nested conditionals in your code.

Solution:
Use the Composite Pattern to treat both files and directories as 'FileSystemEntity' objects. Both 'File' and 'Directory' classes implement this common interface. This way, you can apply operations like display or add uniformly on files and directories.

Here's how you can implement it in Python:

class FileSystemEntity:
    def display(self):
        raise NotImplementedError


class File(FileSystemEntity):
    def __init__(self, name):
        self.name = name

    def display(self):
        print(f"File: {self.name}")


class Directory(FileSystemEntity):
    def __init__(self, name):
        self.name = name
        self.children = []

    def add(self, entity):
        self.children.append(entity)

    def display(self):
        print(f"Directory: {self.name}")
        for child in self.children:
            child.display()


# Usage
# Create files
file1 = File("File1.txt")
file2 = File("File2.doc")

# Create a directory and add files to it
directory = Directory("MyDirectory")
directory.add(file1)
directory.add(file2)

# Create a subdirectory and add it to the directory
subdirectory = Directory("MySubdirectory")
directory.add(subdirectory)

# Display structure
directory.display()

In this example, both File and Directory classes implement the FileSystemEntity interface. The Directory class can contain other directories or files, and when the display method is called on a directory, it recursively calls display on each of its children. This structure allows clients to treat individual files and compositions of files (directories) uniformly.

Decorator Pattern

Purpose: To add new functionalities to objects dynamically without altering their structure.

Example: Adding new features to a web application, like logging or authentication, without changing existing code.

class Component:
    def operation(self): pass

class ConcreteComponent(Component):
    def operation(self):
        print("Basic Operation")

class Decorator(Component):
    def __init__(self, component):
        self.component = component

    def operation(self):
        self.component.operation()

class AdditionalFeatureDecorator(Decorator):
    def operation(self):
        print("Additional Feature")
        super().operation()

# Usage
simple = ConcreteComponent()
decorated = AdditionalFeatureDecorator(simple)
decorated.operation()  # Additional Feature\nBasic Operation

Real-world use case

Scenario:
Imagine you are developing a coffee shop application where you can customize a basic coffee by adding various extras like milk, sugar, whipped cream, or chocolate. Each addition changes the cost and description of the coffee.

Problem:
Without the Decorator Pattern, you would need to create a separate class for each combination of coffee and extras. This approach quickly becomes unwieldy and difficult to maintain, especially as new extras are added.

Solution:
Use the Decorator Pattern to create a base Coffee class and then dynamically add extra features to objects of this class using decorators.

Here's how you can implement it in Python:

class Coffee:
    def get_cost(self):
        raise NotImplementedError

    def get_ingredients(self):
        raise NotImplementedError


class SimpleCoffee(Coffee):
    def get_cost(self):
        return 2

    def get_ingredients(self):
        return 'Coffee'


class CoffeeDecorator(Coffee):
    def __init__(self, coffee):
        self.decorated_coffee = coffee

    def get_cost(self):
        return self.decorated_coffee.get_cost()

    def get_ingredients(self):
        return self.decorated_coffee.get_ingredients()


class WithMilk(CoffeeDecorator):
    def __init__(self, coffee):
        super().__init__(coffee)

    def get_cost(self):
        return super().get_cost() + 0.5

    def get_ingredients(self):
        return super().get_ingredients() + ', Milk'


class WithSugar(CoffeeDecorator):
    def __init__(self, coffee):
        super().__init__(coffee)

    def get_cost(self):
        return super().get_cost() + 0.25

    def get_ingredients(self):
        return super().get_ingredients() + ', Sugar'


# Usage
my_coffee = SimpleCoffee()
print(f"Cost: {my_coffee.get_cost()}; Ingredients: {my_coffee.get_ingredients()}")

my_coffee = WithMilk(my_coffee)
print(f"Cost: {my_coffee.get_cost()}; Ingredients: {my_coffee.get_ingredients()}")

my_coffee = WithSugar(my_coffee)
print(f"Cost: {my_coffee.get_cost()}; Ingredients: {my_coffee.get_ingredients()}")

In this example, SimpleCoffee is a basic coffee without any extras. Decorators like WithMilk and WithSugar extend the functionality of SimpleCoffee by adding additional ingredients and costs. Each decorator class (WithMilk, WithSugar) conforms to the Coffee interface and wraps a Coffee object, adding its own behavior to the existing methods (get_cost, get_ingredients). This way, you can dynamically compose objects to represent various combinations of coffee and extras.

Proxy Pattern

Purpose: To provide a surrogate or placeholder for another object to control access to it, like lazy initialization, logging, or access control.

Example: A virtual proxy for a resource-intensive object, like a high-resolution image.

class Image:
    def display(self): pass

class HighResolutionImage(Image):
    def display(self):
        print("Displaying high-resolution image")

class ImageProxy(Image):
    def __init__(self):
        self.image = None

    def display(self):
        if self.image is None:
            self.image = HighResolutionImage()
        self.image.display()

# Usage
proxy_image = ImageProxy()
proxy_image.display()  # Displaying high-resolution image

Creational Patterns: Enhancing Your Coding Arsenal

Hernan Chilabert — Fri, 01 Dec 2023 00:22:48 +0000

[UPDATED 12/7/2023]
✨ GitHub repo with real-world use cases: https://github.com/herchila/design-patterns/tree/main/creational_patterns

Singleton

Purpose: A singleton ensures that a class has only one instance and provides a global point of access to it.

Example: In applications that require thread management, a Singleton can be used to manage and optimize the use of threads, ensuring that threads are reused and not excessively created and destroyed.

Basic sample

class Singleton:
    _instance = None

    @staticmethod
    def getInstance():
        if Singleton._instance == None:
            Singleton()
        return Singleton._instance

    def __init__(self):
        if Singleton._instance != None:
            raise Exception("This class is a singleton!")
        else:
            Singleton._instance = self

# Usage
s = Singleton.getInstance()
print(s)

s1 = Singleton.getInstance()
print(s1)  # Will print the same instance as s

Advance sample
The Singleton pattern can be effectively used in scenarios involving message producers in systems like Apache Kafka. Apache Kafka is a distributed streaming platform that allows for high-throughput, fault-tolerant handling of streaming data. In such a system, a Singleton can be used to manage a Kafka producer instance to ensure that only one instance is used to send messages to a Kafka topic, which can be crucial for optimizing resource usage and managing connections.

Here's an example of how you might implement a Kafka producer as a Singleton in Python:

from kafka import KafkaProducer
import json

class KafkaProducerSingleton:
    _instance = None

    def __new__(cls, *args, **kwargs):
        if not cls._instance:
            cls._instance = super(KafkaProducerSingleton, cls).__new__(cls, *args, **kwargs)
        return cls._instance

    def __init__(self, kafka_servers):
        # This will only be executed once
        self.producer = KafkaProducer(bootstrap_servers=kafka_servers,
                                      value_serializer=lambda v: json.dumps(v).encode('utf-8'))

    def send_message(self, topic, value):
        self.producer.send(topic, value)
        self.producer.flush()

# Usage example
kafka_servers = ['localhost:9092']  # Replace with your Kafka server addresses
producer1 = KafkaProducerSingleton(kafka_servers)
producer2 = KafkaProducerSingleton(kafka_servers)

print(producer1 == producer2)  # True

# Sending a message
producer1.send_message('my_topic', {'key': 'value'})

In this implementation:

The __new__ method ensures that only one instance of KafkaProducerSingleton is created. If an instance already exists, it returns that existing instance.
The __init__ method initializes the Kafka producer. This initialization only happens once since __new__ ensures only one instance is created.
The send_message method is used to send messages to a specified Kafka topic. It uses the producer to send the message and then flushes the producer to ensure the message is sent immediately.

Abstract Factory Pattern

Purpose: To provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Example: A UI library where we need to create UI elements that are consistent across different operating systems.

class Button:
    def paint(self): pass

class LinuxButton(Button):
    def paint(self):
        return "Render a button in a Linux style"

class WindowsButton(Button):
    def paint(self):
        return "Render a button in a Windows style"

class GUIFactory:
    def create_button(self): pass

class LinuxFactory(GUIFactory):
    def create_button(self):
        return LinuxButton()

class WindowsFactory(GUIFactory):
    def create_button(self):
        return WindowsButton()

# Usage
def client_code(factory: GUIFactory):
    button = factory.create_button()
    print(button.paint())

client_code(LinuxFactory())  # Output: Render a button in a Linux style
client_code(WindowsFactory())  # Output: Render a button in a Windows style

Builder Pattern

Purpose: To separate the construction of a complex object from its representation, allowing the same construction process to create different representations.

Example: Building different types of documents (Text, HTML, Markdown) with the same content.

class Document:
    def __init__(self):
        self.parts = []

    def add(self, part):
        self.parts.append(part)

    def __str__(self):
        return '\n'.join(self.parts)

class Builder:
    def build_title(self, title): pass
    def build_body(self, body): pass
    def get_result(self): pass

class TextBuilder(Builder):
    def __init__(self):
        self.document = Document()

    def build_title(self, title):
        self.document.add(f"Title: {title}")

    def build_body(self, body):
        self.document.add(body)

    def get_result(self):
        return self.document

# Usage
builder = TextBuilder()
builder.build_title("My Title")
builder.build_body("Hello, world!")
document = builder.get_result()
print(document)

Factory Pattern

Purpose: To create objects without specifying the exact class of object that will be created.

Example: Generating different types of charts based on user input.

class Chart:
    def draw(self): pass

class BarChart(Chart):
    def draw(self):
        return "Drawing a bar chart"

class PieChart(Chart):
    def draw(self):
        return "Drawing a pie chart"

def chart_factory(chart_type):
    charts = {
        "bar": BarChart,
        "pie": PieChart
    }
    return charts[chart_type]()

# Usage
chart = chart_factory("bar")
print(chart.draw())  # Output: Drawing a bar chart

Prototype Pattern

Purpose: To create new objects by copying existing objects, thus reducing the cost of creation.

Example: Duplicating graphic objects in a graphic editor.

import copy

class Prototype:
    def clone(self): pass

class ConcretePrototype(Prototype):
    def __init__(self, number):
        self.number = number

    def clone(self):
        return copy.deepcopy(self)

# Usage
prototype = ConcretePrototype(1)
cloned_prototype = prototype.clone()
print(cloned_prototype.number)  # Output: 1

Understanding Design Patterns in Software Engineering: A Python Perspective

Hernan Chilabert — Fri, 01 Dec 2023 00:06:34 +0000

[UPDATED 12/7/2023]
✨ GitHub repo with real-world use cases: https://github.com/herchila/design-patterns

Introduction

In the realm of software engineering, design patterns are fundamental, offering solutions to common problems encountered in software design. These patterns provide a template for how to solve a problem in a particular context, making software design more efficient and maintainable. This post delves into the world of design patterns through the lens of Python, a language known for its simplicity and readability.

What Are Design Patterns?

Design patterns are standardized solutions to common problems in software design. They represent best practices, evolved through the collective experience of skilled software developers. Design patterns offer several benefits:

Solve complex problems by breaking them down into smaller, more manageable parts.
Improve code readability and reusability, making it easier for other developers to understand and use your code.
Facilitate communication among developers, as they provide a common language to describe solutions.

Types of Design Patterns

Design patterns are generally divided into three categories:

Creational Patterns: These deal with object creation mechanisms, trying to create objects in a manner suitable to the situation.

Abstract Factory
Builder
Factory
Prototype
Singleton

Structural Patterns: These are concerned with object composition and typically deal with the relationship between entities.

Adapter
Bridge
Composite
Decorator
Proxy

Behavioral Patterns: These focus on communication between objects, how objects interact, and fulfill duties.

Chain of Responsibility
Observer
Strategy
Visitor

Design patterns are an invaluable tool in a software engineer's arsenal. They help create scalable, maintainable, and efficient code. Python, with its emphasis on readability and simplicity, provides an excellent environment for implementing these patterns. By familiarizing yourself with these patterns and their applications, you'll be well-equipped to tackle a wide range of software design challenges.

[UPDATED 12/7/2023]
✨ GitHub repo with real-world use cases: https://github.com/herchila/design-patterns