DEV Community: Vanni Daghini

Declarative and observable monitor management with Python

Vanni Daghini — Fri, 06 Feb 2026 07:24:38 +0000

tool-clean: a declarative and observable approach to monitor management

When dealing with system configuration, I tend to prefer explicit control over automation.

This is especially true in IT environments, where:

predictability matters more than convenience
implicit behavior becomes technical debt
“magic” often hides responsibility rather than reducing it

With that mindset, I built tool-clean.

What tool-clean is (and is not)

tool-clean is a CLI tool written in Python for observable and declarative monitor management.

It allows you to:

observe connected monitors
identify them in a stable way
assign human-readable labels
declare usage profiles
associate profiles to monitors
persist everything locally
audit all mutating actions

What it does not do:

it does not apply system configurations
it does not change brightness or resolution
it does not interact with drivers or OS APIs
it does not make autonomous decisions

This is intentional.

The design philosophy

tool-clean is built around a few non-negotiable principles:

Human control is explicit
Observation is separate from intention
Declaration is separate from execution
Nothing happens implicitly
Everything relevant is audit-visible

In practice, this means the tool never “reacts” to state.

It only records and exposes it.

Why not automate?

Automation is powerful, but it comes with costs:

hidden assumptions
unclear responsibility
difficult audits
fragile edge cases

In many IT contexts, the real need is not automation, but clarity.

tool-clean is meant to be a foundation:

something an IT operator can reason about
something you can inspect and revoke
something that does not surprise you six months later

How it works (conceptually)

The system observes the real state (connected monitors)
The user declares a profile (an intention, not an action)
The user associates that profile to a monitor
The state is persisted and audited
Any real application happens outside the tool

The tool remains read-only with respect to the operating system.

Technical overview

Python 3.10+
CLI-first (not a library)
Local-only execution
SQLite for persistence
Append-only audit log (INFO / WARN / SECURITY)
No network dependencies
No background services

The project uses a clean src/ layout and a strict separation between:

CLI parsing
domain commands
observed state
persistence

Current scope: Base v2

The current public release is Base v2.

It is intentionally limited:

no centralized management
no federation
no policy enforcement
no automatic configuration application

Those ideas may belong to future versions, but not to the base.

Base v2 is meant to be:

stable
inspectable
defensible

Repository

The project is open source (MIT licensed):

https://github.com/Vanni7544/tool-clean

The repository includes:

full documentation
a canonical source snapshot
clear contribution guidelines
a defined security policy

Closing thoughts

tool-clean is not meant to be flashy.

It is meant to be:

boring in the right way
predictable
explicit
safe to reason about

If you’re interested in tools that favor clarity over automation,

this project might resonate with you.

Technical feedback is welcome.

# The `Person` class is lying to you (and that’s okay)

Vanni Daghini — Mon, 19 Jan 2026 15:25:52 +0000

When you start learning Object-Oriented Programming, sooner or later it happens.

Someone says:

“Let’s make a simple example.”
And the example is almost always the same:

class Person {
    public string $name;
    public int $age;

    public function think() {}
    public function decide() {}
}

The legendary Person class.

It looks harmless.

It even looks natural.

But there’s a small problem.

This class is lying to you.

And it’s doing it with good intentions.

The first (necessary) lie of OOP

The lie is not technical.

It’s conceptual.

That Person class silently suggests that:

a person can be fully described
their state is knowable
their decisions are modellable
their values are consistent

Of course, we know this isn’t true.

And yet, we keep using this example.

Why?

Because programming is not about describing reality.

It’s about reducing chaos into something we can manage.

The Person class is not reality.

It’s a map.

And maps always lie a little.

The problem is not simplification

The problem is forgetting it

Simplification is not a mistake.

It’s unavoidable.

The problem starts when:

we confuse the map with the territory
we assume the model is reality
we blindly trust what the software “decides”

This is where serious problems begin, especially in complex systems.

A small thought experiment

Let’s try a game.
What if we wrote a Person class that explicitly admits its limits?
Not a simulation of a human being.

Not an artificial mind.

Just an honest object.
Something like this:

final class Person
{
    private string $id;
    private string $name;

    // Observed state (never complete)
    private array $states = [];

    // Declared values (not always respected)
    private array $values = [];

    // Action history (not the truth)
    private array $history = [];

    public function __construct(string $id, string $name)
    {
        $this->id = $id;
        $this->name = $name;
    }

