DEV Community: Andrea Debernardi

Databases Are Not Becoming Chatbots

Andrea Debernardi — Fri, 17 Apr 2026 11:30:38 +0000

Over the last two months, while building a database tool and adding AI features to it, I started realizing that I was not just shipping product work. I was bumping into a larger question: what happens to databases when software no longer just reads and writes records, but also interprets schema, suggests queries, explains plans, preserves context, and collaborates with language models?

My current view is simple: databases are not becoming chatbots.

The real change is happening in the layer around the database.

Databases still matter because structured truth still matters. LLMs do not replace the need for schemas, constraints, transactions, and systems of record. If anything, they make those things more valuable.

What AI changes is interpretation, navigation, and action around the database.

That became very concrete to me while building Tabularis, especially once AI, notebooks, visual explainability, MCP, and plugins started living in the same workflow.

Here are the main bets I find myself making:

AI should not become the source of truth
AI should stay optional
preserved context matters more than one-shot generation
the future is probably composable

And here are the mistakes I think I may be making:

using AI where better UX would be enough
overestimating generation and underestimating control
underestimating auditability and reproducibility
designing too much for the future

I wrote the full version here, with more detail on the technical decisions and the mistakes behind them:

Read the full article on tabularis.dev

From 0 to 1,000 GitHub Stars in 10 Weeks: What Actually Worked

Andrea Debernardi — Tue, 14 Apr 2026 07:24:09 +0000

Ten weeks ago I pushed the first binary of Tabularis to GitHub. A cross-platform database client built with Tauri (Rust + React/TypeScript). One person, a late-night frustration, and a SQL editor.

Last week the repo crossed 1,000 stars. Today there are 1,086 stars, 70 forks, 15 contributors, 41 releases, and a plugin ecosystem that didn't exist eight weeks ago.

No marketing budget. No growth hacks.

I wrote a detailed post about what actually worked, what didn't, and what I'd do differently. Here are the highlights.

Ship fast, ship broken

The first week produced fifteen releases. Some were embarrassing. I shipped anyway. Nobody remembers your v0.3.0. People remember whether the tool was useful when they tried it, and whether it got better when they came back.

Build an extension point early

The decision that changed the trajectory: shipping a plugin system (language-agnostic JSON-RPC protocol) at the one-month mark. Within two weeks the community had added Redis, ClickHouse, CSV, and a Hacker News plugin. It turned users into builders.

The AI factor

I need to be honest: Tabularis would not exist without AI-assisted development. Specifically, Claude Code.

41 releases in eleven weeks, one person. That math doesn't work without a force multiplier. But AI doesn't replace experience. It amplifies it. Claude Code didn't design the plugin architecture or decide that JSON-RPC was the right protocol. Those decisions came from years of building software.

What AI did was collapse the distance between a decision and its implementation. Once I knew what to build, I could build it in hours instead of days.

The numbers at week 11

The 1,000-star milestone landed at week ten. Here's where things stand today, one week later:

Metric	Week 4	Week 10	Week 11 (today)
Stars	~270	1,000	1,086
Contributors	5	14	15
Releases	17	39	41
Forks	—	65	70
Plugins	1	7	7
Languages	2	4	4
Issues	—	~70	81
Pull Requests	—	~35	41
Downloads	—	~6,000	7,100+

72 countries and counting

One thing that surprised me: where those stars come from. About half of our stargazers have a public location on their GitHub profile, and they span 72 countries across every continent.

The United States and China lead, but what stands out is the long tail: South Korea, Germany, France, Brazil, Indonesia, Vietnam. Tabularis isn't a tool for one market. It's a tool for developers, and developers are everywhere.

Read the full story

The full post covers every phase week by week, what didn't work, and advice for anyone starting an open source project today.

Read the full post on tabularis.dev

GitHub repo

Join the Discord

If you're building something in the open, I'd love to hear your story. Drop a comment or find me on X or Discord.

I am building a Notebook Environment for SQL Inside a Database Client

