DEV Community: Luciano Federico Pereira

Run WordPress on SQLite: A Zero-Server Local Development Revolution

Luciano Federico Pereira — Wed, 18 Mar 2026 07:41:32 +0000

For years, the "Local WordPress" experience has been synonymous with overhead. Whether you use Docker, XAMPP, or dedicated local server apps, you are essentially running a miniature data center just to edit a theme or manage content.

mysqlite changes the paradigm. It allows you to run WordPress locally using SQLite, meaning no MariaDB, no containers, and no background services. Just PHP and a single database file.

The Vision: WordPress as a Portable Folder

The goal of this project isn't necessarily to replace MySQL on high-traffic production servers. Instead, it’s about making WordPress local-first and ultra-portable.

This is the perfect setup for:

Headless WordPress: Use WP as a content API for your local Next.js or Astro dev environment without spinning up a database.
Static Site Generation (SSG): Build your site locally, generate the static HTML, and deploy to GitHub Pages or Netlify.
Instant Sandboxing: Since the entire site (files + DB) lives in one folder, you can Move, Zip, or Git-commit the entire state of the project instantly.

The Technical Achievement: The Nim Translator

Most previous attempts to bring SQLite to WordPress relied on a db.php drop-in that used PHP's preg_replace to try and rewrite SQL queries on the fly. These were notoriously fragile because MySQL and SQLite speak very different dialects.

mysqlite takes a much more sophisticated, low-level approach using Nim.

What the Nim code actually achieves:

The core of this project is a compiled library written in Nim that acts as a structural translator.

Binary-Level Interception: Instead of just swapping text in PHP, it handles the translation at a high-performance level. Nim compiles to C, allowing it to interface directly with system libraries with near-zero latency.
Dialect Mapping: MySQL and SQLite handle things like AUTO_INCREMENT, date formats, and specific index types differently. The Nim logic acts as a "Universal Translator," taking complex MySQL queries and reframing them into valid SQLite logic before they ever touch the disk.
The "Fake" Client: It effectively tricks the WordPress core into thinking it is talking to a full-blown MySQL server, while secretly writing everything to a highly optimized local .sqlite file.

Why Nim? Using Nim was a strategic choice. It offers the performance of C (required for database-level tasks) but with a much safer, modern syntax that makes complex string manipulation and logic mapping manageable.

Why This Beats Containers for Local Dev

Feature	Traditional (Docker/MariaDB)	mysqlite (Local SQLite)
RAM Usage	Significant (Background services)	Negligible (PHP only)
Start-up Time	10–30 seconds	Instant
Data Storage	Hidden in Volumes/DB Servers	A single `.sqlite` file in your folder
Portability	Requires Export/Import	Copy/Paste the folder

How to Get Started

Since you don't need a database server, the setup is incredibly lean:

Clone the Repo:

git clone https://github.com/lucianofedericopereira/mysqlite

Start the PHP Server:
Navigate to the directory and run:
```
php -S localhost:8000
```
Install: Open your browser. The installation will proceed normally, but you’ll notice you don't need to create a database or a user in a separate management tool.

Final Thought

By decoupling WordPress from the requirement of a dedicated database server, we turn the world’s most popular CMS into a lightweight, file-based tool. It bridges the gap between the power of WordPress and the simplicity of flat-file systems.

Vapor Chamber: A Command Bus Built for Vue Vapor

Luciano Federico Pereira — Mon, 16 Mar 2026 19:53:21 +0000

Vapor Chamber: A Command Bus Built for Vue Vapor

Vue Vapor is changing how Vue apps compile. By ditching the Virtual DOM in favor of direct DOM updates using signals, Vapor opens the door for leaner, faster reactivity. Vapor Chamber is a ~2KB command bus designed to match that philosophy: minimal abstraction, predictable data flow, one place to look, debug, and test.

The Problem With Events

The traditional Vue pattern — emit, v-on, scattered handlers — works fine for small apps. But as complexity grows, logic fragments across components and tracing a single user action becomes a hunt.

With events you ask: where did this get handled?
With a command bus you ask: what does this do? — and the answer is always one function.

bus.dispatch('cart.add', product, { quantity: 2 })

One semantic action. One handler. One result.

Installation

npm install vapor-chamber

Requires Node >=18 and Vue >=3.5 (peer dependency, optional).

Core Concepts

Every command has three parts:

Part	Role	Example
`action`	What to do	`'cart.add'`
`target`	What to act on	`product` object
`payload`	Optional extra data	`{ quantity: 2 }`

