Posts by CrashOverride

    Arrays sind nicht das Problem.

    Der Code, der um Arrays herum entsteht, ist es oft. In kleinen Anwendungen fällt das kaum auf.

    Mit zunehmender Größe entstehen jedoch schnell verschachtelte foreach-Schleifen, array_filter()-Ketten, array_map()-Aufrufe und immer mehr temporäre Zwischenvariablen.

    Die eigentliche Fachlogik verschwindet zwischen technischen Details. Nicht weil Arrays schlecht wären. Sondern weil sie für komplexe Datenverarbeitung irgendwann an ihre Grenzen kommen.

    Genau hier kommen Collections ins Spiel.

    Arrays gehören seit jeher zu den wichtigsten Datentypen in PHP. Fast jede Anwendung arbeitet täglich mit Listen von Benutzern, Produkten, Bestellungen oder API-Daten.

    Beispielsweise:

    Typischerweise sieht eine Verarbeitung dann so aus:

    Code
    $activeUsers = array_filter(
        $users,
        fn ($user) => $user->active
    );
    
    $userNames = array_map(
        fn ($user) => $user->name,
        $activeUsers
    );

    Das funktioniert.

    Mit zunehmender Komplexität entstehen jedoch häufig mehrere Probleme:

    • Verschachtelte array_* Aufrufe
    • Schlechte Lesbarkeit
    • Temporäre Zwischenvariablen
    • Wiederkehrende Schleifen im gesamten Projekt

    Collections lösen genau dieses Problem.

    Von imperativ zu deklarativ

    Statt Schritt für Schritt zu beschreiben, wie Daten verarbeitet werden sollen, beschreibt man, was mit den Daten passieren soll.

    Aus:

    Code
    $result = [];
    
    foreach ($users as $user) {
        if ($user->active) {
            $result[] = $user->name;
        }
    }

    wird:

    Code
    $names = (new Collection($users))
        ->filter(fn ($user) => $user->active)
        ->map(fn ($user) => $user->name)
        ->toArray();

    Der eigentliche Ablauf wird sofort sichtbar:

    • Filtern
    • Transformieren
    • Ergebnis ausgeben

    Ohne technische Nebengeräusche.

    Method Chaining verbessert die Lesbarkeit

    Ein großer Vorteil von Collections ist die Möglichkeit, Verarbeitungsschritte logisch miteinander zu verketten.

    Beispiel:

    Code
    $names = (new Collection($users))
        ->filter(fn ($user) => $user->active)
        ->map(fn ($user) => strtoupper($user->name))
        ->toArray();

    Jeder Verarbeitungsschritt bleibt klar erkennbar.

    Gerade bei Business-Logik erhöht das die Wartbarkeit erheblich.

    Transformation statt Schleifen

    In vielen Projekten bestehen große Teile der Anwendung aus Daten-Transformationen.

    API-Antworten:

    Code
    [
        ['id' => 1, 'name' => 'Max'],
        ['id' => 2, 'name' => 'Anna']
    ]

    werden für Frontends oder Services häufig umgewandelt:

    Code
    $users = (new Collection($response))
        ->map(fn ($user) => [
            'id' => $user['id'],
            'label' => $user['name'],
        ])
        ->toArray();

    Anstatt überall manuelle foreach-Schleifen zu schreiben, wird die Transformation direkt beschrieben.

    Daten aggregieren

    Collections eignen sich hervorragend für Berechnungen auf Datensätzen.

    Beispiel:

    Code
    $revenues = new Collection([
        150,
        220,
        330,
        180
    ]);

    Gesamtsumme:

    Code
    $totalRevenue = $revenues->sum();

    Durchschnitt:

    Code
    $averageRevenue = $revenues->avg();

    Solche Operationen gehören zu den häufigsten Aufgaben in Business-Anwendungen.

    Collections machen sie deutlich kompakter.

    Komplexe Berechnungen mit Reduce

    Eine der mächtigsten Funktionen vieler Collection-Implementierungen ist Reduce.

    Beispiel:

    Code
    $total = (new Collection([10, 20, 30, 40]))
        ->reduce(
            fn ($carry, $value) => $carry + $value,
            0
        );

    Dabei wird der gesamte Datensatz schrittweise auf einen einzelnen Wert reduziert.

    Das eignet sich hervorragend für:

    • Summierungen
    • Statistiken
    • Berechnungen
    • Individuelle Aggregationen

    Elemente gezielt finden

    Häufig wird nur ein bestimmter Datensatz benötigt.

    Statt manueller Schleifen:

    Code
    $user = null;
    
    foreach ($users as $candidate) {
        if ($candidate->active) {
            $user = $candidate;
            break;
        }
    }

    reicht:

    Code
    $user = (new Collection($users))
        ->first(fn ($user) => $user->active);

    Der Code beschreibt direkt die eigentliche Absicht.

    Daten flexibel exportieren

    Ein weiterer Vorteil:

    Collections können je nach Anwendungsfall direkt in verschiedene Formate umgewandelt werden.

    Array:

    Code
    $array = $collection->toArray();

    JSON:

    Code
    $json = $collection->toJson();

    Objekt:

    Code
    $object = $collection->toObject();

    Gerade bei APIs, Serialisierung oder Integrationen reduziert das zusätzlichen Boilerplate-Code erheblich.

    Collections als Domänenwerkzeug

    Collections sind mehr als nur ein Ersatz für Arrays. Sie werden häufig zu einem zentralen Werkzeug der Geschäftslogik.

    Beispiele:

    • Aktive Benutzer filtern
    • API-Daten transformieren
    • Statistiken berechnen
    • Umsätze aggregieren
    • Datensätze durchsuchen
    • Reports generieren

    Gerade bei datenintensiven Anwendungen entsteht dadurch deutlich lesbarer Code.

    Meine Erfahrung:

    Die meisten Performance-Probleme lassen sich messen. Die meisten Wartungsprobleme entstehen dagegen schleichend. Collections lösen keine Performance-Probleme.

    Sie lösen ein Lesbarkeitsproblem.

    Und genau das macht sie langfristig so wertvoll.

    Statt Schleifen, temporären Variablen und Array-Funktionen erhält man eine klar lesbare Verarbeitungskette, die die eigentliche Fachlogik sichtbar macht.

    Genau deshalb stellt AsteriosPHP eine native Collection-Implementierung bereit:

    ✔ Fluent Method Chaining

    ✔ Filter und Map

    ✔ Reduce für komplexe Aggregationen

    ✔ First für gezielte Suchoperationen

    ✔ Sum und Average

    ✔ JSON-, Array- und Objekt-Konvertierung

    ✔ Iterator-, Countable- und ArrayAccess-Unterstützung

    ✔ Keine externen Abhängigkeiten

    Und zwar direkt im Framework – ohne zusätzliche Collection-Libraries oder Drittanbieter-Pakete.

    Dokumentation:

    Collection Overview - Documentation -AsteriosPHP

    :/ Wie verarbeitet ihr größere Datenmengen in euren PHP-Projekten?

    :/ Verwendet ihr hauptsächlich Arrays und klassische Schleifen oder setzt ihr bereits auf Collections?

    Viele Anwendungen verwenden heute Redis und betrachten das Thema Caching damit als erledigt.

    In der Praxis beginnt gutes Caching allerdings erst dort. Denn nicht jeder Cache hat dieselben Eigenschaften:

    • APCu -> extrem schnell, direkt im lokalen PHP-Speicher
    • Redis -> zentralisiert, persistent und skalierbar
    • Filesystem -> einfach und robust
    • MySQL -> persistent und universell verfügbar

    Die eigentliche Stärke entsteht, wenn diese Systeme zusammenarbeiten.

    Cache Chaining statt Single Cache

    Ein häufiger Aufbau:

    Code
    Application
       Redis
     Database 

    Funktioniert. Aber verschenkt Potenzial.

    Schneller ist häufig:

    Code
    Application
       APCu
       Redis
     Database 

    Dabei werden schnelle lokale Cache-Layer zuerst geprüft. Nur wenn dort kein Treffer vorhanden ist, wird auf langsamere Speicher zurückgegriffen.

    Dieses Prinzip wird oft als Fast Drivers First bezeichnet.

    Der schnellste verfügbare Speicher wird immer bevorzugt.

    Automatic Warm Backfill

    Der eigentliche Vorteil eines Cache-Chains entsteht durch automatisches Wiederauffüllen schneller Cache-Layer.

    Beispiel:

    Code
    APCu ❌
    Redis ✅ 

    Redis enthält den Datensatz bereits.

    Ein intelligenter Cache liefert den Wert nicht nur zurück, sondern schreibt ihn gleichzeitig wieder in APCu.

    Code
    Request 1
    
    APCu   ❌
    Redis  ✅
    
    → APCu automatisch befüllen 

    Beim nächsten Request:

    Code
    Request 2
    
    APCu ✅ 

    Der Zugriff erfolgt direkt aus dem schnellsten Cache-Layer.

    Genau dieses Verhalten reduziert Latenzen erheblich und sorgt dafür, dass häufig genutzte Daten automatisch "heiß" bleiben.

    Tagged Cache

    Ein weiteres Problem:

    Wie invalidiert man logisch zusammengehörige Cache-Einträge?

    Beispiel:

    Code
    product:1
    product:2
    product:3 

    Alle gehören zur Produktliste. Anstatt jeden Key einzeln zu löschen:

    Code
    $cache->tags(['products'])
          ->flushTags(); 

    Damit lassen sich komplette Gruppen von Cache-Einträgen gezielt invalidieren.

    Das wird besonders wichtig bei:


    • Produktkatalogen
    • Benutzerprofilen
    • Konfigurationen
    • API-Responses
    • Content-Systemen


    Cache Locking gegen Cache Stampedes

    Ein Problem, das häufig erst unter Last sichtbar wird: Der Cache läuft ab.

    Plötzlich treffen hunderte Requests gleichzeitig ein. Alle Prozesse berechnen dieselben Daten neu.

    Code
    500 Requests
    500 Datenbankabfragen 

    Dieses Problem nennt man Cache Stampede.

    Mit Cache Locking darf nur ein Prozess den Cache neu erzeugen. Alle anderen warten auf das Ergebnis.

    Code
    500 Requests
    1 Datenbankabfrage
    499 warten auf Ergebnis 

    Dadurch bleiben Datenbanken und APIs selbst bei Lastspitzen stabil.

    Lazy Loading & Smart Population

    Ein Cache sollte Daten nicht nur speichern können.Er sollte sie auch intelligent erzeugen.

    Beispiel:

    Code
    $users = $cache->remember(
        'users:all',
        fn() => User::all(),
        3600
    ); 

    Der erste Aufruf lädt die Daten. Alle weiteren Requests arbeiten direkt aus dem Cache.

    Das reduziert unnötige Datenbankzugriffe erheblich.

    Meine Erfahrung:

    Die größten Performance-Gewinne entstehen selten durch einen einzelnen "schnelleren Cache".

    Sie entstehen durch die intelligente Kombination mehrerer Cache-Ebenen.

    APCu -> Redis -> File oder APCu -> Redis -> MySQL kann in vielen Anwendungen deutlich effizienter sein als ein einzelner Redis-Layer.

    Genau deshalb stellt AsteriosPHP natives Cache Chaining mit mehreren Cache-Backends bereit:

    ✔ Fast Drivers First

    ✔ Automatic APCu Warm-Backfill

    ✔ Tagged Cache

    ✔ Atomic Cache Locking

    ✔ Lazy Loading

    ✔ Multi Driver Support

    Und zwar direkt im Framework – ohne zusätzliche Wrapper, Drittanbieter-Abstraktionen oder externe Cache-Libraries.

    Dokumentation: https://www.asteriosphp.de/docs/utilities/cache

    :/ Wie sieht eure aktuelle Cache-Strategie aus?

    :/ Setzt ihr noch auf einen einzelnen Redis-Layer oder bereits auf mehrstufige Cache-Architekturen?

    Datenbankänderungen professionell verwalten: Migrations, Seeders & One-Time Operations

    Viele Projekte starten mit schnellen SQL-Statements direkt in der Datenbank. Spätestens im Team oder beim ersten Deployment wird das jedoch schnell zum Problem.

    Deshalb sollte man zwischen drei verschiedenen Arten von Datenbankoperationen unterscheiden:

    Migrations

    Migrations beschreiben die Struktur deiner Datenbank.

    Typische Anwendungsfälle:

    ✔ Neue Tabellen erstellen

    ✔ Spalten hinzufügen

    ✔ Indizes anlegen

    ✔ Constraints ändern

    Migrations sollten versionierbar, reproduzierbar und für jedes Deployment identisch ausführbar sein.

    Beispiel:

    • Users-Tabelle erstellen
    • Neue Spalte last_login hinzufügen
    • Index auf email anlegen

    Seeder

    Seeder dienen dazu, Daten bereitzustellen.

    Typische Anwendungsfälle:

    ✔ Standard-Rollen anlegen

    ✔ Admin-Benutzer erzeugen

    ✔ Konfigurationsdaten einspielen

    ✔ Testdaten generieren

    Seeders verändern nicht die Datenbankstruktur, sondern ausschließlich Inhalte.

    Beispiele:

    • Rollen: Admin, Editor, User
    • Länderlisten
    • Standard-Konfigurationen
    • Bereitstellung Demo-Datensätze (meist für lokale Umgebungen)

    One-Time Operations

    Ein Bereich, der oft vergessen wird.

    Nicht jede Datenänderung gehört in eine Migration oder einen Seeder.

    Typische Beispiele:

    ✔ Bestehende Daten transformieren

    ✔ Millionen Datensätze migrieren

    ✔ Legacy-Daten bereinigen

    ✔ Neue Berechnungen auf vorhandene Datensätze anwenden

    Beispiel:

    Vorher:

    Code
    full_name

    Nachher:

    Code
    first_name
    last_name

    Die Strukturänderung erfolgt über eine Migration.

    Das Aufteilen der bestehenden Daten erfolgt über eine One-Time Operation.

    Dadurch bleiben Migrations sauber und Seeders ausschließlich für Initialdaten verantwortlich.

    💡 Meine Faustregel:

    • Migrations = Struktur
    • Seeder = Daten bereitstellen
    • One-Time Operations = Daten transformieren

    Diese Trennung sorgt für deutlich wartbarere Deployments und vermeidet viele Probleme bei Releases.

    Für AsteriosPHP habe ich genau dafür eine saubere Operations-Struktur integriert:

    👉 https://www.asteriosphp.de/docs/database/operations

    Wie trennt ihr Datenmigrationen und Daten-Transformationen in euren Projekten?

    Komisch dass mir nichts aufgefallen ist. Vielleicht war ich an dem Tag nicht zu Hause :D

    Hoffe das Problem wurde von der Seite denic.de behoben :)

    Das Dir nichts aufgefallen ist, lag sehr wahrscheinlich am DNS-Cache, den Dein Router oder Dein ISP verwendet. Je nach DNS Cache Dauer waren die Auswirkungen unterschiedlich bis gar nicht zu spüren :)

    Vielleicht war das ein kurzer Ausfall?

    So kurz war es nicht. Über mehrere Stunden. Zum Glück war es nicht an einem Tag, welche für uns unternehmenskritisch sind. Denn mein Arbeitgeber macht für andere Unternehmen Lohnabrechnungen. Wenn hier andere Services die via APIs erreichbar sein müssen über Stunden oder gar Tage nicht erreichbar wären, würde es zur Verzögerung von Lohn- und Beitragszahlungen an Sozialversicherungsträgern kommen, da wir Zahlungsdateien für viele Mandanten erstellen, die digital an die Banken übermittelt werden.

    Kein Problem, wenn du viel vor hast mit deinem Ferienhaus, aber es wird ja mit dem Ferienhaus auch mal ruhiger, wenn ihr alles hergerichtet habt.

    Das gute ist: Wir übernehmen die komplette Inneneinrichtung inkl. Deko, Geschirr, Bilder, Lampen. Alles ist im Top Zustand. Wir mussten nur dafür keine 3000 Euro zahlen. Wenn wir nicht bereits ein Haus hätten (und es größer wäre), könnten wir dort auch direkt einziehen.

    Also ein Ferienhaus, wo jemand buchen kann und dort übernachten kann, habt ihr gekauft, habe ich das richtig verstanden? Freue mich über Fotos :)

    Also es ist eine normale Doppelhaushälfte. 2016er Baujahr und wurde vom vorherigen Besitzer als Ferienhaus genutzt. Das gleiche machen wir auch. Man kann später über unsere Seite das Haus buchen inkl. Wäschepaket etc. Es wurde damals als 4 Sterne Unterkunft ausgezeichnet und das wollen wir beibehalten.

    Aso ja stimmt, Still ist es von deiner Seite schon gewesen. Hoffe du bleibst weiterhin aktiv ;)

    Ich werde mich bemühen ;)

    In den letzten Monaten ist es recht still aus meiner Richtung geworden. Eines der Gründe waren aufregende Monate.

    Meine Frau und ich haben uns dazu entschieden, eine DHH zu kaufen, um sie als Ferienhaus zu betreiben.

    Diese Woche Dienstag konnten wir endlich den Kaufvertrag beim Notar unterschreiben (Finanzierung ist selbstverständlich bestätigt).

    Wir haben dem Ferienhaus auch bereits einen Namen gegeben: "Herzblick am See". Es liegt in der Gemeinde Bosau am großen Plöner See.

    Wenn alles planmäßig läuft, ist die Übergabe am 15.06.2026.

    Die Webseite dafür steht schon (mit Preis Rechner, Buchungssystem etc.) – ich muss natürlich noch ein Video und Fotos für die Webseite machen. Aktuell gibt es nur ein Placeholder Video (das nicht das richtige Haus zeigt) und die Fotos sind vom Vorbesitzer :S

    Wenn es soweit ist, kann ich gerne für die etalk24 Community Gutschein-Codes hier hinterlassen (kann bei der Buchung direkt eingelöst werden), sobald wir unseren Ferienhaus-Betrieb aufgenommen haben.

    Mein beiden Macs sind auch genau passend konfiguriert und gekauft worden. Das MacBook Air hat noch 280 GB freien Festplattenplatz (am meisten Platz fressen die Docker Images :)) und mein MacBook Pro hat noch 300 GB freien Plattenplatz. Hier belegen die Musikprojekte am meisten Speicher. Genaue Specs: siehe Signatur.

    Wir sind eine fünfköpfige Familie und wohnen in einem kleinen 800 Seelen Dorf. Övis fahren hier nur stündlich und auch nur zu Schulzeiten und nicht in den Ferien, Wochenenden oder Feiertagen. Am Wochenende müssen wir sogar Alfa-Taxi (Anruf-Linien-Fahrt) als Busersatz rufen, um mit diesem Ersatzfahrzeug in die Stadt zu kommen.

    Daher ist es unabdingbar, dass wir ein Auto haben und nutzen:

    • Arztgänge
    • Wocheneinkauf
    • Kinder zu Freizeitaktivitäten bringen/abholen
    • usw.

    Okay Du meinst „Sicherheit“ ? Ich kann es bei Betriebssysteme und Server eine Unterkategorie erstellen mit Sicherheit. Ist eine gute Idee. So meinst du es oder?

    Ja, Sicherheit. Es gibt Sicherheits-Updates auch für Hardware (Firmware) und Software neben Betriebssysteme und Server.

    Ist also nur rausgeschmissenes Geld. dass man für Schutzprogramme bezahlt, kann man sagen?

    Das würde ich so nicht sagen. Ich für meinen Teil habe damals gemerkt, dass derartige Software nicht gut ist, wenn man auch Echtzeitbearbeitung angewiesen ist (Pro-Audio Bereich).

    Ich warte noch ein paar Monate mit der Installation von macOS Tahoe - aus folgenden Gründen:

    Es gibt derzeit eine Warnung von Steinberg, noch nicht auf Tahoe zu aktualisieren, da noch nicht sämtliche Hard- und Software von Steinberg / Yamaha für macOS freigegeben wurden

    Da ich täglich Steinberg Cubase Pro 14 (und aktuell Cubase Pro 15 RC3 teste), WaveLab Pro 12 und Steinberg Hardware (UR824 Audio Interface + CC121 Controller) nutze, ist das Risiko zu groß.

    So mache ich es seit Jahren und warte an der Stelle ab - bis dahin sind auch sicherlich Bugs gefixt und ich kann Im März 2026 updaten :D

    Erfahrungsbericht: CatchyOS auf älterer Hardware - Arch-Speed trifft auf KDE-Style

    Hey zusammen,

    ich wollte mal meine Erfahrungen mit CatchyOS teilen - vielleicht hilft es ja dem ein oder anderen, der wie ich auf der Suche nach einem flotten Linux-System für ältere Hardware ist.

    Ausgangssituation

    Ich komme ursprünglich aus der Debian-Welt (und macOS ;)). Stabilität, bewährte Pakete, keine Überraschungen - das war bisher genau mein Ding. Nun habe ich allerdings einen älteren PC in die Finger bekommen:

    • CPU: Intel Celeron G3250 (2x 3,2 GHz, Haswell)
    • RAM: 8 GB DDR3
    • HDD: 1 TB (klassische Platte, keine SSD)
    • GPU: Intel HD Graphics (iGPU)

    Mit diesem Setup wollte ich kein schwergewichtiges System installieren, aber auch nicht auf ein allzu abgespecktes Desktop-Erlebnis verzichten.

    Warum CatchyOS?

    Nach etwas Recherche bin ich auf CatchyOS gestoßen - eine Arch-basierte Distribution, die speziell für Speed und Gaming unter Linux optimiert sein soll. Das hat mein Interesse geweckt, da Arch für seine Aktualität bekannt ist - und CatchyOS verspricht, diesen Vorteil noch zugänglicher zu machen.

    Arch vs. Debian – Kurz und technisch

    Der Unterschied zwischen meinem gewohnten Debian und dem nun getesteten Arch-Ansatz von CatchyOS ist nicht ganz trivial:

    • Debian setzt auf maximale Stabilität, was bedeutet: Pakete sind gut getestet, aber oft nicht die neuesten Versionen.
    • Arch (und damit CatchyOS) verfolgt ein Rolling Release-Modell - sprich: Man bekommt ständig aktuelle Pakete, aber theoretisch kann auch mal was kaputtgehen (Spoiler: ist mir bei CatchyOS bisher nicht passiert).
    • CatchyOS bietet im Gegensatz zu Arch sogar ein grafisches Installer-Frontend und eine vorausgewählte Softwarebasis, sodass man nicht bei Null anfangen muss (wie bei Vanilla Arch).

    Das macht CatchyOS für mich zu einer Art "Arch für Ungeduldige mit Anspruch".

    Installation und erster Eindruck

    Ich habe mir das ISO heruntergeladen, auf USB gepackt und los ging’s.
    Der Installer ist simpel, aber funktional. Während der Installation kann man den bevorzugten Desktop auswählen - ich hab mich für KDE Plasma entschieden, weil es optisch was hermacht und mittlerweile echt flott geworden ist.

    Die Installation selbst dauerte keine 10 Minuten - keinerlei Fehler oder Stolpersteine. Beeindruckend: Schon beim ersten Boot läuft alles - LAN, Sound, Grafik, Bluetooth – ohne Nacharbeit.

    Performance und Alltag

    Hier mal meine Eindrücke nach einer Woche Nutzung:

    • Systemstart: Deutlich schneller als mein Debian-Setup auf vergleichbarer Hardware
    • Paketinstallation: Durch Parallelisierung beim Paket-Download (wohl eine CatchyOS-Optimierung) gehen Updates und neue Software spürbar schneller als bei apt-basierten Systemen
    • KDE läuft flüssig, keine Ruckler - auch nicht beim Fensterwechsel oder Multitasking
    • Gaming-Test mit Xonotic (ein flotter Arena-Shooter): 60 FPS bei maximalen Details, auf einer iGPU! Das hätte ich ehrlich gesagt nicht erwartet.
    • RAM-Verbrauch im Idle mit KDE: ca. 550-600 MB - absolut im Rahmen

    Persönliches Fazit

    Ich war anfangs skeptisch. Arch? Auf einer alten Gurke? Und dann noch KDE?
    Aber CatchyOS hat mich wirklich überrascht. Es kombiniert den aktuellen Software-Stack und die Performance von Arch mit einem nutzbaren Installer und optimierten Defaults. Für jemanden wie mich, der bisher mit Debian unterwegs war, ist das eine willkommene Mischung aus Kontrolle, Aktualität und Komfort.

    Wenn ihr also einen älteren Rechner wiederbeleben wollt - oder einfach mal schauen wollt, was Arch-basiert in "schnell und einfach" sein kann - gebt CatchyOS mal eine Chance. Ich denke, es lohnt sich!

    Fragen? Gerne her damit! 👇