Andrea Debernardi — Fri, 03 Apr 2026 06:42:43 +0000

This post is also available on tabularis.dev.

You know the drill. Write a query, get a table. Need to build on that result? Copy-paste into the next query. Need a chart? Export CSV, open a spreadsheet. Want to document the analysis? Paste SQL into a doc and pray nothing drifts.

I got tired of this loop, so I'm building Notebooks into Tabularis — a cell-based SQL analysis environment that lives inside the database client. No Jupyter, no Python runtime, no context switching. Just SQL + markdown cells, inline charts, and a few features that make multi-query analysis way less painful.

It's still in development, but the core works. Here's what it looks like and how it's shaping up.

How It Works

A notebook is a sequence of cells — SQL or markdown. SQL cells run against your database and show results inline with the same data grid from the query editor (sorting, filtering, resizable panels). Markdown cells are for documentation between queries.

Cell References via CTEs

This is the part I'm most excited about.

Any SQL cell can reference another cell's query with {{cell_N}}. At execution time, it gets resolved as a CTE:

-- Cell 1: Base query
SELECT customer_id, SUM(amount) AS total
FROM orders
GROUP BY customer_id

-- Cell 3: References Cell 1
SELECT * FROM {{cell_1}} WHERE total > 1000

Becomes:

WITH cell_1 AS (
  SELECT customer_id, SUM(amount) AS total
  FROM orders
  GROUP BY customer_id
)
SELECT * FROM cell_1 WHERE total > 1000

No temp tables, no copy-paste. Change the base query, re-run downstream cells, everything stays in sync. You can chain across multiple cells and every intermediate result stays visible.

Inline Charts

Any result with 2+ columns and at least one row can be charted — bar, line, or pie — directly in the cell. Pick a label column and value columns, done. Config is saved with the cell.

Not meant to replace BI tools. It's for when you're exploring and want a quick visual check before writing the next query.

Parameters

Define once, use everywhere:

@start_date = '2024-01-01'
@end_date   = '2024-12-31'
@min_amount = 500

Every SQL cell with @start_date gets it substituted before execution. Change the value, re-run — all queries pick it up. Great for monthly reports, cohort comparisons, anything where the logic stays the same but inputs change.

Parallel Execution

Not every cell depends on the previous one. Mark independent cells with the lightning bolt icon and they run concurrently during "Run All" instead of waiting in sequence. For notebooks with heavy queries against different tables, this makes a real difference.

Run All + Stop on Error

Ctrl+Shift+Enter runs every SQL cell top to bottom. Stop on Error controls whether it halts at the first failure or keeps going. After execution, a summary card shows succeeded/failed/skipped counts — click a failed cell to jump straight to it.

Multi-Database in One Notebook

Each SQL cell can target a different database connection. Pull from production PostgreSQL in one cell, compare with your analytics SQLite in the next. Works across MySQL, MariaDB, PostgreSQL, and SQLite.

Execution History

Every cell keeps its last 10 runs — timestamp, duration, row count. You can restore any previous query version. Useful when you've been iterating and need to go back.

AI Assist

Each SQL cell has AI and Explain buttons — describe what you want, get SQL back, or break down an existing query. There's also an auto-naming feature: click the sparkles icon and AI generates a cell name based on the content. Named cells show up in a notebook outline for navigation.

Organization

Collapse cells to show just headers
Drag and drop to reorder
Cell names (manual or AI-generated) for identity
Markdown cells as section dividers

Import / Export

.tabularis-notebook — JSON with cells, parameters, charts. No result data. Share it, import it, connect to a different DB, run it.
HTML export — self-contained document with rendered markdown, syntax highlighting, embedded result tables. Dark-themed.
Individual results export as CSV or JSON.

What's Not Done Yet

Being honest about rough edges:

Large notebooks (30+ cells) need better virtualization
Circular reference detection is missing — needs a dependency graph
Chart customization is minimal (no axis labels, no color palettes)
Keyboard navigation between cells is partially implemented
Notebook-level undo/redo doesn't exist yet (cell-level works via Monaco)