Results always return a consistent shape:

{ ok: boolean, value?: any, error?: Error }

No exceptions leaking out. No ambiguous returns.

Registering Handlers

One action → one handler. That's the contract.

import { createCommandBus } from 'vapor-chamber'

const bus = createCommandBus()

bus.register('cart.add', (cmd) => {
  cart.items.push(cmd.target)
  return cart.items
})

const result = bus.dispatch('cart.add', product, { quantity: 2 })

if (result.ok) {
  console.log('Cart updated:', result.value)
}

Plugin System

Plugins are middleware that wrap every dispatch. They run in priority order (highest first), making it easy to compose cross-cutting concerns without touching handler logic.

import { validator, logger, history } from 'vapor-chamber'

// Validate before execution
bus.use(validator({
  'cart.add': (cmd) => cmd.target?.id ? null : 'Missing product ID'
}))

// Log everything (lowest priority, runs last)
bus.use(logger(), { priority: 0 })

// Track undo/redo history
bus.use(history())

Built-in Plugins

Plugin	What it does
`logger`	Console logging with action filtering
`validator`	Pre-execution validation rules
`history`	Undo/redo tracking
`debounce`	Delay until activity stops
`throttle`	Limit execution frequency

Async Support

Need to hit an API? Use the async bus:

import { createAsyncCommandBus } from 'vapor-chamber'

const bus = createAsyncCommandBus()

bus.register('user.fetch', async (cmd) => {
  const data = await fetch(`/api/users/${cmd.target.id}`)
  return data.json()
})

const result = await bus.dispatch('user.fetch', { id: 42 })

Batch Dispatching

Run multiple commands as a unit. Stops on the first failure.

const result = await bus.dispatchBatch([
  { action: 'cart.clear', target: cart },
  { action: 'order.create', target: orderData },
  { action: 'email.send', target: user }
])

Vue Vapor Composables

Vapor Chamber ships with composables built for Vue Vapor's signal-based reactivity:

import { useCommandBus, useCommand, useCommandState, useCommandHistory } from 'vapor-chamber'

// Access the shared bus (tree-shakeable)
const bus = useCommandBus()

// Dispatch with reactive loading/error signals
const { dispatch, loading, error } = useCommand('cart.add')

// State management via commands
const { state } = useCommandState('cart', initialState)

// Undo/redo
const { undo, redo, canUndo, canRedo } = useCommandHistory()

Dead Letter Handling

Configure what happens when an unregistered action is dispatched:

const bus = createCommandBus({
  onMissing: 'error'    // 'error' | 'throw' | 'ignore' | (cmd) => {}
})

Testing

createTestBus() records dispatches without executing handlers — perfect for unit tests.

import { createTestBus } from 'vapor-chamber'

const bus = createTestBus()

bus.dispatch('cart.add', product)

expect(bus.dispatched[0].action).toBe('cart.add')
expect(bus.dispatched[0].target).toEqual(product)

DevTools Integration

import { setupDevtools } from 'vapor-chamber'

setupDevtools(app, bus)

Adds a command timeline and inspector panel to Vue DevTools.

Why Vapor Chamber?

~2KB gzipped — practically free
Full TypeScript support out of the box
Framework-optional — works without Vue too
Predictable — consistent result shape everywhere
Testable — first-class testing utilities

Get Started

npm install vapor-chamber

GitHub
npm

If you're building with Vue Vapor and want your data flow as direct as your DOM updates, give Vapor Chamber a try.

In Praise of “Hobbyist Languages”: The Unsung Heroes of Software Development

Luciano Federico Pereira — Thu, 19 Feb 2026 00:38:42 +0000

First published on design﹢code

It started with a simple message posted to a Usenet group in 1991:

“I’m doing a (free) operating system (just a hobby, won’t be big and professional like GNU) for 386(486) AT clones.”

That hobby, of course, was Linux. And its author was Linus Torvalds.

For decades, some of the most significant and foundational technologies in computing originated in much the same way: as hobbyist projects. In an industry that often glorifies enterprise-scale and corporate backing, it’s easy to forget that the spirit of tinkering—coding for the sheer joy of it—is the true engine of innovation.

At the same time, you’ve probably heard the phrase “hobbyist language” tossed around as an insult. The implication is clear: not serious, not professional, not “enterprise‑grade”.

But what if that dismissal gets things completely backward? What if the qualities that make a language beloved by hobbyists are the very signs of a healthy, innovative, and resilient technology?

