All articles

Software Engineering / 04 Sep 2026 / 9 min read

Separating Decisions from Side Effects

Business logic often becomes difficult to test for a simple reason: the code that decides what should happen is mixed with the code that makes it happen. A function reads the clock, queries storage, applies pricing rules, sends an email, and writes an audit record. To test one discount rule, the test must now arrange several unrelated dependencies. When a failure occurs, it is harder to tell whether the decision was wrong or an external operation failed.

Software Engineering Software Design

Software Engineering / 04 Sep 2026 / 7 min read

Separating Commands from Queries

A method named getBalance looks harmless. A developer may call it twice, use it while debugging, or add it to a log statement without expecting the program to change. If that method also clears pending adjustments, increments a counter, or refreshes state, those ordinary actions can alter behaviour. The underlying design problem is not simply a poor method name. Reading information and changing state have different consequences, yet one operation is doing both.

Software Engineering API Design

Software Engineering / 04 Sep 2026 / 10 min read

Separate Decisions from Side Effects

A function reads an order, checks inventory, chooses a shipping method, updates a record, sends an email, and writes a log entry. A small rule change arrives: express shipping is now allowed only when every item is in stock. The rule itself is simple. Testing it is not. To exercise the decision, a test may need a database, an inventory service, an email substitute, and careful setup for several unrelated operations.

Software Engineering Software Design

Cybersecurity / 04 Sep 2026 / 9 min read

Separate Cryptographic Keys by Purpose

Applications often need cryptographic keys for several jobs: encrypting stored data, authenticating messages, signing tokens, or protecting backups. It can be tempting to create one strong secret key and reuse it everywhere. That reduces the number of secrets to manage, but it also connects security boundaries that should remain independent. If the shared key is exposed, every use of that key may be affected at once. Reuse can also make permissions, rotation, incident response, and cryptographic assumptions harder to reason about.

Cybersecurity Cryptography

Tech / 04 Sep 2026 / 8 min read

Screen Timeout vs Auto-Lock: What Each Setting Does

You stop using a phone or laptop for a moment, and its screen goes dark. When you return, sometimes the device opens immediately. Other times it asks for a PIN, password, fingerprint, or another form of authentication. Those two outcomes reveal an important distinction: turning off the display and locking the device are separate actions. Many devices coordinate them closely, so they can feel like one feature, but they solve different problems.

Device Settings Smartphones

Cybersecurity / 04 Sep 2026 / 11 min read

Rotate Session Identifiers After Authentication

A web application often creates a session before a user signs in. The session may hold a shopping cart, a language preference, or state needed during an authentication flow. After login, it is tempting to keep the same session identifier and simply mark that session as authenticated. That creates a security problem if someone else already knows or influenced the pre-login identifier. Authentication has increased what the session is allowed to do, but the credential used to refer to that session has not changed. A previously low-value identifier may suddenly become a key to an authenticated account.

Cybersecurity Session Security

Cybersecurity / 04 Sep 2026 / 8 min read

Rotate Encryption Keys Without Losing Data

Encryption keys are long-lived security dependencies. A key may need replacement because its access policy changed, an operator left, a cryptographic policy changed, or there is reason to suspect exposure. The difficult part is not generating a new key. It is changing keys without making existing ciphertext unreadable or quietly continuing to depend on the old key forever. This process is called key rotation: introducing a new key for a defined cryptographic role and moving the system away from the old one in a controlled way.

Cybersecurity Encryption

Software Engineering / 04 Sep 2026 / 6 min read

Replacing Repeated Null Checks with a Null Object

Optional collaborators often begin with one harmless check. A service sends a notification only when a notifier is configured, so the code asks whether the notifier exists before calling it. Later, the same check appears in five methods, then twelve. The repeated condition is telling you something: absence has a defined behavior. In this case, “no notifier” means “do nothing when asked to notify.” The Null Object pattern represents that behavior with an object that follows the same interface as the real collaborator but performs the appropriate neutral action. This article shows how to recognize that situation, apply the pattern without hiding errors, and decide when a normal null check is still the clearer design.

Software Engineering Design Patterns

Software Engineering / 04 Sep 2026 / 8 min read

Replacing Long Parameter Lists with Parameter Objects

