标签：#electron

Almost everything that makes the modern world hum, from the phone in your pocket to the sensor on a factory floor, traces back to a single quiet afternoon in a nearly empty laboratory in Dallas. In the summer of 1958, a newly hired engineer named Jack Kilby built the first working integrated circuit at Texas Instruments. It was a crude little thing, a sliver of germanium with a few components and some fine gold wires, but it carried an idea that would reshape electronics: that an entire circuit could be made from one piece of semiconductor material. Every microcontroller and connected device we build today is a descendant of that prototype. The engineer who was left behind Kilby had only just joined Texas Instruments and had not yet earned any vacation time. So when the company shut down for its traditional summer break in July 1958 and most of his colleagues left, he found himself nearly alone in the lab with time to think. The problem on his mind was one the whole industry called the "tyranny of numbers." Circuits were getting more capable, which meant more transistors, resistors, and capacitors, each one a separate part that had to be wired together by hand. Every added component meant more connections, more soldering, and more chances for something to fail. The complexity was becoming a wall. Kilby's insight was disarmingly simple. If resistors and capacitors could be made from the same semiconductor material as transistors, then every part of a circuit could be fabricated together in a single block. No separate components, no forest of hand-soldered wires. He sketched the idea, and when his managers returned he had something to show them. September 12, 1958 On September 12, 1958, Kilby demonstrated his prototype to Texas Instruments executives. The device was a phase-shift oscillator built on a bar of germanium, with its elements connected by delicate gold "flying wires." He connected it to an oscilloscope, flipped the switch, and a steady sine wave rolled acro

The incident comes as Tata Electronics expands its role in global technology supply chains.

The Space Force wants to cut the time to field new satellites from years to weeks, days, or hours.

Every connected device on your desk, from a smart plug to a fitness band to a hobbyist ESP32 board, runs on a descendant of one tiny chip that was never meant to change the world. In 1971, Intel released the 4004, the first commercially available microprocessor. It was not built for computers, robots, or the internet. It was built to run a desk calculator. The story of how a calculator chip became the foundation of modern IoT is one of the most instructive in all of electronics. A calculator contract that got out of hand The 4004 began as a job for hire. A Japanese calculator company called Busicom approached Intel in 1969 wanting a set of custom chips for a new line of printing calculators. The original plan called for around a dozen separate, purpose-built integrated circuits, each wired to do one fixed task. It was the standard approach of the era: if you wanted a device to do something, you designed silicon that did exactly that and nothing else. Intel engineer Ted Hoff looked at the sprawling design and proposed something radical. Instead of a pile of single-purpose chips, why not build one general-purpose processor that could be told what to do through software? A program stored in memory could make the same chip behave like a calculator today and something else entirely tomorrow. Stanley Mazor helped shape the architecture, and a newly arrived engineer named Federico Faggin turned the concept into a working device, inventing the silicon-gate design techniques that made it physically possible. Masatoshi Shima, Busicom's representative, worked alongside them on the logic. 2,300 transistors that started everything When the 4004 was announced on November 15, 1971, it packed about 2,300 transistors onto a single sliver of silicon. By modern standards that is almost nothing; a current smartphone chip holds tens of billions. But the leap was not about raw count. It was about the idea. For the first time, a complete central processing unit existed on one chip that an

How to Call Windows Native APIs in Electron Calling Windows native APIs in an Electron app feels like wanting to see the ocean but only having a map. After some trial and error, I've found a few paths—writing this article serves as a record and a guide for others who might follow. Background When building Electron desktop applications, you inevitably need to interact with the operating system. On Windows, these requirements are quite common: Calling Windows Store APIs for in-app purchases Handling file system virtualization specific to Windows Store apps Obtaining system-level permissions and resources Interacting with Windows Runtime (WinRT) components Electron is fundamentally a Node.js environment, and Node.js doesn't natively provide direct access to Windows native APIs. A bridge is needed between the two. It's like trying to communicate with a friend who doesn't speak Chinese—you need a translator. Electron is written in JavaScript, Windows APIs in C/C++. The language barrier requires building a bridge. That's the harsh reality of the code world. About HagiCode The solutions shared in this article come from our practical experience with the HagiCode project. HagiCode Desktop needs to call Microsoft Store APIs to handle subscription purchases and license management, which is why we developed a set of technical solutions. After all, necessity drives innovation—that's a truth. Technical Solution Comparison When calling Windows native APIs in Electron, there are several mainstream approaches to choose from. Each has its applicable scenarios—like different tools in a toolbox, they work best when used in the right place, otherwise just add trouble. Solution Applicable Scenarios Pros Cons dynwinrt WinRT APIs (e.g., Store API) Type-safe, auto-generated bindings, modern JavaScript support Only supports WinRT APIs, requires Windows SDK Native Node.js Extensions High performance, any Windows API Complete control, optimal performance Requires C++ development skills, comple

