DEV Community: Carlos Salamanca

I Built a Tiny Game for When Your App Takes Too Long to Load

Carlos Salamanca — Wed, 29 Jul 2026 22:51:53 +0000

Let's be honest.

Nobody likes staring at a loading spinner.

You wait.

You stare at the screen.

You wait some more.

And eventually you start wondering if the application is actually loading… or if it has simply given up on life. 😅

So I built BoredLoad.

Instead of making users stare at a spinner while waiting for your application to finish loading, BoredLoad gives them a tiny game to play.

🎮 What is BoredLoad?

BoredLoad is a lightweight, open-source loading component that turns long loading times into a small playable experience.

The idea is simple:

User starts waiting
       ↓
Loading...
       ↓
Loading takes longer than expected
       ↓
🎮 BoredLoad appears
       ↓
User plays
       ↓
Your content is ready
       ↓
Game disappears

The goal isn't to hide slow performance.

It's simply to make the waiting experience a little less boring.

🚀 Try it

You can check out the project here:

👉 GitHub

And install it from npm:

npm install boredload

Why did I build it?

I was thinking about something that happens constantly when using web applications:

loading screens are everywhere.

Dashboards load data.

Apps make API requests.

Authentication happens.

Files upload.

Pages transition.

Sometimes those operations take a few seconds.

And during those few seconds, we're usually given the same experience:

       ⏳
    Loading...

I thought:

What if the loading screen actually gave you something to do?

That's where BoredLoad came from.

🧑‍💻 Built for developers

BoredLoad is designed to be easy to drop into an existing project.

It supports:

TypeScript
Vanilla JavaScript
React
Angular
Vite
Next.js
Touch interaction
Keyboard interaction
High scores
Seeded randomness
prefers-reduced-motion
Customizable loading thresholds

And the core has zero runtime dependencies.

The goal was to keep it small enough that adding a tiny game to a loading screen doesn't become a huge performance penalty itself.

⚛️ React example

For example, you can initialize BoredLoad when an operation starts:

import { BoredLoad } from "boredload";

const boredLoad = new BoredLoad({
  threshold: 1500,
});

boredLoad.start();

fetch("/api/data")
  .then((response) => response.json())
  .then((data) => {
    boredLoad.stop();

    // Render your data
  });

The basic idea is that BoredLoad doesn't need to know what you're loading.

It simply needs to know:

"Are we still waiting?"

🕹️ Why a game?

There is actually something interesting about turning waiting into interaction.

A loading spinner is passive.

The user just watches.

A game is active.

Even a tiny interaction can change the perception of waiting.

Instead of:

"Why is this taking so long?"

It becomes:

"Can I beat my previous score?"

That's the little experiment behind BoredLoad.

🧩 Designed to be extensible

One of the things I wanted from the beginning was to avoid building a library that only supports one hardcoded experience.

The project has an extensible game architecture so new mini-games can be added over time.

The long-term idea is to have several small experiences:

BoredLoad
│
├── 🏃 Runner
├── 🐍 Snake
├── 🧠 Memory
├── 🚀 Space
└── 🧱 Breakout

And potentially allow developers to create their own games.

Because if you're going to wait…

you might as well make it interesting.

📦 Open source

BoredLoad is completely open source and released under the MIT License.

The repository is available on GitHub:

👉 https://github.com/salamancacm/boredload

If you like the idea, I'd really appreciate a ⭐ on GitHub.

And if you find a bug, have an idea for a game, or want to contribute, pull requests and issues are welcome.

☕ Support the project

BoredLoad will remain free and open source.

If you enjoy the project, find it useful, or simply like the idea of making loading screens less boring, you can support its development on Ko-fi.

Even a small contribution helps me justify spending more time building weird little developer tools like this one. 😄

☕ Support BoredLoad on Ko-fi

What's next?

I'm planning to experiment with more mini-games, better customization, and additional integrations.

But for now, I just wanted to get the idea out there.

Maybe loading screens don't have to be boring.

Maybe we can make waiting a little more fun.

Try BoredLoad and let me know what you think.

👉 GitHub

👉 npm

⭐ If you like it, consider starring the repository.

And if you build something with it, I'd love to see it.

I kept seeing weird stuff on my VPS, so I built a tool to stop guessing

Carlos Salamanca — Sat, 25 Jul 2026 21:07:02 +0000

A few weeks ago I noticed some things I couldn't explain on one of my VPS instances — nothing catastrophic, just enough "that's not right" to make me nervous. I went looking for a lightweight tool to audit and harden a fresh Linux server and mostly found two things: hand-rolled bash scripts of wildly varying quality, or heavyweight compliance scanners built for enterprises running hundreds of servers, not someone with a couple of $5/mo boxes.

So I built vpsguard — a single Go binary that audits, hardens, and monitors a Linux VPS, with no dependencies beyond what's already on the box.

What it actually does

That's a real recording — audit finding real issues on a stock Ubuntu box, harden fixing them, and monitor catching a simulated attacker adding their own SSH key. No staged screenshots.

Twelve checks in total: SSH config, firewall (ufw and firewalld — more on that below), fail2ban, suspicious user accounts, SSH key hygiene, cron, pending updates, exposed database ports, Docker socket permissions, kernel/patch status, and (as a beta check) AWS EC2's IMDSv1 exposure — the same SSRF vector behind the Capital One breach.

Every harden remediation is idempotent — run it ten times, get the same end state, no duplicated config lines — and every config file it touches gets backed up first.

The part that actually matters: monitor

