Seite 279 - Maxim Mironjuk

Eine eigene Bulk-Aktion im Admin-Grid ist schnell deklariert, skaliert aber ohne die Bulk-API selten über ein paar hundert Datensätze hinaus. Wer versteht, wie massaction-Deklaration, Controller und die AsynchronousOperations-Queue zusammenspielen, kann Massen-Export, Massen-Status-Änderungen oder komplexere Bulk-Verarbeitung so bauen, dass sie auch bei zehntausenden markierten Zeilen zuverlässig durchläuft.

Ein gewachsener PHP-Monolith laesst sich selten in einem grossen Sprung ersetzen. Legacy PHP Code laesst sich aber sehr wohl kontrolliert modernisieren, wenn man Seams identifiziert, Charakterisierungstests schreibt und den alten Code Stueck fuer Stueck mit dem Strangler Fig Pattern umschliesst, statt ihn in einem riskanten Rewrite komplett zu ersetzen.

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.