All articles

Go / 10 Sep 2026 / 6 min read

Insert Iterator Pairs into Go Maps with maps.Insert

Sometimes a Go pipeline naturally produces key-value pairs, but the destination is a map you already have. Turning those pairs into a temporary map just to merge it adds a step that doesn’t help. Go 1.23 added maps.Insert for this case. It consumes an iter.Seq2[K, V] and writes each pair into an existing map. Existing keys are overwritten, unrelated entries stay in place, and the iterator can produce values lazily.

Go Maps

Software Engineering / 10 Sep 2026 / 9 min read

Information Hiding: Designing Modules Around Change

Information Hiding: Designing Modules Around Change A module can have a small API and still be difficult to change. The problem appears when callers know details they shouldn’t need to know: which storage format is used, how identifiers are assembled, which retry sequence is required, or what intermediate states exist inside a workflow. Once that knowledge escapes, an internal change becomes a coordinated change across the codebase. Information hiding is a design principle for preventing that spread. A module hides a design decision by giving other code a stable way to use the capability without depending on the decision itself. This article develops a practical way to recognize leaked decisions, choose useful module boundaries, and avoid interfaces that merely disguise the implementation.

Software Engineering Software Design

Software Engineering / 10 Sep 2026 / 9 min read

Information Hiding: Design Modules Around Change

Information Hiding: Design Modules Around Change A module can have private fields and still expose nearly every design decision it makes. If callers know which storage keys exist, how records are ordered, which retry sequence is used, or how an identifier is encoded, changing those decisions means changing the callers too. Information hiding is the design practice of keeping such decisions behind a boundary. The goal isn’t secrecy. The goal is to make a decision replaceable without forcing unrelated code to understand or change with it.

Software Engineering Software Design

Artificial Intelligence / 10 Sep 2026 / 11 min read

Improve LLM Fine-Tuning with Rejection Sampling

Improve LLM Fine-Tuning with Rejection Sampling Suppose you can tell a good model response from a bad one, but writing thousands of ideal responses by hand is expensive. A capable language model may already produce acceptable answers some of the time. The problem is that those answers are mixed with weaker ones. Rejection sampling fine-tuning turns that observation into a data-generation loop. For each prompt, generate several candidate responses, evaluate them, keep responses that satisfy a selection rule, and use the accepted prompt-response pairs for supervised fine-tuning. The method can concentrate training on behavior you want without requiring a human to author every target from scratch.

Artificial Intelligence Large Language Models

Software Engineering / 10 Sep 2026 / 8 min read

Functional Core, Imperative Shell for Testable Code

Functional Core, Imperative Shell for Testable Code A function that calculates a decision, reads the clock, queries a database, sends a message, and writes a log can be difficult to test for a simple reason: its business rules and its interactions with the outside world are tangled together. Testing one rule may require arranging several dependencies that have nothing to do with that rule. Functional core, imperative shell is a design approach for separating those concerns. The functional core contains deterministic decision-making: given the same explicit inputs, it produces the same result without performing external side effects. The imperative shell handles effects such as reading data, obtaining the current time, calling services, and persisting results.

Software Engineering Software Design

Software Engineering / 10 Sep 2026 / 9 min read

Functional Core, Imperative Shell for Managing Side Effects

Functional Core, Imperative Shell for Managing Side Effects Business logic is often easy to describe and hard to test because it sits between database reads, network calls, clocks, queues, and file writes. A pricing rule that should be a few comparisons can become tangled with fetching a customer, saving an order, and sending a notification. Functional core, imperative shell is a design approach for separating those concerns. The functional core makes decisions from explicit input values and returns values describing the result. The imperative shell obtains those inputs and performs the required side effects.

Software Engineering Software Design

Go / 10 Sep 2026 / 5 min read

Find Values and Insertion Points with slices.BinarySearch

When a Go slice is already sorted, scanning it from the beginning to find one value throws away useful information. slices.BinarySearch uses that ordering directly. It returns both an index and a found flag, and the index remains useful even when the target isn’t present. That second behavior is easy to overlook. slices.BinarySearch isn’t only a membership check; it also tells you where a missing value belongs if you want to preserve the slice’s sort order.

Go Slices

Go / 10 Sep 2026 / 4 min read

Find the First Matching Slice Element in Go with slices.IndexFunc

Searching a slice is easy when the element itself is comparable and you already know the exact value. Real programs often need something slightly different: the first queued job, the first expired token, or the first record whose normalized name matches some input. slices.IndexFunc handles that case directly. You provide a predicate, and it returns the index of the first element for which that predicate is true. If nothing matches, it returns -1.

