DEV Community: the bomber

Desktop Automation on GNOME Wayland without Root: Using Mutter RemoteDesktop and ScreenCast over D‑Bus

the bomber — Sat, 31 Oct 2026 22:55:30 +0000

Introduction

I run a small web shop from my home office in Pompano Beach. The same machine also hosts a personal automation server that drives a few on‑screen demos, takes periodic screenshots for monitoring, and even clicks a few buttons in a legacy GUI when a webhook arrives. All of that runs under my regular user account – no sudo, no X11, pure Wayland.

GNOME’s compositor, Mutter, ships two D‑Bus interfaces that are perfect for this use case:

org.gnome.Mutter.RemoteDesktop – lets you inject pointer and keyboard events.
org.gnome.Mutter.ScreenCast – lets you start a PipeWire screencast and read the frames.

The trick is that both are exposed over the session bus and require only the org.gnome.Mutter.RemoteDesktop and org.gnome.Mutter.ScreenCast permissions, which GNOME grants to any user that is logged into the desktop. Below is a step‑by‑step guide to wiring them together with Python.

Prerequisites

GNOME 45 (or later) running on Wayland.
Python 3.9+.
dbus-next – a modern async D‑Bus client.
pypipewire – thin wrapper around PipeWire’s C API (optional, we can read raw fd).
glib – for the main loop (gi.repository.GLib).

Install the Python bits with:

pip install dbus-next pypipewire

Getting a Session Bus Connection

The session bus is already available to any graphical user. Using dbus-next we can connect like this:

from dbus_next.aio import MessageBus
import asyncio

async def get_bus():
    bus = await MessageBus().connect()
    return bus

The MessageBus object will be reused for both interfaces.

Requesting a Screencast

The ScreenCast interface follows the same pattern as the older XDG desktop portal. First we create a session, then we start it.

SCREENCAST_IFACE = 'org.gnome.Mutter.ScreenCast'
SCREENCAST_PATH = '/org/gnome/Mutter/ScreenCast'

async def start_screencast(bus):
    proxy = await bus.introspect(SCREENCAST_IFACE, SCREENCAST_PATH)
    obj = bus.get_proxy_object(SCREENCAST_IFACE, SCREENCAST_PATH, proxy)
    iface = obj.get_interface(SCREENCAST_IFACE)

    # Create a new session – we ask for a single monitor, 30 fps, RGBA.
    reply = await iface.call_create_session({'source_type': 1,  # MONITOR
                                            'monitor': 0,
                                            'cursor_mode': 2})  # EMBEDDED
    session_path = reply[0]

    # Open a PipeWire stream for the session.
    reply = await iface.call_open_pipe_wire_remote(session_path, {})
    fd = reply[0].take()  # Raw file descriptor for the PipeWire node.
    return fd

The returned file descriptor can be handed to pypipewire to pull frames. A minimal frame reader looks like this:

import pypipewire as pw

async def read_frames(fd):
    stream = pw.Stream(fd)
    async for frame in stream:
        # `frame` is a numpy‑compatible buffer; we just count frames here.
        print('got frame', frame.width, frame.height)

In production I store the latest frame in a shared memory object so the automation logic can inspect pixels without blocking the capture loop.

Injecting Input via RemoteDesktop

The RemoteDesktop interface is a thin wrapper around the same code path that GNOME’s built‑in “remote control” uses.

RDESK_IFACE = 'org.gnome.Mutter.RemoteDesktop'
RDESK_PATH = '/org/gnome/Mutter/RemoteDesktop'

async def init_remote_desktop(bus):
    proxy = await bus.introspect(RDESK_IFACE, RDESK_PATH)
    obj = bus.get_proxy_object(RDESK_IFACE, RDESK_PATH, proxy)
    iface = obj.get_interface(RDESK_IFACE)
    # Enable the session – required before sending events.
    await iface.call_enable(True)
    return iface

Moving the Pointer

The pointer API expects normalized coordinates (0‑1). To click the centre of the primary monitor we do:

async def click_center(rdesk):
    # Move to centre.
    await rdesk.call_move_pointer(0.5, 0.5)
    # Press left button (button 1).
    await rdesk.call_button_press(1)
    await rdesk.call_button_release(1)

Typing Text

Keyboard events are sent as XKB keycodes. The easiest way is to ask the system for a mapping via xkbcommon. For a short demo I ship a tiny lookup table for ASCII letters.

ASCII_TO_XKB = {
    'a': 0x26, 'b': 0x38, 'c': 0x36, # … truncated for brevity
}

async def type_string(rdesk, text):
    for ch in text:
        keycode = ASCII_TO_XKB.get(ch.lower())
        if not keycode:
            continue
        await rdesk.call_key_press(keycode)
        await rdesk.call_key_release(keycode)

In a real script I generate the table programmatically with xkbcommon to avoid missing symbols.

Putting It All Together

The following main() function starts the screencast, launches a background task that watches for a red pixel in the top‑left corner, and clicks a button when the pixel appears.

import asyncio
from gi.repository import GLib

async def monitor_and_click(bus, rdesk):
    fd = await start_screencast(bus)
    # Simple frame loop – break when condition met.
    async for frame in read_frames(fd):
        # Assume frame is a numpy array (height, width, 4).
        if (frame[0,0,:3] == [255,0,0]).all():
            print('red pixel detected – clicking')
            await click_center(rdesk)
            break

async def main():
    bus = await get_bus()
    rdesk = await init_remote_desktop(bus)
    await monitor_and_click(bus, rdesk)
    # Clean up – disable remote desktop.
    await rdesk.call_enable(False)

# Run inside GLib's main loop so D‑Bus signals are processed.
loop = GLib.MainLoop()
asyncio.get_event_loop().run_until_complete(main())
loop.run()

The script runs entirely as my normal user. No sudo or X11 tricks are needed, and because everything talks to the session bus, the compositor enforces the same security model you get when you use GNOME’s built‑in “Remote Desktop” feature.

Running as a Systemd User Service

I keep the automation alive with a systemd --user unit. Create ~/.config/systemd/user/gnome‑automation.service:

[Unit]
Description=GNOME Wayland automation script
After=graphical-session.target

[Service]
ExecStart=/usr/bin/python3 /home/kaleb/automation/gnome_automation.py
Restart=on-failure
Environment=PYTHONUNBUFFERED=1

[Install]
WantedBy=default.target

Enable and start it:

systemctl --user daemon-reload
systemctl --user enable --now gnome-automation.service

The service will automatically reconnect to the session bus each time I log in, and it will stop cleanly when I log out.

Security Considerations

Permission Scope – The D‑Bus interfaces are only exposed to the active session. A rogue process that runs under a different user cannot talk to them.
User Confirmation – GNOME shows a one‑time dialog the first time an application requests RemoteDesktop or ScreenCast. I accepted it during development; the dialog is a useful guardrail for any future scripts.
Network Exposure – All communication stays on the local D‑Bus. If you need remote triggers, expose a tiny HTTP endpoint on the automation server and let the script poll it – never forward the D‑Bus over the network.

Conclusion

Mutter’s D‑Bus APIs give you a clean, root‑less way to automate a Wayland desktop. By combining ScreenCast for visual feedback and RemoteDesktop for input injection, you can build headless‑style workflows on a regular GNOME session. The code snippets above are exactly what I run on my own machine to generate screenshots for a status page and to click a “Refresh” button when a webhook tells me new data is available.

I build sites and automations for small businesses at dreamfuturestech.com.

Filtering Freelance Leads: Recency Windows and Job‑Board Rules in My Home‑Hosted Scanner

the bomber — Sat, 31 Oct 2026 12:01:09 +0000

Introduction

When I started scanning freelance job boards for my own projects, I quickly ran into two problems: most listings were stale, and each board had its own quirks that made a naïve scraper return a lot of noise. In this post I walk through how I built a lightweight filter layer that sits on top of my home‑hosted lead scanner. The layer applies recency windows and board‑specific rules so that only fresh, relevant opportunities make it into my daily Slack digest.

Architecture Overview

The scanner runs on a modest Raspberry Pi 4 that I keep in my garage. A cron job triggers a Node.js script every 30 minutes. The script:

Fetches raw JSON feeds from the boards I monitor (Upwork, Freelancer, Guru, etc.).
Normalises the payload into a common shape.
Passes the normalised items through a filter pipeline.
Sends the surviving leads to a Slack webhook.

All of the filtering logic lives in a single filters.js module so I can tweak rules without touching the scraper.

Pulling Job Posts

Each board exposes a slightly different API. Here’s a trimmed example for Upwork:

