Coder Legion - Recent posts tagged showdev

What I've Been Improving Behind the Scenes

Sat, 31 Oct 2026 07:26:42 +0000

Over the past few weeks, I've been spending more time refining Galaxy Movies rather than adding entirely new features.

For anyone who hasn't come across it yet, Galaxy Movies is my movie and TV discovery project. It helps people find titles and check where they're streaming.

A few recent changes have made a noticeable difference to the experience.

Giving the watchlist a better starting point

One thing I wanted to improve was the empty watchlist experience.

Previously, a new user could open the app and immediately be greeted with an empty page. Now the empty state includes a trending section with titles that can be added directly to the watchlist.

The basic idea is to give users something to explore before they've saved anything.

{watchlist.length === 0 ? (
  <WatchlistEmptyState>
    <TrendingRail
      title="Start Here"
      onAdd={addToWatchlist}
    />
  </WatchlistEmptyState>
) : (
  <WatchlistGrid titles={watchlist} />
)}

It's a small change, but it gives people a much better starting point.

I added a progress bar for page transitions so there's better feedback when navigating around the app.

I also fixed an issue with streaming provider filters where search results could briefly appear before the provider lookup finished.

The important part is keeping the loading state visible until the provider lookup is complete.

if (isLoadingProviders) {
  return <SearchLoadingState />;
}

return (
  <MovieGrid movies={filteredMovies} />
);

This prevents users from seeing results that haven't been filtered yet.

Spending more time on the details

I've also been consolidating repeated UI elements into shared components. It's not the most exciting work to show off, but it makes future changes easier and keeps the interface more consistent.

Instead of maintaining separate versions of the same card rail across the app, shared components can handle the common layout.

<CardRail
  title="Trending Now"
  items={trendingTitles}
  renderItem={(title) => (
    <MovieCard
      key={title.id}
      movie={title}
    />
  )}
/>

On the SEO side, I revisited the sitemap to focus on pages that are more useful to search engines.

I also added a yearly streaming changes accumulator to preserve arrivals and departures by provider. This will make it possible to build yearly streaming recaps using data collected throughout the year.

What's next?

I'm still working on improving discovery and making Galaxy Movies more useful without adding unnecessary complexity.

Building a product independently means constantly deciding where time is best spent. Sometimes the most useful improvements aren't new features. They're the smaller fixes that make everything work better.

You can check out the latest version - https://www.galaxymovies.app

Source code is available - https://github.com/NickFasulo/galaxy-movies

If you're building a side project too, I'm curious how much of your development time goes toward new features versus improving what already exists.

Building Knemora: An Open-source, Local-first AI (SI) Second Brain

Fri, 30 Oct 2026 15:23:16 +0000

I’m Federico, a visual designer and full-stack developer.

About six months ago, I had an idea I kept coming back to: could I turn documents and datasets into connected knowledge, explore the relationships visually, and ask questions without sending my material to a cloud inference service?

Why I built Knemora?
After a lot of research, architecture decisions, late nights, and interface iterations, that idea became Knemora.

How it works?
It’s an open-source, local-first AI (SI) Second Brain. You bring your documents and datasets; Knemora compiles knowledge into a portable Markdown wiki, connects pages, and makes that knowledge available through search, a native graph, and chat with source citations.

Architecture:
The diagrams below show the system architecture and the knowledge/inference workflow.

A few choices behind the architecture:

Portable knowledge: Markdown pages with frontmatter and explicit links. The graph is a rebuildable view of those connections.
Local inference: llama.cpp with Qwen3-8B Q3_K_M as the default model.
Retrieval: BM25 search and bounded graph navigation, without a vector database.
Traceability: original documents are preserved, and generated claims carry source references.
Dataset analysis: Polars performs structured calculations, keeping numerical results grounded in computation.

The stack includes Vue 3, FastAPI, Google ADK, SQLite, and Sigma.js/Graphology.

The initial alpha targets macOS Apple Silicon. Node.js 24 with npm is required; the launcher manages the remaining runtimes and model downloads. Initial setup needs internet access, while the core knowledge and inference workflow runs locally afterward. There’s also an isolated demo with interconnected sample knowledge.

As a designer, I care about making the interface clear and the graph useful. As a developer, I care about keeping the underlying knowledge portable and understandable.

Open-source software has helped me throughout my career, and I’m proud to contribute something of my own. This is an early alpha, with plenty left to improve.

Code, documentation, and setup:
github.com/federicolaterra/knemora

Website:
knemora.space

I made my portfolio site audit its own security headers, live, in front of you.

Tue, 27 Oct 2026 21:03:46 +0000

My portfolio has a section that runs curl -I on itself while you watch. Not a screenshot of headers I pasted in last year and forgot to update. The page fetches its own URL, reads the response headers off it, and prints each one ON or missing, right there in the section. If I ever ship a build that drops a header, the page snitches on me the next time someone loads it.

I want to walk through how it works, and then the part that made me rewrite it: the real Content-Security-Policy is not in one place. It is split across two. Showing only the header would have told half the truth, on a page whose whole point is not doing that.

The setup

The site is built with Astro, output fully static, served from Cloudflare. There is a section on the page titled like a shell command. Under it, a list of the security headers I expect the edge to send. The expected list is not hardcoded into the script, it comes from the component:

const expected = [
  'Content-Security-Policy',
  'Strict-Transport-Security',
  'X-Content-Type-Options',
  'Referrer-Policy',
  'Permissions-Policy',
];

Same origin, so the browser is allowed to read the response headers back. That is the whole trick. A fetch to any other site would get its headers hidden by CORS, but a page is allowed to look at itself.

How can a website audit its own security headers live, in the page itself?

The page runs a HEAD fetch against its own URL. Same origin, so the browser lets it read the response headers back, and the card prints which ones are there and which are missing while you watch.

The client script, in full:

fetch(window.location.href, { method: 'HEAD' })
  .then((res) => {
    box.replaceChildren();
    expected.forEach((name) => box.appendChild(row(name, res.headers.get(name))));
    box.appendChild(row('Content-Security-Policy (meta)', metaCsp && foldHashes(metaCsp)));
  })

HEAD, not GET, because I only care about the headers and there is no reason to pull the body again. For each expected header it calls res.headers.get(name). If the value is there, the row renders ON and prints it. If it is null, the row goes missing and gets a different style. No allowlist of "good" values, no grading. It shows what came back.

One detail I care about more than it probably deserves: every cell is built with document.createElement and textContent, never innerHTML. This is a section about security headers. If I XSS my own security section by piping a header value straight into the DOM as HTML, I have earned every bit of the embarrassment. So the header values are text, and text only.

The site also scored A+ on Mozilla's HTTP Observatory, and the hero links straight to that scan so you can re-run it yourself instead of taking my word for the badge. The live card and the external scanner are checking the same thing from two sides.

Why does a hash-based CSP have to live in a meta tag instead of the response headers?

Because only the build knows the hashes, and the headers file is static. Astro computes the sha256- values at build time and writes them into a <meta http-equiv>; if the same policy also sat in the headers, the browser would apply both as an intersection, and a script-src 'self' written there would cancel out the hashes in the meta.

This is where I had to go back and change the card. When I first wrote it, it read the five headers off the response and stopped. Clean, done. Except the meaningful part of my policy, the script-src full of sha256- hashes, lives in the HTML, not in the header the card was reading.

Why not just put the whole CSP in the Cloudflare _headers file and be done? Because then the browser applies both policies as an intersection, and they fight. My _headers file says exactly this, in a comment I left for future me:

# La CSP non sta qui: la genera Astro (`security.csp` in astro.config.mjs) come
# <meta http-equiv>, perché solo in build può calcolare gli hash dei propri script.
# Se una CSP vivesse anche qui, le due policy verrebbero applicate entrambe come
# intersezione: un `script-src 'self'` in questo file annullerebbe gli hash del meta
# e rimetterebbe il sito offline.

A script-src 'self' in the header would intersect with the hash-based script-src in the meta, and the result blocks the very scripts the hashes were meant to allow. Site offline.

So there is exactly one CSP directive that has to live in the header, and it is the one a <meta> tag is not allowed to express: frame-ancestors. Per spec, frame-ancestors inside a <meta> is ignored, so it has to be a real response header. That is the whole content of the CSP header at the edge:

Content-Security-Policy: frame-ancestors 'none'
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Which means my original card, reading only headers, would have proudly printed a Content-Security-Policy of frame-ancestors 'none' and called it a day. Technically true. Also a lie by omission, because it hid the part of the policy that does most of the work.

So the card reads the meta too. It pulls the <meta http-equiv="content-security-policy"> content out of the DOM and prints it as a second CSP row. The hash list is dozens of entries long and useless to look at, so it folds each run of hashes into a count:

