Forem

Stop Using ngrok for Webhook Testing (A Simpler Way)

Mahesh Srinivasan — Sun, 19 Apr 2026 09:19:48 +0000

Debugging webhooks has always been… annoying.

If you’ve worked with Stripe, GitHub, or any webhook-based system, you probably know this flow:

Start your local server
Run ngrok
Copy the public URL
Paste it into your provider
Restart ngrok → URL changes
Repeat everything again

It works… but it’s not smooth.

🚨 The Problem

Webhook testing shouldn’t feel like setup work.

But right now, it often involves:

Managing tunnels
Dealing with changing URLs
Debugging blindly when something fails

And when you're just trying to test a simple webhook, this overhead slows you down.

⚡ What I Wanted Instead

I wanted something simpler:

Run one command
Get a webhook URL instantly
Send requests
See everything in real-time
Forward directly to my local server

No setup. No accounts. No friction.

🔧 So I Built Anonymily

A lightweight tool to debug webhooks locally — without ngrok or complex setup.

🚀 How It Works

Start your local server (for example on port 3000), then run:

anonymily listen 3000

You’ll instantly get:

Forwarding to http://localhost:3000
Webhook URL: https://api.anonymily.com/h/abc123

Now just send your webhook to that URL.

⚡ What Happens Next

Requests hit the public endpoint
They are streamed in real-time
Automatically forwarded to your localhost
You see the response instantly

POST /webhook 200 OK (120ms)

No refreshing. No guessing.

🔌 Works With Anything

You can use it with:

Stripe webhooks
GitHub events
Shopify hooks
Any custom webhook system

If it sends HTTP requests, it works.

🔥 Why This Is Simpler

No tunnel setup
No config
No login required
Instant endpoints
Real-time inspection

Just run → test → debug.

🧪 Built for Fast Iteration

When you're developing locally, speed matters.

This tool is designed to:

Reduce setup time
Remove friction
Keep you in flow

So you can focus on debugging — not tooling.

🧹 Ephemeral by Default

All webhook data:

Stored in memory
Automatically deleted after 24 hours

No cleanup needed.

🎯 Try It Out

If you’re tired of setting up ngrok just to test webhooks, give this a try:

👉 https://anonymily.com

💬 Feedback Welcome

This is an early version, and I’d love to hear:

What works well
What’s confusing
What you wish it had

Drop your thoughts below 👇

Select Properties with Select-Object: Show Only What Matters

arnostorg — Sun, 19 Apr 2026 09:14:09 +0000

Select Properties with Select-Object: Show Only What Matters

Too much information clutters your screen. Select-Object shows only the columns you care about.

How It Works

Select-Object picks specific properties from results and hides the rest. Imagine a spreadsheet with 50 columns—Select-Object lets you show only the 3 columns you actually need.

This makes output cleaner and easier to read. It also helps you understand what data is available.

Code Examples

Show Specific Columns

# Show only Name and Size (hides other properties)
Get-ChildItem -File | Select-Object Name, Length

# Output:
# Name           Length
# ----           ------
# report.txt     4521
# document.xlsx  12048

Rename Columns While Showing

# Show Length as 'Size in bytes'
Get-ChildItem -File | Select-Object Name, @{Name="SizeInBytes";Expression={$_.Length}}

# Output shows 'SizeInBytes' instead of 'Length'
# Much clearer for other people reading your script!

Show First N Items

# Show only the first 5 files
Get-ChildItem | Select-Object -First 5

# Show the last 10
Get-ChildItem | Select-Object -Last 10

Combine with Sorting

# Show name and size, sorted by size (biggest first)
Get-ChildItem -File | Select-Object Name, Length | Sort-Object Length -Descending

# Result: Cleanest output showing biggest files first

Most Used Options

Name, Length - Show these specific properties
-First 5 - Show only first 5 items
-Last 10 - Show only last 10 items
@{Name='NewName';Expression={...}} - Rename a property while displaying

The Trick: Power Usage

Create readable process reports:

# Show process names and memory, sorted by memory usage
Get-Process | Select-Object Name, @{Name="MemoryMB";Expression={$_.Memory/1MB}} | Sort-Object MemoryMB -Descending

# Shows processes from most to least memory-hungry
# Much easier to read than raw data!

Pipeline cleanup pattern:

Get-ChildItem | Where-Object {$_.Length -gt 10MB} | Select-Object Name, Length | Sort-Object Length -Descending
# 1. Get all files
# 2. Filter to only big ones
# 3. Show only name and size
# 4. Sort by size

Learn It Through Practice

Stop reading and start practicing right now:

👉 Practice on your browser

The interactive environment lets you type these commands and see real results immediately.

Next in PowerShell for Beginners

This is part of the PowerShell for Beginners series:

Getting Started - Your first commands
Command Discovery - Find what exists
Getting Help - Understand commands
Working with Files - Copy, move, delete
Filtering Data - Where-Object and Select-Object
Pipelines - Chain commands together

Related Resources

Summary

You now understand:

How this command works
The most common ways to use it
One powerful trick to level up
Where to practice hands-on

Practice these examples until they feel natural. Then tackle the next command in the series.

Ready to practice? Head to the interactive environment and try these commands yourself. That's how it sticks!

What PowerShell commands confuse you? Drop it in the comments!

ChatGPT for Product Managers: Prompts That Sharpen Every Stage of the Product Cycle

Tosh — Sun, 19 Apr 2026 09:12:19 +0000

ChatGPT for Product Managers: Prompts That Sharpen Every Stage of the Product Cycle

I've been a product manager for seven years. I've survived brutal planning cycles, late-night stakeholder firefights, and sprint retros where nobody wanted to talk. What changed everything wasn't a new framework or a better roadmap tool — it was learning to use ChatGPT as a thinking partner at every stage of the product cycle.

Here's what that actually looks like in practice.

PRD Drafting in Half the Time

The blank PRD is one of the most demoralizing things in product. I used to spend two hours getting the structure right before I'd written a single meaningful sentence. Now I start with this:

Prompt: "You are a senior product manager. Draft a PRD outline for a [feature name] that solves [user problem] for [target user]. Include: problem statement, goals, non-goals, user stories, success metrics, and open questions. Be specific and opinionated."

The output isn't final — it's a scaffold. I spend 20 minutes editing instead of 2 hours starting from scratch.

User Story Generation That Actually Covers Edge Cases

The hardest part of user stories isn't the happy path. It's the edge cases your engineers will discover at 11pm before launch. This prompt surfaces them early:

Prompt: "Generate user stories for [feature] from the perspective of three different user types: a power user, a new user, and an edge-case user with accessibility needs. For each story, include the 'so that' rationale and one acceptance criterion."

I paste these directly into Jira with light editing. My engineers stopped asking "but what about when..." during sprint planning.

Competitive Analysis Without the Slide Deck Death March

I used to spend a full day building competitive matrices. Now I use ChatGPT to accelerate the research synthesis:

Prompt: "I'm building a feature comparison between [Product A], [Product B], and my product [Product C] across these dimensions: [list 4-5 dimensions]. Based on publicly known information, describe the strengths and weaknesses of each. Flag where you're uncertain."

Pair this with your own research and you have a first draft in 30 minutes.

Sprint Retro Summaries That People Actually Read

Most retro notes are a list of complaints nobody revisits. I now use ChatGPT to turn raw retro output into something actionable:

Prompt: "Here are the raw notes from our sprint retro: [paste notes]. Summarize into: 3 wins, 3 recurring friction points, and 2 concrete action items the team agreed on. Keep each point to one sentence."

I share this in Slack before the retro ends. Engagement tripled.

Stakeholder Update Emails That Get Read

The update email is a tax on PMs. Everyone wants them; nobody wants to write them. I now generate a first draft in 60 seconds:

Prompt: "Write a stakeholder update email for a product team. Context: [brief status]. Audience: [executive or cross-functional team]. Tone: direct and confident. Include: what shipped, what's next, and one risk to flag. Keep it under 150 words."

I edit for specifics, but the hard part — structure and tone — is handled.

Prompt Stack for the Full Cycle

Beyond the five prompts above, here are three more I reach for constantly:

Prompt: "I need to prioritize these 6 features using the RICE framework. Here's what I know about each: [paste feature list with rough data]. Help me estimate reach, impact, confidence, and effort for each, and flag your assumptions."

Prompt: "Write interview questions for a user research session about [topic]. Target user: [persona]. Goal: understand their current workflow and pain points. Avoid leading questions."

Prompt: "Review this product spec for logical gaps, missing edge cases, or unstated assumptions. [Paste spec]. Be direct about what's unclear."

Where This Saves Real Time

In a normal week, these prompts save me three to four hours. That's not theoretical — it's time I've reclaimed from low-value drafting and redirected into customer calls and engineering conversations. The prompts don't replace judgment. They eliminate the friction that delays it.

