Archive
1290 posts · Page 75 of 108. ← Blog
The single most common way to build a forecaster that looks brilliant and fails in production is evaluating it wrong — and time-series evaluation is riddled with ways to accidentally let the future leak into the past. Getting evaluation right, through proper backtesting that respects time order, matters more than the choice of model. This post is about measuring forecast quality honestly, which is the skill that separates real forecasters from people who fool themselves.
The #1 way to build a forecaster that looks brilliant and fails in production is evaluating it wrong. Why random train/test splits are catastrophic (future leakage), how backtesting (walk-forward validation) respects time order, and why you must always compare against naive baselines. Evaluation matters more than the model.
Engineers often dismiss "brand" as logos, colors, and marketing fluff — the least substantive thing a company does. But brand is actually one of the most consequential and durable assets a company builds: it's the reputation and trust that make everything else in marketing work, that let people choose you without re-evaluating from scratch, and that competitors can't easily copy. A great product with no brand is a well-kept secret; a strong brand is what turns a product into a default choice.
Engineers often dismiss 'brand' as logos and fluff. But brand is one of the most consequential and durable assets a company builds: the reputation and trust that make everything else in marketing work, that competitors can't easily copy. A great product with no brand is a well-kept secret.
How Go's built-in hash table really behaves — reference semantics, the nil-write panic, comma-ok, randomized iteration, why `&m[k]` is illegal, and the presizing and concurrency rules that separate correct map code from the code that bites you at 2 a.m.
How Go's built-in hash table really behaves — reference semantics, the nil-write panic, comma-ok, randomized iteration, why `&m[k]` is illegal, and the presizing and concurrency rules that separate correct...
How a foreign cardholder is offered payment in their home currency, who earns the FX margin, and how the choice threads through authorization and clearing.
How DCC offers a cardholder their home currency at point of sale, the FX markup and disclosure rules, and settlement implications.
Building a matching engine across the internal ledger, the processor report, and the bank statement — with tolerances, break classification, aging, and auto-resolution rules for the items nobody wants to touch.
Teaches how to build a three-way reconciliation engine (internal ledger vs processor vs bank statement): matching keys and tolerances, break classification, aging, and auto-resolution rules for the long tail.
How split knowledge, dual control, and a layered key hierarchy keep a working key from ever appearing in the clear.
Teaches how to run cryptographic key management for payments: HSM-backed key hierarchies (LMK/ZMK/ZPK), key ceremonies with split knowledge and dual control, rotation, and PIN-block translation.
Securing bank-to-bank and scheme connectivity with mutual TLS, detached JWS signatures for non-repudiation, and replay protection built from nonces and timestamps.
Teaches how to secure bank-to-bank and scheme connectivity: mutual TLS with certificate pinning/rotation, detached JWS/XML message signing for non-repudiation, and replay protection with nonces and timestamps.
ReadonlyContext, CallbackContext, ToolContext, InvocationContext — and why the read-only vs mutable distinction is a feature, not a limitation.
The context objects ADK passes into tools and callbacks — InvocationContext, ToolContext, CallbackContext, ReadonlyContext — what each exposes and why the read-only vs mutable split matters.
How a switch builder fans one edge into three mutually-exclusive branches — the workflow analogue of switch/case/default.
AddSwitch/AddCase/WithDefault fans one edge into three mutually-exclusive branches with a guaranteed fallback — the workflow analogue of switch/case/default, fully offline.
Turning agents into a service you can run and expose, then a full DocQA app that ties the whole series together.
Host Microsoft Agent Framework agents with DevUI, A2A, MCP, and AG-UI, then build DocQA — a grounded, cited multi-agent app that ties the whole Python series together.
Before neural networks, two families of methods dominated forecasting for decades — and they still win surprisingly often. Exponential smoothing and ARIMA are the classical workhorses: well-understood, fast, interpretable, and shockingly hard to beat on many real series. This post explains both without heavy math, and makes the case that for a lot of forecasting, the right answer is still a classical model, not a deep one.
Before neural networks, two families dominated — and still win surprisingly often. Exponential smoothing (weighted memory of the past; Holt-Winters) and ARIMA (modeling autocorrelation directly). Why classical methods remain state-of-the-art for much real forecasting (strong on limited data, fast, interpretable, hard to beat — the M-competition result).
Engineers tend to hold marketing in quiet contempt — associating it with spam, hype, manipulation, and the dishonest inflation of mediocre products. That contempt is understandable and mostly aimed at bad marketing, which is real and everywhere. But it causes a costly blind spot: dismissing marketing as a discipline means your genuinely good work goes undiscovered, out-competed by worse products that were merely better explained. Marketing, done well, isn't manipulation — it's the honest work of helping the right people understand and find something valuable.
Engineers tend to hold marketing in quiet contempt — associating it with spam, hype, and manipulation. That contempt is aimed at bad marketing, and it causes a costly blind spot: your genuinely good work goes undiscovered, out-competed by worse products that were merely better explained. Marketing, done well, is the honest work of helping the right people find something valuable.