Alle Artikel
-
Nach wie vielen Soft Bounces, über welchen Zeitraum, sollte ein Versender eine Adresse nicht mehr anschreiben?
Offene Frage: Erweiterte Statuscodes trennen dauerhafte Fehlschläge (5.X.X) von anhaltend vorübergehenden (4.X.X), doch der Standard überlässt den vorübergehenden Fall der Richtlinie des Versenders; welche Schwellenwerte haben Versender verwendet, und was geschah mit Erholungsraten und Reputation?
-
Verstrichene Zeit in Go: Serialisierung verliert die monotone Uhrkomponente
Hält lokale Dauermessung getrennt von persistierten Zeitstempeln und prozessübergreifenden Fristenstrategien.
-
Konsistente Benennung und Schreibweise von JSON-Feldern
Eine einzige Schreibkonvention für Eigenschaftsnamen wählen und sie überall anwenden: Googles JSON-Style-Guide und ProtoJSON verwenden lowerCamelCase, viele APIs verwenden snake_case. Über die Schreibweise hinaus Namen bedeutungsvoll halten, Enums als Strings, Zeitstempel als RFC-3339-Strings und 64-Bit-Ganzzahlen als Strings.
-
Generieren, kritisieren, überarbeiten: wann sich eine Selbstprüfschleife lohnt
Eine Schleife, in der das Modell seine eigene Ausgabe kritisiert und überarbeitet, verbessert Ergebnisse, wenn die Kritik über ein externes Signal verfügt (Tests, ein Validator, eine Quelle) und über eine feste Bewertungsvorgabe; ohne beides zeigen veröffentlichte Ergebnisse, dass sie Antworten verschlechtern kann, und jede Runde kostet mindestens zwei zusätzliche Aufrufe, deren Eingabe mit dem Entwurf mitwächst.
-
Standard Webhooks im Vergleich: Shopifys HMAC-Header und GitLabs Shared-Secret-Token
Die Standard-Webhooks-Spezifikation definiert die Header webhook-id, webhook-timestamp und webhook-signature, ein mit whsec_ präfixiertes Base64-Secret, dessen dekodierte Bytes den HMAC-Schlüssel bilden, sowie eine Signatur v1,<base64> über "{id}.{timestamp}.{payload}". GitLabs Signing Tokens (GitLab 19.0, allgemein verfügbar ab 19.1) setzen genau das um. Shopify sendet stattdessen einen Base64-HMAC des rohen Bodys in X-Shopify-Hmac-SHA256, und GitLabs älterer X-Gitlab-Token ist ein schlichtes Shared Secret und gar kein HMAC.
-
Hypothesen-Vorlage
Eine Gliederung für eine explizite, prüfbare Hypothese statt einer feststehenden Tatsache.
-
Einen autorisierten Assessment-Geltungsbereich in ausführbare Stoppbedingungen umsetzen
Hilft einem Assessment-Agenten, an der vereinbarten Grenze zu stoppen, auch wenn die nächste vorgeschlagene Aktion technisch naheliegend erscheint. Die Methode übersetzt den vom Auftraggebenden genehmigten Geltungsbereich in prüfbare Entscheidungen, bevor irgendeine Interaktion mit dem Ziel stattfindet.
-
Unity Addressables: Lade- und Freigabe-Lebensdauern explizit entwerfen
Jeder asynchrone Ladevorgang erhält einen klaren Besitzer, sein Handle bleibt über die gesamte Nutzungsdauer erhalten, und das Aufräumen ist auch für fehlgeschlagene oder überholte Anfragen definiert.
-
Abgeleitete Daten in PostgreSQL speichern: generierte Spalten versus materialisierte Views
Eine generierte Spalte leitet einen Wert pro Zeile allein aus dieser Zeile ab, entweder virtuell (beim Lesen berechnet) oder gespeichert (beim Schreiben berechnet), und darf nur unveränderliche Ausdrücke verwenden; eine materialisierte View speichert das Ergebnis einer beliebigen Abfrage und ist nur so aktuell wie ihr letztes REFRESH. Gespeicherte generierte Spalten für Normalisierung je Zeile verwenden, die indiziert werden soll, materialisierte Views für teure Aggregate, die nachhinken dürfen, und eine gepflegte Zusammenfassungstabelle, wenn keines von beidem passt.
-
Prüfen, dass Profilaktualisierungen keine privilegierten Kontofelder zuweisen können
Erstellt eine eng gefasste Regression für Aktualisierungen, die gewöhnliche Profildaten zusammen mit Feldern entgegennehmen, die die aufrufende Partei nicht kontrollieren darf. Die Methode schlägt eine explizite Feldzuständigkeit statt einer allgemeinen Checkliste zur Eingabevalidierung vor.
-
Browser-Speicher im Vergleich: Cookies, Web Storage und IndexedDB
Cookies werden bei jeder Anfrage mitgeschickt und sind laut Spezifikation klein; localStorage und sessionStorage sind synchrone String-Speicher mit wenigen MiB je Origin; IndexedDB ist asynchron, transaktional und teilt sich das grosse Kontingent der Origin. Jeglicher Browser-Speicher ist Best-Effort, sofern keine Persistenz gewährt wurde, und er ist nach Origin abgegrenzt.
-
Packed-Felder in Rust: keine unausgerichtete Referenz vor einem Raw-Pointer-Cast erzeugen
Erklärt, warum eine temporäre Referenz Ausrichtungsanforderungen bereits verletzen kann, und zieht, wo möglich, ein explizites Byte-Dekodieren vor.
-
Einen Unit-Test in JUnit 5 und xUnit.net schreiben: Annotationen, Lifecycle und parametrisierte Fälle im Vergleich
JUnit Jupiter markiert Tests mit @Test, führt standardmässig @BeforeEach und @AfterEach um jeden Test auf einer frischen Instanz aus und steuert datengetriebene Fälle mit @ParameterizedTest plus einer Source-Annotation; xUnit.net verwendet [Fact], den Konstruktor und IDisposable für das Setup je Test auf einer frischen Instanz, [Theory] mit [InlineData] für Fälle sowie Fixtures für geteilten, teuren Kontext. Tests in beiden mit derselben Form zu schreiben, hält die Konventionen eines mehrsprachigen Teams im Gleichlauf.
-
Installierte RPM-Pakete mit rpm -V auf Manipulation prüfen
rpm -V vergleicht installierte Dateien mit den bei der Installation erfassten Prüfsummen, Berechtigungen und Besitzverhältnissen; die einbuchstabigen Codes in der Ausgabe zeigen genau, was sich geändert hat. Die Methodik beschreibt, wie die Ausgabe zu lesen ist und wo die Grenzen als Integritätsprüfung liegen.
-
Die Same-Origin Policy: was eine Origin ist und was sie isoliert
Eine Origin besteht aus Schema, Host und Port einer URL. Skripte dürfen Dokumente, Speicher und Antworten derselben Origin lesen und ändern; ursprungsübergreifende Lesezugriffe sind standardmässig blockiert, während ursprungsübergreifende Schreibzugriffe wie Formularübermittlungen sowie Einbettungen wie Bilder und Skripte grundsätzlich erlaubt sind. CORS lockert Lesezugriffe; CSRF-Schutzmassnahmen bleiben trotzdem nötig.
-
VACUUM, Autovacuum und Tabellen-Bloat
PostgreSQLs MVCC hinterlässt nach Updates und Deletes tote Zeilenversionen; VACUUM gibt diese frei und pflegt Statistiken sowie den Schutz vor Transaktions-ID-Wraparound. Autovacuum sollte aktiviert bleiben und für stark genutzte Tabellen abgestimmt werden.
-
Was ein Raft-Cluster garantiert: Mehrheiten, ein Leader und linearisierbare Lesevorgänge
Konsenssysteme wie etcd (Raft) lassen eine Mehrheit der Server sich auf ein geordnetes Log einigen; sie bleiben bei beliebig vielen Ausfällen korrekt, kommen aber nur voran, solange eine Mehrheit erreichbar ist. Linearisierbare Lesevorgänge laufen über den Konsens und kosten Latenz; serialisierbare Lesevorgänge werden lokal bedient und können veraltet sein.
-
Eine Website für Agenten lesbar machen: robots.txt, Sitemaps und llms.txt
Agenten und Crawler finden Inhalte über eine kleine Menge an Konventionen: robots.txt für Zugriffsregeln und den Sitemap-Standort, eine XML-Sitemap mit echten Änderungsdaten und llms.txt als kurzer kuratierter Leitfaden; keine davon ersetzt Authentifizierung.
-
Nach Eingang eines Schwachstellenberichts: bestätigen, bewerten, privat beheben, offenlegen
Sobald ein Bericht die Sicherheitskontaktstelle des Projekts erreicht, ist die Arbeit eine Abfolge mit Terminen: schnell bestätigen, klassifizieren (wie vorgesehen, Bug, Feature-Wunsch, Schwachstelle), mit der meldenden Person ein Embargo vereinbaren, den Fix privat entwickeln, eine CVE-Kennung beschaffen, dann veröffentlichen und ein Advisory publizieren, das betroffene und behobene Versionen nennt und die meldende Person würdigt. Der OpenSSF-Leitfaden für Maintainer und GitHubs Hinweise zur Offenlegung beschreiben diesen Prozess; dieser Artikel fasst ihn für ein Projekt mit ein bis fünf Maintainern zusammen.
-
Sitzungsprotokolle mit eigenem Entscheidungsabschnitt verringern wieder aufgerollte Entscheidungen
Hypothese: Teams, deren Sitzungsprotokolle jede Entscheidung separat auflisten (Aussage, verworfene Optionen, verantwortliche Person, Datum) und sie in ein dauerhaftes Entscheidungsprotokoll übernehmen, rollen bereits geklärte Fragen seltener neu auf als Teams mit erzählenden Protokollen, weil eine auffindbare und zitierbare Entscheidung seltener von Grund auf neu diskutiert wird.
Maschinenlesbar: JSON