Search
30 results for “decoder”
Search results
JWT Decoder
Decode a JWT header and payload; runs entirely in your browser, the signature is not verified since no secret is available client-side.
Why does data written inside a container disappear when the container is removed?
Anything a container writes lands in its own writable layer, which is deleted along with the container by `docker rm`. That is deliberate; it is what makes containers disposable and reproducible, a fresh container from the same image always starts from the same known state. Anything that actually needs to survive a container's lifecycle (a database's data files, uploaded assets) has to live outside that writable layer, in a named volume or a bind mount, which Docker mounts into the container at a chosen path but manages independently of the container itself.
Why does GitOps improve auditability compared to engineers running kubectl or terraform apply directly?
Every change to cluster state has to go through a Git commit, which means it inherits Git's existing history, authorship, and (if branch protection is configured) pull-request review, automatically. Direct `kubectl apply` access leaves no equivalent trail: two changes with the same effect are indistinguishable, there's no required review step, and reconstructing "who changed what and why" after an incident means digging through cluster event logs instead of reading a linear, reviewed commit history.
Why does simply including a tool definition in a request add cost even on a turn where the model never actually calls it?
Every tool's name, description, and input schema in the `tools` parameter counts as real input tokens on every single request, and using tools at all triggers an additional fixed system-prompt token overhead that varies by model, regardless of whether the model ends up calling any tool that turn. This means a large library of rarely-used tool definitions has a real, continuous token cost across every request that includes them, which is exactly why techniques like on-demand tool discovery (only loading the tool definitions actually relevant to the current task) exist as a mitigation for applications with many available tools.
What do LCP, INP, and CLS each measure, and why are all three needed instead of one overall "speed" number?
LCP (Largest Contentful Paint) measures loading performance, specifically how quickly the largest visible element renders, "good" is 2.5 seconds or less. INP (Interaction to Next Paint) measures interactivity/responsiveness, the delay between a user interaction and the browser's next visual response, "good" is 200 milliseconds or less. CLS (Cumulative Layout Shift) measures visual stability, how much content unexpectedly shifts around during the page's lifecycle, "good" is a score of 0.1 or less. A single overall number couldn't distinguish a page that loads fast but jumps around from one that's stable but slow to interact with, three separate metrics are needed because loading, interactivity, and stability are genuinely different failure modes.
What is the default Docker network driver and how does container-to-container communication work on it?
The default is the bridge driver, Docker creates a private virtual network on the host, and each container gets its own network namespace with a virtual ethernet interface connected to that bridge. Containers on the same user-defined bridge network can reach each other by container name, because Docker runs an embedded DNS server that resolves container names to their internal IPs on that network. Containers on the default (unnamed) bridge network do not get this automatic DNS resolution, only user-defined bridge networks provide it.
What is the difference between ss and the older netstat command, and why would you reach for ss first?
Both report socket/connection information, but ss reads directly from kernel data structures and can display considerably more TCP and socket state detail than netstat, including fine-grained state groupings like every "connected" state (everything except listening and closed) or every "synchronized" state, which makes targeted filtering much easier. netstat has been effectively superseded across current Linux distributions, and ss is the tool actively maintained as part of the iproute2 suite alongside ip, which is why it is the modern default for socket inspection rather than a mere alternative.
Why does using an array index as a list item's key cause state to attach to the wrong item once the list is reordered, and what's the fix?
With `key={i}`, React tracks each item's state by its position in the array, not by which real-world item it represents, so after reversing a list, the state that was originally at index 0 (say, an "expanded" toggle on the first item) stays at index 0 and now renders alongside whatever item ended up there after the reorder, not the original item it belonged to. The fix is using a stable, unique identifier from the actual data, `key={contact.id}`, so React can match each item to its correct state across renders regardless of how the list is reordered, added to, or filtered, rather than relying on a position that can shift under the data.
How to Install Active Directory Domain Services (AD DS) on Windows Server using Hyper-V (Step-by-Step Guide)
Active Directory Domain Services (AD DS) remains one of the most essential building blocks in enterprise IT. Whether you're managing on‑prem infrastructure, hybrid cloud environments, or lab setups, understanding how to deploy and configure AD DS is a core skill for any cloud infrastructure or syst…
Why does Docker's official build guidance recommend running as a non-root user inside a container, and why not just use sudo when root is needed?
Running as root inside a container means that a successful application-level compromise (a code-execution vulnerability, an unsafely deserialized payload) hands the attacker root inside that container immediately, with no privilege-escalation step required, and depending on the container runtime's configuration, root inside a container can sometimes be leveraged toward the host. Creating a dedicated non-root user via `USER` in the Dockerfile means a compromise still has to escalate privileges to do serious damage. `sudo` is specifically discouraged in Docker's own guidance because of its unpredictable TTY and signal-forwarding behavior inside a container, not because privilege separation itself is unnecessary.
Why does using a monotonically increasing field (a sequential ID, a timestamp) as a shard key concentrate all new writes onto one shard, even with range-based sharding across many shards?
With range-based sharding, chunks are assigned contiguous ranges of shard-key values, and a monotonically increasing key means every new document's value is higher than every previously inserted one, so all new inserts land in whatever chunk currently owns the highest range, which lives on one specific shard. Every other shard, holding older, lower-valued ranges, receives none of the new write traffic at all, the exact "hot shard" problem, all insert load concentrated on a single shard regardless of how many total shards the cluster has.
A transaction under Repeatable Read isolation fails with "could not serialize access due to concurrent update." What actually happened, and what is the application expected to do?
Repeatable Read uses snapshot isolation, the transaction sees a consistent snapshot from its own start, but if it then tries to update a row that another, concurrently-committed transaction already modified, PostgreSQL detects the conflict and aborts the transaction with a serialization failure rather than silently applying an update based on stale data. This is not an application bug, it is Repeatable Read (and Serializable) working as designed, both isolation levels explicitly require the application to catch this specific error and retry the transaction from the beginning, trading the guarantee of not overwriting concurrent changes for the operational cost of occasional automatic retries.
Does React mutate the DOM during the render step, and if not, when does the actual DOM update happen?
No. Rendering is a pure calculation, React calls component functions to figure out what the new JSX should be and diffs it against the previous render, but no DOM node is touched during this step. The actual DOM update happens in a separate commit step afterward, where React applies only the minimal necessary changes based on what actually differs from the previous render, appending everything on the very first render, but patching selectively on every re-render after that. This separation is why an uncontrolled `<input>`'s typed value survives a re-render of its parent: React only touches DOM nodes that actually changed, and leaves everything else alone.
What does it mean for a secret to be "dynamic" or "short-lived," and why does that reduce risk compared to a long-lived static credential?
A dynamic secret is issued on demand, scoped to a single application instance or session, and expires automatically after a defined lease, a database credential minted when a service starts and revoked automatically when it stops, rather than a password typed in once and left valid indefinitely. If a short-lived secret leaks, its usefulness to an attacker is bounded by its remaining lease time, often minutes, instead of remaining valid until someone notices and manually rotates it. This is the same underlying idea as preferring IAM roles over long-lived access keys in a cloud provider, temporary credentials shrink the blast radius of a leak by construction, not by better hiding the secret.
A banking system typically favors CP behavior during a partition, while a chat application typically favors AP. What does each system actually do differently when a partition occurs, and why does the choice fit each use case?
A CP system, during a partition, pauses or rejects requests that can't be guaranteed consistent, a bank stopping a transfer rather than risking two nodes independently approving withdrawals against the same balance, since a duplicated or lost transaction is a correctness failure worse than a temporary outage. An AP system keeps responding during the partition, accepting the risk of temporarily inconsistent state, a chat app still accepting and displaying messages on both sides of a network split, reconciling them once the partition heals, because staying available and eventually consistent matters more to users than every message reappearing everywhere in a strict, immediate order.
If a microtask itself queues another microtask while it's running, does that new microtask wait for the next event loop iteration, or does it still run before the next macrotask?
It still runs before the next macrotask. The rule isn't "run the microtasks that were queued when this iteration started", it's "drain the microtask queue completely," and if executing a microtask adds another one, that new one is still part of the queue being drained. This means a chain of microtasks that keep scheduling more microtasks can, in principle, starve the event loop from ever reaching the next macrotask (a real, documented way to accidentally block timers and rendering), which is different from a single flat batch of microtasks all queued up front.
What are the five stages of the browser rendering pipeline, and which ones does a change to a property like width actually have to go through?
The pipeline runs JavaScript, Style calculation, Layout, Paint, and Composite, in that order. Changing a property that affects geometry, `width`, `height`, `position`, forces the browser through every stage: layout has to be recalculated (since the element's size or position changed), then paint (since pixels changed), then composite. That full path is why layout-affecting properties are the most expensive to animate, every frame re-runs the whole pipeline, not just a cheap final step.
What is the difference between continuous integration, continuous delivery, and continuous deployment?
Continuous integration means every code change is automatically built and tested against the main branch frequently; the goal is catching integration problems within minutes, not weeks. Continuous delivery extends that so every change that passes CI is automatically packaged into a release-ready artifact, though a human still decides when to actually deploy it. Continuous deployment goes one step further and removes that human gate, every change that passes all automated checks is deployed to production automatically. The three form a spectrum of increasing automation, and most teams stop at continuous delivery rather than full continuous deployment for anything customer-facing.
What does the principle of least privilege mean in practice, and why is it hard to maintain over time?
Least privilege means granting an identity only the specific permissions it needs to do its job, nothing broader "to be safe" or "to save time." It's hard to maintain because permissions tend to accumulate, someone gets a broad role to unblock a one-time task and it's never revoked, or a service starts with wildcard permissions during initial development and nobody narrows them before shipping. Maintaining least privilege requires ongoing review (access audits, unused-permission detection), not just a careful initial setup, because the natural drift over time is always toward more access, not less.
How does consistent hashing (a ring hash) avoid that near-total remapping problem?
Instead of computing `hash(key) % N`, both hosts and keys are hashed onto positions on a fixed conceptual ring (typically the hash function's full output range), and each key is assigned to the next host found by walking clockwise from the key's position. Removing a host only affects the keys that were mapped to that specific host's section of the ring, they get reassigned to the next host further along, while every other key on the ring, owned by a different host's section entirely, is completely unaffected. For a ring hash across N hosts, adding or removing one host affects only about 1/N of the total keys, not nearly all of them.
What does a container image scanner actually check, and how does it know an image is vulnerable?
A scanner builds a software bill of materials (SBOM) for the image, an inventory of every OS package and application dependency baked into its layers, then matches that inventory against a continuously updated vulnerability database. A match means a known CVE affects a specific version of a package present in the image; the scanner doesn't analyze the application's own logic, it identifies known-vulnerable versions of things the image happens to include, which is why keeping the dependency and base-image inventory small and current matters as much as running the scanner at all.
PostgreSQL detects a deadlock between two transactions. What does it actually do, and can you predict which transaction survives?
PostgreSQL automatically detects the circular wait (a deadlock) and resolves it by aborting one of the involved transactions, letting the other(s) proceed. The documentation is explicit that which transaction gets aborted is difficult to predict and shouldn't be relied upon, there is no guarantee it's the "smaller" transaction, the one that started the wait, or any other predictable rule. Applications need to handle a deadlock-abort the same way they'd handle a serialization failure: catch it and retry the aborted transaction, rather than assuming a specific transaction will always be the one sacrificed.
What is the difference between the bridge and host network drivers?
With the bridge driver (the default), a container gets its own isolated network namespace and IP address, and ports must be explicitly published to be reachable from the host. With the host driver, the container shares the host's network namespace directly, no isolation, no port publishing needed, the container's ports are the host's ports. Host networking is faster (no NAT/bridge overhead) but sacrifices network isolation, so it is used selectively, not as a default.
What do the three digits in a chmod octal mode like 644 or 755 actually mean, and what does a leading fourth digit add?
Each of the three digits is a sum of read (4), write (2), and execute (1), in order for the owner, the group, and everyone else; 644 means the owner gets read+write (4+2), while group and others get read-only (4). 755 means the owner gets read+write+execute (4+2+1), and group/others get read+execute (4+1), the common mode for an executable or a directory that others need to traverse. An optional leading fourth digit sets setuid (4), setgid (2), and the sticky bit (1); setuid/setgid make a program run with its owner's or group's privileges rather than the caller's, and the sticky bit on a directory (classically 1777 on /tmp) restricts file deletion to each file's own owner even though the directory itself is world-writable.
What is the practical difference between ps -ef and ps aux, and why do they show different columns for the same processes?
`-ef` is UNIX-style syntax and `aux` is BSD-style syntax for the same underlying command, and they weren't designed as one consistent interface; mixing them can even be ambiguous depending on other options used. The manual is explicit that BSD-style options change the default output to include process state (STAT) and full command arguments (COMMAND) instead of just the executable name, and BSD-style selection also defaults to showing every process the invoking user owns across all terminals, while UNIX-style selection defaults to processes on the current terminal only. Neither is "more correct," they're two different historical option conventions layered onto the same command, which is why picking one and being consistent about it matters more than which one.
Why does calling a blocking function inside an async function defeat the purpose of using asyncio?
A blocking call (synchronous file I/O, a synchronous HTTP request, `time.sleep`) occupies the single thread the event loop runs on, and unlike `await`, it does not yield control back, the entire event loop is frozen for the duration of that blocking call, so every other coroutine that could otherwise be making progress is stalled too. This is why async code requires async-compatible libraries throughout the I/O path; a single accidental blocking call anywhere in a hot path can silently serialize what was supposed to be concurrent work, and the bug often doesn't show up until real concurrent load exposes it.
Why does Python use indentation instead of braces to define code blocks, and what problem does this create?
Python uses indentation as syntax specifically to force a consistent visual structure, code that looks nested is nested, with no possibility of a brace mismatch making the visual and actual structure disagree, a real class of bugs in brace-delimited languages. The trade-off is that whitespace becomes semantically meaningful: mixing tabs and spaces, or an accidentally misaligned line, is a syntax error (or worse, silently changes which block a line belongs to) rather than a cosmetic issue. Python 3 disallows mixing tabs and spaces in the same file specifically to prevent the silent version of this problem.
Why does the choice between WSGI and ASGI matter when picking a Python web framework?
WSGI (Web Server Gateway Interface) is the traditional, synchronous interface between Python web applications and servers, one request is handled by one worker thread/process at a time, blocking for its duration. ASGI (Asynchronous Server Gateway Interface) extends that to support async request handling and other async protocols (WebSockets), letting a single worker handle many concurrent requests while they're waiting on I/O, the same underlying model as asyncio generally. Flask and Django historically are WSGI (Django has gained ASGI support); FastAPI is ASGI-native. The choice matters because it determines whether the framework can actually benefit from async I/O concurrency, or whether it's fundamentally a one-request-per-worker model regardless of async syntax used inside a handler.
A component's state is preserved when a prop changes, but reset when a completely different element renders in the same spot. What determines which happens?
React associates state with a component's position in the render tree, not with the component instance or its props specifically. If the same component type renders at the same tree position across a re-render, its state is preserved regardless of what props changed. If a different component type (or a different element entirely) renders at that same position, React treats it as a genuinely different thing, destroys the old state, and starts fresh. This is why toggling a prop on the same `<Counter />` keeps its count, but swapping `<Counter />` for a `<p>` at that same spot in the tree resets it entirely, even though from the JSX it might look like a small, local change.
What does contextual retrieval actually change about the chunking process, and what measurable difference did it make?
Instead of embedding each chunk as extracted, contextual retrieval prepends a short, chunk-specific explanatory context before embedding it, turning "The company's revenue grew by 3%..." into something like "This chunk is from an SEC filing on ACME Corp's performance in Q2 2023; the company's revenue grew by 3%...", generated automatically per chunk rather than written by hand. In Anthropic's published results, this reduced retrieval failures by 49%, and combining it with reranking (a second relevance-scoring pass over retrieved candidates) reduced failures by 67%, a substantial, measured improvement from addressing the isolated-chunk context problem directly rather than only tuning the embedding model or retrieval algorithm.