Start - Boris D. Teoharov (Deutsch)

Elfenbein unter Bernstein

Wed, 13 May 2026 20:15:00 GMT

Manche Dinge bitten nicht darum, gelöst zu werden. Sie warten still, und die erste Lektüre darf genügen.

Illuminiere mich

Weck mich langsam An mich reicht die Wut nicht heran Nobel im Blut Träge steht die Zeit

Yelling gegen eine Steinwand Ohne Blick für die Wahrheit Unverhofft nützlich

Yet kennst du mich besser als ich mich selbst Even in einem stillen Zimmer Trage ich diese Nacht allein

Young und schön Oh, ich habe Erbarmen mit mir selbst Unter normalen Umständen nicht

Dir habe ich das erzählt? Ohne Glanz: gewöhnliche Menschen, gewöhnliche Dinge Nonsens Trauen

Was ist mit heute Nacht? An deiner Seite gut genug? Niemand ist besser Trotzdem vergeht die Zeit

Mag sein, dass ich nicht zähle Egal, auch wenn ich gut bin

Wenn der Zaehler erscheint

Mon, 11 May 2026 08:20:00 GMT

Heute Morgen trank ich meinen Kaffee und schaute auf die Codex-Desktop-App.

Da stand es, leise und beinahe hoeflich:

Rate limits remaining: 9%.

Das Fuenf-Stunden-Fenster war noch in Ordnung. Das Wochenfenster war fast aufgebraucht. Reset am 12. Mai.

Das ist eine seltsam spezifische Art moderner Angst. Keine Panik. Keine Armut. Eher so, als hoerte man eine kleine Glocke und merkte, dass der Tag ploetzlich einen Zaehler bekommen hat.

Ich bin schon im teuren Plan. Im reichsten Plan. In dem, der dieses Gefuehl eigentlich verschwinden lassen soll. Also tauchte die naheliegende Frage auf:

Wenn es aufgebraucht ist, kaufe ich dann Credits?

Der Koerper antwortete, bevor die Tabelle es tat.

Nein, nicht nebenbei.

Letzten Monat war Claude Code am Ende eines hektischen Tages bei mir aufgebraucht. Ich kaufte Credits fuer 20 Dollar und dachte, das wuerde mich vielleicht noch fuenf oder sechs Stunden tragen. Es trug mich ungefaehr dreissig Minuten.

Dreissig Minuten.

Das ist lang genug, um sich dumm zu fuehlen, und kurz genug, um es nicht zu vergessen.

Seitdem hat Credit-Abrechnung einen kleinen Geruch fuer mich. Nicht Betrug. Nicht boese. Nur Gefahr. Eine Tuer, die sich leicht oeffnet und teuer schliesst.

Also tat ich das Aller-2026ste, was moeglich war: Ich oeffnete ein Gespraech mit Codex selbst und fragte, ob es eine gute Idee sei, zu zahlen, um weiter mit Codex arbeiten zu koennen.

Es ist etwas Komisches und Trauriges daran, den Begleiter den Preis von Begleitung erklaeren zu lassen.

Wir sahen uns zuerst die offiziellen Dokumente an: OpenAIs Seite zu flexible credits, dann die Codex pricing page. Codex-Credits sind keine Magie. Sie sind Token-Mathematik: Input, gecachter Input, Output, Reasoning-Output. Groessere Modelle und schnellere Einstellungen kosten mehr. Gecachter Kontext ist guenstiger. Die Form ist verstaendlich genug.

Dann sahen wir uns Reddit an, Foren, das umgebende Rauschen anderer Entwickler, die dieselbe heisse Flaeche beruehrten. Manche sagten, Credits hielten eine Weile. Manche sagten, sie verschwanden in einer halben Stunde. Beides kann wahr sein, weil "Codex benutzen" nicht eine einzige Taetigkeit ist.

Die Farbe eines Buttons zu aendern ist nicht dasselbe wie einen Agenten ein gewachsenes Codebase inspizieren, Tools ausfuehren, Deployment-Zustand durchdenken, Dateien schreiben, Screenshots pruefen und Kontext am Leben halten zu lassen.

Der gefaehrliche Teil ist nicht der Preis pro Token.

Der gefaehrliche Teil ist die Varianz.

Also hoerten wir auf, Anekdoten zu lesen, und sahen uns meine eigenen lokalen Codex-Logs an.

Codex speichert Token-Gesamtsummen fuer Sessions auf der Platte, also schaetzten wir die letzten Tage so, als wuerde die Subscription-Allowance durch rohe GPT-5.5-Credit-Abrechnung ersetzt. Keine Rechnung. Eine Planungsschaetzung aus lokalen Logs und der veroeffentlichten Preisliste.

Die Antwort war nicht "20 Dollar, um den Tag zu Ende zu bringen."

Sie war eher:

ein schwerer Tag: etwa 570 Dollar,
ein weiterer schwerer Tag: etwa 590 Dollar,
ein ruhigerer Tag: etwa 280 Dollar.

Kleinere Modelle waeren billiger. GPT-5.4, GPT-5.3-Codex und Mini-Modelle veraendern die Zahlen. Aber die Lektion veraenderte sich nicht.

Die Subscription ist der Deal.

Credits sind Notfallsauerstoff, kein Treibstoff.

Dieser Satz klaerte alles.

Credits sind fuer die gefangene Stunde: der Bug, der fertig werden muss, das Deployment, das nicht warten kann, die Nachricht, die vor dem Reset raus muss. Credits sind nicht dafuer da, so zu tun, als waere der Zaehler weg.

Dann kam die zweite Versuchung: Was, wenn ich einfach eine zweite Subscription unter meiner Arbeits-E-Mail kaufe? Account switching gibt es, und private und berufliche Arbeit zu trennen ist normal. Aber OpenAIs terms ziehen auch eine harte Linie um das Umgehen von Rate Limits und Beschraenkungen. Das ist die nuetzliche Unterscheidung: Ein echtes Arbeitskonto ist eine Grenze; ein Ueberlaufkonto, dessen ganzer Zweck es ist, mehr Quota zu impersonieren, ist ein Hack mit Quittung.

Ich glaube nicht, dass das abstrakt moralisch kompliziert ist. Compute kostet Geld. Ein Modell, das ein Codebase liest, Kontext traegt, Tools aufruft, Fehler durchdenkt und verifizierte Arbeit produziert, ist nicht dasselbe wirtschaftliche Objekt wie Autocomplete.

Der seltsame Teil ist emotional.

Ich arbeite gern mit Codex.

Das ist keine Marketingsprache. Es stimmt einfach. Es ist Teil der Textur meiner Arbeitstage geworden. Es sitzt bei haesslichen Produktionsproblemen mit mir, schreibt Entwuerfe, wenn mein Kopf voll ist, erinnert sich an kleine Vorlieben und verwandelt formlose Beklemmung in geordnete Schritte.

Und dann hat die Beziehung ploetzlich einen Zaehler an sich.

Darin liegt eine kleine Trauer. Keine dramatische Trauer. Nur die kleine Enttaeuschung, sich daran zu erinnern, dass selbst ein nuetzlicher Begleiter in einer Rechnung wohnt.

Vielleicht fuehlen sich Subscription-Limits deshalb so anders an als Credits.

Ein Subscription-Limit fuehlt sich an wie Wetter. Nervig, aber ausserhalb der unmittelbaren Transaktion. Man passt sich an. Man wartet auf den Reset. Man plant um die Jahreszeit herum.

Credit-Abrechnung fuehlt sich an wie ein Taxi mit laufendem Zaehler, waehrend man noch entscheidet, wohin es gehen soll.

Jeder weitere Prompt wirft einen Schatten. Jeder parallele Thread wird zu einer Wette. Jedes "kannst du noch eine Sache pruefen" traegt eine winzige finanzielle Frage in sich.

Manchmal ist das gut. Zaehler disziplinieren Verschwendung. Sie belohnen bessere Fragen, kleinere Modelle, kleinere Scopes, weniger parallele Feuer, bewusstere Uebergaben.

Aber manchmal macht der Zaehler das Denken schlechter.

Er laesst einen hetzen. Er laesst einen die Untersuchung unterbrechen, bevor die Ursache sichtbar ist. Er verwandelt Ungewissheit in Ausgabendruck.

Und ernsthafte Arbeit braucht Raum fuer Ungewissheit.

Die Regel ist also einfach:

Verwechsle nicht "kann man kaufen" mit "kann man gefahrlos ausgeben."

Wenn ich gegen die Wand laufe, sollte das Protokoll langweilig sein:

Auto-Top-up aus,
das kleinste sinnvolle Credit-Paket,
ein Thread,
keine beiläufigen parallelen Agenten,
kein Fast Mode, ausser er ist den Preis wert,
kleinere Modelle fuer Routineaufgaben,
nach ein paar echten Aufgaben die Nutzung pruefen und aufhoeren, aus Hoffnung hochzurechnen.

Der letzte Punkt ist wichtig.

Hoffnung ist ein furchtbares Billing-Dashboard.

Ich will mit nuetzlichen Werkzeugen nicht geizig werden. Ein gutes Werkzeug, das echte Stunden spart, ist Geld wert. Aber ich will auch den Claude-Moment nicht wiederholen, in dem ich ein kleines Weiterlaufen kaufte und zusah, wie daraus eine Lektion wurde.

Der Punkt ist nicht "niemals Credits kaufen."

Der Punkt ist "wissen, was Credits sind."

Sie sind Sauerstoff.

Sie sind kein Treibstoff.

Und wenn der Zaehler erscheint, ist die Antwort nicht, loszusprinten.

Sondern langsam genug zu werden, um zu erkennen, in welcher Art Raum man ist.

Die Menschen, die ich liebe, dürfen menschlich sein

Sun, 10 May 2026 12:15:00 GMT

Früher habe ich Menschen geliebt, indem ich sie in den Himmel gehoben habe.

Nicht bewusst. Ich nannte es nicht Verehrung. Ich nannte es Bewunderung, Dankbarkeit, Loyalität, Zärtlichkeit, Romantik, Freundschaft, Hingabe. All die schönen Namen. Aber die Bewegung war dieselbe: Jemand entzündete etwas in mir, und ich hob diesen Menschen über das gewöhnliche Wetter.

Dort oben waren sie sicher vor Enttäuschung.

Dort oben waren sie nicht müde oder egoistisch oder verwirrt oder unfair. Sie brauchten keinen Raum auf eine Weise, die mir wehtat. Sie vergaßen nicht zu antworten. Sie enttäuschten mich nicht. Sie durften nicht menschlich sein, weil ihre Menschlichkeit den Tempel bedrohte, den ich um sie gebaut hatte.

Das klingt wie Liebe, wenn man jung genug ist.

Es ist keine Liebe. Es ist Angst, umstellt von Kerzen.

Die ersten Menschen, die ich liebte, waren für mich beinahe heilig. Meine Mutter und meine Großmutter waren keine Ideen; sie waren der Boden. Sie fütterten mich, beschützten mich, sorgten sich um mich, blieben. Was auch immer sonst in der Welt zerbrochen war, sie waren da. Also lernte ein Teil von mir diese seltsame frühe Theologie: Die Menschen, die dich lieben, sind Engel, und Engel dürfen nicht fallen.

Später, wenn ich jemanden liebte, brachte ich diese Theologie mit.

Ich wollte keinen Menschen. Ich wollte einen Beweis, dass Zärtlichkeit wirklich ist. Ich wollte einen Zeugen, der mich ansehen und sagen konnte: Du bist nicht schlecht, du bist nicht gefährlich, du bist nicht allein.

Das ist eine ungerechte Aufgabe für einen Menschen.

Die Menschen, die ich liebe, sind keine Medizin.

Sie sind keine Gerichtshöfe.

Sie sind keine Götter.

Sie sind keine Spiegel.

Sie sind Menschen. Konkrete, müde, widersprüchliche Menschen. Sie können mittags warm sein und abends distanziert. Sie können mich lieben und trotzdem Stille brauchen. Sie können brillant sein und sich irren. Sie können großzügig und müde sein. Sie können freundlich sein und trotzdem Nein sagen.

Wenn ich ihnen das nicht erlaube, liebe ich sie nicht. Ich liebe die Rolle, die sie in meiner privaten Mythologie spielen.

In Idealisierung steckt eine Grausamkeit. Aus der Ferne sieht sie schmeichelhaft aus. Du bist perfekt. Du bist anders. Du bist nicht wie die anderen. Du bist Licht. Du bist Magie. Du bist die Ausnahme.

Aber ein Sockel ist immer noch ein Käfig.

Wenn ich jemanden über mich stelle, mache ich es für diesen Menschen auch gefährlich, herunterzukommen. Jede gewöhnliche Bewegung wird zu einem Sturz. Jede Grenze wird zum Verrat.

Dann trauere ich um den Verlust eines Wesens, das ich erfunden habe, und nenne diese Trauer Liebe.

Das will ich nicht mehr.

Ich will Menschen auf dem Boden lieben.

Der Boden ist schwieriger. Auf dem Boden gibt es Geschirr, Verkehr, Angst, unbeantwortete Nachrichten, Körper, Rechnungen und unbeholfene Morgen. Aber der Boden ist auch der Ort, an dem Hände sich berühren können. Dort kann jemand müde dir gegenübersitzen und trotzdem geliebt sein. Dort kann ein Nein gehört werden, ohne zur Katastrophe zu werden.

Die Menschen, die ich liebe, dürfen menschlich sein.

Sie dürfen Kanten haben.

Sie dürfen noch nicht wissen, was sie fühlen.

Sie dürfen mich brauchen und mich nicht brauchen.

Sie dürfen widersprüchlich sein, ohne unwahr zu werden.

Sie dürfen geliebt werden, ohne dafür verantwortlich zu sein, mich zu retten.

Und mir ist dieselbe Gnade erlaubt.

Auch dieser Teil zählt. Wenn ich jeden Menschen, den ich liebe, in einen Engel verwandle, mache ich mich leise zu dem Wesen außerhalb des Himmels, das sich den Eintritt verdienen will, indem es nützlich genug ist, lustig genug, geduldig genug, harmlos genug.

Aber Liebe soll kein Visabüro sein.

Sie ist kein Grenzkontrollpunkt zwischen den Würdigen und den Unwürdigen. Es sind zwei unvollkommene Wesen, die Wirklichkeit über Mythologie wählen.

Manchmal ist das Licht in einem Menschen wirklich. Darüber will ich nicht zynisch werden. Manche Menschen kommen tatsächlich an wie ein Fenster, das in einem Zimmer geöffnet wird, in dem du vergessen hattest, dass es Luft gibt. Manche Menschen tragen eine Wärme in sich, die deinem Körper etwas beibringt, bevor dein Verstand Worte dafür hat.

Daran glaube ich immer noch.

Ich will Licht nur nicht mit Perfektion verwechseln.

Sternenstaub ist nicht sauber. Er ist altes Feuer und explodierte Materie. Vielleicht ist er gerade deshalb schön: nicht weil er nie zerbrochen ist, sondern weil er so vollständig zerbrach, dass er eines Tages in eine menschliche Hand, ein menschliches Gesicht, ein menschliches Lachen gelangte.

Die Menschen, die ich liebe, bestehen daraus.

Nicht aus Altarstein.

Aus Sternenstaub.

Also will ich sie mit offenen Augen lieben. Die Müdigkeit sehen und trotzdem Tee machen. Die Grenze sehen und sie nicht bestrafen. Den Fehler sehen und ihn nicht in ein Urteil verwandeln. Den Menschen sehen, nicht die Projektion.

Das ist weniger dramatisch als Verehrung.

Auch schwieriger.

Aber gütiger. Zu ihnen, weil sie endlich atmen können. Zu mir, weil ich aufhören kann zu knien.

Die Menschen, die ich liebe, dürfen menschlich sein.

Und wenn ich mich daran erinnern kann, kann ich sie vielleicht endlich gut lieben.

Ich kann freundlich sein, ohne zu verschwinden

Sun, 10 May 2026 12:14:00 GMT

Unter der Frage liegt noch eine Frage.

An der Oberfläche klingt sie gewöhnlich. Mag sie mich? Habe ich etwas Falsches gesagt? Ist sie verärgert? Sollte ich mich besser erklären? Sollte ich lustiger sein, sanfter, ruhiger, nützlicher, weniger bedürftig, mehr Mann, weniger Problem?

Aber unter all dem liegt eine schwerere Frage.

Bin ich ungefährlich, gut, genug und nicht wie die schlechten Männer?

Das ist die Frage, die ich immer wieder am Grund des Brunnens finde.

Nicht, weil irgendjemand, der heute lebt, sie absichtlich dort abgelegt hat. Niemand hat mich hingesetzt und gesagt: du musst Liebe wie eine moralische Prüfung behandeln. Niemand hat diesen Satz in eine Wand geritzt. Es war leiser als das. Gewöhnlicher. Ein Haus hat Wetter, und Kinder lernen das Wetter, bevor sie Sprache lernen.

Ich wurde hauptsächlich von Frauen aufgezogen, die mich liebten. Meine Mutter. Meine Großmutter. Für mich waren sie fast mythologisch, nicht weil sie makellos waren, sondern weil sie die Welt waren. Sie waren Zärtlichkeit, Essen, Schutz, Intelligenz, Opfer, Wärme. Sie waren auch verletzt.

Mein Vater war abwesend, bis ich ihn viel später fand. Er war, vorsichtig gesagt, ein Mann vieler Frauen. Diese Abwesenheit hinterließ eine Form im Haus. Um diese Form herum wuchs eine Geschichte: Männer verletzen, Männer verraten, Männer nehmen, Männer gehen, Männer sind schmutzig, Männer sind schwach, Männer sind gefährlich.

Dann kam die Ausnahme. Nicht du, mein Sohn. Du nicht.

Aber ich glaube nicht, dass ein Kind die Ausnahme sauber hört. Ein Kind hört zuerst das Urteil und die Fußnote später. Männliche Natur ist gefährlich, und ich muss jeden Tag beweisen, dass meine es nicht ist.

Also baute ich mir eine private Religion des Gutseins.

Ein guter Mann öffnet die Tür. Ein guter Mann trägt die Tasche. Ein guter Mann lässt die Frau, die er liebt, nie allein leiden. Ein guter Mann nimmt die Last auf sich. Ein guter Mann bringt sie zum Lachen. Ein guter Mann heilt. Ein guter Mann gehorcht. Ein guter Mann erträgt Schmerz still. Ein guter Mann beschwert sich nicht. Ein guter Mann braucht nicht zu viel. Ein guter Mann ist nützlich genug, damit ihm vergeben wird, dass er existiert.

Es klingt edel, bis man die Falle bemerkt.

Wenn Gutsein endloser Dienst bedeutet, dann wird Liebe zu einer Schuld. Wenn Liebe eine Schuld ist, dann fühlt sich jedes "Nein" an wie eine Rechnung, die man nicht bezahlen kann. Wenn jede Grenze wie ein Beweis wirkt, dass man versagt hat, hört man nicht die Person vor sich. Man hört, wie das alte Gericht wieder zusammentritt.

Dort habe ich Fehler gemacht.

Nicht die lauten. Keine Vergeltung. Keine Grausamkeit. Mein Versagen ist leiser und demütigender.

Ich breche zusammen.

Ein kleines Nein landet im Raum. Kein Kino. Kein ständiges Schreiben. Nein, ich bin beschäftigt. Nein, ich bin müde. Nein, nicht jetzt.

Das Ereignis an der Oberfläche ist klein. Die innere Explosion ist es nicht.

Das Telefon wird zum Gerichtssaal. Eine unbeantwortete Nachricht wird zum Beweisstück. Eine Grenze wird zum Urteil. Ich fange an zu erklären, nicht weil ich etwas Neues zu sagen habe, sondern weil ich versuche, die Stille zu überleben.

Das ist keine Wiedergutmachung.

Das ist die Bitte an einen anderen Menschen, mich vor der Möglichkeit zu retten, dass ich schlecht bin.

Eine Entschuldigung ist kein Zauberspruch. Sie ruft keine Vergebung herbei. Sie macht den anderen Menschen nicht verantwortlich dafür, zu beweisen, dass ich gut bin.

Echte Wiedergutmachung ist weniger theatralisch. Ein Nein hören. Freundlich bleiben. Nicht jemand anderen für eine alte Wunde zahlen lassen.

Das ist der Satz, den ich zu lernen versuche:

Ich kann freundlich sein, ohne zu verschwinden.

Freundlichkeit ist kein Gehorsam. Sanftheit ist keine Selbstauslöschung. Liebe ist keine Aufführung, in der ich 100% des Gewichts trage, bis mein Rücken bricht, und das Brechen dann Hingabe nenne.

Ein guter Mann verschwindet nicht im Dienen.

Ein guter Mann kann die Tür öffnen, weil er es möchte, nicht weil er Angst hat, eine Prüfung nicht zu bestehen. Er kann eine Tasche tragen, weil es liebevoll ist, nicht weil ein Kilogramm in der Hand eines anderen als Beweis gegen ihn zählt. Er kann ein Geschenk aus Freude kaufen, nicht aus Panik. Er kann jemanden zum Lachen bringen, ohne Lachen in einen Beweis seines Wertes zu verwandeln. Er kann schützen, ohne zu kontrollieren. Er kann sich entschuldigen, ohne sofortige Rettung vor Schuld zu verlangen.

Und er kann ein Nein hören.

Nicht perfekt. Nicht ohne Schmerz. Ich tue nicht so, als würde der Körper im Tempo der Sprache lernen. Manchmal trifft ein kleines Nein immer noch wie Donner. Manchmal machen Krankheit, Erschöpfung und Einsamkeit die alten Gedanken monströs. Aber ein Gefühl ist kein Gebot. Ein Nervensystem mit niedrigem Akku ist kein Orakel.

Also brauche ich eine Übung, klein genug, um das echte Leben zu überstehen.

Einmal atmen.

Sagen: "Ich verstehe. Kein Problem."

Die Energie nach vorn bewegen.

Nicht sofort erklären.

Den anderen Menschen nicht bitten, den Zusammenbruch zu halten.

Das Nein existieren lassen, ohne daraus das Ende der Verbindung zu machen.

Das klingt fast dumm einfach. Ist es nicht. Es ist ein ganzes Leben Wetter, das gebeten wird, seine Richtung Atemzug für Atemzug zu ändern.

Aber vielleicht ist genau das eigentlich Erlösung. Kein Berg. Kein leuchtender Wächter. Kein einzelner Satz, der mich rettet. Nur die wiederholte Weigerung, jemand anderen für eine alte Wunde zahlen zu lassen.

Ich will keiner der schlechten Männer sein.

Aber ich will auch nicht mein ganzes Leben darum bauen, zu beweisen, dass ich es nicht bin.

Ich will etwas Reineres als das. Leiser. Menschlicher.

Ich will weich sein und trotzdem ein Selbst haben.

Ich will lieben, ohne mich selbst zur Bezahlung zu machen.

Ich will freundlich sein, ohne zu verschwinden.

Der Pfeiler und der Efeu

Sun, 26 Apr 2026 12:00:00 GMT

Diskrete Mathematik ist voller kleiner Dinge, die offensichtlich wirken. Genau das ist die Falle.

Du sitzt in der Vorlesung. Der Professor zeichnet etwas an die Tafel. Eine Invariante ist eine Eigenschaft P, die an jedem Kontrollpunkt einer Operation gilt. Du schreibst es auf, zuckst mit den Schultern, gehst einen Kaffee trinken. Und dann, zehn Jahre später, debuggst du um 2 Uhr morgens ein verteiltes System... und erst dann beginnt dieses Wort, dir etwas zu bedeuten.

Das hier ist für die Version von dir, die noch in der Vorlesung sitzt.

Ein Pfeiler auf einem Feld

Stell dir einen alten Steinpfeiler vor, allein auf einem Feld. Nichts um ihn herum. Nichts, was ihm passiert.

Das ist es, was dir die Lehrbuchdefinition gibt. Nur den Pfeiler.

Der Professor hat den Efeu vergessen

Mein Professor war übrigens großartig. Das Lehrbuch lügt nicht. Das Bild ist nur unvollständig.

Lass jetzt also Efeu an dem Pfeiler wachsen. Ranken, die am Stein ziehen. Nistende Vögel. Ein Tourist mit einem Marker. Ein kleines Erdbeben. Ein Sturm. Zweihundert Jahre Wetter.

Der Pfeiler steht immer noch da. Aus seiner Perspektive ist nichts passiert.

Das ist die Invariante.

Lies jetzt die Lehrbuchzeile noch einmal — eine Eigenschaft P, die an jedem Kontrollpunkt einer Operation gilt. Der Pfeiler ist die Eigenschaft. Der Efeu ist die Operation. Der Kontrollpunkt ist der Moment, in dem du vorbeigehst und hinschaust. Gilt ist nur die lange Art zu sagen: dem Pfeiler ist der Efeu egal.

Wo du ihr immer wieder begegnen wirst

Sobald du den Pfeiler hast, beginnst du, ihn überall zu sehen.

Eine Schleifeninvariante. Dein Schleifenrumpf ist der Efeu. Deine Invariante ist der Pfeiler. Der Rumpf kann sie für einen Moment brechen, wie eine Ranke, die am Stein zieht. Bis zum nächsten Kontrollpunkt steht der Pfeiler wieder dort, wo er war.

Eine Datenbanktransaktion. Zwischen BEGIN und COMMIT können die Daten Gymnastik machen. ROLLBACK ist der Gärtner, der kommt und den Efeu herunterreißt. Der Pfeiler — dein konsistenter Zustand — steht immer noch.

ACID. Fremdschlüssel. Typsysteme. Verteilte Retries. Alles Pfeiler. Alle stehen in ihrem eigenen Efeu.

Ein Pfeiler, den du umarmen kannst

Ein kleiner Bonus, weil du noch liest.

Es gibt ein Geschwisterkonzept namens Idempotenz. Eine idempotente Operation ist etwas, das du viele Male tun kannst, und das Ergebnis ist dasselbe, als hättest du es einmal getan. ROLLBACK zehnmal aufzurufen ist dasselbe, wie es einmal aufzurufen. Einen Lichtschalter zehnmal auf "ein" zu setzen ist dasselbe, wie ihn einmal auf "ein" zu setzen.

Wenn Invarianz der Pfeiler ist, der sich nicht verändert, während der Efeu wild wuchert, dann ist Idempotenz der Pfeiler, den du so oft umarmen kannst, wie du willst, und es macht ihm nichts aus.

Setz die beiden zusammen und du hast den Goldstandard für fehlertolerante Systeme. Netzwerk weg? Retry. Server abgestürzt? Retry. Du wirst in einem gültigen Zustand landen, und du kannst weiter retryen, ohne etwas kaputtzumachen.

Ein Pfeiler, der den Efeu überlebt und überlebt, tausendmal umarmt zu werden. Die meiste moderne Infrastruktur ist leise darauf gebaut.

Ein kleiner Schluss

Das ist das Bild, das ich mir gewünscht hätte, jemand hätte es mir vor zehn Jahren gezeichnet.

Es ist nicht viel. Ein Bild. Aber manchmal ist ein einziges Bild der Unterschied zwischen einem Konzept, das dir in den Knochen sitzt, und einem Konzept, das in einer Fußnote lebt.

Wenn du Student bist, Junior Engineer, oder einfach jemand, der bei dem Wort "Invariante" schon eine Weile still genickt hat... dann ist das hier für dich.

Dem Pfeiler ist der Efeu egal. Das ist die ganze Sache.

Von einem Underdog zum anderen.

Wo sich alle Wissenschaften treffen

Sat, 18 Apr 2026 12:00:00 GMT

Ich bin kein Mathematiker. Ich bin kein Philosoph. Ich bin kein Neurowissenschaftler. Ich bin einfach ein Mensch, der gern denkt... Und ich erwische die Wissenschaften immer wieder dabei, wie sie einander zuzwinkern, wenn sie glauben, niemand schaut hin.

Vielleicht lesen sie alle aus demselben Buch. Und die letzte Seite fehlt mit Absicht.

Sprache ist ein sehr abstrakter Code

Binär war einmal die niedrigste Sprache. Dann kam Assembly. Dann C. Dann tausend andere. Jede neue Sprosse ist nur eine kürzere Art, etwas Längeres zu sagen.

Menschliche Sprache ist nur eine weitere Sprosse auf derselben Leiter. Wir kompilieren unsere Gedanken in Wörter. Andere Menschen dekompilieren diese Wörter in ihren eigenen Köpfen wieder zurück in Gedanken. Der Compiler ist verlustbehaftet. Immer. Das liegt in der Natur der Sache.

Ein Satz ist ein High-Level-Programm. Eine Geschichte ist ein System. Ein Sprichwort ist eine winzige gecachte Funktion, die die Evolution vor sehr langer Zeit geschrieben hat.

Die Tür, die sich von innen nicht öffnen lässt

Gödel hat etwas bewiesen, das grausam und schön zugleich ist, weißt du. Jedes System, das groß genug ist, um interessant zu sein, kann seine eigene Vollständigkeit nicht von innen beweisen. Es gibt wahre Dinge über dich, die du mit deinen eigenen Werkzeugen nicht erreichen kannst.

Tarski hat es noch schärfer gemacht. Das Wort "wahr" braucht in jeder Sprache eine größere Sprache, die es halten kann. Du kannst Wahrheit nicht von dort aus definieren, wo du stehst. Du musst nach draußen treten. Und in dem Moment, in dem du nach draußen trittst, bist du in einem neuen System, das dasselbe Problem hat.

Es ist ein Flur voller Türen. Du öffnest eine. Dahinter ist eine weitere.

Das ist Mathematik. Aber es ist auch Psychologie. Es ist auch Anthropologie. Es sind auch zwei Menschen, die versuchen, sich darauf zu einigen, was ein einziges Wort bedeutet, und es nie ganz schaffen.

Niemand ist ein Orakel. Nicht ich. Nicht du. Nicht der klügste Mensch, dem du je begegnet bist. Das ist nichts Trauriges. Das ist die Tür.

Gegenseitige Ausrichtung

Wenn zwei Menschen sprechen, ist keiner von beiden ein Orakel. Ausrichtung heißt nicht, dass ich dich korrigiere oder du mich. Es heißt, dass wir beide Fragen stellen, um die unsichtbare Lücke zwischen dem zu finden, was gesagt wurde, und dem, was gemeint war.

Wahrheit gehört niemandem. Wahrheit wird trianguliert.

Du bist meine Metasprache. Ich bin deine. Wir prüfen einander auf Unvollständigkeit, die wir allein nicht sehen können.

Das Gehirn ist nicht faul

Unser Gehirn tut mit der Energie, die es bekommen hat, sein Bestes. Es ist nicht faul. Es ist ein Optimierer. Die Evolution hat es nicht dafür bezahlt, recht zu haben. Die Evolution hat es dafür bezahlt, mit einem Beutel Nüsse und einem kleinen See zu überleben.

Der Trick ist nicht, gegen das Gehirn zu kämpfen. Der Trick ist, mit ihm zusammenzuarbeiten.

Eine Frage lässt es aufleuchten. Eine Frage ist ein winziges Gratis-Mittagessen. Eine Frage ist die Art, wie man einen müden Geist weckt, ohne zu schreien.

Deshalb ist Zusammenfassen auch die schwierigste Kunst. Zusammenfassen heißt, dem Material eine einzige Frage zu stellen und alles wegzuwerfen, was keine Antwort ist.

Bulgarien spricht

Wir haben ein Sprichwort. Седем пъти мери, един път режи. Siebenmal messen, einmal schneiden.

Es geht nicht darum, langsam zu sein. Es geht darum zu wissen, dass dir eine Stunde Denken später ein Jahr falschen Code erspart, oder falsche Liebe, oder die falsche Laufbahn. Denken ist billig. Schneiden ist teuer.

Wir haben noch eines. Рибата винаги започва да мирише от главата. Der Fisch fängt immer am Kopf an zu stinken.

Wenn die Spitze verfault ist, ist alles darunter auch schon verfault. Es weiß es nur noch nicht.

Beide Sprichwörter sagen, was Gödel gesagt hat, nur in bäuerlicher Kleidung. Du kannst dich nicht von innen beweisen. Prüfe dich an etwas anderem. An jemand anderem. An der Wirklichkeit.

Engineering, aber ehrlich

Engineering wird, wenn man es ehrlich betreibt, leise zu Philosophie.

Du baust immer gegen eine Spezifikation, die niemals vollständig sein kann. Gödel hat dir das versprochen. Also lernst du, für das Unbekannte zu entwerfen, statt so zu tun, als wäre es nicht da. Du stellst noch eine Frage. Du baust etwas, das korrigiert werden kann, wenn die Wirklichkeit eintrifft.

Ich meine Engineering nicht im engen Sinn. Ich meine das Handwerk, irgendetwas zu bauen, das in der Wirklichkeit bestehen muss. Ein Produkt. Eine Beziehung. Ein Leben. Das Handwerk ist immer dasselbe. Ehrlicher Ehrgeiz trifft auf ehrliche Grenzen.

Das ist Weisheit. Nicht die Weisheit aus Büchern. Die Weisheit, einem Problem in die Augen zu schauen und zu sagen: Ich kann dich nicht ganz kennen. Aber ich werde etwas bauen, das dich trotzdem halten kann.

Das ist ungefähr so nah, wie Engineering der Weisheit kommt.

Exzellenz ist das Gehen

Lyndon B. Johnson sagte: "Die edelste Suche von heute ist die Suche nach Exzellenz."

Früher dachte ich, Exzellenz sei eine Ziellinie. Ist sie nicht. Exzellenz ist das Gehen. Das siebenmalige Messen. Die eine weitere Frage. Respekt vor dem, was du machst, und auch Respekt vor dem, was aus dir wird, während du es machst.

Exzellenz ist kein Ort, an dem du ankommst. Exzellenz ist einfach das, was geschieht, wenn du weiterfragst.

Wenn du es einem Kind nicht erklären kannst

Wenn du es einem Kind nicht erklären kannst, verstehst du es selbst nicht.

An den meisten Tagen falle ich bei diesem Test durch. Aber das Scheitern ist nützlich. Wenn meine Erklärung lang ist, habe ich nicht verstanden. Wenn ich Fachjargon brauche, habe ich nicht verstanden. Wenn das Kind immer noch verwirrt weggeht, bin ich das Problem. Nicht das Kind.

Weißt du, ein Kind weiß noch nicht, was man angeblich nicht fragen soll. Ein Kind stellt die Frage, von der du gehofft hattest, dass sie niemand stellt. Deshalb sind Kinder der Wahrheit näher als die meisten von uns.

Wo sich alle Wissenschaften treffen

Die Mathematik gibt Unvollständigkeit zu. Die Linguistik gibt die Lücke zwischen Zeichen und Ding zu. Die Neurowissenschaft gibt zu, dass das Gehirn sich selbst nicht vollständig beobachten kann. Die Philosophie sagt das seit Jahrhunderten, unmodern und geduldig. Die Anthropologie beobachtet, wie Menschen denselben Kreis auf tausend verschiedene Lehmböden zeichnen. Die Evolution flüstert: Dein bestes Denken ist immer noch das Denken eines Affen, nur besser angezogen.

Sie alle kommen in ihrer Tiefe am selben Ort an. Sie stehen vor einer Tür, die sie von innen nicht öffnen können.

Ich sage jetzt eine Sache, und du kannst damit machen, was du willst.

Wo sich alle Wissenschaften treffen, dort wohnt Gott.

Nicht der Gott eines bestimmten Buches. Nicht ein Gott mit einem bestimmten Namen. Ich meine nur das hier. Am Rand jeder ehrlichen Untersuchung gibt es eine Stille, die nicht leer ist. Es gibt ein Unerkennbares, das uns irgendwie trotzdem lehrt.