Audit is nice, but the thing that motivated this whole project was catching change — someone adding an SSH key you didn't add, a new UID-0 account, a new process running as root. vpsguard monitor snapshots server state and diffs it against the last run — that's the second half of the GIF above, where it catches the CRIT the instant the attacker's key gets added.

Wire it to cron (vpsguard install-cron) and point it at a Slack/Discord webhook or email, and you get pinged instead of finding out three weeks later when you happen to check a log.

Running it from CI/CD

If you'd rather bake this into a pipeline than remember to run it yourself, there's a GitHub Action that audits a whole fleet on a schedule:

name: VPS security audit
on:
  schedule:
    - cron: "0 6 * * *" # daily at 06:00 UTC
  workflow_dispatch:

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: salamancacm/vpsguard-action@v1
        with:
          hosts: web-1.example.com,db-1.example.com
          ssh-user: root
          ssh-key: ${{ secrets.VPS_SSH_KEY }}
          ssh-known-hosts: ${{ secrets.VPS_KNOWN_HOSTS }}
          fail-on: CRIT

It installs vpsguard on the runner, connects to each host with your own SSH key (never vpsguard's — it doesn't handle credentials), runs the audit, and writes a summary table straight into the workflow's job summary. Set fail-on to CRIT, WARN, or NONE depending on whether you want a bad finding to actually fail the build or just get reported; it also exposes crit-count, warn-count, and unreachable-count as outputs if you want to branch on them yourself.

A few things I'm actually proud of

It's honest about what it hasn't verified. The AWS IMDSv1 check is tagged [BETA] in its own output, because I built and unit-tested it but never ran it against a real EC2 instance (that would mean spending real money on infra I didn't need). Rather than pretend otherwise, findings from unverified checks are marked, everywhere — table output and --json both.
Real bugs got caught by testing against real systems, not mocks. Validating the RHEL/dnf code path against an actual Rocky Linux container surfaced two genuine bugs: harden was trying to dnf install ufw (not in RHEL's repos at all) and the audit checks had no concept of firewalld — RHEL's actual default firewall — so a properly-secured RHEL box would've been reported as having no firewall at all. Fixed, and now covered by real Rocky Linux testing.
vpsguard fleet audits multiple hosts over SSH at once, using your own SSH config/agent — the same mechanism the GitHub Action above wraps.

Installing it

curl -fsSL https://raw.githubusercontent.com/salamancacm/vpsguard/main/install.sh | sh

(Checksum-verified against the release, refuses to install on a mismatch — read the script first if piping curl to sh isn't your thing, which is fair.) Also available via go install, and Homebrew-on-Linux.

What's next

Kernel/patch checking on RHEL is solid; broader cloud-provider coverage (Security Group/VPC-level blindness is a real gap right now — vpsguard only sees the OS firewall, not AWS/GCP's network layer) is on the list. If you run a VPS and have five minutes, vpsguard audit is read-only and won't touch anything — I'd genuinely like to know what it gets wrong on your setup.

Repo's here: https://github.com/salamancacm/vpsguard — issues, PRs, and "this check is wrong" reports all welcome.

I built a visual API generator — no code, no prompts, just clean backend projects

Carlos Salamanca — Tue, 25 Nov 2025 00:05:42 +0000

✨ Introduction

For the past few weeks, I’ve been building a tool that I personally needed for a long time:
a way to generate complete backend projects without writing the same boilerplate over and over.

The result is GenAPI — a visual API generator that lets you design your data models in a UI and then export a fully working backend project.

🔗 Try it here: https://thegenapi.io

(No login required — 100% free at the moment)

🛠 Why I built this

As developers, we constantly repeat the same setup steps:

creating models/entities
defining controllers/services
configuring routes
setting up project structure
writing CRUD logic
preparing basic validations
wiring everything into a backend framework

After doing this hundreds of times across Node, Java, Python and PHP projects, I wanted a faster way.

Not AI-generated code.
Not templates.
A real visual builder that outputs a clean, ready-to-run backend.

🧩 How GenAPI works

The workflow is very simple:

Open the visual builder

You start with an empty canvas where you can create:

Entities
Fields
Types
Relationships
Optional constraints

Choose your backend framework

Once your models are ready, you pick the stack you want to export to.

Right now GenAPI supports:

Java (Spring Boot)
Java (Quarkus)
Node.js (Express)
Python (FastAPI)
PHP (Laravel)

Download the generated ZIP

GenAPI creates a complete backend project with:

Models / Entities
Controllers
Services
Routes
Basic CRUD logic
Validations
Clean folder structure
Dependencies installed
A README with instructions

👉 You run it locally and it just works.

No prompts.
No AI guesswork.
Just deterministic code based on your entities.

🎁 New feature: Starter Templates

To help new users get started quickly, I’m adding starter templates inside the builder:

Blog API
E-commerce
Booking System
CRM Lite

These load pre-made entities so you can test the tool instantly.

🚀 Who is GenAPI for?

This tool is ideal if you:

build prototypes frequently
generate small/medium backends
teach backend development
want to speed up CRUD-heavy work
start many client projects
hate repeating boilerplate code

🧪 What I’m currently working on

More export options
Better UI for relationships
SAP CAP export (CDS-based, OData out of the box)
Auto-documented APIs
Advanced constraints
Microservice export mode
A VSCode extension to sync entities

🙏 I’d love your feedback

Since GenAPI is still early, feedback from the dev community is extremely helpful.

Is the builder intuitive?
Does the generated code look clean?
What frameworks should I add next?
Would this be useful in your workflow?

Comments are 100% welcome.

🔗 Try it here: https://thegenapi.io

Thanks for reading! 🚀