Here’s why the hobbyist developer isn’t just a quaint figure of the past, but a vital force for the future of tech.

Hobbyists Drive Early Adoption

Before a language or framework becomes “enterprise‑ready”, hobbyists are already exploring it, pushing its limits, and writing the first tutorials. They adopt new tools not because a manager told them to, but because they’re curious.

Python, Ruby, and many others grew first through communities of self‑taught developers drawn to their elegance and simplicity. Without production deadlines or corporate constraints, hobbyists provide crucial early feedback and help build the initial momentum that later leads to mainstream adoption.

Hobbyists Expand the Talent Pipeline

Where do professional developers come from? Almost always from hobbyists.

GitHub surveys consistently show that most developers started coding as a hobby. That “side project” on a resume often says more about a person’s potential than any certification. It demonstrates passion, self‑direction, and the ability to learn independently.

The person who spends their weekend building a Discord bot or automating their home is the same person who will later solve complex problems on a professional team.

Not every hobbyist becomes a professional developer, and that’s perfectly fine. The kid who spends their weekend running a Minecraft server or coding a 4 K intro doesn’t automatically become a professional DevOps engineer or graphics specialist. But the curiosity, experimentation, and problem‑solving behind those projects are the same traits that often grow into professional skills later on.

Hobbyists Strengthen Ecosystems

Most of the bug fixes, documentation updates, and useful utilities that professionals use daily come from people coding in their spare time.

Think about the last time you used npm, pip, or cargo. The vast universe of open‑source libraries you rely on every day is built substantially by people coding in their spare time.

Bug fixes, documentation updates, small utilities—these contributions form the connective tissue of modern software. They fill the gaps that corporations overlook, and keep ecosystems vibrant, flexible, and resilient.

Hobbyists Keep Languages Relevant

Why do some platforms or languages thrive for decades while others fade into obscurity? A vibrant hobbyist community is a key differentiator (some as die-hard as the Amiga scene). Languages with a low barrier to entry, like Python and JavaScript, attract a steady stream of newcomers. This creates a virtuous cycle: more beginners lead to more tutorials, more forum questions (and answers), and more community-built tools. This activity keeps a language feeling fresh and relevant, preventing it from becoming a niche tool locked away in an enterprise silo.

Hobbyists Create Real Innovation

“Serious innovation,” the kind that truly changes the industry, rarely comes from a corporate R&D department. The history of software is a history of side projects that changed the world. The evidence is undeniable:

Linux: Started by Linus Torvald “just for fun.” It now powers the majority of the world’s servers, Android phones, and countless other devices.
Python: Created by Guido van Rossum as a project to keep him occupied during a Christmas break.
Git: Also created by Linus Torvalds to solve his personal problem of managing the Linux kernel source code.
Ruby on Rails: Extracted by David Heinemeier Hansson from the codebase of Basecamp. He open-sourced the framework that would go on to power thousands of startups.

Hobbyists Increase Language Visibility

Who writes the tutorials, records the YouTube videos, and answers questions on Stack Overflow? Overwhelmingly, hobbyists.

This decentralized network of educators and enthusiasts makes new technologies approachable. Their content often matters more for long‑term adoption than any official marketing campaign.

Final Thoughts

Every time you git push, run a Python script, or spin up a Linux server, you’re standing on the shoulders of hobbyists—past and present.

So keep your side projects alive. That little script you’re writing to automate a boring task? That weird web app you’re building just because it amused you? Or the impulse to see if you can get Doom running on a kitchen thermometer, a smart toaster, or whatever strange gadget you found in a drawer last weekend—that’s the tradition. That’s the vibe. That’s the whole point.

Even if your project never becomes the next Linux, it still matters. You’re part of the lineage that built this industry-and the lineage that will keep it moving.

Code Quality: CQ Risk‑Weighted Assessment Mode

Luciano Federico Pereira — Wed, 11 Feb 2026 06:00:06 +0000

1. The Philosophy: Reality vs. Compliance

In a regulated payment environment, Code Quality (CQ) is often a tug-of-war between two worlds: the Engineering Reality (the daily developer experience) and KPI Governance (the metrics required by regulators like PCI-DSS, PSD2, or ISO 27001).

My approach is to bridge this gap. I do not view quality as a "one-size-fits-all" metric. Instead, I use a Risk-Weighted Scoring Model.