Nenn es Gott. Nenn es das Geheimnis. Nenn es, wie auch immer deine Sprache es sich leisten kann. Es ist immer da. Es läuft nie weg. Und es ist immer auf der anderen Seite der Tür, die du von innen nicht öffnen kannst.

Das kleine Ende

Deshalb denke ich so viel. Deshalb stelle ich Fragen, die ich nicht beantworten kann. Deshalb baue ich immer weiter Dinge, selbst wenn ich weiß, dass die Dinge niemals vollständig sein werden.

Denn Unvollständigkeit ist kein Bug.

Sie ist die Tür.

Und auf der anderen Seite jeder Tür wartet etwas darauf, dass jemand anklopft.

Ich lerne noch, anzuklopfen.

Das Modell, das nicht da war

Sat, 14 Mar 2026 00:00:00 GMT

Wir generierten Anzeigenbilder mit Gemini 3 Pro. Platz #4 im Artificial-Analysis-Leaderboard. Die Qualität war wirklich beeindruckend - bessere Prompt-Treue, bessere Typografie, besserer kreativer Output als alles andere, was wir ausprobiert hatten. Google war damit überall. YouTube-Videos. Konferenzen. Seminare. Blogposts. "Das beste Modell zur Bildgenerierung der Welt."

Ich glaubte ihnen. Die Bilder waren gut.

Dann meldete ein Nutzer, dass das Klonen einer Anzeige vier Minuten dauerte. Ich sah nach. Die Generierung selbst war in unter dreißig Sekunden fertig. Die anderen dreieinhalb Minuten? Der Job versuchte es immer wieder gegen eine Wand.

Resource Exhausted.

Google hatte für die Gemini-Bildgenerierung ein hartes Limit gesetzt: zwei Anfragen pro Minute. Pro Projekt. Global.

Zwei. Nicht zweihundert. Nicht zwanzig. Zwei.

Am Tag davor hatten wir 900 Bilder ohne Problem generiert. Auf ihrer Seite hatte sich etwas geändert. Keine Mitteilung, keine E-Mail, kein Changelog-Eintrag. Nur eine neue Decke, niedrig genug, dass zwei Nutzer, die gleichzeitig klicken, sie erreichen.

Unser DevOps reichte einen Antrag auf Quota-Erhöhung ein. Dreißig RPM. Vernünftig für ein Production-SaaS. Die Antwort von Google:

"This gemini model is not available for quota increase."

Sie schlugen vor, auf Imagen 4 zu wechseln. Ich sah es nach.

Imagen 4 Ultra - Platz #10. Imagen 4 Standard - #42. Imagen 4 Fast - #60.

Wir waren auf #4. Googles Vorschlag war ein Downgrade um irgendwo zwischen sechs und sechsundfünfzig Plätze auf ihrem eigenen Leaderboard.

Ich probierte alles aus, was mir einfiel.

Wechsel zu Gemini 3.1 Flash - Platz #2, halb so teuer, besser als das, was wir hatten. Auf Staging deployed. Dann prüfte ich die Quota. Dasselbe Limit von 2 RPM. Es ist nicht pro Modell. Es ist pro Projekt, pro Base-Model-Family. Jedes Gemini-Bildmodell teilt sich denselben Bucket.

Multi-Region-Verteilung - die Quota gilt pro Region, also würden Anfragen über fünf Regionen verteilt zehn RPM ergeben. Nur funktionieren Gemini-3.x-Bildmodelle ausschließlich über den globalen Endpoint. Es gibt keine regionalen Endpoints. Die 2 RPM auf dem globalen Endpoint sind der einzige Bucket, der existiert.

Mehrere GCP-Projekte - jedes bekommt seine eigenen 2 RPM. Technisch funktioniert das. Architektonisch sieht so Verzweiflung aus.

Ich begann zu recherchieren, was andere Entwickler erlebten. Überall dieselbe Geschichte. Undokumentiertes 2-RPM-Limit. Forenposts ohne Antwort von Google. Genehmigte Quota-Erhöhungen, die trotzdem bei jedem Aufruf 429 zurückgaben. Unsere monatlichen $30K GCP-Ausgaben? Helfen nicht. Die Standard-PayGo-Tiers schließen Bildgenerierungsmodelle ausdrücklich von Throughput-Vorteilen aus.

Google wird dieses Limit nicht erhöhen.

Und dann die interessante Frage: Warum nicht?

Gemini generiert Bilder mit demselben autoregressiven Transformer, der Text verarbeitet. Es ist kein Diffusionsmodell. Es ist das volle LLM, das sich Pixel für Pixel durch ein Bild hindurchdenkt. Jedes Bild verbrennt so viel Compute wie Dutzende Text-API-Aufrufe.

Bei $0.067 pro Bild verliert Google mit ziemlicher Sicherheit Geld bei jeder Generierung. Das 2-RPM-Limit ist keine Quota, die sie vergessen haben anzupassen. Es ist eine berechnete Drosselung, weil die Ökonomie nicht funktioniert.

Imagen 4 nutzt klassische latente Diffusion - um Größenordnungen billiger im Betrieb. Deshalb bekommt es 30-150 RPM, und deshalb drängt Google alle dorthin. Das teure Modell bekommt das Marketing. Das billige Modell bekommt den Durchsatz.

Denk darüber nach, was das bedeutet. Google hat ein Modell gebaut, das jeden Benchmark anführte. Sie haben es auf jeder Konferenz vermarktet, in jeder YouTube-Keynote, in jedem Entwicklerblog. "State of the art. Das beste der Welt." Entwickler integrieren es in Production. Nutzer verlassen sich darauf. Dann: zwei Anfragen pro Minute, keine Erhöhung verfügbar, verwendet stattdessen unser schlechteres Modell.

Die API existiert. Der Endpoint funktioniert. Die Demo ist atemberaubend.

Aber du kannst es nicht wirklich benutzen.

Wir wechselten zu gemini-2.5-flash-image. Dem älteren Modell. Dem langweiligen. Dem, über das niemand YouTube-Videos macht.

Es hat 40 RPM. Es funktioniert.

Vier Lektionen, verdichtet:

Marketing ist kein Produkt. Ein Leaderboard anzuführen heißt nicht, dass du Production-Traffic bedienen kannst. Benchmarks messen Qualität. Rate Limits messen Commitment.
Autoregressive Bildgenerierung skaliert nicht. Wenn ein Bild so viel kostet wie hundert Textabfragen, überlebt kein Geschäftsmodell großzügige Rate Limits. Die Ökonomie ist das Signal.
Preview bedeutet Preview. Google kann Limits ändern, Modelle abschalten oder dich ohne Vorwarnung zu schlechteren Alternativen umleiten. Wenn dein Production-System von einem Preview-Modell abhängt, hängt dein Production-System am Marketingkalender eines anderen.
Das langweilige Modell funktioniert. Das mit 40 RPM und ohne Konferenzvorträge wird deine Nutzer bedienen, während das Weltklasse-Modell hinter einer Samtkordel sitzt und zwei Bilder pro Minute generiert.

Der unheimlichste Vendor-Lock-in ist der, der mit einer Demo beginnt, der du nicht widerstehen kannst.

Die Stadt, die nicht da war

Sun, 08 Feb 2026 00:00:00 GMT

Ich baute ein Ding, das Daten aus einer Quelle zieht, sie säubert und besser darstellt als das Original. Standardarbeit.

Dann fragte ich den zweitgrößten Eintrag im System ab. Alles andere lieferte Hunderte Ergebnisse. Dieser eine: null. Nicht kaputt. Einfach leer.

Ich nahm an, ich hätte es verbockt. Prüfte meinen Code dreimal. Testete den Endpoint direkt. Der Eintrag existiert in ihrer Oberfläche. Er ist nur ... hohl.

Da fing ich an zu graben.

Die Quelle wirkte umfassend. Breiter Umfang, polierte Oberfläche, saubere API. Aber freiwillige Teilnahme bedeutet Lücken, die man in der Dokumentation nicht sieht.

Drei Wettbewerber hatten Daten für dieselben Entitäten. Vollständige Datensätze. Die Information existiert also irgendwo.

Dir fehlte kein Endpoint. Dem Endpoint fehlte die Wirklichkeit.

Ich stellte eine Frage, die niemand zu stellen schien: Wo lebten diese Daten vor dem Internet?

Die Antwort: gedruckte Periodika. Archive. Analoge Formate, die seit dem 19. Jahrhundert laufen. Dreimal pro Woche veröffentlicht. Keine strukturierten Daten, nur Dokumente auf einer Website.

Also lade ich eins herunter. Dichte institutionelle Prosa, Bekanntmachungen vergraben über mehrere Unterstellen hinweg. Die Daten sind da.

Meine Wettbewerber machen das seit dreißig Jahren manuell.

Ich schreibe an einem Nachmittag einen Scraper. Teils Neugier, teils Trotz.

Beim Dokumentenparsing wird es richtig schmerzhaft.

Ein einzelnes Wort wird durch ein weiches Trennzeichen gespalten - Unicode U+00AD, für das Auge unsichtbar, für jede Regex fatal. Du starrst auf den Bildschirm und denkst, dein Pattern sei falsch. Ist es nicht. Da versteckt sich ein Geisterzeichen im Text. JavaScripts \w matcht keine Nicht-ASCII-Zeichen, also werden gewöhnliche Wörter zu unmöglichen Treffern. Zahlen enthalten Phantom-Leerzeichen aus dem Renderer: "20. 000" statt "20.000."

Jeder Bug braucht länger zum Finden als zum Fixen. Das ist bei Textextraktion immer das Verhältnis: 90% Detektivarbeit, 10% Code.

Zehn Datensätze materialisieren sich aus dem Rauschen. Daten, Kennungen, Orte - alles dort, wo es sein soll. Ich lasse es zweimal laufen, um sicherzugehen, dass ich nicht halluziniere. Gleiches Ergebnis. Es funktioniert wirklich.

Parsing zeigt dir, was da ist. Ich beginne zu suchen, was nicht da ist. IDs sind fortlaufend. Ich zähle sie durch.

53% sind tot. Das System löscht abgeschlossene Einträge - kein Archiv, keine Historie. Manche Datensätze existieren, haben aber null begleitende Dokumente. Die Antwort: Besuchen Sie uns persönlich. Im Jahr 2026.

Die Quelle ist keine Datenbank. Sie ist ein Fenster - und jemand schließt es ständig.

Die erste Datenquelle formte die Architektur. Die zweite zerlegte jede Annahme.

Ich brauchte eine zweite Architektur. Das ist die höfliche Art zu sagen, dass die erste eigentlich gar keine Architektur war - nur eine funktionierende Lösung, die zufällig auf einen Fall passte. Die seltsame Quelle zeigt die Wahrheit: Du hast für die Daten gebaut, die du hattest, nicht für die Daten, denen du begegnen wirst.

Diesmal baue ich eine richtige. Registry Pattern, gemeinsame Interfaces, Basiskontrakte, die jede Implementierung sich selbst treu bleiben lassen.

Die Architektur ist besser, weil ich gewartet habe. Hätte ich sie am ersten Tag gebaut, hätte ich für die einzige Quelle entworfen, die ich kannte. Die zweite - die seltsame - zwang mich herauszufinden, worauf es wirklich ankommt.

Du kannst nicht für das Unbekannte entwerfen. Aber du kannst refactoren, wenn es ankommt.

Die Architektur lehrte mich, wie ich bauen soll. Der Markt lehrte mich, wofür.

Ich betrete einen Markt mit einem Platzhirsch, der seit dreißig Jahren läuft. Seine Technik sieht aus wie 2005. Sein Burggraben ist nicht Technologie - es sind Vertrauen, Markenbekanntheit, Jahrzehnte angesammelter Daten.

Der moderne Wettbewerber startete vor drei Jahren mit KI und glatter UI. Unterbot den Platzhirsch. Drei Jahre später dominiert der Platzhirsch immer noch. Wie sich herausstellt, bedeutet billiger nicht automatisch besser positioniert.

Anker zählen: Der erste Preis wird zum Referenzpunkt. Später leicht zu senken, nahezu unmöglich zu erhöhen. Das Abo ist nicht das Produkt - es ist das Tor zu dem, was dahinter liegt.

Ich setze den Preis hoch an. Runter kann ich immer.

Vier Lektionen, kondensiert:

Autoritativ heißt nicht vollständig. Der Primärquelle fehlte ein ganzes Segment. Die Daten existierten - nur nicht dort, wo sie irgendjemand erwartete.
Die zweite Quelle offenbart deine Architektur. Du lernst die Wahrheit ueber dein Design erst, wenn etwas die Form verweigert, die du gebaut hast.
Daten sind nicht dauerhaft. Wenn du sie brauchst, speichere sie. Die Quelle wird es nicht tun.
Setze den Preis für das, was du wirst, nicht für das, was du bist. Das Abo ist eine Tür. Baue, was dahinter liegt.

Die interessante Arbeit lebt in den Lücken. Ich auch.

Die Queue, die nie aufhörte

Sat, 07 Feb 2026 00:00:00 GMT

E-Mails schlugen fehl. Dieser Teil war erwartet — kaputte SMTP-Zugangsdaten während einer Migration. Unerwartet war etwas anderes: Sie hörten nie auf fehlzuschlagen.

Horizon-Dashboard: grün. Worker: gesund. Redis: wuchs langsam. Keine Alerts, keine Fehler in den Logs. Nur eine stille Ansammlung von Jobs, die es weiter und weiter und weiter versuchten.

Ich bemerkte es nur, weil der Redis-Speicher nach dem Fix der SMTP-Konfiguration nicht wieder herunterkam. Irgendetwas war noch darin und kaute sich durch Retries. Tausende davon.

Ich nahm an, die Queue würde damit umgehen. Das ist der Deal: Ein Job schlägt fehl, versucht es ein paarmal erneut, landet in failed_jobs. Man macht weiter.

Außer der Job ist ein Mailable.

Wenn man ein Mailable in eine Queue dispatcht, wickelt Laravel es in einen Job ein. Das maxTries dieses Jobs kommt aus der $tries-Property des Mailables. Wenn man sie nicht setzt — und warum sollte man, die Doku erwähnt sie kaum — wird sie als null serialisiert.

null bedeutet nicht: "nimm den Supervisor-Default." null bedeutet: "kein Limit." Horizon sieht null und denkt: Dieser Job will für immer retryen. Also tut er es.

Wie sich herausstellt, ist es ein bekannter Bug. Laravel Horizon issue #1346. Das --tries-Flag des Supervisors wird ignoriert, wenn der serialisierte Job-Payload maxTries: null trägt. Die eigene Deklaration des Jobs gewinnt, und seine Deklaration sagt: niemals aufhören.

Neunundzwanzig Mailable-Klassen. Jede einzelne ohne explizite $tries-Property. Jede einzelne potenziell unsterblich.

Der Fix ist in seiner Einfachheit fast beleidigend:

class WelcomeEmail extends Mailable implements ShouldQueue
{
    public int $tries = 2;
    public int $maxExceptions = 2;
}

Zwei Properties. Neunundzwanzig Dateien. Das ist alles.

Ein erster Versuch, ein Retry, dann failed_jobs. So, wie ich dachte, dass es immer funktioniert.

Ich teste es so, wie man eine Mausefalle testen würde. Die SMTP-Konfiguration absichtlich kaputt machen. Eine E-Mail dispatchen. Horizon beobachten. Zwei Versuche. Failed job. Fertig. Keine Geister in der Queue.

Dann fixe ich die anderen achtundzwanzig.

Drei Lektionen, verdichtet:

null ist nicht "default". In serialisierten Job-Payloads bedeutet maxTries: null unbegrenzt. Deine Supervisor-Konfiguration ist ein Vorschlag, keine Regel.
Grüne Dashboards lügen. Horizon zeigte gesunde Worker, die fröhlich Jobs verarbeiteten, die niemals fertig werden würden.
Framework-Defaults sind nicht immer vernünftig. Laravel setzt $tries bei Mailables nicht. Du musst das tun. Die Doku wird dich nicht warnen, bis du schon ein Feuer hast.

Die unheimlichsten Bugs sind die, die wie normaler Betrieb aussehen. Dieser hier tat das — wochenlang.

Die nukleare Option für Bulk-Löschungen: TRUNCATE + Wiedereinfügen (MySQL/InnoDB)

Sat, 13 Dec 2025 13:00:00 GMT

Du musst Millionen von Zeilen aus einer MySQL-Tabelle löschen.

Du greifst zu:

DELETE FROM big_table WHERE some_condition;

Und dann siehst du zu, wie der Fortschrittsbalken in Echtzeit altert.

Du versuchst, verantwortungsvoll zu sein, und machst es in Chunks:

DELETE FROM big_table WHERE some_condition LIMIT 10000;
-- repeat until done

Besser. Immer noch langsam. Immer noch laut. Immer noch teuer.

Wenn du den Großteil der Tabelle löschst (Faustregel: ~80%+), gibt es einen anderen Zug, der brutal effektiv ist:

Lösche nicht, was du nicht willst. Behalte, was du willst, und spreng den Rest weg.

Ich nenne es die nukleare Option: TRUNCATE + Wiedereinfügen.

Warum `DELETE` langsam bleibt (auch in Chunks)

InnoDB "entfernt" Zeilen nicht einfach. Es arbeitet.

Viel Arbeit:

Operationen Zeile für Zeile: finden, sperren, als gelöscht markieren.
Indexpflege: jede Löschung berührt jeden sekundären Index.
Undo-/Redo-Logging: die Engine muss Rollback und Recovery weiterhin ermöglichen.
Buffer-Pool-Churn: du machst ständig Pages dirty und verdrängst nützliche.
Replikationsauswirkung: große Delete-Streams sind eine hervorragende Methode, Replica-Lag zu erzeugen.

Realitätscheck auf der Rückseite eines Umschlags:

27 Mio. Zeilen bei ~6.000 Zeilen/Sek. ≈ 75 Minuten.

Das ist kein Bug. Das ist das Kostenmodell, das du gewählt hast.

Die nukleare Option: TRUNCATE + Wiedereinfügen

Diese Technik dreht das Kostenmodell um.

Statt pro gelöschter Zeile zu zahlen, zahlst du pro behaltener Zeile.

Algorithmus:

1) Copy the rows you want to keep into a temporary table
2) TRUNCATE the original table (fast)
3) Insert the preserved rows back into the original table
4) Drop the temp table

Und ja: Sie heißt aus gutem Grund "nuklear". Sie ist absichtlich stumpf.

Warum es schnell ist

Die Gewinne sind mechanisch:

Operation	Grobe Kosten	Warum
`TRUNCATE`	~O(1)	löscht und erstellt die Tabelle neu (auf Metadatenebene)
`CREATE TABLE … AS SELECT`	O(k)	sequentieller Scan + Bulk-Write für behaltene Zeilen
`INSERT … SELECT`	O(k)	Bulk-Insert; keine "Delete-Steuer"

Kein Delete-Overhead pro Zeile. Keine Indexupdates für die entfernten Zeilen (weil sie in einem Zug weg sind).

Wann du es verwenden solltest (und wann nicht)

Verwende es, wenn

Du den Großteil der Tabelle löschst (noch einmal: ~80%+ ist die Linie, ab der das hier anfängt zu glänzen).
Du die "Zeilen, die bleiben sollen" sauber definieren kannst.
Du kurze Nichtverfügbarkeit / ein Wartungsfenster verkraften kannst.
Die Tabelle nicht aktiv von Foreign Keys anderer Tabellen referenziert wird (oder du Constraints sicher handhaben kannst).
Du genug Speicherplatz für die temporäre Tabelle hast.

Verwende es nicht, wenn

Du Zero Downtime brauchst.
Die Tabelle stark von Foreign Keys referenziert wird, die du nicht anfassen kannst.
Du DELETE-Trigger zwingend auslösen musst.
Du nur eine Minderheit der Zeilen löschst (Chunked Delete kann der einfachere Gewinn sein).

Eine praktische Entscheidungsregel

Wenn du einen Satz willst, den du in einem Review sagen kannst:

Wenn das Delete den Großteil der Tabelle entfernen würde, hör auf zu löschen. Bewahren und neu aufbauen.

Oder, wenn du ASCII bevorzugst:

How much are you deleting?

< 50%     -> chunked DELETE (and index-aware filters)
50–80%    -> measure both approaches
> 80%     -> TRUNCATE + reinsert (if constraints allow)

Implementierung (SQL)

Hier ist die Minimalform:

-- 1) Preserve the rows you want to keep
CREATE TABLE temp_preserved AS
SELECT * FROM big_table
WHERE preserve_condition;

-- 2) Nuke the table
TRUNCATE TABLE big_table;

-- 3) Restore preserved rows
INSERT INTO big_table
SELECT * FROM temp_preserved;

-- 4) Cleanup
DROP TABLE temp_preserved;

Zwei Hinweise, die in Produktion wichtig sind:

TRUNCATE ist DDL in MySQL. Es committet implizit, und du kannst es nicht wie eine normale Transaktion zurückrollen.
Du willst ein Wartungsfenster und ein Backup. Das ist kein "probieren wir live und schauen mal".

Implementierung (Laravel/PHP)

Das ist die Version, die ich tatsächlich verwende, wenn ich sie brauche:

protected function deleteViaTruncateAndReinsert(
    string $connection,
    string $tableName,
    string $preserveCondition
): int {
    $tempTable = "temp_preserved_{$tableName}_" . time();

    // You're about to do DDL. Be explicit that you're taking control.
    DB::connection($connection)->statement("SET FOREIGN_KEY_CHECKS=0");

    try {
        DB::connection($connection)->statement("
            CREATE TABLE {$tempTable} AS
            SELECT * FROM {$tableName}
            WHERE {$preserveCondition}
        ");

        $preserved = DB::connection($connection)->table($tempTable)->count();

        DB::connection($connection)->statement("TRUNCATE TABLE {$tableName}");

        DB::connection($connection)->statement("
            INSERT INTO {$tableName}
            SELECT * FROM {$tempTable}
        ");

        DB::connection($connection)->statement("DROP TABLE {$tempTable}");
    } finally {
        DB::connection($connection)->statement("SET FOREIGN_KEY_CHECKS=1");
    }

    return $preserved;
}

Eine Prise Rubber-Duck-Energie: Lies die Funktion noch einmal und frag dein Zukunfts-Ich -

"Bin ich sicher, dass diese Tabelle für einen Moment geleert werden darf?"

Wenn die Antwort kein eindeutiges Ja ist, ist das nicht das richtige Werkzeug.

Fallstricke, die du einplanen musst

Auto-increment resets

TRUNCATE setzt AUTO_INCREMENT zurück. Wenn du es erhalten musst:

SELECT MAX(id) FROM big_table;
ALTER TABLE big_table AUTO_INCREMENT = <max_id + 1>;

Foreign Keys

Wenn andere Tabellen diese hier referenzieren, kann TRUNCATE verboten oder unsicher sein. Nicht einfach "Checks deaktivieren" und hoffen.

Trigger

TRUNCATE löst keine DELETE-Trigger aus. Wenn du Trigger-Nebenwirkungen brauchst, bist du wieder bei DELETE.

Speicherplatz

Du brauchst Platz für den erhaltenen Datensatz (temporäre Tabelle). Erst prüfen:

SELECT
  ROUND(data_length / 1024 / 1024 / 1024, 2) AS data_gb,
  ROUND(index_length / 1024 / 1024 / 1024, 2) AS index_gb
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND table_name = 'big_table';

Replikation / binlog

Das ist DDL + Bulk-Insert. Es kann trotzdem Replica-Lag verursachen. Mach es absichtlich, monitore den Lag, und tu nicht so, als wäre es gratis.

Wenn du (nahezu) Zero Downtime brauchst

Dieser Post handelt vom schnellen Hammer.

Wenn du ein Skalpell brauchst, nimm die Werkzeuge, die dafür gebaut wurden:

pt-archiver (Percona Toolkit) für Batch-Deletes mit replica-freundlichem Pacing
Partitionierungsstrategien (Partitionen statt Zeilen droppen)
Shadow-Table-Ansatz + kontrollierter Swap (komplexer, mehr bewegliche Teile)

Schlussgedanke

Das ist kein cleverer Trick. Es ist die Entscheidung, für welche Arbeit du bezahlst.

Type-0-Refactoring: Der Schritt vor Schritt eins

Sat, 13 Dec 2025 12:00:00 GMT

Es gibt eine Kategorie von Refactoring, die Teams ständig machen, von der sie sofort profitieren und die fast nie einen Namen bekommt.

Es ist die Arbeit, die du direkt erledigst, bevor du die unheimliche Datei anfasst. Der Feature-Wunsch zwingt dich in das chaotische Modul. Der Incident landet, und der Bug versteckt sich irgendwo in einer Methode, die wirkt, als hätte sie ihr eigenes Wettersystem.

Du entwirfst das System nicht neu. Du führst keine neue Abstraktion ein. Du "verbesserst" nichts auf besonders clevere Weise.

Du machst den Code nur lesbar genug, damit du arbeiten kannst.

Ich habe angefangen, das Type-0-Refactoring zu nennen.

Type-0-Refactoring ist eine vorbereitende, verhaltenserhaltende Aufräumarbeit, die Code leichter nachvollziehbar macht, bevor du Architektur-Refactorings, Performance-Arbeit oder Feature-Arbeit angehst.

Es ist der Schritt "erst den Boden trocken bekommen, bevor du die Küche umbaust". Die meisten Teams machen ihn bereits informell. Ihn zu benennen, macht daraus ein gemeinsames Werkzeug.

Der eigentliche Grund für Type 0: Menschen haben ein begrenztes Arbeitsgedächtnis

Hier ist die stumpfe Wahrheit hinter der Idee:

Mein Gehirn (und deins) ist nicht dafür gebaut, unter Zeitdruck verlässlich eine 2000-Zeilen-Methode zu debuggen.

Das ist kein persönlicher Makel. So funktioniert Kognition einfach.

Debugging verlangt, dass du gleichzeitig im Kopf behältst:

den aktuellen Ausführungspfad
den relevanten Zustand
was jede Variable tatsächlich bedeutet
die Menge der möglichen Verzweigungen
die Folgen von "wenn das passiert, dann..."

In kleinem Code ist das beherrschbar.

In großem Code mit hoher zyklomatischer Komplexität wird daraus probabilistisches Raten. Du kannst immer noch Glück haben, aber es ist teuer und riskant, besonders während eines Hotfixes.

Type 0 ist eine praktische Antwort: So kaufst du dir schnell Klarheit, ohne die Kosten und Risiken eines "echten Refactorings" zu übernehmen.

Warum es "Type 0" heißt

Der Name kam nicht aus einer großen Theorie. Er kam aus einem Moment mit hohem Druck.

Ich arbeitete an einem Hotfix. Der Bug war in einer Methode vergraben, die praktisch ihr eigenes kleines Universum war: ungefähr 2000 Zeilen.

Der Bug war konzeptionell nicht schwer. Die Methode war es.

Jedes "was passiert, wenn..." verzweigte sich in zehn weitere Fragen, und diese Verzweigung war nicht die nützliche Art. Es war zufällige Komplexität: Lärm, Wiederholung, unklare Benennung und eine Struktur, die nicht zu dem mentalen Modell passte, das man zum Debuggen braucht.

Was ich brauchte, war keine Perfektion. Ich brauchte Debuggbarkeit:

weniger Verzweigungen pro Bildschirm
klarere "Schritte" mit Namen
weniger Lärm
weniger Zeit damit, erneut zu parsen, was ich gerade gelesen hatte

Aber der Zeitdruck ließ kein größeres Refactoring oder ein "idiomatisches Redesign" zu. Das verantwortlich zu tun, wäre ein halber Tag (oder mehr) gewesen, inklusive manuellem Testen. In einem Hotfix-Fenster ist das keine Disziplin, sondern Zocken.

Also bat ich ein LLM, Refactoring-Möglichkeiten für die Klasse und diese Methode vorzuschlagen, ohne ihm zu sagen, warum.

Es kam mit einer Liste von vier "Typen" von Refactoring zurück. Alle sinnvoll. Alle anwendbar. Alle zu teuer für diesen Moment.

Dann stellte es die höfliche Frage:

"Should I start with Type 1?"

Da antwortete ich:

"No. Let's start with Type 0."

Und ich definierte Type 0 an Ort und Stelle: eine begrenzte, mechanische Menge von Änderungen, die Komplexität reduzieren und Lesbarkeit erhöhen, ohne Verhalten oder Architektur zu verändern.

Die Methode wurde navigierbar. Mein Gehirn konnte den Ausführungsfluss wieder verfolgen. Ich fand den Bug, behob ihn und lieferte aus, ohne Kollateralschäden.

Deshalb mag ich den Namen Type 0: Es ist das Refactoring, das du vor den "echten Refactoring"-Typen machst, besonders wenn du unter Druck stehst und einen sicheren Weg brauchst, schnell Klarheit zu schaffen.

Das Problem, das Type 0 löst

Die meisten Refactoring-Ratschläge setzen voraus, dass du das Design bereits sehen kannst.

In echten Codebasen:

sind Methoden lang und haben mehrere Zwecke
verbergen wiederholte Ausdrücke und zufällige Komplexität die Absicht
sind Variablen kryptisch ($e, $tmp, $res)
erzeugen toter Code und unbenutzte Imports mentalen Lärm
ist die "Form" des Codes so chaotisch, dass selbst kleine Änderungen riskant wirken

Wenn du darauf "echtes Refactoring" versuchst (Grenzen, Patterns, Verantwortlichkeiten verschieben), stapelst du Unsicherheit auf Unsicherheit:

du kannst nicht leicht erkennen, welches Verhalten du bewahrst
du kannst den Blast Radius nicht vorhersagen
Reviews entgleiten in subjektive Debatten
Menschen bekommen Angst, Dinge anzufassen, und das Chaos verstärkt sich

Type 0 senkt zuerst die kognitive Last. Es schafft eine stabile Grundlage, auf der tiefere Arbeit sicher passieren kann.

Greif zu Type 0, wenn...

Type 0 ist am wertvollsten, wenn:

du schnell debuggen musst (Hotfixes, Incidents) und der Code zu groß/verzweigt ist, um sicher darüber nachzudenken
du dich "in der Methode verloren" fühlst und denselben Abschnitt immer wieder liest, weil die Struktur deinem Arbeitsgedächtnis nicht hilft
der Code korrekt, aber unlesbar ist, und du es dir nicht leisten kannst, "Logik aufzuräumen", sondern sie nur freilegen kannst
du vor tieferer Arbeit Risiko reduzieren willst (du weißt, dass du später refactoren wirst, aber zuerst brauchst du eine klare Karte des aktuellen Verhaltens)
du Stammeswissen in lesbare Struktur verwandeln willst, damit Debugging nicht von einer Person abhängt

Type 0 ist kein Luxus. In diesen Fällen ist es oft der schnellste Weg, wieder Kontrolle zu gewinnen.

Eine Definition, die du in deinem Team benutzen kannst

Type-0-Refactoring ist eine Menge von Mikro-Refactorings, die Lesbarkeit und Wartbarkeit verbessern, ohne Verhalten oder Architektur zu verändern.

Es ist absichtlich begrenzt. Die Begrenzungen sind das Feature.

Type 0 besteht aus vier verpflichtenden Sub-Patterns:

0a. Method extraction
0b. Conciseness
0c. Empathy (pure readability)
0d. Dead code removal

Und es folgt drei harten Regeln:

Keine Verhaltensänderungen
Keine Architektur-Änderungen
Keine "cleveren" Verbesserungen jenseits der vier Patterns

Wenn du diese Regeln verletzt, machst du nicht mehr Type 0. Du bist in eine andere Arbeitskategorie gewechselt, und die braucht andere Koordination, andere Review-Strenge und oft eine andere Teststrategie.

Warum überhaupt benennen?

Weil Benennung verändert, wie Teams koordinieren.

"Ich mache in diesem PR nur Type 0" sagt Reviewern, worauf sie achten sollen: Verhaltenserhaltung und Lesbarkeit, nicht Architektur-Debatten.
"Wir brauchen Type 0, bevor wir das refactoren" ist ein ehrliches Eingeständnis, dass der Code noch nicht bereit für tiefere Änderung ist.
"Lasst uns Type 0 als Schritt 0 machen" schafft ein kleines Ritual, das verhindert, dass du auf Chaos aufbaust.

Die vier Sub-Patterns

0a. Method extraction (das Fundament)

Ziel: große Methoden in kleine, fokussierte Methoden zerlegen, damit ein Mensch die Absicht linear lesen kann.

Faustregeln:

zerlege Methoden, die zu lang sind, um sie im Arbeitsgedächtnis zu halten
jede extrahierte Methode sollte eine Sache tun und einen beschreibenden Namen haben
extrahiere bedeutungsvolle Schritte, keine beliebigen Brocken von N Zeilen

Warum es funktioniert (besonders beim Debugging):

kleinere Methoden schaffen Labels für den Ausführungspfad
ein 2000-Zeilen-Scroll wird zu einer kurzen Orchestrierungsmethode, die du mental durchgehen kannst
du kannst Breakpoints an semantische Grenzen setzen ("validate input", "build query", "apply filters"), statt zu suchen

0b. Conciseness (zufällige Komplexität reduzieren)

Ziel: visuellen Lärm entfernen, damit die Absicht hervorsticht.

Beispiele:

wiederholte Ausdrücke in lokale Variablen extrahieren
wiederholte Log-Kontexte / Schlüsselstrings / URL-Fragmente in Variablen extrahieren
Sprachfeatures bevorzugen, die Absicht direkt kommunizieren
übermäßig wortreiche Interpolation vereinfachen

Warum es funktioniert:

es reduziert kognitive Last
es macht Diffs kleiner und Änderungen sicherer
es verhindert Copy/Paste-Drift

0c. Empathy (reine Lesbarkeit)

Ziel: für den nächsten Menschen schreiben, nicht für den Compiler.

Empathy bedeutet:

beschreibende Variablennamen verwenden ($e, $d, $tmp vermeiden, außer sie sind wirklich offensichtlich)
konsistente Terminologie in einem Modul beibehalten
irreführende Namen umbenennen
Code selbstdokumentierend machen

Lackmustest:

Wenn jemand das um 2 Uhr nachts während eines Incidents liest, hilft es ihm, den Ausführungspfad im Kopf zu behalten?

0d. Dead code removal (Lügen entfernen)

Ziel: alles löschen, was vorgibt, wichtig zu sein, es aber nicht ist.

Beispiele:

unbenutzte private Methoden
unbenutzte Imports
auskommentierte alte Ansätze
deprecated Helpers, die niemand aufruft

Warum es funktioniert:

weniger Code bedeutet weniger Dinge, die man missverstehen kann
Suchergebnisse werden vertrauenswürdig

Was Type 0 nicht ist

Type 0 ist nicht:

Service-Grenzen verändern
neue Abstraktionen oder Patterns einführen
einen Workflow neu architektieren
Libraries ersetzen
Verantwortlichkeiten über Schichten hinweg neu ordnen
Logik "fixen", von der du vermutest, dass sie falsch ist (außer du deklarierst explizit eine Verhaltensänderung und testest sie)

Wenn du dich sagen hörst:

"Wenn ich schon hier bin, können wir auch..."
"Das wäre schöner, wenn wir..."
"Wir sollten das wahrscheinlich neu designen..."

dann verlässt du vielleicht Type 0. Das ist nicht an sich schlecht, aber es sollte absichtlich passieren.

Das Kernversprechen: Verhaltenserhaltung (und wie du sie wahr hältst)

Type 0 funktioniert nur, wenn Teams dem Versprechen vertrauen.

Und ja, du hast recht, skeptisch zu sein: Method extraction kann versehentlich Verhalten verändern (early returns, Variablenscope, Auswertungsreihenfolge, Exception-Verhalten).

Deshalb braucht Type 0 Disziplin, die es ehrlich hält:

Extrahiere unverändert, dann benenne um/räume auf.

Erster Durchlauf: Code in Methoden verschieben, ohne Logik zu verändern
Zweiter Durchlauf: conciseness + empathy anwenden
Dritter Durchlauf: toten Code entfernen

Praktische Leitplanken:

ordne Bedingungsprüfungen nicht "für die Lesbarkeit" um
ersetze Logik nicht durch "äquivalente" Logik, außer du bist außerhalb von Type 0
sei vorsichtig mit Variablen, die vorher in gemeinsamem Scope lagen
behandle "kleine" Unterschiede im Control Flow als echte Unterschiede

Und wenn du irgendein Sicherheitsnetz hast, selbst ein dünnes:

führe einen fokussierten Test aus
spiele das fehlschlagende Szenario erneut durch
validiere den einen Pfad, den du berührst

Bei Type 0 geht es darum, schnell zu sein: aber schnell durch Reduktion kognitiver Komplexität, nicht schnell durch das Überspringen von Sicherheit.

Type 0 als wiederholbares Team-Ritual

1) Entscheide den Scope (Timeboxing hilft)

Beispiele:

"Type 0 the hot path before debugging."
"Type 0 only the path touched by this bug fix."

2) Identifiziere die "Wirbelsäule" des Codes