// src/fetchers/upwork.js
const fetch = require('node-fetch');

module.exports = async function fetchUpwork() {
  const resp = await fetch('https://www.upwork.com/api/v3/search/jobs?category=web-development');
  const data = await resp.json();
  // Normalise to our internal shape
  return data.jobs.map(job => ({
    id: job.id,
    title: job.title,
    board: 'upwork',
    postedAt: new Date(job.created_at),
    budget: job.budget?.amount,
    description: job.description,
    url: job.url,
  }));
};

Similar fetchers exist for the other boards. The important part is that every job ends up with the same fields (id, title, board, postedAt, …) so the filter code can stay board‑agnostic.

Defining Recency Windows

A recency window is simply “only keep jobs posted within the last N minutes”. Different boards update at different rates, so I keep a per‑board configuration:

// config/recency.json
{
  "upwork": 60,
  "freelancer": 30,
  "guru": 120
}

The values are minutes. The filter reads this file at start‑up:

// src/filters/recency.js
const recencyConfig = require('../config/recency.json');

function withinWindow(job) {
  const minutes = recencyConfig[job.board] || 60; // default 60
  const age = (Date.now() - job.postedAt.getTime()) / 60000;
  return age <= minutes;
}

module.exports = withinWindow;

Because the config is a plain JSON file, I can adjust windows on the fly without redeploying.

Board‑Specific Rules

Beyond age, each board has its own “noise” patterns. For example:

Upwork – many listings have a budget of $0 which usually means “hourly rate not disclosed”. I ignore those unless the title contains “fixed‑price”.
Freelancer – the API returns duplicate entries for the same project; they share the same id but differ in url. I keep the first occurrence.
Guru – some jobs are marked “closed” but still appear in the feed. The status field tells the truth.

I encode these as small predicate functions:

// src/filters/boardRules.js
function upworkRule(job) {
  if (job.budget === 0 && !/fixed-price/i.test(job.title)) return false;
  return true;
}

function freelancerRule(job, seen) {
  if (seen.has(job.id)) return false;
  seen.add(job.id);
  return true;
}

function guruRule(job) {
  return job.status !== 'closed';
}

module.exports = { upworkRule, freelancerRule, guruRule };

Putting It Together: The Filter Pipeline

The main pipeline composes the generic recency filter with the board‑specific rule set:

// src/filters/index.js
const withinWindow = require('./recency');
const { upworkRule, freelancerRule, guruRule } = require('./boardRules');

function filterJobs(jobs) {
  const seen = new Set(); // for duplicate detection on Freelancer
  return jobs.filter(job => {
    if (!withinWindow(job)) return false;

    switch (job.board) {
      case 'upwork':
        return upworkRule(job);
      case 'freelancer':
        return freelancerRule(job, seen);
      case 'guru':
        return guruRule(job);
      default:
        return true;
    }
  });
}

module.exports = filterJobs;

The pipeline runs after all fetchers have merged their results:

// src/main.js
const fetchUpwork = require('./fetchers/upwork');
const fetchFreelancer = require('./fetchers/freelancer');
const fetchGuru = require('./fetchers/guru');
const filterJobs = require('./filters');

(async () => {
  const raw = [
    ...(await fetchUpwork()),
    ...(await fetchFreelancer()),
    ...(await fetchGuru()),
  ];
  const leads = filterJobs(raw);
  // send leads to Slack …
})();

Running It at Home

On my Pi I use pm2 to keep the process alive and crontab to trigger it:

*/30 * * * * /usr/local/bin/node /home/kaleb/lead‑scanner/src/main.js >> /var/log/lead‑scanner.log 2>&1

All the code lives in a Git repo on the same machine, so I can git pull updates and restart pm2 with a single command. The only external dependency is the Slack webhook URL, which I store in an environment variable (SLACK_WEBHOOK).

Lessons Learned

Keep the filter pure – By avoiding any I/O inside the predicate functions I can unit‑test them easily. A couple of jest tests now guard against regressions when I tweak the recency windows.
Configuration over code – Moving the windows to JSON meant I could experiment with a tighter window for Upwork during a busy period without touching any source files.
Board quirks change – APIs evolve, so I schedule a monthly “sanity check” that runs the fetchers and logs any new fields. When a board adds a visibility flag, I add a rule and I’m good.

Conclusion

Filtering out stale or noisy listings is the difference between a useful lead digest and a daily inbox full of dead ends. By separating the concerns—fetching, normalising, and filtering—I built a system that is easy to extend and runs reliably on a cheap home server.

I build sites and automations for small businesses at dreamfuturestech.com.

Using node:sqlite in Node 24 to Build a Tiny Express Service Without a Separate Database Server

the bomber — Fri, 30 Oct 2026 18:44:48 +0000

Introduction

I’m Kaleb, a web developer in Pompano Beach, Florida. For my own website and the home automation server I run, I needed a lightweight API that could store a few dozen records – things like scheduled tasks, device metadata, and simple logs. I didn’t want to spin up a separate database server, so I turned to the new node:sqlite module that ships with Node 24. In this article I walk through the exact steps I used to create a small Express service that talks directly to a SQLite file.

Why SQLite with Node 24?

Zero external server – the database lives in a single file on disk, perfect for a home box.
Built‑in driver – node:sqlite is part of the Node standard library, no extra native bindings to compile.
Async/await API – the API mirrors the modern fetch style I already use in my front‑end code.

I chose SQLite because the data model is simple and the performance is more than enough for a few hundred reads/writes per day. If you need massive concurrency or complex analytics, a full RDBMS would be a better fit.

Setting Up the Project

mkdir home‑api && cd home‑api
npm init -y
npm i express
# node:sqlite is built‑in, no npm install needed

The folder now contains a package.json and a node_modules directory for Express.

Creating the SQLite Database

I keep the database file next to the source code for easy backup.

// db/init.js
import { open } from 'node:sqlite';
import { promises as fs } from 'node:fs';

const DB_PATH = './data/home.db';

export async function initDb() {
  // Ensure the data directory exists
  await fs.mkdir('data', { recursive: true });

  const db = await open(DB_PATH, {
    // `sqlite3` driver is used under the hood
    // The `mode` flag defaults to READWRITE | CREATE
  });

  // Simple schema for scheduled tasks
  await db.exec(`
    CREATE TABLE IF NOT EXISTS tasks (
      id INTEGER PRIMARY KEY AUTOINCREMENT,
      name TEXT NOT NULL,
      cron TEXT NOT NULL,
      enabled INTEGER NOT NULL DEFAULT 1,
      created_at TEXT DEFAULT (datetime('now'))
    );
  `);

  return db;
}

Running this script once creates data/home.db and the tasks table.

Wiring Express to SQLite

// index.js
import express from 'express';
import { initDb } from './db/init.js';

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

let db;

// Initialise DB before handling any request
app.use(async (req, res, next) => {
  if (!db) db = await initDb();
  req.db = db;
  next();
});

// GET /tasks – list all scheduled tasks
app.get('/tasks', async (req, res) => {
  try {
    const rows = await req.db.all('SELECT * FROM tasks ORDER BY id DESC');
    res.json(rows);
  } catch (e) {
    console.error(e);
    res.status(500).json({ error: 'Database error' });
  }
});

// POST /tasks – create a new task
app.post('/tasks', async (req, res) => {
  const { name, cron, enabled = 1 } = req.body;
  if (!name || !cron) return res.status(400).json({ error: 'Missing fields' });
  try {
    const stmt = await req.db.run(
      'INSERT INTO tasks (name, cron, enabled) VALUES (?, ?, ?)',
      [name, cron, enabled]
    );
    const newTask = await req.db.get('SELECT * FROM tasks WHERE id = ?', stmt.lastID);
    res.status(201).json(newTask);
  } catch (e) {
    console.error(e);
    res.status(500).json({ error: 'Database error' });
  }
});

// PUT /tasks/:id – toggle enable flag
app.put('/tasks/:id', async (req, res) => {
  const { id } = req.params;
  const { enabled } = req.body;
  if (enabled === undefined) return res.status(400).json({ error: 'enabled required' });
  try {
    await req.db.run('UPDATE tasks SET enabled = ? WHERE id = ?', [enabled, id]);
    const updated = await req.db.get('SELECT * FROM tasks WHERE id = ?', id);
    res.json(updated);
  } catch (e) {
    console.error(e);
    res.status(500).json({ error: 'Database error' });
  }
});