Why Build This?

Database clients haven't really evolved beyond "connect, query, see table." Analysis tooling moved forward — Jupyter, Observable, dbt — but the DB client stayed behind.

Notebooks in Tabularis bet that the database client is the right place for exploratory SQL analysis. You already have the connection, the schema, autocomplete, query history. Cells, charts, references and parameters on top of that means the whole workflow — first query to shareable report — happens without switching tools.

It's not a Jupyter replacement. No Python, no R. It's purpose-built for SQL, and for the kind of work most people actually do with their database every day — ad-hoc exploration, report building, data validation, performance investigation — that focus is a feature.

Landing soon. If you want to try it, check out Tabularis.

One Month Building in Public — Here's What I Shipped

Andrea Debernardi — Thu, 26 Feb 2026 09:32:38 +0000

Tabularis was born on the night of January 25th, 2026. A solo project — one person, a frustration turned into code, a binary pushed to GitHub.

Today is exactly one month since that first release. And in one month, it stopped being a solo project.

I believe deeply in what this can become. Not just as a database tool, but as proof that a small team — or even a single person — can build something genuinely useful, genuinely open, and genuinely worth growing. That belief hasn't wavered for a single day. If anything, watching people show up and contribute has made it stronger.

A lot has happened.

The Numbers

~280 stars. 5 contributors. Around 1,000 downloads. Around twenty issues opened by people who actually tried the product, pull requests reviewed, bugs squashed.

For a one-month-old open source project, that's not nothing — that's a community. And communities don't happen by accident. They happen because people show up.

So: thank you. Genuinely.

What We Built

A month ago, Tabularis could connect to PostgreSQL, MySQL, and SQLite. It had a SQL editor, a data grid, and not much else.

Since then, we've shipped:

Plugin System — the biggest release of the month. A language-agnostic JSON-RPC protocol that lets anyone build a new database driver without touching the core app. The first plugin, tabularis-duckdb-plugin, was ready on day one. This is the feature that changes what Tabularis can become: not a tool that supports three databases, but a platform that can support any database.
AI Assistant — generate SQL from natural language, get explanations for complex queries. Integrated with OpenAI, Anthropic, OpenRouter, and Ollama for those who want to keep everything local.
Visual Query Builder — build JOINs and filters without writing a line of SQL.
SSH Tunneling — connect to remote databases through SSH with key and password auth.
Split View — work with two connections simultaneously, side by side.
Schema Management — ER diagrams, inline column editing, table creation wizards.
MCP Server — expose your database to Claude and other AI agents via the Model Context Protocol.
10+ Themes — because your tools should feel good to use.

One month. That's the velocity the community made possible.

The Wiki Is Open

Starting today, the Tabularis Wiki is live and open for contributions. Every page has an Edit on GitHub link.

This is intentional. Documentation written only by the maintainers reflects only the maintainers' perspective. If you've figured out a non-obvious workflow, found a gotcha during setup, or have a tip that saved you time — the wiki is the right place for it.

What's Next

The plugin ecosystem is still young. We want drivers for ClickHouse, CockroachDB, and more. We want the registry to grow. We want the community to build things we haven't thought of yet.

On the core side: better query history, smarter autocomplete, a more complete ER diagram, and performance improvements are all in flight.

Get Involved

GitHub: github.com/debba/tabularis
Discord: discord.gg/YrZPHAwMSG
brew install --cask tabularis
Snap: snap install tabularis
AUR: yay -S tabularis-bin

If Tabularis has been useful to you — tell someone. Open source lives and dies by word of mouth.

Here's to month two.

Building Tabularis: A Developer's Database Tool That Doesn't Suck

Andrea Debernardi — Mon, 09 Feb 2026 09:56:35 +0000

I've been managing databases for years, and I'm tired of the same two options: heavyweight enterprise tools that feel like flying a 747 to get groceries, or stripped-down CLI utilities that make even simple tasks a chore. There had to be a middle ground—something fast, clean, and actually enjoyable to use.