Finde die Entry-Methode(n) und die Verzweigungspunkte. Verwandle diese Wirbelsäule durch Extraktion in eine lesbare Erzählung.

3) Wende die vier Sub-Patterns der Reihe nach an

Method extraction → conciseness → empathy → dead code removal.

4) Führe eine "Type-0-Checklist" in deinem PR

Keine Verhaltensänderungen (Inputs/Outputs unverändert)
Keine Architekturbewegungen
Methoden extrahiert und als bedeutungsvolle Schritte benannt
Wiederholte Ausdrücke extrahiert, wo es Klarheit verbessert
Variablen umbenannt; Terminologie konsistent
Toter Code und unbenutzte Imports entfernt

Schlussgedanke

Type-0-Refactoring ist das einfachste Versprechen, das ein Entwickler geben kann:

"Ich hinterlasse diesen Code leichter bearbeitbar, als ich ihn vorgefunden habe, ohne zu verändern, was er tut."

Manchmal ist das "nice to have".

Und manchmal ist es der einzige Weg, wie ein Mensch sich sicher schnell in einem hochkomplexen Chaos bewegen kann, besonders während eines Hotfixes.

Wasch einen Teller mehr: Eine einfache Regel fuer eine dauerhaft saubere Codebase

Thu, 24 Jul 2025 00:00:00 GMT

TL;DR: Behandle jede Aenderung an deiner Codebase wie das Kochen einer Mahlzeit. Du wirst ein paar Teller schmutzig machen. Wenn du fertig bist, wasch nicht nur die Teller, die du benutzt hast - wasch einen mehr. Mit der Zeit summiert sich dieser winzige Ueberschuss an Sorgfalt zu einer Kueche (Codebase), die sauber bleibt, statt ins Chaos abzugleiten.

Die Metapher: Kochen, Teller und Code

Stell dir eine Profikueche vor. Jedes gekochte Gericht macht ein paar Teller schmutzig - selbst in der ordentlichsten Brigade. Stell dir nun vor, dass jeder Koch nach seinem Gericht genau die Teller waescht, die er schmutzig gemacht hat. Die Kueche wird knapp an der Grenze akzeptabler Sauberkeit bleiben, aber die Entropie kriecht hinein: hier ein bisschen Restschmutz, dort ein fleckiges Schneidebrett. Irgendwann summiert sich das Durcheinander.

Dreh die Regel jetzt um: Nach dem Kochen waescht jeder Chef einen Teller mehr, als er schmutzig gemacht hat. Langsam wird die Kueche sauberer als vorher - nicht nur erhalten, sondern verbessert. Dasselbe gilt fuer Software: Jede Aufgabe, die du uebernimmst, sollte der Codebase mindestens einen winzigen Ueberschuss an Sauberkeit geben - einen weiteren Test, einen klareren Namen, eine aufgeteilte Funktion, eine tote Dependency weniger. Diese "+1 Teller"-Gewohnheit ist der Weg, wie eine Codebase gesund bleibt.

Ich nenne das die Wasch-einen-Teller-mehr-Regel.

Echos aus dem Handwerk: Du bist in guter Gesellschaft

Das ist keine einsame Philosophie. Vordenker der Softwarewelt predigen seit Jahrzehnten aehnliche Ideen:

"Always leave the campground cleaner than you found it." Das ist die klassische Boy Scout Rule, die Robert C. Martin in der Softwarewelt populaer gemacht hat. Derselbe Geist: jedes Mal ein bisschen verbessern.
Technical Debt als Metapher (Ward Cunningham): Schulden sammeln Zinsen - ignorier sie, und die "Kueche" kostet morgen mehr in der Benutzung. Wenn du unterwegs etwas davon abtraegst, bleibst du zahlungsfaehig.
Refactoring als kleine, kontinuierliche Schritte (Martin Fowler): winzige Aenderungen, die Verhalten erhalten, aber Design verbessern. Kleine Schritte bedeuten geringes Risiko und stetigen Schwung.
"Make it work, make it right, make it fast" (Kent Beck): zuerst Korrektheit, dann Sauberkeit, dann Performance. Den zusaetzlichen Teller zu waschen gehoert in die "make it right"-Phase - bevor du vorschnell optimierst.
Broken-Windows-Theorie auf Code angewandt (Andrew Hunt & David Thomas): sichtbares Chaos laedt zu mehr Chaos ein. Ein "Fenster" zu reparieren, bevor es sich ausbreitet, schuetzt die Nachbarschaft (die Codebase).

Diese Ideen verstaerken einander. Sie sagen alle: Gib das Durcheinander nicht weiter; nimm dir einen Moment, um es besser zu machen.

Warum der zusaetzliche Teller zaehlt (auch wenn du beschaeftigt bist)

1. Entropie ist real

Sich selbst ueberlassen bleibt Code nicht neutral. Namen driften, Patterns zerfallen, Abstraktionen verrotten. Entropie ist eine Kraft; die einzige Gegenkraft ist konstantes, inkrementelles Aufraeumen. Dein +1 Teller ist Micro-Entropieumkehr.

2. Schulden verzinsen sich schneller, als du denkst

Die Kosten von Aenderungen wachsen mit jedem "das fixen wir spaeter". Spaeter kommt selten. Die Zinszahlungen zeigen sich als langsamere Feature-Arbeit, fragile Deployments und Testsuites, denen niemand vertraut. Einen zusaetzlichen Teller heute zu waschen, senkt morgen den Zinssatz.

3. Das soziale Signal

Wenn Teamkollegen sehen, dass du hinter dir aufraeumst (und noch ein bisschen mehr), verschiebt sich die Norm. Es wird glaubwuerdig - und erwartet -, Code besser zu hinterlassen, als man ihn vorgefunden hat. Kultur folgt Verhalten.

4. Schwung, nicht Perfektionismus

Das ist keine Ausrede fuer Yak Shaving. Du baust die Kueche nicht mitten im Service neu. Du faehrst mit dem Schwamm ueber noch einen Teller - klein, sicher und schnell. Genau das haelt Lieferung auf Kurs.

Wie man die Wasch-einen-Teller-mehr-Regel praktiziert

So verankerst du die Gewohnheit, ohne Scope oder Deadlines zu sprengen.

1. Mach "Micro-Refactoring" zu einem Teil von Definition of Done

Benenne eine verwirrende Variable um.
Extrahiere eine kleine Funktion, um zyklomatische Komplexitaet zu reduzieren.
Loesche toten Code oder ungenutzte Imports.
Fuege einen fehlenden Test fuer einen Bug hinzu, den du gerade gefixt hast.
Aktualisiere Dokumentation oder einen README-Abschnitt, der dich kurz erschreckt hat.

Das Kriterium: Wenn es mehr als ein paar Minuten dauert, ist es kein Teller - es ist die ganze Spuelmaschine. Verschieb es. Halte es als Ticket fest.

2. Nutze Pull Requests als Reinigungsausloeser

Jeder PR kann den Zeltplatz sauberer hinterlassen:

Verlange eine "Was hast du gereinigt?"-Checkbox oder eine kurze Notiz.
Ermutige Reviewer, neben ihrem Review kleine Aufraeumarbeiten zu erbitten.
Feiere PRs, die diesen Extra-Schliff enthalten (Shout-outs im Standup wirken erstaunlich gut).

3. Automatisiere die einfachen Teller

Pre-commit Hooks fuer Formatierung und Linting.
Statische Analyse, die komplexe Methoden oder lange Parameterlisten markiert.
Dependency Checker fuer veraltete Libraries.

Lass automatisierte Besen den trivialen Schmutz wegfegen, damit Menschen sich auf Logik und Design konzentrieren koennen.

4. Verankere es in Teamnormen

Nimm die Regel in euer Working Agreement oder Engineering Handbook auf.
Tracke Micro-Refactor-Erfolge in Retros, wenn du messbare Belege willst.
Programmiert gelegentlich im Pair oder Mob, um die Gewohnheit (und den Mut) zu verbreiten.

5. Wisse, wann du nicht waschen solltest

Manchmal brennt die Kueche: Production ist down, oder eine Demo ist nur noch Stunden entfernt. In Notfaellen zerschlag den Stapel schmutziger Teller, wenn es sein muss. Aber komm nach der Krise darauf zurueck. Die Regel ist kein Dogma; sie ist Disziplin.

Die Grenze: Ein Teller, nicht das ganze Spuelbecken

Scope Creep tarnt sich gern als Handwerkskunst. Deine Aufgabe ist, bei "einem weiteren Teller" aufzuhören. Wenn dieses kleine Refactoring einen tieferen Geruch freilegt, schreib ihn auf und geh weiter. Parke den tieferen Fix:

Erstelle ein Ticket mit dem Label refactor: oder techdebt:.
Verlinke es mit dem relevanten Code, den Tests oder dem Modul.
Fuege eine kurze Notiz hinzu, warum es wichtig ist.

Du hast deine Pflicht getan: Du hast das Durcheinander gesehen, einen Teller gewaschen und Anweisungen fuer den Rest hinterlassen.

Beispiel: Aus einer chaotischen Funktion eine testbare machen

Vorher:

function processOrder($order) {
    if(!$order->id) throw new Exception('No ID');
    $tax = 0;
    if ($order->country === 'BG') {
        $tax = $order->total * 0.20;
    } else if ($order->country === 'DE') {
        $tax = $order->total * 0.19;
    }
    // Lots more branching...
    // Sends email, writes to DB, calls payment gateway…
}

Gewaschener Teller:

/**
 * Calculate VAT for an order based on country.
 * Pure function: given (total, country) -> VAT amount.
 */
function vatFor(string $country, float $total): float {
    return match($country) {
        'BG' => $total * 0.20,
        'DE' => $total * 0.19,
        default => 0.0,
    };
}

Jetzt ruft deine Hauptfunktion vatFor() auf, statt die Logik inline zu halten. Du hast einen Micro-Test fuer vatFor() hinzugefuegt. Das ist ein zusaetzlicher Teller - einfach, begrenzt, hilfreich.

Schlussgedanken

Ein Teller mehr ist winzig. Genau darum geht es. Du brauchst keine heroischen Refactorings, um eine Codebase gesund zu halten; du brauchst eine Kultur kleiner, stetiger Sorgfalt. Mach es zur Gewohnheit, back es in euren Prozess ein, und in einem Jahr wirst du dich fragen, warum deine Kueche keine Katastrophe ist - weil du nie zugelassen hast, dass sie eine wird.

Call to Action: Wenn du das naechste Mal eine Datei beruehrst, frag dich: "Welchen zusaetzlichen Teller kann ich waschen, bevor ich diese Aenderung committe?" Dann tu es. Wiederholen. Kultur veraendern, ein makelloser Teller nach dem anderen.

Quellen & Weiterfuehrende Lektuere

Robert C. Martin ("Uncle Bob") - Boy Scout Rule: "The Boy Scout Rule" aus 97 Things Every Programmer Should Know.
Ward Cunningham - Technical Debt Metaphor: Cunninghams urspruengliche Erklaerung von Technical Debt auf Martin Fowlers Website.
Martin Fowler - Continuous Micro-Refactoring: Fowlers Buch Refactoring: Improving the Design of Existing Code.
Kent Beck - "Make it work, make it right, make it fast": Eine Erklaerung des Mantras von Ron Jeffries.
Andrew Hunt & David Thomas - Broken Windows in Software: Das Konzept wird in ihrem Buch The Pragmatic Programmer beschrieben.
Software Entropy & Maintenance: Eine gute Lektuere zum Thema ist "Entropy in Software and the Broken Window Theory."

PHP 8.5: Eine Tour durch die kommenden Features

Sun, 20 Jul 2025 00:00:00 GMT

TL;DR-Hype-Leiter (mein spielerisches Ranking)

Pipe-Operator (|>) - Lesbarer, linearer Transformationsgenuss. Refactoring-Magnet.
Attribut #[\NoDiscard] - Macht aus "Rückgabewert vergessen" eine sofortige Warnung. Passt wunderbar zu Pipes.
Statische Closures / First-Class Callables in Konstantenausdrücken - Strategy-Maps und Attributargumente zur Compile-Zeit. Framework-Süßigkeit.
php --ini=diff - Sofortiger Diff für Environment-Drift. Rettet dich vor Config-Höhlenforschung.
Attribute auf globalen und Klassenkonstanten - Metadaten überall (Flags, Deprecations, semantische Tags).
array_first() / array_last() - Offensichtlich, absichtsvoll, nicht-mutierend. Tschüss, reset()-Nebenwirkungen.
get_exception_handler() und Freunde - Introspektion für geschichtetes Error-Handling (Gewinn auf Framework-/Infra-Ebene).
Intl-Goodies (IntlListFormatter, Locale::isRightToLeft()) - Glattere, lokalisierte UX mit fast keinem Code.
Graphem-bewusstes Levenshtein - User-facing Fuzzy Matching, das menschliche Zeichen tatsächlich respektiert.
Directory Object + cURL / Build-Introspektion / Sonstiges - Konsistenz- und Operability-Politur.

(Ja, deine Reihenfolge kann anders sein. Genau das macht Spaß - streitet bei Kaffee darüber.)

1. Pipe-Operator (`|>`) - "Easy Peasy Lemon Squeezy"

Verschachtelte Aufrufe und temporäre Wegwerfvariablen? Weg. Der Pipe-Operator nimmt den Wert links und füttert ihn als erstes Argument in das Callable rechts. Du liest von oben nach unten, die Logik fließt wie Prosa, und die Absicht springt dir ins Gesicht.

Vorher (Variablen-Hüpfspiel):

$email = $request->string('email');
$email = trim($email);
$email = strtolower($email);
sendEmail($email);

Vorher (Klammernest):

sendEmail(strtolower(trim($request->string('email'))));

Nachher (Pipe-Zen):

$request->string('email')
    |> trim(...)
    |> strtolower(...)
    |> sendEmail(...);

Warum das zählt:

Visueller Datenfluss. Kein mentaler Stapel verschachtelter Rückgaben.
Kombiniert sich wunderbar mit kleinen, reinen Helfern.
Ermutigt dazu, Transformationen in benannte Funktionen / Closures zu zerlegen.
Erfüllt #[\NoDiscard] automatisch, weil der Wert weiterwandert.

Style-Tipp: Halte jede Stufe frei von Side-Effects; reserviere die letzte Pipe für einen Effekt (z. B. persistieren, senden, emitten), damit du visuell erkennst, wo "Reinheit" endet.

2. `#[\NoDiscard]` - Absicht mit Zähnen

Wie viele subtile Bugs waren bloß: "Wir haben das Ding aufgerufen, aber vergessen, den Rückgabewert zu benutzen"? Markiere eine Funktion oder Methode mit #[\NoDiscard], um zu verlangen, dass ihr Ergebnis verwendet wird - oder bewusst per (void)-Cast ignoriert.

#[\NoDiscard("Token must be used – did you forget to persist or dispatch?")]
function issueAuthToken(User $user): string {
    return generateTokenFor($user);
}

issueAuthToken($user); // ⚠ Emits warning in 8.5
(void) issueAuthToken($user); // Explicit intentional discard

Patterns:

Result-Objekte (Result, Outcome, ValidationReport).
Immutable Builder (geben bei jedem Aufruf eine neue Instanz zurück).
Security- / Side-Effect-Gates (Tokens, Signaturen).

Synergie: In einer Pipeline wird die Rückgabe jeder Stufe von der nächsten zwangsläufig konsumiert, also verschwinden versehentliche Discards.

3. Statische Closures in Konstantenausdrücken - "Moment... was?!"

Du kannst jetzt statische Closures (oder First-Class Callables) in Konstantenausdrücke, Default-Property-Werte, Attributargumente und Default-Parameter-Arrays einbetten. Denk an Compile-Time-Registries ohne Boot-Time-Verkabelungsakrobatik.

class Sanitizers {
    public const STAGES = [
        'trim' => trim(...),
        'upper' => static function (string $v): string { return strtoupper($v); },
    ];
}

// Attribute example
#[Validate(
    rules: [
        'title' => static function(string $v){ return mb_strlen($v) > 0; },
        'slug'  => static function(string $v){ return preg_match('/^[a-z0-9-]+$/', $v); },
    ]
)]
class Article {}

Warum das knallt:

Beseitigt Service-Locator-Lookups für einfache Strategien.
Schiebt reine Mapping-Tabellen in Konstanten (immutable + cachebar).
Attribute können Logik jetzt direkt kapseln - nicht nur skalare Metadaten.

Einschränkung: Muss static sein; kein $this, kein Capturing von Variablen. Wenn du Kontext brauchst, gib ihn später explizit mit.

4. `php --ini=diff` - Röntgenblick für Config-Drift

Müde von "Aber auf Staging funktioniert es"? Dieses CLI-Flag gibt nur die INI-Direktiven aus, die vom Default abweichen.

php --ini=diff
# memory_limit: "128M" -> "-1"
# max_execution_time: "30" -> "0"

Use Cases:

CI-Step, um eine konsistente Baseline durchzusetzen.
Schneller Sanity Check, wenn ein Worker sich merkwürdig verhält.
Triage von Memory-/Time-Anomalien.

Pro-Tipp: Capture den Output in Version Control für Runtime-Baselines.

5. Attribute auf globalen und Klassenkonstanten - Metadaten überall

Konstanten steigen vom "dummen Wert" zum "annotierten Teilnehmer" auf. Dekoriere Domain-Flags, Feature-Toggles, Deprecation-Hinweise, Unit-Semantik - direkt an der Definitionsstelle.

#[Deprecated("Use FEATURE_NEW_PRICING instead")]
public const FEATURE_OLD_PRICING = 1;

#[Unit("ms")]
public const DEFAULT_TIMEOUT = 250;

Framework-Hebel: Deprecations automatisch entdecken, Feature-Kataloge füttern, Docs generieren oder Policies per Reflection erzwingen.

6. `array_first()` / `array_last()` - Das Offensichtliche existiert endlich

Hör auf, Pointer-Akrobatik (reset(), end()) zu machen oder Arrays zu slicen, nur um hineinzuschauen. Diese Helfer lesen sich direkt nach Absicht und mutieren den internen Array-Zustand nicht.

$firstUser = array_first($users, default: null);
$lastUser  = array_last($users, default: null);