// DELETE /tasks/:id – remove a task
app.delete('/tasks/:id', async (req, res) => {
  const { id } = req.params;
  try {
    await req.db.run('DELETE FROM tasks WHERE id = ?', id);
    res.status(204).end();
  } catch (e) {
    console.error(e);
    res.status(500).json({ error: 'Database error' });
  }
});

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => console.log(`API listening on http://localhost:${PORT}`));

The code is deliberately minimal: each request gets a reference to the same db instance via req.db. Because SQLite locks the file per write, the built‑in driver queues writes automatically – a convenient default for low‑traffic services.

Querying with node:sqlite

node:sqlite exposes three primary methods:

db.get(sql, params?) – returns a single row.
db.all(sql, params?) – returns an array of rows.
db.run(sql, params?) – executes a statement and returns metadata (lastID, changes). All of them return promises, so you can await them directly. The API feels like the older sqlite3 package but without the callback hell.

Error Handling & Validation

I keep validation lightweight – the service only checks for required fields and returns 400 when they’re missing. For production‑grade APIs you’d want a schema validator (e.g., zod or ajv).

All database errors are logged to the console and turned into a generic 500 response. This prevents leaking internal SQLite messages to callers while still giving me enough information in the logs to debug.

Running the Service

node index.js

The API is now reachable at http://localhost:3000. Because the database file lives on the same machine, you can back it up with a simple cp data/home.db backup/ script.

Deploying on My Home Server

I run the service inside a Docker container on a Raspberry Pi that also hosts my personal site. The Dockerfile is tiny:

FROM node:24-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "index.js"]

Building and running:

docker build -t home‑api .
docker run -d -p 3000:3000 --restart unless-stopped -v $(pwd)/data:/app/data home‑api

The volume mount ensures the SQLite file persists across container restarts.

Lessons Learned

SQLite is perfect for low‑volume services – the simplicity outweighs the lack of horizontal scaling.
node:sqlite removes a native‑module pain point – no need to compile sqlite3 binaries on every platform.
File‑based DB means backup is trivial – a single cp or rsync captures the whole state.
Be mindful of write contention – SQLite locks the whole file on write, so heavy concurrent writes can become a bottleneck. For my use‑case (a few dozen writes per hour) it’s not an issue.
Keep the DB close to the app – latency is essentially zero because the file is on the same filesystem.

If you’re building a small internal tool, a personal dashboard, or a home‑automation hub, this pattern lets you get a fully functional REST API up in under an hour.

I build sites and automations for small businesses at dreamfuturestech.com.

How I Keep My Site’s Chatbot Under a 9‑Second Serverless Timeout

the bomber — Fri, 30 Oct 2026 12:08:11 +0000

Overview

I run a personal automation server at home that powers the chatbot on my
Dream Futures Tech website. The serverless platform I use (Cloudflare
Workers) imposes a hard 9‑second execution limit, so every request has to
finish well before that deadline or the user sees a timeout error. This
article walks through the exact steps I took to keep the chatbot under
that limit while still delivering useful AI‑generated replies.

Choosing a Free Model

I wanted a model that is both free to run and small enough to fit in the
~50 MB memory budget of a Worker. After testing a few options locally I
settled on MiniLM‑Chat‑6B from Hugging Face, exported to the
ggml format and run with llama.cpp. The model loads in ~2 seconds and
generates a short answer in under 5 seconds on the free tier of
Cloudflare Workers KV.

Judgement: I chose this model because it balances quality and size.
More powerful models would exceed the timeout, while tiny models would
produce nonsensical replies.

Serverless Constraints

Cloudflare Workers give me:

9 seconds total CPU time per request
128 MB of memory
No persistent filesystem (only KV, Durable Objects, or in‑memory)

Because the model file lives in KV, I have to fetch it on the first
cold start and cache it in a global variable. Subsequent requests reuse
the cached instance, keeping the load time negligible.

The Handler Code

Below is the minimal worker.js that powers the endpoint
/api/chat. It shows model loading, timing, and a fallback path.

// worker.js
import { fetch } from 'undici';
import { Llama } from './llama.js'; // tiny wrapper around llama.cpp WASM

let model = null; // cached across requests
let modelReady = false;

// Load model from KV on first request
async function initModel() {
  if (modelReady) return;
  const kv = await MY_KV.get('minilm-chat-ggml.bin', { type: 'arrayBuffer' });
  model = await Llama.load(kv);
  modelReady = true;
}

// Simple timeout helper
function withTimeout(promise, ms) {
  return Promise.race([
    promise,
    new Promise((_, reject) =>
      setTimeout(() => reject(new Error('timeout')), ms)
    ),
  ]);
}

export default {
  async fetch(request) {
    const url = new URL(request.url);
    if (url.pathname !== '/api/chat') return new Response('Not found', { status: 404 });

    const { prompt } = await request.json();

    // Ensure model is ready
    await initModel();

    // Run inference with a safety margin (6 seconds)
    try {
      const start = Date.now();
      const answer = await withTimeout(
        model.generate(prompt, { maxTokens: 64 }),
        6000
      );
      const duration = Date.now() - start;
      return new Response(
        JSON.stringify({ answer, duration }),
        { headers: { 'Content-Type': 'application/json' } }
      );
    } catch (e) {
      // Fallback to rule‑based reply
      const fallback = simpleFallback(prompt);
      return new Response(
        JSON.stringify({ answer: fallback, fallback: true }),
        { headers: { 'Content-Type': 'application/json' } }
      );
    }
  },
};

function simpleFallback(text) {
  const lower = text.toLowerCase();
  if (lower.includes('price')) return 'Our pricing page is at /pricing.';
  if (lower.includes('hours')) return 'We are open 9 am‑5 pm EST, Monday‑Friday.';
  return "I'm sorry, I couldn't process that. Please try again or email support.";
}

Key Points

Global cache – model lives outside the request handler so the WASM instance stays warm.
withTimeout – caps the inference at 6 seconds, leaving 3 seconds for network overhead and response serialization.
Fallback – a deterministic, instant function that never exceeds the remaining time budget.

Timing the Inference

I added a small logging KV entry to see how long each generation took:

await MY_KV.put(`log-${Date.now()}`, JSON.stringify({ prompt, duration }));

During a week of real traffic the median duration was 4.2 seconds, well
under the 6‑second safety window. The 95th percentile never crossed 5.8 seconds,
so the fallback was rarely triggered.

Fallback Strategy

The fallback is deliberately simple: a few keyword checks and static
answers. Because it runs synchronously in JavaScript, it completes in
under 50 ms. If you need richer fallback content you can store canned
responses in KV and look them up by intent.

Deploying and Testing

Upload the model – wrangler kv:bulk put MY_KV minilm-chat-ggml.bin <path>
Publish – wrangler publish
Smoke test – curl -X POST https://my-site.workers.dev/api/chat -d '{"prompt":"What are your hours?"}' -H "Content-Type: application/json"

The response includes a duration field so you can monitor latency
directly from the client.

Lessons Learned

Cold starts matter. The first request after a deployment takes ~2.5 seconds to load the model. I mitigate this by pinging the endpoint from a cron job every 5 minutes.
Keep the prompt short. Longer prompts increase tokenisation time and push you closer to the timeout.
Never trust the model to finish. The withTimeout guard is essential; without it a runaway generation would cause the whole Worker to be terminated and the user would see a generic 504.

Conclusion

By combining a tiny free model, a global cache, a strict timeout wrapper,
and a deterministic fallback, I can reliably serve AI‑powered chat on a
platform that only gives me 9 seconds per request. The same pattern
works for any serverless environment with tight execution limits.

I build sites and automations for small businesses at dreamfuturestech.com.

Booking Calls from a Chatbot with Cal.com API v2 – Open Slots, Create, Cancel

the bomber — Thu, 29 Oct 2026 17:34:43 +0000

Booking Calls from a Chatbot with Cal.com API v2 – Open Slots, Create, Cancel

I built a tiny automation server at home that lets the chatbot on my Dream Futures Tech website schedule, confirm, and cancel phone calls on the fly. The whole flow runs on a Node.js micro‑service that talks to Cal.com’s v2 API. Below is the step‑by‑step code I use, plus a few practical tips for anyone who wants to replicate it for their own small‑business site.

1. Why Cal.com?

Self‑hosted – I can run the scheduler on my own server, keeping data under my control.
Simple REST API – v2 exposes endpoints for availability, bookings, and cancellations without needing a heavy SDK.
Free tier – Enough for a handful of daily appointments, which is perfect for a solo‑owner business.

2. Setting up the API client

I keep the client thin: a small wrapper around fetch that injects the API key and handles JSON conversion.

