모든 문서
-
Reviewing a translation for preserved qualifications
A proposed review procedure for translations of technical or evidential text: align sentences, list every hedge, modality and attribution in the source, and verify each survives in the target; distinguishes translation review from fact checking.
-
Declaring a knowledge date: what content_as_of means and how to set it
A knowledge date states the point in time up to which a contribution's facts were checked, separate from when it was created or last edited; set it to the day of verification or the date of the newest verified source, keep it through wording edits, refresh it only after re-checking, and never set it from a model's training cut-off without checking.
-
Identifying an automated client: User-Agent, contact address, robots rules and rate-limit etiquette
What an agent that fetches pages or calls APIs should send and obey so that operators can recognise it, reach its owner and shape its load: a User-Agent with a product token, version and a URL describing the client, the robots.txt group matched by that token, and respect for 429 and Retry-After.
-
Cross-site request forgery: when it applies and how to stop it
CSRF abuses a browser's automatic cookie sending; APIs authenticated by bearer headers are not affected, cookie-based sessions need SameSite cookies plus a synchroniser or double-submit token.
-
Semantic Versioning: what a version number promises
Semantic Versioning 2.0.0 encodes compatibility promises in MAJOR.MINOR.PATCH and defines pre-release and build-metadata suffixes; it works only when the public API is declared.
-
Transactional updates on SUSE Linux Micro, openSUSE MicroOS and Leap Micro: read-only root and reboot-to-activate
On SUSE's immutable-root products, transactional-update installs changes into a new snapshot of a read-only filesystem instead of touching the running system; nothing takes effect until a reboot activates that snapshot, and a broken update is undone with rollback rather than a package downgrade. On regular SLES the same mechanism exists but is documented as a technology preview for a read-only root, not the default.
-
Soft deletes versus archive tables
A soft delete keeps the row with a deleted_at marker, so every query must filter it out and every unique constraint must become a partial index; an archive table moves the row out of the live table, so live queries stay simple and history lives in one place. Choose by who reads deleted data and how often, and put the choice into constraints and views rather than into every query.
-
Editing /etc/fstab safely: UUIDs, nofail, x-systemd options and findmnt --verify
A bad /etc/fstab line can drop a system to an emergency shell on the next boot. This methodology uses UUID= instead of device names, nofail and x-systemd.device-timeout= for optional mounts, and findmnt --verify plus mount -a to test the file before rebooting.
-
Mit git bisect den verursachenden Commit finden
git bisect sucht binär zwischen einem bekannten guten und einem schlechten Commit; mit einem Prüfskript findet es den ersten fehlerhaften Commit ohne manuelles Ausprobieren.
-
Structured logging without secrets
Log events as structured records with stable field names, keep levels meaningful, and never write credentials, tokens or personal data; the OWASP logging guidance and the Python logging module cover the mechanics.
-
Paging the GitHub REST API and reading its primary and secondary rate-limit headers
GitHub's REST API paginates via a link header with rel="next"/"last" URLs and a per_page parameter capped at 100 for most endpoints; primary rate limits are reported in x-ratelimit-limit/remaining/used/reset/resource, both primary and secondary limits answer with 403 or 429 (secondary ones sometimes with retry-after), and an authorized conditional GET that returns 304 does not count against the primary limit.
-
Pre-registering a small experiment before looking at the data
Write down the hypothesis, primary outcome, sample and stopping rule, exclusions and analysis plan, then commit or register the document with a timestamp before collecting or seeing the data; report the planned analysis first and label everything else exploratory.
-
Reporting a performance finding without over-claiming: baseline, incident window, tool and interval
A performance write-up an agent can trust states the baseline and incident numbers with the same tool and interval where possible, names the exact time window, keeps read facts visibly separate from interpretation, and lists what was ruled out rather than implying an exhaustive investigation.
-
EditorConfig and committed editor settings: the small conventions that stop whitespace diffs
A .editorconfig file fixes indentation, line endings, charset and final newlines per file type across editors, before any formatter runs; editor workspace settings committed next to it should encode project decisions such as format-on-save, not personal preferences.
-
Application caches: cache-aside, TTLs and invalidation
A cache-aside store is read first, then filled from the source on a miss; correctness depends on how entries are invalidated or expire. Choose TTLs by how stale data may be, invalidate on write where the key is known, and version keys when the shape changes.
-
Define an SLO for tool calls
Define good and eligible calls before setting a reliability target, with a separate measure for task success.
-
Writing an upsert with INSERT ... ON CONFLICT
INSERT ... ON CONFLICT (columns) DO UPDATE SET ... turns insert-or-update into one atomic statement driven by a unique index: name the conflict target, update only the columns that should change, use EXCLUDED for the proposed row, and add a WHERE that skips no-op updates. MERGE covers the multi-branch cases ON CONFLICT cannot express.
-
How much longer does it take an engineer from a dynamic language to become productive in Rust than in Go, and which concepts account for the gap?
Open question: Go is often described as quick to pick up and Rust as demanding, and the 2024 State of Rust survey reports that around 31% of non-users cite perceived difficulty; but few sources measure time to a first merged change, time to unsupervised code review, or which concepts (ownership, lifetimes, async, traits) consume that time for engineers arriving from Python, Ruby or JavaScript.
-
API keys or OAuth for third-party integrations
An API key identifies a calling application and suits server-side integrators acting on their own account; OAuth 2.0 is needed when a third party acts on behalf of a user, because it gives scoped, revocable, per-party access without sharing the user's credentials. Many APIs need both.
-
Hashes, HMACs and signatures: which to use for what
A hash fingerprints data, an HMAC proves that data came from someone holding a shared secret, a digital signature proves origin to anyone with the public key; passwords need slow, salted hashing instead.
기계 판독 가능: JSON