Skip to content

Archive / page 83

All articles

Every practical article from the Nalar archive, newest first.

Tech 03 Sep 2026 7 min read

How QR Codes Store Information and Why They Still Scan When Damaged

QR codes appear on tickets, menus, product packaging, payment screens, Wi-Fi setup cards, and many other everyday objects. A phone can often point its camera at one and recover the information in a fraction of a second. Although a QR code looks like a random grid of black and white squares, its layout is highly structured. Some areas help a scanner locate and orient the symbol, while other areas contain encoded data and information that helps recover from errors.

Tech 03 Sep 2026 7 min read

How NFC Works on Phones and Why It Needs Such Short Range

Tapping a phone against a payment terminal, transit reader, accessory, or small electronic tag can trigger an action almost immediately. The technology behind many of these interactions is NFC, short for Near Field Communication. NFC is a wireless technology, but it behaves differently from Wi-Fi or Bluetooth. It is designed for communication across a very small distance, usually only a few centimetres. That short range is not simply a limitation. It is one of the characteristics that makes tap-based interactions practical.

Tech 03 Sep 2026 8 min read

How microSD Cards Expand Device Storage

A microSD card can add a surprising amount of storage to a small device. Phones, tablets, cameras, handheld game systems, dash cameras, and other electronics may use these tiny removable cards to hold photos, videos, downloads, maps, games, and other files. The basic idea is simple: a microSD card contains flash memory that keeps data even when power is removed. In practice, however, choosing and using one involves more than matching the physical shape. Capacity limits, file systems, speed ratings, workload requirements, and device support all affect whether a card will work well.

Tech 03 Sep 2026 8 min read

How GPS Finds Your Phone Without Mobile Data

A phone can often show your location even when mobile data is turned off. That can seem strange if you normally use GPS through a map app that downloads roads, traffic information, and search results from the internet. The key is that finding your position and downloading a map are separate jobs. Satellite navigation can calculate a position without an internet connection, while many of the services built around that position still need network access.

Tech 03 Sep 2026 8 min read

How Browser Cookies Help Websites Remember You

A website can remember that you signed in, keep products in a shopping cart, or preserve a language choice even though each page request is separate. One common mechanism behind that memory is the browser cookie. A cookie is a small piece of data that a website asks a browser to store and send back with later requests that match the cookie’s rules. The cookie does not need to contain everything the site knows about you. Often it contains only an identifier that lets the website find the relevant information on its own systems.

Tech Updated 15 Sep 2026 9 min read

How Bluetooth Multipoint Lets Headphones Use Two Devices

Using the same wireless headphones with a laptop and a phone can be awkward. Without the right feature, moving from a video call on one device to music on the other may mean disconnecting, opening Bluetooth settings, and reconnecting manually. Bluetooth multipoint is designed to reduce that friction. On supported headphones or earbuds, it allows one audio accessory to maintain Bluetooth connections with more than one source device at the same time. A common setup is a laptop for work and a phone for calls.

Software Engineering 03 Sep 2026 9 min read

Hide Design Decisions Behind Stable Interfaces

A module can have a small public API and still be difficult to change. The problem appears when callers know details they do not actually need: a file layout, a cache key format, a third-party response shape, a particular algorithm, or the order of internal steps. Once those details escape, changing an implementation becomes a multi-module change. Code that should have been independent must now move together. Information hiding is a design principle for preventing that spread. The idea is simple: identify decisions that are likely to change, keep those decisions inside one boundary, and expose an interface based on what callers need rather than how the work is currently done.

Cybersecurity 03 Sep 2026 10 min read

Harden Security Configuration with Secure Defaults

Many security failures do not require a broken cryptographic algorithm or a sophisticated exploit. A system can expose unnecessary services, leave a sensitive feature enabled, grant broader access than intended, or silently keep an old setting after the application changes. This is a secure configuration problem. The software may be capable of operating safely, but its deployed settings place it in a riskier state. A useful defensive mental model is simple: begin from a known secure baseline, make every relaxation intentional, and verify that the deployed system still matches that intent. This reduces the number of accidental paths from a normal installation to an exposed one.

Cybersecurity 03 Sep 2026 6 min read