    // Observe a piece of reality
    public function observe(string $key, mixed $value): void
    {
        $this->states[$key] = $value;

        $this->history[] = [
            'type' => 'observation',
            'key'  => $key,
            'time' => time(),
        ];
    }

    // Declare a value
    public function declareValue(string $value): void
    {
        $this->values[] = $value;
    }

    // Decide under uncertainty
    public function decide(array $options): string
    {
        // Not optimal, just plausible
        $choice = $options[array_rand($options)];

        $this->history[] = [
            'type'   => 'decision',
            'choice' => $choice,
            'time'   => time(),
        ];

        return $choice;
    }

    // Expose history, not truth
    public function history(): array
    {
        return $this->history;
    }
}

What actually changes?

This Person class openly states that:

state is partial
values are not hard rules
decisions are not optimal
history is not truth, just a trace In other words:

the software does not pretend to understand everything
Paradoxically, this makes it safer.

Why this matters (outside toy examples)

In real systems — business software, enterprise platforms, infrastructure —

problems rarely happen because software is “stupid”.

They happen because software:

makes silent decisions
auto-corrects without saying so
acts without leaving traces
closes in on itself

A system becomes dangerous when it stops admitting its own limits.

A simple idea to take with you

OOP is not meant to simulate human beings.

It’s meant to make explicit what we can model

and, more importantly, what we cannot.
The classic Person class is not wrong.

It’s incomplete.
The mistake is not writing it.

The mistake is forgetting that it lies a little.

Conclusion

The best software is not the one that “decides better”.

It’s the one that:

exposes its rules
leaves traces
asks for confirmation
admits uncertainty

Maybe the first thing we should teach

when we introduce the Person class

is not how it works…

but where it stops.

# Laravel Pure Alert: a Blade-native alert system for backend interfaces

Vanni Daghini — Sun, 18 Jan 2026 17:47:31 +0000

Most Laravel projects eventually need alerts.

Not fancy notifications.
Just clear feedback: something was saved, something failed, something needs confirmation.

In backend interfaces and admin panels, this often turns into JavaScript helpers, inline scripts, or UI libraries that do much more than required.

Laravel Pure Alert was born from the need to keep this part of the application simple and predictable.

In CRUD-heavy applications, alerts are not really a UI feature.

They belong to the request lifecycle.

A controller handles a request, performs an action, redirects, and the user expects feedback:
success, error, or confirmation before a destructive action.

This flow is already server-side, yet many solutions introduce extra layers and indirection in places that should remain straightforward.

Laravel Pure Alert is a Blade-native alert and confirmation system designed for backend applications.

Alerts are triggered server-side and rendered through Blade components.
There is no frontend state to manage and no JavaScript framework involved.

Everything follows Laravel’s natural request–response flow.

This package is intentionally minimal.

It does not:

support SPA workflows
manage frontend state
replace JavaScript UI frameworks
add visual effects or animations

Laravel Pure Alert is built for admin panels, internal tools, and backend-first interfaces.

Backend interfaces benefit from predictable behavior.

When alerts live in Blade:

permissions are respected automatically
redirects behave exactly as expected
debugging is straightforward
the execution flow is easy to follow

You read the controller, follow the redirect, and see the alert in the layout.
No additional layers to reason about.

A typical usage starts in the controller, during a redirect.

use Illuminate\Http\Request;

public function store(Request $request)
{
    // ... store logic

    return alert()
        ->success(
            title: 'User created',
            message: 'The user has been created successfully.'
        )
        ->redirectRoute('users.index');
}

The alert component is rendered once in your main layout.

<x-alert />

For destructive actions, a confirmation component can be used.

<x-confirm-delete
    action="{{ route('users.destroy', $user) }}"
    method="DELETE"
    message="Are you sure you want to delete this user?"
>
    Delete
</x-confirm-delete>

Laravel Pure Alert follows a few simple principles:

small, readable Blade components
no implicit side effects
easy to remove if requirements change
no lock-in to a specific frontend stack

The goal is clarity rather than abstraction.

The source code is public and can be inspected on GitHub:

https://github.com/Vanni7544/laravel-pure-alert

The complete documentation and usage notes are provided separately as a commercial product.

This is a conscious choice to keep the project sustainable while keeping the implementation transparent.

Full documentation is available here:

