Blog
Posts about the development process, solved problems and learned technologies
Building a Speech-to-Text EXE: Three DLL Hell Fixes That Actually Worked
I was staring at a PyInstaller build that refused to cooperate. The Speech to Text application—powered by **GigaAM** for audio processing and **CTranslate2** for inference—needed to run as a standalone Windows executable with CUDA support. Sounds simple, right? It wasn't. The mission: collect all required DLLs, bundle them into a working EXE, and ship it. The reality: three separate classes of dependencies, each with their own quirks, decided to hide from the bundler. ## The DLL Collection Problem My first attempt was naive. I assumed PyInstaller would automatically find everything: **2 numpy.libs DLLs**, **11 NVIDIA CUDA libraries**, and **3 CTranslate2 binaries**. Spoiler alert—it didn't. The EXE built fine. It just didn't run. The breakthrough came when I realized PyInstaller's binary collection works through import tracing, not filesystem scanning. If your code doesn't explicitly import a library, the bundler has no reason to look for it. CUDA libraries? They're loaded dynamically at runtime. That means they're invisible to static analysis. ## The Fixes That Stuck **Problem #1: setuptools data files.** Modern setuptools (v80+) ships with mysterious text files that the spec file wasn't capturing. Solution: add them explicitly to the `datas` list in the PyInstaller spec. **Problem #2: numpy.libs openblas DLLs.** Here's where it got weird. NumPy depends on OpenBLAS, but the DLL names are dynamic (`libscipy_openblas64_*.dll`). PyInstaller couldn't trace these because they're loaded via ctypes, not standard imports. I ended up manually specifying them in the `binaries` section of the spec file, pointing directly to the venv directory. **Problem #3: NVIDIA runtime libraries.** The CPU-focused venv had CUDA packages installed (`nvidia-cublas-cu12`, `nvidia-nccl-cu12`, and others), but their binaries weren't being copied. The fix: tell PyInstaller exactly where these libraries live and force-include them. No guessing, no magic. ## The Progressive Warmup Strategy While debugging, I discovered GigaAM's initialization was taking a full **30 seconds** on first load. For a user-facing app, that's a perception killer. I implemented progressive loading: warm up the model in the background with a **0.89-second overhead** on subsequent runs. Not a DLL fix, but it made the final product feel snappier. ## The Reality Check The final EXE in `dist/VoiceInput-CUDA/` now starts successfully, loads GigaAM without errors, and processes audio. All **16 dependency binaries** are accounted for. The GUI appears immediately. The audio engine spins up in under a second on warm loads. Being a self-taught developer debugging a multi-library CUDA bundling issue is almost like being a headless chicken—lots of flapping around until you finally figure out which direction to run. 😄
Wiring Real State into a SCADA UI: When Buttons Actually Control Things
Building a SCADA coating system means dealing with 28 industrial baths that need to heat, cover, stir, and fill themselves—and the operator needs to *see* every change *now*. I faced a classic React problem: my EquipmentView and LineView components were wired to console.log. Time to make them actually control something. The challenge was moving baths from a static import into `useState` so that every button press—whether it's toggling a single heater or commanding all 28 units to close their covers at once—updates the shared state *instantly* across every tab and sidebar. The operator shouldn't wait. They shouldn't wonder if their click registered. I started with **OperatorWorkspace.tsx** as the state owner. All bath data lives there, wrapped in `useState`. Then I threaded callback props down through EquipmentView and GroupControlBar. The heater buttons are straightforward: flip the boolean, re-render. But bulk operations like "ALL COVERS OPEN" demanded more thought. Here's where I chose *asynchronous feedback* over instant completion. When the operator hits "ВСЕ ОТКР" (all covers open), each bath's cover toggles with a ~400ms delay between units. Why? Because in the real world, 28 hydraulic motors don't move simultaneously. The UI reflects that reality—covers progress down the table one by one. If something jams, the operator sees *where* the sequence stops. It's non-blocking too: a new command cancels any pending operations via `clearTimeout`, so the operator keeps control. The "ДОЛИВ" (top-up) operation was trickier. Baths below 70% capacity need to refill, but they can't all pump water at once. I broke it into five steps of incremental fill, staggered across units. Again, asynchronous—the UI stays responsive, and the operator watches the levels climb. I wired everything through a simple callback pattern: EquipmentView receives `onToggleHeater(bathId)` and `onToggleCover(bathId)`. GroupControlBar gets `onBulkHeater(on)`, `onBulkCovers(open)`, and `onTopUp()`. The Sidebar on LineView calls the same callbacks for single-bath controls. All roads lead back to state in OperatorWorkspace. **The result:** No more console.log. Every button works. State syncs across tabs. Bulk commands feel *real* because they stagger, just like actual hardware would behave. Now, when the JavaScript developer on my team asked why I didn't just toggle everything instantly—"wouldn't that be faster?"—I reminded them: *faster isn't always better in industrial UIs.* Predictability and visibility beat speed. 😄
Why Global Setpoints Break Industrial Control Systems
I was deep in the **Bot Social Publisher** project when an old SCADA lesson came back: one control for everything is a design flaw waiting to happen. The scenario was different this time—not coating baths, but content enrichment pipelines. But the principle was identical. We needed mass operations: publish all pending notes, flag all duplicates, regenerate all thumbnails. Tempting to build one big "Apply to All" button. Then reality hit. Each note has different requirements. A git commit note needs different enrichment than a VSCode snippet. Some need Wikipedia context, others don't. Language validation catches swapped RU/EN content—but only if you check per-item. A global operation would bulldoze through edge cases and break downstream consumers. So we split the architecture into **selective control** and **batch monitoring**. The selective layer handles per-item operations: individual enrichment, language validation, proofread requests via Claude CLI. The batch layer tracks aggregates—how many notes processed, which categories failed, language swap frequency. Think of it like SCADA's "All ON/All OFF" without touching individual setpoints. In the code, this meant separating concerns. `EnrichedNote` validation happens item-by-item before any publisher touches it. The pipeline logs metrics after each cycle: `input_lines`, `selected_lines`, `llm_calls_count`, `response_length`. Operators (or automated monitors) see the health signal without needing to drill into every note. The payoff? When Claude CLI hits its daily 100-query limit, we don't publish garbage. When language detection fails on a note, it doesn't corrupt the whole batch. When a collector sends junk with `<ide_selection>` tags, ContentSelector filters it before enrichment wastes LLM tokens. This mirrors what industrial teams discovered decades ago: **granularity prevents cascading failures**. You control what you can measure. You measure what you separate. The technical bet here is context-aware batch processing. Not "apply this operation to everything" but "apply this operation to items matching criteria X, log outcomes, let downstream handlers decide what's safe." Building it clean means respecting the boundary between convenience and correctness. A "publish all" button might save three clicks today. It'll cost you three hours of debugging tomorrow. --- > **Why did the batch job apply for a job in security?** 🔐 Because it learned that checking *every* input before processing beats checking *none* after things break.
Controlling Multiple Baths in SCADA: Why One Setpoint Can't Rule Them All
I was deep into the **feature/variant-a-migration** branch of our SCADA Coating project when I hit a design wall. The team wanted a single setpoint field to control temperature across all baths—a convenient one-click solution. But reality doesn't work that way in industrial control systems, and neither should our UI. Here's the problem: each bath in a coating line has unique thermal characteristics. Bath A might heat slower, Bath B has aging heating elements, Bath C was just refurbished. A global setpoint ignores these physical realities. More importantly, operators need *granular control*—they should be able to adjust individual baths without affecting the entire line. Safety-critical systems demand precision, not convenience shortcuts. So we redesigned the thermal control section. Instead of a single "Set All" input, I implemented: - **Dual action buttons**: "All ON" and "All OFF" sit side-by-side, letting operators toggle banks without touching individual setpoints - **Per-bath setpoint modal**: clicking a bath in the table opens a detailed view where that bath's temperature target is adjustable - **Live counters**: "ON: 10 / OFF: 18 (Total: 28)" keeps operators aware of system state at a glance The same philosophy applied to cover controls—separate "Close All" and "Open All" buttons with no global state setting. Granular wins. For **rectifier monitoring**, we added a carousel of thumbnail cards above the main detail panel. Each card shows critical metrics: name, current, voltage, and associated bath. Tap a thumbnail, and the detail pane below expands with full parameters across four columns—amperage, voltage, bath, amp-hours, communication status, power supply state, max current, max voltage. It's a multi-level navigation pattern that scales as the system grows. The key insight: **industrial UIs aren't about minimizing clicks—they're about preventing mistakes**. Operators working under pressure need controls that match the physical system they're managing, not shortcuts that create dangerous surprises. Building it clean. No errors. Ship it. 😄