Validation

Go / 12 Sep 2026 / 5 min read

Check Custom Slice Order in Go with slices.IsSortedFunc

Code that depends on binary search, ordered output, or merge-style processing often assumes a slice is already sorted. For built-in ordered values, slices.IsSorted can check that assumption. Structs and domain-specific orderings need a comparator, which is where slices.IsSortedFunc fits. The function doesn’t rearrange anything. It answers a narrower question: does this slice already follow the order described by this comparator? Check a struct slice by one field slices.IsSortedFunc accepts a slice and a comparison function:

Go Slices

Software Engineering / 10 Sep 2026 / 8 min read

Parse at Boundaries to Protect Domain Invariants

Parse at Boundaries to Protect Domain Invariants A request arrives with a string that is supposed to be an order quantity. One function checks that the string contains a number. Another checks that the number is positive. A third assumes both checks already happened. Months later, a new caller reaches the third function directly and passes zero. The problem isn’t simply missing validation. The program keeps carrying a weak representation after it already knows something stronger about the value.

Software Engineering Software Design

Software Engineering / 09 Sep 2026 / 9 min read

Turning Raw Input into Trusted Domain Values

A value often enters a program as a string, number, or loosely structured object and then travels through several layers. If every layer must ask whether that value is empty, malformed, or outside an allowed range, validation logic spreads through the codebase. Some callers repeat the checks, some forget them, and others quietly make different assumptions. A useful alternative is to treat external input as untrusted representation and convert it at a boundary into a value that represents a domain fact. After that conversion succeeds, downstream code can rely on the guarantees provided by the new value instead of repeatedly validating the original representation.

Software Engineering Software Design

Software Engineering / 08 Sep 2026 / 9 min read

Turning Validation into Trusted Data

A request enters an application with an email address, a quantity, and a delivery method. The request handler validates all three fields. Later, the pricing code checks the quantity again. The notification code checks the email again. A background job checks the delivery method again. The system has validation, but developers still cannot tell which values are safe to use without checking them first. A more useful design goal is to make validation change what the program knows about the data. Unchecked input crosses a boundary, validation establishes specific facts, and successful validation produces a representation that preserves those facts. Code after that boundary can then rely on the representation instead of repeatedly rediscovering the same conditions.

Software Engineering Software Design

Software Engineering / 08 Sep 2026 / 8 min read

Parse Inputs into Trusted Data at System Boundaries

Input validation often begins as a few sensible checks and slowly spreads through a codebase. A controller checks that an amount is positive. A service checks it again. A helper receives the same primitive value and checks it a third time because it cannot tell whether the earlier checks ran. The problem is not that validation is useless. The problem is that the program keeps carrying data in a form that does not record what has already been established.

Software Engineering Software Design

Software Engineering / 07 Sep 2026 / 9 min read

Designing Strict Input Contracts

Being tolerant of imperfect input can look helpful. A parser silently fixes an invalid value, an API treats an unknown option as a default, or a service accepts several spellings for the same field. The immediate caller succeeds instead of receiving an error. The cost often appears later. Once clients discover that invalid input is accepted, they may depend on that behavior. Tightening validation then becomes a compatibility change, and different implementations may interpret the same malformed input differently.

Software Engineering API Design

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

Software Engineering / 03 Sep 2026 / 8 min read

Validating at Boundaries to Contain Invalid Data

Many software failures begin far from the place where they are eventually noticed. A malformed value enters through an API, configuration file, message, command, or user action. The program accepts it, passes it through several layers, and fails later when some unrelated operation assumes the value is valid. By then, the original cause is harder to see. A useful design principle is to validate data at the boundary where it enters a trusted part of the system. A boundary is any point where code receives information whose assumptions it does not yet control. The goal is not to scatter checks everywhere. It is to turn uncertain input into either a known-valid value or an explicit failure before the rest of the program relies on it.

Software Engineering Validation

Python / 02 Sep 2026 / 9 min read

Python Descriptors: Reusable Attribute Behavior Without Magic

Python properties are useful when one class needs a managed attribute. When the same attribute behavior must be reused across many fields or classes, repeating nearly identical properties becomes harder to maintain. Descriptors provide the protocol underneath properties, bound methods, classmethod, staticmethod, and other familiar Python features. A descriptor is an object stored on a class that can participate in reading, writing, or deleting an attribute. Descriptors are powerful because they integrate with normal dotted access such as obj.width. They are also easy to misuse if you do not understand where descriptor instances live, how values should be stored, and which lookup rules Python applies.

Python Descriptors

Artificial Intelligence / 01 Sep 2026 / 5 min read

Validate LLM Output with Structured Contracts

Large language models are useful when software needs to turn ambiguous text into a structured decision, extraction, or plan. The dangerous shortcut is to treat a model response as if it were already trusted application data. Even when a provider can constrain output to JSON or a schema, the result can still be semantically wrong: a date can be impossible, an identifier can refer to a nonexistent record, or a supposedly positive amount can be negative. Reliable integrations therefore need a contract boundary between model output and the rest of the system.

Artificial Intelligence LLM

Web Development / Updated 02 Sep 2025 / 3 min read

Data Validation in Laravel: A Complete Developer Guide

Validation is an important boundary in web applications. It ensures incoming data has the shape and constraints your application expects before that data reaches business logic or persistence. Laravel provides several validation APIs, from quick controller validation to reusable Form Request classes and custom rules. 1. Basic Validation For small request handlers, call validate() on the request: use Illuminate\Http\Request; public function store(Request $request) { $validatedData = $request->validate([ 'name' => ['required', 'string', 'max:255'], 'email' => ['required', 'email', 'unique:users,email'], 'password' => ['required', 'string', 'min:8', 'confirmed'], ]); // Use $validatedData rather than the entire request payload. } For a normal browser request, Laravel redirects back with validation errors in the session. For requests expecting JSON, Laravel returns a validation error response, normally with HTTP status 422.

Laravel Validation

Go / Updated 02 Sep 2025 / 2 min read

Validate User Input in a Go Web App with Gin

Input validation is one of the first defenses a web application has against malformed, incomplete, or unexpected data. Validation should run before business logic writes data to a database or triggers other side effects. This example uses Gin with go-playground/validator to validate a simple registration request. Project Structure project/ ├── main.go └── utils/ └── validation.go 1. Set Up Gin Create main.go:

Golang Validation

Go / Updated 02 Sep 2025 / 2 min read

Implement Validation in a Go Web App with Gin

Input validation is an important part of any web application. It lets the server reject malformed or incomplete data before business logic runs. This tutorial builds a small API with Gin and uses go-playground/validator for declarative validation rules. Project Structure project/ ├── main.go └── utils/ └── validation.go 1. Create the Gin Application Create main.go with a /register endpoint:

Golang Validation