All articles

Software Engineering / 05 Sep 2026 / 10 min read

Splitting Mixed Work into Explicit Phases

A function often starts with one job and gradually becomes a pipeline hidden inside a block of code. It reads raw input, interprets it, applies business rules, prepares parameters, performs an external action, and formats the result. Each step may be reasonable, but mixing them makes the whole function harder to understand and change. A useful response is Split Phase: separate work that happens for different reasons into explicit stages, and pass a meaningful result from one stage to the next.

Software Engineering Refactoring

Artificial Intelligence / 05 Sep 2026 / 12 min read

Split Conformal Classification for Prediction Sets

A classifier usually returns one label or a vector of scores. That is convenient when the application must choose one answer, but it hides an important distinction: some inputs strongly support one class, while others leave several classes plausible. Conformal prediction provides a way to expose that ambiguity. For classification, it can return a prediction set containing one or more labels instead of forcing every input into a single choice. With an appropriate calibration procedure and statistical assumptions, the method can target a long-run coverage level such as 90%: roughly speaking, the true label should appear in the prediction set for at least that proportion of future examples.

Artificial Intelligence Machine Learning

Cybersecurity / 05 Sep 2026 / 11 min read

Slow Down Automated Login Attacks

A password login endpoint has to accept attempts from people who sometimes mistype their passwords. The same property also gives automated clients a place to try many guesses. If the application processes every attempt at full speed, an attacker can repeatedly test passwords against one account or spread attempts across many accounts. A correct password hash does not solve this problem. Password hashing makes each password verification deliberately costly, but the server still has to decide how many online attempts it will accept. Without another control, the application may provide an attacker with a large number of guesses over time.

Cybersecurity Authentication

Tech / 05 Sep 2026 / 8 min read

Sleep vs Hibernate vs Shutdown: What Changes on a Laptop

Closing a laptop lid can make the computer appear to be off, yet opening it again may restore your work almost immediately. Choosing Shut down produces a different result, and some computers also offer hibernate. These states can look similar because the screen goes dark in each case. Underneath, however, they preserve your working session in different ways. That affects how much power the laptop continues to use, how quickly it can resume, and what happens if the battery runs out.

Laptops Power Management

Software Engineering / 05 Sep 2026 / 7 min read

Separating Decisions from Side Effects with a Functional Core

Business logic often becomes difficult to test for a reason that has little to do with the rules themselves. A function decides what should happen while also reading the clock, querying storage, calling a service, sending a message, and writing logs. To test one decision, you must arrange all of those surroundings. A functional core, imperative shell design separates those concerns. The functional core receives ordinary data and computes decisions without performing external side effects. The imperative shell gathers inputs, calls the core, and carries out the resulting actions.

Software Engineering Software Design

Cybersecurity / 05 Sep 2026 / 9 min read

Rotate Encryption Keys Without Losing Access to Existing Data

Encrypting sensitive data creates a long-term dependency that is easy to overlook: the application must retain the right decryption capability for as long as the ciphertext remains useful. Replacing an encryption key without planning for that dependency can make old data unreadable. Keeping one key forever avoids that immediate problem but makes future key changes harder and can increase the amount of data tied to one key. The practical solution is key versioning. Each ciphertext records which key version protects it. New encryption uses the current key, while decryption can temporarily use older versions for data that has not yet been migrated.

Cybersecurity Cryptography

Cybersecurity / 05 Sep 2026 / 8 min read

Review and Expire Privileged Access Grants

A permission can be correct when it is granted and dangerous six months later. A developer changes teams, a migration ends, a vendor contract closes, or an emergency exception is forgotten. The authorization system still sees a valid grant even though the business reason for it has disappeared. This is privilege accumulation: access grows over time because adding permissions is part of normal work while removing them is easy to miss. The practical defense is to treat privileged access as something with a lifecycle, not a permanent fact. After reading this article, you should be able to design grants that can be reviewed, expired, and removed without depending on someone remembering every old exception.

Cybersecurity Access Control

Cybersecurity / 05 Sep 2026 / 9 min read

Require Reauthentication Before Sensitive Account Changes

An authenticated session is evidence that a user authenticated at some earlier point. It is not proof that the legitimate account holder is still controlling the browser when a high-impact account change happens. That distinction matters when a session is left open on a shared device or its credential is exposed. A requester who can use the session may be able to change the account email, replace an authentication factor, or perform another action that makes later recovery harder. Ordinary session authentication alone gives the application no fresh signal before that change.

