Blog
Top 10 Categories
Top 10 Tags
Chatgpt Zero Width Space In Copied Commands
What ChatGPT shows:
git add careeros scripts reports tests
git commit -m "Complete ChatGPT export inspection"
What actually gets copied in the clipboard and executed in the terminal:
piranna@Rawr CareerOS % git add caree<200b><200b>ros scripts reports tests
git commit -m "Complete ChatGPT export inspection"
U+200B, ZERO WIDTH SPACE… something
looks phishy. Is ChatGPT also adding watermarks to its generated output?
Beyond the Browser: Running mediasoup-client in Node.js as a Headless WebRTC Endpoint
How mediasoup-client-wrtc turns Node.js into a first-class programmable mediasoup endpoint
Understanding npm Lifecycle Scripts (Once and For All)
Or: how a simple question about
preparevsprepublishOnlyturned into a full-blown reverse-engineering of npm.
Mediasoup DataChannels: When Replacing WebSockets Actually Makes Sense
For years, the default answer for real-time bidirectional communication on the web has been simple:
- Need a chat? Use WebSockets.
- Need signaling? Use WebSockets.
- Need lightweight control messages? Use WebSockets.
And honestly, most of the time, that answer is still correct… although not necessarily the most optimal (I still find XMPP / Jabber a pretty robust alternative, and my default choice for certain scenarios where a battle-tested solution with scalability, resilience and chat features matter).
But while working with WebRTC and SFU architectures, I kept running into the same question:
If we already have a fully encrypted, low-latency, bidirectional transport through WebRTC DataChannels (based on SCTP protocol), why introduce a second parallel communication stack with WebSockets?
How to get all branches from a git remote and push them to a new remote
git push newremote refs/remotes/oldremote/*:refs/heads/*
This command will push all branches from the oldremote to the newremote. The
refs/remotes/oldremote/* part specifies that we want to push all branches from
the oldremote, and the refs/heads/* part specifies that we want to push them
to the newremote as branches.
For tags, that would not be so much complex, just git push newremote --tags
would be enough.
Found at https://www.metaltoad.com/blog/git-push-all-branches-new-remote.
Who Watches the Watchmen? AI Code Generation and the Limits of Code Review
Some weeks ago I read an article that captured something many experienced developers have been feeling for some time: software development is changing rapidly in the age of generative AI, and not always in ways we fully understand.
One quote from the article especially resonated with me in particular:
An MIT professor called AI “a brand new credit card that lets us accumulate technical debt in ways we were never able to before”. That credit card now writes 41% of the code.
Whether the exact number is accurate or not (Stability AI Ex-CEO Emad Mostaque has been saying so since 2023… and he predicts that it will be 100% by end of the decade), the point is clear: a large and growing portion of modern codebases is now generated with the help of AI tools. This has undeniable benefits: developers can prototype faster, explore ideas quickly, and automate repetitive tasks that previously consumed valuable time.
But this acceleration also introduces a structural challenge: we are producing code faster than we can reasonably understand and validate it. Some years ago, AI systems started to be so much more complex that we started to lose track of understand how they think, becoming increasingly opaque. And now that they are starting to write our code, we are in a situation where we start to don’t understand how our code works too, nor how well it does.
In many teams, the question is no longer whether AI-generated code should be used, but how we can maintain quality and reliability when the volume of generated code keeps increasing.
And increasingly, it raises a deeper question: we may start to need AI to review and explain the code generated by AI, but who watches the watchmen?
WebRTC bitrate is not what you think, Part II (Mediasoup edition)
What changes when you add an SFU (Mediasoup) in the middle of the pipeline?
WebRTC bitrate is not what you think
Most WebRTC discussions about bitrate are wrong. Not because people don’t know the APIs, but because they don’t control the experiment.
So instead of asking:
“what bitrate should I use?”
I built something slightly different:
a reproducible WebRTC benchmark to measure how codecs behave under controlled conditions
This is what came out of it.
Mafalda SFU receives “Best Scalable Real-Time Media Platform 2026”
I’m happy to share that Mafalda SFU has been recognised as “Best Scalable Real-Time Media Platform 2026” at the Spanish Business Awards organised by EU Business News.
You can find the official listing at https://www.eubusinessnews.com/winners/mafalda-sfu/, and the announcement published on the project website.
It’s always nice when a side project receives some external recognition, especially one that started mostly as an experiment.
Deterministic Audio Fixtures for End-to-End Testing
Designing Robust Spectral Validation for Audio Pipelines
Testing audio systems is deceptively hard.
Unlike text or structured data, audio pipelines are often lossy, time-sensitive, and highly stateful. Codecs introduce quantization noise, transports introduce jitter, buffers may reorder or drop frames, and decoders may subtly alter timing or amplitude. Traditional byte-level comparisons or waveform diffs are therefore brittle and misleading.
In this article, I present audio-test-fixtures, a deterministic, spectral-based approach to testing audio pipelines end-to-end. The result is a small but robust toolkit that generates known audio fixtures and validates decoded output using FFT-based frequency analysis, designed to work reliably even with lossy codecs and imperfect transports.