So I built Tabularis, starting from a vibe-coding session with Claude Code, and then it evolved as I really put my mind into it.

The Problem With Database Tools

Like everyone else, I spent years bouncing between phpMyAdmin, MySQL Workbench, DBeaver, and whatever else was popular that quarter. They all had the same issues:

Too heavy: Enterprise tools pack in features I'll never touch, eating RAM and taking forever to start
Poor UX: Clunky interfaces designed by committee, not for actual daily use
Vendor lock-in: Tools optimized for one database, awkward for others
Missing modern features: No AI assistance, no visual query building, no MCP integration

The real frustration came when I just wanted to quickly check production data or test a query—it shouldn't require launching a 500MB Electron app and waiting 30 seconds for it to connect.

What Makes Tabularis Different

Tabularis is what I actually wanted to use every day. It's built with Tauri (not Electron), so it's genuinely lightweight—the entire app is under 20MB. Starts in under a second. Feels native because it is native.

But being lightweight doesn't mean being limited. Here's what actually matters:

Connection Management That Makes Sense

SSH tunneling with automatic readiness detection. No more "is the tunnel up yet?" guessing games. Secure password storage in your system keychain, not some custom encrypted file. Clone connection profiles instead of manually recreating them.

The Database Explorer I Always Wanted

A proper tree view that shows everything—tables, views, stored procedures, functions, foreign keys, indexes. Not hidden in submenus or separate windows. Right-click context actions for common operations. Want to see the row count? It's one click, not three windows deep.

The ER diagram generator is particularly useful. It's not trying to be a full diagramming tool—it just shows your schema interactively. Pan, zoom, select specific tables. When you're debugging a complex query join, being able to visually trace the relationships saves real time.

Visual Query Builder (That Actually Works)

Most visual query builders are toys. They work for SELECT * FROM users and fall apart at the first JOIN. I needed something that could handle real queries—multiple joins, aggregates, WHERE clauses, HAVING filters.

The builder uses ReactFlow for drag-and-drop table connections. Create visual relationships between tables, and it generates proper JOIN syntax. Add filters, aggregates, sorting—all visually—and watch the SQL update in real-time. When you need to switch to the SQL editor, you're not starting from scratch.

AI Integration (Optional, But Useful)

This is where it gets interesting. I didn't want to force cloud AI on anyone—privacy matters—so Tabularis supports multiple AI providers:

OpenAI, Anthropic, OpenRouter for cloud options
Ollama for completely local inference
OpenAI-compatible APIs (Groq, Perplexity, LocalAI, etc.)

The AI features are straightforward: text-to-SQL generation and query explanation. Type "show me users who signed up last week" and get working SQL. Or paste a complex query and get a plain-English explanation of what it's doing.

But here's the part I'm most excited about: MCP Server support.

The MCP Server: Exposing Databases to AI Agents

Tabularis includes a built-in Model Context Protocol (MCP) server. Run tabularis --mcp and your database connections become available to any MCP-compatible AI agent—Claude Desktop, Cursor, or custom tools.

This means AI agents can query your databases directly. Not through screenshots or copy-paste, but actual programmatic access. I've been using it with Claude Desktop to analyze production data, generate reports, and debug queries—all without leaving my chat window.

The architecture is simple: Tabularis runs as an MCP server, exposes your saved connections through a standard protocol, and handles authentication and query execution. The AI agent just sees a set of available databases and can query them like any other data source.

It's surprisingly powerful. I recently had Claude help me optimize a slow query by letting it inspect the actual table structures, existing indexes, and query execution patterns—all through MCP. It generated three optimization strategies, I tested them, and cut query time by 60%. That workflow wasn't possible with traditional database tools.

Building It All

I started Tabularis about six months ago, mostly as a weekend project to scratch my own itch. The tech stack choices were deliberate:

