tl;dr — IBM WebSphere has a clean configuration API (ConfigService) buried under a broken string-based wrapper (AdminConfig). I built an object-oriented Jython layer that hooks into ConfigService directly via JMX — easing configuration and ensuring type correctness through metadata introspection — plus a persistent daemon that eliminates JVM boot overhead, and 55 idempotent scripts that integrate with Ansible’s change detection. github.com/vjt/ansible-wsadmin
In 2021, I spent six months automating the IFAD WebSphere infrastructure with Ansible. The stack was IBM WebSphere Application Server (WAS), WebSphere Portal Server (WPS), and Business Automation Workflow (BAW) — a clustered deployment with a Deployment Manager, multiple nodes, federated LDAP, SIB messaging, the works.
The standard approach to automating WAS is to write Jython scripts using AdminConfig, AdminTask, and AdminApp — the four global scripting objects that IBM provides inside wsadmin. I tried that. It lasted about a day before I started looking at what’s underneath.
What I found changed how I approached the entire project. It also produced a library full of ideas I never had a chance to describe properly — until now, with a little help from Claude.
Today is my birthday, and I’ve decided to open a time capsule.
Eighteen years ago, we started building Myousica — a platform for collaborative music creation in the browser. Record from your microphone, upload tracks, remix other people’s music, build songs together with strangers across the internet. We launched in September 2008 after nine months of development.
It was a startup. It ran for about five months before being paused, and the source code was eventually released on GitHub under the name Mewsic. I wrote about the technical details in a three-part series: the Rails platform, the Flash multitrack editor, and the audio pipeline. Those posts cover the engineering. This one is about the bigger picture.
The core concept was solid: let anyone make music in a web browser, collaboratively. No software to install. Open your browser, pick a song, add your guitar track, share the result. A musician in Rome could start a beat, someone in Tokyo could add bass, a singer in São Paulo could lay down vocals on top. All in the browser.
The problem was that in 2008, browsers couldn’t do any of this natively.
To capture audio from a microphone, you needed Flash — an ActionScript front-end running in the Flash Player plugin. To stream that audio to a server, you needed RTMP — a Java media server (Red5) just to receive the audio and write it to disk as FLV files. To turn those FLV files into playable MP3s, you needed a pipeline of ffmpeg, sox, and background workers on the server side. To display a waveform, you rendered it as a PNG — the Canvas API wasn’t mature enough. To play back multiple tracks in sync, you built a custom playback engine in ActionScript with frame-accurate timing.
I have a FreeBSD server called m42 that’s been running for years. Email, web, firewall, the usual. Two and a half years of monthly restic backups sitting in snapshots — roughly 25 million syslog lines across four formats: BSD syslog, fail2ban, pf packet filter, and nginx. A goldmine of security telemetry, completely unindexed and unsearchable.
I built an observability stack on a Raspberry Pi 5 at home — VictoriaLogs for storage, Telegraf for processing, Grafana for visualization — and decided to backfill every single one of those 25 million entries through the exact same enrichment pipeline that processes live data. GeoIP geolocation, ASN identification, reverse DNS for every IP address.
The backfill itself was straightforward. What wasn’t straightforward: the three bugs it exposed in Telegraf’s internals. The kind of bugs that only surface under sustained load. The kind nobody hits because nobody does this.
The naive approach is to write Python scripts that replicate your pipeline — parse logs, enrich with GeoIP, POST to your log store. I did this. Twice. Each time the scripts drifted from the live pipeline: different field names, missing enrichment, parsing inconsistencies between Starlark and Python regex.
The fix was embarrassingly simple: stop duplicating the pipeline and just replay the raw logs through the real thing.
The backfill script became a log replayer: read the raw files, wrap each line in an RFC 5424 envelope with the correct timestamp, send it to Telegraf over TCP with octet-counting framing. That’s it. Zero content parsing. The enrichment pipeline handles everything identically to live data.
TL;DR: If you run OpenWrt with mwan3 (multi-WAN failover) and a split-tunnel WireGuard VPN (i.e., you’re NOT routing all traffic through it), add nohostroute=1 to your WireGuard interface. Without it, netifd creates a static route for the WireGuard endpoint at interface-up time, pinned to whatever uplink happens to be active at that moment. By the first corollary of Murphy’s Law, anything that can go wrong will go wrong at the worst possible moment — so your primary link will be down precisely when WireGuard starts, and the endpoint route gets permanently stuck on the backup. Your VPN will be stuck on the slow backup while your primary link sits there doing nothing. You won’t notice until you need to transfer something big.
(If you are routing all traffic through WireGuard, you need the host route to prevent a routing loop — but on a multi-WAN setup, the same stale-route problem applies. You’ll need a different workaround, like a hotplug script that updates the endpoint route when mwan3 switches uplinks.)
Today I discovered that my WireGuard tunnel to a remote server has been crawling at 2 Mbps since early February. The fix took two UCI commands. The root cause was the missing nohostroute flag — plus a bonus: my own firewall was sabotaging my own health checks, making the fiber look unreliable enough that the system never self-corrected.
Here’s the full forensic story, because I’m still furious and you deserve to learn from my suffering.
But first, some context on how this investigation actually happened. I was working with an AI coding assistant (Claude Code) that has SSH access to my infrastructure. This is possible because I have a clean foundation: SSH key authentication everywhere, proper internal DNS (m42, golem resolve to the right VPN addresses), WireGuard mesh between all nodes, and the assistant connects through a ssh-agent running as a systemd user service. One environment variable and the AI can reach every machine in my network — and, critically, cross-reference what it finds on one machine with data from another. This investigation would have taken me hours of jumping between terminals. The AI did it in minutes, methodically testing hypotheses across three machines simultaneously. The infrastructure investment in proper SSH, DNS, and VPN paid off enormously.
It’s like having an incredibly fast, skilled, and thorough engineer sitting next to you — one that really allows your creativity to flow without borders. You say “what if we…” and 30 seconds later you’re looking at a working prototype. You go “no, more like this” and it’s done before you finish explaining why.
That’s what working with Claude Code felt like over the past two days. I completely revamped this blog — translated all 69 posts to Italian, redesigned the layout from the ground up, added a nerdy boot sequence easter egg, cleaned up years of tag cruft, and iterated through dozens of design decisions. All of it tracked in git, all of it reviewable, all of it live.
Every single commit is public. If you want to see the raw process — the brainstorming, the iterations, the bugfixes, the back-and-forth — it’s all in the repo: github.com/vjt/sindro.me (and the theme fork: github.com/vjt/hugo-sindrome-theme). I’m not ashamed of showing how the sausage is made. If anything, I hope someone finds it useful as a learning resource for what AI-assisted development actually looks like in practice — warts and all.
Here’s my GitHub contribution graph to prove I’m not exaggerating:
It’s not that the alarm itself is bad — the SDVECU panel is solid, the
sensors are reliable, the installation is professional. But the app. Good
lord, the app.
You open the app to check your alarm status and you’re greeted by an ad
for Verisure itself. I pay through the nose for the service and they
shove ads inside the app. It’s 2026 and a security company is showing me
banner ads when I’m trying to verify that my house is protected.
But the ads are the least of it. The real problems are:
Blind routines. Yes, the app has “routines” — arm at midnight,
disarm at 7. But they have no idea where you are. It’s midnight
and you’re still in the garden? The alarm arms and the sensors
go off. Window open? The panel announces it can’t arm, but if you
don’t hear it the alarm stays disarmed. Go on vacation and forget
to disable the morning disarm routine? Alarm off with an empty
house. And routine changes take 20 minutes to propagate — “or
the next day”. In 2026.
Zero presence awareness. The app doesn’t know where you are.
It doesn’t know who’s home. It doesn’t know if the cleaning lady
has left. No location-based automation whatsoever.
One camera at a time. Want to see all your cameras? Tap, wait,
go back, tap the next one, wait. No overview. No “capture all”.
Biblically slow. Request an image, wait, wait, maybe it arrives.
Sometimes you reload the app and try again. In 2026.
No permanent storage. Captured images vanish. There’s no
browsable history.
No timestamps on images. You capture a photo and you don’t know
when it was taken or which camera took it. You have to
remember. For a security system, that’s embarrassing.
Generic notifications. One notification, same for everyone. No
actionable notifications, no critical alerts that bypass Do Not
Disturb.
What I wanted: my alarm, integrated into my smart home, with intelligent
automations, notifications for all residents, and a dashboard that shows
everything at a glance. No ads.
It started with WiFi presence detection. I had built a system that tracks which room everyone is in by scraping RSSI from my OpenWrt APs. It worked — but the room assignments kept flickering. Kitchen. Office. Kitchen. Office. Three times in ten seconds. The state machine was fine. The WiFi wasn’t.
My home network runs six OpenWrt APs across three floors, two SSIDs — Mercury on 5 GHz, Saturn on 2.4 GHz — all backed by 802.11r for fast roaming. From the outside, it looks like a proper mesh. From the inside, one phone was bouncing between access points 129 times in 24 hours.
I didn’t know this until I built the tool to see it.
Each row is a WiFi client, the color shows which AP it’s connected to. Healthy clients show long solid bars. Sick ones look like barber poles. See sara-iphone? That rainbow stripe is 129 connects in 24 hours — the phone is walking through an overlap zone between two APs where both have roughly equal (and terrible) signal.
WiFi roaming is invisible. Your phone shows full bars, Netflix buffers for a moment, and you blame the internet. But what actually happened is your phone disconnected from one AP, scanned for alternatives, picked another one with a marginally different signal, associated, authenticated, and started streaming again — all in under a second if 802.11r is working, several seconds if it’s not.
I maintain a bunch of custom OpenWrt packages across four architectures: MediaTek Filogic (aarch64), Raspberry Pi 2 (ARM), Ramips MT7621 (MIPS), and Atheros ath79 (MIPS). The OpenWrt SDK only runs on x86_64. I don’t have a dedicated build server. I don’t want one either — a box sitting idle 99.9% of the time just to compile .ipk files every few days is offensive to my sense of resource allocation.
So I built openwrt-builder: a system that polls my repos for changes, spins up a throwaway Hetzner cloud VM when it needs to compile, builds the packages, ships them back, and destroys the server. All controlled via Telegram.
I had two problems with Home Assistant’s presence detection.
The first: GPS tells you if someone is home, but not where in the house they are. My home has six OpenWrt access points spread across three floors. They already know exactly which phone is connected to which AP at every moment — that’s room-level presence data, sitting right there in the WiFi stack, screaming to be used. Knowing who’s in which room opens up a whole class of automations that GPS can’t touch: lights that follow you, climate control per occupied room, a dashboard that shows the household at a glance.
The second: our housekeeper stays at our place a couple days a week. I don’t want to set up a full HA account for her, install the companion app on her phone, or deal with GPS permissions. But I do need to know if she’s home — because my alarm automation needs to know whether the house is actually empty before arming. Her phone connects to WiFi. That’s all I need.
So I wrote openwrt-ha-presence: a state machine that scrapes RSSI metrics directly from your OpenWrt APs, figures out which room each person is in by signal strength, and publishes per-person home/away state to Home Assistant via MQTT Discovery. No cloud, no beacons, no log parsing, no time-series database. Python, async, ~600 lines of actual logic.