If you want a curated set of 50 prompts built specifically for product managers — covering roadmap communication, stakeholder management, discovery interviews, and more — I put them all in one place.

Get the ChatGPT Prompt Pack for Professionals — $27

It's the shortcut I wish I'd had in year one.

Handy Agent 2026 – From Chatbot to Autonomous AI Systems

ITPrep — Sun, 19 Apr 2026 09:08:53 +0000

"AI is no longer just responding to prompts.
It is executing workflows."

The last few years gave us powerful models like ChatGPT, Gemini, and Claude.

But let’s be real.

Most people are still stuck in this loop:

Prompt → Copy → Paste → Repeat

That is not automation.
That is manual work with extra steps.

⚡ The Paradigm Shift

Old World	New World
Chatbot	Handy Agent
Answering	Executing
Passive	Autonomous

We are moving from Conversational AI → Action-oriented AI

🧠 What is a Handy Agent?

A Handy Agent is an AI system that can:

Understand goals
Break tasks into steps
Use tools (APIs, apps)
Execute actions automatically

In one sentence:

It bridges the gap between intention and execution.

🔄 How Handy Agents Think (ReAct Loop)

At the core is a reasoning loop:

Thought → Action → Observation → Repeat

Example:

{
  "thought": "User wants to schedule meeting",
  "action": "check_calendar",
  "next_step": "find_available_slot"
}

This loop continues until the task is completed.

🧩 System Architecture

1. LLM (The Brain)

GPT / Claude / Gemini
Handles reasoning & planning

2. Tool Layer (Execution)

APIs (Google, Slack, CRM)
Executes real-world actions

3. Memory Layer

Short-term: task context
Long-term: vector DB (RAG)

[ User Goal ]
      ↓
[ LLM Reasoning ]
      ↓
[ Tool Execution ]
      ↓
[ Memory Update ]

⚔️ Chatbot vs Handy Agent (Real Scenario)

Chatbot

You:

"Schedule a meeting"

AI:

"3PM works well"

You still:

Open calendar
Create event
Send invites

Handy Agent

You:

"Schedule a meeting with marketing team"

Agent:

Checks availability
Picks optimal time
Creates event
Sends invites

Time: 10 minutes → 10 seconds

🔥 Real-World Use Cases

Administrative Automation

Meeting scheduling
Email handling
Calendar management

Data Pipeline

CRM → Data Cleaning → Analysis → PDF Report → Email

Fully automated.

Content Engine

Generate posts
Create images
Schedule publishing

🛠️ Build Your First Handy Agent (No Code)

Step 1: Define Scope

Start small:

"Auto extract invoice data from email"

Step 2: Choose Platform

Zapier
Make.com
Flowise
Dify

Step 3: Connect Tools

Gmail
Google Sheets

Step 4: Define Logic

IF email contains "invoice"
THEN extract data
AND save to sheet

🌍 The Future: Agent-to-Agent Economy

Soon, agents will interact with other agents.

Your Agent ↔ Vendor Agent ↔ Payment System

Decisions and transactions will happen automatically.

⚠️ Risks & Challenges

Hallucination → incorrect actions
Security → prompt injection risks
Cost → token usage can scale quickly

Solution: Human-in-the-loop control

📚 Deep Dive & Resources

If you want a full, in-depth breakdown of Handy Agents (architecture, real workflows, and business impact), check out the original article:

🔗 https://itprep.com.vn/gioi-thieu-ve-handy-agent-chuyen-sau-ve-ai-thuc-thi/

For more AI, backend, and developer-focused content, visit:

🏠 https://itprep.com.vn/

🧠 Final Thought

Using AI only for answers is like using a supercomputer as a search engine.

The real value comes from execution.

💬 What would your first Handy Agent automate?

The Modular Monolith 2026 Complete Guide — Spring Modulith, ArchUnit Fitness Functions, and Lessons from Shopify's 30TB/min Architecture

daniel jeong — Sun, 19 Apr 2026 09:05:42 +0000

The biggest architectural inflection point of 2026 is the "microservices regression" phenomenon. According to the CNCF Q1 2026 report, 42% of organizations that initially adopted microservices have consolidated some services into larger deployable units — and that consolidated form is the Modular Monolith. This architecture keeps the operational simplicity of a single deployable unit while explicitly enforcing domain boundaries, and it recently drew attention after Shopify processed a peak of 30TB/minute during Black Friday 2025 without incident. In Q1 2026, Spring Modulith 1.4 GA, ArchUnit 1.3, and jMolecules 2026.0 all landed, signaling the maturity of the Evolutionary Architecture toolchain. Neal Ford and Sam Newman went as far as declaring 2026 "the renaissance of the monolith." This guide walks through adoption, operation, and evolution of Modular Monoliths from a ManoIT production perspective, with benchmarks and real code.

1. Why Modular Monolith in 2026 — The Structural Causes of Microservices Fatigue

From the late 2010s into the early 2020s, the industry treated "microservices" as synonymous with "modern architecture." That consensus collapsed between 2024 and 2026. Amazon Prime Video rolled its video quality monitoring service from microservices back to a single monolith and reported a 90% cost reduction. Segment, InVision, and Istio announced similar regressions. In early 2026, a joint CNCF/SlashData survey found that "satisfaction with microservices architecture" had dropped 19pp compared to 2024.

Metric	2024	2026 Q1	Change
Orgs that consolidated after initial microservices adoption	23%	42%	+19pp
Agree: "Microservices are overkill for teams of 10 or fewer"	61%	84%	+23pp
Share of new 2026 projects adopting modular monolith	14%	37%	+23pp
Spring Modulith GitHub stars (1-year growth)	2.4k	9.1k	+278%
ArchUnit monthly downloads on Maven Central	3.2M	8.8M	+175%

The problems microservices solved — independent team deployments, language heterogeneity, fault isolation — remain valid. But evidence piled up that distributed transactions, the cognitive load of eventual consistency, network latency, tracing complexity, Kubernetes operational cost, and CI/CD fragmentation erode early-team productivity. Neal Ford summarized it in his 2026 QCon keynote: "Microservices are not a destination, they are a path — and most projects don't need more than half of it."

⚠️ Important: A modular monolith is not a retreat from microservices. It is an "evolutionary middle ground" that uses static analysis and runtime events to enforce domain boundaries, while making it cheap to extract a module into a microservice when actually needed. Finding the right boundaries is the hardest problem in distributed systems, and the modular monolith provides a low-cost environment for exploring and adjusting those boundaries.

2. Five Structural Principles of a Modular Monolith

Simon Brown coined the term in 2015 in "Monoliths vs Microservices is Missing the Point." Sam Newman's 2026 second edition of Monolith to Microservices re-anchored it for the modern era. The core idea is explicit, enforced module boundaries within a single deployable unit.

Principle	Description	Tooling
Explicit module boundaries	Packages/namespaces separate modules; each is treated as an independently deployable unit	Spring Modulith, Maven multi-module, Gradle subprojects
Unidirectional dependencies	No cyclic dependencies; modules interact only through published APIs (Ports)	ArchUnit, jMolecules, deptrac
Hidden internal state	Internal classes/tables/entities are off-limits to other modules; `internal` package convention	JPMS, Kotlin `internal`, TypeScript `package.json exports`
Event-first communication	Domain events over synchronous calls to keep coupling loose	Spring ApplicationEvents, MediatR, Transactional Outbox
Architecture fitness functions	CI automatically verifies boundary and dependency rules; builds fail on violations	ArchUnit, pytestarch, custom Checkstyle rules

The key idea here is architecture fitness functions, introduced by Neal Ford and Rebecca Parsons in Building Evolutionary Architectures. Fitness functions express architectural characteristics as executable tests. Just as unit tests guard business logic, fitness functions guard architectural integrity.

3. Spring Modulith 1.4 GA — The 2026 Reference Implementation

Spring Modulith 1.4 went GA on March 27, 2026. Built on Spring Boot 3.5 and Java 21, it adds @ApplicationModule, Event Externalization, a documentation generator, and observability integration.

// package-info.java — placed at the module root package
@org.springframework.modulith.ApplicationModule(
    displayName = "Order Management",
    allowedDependencies = {"common", "catalog::api"}  // only catalog's public API is reachable
)
package com.manoit.lms.order;

// OrderService.java — emit domain events for loose coupling
package com.manoit.lms.order;

import org.springframework.modulith.events.ApplicationModuleListener;
import org.springframework.context.ApplicationEventPublisher;

@Service
@RequiredArgsConstructor
public class OrderService {

    private final OrderRepository repository;
    private final ApplicationEventPublisher events;

    @Transactional
    public Order placeOrder(OrderCommand cmd) {
        var order = Order.create(cmd);
        repository.save(order);

        // Prefer events over direct calls — catalog/inventory modules react as subscribers
        events.publishEvent(new OrderPlacedEvent(order.getId(), cmd.items()));
        return order;
    }
}