A function can become difficult to call correctly even when its implementation is simple. The problem often appears as a growing parameter list: several values travel together, callers must remember their order and meaning, and the same group is passed through multiple layers. One useful refactoring is a parameter object: a small type that groups parameters which belong to one concept. The goal is not to make a function signature shorter at any cost. The goal is to give related data a name, make invalid combinations harder to create, and give future changes a natural home.

Software Engineering Refactoring

Software Engineering / 04 Sep 2026 / 8 min read

Replacing Boolean Parameters with Explicit Operations

A boolean parameter can make an API compact while making each call harder to understand. Consider this call: save(document, true) What does true mean? Overwrite an existing document? Validate before saving? Publish immediately? The caller knows only if they remember the parameter definition or inspect the function.

Software Engineering API Design

Software Engineering / 04 Sep 2026 / 8 min read

Removing Temporal Coupling from APIs

Some APIs look simple because each method is simple. The difficulty appears only when you try to use them: configure() must run before connect(), connect() before start(), and stop() is valid only after startup succeeds. When correctness depends on operations happening in a particular order, the code has temporal coupling. The word temporal refers to time or sequence: one operation is valid only because another operation happened earlier. Temporal coupling is not automatically a design flaw. Many real processes have genuine ordering constraints. The engineering problem is hidden temporal coupling: callers must remember an important sequence that the API does not make clear or enforce.

Software Engineering API Design

Software Engineering / 04 Sep 2026 / 8 min read

Removing Hidden Temporal Coupling

Some code works only when its methods are called in the right order. The individual methods may look valid, yet swapping two calls or forgetting an earlier call produces an error much later. This is temporal coupling: one operation depends on another operation having happened earlier. The coupling is not automatically a design flaw. Opening a transaction before committing it is a real lifecycle constraint. The problem is hidden temporal coupling, where the API allows an invalid sequence and leaves callers to remember an undocumented rule.

Software Engineering Software Design

Software Engineering / 04 Sep 2026 / 9 min read

Remove Duplicated Knowledge, Not Similar Code

Developers often learn the DRY principle as “do not repeat yourself.” That shorthand can lead to the wrong refactoring: two blocks look similar, so they are merged into one abstraction. Later, the two cases evolve for different reasons, and the shared abstraction fills with flags and exceptions. The more useful idea is narrower: avoid having the same piece of knowledge represented independently in multiple places. That distinction changes how you refactor. Similar code is only a clue. The real question is whether the copies encode one decision that must stay consistent, or different decisions that merely happen to look alike today.

Software Engineering Code Quality

Software Engineering / 04 Sep 2026 / 8 min read

Reducing Change Amplification in Code

A requirement can sound small and still produce a surprisingly large patch. Add one order state, rename one business concept, or change one validation rule, and suddenly five modules, several tests, and a serializer all need coordinated edits. The problem is not simply that the codebase is large. It is change amplification: one conceptual change causes many implementation changes because knowledge about that concept is spread across the system. This article shows how to recognize change amplification, trace it back to duplicated knowledge, and reduce it without forcing unrelated code into one giant abstraction.

Software Engineering Software Design

Artificial Intelligence / 04 Sep 2026 / 8 min read

Reduce Training Memory with Gradient Checkpointing

Training a neural network can run out of accelerator memory even when the model parameters fit comfortably. The missing piece is often activations: intermediate values produced during the forward pass and retained because backpropagation needs them later. Gradient checkpointing, also called activation checkpointing, trades extra computation for lower activation memory. Instead of keeping every intermediate activation until the backward pass, training keeps selected checkpoints and recomputes missing forward values when their gradients are needed.

Artificial Intelligence Neural Networks

Cybersecurity / 04 Sep 2026 / 10 min read

Reduce Account Enumeration with Consistent Authentication Responses

A login form can reject every incorrect password and still reveal useful information about its users. If the application says Account not found for one email address and Wrong password for another, anyone who can submit login attempts can learn which address belongs to an account. That information leak is called account enumeration. The same problem can appear in password-reset, registration, invitation, and account-recovery flows. Even when the visible message is identical, differences in HTTP responses, redirects, response size, or processing time can reveal the same fact.