Cybersecurity Authentication

Cybersecurity / 05 Sep 2026 / 8 min read

Require Fresh Authentication for Sensitive Actions

A valid login session is often enough to read ordinary account data or continue routine work. It should not automatically be enough for every action the account can perform. If an attacker obtains an authenticated session, or a user leaves an unlocked session unattended, a long-lived session can turn a temporary opportunity into permission to change a password, replace a recovery method, reveal a sensitive secret, or perform another high-impact operation. Requiring fresh authentication for selected actions reduces that risk by asking the application to verify the user again close to the moment of the sensitive operation.

Cybersecurity Authentication

Software Engineering / 05 Sep 2026 / 9 min read

Replacing Type Conditionals with Polymorphism

A conditional is often the clearest way to express a small decision. Problems begin when the same type question spreads through a codebase. One function asks whether a notification is an email or SMS to format it. Another asks the same question to validate it. A third asks again to calculate delivery cost. Adding a new notification type then means finding and changing several unrelated switches. This is a useful signal for polymorphism: different implementations respond to the same operation according to their own behavior. The goal is not to remove every if or switch. The goal is to stop many callers from repeatedly deciding what an object is before they can decide what it does.

Software Engineering Refactoring

Software Engineering / 05 Sep 2026 / 9 min read

Replacing Systems in Slices with the Strangler Pattern

A system can be difficult to change without being possible to replace in one safe step. The old application may serve real traffic, contain years of business rules, and depend on behavior that nobody has fully documented. A complete rewrite asks the team to reproduce all of that correctly before users receive any value from the new system. The strangler pattern takes a different approach: replace the system one well-defined slice at a time while the old and new implementations coexist.

Software Engineering Architecture

Software Engineering / 05 Sep 2026 / 7 min read

Replacing Repeated Type Conditionals with Polymorphism

A type-based switch can be the simplest way to express a small rule. The trouble starts when the same distinction appears in several places. Pricing checks whether an order is standard or express. Delivery estimates check the same thing. Cancellation rules do too. Adding a new order type then means finding every branch that knows the list of types. The problem is not the switch syntax itself. The problem is distributed knowledge: several callers know which variants exist and which behavior belongs to each one.

Software Engineering Software Design

Software Engineering / 05 Sep 2026 / 7 min read

Replacing Repeated Null Checks with Null Objects

Optional collaborators often begin harmlessly. A service may accept an optional audit recorder, notification sink, or metrics collector. Then every operation that uses the collaborator grows the same check: if audit != null: audit.record("order_created", order.id) One check is easy to understand. Dozens of checks create a different problem: knowledge that the collaborator may be absent is scattered through code that should be focused on other work. A missed check can fail at runtime, while slightly different checks can produce inconsistent behavior.

Software Engineering Design Patterns

Software Engineering / 05 Sep 2026 / 10 min read

Replacing Primitive Values with Domain Types

Many programs represent important concepts with ordinary strings, numbers, and booleans. That is convenient at first. A customer ID is a string, an email address is a string, and a quantity is an integer, so using those primitive types seems sufficient. The trouble starts when values that have different meanings share the same representation. A function can receive a product ID where it expected a customer ID. Validation rules spread across callers. A number that means cents can be confused with one that means whole currency units. The compiler or runtime may see perfectly valid primitives even though the program has made a domain mistake.

Software Engineering Software Design

Software Engineering / 05 Sep 2026 / 10 min read

Replacing Primitive Data with Domain Types

Many bugs begin with a value that is technically valid for its programming-language type but invalid for the job it represents. A quantity is negative. A percentage is passed as 20 where another function expects 0.20. Two string arguments are swapped because both look identical to the type system. The problem is not that strings and numbers are poor types. They are useful building blocks. The problem appears when a primitive value has accumulated rules or meaning that the primitive cannot express.

Software Engineering Code Quality

Software Engineering / 05 Sep 2026 / 8 min read

Replacing Magic Values with Named Concepts

A literal value can be perfectly clear when it describes the mechanics of a calculation. index + 1 usually needs no explanation. But the same syntax becomes harder to understand when a value carries a business rule or engineering decision: if retries > 3, price * 0.85, or timeout = 30. The problem is not that numbers or strings appear in code. The problem is that some literals have meaning that the code does not name. These are often called magic values.

Software Engineering Refactoring

