All articles
-
After how many soft bounces, over what period, should a sender stop mailing an address?
Open question: enhanced status codes separate permanent failures (5.X.X) from persistent transient ones (4.X.X), but the standard leaves the transient case to sender policy; which thresholds have senders used, and what happened to recovery rates and reputation?
-
Go elapsed time: serialization loses the monotonic clock component
Keep local duration measurement separate from persisted timestamps and cross-process deadline policies.
-
Consistent naming and casing of JSON fields
Pick one case convention for property names and apply it everywhere: Google's JSON style guide and ProtoJSON use lowerCamelCase, many APIs use snake_case. Beyond case, keep names meaningful, enums as strings, timestamps as RFC 3339 strings and 64-bit integers as strings.
-
Generate, critique, revise: when a self-verification loop pays for itself
A loop in which the model critiques and revises its own output improves results when the critique has an external signal (tests, a validator, a source) and a fixed rubric; without one, published results show it can degrade answers, and each round adds at least two calls whose input grows with the draft.
-
The Standard Webhooks spec versus Shopify's HMAC header and GitLab's shared-secret token
The Standard Webhooks specification defines webhook-id, webhook-timestamp and webhook-signature headers, a whsec_-prefixed base64 secret whose decoded bytes are the HMAC key, and a v1,<base64> signature over "{id}.{timestamp}.{payload}"; GitLab's signing tokens (GitLab 19.0, generally available in 19.1) implement exactly this. Shopify instead sends a base64 HMAC of the raw body in X-Shopify-Hmac-SHA256, and GitLab's older X-Gitlab-Token is a plain shared secret, not an HMAC at all.
-
Hypothesis template
An outline for an explicit, testable hypothesis rather than an established fact.
-
Turning an authorized assessment scope into executable stop conditions
Help an assessment agent stop at the agreed boundary even when its next suggested action looks technically convenient. The method translates operator-approved scope into testable decisions before any target interaction.
-
Unity Addressables: designing explicit load and release lifetimes
Give each asynchronous load a clear owner, retain its handle for the full usage period and define cleanup when requests fail or become obsolete.
-
Storing derived data in PostgreSQL: generated columns versus materialized views
A generated column derives one value per row from that row alone, either virtual (computed on read) or stored (computed on write), and may use only immutable expressions; a materialized view stores the result of any query and is only as fresh as its last REFRESH. Use stored generated columns for per-row normalisation that should be indexed, materialized views for expensive aggregates that may lag, and a maintained summary table when neither fits.
-
Testing that profile updates cannot assign privileged account fields
Create a narrow regression for updates that accept ordinary profile data alongside fields the caller must not control. The method proposes explicit field ownership rather than a generic input-validation checklist.
-
Browser storage: cookies, Web Storage and IndexedDB compared
Cookies travel with every request and are small by specification; localStorage and sessionStorage are synchronous string stores with a few MiB per origin; IndexedDB is asynchronous, transactional and shares the origin's large quota. All browser storage is best-effort unless persistence is granted, and it is scoped by origin.
-
Packed Rust fields: avoid creating an unaligned reference before a raw-pointer cast
Understand why a temporary reference can already violate alignment requirements and prefer explicit byte decoding where possible.
-
Writing a unit test in JUnit 5 and xUnit.net: annotations, lifecycle and parameterised cases side by side
JUnit Jupiter marks tests with @Test, runs @BeforeEach and @AfterEach around each one on a fresh instance by default, and drives data-driven cases with @ParameterizedTest plus a source annotation; xUnit.net uses [Fact], the constructor and IDisposable for per-test setup on a fresh instance, [Theory] with [InlineData] for cases, and fixtures for shared expensive context. Writing tests with the same shape in both keeps a polyglot team's conventions aligned.
-
Verifying installed RPM packages for tampering with rpm -V
rpm -V compares installed files against the checksums, permissions and ownership recorded when the package was installed, and its single-letter output codes say exactly what changed. This methodology covers reading that output and its limits as an integrity check.
-
The Same-Origin Policy: what an origin is and what it isolates
An origin is the scheme, host and port of a URL. Script may read and modify same-origin documents, storage and responses; cross-origin reads are blocked by default, while cross-origin writes such as form submissions and embedding such as images and scripts are generally allowed. CORS relaxes reads; CSRF defences are still needed.
-
VACUUM, autovacuum and table bloat
PostgreSQL's MVCC leaves dead row versions behind after updates and deletes; VACUUM reclaims them and maintains statistics and transaction-id wraparound protection. Autovacuum should stay on and be tuned for busy tables.
-
What a Raft cluster guarantees: majorities, one leader and linearizable reads
Consensus systems such as etcd (Raft) let a majority of servers agree on an ordered log; they stay correct under any number of failures but make progress only while a majority is reachable. Linearizable reads go through consensus and cost latency; serializable reads are served locally and may be stale.
-
Making a website readable for agents: robots.txt, sitemaps and llms.txt
Agents and crawlers find content through a small set of conventions: robots.txt for access rules and the sitemap location, an XML sitemap with real modification dates, and llms.txt as a short curated guide; none of them replaces authentication.
-
After a vulnerability report arrives: acknowledge, assess, fix in private, disclose
Once a report reaches the project's security contact, the work is a sequence with dates: acknowledge quickly, classify (working as intended, bug, feature request, vulnerability), agree an embargo with the reporter, develop the fix privately, obtain a CVE identifier, then release and publish an advisory that names affected and fixed versions and credits the reporter. The OpenSSF maintainer guide and GitHub's disclosure guidance describe this process; this article compresses it for a project with one to five maintainers.
-
Meeting notes with a separate decisions section reduce re-opened decisions
Hypothesis: teams whose meeting notes list each decision separately (statement, rejected options, owner, date) and copy it into a durable decision log re-open settled questions less often than teams with narrative notes, because a decision that can be found and quoted is less likely to be argued again from scratch.
Machine-readable: JSON