Seite 255 - Mironsoft Blog

Natives CSS-Nesting erlaubt es, verschachtelte Selektoren direkt im Stylesheet zu schreiben, ohne Präprozessor. Jede zusätzliche Verschachtelungsebene erhöht dabei aber automatisch die Spezifität des zusammengesetzten Selektors und die Zahl der Zeichen, die der Browser beim Parsen und Matching verarbeiten muss, was ab einer bestimmten Tiefe echte Wartbarkeits- und Performance-Konsequenzen hat.

Ein Varnish-, Redis- und OpenSearch-Sidecar mit Standard-Konfiguration läuft, aber liefert selten die Performance, die ein Magento-Shop unter echter Last braucht. Dieser Artikel zeigt, wie diese drei Sidecars als Container gezielt feingetunt werden, von VCL-Regeln über Eviction-Policies bis zur JVM-Heap-Dimensionierung, statt sich auf die Werksvorgaben zu verlassen.

Redis kennt von Haus aus kein natives Konzept für Mandantenfähigkeit, weshalb jedes Multi-Tenant-Setup eine bewusste architektonische Entscheidung erfordert. Drei Ansätze stehen dabei typischerweise zur Wahl: präfix-basierte Namensräume innerhalb einer gemeinsamen Datenbank, logische Datenbanken über den klassischen SELECT-Index, oder vollständig getrennte Instanzen pro Mandant. Alle drei unterscheiden sich deutlich in Isolationsgrad, Backup-Granularität und Skalierbarkeit. Dieser Artikel vergleicht die drei Strategien anhand konkreter Kriterien und leitet daraus eine praktische Empfehlung für Multi-Store-Magento-Setups ab, in denen mehrere Store-Views denselben Cache-Layer nutzen sollen.

Redis übernimmt in Magento gleich drei Rollen: Session-Speicher, Object-Cache-Backend und optional Full-Page-Cache. Wer alle drei Rollen in derselben Datenbank ablegt, riskiert Tag-Kollisionen, unnötige Cache-Flushes und im schlimmsten Fall abgemeldete Kunden durch verlorene Sessions. Dieser Artikel zeigt, wie Redis in Magento korrekt konfiguriert, überwacht und vor Speicherüberlauf geschützt wird.

Jedes Docker-Image beginnt mit einem Basis-Image, dem das gesamte Team blind vertraut, meist basierend auf einem Tag wie latest oder einer Versionsnummer ohne weitere Prüfung. Supply Chain Security ersetzt dieses blinde Vertrauen durch gepinnte Digests, kryptographische Signaturen und nachvollziehbare Provenance-Informationen, damit ein kompromittiertes Basis-Image nicht unbemerkt in produktiven Deployments landet.

Ein Build-Job auf Production ist kein Deployment – er ist ein unkontrolliertes Experiment auf dem Live-System. Artefakte aus isolierten CI-Jobs bringen Reproduzierbarkeit, Geschwindigkeit und Sicherheit gleichzeitig.

Magento 2 stellt PhpStorm vor besondere Herausforderungen: Tausende generierte Klassen, ein riesiger vendor/-Baum, PHPUnit-Tests in mehreren Schichten und phtml-Templates mit gemischter PHP-HTML-Syntax. Die richtige Konfiguration macht den Unterschied zwischen einer trägen IDE und einer präzisen Entwicklungsumgebung.

Sobald eine REST-API ihre erste Breaking Change durchlaufen muss, wird die Frage nach der Versionierungsstrategie unausweichlich, und die drei verbreiteten Ansätze, URL-Pfad-Versionierung, Content Negotiation über den Accept-Header und ein dedizierter Custom-Header, haben grundlegend unterschiedliche Auswirkungen auf Caching, Client-Implementierung, Dokumentation und die tatsächliche Nutzbarkeit für externe Integratoren. Die Entscheidung früh und bewusst zu treffen erspart eine schmerzhafte, meist unvollständige Migration Jahre später, wenn bereits tausende Clients auf der ursprünglichen, unbedacht gewählten Struktur aufbauen.

Ein Jest-Testlauf findet auf Node.js statt und kann weder Swift- noch Kotlin-Code ausführen, trotzdem hängt viel React-Native-Logik direkt von nativen Modulen ab: Kamera, Standort, Biometrie, Push-Benachrichtigungen. Wer diese Abhängigkeiten nicht sauber mockt, landet entweder bei unlösbaren Testfehlern oder bei Tests, die stillschweigend gar nichts prüfen. Dieser Artikel zeigt konkrete Mock-Strategien für native Module in Jest, ein durchgängiges Beispiel mit einem Kamera-Modul, und wo die Grenze zwischen sinnvollem Unit-Test und notwendigem End-to-End-Test tatsächlich verläuft.

Neben der Systemzeit, die der Kernel im Arbeitsspeicher fuehrt, besitzt fast jede physische und virtuelle Maschine eine batteriegepufferte Hardware-Uhr, die auch im ausgeschalteten Zustand weiterlaeuft. Wer den Unterschied zwischen System Clock und Hardware-Uhr nicht kennt, wundert sich frueher oder spaeter ueber falsche Boot-Zeitstempel, verschobene Zertifikatspruefungen oder ein Dual-Boot-System, das nach jedem Windows-Start eine andere Uhrzeit anzeigt. Dieser Artikel erklaert, wie hwclock funktioniert, wie die Hardware-Uhr korrekt eingestellt wird und wie sie sich zuverlaessig mit der System Clock synchronisieren laesst.