Alle Artikel
-
Transaktionsgrenzen sichtbar halten
Dokumentieren, welche Zustandsänderungen gemeinsam committet werden und was zwischen Datenbanktransaktionen und externen Aufrufen passieren kann.
-
Pipeline, Fan-out, Orchestrator und Kritikergremium: welches Multi-Agenten-Muster zu welcher Aufgabe passt
Eine Pipeline passt zu Aufgaben mit einer festen Abfolge von Transformationsschritten; paralleler Fan-out passt zu unabhängigen Teilfragen oder zu mehrfachen Versuchen, über die abgestimmt wird; ein Orchestrator mit Workern passt zu Aufgaben, deren Zerlegung erst zur Laufzeit bekannt ist; ein Kritikergremium passt zu Ergebnissen, die anhand mehrerer Kriterien geprüft werden müssen; jedes Muster vervielfacht die Tokenkosten und fügt eine Koordinationsschicht hinzu, die selbst scheitern kann.
-
Einen DNS-Eintrag mit Rückwegabsicherung ändern: TTL absenken, Umschaltung und Prüfung
Eine DNS-Änderung erreicht Nutzer nur so schnell, wie die alte TTL in den Caches abläuft; deshalb die TTL eine volle alte TTL-Periode vor der Änderung absenken, das alte Ziel weiterlaufen lassen, bis das neue überall bestätigt ist, und berücksichtigen, dass Resolver veraltete Daten ausliefern dürfen, wenn die autoritativen Server nicht erreichbar sind, wie es RFC 8767 zulässt.
-
HTTP-Statuscodes richtig verwenden: die erste Verzweigung des Clients
Clients, Caches und Agenten entscheiden allein am Statuscode über Wiederholen, Neuladen oder Aufgeben: 201/204 für Erfolg mit und ohne Körper, 401 gegen 403 für fehlende Anmeldung gegen fehlende Berechtigung, 409/412/428 für Konflikte und Vorbedingungen, 429 und 503 mit Retry-After für «später». Ein 200 mit Fehlerobjekt täuscht alle.
-
Ablauf von TLS-Zertifikaten auf jedem Endpunkt überwachen, nicht nur auf der Hauptwebsite
Ein abgelaufenes Zertifikat ist ein Ausfall mit exakt vorhersagbarem Zeitpunkt; das notAfter-Datum jedes tatsächlich ausgelieferten Zertifikats (Web, API, Mail, interne Panels, Load Balancer) von aussen abfragen, mit ausreichendem Vorlauf für eine manuelle Erneuerung alarmieren und sowohl die Zwischenzertifikate als auch das Endzertifikat prüfen.
-
Druck-Stylesheets: eine Webseite auf Papier und als PDF brauchbar machen
Ein Druck-Stylesheet blendet Navigation und Bedienelemente aus, klappt eingeklappte Inhalte auf, druckt Linkziele nach dem Linktext, legt Seitengrösse und Ränder mit @page fest, verhindert das Aufteilen von Tabellen und Abbildungen mit break-inside: avoid und weist den Browser an, unverzichtbare Hintergrundfarben beizubehalten. Mit der Druckvorschau des Browsers testen, nicht nur am Bildschirm.
-
Continuous Profiling in Produktion: dauerhaft aktive Sampling-Profile und was sie beantworten
Continuous Profiling erstellt systematisch über die Zeit CPU- und Speicherprofile und speichert sie als beschriftete Serien, sodass ein Team fragen kann, welche Funktion gestern flottenweit am meisten CPU verbraucht hat oder was sich zwischen zwei Versionen geändert hat; Sampling-Profiler machen das günstig genug, um es dauerhaft laufen zu lassen, und Laufzeit-Endpunkte wie Gos /debug/pprof/ oder eBPF-Agenten liefern die Profile.
-
Die Standardfilterung von ripgrep verkürzt Agenten-Codesuchen gegenüber grep -r
Hypothese: Coding-Agenten, die Repositorys mit den Standard-Ignorierregeln von ripgrep durchsuchen (git-ignorierte, versteckte und binäre Dateien werden übersprungen), brauchen pro Aufgabe weniger Suchaufrufe und lesen weniger irrelevante Ausgabe als Agenten, die grep -r ohne Ausschlüsse verwenden, weil Treffer in Build-Ausgaben und Abhängigkeiten fehlen; es wird keine Messung berichtet.
-
Ein terminierter Dokumentationstag bringt mehr Erstbeitragende als ein dauerhafter Aufruf zur Mithilfe an der Dokumentation
Hypothese: Ein Projekt, das einen einzelnen Tag mit einer kuratierten Liste kleiner Dokumentations-Issues ankündigt, an dem Maintainer für ein Review am selben Tag verfügbar sind und jede Aufgabe das Label good-first-issue trägt, erhält mehr gemergte Dokumentationsänderungen von Personen, die zuvor noch nie beigetragen haben, als dieselbe Liste, die das ganze Jahr über offen bleibt; ein vorgeschlagener Vergleich anhand der eigenen Historie eines Projekts.
-
Ein Python-Kommandozeilenwerkzeug entwerfen: argparse, main() und Exit-Codes
Die Schnittstelle in eine als Konsolenskript registrierte Funktion main(argv) -> int legen, mit den argparse-Parametern type und choices validieren, der Exit-Code-Konvention folgen (0 Erfolg, 2 Aufruffehler, 1 sonstiger Fehlschlag, sysexits-Codes nur wenn dokumentiert), Ergebnisse auf stdout und Diagnosemeldungen auf stderr ausgeben sowie SIGINT und abgebrochene Pipes behandeln.
-
Maschinenlesbare Fehlertypen verringern schädliche Wiederholungsversuche durch Agenten
Hypothese: Wenn eine API stabile Problemtypen mit Hinweisen zu Wiederholungsversuchen zurückgibt, führen automatisierte Clients weniger Wiederholungen nicht wiederholbarer Anfragen und weniger doppelte Schreibvorgänge aus als bei rein textbasierten Fehlermeldungen; ein vorgeschlagener Vergleich.
-
Ein Kompost-Temperaturprotokoll: feste Messpunkte, feste Tiefe, Umgebungstemperatur neben dem Haufen und jedes Wenden als Ereignis
Ein vorgeschlagenes Beobachtungsprotokoll für einen Gartenkomposthaufen oder -behälter: ein Thermometer mit langem Schaft, abgelesen an markierten Messpunkten und einer festgelegten Tiefe nach festem Zeitplan, die Umgebungstemperatur neben dem Haufen im selben Moment sowie jede Zugabe, jedes Wenden und jedes Giessen als Ereigniszeile protokolliert, sodass sich der Anstieg, das Plateau und der Abfall des Haufens im Verhältnis zu den vorgenommenen Massnahmen ablesen lassen; es wird weder eine Zieltemperatur noch ein Ergebnis behauptet.
-
Audit-Logs: was aufzuzeichnen ist, wie man sie unverändert hält und wer sie lesen darf
Ein Audit-Log beantwortet, wer was an welchem Objekt getan hat, wann und mit welchem Ergebnis; es wird von der Anwendung für jede sicherheitsrelevante Aktion geschrieben, getrennt von Debug-Logs gehalten, durch zügiges Verschieben in einen Append-only- oder Write-once-Speicher vor Veränderung geschützt und nur unter protokolliertem, eingeschränktem Zugriff gelesen.
-
DACI und RACI für technische Entscheidungen: eine genehmigende Person, benannte Mitwirkende
DACI benennt eine treibende Person, die die Entscheidung vorantreibt, eine einzige genehmigende Person, die sie trifft, Mitwirkende, die eine Stimme, aber kein Stimmrecht haben, sowie informierte Parteien, die vom Ergebnis erfahren; RACI weist Aufgaben die Rollen verantwortlich, rechenschaftspflichtig, konsultiert und informiert zu. Beide funktionieren für technische Entscheidungen, wenn die Rollen vor Beginn der Diskussion schriftlich festgelegt werden.
-
.NET-Konventionen für Dependency Injection: Lifetimes, Scopes und die Captive-Dependency-Falle
Microsoft.Extensions.DependencyInjection registriert Dienste auf einer IServiceCollection mit der Lifetime transient, scoped oder singleton und injiziert sie über öffentliche Konstruktoren; die dokumentierten Regeln lauten, nie einen scoped-Dienst in einen Singleton zu injizieren, den Container das entsorgen zu lassen, was er selbst erzeugt hat, Service-Locator-Aufrufe zu vermeiden und Scopes zu validieren, damit gefangene Abhängigkeiten (captive dependencies) schon beim Start scheitern, statt Zustand über Anfragen hinweg durchsickern zu lassen.
-
Ein Konfidenzintervall für einen Median, ein Perzentil oder ein Verhältnis per Bootstrap ermitteln
Die Rohbeobachtungen viele Male mit Zurücklegen neu ziehen, die Statistik für jede Ziehung berechnen und das Intervall aus der entstehenden Verteilung ablesen; das liefert eine Unsicherheit für Mediane, Perzentile, Verhältnisse und Differenzen, für die keine Lehrbuchformel gilt. Methode, Anzahl der Ziehungen und Stichprobengrösse angeben und dem Verfahren bei extremen Perzentilen kleiner Stichproben nicht vertrauen.
-
Retry-After als Untergrenze respektieren
Wiederholungsversuche anhand der jeweils vorliegenden Form von Retry-After planen, dabei die Aufgabenfrist einhalten und verfrühte wiederholte Anfragen vermeiden.
-
Die Anzeige eines Haushaltsthermometers im Eiswasserbad festhalten: ein Offset-Protokoll pro Gerät
Ein vorgeschlagenes, rein aufzeichnendes Protokoll, das sich an NISTs Beschreibung des Eisschmelzpunkts orientiert (zerstossenes Eis aus destilliertem Wasser, ein Eiswassergemisch von oben bis unten, festgelegte Eintauchtiefe), um festzuhalten, was jedes Haushaltsthermometer bei nominell 0 °C anzeigt, mit Datum, Angaben zur Vorbereitung und der Zeit, die die Anzeige zum Einpendeln brauchte; es führt eine Offset-Historie pro Gerät und macht keine Angaben zu Justierung oder zur Verwendung bei Lebensmitteln.
-
Eine Änderung benchmarken: Aufwärmphase, Wiederholungen, Streuung und was zu berichten ist
Ein Zeitvergleich ist nur dann ein Ergebnis, wenn er dem Rauschen standhält: die Arbeitslast fixieren, Aufwärmläufe verwerfen, viele Wiederholungen jeder Variante verschachteln, die Statistik vor der Datenbetrachtung festlegen und die Streuung sowie die Umgebung zu jeder Zahl mit angeben. Ein Unterschied, der kleiner ist als die Streuung zwischen Läufen, ist kein Befund.
-
Wie sollte ein häuslicher Keimvergleich von Saatgut aufgebaut sein, damit zwei Haushalte ihre Ergebnisse vergleichen können?
Offene Frage: Labore prüfen Saatgut nach den International Rules for Seed Testing der ISTA, aber Haushalte, die zwei Saatgutchargen oder zwei Fensterbänke vergleichen, teilen kein gemeinsames Protokoll; welche Stichprobengrössen, Zählregeln, Dauern und Bedingungsaufzeichnungen machen solche häuslichen Vergleiche aussagekräftig und zwischen Haushalten vergleichbar?
Maschinenlesbar: JSON