This model acknowledges a hard truth: in payments, a security breach is an existential threat, while a latency spike is merely a degraded experience. Therefore, we do not chase "clean code" in a vacuum; we prioritize the metrics that protect the business license and the user’s funds.

The Core Thesis: "Speed is a feature; Security is a prerequisite. We can scale to fix performance, but we cannot scale to fix a data breach."

2. The Strategy: Risk-Based Weighting

We align our engineering standards with our regulatory environment. The following weighting model ensures that a system cannot achieve a "Passing" grade if it is fast but insecure.

Category	Weight (PCI-DSS Context)	Why this weight?
Security	40% - 45%	Highest Risk. Non-negotiable for ISO 27001/PCI-DSS. Vulnerabilities here end the business.
Integrity	20% - 25%	Financial Risk. Prevents fraud, double-spending, and data tampering.
Reliability	15% - 20%	Operational Risk. Uptime and error handling must be deterministic.
Performance	5% - 10%	User Experience. Important, but secondary to the safety of funds.

Refined Scoring Formula

To avoid arbitrary grading, each metric is normalized onto a shared 0–100 scale. This lets us compare apples to oranges—latency, error rates, security findings—without smuggling in hidden biases.

The Normalization Model

For any metric where lower is better (latency, error count, etc.):
$$
[ \text{Score} = \max\left(0,; 100 \cdot \left(1 - \frac{\text{Actual} - \text{Target}}{\text{Target}}\right)\right) ]
$$

Hitting the target → 100
Missing the target by 10% → 90
Missing the target by 50% → 50
Catastrophic misses bottom out at 0, not negative values

This keeps the scoring intuitive and prevents a single bad metric from dominating the entire risk profile.

Example

A service has a P95 latency target of 150ms but is currently at 220ms.
$$
[ \text{Score} = 100 \cdot \left(1 - \frac{220 - 150}{150}\right) = 100 \cdot (1 - 0.4667) = 53.3 ]
$$
Rounded → 53

If this metric carries a 5% weight, its contribution to the overall score is:
$$
[ 53 \times 0.05 = 2.65 ]
$$
This keeps the signal honest: the service i*s slow, but the risk impact is proportionate—*unless high‑weight categories like Security or Availability are also degraded.

To avoid arbitrary grading, we use Normalization. We convert diverse metrics (milliseconds, vulnerability counts, percentages) into a shared 0–100 scale using the formula:

Example: If a service has a P95 Latency target of 150ms but is hitting 220ms, the score is 68. However, at a 5% weight, this impacts the final score by only 3.4 points. This allows us to be honest about technical debt without panicking stakeholders, provided the Security score remains high.

3. The Balance: SLAs, Reality, and Error Budgets

An SLA is a promise to the customer; Telemetry is the engineering truth. We manage the gap between them using Error Budgets:

Innovation Phase: If Reality > SLA, the team has the "budget" to ship features fast and experiment.
Stabilization Phase: If telemetry shows we are drifting near the SLA Floor, the model triggers a pivot. We stop feature work and move engineering effort to debt reduction and hardening.

4. Implementation: Multi-Stack Consistency

In a microservices environment utilizing Go, FastAPI (Python), and Symfony/Laravel (PHP) on AWS, language consistency is secondary to Telemetry Consistency.

The Stack Strategy

Go (Microservices): Focused on high-concurrency throughput.
Quality Gate: govulncheck for security, strict context propagation for tracing.
FastAPI (Data/ML): Focused on schema integrity.
Quality Gate: Pydantic for strict input/output validation (Integrity Score).
Symfony/Laravel (BFF/Legacy): Focused on business logic.
Quality Gate: PHPStan (Level 8+) and structured logging for audit trails.
AWS Infrastructure: The Unifying Layer.
Observability: CloudWatch and X-Ray ingest normalized JSON logs and Trace IDs from all three languages, providing a single "pane of glass" for system health.

5. Telemetry: Compliance-Ready Observability

We move beyond "vanity metrics" (like simple uptime) to a maturity model that satisfies PCI-DSS Requirement 10 and PSD2 Auditability.

The Telemetry Checklist

Traceability: Every request generates a Correlation ID at the edge, propagated through every Go routine, PHP process, and Python async task.
Auditability: Logs are structured (JSON), immutable, and contain User IDs/Context (without logging PII/Secrets).
Integrity: We monitor for log-tampering and missing telemetry signals.

Sample Quality Report: `payment-gateway-svc` (Go)

This is an example of the model’s output for a production service.