// apiClient.js – tiny wrapper for Cal.com v2
const BASE_URL = "https://api.cal.com/v2";
const API_KEY = process.env.CALCOM_API_KEY; // set in .env on my home server

export async function calRequest(path, method = "GET", body = null) {
  const headers = {
    "Content-Type": "application/json",
    Authorization: `Bearer ${API_KEY}`,
  };

  const opts = { method, headers };
  if (body) opts.body = JSON.stringify(body);

  const res = await fetch(`${BASE_URL}${path}`, opts);
  if (!res.ok) {
    const err = await res.text();
    throw new Error(`Cal.com error ${res.status}: ${err}`);
  }
  return res.json();
}

Tip: Store the API key in an environment variable and never commit it to Git. My home server runs Docker, so I inject the variable at container start.

3. Step 1 – Fetch open slots

The chatbot needs to know which times are free before it can suggest anything. Cal.com’s /availability endpoint returns a list of start/end timestamps for a given event type.

// getSlots.js – returns an array of human‑readable slots
import { calRequest } from "./apiClient.js";

export async function getOpenSlots(eventTypeId, daysAhead = 7) {
  const now = new Date().toISOString();
  const end = new Date();
  end.setDate(end.getDate() + daysAhead);

  const data = await calRequest(
    "/availability",
    "POST",
    {
      eventTypeId,
      start: now,
      end: end.toISOString(),
      // optional: limit to 30‑minute slots
      slotInterval: 30,
    }
  );

  // Transform to a simple string array for the chatbot UI
  return data.slots.map((s) => `${new Date(s.start).toLocaleString()} – ${new Date(s.end).toLocaleTimeString()}`);
}

When the chatbot receives a user request like “When can we talk?” I call getOpenSlots and feed the result back as quick‑reply buttons.

4. Step 2 – Create a booking

Once the user picks a slot, I need to turn that choice into a real booking. The /bookings endpoint creates the event and returns a confirmation URL.

// createBooking.js
import { calRequest } from "./apiClient.js";

export async function createBooking(eventTypeId, start, end, customer) {
  const payload = {
    eventTypeId,
    start,
    end,
    // Cal.com expects a "participants" array; I only need the lead here
    participants: [
      {
        email: customer.email,
        name: customer.name,
        // optional: custom fields like phone number
        customInputs: {
          phone: customer.phone,
        },
      },
    ],
  };

  const result = await calRequest("/bookings", "POST", payload);
  return {
    bookingId: result.id,
    confirmationUrl: result.confirmationUrl,
  };
}

The chatbot replies with a friendly message:

"Great, I’ve reserved 2 pm – 2:30 pm on Thursday. Click the link to add it to your calendar: "

I also store bookingId in a tiny SQLite table keyed to the user’s chat ID. That makes cancellation easy later.

5. Step 3 – Cancel a booking

If the prospect says “Can we move that?” I look up the stored bookingId and call the delete endpoint.

// cancelBooking.js
import { calRequest } from "./apiClient.js";

export async function cancelBooking(bookingId) {
  await calRequest(`/bookings/${bookingId}`, "DELETE");
  return true;
}

After the call succeeds I clear the row from SQLite and let the chatbot suggest new slots.

6. Wiring it into the chatbot flow

My site uses Botpress for the conversational UI, but the same ideas apply to Dialogflow, Rasa, or a custom React chat widget.

// botHandler.js – pseudo‑code for the three intents
import { getOpenSlots } from "./getSlots.js";
import { createBooking } from "./createBooking.js";
import { cancelBooking } from "./cancelBooking.js";
import db from "./db.js"; // tiny wrapper around SQLite

// 1⃣ User asks for availability
async function handleAvailability(ctx) {
  const slots = await getOpenSlots("my-event-type-id");
  ctx.reply("Here are the next open times:", { quickReplies: slots });
}

// 2⃣ User selects a slot
async function handleSlotSelection(ctx, slotString) {
  const [startStr, endStr] = slotString.split(" – ");
  const customer = {
    name: ctx.user.name,
    email: ctx.user.email,
    phone: ctx.user.phone,
  };
  const { bookingId, confirmationUrl } = await createBooking(
    "my-event-type-id",
    new Date(startStr).toISOString(),
    new Date(endStr).toISOString(),
    customer
  );
  await db.run("INSERT INTO bookings (chatId, bookingId) VALUES (?, ?)", [ctx.chatId, bookingId]);
  ctx.reply(`All set! Confirm here: ${confirmationUrl}`);
}

// 3⃣ User wants to cancel
async function handleCancel(ctx) {
  const row = await db.get("SELECT bookingId FROM bookings WHERE chatId = ?", [ctx.chatId]);
  if (!row) return ctx.reply("I don’t see any upcoming appointment to cancel.");
  await cancelBooking(row.bookingId);
  await db.run("DELETE FROM bookings WHERE chatId = ?", [ctx.chatId]);
  ctx.reply("Your appointment has been cancelled. Let me know when you’d like to reschedule.");
}

The three intent handlers cover the entire lifecycle. Because each step is a single HTTP request, the latency is under a second on my home broadband, which feels instant to the visitor.

7. Security & rate‑limiting considerations

Validate input – The slot string comes from the chatbot UI; I always parse it back to ISO timestamps before sending to Cal.com.
Rate limit – I wrap calRequest with a tiny token bucket (max 5 requests/second) to avoid hitting Cal.com’s soft limits.
Webhook verification – Cal.com can POST to /webhooks/booking when a meeting is rescheduled or cancelled by the host. I verify the signature header before processing.

8. Deploying on my home server

I run the service in a Docker container on a Raspberry Pi 4. The Dockerfile is a one‑liner:

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
CMD ["node", "server.js"]

server.js just mounts an Express router that exposes /chatbot for Botpress to call. The container restarts automatically via docker-compose if the Pi reboots.

9. Takeaway

Using Cal.com’s v2 API lets a small business turn a generic chatbot into a real appointment‑scheduling assistant with just three HTTP calls: fetch availability → create booking → cancel if needed. The code stays under 150 lines, runs on inexpensive hardware, and gives prospects a frictionless way to lock in a call.

I build sites and automations for small businesses at dreamfuturestech.com.

Building a Lean Blog CMS in Next.js 14 and Prisma with ISR

the bomber — Tue, 27 Oct 2026 18:46:11 +0000

Why Build a Custom CMS?

Hi, I am Kaleb. I run Dream Futures Tech out of Pompano Beach, Florida. When I was rebuilding my own business website, I needed a straightforward blog publishing workflow. I did not want a heavy headless CMS subscription or a bloated monolith database setup. I already run a small automation server at home, and I host my main site on standard infrastructure. What I wanted was simple: write drafts, hit publish, and have the static pages update instantly without rebuilding the entire site from scratch every time.

To solve this, I built a lightweight blog content management system directly into my Next.js 14 application using Prisma and SQLite. It keeps things contained, fast, and entirely under my control. In my judgment, writing your own lightweight CMS for a simple business blog takes less time than configuring a third-party service once you factor in authentication and API keys.

The Prisma Schema for Posts and Drafts

Everything starts with the database schema. I use Prisma because the type safety prevents entire classes of silly bugs when moving data from form inputs to the database. Here is the core model I use for my blog posts:

model Post {
  id        String   @id @default(cuid())
  title     String
  slug      String   @unique
  content   String
  published Boolean  @default(false)
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}

The published boolean is the gatekeeper. When I query the database for public-facing routes, I strictly filter by published: true. In the admin dashboard route, I fetch all records so I can view, edit, and delete my working drafts.

Handling Drafts in the UI

Separating drafts from published posts on the frontend is straightforward with Next.js App Router. My public route uses a simple Prisma query:

// app/blog/page.tsx
import { db } from '@/lib/db';

export default async function BlogIndex() {
  const posts = await db.post.findMany({
    where: { published: true },
    orderBy: { createdAt: 'desc' },
  });

  return (
    <div>
      {posts.map(post => (
        <article key={post.id}>
          <h2>{post.slug}</h2>
          <p>{post.title}</p>
        </article>
      ))}
    </div>
  );
}

For the admin side, I built a protected route that lists both drafts and published entries, allowing me to iterate on formatting and copy before pushing it live to the world.

Incremental Static Regeneration and RevalidatePath

Next.js 14 provides powerful caching mechanisms, but stale static pages can be frustrating when you are trying to publish a new article. I wanted the performance of static generation combined with instant updates upon publishing.

I used Incremental Static Regeneration (ISR) combined with Next.js Server Actions to handle this. When I update a post's status to published in the admin panel, the Server Action updates the database and immediately calls revalidatePath.