https://daghini.gumroad.com/l/hnziix

Laravel Pure Alert is a good fit if you are building:

admin panels
internal tools
CRUD-heavy applications
backend-driven interfaces

It is not designed for frontend-first or animation-heavy projects.

Not every Laravel project needs more JavaScript or more abstraction.

Sometimes a small, predictable solution is enough.

If this approach matches how you build backend applications, you can explore the code on GitHub and the documentation on Gumroad.

Config Manager for Laravel: transitioning the Base to MIT and introducing the Pro edition

Vanni Daghini — Thu, 15 Jan 2026 11:52:47 +0000

Config Manager for Laravel: transitioning the Base to MIT and introducing the Pro edition

Over the past months I’ve been working on Config Manager, a Laravel package focused on one very specific and often underestimated problem:

managing .env files safely in real production environments.

While building this package, I realized how many assumptions we usually make about configuration safety — until something goes wrong in production.

Today I want to clearly explain two important things:

why the Base edition has transitioned to MIT
why a Pro edition exists and is commercial

This is not a marketing post.

It’s about design choices, transparency, and sustainability.

The problem I wanted to solve

In many Laravel projects, configuration management is still handled manually:

copying .env files
editing values directly on servers
applying changes without a clear audit trail
rolling back by guesswork

This works… until it doesn’t.

Production environments require:

predictability
safety
explicit control
reversible actions

Config Manager was born to address exactly this.

Config Manager Base (MIT)

The Base edition of Config Manager is now released as open-source (MIT).

It provides:

structured environment configuration storage
safe export to .env files
automatic backups
basic rollback support
production warnings
a console-first workflow

The Base is meant to be:

understandable
hackable
educational
useful for many projects

Transitioning the Base to MIT was a conscious decision.

Open source is where this project started, and it remains a core part of it.

You can explore the Base edition here:

👉 https://github.com/Vanni7544/config-manager

Why a Pro edition exists

While working on the Base, a clear line emerged.

Some features are not about convenience, but about risk management:

detailed audit logs
explicit production guards
guided recovery flows
diagnostic tools
human-error prevention
long-term maintenance

These features require:

more design
more testing
more responsibility

That’s where Config Manager Pro comes in.

Config Manager Pro

The Pro edition builds on top of the MIT Base and focuses on:

Structured audit logging (INFO / WARN / SECURITY)
Selective rollback, with explicit backup selection
Advanced production guards with mandatory confirmation
A diagnostic config-manager:sync command (read-only)
A guided CLI UX with explicit exit paths
Pro-only safety and consistency checks

This is not a SaaS.

There is no cloud.

No background automation.

No remote control.

It’s still a local, explicit, and predictable tool.

You can inspect the Pro source code here:

👉 https://github.com/Vanni7544/config-manager-pro

The commercial license is available here:

👉 https://daghini.gumroad.com/l/urbzs

A note for early supporters of the Base edition

Before the Base transitioned to MIT, it was distributed under a proprietary license.

If you purchased the Base edition during that period, I want to be very clear and fair about it:

you will receive a 100% refund, no questions asked
you will also receive a 50% discount on Config Manager Pro, if you choose to upgrade

This is not an upsell tactic.

It’s about respecting early supporters and making sure no one feels penalized by the transition.

If this applies to you, just get in touch and it will be handled transparently.

Open source and sustainability

Making the Base MIT does not mean the Pro is “closed”.

Config Manager Pro is source-available:

the code is readable
the design is inspectable
behavior is explicit

What you pay for is the license to use it in production, along with continued development.

This balance allows the project to grow without compromising its principles.

Final notes

If the Base edition is enough for your needs, that’s perfectly fine.
That’s exactly why it’s MIT.

If you manage real production environments and value:

safety
predictability
accountability

then the Pro edition exists for you.

Thanks for reading,

and thanks to everyone who supports sustainable open-source development.

Building a safer way to manage .env in Laravel — and I’ve just released the public roadmap

Vanni Daghini — Tue, 06 Jan 2026 11:00:28 +0000

Hi everyone 👋

A few days ago I shared here a tool I’ve been building for Laravel to make working with .env files a bit safer and less stressful.

Over the past weeks I realised how easy it is to break an application just by:
• missing an environment variable

• overwriting the wrong .env

• changing something in production too quickly

So I decided to build a small tool whose only job is to make .env management more safe, predictable and reversible — without turning Laravel into something it’s not.

