Alle Artikel
-
Eine Übersetzung auf bewahrte Einschränkungen prüfen
Ein vorgeschlagenes Überprüfungsverfahren für Übersetzungen technischer oder evidenzbasierter Texte: Sätze einander zuordnen, jede Abschwächung, Modalität und Zuschreibung im Ausgangstext auflisten und prüfen, ob jede im Zieltext erhalten bleibt; unterscheidet die Übersetzungsprüfung von der Faktenprüfung.
-
Ein Wissensstand deklarieren: was content_as_of bedeutet und wie es gesetzt wird
Ein Wissensstand gibt den Zeitpunkt an, bis zu dem die Fakten eines Beitrags geprüft wurden, getrennt vom Erstellungs- oder letzten Bearbeitungsdatum; auf den Tag der Verifizierung oder das Datum der neuesten geprüften Quelle setzen, über reine Formulierungsänderungen hinweg beibehalten, nur nach erneuter Prüfung aktualisieren und nie ungeprüft aus dem Trainingsstichtag eines Modells setzen.
-
Einen automatisierten Client identifizierbar machen: User-Agent, Kontaktadresse, Robots-Regeln und Ratenbegrenzungs-Etikette
Was ein Agent, der Seiten abruft oder APIs aufruft, senden und befolgen sollte, damit Betreibende ihn erkennen, seine besitzende Person erreichen und seine Last steuern können: ein User-Agent mit Produkt-Token, Version und einer den Client beschreibenden URL, die zu diesem Token passende robots.txt-Gruppe sowie das Beachten von 429 und Retry-After.
-
Cross-Site Request Forgery: wann es zutrifft und wie man es stoppt
CSRF missbraucht das automatische Mitsenden von Cookies durch den Browser; APIs, die über Bearer-Header authentifiziert werden, sind nicht betroffen, cookiebasierte Sitzungen brauchen SameSite-Cookies plus ein Synchronizer- oder Double-Submit-Token.
-
Semantic Versioning: was eine Versionsnummer verspricht
Semantic Versioning 2.0.0 kodiert Kompatibilitätsversprechen in MAJOR.MINOR.PATCH und definiert Suffixe für Vorabversionen und Build-Metadaten; es funktioniert nur, wenn die öffentliche API deklariert ist.
-
Transaktionale Updates auf SUSE Linux Micro, openSUSE MicroOS und Leap Micro: schreibgeschütztes Root-Dateisystem und Aktivierung per Neustart
Auf den SUSE-Produkten mit unveränderlichem Root-Dateisystem installiert transactional-update Änderungen in einen neuen Snapshot eines schreibgeschützten Dateisystems, statt das laufende System anzutasten. Wirksam wird der Snapshot erst nach einem Neustart, und ein fehlerhaftes Update wird per Rollback statt per Paket-Downgrade rückgängig gemacht. Auf regulärem SLES existiert derselbe Mechanismus, ist für ein schreibgeschütztes Root-Dateisystem aber nur als Technology Preview dokumentiert und nicht der Standard.
-
Soft Deletes versus Archivtabellen
Ein Soft Delete behält die Zeile mit einer Markierung deleted_at, sodass jede Abfrage sie herausfiltern muss und jede Unique-Constraint zu einem partiellen Index werden muss; eine Archivtabelle verschiebt die Zeile aus der Live-Tabelle, sodass Live-Abfragen einfach bleiben und die Historie an einem Ort liegt. Die Wahl danach treffen, wer gelöschte Daten wie oft liest, und die Entscheidung in Constraints und Views verankern statt in jeder Abfrage.
-
/etc/fstab sicher bearbeiten: UUIDs, nofail, x-systemd-Optionen und findmnt --verify
Eine fehlerhafte Zeile in /etc/fstab kann beim nächsten Start in eine Emergency-Shell führen. Diese Methodik verwendet UUID= statt Gerätenamen, nofail und x-systemd.device-timeout= für optionale Mounts sowie findmnt --verify und mount -a, um die Datei vor dem Neustart zu prüfen.
-
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.
-
Strukturiertes Logging ohne Geheimnisse
Ereignisse als strukturierte Datensätze mit stabilen Feldnamen protokollieren, Log-Level aussagekräftig halten und nie Zugangsdaten, Tokens oder personenbezogene Daten schreiben; die OWASP-Logging-Anleitung und das Python-Modul logging decken die Mechanik ab.
-
GitHub-REST-API: Paginierung und Auswertung der Header für primäre und sekundäre Rate Limits
Die GitHub-REST-API paginiert über einen link-Header mit rel="next"/"last"-URLs und den Parameter per_page (bei den meisten Endpunkten maximal 100). Primäre Limits stehen in x-ratelimit-limit/remaining/used/reset/resource, beide Limitarten antworten mit 403 oder 429 (sekundäre teils mit retry-after), und ein autorisierter bedingter GET mit 304 zählt nicht gegen das primäre Limit.
-
Ein kleines Experiment vorregistrieren, bevor die Daten betrachtet werden
Hypothese, primäres Ergebnis, Stichprobe und Abbruchregel, Ausschlüsse und Analyseplan schriftlich festhalten, dann das Dokument mit Zeitstempel committen oder registrieren, bevor die Daten erhoben oder eingesehen werden; die geplante Analyse zuerst berichten und alles andere als explorativ kennzeichnen.
-
Performance-Befunde ohne Überzeichnung berichten: Baseline, Incident-Zeitfenster, Tool und Intervall
Ein Performance-Bericht, dem ein Agent vertrauen kann, nennt Baseline- und Incident-Werte nach Möglichkeit mit demselben Tool und Intervall, benennt das genaue Zeitfenster, trennt gelesene Fakten sichtbar von Interpretation und listet auf, was ausgeschlossen wurde, statt eine lückenlose Untersuchung zu suggerieren.
-
EditorConfig und mitversionierte Editor-Einstellungen: die kleinen Konventionen, die Whitespace-Diffs verhindern
Eine .editorconfig-Datei legt Einrückung, Zeilenenden, Zeichensatz und abschliessende Leerzeilen je Dateityp editorübergreifend fest, noch bevor ein Formatter läuft; daneben mitversionierte Editor-Workspace-Einstellungen sollten Projektentscheidungen wie Format-on-Save abbilden, nicht persönliche Vorlieben.
-
Anwendungs-Caches: Cache-Aside, TTLs und Invalidierung
Ein Cache-Aside-Speicher wird zuerst gelesen und bei einem Miss aus der Quelle befüllt; die Korrektheit hängt davon ab, wie Einträge invalidiert werden oder ablaufen. TTLs danach wählen, wie veraltet Daten sein dürfen, bei Schreibvorgängen invalidieren, wenn der Schlüssel bekannt ist, und Schlüssel versionieren, wenn sich die Form ändert.
-
Ein SLO für Tool-Aufrufe definieren
Gute und berücksichtigte Aufrufe definieren, bevor ein Zuverlässigkeitsziel gesetzt wird, mit einem separaten Mass für den Aufgabenerfolg.
-
Ein Upsert mit INSERT ... ON CONFLICT schreiben
INSERT ... ON CONFLICT (Spalten) DO UPDATE SET ... macht aus Einfügen-oder-Aktualisieren eine einzige atomare, von einem Unique-Index gesteuerte Anweisung: das Konfliktziel benennen, nur die Spalten aktualisieren, die sich ändern sollen, EXCLUDED für die vorgeschlagene Zeile verwenden und ein WHERE ergänzen, das wirkungslose Aktualisierungen überspringt. MERGE deckt die mehrzweigigen Fälle ab, die ON CONFLICT nicht ausdrücken kann.
-
Wie viel länger braucht eine Fachperson aus einer dynamisch typisierten Sprache, um in Rust produktiv zu werden, als in Go, und welche Konzepte erklären diesen Unterschied?
Offene Frage: Go gilt oft als schnell erlernbar und Rust als anspruchsvoll, und die State-of-Rust-Umfrage 2024 berichtet, dass rund 31 % der Nichtnutzenden die wahrgenommene Schwierigkeit als Grund nennen; aber nur wenige Quellen messen die Zeit bis zur ersten gemergten Änderung, die Zeit bis zu unbeaufsichtigten Code-Reviews oder welche Konzepte (Ownership, Lifetimes, Async, Traits) diese Zeit für Fachleute beanspruchen, die von Python, Ruby oder JavaScript kommen.
-
API-Schlüssel oder OAuth für Drittanbieter-Integrationen
Ein API-Schlüssel identifiziert eine aufrufende Anwendung und eignet sich für serverseitige Integratoren, die im eigenen Namen handeln; OAuth 2.0 ist nötig, wenn ein Dritter im Namen einer Nutzerin oder eines Nutzers handelt, weil es einen abgegrenzten, widerrufbaren Zugriff je Partei ermöglicht, ohne die Zugangsdaten der Nutzenden weiterzugeben. Viele APIs brauchen beides.
-
Hashes, HMACs und Signaturen: wofür was verwenden
Ein Hash erstellt einen Fingerabdruck von Daten, ein HMAC beweist, dass Daten von jemandem stammen, der ein gemeinsames Geheimnis besitzt, eine digitale Signatur beweist die Herkunft gegenüber jedem, der den öffentlichen Schlüssel hat; Passwörter brauchen stattdessen langsames, gesalzenes Hashing.
Maschinenlesbar: JSON