Go Slices

Go / 10 Sep 2026 / 6 min read

Filter Go Slices in Place with slices.DeleteFunc

Filtering a slice often starts with a small loop: inspect each element, keep the ones you want, and return the shorter result. When changing the original backing array is acceptable, slices.DeleteFunc gives that operation a standard-library name and avoids a hand-written compaction loop. The useful detail is in “changing the original backing array.” slices.DeleteFunc isn’t a general-purpose immutable filter. It removes matching elements in place and returns the shortened slice, so it works best when the caller owns the input and no longer needs its old contents.

Go Slices

Go / 10 Sep 2026 / 5 min read

Filter Go Maps In Place with maps.DeleteFunc

Removing map entries by a condition is common when cleaning caches, pruning stale state, or dropping records that no longer belong in a working set. A for range loop with delete works, but when the operation is simply “delete every entry matching this predicate,” maps.DeleteFunc states that intent directly. The function mutates the map you pass to it. That makes it a good fit for owned, mutable state, but a poor fit when callers still need the original contents.

Go Maps

Artificial Intelligence / 10 Sep 2026 / 10 min read

Evaluate Knowledge Edits Before Trusting Model Updates

Changing one fact in a language model sounds simpler than retraining it. If a product name changes, an organization moves offices, or a fictional knowledge base is updated, knowledge editing aims to change a model’s behavior for that information without running broad training again. The hard part isn’t making one prompt produce the new answer. The hard part is knowing what else changed. A useful evaluation therefore asks more than “did the edit work?” It checks whether the new fact survives reasonable paraphrases, whether unrelated behavior stays stable, and whether the model can use the edited information when another answer depends on it. This article builds that evaluation model and shows how to turn it into a practical test suite.

Artificial Intelligence LLM

Cybersecurity / 10 Sep 2026 / 10 min read

Do Not Bind Web Sessions to IP Addresses

A stolen session cookie can let someone use an account without knowing the user’s password. That makes a simple defense sound attractive: remember the IP address used at login and reject the session whenever the address changes. The problem is that an IP address is usually a property of the user’s current network path, not a stable property of the user or device. Legitimate addresses change, while different people can share one address. Strict IP binding can therefore lock out real users without reliably stopping an attacker.

Cybersecurity Authentication

Artificial Intelligence / 10 Sep 2026 / 10 min read

Distill Sequence Models with Teacher-Generated Outputs

Distill Sequence Models with Teacher-Generated Outputs A large text generator may produce useful outputs but still be too expensive for the latency, memory, or throughput budget of a deployment. Training a smaller model on the original dataset is the obvious baseline, but it throws away information encoded in the larger model’s behavior. Sequence-level knowledge distillation offers another option: let a capable teacher generate target sequences, then train a smaller student to reproduce those sequences. The student learns from concrete examples of what the teacher tends to produce rather than only from the original human targets or from the teacher’s next-token probabilities.

Artificial Intelligence Machine Learning

Software Engineering / 10 Sep 2026 / 9 min read

Differential Testing for Behavior-Preserving Changes

Differential Testing for Behavior-Preserving Changes Replacing working code is risky when the requirement is “change the implementation, not the behavior.” A rewritten parser may accept a different edge case. A faster pricing engine may round one value differently. A new library may return the same records in a different order. Ordinary tests help, but they only cover cases and assertions someone thought to write. Differential testing adds another source of evidence: run the old and new implementations on the same inputs, compare their observable results, and investigate differences.

Software Engineering Testing

Software Engineering / 10 Sep 2026 / 10 min read

Designing Graceful Degradation for Partial Failures

Designing Graceful Degradation for Partial Failures A page needs product details, recommendations, reviews, and delivery estimates. The product service is healthy, but the recommendation service times out. Should the whole page fail? Sometimes yes. If the missing dependency is required to produce a correct result, failing the operation is the right behavior. But when the missing part is genuinely optional, turning one local failure into a complete outage throws away useful work.

Software Engineering Reliability

Cybersecurity / 10 Sep 2026 / 9 min read

Design Push MFA to Resist Approval Fatigue

A push notification can make multi-factor authentication feel effortless: enter a password, tap Approve on a registered device, and continue. The same convenience creates a problem when the approval prompt does not require the user to prove which login they are approving. If an attacker obtains a password and can repeatedly trigger MFA requests, the legitimate user may receive prompts they did not initiate. A tired, distracted, or confused user may eventually approve one. This is commonly called MFA fatigue or push fatigue.

Cybersecurity Authentication

Software Engineering / 10 Sep 2026 / 10 min read