const foldHashes = (csp) =>
  csp.replace(/(?:'sha\d{3}-[A-Za-z0-9+/=]+'\s*)+/g, (run) => {
    const n = run.match(/'sha\d{3}-/g)?.length ?? 0;
    return `${n} hash `;
  });

The count is read from the real policy on the page, not a number I typed. If Astro emits one more inline style tomorrow, the number goes up on its own.

What this cost me, honestly

I am mid-level. I did not know going in that frame-ancestors was meta-blind, or that two CSPs intersect instead of one winning. I learned both by breaking the site. There is a manual hash in my Astro config for one inline script, the anti-flash theme script that runs before first paint, because Astro leaves is:inline scripts alone and will not hash them for me:

scriptDirective: {
  resources: ["'self'", 'https://challenges.cloudflare.com'],
  hashes: ['sha256-WV81hIAeXjEdgj/cFIXtOf53g8pIquCjmXQuCHOehlw='],
},

If I touch that script and forget the hash, npm run test:csp fails and tells me the new hash to paste. That test exists because I shipped the mismatch once and the theme script got blocked in production.

The card is not clever. It is a HEAD request, five .get() calls, and one querySelector. What I like about it is that it cannot drift. A README claiming "we set strict security headers" ages the moment someone edits a config. This section re-derives the claim from the live response every time the page loads, and it reads both halves of a policy that lives in two files, because reading one half would make the page a small liar about the one topic it is supposedly honest about.

If you want to try the pattern: same-origin HEAD, read the headers, read the meta CSP too if you have one, build the DOM with textContent. That is the entire thing.

How I Built My Own Opus Clip Alternative With Claude Code

Tue, 27 Oct 2026 10:03:19 +0000

Opus Clip, Submagic and Vidyo all work the same way: you upload a long video, the AI scores every moment for "virality", and you get the clips it likes. That is fine until you want something specific. When I am clipping a podcast for a client I don't want "the most viral 30 seconds". I want "every time they talk about pricing" or "the strongest hook in the first ten minutes".

So I built my own Opus Clip alternative, called Hive Clips AI, with Claude Code. You give it a long video and a plain English prompt, and it transcribes the video, uses an LLM to find the moments that match your prompt, reframes each clip to keep the speaker in shot, burns in word-by-word captions and renders vertical clips ready to post. The prompt drives the selection, not a fixed score. That is the whole difference.

The Hive Clips AI home screen. Drop in a long video or paste a YouTube link.

Here is how it works, stage by stage, and what I would tell you before you try building one.

What does an AI clipping tool actually do?

Strip the marketing away and every clipping tool is the same nine-step pipeline. I built mine so each step runs on its own and saves its result, which matters later.

Stage	What happens	What I used
1. Ingest	Upload a file or paste a YouTube link	yt-dlp, FFmpeg
2. Transcribe	Speech to text with a timestamp on every word	Whisper API, or faster-whisper locally
3. Select	Find moments that match your prompt	GPT-4o with structured JSON output
4. Review	You pick which candidates to keep	Next.js UI
5. Configure	Choose aspect ratio and caption style	Next.js UI
6. Reframe	Track the face and move a virtual camera	OpenCV, PySceneDetect
7. Caption	Build animated word-level captions	ASS subtitles, libass
8. Render	Crop, burn captions, encode	FFmpeg
9. Deliver	Play, download or regenerate	FastAPI + Next.js

The backend is Python with a FastAPI wrapper. The frontend is Next.js 15 with TypeScript and Tailwind. There is also a command line version, which is where I proved the whole pipeline worked before touching the UI.

The nine stages. Select and Reframe are where most of the work went.

How does the AI pick the right moments?

This is the part people assume is magic. It is mostly careful plumbing.

A one hour podcast transcript is tens of thousands of tokens. Sending all of it in one request gives you worse picks, so the transcript is split into 9 minute windows with a 15 second overlap. The overlap is there so a great moment that sits across a window boundary doesn't get cut in half.

Each window goes to GPT-4o with the creator's prompt and a strict instruction: return 2 to 5 clips, each between 20 and 90 seconds, and only clips that genuinely match the intent. The model also rates each clip's hook from 1 to 10, judged on the first three seconds, because that is what decides whether someone stops scrolling.

The output is forced into a JSON schema, so I never have to parse loose text:

{
  "clips": [
    {
      "start_time": 412.3,
      "end_time": 468.9,
      "title": "Why he stopped charging hourly",
      "reasoning": "Direct answer about pricing with a strong opening line",
      "hook_strength": 8
    }
  ]
}

After every window is done, the candidates get merged and re-ranked, and you see them in the review screen. Nothing renders until you pick. That review step is the thing I missed most in the paid tools.

Why is auto-reframing the hardest part?

Turning a 16:9 video into a 9:16 clip means cropping a narrow window out of a wide frame and moving that window to follow the speaker. The obvious way is to detect the face on every frame and centre the crop on it.

That looks terrible. Face detection is noisy, so the crop shakes constantly, and when the video cuts to a different camera the crop slides across the cut like a drunk camera operator.

The fix is to treat the crop as a virtual camera with physics, not a box that snaps to the face:

A critically damped spring. The camera moves toward the face but never overshoots. I ported Unity's SmoothDamp function for this. Smooth time is 0.55 seconds, which feels calm without lagging behind.
A deadzone. If the face moves less than 6% of the crop width, the camera ignores it. This alone kills most of the jitter.
A speed limit. Pans have a maximum speed, so a false detection can't whip the frame across the screen.
Scene cut resets. PySceneDetect finds the hard cuts. At a cut the camera drops its speed and repositions instead of carrying a pan across the edit. Between cuts it must move smoothly.
Headroom. The subject sits about 10% above centre, the way a real camera operator would frame a person.

The camera path becomes a crop track that FFmpeg applies during the render. Face detection itself is a basic OpenCV detector that needs no model download. I kept the smoothing separate from detection on purpose, so I can swap in a better detector later without touching the part that makes it look good.

Real output from the Hive Clips smoother on noisy test data. The camera ignores small jitter and makes one calm pan when the speaker moves.

Picking the output canvas. 9:16 for Reels, Shorts and TikTok, with a live preview on the right.

If you build one of these, spend your time on the smoothing, not the detector. The smoothing is what makes it look professional.

How do the word-by-word captions work?

Most tutorials use SRT subtitles. SRT can't do the captions people actually want on Shorts and Reels, where each word lights up as it is spoken.

I used ASS subtitles instead. ASS supports per-word timing, colours and animation, and FFmpeg burns it into the video through libass. Because the transcript has a timestamp for every word, each word can change colour exactly when it is said.

The tool ships with 24 caption presets. The original 8 cover the basics: a karaoke style, a minimal style, a news bar and an outline style. Then I added 16 styles based on what is working on short-form right now, including a Hormozi-style highlight where the full line shows and the active word recolours, a one-word-at-a-time punch style, and a word reveal where words pop in and stay.

Part of the caption preset grid. Each preset is a starting point you can fine tune per clip.

What broke while building it?

A few honest notes, because build logs that only show the happy path aren't useful.

The web app broke when the CLI didn't. When I added caption overrides (custom colours and sizes per clip), the command line kept working but the web API failed. The database was missing the new column. The fix was a one-line migration, but it taught me to test both entry points every time the data model changes.

Saving every stage paid off. Each of the nine stages writes its result and a job record to the database. So when a render fails, I re-run the render only. I don't wait for the transcription again or pay for the AI selection twice. On a long podcast that is the difference between seconds and many minutes.

Mock mode made testing free. Without an OpenAI key, the tool runs with a stand-in transcript and a simple moment picker, but reframing, captions and rendering are fully real. I could test the hardest parts of the pipeline all day without spending anything on API calls. The UI labels mock mode clearly so stand-in output is never mistaken for real picks.

How did Claude Code fit in?

I wrote a product spec first: the nine stages, the five screens, and the rules for each step. Then I built it with Claude Code one stage at a time, starting from the command line and proving each stage worked before moving on.

Two habits made the biggest difference:

Interfaces before infrastructure. Storage, the job queue, the database and the AI provider each sit behind a simple interface. Right now it runs on SQLite, local files and a local queue. Moving to Postgres, Cloudflare R2 and a proper job queue means swapping one piece at a time, not rewriting the app.
Pure maths in its own file. The camera smoother has no video code in it at all. That made it fast to test and easy for Claude Code to reason about, which is exactly where you want precision.

If you are new to building with Claude Code, my beginner's guide to building an app with Claude Code covers the setup, and Claude Code pricing and free options covers what it costs to run.

What is next for the tool?

The current build is the full pipeline plus the web UI. On the list:

Sharper cut handling. Right now the reposition at a cut uses the last face position from before the cut, so on a hard camera change the frame catches up a beat late. The fix is to look ahead to the first detection after the cut.
Live progress updates instead of polling every 1.5 seconds
Regenerating only the captions or only the reframe, instead of the whole clip
Speaker detection, so two-person podcasts can get a split-screen layout
Running transcription and selection fully locally, with no API costs
Auto-posting finished clips to TikTok, Instagram and YouTube Shorts

Frequently asked questions

Is there a free Opus Clip alternative?

Yes, if you are willing to run it yourself. Open-source pieces like Whisper (transcription), FFmpeg (rendering) and PySceneDetect (scene cuts) are free, and that is most of a clipping tool. The paid part is usually the AI moment selection, and you can run that on a local model to bring the cost close to zero.

How does Opus Clip choose which moments to clip?

Opus Clip and similar tools score moments with their own virality model and give you the top picks. You can't tell them what to look for beyond basic settings. A prompt-driven tool like mine lets you describe the moment you want in plain English.

Can GPT-4o pick good clips from a transcript?

Yes, if you give it structure. Split long transcripts into overlapping windows, ask for a fixed number of clips with strict start and end times, and force a JSON schema. Then review the picks yourself before rendering. It is good at finding topics, less reliable at judging delivery, which is why the review step matters.

What is the hardest part of building an AI clipping tool?

Reframing. Detecting a face is easy. Making the crop move smoothly, without jitter, without overshooting and without sliding across scene cuts, is where most of the work goes.

Do I need a GPU to run it?

No. Local transcription uses faster-whisper, which runs on a CPU, and the face detector is lightweight. A GPU makes encoding faster, and the renderer will use one if you have it.

If you want a clipping pipeline like this built for your channel or agency, get in touch.

Originally published on danishsofi.in.

Launching a fancy text converter: 451 styles, and the Unicode edge cases behind them

Tue, 27 Oct 2026 09:22:36 +0000

I'm Shawn Sun, a front-end engineer, and I just put a fancy text converter online. This is a developer community, so here are the parts that were fun to build instead of a feature list.

You type once and get 451 copy-and-paste styles. Tap one to copy it, and the last 8 you copied come back under Recent. No sign-up. None of these are fonts: every style is real Unicode characters, and that caused most of the work below.

1. A style is mostly a lookup table

Bold, italic, script, Fraktur and the rest live in the Mathematical Alphanumeric Symbols block, so most styles are "offset of A, plus the letter's index".

2. The block has holes

Some letters were encoded earlier elsewhere, so their slot is empty. A naive base + index gives you a box, so each style carries a small exceptions table.

3. Accents: decompose first

There is no bold é. I split it with NFD, style the e and keep the accent after it. Whether the accent then sits on top depends on the font.

4. Don't split emoji

Walk a string by code point and 👩💻 falls apart. I cut input into grapheme clusters with Intl.Segmenter and only style plain letters and digits.

5. Long input: preview first, convert on copy

Rendering every style live is fine for a username and slow for a pasted paragraph. Past 200 UTF-16 code units, each card previews only the start, and the full text is converted when you copy.

Honest limits

Conversion runs in your browser. I count anonymous usage events, such as which style was copied, but your text isn't part of them.

I'd like your feedback

Which category is missing, and do the style names make sense? Try your own text on the live site and tell me in the comments.

— Shawn Sun

I built PinOps to turn a published URL into useful Pinterest pins

Tue, 13 Oct 2026 15:47:07 +0000

I kept losing afternoons after an article was already live.

Pinterest still needed useful pins from that URL: more than one angle, vertical creatives that match the destination, titles that stay honest to the link, and a queue that does not dump twenty pins in a day. The calendar was never the hard part.

So I built PinOps.

Paste a published URL. Get useful pins. Edit what needs a tweak. Queue what you keep.

https://pinops.app

Freemium. Bootstrapped. I built it because I was tired of rebuilding that path every time a post went live.

If you have tried to turn a blog into a Pinterest system, I want to hear where the time actually goes.

I Tried to Build Persistent Compute on an Xbox SSD. The Failed Tests Changed the Architecture.

Mon, 12 Oct 2026 21:54:26 +0000

The Xbox wrote 8 GiB of persistent data.

I still couldn't call the experiment successful.

The bytes were there, but the operation failed because a completely different part of the system had timed out. In another test, the worker correctly refused to allocate more storage even though its configuration technically allowed a much larger workload.

Eventually, the experiment passed. But getting there required much more than writing files to an SSD.

I had to investigate how Xbox processes share resources, build a separate coordination component, introduce a recoverable page store, survive real application restarts, and learn which failures were bugs and which were legitimate platform boundaries.

This is one of the experiments behind XCP that I hadn't explored in the previous articles.

The five-part XCP series ended with the platform becoming open source. This bonus chapter goes back into the original Xbox research to explain how I approached persistent computation inside the Developer Mode sandbox.

The problem wasn't just memory capacity

In the earlier experiments, XCP measured an application memory budget of 5 GiB in one Xbox Series X Developer Mode configuration.

That was useful. It gave us an actual resource boundary for the worker rather than a number inferred from the console's hardware specifications.

But it also raised another question.

What happens when the work I want to execute is larger than the memory I can keep resident?

I wasn't trying to bypass the sandbox or convince the Xbox that its SSD was additional physical RAM.

I wanted to build something different: an execution system that could keep data and completed work in persistent storage, bring bounded pieces into memory, process them, and continue from a valid checkpoint after an interruption.

Before building the storage layer, though, I had another hypothesis to investigate.

Could a second process help?

First, I investigated the Xbox process model

XCP already had a foreground worker capable of running CPU and GPU workloads.

I wanted to understand whether another process inside the same UWP package could perform useful background coordination without consuming the worker's entire resource budget.

The candidate was an out-of-process App Service.

On desktop Windows, creating another process might seem straightforward. On Xbox Developer Mode, I wasn't going to assume that the desktop behavior applied unchanged.

So I started measuring.

The first live probes established that the worker and an auxiliary App Service could run with distinct process and activation identities. They exchanged messages, maintained independent heartbeat activity and retained touched, verified memory during overlapping execution windows.

That was already useful.

But it did not prove that we had discovered a second independent 5 GiB memory budget.

To investigate properly, I built an eleven-phase matrix covering CPU execution, verified GPU execution, simultaneous activity, progressive memory pressure, bidirectional storage visibility, suspension, termination, restart, redeployment and cleanup.

And this is where the testing started getting complicated.

The first failures weren't even storage failures

Worker .150 reached the Xbox but exposed incomplete measurement data. It could report IPC latency summaries, yet the acceptance contract required the underlying distribution, including median, p95 and bidirectional throughput.

There was no legitimate way to reconstruct missing measurements afterward.

So that run remained diagnostic.

Worker .151 produced another interesting failure: 79 of 81 preflight checks passed.

The two failures came from heartbeat validation.

The foreground heartbeat ran at 25 ms intervals. The auxiliary broker used a 100 ms timer. During an approximately 935 ms observation window, the broker produced nine ticks.

The test incorrectly expected 32 because it had reused the foreground count.

The broker wasn't failing to run. Our expectation was wrong.

That candidate stayed failed, and the next version corrected the measurement contract.

Worker .152 passed the preflight, but memory-pressure testing exposed another gap. The Xbox refused a bounded allocation, yet the error didn't carry enough structured information to establish the responsible component, observed headroom, applied reserve and cleanup outcome.

A text error saying that memory allocation failed wasn't sufficient to classify the platform behavior.

Worker .153 added the missing observations.

The completed matrix passed all eleven phases, retaining fourteen actual attempts in its evidence history.

The separate classification step selected Case B: a distinct but resource-limited useful process.

That result changed the design.

I didn't have evidence for a second large compute process. But I had enough evidence for a small coordination service.

That was what I built.

The second process became a coordinator

Instead of creating another general-purpose worker, I gave the auxiliary process a narrower responsibility.

It could participate in lifecycle observation, heartbeat management and storage reservations.

The main worker still controlled execution admission, semantic verification, recovery authorization and final result publication.

This separation mattered because the broker could disappear and restart independently.

A reservation could not simply be assumed valid because some old record said it existed.

The worker had to validate the reservation identity, generation and storage plan before accepting new work.

Worker .154 tested this arrangement on the physical Xbox.

55 of 55 checks passed, with zero violations.

The useful result wasn't more RAM.

It was an operational coordination mechanism on which persistent computation could be built.

Next, I needed storage that could survive failure

Writing a file is easy compared with deciding whether that file represents completed computation.

Imagine a workload producing hundreds of output pages.

The application writes a page, updates some metadata, and then disappears.

After restarting, which pages can be trusted?

Did a page finish writing? Does its recorded hash match the bytes? Was its journal entry committed? Can the computation resume from that point without silently skipping or duplicating work?

For XCP, I built the storage system around content-addressed data and an append-only journal.

Each committed page had an identity derived from its content. The journal recorded ordered transitions, with records linked through hashes.

A page was not considered committed just because its file existed.

The system had to verify the relevant content and metadata before including it in the committed sequence.

Recovery worked from the longest valid committed prefix. Anything beyond that boundary could not silently become trusted state.

That approach allowed the runtime to distinguish a completed checkpoint from bytes left behind by an interrupted operation.

Then I tried breaking it

Worker .155 exercised the page store and recovery system on Xbox.

The tests included truncated journal entries, corrupted hashes, missing pages, incomplete root manifests, conflicting page identities, exhausted quotas, stale reservations and repeated cleanup.

The live campaign also tested recovery after worker restart, auxiliary restart and package redeployment.

One deployment experiment uncovered an unexpected problem.

An in-place installation using the same package version left the application running, but Xbox Network Isolation silently dropped the inbound worker connection.

The correction was not to pretend the storage operation had succeeded.

We used a clean uninstall with application data preserved, reinstalled the exact package, restored connectivity and verified that the committed storage root had survived.

The complete .155 campaign eventually passed 248 of 248 checks.

At this point I had a storage substrate capable of preserving committed data through the tested failure and lifecycle scenarios.

But I still hadn't demonstrated useful persistent computation.

That required the next experiment.

Running computation through persistent storage

For the first workload, I reused an existing XCP test called Provable Worlds.

It produces a deterministic field of 1024 × 1024 unsigned 32-bit values.

The complete result is only 4 MiB.

That may sound small for an SSD experiment, but this test wasn't intended to prove beyond-RAM scale yet.

I wanted to establish that computation could be divided into independently checked units, committed in order, interrupted and resumed correctly.

The field was divided into 256 tiles of 16 KiB each.

Each tile had a known global position in the output. The signed CPU Capsule could compute its bounded portion, and XCP compared that result against the CPU reference.

The runtime used bounded output buffers rather than requiring the complete result to stay resident.

The important condition was that the durable cursor advanced only after a page had been committed successfully.

The first uninterrupted runs passed. Restart failed.

Worker .156 completed two uninterrupted executions.

Then I tested the restart path.

Both real-restart resume attempts failed.

The problem was the reservation lifecycle.

After the foreground interruption, the system attempted to continue using the old coordinator lease. But that lease belonged to the previous activation.

This contradicted what the earlier process-topology experiments had already shown.

Persistent data could survive the interruption.

A live process reservation could not be treated the same way.

So I separated those two concepts.

The committed journal retained its original storage identity and generation. A resumed worker had to obtain a fresh live reservation, with a newer generation, and reauthorize the persisted work before continuing.

Worker .157 implemented that correction.

The test deliberately committed the first 128 tiles, computed the next tile without committing it, and interrupted execution.

After the real restart, the worker verified the committed prefix, skipped those first 128 tiles and computed the remaining 128.

It reproduced the expected final field hash.

The uninterrupted tests, restart/resume path, cleanup and same-package regression checks passed.

XCP admitted that specific bounded persistent-compute capability.

One distinction is worth keeping: the tiled execution used the signed CPU Capsule, not a newly implemented GPU-tiled engine. The existing GPU path was checked separately. Nor did this test demonstrate performance gains from asynchronous I/O overlap.

It demonstrated correct bounded computation and recovery.

Now I wanted to investigate the storage scale.

Eight gigabytes, and another failed experiment

For the scale test, I moved to a different page geometry.

Instead of the 16 KiB computation tiles, the storage characterization used 4 MiB pages.

The target was 8 GiB: exactly 2,048 pages.

I also defined a progression through 256 MiB, 512 MiB, 1 GiB, 2 GiB, 4 GiB and finally 8 GiB.

The data was generated deterministically, with page-specific content, so the test could verify distinct pages without treating a single repeated blob as proof of physical growth.

And there was a safety condition: the operation had to preserve 16 GiB of reported available storage as a reserve.

Then came worker .158.

The worker materialized the full 8 GiB.

But the operation failed.

After more than 163 seconds of storage work, the coordinator attempted to release its reservation using an IPC deadline that had been established at the beginning of the operation.

That deadline was only 30 seconds.

The data had been written, but the protocol could no longer complete the operation correctly.

This was not an accepted result.

I corrected the lease-release timeout handling, added an explicit cleanup path for the failed run and tested again.

Worker .159 successfully committed all 2,048 pages.

The measured seed operation took approximately 164 seconds.

That is an end-to-end operation time, including page generation, hashing, storage and journal work. It isn't a raw SSD throughput benchmark.

But .159 was not the final success either.

The 64 GiB attempt was refused

The broader storage policy allowed much larger declared reservations, so I also tested what happened when the system attempted to continue beyond the 8 GiB seed.

The remaining planned growth was 56 GiB.

The platform-reported filesystem space was nowhere near sufficient for that growth plus the required 16 GiB safety reserve.

The worker returned:

STORAGE_SCALE_PLATFORM_HEADROOM_REFUSED

And crucially, it refused before writing additional data.

The existing workspace remained unchanged. Cleanup subsequently removed the 8 GiB seed and a second cleanup confirmed that the namespace was already absent.

This result did not establish that the Xbox SSD had a 64 GiB limit, or that the entire physical SSD was visible to the application.

The application had observed a much smaller storage filesystem, approximately 32.2 billion bytes of reported capacity in that test.

The configured storage quota was not the same as actual platform capacity.

The refusal was correct.

Instead of trying to force a larger allocation, I froze the demonstrated 8 GiB size as the target for the final characterization.

The result: worker 0.1.160.0

Worker .160 was built and signed as a new exact package and tested on the physical Xbox.

This time, the process completed the full storage lifecycle.

It committed 2,048 distinct 4 MiB pages, totaling 8 GiB, then released the reservation.

I returned to the Xbox Home screen and resumed the worker without power-cycling the console.

The resumed worker obtained a fresh reservation generation, recovered the persisted namespace, reread and rehashed the complete 8 GiB, and committed the ordered root without allocating another storage rung.

A separate verification operation then read the complete data again under another fresh lease and reproduced the same root identity.

Finally, cleanup removed the 2,048 unreferenced blobs and all 8 GiB of their content.

A second cleanup found nothing left to remove.

The complete .160 lifecycle passed its checks.

That was the accepted storage-scale result.

Not 64 GiB. Not the console's full SSD. Not virtual RAM.

Eight GiB of bounded, recoverable, content-verified persistent storage, measured through the actual Xbox worker lifecycle.

What this proves, and what it doesn't

The completed experiments establish two related capabilities.

First, XCP demonstrated a persistent-compute workflow in which deterministic tiled execution could survive a real worker interruption, verify previous committed work and resume without recomputing the valid prefix.

Second, it demonstrated an 8 GiB persistent storage namespace with recovery, full-root verification and cleanup on the physical Xbox.

These were separate tests.

The 4 MiB computation experiment did not prove that an arbitrary dataset larger than RAM could be processed end to end.

The 8 GiB storage experiment did not prove an 8 GiB GPU or CPU workload, transparent paging, unrestricted SSD access or a performance-optimized streaming engine.

In fact, the recorded streaming runtime exposed no measured prefetch/compute overlap advantage. The bounded buffers, ordered commits and recovery path were the capabilities being established.

Combining those pieces into larger real workloads is further engineering work, not something I can claim was already completed.

But the distinction between demonstrated components and future integration doesn't make the result less interesting.

It tells me which parts of the problem are actually solved.

Why the failed tests mattered more than the number

Looking back, there wasn't one dramatic failure.

There were several small, independent ones.

The auxiliary process existed, but didn't prove an independent memory budget.

The heartbeat worked, but the test expected the wrong number of ticks.

Memory pressure produced a refusal, but not enough structured evidence to classify it.

The storage layer survived, but an installation sequence disrupted the worker connection.

Computation succeeded uninterrupted, but couldn't resume under the old lease.

Eight gigabytes were written, but the IPC timeout invalidated the operation.

And a larger storage request was refused because the available space could not satisfy the reserve.

Each result forced a different correction.

Some changed the implementation. Some changed the measurement contract. One changed the resource-topology decision. Another changed the scale we were prepared to claim.

I think this is one of the most interesting aspects of XCP.

It didn't become more capable by assuming the Xbox restrictions were irrelevant.

It became more capable by discovering which capabilities could be combined reliably inside those restrictions.

The result was not a magic way to make SSD behave like RAM.

It was a storage and recovery architecture that allows computation to have a durable history independent of the process that produced it.

The code is now open source

The original Xbox experiments were performed in the historical XCP research environment.

The public repository contains reconstructed reference implementations and the source needed to inspect the design, including:

The distinction between the original historical results and the newly reconstructed development packages remains important.

The public source lets developers inspect and rebuild the relevant components. The historical hardware results belong to their original package versions and evidence records.

Newly reconstructed packages do not automatically inherit those physical-Xbox results. They require their own device validation.

That boundary is explained in the public reconstruction audit.

Beyond the SSD experiment

XCP started as an attempt to make an Xbox Series X a programmable execution target.

The project eventually expanded into a virtual machine, CPU/GPU execution, agent-driven development, a desktop studio and tools for adapting and building software.

The SSD experiments explored another necessary part of that picture.

A useful execution target needs more than the ability to run a program once.

It needs a way to preserve work, recover from interruption and continue under a new execution context without pretending that the old one still exists.

The most valuable result of this experiment wasn't the eight-gigabyte figure by itself.

It was the realization that the lifetime of a computation does not have to be identical to the lifetime of the process executing it.

On this particular Xbox, we demonstrated some concrete parts of that idea.

And as with the rest of XCP, the next meaningful step is to take those capabilities into a more demanding workload and find out where they stop being sufficient.

XCP is open source

GitHub: https://github.com/Daniele-Cangi/xcp-xbox

XCP Studio: https://xcpstudio.com/

I turned strings into letter arrays and started rebuilding URLs with index ranges

Fri, 09 Oct 2026 22:09:28 +0000

I was just playing with a tiny idea:

What if every string was just an array of single characters… and I could pull pieces out by index ranges to form words, paths, or API links?

That experiment became string-range-tokens — a zero-dependency ESM package that does exactly that.

The core idea

import { toTokens, sub, build } from 'string-range-tokens';

const t = toTokens('https://api.example.com/v1/users');

sub(t, 0, 4);                 // "https"
sub(t, 23, 25, [26, 31]);     // "/v1/users"
sub(t, -5, -1);               // "users"   ← negative indexes work
build(t, [0, 4], [23, 25]);   // "https/v1"

toTokens turns any string into a proper array of characters (Unicode-safe).
sub and build let you reassemble any combination of inclusive ranges.

Why bother?

Sometimes you want to:

Assemble API paths or query fragments from a shared token pool
Avoid writing the full string literal in one place
Pick substrings by position without regex
Build tiny string “templates” from a fixed alphabet
Teach indexing, ranges, and a bit of recursion in a playful way

It’s not encryption (never hide real secrets with it). It’s just a clean, lightweight way to work with strings as letter arrays.

Extra powers

`plan` – find the ranges that rebuild a target

const pool = toTokens('the quick brown fox');
const ranges = plan(pool, 'brew');
build(pool, ...ranges); // "brew"

`scatter` / `gather` – seeded shuffle + reconstruct

const { pool, key } = scatter('/api/orders', 7);
gather(pool, key); // "/api/orders"

Useful for deterministic scrambling when you want both the shuffled tokens and a way to put them back together.

Install

npm i string-range-tokens

Or just copy the source — it’s a single file with no dependencies.

Works in Node 18+, Deno, Bun, and the browser.
Both JavaScript and TypeScript implementations are included.

CDN:

import { toTokens, sub, build, plan, scatter, gather } 
  from 'https://cdn.jsdelivr.net/npm/string-range-tokens@1.0.0/src/index.js';

I Added a Chatbot to My Movie Discovery App

Thu, 08 Oct 2026 22:45:14 +0000

I recently added a chatbot feature to Galaxy Movies, my movie discovery app.

The idea came from a problem I run into all the time: there are too many movies to choose from, and browsing doesn’t always help.

You can scroll through trending lists, genres, ratings, and streaming options, but sometimes what you really want is to ask a simple question: “What should I watch tonight?”

So I built Galaxy Bot.

Galaxy Bot is a conversational movie assistant that helps users find movies based on what they actually want in the moment. Instead of only relying on filters, users can describe their mood, who they’re watching with, how much time they have, or what kind of movie they’re trying to avoid.

Some example prompts:

“Recommend a feel-good movie under two hours.”
“I want a sci-fi movie that isn’t too confusing.”
“What should I watch with my family?”
“Give me something tense but not horror.”

The main thing I focused on was making the chatbot feel useful without getting in the way. It should make discovery faster, not make the app feel heavier.

This first version is about helping users get unstuck when they don’t know what to watch. Over time, I’d like to make it better at understanding taste, saved movies, ratings, and streaming availability.

You can check it out here: Galaxy Movies

XCP: From an Xbox Experiment to an Open Development Platform

Thu, 08 Oct 2026 10:54:36 +0000

XCP — Chapter 5
In the previous chapters, I wrote about turning an Xbox Series X into a programmable execution target, building a virtual machine inside its sandbox, connecting AI coding agents to real hardware, and measuring the memory and GPU capabilities available in Developer Mode.

Those articles explained individual parts of XCP. This final chapter is about what they were all leading toward.

The goal was never simply to run AI-generated code on an Xbox. The goal was to build a development platform around the console, one that independent developers could eventually extend with familiar tools, engines and frameworks.

That distinction matters because XCP now contains considerably more than the compute worker that started the experiment.

It includes a programmable runtime, a desktop development environment, an execution and evidence system, Godot adaptation research, a native graphics pipeline and procedural worlds generated from WorldLoop.

Each of those components grew out of a practical experiment. Together, they suggest a different way of approaching console development.

From hardware research to a development platform
The first question was relatively simple: how much useful computation could we perform on an Xbox Series X without bypassing its security model?

XCP began inside the supported Developer Mode application sandbox. We explored memory allocation, persistent storage, CPU execution, GPU compute, graphics rendering and communication with a development PC.

Those experiments produced measurable results, including a 5 GiB application memory budget in one tested configuration and more than 7.7 TFLOP/s in a bounded FP32 shader workload. We also built XVM, a verifiable execution environment capable of running admitted programs and returning structured execution evidence.

But the more interesting possibility emerged after those foundations were working.

We already had a console that could receive structured work, execute it, report its state and preserve a history of what happened. The next logical step was to use that infrastructure for complete software projects rather than isolated compute workloads.

That decision changed XCP from a hardware research project into a creative-platform project.

Three Godot games, three different problems
One of the most important parts of the original XCP research was adapting existing Godot projects into bounded, playable experiences on the Xbox.

Rather than using a single demonstration designed specifically for the platform, we worked with three substantially different games.

Blokki — a 2D puzzle
Blokki gave us a compact starting point for testing scene interpretation, grid interaction, controller input and gameplay feedback.

The adaptation translated pointer-based interactions into a controller-driven grid, replaced some presentation elements with procedural drawing and preserved a bounded playable puzzle loop.

The Xbox playability checks covered rendering, controller response, valid and invalid action feedback, and the usability of the interaction loop.

Minedot — a 3D voxel-style sandbox
Minedot introduced a different class of problems: a 3D environment, camera navigation, spatial interaction and mining or placing blocks.

Its playable reconstruction used the left stick for movement, the right stick for looking around and bounded controller actions for interacting with the world.

Some source dependencies were incomplete, so the Xbox implementation used declared substitutions rather than pretending that the original game had been reproduced completely.

The resulting bounded experience was tested on physical hardware, including movement, camera control, interaction feedback and visual usability.

Open RTS — a more complex 3D strategy game
Open RTS pushed the experiment further.

This time the adaptation involved a strategy environment with unit selection, movement, combat, interface visibility and a victory condition.

The first physical test exposed presentation problems. Rather than simply accepting a successful launch, we corrected the interface behavior and performed another test.

The revised version passed its bounded playability checks, including selection, movement, combat and victory feedback.

Across these three projects, the research recorded 3/3 bounded playable reconstructions, 15/15 human playability checks and 17 captures.

These results do not establish full source equivalence or universal Godot compatibility. The reconstructions used explicit substitutions, and additional work remains before an arbitrary Godot project can pass through the system without project-specific adaptation.

What they do establish is that the approach was exercised across a 2D puzzle, a voxel-style 3D sandbox and a more complex 3D strategy game on real Xbox hardware.

That is a useful foundation for developing reusable engine adapters instead of continuing to create isolated ports.

Forge: when WorldLoop met Xbox
Godot adaptation was not the only creative experiment.

Another branch of the original research connected XCP with WorldLoop, my procedural CAD and world-generation project.

WorldLoop was originally developed around procedural construction and scene generation. Buildings, structural relationships and larger environments could be generated from structured rules rather than manually assembled one object at a time.

I wanted to see whether that same approach could produce content for a completely different execution environment.

This led to Forge Protocol, a native Xbox graphics and gameplay experiment using Direct3D 11.

The important architectural decision was to keep generation on the development PC. WorldLoop produced structured environments, which were then compiled into bounded native assets that the Xbox application could load and render.

The console did not need to run the original generator or its development dependencies.

The pipeline was approximately:

WorldLoop procedural generation

         |
         v

Structured world + geometry

         |
         v

PC-side asset compilation

         |
         v
Forge scene bundle
         |
         v

Xbox native D3D11 runtime

         |
         v
Rendering + gameplay

The experiments progressed beyond simple geometry.

Orbital Forge Alpha demonstrated a WorldLoop-generated scene on Xbox, while Orbital Forge Beta expanded the environment into thousands of render parts, multiple placed structures, roads, structural relationships and a larger native scene bundle.

The Beta world contained 2,364 render parts and compiled into 56,736 vertices and 28,368 triangles. It was installed and launched on the physical Xbox, with further iterations addressing scene scale, composition and gameplay readability.

This mattered for a reason beyond the visual result.

The same console execution target was receiving content from a procedural world generator that had not originally been designed for Xbox.

Forge was not proof that every procedural engine could automatically run on the platform. It demonstrated one workable boundary between external generation and a native console runtime.

For XCP, that boundary is important. Different authoring environments should not necessarily require completely separate execution infrastructures.

XCP Studio: one project, shared by humans and agents
The next part of the platform was the development experience.

XCP Studio was designed as a Windows desktop environment where a developer, a visual interface and an AI coding agent can operate against the same project representation.

Rather than giving each interface its own interpretation of the software, the project has a shared structure and explicit contracts.

A project can declare its modules, assets, required capabilities and runtime configuration. XCP validates these declarations against the capabilities actually exposed by the execution target.

The development cycle is:

Developer / coding agent

       |
       v
Editable XCP project
       |
       v

Validate + build bundle

       |
       v
 Install on Xbox
       |
       v
Launch + interact
       |
       v

Observe + capture evidence

       |
       v
 Revise or rollback
       |
       +------> Next iteration

The desktop environment is not merely a dashboard for a worker.

It is intended to become the place where software is created, adapted, tested and evolved.

The original research has already measured an end-to-end XCP Studio Technical Preview workflow on physical Xbox hardware, including project validation, installation, activation, launch, interaction and capture.

The packaged preview still requires further clean-machine validation and release preparation. It should not be confused with a generally available finished product.

Nevertheless, the essential development loop has been exercised.

Why this could matter commercially
There is a practical audience for a platform like this: independent developers, small studios, technical artists, researchers and people who want to experiment with interactive software on real console hardware.

For many of them, the difficult part is not necessarily writing the first prototype. It is managing the gap between a familiar development environment and the constraints of a different execution target.

A useful platform could reduce that gap.

Imagine creating a small project with an existing engine, adapting it through a community-maintained integration, running it on an Xbox in Developer Mode and receiving structured feedback from the actual device.

The developer could then revise the same project and repeat the cycle without rebuilding a separate workflow for every experiment.

That would be particularly useful during early prototyping, when ideas change frequently and fast iteration is often more valuable than elaborate release infrastructure.

There are already official development paths for engines such as Godot and Unreal Engine. XCP is not intended to replace Microsoft's commercial publishing programs, nor does it grant access to restricted console capabilities.

Its proposed value is different: an open, reusable prototyping and execution environment built around the capabilities available to it.

The long-term ambition is to support increasingly complex projects and established frameworks through reusable adapters and runtime components.

Godot is a natural starting point because we have already conducted adaptation experiments. Unreal Engine and other major frameworks represent possible future integration work, not compatibility that XCP can currently claim.

And I do not think this requires waiting until every feature of a major engine is supported before the platform becomes useful.

A carefully defined subset that developers can actually build, execute and test may already provide value.

Why I made XCP open source
The original repository grew into a laboratory containing hardware probes, multiple generations of runtime experiments, creative projects, integration prototypes, successful tests and failed approaches.

It was useful for research, but it was not a particularly good starting point for external contributors.

That is why I extracted a separate public XCP repository around the reusable components: project contracts, XVM, source adapters, semantic infrastructure, execution evidence, conformance tests and development tools.

The public repository is not a complete copy of the original laboratory. Third-party game sources and assets are excluded, and historical Xbox results must not be presented as fresh verification of newly reconstructed binaries.

The next stage also cannot depend entirely on me building every integration.

For XCP to become a genuine platform, the community needs to be able to extend it.

That could mean implementing another source adapter, contributing rendering functionality, improving Godot support, building conformance tests, introducing a different runtime or exploring another execution target.

The project deliberately separates source interpretation, execution contracts and target-specific capabilities because those are the areas in which independent contributions could eventually make the largest difference.

I am not assuming that every abstraction is already general enough. In fact, one of the reasons to involve outside developers is to discover where the architecture still contains assumptions inherited from the original Xbox experiments.

A platform becomes interesting when people can build things its original author did not anticipate.

What remains to be done
The historical research demonstrates several important capabilities, but turning those capabilities into a broadly usable development platform requires another kind of engineering.

The public toolchain needs reproducible validation against the hardware. The desktop application needs a straightforward installation and onboarding experience. Framework adapters need to become more general, and new projects must be tested without relying on prior knowledge of their structure.

That last point is especially important.

We have demonstrated bounded playable reconstructions of three Godot games. The next significant result would be an independent developer taking a previously unseen project through the adaptation and execution process, with a clear record of which features work, which require substitutions and which remain unsupported.

That would measure something different from the historical experiments: the usefulness of XCP as an extensible development tool.

There is also substantial room for the community to explore beyond games. Interactive scenes, simulations, procedural environments, educational software and GPU-driven experiments all fit the same general direction.

The platform should grow according to what can actually be implemented and measured, rather than a fixed list of promises.

The bigger idea behind XCP
Looking back, the development of XCP followed a somewhat unusual path.

It started with an Xbox and a question about its computational capabilities.

That led to memory and GPU experiments, a virtual machine, verified execution, AI-agent integration, a creative runtime, Godot adaptation, procedural worlds and finally a desktop development environment.

None of those individual components tells the whole story.

XVM is not the final product. GPU compute is not the final product. Forge and the Godot experiments are not separate destinations.

They are different parts of a larger effort to make real hardware available as a practical, programmable and verifiable development target.

The long-term vision is an open platform where developers can bring familiar tools, the community can expand the supported capabilities, and AI agents can participate in development without replacing the developer's authority over the project.

The Xbox Series X is the first physical target because that is where the experiment began and where the current evidence exists.

It does not have to be the last.

And that is why I think XCP has a meaningful future beyond its original hardware research.

Not because it already supports every engine or solves every problem in console development, but because it has established several working pieces of an environment that independent developers could help turn into something substantially larger.

The next interesting result will not be another benchmark produced by me. It will be something built by somebody else using XCP.

That is what I would like to see the project become.

XCP is open source
GitHub: https://github.com/Daniele-Cangi/xcp-xbox

XCP Studio: https://xcpstudio.com/

The public repository contains the extracted platform, reference implementations, contracts and verification tooling. The original Xbox research provides historical hardware evidence, while new builds require validation against their own exact artifacts.

Contributions, experiments and technical discussion are welcome.

This is the final chapter of the XCP introduction series. The development itself continues.

I’m in High School and I Built VBX: A Modern, Compiled Successor to Visual Basic 6

Tue, 06 Oct 2026 11:31:00 +0000

Hey DEV Community!

Remember the 90s and early 2000s? You'd open a simple program, drag a button onto a form, write a couple of readable lines of code, hit Run, and a real, working .exe popped up instantly on your screen.

No 500MB of node_modules. No broken Python virtual environments. No 40GB Visual Studio installation. Just pure, unadulterated programming joy.

Microsoft killed Visual Basic 6 back in 2008. But as a high school student who fell in love with that retro, productive paradigm, I decided to spend my nights building a modern answer for 2026: Meet VBX (Visual Basic X) ⚡.

️ What is VBX?

VBX is not a toy interpreter running inside Python.

It’s an open-source, high-performance compiler written in pure Go that translates clean, human-readable Basic syntax directly into standard C99. The generated C code is then compiled via GCC or Clang with -O2 optimizations into a standalone native binary with zero runtime dependencies.

.vbx Source Code ➔ [ VBX Parser (Go) ] ➔ Standard C99 Code ➔ [ GCC/Clang -O2 ] ➔ Native Binary (.exe)

A Quick Taste of VBX

Here’s an interactive program in VBX that takes user input, shows native OS popups, and writes data to disk:

' Interactive App in VBX
Dim userName = InputBox("Please enter your name:", "Registration")

' Display native OS alert (Windows, Mac, or Linux)
MsgBox "Hello, " & userName & "! Saving your data...", "Welcome"

' Native File I/O
Dim logFile = "user_data.txt"
File.Write logFile, "Registered User: " & userName

' Read it back and verify
Dim savedContent = File.Read(logFile)
MsgBox "Verified from file: " & savedContent, "Success"

You run it with:

vbx run app.vbx

Or compile a release binary ready to distribute:

vbx build app.vbx -o my_app

⚡ Under the Hood (The Engineering)

As someone passionate about systems programming, I wanted VBX to be rock-solid:

Zero External Dependencies in Compiler: The Go compiler relies strictly on Go's standard library (bufio, strings, regexp, os/exec).
Memory Safety (No Heap Leaks): Instead of naive malloc calls for string concatenation, the generated C runtime uses a static ring-buffer memory pool (vbx_alloc_str)—a technique borrowed from classic game engines (like Doom). It chews through 10,000 loop iterations with flat, zero-leak memory usage.
Multi-Pass Type Inference: Evaluates expression types across AST passes to emit clean C function signatures and format specifiers (long long, double, const char*).
42 Test Suites: Tested end-to-end with unit, integration, and nested-block stress tests.
GPLv3 with a Runtime Exception: The compiler remains free software forever, but applications compiled with VBX are 100% yours to distribute or sell under any license you choose.

Meet Our Mascot: BASIC-Chan!

Every great language needs a soul. We designed BASIC-Chan—a cyberpunk anime tech girl holding a glowing holographic floppy disk and a floating retro "Click Me" button, matching our neon cyan and purple aesthetic!

Tooling & VS Code Extension

We didn't want to stop at the CLI. We’ve already built a full multi-editor ecosystem:

The Official VS Code Extension is already live on the Visual Studio Marketplace (works in the browser on vscode.dev too!).
Syntax highlighting packages available for JetBrains IDEs, Sublime Text, Notepad++, Vim, Neovim, Emacs, and Micro.

What's Next?

Our next big milestone is VBX Studio: a dedicated, lightweight, cross-platform visual IDE with a true drag-and-drop form designer, just like the classic 90s RAD tools we all miss.

As Linus Torvalds famously once said: "Just a hobby, won't be big and professional..."

⭐ GitHub Repository: [https://github.com/M5Devs/vbx]
Editors Repository: [https://github.com/M5Devs/vbx-editors]

I'd genuinely love to hear your thoughts, feedback, and what features you'd like to see in VBX! Let me know in the comments below! ❤️

I wanted Git to show me what would happen before changing history, so I built it

Tue, 06 Oct 2026 09:55:16 +0000

I use Git every day, but one thing has always bothered me:

when you do something that changes history, a lot of Git tools still basically ask you to understand the command first and trust that the result is what you expected.

I wanted something more visual.

So while building RepoBeam, I added a before/after preview for operations like going back to an older commit.

Instead of clicking the action and hoping I understood it correctly, RepoBeam first shows me what the repository will look like afterwards.

For example, when going back to a commit I can choose whether I want to:

restore the files as normal unstaged changes
restore them already staged
create a new restore commit when rewriting published history would be unsafe

And RepoBeam shows the expected history before I confirm anything.

The idea is simple:

show me what Git is going to do before it does it.

RepoBeam actually started for a different reason.

I used Fork for a long time on Windows. When I started working more on Linux, I tried GitKraken, Sublime Merge, SmartGit, GitButler and a bunch of smaller clients, but I never found one that really felt like the Git GUI I wanted to use every day.

So I started building my own.

Over time it turned into a full Git client with:

local changes and staging
split/unified diffs
commit history and graph
branches and remotes
stashes
guided conflict resolution
before/after Git previews
Coding Sessions

Coding Sessions

This is another part I use a lot now.

When I start working with Codex or Claude, I start a Coding Session in RepoBeam first.

RepoBeam then organizes everything that changes during that session.

I can review the files afterwards, undo one change, bring it back, keep the rest, or undo the entire session.

It does not replace Git or create some separate version-control system. It works with normal Git repositories.

RepoBeam currently runs on Linux and Windows.

Linux builds are available as:

.deb
AppImage
Snap

Private repositories work, no RepoBeam account is required, and the app is free to use including for work.

https://repobeam.com

I released 1.8.3 this week and this is the first time I'm seriously putting RepoBeam in front of developers I don't know.

The thing I'm most curious about:

Would a before/after preview like this actually make you more comfortable with Git history operations, or do you prefer seeing the underlying Git command directly?

Building CyberRef: A Single-Binary Offline Reference for Cybersecurity Practitioners

Sun, 04 Oct 2026 19:02:33 +0000

I built CyberRef to solve a problem I kept seeing in labs and on engagements: nobody remembers the exact syntax of a command under pressure.

You know the command exists. You know roughly what it does. But it's 2 AM during an incident, or you're mid-engagement with a client watching, and the exact flags slip away. So you open twelve tabs of cheatsheets, dig through your notes app, ask Slack — and twenty minutes disappear on something you knew cold last week.

CyberRef is my attempt to fix that. This article is a walkthrough of what it does, the design decisions behind it, and what I learned building it.

What It Is

A single binary you download and run. It opens a local web UI at http://localhost:8787 with a searchable command reference and a set of guided lab scenarios.

No install. No server. No internet required. Everything is embedded — the UI, the datasets, the assets.

Written in Go for the backend, Alpine.js + vanilla CSS for the frontend, all served from one binary via embed.FS.

Why Offline-First

Most cheat-sheet tools are websites. That's fine until you're in an air-gapped lab, an isolated client environment, or a VM with no network egress. In those settings, an online tool is dead on arrival.

Offline-first isn't a limitation — it's a constraint that shaped every decision:

Data is embedded at build time. YAML files are compiled into the binary via go:embed. No external file reads at runtime.

No network calls at startup. The binary doesn't phone home, doesn't check for updates, doesn't do telemetry.

Stateless by default. Nothing is written to disk unless the user explicitly exports something.

Single binary distribution. One .exe on Windows. Copy it to a USB stick, run it on any machine.

This means the tool works in the environments where cyber work actually happens — not just where developers are comfortable.

Why Not React

The obvious frontend choice would have been React with Vite and a build pipeline. I went with vanilla HTML/CSS/JS + Alpine.js instead. Here's why:

go build must be the only build command. A React pipeline adds Node, npm, a bundler, and version drift. Two toolchains for a lookup tool is overkill.

Alpine.js gives 80% of React's ergonomics in one <script> tag. Declarative bindings, reactivity, x-for, x-if — everything a searchable list needs.

No dist/ folder to embed. The HTML, CSS, and JS files are the final artifacts. go:embed picks them up directly.

Zero framework churn. Alpine v3 will keep working in five years. React 18 will be replaced by React 21 by then.

For a searchable, filterable, well-formatted reference tool, this is the right tradeoff. React would have been solving a problem I didn't have.
The Placeholder Substitution Feature

This is the feature that turned CyberRef from a nice-to-have into a tool people actually use.

Commands like nmap -A -p- {TARGET} aren't directly paste-ready. {TARGET} is a placeholder that must be replaced. CyberRef scans each command for {TOKEN} patterns and renders an inline input for each one:
A few things make this work well:

Values persist across sessions. Type your lab IP once, and every command using {TARGET} reuses it.

YAML defaults pre-fill inputs. When a scenario specifies placeholders: { TARGET: "10.10.10.5" }, the input starts populated.

Copy gives you the substituted version. Not the template. The ready-to-paste command.

Values are shared across commands and scenarios. Configure once for an engagement, use everywhere.

Twenty lines of Alpine state plus a localStorage wrapper. Small feature, huge UX impact.
The Scenario Layer

A command reference is table stakes. The real problem in cyber training isn't "what's the command" — it's "what's the sequence, and why."

In v0.3 I added a scenario layer. Each scenario is a guided workflow with:

Narrative overview — what the technique is, why it matters

Prerequisites — what you need before starting

Steps — ordered commands with rationale, expected output, and notes

Defense — hardening, detection, and response guidance

References — MITRE ATT&CK, OWASP, vendor docs

The scenarios are mapped to the Cyber Kill Chain, MITRE ATT&CK, and the CIA triad. This is important — it turns a command list into a curriculum.

Blue-Team Content

In v0.4 I added the first blue-team scenario — Log Analysis & Detection Engineering — plus purple-team notes on every attack scenario.

Purple team notes are the connective tissue. They answer the question: "How do I run this attack and watch it get detected at the same time?"

For example, on the Kerberoasting scenario:

Detection is easiest when 4769 events are forwarded to a SIEM. Filter for RC4 (0x17) ticket encryptions — modern AD should only see AES in normal operations. Any RC4 TGS is worth investigating.

This is different from the Defense panel. The Defense panel lists what to monitor. The Purple Team Notes explain how to actually run the exercise.

Blue-team content also includes ready-to-run SIEM queries for Splunk, Elastic, and Wazuh. Copy, paste, run. No translation needed.

What I Learned

Constraints make the product better. Offline-first, single-binary, no-build-step — these weren't compromises. They were features. Every one of them made the tool faster, simpler, and more usable in the environments where it matters.
Ship small, ship often. The progression was:

v0.2 — command reference with placeholders
v0.3 — scenarios + export
v0.3.1 — favorites & recents
v0.3.2 — filters & command palette
v0.4 — attack lifecycle depth + blue-team content

Each release solved one thing well. Nobody had to wait six months for a "big update."

Users tell you what to build next. The favorites feature came from watching how I used the tool myself. The command palette came from friends who said "We want to jump to a command without leaving the keyboard." Real friction beats planned roadmaps.
Some things don't need to be fancy. embed.FS + net/http + Alpine.js. No ORM, no state management library, no container. Just three external Go dependencies and one vendored JS file. The simplicity is the point.

What's Next

Planned for v0.5:

Windows / Active Directory — native commands and AD-focused scenarios
CLI companion — cyberref search "kerb" from the terminal, reusing the same data
PowerShell export — for scenarios, alongside the current bash export
Light theme — for bright environments
Signed binaries — to remove the Windows SmartScreen warning

Longer term:
Community scenario contribution format
Documentation site
Multi-platform binaries (macOS, Linux)

Try It

Download: https://github.com/toyosee/cyberref-releases/releases

Run: Double-click cyberref.exe. Browser opens. That's the whole setup.

Note on Windows SmartScreen: You'll likely see a "Windows protected your PC" warning. This is normal for unsigned binaries. Click More info → Run anyway. Code signing is on the roadmap.
Feedback Welcome

If you're a practitioner — red, blue, or somewhere in between — I'd love to hear:

What commands or scenarios are missing that you'd use?
What friction points does the tool not solve yet?
What would make it part of your daily workflow?

Open an issue on the releases repo, or find me on LinkedIn. - https://linkedin.com/in/elijahabolaji

CyberRef is written in Go, uses Alpine.js for the frontend, and ships as a single binary for Windows with macOS and Linux builds planned. Source is maintained privately; binaries are released publicly.

Show a single Windows application window in any web browser on LAN

Sun, 04 Oct 2026 05:51:45 +0000

Ever needed to show one app window on a tablet without any remote-desktop software?

I built WindowStream for exactly that, and Ive just open-sourced it.

Its a small Windows tray app that streams a chosen window as MJPEG over HTTP on your local network. On the tablet or other PC you just open a browser: nothing to install, and its strictly view-only.

What Im happy with:

Any modern browser works as the viewer (Android, iOS, another PC), with pinch-zoom, panning and fullscreen.
Two capture modes: a screen copy, or PrintWindow, which keeps streaming the window even when other windows cover it.
Light on resources: a frame is encoded only when the picture has changed, and JPEG encoding goes through libjpeg-turbo.
Starts with Windows and finds the window again even if its title changes.
English and Russian interface, a single-exe build, unit tests, and user manuals in three languages. Python, MIT licensed.

One caveat: there is no password or encryption, so its meant for trusted networks only, and the docs say so clearly.

Code, a release with the ready-made exe, and documentation: https://github.com/eugenyh/WindowStream

Feedback and ideas are very welcome!

CodeSage: Code Intelligence for AI Agents, and Why I Rebuilt Its Models

Fri, 02 Oct 2026 11:25:42 +0000

Until this week, CodeSage ran its two models exactly as they ship on Hugging Face: Jina's code embedder and the ms-marco MiniLM reranker. A full index of php-src took 1,782 seconds, just under half an hour, and I got tired of waiting.

CodeSage 0.38 does the same full index in 373 seconds. Nothing was retrained. The weights are the same weights; what changed is the inference graph around them, a few things in the chunker, and one SQLite query that had been quietly eating most of the run. The two rebuilt models are now public on Hugging Face, along with the scripts that produce them byte-for-byte.

What CodeSage gives an agent

CodeSage is a code intelligence engine for AI coding agents: a structural graph (symbols, references, dependencies) plus semantic search (embedding retrieval with cross-encoder reranking), in one Rust binary that works as a CLI or an MCP server. An agent asks it questions grep can't answer, like "what depends on this class" or "where does session handling happen", and gets file-and-line answers from an index instead of guesses from a context window.

Parsing is tree-sitter, covering PHP, Python, C, C++, Java, Rust, JavaScript, TypeScript and Go. Each project gets one SQLite database at .codesage/index.db, with sqlite-vec for KNN and FTS5 for literal matches. The MCP side is a stdio shim that starts or reuses a per-user daemon over a Unix socket, so concurrent agent sessions share one project cache, one model pool and one CUDA context. There is no HTTP listener.

The MCP server exposes 22 tools. The ones agents lean on most:

find_symbol, find_references, trace_call_path: where something is defined, who calls it, and the shortest call chain between two symbols.
impact_analysis, assess_risk: what a change to this file can break, scored from the graph plus git history.
search: natural-language retrieval over ~50-line chunks, reranked.
from_trace: maps a pasted stack trace or ASan report (Python, PHP with Xdebug, Rust, Java, Go, Node, gdb) onto indexed symbols.
edit_check: diffs a proposed declaration against HEAD before the agent writes the file.

The graph is only as useful as its recall. In August, impact_analysis reported that AxiosError in axios had 0 dependents. It has 23. File-path imports like ./core/AxiosError.js never resolved; only Rust-style :: paths did. Fixing that, and counting Foo.staticMethod() and x instanceof Foo as usage, took mean dependent recall on axios from 0.37 to 0.66 at precision 0.85. An agent told "0 dependents" by a tool it trusts goes ahead and changes the class.

The index has to keep up with the code

An index that lags the code feeds the agent stale answers with full confidence, so CodeSage re-indexes from git hooks on every commit, checkout and merge. That puts the indexer's fixed cost on the hot path dozens of times a day, which is why a lot of the work across 46 releases since April has gone into cost rather than features.

The per-commit path got there first. In 0.23.0, a no-change incremental run stopped loading the ONNX model and mapping a CUDA context before checking whether any file had changed:

No-change incremental `codesage index`	Time	Peak memory
0.22.0	2.7-4.5 s	1.16 GB
0.23.0	0.08 s	150 MB

The file watcher re-embeds only chunks whose text changed: an 8-save burst marks 90 chunks dirty and embeds 1.

That leaves the full index, which nobody runs on every commit but everybody runs eventually: first onboarding, a model change, a chunker change. 0.38 itself forces one, because the embedder now reads up to 1,024 tokens per chunk instead of 512. When the full run takes half an hour on a large repo, people postpone it, and a postponed re-index is a stale index.

Same weights, rebuilt graphs

The embedder was slow because of how it was exported, not because of what it computes. The upstream Jina v2 ONNX file is a decomposed opset-11 export. Its attention uses ALiBi plus a QK LayerNorm, a combination ONNX Runtime's transformer optimizer doesn't recognize, so nothing fuses. Every layer materializes the full [batch, 12, seq, seq] score tensor several times over, and because the graph outputs per-token hidden states, every batch copies a [batch, seq, 768] tensor from the GPU back to the host just so the caller can average it.

IA0x00/jina-embeddings-v2-base-code-codesage carries two graphs:

onnx/model.onnx (fp32, every execution provider): masked mean pooling and L2 normalization folded into the graph, so the output is the 768-dimension sentence embedding and nothing else crosses back to the host.
onnx/model_cuda_fp16.onnx (CUDA only): the same pooling, plus attention fused by hand into com.microsoft MultiHeadAttention, with ALiBi and the key-padding mask passed as attention_bias. Weights are fp16; the output stays fp32.

One fp16 detail: the attention mask filled padded positions with -FLT_MAX, which overflows fp16. It's -10000.0 now, which is still negative enough to zero those positions after softmax.

Measured on an RTX 4080 Laptop GPU with ONNX Runtime 1.24.4, 2,048 real chunks per corpus of up to 512 tokens each, compared against upstream fp32 with pooling done on the host:

Corpus	Upstream fp32	Pooled fp32	Fused fp16	Min cosine (fp16)	Top-10 neighbour overlap
php-src (C)	59.7 chunks/s	89	249-257	0.99999	0.994
Laravel app (PHP)	67.2	113	301-317	0.999996	0.996
React app (TS/JS)	69.8	109	296-317	0.999995	0.997

A minimum cosine of 0.99999 across 2,048 chunks means the vectors are, for retrieval purposes, the same vectors. Those throughput figures are at the 512-token cap; CodeSage now runs Jina at 1,024, because real C in php-src runs a median of 611 tokens per 1,500-byte chunk and the old cap truncated more than half of them. So the production per-chunk rate is lower than this table, and the chunks carry more of the code.

The reranker needed far less. IA0x00/ms-marco-MiniLM-L6-v2-codesage is a standard BERT, so ONNX Runtime's stock optimizer fuses it (embedding LayerNorm, six Attention nodes, skip LayerNorm, bias GELU) and the work was mostly converting to fp16. Scoring 50 (query, chunk) candidates went from a median 108.0 ms per query to 20.6 ms, with the same top result on 40 of 40 test queries, top-10 overlap of 0.9975, and a maximum logit change of 0.024.

Both repositories are Apache-2.0, the upstream license, and the weights are unchanged apart from precision. CodeSage pins each one by Hugging Face commit and by the sha256 of every graph and tokenizer it loads, and scripts/derive-jina-onnx.py and scripts/derive-reranker-onnx.py in the CodeSage repo download the pinned upstream files, verify them, and write the published files byte-for-byte. You don't have to trust my upload; you can rebuild it. Your config.toml keeps the upstream model names, and the pin table maps them to the derived repos, so there is nothing to change on upgrade.

The biggest single win wasn't a model

Most of the half hour was SQLite. When a file changes, its old chunks are deleted first, and file_path lived in an auxiliary column of the sqlite-vec table and an UNINDEXED column of the FTS5 table. Neither can be searched by index, so DELETE ... WHERE file_path = ? scanned both tables for every file: about one second per file at php-src's 54,000 rows, roughly 20 of the 28 minutes a full index took when I measured it.

The fix is a small sidecar table, <chunk_table>_paths(id, file_path), kept in step on every insert and delete and rebuilt if it goes missing or diverges. Deletes now resolve the path to rowids and remove by rowid: 3.2 ms per file.

Two chunker changes ship in the same release. Chunks that are mostly digits and commas (lookup tables, timezone and Unicode data) are no longer embedded, since no natural-language query is looking for them, and batches are length-sorted and byte-bounded so a batch of short chunks isn't padded out to the length of its longest member.

Before and after, all of it together:

`codesage index --full`	Before	0.38
php-src	1,782 s	373 s
private mobile backend	469 s	80 s
private frontend app	295 s	60 s

That is the combined effect of the fused fp16 graph, the 1,024-token cap, the dropped data chunks, the batching, and the delete fix. I don't have a clean per-change split beyond the delete scan's own estimate, so I'm not going to invent one. Retrieval held: recall@10 is unchanged on three private eval corpora and rose from 0.765 to 0.790 on a php-src session corpus.

Scores that say what they measured

Fast answers are worthless if the agent can't tell a measurement from a default, so several releases since August went into making CodeSage say what it didn't check. impact_analysis reports a lower bound, because dynamic calls and unresolved imports can hide real dependents. assess_risk returns unscored for a file with no indexed git history instead of a low number. find_references marks a count as a floor when the symbol name is ambiguous. An empty search result carries indexed-file counts per language, so "not found" and "never indexed" stop looking identical.

The same rule applies to my own benchmarks. In August I withdrew a published retrieval number (recall@10 0.932, NDCG@10 0.788 over 602 queries) after finding the harness had indexed whole repos instead of each benchmark's root and scored crashed queries as 0.000. The replacement table in the README runs 663 queries across 33 repos in 9 languages, reports per-language NDCG@10 from 0.7455 (C) to 0.9434 (JavaScript), and says it was measured on a modified 0.27.0 build. It hasn't been re-run on 0.38 yet.

Where it falls short

These are the limits I know about, all of them in the README:

Nine languages. On the public benchmark, 47% of queries are in languages CodeSage doesn't parse (Ruby, Kotlin, Swift, Scala) and get no recall at all.
Agents don't reach for it on their own. With CodeSage and Grep both available in Claude Code, agents picked CodeSage on code-identifier queries 1.1% of the time over 30 days of sessions, and 0 of 10 on a controlled harness (measured in April, not re-measured since). That is why the codesage-tools Claude Code plugin serves a codesage brief inline before an Edit or Write in an onboarded project instead of waiting to be asked. It stays silent when there is nothing worth saying.
Every speed number in this post is CUDA. CPU and Apple's CoreML get the pooled fp32 graph but not the fused fp16 one, and I haven't measured the CPU side.
No prebuilt binaries and no documented Windows support. You build it with cargo.
Read-only. It doesn't edit code and doesn't query across repositories.

Try it

cargo build --release -p codesage --features cuda   # drop --features cuda for CPU / CoreML
cd /path/to/your/project
codesage init
codesage index
codesage install-hooks
claude mcp add --scope user codesage -- codesage mcp

Codex users run codesage install codex --global instead of the last line. If you're on Claude Code, whetstone is the other half: CodeSage tells the agent what the code is, whetstone covers how to investigate, review and ship. The first index downloads the models: about 370 MB on CUDA, about 736 MB for the fp32 graphs on CPU or CoreML.

Nothing about CodeSage 0.38 required a better model. It required looking at what the existing one did between input and output, and at what the database did on every file delete. Most of that half hour was overhead around the model, not the model itself.

github.com/iliaal/codesage

Miraiclip: an open-source engine for building video editors in the browser

Tue, 29 Sep 2026 12:28:18 +0000

title: "Miraiclip: an open-source engine for building video editors in the browser"
published: true
description: "A framework-agnostic TypeScript library where every edit is a command — undo/redo, collaboration, and AI control fall out of one design decision."

tags: webdev, typescript, opensource, showdev

I've been building Miraiclip — an open-source, framework-agnostic library for building video editors in the browser — and it's now on npm under MIT. This post covers what it is, the one design decision everything hangs on, and a few hard-won lessons from making video actually work in a browser.

The problem

Every browser video editor ends up rebuilding the same difficult parts: frame-accurate playback, an undo/redo system that never corrupts state, and exports that match what the preview showed. These are engine problems, not product problems — but there's no engine to reach for, so every team pays for them again.

Miraiclip is that engine. It is deliberately not an editor app. There's no timeline UI, no buttons — the core is headless: project state, a microsecond-precision timeline, and a full command history, with rendering delivered as a separate layer. You bring the UI (React, Vue, Svelte, vanilla — the core has zero UI dependencies).

One design decision: everything is a command

Instead of calling imperative methods that mutate state, you dispatch descriptive commands. Every command is deterministic, validated against a schema, serializable, and invertible.

import { createProject } from "@miraiclip/core";

const project = createProject({ width: 1920, height: 1080, fps: 30 });

project.dispatch({
  type: "asset/add",
  payload: { id: "intro", kind: "video", src: "/media/intro.mp4", durationUs: 12_000_000 },
});
project.dispatch({ type: "track/add", payload: { id: "video-1", kind: "video" } });
project.dispatch({
  type: "clip/add",
  payload: {
    kind: "video", id: "clip-1", trackId: "video-1", assetId: "intro",
    startUs: 0,            // timeline position in microseconds
    durationUs: 5_000_000, // 5 seconds
  },
});

// Batch commands into one undoable transaction
project.transaction(() => {
  project.dispatch({ type: "clip/split", payload: { clipId: "clip-1", atUs: 2_000_000, newClipId: "clip-1b" } });
  project.dispatch({ type: "clip/move", payload: { clipId: "clip-1", startUs: 1_000_000 } });
});

project.undo();
project.redo();

Three things fall out of this decision without being bolted on:

Undo/redo — commands are invertible, so history is exact, replayable, and inspectable.

Collaboration — every state change is emitted as granular RFC-6902 JSON patches. Command and patch streams are the substrate for multiplayer editing:

project.events.on("patches", ({ patches }) => {
  // [{ op: "replace", path: "/clips/clip-1/startUs", value: 1000000 }]
});

AI control — commands are plain descriptive data with a published catalog and JSON schemas. An LLM can read project state and generate valid edit sequences; the command catalog doubles as a tool definition. A human clicking a UI, an LLM planning an edit, and a sync layer replaying a collaborator's changes all speak the same language.

Playback and export

The rendering layer (@miraiclip/renderer) is a WebCodecs decode pipeline plus a WebGL compositor (PixiJS), with an audio-master clock:

import {
  createPixiBackend, createPlayer, exportProject,
  openMediabunnyDemuxer, createWebCodecsDecoderFactory,
  createWebAudioOutput, openMediabunnyAudio,
} from "@miraiclip/renderer";

const backend = await createPixiBackend({ canvas, width: 1280, height: 720 });
const player = createPlayer(project, {
  backend,
  openDemuxer: openMediabunnyDemuxer,
  createDecoder: createWebCodecsDecoderFactory({ maxOutputDimensionPx: 1920 }), // proxy preview
  audioOutput: createWebAudioOutput(),
  openAudio: openMediabunnyAudio,
});
player.play();

// Offline export, faster than realtime — same compositor as the preview
const bytes = await exportProject(project, { format: "mp4", quality: "high" });

The export renders through the same compositor as the preview, so preview/export parity holds by construction rather than by testing luck. Output goes to MP4 or WebM, and it can stream straight into a file (showSaveFilePicker writable) so long exports don't accumulate in memory. There's also @miraiclip/server-export, which runs the identical pipeline in headless Chrome from Node:

miraiclip-export project.json --out final.mp4 --quality high

Keyframe animations (cubic-bézier easings), effects (color adjust, blur, chroma key), transitions with equal-power audio crossfades, and karaoke-style captions with SRT/VTT and ASR word-timestamp import are built in — and they render identically in preview, browser export, and server export, because it's one compositor everywhere.

Things the browser made me learn

A few lessons that shaped the engine, in case you're building anything media-heavy:

"Frame-accurate" means presented frames, not scheduled ones. Callbacks tell you a frame was scheduled; only reading pixels back tells you what the user actually saw. Miraiclip's test fixtures encode each frame's index as its color, so tests assert on what's really on the canvas — that's how several seek and playback bugs were caught that callback-based tests would have blessed.

Export memory must be independent of timeline length. Mixing an hour of audio in one OfflineAudioContext buffer costs ~1.4 GB; encoding into an in-memory buffer costs the whole file. Miraiclip mixes audio in bounded sequential chunks interleaved with the frame walk and streams encoded output to disk — a demonstrated one-hour export (86,400 frames plus a full hour of audio) peaked at 165 MB of JS heap, running at 1.6× realtime on a dev laptop.

Trust nothing you can't verify with a second decoder. Exports are validated by a corpus that re-decodes every file with ffmpeg — an independent decoder — checking every frame's timestamp and pixels, audio gain, and A/V sync (measured offset: 0 ms at both ends of the file). A muxer bug can't hide by round-tripping through the encoder that produced it.

Status

Miraiclip is pre-1.0: the core model is stable in shape, but expect API changes between minor versions. Current packages: @miraiclip/core, @miraiclip/renderer, and @miraiclip/server-export. Chromium-family browsers are the target for rendering and export (WebCodecs-based); the core runs anywhere JS runs, including Node.

If you're building anything with video in the browser — an editor, a clip tool, automated video generation — I'd genuinely value your eyes on the API before it hardens.

GitHub: github.com/comaniacs/miraiclip
Docs + live examples (the code shown is the code that runs): comaniacs.github.io/miraiclip
npm: @miraiclip/core

Questions and issues welcome — and if you try it, I'd love to hear what you build.

Guys I need your feedback for logo

Tue, 29 Sep 2026 11:45:22 +0000

Hey guys ;)
This post is a bit unusual, but I really need your help and opinion. So right now I’m working on a new logo for Aster. And I really need to know is it good? And if it isn’t, then what’s wrong with it? I'll be glad to hear from all of you, thanks.
Here it is

More about idea of logo and other I'll tell in next post. So, yep bye bye and thanks for all of you.
Oops, here is second version of logo. So, which is better?

I built a Pix library for Elixir (and one cent proved it works)

Tue, 29 Sep 2026 00:34:58 +0000

Over the last few months I became a bit of a compulsive open source contributor. Translating Linux kernel documentation into Portuguese, a merged PR in uutils/coreutils, a few fixes in Elixir libraries I had used before. Always the same routine: find a problem in someone else's project, understand it, fix it, wait for review.

Then a different itch showed up: instead of fixing other people's libraries, build my own.

This post is about that. How I built pix_brcode, a Pix library for Elixir, over a weekend, tested it with real money (R$ 0.01, don't judge me) and published it on Hex. And about the bug that only showed up once a real bank got involved.

What is Pix, and why a library for it

If you're not from Brazil, you've probably never heard of Pix. It's the instant payment system created by Brazil's Central Bank in 2020, and it took over the country: it's free for individuals, settles in seconds, works 24/7, and today it's how Brazilians pay for everything from coffee to rent.

Most Pix payments start with a QR code, or with its text version, the "copia e cola" (copy and paste) code: a long string starting with 000201 that you paste into your bank app. Everyone uses it every day, and almost nobody knows what's inside it.

In the JavaScript world this is a solved problem: pix-utils on npm generates and parses Pix codes and gets over 60k downloads a month. I went looking for the equivalent on Hex, Elixir's package manager, and couldn't find a maintained one.

So I put the two things together: a big, mature library to use as a reference, and an empty spot in the ecosystem I wanted to fill. I decided to build a "pix-utils" for Hex, or, as I preferred to call it, pix_brcode.

What's inside a Pix code

That string is a BR Code: an international payment QR code standard (EMVCo's QR Code Specification, Merchant-Presented Mode) with Pix-specific fields.

The structure is simpler than it looks. Everything is TLV: a 2-digit ID, a 2-digit length, then the value.

00 02 01                       → payload format: "01"
26 58 0014br.gov.bcb.pix0136…  → Pix account (with subfields inside!)
52 04 0000                     → merchant category
53 03 986                      → currency: Brazilian real
54 04 0.01                     → amount
58 02 BR                       → country
59 04 Igor                     → receiver name
60 09 Sao Paulo                → city
62 07 0503***                  → txid (transaction id)
63 04 F6CE                     → CRC16

Look at field 26: its value is another TLV, holding the Pix identifier (br.gov.bcb.pix) and the key. TLV inside TLV.

And the last field, 63, is a CRC16: a checksum over everything before it. If someone copies the code missing one character, the CRC doesn't match and the bank app rejects it.

(Important side note: a CRC is not security. It catches accidental errors, not fraud. Anyone can recompute it.)

The decisions that made the weekend worth it

Zero dependencies

Installing pix_brcode pulls in nothing else. That had a cost: Erlang only ships CRC32, so the CRC16 was written by hand in about 20 lines, using Elixir's binary pattern matching:

defp crc(<<byte, rest::binary>>, acc) do
  acc = Enum.reduce(1..8, bxor(acc, byte <<< 8), fn _, acc -> shift(acc <<< 1) end)
  crc(rest, acc)
end

defp crc(<<>>, acc), do: acc

Adding a dependency for 20 lines would be trading a small problem for a permanent one.

Money is never a float

pix-utils takes the amount as a JavaScript number, which is a float. And floats with money are how you end up seeing 0.1 + 0.2 = 0.30000000000000004 on someone's bill.

In pix_brcode, the amount is either an integer in cents (1050 becomes "10.50") or an exact string ("10.50"). The conversion is done on text, with no division at all.

Strict in what you send, liberal in what you accept

When generating, the library is strict: a name longer than 25 characters is an error instead of being silently truncated (imagine the payer's bank app showing the wrong name). When parsing, it accepts whitespace and line breaks around the code, because real copy-and-paste comes dirty from WhatsApp.

That principle has a name, Postel's law. And it was about to be tested sooner than I expected.

The moment of truth: real money

Tests passing, Credo clean, docs generated. Only one test left that really matters: a bank app accepting the code.

The first try failed in all three banks I tested. Itaú, Nubank and Mercado Pago: "Invalid QR Code".

For a minute I thought the weekend was wasted. It wasn't: I had used a made-up Pix key. When you paste a static Pix code, the app looks the key up in the Central Bank's directory. Unknown key, rejected code. The test was wrong, not the library.

I generated it again with my real Itaú random key and an amount of one cent:

PixBrcode.encode(%{key: "my-real-key", amount: 1,
                   merchant_name: "Igor", merchant_city: "Sao Paulo"})

Pasted it into Nubank. My name showed up, R$ 0.01. Paid. It landed in my Itaú account instantly.

The best-invested cent of my life.

The bug no test caught

The reverse path was still missing: generate a code in the bank app and parse it with the library. Pix > Receive on Nubank, copy, paste into the terminal:

iex> PixBrcode.decode("00020126580014BR.GOV.BCB.PIX0136…")
{:error, :invalid_gui}

BR.GOV.BCB.PIX. In uppercase.

The Central Bank's manual writes br.gov.bcb.pix in lowercase, and the library compared the exact text. Nubank sends it uppercase. So does Itaú. All my tests passed because they all followed the manual to the letter, and the banks don't.

The fix was one line: compare case-insensitively when parsing, and keep generating lowercase, as the manual says. Postel again: strict in what you send, liberal in what you accept.

The real codes showed other differences too: Nubank includes the postal code (field 61) and puts part of the account holder's tax ID in the receiver name; Itaú doesn't. The library's tests now use payloads with the same layout as the real ones, but with fake data. (Your partial tax ID in a public repo is not a great idea, and I learned that before making the mistake.)

The lesson: the spec is the minimum. Real systems have variations that only show up with real data.

A second opinion before publishing

Before pushing to Hex, I had an AI agent do an independent code review: a fresh session, with no context from the development, reading everything from scratch. Nothing blocked the release, but it came back with four good findings:

the amount field didn't enforce the spec's 13-character limit;
decode(nil) raised an exception, while the README promised always {:ok, _} or {:error, _};
text with invalid bytes also crashed the library;
emoji in the name got through, and since each emoji takes several bytes, the length declared in the TLV was wrong for other parsers.

All four were fixed before v0.1.0. Name, city and description must now be ASCII after removing accents (São João becomes Sao Joao, and ☕ is an error).

What's next

v0.1.0 generates and parses static and dynamic Pix codes, validates keys (tax IDs, phone, e-mail, random key) and runs CI on three Elixir versions. Next on the list: typespecs, more tolerant key parsing and a CHANGELOG. And there's another idea in the queue: Brazilian boleto bank slips, which also have no package on Hex.

If you work with Elixir and Pix, try the library and tell me what breaks. Issues and PRs are very welcome:

Fixing other people's libraries taught me to read code. Building my own taught me that the manual is only the start of the conversation.

This post was originally published in Portuguese on Coisa de Dev.

Forensic Aviation Analytics: Auditing Fuel Bleeds & Delay Cascades on a Regional A320neo Network

Mon, 28 Sep 2026 11:41:49 +0000

When evaluating airline performance, typical analytics dashboards rely blindly on passenger-facing "On-Time" arrival percentages. However, from an operational and financial engineering standpoint, these high-level metrics can easily mask millions of dollars in silent cash destruction.

Due to strategic schedule padding, a short-haul flight can sit idling its engines on a congested tarmac for 20 minutes, yet still be registered as "On-Time" to the customer. The passenger is happy, but the airline’s finance department just watched pure margin vaporize into thin air.

To expose these hidden friction layers, I engineered LCC-Ops: an end-to-end data warehouse auditing over 120,000 regional transaction legs modeled around the single-aisle network performance of flynas across key GCC hubs.

Here is the technical architecture and the forensic database methodologies behind the pipeline.

The Tech Stack & Architecture

Database Layer: MySQL Server 8.0 (Advanced CTEs, Mathematical Window Functions, Schema Migrations)
Business Intelligence: Power BI Desktop (Data Type Optimization, Cross-Table Iterators, UI Design)
Core Fleet Constants: Engineered around the Airbus A320neo (CFM LEAP-1A26 engine) utilizing official ICAO Engine Emissions Databank metrics. At a standard 7% ground idle taxi thrust, this engine burns exactly 0.0940 kg of fuel per second, per engine

The Database Engineering Breakdown

Pillar 1: Isolating Tarmac Cash Destruction (Domain A)To find the true cost of airport ground bottlenecks, the ingestion engine isolates rows inside the transactions table (fact_flights) where the Out-Gate to Runway Takeoff latency (taxi_out) exceeded a standard 4-minute engine stabilization and warming buffer.

By pulling the real-world ICAO fuel coefficients down via relational keys, the calculation bypasses text-based padding and computes raw physical fuel destruction.

SELECT 
    f.origin AS departure_hub,
    COUNT(f.tail_number) AS total_monitored_flights,
    ROUND(AVG(f.taxi_out), 2) AS avg_taxi_out_minutes,
    -- Formula: (Actual Taxi Time - 4 Min Buffer) * 60 Sec * ICAO Idle Flow Rate * 2 Engines
    ROUND(SUM((f.taxi_out - 4) * 60 * e.fuel_flow_idle_kg_sec * 2), 2) AS total_wasted_fuel_kg
FROM fact_flights f
JOIN dim_aircraft a ON f.tail_number = a.tail_number
JOIN dim_engine e ON a.engine_identification = e.engine_identification
WHERE f.reporting_airline = 'XY' AND f.taxi_out > 4
GROUP f.origin;

Pillar 2: Tracking Cross-Border Delay Cascades (Domain D)
When an international flight arriving from an airport like Karachi (KHI) experiences customs or airspace delays, that latency risks cascading into the aircraft’s subsequent domestic legs (e.g., RUH ➔ JED).

To track this chronologically across individual daily airframe lifecycles, I utilized advanced LEAD() mathematical window functions

WITH ranked_daily_schedule AS (
    SELECT 
        flight_date, tail_number, origin, dest, carrier_delay AS leg_1_delay,
        LEAD(origin, 1) OVER (PARTITION BY tail_number, flight_date ORDER BY taxi_out DESC) AS leg_2_origin,
        LEAD(carrier_delay, 1) OVER (PARTITION BY tail_number, flight_date ORDER BY taxi_out DESC) AS leg_2_delay
    FROM fact_flights
    WHERE reporting_airline = 'XY'
)

Pillar 3: Menu Logistics & Hangar Risk Automation (Domains B & C)
Catering Spoilage Optimization: Short flight windows on regional tracks mean cabin crews lack the time to complete complex perishable sales loops. The data models validate flynas’s lean, shelf-stable buy-on-board menu model, proving that switching to fresh profiles would trigger an immediate 54% inventory spoilage cash bleed

Automated Hangar Reorder Points (ROP): The warehouse tracks rolling airframe hours against specific tail numbers (HZ-NS1 to HZ-NS5) [Query-relevant Context]. If a component approaches its high-wear safety limit, the system triggers automated database alerts to protect the airline against catastrophic $25,000/day Aircraft on Ground (AOG) hangar penalties

UI Engineering in Power BI

To present these data layers to corporate stakeholders, I built an interactive application-style interface directly inside Power BI using flynas’s signature branding tones.

The biggest challenge during BI ingestion was data type conversions—empty strings or trailing spaces in the raw logs caused math functions to drop blank values (--). By implementing upfront string transformations (Uppercase/Trim) and embedding data validation wrappers like ISNUMBER(VALUE()) directly into row-level DAX iterators, the front-end dynamically scales across massive transaction volumes without data loss.

The entire production code schema and scripts are live on my GitHub Link. I'd love to hear how other data engineers manage real-time fuel-burn parameters or multi-leg network routing in your pipelines!

Marshal: Teaching an AI Copilot to Run a World Cup Stadium — Built with Google Antigravity

Fri, 25 Sep 2026 16:42:53 +0000

The Problem

PromptWars Challenge 4 asked for a GenAI solution touching stadium
navigation, crowd management, accessibility, transportation,
sustainability, multilingual support, and operational intelligence
during FIFA World Cup 2026 — for fans, organizers, volunteers, or
venue staff.

That's seven verticals in one sentence. Trying to solve all of them
is how you end up with a shallow app that does nothing well.

Why I Rejected the Obvious Path

Most teams in this challenge will build a fan-facing app — a chatbot
that helps you find your seat, or a navigation assistant. It's the
first idea everyone has, which means the leaderboard will be full of
near-identical submissions competing on polish alone.

I went the other way: build for stadium staff, not fans. A World
Cup venue runs on volunteers and ops staff making fast decisions with
incomplete information — where's the bottleneck, who do we move, in
what language do we tell them. That's a harder, less obvious, and
much less saturated problem. I named it Marshal.

Marshal combines three of the seven verticals — crowd management,
real-time decision support, and multilingual support — and
deliberately ignores the other four (navigation, accessibility,
transportation, sustainability) for this build. Depth over breadth.

Architecture

Marshal runs as a 4-agent pipeline:

Signal Ingestor — reads live gate density, transit delays, and
incident feeds (simulated for this build)
Situation Analyzer — detects anomalies and classifies severity
(LOW/MEDIUM/HIGH) based on how fast a gate is approaching capacity
Action Recommender — calls a tool, checkAlternateGateCapacity(),
that checks the real-time density of every other gate and picks the
least-congested one, then drafts a concrete staff action
Multilingual Notifier — generates real alert text in English,
Spanish, French, and Hindi for staff, plus a simplified version for
fan-facing signage

The pipeline is visualized live in the UI — each stage lights up as
it runs, and a reasoning console streams the AI's decision-making in
real time, so a viewer can watch the logic unfold instead of just
seeing a final answer appear.

My Build Process with Antigravity

I built this in 8 sequential prompts rather than one giant spec —
smaller, focused prompts held Antigravity's output closer to what I
actually wanted at each stage.

Prompt 1 scaffolded the 3-panel dashboard and simulated gate-density
generator. This came out clean on the first pass — proper HTML/CSS/JS
separation, a distinctive dark control-room visual theme (glassmorphism,
scanline overlay, amber/cyan glow accents) instead of a generic template.

What broke: After the first few prompts, three real gaps showed up
when I compared the output against what I'd actually asked for:

The "Simulate Crowd Spike" button had no click listener wired to
it — the pipeline was instead running on a random 3-second timer,
which meant I had zero control over when a demo-worthy event
actually fired.
The Action Recommender was a hardcoded lookup table
({'Gate A': 'Deploy 2 tickets...'}) instead of a real tool call —
it gave the same canned advice regardless of what was actually
happening at the other gates.
The Multilingual Notifier printed a console line claiming it sent
alerts in EN/ES/FR, but never actually generated any translated text.

How I fixed it: I sent three targeted follow-up prompts rather than
re-prompting from scratch — each one named the exact gap:

Wire a real click handler to the button and force a controllable
spike instead of relying on the timer
Replace the lookup table with a real checkAlternateGateCapacity()
function that reads live gate state and picks the actual
least-congested option, with the tool call and its result logged
visibly in the console
Generate real 4-language alert text tied to the specific gate and
action from that run, displayed in the alert card itself

This iteration loop — build, compare against the original prompt, name
the specific gap, re-prompt — was more reliable than trying to get
everything right in one shot.

Demo Walkthrough

{% embed https://www.loom.com/share/0523f68b722845489aad58bccdc66969 %}

Clicking "Simulate Crowd Spike at Gate 3" triggers the full pipeline:
Gate 3 density jumps to 91%, the Signal Ingestor picks it up, the
Analyzer classifies it as HIGH severity and explains why, the
Recommender calls its tool and finds the least-crowded alternate gate,
and the Notifier pushes a real multilingual alert — all visible in the
console in under 15 seconds.

Quantified Impact

Simulated staff decision latency drops from ~4 minutes of manual radio coordination to under 15 seconds of automated
detection-to-alert time." its a simulated benchmark,
since this is a prototype, not a deployed system.

What I'd Build With More Time

Real IoT/sensor integration instead of simulated feeds
A predictive model (forecasting a crowd spike 10+ minutes ahead)
rather than a reactive one
Historical incident data to tune severity thresholds per venue
Expanding to the accessibility and transportation verticals I
deliberately left out of this build

Try It

Built for PromptWars Challenge 4, using Google Antigravity end to end.

Data Engineering Beyond "Pretty Charts": How I Built an Aviation Telemetry Leakage Engine

Wed, 23 Sep 2026 12:10:54 +0000

Stop Tracking "On-Time" Flights. Track Tarmac Fuel Destruction Instead.

Most aviation dashboards track gate-to-gate "On-Time" arrivals. The problem? It's a lagging indicator that completely masks why airlines silently hemorrhage millions. Padded flight schedules disguise a massive bottleneck: chronic tarmac fuel destruction occurring right before takeoff.

I built AeroOps, an end-to-end telemetry and multi-domain operations leakage engine, to expose exactly where systems drop value between the hangar and the runway.

Repo & Technical Report: [GitHub Link]
Stack: MySQL (Star Schema & CTEs) · Telemetry Data Modeling · Executive Dashboard Architecture · Power BI (DAX)

The Architectural & Engineering Challenge

Handling flight telemetry means dealing with high-volume, disjointed datasets. To make this actionable, the engineering required:

Star Schema Data Warehousing: Joined 513,000+ flight legs with precise technical burn parameters pulled directly from the ICAO Aircraft Emissions Databank.
Bypassing Relational Boundaries: Formulated deduplicated DAX lookup models to handle wide-body propulsion penalties under sub-second memory constraints.
Algorithmic Baseline Filters: Enforced a strict 4-minute engine warm-up buffer directly into the SQL logic. This stripped away safe, expected operational windows to isolate true, excess ground latency.

The Bottom-Line Impact Metrics

By querying raw transaction logs and user event data instead of building passive, "pretty" charts, the engine surfaced massive operational friction:

$42.69M in Tarmac Cash Destruction: Isolated and quantified the exact cost of ground traffic gridlocks at major hubs like Atlanta (ATL).
54% to 57% Short-Haul Menu Spoilage: Exposed a massive waste loop across major carriers (Delta/American) due to over-boarding. Transitioning the system to a 100% shelf-stable inventory model reclaimed $2.58M in simulated margin leaks.
$725K Legal Fine Exposure: Isolated a hidden 9% telemetry sync drop rate specifically among regional commuter airframes caused by corrupted logs.
Prevention of $1.50M Asset Groundings (AOG): Coded an automated Reorder Point (ROP) trigger tool to insulate warehouses against catastrophic out-of-stock asset scenarios.

The Takeaway

Data shouldn't just look nice in a presentation deck. If your queries aren't actively protecting business margins or exposing systemic infrastructure leaks, you're looking at the wrong metrics.

If your team is scaling fast and dealing with messy relational pipelines or unoptimized telemetry data, let's connect and fix your backend infrastructure loops.

Reverse-Engineering Messy Databases: My End-to-End Data Audits Across 17,000+ Relational Schema Logs

Wed, 23 Sep 2026 11:56:39 +0000

From Raw Logs to Business Strategy: How I Taught Myself Data Engineering & Analytics

I didn’t take the traditional path into data. Over the past 12 months, I bypassed the university lecture halls to teach myself relational database architecture, pipeline optimization, and growth analytics by diving straight into raw datasets.

I look at data through an engineering and business lens. Instead of building passive charts that just look pretty, I query transaction logs and user event data to find hidden operational friction, map out user behavior patterns, and isolate exactly where systems are dropping value. I build end-to-end data systems: raw SQL schemas, data sanitization scripts, interactive Power BI dashboards, and single-page executive reports.

Below are the architectural breakdowns, technical challenges, and business impact metrics of the four core data infrastructure projects I have engineered from scratch.

Project 1: StockPulse — Multi-Regional Supply Chain Audit

Technical Stack: MySQL (Mathematical Window Functions), Power BI, Advanced Excel
GitHub Codebase & Dashboard Layout: [LINK]

The Operational Bottleneck

Horizon Marketplace faced shrinking profit margins from slow-moving warehouse stock, while simultaneous supplier shipping delays caused high-demand items to go out of stock on our mobile application. Traditional procurement tracking models failed because they relied on simple historical averages, which immediately miscalculate when data hits high seasonal sales volatility spikes.

The Technical Implementation

Audited 17,646 operational and sales ledger transactions using MySQL window functions to calculate cumulative revenue contributions per SKU.
Coded a predictive restocking matrix script utilizing sales volatility standard deviations and rolling manufacturer lead timelines.
Formulated dynamic Safety Stock buffers and programmed automated database Reorder Point triggers to flag supplier order alerts before shelves hit zero.

The Business Impact Metrics

ABC inventory segmentation proved that exactly 23 Class A items drive 80% of total marketplace revenue, showing that the remaining catalog space was tying up critical capital.
Quantified a hidden revenue bleed of $63,897.26 caused by a single high-demand apparel product sitting entirely out of stock for 42 days due to upstream logistics bottlenecks.
Transitioned a multi-regional operation from manual, time-intensive spreadsheets to an automated, predictive data framework.

Project 2: FunnelOpt — HabitArcade B2C Telemetry Audit

Technical Stack: MySQL (Session Overrides), Funnel Analysis, User Lifecycle Mapping
GitHub Codebase & Database Logs: [LINK]

The Operational Bottleneck

A B2C application tracking engine suffered from severe data execution drops where product behavioral logs completely failed to map user activation patterns. The relational schema dropped child telemetry records because they were importing prior to the absolute database finalization of the parent account index logs.

The Technical Implementation

Audited full-funnel growth logs across 6 independent acquisition pipelines to analyze customer conversion latency and drop-offs.
Structured specific MySQL session overrides to temporarily bypass structural foreign key constraints.
Forced clean data synchronization across child records to completely restore parent-child index synchronization without corrupting historical system logs.

The Business Impact Metrics

Isolated a systemic “Streak-Breaking Crash Tax” where application sync errors wiped 30-day user milestones, triggering immediate 1-star reviews and an active 6% to 7% monthly subscriber bleed.
Exposed an “Inverted Value Curve” revealing that high-value annual checkout tiers underperformed monthly subscriptions due to silent gateway billing processor failures blocking top-priced subscription cash settlement.

Project 3: LeakStop — Olist B2B Revenue Leakage & Onboarding Audit

Technical Stack: MySQL (Schema Engineering), Power BI, Business Intelligence
GitHub Codebase & Analytical Readme: [LINK]

The Operational Bottleneck

Cross-vendor data duplication across digital marketplace ledgers was heavily skewing gross reporting metrics. Standard relational database joins double-counted total transactions when a customer order spanned multiple independent business vendors in a single checkout loop.

The Technical Implementation

Engineered robust MySQL ingestion and data sanitization scripts to enforce strict primary key integrity down to individual item vectors, removing all reporting bias.
Processed user account lifecycles to calculate onboarding completion latency across specific B2B verticals.
Programmed a real-time database filter to flag slipping user accounts precisely on Day 16 of transaction inactivity.

The Business Impact Metrics

Isolated an annual revenue leakage of R$ 600,600 (approximately $119,175 USD) stemming from 462 merchant accounts that stalled out completely during the onboarding phase.
Exposed an invisible latency anomaly where logistically complex business profiles stalled for an average of 112 days in domain routing and tax mapping phases.
Implemented a Day 16 early-warning database filter to flag at-risk accounts before they reached a terminal, zero-recovery retention cliff.

Project 4: CohortPace — SaaS Behavioral Retention Engine

Technical Stack: MySQL (Subqueries & Relational Joins), Cohort Modeling, Data Analytics
GitHub Codebase & Technical Report: [LINK]

The Operational Bottleneck

Initial application dashboards focused blindly on feature exploration depth, which completely masked why healthy-looking active user profiles were suddenly canceling subscriptions. Traditional active-user metrics acted as a lagging indicator, hiding friction because churning accounts remain active inside broken workflows right up to their exit timelines.

The Technical Implementation

Modeled simulated user cohort transactions across multi-platform SaaS behavioral profiles to analyze the core drivers of long-term Monthly Recurring Revenue (MRR).
Used advanced MySQL subqueries and relational joins to reconstruct full lifecycle interaction sequences.
Mapped user interaction velocity trends against subscription lifecycles to isolate clear behavioral churn signatures.

The Business Impact Metrics

Proved through data pacing sending signals that churning users maintain consistent interaction velocity close to their exit date, showing churn is driven by late-stage workflow utility limits rather than gradual disengagement.
Demonstrated that long-term user monetization is strictly dependent on habit formation within a single core workflow rather than broad, multi-feature platform exploration.

Conclusion: Turning Code Into Business Strategy

I don’t need a playbook to get started, and I don’t need a manager to hand me a static checklist. I find the question, ingest the data, clean the schemas, model the answer, and present the metric that directly protects business margins.

I am actively available for analytical remote contract roles, standalone data audits, and freelance pipeline optimization. If your startup is scaling fast and dealing with messy relational pipelines, let’s connect and fix your backend infrastructure loops.

Interactive Portfolio Hub: [LINK]
Contact: motiwala603@gmail.com
Connect with me: [LinkedIn]

Open to analyst remote roles across product, growth, and business analytics. Based in Pakistan, available worldwide.

I Wanted a RAG System That Could Show Its Work, So I Built Alchimista

Tue, 22 Sep 2026 13:05:47 +0000

Most RAG demos stop at the answer.Alchimista

You upload a document, ask a question, get a plausible response, maybe see a few source chunks, and that's where the story ends.

But I kept coming back to a different problem:

What happens when the answer itself isn't enough?

What if I need to know which evidence was used, what happened to sensitive data before processing, which policy was active, whether two tenants could ever see each other's documents, and what the system actually did rather than what its architecture diagram claims it should do?

That's where Alchimista started.

The idea

Alchimista is a self-hosted document intelligence and AI governance system built around a fairly simple principle:

An AI answer should leave evidence behind.

The basic path looks like this:

document → privacy processing → ingestion → retrieval → cited answer → decision evidence → audit

That sounds straightforward. Making all of those boundaries agree with each other was considerably less straightforward.

RAG wasn't the difficult part

Retrieving chunks and generating an answer is only one piece of the system.

The more interesting questions appeared around it.

A document belongs to a tenant. Retrieval has to respect that boundary.

An answer needs citations. Those citations need to point back to actual indexed evidence.

Sensitive information may need to be detected or pseudonymized before it reaches an external model.

If privacy processing fails, silently continuing with the original text is not an acceptable fallback.

And if the system records an AI decision, the audit trail shouldn't accidentally become another place where sensitive data leaks.

So Alchimista gradually became less of a "RAG application" and more of an infrastructure layer around the complete evidence path.

Privacy as part of the pipeline

Alchimista currently has several privacy modes.

At the strictest level, sensitive values are pseudonymized before chunking and embedding, meaning the normal retrieval index never receives their cleartext representation.

Reversible mappings live separately in an AES-256-GCM encrypted vault.

More importantly, enabled privacy policies fail closed. If the privacy service is unavailable or produces an invalid result, processing stops instead of quietly bypassing the protection.

That behavior matters more to me than adding another checkbox labelled "privacy".

Local first

An earlier version of the project leaned heavily on cloud infrastructure.

That worked, but eventually I wanted the core system to be independently runnable and inspectable.

The current baseline needs:

Docker with Compose
Python 3.11+
PostgreSQL

No GCP project, external vector database, Auth0 tenant, object store, or paid service is required.

The cloud integrations still exist as optional adapters, but they are no longer prerequisites for proving that the system works.

Starting it locally is intentionally boring:

git clone https://github.com/Daniele-Cangi/Alchimista.git
cd Alchimista
python scripts/init_local_env.py
docker compose up --detach --build --wait

Then the application is available locally with Documents, Ask, Privacy, Audit, Governance, and System in the same interface.

I wanted a proof, not just a demo

One thing I've become increasingly skeptical of in my own projects is a green UI that proves very little about the system underneath it.

So Alchimista has an end-to-end self-hosted smoke test.

It doesn't just check that the containers started.

It exercises ingestion, privacy detection, pseudonymization and restoration, protected persistence, SQL retrieval, citations, tenant isolation, AI decision evidence, audit metadata, the encrypted vault, cleanup behavior, and persistence across a PostgreSQL restart.

The successful end state is deliberately unexciting:

SELF_HOSTED_SMOKE_OK

But that line means much more to me than a screenshot of a chatbot answering a document question.

Some deliberate limitations

There are also things I don't want Alchimista to pretend.

It implements technical controls; it does not magically certify GDPR, the EU AI Act, or any other regulation.

PII detection cannot promise to identify every possible sensitive value.

The default local embedding path is designed to make the complete system independently runnable and test retrieval mechanics. It isn't a claim that a deterministic offline embedder is the best semantic retrieval system available.

And stronger pseudonymization can affect retrieval quality, which means strict privacy modes have to be evaluated against the actual domain rather than assumed to be free.

I think being explicit about those boundaries makes the system more useful, not less.

What's next

Alchimista is now at the point where I'm less interested in adding features for the sake of feature count and more interested in attacking the boundaries.

What breaks under larger document collections?

How much retrieval quality is lost under different privacy strategies?

Which pieces of AI decision evidence are genuinely useful during an investigation months later?

Where should the trust boundary actually sit when an external model is introduced?

Those are the experiments I'm interested in next.

This is also my first proper post on DEV, so I'll probably use this space less as a release feed and more as a place to document those experiments — including the ones that don't work.

Alchimista is open source and available on GitHub.

Feedback on the architecture, privacy model, or places you'd try to break it is very welcome.

Faker Doesn't Know Your Entities Are Related, So I Built Something That Does

Tue, 22 Sep 2026 11:22:33 +0000

You've added a second entity to the schema, wired up a @ManyToOne, and gone back to your seed script to generate fifty more rows. Ninety seconds later, the app refuses to start: unique constraint violation, somewhere inside a loop you wrote three weeks ago at 11pm. You fix it. You restart. A different field breaks a different constraint.

This is the exact moment every Spring Boot developer eventually meets the real limit of tools like Faker. They're brilliant at generating a name, an email, an address. They have no idea the Payment sitting in front of them needs a Counterparty to already exist.

So you do what everyone does: hand-write the wiring. Create parents first. Hold onto their generated IDs. Wire them into children. Hope you didn't just violate a @NotNull somewhere in the process. It works, for a while. Then the schema changes, and the script quietly stops matching reality until the next 3am debugging session finds out the hard way.

I hit this enough times that I stopped patching the script and looked at the actual problem: the information needed to seed this correctly already exists. It's sitting right there in the entity, in the annotations you already wrote. @ManyToOne, @NotNull, @Column(unique = true), JPA already knows the shape of your data. Nothing should need to be told that twice.

That became SynthForge.

The core idea

Instead of writing a script that generates data, you annotate the entity:

@Entity @Seed(count = 50)
public class Counterparty { /* fields only */ }

@Entity @Seed(count = 200)
public class Payment {
    @ManyToOne(optional = false) private Counterparty counterparty;
}

Start the app in a dev profile. Both tables populate, correctly ordered, on every restart. No seed method. No calling code, anywhere. The entity is the seed script.

What's actually happening underneath

Entity scanning. SynthForge reads JPA-managed attributes through the jakarta.persistence.metamodel.Metamodel API, not raw reflection. That distinction matters more than it sounds: only real persistent fields ever get touched, nothing that merely resembles one.

Relationship ordering. From the owning-side @ManyToOne/@OneToOne relationships, it builds a dependency graph and topologically sorts it. Parent rows exist before a child is ever generated to reference them. This is precisely where hand-written scripts fail first: the moment a second level of nesting shows up, manual ID-tracking becomes its own source of bugs, the thing you're debugging instead of your actual feature.

Constraint-aware generation. @NotNull, @Size, @Email, and a set of field-name heuristics (email, iban, amount, country) drive realistic values through Datafaker. Hit a @Column(unique = true) field, and instead of a constraint violation forty rows in, you get a bounded retry loop.

Idempotent restarts. A table that already has rows gets skipped. Restart against a persistent database as many times as you want; nothing duplicates.

"Isn't this just Instancio?"

Fair question, and worth answering directly rather than dodging it. Instancio, and its instancio-jpa extension, gives you an API to call from inside a test: build a graph, persist it, for that one test. It's genuinely good at that job.

SynthForge isn't called from anywhere. Annotate the entity, start the app in an enabled profile, and the database is already populated before your code runs a single line. Different tool, because it solves a different moment: application startup, not a single test method.

Where it stands

Live on Maven Central:

<dependency>
    <groupId>io.github.thembatman0</groupId>
    <artifactId>synthforge-spring</artifactId>
    <version>0.1.0</version>
</dependency>

Repo: github.com/ThembaTman0/synthforge

It won't fix your architecture and it won't make decisions for you. But the next time you add a foreign key at 11pm, there's a decent chance it means you get to go to bed instead.

I Got Tired of Building Backends for Forms, So I Built FORX

Tue, 22 Sep 2026 04:12:24 +0000

I Got Tired of Building Backends for Forms, So I Built FORX

I don't know if I'm the only developer who does this.

You need a simple contact form.

So you create the HTML.

Then you realize:

“Okay, where does this form data actually go?”

And suddenly your tiny contact form needs a backend.

You start thinking about API routes, databases, validation, authentication, email notifications, spam protection, deployment...

All that.

For a form.

That was basically the reason I started building FORX.

The problem

Let's say I'm building a portfolio.

I want a simple form where someone can enter:

Name
Email
Message

That's it.

I don't necessarily want to create a database.

I don't want to build an API.

I don't want to deploy another backend.

I just want the submissions to go somewhere.

And I realized this isn't only useful for contact forms.

The same thing applies to:

Waitlists
Feedback forms
Surveys
Job applications
Event registrations
Portfolio inquiries
Simple data collection
Landing page forms

A lot of these projects don't need a full backend.

They just need a place to send the data.

So I started thinking:

What if the backend was already there?

That's FORX

FORX is basically forms without the backend.

You create an endpoint with FORX, connect your form to it, and whenever someone submits the form, FORX receives the data.

Your architecture can look something like this:

Your website

 |
 | POST request
 v

FORX endpoint

 |
 v

Submission stored

 |
 v

FORX dashboard

That's the idea.

No database setup.

No API route.

No backend to deploy.

Just your form.

The simplest example

Imagine I have this contact form:

< form action="YOUR_FORX_ENDPOINT" method="POST">
< input

type="text"
name="name"
placeholder="Your name"
required

< input

type="email"
name="email"
placeholder="Your email"
required

< textarea

name="message"
placeholder="Your message"
required

> </ textarea >

< button type="submit">

Send message

</ button >
</ form >

Instead of writing my own API endpoint, I point the form's "action" to my FORX endpoint.

That's basically it.

When someone submits the form, FORX receives the POST request and handles the submission.

Your frontend doesn't really care where the backend is.

It just sends the request.

Why not just build a backend?

You absolutely can.

That's actually the point.

If you're building something complex, you probably should build your own backend.

FORX isn't trying to replace that.

But sometimes you're building something like:

portfolio.html
landing-page.html
contact.html

And you just need:

POST /contact

You don't want to spend an afternoon setting up infrastructure for it.

I know I don't.

I wanted FORX to feel stupidly simple

One thing I've been thinking about while building FORX is that infrastructure products can sometimes become more complicated than the problem they're solving.

I didn't want:

“Welcome to FORX. Before you create your first form, please configure seventeen things.”

I wanted something closer to:

Create endpoint

↓

Copy endpoint

↓

Put it in your form

↓

Receive submissions

That's the experience I'm aiming for.

But it's not just contact forms

This is probably the part I'm most interested in.

FORX can be used anywhere you need to collect data from a frontend without wanting to build the backend yourself.

For example, imagine you're launching a small project and want to collect emails.

You could have:

< form action="YOUR_FORX_ENDPOINT" method="POST">
< input

type="email"
name="email"
placeholder="you@example.com"

< button type="submit">

Join the waitlist

</ button >

Or maybe you're building a portfolio and want people to contact you.

Or you're making a small survey.

Or you want to collect feedback from users.

The frontend stays yours.

FORX just handles the boring part behind it.

One feature I really wanted: domain restrictions

There's also something I think is important when you're accepting submissions from the public.

You don't necessarily want your endpoint being used by random websites.

So FORX lets you configure allowed domains for an endpoint.

That means you can say:

This endpoint should only accept submissions from my website.

It's a small feature, but it's one of those things that becomes important once you actually put a form on the internet.

The developer in me still wanted an endpoint

I also didn't want FORX to feel like one of those form builders where you're forced into a specific UI.

Your form can still be completely yours.

You can use:

Plain HTML
React
Next.js
Vue
Astro
Svelte
Basically anything that can make an HTTP request

FORX doesn't need to know what your frontend looks like.

It just needs to receive the request.

That's what I like about the idea.

Why I built it

This project started from one of those “surely someone has already solved this” moments.

I was thinking about forms and backend infrastructure, and I realized there was an interesting gap between:

“I need a backend.”

and

“I need somewhere for this form submission to go.”

Those aren't always the same problem.

And maybe developers shouldn't have to build an entire backend every time they want to collect a few pieces of data.

That's basically what I'm trying to solve with FORX.

Not every form needs a backend.

Sometimes the backend should just exist.

FORX is still evolving

I'm still building it.

There are a lot of things I want to improve and add.

I'm also still figuring out exactly how far I want to take the product.

Because honestly, one of the fun parts of building something from scratch is discovering what people actually use it for.

Maybe someone will use FORX for a portfolio contact form.

Maybe someone will use it for a waitlist.

Maybe someone will do something I didn't even think about.

That's kind of the point.

Try it

If you're building a portfolio, landing page, survey, waitlist, contact form, or basically anything that needs to collect data, you can check out FORX here:

Create an endpoint, connect it to your form, and see how it feels.

I'm especially interested in hearing what you would use it for.

Because at the end of the day, I built FORX for a pretty simple reason:

I don't want to build another backend just to receive a form submission.

And maybe you don't either.

I Built Lens Browser Because the Internet Never Forgets

Mon, 21 Sep 2026 17:26:51 +0000

Every time we open a website, something happens behind the screen.

A request is sent.

A connection is created.

Scripts are loaded.

Trackers start working.

And quietly, information about us begins to leave.

Most people never see it.

They simply open a page, search for something, read an article, or watch a video — while invisible systems collect signals about their behavior.

The modern internet is powerful.

But that power often comes with a hidden cost.

Our data.

Your Data Is Not Free

Browsing history.

Interests.

Device information.

Location signals.

Online behavior.

These things have value.

Companies build products around this data. Advertisers use it to understand people. Analytics systems use it to measure behavior.

But the question is:

Do we really know how much of ourselves we give away every day?

Privacy should not be something only available to people who understand complicated settings.

It should be the default.

That is why I started building Lens Browser.

Not Another Browser

There are already many browsers.

Some are fast.

Some have beautiful interfaces.

Some have millions of users.

I did not build Lens Browser because the world needed another browser.

I built it because I wanted a browser that starts from a different idea:

The user should be in control.

A browser should be a window to the internet.

Not a tool that quietly watches the person looking through that window.

Privacy by Default

Lens Browser was designed around a simple principle:

Browse privately. No compromise.

It includes:

Dual-layer ad blocking using connection-level filtering and JavaScript interception
Anti-fingerprinting protection through Privacy Mode
Automatic deletion of history, cookies, and cached data when closing the app
Threat detection before dangerous pages fully load
Trusted and blocked domain management
Lightweight design with no account required

No sign-up.

No profile.

No unnecessary tracking.

Just open and browse.

Built Small, Built Carefully

Lens Browser is built with modern Android technology:

Kotlin
Jetpack Compose
MVVM architecture
Android WebView with custom privacy layers

The app is lightweight, around 10 MB, and supports Android 6.0+.

It is also open source under the MIT License.

I believe privacy tools should be transparent.

People should be able to understand what they use.

The Internet Was Built to Connect People

Technology should make life better.

It should help people discover, communicate, and create.

But as the internet evolves, we should not forget one important thing:

Behind every device is a person.

Not a data point.

Not a profile.

Not a target.

A person.

Lens Browser is my small contribution toward a more private internet.

A reminder that privacy still matters.

Try Lens Browser

Lens Browser is available for Android.

Download:
https://flagodna.com/lens-browser/

We Built Kolaboratr Because Finding the Right People to Build With Shouldn’t Be This Hard

Sat, 19 Sep 2026 02:44:16 +0000

There’s a pattern we keep seeing across indie development and creative communities.

One person posts:

“I have a project, but I need an artist.”

A programmer says:

“I’m looking for a team.”

A writer is looking for something worth joining.

A composer wants a real project to score.

A designer has an idea, but needs developers to help bring it to life.

Sometimes these people are in the same community.

Sometimes they’re only a few posts apart.

And somehow, they still never find each other.

That problem is why we built Kolaboratr.

{% embed https://youtube.com/shorts/NFo2aRf9ZYw?si=XcF9ijJWNIWQr0hG %}

What Is Kolaboratr?

Kolaboratr is a creator collaboration platform built to help people find projects, collaborators, and teams.

It’s designed for creators such as:

Developers
Artists
Writers
Designers
Composers
Animators
Project leads
Other people trying to build something with a team

Project leads can create a Kolab, explain what they’re building, list the roles they need, describe the collaboration or compensation arrangement, and manage applications and invitations.

Creators can build profiles around their:

Roles
Skills
Tools
Experience
Availability
Portfolio

The goal is simple:

Put the people looking for collaborators and the people looking for projects in the same place.

We’re Starting at Zero — And We’re Not Hiding It

Kolaboratr is brand new.

That means there aren't thousands of creator profiles already waiting inside.

There aren't hundreds of projects filling every category.

We could try to make the platform look established.

We'd rather tell people the truth.

We're building the first community right now.

We’re looking for the first real:

Developers looking for projects
Artists looking for teams
Writers looking for collaborators
Composers looking for games to score
Designers looking for people to build with
Project leads actively trying to form teams

If you join now, you aren't arriving after the community has already been established.

You're helping establish it.

Finding Someone Is Only the Beginning

Anyone who has worked on a collaborative project knows the problems don't disappear once somebody says:

“Sure, I’ll join.”

Then come the other questions.

Who owns the work?

Is the project paid, unpaid, or revenue share?

How is revenue divided?

Who gets credit?

Can contributors use their work in their portfolios?

What happens if somebody leaves?

What happens if the project gets cancelled?

And perhaps the most dangerous question:

“Wait... what did we actually agree to?”

That’s why Kolaboratr also includes Kolaboratr Kontracts.

Kolaboratr Kontracts

Kontracts give collaborators a way to document important project terms, including:

Compensation
Revenue sharing
Existing asset ownership
Ownership of new contributions
Licensing
Credit
Portfolio rights
Expected time commitments
What happens if someone leaves
What happens if the project is cancelled

Both parties review and sign the same version of the agreement.

Once finalized, that version is preserved as a record of what everyone actually accepted.

Kolaboratr Kontracts are not a substitute for professional legal advice when an attorney is appropriate.

They are a way to prevent important collaboration terms from existing only inside scattered DMs, Discord messages, and forgotten conversations.

Built by Vasken Interactive Studios

Kolaboratr is a product of Vasken Interactive Studios LLC.

We’re an independent game and software studio creating original games, apps, and creator-focused tools.

Our projects include games currently in development such as:

House of Brats
Last Haul
Shadow Realms

We're also building practical and creative software including:

Trucker Suite
PremiseForge
Kolaboratr

Different projects. Different audiences.

But there's a common theme:

Take an idea and turn it into something real.

Kolaboratr grew directly out of one obstacle that keeps appearing when people try to do exactly that.

Having ideas isn't usually the problem.

Having work to do isn't the problem.

Finding the right people who actually want to build something with you can be.

The Founding Kolaboratrs

Because we're building the initial community now, the first 1,000 members receive:

One full year of full access free
No payment card required
A permanent Founding Kolaboratr badge

That Founding badge stays with the account permanently.

It marks the creators who were there while the community was still being built.

We Want the Rough-Edge Feedback

This isn't a polished corporate announcement followed by:

“Thanks for using our product. Please submit feedback into the void.”

We're still actively building.

If you're one of the first people using Kolaboratr and something is:

Confusing
Awkward
Broken
Missing
Unnecessary
Harder than it should be

Tell us.

We especially want to hear from people who are genuinely trying to:

Find a project
Recruit collaborators
Build an indie team
Organize a creative project
Work across different creative disciplines

The first community has a real opportunity to influence how Kolaboratr develops.

Find Your People

If you're building something and missing the right person...

Or you're the person looking for something worth building...

Come help us build the first Kolaboratr community.

Join Kolaboratr

Find your people. Build something together.

— Vasken Interactive Studios LLC

I built a real MNA circuit solver from scratch, then wrapped it in Three.js

Fri, 18 Sep 2026 11:23:57 +0000

The problem with "circuit simulators" on the web

Most browser-based circuit tools either fake it (animate current flow without real math) or wrap an existing SPICE engine. I wanted to actually implement the math myself — a Modified Nodal Analysis (MNA) solver, the same technique real SPICE tools use under the hood — and then give it a 3D interface instead of the usual flat 2D schematic.

The result is CircuitForge: place components on a 3D breadboard, wire them up, and get real computed node voltages and branch currents — not an animation.

The actual solver

MNA builds a matrix from Kirchhoff's Current Law at every node, plus extra equations for voltage sources, then solves it. Stripped down, the core loop looks roughly like this:

const g = 1 / resistance;
matrix[nodeA][nodeA] += g;
matrix[nodeB][nodeB] += g;
matrix[nodeA][nodeB] -= g;
matrix[nodeB][nodeA] -= g;

Solve Ax = z for the node voltage vector, and you get exact values — not an approximation. I validated it against hand-calculated results on a few real circuits (simple divider, diode network, a series-parallel KCL cross-check) before trusting it in production. Full writeup with the actual worked numbers is here: luvaai.in/learn/circuit-simulator-accuracy-validation.

Then the fun part: making it 3D

Three.js handles the scene, camera, and raycasting for placing/wiring components. The tricky bit wasn't rendering — it was making wire connections feel physical: snapping to component pins, detecting valid connection points, and keeping the 3D positions in sync with the underlying circuit graph the solver actually operates on. Two completely separate data models (3D scene graph vs. circuit netlist) that have to stay perfectly consistent.

What it can't do (yet)

Being upfront: this is DC operating-point analysis only right now — no transient simulation, no AC frequency sweeps. If you need to see a capacitor charge curve over time, this isn't there yet. It's on the roadmap, but I'd rather ship an honestly-scoped DC solver than fake a transient one.

Try it

Live at luvaai.in — no signup needed, just start placing components. If you've built anything with raycasting-based node/wire editors, or have thoughts on extending MNA to transient analysis, I'd love to hear it in the comments.

Two years of pelicans on bicycles: 103 SVGs, 66 models, and what the guy who invented the benchmark says about it

Fri, 18 Sep 2026 01:30:04 +0000

In October 2024, Simon Willison gave sixteen LLMs the same eight words:

Generate an SVG of a pelican riding a bicycle.

He has been running it on every new model since. Twenty-three months later there are 103 of these drawings scattered across dozens of his posts, and he has written a section explaining why you should not use his benchmark to compare models.

We pulled all of them into one page — pelicanzoo.ai — because reading them in order turns out to be a surprisingly good history of the last two years. This post is what we learned putting it together, and how the thing is built.

Everything here is Simon's work. The images, the commentary and the judgement calls are his; we mirrored and organised them, and every specimen links back to the post it came from.

The prompt is deliberately unfair

His stated reasons are mundane: he likes pelicans (he lives in Half Moon Bay, they're on the beach), and he was confident no SVG of a pelican on a bicycle existed in any training set.

The reasons it works are better. LLMs are text models that can't see, but they can write code, and SVG is code. So the task is to assemble a picture out of coordinates and radii with no feedback loop — the model never sees what it drew. Bicycles are hard for humans to draw from memory (try it: you'll get the frame wrong). And, in his words:

Pelicans can't ride bicycles. They don't have the right shape.

There's a bonus that matters more than it sounds: models leave comments in the SVG. , . You can read what it meant to draw and compare it against what came out. The gap is usually the joke.

2024: it's mostly shapes

The early attempts are bad in specific, funny ways. Claude 3.5 Sonnet produced two circles, a triangle, and a beak Simon described as a yellow banana smile. Llama 3.3 70B drew a small circle, a vertical line, and something shaped like a sink. Qwen2.5-Coder's bicycle is a pile of brown shapes that reads as a tractor. Mistral Small 3 delivered a squat white duck squatting on a barbell.

Then DeepSeek R1 landed in January 2025, and shortly afterwards Nvidia lost about $600bn in market cap. Simon later singled its pelican out as "the pelican that crashed the stock market" — the best one so far: a recognisable bicycle, a bird next to it that's arguably a pelican, not actually riding it.

For that first year the drawings tracked real capability fairly well. Models that drew better pelicans were better at writing code. A joke about how silly model comparisons are started behaving like a real benchmark.

The 560-match tournament that cost 18 cents

By June 2025 he had 34 pelicans and wanted a ranking without looking at 34 images himself.

So he had Claude write a tool that renders any two pelicans side by side and screenshots the pair. 34 images, every pairing, 560 matches. Each match went to GPT-4.1 mini with instructions to pick the better "pelican riding a bicycle" illustration and explain why. Elo scores out of the results.

Total judging cost: about 18 cents.

Winner was a Gemini 2.5 Pro preview; last place, Llama 3.3 70B. The judge's reasoning for that matchup: the left image clearly depicts a pelican riding a bicycle, the right is a few minimal shapes that don't read as anything.

The same talk includes the cost comparison that stuck with me. o1-pro: 88.755 cents for one pelican. Gemini 2.5 Pro: 4.77 cents. Gemini's was better.

The models start editorialising

August 2025, Simon runs Qwen3-4B-Thinking locally. It declines to draw a bicycle. It returns a blue circle with red text across it:

This is art - pelicans don't ride bikes!

He made that the headline of the post.

In November, Gemini 3 at low reasoning effort gave its pelican a little hat, with an SVG comment reading hat (optional fun detail). At high effort the frame geometry was finally correct.

He decided the task had gotten too easy and escalated: a California brown pelican, bicycle with spokes and a correct frame, large gular pouch, visible feather texture, unambiguously pedalling, in breeding plumage. He attached a photo he took himself.

Most models missed the detail that makes it a trick question — the California brown pelican isn't brown.

The laptop model that beat Opus

April 16, 2026: Qwen3.6-35B-A3B and Claude Opus 4.7 shipped the same day. Simon ran Qwen as a 20.9GB quantised model on his MacBook and Opus through the API.

He gave it to Qwen. Opus got the frame geometry wrong, and got it wrong again at maximum reasoning effort.

This result made him suspicious of his own benchmark. There's a persistent theory that labs train against his "stupid test", and he'd been keeping a spare prompt in reserve for exactly this moment. He burned it: a flamingo riding a unicycle.

Qwen's flamingo wears sunglasses and a bow tie, appears to be smoking, and is flanked by heart emoji and the caption "Flamingo on a Unicycle". The source comment says Give the flamingo sunglasses!. Opus drew a competent, entirely unremarkable flamingo. That one went to Qwen as well.

His own framing was careful: he has enormous respect for Qwen, and he does not believe a 21GB quantised model is more useful than Anthropic's latest flagship. But if the thing you want is an SVG of a pelican on a bicycle, the laptop won that day.

That's roughly where pelican quality and model capability stop tracking each other.

The inventor says don't use it

Kimi K3, July 2026. Its pelican burned 13,241 reasoning tokens and cost 25 cents. Simon used the post to write a section on what the benchmark is still good for.

His conclusion after 21 months: it was never a good benchmark. The correlation in year one was a surprise and it's basically gone now — GLM-5.2 draws a better pelican than GPT-5.6 or Claude Fable 5, and he doesn't think GLM is in that class. More importantly it tests nothing about what actually matters today, namely whether a model can hold a long conversation and call tools reliably. His words: don't use pelicans to compare models.

So why keep going? Two reasons, both practical:

It forces him to actually run each new model. Posting a pelican is proof he got the thing working, rather than just reading the launch post.
Even one prompt leaks information. On the Kimi K3 run he noticed his eight-word prompt was billed as 95 input tokens, and sending just "hi" cost 86 — implying about 85 tokens of hidden system prompt.

September 1, 2026: Claude Fable 5.1, across five reasoning levels. Low and medium barely think and finish in about twenty seconds. Maximum ran 13 minutes 54 seconds, emitted 65,927 tokens, cost $3.30, and produced a pelican in a blue cap with a fish in the basket. Best pelican he's seen from Anthropic.

The benchmark has become a ritual rather than a measurement. It won't tell you which model is strongest. One pelican's invoice and reasoning trace will still tell you a lot about how a model works, and whether it'll decide on its own to put a hat on your bird.

Building the zoo

The drawings live across two years of posts, which makes reading them in sequence tedious. So: one page, 103 specimens, 66 models, 12 vendors, October 2024 to now. Each one is tagged with model and date and links back to Simon's original post.

A few things that turned out to be more interesting than expected:

24 of them are still vector. Where the original SVG survives, the page serves the SVG — zoom in as far as you like, and four of them are animated (wheels turning, pelican bobbing). The rest exist only as screenshots from his conference slides, so they're labelled print rather than live. Making that distinction visible mattered more than we expected; a screenshot of an SVG and the SVG are not the same artifact, and the ones that are still code are the ones you can actually inspect.

The critic reads source, not pixels. There's a button under each specimen that asks a model to review the drawing — and it's given the SVG source, not an image. Half of that is cost. The other half is that it's funnier and more specific: it can complain that the body is an ellipse of radius 104, or that the rear wheel is out of proportion with the frame. Using models to review models closes a loop that probably shouldn't be closed.

Submissions have no backend. You can paste in an SVG a model drew for you. The page sanitises it in the browser, then generates a pre-filled GitHub pull request. No server, no database — one pelican is one file. It's a static site on Cloudflare.

The sanitiser is the part I'd actually defend in review. Model-generated SVG pasted in by strangers is untrusted markup, so it strips <script>, <foreignObject>, iframe/object/embed, inline on* handlers, javascript: URLs, @import, and any remote href/src/url() reference. Data URIs stay — they're self-contained. Remote references go because they leak the visitor's IP to whoever hosts them and let someone swap the picture out later.

Two design decisions in there I'd repeat:

// It reports what it removed instead of only returning a cleaned string.
// @returns {{ ok, svg, removed: string[], error }}

The same function runs in three places — the static build, the browser preview, and CI on incoming pull requests. Because the site strips before it builds the PR, a submission that still arrives dirty was hand-crafted, so CI stops it for a human to read rather than silently cleaning it. A sanitiser that returns a clean string and nothing else throws away the signal that someone was trying.

The other one is dull and bit us first:

// Percentages need something to be a percentage of; without a viewBox an SVG
// whose width/height we strip will stretch to fill whatever box it lands in.

We strip fixed width/height so specimens scale in a grid. Do that to an SVG with no viewBox and it stretches to fill its container. So the sanitiser synthesises one from the original dimensions when it's missing.

There's also a guessing game — you get a drawing and four model names, 73 rounds over 51 models. Distractors are picked from different vendors on purpose. Three Gemini variants side by side isn't difficult, it's just unfair. The 2024 ones are easy. The 2026 ones are basically a coin flip, which is its own kind of result.

Credit

The images and the original keeper's notes are Simon Willison's, collected from his posts, and the footer links back to his pelican-riding-a-bicycle tag. We built the cage, not the birds.

If you've got one that's especially good, or especially wrong, the submission box takes it.

pelicanzoo.ai

Sources

Pelicans on a bicycle (2024-10-25)
The last six months in LLMs, illustrated by pelicans on bicycles (2025-06-06)
Trying out Gemini 3 Pro with audio transcription and a new pelican benchmark (2025-11-18)
Qwen3.6-35B-A3B on my laptop drew me a better pelican than Claude Opus 4.7 (2026-04-16)
Kimi K3, and what we can still learn from the pelican benchmark (2026-07-16)
Claude Fable 5.1 made me a really nice animated pelican (2026-09-01)

Turning YouTube Videos Into Obsidian Notes — and What Shipping the Plugin Taught Me

Fri, 18 Sep 2026 01:29:36 +0000

Every so often I'd watch a 90-minute conference talk, close the tab, and realise the only trace it left in my vault was a URL in a list called "watch later (again)".

So I built an Obsidian plugin that turns a video into an actual note. It's been in the community directory since September and is on 0.3.0 now. This is what it does, and — more usefully — the handful of decisions and review rules I'd want to know before building another one.

What lands in the vault

One command, one link, and you get a note:

a TL;DR callout and key insights
an embedded player at the top — timestamps seek it in place, without leaving the note
chapters as timestamped bullets
optional summary (several templates), quiz, and full transcript in a collapsed callout
frontmatter with title, source, channel, language and tags, shaped for Dataview

Plus a right-sidebar chat panel scoped to the note you're reading, and a command that turns the quiz into Spaced Repetition cards.

Now the parts that were actually decisions.

The plugin holds no model keys

An Obsidian plugin runs on the user's machine. You can't ship an API key in it, and asking every user to paste their own is both friction and a support queue you will personally staff forever.

So the plugin generates nothing. It sends a video link and an account token to a server, and writes down what comes back. That's the whole client.

The honest trade-off: this means the plugin needs an account, which is a real cost to the user and something I put in the README under a Before you install heading rather than burying. A plugin that silently requires a signup is a plugin that gets one-starred.

The connect handshake, and the one line that makes it safe

Settings → Connect opens the browser at /connect/obsidian?state=…&vault=…. You sign in, the server mints a token, and the page bounces you back via obsidian://svt-connect?token=…&state=….

The state is generated by the plugin and checked when the redirect comes home. Without that check, any web page could deep-link a token into your vault — the obsidian:// scheme is open to anyone. It's four lines of code and it's the difference between a handshake and a hole.

Server side the token is stored as a sha256 hash. Client side it lands in .obsidian/plugins/<id>/data.json, which is worth saying out loud in your docs: if the user syncs their vault, that file goes with it.

One note format, two producers

The website also has an Export → Obsidian button. That's two code paths producing "the same" Markdown, which in my experience drift apart within about a week.

So the Markdown is assembled in exactly one place — a server endpoint — and the plugin writes whatever it receives verbatim. The website button and the plugin produce identical notes because they are, literally, the same function call.

Re-running a command must not eat the user's writing

People add their own notes under the generated stuff. Refreshing a note has to be non-destructive or nobody will ever press it twice.

The generated region is fenced:

%% svt:start %%
…everything the server produced…
%% svt:end %%

## My notes
whatever you wrote, untouched

Refresh replaces only what's between the markers. Frontmatter is the subtler half: the server returns an ownedKeys list alongside the note, so the plugin overwrites the keys it owns and leaves every key you added alone. Writes go through vault.process rather than read-then-write, which is also what the community review expects.

`requestUrl` doesn't stream

Obsidian's requestUrl sidesteps CORS, which you want, because your plugin isn't an origin anyone will whitelist. What it doesn't do is stream.

My summary endpoint is server-sent events. So the plugin waits for the whole response and parses the event stream after the fact. You lose the progressive typewriter effect; you keep mobile support and never fight a preflight. Worth knowing before you architect around a stream that won't arrive.

Flashcards, and only appending

0.3.0 turns the quiz into a card note: multi-line format, the right answer and its explanation on the back, and a timestamp link to the moment the question came from.

Run it again after new questions appear and only the missing cards are appended. Existing cards, their  review schedules, and any cards you wrote yourself are never touched. Rewriting a review schedule is the fastest way to lose a user who has been reviewing for six months.

What the community directory review actually checks

Submitting is no longer a PR against obsidian-releases. You log in at community.obsidian.md, link GitHub, and an automated reviewer runs. Mine came back with a list. The useful items:

No inline styles. Anything you'd reach for as el.style.foo = bar belongs in styles.css. My auto-growing textarea became the CSS field-sizing: content instead of a resize handler, which is a better implementation anyway.
Settings must use the declarative 1.13 API (getSettingDefinitions() with groups, getControlValue / setControlValue). That forced minAppVersion up to 1.13.0, because the no-unsupported-api rule rejects 1.13 APIs while you claim to support older versions. Pick a lane; you can't straddle.
Attest your build. actions/attest-build-provenance in the release workflow, with id-token and attestations write permissions. gh attestation verify main.js --owner <you> exiting 0 with no output is what success looks like.
The tag must match the manifest version, and npm version writes tags with a v prefix that Obsidian doesn't want. git tag -d v0.2.2 && git tag 0.2.2.

One false alarm worth pre-empting: right after I re-cut a release, the checker insisted "No release matches your manifest version." It had scanned during the draft window and cached that. Re-scan, it passes. Don't go rewriting your workflow like I nearly did.

Three Obsidian CSS facts that cost me an evening

.view-content ships with padding: 12px 12px 32px. If your custom view's layout looks mysteriously inset, that's why. Zero it with a same-specificity selector: .workspace-leaf-content[data-type="…"] .view-content.your-class.
On desktop the status bar is position: fixed, 27px tall, and floats over the bottom of the right sidebar. Leave it room or your input box is permanently half-covered.
button:not(.clickable-icon) picks up Obsidian's background and shadow. For a text link, use an <a>.

Links

Plugin: community.obsidian.md/plugins/summarize-video-to-text
Source (MIT): github.com/diaozxin007/obsidian-summarize-video-to-text
Setup walkthrough: summarizevideototext.com/obsidian-plugin

If you're building something that writes into other people's vaults, the markers-and-ownedKeys pattern is the piece I'd steal. Everything else was replaceable; that one is what makes a destructive command safe to press twice.

I built an all-in-one AI workspace (Chat, Code, Live Web Research, Docs & Images) — looking for tech

Thu, 17 Sep 2026 12:38:47 +0000

Hi everyone,

I wanted to share a project I've been working on to solve my own daily workflow frustration: SMS AI SMS AI.

The goal was to build a highly responsive, unified three-pane workspace where you can handle complex code generation, live web research, document parsing, and visual generation without constantly swapping tabs or losing your active chat state context.

What's Built-In Right Now:
*Asynchronous Token Streaming Chat: Smooth, word-by-word token delivery with Markdown formatting and native syntax-highlighted code rendering blocks.

Intelligent Coding Assistant: Formats, refactors, and explains code across multiple programming languages instantly without freezing the browser execution thread.
Live Web Research Integration: Executes live web queries and dynamically infuses clickable, cited research sources straight into the conversational interface.
Document Parsing RAG Pipeline: Drop in dense PDF, DOCX, or TXT documents to instantly run automated local passes to pull summaries and extract key text insights.
In-Chat Multimedia Actions: Native speech-to-text dictation mechanics alongside instant visual art generation using dedicated in-chat model toggles.

⚙️ The Tech Stack:

Frontend UI Layout: React + Vite + Tailwind CSS for a hyper-lightweight layout structure and fast initial load speeds.
Backend Cloud Infra: Native Supabase integration to manage user session authentication states securely.

The workspace features a completely live 100% free tier (10 messages per day, no credit card required) so you can jump in and try it out.

I’m looking to aggressively optimize the layout, performance, and API delivery speeds. Please throw some tough optimization tasks or complex data sheets at it. What features do you feel are missing? What feels slow? I'll be monitoring the comments to answer any technical questions about the architecture!

I Love Fragrances, So I Built a 6-Game Arcade + Concierge About My Obsession

Sun, 13 Sep 2026 12:02:18 +0000

Hi, my name's Ibrahim, I'm a university student, and I have a problem: I love fragrances way more than my bank account loves me for it.

It started small, the way these things always do. A cheap Middle Eastern attar someone gave me as a gift, the kind that costs less than a coffee but somehow smells like it belongs in a much fancier bottle. Then another. Then I started actually reading about notes, pyramids, accords, sillage, the whole rabbit hole. Fast forward through a lot of saved-up allowance and skipped nights out, and I've now got about 20 bottles on my shelf. Mostly affordable Middle Eastern gems (some of them genuinely punch way above their price), with a small handful of designer pieces I saved up for and treat like trophies.

If you're a fellow fragrance enthusiast, you already know the feeling: you don't just "wear" a scent, you collect them, you study them, you have opinions about whether a note is top, heart, or base and you will absolutely fight someone about it. That obsession is basically the entire reason this project exists.

So when I saw the DEV Weekend Challenge's "Passion" prompt, there was only one thing I could possibly build.

What I built: recommendmeafragrance

recommendmeafragrance is a browser arcade for fragrance nerds: six small daily games built around real perfume data (notes, brands, years, price tiers), plus an AI Concierge you can actually talk to about what you're in the mood for. Every game feeds into a personal "shelf" that tracks which fragrances you've discovered, plus streaks so you have a reason to come back tomorrow.

Here's the tour.

Scentle: Wordle, but for your nose

A new fragrance is picked every day (the same one for everyone, worldwide, no matter your timezone). You get 6 guesses, and after each one you get Wordle style feedback: was the brand exact or just the same house family, did the real answer come out earlier or later than your guess, is it pricier or cheaper, same gender, same concentration, how many notes do you actually share. You can even copy a little emoji share-grid at the end, because obviously.

There's now an Easy/Hard toggle: Easy leans on a famous, recognizable bottle for the day; Hard pulls from the deep catalog for people who want a real challenge.

Note Detective: reverse engineer a scent from its notes only

This one's my favorite. You're given nothing but notes, revealed one at a time in rotating order (one top, one heart, one base, cycling through the pyramid), and you have to guess the perfume before your score hits zero. Every note you reveal costs points, but the cost is calculated as a percentage of that specific perfume's total note count, so a fragrance with 6 notes and one with 16 notes both cost the same fair share to fully reveal. As you burn through reveals, letters of the name itself slowly uncover hangman-style, so there's a nice tension between "guess now" and "wait, I need one more hint."

Also has an Easy/Hard mode, same famous-vs-deep-catalog split as Scentle.

Build-a-Bottle — invent your own scent, find out what it actually is

Pick as many top, heart, and base notes as you want from a searchable list of hundreds of real notes, hit "invent," and the app runs a weighted similarity match (base notes count extra, since they carry a scent's identity the most) against the whole catalog to tell you what you basically just invented, plus two runner-up matches. It also treats closely related notes as the same family (so picking "vanilla" still matches perfumes listed under "Madagascar vanilla," etc.), because with hundreds of real notes in the system, exact-string-only matching would've been brutal.

Higher or Lower

Two perfumes, one question: which came out first, or which one's pricier? Keep guessing right to build a streak, one miss ends the run. Easy mode keeps the gap obvious and leans on famous bottles; Hard mode pulls from the deep catalog and can come down to a single year or price tier.

Scent Roulette

Set some dials (season, occasion, how much chaos you want), pull the lever, get a fragrance recommendation that actually respects your filters instead of just being random.

Swipe through fragrances blind, no brand or hype attached, just notes and vibe, and decide "buy" or "skip." At the end it tells you your "nose score," how many of your buys were actually the famous, universally-loved ones. Humbling, honestly.

Meet the Concierge

Alongside the games there's a chat-style AI Concierge, built to feel like the app's little mascot come to life: warm, encouraging, genuinely curious about what you like, not just a recommendation-spitting bot. Tell it "something warm and cozy for winter nights" and it'll actually ask a follow-up question before throwing fragrances at you, and when it does recommend something, it comes with a real, buyable card attached, not just a name typed in a chat bubble.

Bringing Google AI into it

This is where I'm submitting for the Best Use of Google AI category. The Concierge runs on a shared daily budget by default so everyone gets to try it for free, but I added a "bring your own Gemini API key" option: paste in a free key from Google AI Studio, and the Concierge switches over to running entirely on Gemini for you, with zero daily limit. The key never touches our servers, it lives only in your browser's local storage and gets sent along with your own requests, so you're fully in control of it. It felt like the right way to let people who want unlimited access get it, without me needing to foot an unlimited AI bill as a student running this on personal savings.

Real bottles, real links

None of this matters if it's just a trivia game, so every single fragrance in the catalog (over a thousand of them) is linked to a live, working offer through FragranceShop.com. Win a game, discover something in the Concierge, or just click "buy" on a card, and it adds to your personal shelf and takes you straight to a real product you can actually purchase. It's a small, honest way to make an app about a hobby self-sustaining without shoving ads in your face.

Try it

recommendmeafragrance.com

No pressure to sign up for anything just to poke around, though creating a free account (Google sign-in, ten seconds) saves your streaks and shelf across devices and unlocks the Concierge chat.

Closing thoughts

I've genuinely lost track of how many hours went into this between actual classwork, but every time I opened a new bottle from my (very modest, very Middle-Eastern-attar-heavy) collection for "research," it felt worth it. If you're even a little bit of a fragrance nerd, or you just like small, weird, well-made web games, I'd love for you to come play and tell me what your nose score is.

weekendchallenge #googleai #webdev #showdev

I built an async wrapper for OpenAI/Anthropic SDKs because I didn't want a proxy in my request path

Sun, 13 Sep 2026 06:46:31 +0000

I kept running into the same tradeoff building cost tooling for teams shipping LLM features. Every attribution tool in this space works the same way: you point base_url at a proxy, and it sees every call before it happens. That's genuinely useful if you want to block or downgrade a call before it fires. It also means the proxy's uptime is now your uptime, and you've added a network hop to every single request.

I wanted the attribution without touching the request path at all. So I wrote a wrapper instead.

Cognocient wraps the OpenAI and Anthropic Python clients directly. You still call client.chat.completions.create() exactly the way you always did. The wrapper times the call, then fires a cost report on a background thread after your real response has already returned to your code.

The part I actually spent the most time on wasn't the happy path, it was making sure a dead reporting endpoint can never touch your application. If Cognocient's ingestion API is slow, down, or just does not exist, that failure has to stay invisible to whatever you're building. No exception bubbling up, no retry pile-up blocking your real call. There is a test, test_reporter_failure_isolation.py, that specifically points the reporter at an unreachable host and asserts the actual API call still returns clean. Writing that test is what convinced me the design was sound, not the other way around.

What you get: per-call cost, and tags for feature/team/user if you want chargeback-style reporting later.

What you do not get, on purpose: pre-call blocking. If a call is about to blow your budget, this wrapper finds out after it already happened, same as any billing dashboard does. If you need to stop a call before it fires, you want a proxy, and honestly LiteLLM or Portkey do that well. This is for people who've already decided visibility without a critical-path dependency is the right tradeoff for their setup.

Also worth knowing before you reach for it: streaming responses (stream=True) aren't reported yet. If most of your traffic streams, this won't give you complete numbers right now. Non-streaming is solid, I would call it production-safe there. Streaming is next.

from cognocient import CognocientOpenAI as OpenAI

client = OpenAI(api_key="sk-...", cognocient_key="sk-cog-...")
# everything else about the client works exactly like before

MIT licensed, signed provenance on the PyPI release, genuinely early (v0.1.x). If you're already routing through a gateway and it is working for you, this probably isn't for you. If you have been putting off cost visibility specifically because you didn't want another hop in the path, I would like to hear if this is useful or if I have missed something obvious.

GitHub: https://github.com/mandarvshinde/cognocient-python-wrapper
PyPI: pip install cognocient

Marla to Gaj (Square Yard) Conversion: A Simple Tool I Built for My Local Marketplace

Thu, 10 Sep 2026 18:45:17 +0000

If you've ever bought or sold property in Pakistan, you've run into this problem: land size gets quoted in marla, kanal, square feet, or gaj (square yards) — often interchangeably, depending on who you're talking to. A property dealer might tell you a plot is "5 marla," while the registry documents list it in square yards, and a buyer coming from a different city might only think in gaj.

That mismatch causes real confusion — and sometimes real money lost — during property deals.

So when I was building Connect Bazaar, a local marketplace and services platform for Pirpiai and Nowshera, I added a simple Marla to Gaj calculator as part of a broader Property & Land tools section.

Here's the conversion logic, and why a dedicated tool beats just Googling the number.

The Basic Conversion

In most of Pakistan, the standard conversion used is:

Unit	Equals
1 Marla	≈ 30.25 square yards (gaj)
1 Kanal (20 Marla)	≈ 605 square yards (gaj)

Marla → Gaj

Gaj = Marla × 30.25

Gaj → Marla

Marla = Gaj ÷ 30.25

Simple math — the friction isn't the formula, it's that nobody wants to redo it manually every time, especially when comparing several plots or double-checking what a dealer just quoted.

Why a Dedicated Calculator Actually Helps

Speeds up real decisions. Comparing 3–4 plots quoted in different units? Converting everything to one unit makes the comparison honest and fast.
Reduces reliance on the dealer's math. Buyers can independently verify what they're being told — which matters a lot in informal or semi-formal property markets.
One less spreadsheet. A shared, always-available tool replaces everyone's personal napkin-math formula.
How It Fits Into Connect Bazaar

The calculator lives inside the Property & Land tools category, alongside other land conversion tools (marla, kanal, square feet, plot area). It's built mobile-first, since most users check it standing on-site at a plot or mid-conversation with a dealer — not sitting at a desk.

Try it here: Property & Land Tools on Connect Bazaar

If you're building something similar — a local utility site, a regional marketplace, or any tool involving unit conversions people rely on for real transactions — I'd love to compare notes in the comments.

What conversion or utility tools have you found genuinely useful (not just "nice to have") on a niche or local website?

One I can't finish, one I can't measure

Sat, 05 Sep 2026 15:40:23 +0000

I shipped two things this week that could not be less alike.

One is an integration against the SaaS that most process-serving firms run their dispatch on — a system of legal record, where a wrong write becomes a wrong document attached to a real court case. The other is a 24.92 KiB Chrome extension containing a dinosaur that walks across your page and refuses to leave.

They have exactly one thing in common, and it took me until I'd written both up to notice it: each one has a hole in it that I put there on purpose.

One I can't finish. One I can't measure.

The one I can't finish

ServeManager speaks JSON:API, not flat REST. If you've never hit that shape before, the first thing it does is lie to you quietly:

// Returns undefined. Does not throw. Ships to production as a blank column.
const status = job.data.service_status;

// The scalar actually lives here
const status = job.data.attributes.service_status;

Relationships are worse — they're pointers, not objects, and the thing they point at lives in a separate top-level included array you have to resolve yourself. Getting a court name off a job is three hops:

const resolve = (included, ref) =>
  ref?.data
    ? included.find(i => i.id === ref.data.id && i.type === ref.data.type) ?? null
    : null;

const courtCase = resolve(included, job.data.relationships.court_case);
const court     = resolve(included, courtCase?.relationships?.court);
const courtName = court?.attributes?.name;   // null-guard every hop

Every one of those failure modes is silent. Nothing throws. You get undefined, it flows through your mapper, and it lands in a report as an empty cell — in a domain where an empty cell means "we have no idea whether this person was legally served."

So here's the hole. There is one write I have never confirmed: attaching a file to an already-existing job. The documented flow covers uploading during job creation. The attach-afterward body schema, I have never captured from a real request.

I could infer it. The create flow is right there, the naming is consistent, and I'd probably be right.

"Probably right" is a fine standard for a side project and a terrible one for a system of legal record. A malformed write here doesn't throw an exception — it produces a wrong document on someone's real case, and nobody finds out until the day it matters. So the feature is gated. It does not run against production. It sits there, unfinished, until I spend the hour with a network tab open and capture what the request actually looks like.

The full writeup, with the status codes that look like your bug and aren't (406, 409, and a 403 that's a permissions level rather than a bad payload), is here: The ServeManager API is a document, not a record.

The one I can't measure

Same week. Different universe.

Annoying Dino is a Manifest V3 extension that puts a tiny T-Rex in your browser. You can tap him, feed him, or ignore him. His mood shifts based on which you pick. There's an egg-and-hatch collection running alongside. That's the product. It is the least ambitious thing I have ever shipped.

It is also, by a factor of nearly five, the most-installed thing in my portfolio.

I didn't want to write that sentence without checking it, so I counted every listing:

Extension	Installs
Annoying Dino	19
Arcanum Idle	4
Dino Dots	4
Planet Express Lounge	3
Cobalt Star / Kawaii Time Garden / Spellsurge / Hot Dog Rush	2 each
Devotion	1

Four listings wouldn't surface a count at all, so the honest version is "leads everything I could measure." Nineteen users is not a business or a validation — it's nineteen browsers. But it beats the idle game with nine automated test suites, and that gap is the interesting part.

Here's the hole: I have no idea whether any of those nineteen people have opened it since.

There is no analytics in any of my extensions. No event pings, no install beacon, no heartbeat. I check that the way I check a bug — grep the whole codebase for network APIs before the privacy claims get written. Which means I cannot tell you a retention curve, a DAU number, or whether the feeding mechanic is the part people actually like. I can't even tell you if it's broken on someone's machine right now.

Anyone with an analytics tag would have known all of that on day two.

And I still won't add one — because of what this specific extension is. It runs on the pages you visit. Any usage telemetry worth having from it would be, functionally, a log of when you were browsing and what you were looking at when a cartoon reptile walked past. There is no version of "just a little event tracking" there that isn't a surveillance surface wearing a joke costume.

Full numbers and reasoning: The most-installed thing I have built is a dinosaur that bothers you.

I thought these were opposites. A legal-record API and a joke dinosaur; maximum consequence and zero consequence.

They're the same decision made twice.

In both cases there was a shortcut available that would have made the product better on paper. Infer the field shape and ship the attach feature. Add three lines of telemetry and finally know if anyone plays the thing. Both shortcuts are small, normal, and what most people would do without a second thought.

And in both cases the cost of taking the shortcut lands on someone who is not me. A guessed field shape puts a wrong document on a stranger's court case. A telemetry ping puts a stranger's browsing pattern on a server. The benefit is all mine — a shipped feature, a retention chart — and the risk is all theirs.

So the rule I've ended up with is not "be careful." It's narrower than that:

When the shortcut's upside accrues to you and its downside accrues to your user, the shortcut isn't a tradeoff. It's a transfer.

The follow-on is that you have to be willing to hold the gap. Ship the integration with the feature switched off and say so. Ship the extension and admit publicly you can't measure it. Both look like weakness in a portfolio. Both are the actual engineering.

The unglamorous coda: neither hole is permanent. The attach schema needs one hour with DevTools open. The dino telemetry is never coming — but the install count is a real signal, and it already told me something I didn't want to hear about the gap between what I find interesting to build and what a stranger will actually click.

If you want the longer versions, I keep the case studies at dhseadev.online/writing and the running devlog at dhseadev.online/updates. Everything I ship is local-first, no accounts, no telemetry — which, as established, is occasionally very inconvenient for me.

What's the shortcut you refuse to take, and what does it cost you?

How an Abandoned Client Project Became My Proudest Showcase

Tue, 01 Sep 2026 15:07:19 +0000

In the first part of this series, I walked through the technical grit of rebuilding a musician's web platform from scratch—spending over 320 hours fixing legacy WordPress code, writing custom CLI tools with Node.js and FFmpeg, and crafting a lightweight Vanilla JS SPA router.

If Part 1 was about the engineering side, Part 2 is about the human side: scope creep, irrational client expectations, and why finishing an "abandoned" project is sometimes the ultimate test of a developer’s character.

"Appetite Comes With Eating": How a Volunteer Portfolio Case Turned Into Scope Creep

They say the road to hell is paved with good intentions.

We stepped into this project on pure enthusiasm. The agreement was simple: we help an independent artist build a sleek web presence for free, and in return, we get a real-world production case for our engineering portfolios. Win-win, right?

At the beginning, everything was smooth. The client was absolutely thrilled with the initial UI/UX prototypes. But as soon as the application was actually hosted and brought to life, the "appetite" started growing exponentially:

Phase 1 (Initial tweaks): "Can we change the album cover art?" — Sure thing. It's your music, your Bandcamp embed—done.
Phase 2 (The Breaking Point): "The fonts don't feel right... can we rewrite the copy?"

This was the final straw. Keep in mind: we had repeatedly confirmed typography and styling choices with the client earlier, and everything had been approved.

When my teammate David politely informed the client that fundamental UI changes were outside the scope of our volunteer agreement, the client responded with: "Just show me where the files are, and I'll change the fonts myself."

For anyone who works in web development, this was the ultimate ironic punchline. Changing fluid typography, responsive SCSS breakpoints, and layout variables isn't like picking a font in Microsoft Word. Knowing that the client had previously struggled to set up a basic Bandcamp profile, we wished him the best of luck—and officially closed the client chapter.

And the kicker? The expectation was that all these endless, fundamental redesigns should continue under the same "volunteer" umbrella indefinitely.

"You Live and You Learn": The Hardest Tech Stack is Working With People

Seniors and project managers reading this might smirk: "Well, that’s classic Scope Creep. That's why you need ironclad contracts, strict specs, and change-request fees!"

And you are 100% right. Coming from a non-tech background where I spent years working directly with clients, I already knew that PEOPLE are always the most complex variable in any equation. But experiencing it firsthand as a developer hits differently.

It wasn't just about a client changing his mind; it was about watching a project you deeply cared about get derailed by communication breakdowns. Eventually, the client realized he wanted something completely different, and our custom architecture was left orphaned.

Giving an Orphaned Project a Second Life

At that point, I had two choices:

Option A: Throw 320+ hours of blood, sweat, and clean code into the dark abyss of a discarded folder and forget it ever happened.
Option B: Refuse to leave it broken, roll up my sleeves, and transform this project into an independent, high-performance Open-Source Showcase.

I chose Option B.

I spent another full week polishing the codebase, replacing client-specific PII with clean configuration placeholders, refining responsive layouts, writing comprehensive tests, and building a dedicated showcase identity under the D&K Custom Media Platform brand.

If you’re too lazy to dive directly into the GitHub repository, here is a quick 2-minute video walkthrough of what we built:

Conclusion: Even Failures Deserve a Logical Conclusion

Some might say it’s foolish to pour even more time and emotion into a project that failed commercially.

I disagree. You never get anywhere in life—or in software engineering—if you abandon things the moment they get messy. Completing this project gave me something far more valuable than a client's signature:

A deep, practical understanding of full-stack media pipelines, SPA
state management, and CI/CD automation.
Ironclad resilience in handling unexpected project shifts.
A clean, open-source portfolio piece that I can proudly stand behind.

In the end, every failure deserves a logical, high-standard conclusion. As the saying goes: You’ll never reach your destination if you stop and throw stones at every dog that barks. The code is live, the repository is public, and the work speaks for itself.

Links & Resources:

🔗 GitHub Repository: https://github.com/kate8382/custom-media-platform-showcase.git
📺 YouTube Video Walkthrough: Watch Here
👤 Frontend Developer: Ecaterina Sevciuc (LinkedIn | GitHub)
👤 Backend Architect: David H. Watson (LinkedIn | GitHub)

Why I built 28 web tools that run 100% in your browser (and zero on my servers)

Thu, 27 Aug 2026 23:50:03 +0000

Have you ever needed to quickly compress an official invoice, sign a PDF contract, or format a photo online, but hesitated before clicking "Upload"?

I kept running into this exact dilemma. Almost every popular online PDF or image converter forces you to send your private documents—passwords, ID cutouts, financial statements—to a remote cloud server. You have no idea where your files are stored, who has access to them, or how long they sit on someone else's database.

I wanted a better way. So I set out to build Resizer Tools with a simple, strict rule: Zero server uploads. Everything must run 100% locally inside the browser.

🛠️ How it works under the hood

Instead of shipping user files to a backend Node or Python server, the entire processing engine runs locally inside your browser's client-side memory:

Browser-Native Graphics Engine: Compression, resizing, format conversions (HEIC/PNG/JPEG/WebP), and passport photo grid layouts execute directly on HTML5 Canvas API and WebAssembly.
Client-Side PDF Streams: PDF stitching, page extraction, password encryption, and digital signatures run locally using WebCrypto and pdf-lib.
Works 100% Offline: Try turning off your Wi-Fi or switching to airplane mode—the app continues editing and compiling documents without missing a beat.

🧰 What's inside the tool studio?

I've built 28 standalone browser tools so far, categorized into 4 core hubs:

📄 PDF Manipulation: Merge, split, compress, extract/delete pages, rotate, and add watermarks.
🖼️ Image & Graphics: Lossless compressor, resizer, batch image-to-PDF converter, and photo print sheet arranger.
🔒 Security & Docs: Password encrypter/decrypter, digital signature creator, corporate invoice compiler, and ATS resume builder.
⚡ Studios & Utilities: App Store screenshot designer, QR generator & scanner, and document camera scanner.

💬 I'd love your feedback!

Building this was a fun engineering challenge around client-side performance, memory management, and privacy-first web design.

Give it a spin at resizertools.com and let me know what you think! I’d love to hear your feedback, thoughts on the UI, or any new tools you’d like to see added.

I mapped India's public financial data endpoints so you don't have to

Mon, 24 Aug 2026 06:00:00 +0000

Indian financial market data can cost companies lakhs of rupees every year.

But a lot of the underlying data is already publicly available.

The expensive part isn't always the data itself. It's figuring out where it lives and how to reliably consume it.

If you've ever tried building something around Indian financial data, you've probably encountered the same problems: undocumented endpoints, APIs with strange headers, inconsistent file formats, identifier changes, historical gaps, and datasets spread across different public sources.

I've spent a lot of time digging through those problems.

So instead of keeping the findings in a pile of scripts and notes, I mapped the endpoints I could find and open-sourced them.

What's in the repository?

The repository currently documents public endpoints covering several areas of Indian financial data.

Mutual fund NAV data

Around 14,000 mutual fund schemes with more than 18 years of NAV history.

There are also parameterized APIs for retrieving historical NAV timelines.

Expense ratios

Daily Total Expense Ratio (TER) data, broken down across the available regulatory expense components.

NSE index data

Historical valuation metrics including:

PE
PB
Dividend yield

The dataset covers 140+ NSE indices.

There's also historical Total Return Index (TRI) data for Nifty indices.

Industry AUM

Industry-wide mutual fund AUM statistics going back to 2009.

Corporate shareholding

Corporate shareholding data sourced from public iXBRL disclosures.

The goal isn't to build another financial-data product.

It's to make the underlying discovery work easier for developers building things on top of public data.

The interesting part: the data has traps

Finding an endpoint is only the beginning.

While mapping these sources, I ran into several things that could quietly cause problems in production.

Historical discontinuities

Some datasets have historical discontinuities around April 2019.

If you're building a long-term time series, you can't blindly assume that the data behaves consistently across the entire history.

Files that lie about their format

Some files claim to be one format while actually containing data in another.

That can be particularly annoying when you're writing automated ingestion pipelines that trust file extensions or content types.

Fund identifiers aren't always stable

Mergers, rebranding and other changes can make fund identifier mappings surprisingly messy.

If you're maintaining historical data, you need to account for those relationships rather than treating every identifier as permanently immutable.

The one-header problem

Here's one of my favorite examples.

There's a public corporate shareholding endpoint that appears to reject automated requests.

You might assume there's authentication, some elaborate anti-bot mechanism, or another access restriction involved.

In one case, the problem was simply the Origin header.

Remove it and the request works.

That's it.

One HTTP header was the difference between "this endpoint doesn't work" and getting the data immediately.

Why I open-sourced this

I've had to spend hours figuring out things that probably shouldn't take hours to figure out.

And I know I'm not the only developer doing it.

Someone building a portfolio tracker shouldn't have to spend days reverse-engineering network requests just to discover where historical data comes from.

Someone building a quantitative research tool shouldn't have to rediscover the same identifier mappings.

Someone building a fintech prototype shouldn't have to start from zero because the documentation around a public endpoint is scattered or nonexistent.

So I decided to put the findings in one place.

The repository is MIT licensed, so you can use it as a starting point for projects involving:

Indian fintech
Wealth management
Quantitative research
Portfolio tracking
Market analytics
Financial data pipelines

There are probably still gaps.

That's intentional.

I mapped what I could find, documented the behavior I encountered, and would rather have other developers extend it than keep trying to maintain a private collection of scripts.

One less thing to reverse-engineer

The data was public.

The documentation wasn't.

That's the problem I'm trying to solve with this repository.

If you're building something around Indian financial data, hopefully this saves you a few days of digging through network requests and figuring out why an otherwise perfectly reasonable API request gets rejected because of one header.

Repository: https://github.com/satwikbasu

If you know of other undocumented Indian market-data endpoints, PRs and contributions are very welcome.

The EU AI Act deadline nobody's ready for (and what developers actually have to do)

Mon, 24 Aug 2026 05:33:43 +0000

If you've been following AI regulation at all, you've probably heard about the EU AI Act.

You may also have heard that parts of it were delayed.

That's true, but it's causing a lot of confusion.

The recent Digital Omnibus changes pushed several high-risk AI obligations into 2027 and 2028. Many teams interpreted that as "the AI Act got delayed."

It didn't.

Some of the first transparency requirements are still arriving on schedule, and for many software teams they become relevant on August 2, 2026.

If your product has an AI chatbot, AI-generated content, voice assistant, image generator, emotion detection feature, or anything similar that reaches users in the European Union, Article 50 is worth understanding now.

This article explains what developers actually need to know, in plain English.

The short version

Article 50 focuses on transparency.

The idea is simple:

People should know when they're interacting with AI, when content was generated by AI, and when systems are performing sensitive analysis such as emotion recognition.

The obligations are split across four sections:

Article 50(1): Disclosure for AI systems that interact with people
Article 50(2): Machine-readable marking of AI-generated content
Article 50(3): Disclosure for emotion recognition and biometric categorisation systems
Article 50(4): Labeling requirements for deepfakes and certain AI-generated public-interest content

Most of these obligations apply from August 2, 2026.

The machine-readable marking requirement in Article 50(2) applies from December 2, 2026.

Who is affected?

A common misconception is that only large AI companies need to care.

In practice, many ordinary software products could be affected.

Examples include:

SaaS products with AI chat assistants
Customer support chatbots
AI writing tools
AI image generation products
Voice agents
Meeting assistants
Internal business tools used by EU employees
Mobile apps with AI features
Websites embedding third-party AI widgets

You don't need to be based in Europe.

If your product reaches users in the EU, these obligations can become relevant.

For many startups, that's the surprising part.

Article 50(1): Tell people they're interacting with AI

This is the easiest requirement to understand.

If a user is interacting directly with an AI system, they should be informed that they're interacting with AI.

Think about:

Chatbots
Voice assistants
AI customer support agents
AI companions
AI-powered onboarding assistants

In practical terms, this usually means providing clear disclosure before or during the interaction.

The regulation is trying to prevent situations where users believe they're communicating with a human when they're actually communicating with software.

For most teams, the work here is not technical.

It's identifying every AI interaction surface and ensuring the disclosure is visible and understandable.

Article 50(2): Machine-readable marking of AI-generated content

This is the requirement that seems to catch developers off guard.

It's not only about visible labels.

The regulation expects AI-generated content to include machine-readable information indicating that AI was involved.

This becomes applicable on December 2, 2026.

The exact implementation details will continue evolving, but developers should already be thinking about metadata pipelines.

Questions worth asking:

How are generated images stored?
What metadata survives exports?
What happens when content is transformed?
Can downstream systems detect that content originated from AI?

If your product generates images, documents, audio, or video, this deserves engineering attention well before December.

Article 50(3): Emotion recognition and biometric categorisation

This obligation applies to systems that perform emotion recognition or biometric categorisation.

If a system is analyzing facial expressions, voice characteristics, behavioral patterns, or similar signals to classify emotional states or biometric traits, users generally need to be informed.

Many teams assume they don't do this.

Some are wrong.

Features marketed as:

Mood detection
Sentiment analysis from video
Interview analysis
Engagement scoring
Attention tracking

may deserve closer review depending on how they operate.

The key lesson is simple:

Don't rely on marketing names.

Review what the software is actually doing.

Article 50(4): Deepfake and AI-generated content labeling

This section addresses synthetic content that could be mistaken for authentic content.

Deepfakes are the obvious example.

The goal is transparency.

People should have a reasonable ability to understand when media has been artificially generated or manipulated.

The exact implementation can vary depending on the context and the type of content involved, but teams creating AI-generated media should not assume this requirement only affects large platforms.

A surprisingly small product can generate surprisingly large amounts of synthetic content.

What happens if you ignore it?

Article 99 provides the penalty framework.

For certain violations, fines can reach:

€15 million or 3% of global annual turnover, whichever is higher.

Whether a specific situation reaches that level depends on the facts, enforcement decisions, and legal interpretation.

But even without discussing fines, most companies would prefer to avoid discovering transparency gaps after a regulator, customer, journalist, or enterprise buyer finds them first.

What can a development team do this week?

You do not need a six-month compliance project to make progress.

Start with inventory.

Step 1: Find every AI surface

Create a list of:

Chatbots
Agents
AI search features
Image generation features
Voice features
Third-party AI integrations
Embedded widgets

Most organizations have more AI entry points than they initially expect.

Step 2: Map each feature to an obligation

Ask:

Does a user interact with AI?
Is AI-generated content produced?
Is emotion recognition involved?
Is synthetic media produced?

A single feature can trigger multiple obligations.

Step 3: Review disclosures

Check whether disclosures are:

Visible
Understandable
Consistent
Present across all user journeys

Don't only check the happy path.

Look at mobile flows, embedded widgets, and edge cases.

Step 4: Review generated content pipelines

If your product generates content, determine:

What metadata exists today?
What metadata gets removed?
What survives exports?
What survives sharing?

The answers are often surprising.

Step 5: Create evidence

Document:

What you reviewed
What was found
What was fixed
When reviews occurred

The approach I'm taking

I built a scanner for this because manually hunting through repositories and live websites became repetitive.

npx article50 scan

The point isn't to replace legal review.

It's to help developers find AI surfaces, transparency gaps, and implementation work that might otherwise be missed.

Final thoughts

The biggest misunderstanding around the EU AI Act right now is that teams think the important deadlines are years away.

For Article 50 transparency obligations, they aren't.

August 2, 2026 is close.

For many products, the hardest part won't be implementing disclosures.

It will be discovering every place AI is already present.

Start with inventory.

Then review disclosures.

Then review content-marking workflows.

The earlier you start, the easier the work becomes.

Resources

EU AI Act text
European Commission guidance materials
article50 (MIT): https://github.com/satwikbasu/article50

Disclaimer: This is technical guidance, not legal advice.

Show DEV: I built an AI Agent inside VS Code

Tue, 18 Aug 2026 12:20:28 +0000

Hey everyone,

For the past few months, I’ve been building Kalai Agent, a VS Code extension designed to bring fully agentic AI directly into your editor, bypassing the need to constantly copy-paste code snippets into a browser tab.

It’s finally at a stable v2.1.5, and I’m looking for some brutal engineering feedback on the architecture, security flows, and UX.

The Architecture & Tech Stack

Instead of building a wrapper around a basic chat interface, I wanted something that could safely interact with the local workspace.

Frontend: VS Code Webview API with batched streaming to prevent UI thread stuttering.
LLM Engine: Proxied Moonshot/Kimi API.
Backend: A lightweight Node service managing auth, workspace routing, and pay-as-you-go billing.
Capabilities: File-system operations, local terminal command execution, Python/Node script running, and web search capabilities.

Check it out

If you want to take it for a spin, install it directly from the marketplace:
Kalai Agent - Visual Studio Marketplace

If you run into bugs, have notes on the UI, or just think a specific feature is clunky, drop a comment below or email us on culustech@gmail.com. I’m entirely open to critiques!

How to Check If AI Systems Can Find and Cite Your Site (in 5 Minutes)

Tue, 28 Jul 2026 18:15:17 +0000

Co-authored by Rudrendu Paul and Sourav Nandy.

Repo: github.com/RudrenduPaul/LLMScout, a zero-dependency, cross-platform CLI that runs 21 GEO/AEO checks against any website. npm install -g llmscout-cli or pip install llmscout-cli.

Position-1 click-through rate on keywords that trigger an AI Overview fell from 7.3% in December 2023 to 1.6% in December 2025, per Ahrefs. If an AI system can't find or cite your site, that traffic doesn't come back on its own. Here's how to check where your own site actually stands, in under five minutes.

What LLMScout checks

LLMScout is a CLI that runs 21 checks against any site: 12 covering technical SEO fundamentals, 9 covering GEO signals specifically for AI systems. Every check reports PASS, WARN, or FAIL, and the whole run exits with a machine-readable code, so it drops straight into CI. It ships as two distributions: an npm package with two runtime dependencies, and a Python package with zero. Neither one needs a headless browser.

One check worth knowing about before you run it is ai-crawler-directives. It reports on all 7 major AI bots separately, because blocking GPTBot (which trains models) does nothing to stop OAI-SearchBot (which does live retrieval for ChatGPT) from fetching and citing your page. They're independently configurable in robots.txt, and most tools treat them as a single signal.

Install

There are two ways to install it. If you're not sure which one you want, try npm first:

npm install -g llmscout-cli

This needs Node 18+, and it pulls in exactly two runtime dependencies: cheerio and commander. No Python, no browser download, no subprocess calls.

If you'd rather use Python:

pip install llmscout-cli

This version has zero runtime dependencies; it's pure standard library. It runs the same 21 checks and gives the same PASS/WARN/FAIL verdicts as the npm version.

Both install in under a minute on Windows, macOS, and Linux.

Run your first check

Once installed, point it at a site:

llmscout init ./my-site --site-url https://yourdomain.com
llmscout check ./my-site

init writes an llmscout.json config file into ./my-site. check fetches the URL in that config and runs all 21 checks against it.

Here's real output from running check against example.com:

LLMScout check -- https://example.com

[PASS] (technical) Title tag
  Title "Example Domain" is 14 characters, within the recommended 10-60 range.

[WARN] (technical) Meta description
  No meta description found.
  Fix: Add <meta name="description" content="..."> with 50-160 characters summarizing the page.

[WARN] (technical) Canonical tag
  No <link rel="canonical"> tag found.
  Fix: Add a canonical link tag pointing at the preferred URL for this page.

[FAIL] (technical) robots.txt
  robots.txt was not reachable at https://example.com/robots.txt (HTTP 404).
  Fix: Add a robots.txt file at your site root, even a permissive one, so crawlers
  and agents have explicit directives.

[WARN] (technical) sitemap.xml
  No sitemap was reachable (tried: https://example.com/sitemap.xml).
  Fix: Add a sitemap.xml at your site root, or point to one with a Sitemap: directive
  in robots.txt, to help search engines discover pages.

[PASS] (technical) Heading structure
  Exactly one <h1> and no skipped heading levels detected.

[WARN] (geo) Structured data (JSON-LD)
  No JSON-LD structured data found.
  Fix: Add schema.org JSON-LD markup (e.g. Organization, WebSite, or Article) so
  generative engines can understand the page's entities.

[WARN] (geo) AI crawler directives
  robots.txt is unreachable, so AI-crawler directives could not be determined.
  Fix: Add a reachable robots.txt if you want to state an explicit policy for AI
  crawlers (GPTBot, OAI-SearchBot, ClaudeBot, Claude-SearchBot, PerplexityBot,
  Google-Extended, Applebot-Extended).

Summary: 6 PASS, 14 WARN, 1 FAIL (21 checks)

There are three things worth understanding about that output.

FAIL exits with code 1. At least one check failed outright, and that's the signal a CI pipeline should gate on. WARN is a missed optimization; it won't fail the run on its own. PASS means the check came back clean.

Notice the dependency between the last two checks: because robots.txt is unreachable, ai-crawler-directives can't determine any policy, so it reports WARN instead of FAIL. An unreachable robots.txt and one that explicitly blocks every AI bot are different problems with different fixes, and the tool keeps that distinction explicit instead of collapsing both into one warning.

Every WARN and FAIL comes with a fix suggestion built in. You don't need to look up what a canonical tag is or how to add one; the fix line tells you.

JSON output and CI

For CI, add --json and the output becomes something a script can actually parse:

llmscout --json check ./my-site

Exit codes: 0 for a clean run, 1 if at least one check FAILed, 2 for a usage or config error. That's enough to fail a build on a new FAIL without writing your own parser logic.

The JSON includes per-check id, status, message, and fix fields, plus a summary object with the totals. Wire it into a pre-merge check and a PR that regresses on structured data or robots.txt breaks the build instead of shipping quietly. The full schema is in the README.

Fleet mode for multiple sites

If you manage more than one site, llmscout fleet takes a JSON manifest of site paths and runs the full 21-check suite against every one of them in a single command. --out-dir writes one auto-named report file per site instead of dumping everything to stdout at once.

llmscout fleet ./fleet.json --out-dir ./reports

The manifest:

{
  "sites": [
    { "name": "client-a", "path": "./clients/client-a" },
    { "name": "client-b", "path": "./clients/client-b" }
  ]
}

That produces client-a.txt and client-b.txt (or .json with --json), one report per site, named straight from the manifest's name field. That gives an agency a separate, named report file per client that you can open, send, or archive, instead of scrolling back through one combined terminal dump.

Wrap up

The checks cover the signals that matter most for AI-system citability: structured data, crawler access policies, content extractability, entity markup. Contested signals, like llms.txt, are flagged as informational since the evidence for their impact is still developing. Run it against your own site and see where you actually stand.

GitHub: https://github.com/RudrenduPaul/LLMScout
npm: https://www.npmjs.com/package/llmscout-cli
PyPI: https://pypi.org/project/llmscout-cli/

Co-authored by Rudrendu Paul and Sourav Nandy. Rudrendu is an AI/ML builder and published researcher (ICML, Springer Nature, Elsevier, IEEE) with 15+ years of experience at Fortune 50 companies, building open-source tools for the AI development ecosystem. Find the code at github.com/RudrenduPaul.

Launching my first startup on product hunt

Tue, 28 Jul 2026 07:22:05 +0000

Built Quorel: turn any public website into a structured, versioned dataset. Describe the fields you want in plain English, it extracts nightly, and every refresh is saved as a diffable, reversible version.
Real example, not a mockup: 25 rows added, 78 removed, 312 modified between two versions of the same live dataset: quorel.vercel.app/dataset/web-diff/1
MCP server ships on every plan, including Free, so Claude or any agent can query, clean, and fix data directly.
Live on Product Hunt today if you want to check it out: https://producthunt.com/posts/quorel

Firecrawl vs Apify vs Quorel

Sat, 25 Jul 2026 21:23:40 +0000

Firecrawl and Apify both do the hard part well. They render JavaScript, dodge bot detection, and hand you back clean markdown or structured JSON. If you need a page turned into text, either one will do that job.

But most of the time the point isn't a single page. It's a page you need to check again tomorrow, and the day after, and the day after that: a price, a listing, a status, a set of rows that might quietly change. And that's where the workflow, not the extraction, starts costing you.

Firecrawl bills per credit, and the credit math is not what the pricing page implies. Scrape is 1 credit. Add JSON extraction and Enhanced Mode — both of which you probably want for structured data — and it's 9 credits per page. A $16/mo Hobby plan advertised at 3,000 credits works out closer to 300–500 pages once you're actually extracting fields, not just fetching markdown. Credits also don't roll over, so a quiet month doesn't bank anything for a busy one.

Apify flips the complaint around. Pricing is compute-unit based (RAM × time) plus separate line items for proxy and storage. It's flexible and it scales, but you can't look at a number on the pricing page and know what a job will cost until you've run it. For teams that want a predictable bill, that unpredictability is the whole problem.

Neither tool keeps history by default. You get the current state of the page. If you want yesterday's version to compare against today's, that's on you to build — a database, a diffing script, a place to store snapshots, a way to roll back if a refresh comes back wrong.

Quorel starts from a different question: not "how do I fetch this page," but "how do I keep a page as structured, versioned data over time." You describe the fields you want in plain English. Every refresh (nightly by default, or on demand via a ping URL, webhook, or your own cron) is saved as its own immutable version. Nothing is overwritten. You can diff any two versions to see exactly what changed, and roll back in one click if a refresh comes back bad.

Pricing is flat, not metered. Free tier is one dataset, 20 URLs, full version history included. Pro is $19/mo for 5 datasets and 100 URLs, with on-demand refresh and webhooks. No credit multipliers, no compute-unit math, no surprise bill.

This isn't a claim that Quorel replaces Firecrawl or Apify at everything they do. If you need to fetch an arbitrary one-off page as clean markdown for an LLM right now, Firecrawl is built for exactly that. If you need thousands of site-specific scrapers off a marketplace, Apify's Actor ecosystem has years of head start. Quorel is built for the narrower, recurring job: turning a page you check regularly into a structured, versioned API you can trust and query later.

Every dataset ships with an MCP server on every plan, free included, so an agent can query it directly — or pull the raw rows, fix nulls, and publish a new version itself.

If you've been burned by a scraper that silently broke, or wished you'd kept last week's data to compare against, that's the specific gap Quorel is built to close.

I'm building Quorel — happy to answer questions on versioning, pricing, or how the MCP integration works.

I Built a Job Listing + E-commerce API Dataset in 4 Hours, No Code

Fri, 24 Jul 2026 21:37:07 +0000

The problem with "just build your own API"

If you've ever wanted a personal dataset (job listings, product prices, whatever) you know the real cost isn't the idea, it's the pipeline. Scraping. Cleaning. Storage. Refreshing on a schedule. Serving it over an API. Handling schema drift when the source site redesigns. Every one of those is its own mini-project, and each is its own source of friction.

I wanted a dataset combining Amazon products for developers and job listings scraped from multiple sites. Normally that's a multi-day side project. I built it in about 4 hours, without writing a single line of scraping or backend code.

Here's how.

The magic part: describing data instead of scraping it

I used a tool called Quorel. The workflow was almost embarrassingly simple:

I pasted in my source URLs (Amazon product pages, a few job board listing pages).
I described the schema and extraction intent in plain English: no selectors, no XPath, no code. Something like "product name, price, rating, whether it's in stock" for the Amazon side, and "job title, company, location, salary range, posted date" for the listings side.
I hit run and left it alone for 30–60 minutes.

When I came back, the data was fully structured and ready to query.

From there I asked Claude to build me a dashboard on top of the API so I could actually see and explore the data. That part took the rest of the 4 hours. The result is live here: diffboard.vercel.app.

The part that actually sold me: it's versioned like git

Structuring the data was the easy win. What kept me around is that Quorel treats datasets like a git repo for live web data:

Nightly refresh (or your own cron schedule): the data doesn't go stale.
Every refresh is a saved version, nothing overwrites the last run.
Diffing between versions: I can see exactly what changed, like prices that moved, listings that disappeared, new rows that showed up.
Time travel: I can pull the dataset as it looked days or months ago.
Rollback: a bad refresh doesn't mean starting over.
Forking: you can clone a public dataset the way you'd fork a repo, and extend it for your own use case.

That combination, structure plus history, is the part a plain scraper never gives you. Most tools hand you today's snapshot. This hands you the whole timeline.

Talking to your data instead of querying it

The other piece that stood out: Quorel ships an MCP server with every dataset, on every plan, including free. That means I can point an AI agent at my dataset and just talk to it, like "find listings with price drops this week" or "fix the null prices and publish a new version," and it does the pull, clean, and push cycle for me, still landing in the same versioned system. It's genuinely like chatting with your data pipeline instead of writing scripts for it.

Try it yourself

The datasets I built are public and free to use. You can query them directly, or clone one and extend it to fit your own project:

Quorel: quorel.vercel.app
Public datasets: quorel.vercel.app/datasets
My dashboard: diffboard.vercel.app

I've barely scratched what's possible here. Next I want to enrich the job listings with salary normalization and wire the Amazon dataset into a price-drop alert bot. If you build something on top of this, I'd love to see it.

Why Titles and Price Tags Don't Guarantee Quality: The Work Speaks for Itself

Wed, 22 Jul 2026 15:44:58 +0000

How We Rebuilt a Website for a Musician and Why Engineering Ownership Matters More Than Commercial Labels.

In the tech market, people tend to judge a book by its cover: if a "design agency" takes on a project, clients are willing to pay big checks on blind trust. If an entry-level developer works on it, they're met with skepticism ("they stand no chance of getting hired right now anyway").

But do titles and price tags actually guarantee results? We recently completed a full-stack custom web platform for an independent Canadian musician. And this story is the best answer to anyone who measures quality by brand name alone.

Background: The Client's Journey Through "Professionals"

The story of this website is a classic example of a client going in circles searching for a decent solution:

The "Professional" Agency: The artist originally hired a specialized agency. They quoted a fee he assumed was the total cost, but halfway through, the agency demanded more money. In the end, the client was left with a half-baked mess despite paying a commercial rate.
DIY Attempts: The artist tried building the site himself using popular website builders, but ran straight into their rigid limitations.
Volunteer Format: Eventually, the project shifted into a hands-on practice model. I stepped in alongside David (LinkedIn: David H. Watson, GitHub: @dEhiN — backend), taking full charge of the frontend, UI/UX, client logic, and site architecture.

For me, this wasn't just a "learning pet project"—it was a real production case where I poured in over 320 hours of work, striving for top-tier quality.

The "BEFORE" Phase: What Did the Client Pay the Agency For?

When I received the raw source files from the studio (a WordPress dump, a bloated theme, and chaotic HTML/CSS), my initial reaction was deep repulsion. This wasn't a site built by professionals; it was a product slapped together "on the knee" during coffee breaks.

What was under the hood and in the UI:

An Infrastructure Monster: A heavy system loaded with overlapping styles just to display a couple of audio tracks and photos.
Complete Disregard for Accessibility (a11y): A musician's website should be comfortable for every single user. In the original codebase, accessibility logic was completely wrecked: broken element focus, lack of semantic structure, and a mess of CSS rules overriding native browser behavior.
Zero UX Consideration: Clunky player interactions, broken spacing, and complete unusable layouts on mobile devices.

Developer's Reflection:
Everyone preaches Best Practices—semantics, accessibility (a11y), proper focus handling, clean code, and optimization. Then you look at code produced by a "commercial agency" and find a Frankenstein monster where all those standards were simply tossed aside.

When it comes to music, a website should be accessible and alive. If developers don't care about that, it's not a technology problem—it's an attitude problem.

That's exactly why I decided against patching up this WordPress corpse and chose to build a clean, lightweight, and accessible frontend from scratch—one I could actually be proud of.

The "AFTER" Phase: Having Nothing but 320 Hours and Engineering Passion

I can already hear the ironic smirks from seniors and team leads:
“320 hours on a single website?! Talk about inexperience, typical Junior. You could rewrite three SPAs in that time!”

Alright, let’s break down letter by letter what actually went into those 320 hours.

At the start, we had ABSOLUTELY NOTHING:

Design and Content? Zero. No logo, no promotional copy, not even a single usable photo. I spent hours generating promotional assets, tailoring them to fit various grid formats, layouts, and resolutions. Everything visual on this site is the work of a frontend developer wearing a designer hat.
Understanding What the Client Wanted? Nonexistent. The client expected a flawless outcome, but the vision kept shifting on the fly. I had to iterate through dozens of concepts and finalize a responsive layout.
Audio Content? There was only an idea: link the site's playlist to Bandcamp so we wouldn't have to hardcode every track card manually.

Technical Breakdown:

1. Audio Pipeline Automation (`build-tools`)

It turned out the client didn't even have a set-up profile, and the audio files were in the wrong format. While David was uploading tracks to Bandcamp, I wrote a CLI script using Node.js and fluent-ffmpeg to automatically convert MP3s to required WAV formats, generate copies, and verify duration via ffprobe down to 60 ms tolerance, checking channel counts and sample rates along the way.

// MP3 to WAV conversion with auto-verification via ffprobe (excerpt)
async function convertAndVerify(inputPath, outGenerated, outDist, attempts = 1) {
  for (let attempt = 0; attempt <= attempts; attempt++) {
    try {
      await convertOne(inputPath, outGenerated, outDist);
      if (!VERIFY) return;

      const srcInfo = await ffprobeAsync(inputPath);
      const actualOut = SKIP_DIST ? outGenerated : outDist;
      const outInfo = await ffprobeAsync(actualOut);

      const durDiff = Math.abs((srcInfo.duration || 0) - (outInfo.duration || 0));
      const DURATION_THRESHOLD = 0.06; // 60ms толерантность

      const sampleMatch = srcInfo.sample_rate === outInfo.sample_rate;
      const channelsMatch = srcInfo.channels === outInfo.channels;

      if (durDiff > DURATION_THRESHOLD || !sampleMatch || !channelsMatch) {
        throw new Error(`Verification failed (durDiff: ${durDiff}s)`);
      }
      return;
    } catch (err) {
      if (attempt >= attempts) throw err;
    }
  }
}

2. Dynamic Playlist Class (`playlist.js`)

Dedicated client-side logic was written for the music section:

- Backend Integration: The Playlist class executes requests with automatic retries (_fetchWithRetry) targeting /api/bandcamp.

- Inline Markup Cleanup (normalizeIframes): The method forcibly strips hardcoded width and height attributes from Bandcamp iframes, delegating layout control entirely to SCSS and CSS custom properties (--collapsed-height).

- Smart Expand/Collapse & Accessibility: Automatically calculates grid items per row (_computeItemsPerRow), dynamically updates aria-expanded and aria-controls attributes for the "See more / See less" button, and handles viewport changes with a debounce listener.

// Frame normalization and collapsed playlist height calculation (excerpt)
normalizeIframes() {
  const iframes = Array.from(document.querySelectorAll('iframe.playlist__iframe, iframe'));
  iframes.forEach((frame) => {
    try {
      frame.removeAttribute('width');
      frame.removeAttribute('height');
      if (frame.style) {
        frame.style.removeProperty('width');
        frame.style.removeProperty('height');
      }
    } catch (e) { /* ignore CORS/readonly */ }
  });
}

3. Architecture: Multi-Page Feel Without Heavy Frameworks (Custom SPA Router)

The client preferred a traditional multi-page website (MPA) feel—with explicit URLs, intuitive navigation, and page state. However, I didn't want to bloat the workspace, inflate bundle sizes, or deal with maintaining multi-page routing overhead.

The solution? Build a custom vanillajs SPA router using hash routing that looks like a traditional MPA from the outside while running blazingly fast under the hood.

The router intercepts internal link clicks, manages history.pushState / popstate, updates accessibility attributes (aria-current="page") and seamlessly handles browser back/forward buttons.

export default class Router {
  constructor(routes = {}, options = {}) {
    this.routes = routes;
    this.useHash = options.useHash !== undefined ? options.useHash : true;
    this._onLinkClick = this._onLinkClick.bind(this);
    this._onPopState = this._onPopState.bind(this);
  }

  init() {
    document.addEventListener('click', this._onLinkClick);
    window.addEventListener(this.useHash ? 'hashchange' : 'popstate', this._onPopState);
    const initialPath = this._getPath();
    this._routeTo(initialPath);
    try { history.replaceState({ path: initialPath }, '', window.location.href); } catch (e) {}
  }

  _onLinkClick(e) {
    const anchor = e.target.closest && e.target.closest('a');
    if (!anchor) return;
    const href = anchor.getAttribute('href');
    if (!href || href.startsWith('http') || anchor.target === '_blank') return;

    e.preventDefault();
    let path = href.startsWith('#') ? href.slice(1) || '/' : href;
    this.navigate(path);
  }

  _updateActiveLink(path) {
    const links = document.querySelectorAll('.header__nav-link');
    links.forEach((link) => {
      const linkPath = link.getAttribute('href').replace(/^#/, '');
      if (linkPath === path) link.setAttribute('aria-current', 'page');
      else link.removeAttribute('aria-current');
    });
  }
}

4. What About Infrastructure and CI/CD?

Not to mention writing end-to-end (E2E) tests and configuring complete CI/CD deployment pipelines. At the start, we had no idea where or how we would host the project.

Ultimately, we settled on Render.com's free tier. You could say spending time configuring production-grade CI/CD was a bit overkill for this stage, but as a result, the project got a solid setup that deploys in a single click.

Note on Project Status & Demo:
As is common in software engineering, project handoffs and client hosting agreements can evolve over time. While the original client instance is currently offline, our custom-built frontend architecture, Vanilla JS router, and media pipelines remain a fully functional showcase of high-performance web engineering. A standalone demo repository/showcase stand will be published shortly.

Conclusion: Quality Isn't Measured by Price Tags

Is 320+ hours a lot? If you view a developer as a "button pusher executing pre-made Jira tasks and Figma designs"—yes, it is.

But if your job is to take absolute chaos, zero media assets, and broken legacy code, and turn it into a production-ready, beautiful, accessible (a11y), and optimized web product—that is the real cost of deep engineering commitment.

I’m proud of what we accomplished on this architecture. We built a fully functional, high-standard platform from scratch and gained immense experience along the way.

So next time someone tells you entry-level developers can't build anything without third-party libraries or constant senior oversight—just show them this case. In the end, the code and the work speak louder than any title.

We Measure Everything Except Code Quality — So I Built CodeMultiVitals

Tue, 21 Jul 2026 13:01:19 +0000

As software engineers, we've become incredibly good at monitoring our applications.

We monitor CPU usage.

We monitor memory.

We monitor API latency.

We monitor database performance.

We monitor logs, traces, and infrastructure.

Our CI/CD pipelines run tests, security scans, dependency audits, and linters before every deployment.

Yet there's one thing we rarely monitor continuously:

The health of the codebase itself.

That realization became the motivation behind building CodeMultiVitals.

The Problem

Every project starts with clean, maintainable code.

Then reality kicks in.

New features are added.

Developers join the team.

Deadlines become tighter.

Requirements change.

Months later, the project still works—but the code becomes increasingly difficult to maintain.

You begin to notice:

Large functions
Deeply nested logic
Growing cyclomatic complexity
Duplicate code
Files nobody wants to touch
Pull requests that are harder to review
Refactoring becoming increasingly risky

These issues don't appear overnight.

They accumulate gradually.

Unfortunately, by the time we notice them, fixing them is significantly more expensive.

Existing Tools Solve Different Problems

Don't get me wrong—we already have fantastic tools.

ESLint catches code smells.
Prettier keeps formatting consistent.
TypeScript improves type safety.
Jest validates behavior.
GitHub Actions automates CI/CD.
Security scanners identify vulnerabilities.

These tools answer an important question:

"Does the application work correctly?"

But they don't necessarily answer another question:

"Is the codebase becoming healthier over time?"

Passing tests don't guarantee maintainable software.

A successful deployment doesn't guarantee sustainable architecture.

The Question That Started Everything

I kept asking myself:

Why can't every commit tell us whether the project just became healthier—or worse?

Imagine opening a Pull Request and immediately seeing:

Complexity increased by 12%
Maintainability score dropped
Three files exceeded recommended thresholds
Technical debt is trending upward
Overall project health decreased

Instead of relying entirely on opinions during code reviews, we'd have measurable engineering data.

That's exactly what I wanted to build.

Introducing CodeMultiVitals

CodeMultiVitals is an open-source code quality metrics engine for JavaScript and TypeScript.

Its goal isn't to replace existing tools.

Instead, it complements them by continuously measuring code quality across an entire project.

The current pilot version includes:

Complexity Analysis
Maintainability Metrics
❤️ Project Health Scores
️ CLI
Programmatic API
HTML Dashboard
⚙️ GitHub Actions Integration
SARIF Output
️ SVG Badges
Historical Health Tracking

The objective is simple:

Turn code quality into measurable engineering data.

Why This Matters

Poor code quality doesn't just affect developers.

It affects the entire business.

Healthy code leads to:

Faster onboarding
Better code reviews
Easier refactoring
Lower maintenance costs
Higher developer productivity
More predictable releases
Reduced technical debt

The earlier teams identify quality issues, the cheaper they are to fix.

The Long-Term Vision

My vision extends beyond building another CLI tool.

I'd like to see continuous code quality become a standard engineering practice.

Just as every project runs automated tests before merging code, I believe every project should also answer questions like:

Is maintainability improving?
Is complexity increasing?
Are we introducing technical debt?
Which modules should be refactored first?
Is the project healthier than it was yesterday?

Code quality shouldn't be something we think about only during refactoring sprints.

It should be continuously visible.

This Is Only the Beginning

The current release is intentionally a Pilot Version.

There are many ideas planned for future releases:

Framework-specific analysis
Pull Request Quality Reports
Team Dashboards
Organization-wide Analytics
AI-assisted insights
CI/CD Quality Gates
Custom metric plugins
Trend-based quality forecasting

The goal is to build an ecosystem that helps engineering teams make better architectural decisions using measurable data.

I'd Love Your Feedback

If you work with JavaScript or TypeScript, I'd really appreciate your thoughts.

What code quality metrics matter most to your team?
Which quality problems do existing tools fail to solve?
What would make a tool like this genuinely useful in your workflow?

The pilot version is available now, and I'm actively looking for feedback from the community.

NPM: https://www.npmjs.com/package/code-multivitals

Open-source projects improve through honest discussions, and I'd love to hear your ideas, critiques, and feature requests.

Let's make code quality measurable, affordable, and part of every engineering workflow.

I Built a Tool to Visualize DSA. Let’s Learn Together! (DSA View View 👀👀)

Wed, 15 Jul 2026 13:00:13 +0000

Hoi hoi!

I’m @nyaomaru, a frontend engineer currently fighting the intense European heatwave by building DIY window screens here in the Netherlands. 🛠️

https://medium.com/data-science-collective/should-you-still-learn-to-code-in-2026-034685e17707

As this article also discusses, I believe that improving our fundamental engineering skills is still essential in the age of AI.

Imagine that AI makes an F1 car fully autonomous. 🏎️

Would you let someone without even a driver’s license enter a race as its driver?

Or imagine that AI completely automates maintenance during pit stops.

Would you put someone who knows absolutely nothing about cars, their parts, or their internal structure in charge of that AI?

AI is certainly reducing the amount of code we need to write by hand. Typing quickly and memorizing every small piece of syntax or every method are becoming less important.

But can we confidently release a product without understanding its fundamental concepts or implementation? If something goes wrong in production, can we take responsibility and fix it?

My answer was no.

Building things faster is obviously a good thing. But if we build without understanding, we may simply produce fragile software with no long-term sustainability at a faster rate.

The real value comes from building meaningful things quickly.

Then, how can we develop the fundamental skills we still need in the AI era?

I believe one useful approach is learning DSA: Data Structures and Algorithms. So I decided to start learning DSA again.

However, while solving problems on LeetCode, I repeatedly ran into the same problem.

I want to visualize the data flow and understand what is happening, but I still can’t clearly see it.

So I used the skills I have developed through frontend engineering and built a tool that visualizes the execution flow of DSA implementations! 🚀

https://github.com/nyaomaru/dsa-view-view

In this article, I’ll explain how DSA View View works and how we can use it to study DSA.

Let’s take a look together!

Disclaimer
I may sound confident so far, but I’m definitely not a DSA expert. I’m still learning, just like many of you.

In fact, I built this tool precisely because I was struggling. When I realized that I couldn’t immediately solve Binary Search, I started to panic a little. 😸

🖥️ What Is DSA View View?

DSA View View is a tool that executes functions and classes written in TypeScript and lets you inspect how variables and return values change on each line through a runtime timeline.

The easiest way to understand is to try it yourself!

Open the tool and click the Run Demo button.

You’ll quickly see how the workflow works:

Write your implementation
Compile it
Enter the input values
Run it

That’s really it.

Although I created it primarily for DSA problems, you can also use it to inspect and test smaller TypeScript implementations.

And, of course, it’s completely free!

🤔 What Can It Do?

With DSA View View, you can:

Write DSA implementations in TypeScript
Test implementations with different input values
Move forward and backward through runtime steps
Visualize supported data structures and algorithms
Review LeetCode solutions and confirm your understanding

You can also use it as a lightweight environment for executing functions or formatting code blocks for technical articles such as Dev.to 😸

Feel free to experiment with it and find your own use cases!

🧑🏫 How to Use It

The main workflow consists of three modes:

Editor
Verification
Runtime

Let’s look at each one.

Editor

First, write your implementation!

The Editor is designed to feel similar to a basic IDE.

TypeScript diagnostics are available by default, so the editor can detect some errors while you write.

You can also press Cmd/Ctrl + S to format your code with Prettier, so feel free to write first and clean it up afterward.

Common classes used in DSA problems, such as TreeNode and ListNode, are already available.

You don’t need to declare or import them every time.

You can also define your own classes or replace the provided definitions when necessary.

Once your implementation is ready, click Compile Code.

If compilation fails, the tool displays the relevant location and error message so that you can fix it.

There is also an Example menu containing several common implementations.

For example, if you want to quickly inspect a Heap Sort implementation and see how it behaves, you can load the example instead of writing everything manually.

Verification

In Verification mode, you define the input values that should be passed to your function or class.

Enter a test value for each argument.

For arrays, both of the following formats are supported:

[1, 2, 3]

1, 2, 3

Once your input values are ready, click Run.

Runtime

Finally, let’s inspect the runtime!

When you click Run in Verification mode, your implementation is executed.

Runtime mode then lets you play through the execution steps or move backward and forward manually.

When the tool recognizes supported logic, an additional visualization is displayed in a modal.

Not every possible implementation is supported yet, of course. If something you need is missing, I would be happy to receive an issue or pull request!

You can move backward and forward through the executed lines to inspect:

Which line is currently running
How variables change
Where values are returned
How the execution reaches its final result

You can return to the beginning, jump directly to the end, or move through the timeline one step at a time.

The main execution process runs entirely in the browser.

DSA View View also includes a sharing feature.

You can create a URL that preserves your implementation and share it with someone else.

Use the Share button at the top of the page to post it on social media or copy the link directly.

Share your implementations, compare different solutions, and let’s learn together!

Important: The shared URL contains your implementation. Do not paste private, confidential, or proprietary code into the tool before sharing it.

What Is That Thing in the Top-Right Corner? 👀👀

Meet Mr. View.

Mr. View watches over your implementation.

Nothing more.

Nothing less.

He is simply there to support you.

When you need to concentrate, press the TV button to hide him. Press it again to bring him back.

However, if Mr. View is enough to distract you, you may not be ready for an attack from ten simultaneous Slack notifications. 😸

✏️ How Should We Study DSA?

Now you know how to use DSA View View.

The next question is probably

Which problems should I solve?

LeetCode is an obvious place to start, and the study plan from Tech Interview Handbook also provides a useful collection of practice problems. 👇

https://www.techinterviewhandbook.org/coding-interview-study-plan/

Try solving these problems with DSA View View.

Once your implementation works, use the runtime timeline to inspect the data flow and understand exactly how the algorithm reaches its answer.

You can also use tools such as ChatGPT, Codex, Claude, Claude Code, Gemini, and Grok to explore your solution further.

Don’t limit yourself to asking

Is this implementation correct?

Try asking questions such as:

What would happen if I rewrote this DFS solution using BFS?
Could Dynamic Programming solve this problem?
Are there any other reasonable approaches?
What are the time and space complexities?
Why is this approach better than the alternatives?
Under which conditions would another approach be better?

AI becomes much more useful for learning when it helps us compare and understand different approaches instead of only generating a final answer. 👍

Why TypeScript Instead of Python? 🐍

The simple answer is that TypeScript is my favorite language.

I mainly work as a frontend engineer, so TypeScript is also the language in which I feel most comfortable experimenting and learning.

However, I designed the tool so that additional languages could be supported in the future.

If there is enough demand for another language, please leave a comment or open an issue!

🎯 Conclusion

AI is helping us write code faster and faster.

However, understanding what happens inside an implementation remains an important engineering skill.

In fact, I believe that this ability may become even more valuable as AI-generated code becomes increasingly common.

I built DSA View View because I wanted a tool that could help me strengthen those fundamental skills from the ground up.

To be honest, I still have a lot to learn about DSA.

That is exactly why I hope we can learn together.

Please leave a comment or open an issue if:

You want support for a particular problem or data structure
You have an idea for a new visualization
You find a bug
You want support for another programming language

Let’s train our DSA muscles together! 💪😸

If you like it, please give a star ⭐

https://github.com/nyaomaru/dsa-view-vie

And I also launched on ProductHunt! Come say hello and let me know what you think 😸 👇

https://www.producthunt.com/products/dsa-view-view

Malcolm X Is Not a Suffix

Sun, 12 Jul 2026 14:09:14 +0000

Parse Malcolm X with almost any name splitter and you get a suffix. X looks like a roman numeral, roman numerals are suffixes (John III, Henry VIII), so X becomes the suffix and the surname disappears. That's the kind of bug you only find once you already have a working parser, because it isn't a missing rule. It's two correct rules wanting the same token.

Last month I wrote about the casing fix in nameparser: the idea that a parser reading Jane Doe DDS should keep Doe as the surname and DDS as a credential, using letter casing as the signal that lowercasing throws away. Version 1.3.0 is the follow-up, and it is almost entirely about collisions like Malcolm X: tokens that two disambiguation rules both claim. nameparser is a maintained fork of the dormant theiconic/name-parser, by way of codebyzach/name-parser's PHP 8.3+ modernization; the contribution here is the casing and credential layer plus a confidence pass, not the parser core.

The credential that is also a name

JO ANDERSON PhD used to parse to first name J. Jo is a real short given name, but in all caps it also reads as a credential-run token, and the credential rule won. 1.3.0 keeps all-caps short given names intact beside a mixed-case salutation or credential, so Jo survives.

The mirror image is the credential that gets read as a surname. Jane DDS (a credential-only row with no comma) and John A. MD (an initial plus a credential) used to rewrite the trailing credential as the last name, because a token in the surname slot with nothing after it looks like a surname. Both now keep the credential in the suffix.

The collision gets worse with more than one credential. John Smith MD FACS used to keep MD and leak FACS into the name, because FACS is not in the dictionary and an unknown trailing token defaults to a name. Now a known credential anchors the tail and pulls the unknown one in with it, so both stay in the suffix. Parenthetical credentials were their own trap: Jane Doe (MD) used to parse (MD) as a nickname, since parentheses mark nicknames, and now reads it as a suffix. And a credential-only segment that lands before the given name, as in Smith, MD, John, is pulled out to the suffix so the first name stays John rather than becoming MD.

Casing is the tiebreaker for all of these, which means it fails exactly where casing carries no signal. Uniform all-caps registry data, or all-lowercase input, has nothing to disambiguate on, so an ambiguous trailing token defaults to being read as a credential. That's a hard limitation, not a bug, and it's why the library ships a confidence pass: getConfidence() flags a casing-undecidable row as ambiguous so it can go to a human instead of silently into your database wrong.

Word order that hides the surname

Surname-first input is its own minefield when a salutation and a credential sit on the same name. Dr. Kim Jong Un used to lose the surname to the title; Kim Jong Un, MD used to fall back to Western order. Both now keep surname Kim, and Dr. Kim Jong Un, MD correctly yields surname Kim, salutation Dr., and credential MD. The salutation and the credential were each pulling the parser back toward a different word order, and the fix is teaching it that a leading salutation and a trailing credential-only comma tail can coexist with a surname-first name.

The comma inside the nickname

A comma in a name usually means surname-first. So a comma inside a delimited nickname is a direct collision with the rule that reads commas as name-order markers. John (Bob, Jr) Doe and John 'Bob, Jr' Doe used to bisect on that inner comma and lose half the name. 1.3.0 keeps the nickname Bob, Jr whole, for bracketed, quoted, and custom multi-character delimiter pairs alike, and the same holds on the given-name side: Smith, John (Jack, Robert) keeps Jack, Robert intact.

Scripts with no casing at all

If casing is the signal, a script without upper and lower case has none. Wang, 李明 used to split 李明 into two initials, because the initials rule fires on short tokens and nothing told it these were not initials. 1.3.0 leaves caseless-script names intact as the first name. In the other direction, an elided surname particle like the one in 't Hooft used to read as an unterminated nickname or an initial; it now survives as the leading particle. Dutch honorifics (Dhr., Mevr., Mw.) also join the default salutation set, so Dhr. Jan de Vries reads the title as a salutation rather than a first name.

And the input that is trying to break you

A name parser sits directly on user-supplied strings, so an adversarial input is a real exposure, not a theoretical one. Kilobytes of unmatched quotes, 100 KB tokens of any case shape, megabyte-long rows: 1.3.0 parses all of them in linear time and bounded memory. Invalid-UTF-8 delimiter keys and empty whitespace sets that used to emit a compile warning on every parse are now ignored quietly.

Turning a wrong split into a review queue

Every collision above resolves on casing, and casing runs out of signal on uniform-case data. So the honest design isn't to pretend the parser is always right; it's to say when it's guessing. The confidence pass reads the same input the parser does and flags a row whose split hinges on a signal that is not there.

use Iliaal\NameParser\Parser;

$name = (new Parser())->parse('SMITH, JM');
$name->getConfidence();   // ['ambiguous' => true, 'notes' => [...]]
$name->getSource();       // 'SMITH, JM'  (the normalized input it judged)

SMITH, JM is exactly the case with no answer: with mixed case, Smith, JM splits JM into the initials J and M, because the mixed-case surname proves those are initials; all-caps SMITH, JM keeps Jm as a first name, because the caps could equally be a short given name. The parser has to pick one, and the confidence flag records that it had to. getSource(), new in 1.3.0, returns the normalized string the confidence was assessed against, so a batch importer can log precisely what it judged. The flag is advisory and opt-in; it never changes what parse() returns. On a million-row import, that is the difference between silently corrupting an unknown fraction of records and routing a known set of them to a person.

One caution the README states and this post repeats: ambiguous => false on an all-caps row is not a correctness guarantee. Clean credentials that are not also names (RN, PT, OD) are left unflagged on purpose, to keep review volume manageable, so a false there means "no name-colliding token," not "definitely right."

The seams where cases meet

None of these are new features. They're the boundaries between rules that were already there, the places where two disambiguation heuristics both reach for the same token. That's what this round of work looks like: not more cases, but the seams where cases meet. Casing decides most of them. Where it cannot, the confidence flag says so, and the row goes to review instead of into your data wrong.

composer require iliaal/nameparser

github.com/iliaal/nameparser

Building Type Guards Like LEGO Blocks: Making Reusable Logic with is-kit

Wed, 08 Jul 2026 14:59:42 +0000

Hoi hoi!

Still writing TypeScript guards by hand again and again? 😎
I’m @nyaomaru, a frontend engineer!

When writing TypeScript, we often end up creating type guard functions (value is Foo) over and over again.

But you know the pain:

The same isXXX functions appearing everywhere
Copy → tweak → repeat = infinite boilerplate hell
Runtime checks and type narrowing slowly drifting apart
Complex guards becoming painful to reuse

Sound familiar? 😅

So today, I’ll show a pattern for turning type guards into reusable logic blocks.

I’ll use my lightweight, zero-dependency library is-kit to illustrate the idea — but the mindset applies to vanilla TypeScript too.

https://github.com/nyaomaru/is-kit

Alright, let’s dive in! 🧩

What’s a Type Guard Anyway?

In short: a function that performs runtime validation while narrowing TypeScript types at the same time.

function isString(value: unknown): value is string {
  return typeof value === 'string';
}

declare const input: unknown;

if (isString(input)) {
  input.toUpperCase(); // input is string
}

Simple, right?

Here’s a slightly more realistic version:

type SimpleUser = {
  id: number;
  name: string;
};

function isObject(value: unknown): value is Record<PropertyKey, unknown> {
  return typeof value === 'object' && value !== null;
}

function isNumber(value: unknown): value is number {
  return typeof value === 'number' && Number.isFinite(value);
}

function isUser(value: unknown): value is SimpleUser {
  return (
    isObject(value) &&
    isNumber(value.id) &&
    isString(value.name)
  );
}

This works.

But as your app grows, these guards start multiplying like crazy.

You often need the same checks again and again:

primitive checks
object-shape checks
literal checks
optional/nullish checks
extra domain rules

Handy, but repetitive.
That’s where composition comes in ♻️

♻️ Build Guards Through Definition and Composition

The core idea is simple:

Define small guards.
Compose them.
Reuse the result anywhere TypeScript narrowing matters.

With is-kit, the previous isUser example becomes:

import { isNumber, isString, struct } from 'is-kit';

const isUser = struct({
  id: isNumber,
  name: isString
});

Clean, concise, and fully type-safe! ✨

declare const input: unknown;

if (isUser(input)) {
  input.id; // number
  input.name; // string
}

struct handles the object-shape check for you.

It also only accepts plain objects — not arrays, dates, maps, or class instances.

Want to reject extra own enumerable string keys too? Use exact mode:

const isExactUser = struct(
  {
    id: isNumber,
    name: isString
  },
  { exact: true }
);

Nice and strict 🛡️

For existing TypeScript object types, use typedStruct<T>() to keep your handwritten guard aligned with the type:

import { isNumber, isString, typedStruct } from 'is-kit';

type User = {
  id: number;
  name: string;
};

const isUser = typedStruct<User>()({
  id: isNumber,
  name: isString
});

If the User type changes, TypeScript helps you notice when the guard no longer matches.

That means fewer silent runtime/type mismatches.
Very good. Very useful. 😎

Define Custom Guards

Sometimes a primitive guard is not enough.

For reusable custom checks, use define<T>(...).

import { define, isString } from 'is-kit';

const isSlug = define<string>(
  (value) => isString(value) && /^[a-z0-9-]+$/.test(value)
);

isSlug('release-110'); // true
isSlug('Release 110'); // false

This is great when you want to name a runtime rule and reuse it as a guard.

No mystery regex scattered everywhere.
Just one small reusable block ✨

Compose Existing Guards

Need “A or B”? Use or.

import { isNumber, isString, or } from 'is-kit';

const isId = or(isString, isNumber);

isId('user-1'); // true
isId(123); // true
isId(false); // false

Need “base guard plus extra rule”? Use and with predicateToRefine.

import { and, isNumber, predicateToRefine } from 'is-kit';

const isPositive = predicateToRefine<number>((value) => value > 0);

const isPositiveNumber = and(isNumber, isPositive);

isPositiveNumber(1); // true
isPositiveNumber(-1); // false
isPositiveNumber('1'); // false

The important part:

isNumber runs first.

So after that, the refinement can safely check value > 0.

No unsafe guessing.
No “please TypeScript trust me” energy. 😅

Example: Role-Based User Guards

Let’s build something closer to real app code.

import {
  and,
  isNumber,
  isString,
  narrowKeyTo,
  oneOfValues,
  or,
  predicateToRefine,
  struct
} from 'is-kit';

type User = {
  id: string;
  name: string;
  age: number;
  role: 'admin' | 'member' | 'guest';
};

const isUser = struct({
  id: isString,
  name: isString,
  age: isNumber,
  role: oneOfValues('admin', 'member', 'guest')
});

Now we can create role-specific guards from the base guard.

const byRole = narrowKeyTo(isUser, 'role');

const isAdmin = byRole('admin');
const isMember = byRole('member');
const isGuest = byRole('guest');

Want multiple roles? Use or.

const isStaff = or(isAdmin, isMember);

declare const input: unknown;

if (isStaff(input)) {
  input.role; // 'admin' | 'member'
  input.name; // string
}

Want a role plus another condition? Use and.

const isAdult = predicateToRefine<Readonly<User> & { role: 'admin' }>(
  (user) => user.age >= 18
);

const isAdultAdmin = and(isAdmin, isAdult);

declare const candidate: unknown;

if (isAdultAdmin(candidate)) {
  candidate.role; // 'admin'
  candidate.age; // number
}

That’s all.

isUser validates the object shape
isAdmin narrows the role
isAdult adds the age rule
isAdultAdmin composes them

No giant nested if.
No repeated object checks.
No copy-pasted guard logic.

Just small reusable pieces snapping together like LEGO blocks 🧱✨

Parse Unknown Values Safely

Guards become especially useful at boundaries:

API responses
localStorage
form input
JSON parsing
message events
feature flags

Basically, anywhere unknown enters your app.

Use safeParse when you want a small result object.

import { safeParse } from 'is-kit';

declare const payload: unknown;

const result = safeParse(isUser, payload);

if (result.valid) {
  result.value.id; // string
  result.value.role; // 'admin' | 'member' | 'guest'
}

For JSON text, use safeJsonParse.

import { safeJsonParse } from 'is-kit';

const result = safeJsonParse(
  '{"id":"u1","name":"Ada","age":36,"role":"admin"}',
  isUser
);

if (result.valid) {
  result.value.name.toUpperCase();
}

Invalid JSON? { valid: false }
Guard mismatch? { valid: false }

Simple and predictable. Very nice 😎

Handle Nullish Values Explicitly

Nullish handling is another place where guard logic gets messy fast.

is-kit gives you small helpers for that too.

import { isNil, isString, nullish, optional } from 'is-kit';

isNil(null); // true
isNil(undefined); // true
isNil(0); // false

const isNullishString = nullish(isString);
const isOptionalString = optional(isString);

isNullishString(null); // true
isNullishString('hello'); // true

isOptionalString(undefined); // true
isOptionalString('hello'); // true

Use:

isNil(value) to check null | undefined directly
nullable(guard) to allow null
optional(guard) to allow undefined
nullish(guard) to allow both

For optional object keys inside struct, use optionalKey.

import { isString, optionalKey, struct } from 'is-kit';

const isProfile = struct({
  id: isString,
  nickname: optionalKey(isString)
});

This means nickname may be missing.
But if it exists, it must be a string.

Small rule. Clear behavior. No confusion 👍

🎯 Summary

Type guards do not have to be one-off defensive functions.

They can be reusable logic blocks.

With is-kit, you can build guards from small pieces:

define for custom runtime checks
struct and typedStruct for object shapes
and, or, and not for composition
predicateToRefine for extra conditions
narrowKeyTo for discriminant-style narrowing
safeParse and safeJsonParse for boundary validation

Try converting just one existing isXXX function into an is-kit version.

Once your guards are small and composable, they become much easier to share, test, and maintain.

You’ll feel the difference pretty quickly 🚀

If you like it, drop a ⭐ — it really helps! 😻

https://github.com/nyaomaru/is-kit

JobApp AI

Tue, 07 Jul 2026 17:32:02 +0000

Job hunting shouldn't cost a fortune or your data.
JobApp AI is a subscription platform helping job seekers streamline their applications, with pricing designed to stay accessible across Africa and other global regions.

Milestones I'm proud of: Shipped end-to-end encryption for stored user credentials Built a self-service billing portal so users can manage their own subscriptions, no support ticket needed ️ Ran a full security audit of the codebase because trust isn't a feature; it's a foundation
Building a SaaS product solo means wearing every hat: engineer, security reviewer, support desk, and product manager. This was a good reminder of why that audit work matters as much as the features people see.
Try it: https://jobapp.best

It's open source too.
https://github.com/JulietChinenyeDuru/Job-App-AI
Feel free to fork it and build on it, and if you find it useful, a star ⭐ on the repo goes a long way in helping others discover it.

Coder Legion - Recent posts tagged showdev

What I've Been Improving Behind the Scenes

Giving the watchlist a better starting point

Making navigation feel smoother

Spending more time on the details

What's next?

Building Knemora: An Open-source, Local-first AI (SI) Second Brain

I made my portfolio site audit its own security headers, live, in front of you.

The setup

How can a website audit its own security headers live, in the page itself?

Why does a hash-based CSP have to live in a meta tag instead of the response headers?

What this cost me, honestly

How I Built My Own Opus Clip Alternative With Claude Code

What does an AI clipping tool actually do?

How does the AI pick the right moments?

Why is auto-reframing the hardest part?

How do the word-by-word captions work?

What broke while building it?

How did Claude Code fit in?

What is next for the tool?

Frequently asked questions

Is there a free Opus Clip alternative?

How does Opus Clip choose which moments to clip?

Can GPT-4o pick good clips from a transcript?

What is the hardest part of building an AI clipping tool?

Do I need a GPU to run it?

Launching a fancy text converter: 451 styles, and the Unicode edge cases behind them

1. A style is mostly a lookup table

2. The block has holes

3. Accents: decompose first

4. Don't split emoji

5. Long input: preview first, convert on copy

Honest limits

I'd like your feedback

I built PinOps to turn a published URL into useful Pinterest pins

I Tried to Build Persistent Compute on an Xbox SSD. The Failed Tests Changed the Architecture.

The problem wasn't just memory capacity

First, I investigated the Xbox process model

The first failures weren't even storage failures

The second process became a coordinator

Next, I needed storage that could survive failure

Then I tried breaking it

Running computation through persistent storage

The first uninterrupted runs passed. Restart failed.

Eight gigabytes, and another failed experiment

The 64 GiB attempt was refused

The result: worker 0.1.160.0

What this proves, and what it doesn't

Why the failed tests mattered more than the number

The code is now open source

Beyond the SSD experiment

I turned strings into letter arrays and started rebuilding URLs with index ranges

The core idea

Why bother?

Extra powers

plan – find the ranges that rebuild a target

scatter / gather – seeded shuffle + reconstruct

Install

Links

I Added a Chatbot to My Movie Discovery App

XCP: From an Xbox Experiment to an Open Development Platform

I’m in High School and I Built VBX: A Modern, Compiled Successor to Visual Basic 6

️ What is VBX?

A Quick Taste of VBX

⚡ Under the Hood (The Engineering)

Meet Our Mascot: BASIC-Chan!

Tooling & VS Code Extension

What's Next?

I wanted Git to show me what would happen before changing history, so I built it

Coding Sessions

Building CyberRef: A Single-Binary Offline Reference for Cybersecurity Practitioners

Show a single Windows application window in any web browser on LAN

CodeSage: Code Intelligence for AI Agents, and Why I Rebuilt Its Models

What CodeSage gives an agent

The index has to keep up with the code

Same weights, rebuilt graphs

The biggest single win wasn't a model

Scores that say what they measured

Where it falls short

Try it

`plan` – find the ranges that rebuild a target

`scatter` / `gather` – seeded shuffle + reconstruct