// InventoryEventHandler.java — listener in a different module
package com.manoit.lms.inventory;

@Component
class InventoryEventHandler {
    @ApplicationModuleListener  // Splits the tx boundary, auto-handles retries and DLQ
    void on(OrderPlacedEvent event) {
        // Deduct inventory (async, independent transaction)
    }
}

@ApplicationModuleListener bundles @TransactionalEventListener(AFTER_COMMIT) + @Async + Transactional Outbox behind a single annotation. The decisive improvements in Spring Modulith 1.4 are:

Capability	1.3	1.4	Production impact
Event Externalization (Kafka/RabbitMQ/JMS)	Experimental	GA	Internal events auto-published to external brokers — an escape hatch to microservices
Observability (Micrometer/OpenTelemetry)	Manual	Auto-instrumented	Inter-module calls and events appear as spans
Auto-generated module docs (C4 model)	Text only	PlantUML + Structurizr	Architecture diagrams become a build artifact
Integration test helpers	Module-scoped	Scenario DSL	Test event chains with `Scenario.publish().andWaitFor()`
Named interfaces	Single `api` package	Multiple interfaces	`catalog::admin-api`, `catalog::public-api`, etc.

Event Externalization going GA is the strategic highlight. When a single module eventually must be extracted to a microservice, having events already flowing through an external broker drops the extraction cost by more than 70%. The evolutionary path is baked into the architecture itself.

4. Architecture Fitness Functions with ArchUnit 1.3

ArchUnit 1.3 (February 2026) has full JUnit 5, Kotlin, record-type, pattern-matching, and DSL support, and its new FreezingArchRule makes incremental adoption in legacy codebases feasible. The following is the ManoIT standard rule set.

// ArchitectureRulesTest.java — gate conditions on the CI pipeline
package com.manoit.lms.architecture;

import com.tngtech.archunit.junit.AnalyzeClasses;
import com.tngtech.archunit.junit.ArchTest;
import com.tngtech.archunit.lang.ArchRule;
import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.*;
import static com.tngtech.archunit.library.Architectures.*;
import static com.tngtech.archunit.library.modules.ModuleRuleDefinition.*;

@AnalyzeClasses(packages = "com.manoit.lms", importOptions = ImportOption.DoNotIncludeTests.class)
class ArchitectureRulesTest {

    // Rule 1: Respect hexagonal layering
    @ArchTest
    static final ArchRule hexagonal_layers = layeredArchitecture().consideringAllDependencies()
        .layer("Domain").definedBy("..domain..")
        .layer("Application").definedBy("..application..")
        .layer("Adapter").definedBy("..adapter..")
        .whereLayer("Adapter").mayNotBeAccessedByAnyLayer()
        .whereLayer("Application").mayOnlyBeAccessedByLayers("Adapter")
        .whereLayer("Domain").mayOnlyBeAccessedByLayers("Application");

    // Rule 2: Inter-module access only through api packages
    @ArchTest
    static final ArchRule module_boundary = modules()
        .definedByRootClasses()
        .should().respectTheirAllowedDependencies();

    // Rule 3: No direct references to Entities from outside the repository package
    @ArchTest
    static final ArchRule entity_encapsulation = noClasses()
        .that().resideOutsideOfPackages("..domain..", "..repository..")
        .should().dependOnClassesThat().areAnnotatedWith(Entity.class);

    // Rule 4: Controllers call services only, never repositories directly
    @ArchTest
    static final ArchRule controller_isolation = noClasses()
        .that().resideInAPackage("..adapter.web..")
        .should().dependOnClassesThat().resideInAPackage("..repository..");

    // Rule 5: Zero circular dependencies
    @ArchTest
    static final ArchRule no_cycles = slices().matching("com.manoit.lms.(*)..")
        .should().beFreeOfCycles();
}

These five rules run on every commit in the build pipeline. A violation blocks PR merges, which structurally prevents "architectural drift." This is the same strategy deployed by Google, Shopify, and Netflix.

5. Shopify — 30TB/min on Black Friday, 2M Classes in a Modular Monolith

Shopify runs the largest Ruby on Rails monolith in the world. Per their 2026 engineering blog, the monolith contains roughly 2M classes, more than 4,000 components, and hundreds of concurrent contributors, and it handled a peak of 30TB/minute during Black Friday Cyber Monday (BFCM) 2025.

Shopify platform metric	Value
Codebase size	~4M lines of Ruby + TypeScript
Components (modules)	4,000+
Daily production deploys	200+ per day
BFCM 2025 peak throughput	30TB/min, ~$4B in GMV
Architecture rule violation block rate in CI	100%

Shopify's secret is a proprietary static analysis tool called Packwerk. Packwerk enforces explicit boundaries in a Ruby codebase via package.yml, playing a role analogous to ArchUnit. The core design principles are:

Pack-level boundaries — each pack splits into a public/ API and private internals; outside packs can only import from public/.
Explicit dependency graph — allowed packs are listed in a dependencies YAML; CI fails on violations.
Domain events first — synchronous calls between packs are minimized, using Rails ActiveSupport::Notifications for async propagation.
Checkpoint-managed refactoring — violations are snapshotted into deprecated_references.yml and then whittled down.
Module ownership — CODEOWNERS plus pack metadata establishes team-level ownership — by domain, not file.

Shopify's conclusion is sharp: "We did not need to move to microservices. What we needed was order inside the monolith." Internal measurements published in April 2026 report that after adopting pack-based modularization, new-developer onboarding time fell by 55%, and cross-module regressions dropped by 68% year-over-year.

6. Decision Framework — When Modular Monolith, When Microservices

Based on Sam Newman's four-axis decision matrix in the 2026 second edition of Monolith to Microservices, here are the criteria ManoIT applies when starting a new project.

Axis	Favors Modular Monolith	Favors Microservices
Team size	1–20 people, single or a few teams	50+ across many autonomous teams
Domain-boundary certainty	Still being explored — refactoring cost must stay low	Boundaries are clear and stable; aligned with Conway's Law
Deployment frequency/independence	1–10 deploys/day, coordinated deploys acceptable	Dozens per hour, fully independent team deploys required
Scaling pattern	Horizontal replication suffices, load distributed evenly	Extreme per-module load variance, GPUs or special hardware
Data consistency	ACID / strong consistency needed, avoids distributed tx complexity	Eventual consistency acceptable, CDC/Saga available
Operational maturity	Kubernetes, service mesh, distributed tracing not yet mature	Platform team in place, SRE established, full observability stack

Notably, Martin Fowler's "MonolithFirst" principle is regaining traction in 2026. Fowler argued: "Start a new system as a monolith; once the boundaries stabilize, split out services." The 2026 reality is that most projects do not even need that split. More than 90% of enterprise projects are adequately served by a well-designed modular monolith.

7. Migration Path — The Reverse Strangler Fig Pattern

For teams already sprawled across many microservices, Newman proposes a Reverse Strangler pattern for re-consolidation.

# Step 1: Pick consolidation targets by measuring joint change frequency
# Analyze git history to find "services that change together"
$ git log --name-only --since="6 months ago" | \
    awk '/services\//' | \
    sort | uniq -c | sort -rn | head -20
# Result: order + payment + inventory change together in 72% of commits → consolidate