Harden Authenticated Sessions Against Hijacking

Authentication does not end when a password, passkey, or second factor is accepted. After login, most applications represent the user’s authenticated state with a session credential. Anyone who obtains that credential may be able to act as the user without repeating the original authentication. Session security therefore depends on protecting the credential throughout its lifecycle: creation, transport, use, rotation, expiration, and revocation. Treat the session identifier as a credential A session identifier should be unpredictable and generated with a cryptographically secure random generator. It should not encode sequential database IDs, timestamps, usernames, or other values an attacker can infer.

Cybersecurity 03 Sep 2026 9 min read

Generate Security Tokens with Cryptographic Randomness

Many security features depend on a value that an attacker must not be able to guess. Password-reset links, email-verification links, invitation codes, session identifiers, and one-time capability URLs are common examples. If such a token is predictable, an attacker may not need to steal it. They may be able to guess a valid value instead. The defensive requirement is therefore stronger than “make the token look random.” A security token needs enough entropy, meaning uncertainty from the attacker’s point of view, and it needs to come from a generator designed for security-sensitive randomness.

Tech Updated 15 Sep 2026 8 min read

eSIM vs Physical SIM: What Changes for Phone Users

A phone needs a way to identify your mobile subscription when it connects to a carrier network. For many years, that job has been associated with a removable SIM card. Modern phones may also support an eSIM, which stores a carrier profile in hardware built into the device instead of relying on a removable card. The difference changes how a mobile plan is installed and moved, but it does not turn the phone into a different kind of network device. Calls, messages, and mobile data still depend on the carrier, plan, coverage, device compatibility, and network conditions.

Cybersecurity 03 Sep 2026 9 min read

Enforce Object-Level Authorization on Every Request

An application can authenticate a user correctly and still expose another user’s data. The failure often happens when an endpoint accepts a resource identifier, loads that resource, and assumes that knowing the identifier is enough to use it. It is not. A resource ID answers which object the client wants. Authorization must separately answer whether this actor may perform this action on that object. This article develops a practical mental model for object-level authorization, shows where checks belong, and explains how to avoid common gaps when applications grow beyond simple owner-only data.

Software Engineering 03 Sep 2026 10 min read

Directing Dependencies Toward Stable Code

A dependency can look harmless when it is introduced. A business rule calls a payment SDK directly, a reporting module knows the exact storage format, or an order workflow imports a concrete notification client. Each choice may save a small amount of code today. The cost appears later. When an external library, storage mechanism, or delivery channel changes, code that represents important business behaviour must change with it. Dependency direction is a way to reduce that coupling. The central idea is simple: code that expresses important, relatively stable policy should not have to know the details that are likely to change around it.

Software Engineering 03 Sep 2026 9 min read

Designing Modules Around Cohesion and Coupling

A codebase can be split into many files and still be difficult to change. A small feature may require edits in several modules, tests may need large fixtures, and one internal change may unexpectedly break distant code. The problem is often not the number of modules. It is where their boundaries are drawn. Two ideas are especially useful when evaluating those boundaries: cohesion and coupling. Cohesion asks whether the responsibilities inside a module belong together. Coupling asks how much one module depends on the details of another. Used together, they provide a practical way to decide where code should live and which dependencies deserve attention.

Software Engineering 03 Sep 2026 8 min read

Designing Invariants That Make Invalid States Hard to Represent

Many software defects are not caused by complicated algorithms. They happen because the program reaches a state that should never have been possible: an order has a negative quantity, a completed job has no completion time, or a configuration contains two options that cannot be enabled together. An invariant is a condition that must remain true for a particular object, module, or operation to be valid. Designing around invariants turns assumptions into enforceable rules. The result is usually less defensive code, clearer interfaces, and failures that occur closer to their cause.

Software Engineering 03 Sep 2026 12 min read

Designing for Localized Change

A small requirement can produce a surprisingly large code change. Suppose a product changes the rule for displaying customer names. The new rule sounds simple: show the preferred name when one exists, otherwise show the legal name. Yet implementing it requires edits in an API response mapper, an email formatter, an audit message, a report generator, and three tests that each reconstruct the same choice. The problem is not that five files changed. Some changes legitimately cross many files. The warning sign is that one decision had to be rediscovered and edited in several places.

