Search
17 results for “validator”
Search results
JSON Formatter
Format, validate, and minify JSON, runs entirely in your browser, nothing is sent anywhere.
What is an "LLM-graded" eval, and when would you reach for it instead of exact-match or similarity-based grading?
An LLM-graded eval uses a separate model call to judge a subjective quality of the output, tone, empathy, professionalism, on a numeric scale or binary classification, rather than checking it against one fixed correct answer. Exact-match grading only works when there's one right answer (a category label); similarity-based grading (cosine similarity between embeddings) works when wording can vary but meaning should match a reference. LLM-graded evals are the right tool specifically for qualities that are inherently subjective and hard to define with a fixed rule or reference string, at the cost of being noisier and more expensive to run than a simple string comparison.
Given the risk of hitting a recursion limit, when would you rewrite a recursive algorithm iteratively, and what does that actually trade away?
Rewrite iteratively when the recursion depth scales with input size in a way that could plausibly exceed the platform's real stack capacity, deep tree traversals, recursive descent over large or adversarial inputs, anything where "how deep" isn't bounded by a small constant. The trade is code clarity: many recursive algorithms (tree traversal, divide-and-conquer, backtracking) read far more naturally as recursion, mirroring the problem's own recursive structure, and converting them to an explicit-stack iterative version, while removing the depth risk entirely, usually costs some of that direct correspondence between code and problem structure.
Why can naive cache invalidation cause a race condition?
If a write invalidates (deletes) a cache key and then updates the database, a concurrent read between those two steps can repopulate the cache with the old value right after it was deleted, leaving stale data cached until the next TTL expiry or invalidation. Ordering matters: update the database first, then invalidate the cache, and even then, a very unlucky interleaving with a concurrent cache-aside read can still occur, which is why short TTLs are used as a safety net rather than relying on invalidation alone for strict consistency.
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.
A client sends a payment request, the network times out before a response arrives, and the client retries with the same idempotency key. What actually happens on the server?
If the original request already completed (successfully or even with an error like a 500) before the retry arrives, the server returns the exact same result it returned (or would have returned) the first time, the same status code and response body, without re-executing the underlying operation, so the customer isn't charged twice just because the client never saw the first response. This is the entire point of an idempotency key: it lets a client safely retry an operation whose actual outcome it's genuinely uncertain about (did the first request even reach the server? did it complete before the timeout?) without that retry risking a duplicate side effect.
Why are environment variables considered a weaker place to store a secret than a dedicated secrets manager, even though they avoid hardcoding it in source?
Environment variables are readable by the entire process (and often child processes) they're set for, commonly get dumped into crash reports, debugging output, or `/proc` on Linux, and are easy to accidentally log in full, none of which requires a targeted attack, just an ordinary operational mistake. A dedicated secrets manager instead requires an authenticated, audited API call to retrieve a secret, can issue it as short-lived, and centralizes rotation and access logging in one place. Environment variables are a real improvement over hardcoding in source, but they are a stopgap, not the same security posture as centralized, audited secret retrieval.
Given a setTimeout(fn, 0) and a Promise.resolve().then(fn) registered in that order, which one runs first, and why?
The Promise callback runs first, even though the timeout was registered with a 0ms delay and appears to ask for the soonest possible execution. `setTimeout` queues a macrotask (a "task" in spec terms), while a Promise callback queues a microtask, and the event loop's rule is that the entire microtask queue is drained completely before the next macrotask is even pulled, regardless of registration order or the timeout value. A 0ms delay doesn't mean "immediately", it means "as the next task once the microtask queue is empty and the current call stack has finished."
What is the difference between journald's "volatile", "persistent", and "auto" storage modes, and which one is the default?
"Volatile" keeps the journal only in `/run/log/journal`, which is memory-backed and wiped on every reboot, nothing survives a restart. "Persistent" writes to `/var/log/journal` on disk, so entries survive reboots (falling back to volatile only during very early boot or if the disk is unavailable). "Auto" is the actual default, and it behaves like "persistent" only if `/var/log/journal` already exists, otherwise it behaves like "volatile", so whether logs survive a reboot on a given system depends entirely on whether that directory happens to have been created, not on any setting an administrator consciously chose.
A consumer receives a message, starts processing, but crashes before deleting it. What happens to that message, and why is this actually the desired behavior?
Once the visibility timeout expires without the message being deleted, it automatically becomes visible again in the queue and can be picked up by the same or a different consumer for another processing attempt. This is deliberate, not a bug: the alternative (a crashed consumer's message vanishing permanently) would silently lose data, whereas reappearing after timeout guarantees eventual processing at the cost of a possible duplicate attempt, which is exactly the trade-off "at-least-once delivery" describes. Setting the visibility timeout too short causes premature, unnecessary reprocessing of messages still legitimately being worked on; too long delays legitimate retries after a real crash.
What does "at-least-once delivery" actually guarantee, and what does it not guarantee, and why does that mean a consumer must be idempotent?
At-least-once delivery guarantees a message will eventually be delivered and processed at least one time, it does not guarantee exactly one delivery, the same message can legitimately be delivered and processed more than once, for example if a consumer's deletion request is lost after it already finished processing, or a visibility timeout expires just as processing completes. Because duplicate delivery is a normal, expected outcome of this model rather than a rare edge case, a consumer has to be written so that processing the same message twice produces the same end result as processing it once (an idempotent operation), rather than assuming the queue itself will prevent duplicates.
A custom class defines __eq__ based on a value field but leaves __hash__ using default identity-based hashing. What actually goes wrong when you use an instance as a dict key?
In Python 3, simply defining `__eq__` without touching `__hash__` doesn't leave the old identity-based hash in place, Python automatically sets `__hash__` to `None` on that class, making instances unhashable, so using one as a dict key raises `TypeError` immediately rather than corrupting anything. This happens even if a parent class defines `__hash__`: overriding `__eq__` in a subclass sets that subclass's `__hash__` to `None` regardless of what the parent provides, ordinary inheritance does not carry the parent's hash forward. The silent, no-exception version of this bug only happens if the class explicitly keeps or re-supplies an identity-based `__hash__` alongside the value-based `__eq__` (e.g. `__hash__ = object.__hash__`, or, to retain a parent's hash on purpose, `__hash__ = Parent.__hash__`). In that case, two instances with the same value compare equal (`a == b` is `True`) but hash differently, and inserting under key `a` then looking up with an equal-but-distinct key `b` lands in the wrong hash bucket and returns nothing, because the hash mismatch never gave the lookup a chance to even check equality against the right entry.
What is the difference between durability and availability in S3, and why does it matter when picking a storage class?
Durability is the probability that a stored object is not lost over a year, and S3 Standard, Standard-IA, and every Glacier class are all designed for the same 99.999999999% (11 nines) durability. Availability is how often the object can actually be successfully retrieved on demand, and that number does vary by class, 99.99% for Standard down to 99.5% for One Zone-IA. It matters because a cheaper class is not automatically a less durable one, S3 One Zone-IA is exactly as durable as Standard-IA per object, but it is not resilient to the loss of its single Availability Zone at all, since it isn't replicated across multiple zones the way every multi-AZ class is.
A custom dropdown built entirely from styled divs passes a visual design review. What is likely still broken for a keyboard-only or screen-reader user, and why doesn't looking right catch it?
Without the correct ARIA roles/states (or, better, a native `<select>`), a div-based dropdown typically has no way to be reached or operated via keyboard alone (no built-in Tab/Enter/Arrow-key handling), and a screen reader has no semantic information telling it "this is a dropdown, it is currently closed, here are its options," so it may announce nothing meaningful at all. A purely visual review can't catch this because the div looks and behaves correctly with a mouse, the missing behavior only surfaces via keyboard navigation or assistive technology, which is exactly why accessibility has to be tested directly with a keyboard and a screen reader, not inferred from how a component looks.
When does semantic search (via embeddings) actually outperform traditional keyword search, and when might keyword search still win?
Semantic search wins when a query and the relevant document use different words for the same idea, "car won't start" matching a document about "vehicle fails to ignite", since embeddings compare meaning rather than literal tokens, which keyword search cannot do at all. Keyword search still wins, or at least remains necessary, for exact-match needs, an error code, a product SKU, a specific proper noun, where the literal string matters and a semantically "close" but textually different result is actually the wrong answer. This is why production search systems commonly combine both (hybrid search) rather than treating embeddings as a strict replacement for keyword matching.
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.
What problem does RAG solve that simply pasting an entire knowledge base into the prompt doesn't?
A real knowledge base, product docs, legal filings, support history, routinely exceeds any model's context window, and even when it technically fits, stuffing everything into every request wastes tokens on mostly-irrelevant content and degrades accuracy as context grows. RAG instead retrieves only the specific chunks relevant to the current query at request time, from a knowledge base that's been pre-processed into searchable chunks and embeddings, so the model gets focused, relevant background knowledge sized to the question actually being asked, not the entire corpus every time.