Search
16 results for “regex”
Search results
Regex Tester
Test a regular expression against sample text with live match highlighting and capture groups; runs entirely in your browser.
A request's input already exceeds the model's context window before generation even starts. What happens, versus a request that only exceeds the limit once output is generated?
If the input alone already exceeds the context window, the API rejects the request upfront with a 400 error, generation never starts at all. If the input fits but input tokens plus the requested max output tokens could exceed the window, current models accept the request and generate as far as they can; if generation actually reaches the window limit before finishing, it stops early with a specific stop reason indicating the context window was exhausted, rather than silently truncating or erroring out mid-response. The distinction matters operationally: the first case is a fixable request-construction bug, the second is a signal to reduce the requested output length or the accumulated conversation history.
What is the core difference between Grid and Flexbox?
Flexbox lays items out along a single axis (row or column) and is content-driven, items can wrap, but each row or column sizes independently based on its own content. Grid lays items out on a two-dimensional row-and-column track system defined up front, so rows and columns can be aligned to each other across the whole layout. The practical rule: reach for Flexbox when you are arranging items in a line, Grid when you need rows and columns to line up together.
How does the fr unit in Grid differ from flex-grow in Flexbox?
Both distribute available space proportionally, but fr operates on Grid tracks (rows/columns) as part of an explicit track list, `grid-template-columns: 1fr 2fr` splits width into three parts with the second column taking two of them. flex-grow operates on individual flex items along the main axis and only kicks in for leftover space after each item's base size is accounted for. fr is about defining the track structure; flex-grow is about how items compete for remaining space within it.
What do WCAG's 4.5:1 and 3:1 contrast ratios each apply to, and why does the threshold change for large text?
WCAG 2.1's AA-level contrast requirement is 4.5:1 for normal text, text smaller than 18 point (or 14 point bold), and a relaxed 3:1 for large text at or above that size threshold. The reasoning given is that larger text with wider character strokes is inherently easier to read at lower contrast, so the stricter 4.5:1 ratio is reserved for the smaller, harder-to-read text where insufficient contrast is much more likely to genuinely block reading for people with low vision, color-vision deficiencies, or age-related contrast sensitivity loss. It is not an arbitrary aesthetic distinction, it is calibrated to actual legibility at different sizes.
What is a "golden path" and why does it matter more than giving teams unlimited flexibility?
A golden path is an opinionated, well-supported, self-service way to accomplish a common task, spinning up a new service, provisioning a database, setting up a CI pipeline, that comes with sane defaults for security, observability, and reliability already wired in. Unlimited flexibility sounds appealing but means every team re-solves the same problems (how do we get logs flowing, how do we handle secrets) slightly differently, multiplying the platform team's support burden and creating inconsistent security/reliability posture across the organization. A golden path trades some flexibility for consistency and speed, while still allowing teams to go off-path when they have a genuine reason to.
What problem does wrapping different parts of a prompt in XML-style tags actually solve?
A complex prompt often mixes several genuinely different kinds of content in one block of text, instructions, background context, few-shot examples, and the actual variable input to process, and a model has to infer where one ends and the next begins from phrasing alone if nothing marks the boundaries. Wrapping each kind of content in its own consistently-named tag, `<instructions>`, `<context>`, `<example>`, `<input>`, removes that inference step entirely: the structure itself tells the model unambiguously what role each piece of text plays, which reduces misinterpretation especially as a prompt grows longer or nests multiple documents or examples.
Name three CSS properties, besides z-index with positioning, that create a new stacking context, and why does that matter when debugging a layering bug?
Opacity below 1, any non-none `transform`, and `filter` or `backdrop-filter` with a value other than `none` all create a new stacking context, along with several others like `isolation: isolate` and `will-change` naming a stacking-context property. This matters when debugging because a completely unrelated-looking style change, adding a fade transition via opacity, or a hover effect via transform, can silently create a new stacking context and change how that element's children layer against the rest of the page, a z-index layering bug that has nothing to do with z-index values themselves, but with an accidental new stacking context somewhere in the ancestor chain.
A PostgreSQL primary crashes right after committing a transaction, under asynchronous replication. Is that transaction guaranteed to exist on the standby?
No. Asynchronous replication (the default) confirms a commit on the primary without waiting for the standby to receive or apply the corresponding WAL records, there's typically a small delay, often under a second, between a commit and its visibility on the standby. If the primary crashes in that window, before the WAL records reached the standby, that transaction is lost even though the client was already told it committed successfully. This is the specific, documented risk asynchronous replication accepts in exchange for not adding network round-trip latency to every commit.
What does hashed sharding trade away in exchange for fixing the monotonic-key hot-shard problem?
Hashed sharding computes a hash of the shard key value and assigns chunks by hash range instead of by the raw value, which scatters even monotonically increasing keys roughly evenly across shards, since consecutive input values hash to essentially unrelated output values. The trade-off is range-query locality: a query filtering a range of the original shard key values (like "the last 24 hours" on a timestamp key) can no longer be routed to one contiguous set of shards, because the corresponding hashed values are scattered unpredictably across the whole cluster, turning what would have been a single-shard query under range sharding into a broadcast query touching every shard.
What is the difference between a composite index and two separate single-column indexes?
A composite (multi-column) index on (a, b) stores rows sorted by a, then by b within each a. It efficiently serves queries filtering on a alone, or on a and b together, but not on b alone. Two separate single-column indexes let Postgres combine them via a bitmap AND/OR, which works but is usually slower than one well-ordered composite index for the common query pattern. Column order in a composite index should match the most selective, most-frequently-filtered column first.
Azure Policy, Tags, and Resource Locks Explained: A Complete Governance Guide for Cloud Engineers
Effective governance is essential as cloud environments grow. Without proper controls, organizations often face challenges in visibility, accountability, and cost tracking. In this lab, we explore how to implement governance practices in Azure using Azure Policy , Resource Tags , and Resource Locks…
Why is an evaluation suite necessary before shipping a prompt change, instead of just testing it manually on a few examples?
A prompt change can improve one success dimension while quietly breaking another, better accuracy but worse consistency, or improved tone at the cost of latency, and manually eyeballing a handful of examples won't reliably catch a regression on a dimension you weren't specifically looking at. An evaluation suite tests against a defined, ideally large set of cases, including deliberately hard edge cases like sarcasm or mixed sentiment, and scores every dimension that actually matters, which turns "it feels better" into a measurable, defensible, trackable claim, and catches regressions before they reach production rather than after.
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.
Why does Python's sort achieve O(n) in the best case rather than always costing O(n log n) like a textbook mergesort?
Python uses Timsort, which specifically looks for and exploits "runs," contiguous stretches of already-ordered (or reverse-ordered) elements already present in the input, merging those runs rather than treating the data as uniformly random. Fully-sorted input is the extreme case of this: it's already one giant run, so Timsort recognizes it and finishes in linear time instead of doing the full comparison work a naive O(n log n) sort would perform regardless of input order. This is exactly why Timsort performs so well on real-world data, which is very often partially sorted already, not uniformly random.
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.