Design by Contract: Make Assumptions Explicit

Design by Contract: Make Assumptions Explicit A function often depends on rules that its type signature doesn’t fully express. A withdrawal amount must be positive. A completed operation must leave the balance consistent. An object may require its reserved quantity to stay between zero and the quantity on hand. When those rules live only in developers’ heads, failures appear far from their cause. Design by Contract gives the rules names and assigns responsibility for them. The useful mental model is simple: the caller promises to meet the operation’s entry conditions, and the operation promises a valid result while preserving the object’s valid state.

Software Engineering Software Design

Cybersecurity / 10 Sep 2026 / 9 min read

Design Audit Logs That Remain Useful After Compromise

An application can record every error and still have little evidence when an account is abused. Ordinary operational logs answer questions such as “why did this request fail?” Security investigations need different facts: which identity changed an authentication factor, which administrator granted access, which object was affected, and whether the action succeeded. That is the job of an audit log: a durable record of security-relevant actions and decisions. A useful audit log helps investigators reconstruct events after an incident while limiting two risks of its own: attackers changing the evidence and sensitive data leaking through the log.

Cybersecurity Security Logging

Software Engineering / 10 Sep 2026 / 9 min read

Creating Seams to Test Hard-to-Change Code

Creating Seams to Test Hard-to-Change Code A method can contain a simple business rule and still be difficult to test. The difficulty often comes from everything attached to the rule: the current clock, a network client, a filesystem call, a global configuration object, or a constructor that creates its own dependencies. When rewriting the surrounding code would be risky, a seam can give you a smaller move. A seam is a place where you can change which behavior the code uses without changing the code that makes the business decision. In tests, that lets you replace an awkward dependency with controlled behavior.

Software Engineering Testing

Go / 10 Sep 2026 / 8 min read

Copy Go Maps with maps.Clone Without Sharing Top-Level State

Copying a Go map is easy to get subtly wrong. Assigning one map variable to another doesn’t duplicate the map, so a write through either variable changes the same underlying map. Since Go 1.21, the standard library’s maps.Clone function gives you a concise way to make a separate top-level map. There is one boundary worth understanding before using it: maps.Clone is a shallow clone. Adding, deleting, or replacing entries in the clone won’t change the original map, but nested maps, slices, pointers, and other reference-bearing values can still refer to the same underlying data.

Go Maps

Cybersecurity / 10 Sep 2026 / 10 min read

Consume One-Time Security Tokens Atomically

A password-reset link may be described as “single use”, yet two requests arriving almost together can both see the token as unused. If each request then continues independently, the application can perform a security-sensitive action twice even though its data model contains a used flag. This is a concurrency problem with security consequences. The same pattern can affect account invitations, email-verification links, recovery codes, approval links, and other credentials that are supposed to grant authority once.

Cybersecurity Authentication

Cybersecurity / 10 Sep 2026 / 11 min read

Constrain Server-Side URL Fetching to Prevent SSRF

Applications often fetch URLs supplied indirectly by users. A link-preview service retrieves a page, an image importer downloads an avatar, or a webhook tester sends a request to a configured endpoint. The feature may look like ordinary URL handling, but it gives the requester influence over a network connection made with the application’s identity and network access. If that influence is too broad, the application can become a route to destinations the requester could not reach directly. This class of weakness is server-side request forgery, usually shortened to SSRF.

Cybersecurity Secure Coding

Cybersecurity / 10 Sep 2026 / 10 min read

Confine Archive Extraction to Its Destination

Extracting an archive looks like a simple file operation: read each entry, join its name to an output directory, and write the result. The dangerous part is that an archive controls those entry names. If extraction code treats them as trusted relative paths, a crafted entry can make a write escape the directory chosen by the application. That failure is commonly called archive path traversal. It can turn an upload, package import, backup restore, or document-processing feature into an unintended filesystem write. The consequence depends on the extractor’s permissions: files outside the extraction area may be created or replaced, including files later consumed by other parts of the system.

Cybersecurity Secure Coding

Software Engineering / 10 Sep 2026 / 8 min read

Composed Method: Keep Code at One Level of Abstraction

Composed Method: Keep Code at One Level of Abstraction A method can be only thirty lines long and still be difficult to read. The problem often isn’t its length. It is that the method keeps changing altitude: one line describes a business step, the next manipulates a collection, then another formats a storage key, and then the code returns to business logic. The Composed Method pattern addresses that problem by making a method read as a sequence of operations at roughly the same level of abstraction. The top-level method explains what happens. Smaller methods hold the details of how each step happens.

Software Engineering Refactoring