You scan one to pay at a sari-sari store, pull up a restaurant menu, or board a flight. The QR code has quietly become one of the most universal pieces of interface design on the planet. But it was never meant for any of that. The QR code was invented in 1994 to solve a very specific problem on a Japanese car factory floor, and the engineering decisions made under that constraint are exactly why it later conquered the world. A barcode problem on the assembly line In the early 1990s, Toyota's manufacturing arm had a data problem. Tracking thousands of distinct components through production meant scanning barcodes, and barcodes are stingy: a standard one-dimensional barcode holds roughly 20 characters. Workers were ending up with parts plastered in ten or more barcodes just to encode enough information, and each one had to be scanned separately. It was slow, and on an assembly line, slow is expensive. Masahiro Hara, an engineer at Denso Wave, a Toyota subsidiary, took on the challenge of designing something better. He wanted a code that could hold far more data, be read much faster, and tolerate the dirt, smudges, and odd angles of a real factory rather than a clean lab. Designing for speed and any angle The breakthrough was going two-dimensional. By encoding data in a grid of black and white squares rather than a single row of lines, Hara's team could pack in thousands of characters instead of a few dozen. The name they chose, QR for "Quick Response," was a direct promise about scanning speed. The most recognizable feature of a QR code, the three large squares in its corners, solves the hardest part of the problem: letting a scanner instantly find the code and work out its orientation no matter how the part is turned. Hara's team analyzed printed material to find a black-and-white sequence that almost never occurs naturally in text and images, and settled on a ratio of 1:1:3:1:1 for those corner markers. Because that pattern is so rare in everyday print, a scanner ca

If you sell a desktop app on Gumroad, it hands every buyer a license key. But Gumroad stops there — checking that key inside your app is entirely up to you. Here's how to do it properly in Node/Electron, plus the three traps that catch almost everyone. We'll use gumroad-license-lite, a tiny, zero-dependency, MIT-licensed helper (you can npm install it or just copy its ~120 lines). Turn on license keys in Gumroad On your product, enable "Generate a unique license key per sale," then grab your product_id (in the product settings / API). Every buyer now gets a key on their receipt. Verify a key const { verifyGumroadLicense } = require('gumroad-license-lite'); const result = await verifyGumroadLicense({ productId: 'YOUR_PRODUCT_ID', licenseKey, }); if (result.valid) { unlockApp(result.email); } result.valid is true only if the key is real and the sale wasn't refunded, disputed, or a cancelled subscription — not just "does this key exist," which is gotcha #1 below. Gate your app on launch You don't want to call Gumroad on every launch, and you want the app to survive a flaky connection. LicenseGate caches the result and re-checks periodically: const path = require('node:path'); const { LicenseGate } = require('gumroad-license-lite'); const gate = new LicenseGate({ productId: 'YOUR_PRODUCT_ID', storageFile: path.join(app.getPath('userData'), 'license.json'), recheckEveryDays: 3, offlineGraceDays: 14, }); // on your activation screen: await gate.activate(userEnteredKey); // on every launch: const status = await gate.check(); if (!status.licensed) showActivationScreen(); The 3 gotchas "Valid" isn't the same as "exists." A refunded or charged-back sale still has a real, working key. If you only check that the key exists, people can buy, copy the key, refund, and keep your app forever. Always check the refund / dispute / subscription flags (the helper above does this for you). The uses counter is global, not per-device. Gumroad tracks a uses count, but it can't tell you which