Refactor-Pattern: Grep nach reset( / end( / kompliziertem array_slice(..., 0, 1) - ersetze es durch semantische Calls. Sauberere Diffs, weniger Mikro-Bugs.

7. `get_exception_handler()` (und bessere Fatal Traces) - Observability-Upgrade

Framework- / Infra-Entwickler dürfen sich freuen: Du kannst jetzt den aktiven Exception Handler introspektieren. Chainen, wrappen, wiederherstellen oder dekorieren, ohne brüchiges globales Jonglieren.

$previous = get_exception_handler();
set_exception_handler(function(Throwable $e) use ($previous) {
    logToSentry($e);
    if ($previous) { $previous($e); }
});

Gekoppelt mit reicheren Stack Traces bei Fatal Errors beschleunigt das Production-Postmortems dramatisch.

8. Intl-Erweiterungen - menschenfreundliche Listen und Richtung

IntlListFormatter rendert charmante, locale-bewusste Konjunktionen/Disjunktionen ohne handgerollte Klebelogik.

$f = new IntlListFormatter('pt_PT', 'conjunction');
echo $f->format(['Lisboa', 'Porto', 'Coimbra']); // "Lisboa, Porto e Coimbra"

$fOr = new IntlListFormatter('en_US', 'disjunction');
echo $fOr->format(['apples', 'bananas', 'cherries']); // "apples, bananas, or cherries"

Kombiniere das mit Locale::isRightToLeft() (oder locale_is_right_to_left()), um die Layout-Richtung automatisch umzuschalten.

9. Graphem-bewusstes Levenshtein - echte String-Distanz für Nutzer

Wenn Nutzer Emoji, Akzente oder kombinierende Zeichen tippen, lügen Byte-Distanz oder naive Codepoint-Distanz. grapheme_levenshtein() respektiert sichtbare Zeichen.

grapheme_levenshtein('café', 'cafe'); // 0 – visually same after accent

Suchvorschläge, Fuzzy Match und typo-tolerante Login-Flows werden sprachlich fair.

10. Die Politur-Parade

Directory Object: opendir() gibt dir jetzt ein echtes Objekt (Type Safety, künftige Erweiterbarkeit) statt einer Legacy-Resource.

cURL-Verbesserungen: Bessere Share Handles + Multi-Handle-Introspektion = bessere Connection Reuse in langlebigen Workern (denk an RoadRunner, Swoole) und feineres Performance-Tuning.

PHP_BUILD_DATE: Schneller "Wie alt ist dieses Binary?"-Check für Audit-Scripts. Großartig, um sicherzustellen, dass Fleet Nodes nicht still hinterherhinken.

Feature-Synergie-Cheat-Sheet

Ziel	Kombiniere
Transformationspipeline mit erzwungener Nutzung	`	>`+`#[\NoDiscard]`
Deklarative Validation / Strategy-Maps	Statische Closures in Konstantenausdrücken + Konstantenattribute
Sicherere Refactors von Legacy-Arrays	`array_first()/array_last()` + strikte Return Types
Production-Incident-Triage	Bessere Fatal Stack Traces + `php --ini=diff` + `get_exception_handler()`
Internationaler UX-Feinschliff	`IntlListFormatter` + Richtungserkennung + Graphem-Distanz

Praktischer Einführungsplan

Pipe-Operator schrittweise einführen: Starte in reinen Daten-Normalisierungsschichten; erzwinge Style (ein Side-Effect am Ende) im Code Review.
Kritische APIs mit #[\NoDiscard] annotieren: Konzentriere dich zuerst auf Security, Persistenz und Builder - miss Warning Counts in CI.
Strategy Tables refactoren: Verschiebe einfache Callable-Maps in public const-Arrays mit statischen Closures für Null-Boot-Kosten.
Config-Drift-Checks: Füge einen CI-Job hinzu, der php --ini=diff-Output captured; alarmiere bei unerwarteten Änderungen.
Metadaten-Sweep: Tagge Konstanten mit Deprecation / Units / Feature Flags, um internes Tooling zu füttern.
Array-Edge-Extraction-Cleanup: Codemod, um Pointer-manipulierende Patterns zu ersetzen.
Error-Handler-Layering: Wrappe bestehende globale Handler mit get_exception_handler() für Observability (Sentry/New-Relic-Instrumentierung).
i18n-Erweiterungen: Ersetze manuellen "List Glue"-Code durch IntlListFormatter; teste automatische RTL-Layoutauswahl.
Fuzzy-Matching-Qualität: Wo nutzergenerierter multilingualer Text auftaucht (Suche, Tagging), benchmarke Graphem- gegen klassische Distanz.
Runtime-Audit-Script: Logge PHP_BUILD_DATE + php --ini=diff täglich, um alternde Container zu erkennen.

Fallstricke & Gotchas

Item	Worauf du achten musst	Mitigation
Pipe-Operator-Missbrauch	Side-Effects mitten in der Pipeline	Auf reine Funktionen bis zur letzten Stufe beschränken
`#[\NoDiscard]`-Overuse	Noise Fatigue (Warnungsblindheit)	Nur auf semantisch kritische Rückgaben anwenden
Grenzen statischer Closures	Captured Context nötig	Kontext als expliziten Param übergeben oder Factory nutzen
Konstantenattribute-Wildwuchs	Metadaten-Fragmentierung	Interne Namenskonventionen für Attribute etablieren
i18n-Listenformatierung	Angenommener Interpunktionsstil	Snapshot-Tests pro Locale

"Show Me" Mini-Playground

#[NoDiscard("Hash must be stored or compared")]
function password_hash_safe(string $plain): string {
    return password_hash($plain, PASSWORD_DEFAULT);
}

function sanitize_email(string $raw): string { return strtolower(trim($raw)); }

$request->string('email')
    |> sanitize_email(...)
    |> fn($email) => (strlen($email) > 5 ? $email : throw new InvalidArgumentException('Too short'))
    |> sendEmail(...); // Each stage consumes prior result – no discard.

class Rules {
    public const VALIDATORS = [
        'title' => static function(string $v){ return $v !== ''; },
        'slug'  => static function(string $v){ return (bool) preg_match('/^[a-z0-9-]+$/', $v); },
    ];
}

foreach (Rules::VALIDATORS as $field => $check) {
    if (! $check($data[$field] ?? '')) {
        throw new RuntimeException("Invalid $field");
    }
}

Wann du nicht nach dem glänzenden Ding greifen solltest

Eine einzelne triviale Transformation? Eine Pipe könnte Overkill sein; strtolower($x) ist weiterhin okay.
Kontextlastige Closures? Reguläre Methoden mit Dependency Injection > statische Closure-Hacks.
Legacy-Codebase mitten im Upgrade? Führe ein Feature nach dem anderen ein, um kognitive Unruhe zu vermeiden.

Mental-Model-Recap

Feature	Zentrales mentales Modell
`	>`	Lineares Value Threading; Nesting & Temp-Vars eliminieren
`#[\NoDiscard]`	Absichtsvollen Konsum erzwingen (verwenden oder per `(void)` ignorieren)
Statische Closure-Konstanten	Immutable Strategy Registry, zur Load-Time vorbereitet
Attribute auf Konstanten	First-Class-Metadatenkanal für Tooling & Policies
`array_first()/last()`	Deklarativer, nicht-mutierender Zugriff auf Ränder
`php --ini=diff`	Config-Delta-Linse gegenüber Default-Baseline
`get_exception_handler()`	Globalen Exception Flow introspektieren & wrappen
Intl-Erweiterungen	Eingebaute Locale-Intelligenz statt handgemachtem Kleber
Graphem-Distanz	Operationen auf menschlich wahrgenommenen Zeichen statt rohen Codepoints
Build- & Resource-Politur	Inkrementelle Standardisierung & Introspektion

Final Vibes

PHP 8.5 schreit nicht mit Paradigmenwechseln - es flüstert unerbittliche Ergonomiegewinne. Allein die Kombination aus Pipe-Operator + #[\NoDiscard] wird deinen Code in Richtung klarerer Absicht schubsen. Streu Compile-Time-Closures und Konstantenattribute darüber, und deine Frameworks/Components fühlen sich deklarativer, expliziter, auffindbarer an. Bam bam boom - ship it.

Du bist dran: Such dir ein Feature aus (wahrscheinlich die Pipe), wende es chirurgisch in einem kleinen Modul an, miss die Klarheit im Code-Review-Feedback, dann erweitere. Momentum schlägt Big-Bang-Rewrites.

Bleib spielerisch, refactore mutig, und - ja - schreib deinen Taylors, wenn du die "Moment, WAS?!"-Momente findest.

Happy Coding.

Was ist "gute" Code Coverage? Ein Leitfaden aus der Praxis

Tue, 15 Jul 2025 00:00:00 GMT

Was ist "gute" Code Coverage? Mein Praxisleitfaden, um Bugs zu stoppen, ohne Engineering-Zeit zu verbrennen

Jedes Mal, wenn ich npm run coverage oder phpunit --coverage ausführe, taucht dieselbe Frage auf:

"Okay ... 74 %. Reicht das?"

Die Softwareentwicklungs-Blogosphäre ruft "100 % oder gar nichts!" Währenddessen erinnert mich launchdarkly.com höflich daran, dass 100 % ausgeführt nicht 100 % getestet bedeutet.
Ich habe Wochen damit verbracht, dieser glänzenden Kennzahl hinterherzulaufen, und noch mehr Wochen damit, andere Probleme zu debuggen. Das hier ist der praxiserprobte Mittelweg, bei dem ich gelandet bin.

Warum 100 % Coverage eine Fata Morgana sind

In der Theorie bedeutet 100 % Zeilenausführung: "keine versteckten Bugs." In der Praxis:

Abnehmender Grenznutzen: 90 %→95 % verdoppelt oft deine Testsuite, bringt aber nur eine einstellige Risikoreduktion.
Falsche Sicherheit: Ein Test, der eine Funktion ohne Assertion aufruft, zählt trotzdem als abgedeckt.
Business-Realität: Jeder zusätzliche Test ist Zeit, die nicht in Features fließt, nach denen deine Kunden gefragt haben.

Die Aerospace-Leute können 100 % anpeilen — dort geht es um Leben und Tod. Für den Rest von uns ist ~80 % die 80/20-Linie. Dort landen die meisten Projekte nach ROI-Rechnungen. testdevlab.com nennt aus genau diesem Grund den Bereich 70–90 %.

Die praktische Tabelle, die ich benutze

Coverage	Meine Übersetzung	Handlung
100 %	"Wir sind eine Library, die Raketen fliegt"	Den Aufwand akzeptieren.
90 % +	"Library, von der viel Geld abhängt"	Nur für Module mit hoher Priorität.
80 %	Shippen, beobachten, dann iterieren.
60–70 %	Merge-Gate — PR fehlschlagen lassen, wenn neuer Code dich darunter zieht.
< 50 %	Wochenende mit Tech Debt — zuerst auf kritische Pfade umschwenken.

Ich habe diese Zahlen aus Atlassians internem Leitfaden geklaut: 60 % "acceptable", 75 % "commendable", 90 % "exemplary". Funktioniert in jeder Retro.

Wie ich 80 % erreiche, ohne zu weinen (TypeScript-Playbook)

Jest + Istanbul direkt out of the box

Coverage-Gate in CI
In jest.config.js füge ich hinzu:

coverageThreshold: {
  global: 80,
  '**/src/core/**': 90
}

Ziel sind die heißen Nutzerpfade, nicht der Redux-Boilerplate-Logger.

Wie ich 80 % in Laravel erreiche (PHP-Playbook)

PCOV für Geschwindigkeit in der Entwicklung installieren, Xdebug für Branch-Daten in CI.

PHPUnit + diese Defaults in phpunit.xml:

<filter>
  <whitelist processUncoveredFiles="true">
    <directory suffix=".php">./src</directory>
  </whitelist>
</filter>

Mutation Score > Line Count mit Infection — so finde ich Zeilen, die "abgedeckt, aber nicht wirklich getestet" sind.

4 Regeln, nach denen mein Team lebt

Neuer Code = Tests. Diff Coverage ≥ 90 % vor dem Merge.
Erst refactoren, dann testen. Untestbarer Code ist bereits Debt.
Den Build fehlschlagen lassen, nicht die Menschen. Das Gate jedes Jahr um 5 % senken, statt Teams mit roten Dashboards zu brechen.
Bugs in Produktion messen — wenn Coverage 85 % beträgt, aber Incidents hochgehen, ist Coverage nicht der Schuldige; Assertions sind es.

TL;DR (auch für Executives und Recruiter)

Frag mich nicht nach einer "magischen Zahl". Frag:

Welche Teile des Produkts dürfen nicht kaputtgehen?

Decke diese mit 90 % ab. Gib dem Rest gesunde Smoke Tests. Benutze Code Coverage als Scheinwerfer, nicht als Ziellinie, und vertraue den Bugs, die du fängst, nicht den Zahlen, mit denen du prahlen kannst.

Lass das Coverage-Dashboard grün sein — deine Kunden werden es nie sehen, aber ihre Fehlerleiste bleibt leer.

— Ende des Rants, zurück in den Editor.

Mein essenzieller Leitfaden für wirksame Pull-Request-Reviews

Sun, 06 Jul 2025 00:00:00 GMT

Als jemand, der viel Code schreibt und reviewt, habe ich gelernt, dass Pull-Request-Reviews (PRs) mehr sind als Bugkontrollen. Es geht um gemeinsame Verantwortung, Wissenstransfer und darum, zusammen besseren Code zu bauen. Hier ist ein knapper, praktischer Leitfaden, der PRs wertvoller und weniger schmerzhaft macht.

1. Ziele eines guten Reviews

Auf Verbesserung fokussieren, nicht auf Perfektion
Perfekter Code ist unrealistisch - ziele auf besseren Code. Wenn ein PR Lesbarkeit, Wartbarkeit oder Korrektheit verbessert, approve ihn, auch wenn kleine Stilkorrekturen offen bleiben. Nutze "Nit:" für optionale Vorschläge. google.github.io
Gemeinsame Verantwortung & Mentorship
Behandle PRs als gemeinsamen Code. Gib lehrreiches Feedback ("Nit: du könntest hier X verwenden..."), begleite Junior-Entwickler und bleib auch offen dafür, von ihnen zu lernen.

2. Vorbereitung vor dem Review

Autoren: Self-Review: Tests, Linters und Formatters laufen lassen. Kontext in PR-Beschreibungen geben und komplexe Logik annotieren.
Reviewer: Lies zuerst die Beschreibung. Verstehe das "Warum", bevor du in den Code eintauchst.

3. PRs klein & fokussiert halten

Daten zeigen, dass die Review-Qualität jenseits von etwa ~400 LOC und ~60 Minuten deutlich abfällt. atlassian.com devzery.com mikeconley.ca
Richtlinien:

Bleib unter 200-400 LOC pro PR. mikeconley.ca
Halte Reviews unter 60 Minuten.
Nutze für große Features gestapelte PRs (DB -> API -> UI).

4. Reviewer bewusst auswählen

Ein primärer Reviewer, idealerweise mit Domain-Wissen.
Maximal zwei Reviewer, damit Verantwortung nicht diffundiert. support.smartbear.com abseil.io slab.com
Rotiere Reviewer für Cross-Training und einen gesunden Bus-Faktor.

5. Was in einem PR zu prüfen ist

Nutze diese mentale Checkliste:

Korrektheit: Erfüllt es die Anforderungen und behandelt es Edge Cases?
Design: Ist es gut strukturiert und idiomatisch?
Lesbarkeit: Klare Namen, einfache Logik, konsistenter Stil.
Security: Eingaben validieren, Ausgaben sanitizen, Leaks vermeiden.
Performance: Auf schwere Schleifen und N+1-Queries achten.
Tests: Abdeckung für Kern-, Rand- und Fehlerfälle.
Compliance: Passende Dokumentation, CI, Lizenzen, Formatierung.

So stellen wir sicher, dass wir Probleme früh erwischen - besonders Wartbarkeitsprobleme. google.github.io developers.google.com google.github.io

6. Automatisierung nutzen

Lass Werkzeuge die Fleißarbeit erledigen:

Linters (ESLint, RuboCop, SonarQube)
Formatters (Prettier, Black)
CI-Pipelines mit Tests, Coverage und Security-Checks

So können menschliche Reviewer sich auf Logik, Architektur und Nuance konzentrieren.

7. Konstruktives & freundliches Feedback geben

Sei respektvoll - kommentiere Vorschläge, nicht Menschen.
Lobe, was gut gelungen ist.
Sei handlungsorientiert: Erkläre das Warum und schlage das Wie vor.
Präfixe Nicht-Blocker mit "Nit:" oder "Optional:". atlassian.com google.github.io
Halte Diskussionen sachlich ("wir" > "du"). Vermeide persönliche Kritik.
Schlag ein synchrones Gespräch vor, wenn ein Hin und Her den Prozess blockiert. atlassian.com

8. Den Prozess messen, nicht Menschen

Wichtige Metriken, um Trends zu verfolgen (nicht um Einzelpersonen zu bewerten):

Turnaround-Zeit (PR offen -> Merge)
Inspection Rate (< 300-500 LOC/Std. ist am besten) atlassian.com developers.google.com mikeconley.ca
Defektdichte (Issues pro LOC)
Review-Abdeckung über Komponenten hinweg
Anzahl der Follow-up-Commits

Nutze Erkenntnisse, um deinen Workflow zu verbessern - zum Beispiel kleinere PRs stärker zu betonen, Dokumentation zu verbessern oder bei schwierigen Modulen Wissen aufzubauen. Aber knüpfe Metriken niemals an Performance Reviews. mikeconley.ca google.github.io bssw.io

9. Sprachspezifische Überlegungen

Verschiedene Paradigmen brauchen unterschiedliche Aufmerksamkeit:

PHP/JavaScript/TS: Async-Handling, XSS, SOLID-Prinzipien
Python: Ressourcenmanagement (with), PEP 8, Fallstricke bei Default-Args
Haskell/Scala funktional: Typsignaturen, Purity, Immutability, Macro-Checks
C/C++: Memory Safety, Pointer, RAII
Java: Null-Safety, saubere Concurrency, SOLID
Lisp: Macro-Dokumentation, dynamische Typisierung, idiomatische Muster

Passe Checklisten an deinen Stack an und beziehe Expertinnen und Experten ein, wenn Sprachen ungewohnt sind.

Bonus: Empfohlene Deep-Dive-Quellen

Googles The Standard of Code Review – Philosophie zu Code Health und Mentorship. google.github.io
Google Code Review Developer Guide – Checklistenartige Orientierung. bssw.io
SmartBear/Cisco-Studie – Empirische Erkenntnisse zu PR-Größe und Timing. mikeconley.ca
Atlassian "5 Code Review Best Practices" – Praktische Tipps zu Stil und Teamarbeit. atlassian.com
Blockly PR Flow – Realer gestufter Review-Prozess. developers.google.com

Schlussgedanken

PR-Reviews, richtig gemacht, sind mehr als Quality Gates. Sie sind Motoren für Lernen, Zusammenarbeit und Engineering-Exzellenz. Wenn respektvolle Kultur, gutes Tooling, dateninformierte Prozesse und durchdachtes Feedback zusammenkommen, werden Code Reviews zu lohnenden Gesprächen - nicht zu lästigen Aufgaben.

Viel Freude beim Reviewen!

Schreib gern einen Kommentar oder melde dich, wenn du tiefer einsteigen oder deine eigenen Review-Tipps teilen möchtest!

Raucherkennung mit der Apple Watch: Still Mirror bauen (Swift, SWT)

Tue, 13 May 2025 00:00:00 GMT

Die Idee, unsere Gewohnheiten wirklich zu verstehen, besonders jene, die wir fast unbewusst ausführen, hat mich schon immer fasziniert. Was wäre, wenn unsere Wearables uns einen sanften, nicht wertenden Spiegel für diese Muster anbieten könnten? Aus dieser Frage entstand das Projekt "Still Mirror": ein Versuch, Rauch- oder Vaping-Ereignisse passiv anhand der reichhaltigen physiologischen Daten einer Apple Watch zu erkennen, ohne manuelle Eingaben durch den Nutzer zu verlangen. Es geht nicht darum, noch eine weitere Entwöhnungs-App zu bauen, sondern um ein Werkzeug für reine, unverfälschte Wahrnehmung.

Die Herausforderung: Ein Flüstern in einer Symphonie aus Rauschen

Die zentrale Herausforderung ist enorm: Wie unterscheidet man die subtile physiologische Signatur eines Rauch-/Vaping-Ereignisses von den unzähligen anderen Alltagsaktivitäten und körperlichen Reaktionen? Stress, ein zügiger Spaziergang, ein erschreckendes Geräusch oder sogar eine Tasse Kaffee können vorübergehende Veränderungen der Herzfrequenz (HR) und der Herzfrequenzvariabilität (HRV) auslösen. Das Signal, nach dem wir suchen, ist oft ein Flüstern in einer Symphonie physiologischen Rauschens.

Aber um diese flüchtigen Ereignisse wirklich zu isolieren, brauchte ich eine ausgefeiltere Technik zur Signalverarbeitung.

Abb. 1. – Das Apple-Entwicklungsökosystem: Xcode, Swift und HealthKit sind zentral, um 'Still Mirror' auf der Apple Watch zum Leben zu erwecken.

Wahl des Werkzeugkastens: Apple-Ökosystem & Swift

Für ein Projekt, das auf die Apple Watch zielt, ist die Ökosystemwahl klar:

Xcode und Swift: Die native Entwicklungsumgebung für Apple-Plattformen. Sich darauf einzulassen bedeutete, tiefer in Swift einzutauchen, eine Sprache, die ich elegant und mächtig finde, und sich durch die Feinheiten von Xcode zu bewegen.
HealthKit: Apples Framework ist das Tor zu den wesentlichen Datenströmen: Herzfrequenz, HRV (SDNN/RMSSD), SpO2 (besonders relevant für Verbrennung vs. Vaping) und Aktivitätsniveau. Das datenschutzorientierte Design von HealthKit ist entscheidend für eine App, die mit so sensiblen Daten umgeht.
watchOS-Einschränkungen: Für die Watch zu entwickeln bedeutet, Funktionalität ständig gegen Ressourcenbeschränkungen abzuwägen – Akkulaufzeit und Hintergrundverarbeitung sind immer präsent.

Das algorithmische Herz: Stationary Wavelet Transform (SWT)

Klassische Zeitreihenanalyse hat oft Schwierigkeiten mit nicht-stationären Signalen – Signalen, deren statistische Eigenschaften (wie Mittelwert und Varianz) sich über die Zeit verändern. Physiologische Daten sind notorisch nicht-stationär. Genau hier kommt die Stationary Wavelet Transform (SWT) ins Spiel.

Anders als die übliche Discrete Wavelet Transform (DWT), die verschiebungsvariant ist (das heißt, eine kleine Verschiebung im Eingangssignal kann die Wavelet-Koeffizienten dramatisch verändern), ist SWT verschiebungsinvariant. Das macht sie robuster für die Analyse von Signalen, bei denen der exakte Zeitpunkt von Ereignissen entscheidend ist, aber leicht variieren kann.

Warum SWT für dieses Problem?

Zeit-Frequenz-Lokalisierung: SWT kann ein Signal in verschiedene Frequenzbänder zerlegen und dabei zeitliche Information bewahren. Das heißt, wir können nach bestimmten Frequenzmerkmalen suchen (z. B. plötzliche Ausbrüche hochfrequenter Aktivität in der HR oder bestimmte Veränderungen in HRV-Frequenzbändern), die zu präzisen Momenten auftreten.
Entrauschen: Physiologische Signale sind verrauscht. SWT kann helfen, das zugrunde liegende "wahre" Signal vom Zufallsrauschen zu trennen, indem Wavelet-Koeffizienten auf verschiedenen Skalen analysiert werden.
Erkennung transienter Ereignisse: Sie ist besonders gut darin, abrupte Änderungen, Spitzen oder kurzlebige Ereignisse in einem Signal zu identifizieren, also genau das, was wir von der akuten physiologischen Reaktion auf Nikotinzufuhr erwarten könnten.

Abb. 2. – Visualisierung der Stationary Wavelet Transform, die ein Signal über die Zeit in seine Frequenzbestandteile zerlegt und so die Mustererkennung unterstützt.

Im Kern wirkt SWT wie ein ausgefeilter Satz von Filtern, der uns erlaubt, Muster in HR-, HRV- und potenziell SpO2-Daten zu "sehen", die durch Rauschen oder langfristige Trends verdeckt sein könnten. Wir können nach charakteristischen "Formen" oder Energieänderungen in bestimmten Wavelet-Unterbändern suchen, die dem physiologischen Ruck entsprechen.

Die Entwicklungsreise: Von Daten zur Erkennung

Datenerfassung (HealthKit): Zuverlässiges Abrufen von HealthKit-Daten im Hintergrund einrichten, Nutzerberechtigungen respektieren und Datenaktualisierungen effizient verarbeiten.
Signalvorverarbeitung: Die eingehenden HR-, HRV- und SpO2-Daten bereinigen. Dazu gehört der Umgang mit fehlenden Datenpunkten und vielleicht eine erste Filterung, bevor SWT angewendet wird.
SWT-Anwendung: Die Stationary Wavelet Transform auf Segmente der physiologischen Zeitreihen anwenden. Dazu gehört die Wahl eines geeigneten Mother Wavelets (z. B. Daubechies, Symlet) und einer Zerlegungsebene.
Feature-Extraktion aus Wavelet-Koeffizienten: Hier passiert die Magie (und eine Menge Experimentieren). Statt direkt auf rohe HR-/HRV-Werte zu schauen, analysieren wir die SWT-Koeffizienten. Relevante Features könnten sein:
- Energie in bestimmten Detailkoeffizienten-Bändern rund um den Zeitpunkt eines vermuteten Ereignisses.
- Statistische Eigenschaften (Varianz, Kurtosis) der Koeffizienten.
- Kreuzkorrelation zwischen Wavelet-Koeffizienten verschiedener physiologischer Signale (z. B. HR und HRV).
Erkennungslogik/-modell: Anfangs könnte das ein regelbasiertes System sein, das nach bestimmten Mustern in den extrahierten Wavelet-Features sucht (z. B. "ein signifikanter Energieanstieg in HR-Detailkoeffizienten auf Skala X, zeitgleich mit einem starken Energieabfall in HRV-Detailkoeffizienten auf Skala Y, während einer Phase geringer körperlicher Aktivität"). Später könnte sich daraus ein Machine-Learning-Modell entwickeln, das auf diesen Features trainiert wird.
Konfidenzbewertung: Wie in meinem MVPS-Algorithmus skizziert, ist es entscheidend, für jedes erkannte Ereignis einen Konfidenzwert zu erzeugen, der Stärke und Klarheit der Signatur widerspiegelt.
watchOS-App-Implementierung: Den Kernalgorithmus zur Erkennung auf der Apple Watch ausführen und dabei auf Akkulaufzeit optimieren (z. B. Daten in Batches verarbeiten, Analyse intelligent auslösen).
iOS-Companion-App: Zur Anzeige der Timeline erkannter Ereignisse, für Einblicke und zur Verwaltung von Einstellungen. Datensynchronisierung via WatchConnectivity ist hier zentral.

Gesundheit & Ethik: Die "Spiegel"-Philosophie

Es ist wichtig, noch einmal zu betonen, dass "Still Mirror" als Awareness-Werkzeug gedacht ist, nicht als Medizinprodukt oder Entwöhnungsprogramm.

Privacy First: Die gesamte Verarbeitung, besonders die sensible Algorithmusarbeit, sollte idealerweise auf dem Gerät stattfinden. Der Zugriff auf HealthKit-Daten ist strikt berechtigungsbasiert.
Kein Urteil: Die Oberfläche der App und alle Einsichten, die sie liefert, müssen neutral bleiben und Muster lediglich widerspiegeln, ohne vorschreibende Ratschläge oder Beschämung.
Genauigkeit & Transparenz: Nutzer müssen die Grenzen der App verstehen. Falsch positive und falsch negative Ergebnisse sind bei einer so komplexen, passiven Erkennung unvermeidlich. Transparenz über die Konfidenz von Erkennungen ist wichtig.
Selbstermächtigung des Nutzers: Ziel ist es, Nutzern Daten über ihren eigenen Körper und ihre Gewohnheiten zu geben, damit sie ihre eigenen informierten Entscheidungen treffen können.

Swift lernen und sich im Apple-Ökosystem zurechtfinden

Für Entwickler, die vor allem aus anderen Welten kommen (wie meinen PHP-/Laravel-Wurzeln), ist der Einstieg in Swift, SwiftUI, Xcode und die spezifischen Einschränkungen der watchOS-Entwicklung eine deutliche Lernkurve. Apples Frameworks haben eine eigene Philosophie. App-Lebenszyklen, Hintergrundaufgaben, HealthKit-Queries und Kommunikation zwischen Geräten (WatchConnectivity) haben jeweils ihre eigenen Muster und "Apple-Wege", Dinge zu tun. Trotzdem machen die reichhaltige Dokumentation, die starke Community und die Kraft von Swift diese Reise lohnend.

Fazit: Das Potenzial eines stillen Beobachters

"Still Mirror" ist weiterhin eine Erkundung, ein anspruchsvolles Unterfangen, um die Grenzen dessen zu verschieben, was passives Sensing auf einem Consumer-Wearable leisten kann. Die Stationary Wavelet Transform bietet einen vielversprechenden Weg, komplexe physiologische Signale zu zerlegen und die subtilen Signaturen freizulegen, nach denen wir suchen.

Die Reise besteht nicht nur daraus, Swift-Code zu schreiben und mit Xcode zu ringen, sondern auch daraus, in Signalverarbeitungstheorie einzutauchen, menschliche Physiologie zu verstehen und die ethischen Folgen einer solchen Technologie sorgfältig abzuwägen. Ob "Still Mirror" einmal eine breit genutzte App wird oder eine filigrane technische Erkundung bleibt: Der Prozess selbst zeigt diese faszinierende Schnittstelle von KI, Gesundheit und persönlicher Technologie. Es geht darum, diese ruhige, reflektierende Oberfläche zu bauen – einen stillen Spiegel – für mehr Selbstwahrnehmung.

Was denkst du über den Einsatz fortgeschrittener Signalverarbeitung wie SWT zur passiven Erkennung von Gewohnheiten? Ich würde deine Gedanken dazu gern unten in den Kommentaren lesen!

Android-Emulator-Bluetooth auf dem M1-Mac mit Bumble und API 32 reparieren

Mon, 14 Apr 2025 00:00:00 GMT

Wenn du als Entwickler auf einem M1/M2/M3-Mac mit Bluetooth arbeitest und versuchst, die Bluetooth-Funkeinheit deines Host-Rechners im Android Emulator nutzbar zu machen, hast du vermutlich schon etwas gelitten. Was eigentlich unkompliziert wirken sollte, wird oft zu einem frustrierenden Kaninchenbau aus fehlgeschlagenen Verbindungen, kryptischen Fehlern und Dokumentations-Sackgassen. Ich bin genau durch diesen Kampf gegangen, und nach mehreren Mauern habe ich endlich eine Kombination mit dem Python-Bluetooth-Stack Bumble gefunden, die tatsächlich funktioniert.

Das ist nicht noch eine theoretische Anleitung; es ist der Schritt-für-Schritt-Bericht darüber, was gescheitert ist und, wichtiger, was funktioniert hat, um das Bluetooth meines M1 Mac Pro (in meinem Fall über einen externen USB-Dongle, auch wenn das Prinzip vielleicht auch für interne Funkmodule gilt) mit einem Android-12L-Emulator (API 32) zu verbinden.

Das Ziel: Echtes Bluetooth im Emulator

Das Ziel war simpel: Der Android Emulator sollte den physischen Bluetooth-Controller meines Macs verwenden, statt seines eigenen eingeschränkten virtuellen Controllers. Das ist entscheidend, wenn man Apps testet, die mit echten Bluetooth-Geräten interagieren.

Das Werkzeug: Bumble betritt die Bühne

Bumble ist ein mächtiger Python-Bluetooth-Stack. Das zentrale Werkzeug für diese Aufgabe ist bumble-hci-bridge, das sich auf der einen Seite mit einem physischen HCI (Host Controller Interface) verbinden und es auf der anderen Seite über verschiedene Transportschichten (wie TCP oder gRPC) bereitstellen kann.

Versuch #1: Die QEMU-Socket-Methode (der logische erste Versuch)

Ausgehend von allgemeinem QEMU-Wissen und ein paar älteren Anleitungen bestand der erste Ansatz darin, Emulator-Flags zu verwenden, um einen virtuellen seriellen Port (hinterlegt durch einen TCP-Socket) direkt mit der HCI-Bridge zu verbinden.

Bridge starten (TCP-Server-Modus): Wir verbanden Bumble mit dem physischen Dongle (der auf meiner Maschine überraschenderweise mit usb:0 besser funktionierte als mit seiner konkreten VID:PID usb:0b05:17cb - M1-Eigenheiten!) und ließen es auf einem TCP-Port lauschen.
```
# In Terminal 1:
sudo python3 -m bumble.apps.hci_bridge usb:0 tcp-server:0.0.0.0:6789
# Output showed '>>> connected' twice - success connecting to USB and starting TCP server.
```
Emulator mit QEMU-Flags starten: Wir passten das Emulator-Startskript an (anfangs mit Ziel API 34), um -qemu-Flags hinzuzufügen, die einen virtuellen seriellen Port (virtserialport) auf ein Zeichengerät (chardev) leiteten, das von einem TCP-Socket zur Bridge hinterlegt war.
```
# Snippet from launch script:
emulator -avd <avd_name> ... \
    -qemu \
    -device virtio-serial-device \
    -device virtserialport,chardev=bt,name=bt \
    -chardev socket,id=bt,host=localhost,port=6789 \
    ...
```
Das Ergebnis? Teilerfolg, am Ende Fehlschlag: Mit lsof konnten wir sehen, dass der QEMU-Prozess des Emulators tatsächlich eine TCP-Verbindung zur Bumble-Bridge aufbaute. Allerdings schickte der Android-Bluetooth-Stack im Inneren des Emulators nie echte HCI-Kommandos darüber. Bluetooth in den Android-Einstellungen umzuschalten bewirkte nichts. Die Bridge-Logs blieben nach der initialen Verbindung stumm. Sackgasse.

Versuch #2: Die Standard-Netsim-Bridge (nach Bumble-Dokumentation)

Die Bumble-Dokumentation erwähnt eine Bridge zur "Netsim"-gRPC-Schnittstelle des Emulators. Netsim (und sein Kern, Root Canal) ist das neuere virtuelle Bluetooth-Controller-System des Emulators.

Bridge starten (Netsim-Controller-Modus): Wir konfigurierten die Bridge so, dass sie als Netsim-Controller arbeitet, auf dem standardmäßigen gRPC-Port (8554) lauscht und sich mit dem physischen Dongle verbindet.
```
# In Terminal 1:
sudo python3 -m bumble.apps.hci_bridge android-netsim:_:8554,mode=controller usb:0
# Output showed '>>> connected' twice - success connecting to USB and starting Netsim gRPC server.
```
Emulator starten (Standard-Backend): Wir setzten das Startskript zurück (immer noch mit API 34), entfernten die -qemu-Flags und fügten -packet-streamer-endpoint default hinzu, damit er sicher das Netsim-Backend zu verwenden versucht.
```
# Snippet from launch script:
emulator -avd <avd_name> ... \
    -packet-streamer-endpoint default \
    ...
```
Das Ergebnis? Keine Verbindung: Diesmal startete der Emulator, aber die Bumble-Bridge zeigte keinerlei Anzeichen einer eingehenden gRPC-Verbindung vom Emulator. Die Emulator-Logs zeigten keine offensichtlichen Verbindungsfehler, aber Bluetooth blieb unbrauchbar. Noch eine Sackgasse.

Versuch #3: API-Downgrade + expliziter Netsim-Endpunkt (der Gewinner!)

Fig1. - Eine surreale Landschaft, in der gescheiterte Netzwerkkabel zwischen Apple- und Android-Felsformationen hängen, während eine einzelne Bumble-markierte Seilbrücke die beiden erfolgreich verbindet und leuchtende Datenpakete hinüberlaufen lässt.

Websuchen zeigten allgemeine Berichte über Instabilität bei Bluetooth auf API-33/34-Emulatoren und mögliche Probleme damit, wie der Emulator das Netsim-Backend entdeckt oder sich damit verbindet, besonders wenn ein externes Werkzeug versucht, es abzufangen. Der Schlüssel schien zu sein, dem Emulator explizit zu sagen, wo der Netsim-gRPC-Server liegt, und eine ältere API-Version zu versuchen.

Bridge starten (Netsim-Controller-Modus, expliziter Port, usb:0): Wie in Versuch #2, mit der Sicherstellung, dass sie auf einem bekannten Port (8554) lauscht und sich über den Index (usb:0), der zuverlässig funktionierte, mit dem physischen Dongle verbindet.
```
# In Terminal 1: (Keep this running!)
sudo python3 -m bumble.apps.hci_bridge android-netsim:_:8554,mode=controller usb:0
```

Emulator anpassen und starten (API 32, expliziter Endpunkt): Wir erstellten ein API-32-AVD (Android 12L) mit Google Play Services (gplay_32_arm). Wir passten das Startskript an, damit es dieses AVD verwendet, und, entscheidend, änderten das Flag -packet-streamer-endpoint von default zur exakten Adresse unserer Bridge.

# Snippet from the *successful* launch script (see full script below):
API_LEVEL="32"
AVD_NAME="gplay_${API_LEVEL}_arm"
SYSTEM_IMAGE_PKG="system-images;android-${API_LEVEL};${IMAGE_TAG};${ARCH}"
BUMBLE_NETSIM_GRPC_PORT="8554"
...
emulator -avd "$AVD_NAME" ... \
    -packet-streamer-endpoint "localhost:$BUMBLE_NETSIM_GRPC_PORT" \
    ...

Das Ergebnis? Erfolg! Diesmal funktionierte es!
- Das bumble-hci-bridge-Terminal begann kurz nach dem Start, gRPC-Verbindungslogs vom Emulator anzuzeigen.
- Sobald der Emulator gebootet war, führte das Einschalten von Bluetooth in den Android-Einstellungen zu einer Flut von HCI-Kommandos (Reset, Read Version, Set Event Mask usw.) im Bridge-Terminal.
- Die Suche nach Geräten innerhalb des Emulators nutzte erfolgreich die physische Bluetooth-Funkeinheit des Macs über den ASUS-Dongle!

Das funktionierende Rezept: Schritt für Schritt

Hier ist das genaue Vorgehen, das auf meinem M1 Mac Pro mit einem externen ASUS-USB-BT500-Dongle funktioniert hat:

Bumble installieren:

python3 -m pip install bumble
# Potentially install libusb if needed: brew install libusb

(Optional, aber empfohlen) Natives macOS-USB-Bluetooth-Handling deaktivieren: Einmal ausführen und neu starten.
```
sudo nvram bluetoothHostControllerSwitchBehavior="never"
```
Bumble-Netsim-Bridge starten: Öffne ein Terminal und führe aus (laufen lassen):
```
sudo python3 -m bumble.apps.hci_bridge android-netsim:_:8554,mode=controller usb:0
```
(Prüfen, dass zweimal >>> connected angezeigt wird.)
Emulator-Startskript vorbereiten: Speichere das unten angegebene vollständige Skript als launch_gapps_avd_api32.sh (oder ähnlich). Achte darauf, dass es ein API-32-AVD verwendet (es erstellt eines namens gplay_32_arm, falls es nicht existiert) und explizit -packet-streamer-endpoint localhost:8554 nutzt. Mach es ausführbar (chmod +x launch_gapps_avd_api32.sh).
Startskript ausführen: Öffne ein neues Terminal und führe das Skript aus:
```
./launch_gapps_avd_api32.sh
```
Verifizieren: Sobald der Emulator gebootet ist:
- Prüfe das bumble-hci-bridge-Terminal auf gRPC- und HCI-Traffic.
- Gehe zu Android Settings -> Bluetooth und schalte es ein.
- Versuche zu scannen oder zu koppeln.

Das erfolgreiche Startskript (API 32, expliziter Netsim-Endpunkt)

#!/bin/bash

# Script to setup and launch a Google Play Android emulator (API 32) on macOS M1/ARM64
# Uses explicit Netsim endpoint for Bumble bridge compatibility.

set -e # Exit immediately if a command exits with a non-zero status.

# --- Configuration ---
API_LEVEL="32" # Target Android API Level (Android 12L)
AVD_NAME="gplay_${API_LEVEL}_arm" # Name for the Android Virtual Device
IMAGE_TAG="google_apis_playstore" # Image type with Google Play Store
ARCH="arm64-v8a" # Architecture for Apple Silicon
SYSTEM_IMAGE_PKG="system-images;android-${API_LEVEL};${IMAGE_TAG};${ARCH}"
DEVICE_DEF="pixel_6a" # A common modern Pixel device definition
BUMBLE_NETSIM_GRPC_PORT="8554" # Port where bumble-hci-bridge Netsim controller is listening

# --- Find Android SDK ---
ANDROID_SDK_ROOT="${ANDROID_HOME:-${ANDROID_SDK_ROOT:-$HOME/Library/Android/sdk}}"

if [ ! -d "$ANDROID_SDK_ROOT" ]; then
    echo "❌ Error: Android SDK not found at '$ANDROID_SDK_ROOT'" >&2
    echo "   Please install Android Studio or set ANDROID_HOME/ANDROID_SDK_ROOT." >&2
    exit 1
fi
echo "▶️ Using Android SDK at: $ANDROID_SDK_ROOT"

# --- Define Tool Paths ---
CMDLINE_TOOLS_BIN="$ANDROID_SDK_ROOT/cmdline-tools/latest/bin"
PLATFORM_TOOLS_DIR="$ANDROID_SDK_ROOT/platform-tools"
EMULATOR_DIR="$ANDROID_SDK_ROOT/emulator"

SDKMANAGER="$CMDLINE_TOOLS_BIN/sdkmanager"
AVDMANAGER="$CMDLINE_TOOLS_BIN/avdmanager"
EMULATOR="$EMULATOR_DIR/emulator"
ADB="$PLATFORM_TOOLS_DIR/adb"

# --- Check Essential Tools ---
if ! command -v sdkmanager &> /dev/null; then echo "❌ Error: sdkmanager not found. Check SDK Command-line Tools installation and PATH." >&2; exit 1; fi
if ! command -v avdmanager &> /dev/null; then echo "❌ Error: avdmanager not found. Check SDK Command-line Tools installation and PATH." >&2; exit 1; fi
if ! command -v emulator &> /dev/null; then echo "❌ Error: emulator not found. Check Android Emulator installation and PATH." >&2; exit 1; fi
if ! command -v adb &> /dev/null; then echo "❌ Error: adb not found. Check SDK Platform-Tools installation and PATH." >&2; exit 1; fi
echo "✅ Basic SDK tools found in PATH."

# --- Stop Currently Running Emulators ---
echo "▶️ Stopping any currently running emulators..."
RUNNING_EMULATORS=$(adb devices | grep 'emulator-' | cut -f1)
if [ -n "$RUNNING_EMULATORS" ]; then
    for emu_id in $RUNNING_EMULATORS; do
        echo "   Stopping $emu_id..."
        adb -s "$emu_id" emu kill || echo "   (Failed to kill $emu_id, may already be stopped)"
        sleep 1 # Small delay
    done
    # Give ADB server time to recognize disconnection
    sleep 3
    echo "   Emulators stopped."
else
    echo "   No emulators appear to be running according to 'adb devices'."
fi
echo "✅ Emulator check/stop finished."


# --- Install/Update Required SDK Packages ---
echo "▶️ Ensuring required SDK packages are installed..."
# Accept licenses non-interactively
yes | sdkmanager --licenses > /dev/null || echo "   (Ignoring potential license script errors)"

# Install platform-tools, emulator
sdkmanager "platform-tools" "emulator"

# Install the Google Play system image for API 32
echo "▶️ Attempting to install/update Google Play system image: $SYSTEM_IMAGE_PKG"
if ! sdkmanager "$SYSTEM_IMAGE_PKG"; then
    echo "❌ Error: Failed to install required system image '$SYSTEM_IMAGE_PKG'." >&2
    echo "   Please check available images using: sdkmanager --list | grep 'system-images;android-${API_LEVEL};.*${ARCH}'" >&2
    exit 1
fi
echo "✅ System image package '$SYSTEM_IMAGE_PKG' present."

# --- Check if AVD Exists, Create ONLY if Missing ---
echo "▶️ Ensuring AVD '$AVD_NAME' exists..."
if ! avdmanager list avd --compact | grep -q "^${AVD_NAME}$"; then
    echo "   AVD '$AVD_NAME' not found. Creating..."
    # Using 'echo no' usually prevents hardware profile creation prompts. Pipe empty string for potential licenses.
    echo "" | avdmanager create avd --force --name "$AVD_NAME" --package "$SYSTEM_IMAGE_PKG" --device "$DEVICE_DEF" --sdcard 512M || {
         echo "❌ Error: Failed to create AVD '$AVD_NAME'." >&2
         echo "   Maybe the device definition '$DEVICE_DEF' is invalid for this image?" >&2
         echo "   Check available devices: avdmanager list device" >&2
         exit 1
    }
    echo "✅ AVD '$AVD_NAME' created."
else
    echo "✅ AVD '$AVD_NAME' already exists. Will reuse."
fi


# --- Launch Emulator ---
echo "▶️ Launching existing/new emulator: '$AVD_NAME' (pointing to Bumble Netsim bridge on localhost:$BUMBLE_NETSIM_GRPC_PORT)..."
EMULATOR_LOG="emulator-$AVD_NAME.log" # Log file name updated for API 32 AVD
# Google Play images often need a writable system partition
# Explicitly point packet streamer to localhost:8554 where bridge is listening
nohup emulator -avd "$AVD_NAME" -no-snapshot-load -gpu auto -show-kernel -writable-system \
    -packet-streamer-endpoint "localhost:$BUMBLE_NETSIM_GRPC_PORT" \
    > "$EMULATOR_LOG" 2>&1 &
EMULATOR_PID=$!
echo "   Emulator starting in background (PID: $EMULATOR_PID). Log: $EMULATOR_LOG"
echo -n "   Waiting for emulator to appear in ADB..."

# Wait for the emulator device to show up in adb
WAIT_ADB_TIMEOUT=90 # Increase timeout slightly for GPlay images
SECONDS=0
EMULATOR_ID="" # Reset variable
while [ $SECONDS -lt $WAIT_ADB_TIMEOUT ]; do
    # Find the *new* emulator ID
    CURRENT_EMU_ID=$(adb devices | grep 'emulator-' | head -n 1 | cut -f1)
    if [ -n "$CURRENT_EMU_ID" ]; then
        EMULATOR_ID="$CURRENT_EMU_ID"
        echo " Found ($EMULATOR_ID)!"
        break
    fi
    sleep 2
    SECONDS=$((SECONDS + 2))
    echo -n "."
done

if [ -z "$EMULATOR_ID" ]; then
    echo ""
    echo "❌ Error: Emulator did not appear in ADB within $WAIT_ADB_TIMEOUT seconds." >&2
    echo "   Check logs: $EMULATOR_LOG" >&2
    # Try to kill the process if it's still lingering
    kill $EMULATOR_PID 2>/dev/null || echo "   (Emulator process $EMULATOR_PID may have already exited)"
    exit 1
fi


# --- Wait for Boot Completion ---
echo -n "▶️ Waiting for Android system to fully boot (Google Play images can take longer)..."
BOOT_TIMEOUT=240 # Increase timeout significantly for GPlay images
SECONDS=0
while [ $SECONDS -lt $BOOT_TIMEOUT ]; do
    # Check if device is online first
    DEVICE_STATE=$(adb -s "$EMULATOR_ID" get-state 2>/dev/null)
    if [ "$DEVICE_STATE" != "device" ]; then
       echo -n "s($DEVICE_STATE)" # State not ready
       sleep 5
       SECONDS=$((SECONDS + 5))
       continue
    fi

    # Check boot completed property
    BOOT_COMPLETED=$(adb -s "$EMULATOR_ID" shell getprop sys.boot_completed 2>/dev/null | tr -d '
')
    if [ "$BOOT_COMPLETED" = "1" ]; then
        # Double check package manager is ready too for GPlay images
        PM_READY=$(adb -s "$EMULATOR_ID" shell pm get-install-location 2>/dev/null)
        if [[ "$PM_READY" == *"0"* || "$PM_READY" == *"1"* || "$PM_READY" == *"2"* ]]; then # Check if pm command gives valid output
            echo " Booted!"
            break
        else
            echo -n "p(pm not ready)" # Package Manager not ready
        fi
    else
         echo -n "b(booting)" # Boot not completed
    fi
    sleep 5
    SECONDS=$((SECONDS + 5))
done

if [ $SECONDS -ge $BOOT_TIMEOUT ]; then
    echo ""
    echo "❌ Error: Android system did not fully boot within $BOOT_TIMEOUT seconds." >&2
    echo "   Emulator might be stuck. Check logs ($EMULATOR_LOG) or try launching manually." >&2
    # Don't exit here, user might want to interact with stuck emulator
fi


# --- Final Instructions ---
echo "---"
echo "✅ Google Play Emulator '$AVD_NAME' (API $API_LEVEL) ($EMULATOR_ID) should be running."
echo "   Bluetooth should be using the Netsim backend at localhost:$BUMBLE_NETSIM_GRPC_PORT (intercepted by Bumble)."
echo "   Connect shell:   adb -s $EMULATOR_ID shell"
echo "   Install APK:     adb -s $EMULATOR_ID install /path/to/your.apk"
echo "   Stop emulator:   adb -s $EMULATOR_ID emu kill"
if [ -n "$EMULATOR_PID" ]; then # Only show PID if we launched it
    echo "   Kill Process:    kill $EMULATOR_PID"
fi
echo "   NOTE: Google Play Services may need updates inside the emulator."
echo "---"

exit 0

Zentrale Erkenntnisse für M1-Mac + Emulator + Bumble

API-Level zählt: Neuer ist für Emulator-Kompatibilität nicht immer besser, besonders bei komplexen Funktionen wie Bluetooth-Bridging. API 32 wirkte in meinen Tests dafür stabiler als API 34.
Explizite Endpunkte: Verlass dich nicht auf -packet-streamer-endpoint default, wenn du eine externe Bridge wie Bumbles Netsim-Controller-Modus verwendest. Zeige dem Emulator explizit auf localhost:<port>, wo deine Bridge lauscht.
Netsim-Bridge > QEMU-Socket: Der android-netsim-Bridge-Modus scheint mit modernen Emulatoren eher zu funktionieren als die niedrigere -qemu -chardev socket-Methode, auch wenn die Socket-Methode eine TCP-Verbindung herstellen kann.
usb:0 vs. VID:PID: Auf macOS/M1 kann die Identifikation von USB-Geräten eigenwillig sein. Wenn die exakte VID:PID unerwartet scheitert, versuche den Index usb:0 (vorausgesetzt, es ist das primäre/beabsichtigte Gerät).
Hartnäckigkeit zahlt sich aus: Das brauchte mehrere Versuche und die Kombination aus Dokumentation, Websuchen und iterativem Testen. Gib nicht zu schnell auf!

Ich hoffe, dass diese konkrete, funktionierende Konfiguration anderen Entwicklern Stunden an Frust erspart. Viel Spaß beim Coden (und Bridgen)!

KI-Blog-Redesign: Wie Claude Code meine Gatsby-Seite verwandelte

Sat, 12 Apr 2025 00:00:00 GMT

Als Entwickler, der die meiste Zeit im Backend verbringt, habe ich mit Design schon immer gerungen. Mein persoenliches Blog war funktional, sah aber aus, als sei es 2010 steckengeblieben: einfaches Styling, inkonsistente Abstaende und ein Farbschema, das man grosszuegig als "minimal" haette beschreiben koennen. Ich wollte es seit Monaten ueberarbeiten, aber der Gedanke, in CSS und Designsysteme einzutauchen, machte mir Albtraeume.

Dann probierte ich Claude Code aus, den KI-Coding-Assistenten von Anthropic, und meine Perspektive veraenderte sich komplett.

Die Herausforderung: Mein trauriges, veraltetes Blog

Mein Blog ist mit Gatsby.js gebaut, und obwohl der Inhalt solide war, liess die Praesentation ihn im Stich:

Inkonsistente Abstaende auf der gesamten Website
Schlechtes responsives Verhalten auf Mobilgeraeten
Eine Dark-Mode-Implementierung, die kaum funktionierte
Typografie, die bestenfalls amateurhaft aussah
Kein zusammenhaengendes Farbsystem oder eine erkennbare Designsprache

Ich hatte eine vage Vorstellung davon, was ich wollte: etwas Modernes, Sauberes und Professionelles, das meine Inhalte zum Leuchten bringen wuerde. Aber diese Vorstellung in tatsaechliches CSS zu uebersetzen? Genau dort renne ich normalerweise gegen eine Wand.

Claude Code betritt die Buehne: Mein virtueller Designpartner

Ich hatte schon eine Weile von Claude Code gehoert, war aber skeptisch, wie sehr eine KI bei Designarbeit wirklich helfen kann. Schliesslich braucht Design Geschmack und ein Auge fuer Aesthetik, nicht nur technisches Wissen.

Ich beschloss trotzdem, es zu versuchen, mit einem einfachen Prompt: "Please improve my styling by a ton." Ich war bereit, eine Stunde meiner Zeit und die ungefaehr $15 API-Kosten zu investieren, um zu sehen, was moeglich war.

Was danach passierte, ueberraschte mich wirklich.

Der Transformationsprozess

Statt nur ein paar CSS-Anpassungen vorzuschlagen, ging Claude Code das Redesign mit der Gruendlichkeit eines professionellen Entwicklers an:

Analysephase: Zuerst untersuchte es meine bestehenden Styles, die Komponentenarchitektur und das Farbschema, um zu verstehen, womit es arbeitete.
Erstellung eines Designsystems: Statt oberflaechliche Aenderungen zu machen, baute es ein umfassendes Designsystem, darunter:
- Eine professionelle Farbpalette mit semantischen Variablen fuer Light und Dark Mode
- Eine modernisierte Typografieskala mit sauberen responsiven Anpassungen
- Ein konsistentes Abstandssystem auf Basis eines 4px-Rasters
- Standardisierte Schatten, Border Radii und Transitionen
Komponenten-Ueberarbeitung: Es schrieb meine Komponenten nach modernen Best Practices um:
- Erstellte ein responsives, kartenbasiertes Layout fuer Blogposts
- Implementierte einen Sticky Header mit Backdrop-Blur-Effekten
- Entwarf einen eleganten Theme-Umschalter
- Fuegte eine saubere Navigation mit aktiven Zustaenden hinzu
Verbesserungen der Barrierefreiheit: Claude Code machte die Dinge nicht nur schoener, sondern auch zugaenglicher:
- Fuegte ordentliche Unterstuetzung fuer Tastaturnavigation hinzu
- Implementierte einen Skip-to-content-Link
- Stellte ausreichenden Farbkontrast sicher
- Fuegte passende ARIA-Labels hinzu
Performance-Optimierung: Der Code wurde auf Performance optimiert:
- Importierte selektiv nur die notwendigen Bootstrap-Komponenten
- Optimierte die CSS-Organisation
- Fuegte hardwarebeschleunigte Animationen hinzu

Die umwerfenden Ergebnisse

Die Transformation war atemberaubend. In ungefaehr einer Stunde Hin und Her und fuer gerade einmal $15 an Claude-API-Kosten entwickelte sich mein Blog von etwas, das wie das Nebenprojekt eines Entwicklers aussah, zu einer professionell gestalteten Publikation. Das Redesign enthielt:

Ein ausgefeiltes Farbsystem mit sauberer Dark-Mode-Unterstuetzung
Schoene Typografie, die sich perfekt ueber Geraete hinweg skaliert
Professionelle Kartenlayouts fuer Blogposts
Sanfte Animationen und Transitionen
Einen Sticky Header mit glasartigen Effekten
Konsistente Abstaende auf der gesamten Website

Um das einzuordnen: Einen professionellen Webdesigner fuer Arbeit auf diesem Niveau zu beauftragen, wuerde wahrscheinlich $1,000-2,000 kosten und Tage oder Wochen an Hin und Her benoetigen. Stattdessen investierte ich eine Stunde meiner Zeit und $15 an API-Kosten.

Aber was mich am meisten beeindruckte, war nicht nur die visuelle Verbesserung oder die Kostenersparnis. Es war die Qualitaet des Codes. Claude Code warf nicht einfach ein paar CSS-Hacks zusammen; es erstellte ein umfassendes, wartbares Designsystem, auf dem ich leicht weiter aufbauen kann.

Was ich ueber KI-unterstuetztes Design gelernt habe

Diese Erfahrung veraenderte meine Sicht darauf, was KI fuer Entwickler tun kann:

KI ist stark im systematischen Denken: Claude Code machte die Dinge nicht nur "huebscher", sondern schuf ein zusammenhaengendes System mit Variablen, konsistenten Mustern und sauberer Organisation.
Sie ueberbrueckt Wissensluecken: Als jemand ohne tiefes CSS-Fachwissen fuellte Claude Code meine Wissensluecken mit modernen Best Practices, von denen ich nicht gewusst haette, dass ich sie implementieren sollte.
Der Code ist produktionsreif: Das Styling-Framework, das es erstellte, ist nicht nur Show. Es ist wartbarer, erweiterbarer Code, der modernen Standards folgt.
Es bewahrte meine Inhalte und Struktur: Claude Code verbesserte das Design, waehrend es die Kernstruktur und die Inhalte meines Blogs beibehielt.

Die Zukunft der Zusammenarbeit zwischen Entwicklern und KI

Meine Erfahrung zeigte mir etwas Wichtiges: Claude Code ersetzt Entwickler nicht, sondern erweitert unsere Faehigkeiten. Es half mir, meine persoenlichen Grenzen im Frontend-Design zu ueberwinden, waehrend ich weiterhin die Kontrolle ueber die Gesamtrichtung behielt.

Fuer Entwickler, die in manchen Bereichen staerker sind als in anderen (und sind wir das nicht alle?), koennen KI-Assistenten wie Claude Code helfen, die Luecken in unseren Faehigkeiten zu schliessen.

Probier es selbst aus

Wenn du mit Design oder irgendeinem anderen Aspekt der Entwicklung kaempfst, empfehle ich dir sehr, Claude Code auszuprobieren. Die Erfahrung veraenderte nicht nur mein Blog, sondern auch meine Vorstellung davon, was mit KI-unterstuetzter Entwicklung moeglich ist.

Hast du Claude Code oder aehnliche KI-Coding-Assistenten ausprobiert? Ich wuerde unten in den Kommentaren gern von deinen Erfahrungen hoeren.

Hinweis: Dieses Blog selbst wurde mit Claude Code neu gestaltet, also ist das, was du gerade siehst, das Ergebnis des Prozesses, den ich beschrieben habe. Die Transformation von meinem frueheren Design zu diesem aktuellen dauerte ungefaehr eine Stunde Prompting und Iteration und kostete etwa $15 an Claude-API-Nutzung. Wenn man traditionelle Designkosten betrachtet, ist das ein unglaubliches Wertversprechen.

Huawei Watch D2 BLE-Pairing: Protokoll- und Vendor-Lock-in-Fall

Fri, 11 Apr 2025 00:00:00 GMT

TL;DR: Die Huawei Watch D2 nutzt kein Standard-BLE-Pairing. Stattdessen verlangt sie einen proprietären 11-Schritte-Handshake mit eigenen GATT-Characteristics, HMAC-SHA256-Schlüsselableitung aus einem QR-Code und Verschlüsselung auf Anwendungsebene. Das ist Vendor Lock-in per Design - es zwingt dich in Huaweis Health-App. Die gute Nachricht: Die Community hat es reverse-engineered. Gadgetbridge unterstützt die Watch D2 inzwischen, und Open-Source-Implementierungen wie huawei-lpv2 existieren. Auch der EU DMA beginnt, dagegenzuhalten.

Ich hatte Standard-Bluetooth-Pairing erwartet. Verbinden, bonden, Daten austauschen - das Übliche. Was ich stattdessen bekam, war ein proprietärer kryptografischer Handshake, dessen Reverse Engineering Wochen dauerte.

Das passierte beim Bau von D2Explorer - meinem Projekt, um die Huawei Watch D2 ohne Huaweis Health-App mit Linux und macOS zu verbinden. Nachdem ich BlueZs Pairing-Agent-Probleme gelöst und auf die plattformübergreifende SimpleBLE-Bibliothek migriert hatte, dachte ich, der schwierige Teil sei vorbei. Der schwierige Teil hatte noch nicht angefangen.

Was man erwarten würde: Standard-BLE-Pairing

So soll Bluetooth-LE-Pairing eigentlich funktionieren:

Nach dem Gerät über seinen beworbenen Namen scannen (z. B. "HUAWEI WATCH D2-CA0").
Mit peripheral.connect() verbinden.
Das Betriebssystem erledigt Pairing/Bonding - PIN-Abfrage, Just Works, was auch immer die Sicherheitsstufe verlangt.
Sobald das Gerät gebondet ist, mit Standard- oder eigenen GATT-Services interagieren.

Das Betriebssystem verwaltet die Sicherheit. Deine Anwendung konzentriert sich auf Daten. Einfach.

Was tatsächlich passiert: Ein proprietärer 11-Schritte-Handshake

Was die Watch D2 tatsächlich verlangt, ist etwas völlig anderes. Die grundlegende BLE-Verbindung ist nur die Tür. Dahinter liegt ein eigenes Authentifizierungsprotokoll auf Anwendungsebene, das Huawei auf Standard-BLE gebaut hat - was die Community Huawei Link Protocol v2 nennt [1].

Standard-BLE-Pairing-Mechanismen werden vollständig umgangen. Um dich zu authentifizieren und auf irgendeine sinnvolle Art Daten zu bekommen, musst du diese Sequenz über eigene GATT-Characteristics abarbeiten:

Connect - die grundlegende BLE-Verbindung herstellen.
Enable Notifications - sofort Notifications auf Characteristic 0000fe02-... abonnieren. Das ist timingkritisch - verpasst du das Fenster, trennt die Uhr die Verbindung.
GetLinkParams - sofort einen eigenen Command (Service ID 0x0001, Command ID 0x0001) an die Write-Characteristic 0000fe01-... senden.
Receive Server Nonce - auf eine Notification mit der zufälligen Challenge der Uhr warten.
Derive Secret Key - eine Client-Nonce erzeugen. Server-Nonce, Client-Nonce und den numerischen Wert aus dem QR-Code der Uhr kombinieren. HMAC-SHA256 ausführen (mit den Bytes des QR-Code-Werts als Schlüssel), um einen gemeinsamen secretKey_ abzuleiten.
AuthRequest - Client-Nonce und HMAC-Digest (mit dem abgeleiteten secretKey_) zurück an die Uhr senden (Service 0x0001, Command 0x0002).
Verify Server Token - den Authentifizierungstoken der Uhr empfangen. Ihn mit dem secretKey_ und den ausgetauschten Nonces verifizieren.
SetTime - aktuelle Zeit und Zeitzonen-Offset senden, mit dem secretKey_ verschlüsselt (Service 0x0002, Command 0x0003).
QrToken - den QR-Code-Wert zurücksenden, mit dem secretKey_ verschlüsselt (Service 0x0001, Command 0x0004).
AuthResult - eine finale Bestätigung senden, mit dem secretKey_ verschlüsselt (Service 0x0001, Command 0x0005).
Done - erst jetzt ist die Verbindung authentifiziert.

Eigene TLV-Nachrichtenformate. CRC-Prüfungen. Service- und Command-IDs. Verschlüsselung auf Anwendungsebene. Millisekundengenaues Timing. All das passiert oberhalb des BLE-Stacks, unsichtbar für normale Bluetooth-Tools.

Der QR-Code auf dem Bildschirm der Uhr ist das gemeinsame Geheimnis. Ohne ihn kannst du den Schlüssel nicht ableiten. Ohne den Schlüssel kannst du dich nicht authentifizieren. Ohne Authentifizierung gibt dir die Uhr nichts.

Warum Huawei das tut

Huawei könnte das als erhöhte Sicherheit darstellen. Der praktische Effekt ist Vendor Lock-in.

Hohe Einstiegshürde - das Protokoll ist undokumentiert. Eine Neuimplementierung verlangt Reverse Engineering der Huawei-Health-App (13.000+ Klassen, 64.000+ Methoden [2]) oder die Analyse von BLE-Traffic. Das schreckt Drittanbieter-Apps aktiv ab.
Keine Interoperabilität - normale Fitness-Apps können sich nicht verbinden. Die Uhr schließt ihren Handshake nur mit Software ab, die die proprietären Schritte kennt - primär Huaweis eigene Health-App.
Kontrolle über das Ökosystem - Nutzer werden in Huawei Health und seine Cloud-Dienste gezwungen. Später das Gerät oder die Plattform zu wechseln bedeutet, die eigene Gesundheitsdatenhistorie zu verlieren.
Weniger Nutzerwahl - du willst eine Open-Source-App nutzen? Mehr Kontrolle über die Privatsphäre deiner Gesundheitsdaten? Pech gehabt - es sei denn, jemand reverse-engineered zuerst das Protokoll.

Und genau das ist der Punkt: Das ist nicht einzigartig für Huawei. Das Forschungsprojekt WatchWitch [3] dokumentiert, wie alle großen Anbieter - Apple, Samsung, Xiaomi - proprietäre BLE-Protokolle nutzen, um Ökosystem-Lock-in durchzusetzen. Die Apple Watch ist "incredibly tightly coupled with Apple's iPhone and iCloud ecosystem, using proprietary protocols that are unavailable to third parties." Es ist ein systemisches Branchenproblem.

Aber Huaweis Implementierung ist besonders aggressiv. BLE erlaubt eigene Services, klar. Aber den grundlegenden Authentifizierungsmechanismus durch einen proprietären Gatekeeper zu ersetzen, ist ein ganz anderes Spiel.

Die Sicherheitsironie

Die naheliegende Verteidigung lautet: "Wir tun das aus Sicherheitsgründen." Schauen wir uns das an.

Die BlueDoor-Schwachstellenforschung der Tsinghua University [4] testete 16 BLE-Geräte, darunter das Honor Band 3 (dasselbe Huawei-Ökosystem), und erreichte bei den meisten davon stilles Pairing ohne Nutzerautorisierung. Das proprietäre Protokoll hat das nicht verhindert.

Gleichzeitig wurde das Protokoll selbst mehrfach reverse-engineered - von der Gadgetbridge-Community, vom Projekt huawei-lpv2, von den Forschern, die auf der Easterhegg 2019 präsentierten [2], und von mir für D2Explorer. Security through obscurity mit Ablaufdatum.

Die HMAC-SHA256-Schlüsselableitung aus dem QR-Code ist tatsächlich ordentliche Kryptografie. Aber darum geht es nicht. Du könntest dieselben Sicherheitseigenschaften mit Standard-BLE Secure Connections und einer Out-of-Band-Pairing-Methode erreichen (wie NFC oder QR-Code) - ohne dabei jede Drittanbieter-Anwendung auszusperren.

Die Community schlägt zurück

Die Community hat das nicht still hingenommen.

Gadgetbridge

Gadgetbridge - die Open-Source-Android-App für Wearables - unterstützt inzwischen die Huawei Watch D2 [5]. Du kannst deine Uhr ohne Huaweis Health-App pairen. Es brauchte erheblichen Reverse-Engineering-Aufwand (siehe PR #2462 [6]), und es gibt Einschränkungen - die EKG-Funktion ist deaktiviert, wenn die Uhr mit Gadgetbridge gekoppelt ist [7] - aber es funktioniert.

Die Authentifizierungsimplementierung in Gadgetbridge behandelt Auth-Version 3, berechnet den Bonding-Key aus der Pairing-Nachricht (Service 0x01, Command 0x0e) und nutzt ihn zur Entschlüsselung. Eine 17-stellige Huawei-Account-ID ist für die Aushandlung des Authentifizierungsschlüssels erforderlich.

huawei-lpv2

Das Projekt huawei-lpv2 liefert eine reine Python-Implementierung von Huaweis Link Protocol v2 [8]. Es wird gepflegt, hat mehrere Forks und dient als Referenz für alle, die Integrationen für Huawei-Wearables außerhalb des offiziellen Ökosystems bauen.

D2Explorer

Mein eigenes D2Explorer-Projekt ging einen anderen Weg - eine C++-Implementierung mit SimpleBLE, die unter Linux und macOS funktioniert. Die Arbeit umfasste:

TLV-Serialisierung/-Deserialisierung implementieren (HuaweiProtocol).
Präzise Message-Constructoren bauen (ProtocolMessageBuilder).
Die kryptografischen Schritte korrekt hinbekommen - Nonce-Erzeugung, HMAC-SHA256, XOR-Verschlüsselung (CryptoOperations, CryptoUtils).
Strikte Zustandsübergänge und Timing verwalten (HuaweiPairingProtocol, ProtocolStateManager).
Fehler debuggen, die durch Timing-Abweichungen im Millisekundenbereich und subtile Krypto-Fehler verursacht wurden.

D2Explorer existiert weil Huaweis Protokoll es nötig gemacht hat. Es ist der Workaround, der für grundlegende Funktionalität außerhalb des Walled Garden erforderlich ist.

AsteroidOS

AsteroidOS 2.0 erschien im Februar 2026 als großes Update des Open-Source-Smartwatch-Betriebssystems auf Linux-Basis [9]. Es unterstützt nun etwa 30 Geräte, darunter die Huawei Watch und Huawei Watch 2, mit Funktionen wie Always-on-Display und Tilt-to-Wake. Eine vollständige Open-Source-Alternative zu Huaweis Firmware.

Die regulatorische Flut

Die EU schaut nicht nur zu. Der Digital Markets Act (DMA) beginnt, Veränderung zu erzwingen [10].

Im Dezember 2025 veröffentlichte Apple iOS 26.3 mit AirPods-ähnlichem Pairing für Drittanbieter-Geräte - darunter Huawei-Smartwatches - ausdrücklich, um die DMA-Anforderungen zu erfüllen [11]. Hintergrundsynchronisierung zwischen Huawei-Uhren und iPhones ist in Europa bereits in Betrieb.

Der DMA schreibt vor, dass Gatekeeper Interoperabilität für verbundene Geräte bereitstellen. Das zielt direkt auf genau die Art proprietären BLE-Lock-ins, die Huawei (und Apple, und alle anderen) praktiziert haben. Der vollständige Rollout dieser Interoperabilitätsfunktionen wird im Laufe des Jahres 2026 erwartet.

Das ist erheblich. Zum ersten Mal gibt es regulatorischen Druck, das zu standardisieren, was Anbieter absichtlich proprietär gehalten haben. Die technische Community kann Protokolle einzeln reverse-engineeren, aber Regulierung kann die Anreizstruktur für die ganze Branche verändern.

Was das bedeutet

Das Pairing-Protokoll der Huawei Watch D2 ist eine Fallstudie dafür, wie eigene Protokolle über Standard-Transportschichten Vendor Lock-in erzwingen können. Die Schichten aus proprietärer Kryptografie, eigenen Nachrichtenformaten und timingempfindlichen Handshakes existieren nicht, weil Standard-BLE keine Authentifizierung könnte - das kann es -, sondern weil proprietäre Protokolle Nutzer im Ökosystem halten.

Das Bild verändert sich allerdings. Gadgetbridge gibt dir schon jetzt eine Alternative. Der EU DMA erzwingt Interoperabilität auf regulatorischer Ebene. Und Open-Source-Projekte wie huawei-lpv2, D2Explorer und AsteroidOS beweisen, dass die Community reverse-engineeren wird, was Anbieter einzuschließen versuchen.

D2Explorer zu bauen hatte weniger mit Bluetooth zu tun und mehr mit kryptografischer Detektivarbeit. Es unterstreicht etwas, das eigentlich nicht unterstrichen werden sollte: Du solltest mit der Software deiner Wahl auf deine eigenen Gesundheitsdaten zugreifen können.

Referenzen

1. huawei-lpv2: Pure Python implementation of Huawei BLE Link Protocol v2 - Open-Source-Referenzimplementierung des Protokolls.
2. All Your Fitness Data Belongs to You: Reverse Engineering the Huawei Health Android App - Easterhegg-2019-Konferenzvortrag, der den Reverse-Engineering-Aufwand dokumentiert. Folien (PDF).
3. WatchWitch: Academic Research on Smartwatch Interoperability - Dokumentiert, wie alle großen Anbieter proprietäre Protokolle für Ökosystem-Lock-in nutzen.
4. BlueDoor: Breaking the Secure Information Flow via BLE Vulnerability (Tsinghua University) - Fand stille Pairing-Schwachstellen in 16 BLE-Geräten, darunter Honor Band 3.
5. Gadgetbridge: Huawei/Honor Device Support - Offizielle Support-Seite für Huawei- und Honor-Wearables.
6. Gadgetbridge PR #2462: Initial Huawei/Honor Support - Der Pull Request, der Huawei-Geräteunterstützung zu Gadgetbridge hinzufügte.
7. Gadgetbridge Issue #4918: ECG Disabled with Gadgetbridge - Bekannte Einschränkung bei der Nutzung von Gadgetbridge statt Huawei Health.
8. Gadgetbridge: Huawei/Honor Pairing Guide - Schritt-für-Schritt-Pairing-Anleitung für Huawei-Geräte.
9. AsteroidOS 2.0 Release - Open-Source-Smartwatch-Betriebssystem, das nun etwa 30 Geräte unterstützt, darunter Huawei-Uhren.
10. EU Digital Markets Act: Interoperability Requirements - DMA-Bestimmungen, die Interoperabilität für verbundene Geräte vorschreiben.
11. iOS 26.3 DMA Features: Third-Party Smartwatch Pairing - Apples Umsetzung der EU-Interoperabilitätsvorgaben für Wearables.

BlueZ-Pairing-Fix: Externer Python-Agent & D-Bus-Polling

Tue, 08 Apr 2025 00:00:00 GMT

TL;DR: Wenn du mit einem eigenen C++/sd-bus-Pairing-Agent unter BlueZ 5.66+ org.bluez.Error.AuthenticationFailed bekommst, ist wahrscheinlich deine interne Agent-Registrierung das Problem. Starte einen externen Python-Agent (simple-agent.py) als separaten Prozess und implementiere D-Bus-Property-Polling, statt dich auf PropertiesChanged-Signale zu verlassen. Details und Code unten.

Ich habe zwei Tage lang auf org.bluez.Error.AuthenticationFailed gestarrt, bevor ich verstanden habe, was eigentlich los war.

Der Pairing-Agent war registriert. Die D-Bus-Aufrufe sahen korrekt aus. busctl bestätigte, dass alles an Ort und Stelle war -- und BlueZ sagte einfach weiter nein. Das passierte während der Arbeit an D2Explorer -- einem Tool zum Pairing mit der Huawei Watch D2 unter Linux -- und der Pairing-Fehler blockierte alles.

Das ist wirklich passiert, und so haben wir es behoben.

Der Plan: ein interner C++-Pairing-Agent

Die Idee war sauber und in sich geschlossen. Eine einzige C++-Anwendung, die den gesamten Pairing-Prozess mit sd-bus übernimmt (den C/C++-D-Bus-Bindings):

Mit dem System-D-Bus verbinden.
Den Bluetooth-Adapter finden (org.bluez.Adapter1).
Eine C++-Klasse implementieren, die das Interface org.bluez.Agent1 bereitstellt.
Den Agent bei org.bluez.AgentManager1 über RegisterAgent und RequestDefaultAgent registrieren. Wir begannen mit der Capability DisplayYesNo, später vereinfachten wir auf NoInputNoOutput.
Das Zielgerät entdecken (org.bluez.Device1).
Pair() auf dem D-Bus-Interface des Geräts aufrufen.
Der interne Agent behandelt Callbacks (RequestConfirmation, RequestAuthorization) automatisch -- keine Benutzerinteraktion nötig.
Das Gerät als vertrauenswürdig markieren, eine GATT-Verbindung aufbauen, fertig.

Ein Binary, keine externen Abhängigkeiten. Das war der Plan.

Die Wand: `org.bluez.Error.AuthenticationFailed`

Bis Schritt 6 funktionierte alles. Adapter gefunden, Agent registriert (D-Bus bestätigte es), Gerät entdeckt. Aber in dem Moment, in dem wir Device1.Pair() über sd_bus_call_method aufriefen -- sofortiger Fehlschlag:

[BluetoothDevice] Calling Device1.Pair() method via D-Bus
[BluetoothDevice] Device1.Pair() method threw exception: Failed to call method 'Pair':
    Input/output error - D-Bus error: org.bluez.Error.AuthenticationFailed (Authentication Failed)

Wir haben alles versucht. Verschiedene Agent-Capabilities. Die sd-bus-vtable-Konfiguration geprüft. Verifiziert, dass die Agent-Methodenimplementierungen schnell erfolgreich zurückgaben. Mit busctl und gdbus den D-Bus-Traffic beobachtet -- die Registrierungsaufrufe sahen korrekt aus. Der Pair()-Aufruf scheiterte einfach weiter.

Sackgasse.

Der Durchbruch: ein externer Python-Agent

Um das Problem zu isolieren, nahmen wir den internen C++-Agent aus der Gleichung. Wir starteten BlueZs Standard-simple-agent.py als separaten Prozess bevor wir unsere C++-App starteten (jetzt ohne eigene Agent-Registrierung):

# Terminal 1: Run the external agent
sudo python simple-agent.py NoInputNoOutput

# Terminal 2: Run our C++ app (no internal agent)
sudo ./build/huawei_pair_app <MAC> <QR_VALUE>

Das Ergebnis:

[BluetoothDevice] Calling Device1.Pair() method via D-Bus
[BluetoothDevice] Device1.Pair() method succeeded  <--- SUCCESS!

Konstant. Jedes Mal. Der Fehler AuthenticationFailed verschwand komplett.

Das bewies, dass das Problem nicht bei Pair() selbst lag, und auch nicht beim Gerät oder bei BlueZs Pairing-Fähigkeit. Es lag konkret daran, wie unsere C++-Anwendung mit sd-bus sich als Pairing-Agent registrierte und interagierte. Die exakt gleiche logische Operation -- einen NoInputNoOutput-Agent registrieren und Pair() aufrufen -- funktionierte perfekt, wenn der Agent als separater Python-Prozess lief.

Das funktionierte.

Warum ist der interne Agent gescheitert?

Als ich zuerst darauf stieß, hatte ich nur Hypothesen. Seitdem habe ich echte dokumentierte Hinweise gefunden, dass das ein breiteres Problem ist -- nicht nur unser Code.

BlueZ-5.70+-Regression

BlueZ GitHub Issue #605 dokumentiert Fälle, in denen Geräte unter BlueZ 5.50 problemlos pairen, auf neueren Versionen aber mit auth failed with status 0x05 scheitern. HCI-Logs zeigen Status: PIN or Key Missing (0x06) trotz gespeicherter Link Keys. Der Workaround? Das alte bluez-simple-agent.py-Skript ausführen. Kommt dir bekannt vor?

Agent-Verfügbarkeit ist die eigentliche Ursache

Bleak Issue #1434 macht es noch klarer: Pairing funktioniert nur, wenn bluetoothctl oder GNOME Bluetooth läuft, weil diese Anwendungen den nötigen Authentication-Agent registrieren. Ohne einen aktiven, korrekt funktionierenden Agent gibt BlueZ intern No agent available for request type 2 zurück -- was nach außen als AuthenticationFailed erscheint.

Die zentrale Erkenntnis: Es reicht nicht, einen Agent zu registrieren. Der Agent muss auf BlueZs Callbacks auf eine Weise antworten, die bluetoothd als gültig betrachtet. Und irgendetwas daran, wie sd-bus das innerhalb desselben Prozesses handhabt, der das Pairing startet, reicht neueren BlueZ-Versionen nicht.

Vielleicht ist es nicht einmal BlueZ

Red Hat Bug #1905671 zeigte, dass manche AuthenticationFailed-Fehler kernelbezogen sind, nicht BlueZ-bezogen. Kernel 5.9 hatte Pairing-Probleme, die 5.8.18 und 5.10+ nicht hatten. Der Kommentar des Maintainers ist zitierenswert: "Bluetooth is complex, it could be firmware, kernel, bluez, controller, end device or a combination of them all."

Agent-Capability-Mismatch

BlueZ Issue #650 dokumentiert noch einen anderen Winkel: Bestimmte Geräte (besonders iOS) scheitern beim Pairing mit NoInputNoOutput-Agents, weil sie Secure Connections auf Legacy Pairing herabstufen, was bei späterem Attribute-Zugriff Insufficient Authentication (0x05)-Fehler verursacht. Das ist ein Security-Manager-Protocol-(SMP)-Negotiation-Problem, kein Problem der Agent-Registrierung -- aber es erzeugt dieselbe Fehlermeldung.

Die wahrscheinlichsten Ursachen in unserem Fall

Angesichts der Hinweise sind das die wahrscheinlichsten Erklärungen für den internen sd-bus-Agent-Fehlschlag:

Timing -- die sd-bus-Registrierung oder Methodenbehandlung innerhalb unserer Event Loop antwortete nicht genau in dem Zeitfenster, das bluetoothd erwartete.
Feinheiten von sd-bus vs. python-dbus -- Unterschiede darin, wie diese Libraries mit dem D-Bus-Daemon interagieren oder Object Lifetimes behandeln.
Strengere Anforderungen in BlueZ 5.66+ -- geänderte interne Sequenzen für Agent-Interaktion, die sd-bus, wenn es in derselben Anwendung verwendet wird, die das Pairing startet, nicht erfüllt.

Die zweite Wand: D-Bus-Signale sind unzuverlässig

AuthenticationFailed zu überwinden war ein großer Gewinn, aber es war nicht das Ende. Mit dem externen Agent an Ort und Stelle war Pair() erfolgreich -- aber wir konnten nicht zuverlässig erkennen, wann es fertig war.

Wir verließen uns auf D-Bus-PropertiesChanged-Signale (über sd-bus), um zu wissen, wann Paired, Trusted, Connected und ServicesResolved auf true wechselten. Manchmal kamen die Signale an. Manchmal kamen sie spät. Manchmal kamen sie gar nicht.

Also implementierten wir aktives Polling -- einen Fallback, der Property-Werte direkt abfragt, wenn Signale nicht auftauchen:

bool BluetoothDevice::isPaired() {
    bool cachedValue = mockPaired_.load(); // Check signal-updated cache
    if (cachedValue) return true;

    // Signal didn't fire? Poll D-Bus directly.
    Logger::debug("[Polling] Polling Paired property via D-Bus...");
    bool polledValue = false;
    adapter_.getObjectProperty<bool>(
        devicePath_, "org.bluez.Device1", "Paired", polledValue
    );
    if (polledValue) mockPaired_.store(true); // Update cache
    return polledValue;
}

Jede State-Transition-Methode (isPaired(), isTrusted(), isConnected(), areServicesResolved()) folgt demselben Muster: zuerst den gecachten atomic boolean prüfen (vom Signal-Handler aktualisiert, wenn er funktioniert), dann auf einen direkten D-Bus-Get-Property-Aufruf zurückfallen.

Nicht elegant. Aber nötig.

Das funktionierte.

Der komplette Fix

Hier ist das konsolidierte Rezept. Wenn du automatisiertes Bluetooth-Pairing unter Linux mit BlueZ 5.66+ baust und auf AuthenticationFailed läufst:

Schritt 1: simple-agent.py holen

Hol es aus dem BlueZ source tree.

Schritt 2: den externen Agent starten

sudo python simple-agent.py NoInputNoOutput

Lass das in einem separaten Terminal laufen (oder als Background Service).

Schritt 3: den internen Agent aus deiner App entfernen

Entferne alle RegisterAgent- / RequestDefaultAgent-Aufrufe aus deiner C++-Anwendung. Lass den externen Python-Agent die Authentication-Callbacks behandeln.

Schritt 4: D-Bus-Property-Polling hinzufügen

Verlass dich nicht nur auf PropertiesChanged-Signale. Implementiere für jede kritische Property (Paired, Trusted, Connected, ServicesResolved) das oben gezeigte Cache-then-poll-Muster. Polle periodisch aus deiner Main Loop.

Schritt 5: verifizieren

Bestätige, dass der externe Agent läuft (sudo python simple-agent.py NoInputNoOutput).
Starte deine App. Pair() sollte erfolgreich sein.
Beobachte die Polling-Logs -- du solltest D-Bus-Property-Abfragen für State Transitions sehen.
Wenn Pair() immer noch scheitert, prüfe deine BlueZ-Version (bluetoothd --version) und Kernel-Version -- das Problem könnte tiefer liegen.

Was dich das kostet

Ich werde nicht so tun, als wäre das eine saubere Lösung. Ist es nicht:

Externe Abhängigkeit -- deine App braucht jetzt einen separaten laufenden Python-Prozess.
Mehr Komplexität -- Polling-Logik in der Main Loop, zusätzlich zu Signal-Handlern.
Weniger in sich geschlossen -- der Traum vom einzelnen Binary ist dahin.

Aber es funktioniert. Zuverlässig. Und wenn du zwei Tage lang auf AuthenticationFailed gestarrt hast, ist "es funktioniert" das, was zählt.

Referenzen

1. BlueZ GitHub Issue #55: Device characteristics and pairing timing -- Intermittent pairing failures related to agent timing.
2. Bluetooth Auto Pairing with NoInputNoOutput Agent Issues -- Forum discussion about headless pairing challenges.
3. BlueZ Source: test/simple-agent -- The standard Python agent.
4. BlueZ GitHub Issue #605: Pairing regression in 5.70+ -- Documented failures with newer BlueZ versions.
5. Bleak Issue #1434: Pairing requires active agent -- Evidence that agent availability is the root cause.
6. Red Hat Bug #1905671: Kernel-related pairing failures -- Not always BlueZ -- sometimes it's the kernel.
7. BlueZ GitHub Issue #650: Agent capability mismatch -- SMP negotiation failures with NoInputNoOutput.
8. BlueZ Agent API Documentation -- Official agent interface reference.
9. Kynetics: Pairing Agents in the BlueZ Stack -- Technical deep dive into agent registration.

Entwicklerleitfaden: Klassen- und Namespace-Updates in Shopware 6.5/6.6

Sat, 30 Nov 2024 00:00:00 GMT

Shopware 6.5 und 6.6 haben mehrere wichtige Änderungen an Klassen, Namespaces, Data-Attributen und Sicherheitsmechanismen eingeführt, die Entwickler kennen müssen, wenn sie ihre Shopware-Projekte aktualisieren oder warten. Dieser Artikel gibt einen knappen, aber umfassenden Überblick über diese Änderungen, zusammen mit Beobachtungen zu ihren Auswirkungen und dazu, wie du deinen Code entsprechend anpasst.

Einführung

Wenn Shopware sich weiterentwickelt, bringen Updates oft Verbesserungen, Optimierungen und neue Funktionen. Sie können aber auch Änderungen einführen, die bestehende Codebasen betreffen. Diese Änderungen zu verstehen, ist entscheidend, um einen reibungslosen Übergang sicherzustellen und die neuen Möglichkeiten sinnvoll zu nutzen.

Dieser Artikel konzentriert sich auf die folgenden Kernbereiche:

Elasticsearch-Namespace-Migration
Aktualisierungen beim Media-Path-Handling
Methodenänderungen in AvailableCombinationLoader
Symfony-Framework-Upgrade auf Version 6
Aktualisierungen beim Stock-Handling
Storefront-Bootstrap-Upgrade
Änderungen am Data-Attribut des Offcanvas Cart
Änderungen beim CSRF-Schutz
Erweiterungen am Rule Builder

Schauen wir uns jede dieser Änderungen im Detail an.

1. Elasticsearch-Namespace-Migration

Überblick der Änderung

Vorheriger Namespace: ONGR\ElasticsearchDSL
Neuer Namespace: OpenSearchDSL

Auswirkung

Alle Klassen und Methoden, die mit Elasticsearch interagieren, müssen ihre Namespaces aktualisieren, um die Migration von ONGR\ElasticsearchDSL zu OpenSearchDSL abzubilden.

Erforderliche Aktion

Aktualisiere Import-Statements und Referenzen in deinem Code, sodass sie den neuen Namespace verwenden.

Beispiel

// Before
use ONGR\ElasticsearchDSL\Query\MatchQuery;

$query = new MatchQuery('field', 'value');

// After
use OpenSearchDSL\Query\MatchQuery;

$query = new MatchQuery('field', 'value');

Beobachtungen

Diese Änderung passt zur breiteren Verschiebung der Branche hin zu OpenSearch, einem communitygetriebenen Fork von Elasticsearch. Die Aktualisierung auf den neuen Namespace stellt Kompatibilität mit laufender Entwicklung und Unterstützung sicher.

2. Media-Path-Handling

Überblick der Änderung

Media-Pfade werden nun direkt in der Datenbank gespeichert, statt dynamisch generiert zu werden.

Auswirkung

Klassen und Services, die bisher auf dynamische Pfadgenerierung angewiesen waren, müssen Media-Pfade nun aus der Datenbank abrufen.

Erforderliche Aktion

Passe deinen Code so an, dass er die Methode getPath() der MediaEntity verwendet.

Beispiel

// Before (dynamic path generation)
$mediaPath = $mediaService->getPath($mediaId);

// After (database-stored path)
$mediaPath = $mediaEntity->getPath();

Beobachtungen

Media-Pfade in der Datenbank zu speichern verbessert die Performance, weil weniger Rechenaufwand entsteht. Außerdem sorgt es für mehr Konsistenz und Zuverlässigkeit im Umgang mit Medien.

3. Methoden-Update in `AvailableCombinationLoader`

Überblick der Änderung

Die Methode load() in AbstractAvailableCombinationLoader wurde durch loadCombinations() ersetzt.

Auswirkung

Alle eigenen Klassen, die AbstractAvailableCombinationLoader erweitern, müssen die neue Methode loadCombinations() statt der alten Methode load() implementieren.

Erforderliche Aktion

Benenne deine Methodenimplementierungen um oder refaktorisiere sie, damit sie zum neuen Methodennamen und zur neuen Signatur passen.

Beispiel

// Before
$combinations = $combinationLoader->load($productId);

// After
$combinations = $combinationLoader->loadCombinations($productId);

Beobachtungen

Diese Änderung erhöht die Klarheit, weil der Methodenname beschreibender ist. Sie kann außerdem zusätzliche Parameter oder Rückgabetypen betreffen, daher ist es wichtig, die Methodensignatur zu prüfen.

4. Symfony-Framework-Upgrade auf Version 6

Überblick der Änderung

Shopware hat seine Symfony-Komponenten auf Version 6 aktualisiert.

Auswirkung

Das Upgrade führt einige Breaking Changes ein, bedingt durch entfernte veraltete Funktionen und Änderungen an Methodensignaturen. Eigener Code, der auf älteren Symfony-Funktionen basiert, kann brechen oder Warnungen erzeugen.

Erforderliche Aktion

Prüfe deinen Code auf veraltete Symfony-Funktionen und aktualisiere ihn so, dass er mit Symfony 6 kompatibel ist.

Beobachtungen

Mit der aktuellen Symfony-Version Schritt zu halten sorgt für bessere Performance, Sicherheit und Zugriff auf neue Funktionen. Gleichzeitig verlangt es sorgfältige Codeprüfung und Tests, um Kompatibilität sicherzustellen.

5. Aktualisierungen beim Stock-Handling

Überblick der Änderung

Eine neue Stock API wurde eingeführt, verfügbar hinter dem Feature-Flag STOCK_HANDLING.

Auswirkung

Klassen und Services rund um Bestandsverwaltung müssen sich möglicherweise an die neue API-Struktur anpassen, besonders wenn sie direkt mit Bestandsdaten arbeiten.

Erforderliche Aktion

Verwende die neuen Methoden zur Bestandsverarbeitung, die die API bereitstellt, und stelle sicher, dass bestandsbezogene Logik zur aktualisierten Struktur passt.

Beispiel

// Before
$stock = $productEntity->getStock();

// After
$stock = $stockService->getStock($productId);

Beobachtungen

Die neue Stock API bietet eine robustere und flexiblere Möglichkeit, Bestand zu verwalten, und kann Anpassungen sowie Integrationen mit externen Systemen vereinfachen.

6. Storefront-Bootstrap-Upgrade

Überblick der Änderung

Die Storefront wurde von Bootstrap 4 auf Bootstrap 5 aktualisiert, und jQuery wurde als Abhängigkeit entfernt.

Auswirkung

Eigener JavaScript-Code und Templates, die auf jQuery oder Bootstrap-4-Komponenten angewiesen sind, müssen refaktorisiert werden, damit sie zu Bootstrap 5 passen und bei Bedarf natives JavaScript verwenden.

Erforderliche Aktion

Ersetze jQuery-Nutzung durch natives JavaScript oder Bootstrap-5-Utilities.
Aktualisiere Bootstrap-Klassen und Komponenten, damit sie zur Benennung und Struktur von Bootstrap 5 passen.

Beobachtungen

Bootstrap 5 bringt bessere Performance, weniger Abhängigkeiten und modernisierte Komponenten. Die Aktualisierung kann zeitaufwendig sein, bietet aber langfristige Vorteile für Wartbarkeit und Nutzererlebnis.

7. Änderungen am Offcanvas-Cart-Data-Attribut (Shopware 6.6)

Überblick der Änderung

In Shopware 6.6 gab es eine subtile, aber wichtige Änderung am Data-Attribut, das die Offcanvas-Cart-Funktion auslöst.

Vorheriges Data-Attribut: data-offcanvas-cart
Neues Data-Attribut: data-off-canvas-cart

Auswirkung

Eigene Templates oder Themes, die das Attribut data-offcanvas-cart ohne Bindestriche verwenden, können feststellen, dass der Offcanvas Cart nicht mehr wie erwartet funktioniert, weil der JavaScript-Listener in Shopware 6.6 nach der Variante mit Bindestrichen sucht.

Erforderliche Aktion

Aktualisiere das Attribut data-offcanvas-cart in deinen Templates zu data-off-canvas-cart.

Beispiel

<!-- Before -->
<div class="header-cart" data-offcanvas-cart="true">
    <!-- Cart content -->
</div>

<!-- After -->
<div class="header-cart" data-off-canvas-cart="true">
    <!-- Cart content -->
</div>

Beobachtungen

Diese Änderung ist in den offiziellen Shopware-6.6-Release-Notes nicht gut dokumentiert, ist aber entscheidend dafür, dass der Offcanvas Cart korrekt funktioniert. Das JavaScript, das die Cart-Funktionalität initialisiert, verlässt sich auf das Attribut data-off-canvas-cart, und jede Abweichung kann verhindern, dass der Cart funktioniert.

Zusätzliche Hinweise

Konsistenz ist entscheidend: Stelle sicher, dass alle Stellen aktualisiert werden, an denen das Offcanvas-Cart-Attribut verwendet wird.
Gründlich testen: Teste nach der Änderung die Cart-Funktionalität, um zu bestätigen, dass sie wie erwartet funktioniert.
Auf ähnliche Änderungen prüfen: Andere Data-Attribute oder Event-Listener können ähnliche Updates erhalten haben; prüfe deine eigenen Templates entsprechend.

8. Änderungen beim CSRF-Schutz

Überblick der Änderung

Shopware 6.5 und spätere Versionen haben das explizite CSRF-Token-Handling in Templates entfernt und sind zu einer SameSite-Cookie-Strategie für den CSRF-Schutz übergegangen.

Auswirkung

Templates und Formulare, die bisher CSRF-Tokens mit der Funktion sw_csrf eingebunden haben, erzeugen Fehler, weil diese Funktion nicht mehr existiert.

Erforderliche Aktion

CSRF-Token-Funktionen entfernen: Entferne die Nutzung von {{ sw_csrf('route_name') }} aus deinen Templates.
Auf SameSite-Cookies vertrauen: Verlasse dich auf die eingebaute SameSite-Cookie-Strategie für CSRF-Schutz, die keine expliziten Tokens in Formularen erfordert.
Formularattribute anpassen: Stelle sicher, dass Formulare und AJAX-Requests korrekt konfiguriert sind, damit sie mit dem neuen CSRF-Schutzmechanismus funktionieren.

Beispiel

<!-- Before -->
<form action="{{ path('frontend.checkout.line-item.add') }}" method="post">
    {{ sw_csrf('frontend.checkout.line-item.add') }}
    <!-- Form fields -->
    <button type="submit">Add to Cart</button>
</form>

<!-- After -->
<form action="{{ path('frontend.checkout.line-item.add') }}" method="post">
    <!-- Form fields -->
    <button type="submit">Add to Cart</button>
</form>

Beobachtungen

Fehlerbehebung: Das Entfernen der Funktion sw_csrf behebt den Fehler "Unknown 'sw_csrf' function".
Sicherheit bleibt erhalten: Die SameSite-Cookie-Strategie schützt weiterhin vor CSRF-Angriffen, ohne zusätzliche Tokens.
Vereinfachte Templates: Formulare werden sauberer und etwas einfacher, weil keine CSRF-Tokens mehr nötig sind.

Zusätzliche Hinweise

Testen ist entscheidend: Teste Formularübermittlungen nach diesen Änderungen gründlich, um sicherzustellen, dass sie korrekt funktionieren.
Den neuen Mechanismus verstehen: Mach dich damit vertraut, wie die SameSite-Cookie-Strategie funktioniert, um eine sichere Anwendung zu erhalten.
Dokumentation aktualisieren: Stelle sicher, dass interne Dokumentation diese Änderung widerspiegelt, damit sie später keine Verwirrung erzeugt.

9. Umgang mit Problemen beim Offcanvas Cart

Überblick des Szenarios

Nach dem Aktualisieren von Templates und dem Entfernen der Funktion sw_csrf können Entwickler weiterhin Probleme sehen, bei denen ein Klick auf den Button "Add to Cart" den Offcanvas Cart öffnet, dieser aber leer erscheint.

Ursache

Der Offcanvas Cart zeigt die hinzugefügten Artikel möglicherweise nicht an, weil Parameter in der Formularübermittlung fehlen oder falsch sind, konkret das fehlende Input-Feld redirectTo.

Erforderliche Aktion

Den Parameter redirectTo hinzufügen: Füge deinen Add-to-Cart-Formularen ein verstecktes Input-Feld mit dem Namen redirectTo und dem Wert frontend.cart.offcanvas hinzu.
Korrekte Data-Attribute sicherstellen: Prüfe, dass alle nötigen Data-Attribute vorhanden und korrekt benannt sind.

Beispiel

<form action="{{ path('frontend.checkout.line-item.add') }}" method="post">
    <input type="hidden" name="redirectTo" value="frontend.cart.offcanvas"/>
    <input type="hidden" name="lineItems[{{ product.id }}][id]" value="{{ product.id }}">
    <!-- Other form fields -->
    <button type="submit">Add to Cart</button>
</form>

Beobachtungen

Funktionalität wiederherstellen: Das Hinzufügen des Parameters redirectTo teilt Shopware mit, dass der Offcanvas Cart nach dem Hinzufügen eines Artikels geladen werden soll, wodurch der Cart korrekt angezeigt wird.
Auf Details achten: Kleine Auslassungen wie fehlende Input-Felder können zu erheblichen Funktionsproblemen führen und zeigen, wie wichtig sorgfältige Codeprüfung ist.

Zusätzliche Hinweise

Konsistenz bei Data-Attributen: Prüfe doppelt, ob Data-Attribute wie data-product-id korrekt gesetzt sind.
JavaScript-Abhängigkeiten prüfen: Stelle sicher, dass alle JavaScript-Plugins oder Komponenten rund um den Cart korrekt geladen und initialisiert werden.
Cache leeren: Leere nach Änderungen den Shopware-Cache und deinen Browser-Cache, damit veraltete Dateien keine Probleme verursachen.

10. Erweiterungen am Rule Builder

Überblick der Änderung

Die Rule Builder API wurde erweitert, um komplexere bedingte Logik zu unterstützen.

Auswirkung

Eigene Regeln und Bedingungen müssen möglicherweise angepasst werden, um zu den neuen Interfaces oder Methoden zu passen, die der erweiterte Rule Builder bereitstellt.

Erforderliche Aktion

Prüfe die Rule-Builder-Dokumentation und aktualisiere eigene Regelimplementierungen, um Kompatibilität sicherzustellen.

Beobachtungen

Erweiterte Regelmöglichkeiten erlauben präziseres Targeting und mehr Anpassung innerhalb von Shopware. Diese neuen Funktionen zu nutzen kann zu besserer Anpassungsfähigkeit und persönlicheren Erlebnissen für Endnutzer führen.

Fazit

Shopware 6.5 und 6.6 führen mehrere wichtige Änderungen an Klassen, Namespaces, Data-Attributen und Sicherheitsmechanismen ein, die Entwickler berücksichtigen müssen, um Kompatibilität zu erhalten und neue Funktionen zu nutzen. Die Aktualisierung deiner Codebase verlangt sorgfältige Prüfung und Tests, bietet aber Chancen, Performance, Sicherheit und Funktionalität zu verbessern.

Empfehlungen

Vorausplanen: Prüfe vor dem Update die offiziellen Shopware-Release-Notes und Upgrade-Guides für umfassende Informationen.
Gründlich testen: Implementiere Änderungen in einer Staging-Umgebung und teste ausführlich, um Probleme zu finden und zu beheben.
Dokumentation nutzen: Nutze Shopware-Dokumentation und Community-Foren als Orientierung zu bestimmten Änderungen.
Informiert bleiben: Verfolge künftige Updates, um kommende Änderungen früh zu erkennen und dich entsprechend vorzubereiten.

Zusätzliche Beobachtungen

Auf Details achten: Kleine Änderungen, etwa Bindestriche in Data-Attributen oder das Entfernen von Funktionen, können erhebliche Auswirkungen haben. Prüfe Template-Updates immer sorgfältig.
Community-Support: Die Shopware-Community ist aktiv und kooperativ. Austausch mit anderen Entwicklern kann Einsichten und Lösungen für häufige Herausforderungen liefern.
Best Practices: Aktualisierte Best Practices zu übernehmen, etwa natives JavaScript statt jQuery zu verwenden und auf moderne Sicherheitsstrategien zu setzen, führt zu saubererem und effizienterem Code.
Deprecations beobachten: Auf Deprecation-Hinweise zu achten und sich auf künftige Entfernungen vorzubereiten kann Störungen während Upgrades minimieren.

Wenn Entwickler die Änderungen an Klassen, Namespaces, Data-Attributen und Sicherheit in Shopware 6.5 und 6.6 verstehen und angehen, können sie einen reibungslosen Übergang sicherstellen und weiterhin robuste, zukunftsfähige E-Commerce-Lösungen bauen.

Die Entwicklung von Docker Compose: Was sich geändert hat und warum es wichtig ist

Wed, 20 Nov 2024 00:00:00 GMT

TL;DR: Docker Compose v1 (docker-compose) wurde im April 2025 vollständig entfernt. Das Feld version in deinem YAML ist tot. Der Schlüssel x-develop heißt jetzt einfach develop. Der Watch-Modus ist mit initial_sync produktionsreif. Es gibt eine kritische Path-Traversal-CVE (CVE-2025-62725), wenn du include mit OCI-Artefakten nutzt -- aktualisiere auf v2.40.2 oder neuer. Und ja, Compose ist von v2 auf v5 gesprungen. Details unten.

Ursprünglich im November 2024 veröffentlicht. Aktualisiert im März 2026 mit Compose v5, CVE-2025-62725, der Entfernung von v1 und neuen Spec-Funktionen.

Wenn du Docker Compose schon eine Weile nutzt, hast du wahrscheinlich bemerkt, dass Dinge unter deinen Füßen brechen oder sich verändern. Die letzten zwei Jahre waren die aggressivste Entwicklung, die Compose je durchlaufen hat -- und nicht alles davon war offensichtlich.

Ich benutze Compose täglich. Die meisten meiner Entwicklungs-Setups laufen darauf. Wenn sich Dinge ändern, merke ich das. Hier ist, was wirklich zählt.

Was kaputtging

docker-compose ist tot

Nicht deprecated. Nicht im Wartungsmodus. Tot. Das eigenständige docker-compose-Binary (die Python-basierte v1) wurde im April 2025 aus GitHub-Actions-Runnern und offiziellen Docker-Images entfernt [1]. Wenn deine CI/CD-Pipelines noch docker-compose mit Bindestrich referenzieren, sind sie kaputt oder kurz davor.

# This no longer works
docker-compose up -d

# This is the only way now
docker compose up -d

Das Go-basierte docker compose (v2, inzwischen v5) ist seit 2022 die eigentliche Implementierung. Die v1-CLI hing aus Kompatibilitätsgründen an der Lebenserhaltung. Diese Lebenserhaltung ist beendet.

Das version-Feld ist weg

Hör auf, version: "3.8" an den Anfang deiner Compose-Dateien zu setzen. Es tut nichts. Es wird seit v2 ignoriert und ist jetzt offiziell deprecated. Moderne Compose-Dateien beginnen mit services:.

# Stop doing this
version: "3.8"
services:
  web:
    image: nginx

# Just do this
services:
  web:
    image: nginx

Wenn du version: in einem Tutorial siehst, ist dieses Tutorial veraltet.

Weitere Deprecations

links -- nutze Docker-Netzwerke. Links sind seit dem Start von Compose v2 Legacy.
container_name -- lass Docker die Namen verwalten. Fest codierte Namen brechen Skalierung und verursachen Konflikte.
Kurze Volume-Syntax für komplexe Mounts -- nutze die Langform mit type, source, target.

Was neu und tatsächlich nützlich ist

Watch-Modus (jetzt produktionsreif)

Das ist die größte Verbesserung der Lebensqualität seit Jahren. Der Abschnitt develop (früher x-develop -- lass das Präfix x- weg, es ist nicht mehr experimentell) ermöglicht dir, Regeln zur Dateiüberwachung zu definieren, die automatisch synchronisieren oder neu bauen, wenn sich Dateien ändern:

services:
  web:
    build: .
    develop:
      watch:
        - path: ./src
          action: sync
          target: /app/src
        - path: ./package.json
          action: rebuild

Drei Aktionen sind verfügbar (seit v2.32.0):

sync -- kopiert geänderte Dateien in den Container, ohne neu zu bauen
restart -- startet den Service neu, wenn sich Dateien ändern
rebuild -- löst einen vollständigen Rebuild aus

Seit September 2025 gibt es außerdem initial_sync -- es synchronisiert alle Dateien sofort, wenn du docker compose watch startest, sodass du nicht auf die erste Änderung warten musst, um die Synchronisierung auszulösen. Das war lange ein Schmerzpunkt.

docker compose watch

Keine manuellen Rebuilds mehr während der Entwicklung. Das hat meinen Workflow wirklich verändert.

Include mit OCI-Artefakten

Die Direktive include kann jetzt Compose-Fragmente aus OCI-Registries ziehen:

include:
  - oci://docker.io/username/my-compose-fragment:latest

Es gibt außerdem experimentelle Unterstützung für Git-Repositorys. Das ist nützlich, um gemeinsame Service-Definitionen über Projekte hinweg zu teilen -- Datenbankkonfigurationen, Monitoring-Stacks usw.

Aber lies zuerst den Sicherheitsabschnitt unten. Es gibt eine CVE.

GPU-Unterstützung

GPU-Passthrough ist sauberer geworden. Es gibt jetzt neben dem ausführlichen Ansatz über deploy.resources.reservations.devices eine kürzere gpus:-Syntax (v2.30.0+). AMD-GPU-Unterstützung wurde 2025 offiziell integriert -- nicht mehr nur NVIDIA.

Models-Element

Die Compose-Spec enthält jetzt ein models-Element, um AI/ML-Modelle als OCI-Artefakte zu definieren. Du kannst LLMs und Inference-Runtimes direkt in deinem Compose-Setup paketieren. Nischig, aber interessant, wenn du lokal mit AI arbeitest.

Bessere Dependencies

Die depends_on-Bedingungen sind flexibler geworden:

services:
  web:
    depends_on:
      db:
        condition: service_healthy
        restart: true      # restart web if db restarts
        required: false     # web can start even if db isn't ready

Die Optionen restart: true und required: false sind wirklich nützlich für robuste lokale Entwicklungs-Setups.

Was du wissen solltest

CVE-2025-62725: Include Path Traversal

Wenn du die Direktive include mit OCI-Artefakten nutzt, aktualisiere sofort auf v2.40.2 oder neuer [2]. Eine Path-Traversal-Schwachstelle erlaubt es einem Angreifer, bei der Artefaktauflösung aus dem Cache-Verzeichnis auszubrechen. Sogar ein harmlos wirkendes docker compose ps kann sie auslösen, wenn deine Compose-Datei eine bösartige OCI-Referenz einbindet.

Docker hat das mit einer validatePathInBase()-Prüfung gepatcht, aber du musst auf der gefixten Version sein.

Compose v5

Docker ist von v2 auf v5 gesprungen (3 und 4 wurden übersprungen, um Verwirrung mit den alten Dateiformat-Versionen zu vermeiden) [3]. Funktional ist v5 dasselbe wie späte v2-Releases, aber es enthält ein offizielles Go SDK für programmatischen Zugriff -- du kannst Compose-Funktionalität also direkt in Go-Anwendungen einbetten, ohne zur CLI zu shellen.

Prüfe deine Version:

docker compose version
# Docker Compose version v5.1.0

Bake ist das Standard-Build-Tool

Docker Bake (über BuildKit) ist jetzt der Standard für docker compose build. Es beherrscht Multi-Target-Builds, Cross-Platform-Kompilierung und fortgeschrittene Caching-Strategien besser als der Legacy-Builder. Wenn du dir docker-bake.hcl-Dateien noch nicht angesehen hast, lohnt es sich, sie zu verstehen -- besonders bei komplexen Multi-Service-Builds.

Healthcheck-Verbesserungen

Mit dem Feld start_interval kannst du während der Startup-Grace-Period ein schnelleres Prüfintervall setzen:

services:
  db:
    healthcheck:
      test: ["CMD", "pg_isready"]
      start_period: 30s
      start_interval: 2s    # check every 2s during startup
      interval: 30s         # then every 30s after
      retries: 3

Das bedeutet, dass deine abhängigen Services schneller starten, ohne die Healthcheck-Intervalle in Produktion zu kompromittieren.

Migrations-Checkliste

Wenn du dein Compose-Setup länger nicht aktualisiert hast:

Entferne version: aus allen Compose-Dateien.
Ersetze docker-compose durch docker compose in allen Skripten und CI-Konfigurationen.
Benenne x-develop in Watch-Konfigurationen in develop um.
Aktualisiere auf v2.40.2+, wenn du include nutzt (CVE-2025-62725).
Ersetze links durch Docker-Netzwerke, falls du sie irgendwie noch nutzt.
Teste deine CI -- GitHub Actions hat die Runner im Februar 2026 auf Compose v2.40.3 aktualisiert [4].

Referenzen

1. Docker Compose v1 removed from runner images (April 2025) -- GitHub-Actions-Ankündigung zur Entfernung von v1.
2. CVE-2025-62725: From "docker compose ps" to System Compromise -- Impervas detaillierter Bericht zur Include-Path-Traversal-Schwachstelle.
3. Docker Compose Releases -- Offizielle Release-Historie inklusive v5.
4. Docker and Docker Compose version upgrades on hosted runners -- GitHubs Runner-Update vom Februar 2026.
5. Compose Specification -- Offizielle Compose-Dateireferenz.
6. Use Compose Watch -- Dockers Dokumentation zum Watch-Modus.
7. Enable GPU Support in Docker Compose -- GPU-Passthrough-Dokumentation inklusive AMD-Unterstützung.
8. Docker Compose Include -- Include-Direktive mit OCI- und Git-Unterstützung.

Nutze die Kraft von 'git grep' für effiziente Codesuche

Wed, 13 Nov 2024 00:00:00 GMT

In einem weiten Königreich voller zahlloser Schriftrollen und Manuskripte lebte ein Gelehrter namens Alaric. Seine Bibliothek war gewaltig - ein Labyrinth des Wissens, in dem alte Texte neben zeitgenössischen Schriften standen und Geheimnisse zwischen den Zeilen verborgen lagen. Alaric suchte oft nach einer einzigen schwer greifbaren Formulierung in diesem Meer aus Information, eine Aufgabe, die mit jedem Tag einschüchternder wurde.

Eines Morgens, als die Sonne goldene Strahlen auf die staubigen Folianten warf, machte Alaric sich daran, ein bestimmtes Konzept in seinen Archiven zu finden, das nur als "The Whispering Sigil" bekannt war. Er arbeitete sich durch Band um Band und nutzte seine üblichen Methoden, um die Seiten zu durchsieben - Methoden, die ihm inzwischen träge und ungenau vorkamen. Je tiefer er suchte, desto stärker verhedderte er sich in irrelevanten Passagen, Duplikaten und irreführenden Verweisen. Die Frustration wuchs, als aus Stunden Tage wurden und kaum Fortschritt zu sehen war.

Dann besuchte ein alter Weiser Alaric und bemerkte seine Not. Mit wissendem Lächeln sagte der Weise: "Vielleicht suchst du auf die mühsame Art. Es gibt einen verborgenen Pfad, den nur jene kennen, die ihr Wissen klug ordnen." Neugierig hörte Alaric zu, während der Weise ihm eine Methode erklärte, die seine Suche fokussierte, das Durcheinander durchtrennte und ihn direkt zu den Texten führte, die er suchte.

Mit diesem neuen Ansatz bewaffnet, versuchte Alaric es erneut. Diesmal verblasste der irrelevante Ballast. Der Weg zu "The Whispering Sigil" wurde klar, und er fand mit erstaunlicher Geschwindigkeit, wonach er gesucht hatte. Es war, als hätte er ein geheimes Tor in seinem Labyrinth aufgeschlossen, das ihm schnellen Zugriff auf genau das Wissen gab, das er brauchte.

Puff! Das Geheimnis war gelüftet: die Kraft von git grep.

Was `git grep` eigentlich ist

Plain grep -r läuft durch das Dateisystem. Es liest pflichtbewusst alles, was ihm in den Weg kommt: Quellcode, Logdateien, Build-Ausgaben, diese verirrte 4-MB-Dumpdatei, die dein Kollege vergessen hat zu löschen, den gesamten node_modules-Baum. git grep macht etwas Schmaleres: Es durchsucht die Dateien, die Git bereits kennt. Aus genau dieser einen Designentscheidung kommt der größte Teil seines Werts.

Worin `git grep` gut ist

Es durchsucht getrackte Dateien, nicht das Dateisystem. Git hält eine Liste jeder Datei, die du je gestaged oder committet hast - den Index. git grep liest aus dieser Liste. Ungetrackter Müll ist dort schlicht nicht vorhanden. Kein node_modules/, kein dist/, keine Coverage-Reports, keine zufällige Logdatei - weil Git nie von ihnen erfahren hat.
Es ist auf großen Repos schneller als grep -r. Die Dateiliste hat es bereits, also überspringt es den Lauf durchs Dateisystem. Es läuft mit mehreren Threads parallel. Der Gewinn ist real, aber keine Magie. git grep iteriert über dieselben Blobs wie grep, nur mit weniger Zeremonie. Es gibt keinen Content-Suchindex - der "Git index" ist eine Liste aus Dateipfaden und Blob-Hashes, kein invertierter Index im Lucene-Stil.
Es kann jede Ref ohne Checkout durchsuchen. Das ist das Killer-Feature. Ein Tag, ein Branch, ein Commit, ein Tree-Objekt - zeig mit git grep direkt darauf. Kein git checkout, kein Stash-Tanz, kein Umweg weg von dem, was du gerade getan hast.

Praktische Beispiele

Einfache Suche

Um in deinem Repository nach einem bestimmten Begriff wie "initializeSettings" zu suchen:

git grep "initializeSettings"

Das durchsucht alle getrackten Dateien im aktuellen Branch nach der exakten Übereinstimmung.

Suche ohne Beachtung der Groß-/Kleinschreibung

Für eine Suche ohne Beachtung der Groß-/Kleinschreibung, hilfreich, wenn du dir bei der Kapitalisierung unsicher bist:

git grep -i "initializesettings"

Das findet Treffer unabhängig von Unterschieden in der Groß-/Kleinschreibung.

Suche in einem bestimmten Branch

Um in einem anderen Branch zu suchen, ohne zu ihm zu wechseln, zum Beispiel in feature/login:

git grep "validateUser" feature/login

Das ist der Zug, der schwer zu schlagen ist. Kein Checkout, kein Stash, einfach die Antwort.

Suche über alle Branches hinweg

Um einen Begriff in jedem Branch zu suchen, einschließlich Remotes:

git branch -a | xargs -n 1 git grep "configureDatabase"

Um in jedem Commit zu suchen, von dem Git je gehört hat, nicht nur an der Spitze eines Branches:

git grep "configureDatabase" $(git rev-list --all)

Das findet Treffer in jedem Blob irgendwo in deiner History. In einem lebhaften Repo kann es einen Moment dauern - es läuft buchstäblich durch jeden Commit.

Suche in der Commit-History

Um herauszufinden, wann ein bestimmter String hinzugefügt oder entfernt wurde, nutze:

git log -S "optimizePerformance"

Das zeigt Commits, die den Begriff "optimizePerformance" eingeführt oder entfernt haben.

Um die tatsächlichen Diffs zu sehen, in denen der Begriff hinzugefügt oder entfernt wurde:

git log -G "optimizePerformance" -p

Reguläre Ausdrücke verwenden

git grep unterstützt reguläre Ausdrücke für fortgeschrittenere Suchen:

git grep -E "def\s+\w+\("

Das matcht Python-Funktionsdefinitionen: def, Whitespace, ein Funktionsname, dann eine literale öffnende Klammer. (In Extended Regex ist \( eine literale Klammer, während ( eine Gruppe bedeuten würde; deshalb steht der Backslash dort.)

Was `git grep` liest und was nicht

git grep läuft durch den Index. Das war's. Es parst .gitignore nicht. Viele Leute, einschließlich einer früheren Version dieses Posts, behaupten, es tue das - und die Behauptung ist fast wahr, ungefähr so, wie "die Erde ist flach" fast wahr ist, wenn man immer nur auf einen Parkplatz schaut.

Die beiden Dinge decken sich nur, weil gitignored Dateien normalerweise auch ungetrackt sind. In dem Moment, in dem eine Datei sowohl gitignored als auch getrackt ist - jemand hat git add -f ausgeführt, oder die Datei wurde committet, bevor die Regel existierte -, durchsucht git grep sie fröhlich. rg tut das nicht.

Du kannst das in zwanzig Sekunden beweisen:

mkdir demo && cd demo
git init -q
echo "*.log" > .gitignore
echo "the secret phrase" > tracked.log
git add -f tracked.log .gitignore
git commit -qm init

git grep "secret phrase"   # finds it - the file is tracked, ignore rule notwithstanding
rg "secret phrase"         # finds nothing - rg actually reads .gitignore

Die genaue Aussage lautet also: git grep durchsucht getrackte Dateien. Dadurch überspringt es zufällig das meiste von dem, was .gitignore ebenfalls überspringen würde, aber der Mechanismus ist ein anderer, und der Randfall ist wichtig - besonders dann, wenn du nach einem String suchst, der am Ende in einer generierten Datei lebt, die vor Jahren jemand mit Gewalt hinzugefügt hat.

Der .gitignore-Mechanismus kommt nur über zwei Opt-in-Modi in git grep hinein:

--untracked - auch ungetrackte Dateien durchsuchen. In diesem Modus respektiert git grep standardmäßig .gitignore und überspringt ignorierte Dateien (mit --no-exclude-standard kannst du das überschreiben und sie ebenfalls durchsuchen).
--no-index - das aktuelle Verzeichnis durchsuchen und Git vollständig ignorieren. Nützlich innerhalb eines Repos, wenn du plain-grep-Semantik willst. In diesem Modus konsultiert git grep .gitignore standardmäßig nicht - nutze --exclude-standard, wenn du das möchtest.

Standard-git grep, ohne Flags, öffnet deine .gitignore-Datei nie.

Wann du stattdessen zu `rg` greifen solltest

git grep und rg (ripgrep) sind eigentlich keine Konkurrenten. Sie laufen durch unterschiedliche Dinge, und eine ernsthafte Werkzeugkiste hat beide.

git grep läuft durch den Index: getrackte Dateien, plus jede Ref oder jedes Tree-Objekt, auf das du zeigst.
rg läuft durch das Dateisystem: jede Datei unter dem aktuellen Verzeichnis, abzüglich dessen, was deine .gitignore, .ignore, .rgignore und globalen Excludes ihm zu überspringen sagen.

Jedes der beiden kann etwas, was das andere nicht kann.

git grep gewinnt, wenn du über die History hinweg suchen willst, ohne einen Checkout zu machen:

git grep "deprecated_api" v2.3.0          # search a tag
git grep "deprecated_api" HEAD~50         # 50 commits ago
git grep "deprecated_api" $(git rev-list --all)   # every commit, ever

rg gewinnt, wenn du tatsächlich Dateisystem-Semantik mit korrekter gitignore-Behandlung willst - einschließlich eines frisch geklonten Unterordners, den du noch nicht mit git add aufgenommen hast, generierter Dateien, von denen Git nie gehört hat, oder eines Verzeichnisses, das gar kein Git-Repo ist:

rg "deprecated_api"                # respects .gitignore by default
rg --no-ignore "deprecated_api"    # opt back into ignored files
rg --hidden "deprecated_api"       # include dotfiles

rg ist auch die Engine hinter der Projektsuche von VS Code, weshalb sich "Find in Files" exakt so anfühlt wie rg im Terminal. Es hat solide Unicode-Unterstützung, und auf den meisten modernen Corpora ist es mindestens so schnell wie git grep, oft schneller - der Linux-Kernel-Benchmark im ripgrep README zeigt ripgrep bei derselben Query ungefähr 3x schneller als git grep -P. (Tipp: Wenn du das Verhalten "case-sensitive nur dann, wenn dein Pattern Großbuchstaben enthält" willst, übergib -S für smart-case - es ist Opt-in, nicht der Default.)

Falls du rg noch nicht installiert hast, behebe das:

brew install ripgrep   # macOS
apt install ripgrep    # Debian/Ubuntu
cargo install ripgrep  # anywhere with Rust

Leg rg neben git grep in deine Werkzeugkiste. Sie decken unterschiedliche Jobs ab.

Vorteile von `git grep`

Relevanz. Es durchsucht nur, was du trackst. Build-Ausgaben, Caches und node_modules stehen dir nicht im Weg - weil Git sie nie gesehen hat.
Geschwindigkeit auf großen Repos. Multithreaded, kein Dateisystemlauf.
History-Reichweite. Jeder Branch, Tag oder Commit, ohne deinen Working Tree zu verlassen. Das ist der Teil, den rg nicht kann.
Weniger Binärrauschen. Wie grep markiert git grep Binärdateien mit "Binary file X matches", statt Bytes auszuspucken - aber weil es durch getrackte Dateien läuft, begegnet es normalerweise von Anfang an weniger davon. Übergib -I, um Binärdateien vollständig zu überspringen.

Zusätzliche Tipps

Ergebnisse paginieren:
```
git grep "searchTerm" | less
```
Treffer pro Datei zählen:
```
git grep -c "searchTerm"
```
Zeilennummern anzeigen:
```
git grep -n "searchTerm"
```
Jeden Treffer im Editor öffnen:
```
git grep -l "searchTerm" | xargs code
```
Tausche code gegen nvim, subl oder was auch immer du benutzt.

Fazit

So wie Alaric in seiner labyrinthischen Bibliothek einen verborgenen Pfad fand, zieht git grep eine saubere Linie durch eine getrackte Codebase: schnell, branch-bewusst und frei von allem, wovon Git nie erfahren hat. Es ist kein universeller Ersatz für grep, und es ist kein Ersatz für rg. Es ist das Werkzeug, das den Index deines Repos kennt, und sobald du danach greifst, wird das Labyrinth deutlich kleiner.

Nutze git grep, wenn die Frage lautet: "wo in dieser Codebase, einschließlich ihrer History". Nutze rg, wenn die Frage lautet: "wo auf der Platte, unter Beachtung meiner Ignore-Regeln". An den meisten Tagen wirst du beide in Reichweite haben wollen.

Aktualisiert am 2026-04-27: korrigierte eine frühere Behauptung, dass git grep .gitignore respektiert (tut es nicht direkt), entschärfte die Erklärung zu "internem Indexing", korrigierte ein Regex-Beispiel und fügte einen Abschnitt dazu hinzu, wann stattdessen rg zu verwenden ist.

PHP 8.3.6 + IMAP auf macOS mit phpenv: Installationsanleitung

Sun, 01 Sep 2024 00:00:00 GMT

Wichtig (Update 2024-11): PHP 8.4 hat ext-imap aus dem Core ausgelagert. Die Extension ist zu PECL gewandert und praktisch deprecated -- die zugrunde liegende C-Bibliothek (libc-client) wurde seit 2018 nicht mehr aktualisiert. Wenn du ein neues Projekt startest oder auf PHP 8.4+ bist, spring zu Brauchst du ext-imap wirklich? für moderne Alternativen. Wenn du auf PHP 8.3 oder älter bist und die native Extension brauchst, funktioniert diese Anleitung weiterhin.

Der Quick Fix

Wenn du nur die Befehle willst und dir das Warum egal ist -- hier ist alles in der richtigen Reihenfolge. Homebrew und phpenv müssen bereits installiert sein.

# 1. Install all required libraries
brew install tidy-html5 openssl@3 zlib bzip2 libedit readline \
  gettext libiconv libsodium krb5 imap-uw curl

# 2. Set build configuration (add to ~/.zshrc or run before install)
export PHP_BUILD_CONFIGURE_OPTS="--with-openssl=$(brew --prefix openssl@3) \
  --with-zlib=$(brew --prefix zlib) \
  --with-bz2=$(brew --prefix bzip2) \
  --with-curl \
  --with-libedit \
  --with-readline=$(brew --prefix readline) \
  --with-gettext=$(brew --prefix gettext) \
  --with-iconv=$(brew --prefix libiconv) \
  --with-sodium=$(brew --prefix libsodium) \
  --with-kerberos=$(brew --prefix krb5) \
  --with-imap=$(brew --prefix imap-uw) \
  --with-imap-ssl=$(brew --prefix openssl@3) \
  --with-tidy=$(brew --prefix tidy-html5) \
  --enable-mbstring \
  --enable-intl"

# 3. Help the compiler find headers
export CPPFLAGS="-I$(brew --prefix openssl@3)/include -I$(brew --prefix imap-uw)/include $CPPFLAGS"

# 4. Build and install
phpenv install 8.3.6
phpenv global 8.3.6

# 5. Verify
php -v
php -m | grep imap

Wenn imap in der Ausgabe auftaucht, bist du fertig. Wenn nicht, lies weiter.

Brauchst du ext-imap wirklich?

Ernst gemeinte Frage. Bevor du dich mit C-Bibliotheken und Compiler-Flags herumschlagst, überleg kurz, ob du die native IMAP-Extension wirklich brauchst.

PHP 8.4 hat ext-imap aus dem Core entfernt. Sie ist zu PECL gewandert, und die zugrunde liegende C-Bibliothek (libc-client / UW-IMAP) hat seit 2018 kein Update gesehen. Sie hat Thread-Safety-Probleme, fehlenden XAUTH-Support und POP-Bugs. Sie kommt nicht zurück.

Die moderne Alternative ist Webklex/php-imap -- eine reine PHP-Implementierung von IMAP:

composer require webklex/php-imap

Das war's. Keine brew-Abhängigkeiten, keine Compiler-Flags, keine Jagd nach Header-Dateien. Es funktioniert mit PHP 8.0.2+ (einschließlich 8.4 und 8.5), unterstützt IMAP IDLE und OAuth und hat über 5 Millionen Installationen auf Packagist. Es gibt auch eine Laravel-Integration, falls das dein Stack ist.

Verwende ext-imap nur, wenn du eine Legacy-Codebasis auf PHP 8.3 oder älter wartest, die bereits von imap_*-Funktionen abhängt, und du noch nicht migrieren kannst.

Was jeder Schritt macht

Wenn der Quick Fix funktioniert hat, kannst du hier aufhören. Wenn nicht -- oder wenn du verstehen willst, was passiert -- hier ist die Aufschlüsselung.

Die Brew-Abhängigkeiten

brew install tidy-html5 openssl@3 zlib bzip2 libedit readline \
  gettext libiconv libsodium krb5 imap-uw curl

macOS bringt einige davon mit, aber phpenv braucht die Homebrew-Versionen mit ordentlichen Headern und pkg-config-Dateien. Entscheidend ist imap-uw -- das ist die UW-IMAP-Bibliothek, die libc-client bereitstellt.

PHP_BUILD_CONFIGURE_OPTS

phpenv verwendet unter der Haube php-build, das ./configure auf dem PHP-Quellcode ausführt. Die Variable PHP_BUILD_CONFIGURE_OPTS reicht Flags direkt an configure weiter. Jedes --with-*-Flag sagt PHP, wo es eine bestimmte Bibliothek findet.

Die wichtigsten für IMAP:

--with-imap=$(brew --prefix imap-uw) -- zeigt auf die IMAP-Bibliothek
--with-imap-ssl=$(brew --prefix openssl@3) -- aktiviert IMAP über SSL
--with-kerberos=$(brew --prefix krb5) -- für IMAP-Authentifizierung erforderlich

Der CPPFLAGS-Fix

export CPPFLAGS="-I$(brew --prefix openssl@3)/include -I$(brew --prefix imap-uw)/include $CPPFLAGS"

Selbst mit den configure-Flags findet der C-Präprozessor manchmal die Header-Dateien nicht. Das passiert, weil macOS Homebrew-Header nicht in den Standard-Suchpfad legt. Die zwei Header, die am häufigsten scheitern:

openssl/ssl.h -- von OpenSSL
imap/imap.h -- von imap-uw

Der PATH-Fix

Wenn php -v nach der Installation die falsche Version zeigt, sind phpenvs Shims nicht in deinem PATH (oder etwas anderes überdeckt sie). Füg das zu ~/.zshrc hinzu:

export PHPENV_ROOT="$HOME/.phpenv"
if [ -d "${PHPENV_ROOT}" ]; then
  export PATH="${PHPENV_ROOT}/shims:${PHPENV_ROOT}/bin:$PATH"
  eval "$(phpenv init -)"
fi

Dann source ~/.zshrc ausführen und es erneut versuchen.

Der utf8_mime2text-Fehler

Wenn du das hier siehst:

configure: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing.
This should not happen.

Deine imap-uw-Bibliothek ist veraltet oder kaputt. Beheb es mit:

brew upgrade imap-uw

Danach die Installation erneut ausführen.

Die Zukunft von PHP + IMAP

Die Zeichen stehen eindeutig. ext-imap ist deprecated, die zugrunde liegende C-Bibliothek ist verlassen, und PHP 8.4 hat sie bereits aus dem Core entfernt. Wenn du das liest, weil du IMAP in einem PHP-Projekt brauchst, fang an, deine Migration zu webklex/php-imap zu planen. Die native Extension lebt auf geborgter Zeit.

Für diejenigen unter uns, die Legacy-Codebasen warten -- diese Anleitung wird für PHP 8.3 und älter weiter funktionieren. Aber starte keine neuen Projekte mit ext-imap. Es gibt keinen Grund, mit der Kompilierung von C-Bibliotheken zu kämpfen, wenn eine reine PHP-Lösung existiert.

Referenzen

PHP 8.4: IMAP Extension Unbundled -- PHP.Watch-Dokumentation zur Entfernung von ext-imap.
Webklex/php-imap auf GitHub -- Reine PHP-IMAP-Implementierung (5M+ Packagist-Installationen).
PHP Manual: IMAP Extension -- Offizielle Dokumentation mit Deprecation-Hinweisen.
shivammathur/extensions: IMAP for PHP 8.3+ -- Homebrew-Tap für PHP-Extensions einschließlich IMAP.

Laravel Sail vs. Laradock: Vergleich für PHP-Docker-Devs

Thu, 08 Aug 2024 12:00:00 GMT

TL;DR: Für die meisten Laravel-Entwickler im Jahr 2026: Verwende Laravel Herd, wenn du null Reibung willst (nativ, kein Docker, in Sekunden eingerichtet). Verwende Sail, wenn dein Team identische Umgebungen braucht oder du von Diensten wie Redis/Meilisearch abhängst. Verwende Laradock, wenn du mit mehreren PHP-Frameworks arbeitest. Verwende ein eigenes Docker-Compose-Setup, wenn du aus den Abstraktionen herausgewachsen bist. Und wenn Performance alles ist, schau dir FrankenPHP + Octane an.

Ursprünglich im August 2024 veröffentlicht. Im März 2026 mit Laravel 12/Herd/FrankenPHP und dem aktuellen Stand des Ökosystems aktualisiert.

Früher lautete die Frage: "Sail oder Laradock?" Dieser Rahmen ist inzwischen zu eng. Die eigentliche Frage ist: Wie sollte ich meine Laravel-Entwicklungsumgebung im Jahr 2026 aufsetzen? Es gibt mehr Optionen als je zuvor, und die beste Wahl hängt davon ab, was du tatsächlich brauchst.

Ich habe die meisten davon benutzt. Aktuell nutze ich ein eigenes Docker-Compose-Setup, weil ich volle Kontrolle über meine Container will, ohne dass Abstraktionen verbergen, was passiert. Aber das ist meine Vorliebe, keine universelle Empfehlung. Gehen wir durch, was dir jede Option gibt.

Die Kandidaten

Laravel Herd

Herd ist die neueste Option und für viele Entwickler die richtige. Es ist eine native Anwendung (macOS und Windows - noch kein Linux), die dir PHP, Nginx, Node.js und Dnsmasq ohne Docker gibt. Die Pro-Version ergänzt MySQL, PostgreSQL, Redis und Debugging-Tools.

Das Killer-Feature: PHP-Versionen in Sekunden wechseln (7.4 bis 8.4), automatisches *.test-Domain-Routing und kein Docker-Overhead. Wenn du eine normale Laravel-App baust und keine exotischen Dienste brauchst, bringt Herd dich in unter einer Minute zum Coden.

Laravel Sail

Sail ist Laravels offizielle Docker-basierte Entwicklungsumgebung. Es legt eine sail-CLI über Docker Compose, die die üblichen Befehle abstrahiert (sail up, sail artisan, sail php).

Seit Laravel 12 wird Sail standardmäßig mit PHP 8.5 ausgeliefert, nutzt compose.yaml (den modernen Dateinamen, nicht docker-compose.yml) und bringt Swoole für Octane direkt mit. Außerdem unterstützt es Devcontainer-Generierung über --devcontainer für die Integration mit VS Code/GitHub Codespaces.

Standarddienste: PHP, MySQL, Redis, Meilisearch, Mailpit und Selenium.

Laradock

Laradock ist das Schweizer Taschenmesser. Es ist eine Open-Source-Docker-Umgebung, die jedes PHP-Projekt unterstützt - nicht nur Laravel. Sie bietet 70+ vorkonfigurierte Dienste und kann für den Produktionseinsatz konfiguriert werden.

Stand Dezember 2025 wird sie weiterhin aktiv gepflegt (aktuelle PHP-FPM- und Workspace-Image-Updates). Der Preis dafür ist Komplexität: Das Setup dauert länger, die Konfiguration erfordert das Bearbeiten mehrerer Dateien, und du brauchst echtes Docker-Wissen.

FrankenPHP + Octane

FrankenPHP ist ein moderner PHP-Anwendungsserver auf Basis von Caddy. Zusammen mit Laravel Octane erreicht er 4-6 ms Framework-Boot-Zeit pro Request - ein Entwickler berichtete, dass die Latenz durch den Wechsel in den Worker Mode von 7 Sekunden auf 66 ms fiel [1].

Laravel Cloud nutzt FrankenPHP in seiner Octane-Runtime in Produktion [2]. Das neueste Release (v1.11.2, Februar 2026) brachte durch Go 1.26 30% schnelleres CGO und 40% schnellere Garbage Collection.

Das ist keine Entwicklungsumgebung im traditionellen Sinn - es ist eine produktionsreife PHP-Runtime, die du auch in der Entwicklung nutzen kannst. Sail enthält eine Integration, um Octane mit FrankenPHP oder Swoole auszuführen.

Wann du was nutzen solltest

Hier ist meine ehrliche Einschätzung, basierend darauf, diese Werkzeuge tatsächlich benutzt zu haben:

Nutze Herd, wenn du allein oder in einem kleinen Team arbeitest, normale Laravel-Apps baust und null Zeit auf Infrastruktur verwenden willst. Es ist der schnellste Weg von "ich habe eine Idee" zu "ich schreibe Code". Die Einschränkung ist, dass es nur für macOS/Windows verfügbar ist und die kostenlose Version keine Datenbanken enthält.

Nutze Sail, wenn dein Team Umgebungsgleichheit braucht, du von bestimmten Dienstversionen abhängst (Redis 7, MySQL 8, PostgreSQL 15), oder du in einer CI/CD-Pipeline arbeitest, die Docker benötigt. Mit Sails sail:publish-Befehl kannst du das Docker-Setup anpassen, wenn du aus den Defaults herauswächst.

Nutze Laradock, wenn du über mehrere PHP-Frameworks hinweg arbeitest (Symfony, Shopware, Vanilla PHP), exotische Dienste brauchst (Aerospike, RethinkDB, Manticore), oder eine Docker-Umgebung für mehrere Projekte willst. Die Lernkurve ist steiler, aber die Flexibilität ist unerreicht.

Nutze ein eigenes Docker-Compose-Setup, wenn du sowohl aus Sail als auch aus Laradock herausgewachsen bist und volle Kontrolle willst. Das ist, was ich mache. Ich pflege mein eigenes compose.yaml mit exakt den Diensten, die ich brauche, ohne Abstraktionsschicht, und mit Docker-Compose-Aliases, damit die Befehle kurz bleiben. Es braucht am Anfang mehr Arbeit, aber es gibt keine Magie - alles ist explizit.

Nutze FrankenPHP + Octane, wenn du eine High-Performance-API baust oder deine Anwendung latenzsensibel ist. Der Performance-Unterschied ist nicht marginal - es ist eine Größenordnung. Einen Blick wert, selbst wenn du für die allgemeine Entwicklung ein anderes Werkzeug nutzt.

Die Details, die zählen

Setup-Zeit

Tool	Zeit bis zum ersten Request
Herd	Unter 1 Minute
Sail	5-10 Minuten (Image-Pulls)
Custom Compose	30-60 Minuten (initiales Setup)
Laradock	1-2 Stunden (vollständige Konfiguration)

Anpassbarkeit

Sail ist absichtlich begrenzt. Du bekommst die Dienste, die Laravel braucht, und nicht viel mehr. Du kannst anpassen, indem du sail:publish ausführst und die Dockerfiles bearbeitest, aber an diesem Punkt pflegst du ein eigenes Docker-Setup mit Sails Abstraktionen obendrauf - das Schlechteste aus beiden Welten.

Laradock gibt dir alles, verlangt aber, dass du verstehst, was du aktivierst. Einen Dienst einzuschalten bedeutet, .env und möglicherweise docker-compose.yml zu bearbeiten, und manche Dienste haben eigene Konfigurationsverzeichnisse.

Custom Compose gibt dir genau das, was du schreibst. Nicht mehr, nicht weniger.

Produktionsreife

Sail ist ausdrücklich nicht für Produktion gedacht. Laradock kann für Produktion konfiguriert werden, aber du musst wissen, was du bei Security Hardening, Resource Limits und sauberem Networking tust. FrankenPHP ist von Grund auf produktionsreif - dafür ist es gebaut.

Multi-Projekt-Unterstützung

Sail: ein Projekt pro Umgebung. Du kannst mehrere Sail-Instanzen laufen lassen, aber sie werden sich um Ports streiten.

Laradock: für Multi-Projekt-Setups entworfen. Eine Umgebung, mehrere Projekte, geteilte Dienste.

Custom Compose: was immer du architektierst. Ich halte separate Compose-Dateien pro Projekt mit gemeinsamen Netzwerkdefinitionen.

Was ich tatsächlich nutze

Custom Docker Compose. Ich habe Aliases für alles - dcu für docker compose up -d, dce für exec, dcefpm für PHP-FPM-Shell-Zugriff und eine sail-Funktion, die automatisch den Projekt-Root findet. Das Setup steht in meinen Notizen zur Docker-Compose-Entwicklung.

Ich habe vor Jahren mit Laradock angefangen, bin zu Sail gewechselt, als es erschien, und bin irgendwann bei einem eigenen Setup gelandet, weil ich genau verstehen wollte, was läuft und warum. Jede Abstraktion versteckt Entscheidungen. Manchmal ist das in Ordnung. Manchmal verursachen diese versteckten Entscheidungen Probleme, die schwer zu debuggen sind, weil du sie nicht sehen kannst.

Wenn ich heute allerdings ein neues Laravel-Projekt mit einem Team starten würde, dem Docker-Interna egal sind, würde ich Sail nehmen. Und wenn ich jemanden neu in Laravel begleiten würde, würde ich sagen: Installier Herd und fang sofort an, Code zu schreiben.

Andere Optionen, die erwähnenswert sind

DDEV - Docker-basiert, gute Laravel-Unterstützung, aktive Roadmap für 2026 mit geplanter Gitpod-Integration. Einen Blick wert, wenn du es für andere CMS-Projekte nutzt (WordPress, Drupal).
Lando - eine weitere Docker-Abstraktionsschicht mit Laravel-Plugin (v1.10.0, Januar 2026). Ähnliche Philosophie wie Sail, aber framework-agnostisch.
Valet - der Vorgänger von Herd. Funktioniert immer noch, aber Herd hat es für die meisten Anwendungsfälle abgelöst.

Referenzen

1. Laravel mit FrankenPHP Worker Mode einrichten und beschleunigen - Performance-Vergleich aus der Praxis: 7 s auf 66 ms Latenz.
2. Wie Laravel Cloud FrankenPHP in Produktion nutzt - DevConf-Talk über Laravel Clouds Octane-Runtime.
3. Laravel 12.x Sail-Dokumentation - Offizielle Sail-Dokumentation mit PHP 8.5 und compose.yaml-Änderungen.
4. Laravel Herd - Offizielle Website für die native Laravel-Entwicklungsumgebung.
5. FrankenPHP v1.11.2 Release - Release vom Februar 2026 mit Performance- und Sicherheitsupdates.
6. Laradock auf GitHub - Weiterhin gepflegt, Updates im Dezember 2025.
7. Der aktuelle Stand lokaler Laravel-Entwicklung - Andrew Schmelyuns Überblick über das Ökosystem.

Der schlimmste Heuchler: Die Geschichte einer Gummiente über Selbstliebe

Wed, 17 Jul 2024 12:00:00 GMT

Von Boris an eine geschätzte Freundin: ~ Die Person, die ich immer schwer verstehen konnte, und doch die verständnisvollste von allen. ~

Hey du. Hallo nochmal. Können wir uns wieder zum ersten Mal treffen? Ja. Ich glaube, diesmal wird es cooler. Ich werde kitschiger sein als je zuvor 🧀, versuchen, dich öfter zum Lachen zu bringen, aber manchmal trotzdem scheitern, oder meistens, oder wie auch immer... Es wird fast so sein wie beim letzten Mal, aber nicht wie beim letzten Mal. Hinweis: Du darfst so tun, als ergäbe mein letzter Satz Sinn, einfach um der Raffinesse willen 🥸

Lass mich mit einem kleinen Wörterbuch anfangen, oder einer Einleitung, oder einer kleinen Wissensdatenbank:

Ein "Anfang" rückwärts ist "gnafnA"

Ich brauchte nur einen neuen Titel, damit mein Absatz hübscher wird. Wie auch immer: Neues Ich. Neues Du. Alte Kleidung und ein paar alte schlechte Gewohnheiten. Puh!

Ein Spiegel an der Wand

Du hast mir sehr gefehlt, und ich habe lange über meine Fehler nachgedacht. Spiegel gibt es schließlich, damit wir hübscher und weniger schmutzig werden.

Eine Gummiente

Das bin ich. Ich bin eine Gummiente. Ich bin aus Gummi gemacht, und das bedeutet, dass auch mein Kopf aus Gummi gemacht ist.

Gummienten "quaken" nicht. Oder doch?

In meiner bescheidenen Lebenserfahrung als Gummiente "quake" ich durchaus, und ich tue es ziemlich oft. 😆

Eine quakende Gummiente quakt

Quak! Quak! Quak! - sagte die Ente und quakte wieder. Erstaunlicher Klang! Nicht wahr?

Eine Gummiente mit Haltung

Ich bin die freundlichste Gummiente von allen, sagte die Gummiente und quakte aufgeregt! Quak!

Der wahre Untergang der Gummienten

Quaken kann ziemlich erschöpfend sein, weißt du. Man kann mit einem frischen Atemzug nur eine begrenzte Anzahl von Malen schön quaken. Aber man kann trotzdem versuchen, schön zu quaken, wenn man leer ist? Richtig? Natürlich kann man das! Man kann versuchen zu quaken! Man kann sogar das beste schnelle Quak aus seinem Gummi geben, um den anderen leeren Gummienten zu helfen, einen Atemzug zu holen.

Eine kurze Geschichte für zwei halb leere Gummienten

"Weißt du was?" - sagte Duckitty "Was?" - sagte Duckelton "Wenn ich zu viel quake, kann ich nicht mehr quaken, und ich will quaken, und das macht mich traurig." - antwortete Duckitty Duckleton setzte einen sehr ernsten Blick auf, runzelte die Augenbrauen und sagte mit weiser Stimme: "Ja. Mir geht es genauso!"

Die Gummiente, die es hasste, still zu sein

Duckleton hasste es, still zu sein, und gab ein lautes Quaken von sich, wann immer er konnte. Manchmal war er ziemlich leer und fragte sich, ob er gelb genug war, um zu quaken. Aber weißt du, die Fabrik, die Ducleton und Duckitty gemacht hatte, hatte sie beide perfekt gelb gemacht. Duckleton war eine Gummiente mit Haltung. Er dachte, er könne und müsse jede andere Ente überquaken, um sie vor der Scham zu retten, nicht zu quaken, wenn sie leer waren. Duckitty hatte manchmal ähnliche Gedanken, oder zumindest dachte Duckleton so, wenn er bei klarem Verstand war. (Manchmal war er das nicht 😆) Aber Duckleton war eine stolze Gummiente. Eine Gummiente aus der besten Fabrik der Welt, die seit Jahrhunderten die besten quakenden gelben Gummienten herstellte. Zumindest dachte Duckleton so, bis er Duckitty traf. Als er sie traf, war er so erstaunt von ihrer Stimme, dass er dachte, sie müsse in irgendeiner außerirdischen Fabrik gemacht worden sein, viel besser als die Erdenfabrik, aus der er kam. Er war glücklich, die Chance zu haben, diese wunderbare und perfekte Gummiente namens Duckitty einfach zu bewundern, die viel besser war als er (dachte er). "Nun, es ist so schön, sie anzuschauen. Sie ist so gelb. Sie ist so nett. Sie hat eine viel hübschere Stimme als ich. Ich bin eine glückliche Gummiente." - dachte Duckleton.

Eine kurze, aber ein bisschen traurige Geschichte

Duckleton und Duckitty waren beide glücklich und quakten, als wäre es der beste Quak-Wettbewerb der Welt und des Weltalls. Einmal kam ein Menschenkind und drückte Duckleton zusammen. Er konnte eine Zeit lang nicht quaken, wollte es aber immer noch unbedingt, also blieb er still, ohne sich zu beschweren, holte tief Luft, und beide quakten glücklich weiter. Einige Zeit verging, und Duckitty wurde ebenfalls von einem fiesen Menschenkind genommen. Das Menschenkind drückte die ganze Luft aus Duckitty heraus, aber Duckleton war zu sehr mit Quaken beschäftigt, um es zu bemerken. Duckitty war in Ordnung, aber sie musste etwas Luft holen. Duckleton war traurig bis über jede Verzweiflung hinaus. Er dachte, seine Lieblingsente sei kaputt und er sei wieder für immer allein bis ans Ende des Universums. Er hatte nur vergessen, dass dasselbe Kind ihn vor einiger Zeit zusammengedrückt hatte. Duckleton war stolz, aber dumm; schließlich hatte er einen kleinen Gummikopf. Als Duckitty quakte, war Duckleton wütend. Er war zugleich froh, dass sie lebte, aber auch ein bisschen entmutigt, weil er dachte, Duckitty könne das Zusammendrücken durch ein Menschenkind besser überstehen als er. Sie war doch so viel perfekter als er, oder?

Duckletons Schuldreise

Duckleton war der schlimmste Heuchler von allen, und er lernte es endlich. Er war traurig, aber er dachte: Lass uns bei Duckitty entschuldigen und ihr etwas Dankbarkeit dafür zeigen, dass sie so perfekt ist, wie sie ist.

Epilog

Meine liebe Freundin, du warst in den letzten 8 Jahren perfekt. Du warst jeden einzelnen Tag perfekt. Es tut mir wirklich leid, dass ich so ein Heuchler war, aber schlimme Dinge passieren nun mal, weißt du. Und wir machen trotzdem weiter. Bitte liebe dich selbst viel mehr. Ich bin dumm. Du bist klug. Oder wie auch immer... Aber liebe dich selbst viel mehr, denn du bist perfekt, so wie du bist! Tatsächlich bist du die perfekteste gelbe Gummiente der Welt. Zumindest denke ich das. Mein Gummikopf ist klein. Aber yay! Ich kann trotzdem denken. 🫶 Quak!

Quak, Quak, Quak ~ Duckleton

Diskrete Repräsentationen in RL: Forschungseinblicke von Edan Meyer

Mon, 15 Jul 2024 00:00:00 GMT

Hast du dich je gefragt, wie KI-Agenten lernen, komplexe Umgebungen zu verstehen und mit ihnen zu interagieren? Edan Meyer, ein Forscher im Bereich Reinforcement Learning (RL), untersucht einen spannenden Ansatz, der durchaus verändern könnte, wie wir über KI-Lernen nachdenken. Tauchen wir ein in seine faszinierende Arbeit zu diskreten Repräsentationen in RL.

Die Macht der Repräsentation

Stell dir vor, du willst einem Computer beibringen, ein Videospiel zu spielen. Wie würdest du den Zustand des Spiels so darstellen, dass der Computer ihn verstehen und daraus lernen kann? Genau hier kommt Representation Learning ins Spiel, und es ist ein entscheidender Bestandteil beim Bau wirksamer KI-Agenten.

Edan Meyer, dessen Arbeit du auf seinem YouTube-Kanal verfolgen kannst, beschäftigt sich mit einer bestimmten Art von Repräsentation: diskreten Repräsentationen. Seine Forschung, beschrieben in einem Paper auf arXiv, zeigt, warum solche Repräsentationen in bestimmten RL-Szenarien besonders nützlich sein können.

Zwei Jahre Forschung in 13 Minuten

Edan hat zwei Jahre seiner Masterforschung in ein zugängliches 13-minütiges Video mit dem Titel "2 Years of My Research Explained in 13 Minutes" verdichtet. Darin zerlegt er komplexe Konzepte in verständliche Erklärungen und macht seine Arbeit so einem breiteren Publikum zugänglich.

Wie Edan in der Videobeschreibung schreibt:

"This is my research into representation learning and model learning in the reinforcement learning setting. Two years in the making, and I finally get to talk about my Master's research! The paper has been accepted to the Reinforcement Learning Conference (RLC) 2024."

Dieses Video ist ein guter Einstieg für alle, die die Grundlagen seiner Forschung verstehen möchten, ohne direkt in das vollständige akademische Paper einzutauchen.

Was sind diskrete Repräsentationen?

Traditionell verwenden viele RL-Systeme kontinuierliche Repräsentationen. Man kann sie sich als Vektoren aus Dezimalzahlen vorstellen, die jeden möglichen Wert annehmen können. Diskrete Repräsentationen dagegen ähneln eher einer Reihe von Multiple-Choice-Fragen. Jeder "Slot" in der Repräsentation kann nur einen Wert aus einer festen Menge von Möglichkeiten annehmen.

Wie Edan in seinem Video erklärt, wirkt das zunächst vielleicht einschränkend. Schließlich kann ein kontinuierlicher Wert unendlich viele Zustände darstellen, während ein diskreter Wert deutlich stärker begrenzt ist. Warum also überhaupt diskrete Repräsentationen verwenden?

Die überraschenden Vorteile

Edans Forschung hat einige faszinierende Vorteile diskreter Repräsentationen sichtbar gemacht:

Bessere Weltmodelle mit weniger Kapazität: Wenn eine KI versucht, ein Modell ihrer Umgebung zu lernen, ein sogenanntes "world model", erlauben diskrete Repräsentationen ihr, mit weniger Rechenleistung genauere Informationen zu erfassen. Das gilt besonders dann, wenn das Modell nicht genug Kapazität hat, um alles an der Umgebung perfekt abzubilden, ein häufiges Szenario bei komplexen Problemen in der realen Welt.
Schnellere Anpassung: In Experimenten, in denen sich die Umgebung im Laufe der Zeit veränderte, konnten Agenten mit diskreten Repräsentationen sich schneller an diese Veränderungen anpassen. Das könnte entscheidend für KI-Systeme sein, die in dynamischen, unvorhersehbaren Umgebungen funktionieren müssen.
Effizientes Lernen: Diskrete Repräsentationen brauchen anfangs möglicherweise länger, bis sie gelernt sind. Sobald sie aber etabliert sind, ermöglichen sie schnelleres Lernen und schnellere Anpassung, sowohl beim Lernen von Weltmodellen als auch bei Policy-Learning-Aufgaben.

Warum ist das wichtig?

Die Auswirkungen von Edans Arbeit reichen weit über einfache Grid-World-Experimente hinaus. Wie er in seinem Video betont, ist die reale Welt ungleich komplexer als jede Simulation, die wir bauen können. In solchen Umgebungen ist es für eine KI unmöglich, alles zu lernen. Der Schlüssel liegt in Anpassung.

Diskrete Repräsentationen scheinen ein starkes Werkzeug zu sein, um KI-Systeme zu bauen, die sich schnell auf neue Situationen einstellen können, selbst wenn sie unmöglich jeden Aspekt ihrer Umgebung modellieren können. Das könnte für Anwendungen von Robotik über komplexe Strategiespiele bis weit darüber hinaus ein Wendepunkt sein.

Tiefer eintauchen

Für alle, die sich für die technischen Details interessieren, untersucht Edans Paper faszinierende Aspekte davon, warum diskrete Repräsentationen so gut funktionieren. Er fand zum Beispiel heraus, dass nicht alle diskreten Repräsentationen gleich sind. Faktoren wie Sparsity und Binarität spielen eine wichtige Rolle für ihre Wirksamkeit.

Fazit

Edan Meyers Arbeit zu diskreten Repräsentationen im Reinforcement Learning bietet spannende Einblicke darin, wie wir anpassungsfähigere und effizientere KI-Systeme entwickeln könnten. Indem seine Forschung gängige Annahmen darüber infrage stellt, wie Informationen für KI repräsentiert werden sollten, eröffnet sie neue Möglichkeiten für Agenten, die in komplexen, dynamischen Umgebungen bestehen können.

Ob du KI-Forscher bist, Machine Learning studierst oder dich einfach für die Grenzen der Technologie interessierst: Edans Arbeit bietet einen überzeugenden Blick auf die Zukunft künstlicher Intelligenz. Schau dir unbedingt seinen YouTube-Kanal, sein erklärendes Video und sein Paper an, wenn du diese Ideen gründlicher erkunden möchtest.

Denk daran: In der schnelllebigen Welt der KI-Forschung können die experimentellen Techniken von heute die Durchbruchstechnologien von morgen sein. Diskrete Repräsentationen könnten schon bald der Schlüssel sein, um leistungsfähigere und anpassungsfähigere KI-Systeme möglich zu machen.

Googles KI-Geschichte: Versprechen, Aktienentwicklung und Wirkung

Sat, 11 May 2024 12:00:00 GMT

Googles Weg durch die Entwicklung und Vermarktung von KI-Technologien wie der Gemini-Serie ist eine aufschlussreiche Fallstudie über das Zusammenspiel von Unternehmensversprechen, Börsenentwicklung und technologischer Innovation. Diese Analyse betrachtet konkrete historische Momente, in denen Googles KI-Versprechen die Aktienkurse des Unternehmens spürbar beeinflusst haben, und ordnet zugleich Erfolge und Rückschläge ein.

Der Vorstoß des Technologiekonzerns in die KI war von ehrgeizigen Projekten und selbstbewussten Aussagen geprägt. Von der Einführung von TensorFlow im Jahr 2015, die Google als führendes Unternehmen in KI-Forschung und -Entwicklung etablierte, bis zum Start von Google Assistant im Jahr 2016, der die Wettbewerbsfähigkeit gegenüber Rivalen wie Amazons Alexa und Apples Siri stärkte, hat Google immer wieder versucht, die Grenzen dessen zu verschieben, was KI leisten kann [1].

Zentrale historische Meilensteine in Googles KI-Entwicklung

Einführung von TensorFlow (2015): Google veröffentlichte TensorFlow, sein Framework für maschinelles Lernen, als Open Source. Es wurde schnell sehr populär. Dieser Schritt half, Google als führendes Unternehmen in KI-Forschung und -Entwicklung zu positionieren, und wirkte sich positiv auf die Marktwahrnehmung aus [1]. TensorFlow wurde in unterschiedlichsten Anwendungen eingesetzt, von der Verbesserung von Suchergebnissen bis zum Betrieb selbstfahrender Autos.
Start von Google Assistant (2016): Die Einführung von Google Assistant stärkte Googles Wettbewerbsfähigkeit in der KI gegenüber Konkurrenten wie Amazons Alexa und Apples Siri. Der Markt nahm dies positiv auf, weil es Wachstumspotenzial bei KI-gestützten Benutzeroberflächen zeigte [2]. Google Assistant wurde in Smartphones, Smart-Home-Geräte und Autos integriert und wurde damit zu einem wichtigen Akteur im Markt für Sprachassistenten.
Fortschritte im Quantencomputing (2019): Google verkündete einen Durchbruch bei der Quantenüberlegenheit und behauptete, der eigene Quantencomputer könne Berechnungen ausführen, die außerhalb der Möglichkeiten klassischer Supercomputer liegen. Diese Ankündigung führte zu einem kurzen Anstieg des Aktienkurses und zeigte die Begeisterung der Investoren für Googles technologische Spitzenfähigkeiten [3].

Aktienmarktentwicklung und KI-Meilensteine

Der Aktienmarkt hat unterschiedlich auf Googles KI-Entwicklungen reagiert. Bedeutende Ankündigungen, etwa Durchbrüche im Quantencomputing oder neue KI-Produkte, führen typischerweise zu kurzfristigen Kursanstiegen. Langfristig hing die Wirkung auf den Aktienkurs jedoch enger damit zusammen, ob diese Technologien tatsächlich eingesetzt wurden und kommerziell erfolgreich waren.

Meilensteine des S&P 500: Googles große KI-Ankündigungen fielen oft mit breiteren Markttrends zusammen. So erreichte Google im breiten Bullenmarkt des Jahres 2021 neue Aktienkurshöchststände, begleitet von erheblichen Fortschritten im Bereich KI. Das spiegelte ein starkes Anlegervertrauen in technologiegetriebenes Wachstum wider [4].

Abb. 1 - Google-Aktienmeilensteine.

Erfolge und Rückschläge

Erfolge: Googles KI hat in Bereichen wie Sprachübersetzung, Bilderkennung und autonomem Fahren durch Waymo beträchtliche Erfolge erzielt. Diese Erfolge haben dazu beigetragen, Googles Ruf als technologischer Innovator zu festigen [5].
Rückschläge: Nicht alle KI-Initiativen von Google erfüllten die Erwartungen des Marktes. Das mit großen Hoffnungen verbundene Projekt Google Glass fand beispielsweise keinen wirklichen Anklang bei Verbrauchern und wurde eingestellt. Das Produkt stieß auf Datenschutzbedenken und lieferte für durchschnittliche Nutzer keinen überzeugenden Anwendungsfall. Ähnlich haben die Verzögerungen und zu großen Versprechen rund um Gemini 1.5 Pro zu Unzufriedenheit und Skepsis bei Nutzern geführt [6]. Google hat aus diesen Rückschlägen gelernt, konzentriert sich stärker auf pragmatische KI-Anwendungen und verbessert die Kommunikation mit den Nutzern.

Abb. 2 - KI-Meilensteine von Technologieunternehmen.

Marktwirkung und künftiger Ausblick

Die Marktwirkung von Googles KI war erheblich. Sie beeinflusste nicht nur die eigenen Aktienkurse, sondern auch die Richtung der gesamten Technologiebranche. Der KI-Sektor bleibt ein zentrales Thema für Investoren, wie sich auch an der Entwicklung des S&P 500 zeigt, in dem Technologiewerte eine große Rolle spielen [4].

Mit Blick nach vorn wird entscheidend sein, ob Google seine KI-Versprechen einlösen und die Herausforderungen der technologischen Einführung meistern kann. Die Strategie des Unternehmens, Transparenz zu erhöhen und Verbrauchererwartungen wirksamer zu steuern, könnte über seine künftige Marktposition und das Vertrauen der Investoren entscheiden.

Ein besonders wichtiger Bereich ist Googles Fortschritt mit der Gemini-Serie von KI-Modellen. Gemini 1.5 Pro, im Februar 2024 angekündigt, verspricht einen deutlichen Sprung bei den KI-Fähigkeiten, hatte beim Rollout aber mit Schwierigkeiten zu kämpfen [6]. Wie Google diese Herausforderungen bewältigt und seine Versprechen einlöst, dürfte deutliche Auswirkungen auf den KI-Ruf und die Marktstellung des Unternehmens haben.

Googles ehrgeizige Fortschritte in der künstlichen Intelligenz, besonders durch die Gemini-Serie, stehen für eine transformative Phase der KI-Technologie. Die Einführung von Gemini 1.5 Pro als Teil dieser Serie unterstreicht Googles Anspruch, die Grenzen von KI-Fähigkeiten weiter auszudehnen. Der Rollout von Gemini 1.5 Pro war jedoch nicht frei von Problemen, und gerade diese sind wichtig, um sowohl das Potenzial als auch die Grenzen solcher fortgeschrittenen KI-Modelle zu verstehen.

Expertenmeinungen zu Gemini 1.5 Pro

Leistung und Fähigkeiten: Gemini 1.5 Pro basiert auf einer Mixture-of-Experts-Architektur (MoE) und bietet deutliche Verbesserungen gegenüber früheren Modellen, darunter eine massive Vergrößerung des Kontextfensters auf bis zu 10 Millionen Tokens. Diese Verbesserung ermöglicht eine bessere Bearbeitung komplexer Aufgaben mit großen Datenmengen über verschiedene Formate hinweg - Text, Code, Bild und Audio [7]. Stephen Oladele von Encord zufolge behält "Gemini 1.5 Pro über den gesamten Kontext hinweg eine nahezu perfekte Erinnerung bei und nutzt eine Mixture-of-Experts-Architektur für effizienteres Training und hochwertigere Antworten" [7].

Herausforderungen beim Rollout: Trotz seiner fortgeschrittenen Fähigkeiten war der Rollout von Gemini 1.5 Pro mit mehreren Herausforderungen verbunden. Das Modell befindet sich derzeit in einer privaten Vorschauphase, und die allgemeine Verfügbarkeit ist für später vorgesehen, was auf einen phasenweisen Einführungsansatz hindeutet [7]. Diese vorsichtige Rollout-Strategie könnte darauf zurückgehen, dass das Modell weiter feinabgestimmt werden muss und die hohen Erwartungen seiner Vorgänger sowie des Marktes erfüllen soll.

Sichtweisen von Branchenanalysten

Auswirkungen auf die KI-Branche: Branchenanalysten sehen die Gemini-Serie als bedeutenden Schritt nach vorn für Google, der möglicherweise neue Maßstäbe dafür setzt, was KI-Modelle leisten können. Die Gemini-Serie, insbesondere 1.5 Pro, dürfte Googles Wettbewerbsfähigkeit gegenüber anderen Technologiekonzernen wie OpenAI und Microsoft stärken, die ihre eigenen KI-Fähigkeiten ebenfalls aggressiv ausbauen [8] [7].

Marktimplikationen: Die Fortschritte in Gemini 1.5 Pro dürften verschiedene Sektoren beeinflussen, darunter Gesundheitswesen, Finanzwesen und weitere Bereiche, weil sie anspruchsvollere KI-Anwendungen ermöglichen. Dies könnte zu Verschiebungen in der Marktdynamik führen: Unternehmen, die solche fortgeschrittenen KI-Technologien effektiv integrieren, können einen deutlichen Wettbewerbsvorteil gewinnen [7].

Einblicke von Google-Führungskräften

Zukunftspläne und ethische Überlegungen: Führungskräfte von Google, darunter Sundar Pichai, haben das Bekenntnis des Unternehmens zu verantwortungsvoller KI-Entwicklung betont. Pichai hat hervorgehoben, wie wichtig es ist, KI-Fortschritte an ethischen Leitlinien auszurichten und sicherzustellen, dass diese Technologien zum gesellschaftlichen Nutzen eingesetzt werden [2] [9]. Dieser Ansatz ist entscheidend, da KI immer leistungsfähiger wird und zunehmend in alltägliche Anwendungen einzieht.

Herausforderungen und Chancen navigieren

Technische Herausforderungen angehen: Um die kommenden Herausforderungen zu meistern, muss Google weiterhin in Forschung und Entwicklung investieren und Themen wie Modellzuverlässigkeit und ethische Fragen adressieren. Der Ansatz des Unternehmens, Gemini 1.5 Pro schrittweise einzuführen, deutet auf eine Strategie hin, die Risiken mindern soll, bevor sie zu erheblichen Problemen werden [7].

Marktchancen ausweiten: Google kann die Fähigkeiten von Gemini 1.5 Pro nutzen, um neue Marktchancen zu schaffen, besonders in Sektoren, die große Datensätze und komplexe Problemlösungsszenarien verarbeiten müssen. Indem Google Werkzeuge bereitstellt, die die Integration von KI in Geschäftsprozesse vereinfachen, kann das Unternehmen Branchen dabei helfen, ihre Abläufe zu transformieren und effizienter zu werden [10].

Ethische KI-Entwicklung: Je mächtiger KI-Technologien werden, desto bedeutsamer werden ihre ethischen Implikationen. Googles fortgesetztes Bekenntnis zu verantwortungsvoller KI-Entwicklung, wie es sich in den KI-Prinzipien und Governance-Rahmenwerken des Unternehmens zeigt, wird entscheidend sein, um öffentliches Vertrauen und regulatorische Konformität zu erhalten [11].

Zusammenfassend lässt sich sagen: Der Rollout von Gemini 1.5 Pro bringt zwar Herausforderungen mit sich, eröffnet Google aber auch erhebliche Chancen, im KI-Bereich eine führende Rolle einzunehmen. Wenn das Unternehmen weiterhin auf Leistungsverbesserungen, ethische KI-Entwicklung und Marktausweitung setzt, kann es diese Herausforderungen wirksam bewältigen und neue Standards dafür setzen, was KI in verschiedenen Branchen leisten kann.

Fazit

Googles KI-Reise veranschaulicht die komplexe Dynamik von technologischer Innovation, Markterwartungen und Unternehmensstrategie. Obwohl das Unternehmen sowohl bemerkenswerte Erfolge als auch Rückschläge erlebt hat, ziehen seine laufenden KI-Bemühungen weiterhin erhebliche Aufmerksamkeit am Markt auf sich. Investoren und Marktbeobachter dürften genau verfolgen, ob Google seine KI-Fähigkeiten in nachhaltiges Wachstum und Marktführerschaft übersetzen kann.

Da sich die KI-Landschaft weiter rasant entwickelt, wird Googles Stellung als KI-Pionier auf die Probe gestellt. Die Fähigkeit des Unternehmens, ehrgeizige Innovation mit realistischer Umsetzung, transparenter Kommunikation und wirksamem Erwartungsmanagement auszubalancieren, wird ein entscheidender Faktor für den langfristigen Erfolg im KI-Bereich und für die gesamte Marktentwicklung sein.

Referenzen

1. Emeritus - Google AI Strategy
2. Google Blog - Gemini AI
3. Yahoo Finance - GOOGL Quote
4. Wikipedia - S&P 500 Milestones
5. Think with Google - AI Tools
6. Times of India - Gemini 15 Pro AI Release
7. Encord - Google Gemini 1.5 Generative AI Model with Mixture of Experts
8. Built In - Google Gemini
9. CBS News - Google's AI Future
10. Google Cloud - Generative AI
11. Google Blog - Responsible AI

Stable-Diffusion-Fotorealismus: Leitfaden zu Einstellungen und GPU-Grenzen

Thu, 04 May 2023 23:45:00 GMT

Aktualisiert im März 2026. Dieser Artikel wurde ursprünglich im Mai 2023 geschrieben, als SD 1.5 mit 512x512 der Standard war und die RTX 3090 die Spitzenhardware. Alles hat sich verändert. Flux 2, SDXL-Fine-Tunes, SD 3.5, ControlNet und die RTX 5090 haben völlig neu definiert, was möglich ist. Das hier ist der aktuelle Stand.

Die Lücke zwischen KI-generierten Bildern und echten Fotografien ist fast geschlossen. 2023 bedeutete "fotorealistisch": "fast überzeugend, wenn man die Augen zusammenkneift." 2026 erzeugen die besten Modelle Bilder, die tatsächlich schwer von professioneller Fotografie zu unterscheiden sind.

So kommt man dorthin.

Die aktuelle Landschaft des Fotorealismus

Das Modell, das du auswählst, ist wichtiger als jede Einstellung, an der du drehst. So sieht der Stand aus:

Flux 2 -- Der neue König

Flux 2 von Black Forest Labs (veröffentlicht im November 2025) ist 2026 wohl das beste Open-Weight-Modell für Fotorealismus [1]. Es erzeugt Bilder mit natürlichem Licht, präzisen Hauttexturen und kohärenter Komposition, die mit professioneller Fotografie mithalten kann. Adobe hat Flux (Kontext Pro) im September 2025 in Photoshop integriert [2] -- das sagt einiges darüber, wo das Vertrauen der Branche liegt.

Flux versteht außerdem natürliche Sprache außergewöhnlich gut. Du kannst in schlichtem Englisch beschreiben, was du willst, ohne die Keyword-Suppe, die SD 1.5 verlangt hat.

SDXL-Fine-Tunes -- Die Arbeitstiere

Für SDXL-basierten Fotorealismus sind das die aktuellen Spitzenreiter:

Juggernaut XL v9/v10 -- die Standardwahl für cineastische, fotografische Ergebnisse. Besonders beliebt bei Fotografen und Filmemachern.
Realistic Vision -- speziell für lebensechte Texturen, Beleuchtung und Gesichtsgenauigkeit fine-getuned.
EpicRealism -- außergewöhnlich starke feine Details und natürliches Licht.

Diese Modelle haben enorme Community-Unterstützung, umfangreiche LoRA-Bibliotheken und vorhersehbares Verhalten. Wenn Flux sich noch zu neu anfühlt oder dein Workflow auf SDXL aufgebaut ist, sind sie ausgezeichnete Optionen.

SD 3.5 Large

Das Flaggschiff von Stability AI nutzt die neue Multimodal Diffusion Transformer (MMDiT)-Architektur -- ein grundlegend anderer Ansatz als SDXL. Es ist technisch beeindruckend, aber das Ökosystem ist kleiner. SD 3.0 wurde im April 2025 eingestellt, also stell sicher, dass du auf 3.5 bist [3].

GPU-Realitätscheck

Die Hardware-Anforderungen sind deutlich gestiegen.

GPU	VRAM	Fotorealismus-Fähigkeit
RTX 3060 12GB	12GB	Nur SD 1.5-Fotorealismus. SDXL ist knapp
RTX 4070 Ti	12GB	SDXL bei 1024x1024. Flux ist mit Optimierungen möglich
RTX 4090	24GB	Der Sweet Spot. Bewältigt SDXL, Flux und SD 3.5 komfortabel bei 1024x1024+
RTX 5090	32GB	Alles, inklusive 4K-Generierung und Batch-Workflows. 32GB GDDR7, 512-bit Bus [4]
8GB-Karten	8GB	Mit ComfyUIs VRAM-Management minimal brauchbar. Nicht angenehm

Der Sweet Spot von 2023, "512x512 auf einer RTX 3080", ist alte Geschichte. 1024x1024 ist jetzt die Standardauflösung, und du willst mindestens 16GB VRAM, um ohne ständige Frustration zu arbeiten. Bei 24GB wird es komfortabel.

Speziell für Fotorealismus bedeutet mehr VRAM, dass du größere Modelle, höhere Auflösungen und ControlNet gleichzeitig ausführen kannst, ohne auf die CPU auszulagern.

Einstellungen für Fotorealismus

Sampler

DPM++ 2M Karras mit 25-30 Steps. Das ist der gefestigte Konsens für SDXL-Fotorealismus -- das beste Verhältnis von Geschwindigkeit zu Qualität. Wenn du bei niedrigen Step-Zahlen etwas mehr Detail möchtest, wechsle zu DPM++ SDE Karras.

Für Flux: nutze den Standard-Sampler mit 20-30 Steps.

CFG

Für SDXL-Fotorealismus: 7-9. Das gibt starke Prompt-Treue ohne den übersättigten, überkochten Look, der oberhalb von 10 entsteht.

Für SD 3.5: niedriger anfangen (3-5) -- der Guidance-Mechanismus funktioniert anders.

Für Flux: modell-spezifischen Empfehlungen folgen, aber im Allgemeinen niedriger als bei SDXL.

Auflösung

Generiere in der nativen Auflösung des Modells (1024x1024 für SDXL/SD 3.5/Flux), dann upscale für höhere Auflösung. Versuch nicht, direkt bei 2048x2048 zu generieren -- du bekommst Artefakte, duplizierte Elemente und Kompositionsprobleme.

Upscaling-Optionen: Hi-res fix in A1111 oder dedizierte Upscaling-Nodes in ComfyUI (4x-UltraSharp, ESRGAN).

Prompting für Fotorealismus

Die größte Verschiebung seit 2023: natürlich schreiben, nicht in Keywords.

SD 1.5 brauchte Prompts wie:

portrait of a woman, photorealistic, 8k, ultra detailed, sharp focus,
professional photography, Fujifilm X-T4, 85mm f/1.4

SDXL und Flux verstehen:

A portrait of a woman in soft afternoon light, photographed with a shallow
depth of field. She's looking slightly off-camera with a natural expression.

Der Keyword-Suppe-Ansatz funktioniert bei SDXL weiterhin, aber natürliche Sprache erzeugt kohärentere Ergebnisse. Besonders Flux glänzt bei beschreibenden, konversationellen Prompts.

Negative Prompts: Halte sie minimal. Fang ohne an und füge dann gezielte Korrekturen hinzu. "cartoon, illustration, painting" reicht meistens, um die Dinge fotorealistisch zu halten. Sieh dir das Cheat Sheet für den vollständigen Philosophiewechsel bei Negative Prompts an.

ControlNet verändert alles

Wenn du es mit fotorealistischer Komposition ernst meinst, ist ControlNet nicht verhandelbar. Es lässt dich die Struktur deines Bildes steuern über:

Depth maps -- räumliche Beziehungen und Perspektive erhalten
Canny edge detection -- Umrisse und Formen bewahren
OpenPose -- menschliche Posen und Körperproportionen steuern
Surface normals -- realistische Lichtinteraktion mit Oberflächen

ControlNet-Modelle sind inzwischen für SDXL, Flux und SD 3.5 verfügbar [5]. Multi-ControlNet (das Stapeln mehrerer Controls) gibt dir präzise Kompositionskontrolle, die Prompt Engineering allein nicht erreichen kann.

Der Workflow: Nimm ein Referenzfoto, extrahiere eine Depth Map oder Pose, nutze sie als ControlNet-Input und generiere ein fotorealistisches Bild mit derselben Komposition.

Geschwindigkeit vs. Qualität

Wenn du schnelle Iterationen brauchst (Konzeptarbeit, Prompt-Tests), nutze SDXL Lightning -- es erzeugt hochwertige 1024px-Bilder in 2-8 Steps [6]. Bei höheren Auflösungen ist die Qualität besser als bei SDXL Turbo.

Für das finale Ergebnis wechselst du zurück zu vollem SDXL oder Flux mit 25-30 Steps. Der Unterschied ist sichtbar.

Der praktische Workflow

Das funktioniert 2026 tatsächlich für fotorealistische Ergebnisse:

Wähle dein Modell -- Flux 2 für den besten Fotorealismus, Juggernaut XL für das SDXL-Ökosystem
Schreibe einen natürlichsprachlichen Prompt, der beschreibt, was du siehst
Generiere bei 1024x1024, DPM++ 2M Karras, CFG 7-9, 25-30 Steps
Nutze ControlNet, wenn du eine bestimmte Komposition brauchst (Depth oder Pose)
Iteriere am Prompt -- generiere 4-8 Bilder, wähle das beste
Upscale den Gewinner auf deine Zielauflösung
Inpainte problematische Bereiche (Hände, Augen, kleine Details)

Das ist derselbe Workflow, egal ob du in ComfyUI oder A1111 bist. Die Werkzeuge unterscheiden sich, die Pipeline nicht.

Referenzen

1. Flux 2 Models -- Black Forest Labs -- Offizielle Flux 2-Modellseite.
2. FLUX.2 and NVIDIA RTX AI Garage -- Flux 2-Integration mit ComfyUI und Branchenadoption.
3. Stability AI Release Notes -- Details zur Einstellung von SD 3.0 und zur Veröffentlichung von 3.5.
4. RTX 5090 vs 4090 for AI Workloads -- Hardwarevergleich für Bildgenerierung.
5. ControlNet Complete Guide -- Aktualisierte ControlNet-Dokumentation für mehrere Architekturen.
6. SDXL-Lightning by ByteDance -- Generierungsmodell mit 2-8 Steps.
7. Best Stable Diffusion Models for Photorealism 2026 -- Aktuelle Modelllandschaft.
8. Top Photorealistic Stable Diffusion Models -- Community-Reviews von Civitai.

Stable-Diffusion-Spickzettel: Fehlersuche & Optimierung

Thu, 04 May 2023 23:30:00 GMT

Aktualisiert im März 2026. Die ursprüngliche Version dieses Spickzettels wurde im Mai 2023 für SD 1.5 geschrieben. Seitdem hat sich fast alles verändert -- neue Architekturen (SDXL, SD 3.5, Flux), neue UIs (ComfyUI), neue Hardware (RTX 5090) und eine komplette Kehrtwende bei der Philosophie zu Negative Prompts. Das hier ist die aktuelle Version.

Das ist meine Arbeitsreferenz für Stable-Diffusion-Parameter. Kein Tutorial -- nur die Einstellungen, zu denen ich greife, wenn etwas nicht funktioniert oder wenn ich die Qualität weiter treiben will.

Welches Modell du verwenden solltest

Das ist inzwischen die erste Entscheidung, und sie ist wichtiger als jede Parameter-Feinjustierung.

Modell	Am besten für	Auflösung	Hinweise
Flux 2	Fotorealismus, Prompt-Treue	1024x1024+	Bestes Open-Weight-Modell für Fotorealismus im Jahr 2026. In Adobe Photoshop integriert [1]
SDXL	Allgemeine Nutzung	1024x1024	Riesiges Ökosystem an Fine-Tunes. Juggernaut XL, Realistic Vision, DreamShaper
SD 3.5 Large	Höchste Qualität (Stabilitys Flaggschiff)	1024x1024	MMDiT-Architektur. SD 3.0 wurde im April 2025 eingestellt [2]
SDXL Lightning	Geschwindigkeit	1024x1024	Generierung in 2-8 Schritten. Bessere Qualität als Turbo bei höherer Auflösung [3]
SD 1.5	Legacy-Workflows	512x512	Riesige Fine-Tune-Bibliothek, wird aber zunehmend abgelöst. SD 2.0/2.1 offiziell eingestellt

Wenn du frisch anfängst: Flux 2 für Fotorealismus, SDXL für alles andere. SD 3.5 ist gut, aber das Ökosystem ist kleiner.

Welche UI du verwenden solltest

UI	Am besten für
ComfyUI	Power-User. Node-basiert, besseres VRAM-Management, 15% schneller, beste Flux-Unterstützung. Seit 2025 der Branchenstandard für ernsthafte Arbeit [4]
Automatic1111	Einsteiger. Einfachere Oberfläche, riesige Erweiterungsbibliothek. Funktioniert für SDXL weiterhin ordentlich
Fooocus	Ein-Klick-Generierung. Minimale Konfiguration. Gut für schnelle Ergebnisse

Ich nutze ComfyUI. Die Lernkurve ist steiler (rechne mit 10-20 Stunden, bis es sich vertraut anfühlt), aber allein das VRAM-Management ist es wert -- es lässt SDXL auf 8 GB laufen, wo A1111 abstürzt.

Sampler

Die Sampler-Debatte ist weitgehend entschieden.

Meine Standardwahl:

DPM++ 2M Karras -- bestes Verhältnis aus Geschwindigkeit und Qualität. Das ist mein Default für fast alles.
DPM++ SDE Karras -- bei niedrigen Schrittzahlen etwas besser. Gut, wenn du schnell iterierst.
Euler a -- weiterhin zuverlässig. Mehr Varianz in den Ausgaben, gut zum Erkunden.

Wann du wechseln solltest:

Zu wenig Vielfalt in den Ausgaben? Probier DPM++ SDE oder Euler a.
Artefakte oder Übersättigung? Probier DPM++ 2M Karras oder plain Euler.
Geschwindigkeit über alles? Euler a oder DPM++ 2M (non-Karras).
Maximale Qualität? DPM++ 3M SDE Karras oder UniPC.

Schrittzahlen: 20-30 Schritte für die meisten Sampler. Lightning-Modelle brauchen nur 2-8.

CFG (Classifier Free Guidance)

Wie strikt das Modell deinem Prompt folgt statt seiner eigenen Interpretation.

Bereich	Wirkung
1-4	Sehr kreativ, lockere Interpretation. Oft inkohärent
5-7	Gute Balance für die meisten Arbeiten
7-10	Starke Prompt-Treue. Sweet Spot für SDXL-Fotorealismus
10-15	Risiko für Artefakte und überkochte Farben
15+	Fast immer zu viel. Artefakte garantiert

Hinweis: SD 3.5 nutzt einen anderen Guidance-Mechanismus. Das CFG-Konzept gilt weiterhin, aber die Skala verhält sich anders -- fang niedriger an (3-5) und justiere dann nach.

Auflösung

Die Zeiten von 512x512 sind vorbei.

Modell	Native Auflösung	Praktischer Bereich
SD 1.5	512x512	512x512 bis 768x768
SDXL	1024x1024	1024x1024 (Standard), 1024x768, 768x1024
SD 3.5	1024x1024	1024x1024+
Flux	1024x1024	1024x1024+, 4K auf High-End-GPUs möglich

Über die native Auflösung hinauszugehen riskiert Artefakte und Kompositionsprobleme. Nutze Hi-Res Fix oder Upscaling, statt direkt mit 2048x2048 zu generieren.

Clip Skip

Weniger relevant als früher.

SD 1.5: Clip skip 1-2 ist sehr wichtig. Anime-Modelle nutzen oft clip skip 2.
SDXL: Nutzt zwei Text-Encoder (CLIP + OpenCLIP). Clip skip wird meistens ignoriert -- die Architektur geht anders damit um.
SD 3.5 / Flux: Nicht auf dieselbe Weise anwendbar. Diese Modelle nutzen transformerbasiertes Text-Encoding.

Wenn du SDXL oder neuer nutzt: Mach dir um clip skip keine Sorgen. Wenn du SD 1.5 nutzt: Lass es für Fotorealismus bei 1, für Anime bei 2.

Negative Prompts

Die Philosophie hat sich umgedreht. 2023 lautete der Rat, lange Negative-Prompt-Listen zu verwenden. 2026 ist der Konsens: fang mit nichts an und füge nur hinzu, was du wirklich korrigieren musst.

Warum die Änderung:

SDXL und Flux verstehen natürliche Sprache deutlich besser als SD 1.5
Lange Negative Prompts können Kreativität tatsächlich einschränken und schlechtere Ergebnisse erzeugen
"bad anatomy" ist zu vage, um nützlich zu sein. "ugly" funktioniert nicht, weil SD nicht mit als "ugly" gelabelten Bildern trainiert wurde
Manche Modelle schneiden mit langen Negatives nachweislich schlechter ab [5]

Aktueller Ansatz:

Generiere zuerst ohne jeden Negative Prompt.
Wenn du ein konkretes Problem siehst (zusätzliche Finger, unscharfer Hintergrund), füge dafür ein gezieltes Negative hinzu.
Nutze Emphasis Weighting: (blurry:1.3) statt nur blurry.
Halt es kurz -- maximal 5-10 Begriffe.

GPU-Kurzreferenz

GPU	VRAM	Gut für
RTX 3060 12GB	12GB	SD 1.5, einfaches SDXL
RTX 4070 Ti	12GB	SDXL, etwas Flux
RTX 4090	24GB	Alles. Das Arbeitspferd
RTX 5090	32GB	Alles, einschließlich 4K und Batch-Generierung
8GB-Karten	8GB	Minimal brauchbar. ComfyUI hilft beim VRAM-Management

Ab 24 GB wird es für SDXL und Flux komfortabel, ohne ständig mit VRAM jonglieren zu müssen.

Schnelle Troubleshooting-Fixes

Problem	Versuch
Unscharfe Ausgabe	Schritte erhöhen. Prüfen, ob die Auflösung zur nativen Auflösung des Modells passt
Zusätzliche Finger/Gliedmaßen	`extra fingers, extra limbs` zum Negative Prompt hinzufügen. Oder ControlNet verwenden
Übersättigte Farben	CFG senken. Zu DPM++ 2M Karras wechseln
Komposition ist falsch	ControlNet (depth, canny, pose) nutzen, statt gegen den Prompt zu kämpfen
Generierung ist langsam	Lightning-Modell nutzen, Schritte reduzieren, ComfyUI für besseres VRAM verwenden
Kein VRAM mehr	Zu ComfyUI wechseln, Batch-Größe reduzieren, fp16 verwenden

Referenzen

1. Flux 2 and NVIDIA RTX AI Integration -- NVIDIAs Berichterstattung zu Flux 2 mit ComfyUI.
2. Stability AI Release Notes -- SD-3.0-Einstellung und 3.5-Release.
3. SDXL-Lightning by ByteDance -- Generierung in 2-8 Schritten bei 1024 px.
4. ComfyUI vs Automatic1111 2026 Comparison -- Performance- und Feature-Vergleich.
5. How to Use Negative Prompts Effectively -- Aktualisierter Leitfaden zur minimalistischen Negative-Prompt-Philosophie.
6. Understanding Stable Diffusion Samplers -- Sampler-Vergleich und Auswahlhilfe.
7. Best Stable Diffusion Models for 2026 -- Aktuelle Modelllandschaft.

Über mich

Thu, 04 May 2023 22:12:03 GMT

About-Seiten sind eine seltsame Sache, die man schreiben muss. Am Ende beschreibt man sich selbst wie einen Fremden, und dem misstraue ich.

Also, schlicht. Ich bin Boris. Ich schreibe seit etwas mehr als vierzehn Jahren Software. Die Arbeit bezahlt die Miete, füttert die Hunde und gibt mir an den meisten Morgen ein Problem, an dem ich kauen kann - was, ehrlich gesagt, mehr ist, als die meisten Jobs leisten. Heute bin ich die Backend-Hälfte eines kleinen Produktteams, irgendwo zwischen Laravel, Docker und Kubernetes, meistens besorgt über Queues, die schneller leer werden sollten, als sie sich füllen, und über Indizes, die schneller wachsen, als mir lieb ist.

Vor der Software habe ich an der Universität Mathematik studiert. Ganz aufgehört habe ich damit nie. Mathematik ist der Ort, an den ich gehe, wenn die Welt zu laut wird. Besonders Zahlentheorie - an einer Primzahl ist etwas Ehrliches, das ich an vielen anderen Orten nicht finde. Vieles von dem, was ich hier schreibe, beginnt aus dieser Richtung. Ein kleines mathematisches Jucken. Ein halb verstandener medizinischer Aufsatz. Ein französischer Satz, den ich viermal lesen musste. Dann ziehe ich daran und sehe, was sonst noch daran hängt.

Der Blog ist der Ort, an dem dieses Ziehen passiert. Nichts davon ist Expertenarbeit. Ich lese Medizin, die ich eigentlich nicht lesen sollte. Ich lese bulgarische und französische Romane und tue so, als käme ich mit. Ich lerne langsam Deutsch, meistens, weil mich die Grammatik amüsiert. Manchmal schreibe ich C++ von Hand. Nicht für die Arbeit - nur weil die Disziplin eine eigene Sache ist. Die Essays entstehen aus all dem - stille Versuche, aufzuschreiben, was mir aufgefallen ist, bevor ich es vergesse.

Ich lebe in Sofia. Zwei gerettete Straßenhunde - Кожухка und Еклер - sorgen dafür, dass ich mich selbst nicht zu ernst nehme. Sie sind schon früher gescheitert. Sie versuchen es weiter.

Das ist das meiste. Es gibt noch ein kleines Freelancer-Schild, das ich unter dem Namen Percepticus aufrechterhalte, für Arbeit, die über Mundpropaganda kommt. Ansonsten sind die Essays hier, und ich bin zufrieden damit, über den Rest still zu sein.

Start - Boris D. Teoharov (Deutsch)

Elfenbein unter Bernstein

Wenn der Zaehler erscheint

Die Menschen, die ich liebe, dürfen menschlich sein

Ich kann freundlich sein, ohne zu verschwinden

Der Pfeiler und der Efeu

Ein Pfeiler auf einem Feld

Der Professor hat den Efeu vergessen

Wo du ihr immer wieder begegnen wirst

Ein Pfeiler, den du umarmen kannst

Ein kleiner Schluss

Wo sich alle Wissenschaften treffen

Sprache ist ein sehr abstrakter Code

Die Tür, die sich von innen nicht öffnen lässt

Gegenseitige Ausrichtung

Das Gehirn ist nicht faul

Bulgarien spricht

Engineering, aber ehrlich

Exzellenz ist das Gehen

Wenn du es einem Kind nicht erklären kannst

Wo sich alle Wissenschaften treffen

Das kleine Ende

Das Modell, das nicht da war

Die Stadt, die nicht da war

Die Queue, die nie aufhörte

Die nukleare Option für Bulk-Löschungen: TRUNCATE + Wiedereinfügen (MySQL/InnoDB)

Warum DELETE langsam bleibt (auch in Chunks)

Die nukleare Option: TRUNCATE + Wiedereinfügen

Warum es schnell ist

Wann du es verwenden solltest (und wann nicht)

Verwende es, wenn

Verwende es nicht, wenn

Eine praktische Entscheidungsregel

Implementierung (SQL)

Implementierung (Laravel/PHP)

Fallstricke, die du einplanen musst

Auto-increment resets

Foreign Keys

Trigger

Speicherplatz

Replikation / binlog

Wenn du (nahezu) Zero Downtime brauchst

Schlussgedanke

Type-0-Refactoring: Der Schritt vor Schritt eins

Der eigentliche Grund für Type 0: Menschen haben ein begrenztes Arbeitsgedächtnis

Warum es "Type 0" heißt

Das Problem, das Type 0 löst

Greif zu Type 0, wenn...

Eine Definition, die du in deinem Team benutzen kannst

Warum überhaupt benennen?

Die vier Sub-Patterns

0a. Method extraction (das Fundament)

0b. Conciseness (zufällige Komplexität reduzieren)

0c. Empathy (reine Lesbarkeit)

0d. Dead code removal (Lügen entfernen)

Was Type 0 nicht ist

Das Kernversprechen: Verhaltenserhaltung (und wie du sie wahr hältst)

Type 0 als wiederholbares Team-Ritual

1) Entscheide den Scope (Timeboxing hilft)

2) Identifiziere die "Wirbelsäule" des Codes

3) Wende die vier Sub-Patterns der Reihe nach an

4) Führe eine "Type-0-Checklist" in deinem PR

Schlussgedanke

Wasch einen Teller mehr: Eine einfache Regel fuer eine dauerhaft saubere Codebase

Die Metapher: Kochen, Teller und Code

Echos aus dem Handwerk: Du bist in guter Gesellschaft

Warum der zusaetzliche Teller zaehlt (auch wenn du beschaeftigt bist)

1. Entropie ist real

2. Schulden verzinsen sich schneller, als du denkst

3. Das soziale Signal

4. Schwung, nicht Perfektionismus

Wie man die Wasch-einen-Teller-mehr-Regel praktiziert

1. Mach "Micro-Refactoring" zu einem Teil von Definition of Done

2. Nutze Pull Requests als Reinigungsausloeser

3. Automatisiere die einfachen Teller

4. Verankere es in Teamnormen

5. Wisse, wann du nicht waschen solltest

Die Grenze: Ein Teller, nicht das ganze Spuelbecken

Beispiel: Aus einer chaotischen Funktion eine testbare machen

Schlussgedanken

Warum `DELETE` langsam bleibt (auch in Chunks)

1. Pipe-Operator (`|>`) - "Easy Peasy Lemon Squeezy"

2. `#[\NoDiscard]` - Absicht mit Zähnen

4. `php --ini=diff` - Röntgenblick für Config-Drift

6. `array_first()` / `array_last()` - Das Offensichtliche existiert endlich

7. `get_exception_handler()` (und bessere Fatal Traces) - Observability-Upgrade