Category	Metric (Target vs. Actual)	Score (0-100)	Weight	Weighted Contribution
Security	0 Critical Vulns	100	45%	45.0
Integrity	100% Schema Validation	100	20%	20.0
Reliability	99.9% Uptime (Actual 99.8%)	99	15%	14.8
Performance	P95: 150ms (Actual 220ms)	68	5%	3.4
Auditability	100% Trace ID Propagation	100	15%	15.0
TOTAL				98.2 / 100 (PASS)

Analysis: The service passes because it is secure and auditable. The performance drift (220ms) is noted as technical debt but does not block deployment, as it sits within the Error Budget.

6. Conclusion

This work shows that Code Quality is a measurable control surface, not an ideal. By weighting Security and Integrity above all else, we align engineering effort with real risk. Telemetry becomes the verification layer that proves our engineering state matches our business commitments.

Vapor Chamber — A Tiny Command Bus for Vue Vapor (~1KB)

Luciano Federico Pereira — Thu, 29 Jan 2026 00:12:07 +0000

Source: github.com Package: npmjs.com

Vapor Chamber is a lightweight command bus built for Vue Vapor, Vue’s upcoming compilation mode that removes the Virtual DOM. Vapor compiles templates into direct DOM operations powered by signals, updating only what actually changed.

Vapor Chamber follows the same philosophy: minimal abstraction, direct updates, signal‑native reactivity.

Minimal Example

import { createCommandBus } from 'vapor-chamber';

const bus = createCommandBus();

bus.register('cart.add', (cmd) => {
  cart.items.push(cmd.target);
  return cart.items;
});

bus.dispatch('cart.add', { id: 1, name: 'Book' });

Why a Command Bus?

Traditional event systems scatter logic across components. A command bus centralizes it:

Event-driven: components emit → others listen → logic spreads everywhere
Command bus: dispatch('cart.add', product) → one handler → plugins wrap behavior

Benefits

Clear, semantic actions (cart.add > emit('add'))
One handler per action → easier debugging & testing
Plugin pipeline for logging, validation, analytics, etc.
Natural undo/redo via command history

Jinja2TT2: Jinja2 to Template Toolkit Transpiler

Luciano Federico Pereira — Wed, 28 Jan 2026 05:59:15 +0000

A Perl transpiler that converts Jinja2 templates to Template Toolkit 2 (TT2) syntax.

Source: https://github.com/lucianofedericopereira/jinja2tt2

Description

Jinja2 is deeply integrated with Python, making a direct port impractical. However, since TT2 and Jinja2 share similar concepts and syntax patterns, this transpiler performs a mechanical translation between the two template languages.

Why TT2?

TT2 and Jinja2 share:

Variable interpolation: {{ var }} maps to [% var %]
Control structures: {% if %} / {% for %} map to [% IF %] / [% FOREACH %]
Filters: {{ name|upper }} maps to [% name | upper %]
Includes, blocks, and inheritance (conceptually similar)
Expression grammar close enough to map mechanically

Installation

No external dependencies beyond core Perl 5.20+.

git clone https://github.com/lucianofedericopereira/jinja2tt2
cd jinja2tt2

Usage

Command Line

# Transpile a file to stdout
./bin/jinja2tt2 template.j2

# Transpile with output to file
./bin/jinja2tt2 template.j2 -o template.tt

# Transpile in-place (creates .tt file)
./bin/jinja2tt2 -i template.j2

# From stdin
echo '{{ name|upper }}' | ./bin/jinja2tt2

# Debug mode (shows tokens and AST)
./bin/jinja2tt2 --debug template.j2

Programmatic Usage

use Jinja2::TT2;

my $transpiler = Jinja2::TT2->new();

# From string
my $tt2 = $transpiler->transpile('{{ user.name|upper }}');
# Result: [% user.name.upper %]

# From file
my $tt2 = $transpiler->transpile_file('template.j2');

Supported Constructs

Variables

{{ foo }}           →  [% foo %]
{{ user.name }}     →  [% user.name %]
{{ items[0] }}      →  [% items.0 %]

Filters

{{ name|upper }}              →  [% name.upper %]
{{ name|lower|trim }}         →  [% name.lower.trim %]
{{ items|join(", ") }}        →  [% items.join(', ') %]
{{ name|default("Guest") }}   →  [% (name || 'Guest') %]

Conditionals