I’ve now published a public product roadmap so that everything is clear and transparent:
👉 https://github.com/Vanni7544/config-manager/blob/main/ROADMAP.md

What the tool currently does

Right now Config Manager allows you to:

✔ export environment configuration

✔ validate required variables before export

✔ generate a .env.config-manager file

✔ optionally apply it using --apply

✔ automatically back up the previous .env

✔ rollback safely when needed

✔ show clear warnings when dealing with production

So instead of editing .env manually and hoping for the best,
the workflow becomes much more controlled and calm.

What’s coming next (Pro Edition)

In the roadmap I describe the next major goals, including:

🔹 local audit logs (no SaaS, no external services)

🔹 the ability to choose which backup to restore

🔹 a simple terminal CLI so nobody needs Tinker

🔹 better onboarding and safety UX

All development will stay focused on:

✔ safety

✔ reversibility

✔ predictability

✔ keeping things local

Long-term vision

There will eventually be a Security / Enterprise Edition with things like:

🔸 declarative environment rules

🔸 dry-run mode with human-readable output

🔸 structured audit logging

🔸 CI/CD validation support

🔸 diff between environment versions

But the core philosophy will never change:
🚫 no remote config storage

🚫 no silent updates

🚫 no hidden magic

If you want to have a look

GitHub (details, docs, roadmap):
👉 https://github.com/Vanni7544/config-manager

AMA — happy to chat 🙂

If you’re curious about:

• why I built it

• how it works internally

• real problems it solved for me

• what you would improve

• whether this is useful in your workflow

…feel free to ask anything.

I’m not trying to spam — I genuinely enjoy talking about safe configuration practices in Laravel and learning from how others do it.

Thanks for reading 🙏

I built a safer way to manage .env files in Laravel (export, validate, backup, rollback)

Vanni Daghini — Sun, 04 Jan 2026 09:26:07 +0000

Over the last few weeks, I’ve been working on a small tool for Laravel that was born from a real-world problem I kept running into: safely managing .env files across multiple environments (local, staging, production).

I noticed how little it takes — a missing value, a wrong variable, a rushed copy-paste — to break an application. And when this happens in production, it’s stressful and risky.

So I decided to build something that would make .env management a bit safer and more controlled — without changing how Laravel works.

This is not meant as spam 🙂 — I’m sharing it because it might be useful to others, and also because I’d love to hear how you all manage this topic in your own workflows.

🔐 What the tool does (in simple terms)

The .env file usually contains things like:

• database credentials

• API keys

• environment mode

• other critical configuration values

It’s a fragile file — one wrong line and the app stops working.

So the tool acts like a “safety layer” for .env.

It lets you:

✔ manage configuration per-environment

✔ export a generated .env when you choose

✔ automatically back up your old .env

✔ rollback instantly if needed

And most importantly:

➡ your real .env is NOT touched unless you explicitly apply it

🧪 Examples

Export a configuration:

php artisan config-manager:export <project-id> <environment-id>

This creates:

.env.config-manager

Your .env is not modified yet.

Apply the configuration (with automatic backup):

php artisan config-manager:export <project-id> <environment-id> --apply

This will:

✔ back up your current .env into .env.backups/

✔ replace it with the generated one

Rollback to the previous .env:

php artisan config-manager:export --rollback

Instant restore — no drama 🙂

If the environment is marked as production, the tool also shows a clear confirmation prompt before doing anything — so you don’t accidentally overwrite live configuration.

🔍 If you want to check it out

GitHub:

https://github.com/Vanni7544/config-manager

Gumroad (commercial ready-to-install package):

https://daghini.gumroad.com/l/ifyzw

It’s not a SaaS — nothing leaves your server.

Everything runs locally inside your Laravel project.

💬 Feedback welcome

If you try it and have feedback, criticism, improvement ideas, or thoughts about safer ways to manage .env, I’d honestly love to hear them.

And if you’re curious — AMA-style — about:

• why I built it

• how it works internally

• what real-world problems it solved

• what I’d like to improve next

I’m happy to chat 🙂

This isn’t meant as a promotional post — more a way to share something I built and hopefully learn from the community as well.

Thanks for reading!

❤️ PS

If English isn’t perfect everywhere, forgive me — I’m Italian 🇮🇹 and doing my best 😄 Happy to clarify anything!