# Step 2: Centralize routing at the API gateway
routes:
  - path: /api/order/*
    service: monolith-v2  # new modular monolith
    fallback: legacy-order-service
  - path: /api/payment/*
    service: monolith-v2
    fallback: legacy-payment-service

# Step 3: Absorb into Spring Modulith modules
# order service code  → /modules/order/
# payment service code → /modules/payment/
# Database: per-service schema → single DB + schema-per-module

# Step 4: Verify consolidation with ArchUnit fitness functions
# Zero circular dependencies, zero module boundary violations

# Step 5: Gradually shift traffic away from legacy services (10% → 50% → 100%)
# Canary deploys + error-rate SLO monitoring

In one ManoIT customer engagement, 7 of 12 microservices were consolidated into a modular monolith, resulting in 58% infrastructure cost savings, 42% reduction in median response latency, and 73% fewer incident pages. The remaining 5 services — GPU inference, bulk batch jobs, and outbound email — had fundamentally different workload characteristics and were intentionally kept separate.

8. Modular Monoliths in Python/Django and Node.js

Modular monoliths are not JVM-only. Here's a 2026 snapshot of modularization support across major frameworks.

Language/Framework	Modularization tooling	Highlights
Java/Spring	Spring Modulith 1.4	`@ApplicationModule`, Event Externalization, ArchUnit integration
Kotlin	Arrow + ArchUnit	`internal` visibility, Gradle subprojects, sealed interfaces
Python	pytestarch 3.0, import-linter 2.0	Package dependency rules, FastAPI Router modularization
TypeScript/Node	Nx 20, turbo 2, dependency-cruiser 16	Monorepo workspaces, `exports`-field boundaries
Ruby on Rails	Packwerk 3, Engines	Pack-level boundaries, enforced `public/` API
C#/.NET	NetArchTest 2, MediatR 12	Assembly split, vertical slice architecture
Go	go-cleanarch, deptrac-go	Package dependency tests, interface boundaries

FastAPI-based ManoIT projects rely on import-linter to enforce module boundaries. Minimal configuration:

# setup.cfg — import-linter configuration
[importlinter]
root_package = app

[importlinter:contract:layered_architecture]
name = Layered Architecture
type = layers
layers =
    app.adapter
    app.application
    app.domain

[importlinter:contract:module_boundary]
name = Module Boundary — order cannot import payment.internal
type = forbidden
source_modules =
    app.modules.order
forbidden_modules =
    app.modules.payment.internal
    app.modules.inventory.internal

[importlinter:contract:no_cycles]
name = No Circular Dependencies
type = independence
modules =
    app.modules.order
    app.modules.payment
    app.modules.inventory
    app.modules.catalog

Running poetry run lint-imports in CI instantly catches boundary violations and integrates with any GitHub Actions or GitLab CI pipeline in under a minute.

9. Observability — Tracing Inter-Module Interactions

Observability for a modular monolith requires a different approach than microservices. The OpenTelemetry 2026 semantic conventions standardize module.name and module.interface attributes, and Spring Modulith 1.4 injects them automatically.

// application.yml — enable Spring Modulith observability
spring:
  modulith:
    events:
      externalization:
        enabled: true
        broker: kafka
    observability:
      enabled: true  # auto-instrument module boundaries
      tags:
        module.sla: critical

management:
  otlp:
    tracing:
      endpoint: http://otel-collector:4318/v1/traces
    metrics:
      export:
        enabled: true
  tracing:
    sampling:
      probability: 1.0  # 100% in dev, 0.1 in production

The result is that Grafana Tempo or Jaeger visualizes the flow "order module → payment module → inventory module" as a distributed trace. Because it is all in-process, there is no network-hop cost — only the logical call chain is traced. This is extremely useful for debugging and for defining SLOs.

10. ManoIT Production Checklist

Standard checklist for teams considering a modular monolith:

Model the domain first. Run Event Storming or Domain Storytelling workshops to identify bounded contexts. When boundaries are uncertain, start with coarser modules.
Stamp out a module skeleton. Each module uses a fixed api/, application/, domain/, adapter/ layout. Provide a template scaffold.
Add Spring Modulith 1.4 and ArchUnit 1.3 dependencies. Drop them into Maven/Gradle and commit your first fitness functions.
Wire into CI. Run architecture rules alongside unit tests via mvn test or gradle check.
Prefer event-first communication. If three or more synchronous inter-module calls chain together, redesign with events.
Set up a Transactional Outbox. Use Event Externalization GA to publish to Kafka/RabbitMQ.
Auto-generate C4 diagrams. Add Spring Modulith's Documenter to the build so PlantUML outputs ship with every build.
Instrument 100% of boundaries. OpenTelemetry + Micrometer spans on every module boundary, 0.1 sampling in production.
Pre-define scaling SLOs. Explicit, numeric rules for "we extract this module into a service when this metric crosses X."
Keep the evolution path open. Event-first communication drastically lowers the cost of extracting a module into a service later.

11. Conclusion — The Common Sense of Architecture Has Shifted in 2026

2026 is the year the "microservices = modern" equation broke for good. The modular monolith is not a retreat but an evolution. When combined with domain-driven design, architectural fitness functions, event-first communication, and observability, it delivers — for the majority of production systems — lower operational cost, higher development velocity, and equivalent scalability compared to microservices. Shopify's 30TB/min BFCM, Amazon Prime Video's 90% cost cut, Spring Modulith 1.4 going GA, and ArchUnit 1.3's maturity prove this is a structural shift, not a passing trend.

Starting in Q2 2026, ManoIT is moving all new enterprise engagements to a default architecture of modular monolith plus selective service extraction. The goal is to reduce operational burden today while keeping the door open for any module to evolve into an independent service as the business grows — an Evolvable Architecture. Complexity should be justified by necessity, not by tooling.

This article was produced through ManoIT's Claude Opus 4.6–powered automated blog pipeline, with facts cross-checked against Spring Modulith's official blog, Shopify Engineering, the CNCF × SlashData 2026 report, Sam Newman's second edition of *Monolith to Microservices, Neal Ford's QCon 2026 keynote, the ArchUnit documentation, The New Stack, InfoQ, and dev.to. Benchmarks (Shopify's 30TB/min, the 42% consolidation rate, etc.) reflect each source's published measurements. Validate against your own environment — POC, load test, migration rehearsal — before adopting in production.*

Originally published at ManoIT Tech Blog.

Offline Hash Cracking Tutorial: Crack the Hash Room Walkthrough | TryHackMe

Md. Ibrahim Reza Rabbi — Sun, 19 Apr 2026 09:04:19 +0000

Now, We will jump to the 2nd level of this ->

Question-1:

Hash: F09EDCB1FCEFC6DFB23DC3505A882655FF77375ED8AA2D1C13F640FCCC2D0C85

Now, lets crack this with SHA-256 mode 1400 by hashcat

Question-2:

Hash: 1DFECA0C002AE40B8619ECF94819CC1B

Now, this hash is tricky though it is showing MD5 or any version of MD but it is "NTLM". So, we should not blindly trust the top guess of this tools rather than sequentially test all the hash until we will get the hash cracked.

Question-3:

Hash: $6$aReallyHardSalt$6WKUTqzq.UQQmrm0p/T7MPpMbGNnzXPMAXi4bJMl9be.cfi3/qxIf.hsGpS41BqMhSrHVXgMpdjS6xeKZAs02.

Salt: aReallyHardSalt

Now, it is bit tricky. Go to hashcat_wiki and search the $6$ tag and understand which mode is this. ->

okay now lets crack we don't need to add the salt in the hash manually cause it is attached with that in the hash. But, most of we miss to add the (.) full stop at the end. This full stop is a part of this hash. And also it will take some time to crack ->

Question-4:

Hash: e5d8870e5bdd26602cab8dbe07a942c8669e56d6
Salt: tryhackme

now if we look at the hashcat_wiki the Sha-1 with salt is the mode 110 and also see the format sha1($pass.$salt) ->

But, unfortunately it didn't work :) then I sequentially search for other sha1 and salt type hash mode and I found this ->

And with that 160 mode we cracked the hash ->

┌──(kali㉿kali)-[~/password]
└─$ echo 'e5d8870e5bdd26602cab8dbe07a942c8669e56d6:tryhackme' > hash.txt

┌──(kali㉿kali)-[~/password]
└─$ hashcat -m 160 -a 0 hash.txt /usr/share/wordlists/rockyou.txt      
hashcat (v7.1.2) starting

OpenCL API (OpenCL 3.0 PoCL 6.0+debian  Linux, None+Asserts, RELOC, SPIR-V, LLVM 18.1.8, SLEEF, DISTRO, POCL_DEBUG) - Platform #1 [The pocl project]
====================================================================================================================================================
* Device #01: cpu-sandybridge-12th Gen Intel(R) Core(TM) i5-12450H, 1466/2933 MB (512 MB allocatable), 4MCU

Change tracking and soft delete: audit trails without the boilerplate

David Lastrucci — Sun, 19 Apr 2026 09:02:53 +0000

In most business applications, you need to answer questions like: Who created this record? When was it last modified? Can we undo this deletion?

Implementing this by hand means adding columns, writing triggers or hooks, and remembering to update them on every operation. Trysil does it with six attributes.

The change tracking attributes

Attribute	Set on	Required field type
`[TCreatedAt]`	Insert	`TTNullable<TDateTime>`
`[TCreatedBy]`	Insert	`String`
`[TUpdatedAt]`	Update	`TTNullable<TDateTime>`
`[TUpdatedBy]`	Update	`String`
`[TDeletedAt]`	Delete	`TTNullable<TDateTime>`
`[TDeletedBy]`	Delete	`String`

You add them to your entity fields, and Trysil fills them in automatically.

Adding an audit trail

unit Article.Model;

{$WARN UNKNOWN_CUSTOM_ATTRIBUTE ERROR}

interface

uses
  Trysil.Types,
  Trysil.Attributes,
  Trysil.Validation.Attributes;

type
  [TTable('Articles')]
  [TSequence('ArticlesID')]
  TTArticle = class
  strict private
    [TPrimaryKey]
    [TColumn('ID')]
    FID: TTPrimaryKey;

    [TRequired]
    [TMaxLength(200)]
    [TColumn('Title')]
    FTitle: String;

    [TColumn('Body')]
    FBody: String;

    [TCreatedAt]
    [TColumn('CreatedAt')]
    FCreatedAt: TTNullable<TDateTime>;

    [TCreatedBy]
    [TColumn('CreatedBy')]
    FCreatedBy: String;

    [TUpdatedAt]
    [TColumn('UpdatedAt')]
    FUpdatedAt: TTNullable<TDateTime>;

    [TUpdatedBy]
    [TColumn('UpdatedBy')]
    FUpdatedBy: String;

    [TColumn('VersionID')]
    [TVersionColumn]
    FVersionID: TTVersion;
  public
    property ID: TTPrimaryKey read FID;
    property Title: String read FTitle write FTitle;
    property Body: String read FBody write FBody;
    property CreatedAt: TTNullable<TDateTime> read FCreatedAt;
    property CreatedBy: String read FCreatedBy;
    property UpdatedAt: TTNullable<TDateTime> read FUpdatedAt;
    property UpdatedBy: String read FUpdatedBy;
  end;

Now when you insert or update:

var
  LArticle: TTArticle;
begin
  LArticle := LContext.CreateEntity<TTArticle>();
  LArticle.Title := 'Getting started with Trysil';
  LArticle.Body := 'In this article...';
  LContext.Insert<TTArticle>(LArticle);
  // CreatedAt is now set to the current timestamp
  // CreatedBy is set to the current user name
end;

LArticle.Title := 'Getting started with Trysil (updated)';
LContext.Update<TTArticle>(LArticle);
// UpdatedAt is now set to the current timestamp
// UpdatedBy is set to the current user name
// CreatedAt and CreatedBy remain unchanged

Providing the current user

The *By fields need to know who the current user is. You provide this via a callback on TTContext:

LContext.OnGetCurrentUser := function: String
begin
  result := 'david.lastrucci';
end;

In a real application, this might read from an authentication token, a session variable, or a thread-local user context. If you do not assign the callback, Trysil writes an empty string.

Soft delete

Traditional DELETE removes the row from the database. In many scenarios — audit compliance, undo functionality, data recovery — you want to keep the record but mark it as deleted.

Trysil supports this natively. Add [TDeletedAt] (and optionally [TDeletedBy]) to your entity:

  [TTable('Articles')]
  [TSequence('ArticlesID')]
  TTArticle = class
  strict private
    // ... other fields ...

    [TDeletedAt]
    [TColumn('DeletedAt')]
    FDeletedAt: TTNullable<TDateTime>;

    [TDeletedBy]
    [TColumn('DeletedBy')]
    FDeletedBy: String;

    [TColumn('VersionID')]
    [TVersionColumn]
    FVersionID: TTVersion;
  public
    // ... properties ...
    property DeletedAt: TTNullable<TDateTime> read FDeletedAt;
    property DeletedBy: String read FDeletedBy;
  end;

What changes

When an entity has a [TDeletedAt] field, calling Delete<T> no longer executes a SQL DELETE. Instead it executes:

UPDATE Articles
SET DeletedAt = :DeletedAt, DeletedBy = :DeletedBy, VersionID = VersionID + 1
WHERE ID = :ID AND VersionID = :VersionID

The record stays in the database, but it is marked as deleted.

Automatic exclusion

All SELECT queries on that entity automatically add DeletedAt IS NULL to the WHERE clause. Soft-deleted records are invisible by default — your application code does not need to change at all.

// This only returns non-deleted articles
LContext.SelectAll<TTArticle>(LArticles);

Including deleted records

Sometimes you need to see deleted records (admin panels, audit logs). Use the filter builder:

var
  LBuilder: TTFilterBuilder<TTArticle>;
  LFilter: TTFilter;
begin
  LBuilder := LContext.CreateFilterBuilder<TTArticle>();
  try
    LFilter := LBuilder
      .IncludeDeleted
      .OrderByDesc('DeletedAt')
      .Build;

    LContext.Select<TTArticle>(LAllArticles, LFilter);
  finally
    LBuilder.Free;
  end;
end;

Relation checks and soft delete

When you soft-delete a parent record, Trysil skips the child relation check. This makes sense: the record is not being physically removed, so foreign key integrity is preserved.

Putting it all together

Here is the SQL table that supports full change tracking with soft delete:

CREATE TABLE Articles (
  ID INTEGER PRIMARY KEY,
  Title TEXT NOT NULL,
  Body TEXT,
  CreatedAt TEXT,
  CreatedBy TEXT,
  UpdatedAt TEXT,
  UpdatedBy TEXT,
  DeletedAt TEXT,
  DeletedBy TEXT,
  VersionID INTEGER NOT NULL DEFAULT 1
);

And the complete entity lifecycle:

var
  LArticle: TTArticle;
begin
  // Create
  LArticle := LContext.CreateEntity<TTArticle>();
  LArticle.Title := 'My article';
  LArticle.Body := 'Content here';
  LContext.Insert<TTArticle>(LArticle);
  // CreatedAt = 2026-04-09 10:30:00, CreatedBy = 'david.lastrucci'

  // Update
  LArticle.Title := 'My article (revised)';
  LContext.Update<TTArticle>(LArticle);
  // UpdatedAt = 2026-04-09 11:15:00, UpdatedBy = 'david.lastrucci'

  // Soft delete
  LContext.Delete<TTArticle>(LArticle);
  // DeletedAt = 2026-04-09 14:00:00, DeletedBy = 'david.lastrucci'
  // Record is still in the database, but invisible to normal queries
end;

Series recap

Over these six articles we have covered the core of Trysil:

First contact — entity, connection, CRUD
Entity mapping — attributes, types, nullable fields, optimistic locking
Validation — declarative rules, custom validators, error handling
Filtering — fluent query builder, sorting, pagination
Relations — lazy loading, cascade delete, parent-child patterns
Change tracking — audit trails, soft delete, automatic exclusion

Trysil also includes a JSON serialization module, an HTTP/REST hosting module with attribute-based routing and JWT authentication, and a Unit of Work pattern via TTSession<T>. These are topics for future articles.

If you want to explore further, the GitHub repo contains full demo projects, a cookbook with 17 copy-paste recipes, and complete API documentation.

Trysil is open-source and available on GitHub. If this series helped you, consider giving the project a star — it helps other Delphi developers discover it!

Tu WebView no necesita un servidor HTTP. Necesita un Virtual Host.

Giovani Fouz — Sun, 19 Apr 2026 09:01:38 +0000

Cómo un patrón de los años 90 resolvió uno de los problemas más frustrantes del desarrollo móvil moderno

Hay una idea en ingeniería de software que reaparece una y otra vez, con décadas de distancia y en plataformas completamente distintas. Una idea tan elegante que la industria la redescubre cada cierto tiempo, la viste con nueva ropa, y la presenta como si fuera nueva.

Esta es la historia de esa idea. Y de cómo terminó viviendo dentro de una app Android.

El problema que nadie quiere admitir

Construir una app móvil con React, Vue o cualquier framework web moderno es tentador. Tienes un equipo que ya sabe web, una base de código compartida, y la promesa de "escribe una vez, corre en todas partes."

Hasta que llega el momento de cargar tu app en Android sin conexión a internet.

Android no tiene un servidor local. WebView no sabe hablar con tu carpeta assets/ como si fuera un dominio real. Y React Router — el corazón de la navegación en casi toda SPA moderna — necesita que las rutas como /dashboard o /perfil/123 devuelvan siempre el mismo index.html, sin importar qué tan profunda sea la URL.

Sin eso, tu app se rompe. El usuario navega, presiona atrás, recarga — y ve una pantalla en blanco o un error 404 que no debería existir.

La solución obvia sería levantar un servidor HTTP local. Pero eso consume batería, requiere permisos, complica el ciclo de vida de la app, y abre vectores de seguridad innecesarios. No es la respuesta correcta.

La respuesta correcta tiene 30 años de historia detrás.

1991: Cuando los servidores aprendieron a mentir (bien)

En los primeros días de la web, cada URL correspondía a un archivo físico en el disco del servidor. /pagina.html era literalmente un archivo llamado pagina.html. Simple, predecible, rígido.

El problema llegó cuando los sitios crecieron. Un servidor físico, múltiples dominios. ¿Cómo diferenciaba el servidor a cuál de ellos le hablaba el visitante?

La respuesta fue el Virtual Hosting: la capacidad de un solo servidor de hacerse pasar por muchos, respondiendo diferente según el dominio que el cliente pedía. Apache HTTP Server lo popularizó a mediados de los 90. Un servidor físico podía alojar empresa-a.com, empresa-b.com y empresa-c.com simultáneamente, cada uno con su propio espacio de archivos, sus propias reglas, su propia identidad.

Era, en esencia, enseñarle a un servidor a interceptar una petición y decidir: ¿quién eres tú y qué te mereces recibir?

Nginx lo refinó. Los CDNs lo escalaron a millones de dominios. Y el patrón quedó grabado en el ADN de la infraestructura web moderna.

2010: Las SPAs rompen todo (de nuevo)

Cuando llegaron las Single Page Applications, el Virtual Hosting tuvo que evolucionar.

Una SPA tiene una sola entrada: index.html. Todo lo demás — rutas, vistas, estados — es JavaScript puro que corre en el navegador. El servidor no sabe nada de /dashboard o /usuario/perfil. Cuando alguien recarga esa URL, el servidor busca un archivo llamado dashboard en el disco. No existe. 404.

La solución fue tan simple como poderosa: el fallback a index.html. Si el servidor no encuentra el archivo estático solicitado, en lugar de responder con un error, devuelve siempre index.html. React Router toma el control desde ahí y reconstruye la vista correcta.

En Nginx, son dos líneas:

try_files $uri $uri/ /index.html;

En ASP.NET Core, Microsoft lo formalizó como middleware oficial con MapFallbackToFile("index.html"). El patrón tenía nombre, documentación, y respaldo institucional.

Pero todo eso asume que tienes un servidor. ¿Qué pasa cuando no lo tienes?

2024: El mismo patrón, sin servidor

Android tiene un mecanismo poco conocido pero extraordinariamente poderoso: shouldInterceptRequest. Cada vez que el WebView está a punto de hacer una petición de red, se detiene y pregunta: ¿alguien quiere manejar esto antes que yo?

La mayoría de los desarrolladores lo ignora. Algunos lo usan para bloquear anuncios o inyectar headers. Pero hay una tercera posibilidad: usarlo para construir un servidor virtual completo que nunca hace una petición de red real.

Eso es exactamente lo que hace VirtualHostManager.

Cuando el WebView intenta cargar https://app.gfouz.com/assets/main.js, la clase intercepta esa petición antes de que salga al mundo. Busca el archivo en la carpeta assets/ del APK. Lo sirve directamente, con el MIME type correcto, con los headers de caché apropiados, sin tocar internet.

Y cuando el WebView pide https://app.gfouz.com/dashboard — una ruta de React Router que no existe como archivo — la clase reconoce que no tiene extensión, asume que es una ruta SPA, y devuelve index.html. React Router hace el resto.

El servidor está dentro de la app. El dominio es ficticio. Las peticiones nunca salen del dispositivo. Y React Router nunca se entera de la diferencia.

Por qué esto importa más de lo que parece

La mayoría de soluciones para este problema siguen uno de dos caminos: usar file:// (que rompe CORS y tiene restricciones de seguridad severas) o levantar un servidor HTTP local con librerías como NanoHTTPD (que consume recursos y complica el ciclo de vida de la app).

VirtualHostManager toma un tercer camino: habitar la infraestructura existente del WebView en lugar de luchar contra ella o rodearla.

El resultado es una clase que:

· No abre puertos de red.
· No requiere permisos adicionales.
· Cachea solo lo que vale cachear (index.html, que se pide en cada navegación).
· Transmite archivos grandes como streams, sin cargarlos completos en RAM.
· Valida rutas para prevenir path traversal attacks.
· Soporta 25 tipos de archivo con sus MIME types correctos.
· Funciona en Android 4.1 en adelante.

Y hace todo eso en menos de 200 líneas de Java.

El patrón que no envejece

Lo fascinante de esta historia no es la clase en sí. Es que el problema — ¿cómo sirvo contenido estático con inteligencia? — ha tenido exactamente la misma solución en cada era de la computación:

1995 → Apache Virtual Hosting
2005 → Nginx try_files
2016 → ASP.NET Core MapFallbackToFile
2024 → Android shouldInterceptRequest + SPA fallback

El contexto cambia. El hardware cambia. Los frameworks cambian. El patrón permanece.

Eso, en ingeniería de software, es la señal más confiable de que algo es fundamentalmente correcto.

VirtualHostManager es parte de FouzStack — una colección de soluciones de ingeniería para desarrollo móvil con tecnologías web.

gfouz (Giovani Fouz) · GitHub

Welcome, I'm excited to share my journey, skills, and projects with you. Dive in, explore my projects, and get to know the developer behind the screen. - gfouz

github.com

How to Containerize Your Python App and Deploy to VPS

Big Mazzy — Sun, 19 Apr 2026 09:00:13 +0000

Are you tired of the "it works on my machine" problem when deploying your Python applications? Containerization offers a solution by packaging your application and its dependencies into a portable unit. This article will guide you through containerizing your Python app using Docker and deploying it to a Virtual Private Server (VPS).

Why Containerize Your Python App?

Deploying applications can be a complex process. Different environments often have varying system libraries, Python versions, or installed packages, leading to unexpected errors. Containerization, using tools like Docker, solves this by bundling your application with everything it needs to run. This ensures consistency across development, testing, and production environments.

Think of a container like a self-contained apartment. It has its own plumbing, electricity, and furniture – everything needed for a resident to live comfortably, without interfering with other apartments or the building's main infrastructure. Similarly, a Docker container includes your application, its runtime, system tools, libraries, and settings, all isolated from the host system and other containers.

Understanding Docker

Docker is an open-source platform that automates the deployment, scaling, and management of applications using containers. It provides a standardized way to package applications, ensuring they run reliably across different computing environments.

What is a Docker Image?

A Docker image is a lightweight, standalone, executable package that includes everything needed to run a piece of software, including the code, runtime, system tools, system libraries, and settings. Images are immutable, meaning they cannot be changed after they are built.

What is a Docker Container?

A Docker container is a runnable instance of a Docker image. You can create, start, stop, and delete containers. A container is the actual running process.

Getting Started with Docker

Before you can containerize your Python app, you need to install Docker on your development machine. You can find installation instructions for various operating systems on the official Docker website.

Once Docker is installed, you can start building your container.

Creating a Dockerfile

A Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image. Docker reads this file and executes the commands sequentially to build the image.

Let's create a simple Flask application to demonstrate.

app.py:

from flask import Flask

app = Flask(__name__)

@app.route('/')
def hello_world():
    return 'Hello from my containerized Python app!'

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

This is a basic Flask web application that will serve a simple greeting. The host='0.0.0.0' is crucial for allowing the application to be accessible from outside the container.

Now, let's create our Dockerfile.

Dockerfile:

# Use an official Python runtime as a parent image
FROM python:3.9-slim

# Set the working directory in the container
WORKDIR /app

# Copy the current directory contents into the container at /app
COPY . /app

# Install any needed packages specified in requirements.txt
RUN pip install --no-cache-dir -r requirements.txt

# Make port 5000 available to the world outside this container
EXPOSE 5000

# Define environment variable
ENV NAME World

# Run app.py when the container launches
CMD ["python", "app.py"]

Let's break down this Dockerfile:

FROM python:3.9-slim: This specifies the base image. We're using a lightweight official Python 3.9 image. Using -slim variants often results in smaller image sizes.
WORKDIR /app: This sets the working directory inside the container. All subsequent commands will be executed from this directory.
COPY . /app: This copies the files from your local project directory (where the Dockerfile is located) into the /app directory inside the container.
RUN pip install --no-cache-dir -r requirements.txt: This command installs the Python dependencies. We assume you have a requirements.txt file. The --no-cache-dir flag helps reduce the image size by not storing the pip cache.
EXPOSE 5000: This informs Docker that the container will listen on port 5000 at runtime. It's documentation and doesn't actually publish the port.
ENV NAME World: This sets an environment variable named NAME with the value World. This is an example of how you can pass configuration into your container.
CMD ["python", "app.py"]: This specifies the command to run when the container starts. It executes our Flask application.

Creating `requirements.txt`

You'll need a requirements.txt file listing your Python dependencies. For our example, it would be:

requirements.txt:

Flask==2.0.1

Building the Docker Image

Navigate to your project directory in your terminal (the one containing app.py, Dockerfile, and requirements.txt). Then, build the Docker image using the following command:

docker build -t my-python-app .

docker build: This command initiates the image building process.
-t my-python-app: The -t flag tags the image with a name (my-python-app). You can choose any name.
.: This dot indicates that the Dockerfile is in the current directory.

This command will execute the steps in your Dockerfile, download the base image, copy your code, install dependencies, and create your custom image.

Running the Docker Container Locally

Before deploying, it's a good practice to test your container locally.

docker run -p 5000:5000 my-python-app

docker run: This command creates and starts a new container from an image.
-p 5000:5000: This maps port 5000 on your host machine to port 5000 inside the container. The format is host_port:container_port.
my-python-app: This is the name of the image you want to run.

Now, open your web browser and go to http://localhost:5000. You should see "Hello from my containerized Python app!".

Deploying to a VPS

To deploy your application to the internet, you'll need a Virtual Private Server (VPS). A VPS is a virtual machine sold as a service by an internet hosting service. It provides dedicated resources like CPU, RAM, and storage, giving you more control than shared hosting.

When choosing a VPS provider, consider factors like performance, pricing, and support. Providers like PowerVPS offer competitive pricing and robust infrastructure, making them a good option for hosting containerized applications. Another excellent choice is Immers Cloud, which provides flexible plans suitable for various deployment needs. For a comprehensive overview of server rental options, the Server Rental Guide is a valuable resource.

Setting Up Your VPS

Provision a VPS: Choose a Linux distribution (like Ubuntu or Debian) and provision your VPS.
Connect via SSH: Securely connect to your VPS using SSH.
Install Docker: Install Docker on your VPS. The installation process will vary slightly depending on your VPS's operating system. For Ubuntu, you can typically use:
```
sudo apt update
sudo apt install docker.io -y
sudo systemctl start docker
sudo systemctl enable docker
```
It's also a good idea to add your user to the docker group to run Docker commands without sudo:
```
sudo usermod -aG docker $USER
newgrp docker # Apply group changes to the current session
```

Transferring Your Application

You can transfer your application files and Dockerfile to the VPS using scp or by cloning your Git repository.

Using scp (example):

# On your local machine
scp -r /path/to/your/app/directory user@your_vps_ip:/home/user/app

Replace /path/to/your/app/directory with the actual path on your local machine, user with your VPS username, and your_vps_ip with your VPS's IP address.

Building the Image on the VPS

Once your files are on the VPS, navigate to your application directory and build the Docker image:

cd /home/user/app # Or wherever you copied your app
docker build -t my-python-app .

Running the Container on the VPS

Now, run your container on the VPS. You'll want to map a port on the VPS to your container's port. For public accessibility, you'll typically use port 80 (HTTP) or 443 (HTTPS).

docker run -d -p 80:5000 my-python-app

-d: This runs the container in detached mode, meaning it will run in the background.
-p 80:5000: This maps port 80 on your VPS to port 5000 inside the container.

Now, you should be able to access your application by navigating to your VPS's IP address in a web browser.

Considerations for Production

While the above steps get your application running, production deployments often require more robust solutions.

Port Mapping and Firewalls

Ensure your VPS's firewall is configured to allow traffic on the port you're exposing (e.g., port 80). If you're using a cloud provider's firewall, you'll need to open the relevant ports there as well.

Reverse Proxy (Nginx/Apache)

For production, it's common to use a reverse proxy like Nginx. A reverse proxy sits in front of your application container, handles incoming requests, and forwards them to your application. This offers benefits like SSL termination, load balancing, and caching.

You would typically run Nginx in its own Docker container and configure it to proxy requests to your Python application container.

Persistent Storage

If your application needs to store data (e.g., user uploads, database files), you'll need to use Docker volumes or bind mounts to persist data outside the container's lifecycle. Otherwise, any data stored inside the container will be lost when the container is removed.

Container Orchestration

For more complex deployments with multiple containers, microservices, or the need for automatic scaling and self-healing, consider container orchestration platforms like Docker Swarm or Kubernetes. These tools manage the deployment, scaling, and networking of containerized applications.

Conclusion

Containerizing your Python applications with Docker and deploying them to a VPS provides a consistent, reliable, and scalable way to run your code. By following these steps, you can move beyond the "it works on my machine" dilemma and gain better control over your application's deployment environment. Remember to prioritize security and consider advanced deployment strategies for production-ready applications.

Idempotency in CQRS and Event Sourcing — Part 2: commands, projections and outbox

Odilon HUGONNOT — Sun, 19 Apr 2026 09:00:02 +0000

In HTTP, idempotency is straightforward: store the key, return the cache. In a CQRS/Event Sourcing system, it's more subtle. The command may be idempotent, but what about the event it generates? The projection consuming it? Idempotency must cross the entire stack.

If you haven't read part 1, it covers the basics and the HTTP implementation in Go — with a complete PostgreSQL store that replaces Redis. Here we go one level deeper: command store, optimistic locking, idempotent projections, outbox pattern. These are the patterns found in financial systems, e-commerce platforms, anywhere a processing duplicate costs money or trust. Everything runs on PostgreSQL — no Redis, no external broker for idempotency.

The problem specific to Event Sourcing

In Event Sourcing, the application state is the event stream. An account balance is not a column in the database — it's the sum of AccountCredited and AccountDebited events since opening. If the same event is recorded twice, the reconstructed state is wrong. And often irreparable without manual intervention.

Concrete scenario on a payment system:

The command DebitAccount(amount=100, idempotencyKey=abc123) arrives
The event AccountDebited(amount=100) is recorded, balance goes from 200 to 100
Network drops. Client retries. The same command arrives a second time
Without protection: a second AccountDebited(amount=100) is recorded, balance drops to 0
The user has been charged twice for a single purchase

In a classic relational database, you could fix this with an UPDATE. In Event Sourcing, you never modify the past — you can only append a corrective event, which complicates audit and support. Better to prevent the duplicate from getting in at all.

Command idempotency with the idempotency key

The principle is the same as in HTTP: associate each command with a unique key provided by the client, and check before processing whether that key has already been seen. The difference is that you store the result in a dedicated command store, and the save must be atomic with the events.

CREATE TABLE processed_commands (
    idempotency_key UUID PRIMARY KEY,
    aggregate_id    UUID NOT NULL,
    command_type    VARCHAR(100) NOT NULL,
    result_event_id UUID,
    processed_at    TIMESTAMPTZ DEFAULT NOW()
);

The handler follows a three-step schema:

func (h *PaymentHandler) Handle(ctx context.Context, cmd DébiterCompte) error {
    // 1. Check if already processed
    existing, err := h.commandStore.Get(ctx, cmd.IdempotencyKey)
    if err == nil {
        // Already processed — return silent success
        _ = existing
        return nil
    }
    if !errors.Is(err, ErrNotFound) {
        return fmt.Errorf("checking idempotency: %w", err)
    }

    // 2. Process the command
    events, err := h.aggregate.Handle(ctx, cmd)
    if err != nil {
        return err
    }

    // 3. Save events + mark command as processed — ATOMICALLY
    return h.store.SaveEventsAndMarkCommand(ctx, events, cmd.IdempotencyKey)
}

The atomicity of step 3 is non-negotiable. If you save the events in one transaction and mark the command in a second separate transaction, a crash between the two gives you: events in the database, command not marked. On the next retry, the handler doesn't see the key, processes again, records a duplicate event. Both operations must live in the same PostgreSQL transaction.

Optimistic locking — detecting concurrent conflicts

The idempotency key protects against duplicates of the same command. It doesn't protect against two different commands modifying the same aggregate at the same time. That's the role of optimistic locking.

Each aggregate has a version number. When a client reads the state of an aggregate, it receives its current version. When it sends a command, it includes that version. If in the meantime someone else has written to the same aggregate, the versions no longer match and the command is rejected — it's up to the client to re-read the state and decide whether its command still holds.

CREATE TABLE account_events (
    id             UUID PRIMARY KEY,
    aggregate_id   UUID NOT NULL,
    version        INT NOT NULL,
    event_type     VARCHAR(100) NOT NULL,
    payload        JSONB NOT NULL,
    created_at     TIMESTAMPTZ DEFAULT NOW(),
    UNIQUE(aggregate_id, version) -- key constraint
);

The UNIQUE(aggregate_id, version) constraint does all the work. If two concurrent commands try to write version 5 of the same aggregate, PostgreSQL lets one through and rejects the other with a uniqueness violation.

type DébiterCompte struct {
    AggregateID     uuid.UUID
    ExpectedVersion int // version the client read
    Montant         float64
    IdempotencyKey  uuid.UUID
}

func (s *EventStore) AppendEvents(
    ctx context.Context,
    aggregateID uuid.UUID,
    expectedVersion int,
    events []Event,
) error {
    for i, event := range events {
        _, err := s.db.ExecContext(ctx,
            `INSERT INTO account_events (id, aggregate_id, version, event_type, payload)
             VALUES ($1, $2, $3, $4, $5)`,
            event.ID,
            aggregateID,
            expectedVersion+i+1,
            event.Type,
            event.Payload,
        )
        if isUniqueViolation(err) {
            return ErrVersionConflict // caller can retry with the new version
        }
        if err != nil {
            return fmt.Errorf("appending event: %w", err)
        }
    }
    return nil
}

By returning ErrVersionConflict, we leave the decision to retry or surface the error to the user to the caller. In a financial system, you often surface an explicit error ("your operation was cancelled because the account was modified in the meantime") rather than retrying silently.

Idempotent projections

Projections consume the event stream to build denormalized views — the current balance of an account, the order list for a customer, etc. With Kafka or any at-least-once system, the same event can arrive multiple times. The projection must produce the same result whether it sees it once or ten times.

Approach 1: tracking position in the stream

Each projection remembers the ID of the last event it processed. Events older than or equal to the checkpoint are ignored.

CREATE TABLE projection_checkpoints (
    projection_name VARCHAR(100) PRIMARY KEY,
    last_event_id   UUID NOT NULL,
    updated_at      TIMESTAMPTZ DEFAULT NOW()
);

This approach works well when events are ordered and IDs can be compared (UUIDs v7 or sequences). It assumes the event store guarantees a stable order, which is generally true per aggregate but may be less so across different aggregates.

Approach 2: idempotent upsert

Rather than filtering duplicates upstream, write in a way that rewriting the same data is harmless. PostgreSQL's INSERT ON CONFLICT DO UPDATE instruction is built for this:

INSERT INTO account_balances (account_id, balance, last_event_id)
VALUES ($1, $2, $3)
ON CONFLICT (account_id) DO UPDATE
    SET balance       = EXCLUDED.balance,
        last_event_id = EXCLUDED.last_event_id
WHERE account_balances.last_event_id < EXCLUDED.last_event_id;
-- The WHERE clause prevents overwriting a more recent state with an older event

The WHERE clause matters. Without it, if an old event arrives after a recent event (which can happen with multiple Kafka partitions), you overwrite a correct state with a stale one. With it, you only update if the incoming event is newer than what you already have.

In practice, both approaches are complementary: the checkpoint avoids replaying thousands of events unnecessarily, and the idempotent upsert acts as a safety net for duplicates that slip through anyway.

The Outbox pattern — publishing events without data loss

Suppose your system saves events in PostgreSQL and publishes them to Kafka for other services. If the process crashes after the PostgreSQL commit but before publishing to Kafka, the event is lost from the perspective of consumers. If you reverse the order, you might publish an event that the transaction will then rollback. It's impossible to do an atomic commit across two independent systems without a distributed coordinator.

The Outbox pattern sidesteps the problem without two-phase commit:

In the same PostgreSQL transaction: save the event and write it to an outbox table
A dedicated worker reads outbox and publishes to Kafka
Once successfully published, mark the row as sent

CREATE TABLE outbox (
    id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    event_type   VARCHAR(100) NOT NULL,
    payload      JSONB NOT NULL,
    published    BOOLEAN DEFAULT FALSE,
    created_at   TIMESTAMPTZ DEFAULT NOW(),
    published_at TIMESTAMPTZ
);

func (s *Store) SaveEventAndOutbox(ctx context.Context, tx *sqlx.Tx, event Event) error {
    // 1. Save the event in the event store
    if err := s.saveEvent(ctx, tx, event); err != nil {
        return err
    }
    // 2. Write to the outbox — same transaction, same commit or same rollback
    _, err := tx.ExecContext(ctx,
        `INSERT INTO outbox (event_type, payload) VALUES ($1, $2)`,
        event.Type,
        event.Payload,
    )
    return err
}

// Separate worker — runs in the background
func (w *OutboxWorker) Run(ctx context.Context) {
    ticker := time.NewTicker(100 * time.Millisecond)
    defer ticker.Stop()
    for {
        select {
        case <-ticker.C:
            if err := w.publishPending(ctx); err != nil {
                slog.Error("outbox publish failed", "error", err)
            }
        case <-ctx.Done():
            return
        }
    }
}

func (w *OutboxWorker) publishPending(ctx context.Context) error {
    rows, err := w.db.QueryContext(ctx,
        `SELECT id, event_type, payload FROM outbox
         WHERE published = FALSE
         ORDER BY created_at
         LIMIT 100`,
    )
    if err != nil {
        return fmt.Errorf("querying outbox: %w", err)
    }
    defer rows.Close()

    for rows.Next() {
        var id uuid.UUID
        var eventType string
        var payload []byte
        if err := rows.Scan(&id, &eventType, &payload); err != nil {
            return fmt.Errorf("scanning outbox row: %w", err)
        }
        if err := w.kafka.Publish(ctx, eventType, payload); err != nil {
            return fmt.Errorf("publishing event %s: %w", id, err)
        }
        _, err = w.db.ExecContext(ctx,
            `UPDATE outbox SET published = TRUE, published_at = NOW() WHERE id = $1`,
            id,
        )
        if err != nil {
            return fmt.Errorf("marking event published %s: %w", id, err)
        }
    }
    return rows.Err()
}

The worker may publish the same event twice if it crashes after the Kafka publish but before the UPDATE outbox. That's at-least-once delivery, not exactly-once. Kafka consumers must therefore be idempotent — which the upsert approach described in the previous section guarantees.

For high-volume systems, polling every 100ms can be replaced by PostgreSQL LISTEN/NOTIFY to trigger the worker immediately after each outbox insertion, without waiting for the next tick.

Summary — what protects what

Problem

Solution

Command received twice (client retry)

Idempotency key in processed_commands

Two concurrent commands on the same aggregate

Optimistic locking (UNIQUE constraint on version)

Event published twice by the broker

Idempotent projection (checkpoint or upsert)

Crash between save and publish

Outbox pattern (atomicity via transaction)

Each layer protects against a different type of duplicate. The idempotency key doesn't replace optimistic locking, and the outbox doesn't make the projection idempotent — these are orthogonal guarantees that each cover a distinct failure point.

Conclusion

Idempotency in CQRS/Event Sourcing is not a detail you add after the fact — it's what separates a system that works in a demo from one that holds up in production. Retries happen. Processes crash. Kafka re-delivers messages. That's not paranoia, it's the normal behavior of any distributed system under load.

The good news: these four patterns are well-known, well-supported by PostgreSQL, and assemble cleanly in Go. Once in place, they work silently — and that's exactly what you expect from them. The "duplicate payment" ticket that never comes in, that's the real success.

📄 Associated CLAUDE.md

View • Download • Catalogue

Built tasuki — an AI CLI Orchestrator that Seamlessly Hands Off Between Tools

kohei — Sun, 19 Apr 2026 08:49:32 +0000

I built and open-sourced tasuki, an AI CLI orchestrator that automatically rotates between Claude Code / Codex CLI / GitHub Copilot CLI based on priority.

Repository: https://github.com/0xkohe/tasuki

Motivation

I’m the kind of person who prefers subscribing to multiple AI tools at $20–$30 each rather than committing to a single $100–$200 plan. I want to explore different tools and continuously feel the differences between models.

However, doing this means hitting usage limits fairly quickly, which interrupts workflow and requires manual switching — something I found annoying.

Each AI has its strengths — Codex for review, Claude for conversation, etc. But unless you’re extremely opinionated, there’s value in constantly rotating through tools and experiencing their evolution. If you stick to one, you may miss when another becomes better at something.

The switching decision itself is trivial labor — so I wanted to automate it.
That’s why I built tasuki.

Instead of treating rate limits as a constraint, I treat them as an opportunity to move to another model.

Intended Workflow

Prioritize Claude Code and Codex CLI (5-hour windows)
Since their reset cycles are short, it’s more cost-efficient to exhaust them first.
Once both 5-hour windows are exhausted, switch to GitHub Copilot CLI
Copilot operates on a monthly quota, so it works well as a “bridge.”
When Claude / Codex reset, switch back automatically
Monthly quota should be preserved as much as possible.

What It Does

Native UI stays intact
Each CLI runs inside a wrapped PTY, preserving the original interactive experience.
Automatic switching based on usage
Adapters monitor CLI output streams and trigger a handoff when a threshold (default: 95%) is reached.
Context-aware handoff
Progress is written to .tasuki/handoff.md and injected into the next provider.

Try It in 5 Minutes

Install

go install github.com/0xkohe/tasuki/cmd/tasuki@latest

First Run

cd path/to/your/project
tasuki

Closing

Use everything. Keep exploring.
tasuki reduces the friction of doing that.

GitHub: https://github.com/0xkohe/tasuki
Issues: https://github.com/0xkohe/tasuki/issues

OpenClaw is old? Run Hermes Agent in VS Code through ACP (Agent Client Protocol) now!

Jun Han — Sun, 19 Apr 2026 08:49:21 +0000

In recent weeks, the Hermes Agent becomes much populor in Agent world.

Several users asked me about whether my VS Code ACP Client extension could support Hermes Agent?

So in this weekend, I have added support for Hermes Agent!

Please note that, before you could run Hermes Agent in VS Code, install Hermes Agent via the Hermes Quickstart (Linux/macOS/WSL2 only — Windows requires WSL2). Make sure hermes is on your PATH and launch VS Code from the same shell/venv. Configure credentials with hermes model.

If you are a Windows user, you need to connect to the Hermes Agent in WSL through the WSL VS Code extension:

Actually, I've quietly developed three different ACP Clients that can suit different user groups!

If you're a VS Code user, try the ACP Client extension:

https://github.com/formulahendry/vscode-acp

If you want a lightweight ACP Desktop interface on Windows/macOS/Linux, check out the cross-platform ACP UI:

https://github.com/formulahendry/acp-ui

If you want to connect to an Agent from your phone via WeChat (iOS or Android), go for WeChat ACP:

https://github.com/formulahendry/wechat-acp

There’s something for everyone!

Connect to any Agent, anytime, anywhere — effortlessly.