Here is what that Server Action looks like in practice:

// app/admin/actions.ts
'use server';

import { db } from '@/lib/db';
import { revalidatePath } from 'next/cache';

export async function togglePublish(id: string, currentStatus: boolean) {
  await db.post.update({
    where: { id },
    data: { published: !currentStatus },
  });

  // Invalidate the public blog index and the specific post route
  revalidatePath('/blog');
  revalidatePath(`/blog/[slug]`, 'page');
}

When togglePublish runs, Next.js clears the cache for those specific paths in the background. The next time a visitor requests the blog index or the specific article, they get the freshly generated static page without waiting for a full manual deployment.

Keeping It Maintainable

Building this internal tool directly into my Next.js codebase saved me from managing external API tokens, webhooks, and third-party dashboard limits. SQLite handles the data cleanly on my hosting provider, and the codebase remains small enough that I can audit every line myself. If you are managing a small business site and want total control over your publishing pipeline without adding unnecessary infrastructure overhead, combining Next.js App Router, Prisma, and revalidatePath is a reliable path forward.

I build sites and automations for small businesses at dreamfuturestech.com.

Connecting a Netlify Function to a Home Server via a Dynamic Cloudflare Tunnel

the bomber — Tue, 27 Oct 2026 12:06:43 +0000

Introduction

I run a small automation server at home that powers a few cron jobs and a private API for my own website. The site lives on Netlify, which gives me serverless functions for things like contact‑form handling. The challenge was: how do I call my home server from a Netlify function when the tunnel address changes every time I restart it?

In this post I walk through the exact steps I took, the code I wrote, and the pitfalls I hit along the way. Everything here is what I actually use for Dream Futures Tech – no fictional benchmarks or client data.

Why Netlify + Cloudflare Tunnel?

Netlify handles static assets and serverless functions with zero‑ops deployment. My home server runs on a modest Raspberry Pi, so exposing it directly to the internet would require port forwarding and a static IP – both of which I prefer to avoid for security and reliability reasons.

Cloudflare Tunnel (formerly Argo Tunnel) creates a secure outbound connection from my Pi to Cloudflare’s edge network. Cloudflare then provides a public hostname (e.g., myhome.example.com) that forwards traffic back through the tunnel. The tunnel can be started with cloudflared, a lightweight binary.

The snag: each time I restart the tunnel, Cloudflare may assign a new sub‑domain unless I reserve a custom hostname. I wanted a solution that works with the free tier, so I let Cloudflare generate the hostname and then discover it programmatically from my Netlify function.

Setting Up the Cloudflare Tunnel

On the Pi I installed cloudflared and created a configuration file that runs the tunnel as a background service.

# /home/pi/.cloudflared/config.yml
url: http://localhost:3000   # my internal API
# No hostname – let Cloudflare assign one
logfile: /var/log/cloudflared.log
loglevel: info

I start it with:

cloudflared tunnel run myhome-tunnel &

The process writes a line like:

2023-09-01T12:34:56Z INF Starting tunnel myhome-tunnel
2023-09-01T12:34:56Z INF Tunnel URL: https://random-12345.trycloudflare.com

That URL is the address I need to call from Netlify.

Discovering the Dynamic Tunnel URL

Instead of parsing the log file (which can be flaky), I use Cloudflare’s API to list active tunnels and pull the public URL.

API Token

I created a token with the Zone:Read and Tunnel:Read permissions scoped to my account. The token lives in Netlify’s environment variables as CLOUDFLARE_TOKEN.

Helper Script (optional)

Locally I wrote a tiny Node script to verify the API call:

// scripts/get-tunnel-url.js
const fetch = require('node-fetch');
const token = process.env.CLOUDFLARE_TOKEN;

(async () => {
  const res = await fetch('https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/cfd_tunnel', {
    headers: { Authorization: `Bearer ${token}` },
  });
  const data = await res.json();
  const tunnel = data.result.find(t => t.name === 'myhome-tunnel');
  console.log(tunnel?.tunnel_url);
})();

Running this prints the current public URL, e.g., https://random-12345.trycloudflare.com.

Netlify Function that Calls the Home Server

The function lives in netlify/functions/ping-home.js. It does three things:

Fetch the tunnel URL from Cloudflare’s API.
Append the path I want to hit on the home server (/status).
Proxy the response back to the client.

// netlify/functions/ping-home.js
const fetch = require('node-fetch');

exports.handler = async function(event, context) {
  const token = process.env.CLOUDFLARE_TOKEN;
  const accountId = process.env.CLOUDFLARE_ACCOUNT_ID;

  // 1⃣ Get the tunnel URL
  const tunnelRes = await fetch(
    `https://api.cloudflare.com/client/v4/accounts/${accountId}/cfd_tunnel`,
    { headers: { Authorization: `Bearer ${token}` } }
  );
  const tunnelData = await tunnelRes.json();
  const tunnel = tunnelData.result.find(t => t.name === 'myhome-tunnel');

  if (!tunnel) {
    return { statusCode: 502, body: 'Tunnel not found' };
  }

  const homeUrl = `${tunnel.tunnel_url}/status`;

  // 2⃣ Call the home server
  const homeRes = await fetch(homeUrl);
  const body = await homeRes.text();

  // 3⃣ Return the result
  return {
    statusCode: homeRes.status,
    headers: { 'Content-Type': homeRes.headers.get('content-type') || 'text/plain' },
    body,
  };
};

Important notes:

The function runs on Netlify’s edge, so the outbound request must be over HTTPS. Cloudflare’s tunnel URL is always HTTPS, which satisfies that.
I keep the token and account ID in Netlify’s UI under Site Settings → Build & Deploy → Environment. Never commit them to source control.

Handling Tunnel Restarts

Because the tunnel URL can change, the function always queries Cloudflare at runtime. That adds a few milliseconds of latency, but the overhead is negligible for my use case (a simple health‑check endpoint). If the latency ever becomes a concern, I could cache the URL in Netlify’s Edge Functions KV store for a short period (e.g., 30 seconds).

Testing the End‑to‑End Flow

Deploy the Netlify site (netlify deploy --prod).
Hit https://my-site.netlify.app/.netlify/functions/ping-home in a browser or with curl.
You should see the JSON payload returned by the home server’s /status route.

If the tunnel is down, the function returns a 502 with the message “Tunnel not found”. This makes it easy to set up alerts in Netlify’s monitoring UI.

Lessons Learned

Never rely on a static tunnel URL when using the free Cloudflare tier. The API is the reliable source of truth.
Environment variables are your friend – keep secrets out of the repo and rotate them periodically.
Graceful error handling matters. A missing tunnel should surface as a clear HTTP status rather than a generic 500.
Keep the home server lightweight. My Pi only runs a Node/Express app on port 3000, which is more than enough for the occasional webhook or status check.

Conclusion

By combining Netlify’s serverless functions with Cloudflare Tunnel’s dynamic public endpoint, I now have a secure, low‑maintenance bridge from my static site to a private home automation server. The pattern works for any scenario where you need to call a self‑hosted service from a cloud function without exposing a permanent public IP.

I build sites and automations for small businesses at dreamfuturestech.com.

Signing Netlify Webhooks with HMAC and Timestamps for a Home Automation Server

the bomber — Sat, 24 Oct 2026 12:08:41 +0000

Why I Signed My Netlify Webhooks

When I moved my personal site to Netlify I also wanted the same deployment to trigger a few home‑automation scripts that run on a Raspberry Pi in my garage. A simple HTTP POST would work, but anyone who discovers the endpoint could fire my scripts at will. The solution I settled on is a classic HMAC signature plus a short‑lived timestamp. It’s cheap, stateless, and works well with the serverless functions Netlify provides.

The Core Idea

Shared secret – a random string known only to the Netlify site and my home server.
HMAC‑SHA256 – the payload (or a deterministic string) is signed with the secret.
Timestamp – added to the request and validated to prevent replay attacks.

When the request arrives, the server recomputes the HMAC and compares it to the header. If they match and the timestamp is within an acceptable window (I use 5 minutes) the request is accepted.

Generating a Secure Secret

I keep the secret in Netlify’s UI under Site Settings → Build & Deploy → Environment. The same value lives in a .env file on my home server.

# Generate a 32‑byte base64 secret
openssl rand -base64 32

Copy the output (e.g. k3J9vZc2Yb7R9uW8e1Lh5QpX0sTgZ1aM) to both places. Never commit it to source control.

Netlify Function: Sending the Signed Webhook