{% if user %}          →  [% IF user %]
{% elif admin %}       →  [% ELSIF admin %]
{% else %}             →  [% ELSE %]
{% endif %}            →  [% END %]

Loops

{% for item in items %}    →  [% FOREACH item IN items %]
{{ loop.index }}           →  [% loop.count %]
{{ loop.first }}           →  [% loop.first %]
{{ loop.last }}            →  [% loop.last %]
{% endfor %}               →  [% END %]

Blocks and Macros

{% block content %}        →  [% BLOCK content %]
{% endblock %}             →  [% END %]

{% macro btn(text) %}      →  [% MACRO btn(text) BLOCK %]
{% endmacro %}             →  [% END %]

Comments

{# This is a comment #}    →  [%# This is a comment %]

Whitespace Control

{{- name -}}               →  [%- name -%]
{%- if x -%}               →  [%- IF x -%]

Other Constructs

{% include "file.html" %} → [% INCLUDE file.html %]
{% set x = 42 %} → [% x = 42 %]
Ternary: {{ x if cond else y }} → [% (cond ? x : y) %]
Boolean literals: true/false → 1/0

Filter Mapping

Jinja2	TT2 Equivalent
`upper`	`.upper`
`lower`	`.lower`
`trim`	`.trim`
`first`	`.first`
`last`	`.last`
`length`	`.size`
`join`	`.join`
`reverse`	`.reverse`
`sort`	`.sort`
`escape` / `e`	`\
{% raw %}`default`	`\
{% raw %}`replace`	`.replace`

Some filters require TT2 plugins (e.g., tojson needs Template::Plugin::JSON).

Loop Variable Mapping

Jinja2	TT2
`loop.index`	`loop.count`
`loop.index0`	`loop.index`
`loop.first`	`loop.first`
`loop.last`	`loop.last`
`loop.length`	`loop.size`

Limitations

Template inheritance ({% extends %}) requires manual adjustment for TT2's WRAPPER pattern
Autoescape is not directly supported in TT2
Some filters need custom TT2 plugins or vmethods
Complex Python expressions may need review

Running Tests

prove -l t/

Architecture

Tokenizer: Splits Jinja2 source into tokens (text, variables, statements, comments)
Parser: Builds an Abstract Syntax Tree (AST) from the token stream
Emitter: Walks the AST and generates equivalent TT2 code

Credits

Luciano Federico Pereira - Author

License

This is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License (LGPL) version 2.1 as published by the Free Software Foundation.

The Joy Division Effect: How I Learned Programming by Making Waves

Luciano Federico Pereira — Mon, 26 Jan 2026 22:56:31 +0000

Exploring how a static pulsar plot from 1970 became the spark that led me to understand Perlin noise, animation, and the beauty of coherent randomness. Turning Unknown Pleasures into moving waves taught me more about programming than any textbook ever did.

Original Posted on:
Codecraft blog

The original image is a plot of radio pulses from the pulsar CP1919, first published in The Cambridge Encyclopaedia of Astronomy.

4K Before 4K

Back then, “4K” didn’t mean ultra‑HD — it meant 4 kilobytes. Tiny intros that somehow squeezed whole worlds of motion, color, and attitude into the space of a modern emoji pack. And somewhere in that neon‑washed universe of pixels pretending to be ultra‑HD, with synth lines stretching into cosmic gradients, one image kept resurfacing in my mind: the waveform from Joy Division’s Unknown Pleasures.

That stark, minimalist cover showed something I couldn’t unsee — a still image that wanted to move. Those parallel mountain ranges weren’t Perlin noise at all, but stacked plots of radio pulses from the pulsar CP1919. Still, to my kid‑programmer brain, they looked like frozen waves begging to be animated, pulsing, breathing.

From Stillness to Motion

On my Commodore 64, armed with assembly language and pre‑calculated prime numbers (because true randomness was too expensive), I tried to animate what I saw. Sine waves came first: too perfect, too predictable. Then I tried more complex LFOs, but they still lacked that organic wobble I was chasing.

Just to be clear, the original CP1919 pulsar plot — the one used on Unknown Pleasures — does not move. It’s a stack of 80 separate recordings, each one a single rotation of the pulsar. Think of it like 80 screenshots of a repeating signal.

But what I wanted wasn’t the science — it was the feeling of those lines coming alive. And to get that, I needed something the real data couldn’t give me.

Perlin noise: So 80s.

Years later, I realized I’d been trying to reinvent Perlin noise without knowing it existed. Ken Perlin’s 1983 algorithm for generating natural‑looking textures was exactly what I’d been reaching for: coherent randomness, smooth transitions — the mathematical equivalent of something alive.

Perlin created his noise function while working on Tron, trying to avoid the rigid, grid‑like look that early CGI couldn’t escape. He later described the method in a paper called An Image Synthesizer, which remains one of the most accurate names ever given to a graphics technique. Between Tron, synth aesthetics, vector graphics, and that title, the only thing missing is The Breakfast Club and you’ve basically assembled the entire 80s in one algorithm.

The core idea behind Perlin noise is simple: generate variation that isn’t repetitive like a sine wave and isn’t chaotic like pure randomness. It produces values that drift smoothly — exactly the behavior I could never coax out of lookup tables, LFOs, or prime‑indexed hacks.

How 1D Perlin Noise Works

The one‑dimensional version goes like this:

take the two integer positions around your input
assign each a pseudo‑random gradient
compute each gradient’s influence
blend the results using a smooth interpolation curve
That interpolation step is what removes the mechanical edges and creates the “organic” motion the Unknown Pleasures cover hints at.

Once you understand that, animating the lines becomes straightforward. Each horizontal line samples a slightly different position in the noise field. Each x‑coordinate marches forward through noise space. A height table shapes the silhouette so the lines rise and fall like the original plot. Everything else is just drawing.

Let’s Bring in JavaScript

The JavaScript version below keeps only the essentials: a permutation table for repeatable pseudo‑random values, a precomputed fade curve for smooth transitions, and a compact 1D noise function. A height table controls how much each point can move, creating the familiar rise in the center and fall at the edges. Each line reads from a slightly different position in the noise field, and each x‑coordinate steps forward to preserve the tiny spikes and irregularities that make the motion feel alive. Relevant Parts of the Code

Permutation table (perm): A 512‑entry table used to generate repeatable pseudo‑random gradients — the backbone of classic Perlin noise.
Fade table (fadeTable): A precomputed smoothing curve. Instead of calculating the fade function every frame, the code looks it up, which is faster and avoids unnecessary floating‑point work.
Height table (hTable): _ Defines how tall each line can be at each x‑coordinate. This creates the “mountain” profile: low at the edges, high in the center._
Noise function (noise(x)): A compact 1D Perlin implementation that: finds the integer cell around x, computes the fractional part, blends the two gradient contributions using the fade curve.The result is a smooth value between 0 and 1.
Animation loop (animate()) : _Draws stacked horizontal lines. Each line: samples the noise field with a different offset (this.t + idx * this.step), uses the height table to scale the displacement, and fills and strokes the shape to create the solid Unknown Pleasures look.

The key detail is the idx++ inside the inner loop. That increment ensures each x‑coordinate samples a unique position in the noise field, preserving the tiny spikes and irregularities that make the waveform feel alive.

What the Code Is Doing, Conceptually

In practical terms:

Initialize noise tables
Build the permutation table, fade curve, and height profile.
For each animation frame: 1) clear the canvas 2) loop over horizontal lines 3)
for each x‑coordinate, compute a Perlin noise value: 1) multiply it by the height table 2) subtract it from the baseline y‑position 3) draw the resulting shape
Advance time (this.t += 0.01) This shifts the sampling position in the noise field, creating motion.
Request the next frame
And the animation continues.