Cybersecurity Authentication

Linux / 04 Sep 2026 / 13 min read

Prevent Overlapping Linux Jobs with Advisory File Locks and flock

A scheduled job often looks harmless until two copies run at the same time. A backup takes longer than usual, a second timer fires, and both processes start writing the same output. A maintenance script overlaps with itself and launches duplicate work. A cache refresh runs concurrently and leaves partially coordinated state behind. The problem is not that Linux started the processes incorrectly. The problem is that the application needs a rule saying, “only one cooperating process may enter this critical section at a time.”

Linux Concurrency

Database / 04 Sep 2026 / 11 min read

Prevent Lost Updates with Optimistic Locking in SQL

Two users can read the same database row, make different changes, and both believe their update succeeded. If the second write silently replaces the first, the application has a lost update. This is easy to miss because each individual SQL statement can be valid. The bug appears only when multiple requests overlap in time. One practical way to prevent this is optimistic locking: let readers proceed without holding a database lock, but make every write prove that the row is still the version the writer originally read.

Database SQL

Cybersecurity / 04 Sep 2026 / 9 min read

Prevent Confused Deputy Problems with Explicit Authority

A service can enforce authentication correctly, hold only legitimate credentials, and still perform an action that the requester was never allowed to cause. This happens when a privileged component uses its own authority without preserving enough information about who asked for the action and what that requester may do. This class of mistake is called the confused deputy problem. The deputy is a component that has legitimate access to a resource. It becomes confused when it cannot distinguish an authorized use of that access from a request that merely causes it to exercise its privilege on someone else’s behalf.

Cybersecurity Access Control

Artificial Intelligence / 04 Sep 2026 / 9 min read

Perplexity for Language Model Evaluation

A language model can assign high probability to likely text and low probability to unlikely text, but developers still need a compact way to summarize that behavior across many tokens. Perplexity is one common metric for this job. Perplexity is useful when comparing probabilistic language models on the same evaluation data under compatible tokenization and scoring rules. It is much less useful as a general score for whether generated answers are correct, helpful, safe, or well written.

Artificial Intelligence LLM

Software Engineering / 04 Sep 2026 / 9 min read

Parse Input into Trusted Types

A common validation problem is not that a program forgets to check input. It is that the program checks the input, keeps the same weak representation, and then has to remember what was already proved. Suppose an order accepts a quantity as an integer. The boundary rejects zero and negative values, but every later function still receives an ordinary integer. Nothing in that representation distinguishes a checked quantity from 0, -3, or an integer created somewhere else. The validation happened, but the result of that validation was not captured.

Software Engineering Code Quality

Software Engineering / 04 Sep 2026 / 9 min read

Parse Boundary Data into Trusted Types

Validation often starts as a small check near the edge of a program. As the system grows, the same fact gets checked again in handlers, services, helpers, and background jobs because none of those places can tell whether the value they received has already been validated. The result is defensive code everywhere and uncertainty about what a function may safely assume. A useful design technique is to parse boundary data into a trusted type. Instead of checking a raw value and then continuing to pass that raw value around, convert it into a representation that can exist only after the required checks succeed. Core code receives that representation and can rely on the facts it expresses.

Software Engineering Software Design

Python / 04 Sep 2026 / 8 min read

Order Dependency-Driven Work in Python with graphlib.TopologicalSorter

Many automation tasks are not really lists. They are dependency graphs. A deployment may need a database migration before the API starts, while static assets can build independently. A data pipeline may need two source extracts before a join can run. A build system may have several targets that become runnable as soon as their prerequisites finish. If you encode this work as one hand-written sequence, you hide the real constraint: which tasks depend on which other tasks. That makes the sequence harder to change and can prevent independent work from running concurrently.

Python graphlib

Tech / 04 Sep 2026 / 8 min read

Optical vs Digital Zoom: What Changes in Your Phone Camera

Pinch outward in a phone camera app and the subject becomes larger on screen. That simple gesture can hide an important difference: sometimes the phone changes how the scene is captured, while other times it mainly enlarges a smaller part of an image it already has. These approaches are commonly described as optical zoom and digital zoom. The distinction matters because making a subject look larger is not the same as recording more detail about it.

Smartphones Cameras