Plug a sensor into a switch, wire up a building full of cameras, or rack a server, and you are using Ethernet. It is the most widely deployed wired networking standard on earth, the quiet backbone under offices, factories, and data centers. And it is named after a scientific idea that turned out to be completely wrong. The name was not an accident or a marketing afterthought. It was a deliberate engineering choice, and the reasoning behind it explains why Ethernet outlived nearly every rival and still underpins industrial IoT half a century later. A memo, a laser printer, and a dead theory The date Ethernet enthusiasts celebrate is May 22, 1973. On that day, a young engineer named Robert Metcalfe, working at Xerox's legendary Palo Alto Research Center (PARC), circulated a memo describing how to connect the Alto - one of the first personal computers - to a new device PARC had built: the laser printer. The problem was getting many machines to share one wire without their messages colliding into noise. Metcalfe needed a name for the shared medium that carried the signals. He reached back into nineteenth-century physics and borrowed the term luminiferous ether . For generations, physicists had assumed that light, being a wave, needed something to wave through - just as sound needs air. They called that invisible, all-pervading substance the ether, and they believed it filled the entire universe as a silent carrier of electromagnetic waves. The trouble is that the ether does not exist. The famous Michelson-Morley experiment of 1887 failed to detect it, and Einstein's special relativity in 1905 made it unnecessary altogether. By the time Metcalfe wrote his memo, the luminiferous ether had been a discredited idea for decades. He used it anyway, and on purpose. Why a debunked idea made for brilliant engineering Metcalfe later explained the choice plainly: "We called it Ethernet because the ether could be coax, twisted pair, radio, optical fibers, power line, whatever you wa

Ask almost any engineer what "Wi-Fi" stands for and you'll hear the same answer: "Wireless Fidelity." It is one of the most repeated facts in tech, it appears in textbooks and product manuals, and it is wrong. Wi-Fi does not stand for Wireless Fidelity. In fact, it does not stand for anything at all. A name invented by a branding agency In 1999, the industry group then known as the Wireless Ethernet Compatibility Alliance — today the Wi-Fi Alliance — had a problem. The wireless networking standard it was promoting carried the memorable name "IEEE 802.11b Direct Sequence." That string is precise, but no consumer was ever going to ask a store clerk for an 802.11b router. The technology needed a brand. So the alliance hired Interbrand, the same firm behind names like Prozac and the Compaq brand, to invent something catchy. Interbrand returned with a shortlist of about ten candidates, and the group chose "Wi-Fi." Phil Belanger, a founding member of the alliance, has been blunt about it for years: the name has no expanded meaning. It was picked because it was short, easy to say, and rhymed with "Hi-Fi," a term consumers already associated with high-quality audio gear. So where did "Wireless Fidelity" come from? The myth has a real origin. Some board members were uncomfortable shipping a brand name that "meant nothing," so the alliance briefly bolted on the tagline "The Standard for Wireless Fidelity." It was a backronym — two words reverse-engineered to fit the syllables "Wi" and "Fi" after the fact. The phrase was clumsy, it never described the technology accurately, and once the alliance brought on more marketing-savvy members it was quietly dropped. The tagline disappeared; the misconception it planted did not. Why this matters if you build connected things This is a fun piece of trivia, but it points at something real for anyone doing IoT and embedded development . The protocols we treat as immovable technical bedrock are often shaped as much by branding, licensing,

