______ ____ ____ ____________ __
/ / __ \/ __ \/ __ \/ _/ ____/ //_/
__ / / / / / / / / /_/ // // / / ,<
/ /_/ / /_/ / /_/ / _, _// // /___/ /| |
\____/\____/_____/_/ |_/___/\____/_/ |_|
| NAME | SIZE | MODIFIED | DESCRIPTION |
|---|---|---|---|
| -- | 2025 | Smart-home hub running a local LLM, no cloud | |
| |||
| -- | 2025 | Real-time voice conversion -- synthetic-voice fraud study | |
| |||
| 340kb | 2026-07 | Four-stem browser jam rack -- no backend at all | |
| |||
| live | 2024-2026 | Storefront I built and operate -- real customers, real payments | |
| |||
The thing I keep coming back to is dependency. Most systems people rely on every day quietly require somebody else's server to be reachable, and nobody notices until it is not.
A voice assistant that ships your audio to a datacenter stops working when the uplink drops. A web app that phones home cannot be used on a plane. A storefront that trusts its payment gateway to behave will sell somebody a half-configured order at 2am. These are the same problem wearing different clothes.
I came up through support because I like being the person who figures out what actually broke. Five years of that -- Active Directory, servers, routers, firewalls, then cloud and on-prem infrastructure with Docker and CI/CD -- taught me that the useful skill is not knowing the answer, it is being able to take a system apart while it is running. That is what a SOC runs on: an alert is a system telling you something broke, and somebody has to find out what.
So the projects here are all the same experiment: build the thing so it does not need permission from anyone to keep working. Run the model in the house. Do the DSP on the client. Own the failure path.
rick.marquinez@gmail.com
| aws-cloud-practitioner | CLF-C02 | Amazon Web Services |
| azure-fundamentals | AZ-900 | Microsoft |
| cysa-plus | CS0-003 | CompTIA |
| security-plus | SY0-701 | CompTIA |
| network-plus | N10-009 | CompTIA |
| a-plus | 220-1101 | CompTIA |
| project-plus | PK0-005 | CompTIA |
| linux-essentials | -- | Linux Professional Institute |
| itil-4-foundation | -- | PeopleCert |
| google-it-support | -- | |
| ciw-web-foundations | x3 | CIW |
Commercial voice assistants work by shipping audio from inside your house to a datacenter. That is the architecture, not a setting you can switch off.
Two things follow from it. The first is obvious: every request a household makes is processed on somebody else's hardware, under somebody else's retention policy.
The second is the one that actually breaks things. The assistant stops working the moment the uplink does. A light switch that depends on a datacenter being reachable is a worse light switch than the one it replaced.
Warden runs the language model locally through Ollama and wires it into Home Assistant as the voice and automation layer. Interpretation happens on hardware in the building.
No audio leaves the premises. No telemetry goes out. The house keeps responding during an outage.
This is the same instinct that makes me useful in an incident. Understanding a system well enough to run it yourself -- instead of escalating to a vendor and waiting -- is the difference between a short outage and a long one.
A real-time voice-conversion pipeline: speech in, a different voice out, fast enough to hold a live conversation.
The engineering problem is latency budgeting. Transcription and synthesis each cost time, and past a certain total the round trip stops feeling like a conversation and starts feeling like a radio call.
What I did not expect was how convincing it got, and how little it cost to get there. A weekend project on consumer hardware produced something that would comfortably pass over a phone call.
So the project changed shape. It became a practical study of synthetic-voice fraud -- the vishing and voice-cloning attacks that show up in the same material as my CySA+ and Security+ work.
Building the attack is the fastest honest way to understand what defending against it requires. It is the piece of my security training I have held in my own hands rather than read about in a courseware module.
Most browser DJ apps are two decks and a crossfader. Random Access Jam is a four-position rack instead -- vocals, drums, bass, lead -- and each position is sourced independently from any loaded track.
Vocals from song A over drums from song B over bass from song C, all playing at once, summed rather than blended.
That model is the whole design. It is not "mix between two things," it is "build one thing out of four unrelated things." Which only works if every stem can be made to agree on tempo and key.
Every stem is conformed to a master tempo (90-157 BPM) and master key by pitch-preserving time-stretch, done offline through Signalsmith Stretch compiled to WASM -- the project's only vendored dependency. A half/double-time guard keeps extreme ratios from sounding obviously processed.
Timing is a look-ahead scheduler over the bar grid. Loops launch quantized and restart in lockstep on every 16-bar boundary, so nothing drifts over a long session -- which is the failure mode that makes naive Web Audio loopers unusable after a few minutes.
Change the master BPM or key mid-session and every position re-conforms and swaps on the next loop boundary rather than glitching in place. Tempo and key detection are pure JS running in a Worker, so analysis never blocks the audio thread or the UI.
The app makes no network calls at runtime. Tracks live in IndexedDB on the user's own machine and never leave it. A service worker keeps the whole thing working offline.
Two demo stem sets are synthesized procedurally on first run via OfflineAudioContext, so it boots straight into a playable cross-track mashup with nothing uploaded and no account.
An e-commerce platform I built and operate for a niche technical community -- a storefront selling tooling and packs to people who know exactly what they want and get annoyed when a checkout gets in the way.
The centerpiece is a multi-step product configurator written in vanilla JS that drives WooCommerce variation selection, with checkout across Stripe, PayPal, and Google Pay.
Payment buttons must not appear until a configuration is actually valid. Sounds trivial. It is not, because the payment gateway wants control of its own UI and will fight you for it.
It ended up needing two layers: a CSS gate that hides the payment surface until the configurator marks the state ready, plus a JS intercept for the gateway writing inline !important styles of its own.
One layer alone leaves a window where a customer can pay for something they have not finished configuring -- which is a support ticket, a refund, and a lost customer.