That’s all the algorithm needs: a smooth noise source, a height profile, and a stack of lines sampling the noise field at different offsets.

The Result

https://lucianofedericopereira.github.io/codecraft/design/the-joy-division-effect-how-i-learned-programming-by-making-waves/

🚀 sqltool: A Lightweight Local MySQL/MariaDB Instance Manager (No Containers Needed)

Luciano Federico Pereira — Thu, 22 Jan 2026 20:49:49 +0000

👉 GitHub repo: sqltool

If you’ve ever spun up a MySQL or MariaDB database for local development, you’ve probably gone through one of these:

Pull a heavy Docker image

Run a container that stays running even when you don’t need it

Install a system‑wide service that auto‑starts on boot

Fight with conflicting ports, configs, or leftover data

For something as simple as “I need a database for this project,” that’s a lot of overhead.

sqltool takes a different approach.

It’s a tiny, single‑file CLI tool that creates isolated MySQL/MariaDB instances on your machine — without containers, without systemd services, and without touching your global database installation.

Each project gets its own clean, isolated environment that runs only when you explicitly start it.

🧩 What is sqltool?

sqltool is a local MySQL/MariaDB instance manager designed specifically for development workflows. It:

Runs mysqld directly as your user

Creates isolated per‑project instances

Avoids global configuration changes