The first time I encountered an EIA-96 resistor , I assumed the marking would tell me the resistance value directly. I was troubleshooting a PCB and found a resistor marked 24C . Naturally, I expected some relationship between "24" and the actual resistance. After measuring and checking the datasheet, I discovered the resistor was 17.4 kΩ . That raised an obvious question: Why doesn't the code match the resistance value? The Problem With Traditional SMD Codes Most electronics enthusiasts learn resistor markings through familiar examples: 103 = 10 kΩ 472 = 4.7 kΩ 681 = 680 Ω These markings are straightforward. The first digits are significant figures and the last digit is a multiplier. The system works well for common resistor values, especially 5% tolerance components. However, things become complicated when manufacturers need to identify large numbers of precision resistor values on extremely small packages. Enter the EIA-96 Series Precision resistors often use the E96 preferred value series. Instead of having only a handful of values per decade, the E96 series contains 96 standardized resistance values between powers of ten. Some examples include: 100 Ω 102 Ω 105 Ω 107 Ω 110 Ω 113 Ω Notice how closely spaced these values are. Trying to represent all of them with traditional three-digit markings would quickly become messy and inconsistent. A Different Approach Rather than printing the resistance value directly, EIA-96 uses an index system. Each number from 01 to 96 corresponds to one of the standard E96 values. For example: Code Base Value 01 100 24 174 68 499 96 976 A letter is then added to indicate the multiplier. So the resistor marking becomes: Number + Letter Instead of: Resistance Value Example: Decoding 24C Let's break down 24C. First, look up the base value: 24 → 174 Next, decode the multiplier letter: C → ×100 Now calculate: 174 × 100 = 17,400 Ω Final resistance: 17.4 kΩ At first glance, nothing about "24C" resembles 17.4 kΩ, but that's because the code i

If you're building or integrating Automated Test Equipment for aerospace or defence electronics, the technical requirements go well beyond "does the test pass." You need documentation that satisfies MIL-STD, AS9100, and DO-178C auditors — and an architecture that scales from prototype to production. Here's how modern Universal ATE systems are structured for defence-grade compliance. The Core Architecture A defence-grade ATE system has four functional layers: ┌─────────────────────────────────────────┐ │ Test Executive (LabVIEW) │ ← Orchestrates all test sequences ├────────────────┬────────────────────────┤ │ Instrument │ DUT Interface │ ← Hardware layer │ Control │ (ICT/JTAG/Func) │ ├────────────────┴────────────────────────┤ │ Data Management Layer │ ← Logging, traceability, reports ├─────────────────────────────────────────┤ │ Calibration & Verification │ ← Ensures measurement accuracy └─────────────────────────────────────────┘ Test Executive Design in LabVIEW The test executive controls the sequence, manages results, and handles failures. Key design principles: Test Sequence: 1. DUT identification (serial number scan or manual entry) 2. Pre-test self-check (verify instrument calibration status) 3. ICT phase — passive component verification 4. JTAG boundary scan — IEEE 1149.1 interconnect verification 5. Power-on functional test — operational verification 6. RF/signal analysis — if applicable to DUT type 7. Report generation — automatic, timestamped 8. Pass/fail disposition record JTAG Integration via IEEE 1149.1 For high-density boards where bed-of-nails is not viable, JTAG boundary scan is implemented via a JTAG controller (e.g., XJTAG, Corelis, or ASSET InterTech) integrated into the LabVIEW environment: LabVIEW → JTAG Controller API → Scan Chain → DUT ICs The boundary scan description files (BSDL) for each IC define the test vectors. Your test executive loads BSDL files, generates scan chain topology, and runs interconnect tests automatically. Data Traceabili