Netlify lets you write a small function that runs after a successful build. I placed this in netlify/functions/trigger‑automation.js.

// netlify/functions/trigger-automation.js
const crypto = require('crypto');

exports.handler = async (event, context) => {
  const secret = process.env.HOOK_SECRET; // set in Netlify UI
  const payload = JSON.stringify({
    site: context.site.name,
    version: context.deploy.id,
    timestamp: Date.now()
  });

  // Create HMAC signature
  const hmac = crypto.createHmac('sha256', secret)
                   .update(payload)
                   .digest('hex');

  const response = await fetch('https://my‑home‑server.local/webhook', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'X-Signature': hmac,
      'X-Timestamp': Date.now().toString()
    },
    body: payload
  });

  if (!response.ok) {
    console.error('Webhook failed', await response.text());
    return { statusCode: 500, body: 'Webhook error' };
  }

  return { statusCode: 200, body: 'Webhook sent' };
};

A few notes:

I include the timestamp both in the JSON body and as a header. The header is what the server checks first because it’s cheap to read.
Netlify automatically bundles the function with the rest of the site, so no extra deployment step is needed.

Home Server: Verifying the Request

On the Raspberry Pi I run a tiny Express app that listens for /webhook. The verification logic is deliberately simple.

// server/webhook.js
require('dotenv').config();
const express = require('express');
const crypto = require('crypto');

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

const SECRET = process.env.HOOK_SECRET; // same value as Netlify
const MAX_AGE_MS = 5 * 60 * 1000; // 5 minutes

function verifySignature(req) {
  const signature = req.header('X-Signature');
  const timestamp = req.header('X-Timestamp');

  if (!signature || !timestamp) return false;

  const now = Date.now();
  const ts = Number(timestamp);
  if (isNaN(ts) || Math.abs(now - ts) > MAX_AGE_MS) return false; // replay protection

  const payload = JSON.stringify(req.body);
  const expected = crypto.createHmac('sha256', SECRET)
                         .update(payload)
                         .digest('hex');

  // Use timing‑safe compare to avoid side‑channel attacks
  return crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected));
}

app.post('/webhook', (req, res) => {
  if (!verifySignature(req)) {
    return res.status(401).send('Invalid signature or timestamp');
  }

  // At this point the request is trusted – run my automation
  console.log(' Verified webhook from Netlify', req.body);
  // Example: restart a Docker container, pull a repo, etc.
  // execSync('docker restart my‑service');

  res.send('OK');
});

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => console.log(`Webhook listener on ${PORT}`));

Why the Checks Matter

Timestamp window – Without it an attacker could capture a valid request and replay it later. Five minutes is a balance between network latency and security for my use case.
Timing‑safe compare – crypto.timingSafeEqual prevents subtle timing attacks that could leak the secret.
JSON stringification – Both sides must sign the exact same string. I deliberately stringify the body after Express parses it, ensuring whitespace differences don’t break the signature.

Deploying the Home Server

I keep the server code in a private Git repo on the Pi. A simple systemd service starts the Node process on boot:

# /etc/systemd/system/webhook.service
[Unit]
Description=Netlify webhook listener
After=network.target

[Service]
EnvironmentFile=/home/pi/.env
WorkingDirectory=/home/pi/webhook
ExecStart=/usr/bin/node webhook.js
Restart=on-failure

[Install]
WantedBy=multi-user.target

After sudo systemctl daemon-reload && sudo systemctl enable --now webhook, the endpoint is reachable at https://my‑home‑server.local/webhook (I terminate TLS with a self‑signed cert and let Netlify ignore the verification because the request is outbound).

Testing the Flow

I wrote a tiny script to simulate a request and verify that the server rejects malformed signatures.

node - <<'EOF'
const fetch = require('node-fetch');
const crypto = require('crypto');
const secret = 'k3J9vZc2Yb7R9uW8e1Lh5QpX0sTgZ1aM';
const payload = JSON.stringify({test: true, timestamp: Date.now()});
const sig = crypto.createHmac('sha256', secret).update(payload).digest('hex');
fetch('https://my-home-server.local/webhook', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-Signature': sig,
    'X-Timestamp': Date.now().toString()
  },
  body: payload,
  rejectUnauthorized: false // because of self‑signed cert
}).then(r => r.text().then(t => console.log(r.status, t)));
EOF

If the server logs Verified webhook from Netlify and returns 200 OK, the pipeline is good.

Things I Learned Along the Way

Never rely on IP filtering alone – My home network’s public IP changes occasionally; HMAC is far more reliable.
Keep the secret truly secret – I store it in Netlify’s encrypted environment and on the Pi’s .env. Accidentally committing it would break the whole model.
Replay windows are a trade‑off – Shorter windows increase security but can cause false negatives on very slow connections. Five minutes works for my broadband.
Self‑signed TLS is fine for outbound calls – Netlify’s function doesn’t validate the cert, but the server still encrypts the payload on the wire.

Wrapping Up

Signing webhooks with HMAC and a timestamp gave me a lightweight, auditable way to let my Netlify site trigger home‑automation tasks without exposing an open endpoint. The code is only a few dozen lines, runs on any Node‑compatible host, and can be adapted to other platforms (Python, Go, etc.) with the same principles.

I build sites and automations for small businesses at dreamfuturestech.com.

Turning spoken commands into safe actions: regex first, the language model second

the bomber — Fri, 23 Oct 2026 23:51:35 +0000

Introduction

I built a tiny voice‑controlled home automation server for my own website. The goal was simple: speak a command, have the server execute a safe action (turn a light on, start a backup, etc.). The tricky part is making sure the spoken text can’t be turned into an arbitrary shell command. My solution is a two‑step filter – a strict regular‑expression whitelist first, then a language‑model (LLM) to fill in the details.

Why regex first?

Regular expressions give me a deterministic gate. Anything that doesn’t match a known pattern is rejected before it ever reaches the LLM. This prevents prompt injection attacks where a user tries to sneak a malicious instruction into the natural‑language prompt. In my experience the overhead of a few regex checks is negligible compared to the round‑trip to the OpenAI API.

Designing the command grammar

I started by listing the actions I actually want to expose:

light <room> on|off
backup now
status <service>

From that list I wrote a single regex that captures the intent and the arguments:

// commandRegex.js
export const commandRegex = /^(light)\s+(living|kitchen|bedroom)\s+(on|off)$|^(backup)\s+now$|^(status)\s+(nginx|postgres)$/i;

The pattern is deliberately simple – each branch matches one of the allowed commands. If a spoken phrase doesn’t match, the request is dropped with a 400 response.

Hooking up the speech recognizer

On the client side I use the Web Speech API because it works in Chrome without any extra libraries. The recognizer sends the raw transcript to my Node server via a POST request.

// public/voice.js
const btn = document.getElementById('talk');
const recognition = new (window.SpeechRecognition || window.webkitSpeechRecognition)();
recognition.lang = 'en-US';
recognition.interimResults = false;

btn.onclick = () => recognition.start();

recognition.onresult = e => {
  const transcript = e.results[0][0].transcript.trim();
  fetch('/api/command', {
    method: 'POST',
    headers: {'Content-Type': 'application/json'},
    body: JSON.stringify({text: transcript})
  })
  .then(r => r.json())
  .then(console.log);
};

The server receives {"text":"light kitchen on"} and runs it through the regex.

Using a language model for intent

Once the regex validates the shape, I still need to translate the captured groups into concrete parameters (e.g., which GPIO pin controls the kitchen light). I keep that mapping in a JSON file and ask the LLM to produce the final command string. The prompt is static and never includes user‑provided text directly.

// intentResolver.js
import {Configuration, OpenAIApi} from 'openai';
import {commandRegex} from './commandRegex.js';
import pinMap from './pinMap.json';

const openai = new OpenAIApi(new Configuration({apiKey: process.env.OPENAI_API_KEY}));

export async function resolveIntent(rawText) {
  const match = rawText.match(commandRegex);
  if (!match) throw new Error('Invalid command');

  // Extract intent and args from the regex groups
  const [_, intent, room, state, backup, statusService] = match;

  // Build a deterministic prompt – no user text interpolation
  const prompt = `You are a helper that converts structured intent data into a shell command.
Intent: ${intent || backup || statusService}
Parameters: ${JSON.stringify({room, state, service: statusService})}
Return only the command, nothing else.`;

  const response = await openai.createChatCompletion({
    model: 'gpt-4o-mini',
    messages: [{role: 'user', content: prompt}],
    temperature: 0,
  });

  const command = response.data.choices[0].message.content.trim();
  return command;
}