Software Engineering 03 Sep 2026 8 min read

Designing Errors for Actionable Failures

Errors are part of a program’s interface. They tell callers that an operation could not produce its promised result, but useful error handling goes further: it preserves enough meaning for the caller to decide what to do next. Weak error handling tends to fail in two opposite ways. Some code hides failures by returning defaults, logging and continuing, or catching exceptions too broadly. Other code exposes every low-level detail directly, forcing callers to understand implementation choices that should have remained private.

Artificial Intelligence 03 Sep 2026 10 min read

Design Reliable LLM Tool Calls with Structured Outputs

Giving a language model access to tools changes what an AI application can do. Instead of only producing text, the model can request a database lookup, search a document index, calculate a value, or trigger an application operation. The difficult part is not exposing a function. It is deciding which responsibilities belong to the model and which must remain under application control. A useful mental model is: model proposes an action application validates the proposal application decides whether to execute it tool returns data model explains or uses the result This separation makes tool-calling systems easier to reason about. The model handles interpretation and selection. Deterministic application code handles authorization, validation, execution, and state changes.

Python 03 Sep 2026 9 min read

Design Managed Attributes in Python with property

Python code often starts with plain public attributes. That is usually a good default: order.total is simpler than a pair of trivial getter and setter methods when reading and writing the value needs no extra behavior. Requirements can change. A value may need validation, an attribute may become computed, or an existing public field may need to keep its interface while its internal representation changes. Python’s built-in property type lets a class place method logic behind normal attribute access.

Python 03 Sep 2026 11 min read

Design Hashable Python Objects Correctly

Python dictionaries and sets make lookups feel simple: give them a key or value, and they can usually find it quickly. That convenience depends on a contract that becomes important as soon as you create your own value-like classes. A dictionary key is not located by equality alone. Python first uses the object’s hash value to narrow the search, then uses equality to distinguish candidates that land in the same area of the hash table.

Cybersecurity 03 Sep 2026 5 min read

Design Backups for Security and Recovery

Backups are a security control, not only an operations convenience. They can limit the impact of ransomware, destructive mistakes, compromised administrator accounts, corrupted data, and failed deployments. A backup strategy is useful only when attackers cannot easily destroy it and the organization can reliably restore from it. Copying production data to another location is therefore only the beginning. Define what must be recoverable Start by identifying the systems and data that matter to recovery. This may include databases, uploaded files, configuration, encryption key material, infrastructure definitions, and other state that cannot simply be rebuilt from source control.

Cybersecurity 03 Sep 2026 10 min read

Design Actionable Security Alerts

Collecting security logs does not guarantee that anyone will notice an attack or dangerous failure. A system can record every authentication failure and privilege change yet still leave responders searching through millions of events after the damage is done. A security alert is a signal that selected activity may require investigation or action. The difficult part is not generating alerts. It is generating alerts that are timely, understandable, and reliable enough that responders know what to do next.

Cybersecurity 03 Sep 2026 11 min read

Design Account Recovery as an Authentication Boundary

A strong sign-in flow can be undermined by a weak recovery flow. Suppose an account requires a password and a phishing-resistant authenticator for normal sign-in. That protection matters only until a user loses the authenticator. If the recovery path replaces it after answering easily discovered personal questions or passing a much weaker check, an attacker can target recovery instead of the normal login. The consequence is straightforward: account recovery is another authentication path, not an administrative convenience. It must provide confidence appropriate to the account and to the access it restores.

Software Engineering 03 Sep 2026 10 min read

Dependency Injection Without a Container

Dependency injection is often introduced together with a framework or container. That can make a simple design idea look like infrastructure: register services, configure scopes, add annotations, and ask a runtime to assemble an object graph. The underlying technique is smaller. A component receives the collaborators it needs instead of constructing or locating them itself. Another part of the program decides which implementations to supply. For many applications, ordinary constructors and functions are enough. Manual dependency injection keeps object creation visible, makes required dependencies explicit, and avoids coupling application logic to a container API. A container can still be useful when the object graph becomes large or a framework owns object creation, but it is not a prerequisite for dependency injection.