Seite 7 - Monthly Archives: April 2025

Wenn ein Client hunderte Entitäten anlegen oder aktualisieren muss, sind hunderte einzelne HTTP-Requests ineffizient, sowohl für den Netzwerk-Overhead als auch für die Serverlast. Ein gut designter Bulk-Endpoint reduziert diesen Overhead drastisch, bringt aber eine eigene Design-Herausforderung mit sich: Wie wird kommuniziert, wenn einige Elemente eines Batches erfolgreich sind und andere fehlschlagen?

Sobald eine Expo-Router-App über eine einzelne Tab-Leiste hinauswächst, stellt sich unweigerlich die Frage, wie Header, Tab-Bars und andere gemeinsame UI-Elemente über mehrere Routen-Ebenen hinweg konsistent bleiben, ohne dass jeder einzelne Screen dieselbe Konfiguration wiederholt. Verschachtelte _layout-Dateien lösen genau dieses Problem, indem sie wie React-Komponenten ineinander greifen und dabei jede Ordnerebene um einen eigenen Navigator erweitern können. Dieser Artikel zeigt, wie diese Verschachtelung in der Praxis funktioniert, wie Modal-Präsentation dateibasiert gesteuert wird und wie eine Tab-Navigation mit einem modalen Detail-Screen darüber konkret aufgebaut wird.

Seit AI Overviews auf immer mehr Suchanfragen erscheinen, verlieren klassische Click-Through-Rate-Werte aus der Search Console spürbar an Aussagekraft. Eine Position 1 mit früher zehn Prozent CTR kann heute trotz unveränderter Rankingposition deutlich weniger Klicks bringen, ohne dass die Search Console diesen Effekt sauber ausweist. Dieser Artikel zeigt, warum die Verzerrung entsteht, mit welchen Behelfslösungen sich der reale Effekt annähern lässt und wo die aktuelle Messbarkeit an harte Grenzen stößt.

Structured Clone kopiert Daten standardmaessig bei jedem postMessage-Aufruf, was bei grossen Binaerdaten spuerbar Zeit kostet. Transferable Objects loesen das durch einen Ownership-Wechsel statt einer Kopie. Dieser Artikel zeigt die Transfer-Liste von postMessage, das neuere ArrayBuffer.prototype.transfer() und typische Fehlerquellen mit detached Buffers.

"Staging Area" ist nur ein Spitzname. Dahinter steckt eine reale, binäre Datei mit dokumentiertem Format, eigener Prüfsumme und Stage-Nummern pro Eintrag. Dieser Artikel geht direkt in die Internals: Dateiformat, was git add technisch schreibt, wie git status und git diff den Index als Angelpunkt nutzen, wie man ihn mit git ls-files und git update-index direkt inspiziert und manipuliert, und warum git add -p überhaupt nur funktioniert, weil der Index vom Working Directory entkoppelt ist.

Claude und ChatGPT lösen viele Programmieraufgaben mittlerweile ähnlich gut, unterscheiden sich aber deutlich bei Kontextverarbeitung, agentischem Tool-Use in der Kommandozeile und der Integration in bestehende Entwicklungs-Workflows. Dieser Vergleich zeigt konkrete, praxisrelevante Unterschiede statt pauschaler Bewertungen und hilft Teams bei einer begründeten Werkzeugwahl.

Wer im Incident wahllos Konfigurationen ändert und Dienste neu startet, verlängert die Downtime und produziert widersprüchliche Spuren für die Ursachenanalyse. Ein fester Ablauf aus Verfügbarkeitsprüfung, Änderungsabgleich, Ressourcenchecks und systematischer Log-Analyse führt schneller zur Ursache, liefert nachvollziehbare Dokumentation für das Postmortem und macht klar, wann eskaliert werden sollte, statt endlos allein weiterzugraben.

Die Standardansicht eines Pull Requests zeigt fast immer nur den kumulierten Diff zwischen Ziel-Branch und letztem Commit. Damit geht verloren, wie eine Änderung tatsächlich entstanden ist: ob sie in einem sauberen, atomaren Commit entstand oder erst über mehrere Korrekturrunden zur finalen Form fand. Dieser Artikel zeigt, wie sich mit git log, git show, git range-diff und gezieltem interaktivem Rebase eine Commit-Historie vor dem Merge tatsächlich prüfen lässt, statt sich allein auf das Endergebnis zu verlassen.

Der Profiler-Tab der React DevTools zeigt bei jedem Commit einen Flame Graph, aber die Faerbung allein sagt wenig aus. Wer Commit-Dauer, Ranked Chart und die Why-did-this-render Anzeige richtig kombiniert, findet echte Bottlenecks statt an Symptomen zu doktern.

Doctrine bringt zwei grundverschiedene Cache-Mechanismen mit, die auf den ersten Blick beide dasselbe Ziel verfolgen, nämlich weniger Last auf der Datenbank, aber strukturell komplett unterschiedlich arbeiten. Der Query Result Cache merkt sich das fertige Ergebnis einer konkreten Abfrage, während der Second-Level Cache einzelne Entities unabhängig von der Abfrage, die sie ursprünglich geladen hat, vorhält. Wer beide Mechanismen verwechselt, baut entweder eine Caching-Schicht, die bei jeder Schreiboperation veraltete Daten ausliefert, oder eine, die viel zu aufwendig für das eigentliche Problem ist. Dieser Artikel klärt die Unterschiede an konkreten Beispielen und zeigt, wie man Cache-Invalidierung sauber umsetzt.