Tauri v2 instead of Electron (smaller bundle, better performance, native feel)
React 19 with TypeScript (familiar, fast development)
Tailwind CSS v4 (rapid UI iteration without CSS bloat)
Rust backend with SQLx (type-safe queries, excellent performance)

The Rust backend handles all database operations through SQLx, which provides compile-time verification of SQL queries. No more runtime surprises about typos in column names. SSH tunneling is handled with native Rust libraries, not shelling out to external processes.

One interesting challenge was supporting multiple database types (MySQL, PostgreSQL, SQLite) with a unified interface. SQLx helps here with its database-agnostic query builder, but each database has quirks—MySQL's information_schema differs from PostgreSQL's pg_catalog, and SQLite is its own thing entirely.

The solution was a trait-based provider system in Rust. Each database implements a common DatabaseProvider trait that defines operations like "fetch tables," "execute query," "get foreign keys." The frontend doesn't care which database it's talking to—it just calls methods on the trait.

Using Tabularis

Getting started is intentionally simple:

macOS (Homebrew)

brew tap debba/tabularis
brew install --cask tabularis

Arch Linux

yay -S tabularis-bin

Everyone Else

Download from releases for Windows, Linux (AppImage), or macOS (DMG).

Connect to your database, start exploring. The interface is designed to be obvious—if you've used any database tool before, you'll figure it out in 30 seconds.

All configuration lives in ~/.config/tabularis/ (or your OS equivalent)—connections, saved queries, themes, settings. Plain JSON files, easy to back up or edit manually if needed.

What's Next

Tabularis is fully functional today, but there's more to build:

Better PostgreSQL & SQLite support: MySQL is solid, but Postgres and SQLite need more love
Query history: Track and revisit past queries across sessions
Performance monitoring: Built-in query profiling and execution plan visualization

The code is on GitHub, Apache 2.0 licensed. It's built by a developer, for developers. No telemetry, no accounts, no subscriptions. Just a tool that works.

If you're tired of database tools that feel like they're fighting you instead of helping you, give Tabularis a try. It's what I wish I had years ago.

Download: tabularis.dev | Source: github.com/debba/tabularis

Run tabularis --mcp to enable MCP server mode and start connecting your databases to AI agents.

I was tired of database tools — so I started building my own

Andrea Debernardi — Tue, 27 Jan 2026 12:04:22 +0000

Repo url: https://github.com/debba/debba.sql

At some point, I realized I was spending more energy fighting my database tools than actually working with databases.

Most of the popular DB managers are:

closed source
heavy as hell
UX-wise… questionable
clearly not built with Linux developers in mind

And yes, some of them look nice (👀 DataGrip), but they feel like bringing a tank to open a bottle of water.

So one night, instead of complaining on Twitter or Discord, I did the most dangerous thing a developer can do:

I started vibe coding my own DB manager.

It started as a hack (literally)

This wasn’t a “vision”, or a “startup idea”.

It was:

late at night
Rust open in my editor
Tauri + React on the side
a strong feeling of “how hard can it be?”

I just wanted:

something fast
something local
something that doesn’t feel like a bloated enterprise product
something I can actually understand end-to-end

No roadmap.

No design doc.

Just hacking.

From vibe coding to “wait, this might actually work”

After the first hacky prototype, something unexpected happened.

I kept adding things.

Slowly.

Incrementally.

Scratching my own itch.

What started as:

“Let me just connect to a DB”

became:

multi-database support (SQLite, Postgres, MySQL…)
a cleaner mental model
better performance than I expected
an app that feels mine

At that point I thought:

ok, either I stop now… or I open-source it and see what happens.

debba.sql (name pending 😅)

The project is currently called debba.sql — debba is my nickname and, conveniently, contains db.

Is the name final?

Probably not.

Is the project done?

Absolutely not.

Right now it’s:

🧩 a side project
🦀 written in Rust
🖥️ wrapped with Tauri
⚛️ frontend in React
🐧 built with Linux devs in mind
🌍 open source, repo public

No company.

No monetization (for now).

Just a tool I actually want to use.