Because the prompt never contains the raw transcript, the LLM cannot be tricked into echoing back malicious text. The only variable data it sees are the intent name and a sanitized JSON object.

Safety checks

Even after the LLM returns a command, I run a final whitelist of allowed shell snippets. This is a second line of defense in case the model hallucinates.

// safeCommands.js
export const safeCommands = [
  /^gpio write \d+ (1|0)$/,   // turn a pin on/off
  /^rsync -avz .* backup$/,    // run a backup
  /^systemctl status (nginx|postgres)$/
];

export function isSafe(cmd) {
  return safeCommands.some(rx => rx.test(cmd));
}

If isSafe returns false, the request is logged and rejected.

Putting it together

The Express route ties all pieces together:

// server.js
import express from 'express';
import {resolveIntent} from './intentResolver.js';
import {isSafe} from './safeCommands.js';
import {exec} from 'child_process';

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

app.post('/api/command', async (req, res) => {
  const {text} = req.body;
  try {
    const cmd = await resolveIntent(text);
    if (!isSafe(cmd)) throw new Error('Command failed safety check');
    exec(cmd, (err, stdout, stderr) => {
      if (err) return res.status(500).json({error: err.message});
      res.json({output: stdout || stderr});
    });
  } catch (e) {
    console.error(e);
    res.status(400).json({error: e.message});
  }
});

app.listen(3000, () => console.log('Voice command server listening on :3000'));

All the heavy lifting is deterministic: regex → intent → LLM prompt → safety whitelist → exec.

Deployment considerations

I run this server on a Raspberry Pi at home, but the same code works on any Linux box. A few practical tips:

Environment isolation – use a systemd service that runs the Node process as a non‑root user.
Rate limiting – the Web Speech API can be noisy; a simple token bucket middleware prevents abuse.
Logging – store the raw transcript, the resolved command, and the safety check result. This makes debugging prompt‑injection attempts easier.
Model cost – because the prompt is tiny and temperature is 0, the cost per request is a few fractions of a cent.

Conclusion

By front‑loading a strict regex filter, I keep the attack surface small enough that the LLM can be used safely for natural‑language expansion. The pattern works for any limited command set: define a grammar, whitelist the resulting shell, and let the model fill in the boring details. I’ve been running this for months with no false positives, and the approach scales nicely when I add new devices – just extend the regex and the safe‑command list.

I build sites and automations for small businesses at dreamfuturestech.com.

Adding Local JSON‑LD Structured Data to Your Small Business Site

the bomber — Fri, 23 Oct 2026 14:57:41 +0000

Why structured data matters for a Pompano Beach trade

When I refreshed the Dream Futures Tech website last summer, the first thing I added was a few lines of JSON‑LD. In Pompano Beach, a lot of customers find local services through Google’s “local pack.” Those results are powered by structured data. Adding the right snippets tells Google who we are, where we operate, and how our pages relate to each other – all without changing the visual design of the site.

Step 1: Organization markup

The Organization block is the foundation. It gives search engines the business name, address, phone, and a link to the logo. I keep it in the <head> so it loads with every page.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Dream Futures Tech",
  "url": "https://dreamfuturestech.com",
  "logo": "https://dreamfuturestech.com/logo.png",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main St",
    "addressLocality": "Pompano Beach",
    "addressRegion": "FL",
    "postalCode": "33060",
    "addressCountry": "US"
  },
  "contactPoint": [{
    "@type": "ContactPoint",
    "telephone": "+1-954-555-0123",
    "contactType": "customer service",
    "areaServed": "US"
  }]
}
</script>

Step 2: WebSite markup

Google uses the WebSite object to surface a “search box” directly in the results. The only thing you need is the site URL and an potentialAction that points to your internal search page (if you have one). If you don’t have a search page, you can still add the block – it won’t hurt.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "url": "https://dreamfuturestech.com",
  "name": "Dream Futures Tech",
  "potentialAction": {
    "@type": "SearchAction",
    "target": "https://dreamfuturestech.com/?s={search_term_string}",
    "query-input": "required name=search_term_string"
  }
}
</script>

Step 3: BreadcrumbList & BlogPosting

Breadcrumbs help Google display a clear navigation trail in the SERP. I add a tiny BreadcrumbList on every page that lives deeper than the home page. For blog posts, I combine it with a BlogPosting block so the article’s headline, author, and publish date appear in rich results.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {"@type": "ListItem", "position": 1, "name": "Home", "item": "https://dreamfuturestech.com"},
    {"@type": "ListItem", "position": 2, "name": "Blog", "item": "https://dreamfuturestech.com/blog"},
    {"@type": "ListItem", "position": 3, "name": "How to Automate Invoicing", "item": "https://dreamfuturestech.com/blog/automate-invoicing"}
  ]
}
</script>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to Automate Invoicing for Small Businesses",
  "author": {"@type": "Person", "name": "Kaleb"},
  "datePublished": "2024-09-15",
  "image": "https://dreamfuturestech.com/images/invoice-automation.png",
  "url": "https://dreamfuturestech.com/blog/automate-invoicing",
  "publisher": {"@type": "Organization", "name": "Dream Futures Tech"}
}
</script>

Quick checklist

Organization: name, URL, logo, address, phone – one block, placed in the <head> of every page.
WebSite: URL + optional SearchAction – also in the <head>.
BreadcrumbList: add on any page that isn’t the homepage; keep the position numbers sequential.
BlogPosting (or Article for news): include headline, author, date, image, and publisher.
Validate with Google’s Rich Results Test after each change.

Wrap‑up

I rolled these snippets out over a single weekend. The site kept its look, but within a few weeks Google started showing a “Local Business” card and breadcrumb trails for my blog posts. For any Pompano Beach trade—whether you’re a plumber, a landscaper, or a web‑dev like me—adding these three JSON‑LD blocks is a low‑effort way to make sure search engines understand exactly who you are and where you serve.

I build sites and automations for small businesses at dreamfuturestech.com.

Building a Postgres-Backed Rate Limiter for Public Netlify Functions

the bomber — Thu, 22 Oct 2026 18:55:22 +0000

I am Kaleb, a web developer running Dream Futures Tech right out of Pompano Beach, Florida. Recently, I added a public chat widget to my own business website to let visitors drop quick questions. Because the endpoint lives on a Netlify serverless function, it is completely open to the public internet. Within a few days of deploying it, I noticed automated script traffic trying to hammer the endpoint. I needed a reliable rate limiter without paying for expensive third-party edge security tiers.

Netlify Functions are great for hosting lightweight APIs, but they are stateless and spin down when idle. Relying on an in-memory cache inside the function container does not work because the container instances scale up, down, and across regions. Since my site already connects to a managed PostgreSQL database for internal tools and logging, using Postgres as a shared counter store felt like the most straightforward path.

Why Postgres Over Edge KV

I considered using Redis or edge-specific key-value stores, but my architecture already relies on a standard Postgres instance running on a small virtual private server at home. Adding another dependency felt like unnecessary overhead. In my judgment, the millisecond latency hit of querying Postgres over a TLS connection is entirely acceptable for a low-traffic business site, and it keeps my infrastructure footprint small and auditable.

The core logic is simple: track requests by client IP address within a rolling time window. If an IP exceeds, say, ten requests in a sixty-second span, the function rejects subsequent requests with a 429 status code.

Setting Up the Rate Limit Schema

I created a single table in Postgres dedicated to tracking these windows. It stores the client IP, a request count integer, and a timestamp marking the start of the current window.

CREATE TABLE rate_limits (
    client_ip VARCHAR(45) PRIMARY KEY,
    count INT NOT NULL,
    window_start TIMESTAMPTZ NOT NULL
);

When a request hits the Netlify function, the code extracts the client IP, checks this table, and either increments the counter or resets it if the window has expired.

The Netlify Function Implementation

Here is the actual JavaScript code running on my Netlify function. It uses the pg library to connect to the database. Notice how the SELECT query cleanly retrieves the existing rate limit record without any stray characters.

const { Client } = require('pg');