If you've ever built an Electron app that needs a backend, you know the problem. You want something lightweight, something that runs on Node, something where you don't spend three hours configuring Swagger, and something that doesn't make you feel like you're setting up a microservices architecture just to expose two endpoints to your own desktop UI. I've shipped Electron apps with Express. I've tried Fastify. Both work, but they leave you doing a lot of plumbing yourself. Then I found DaloyJS , and honestly, it clicked. The Electron Backend Problem Here's the thing about Electron: your renderer process is basically a browser, and your main process is a Node.js server. When you need data from external APIs, or you need a clean layer between your UI and your business logic, you want a BFF, a Backend for Frontend. A thin server that composes upstream calls, holds the session, and returns exactly the shape your UI needs. DaloyJS was built for this role. The docs even say so plainly: typed upstream client, fetchGuard for safe egress, session handling, and edge runtime support. That combination is exactly the BFF toolkit. Contract-First Means Less Glue The killer feature for desktop apps is contract-first routing. You define a route once, and DaloyJS gives you validation, OpenAPI 3.1 docs, and a typed in-process client all from the same source. No stale spec files. No writing types by hand. Here's what a basic Electron BFF route looks like: import { z } from " zod " ; import { App , requestId , secureHeaders , rateLimit } from " @daloyjs/core " ; import { serve } from " @daloyjs/core/node " ; const app = new App ({ bodyLimitBytes : 1 << 20 , requestTimeoutMs : 5 _000 , docs : true , // auto-mounts /docs and /openapi.json }); app . use ( requestId ()); app . use ( secureHeaders ()); app . use ( rateLimit ({ windowMs : 60 _000 , max : 120 })); app . route ({ method : " GET " , path : " /settings/:userId " , operationId : " getUserSettings " , request : { params : z . objec

For months I had the same annoying problem: folders full of screenshots I couldn't actually use. Lecture slides, PDFs I own, scanned pages — all just images . I couldn't Ctrl-F them, couldn't copy a line out, couldn't get my OS to index them. A picture of text is useless the moment you need to find something in it. So I built CapDrop to automate the whole chain on Windows. This is a write-up of how it works under the hood and the bugs that nearly broke me. The core idea You draw a capture box over a page, pick a page key (Page Down, arrow keys), set an interval, and walk away. CapDrop then: Captures each page on the interval Presses the page key for you to advance Auto-crops margins and toolbars out of every shot Runs OCR locally Binds everything into a single PDF with a real text layer The result is one document you can search, not a pile of images. The stack Electron for the app shell and capture/UI (I already had window management, hotkeys, and floating-bubble export working — no reason to rewrite). A Python OCR sidecar (RapidOCR) spawned as a child process. OCR runs 100% locally; nothing is ever uploaded. jimp for auto-crop, with a 12px safety pad so edge text never gets clipped. pdf-lib to bind the pages and inject the OCR text layer. The Electron + Python-sidecar split was a deliberate choice. People kept telling me to rewrite the whole thing in Python "for the OCR," but the Electron app already had everything except OCR. Adding a sidecar was a few hundred lines; a rewrite would've been months. The bug that cost me two days After adding the OCR pipeline, my global capture hotkey developed a 4-second delay on the first press. Cold, every time. I guessed wrong twice — thumbnail size, then a race condition. Both were dead ends. The only thing that actually found it was instrumenting the hot path with timing logs. The culprit: a fs.readFile of a tiny 749-byte settings.json on every hotkey press. On a cold start that read was taking 2–4 seconds — Windows Defender's

Lithium battery packs are only as strong as their weakest cell. Whether you're designing a drone battery, an EV pack, or an energy storage system, cell balancing plays a critical role in battery safety, lifespan, and performance. But many developers and hardware engineers still confuse passive balancing and active balancing , or underestimate how important balancing becomes in multi-cell lithium systems. In this article, we'll break down: Why battery balancing matters What causes cell imbalance How passive balancing works How active balancing works Engineering trade-offs between both methods Where each balancing strategy is commonly used 1. Why Battery Cells Become Unbalanced In theory, every lithium cell inside a battery pack should behave identically. In reality, that never happens. Even cells from the same production batch will have slight differences in: Internal resistance Capacity Self-discharge rate Temperature response Aging characteristics Over time, those small differences accumulate. For example: One cell may charge slightly faster Another may discharge deeper One may heat up more under load Eventually, the pack voltage becomes uneven. This is called cell imbalance . 2. Why Cell Imbalance Is Dangerous Imagine a 4S lithium battery pack. If one cell reaches 4.25V while the others are still at 4.10V, the charger must stop to avoid overcharging that single cell. That means: The entire pack never reaches full usable capacity Weak cells age faster Heat generation increases Safety risks become higher The same problem happens during discharge. If one cell drops below the minimum safe voltage earlier than others, the BMS cuts power to protect the pack — even though the remaining cells still contain energy. In other words: A battery pack is limited by its weakest cell. 3. What Is Battery Balancing? Battery balancing is the process of equalizing cell voltages inside a battery pack. The goal is simple: Prevent overcharge Prevent over-discharge Improve pack lifespan I