This is not a manifesto (yet)

I’m not claiming this will “replace” anything.

I’m not claiming it’s better than your favorite tool.

I am saying:

dev tools should feel empowering
open source matters
UX is not optional
Linux users deserve first-class experiences

And sometimes, the best way to stop complaining…

is to build.

I want your feedback

This is the part where I shut up and listen.

If you:

have strong opinions about DB tools
build dev tools yourself
care about open source UX
are tired of bloated software

I’d love your feedback.

Issues, comments, brutal honesty — all welcome.

This started as vibe coding at night.

Let’s see where it goes.

🧪🔥

Repo url: https://github.com/debba/debba.sql

From VS Code to Zed: building a FreeMarker extension because I needed one

Andrea Debernardi — Thu, 15 Jan 2026 12:37:57 +0000

From VS Code to Zed: building a FreeMarker extension because I needed one

A few months ago, I switched from VS Code to Zed.

Not because VS Code is bad — it’s still an amazing editor — but because it slowly became… heavy.

My setup had turned into a Frankenstein monster of freemium extensions, background processes, upsells, and “just one more helper” that somehow made everything slower.

I wanted something:

fast
open-source
opinionated
boring in the best possible way

Zed checked all the boxes.

Until I had to start working with FreeMarker.

FreeMarker is still very much alive

If you work in Java or enterprise environments, you already know this.

FreeMarker isn’t trendy.

It’s not on Hacker News every week.

But it’s everywhere.

In my case, I’m using it in a project that integrates Keycloak, where FreeMarker templates are still a core part of the customization flow.

So yes — FreeMarker is old.

And yes — it’s still critical.

Which made this part a bit painful:

👉 Zed had no FreeMarker support.

No syntax highlighting.

No understanding of directives.

Nothing.

The “fine, I’ll do it myself” moment

Zed is fast enough that once you get used to it, going back feels… wrong.

So instead of switching editors again, I thought:

“How hard can it be to write a FreeMarker extension?”

(Last words before opening a tree-sitter grammar.)

I already knew that:

Zed uses tree-sitter
Syntax highlighting is grammar-driven
Extensions are lean and explicit

I also had a starting point:

a FreeMarker extension for VS Code.

The idea was simple:

reuse what I could
adapt what I had to
learn the Zed extension model along the way

With some help from vibe-coding and a lot of trial & error, I started porting it.

The actual journey (a.k.a. tree-sitter reality check)

Some things were easier than expected:

Zed’s extension model is refreshingly clean
Tree-sitter forces you to think properly about structure
No magic, no hidden layers

Some things were… not:

FreeMarker syntax is flexible in annoying ways
Directives, interpolations, nested expressions
Edge cases you only notice after breaking everything

Porting from VS Code wasn’t a copy–paste job.

It was more like translating between two different mental models.

But honestly?

That’s what made it fun.

The result: early, but usable

The extension is live here:

👉 https://github.com/debba/zed-freemarker

What it supports today:

FreeMarker syntax highlighting
Directives
Interpolations
A solid base for further improvements

Is it perfect? No.

Is it production-grade? Not yet.

Is it good enough to work daily without hating your editor? Absolutely.

And for an editor like Zed, that already feels like a win.

Thoughts on Zed and niche tooling

Zed feels like an editor for people who:

enjoy understanding how their tools work
prefer fewer abstractions
don’t mind building missing pieces themselves

Writing this extension reminded me of something important:

Open source doesn’t move forward only with big features —

it also grows through small, boring, niche tools that solve real problems.

FreeMarker isn’t cool.

But someone still has to maintain it.

What’s next?

Possible next steps:

better grammar coverage
error handling
maybe an LSP in the future (no promises)

If you:

use FreeMarker
use Zed
enjoy hacking on developer tools

Feedback, issues, and PRs are more than welcome.

Sometimes the best extensions start with a simple need:

“I just want my editor to understand this file.”

And that’s exactly how this one was born 🚀