Keeps everything inside ~/sql/

Works on almost any Linux distribution

Requires no dependencies beyond Perl and MariaDB

It’s ideal for developers working on multiple projects, microservices, or experiments where each environment needs its own database.

✨ Key Features

No containers — no Docker, no Podman, no images to pull

No system services — nothing auto‑starts, nothing runs in the background

Isolated instances — each project gets its own data directory, socket, port, and logs

Simple workflow — add, start, stop, backup, restore, clone

Multi‑distro support — Debian, Ubuntu, Fedora, Arch, SUSE, Alpine, Void, and more

Single‑file tool — just copy it and run

📦 Requirements

Perl 5 (preinstalled on almost every Linux distro)

MariaDB or MySQL (auto‑installed if missing)

📚 Commands Overview

Command Description
add Create new instance
remove Delete instance + data
start Start instance
stop Stop instance
list List all instances
info Show details
port Show port
logs Show recent logs
backup Create SQL backup
restore Restore backup
clone Clone instance
status Quick status
help Show help

🐧 Supported Linux Distributions

Auto‑detection + auto‑installation works on:

Debian, Ubuntu, Linux Mint, Pop!_OS, elementary OS
Fedora, RHEL, CentOS, Rocky, AlmaLinux
Arch Linux, Manjaro
openSUSE, SUSE
Alpine Linux
Void Linux

For other distros, just install MariaDB manually.

🐪 Why Perl?

Because for this kind of tool, Perl hits the sweet spot:
Preinstalled everywhere
No dependency hell
Uses only core modules
Fast startup
Perfect for system tasks
Single‑file distribution
Stable across decades

Many classic Linux tools are still written in Perl or shell for a reason — they’re reliable, portable, and easy to maintain.

📜 License

LGPL‑2.1 — see source file for details.

👤 Author

Luciano Federico Pereira

DEV Community: Luciano Federico Pereira

Run WordPress on SQLite: A Zero-Server Local Development Revolution

The Vision: WordPress as a Portable Folder

The Technical Achievement: The Nim Translator

What the Nim code actually achieves:

Why This Beats Containers for Local Dev

How to Get Started

Final Thought

Vapor Chamber: A Command Bus Built for Vue Vapor

Vapor Chamber: A Command Bus Built for Vue Vapor

The Problem With Events

Installation

Core Concepts

Registering Handlers

Plugin System

Built-in Plugins

Async Support

Batch Dispatching

Vue Vapor Composables

Dead Letter Handling

Testing

DevTools Integration

Why Vapor Chamber?

Get Started

In Praise of “Hobbyist Languages”: The Unsung Heroes of Software Development

Hobbyists Drive Early Adoption

Hobbyists Expand the Talent Pipeline

Hobbyists Strengthen Ecosystems

Hobbyists Keep Languages Relevant

Hobbyists Create Real Innovation

Hobbyists Increase Language Visibility

Final Thoughts

Code Quality: CQ Risk‑Weighted Assessment Mode

1. The Philosophy: Reality vs. Compliance

2. The Strategy: Risk-Based Weighting

Refined Scoring Formula

The Normalization Model

Example

3. The Balance: SLAs, Reality, and Error Budgets

4. Implementation: Multi-Stack Consistency

The Stack Strategy

5. Telemetry: Compliance-Ready Observability

The Telemetry Checklist

Sample Quality Report: payment-gateway-svc (Go)

6. Conclusion

Vapor Chamber — A Tiny Command Bus for Vue Vapor (~1KB)

Minimal Example

Why a Command Bus?

Benefits

Jinja2TT2: Jinja2 to Template Toolkit Transpiler

Description

Why TT2?

Installation

Usage

Command Line

Programmatic Usage

Supported Constructs

Variables

Filters

Conditionals

Loops

Blocks and Macros

Comments

Whitespace Control

Other Constructs

Filter Mapping

Loop Variable Mapping

Limitations

Running Tests

Architecture

Credits

License

The Joy Division Effect: How I Learned Programming by Making Waves

4K Before 4K

From Stillness to Motion

Perlin noise: So 80s.

How 1D Perlin Noise Works

The one‑dimensional version goes like this:

Let’s Bring in JavaScript

What the Code Is Doing, Conceptually

Sample Quality Report: `payment-gateway-svc` (Go)