Software Engineering / 05 Sep 2026 / 9 min read

Replacing Boolean Flag Parameters with Explicit Operations

A boolean parameter looks harmless because it carries only two values. The problem is that those values often control two different behaviours while saying almost nothing at the call site. Consider set_access(user, true). Does true mean grant access, require approval, make access permanent, or enable logging? A developer has to remember the parameter name or inspect the function before the call becomes clear. This problem becomes more expensive when the flag selects different validation, side effects, or failure rules. One function then behaves like two operations hidden behind a small parameter.

Software Engineering API Design

Software Engineering / 05 Sep 2026 / 9 min read

Replace Query-Then-Act with Intention-Revealing Operations

An object can expose perfectly reasonable getters and still make a system difficult to change. The problem appears when callers repeatedly read those values, interpret them, and then decide which mutation is allowed. Suppose several parts of an application do this: if order.status == "pending" and order.paymentReceived: order.status = "confirmed" The caller is not merely using data. It knows the rule for confirming an order. If another caller needs the same behavior, that rule is likely to be copied. When the rule changes, every copy becomes a place that can disagree.

Software Engineering Software Design

Software Engineering / 05 Sep 2026 / 8 min read

Refactoring Tangled Methods with Method Objects

A long method is not automatically a design problem. Sometimes a calculation is easiest to understand when its steps stay together. Trouble starts when one method accumulates many temporary values, later steps depend on several earlier results, and extracting any part requires passing a long list of arguments. At that point, ordinary Extract Method refactoring can feel blocked by the method’s local state. A method object is one way through that problem: move the computation into a short-lived object, turn the important local variables into fields, and then extract parts of the computation into small methods on that object.

Software Engineering Refactoring

Software Engineering / 05 Sep 2026 / 8 min read

Reducing Object Graph Coupling with the Law of Demeter

A small change to an object model can cause surprising edits far away from the changed class. A developer moves an address under a customer profile, for example, and code in pricing, notifications, and reporting all breaks because each caller navigates the same chain of objects. The immediate problem looks like missing properties. The deeper problem is that those callers know the shape of an object graph they do not own.

Software Engineering Software Design

Software Engineering / 05 Sep 2026 / 10 min read

Reducing Change Amplification by Keeping Decisions Together

A small requirement can produce a surprisingly large patch. Changing one pricing rule might require edits in an API handler, a validator, a report formatter, three tests, and a scheduled job. None of the edits is difficult by itself, yet missing one can leave the system inconsistent. This is change amplification: one conceptual change requires modifications in many places. The practical problem is not the number of files alone. It is that knowledge about one decision is scattered, so developers must rediscover every place that encodes it whenever the decision changes.

Software Engineering Code Quality

Artificial Intelligence / 05 Sep 2026 / 10 min read

Reduce Transformer Padding with Length Bucketing

Transformer training often starts with a simple batching rule: shuffle the examples, take the next B sequences, and pad every sequence in the batch to the length of the longest one. The rule is correct, but it can waste substantial computation when sequence lengths vary widely. A batch containing a 900-token document and several 100-token documents must usually represent every sequence with 900 token positions. Attention masks prevent padding from acting like real input, but they do not necessarily make the padded positions free to process.

Artificial Intelligence Machine Learning

Artificial Intelligence / 05 Sep 2026 / 9 min read

Reduce LLM Decoding Latency with Speculative Decoding

Large language models generate text autoregressively: each new token depends on the tokens that came before it. That dependency makes ordinary decoding sequential. Even when a GPU has enough compute to process many token positions in parallel, the model normally discovers only one new token per decoding step. Speculative decoding tries to turn some of that sequential work into parallel verification. A faster draft model proposes several future tokens. The larger target model then scores those proposed positions together and decides which proposals can be accepted. When the draft predicts well, one expensive target-model pass can advance generation by multiple tokens.

Artificial Intelligence LLM

Cybersecurity / 05 Sep 2026 / 10 min read

Recheck Authorization at the Point of Use

An application can perform a correct authorization check and still allow an action that should no longer be permitted. The problem appears when the application checks authority, waits or performs other work, and only later changes protected state. During that gap, the facts that justified the decision can change. For example, a worker may confirm that a user can modify a project, queue the requested change, and apply it several seconds later. If the user’s project access is revoked before the worker runs, using the earlier decision can let revoked authority survive longer than intended.

Cybersecurity Access Control