Building AuthPress: From Simple Telegram 2FA to Extensible WordPress Security Platform

Andrea Debernardi — Tue, 16 Sep 2025 12:50:53 +0000

How I evolved a single-provider WordPress 2FA plugin into a comprehensive, developer-friendly authentication system

The Problem 🔐

WordPress powers 43% of the web, but most sites still rely on password-only authentication. While there are 2FA plugins available, they're often:

Limited to specific providers
Hard to extend or customize
Not developer-friendly
Missing modern authentication methods

The Journey 🚀

AuthPress started as a simple idea: "What if I could get my WordPress 2FA codes via Telegram?" Three years and multiple iterations later, it's become a comprehensive authentication platform.

Version 4.0: The Extensible Platform

Now it supports multiple providers through a clean architecture:

// Modern extensible system
abstract class Abstract_Provider {
    abstract public function send_code($user_id, $code);
    abstract public function verify_code($user_id, $code);
    abstract public function render_user_settings($user_id);
}

// Register custom providers
add_filter('authpress_register_providers', function($providers) {
    $providers['my_sms'] = 'MyPlugin\\SMS_Provider';
    $providers['push_notification'] = 'MyPlugin\\Push_Provider';
    return $providers;
});

Technical Architecture 🏗️

Core Features

Multi-Provider Support: Telegram, Email, TOTP, Recovery Codes
Extensible API: Clean interfaces for custom providers
Professional Logging: WordPress-native admin tables
Security First: Rate limiting, encrypted storage, brute force protection

The Provider System

Each authentication method is a provider class:

class Telegram_Provider extends Abstract_Provider {
    public function send_code($user_id, $code) {
        // Telegram API integration
        return $this->send_telegram_message($user_id, $code);
    }

    public function verify_code($user_id, $submitted_code) {
        // Validate against stored code
        return $this->validate_stored_code($user_id, $submitted_code);
    }

    public function render_user_settings($user_id) {
        // User configuration interface
        include 'templates/telegram-settings.php';
    }
}

Developer Experience 👨‍💻

Creating Custom Providers

Want SMS via Twilio? Here's how simple it is:

class Twilio_SMS_Provider extends Abstract_Provider {
    private $twilio_client;

    public function __construct() {
        $this->twilio_client = new Twilio\Rest\Client($sid, $token);
    }

    public function send_code($user_id, $code) {
        $phone = get_user_meta($user_id, 'phone_number', true);

        return $this->twilio_client->messages->create($phone, [
            'from' => '+1234567890',
            'body' => "Your WordPress login code: {$code}"
        ]);
    }

    public function verify_code($user_id, $code) {
        return parent::verify_stored_code($user_id, $code);
    }
}

WordPress Integration

Follows WordPress best practices:

Uses hooks and filters extensively
Proper nonce verification
WP_List_Table for admin interfaces
Standard WordPress coding standards

What's Next? 🔮

Working on:

Passkey/WebAuthn integration (already in beta)
Hardware token support (YubiKey, etc.)

Open Source & Community 💝

AuthPress is GPL-licensed and available on:

WordPress.org: Official plugin directory
GitHub: dueclic/authpress

Contributing

We welcome contributions! Especially:

New provider implementations
Security audits
Documentation improvements
Translation updates

Lessons Learned 📚

Start simple, architect for growth - The extensible design saved massive refactoring
Security can't be an afterthought - Built-in from day one
Developer experience matters - Clean APIs lead to better ecosystem
WordPress standards exist for a reason - Following them made everything easier

Try AuthPress on your WordPress site and let me know what custom providers you'd build! The extensibility system makes it possible to integrate with virtually any authentication service.

What 2FA method would you want to see next? Drop your ideas in the comments! 👇

WordPress #2FA #Security #PHP #OpenSource

Building rewindtty – a terminal session recorder in C with PTY support

Andrea Debernardi — Wed, 30 Jul 2025 19:04:21 +0000

Have you ever needed to record what happens inside a terminal — with timing, full output, and possibly even ANSI sequences?