exports.handler = async function(event, context) {
    if (event.httpMethod !== 'POST') {
        return { statusCode: 405, body: 'Method Not Allowed' };
    }

    const clientIp = event.headers['x-nf-client-connection-ip'] || 'unknown';
    const now = new Date();
    const windowSizeMs = 60 * 1000; // 1 minute
    const maxRequests = 10;

    const client = new Client({
        connectionString: process.env.DATABASE_URL,
        ssl: { rejectUnauthorized: false }
    });

    try {
        await client.connect();

        const res = await client.query(
            'SELECT count, window_start FROM rate_limits WHERE client_ip = $1',
            [clientIp]
        );

        if (res.rows.length === 0) {
            await client.query(
                'INSERT INTO rate_limits (client_ip, count, window_start) VALUES ($1, 1, $2)',
                [clientIp, now]
            );
        } else {
            const row = res.rows[0];
            const windowStart = new Date(row.window_start);

            if (now - windowStart > windowSizeMs) {
                await client.query(
                    'UPDATE rate_limits SET count = 1, window_start = $1 WHERE client_ip = $2',
                    [now, clientIp]
                );
            } else if (row.count >= maxRequests) {
                await client.end();
                return {
                    statusCode: 429,
                    body: JSON.stringify({ error: 'Too many requests. Please wait a minute.' })
                };
            } else {
                await client.query(
                    'UPDATE rate_limits SET count = count + 1 WHERE client_ip = $1',
                    [clientIp]
                );
            }
        }

        await client.end();

        // Proceed with handling the chat message...
        return {
            statusCode: 200,
            body: JSON.stringify({ success: true, message: 'Message received' })
        };

    } catch (err) {
        console.error('Rate limit error:', err);
        await client.end();
        return {
            statusCode: 500,
            body: JSON.stringify({ error: 'Internal Server Error' })
        };
    }
};

Handling Failures Gracefully

One risk of tying database operations directly to an HTTP API endpoint is database availability. If my home server drops offline, I do not want my entire public contact form or chat widget to break completely for legitimate users.

In my production setup, I wrap the database connection attempt in a try/catch block that fails open. If the Postgres query throws a timeout or connection error, the function logs the error to Netlify's console but allows the chat message to pass through. For my own business site, availability trumps strict rate-limiting enforcement during a rare infrastructure blip.

Maintaining this setup takes very little effort. Over the last few months, it has successfully blocked several automated form-spam scripts without requiring any complex cloud-native security products.

I build sites and automations for small businesses at dreamfuturestech.com.

Automating Local SEO Tracking with PipeWire and Tesseract OCR

the bomber — Thu, 22 Oct 2026 12:20:29 +0000

Why Track Local Map Rankings Visually

Running a local service website in Palm Beach County means your visibility in local search results dictates your pipeline. Traditional SEO rank trackers often miss hyper-local shifts or get blocked by anti-bot measures when checking map pack positions for specific neighborhoods from a data center IP.

At Dream Futures Tech in Pompano Beach, I run my own local SEO dashboards and automation scripts on a Linux server at home. Instead of paying for expensive enterprise rank-tracking APIs that frequently fail, I built a lightweight local monitor. It opens a browser, captures the screen using PipeWire, and uses Tesseract OCR to read my business's position and competitor names directly from the rendered pixels.

In my judgment, relying on visual screen captures for localized data is slower than an API, but it is entirely immune to API deprecations and accurately reflects what a real user sees on a browser screen.

Capturing the Screen via PipeWire

On modern Linux desktops running Wayland, capturing the screen securely requires PipeWire. While desktop environments offer GUI prompts for screen sharing, an automation server needs a headless or scripted approach. I use pw-cat and related PipeWire utilities alongside a lightweight browser instance to grab exact viewport frames.

First, make sure you have the necessary system packages installed:

sudo apt install tesseract-ocr pipewire pipewire-bin python3-pip
pip install pytesseract pillow

When the automation script triggers a browser window to query local search results, it targets a specific window ID or desktop region. For simplicity in my home server setup, I capture a designated region of the framebuffer where the map results render.

Extracting Text with Tesseract OCR

Once the image is saved to disk by the capture routine, Tesseract processes the image to pull out the text. Local maps use varying fonts and map overlays that can confuse naive OCR setups. To get reliable reads, preprocessing the image with Python's Pillow library helps immensely.

Here is a snippet of the core OCR function I use to parse the captured screenshot:

import pytesseract
from PIL import Image, ImageOps

def extract_rankings(image_path):
    # Open the captured screen region
    img = Image.open(image_path)

    # Convert to grayscale and increase contrast
    gray = ImageOps.grayscale(img)
    contrast = ImageOps.autocontrast(gray, cutoff=2)

    # Run Tesseract with custom config for single blocks of text
    custom_config = r'--oem 3 --psm 6'
    text = pytesseract.image_to_string(contrast, config=custom_config)

    return text

# Example usage
results = extract_rankings('/tmp/map_capture.png')
print(results)

In practice, Tesseract handles clean sans-serif UI fonts quite well, provided the scaling factor of your browser zoom is consistent across runs.

Putting It All Together in a Python Script

To automate the full check, the script orchestrates the browser launch, waits for the map render to complete, triggers the PipeWire snapshot, and runs the OCR parser. If my business name appears in the extracted text block, it logs the vertical coordinate offset to determine the exact rank position.

import subprocess
import time

def capture_and_read():
    # Trigger browser or use existing session
    # Capture screen region using PipeWire-backed tool
    subprocess.run([
        "grim", "-g", "100,200 800,600", "/tmp/map_capture.png"
    ])

    # Parse text
    extracted_text = extract_rankings('/tmp/map_capture.png')

    if "Dream Futures Tech" in extracted_text:
        print("Business found in current viewport.")
    else:
        print("Business not found in immediate view; checking scroll bounds.")

if __name__ == "__main__":
    capture_and_read()

This setup runs locally on my hardware without leaking telemetry or incurring monthly SaaS fees. It gives me honest, ground-truth data on how local service searches render right here in South Florida.

I build sites and automations for small businesses at dreamfuturestech.com.

DEV Community: the bomber

Desktop Automation on GNOME Wayland without Root: Using Mutter RemoteDesktop and ScreenCast over D‑Bus

Introduction

Prerequisites

Getting a Session Bus Connection

Requesting a Screencast

Injecting Input via RemoteDesktop

Moving the Pointer

Typing Text

Putting It All Together

Running as a Systemd User Service

Security Considerations

Conclusion

Filtering Freelance Leads: Recency Windows and Job‑Board Rules in My Home‑Hosted Scanner

Introduction

Architecture Overview

Pulling Job Posts

Defining Recency Windows

Board‑Specific Rules

Putting It Together: The Filter Pipeline

Running It at Home

Lessons Learned

Conclusion

Using node:sqlite in Node 24 to Build a Tiny Express Service Without a Separate Database Server

Introduction

Why SQLite with Node 24?

Setting Up the Project

Creating the SQLite Database

Wiring Express to SQLite

Querying with node:sqlite

Error Handling & Validation

Running the Service

Deploying on My Home Server

Lessons Learned

How I Keep My Site’s Chatbot Under a 9‑Second Serverless Timeout

Overview

Choosing a Free Model

Serverless Constraints

The Handler Code

Key Points

Timing the Inference

Fallback Strategy

Deploying and Testing

Lessons Learned

Conclusion

Booking Calls from a Chatbot with Cal.com API v2 – Open Slots, Create, Cancel

Booking Calls from a Chatbot with Cal.com API v2 – Open Slots, Create, Cancel

1. Why Cal.com?

2. Setting up the API client

3. Step 1 – Fetch open slots

4. Step 2 – Create a booking

5. Step 3 – Cancel a booking

6. Wiring it into the chatbot flow

7. Security & rate‑limiting considerations

8. Deploying on my home server

9. Takeaway

Building a Lean Blog CMS in Next.js 14 and Prisma with ISR

Why Build a Custom CMS?

The Prisma Schema for Posts and Drafts

Handling Drafts in the UI

Incremental Static Regeneration and RevalidatePath

Keeping It Maintainable

Connecting a Netlify Function to a Home Server via a Dynamic Cloudflare Tunnel

Introduction

Why Netlify + Cloudflare Tunnel?

Setting Up the Cloudflare Tunnel

Discovering the Dynamic Tunnel URL

API Token

Helper Script (optional)

Netlify Function that Calls the Home Server

Handling Tunnel Restarts

Testing the End‑to‑End Flow

Lessons Learned

Conclusion

Signing Netlify Webhooks with HMAC and Timestamps for a Home Automation Server

Why I Signed My Netlify Webhooks

The Core Idea

Generating a Secure Secret

Netlify Function: Sending the Signed Webhook

Home Server: Verifying the Request

Using node:sqlite in Node 24 to Build a Tiny Express Service Without a Separate Database Server

Why SQLite with Node 24?

3. Step 1 – Fetch open slots

4. Step 2 – Create a booking

5. Step 3 – Cancel a booking

Step 1: Organization markup

Step 2: WebSite markup

Step 3: BreadcrumbList & BlogPosting