That’s what I’m building with rewindtty, a simple yet powerful terminal session recorder written in pure C. It spawns CLI commands inside a pseudo-terminal (PTY), and logs the output in structured JSON format with timestamps.

✅ It already records:
• stdout and stderr
• command execution and timestamps
• logs you can replay or analyze later

🔧 I just opened a feature request to support recording ANSI escape sequences, so that full-screen TUI programs like vim, htop, and others can be captured and replayed accurately.

🎯 Use cases:
• Debugging interactive programs
• Sharing reproducible CLI workflows
• Building in-browser replayers (with e.g. xterm.js)

🧠 I’d love your feedback, especially if you’ve worked with PTY APIs in C, terminal emulation, ANSI sequence parsing or rendering

I built rewindtty: a C tool to record and replay terminal sessions as JSON logs (like a black box for your CLI)

Andrea Debernardi — Mon, 28 Jul 2025 16:25:44 +0000

Hey folks! 👋

Over the past few weeks, I’ve been working on a little tool in C called rewindtty — it's like a black box for your terminal.

The idea is simple:

rewindtty record: Launches a shell (or any program), records all your inputs and outputs to a JSON log.

rewindtty replay: Replays that session step-by-step in a terminal-like environment.

Here’s an example of what the recorded JSON looks like:

{
  "timestamp": "2024-07-28T14:01:03Z",
  "command": "ls -la",
  "output": "total 4\n-rw-r--r-- file.txt\n",
  "stderr": ""
}

Why?

I wanted a dead-simple way to:

-Capture what really happened in a CLI session, without overengineering.
-Debug or share reproducible steps with colleagues (like "here’s exactly what I typed and what I got").

Build a foundation for visual or animated terminal playback (think GIFs or asciinema-style exports).
How it works

Under the hood:

Uses fork() to launch a subprocess in a pseudo-terminal.
Intercepts both stdin and stdout/stderr, recording them with precise timestamps.
Clean JSON output makes it easy to transform, diff, analyze, or visualize.

Cool ideas I’m playing with next:

--timing flag to replay with realistic delays
Export to .cast format (asciinema)
GIF or SVG animations using svg-term
Auto-record hooks for Git or critical scripts
Comparing two sessions for debugging

Why not use asciinema?

Great question! I love asciinema, but:

I wanted full control over the data format (and stderr!)
JSON logs are easier to post-process for my use case
I wanted to build it in C for fun and for low-level control

Project URL

DBSeeker - MySQL Search Script (Alpha) : Search Across All Databases!

Andrea Debernardi — Wed, 12 Mar 2025 06:39:15 +0000

Project URL

I’ve built a tiny script that lets you search for a string across every database on a MySQL server. It outputs results in a table format, showing which database and table contain the term, how many rows were found, and the search time.

It’s still in alpha, so expect some bugs and missing features. Feedback and suggestions are welcome!

Would you find this useful? Let me know what you think! 🚀

Angular 18.1: Template Local Variables with @let

Andrea Debernardi — Thu, 11 Jul 2024 20:36:56 +0000

Key takeaways

Syntax: let variableName = expression;
Scope: The variable is only available within the HTML element or block where it's declared.
Common scenarios:
- Reduce repetition of complex expressions.
- Better handle type narrowing.
- Define complex styling options.
- Improve template readability.

Best practices

Use let to minimize repetition.
Use let to improve type narrowing.
Use let to define complex styling options.
Carefully consider using let for calculations or business rules.

Thoughts

The let declaration is a welcome addition that simplifies variable management in templates and improves code readability. It's particularly useful for reducing repetition and defining complex styling options. However, it's important to carefully consider using let for calculations or business rules, as it could make the code harder to maintain.

Additional resources

Official Angular documentation on the let declaration: https://blog.angular.dev/introducing-let-in-angular-686f9f383f0f?gi=63f5b3e52822

How do you plan to use the let declaration in your Angular projects?

Leave a comment below and share your thoughts!