[Bürotalk] 4-Tage-Woche, PHP 8.5 & Containerhäfen.

Hallo lieber Kay, ich musste dich mal eben zu ein paar Themen anrufen. Hast du Zeit? Hallo Felix, na klar. Was hast du auf dem Herz? Das ist schon spät am Nachmittag, aber ich habe mir sogar extra einen Tee gemacht und habe gedacht, jetzt rufe ich mal eben Kay an zu ein paar Sachen, die ich mir aufgeschrieben habe. Fantastisch, ich bin ganz oren. Ja, pass auf, ich habe ganz viele Themen aufgeschrieben, aber drei habe ich hier schon mal so auf der Liste. Wir müssen mal gucken, wie weit wir kommen. Ich glaube, wir wollen so Büro-Talk ja nicht zu lange ziehen. Aber eine Sache ist mir doch aufgefallen. Wir haben keinen Menschen mehr bei uns in der Firma, der einen 40-Stunden-Job hat.

Ist das nicht interessant? Das ist in der Tat interessant. Wie viele Stunden machst du denn laut Vertrag? Besser sage ich jetzt mehr als 40, sonst hält man nämlich jemanden. Ich meine natürlich meine Mitarbeitende quasi. Ja, wie viel ich mache, das werde ich ganz oft gefragt. Das kann ich gar nicht beantworten müssen, weil ich auch, glaube ich, nicht länger darauf rumreiten. Aber das sind sicherlich in vielen Wochen mal mehr als 40 Stunden, aber in ganz vielen Wochen auch weniger. Aber ich weiß gar nicht, was mein Arbeitsvertrag hergibt. Ich habe ja sogar einen Arbeitsvertrag. Aber ich weiß nicht, was drin steht.

Jedenfalls verlässt uns zum Mitte August jetzt ein Mitarbeiter Richtung von einem Kunden, das war ganz transparent kommuniziert.

Coole Kommunikation, also no hate an der Stelle. Und vielleicht an dieser Stelle auch noch mal alles Gute für den Herren. Und Kay, du hast dich ja jetzt relativ spontan zu meiner Überraschung dazu entschieden, dass du eben als letzter Mitarbeiter bei uns in der Firma auch nicht mehr 40 Stunden machen möchtest.

Wollst du was dazu sagen? Oder ist das zu privat? Nö, kann ich ruhig machen. Spontan war es ja nur für dich. Ich bin damit schon länger schwanger gewesen, wie man sagt. Und was mich eigentlich die ganze Zeit davon abgehalten hat, war, oder vielleicht andersherum, ich habe schon länger gemerkt, dass ich das eigentlich ganz gerne mag, so Freizeit haben und die dann auch frei gestalten.

Und dass ich glücklicherweise in einer Position bin, wo ich so viel Geld bekomme, dass ich mir das auch leisten könnte.

Und was mich dann davon abgehalten hat, das früher zu machen, war dann so ein Verantwortungsbewusstsein. Ich bin ja in so einer leidenden Position und da sind ja die Kollegen sind ja auf mich angewiesen, die Kunden wollen möglicherweise Dinge von mir.

Und da dachte ich, kann ich doch nicht einfach einen Tag weniger da sein? Was ist, wenn da ein Meeting ist oder wenn mich jemand braucht oder sonst irgendwas? Jetzt muss man dazu ja noch kurz erklären, dass die meisten Leute, die bei uns 35 oder 30 Stunden machen, die sind eigentlich an allen Tagen da, bis auf einer, glaube ich, und machen einfach weniger Stunden und freuen sich dann über einen früheren Feierabend, während du dich für eine Modelle entschieden hast, wo du immer freitags nicht mehr da bist.

Genau, weil das auch einfach das ist, wie ich mir das sinnvoll vorstellen kann. Also eine Stunde weniger am Tag, das klingt auf dem Papier gut, aber ich merke schon, so ein ganzer Tag muss es dann schon sein, damit ich auch was davon merke.

Also, dass ich dann auch vormittags mir irgendwelche Freizeitsachen machen kann, mal irgendwelche Ausflüge. Ich habe so einen Freundeskreis, der relativ viel Schichtarbeit macht und die machen dann auch schon mal unter der Woche irgendwelche Dinge, einfach weil sie dann am Wochenende arbeiten oder sowas.

Und dann so einen Tag, wo ich frei sagen kann, hör mal, ich habe jetzt das Arbeitshandy gar nicht an, ich reagiere gar nicht auf E-Mails, sondern mache das frei, wie ich das möchte.

Das war es, was ich eigentlich wollte. Und dann, wie gesagt, hat es mich lange davon abgehalten, dass ich so ein Verantwortungsbewusstsein hatte. Aber jetzt mehr und mehr habe ich gedacht, wenn es jetzt wirklich daran scheitert, dass ich irgendwie einen Tag weniger nicht da bin und auf Kunden nicht reagieren kann, dann ist eigentlich schon bei der Planung vorab irgendwas falsch gelaufen.

Also, so wichtig kann das, was ich freitags mache, nicht sein, dass ich auf jeden Fall da sein muss.

Und ja, das habe ich dann mit dir besprochen und du warst, glaube ich, ein bisschen verhalten, aber natürlich bester Arbeitgeber, wie du bist. Hast du mir das ermöglicht? Ja, ich kann dir die Arbeitgeberperspektive da auch gerne sagen. Also, einerseits ist es natürlich so, dass ich grundsätzlich Riesenfan davon bin. Das ist ja auch nicht ohne Grund, dass alle weniger als 40 Stunden machen. Ich bin ein Riesenfan davon, wenn man dann zum Beispiel eine 30- oder 35-Stunden-Woche macht. Und meistens erkläre ich das so, dass wenn man sieben Stunden am Tag arbeitet, man eigentlich genauso produktiv ist wie mit acht Stunden.

Also, eigentlich ähnlich viel geschafft kriegt. Und also, man hat ja so ein Tagesprogramm, das man sich vornimmt und dann legt man los und macht das. Und ich habe so das Gefühl, wenn man, ja, sieben Stunden ist man halt noch ein bisschen frischer als in dieser letzten achten Stunde dann. Und ich glaube, das skaliert man mindestens nicht linear. Und dann hat man natürlich als Arbeitgeber den Vorteil, dass man sich ein bisschen Gehalt spart. Also, das Gehalt wird ja entsprechend auch um die Zeit dann proportional gekürzt. Und das macht ja mehr aus, weil die Steuern ja hinten raus zunehmen und so.

Da könnte man jetzt lange drüber sprechen. Aber jedenfalls lohnt sich das noch mehr, als es dann erstmal auf dem Papier aussieht. Und deswegen ist das einerseits geldtechnisch praktisch. Ich habe das Gefühl, dass keiner von den Jungs und Mädels an Produktivität in irgendeiner Form verliert, sind jeden Tag erreichbar.

Und das bin ich da an sich erstmal großer Fan von. Jetzt ist es bei dir natürlich so, dass du eine spezielle Rolle bei uns hast und wirklich ein sehr wichtiger Baustein bei uns bist und viele Fäden in der Hand hast. Und wenn du einen Tag nicht da bist, dann merkt man das manchmal schon. Und deswegen hätte ich mir bei dir auch, hätte ich gerne ein Modell gesehen, wo du sagst, du bist jeden Tag nur sechs oder sieben Stunden da. Hätte ich sofort unterschrieben, überhaupt kein Problem. Wenn du den Freitag tatsächlich nicht da bist, dann wird man das vielleicht merken. Jetzt hattest du einmal schon den Genuss, den Freitag frei zu haben.

Da muss ich natürlich gleich auch noch fragen, wie es war. Aber wer bin ich, der dir das jetzt verbietet oder sagt, wir machen das nicht oder wir probieren das nicht aus. Weil wir haben das jetzt ja nur bei einem von unseren Kollegen, der das eben auch so macht mit dem Freitag. Und ja, ich weiß gar nicht, haben wir da jemals was von gemerkt, dass der Freitag nicht da ist? Also das ist jetzt gar nicht negativ gegenüber ihm. Aber ich meine so, also das läuft ja trotzdem und das Projekt läuft gut und es funktioniert alles. Ja, ja. Das waren jetzt sehr viele Fragen auf einmal. Ich glaube, es kommt schon in ganz, ganz seltenen Ausnahmefällen mal vor, dass doch freitags ausgerechnet irgendein Notfall ist.

Aber es ist ja alles nicht in Stein gemeißelt. Also ich muss ja freitags nicht frei nehmen. Ich kann es ja dann auch irgendwie kurzfristig mal montags oder sonst irgendwas machen. Das wusste ich sogar noch gar nicht. Ja, ist ja klar. Wenn jetzt irgendein Notfall ist, das wirklich nicht noch drei Tage Aufschub hat, dann kann man da natürlich flexibel was machen. Und auch wenn jetzt in Zukunft irgendwelche Sachen sich ändern bei den Projekten, die wir so in der Firma haben und es dann wirklich nicht mehr gangbar ist, dass ich einen Tag weg bin, dann kann man das sicher auch nochmal anpassen.

Ist ja alles nicht in Stein gemeißelt. Aber jetzt gerade sind wir von den Projekten her eben so aufgestellt, dass eben nicht so viele Code-Reviews anfallen und dementsprechend auch ich nicht so als Bottleneck in der Position sitze, wo alles an mir vorbei muss.

Und deswegen klappt das jetzt im Moment, glaube ich, ganz gut. Aber für die Zukunft müssen wir dann mal schauen. Cool. Und wie war der letzte Freitag? Ja, es war fantastisch. Also es ist doch, also wenn man es sich runterbricht, ist es pro Tag fünf Prozent weniger.

Aber doch insgesamt ist man einfach einen Tag früher fertig. Und jetzt ist heute Mittwoch und das heißt, morgen ist schon der letzte Tag. Mittwoch ist quasi Wochenende, weil Donnerstag ist ja der neue Freitag. Genau, und das ist einfach geil. Und jetzt habe ich mich schon mit Freunden verabredet, dass wir am Freitag was machen. Und das ist schon cool. Ja, cool. Ja, ich bin ganz gespannt, wie sich das so ergibt und freue mich, dass wir es ausprobieren. Und genau wie du sagst, in dem Moment, wo wir merken, das ist irgendwie nichts, aus welchen Gründen auch immer, ist das ja nicht irgendwie festgelegt.

Und ja, ich bin ja grundsätzlich auch immer so entspannt. Wir haben ja jetzt das nicht mal vertraglich geregelt oder so, sondern wir haben das mündlich abgemacht. Ich habe das der Steuerberaterin mitgegeben, dass sie das Geld entsprechend anpasst. Und dann probieren wir das jetzt aus. Und das ist jetzt nicht irgendwie eine Sache, die nie wieder umgestoßen werden darf. Und da werden wir bestimmt im Podcast nochmal darüber berichten, wie das so läuft. Fantastisch. Ganz spannend. Nur nicht mehr freitags. Ja, und ich bin ganz happy damit, weil ich nur zufriedene Mitarbeitende habe, die sich nicht überarbeiten.

Man kommt da natürlich ins Grübeln, ob man zu viel Gehalt zahlt, wenn alle auch mit 20 Prozent weniger zurechtkommen. Aber nein, ich freue mich natürlich, wenn ich konkurrenzfähige Gehälter zahlen kann, die Leute happy sind. Und ich sage ja auch immer wieder, als kleine Bude müssen wir irgendwie gucken, wie wir gegen die großen Player bestehen können, die natürlich ganz andere Benefits auch dann anbieten können. Und eine Möglichkeit, die wir haben, ist eben so flexibel, zum Beispiel solche Sachen auch einzurichten und möglich zu machen. Ja, also nochmal jetzt hier offiziell, danke an dich, Felix, dass du das auch möglich gemacht hast.

Sehr, sehr gerne. Kay, ich habe noch zwei andere Themen. Und als erstes muss ich erstmal sagen, ich habe mein Büro aufgeräumt. Deswegen halte es jetzt wieder ein bisschen mehr. Jetzt habe ich hier schon die ganze Sofa-Garnitor wieder reingeschleppt, damit der Sound besser wird. Also man sollte nicht aufräumen, wenn man podcastet, das mal so als kleiner Hinweis. Und dann würde ich gerne auf die Folge eingehen, die wir zu PHP gemacht haben. Und da habe ich so in so einem lapidaren Satz, weil ich mich nicht gut informiert hatte, gesagt, ja in PHP 8.5, das ja jetzt ansteht, kommen nur Funktionen, die wir nicht brauchen.

Und dann hast du richtigerweise schon darauf hingewiesen, dass der Pipe-Operator da mit drin ist. Und du hattest noch auf jeden Fall was anderes hingewiesen. Ich glaube, diese Error-Geschichten, diese Error-Händler, die sich eventuell als ganz praktisch herausstellen könnten. Oh, ja, ich sage mal ja. Ich habe es vielleicht nicht mal so 100 Prozent im Kopf, aber diesen Chain-Pipe-Irgendwas-Operator, der ist ganz schön nice. Ja, genau. Und ich habe jetzt einen Newsletter bekommen von Laravel. Und da stand drin, dass in PHP 8.5 zwei neue Array-Funktionen eingeführt werden. Weißt du, welche das sind?

Oder welche vermisst du? Tja, das ist jetzt eine Fangfrage. Ja, klar. Und Kay ist wirklich nicht darauf vorbereitet. Das muss man den Leuten da draußen sagen. Ich habe es selbstverständlich gelesen. Das Problem ist, dass, wenn ich täglich mit PHP arbeite, arbeite ich ja nicht mit PHP, sondern arbeite mit Laravel.

Und die haben natürlich noch zusätzliche Rapper und Helper für so Array-Dingances gemacht, wo man dann auch die Sachen abbilden konnte, die vorher nicht nativ gingen.

Aber sag es mir gerne nochmal. Ja, es gibt Array-First, also Array-First und Array-Last. Und in der Vergangenheit kann ich mich daran erinnern, das war ein ziemlicher Krampf, das erste und das letzte Element aus einem Array auszulesen, so wild das auch ist.

Ich will dich jetzt nicht zu sehr quälen mit solchen Fragen, die in Interviews auch mal kommen und wo ich mich dann immer ärgere, weil sowas weiß halt keiner auswendig.

Aber wenn du das erste Element von einem Array im PHP auslesen willst, dann kannst du natürlich jetzt, wenn du einen ganz normalen numerischen Index hast, kannst du natürlich einfach auf eine eckige Klammer 0 zugreifen.

Dann kriegst du auch das erste Element raus. Wunderbar, dann hast du es. Aber in dem Moment, wo du so ein assoziatives Array hast oder die Array-Keys halt nicht so schön sortiert sind, hast du halt ein Riesenproblem.

Und es gibt ja zig Varianten, wie man an das erste Element kommt. Also du kannst irgendwie mit Array-Shift was machen. Ich weiß gar nicht, dann verkürzt du, glaube ich, das Array oder veränderst es auf jeden Fall. Du kannst mit Array-Reverse und Array-Pop arbeiten und die Variante, die sich, glaube ich, so in letzter Zeit durchgesetzt hat, war mit Reset und dann das Array da reingeben.

Dann resettest du quasi den internen Pointer auf das erste Element und bekommst auch das erste Element zurück. Das klappt erstmal soweit ganz gut. Aber du resettest halt den Pointer. Also ich weiß ja, in der Vergangenheit hat mich das ganz oft aus dem Konzept gebracht, weil ich da früher noch nicht wusste, was dann der Array-Pointer ist und so. Und dann kommen da auf einmal Ergebnisse, die man nicht erwartet. Jedenfalls ist das nicht immer cool, diesen Pointer zurückzusetzen. Und man kommt einfach nicht entspannt an das erste Array-Element dran. Ich wäre jetzt total davon ausgegangen, dass man auch bei assoziativen Arrays mit so numerischen Indrex auf die Dinger zugreifen kann.

Stimmt das gar nicht? Wir haben natürlich jetzt hier einen schönen Podcast, das heißt, wir können es schneiden. Das heißt, ich werde es jetzt in einem PHP-Playground ausprobieren. Man muss jetzt dazu sagen, ich habe jetzt meine mechanische Tastatur wieder angeschlossen. Das heißt, sobald ich hier irgendwas tippe... Oh, mach doch mal. Kingen das alle mit. Aber noch ein bisschen ASMR rein. Ach, guck mal hier, der Playground gibt mir sogar direkt ein Array. Das ist ja richtig geil. So, und dann habe ich hier ein Array. Das nehme ich jetzt mal hier... Warte mal. Host 1 ist mein Key. Und der Name ist Felix.

Jetzt einfach nur alphabetisch, nicht weil ich cooler bin. Dann haben wir den Host 2. Und der heißt Kay. Ich kenne es mir vorher. Die restlichen Elemente haue ich hier raus. Also ich mache jetzt wirklich einfach nur ein Array auf. Das heißt auch Dollar Array. Ganz kreativ. So, und jetzt mache ich hier einen Print R mache ich mal auf Array und dann 0.

Oh, mein Handy ist noch richtig angerostet. So lange habe ich nicht mehr programmiert. Jetzt execute ich das Ganze mal. Und dann kommt Undefined Array Key 0 in und so weiter Online 7. Okay. Ja, genau. Also das hätte mich natürlich jetzt sehr gewundert. Dann hätte ich den direkt zurückgeschrieben, könnt eure Funktion wieder einpacken. Alles zurück. Aber selbst wenn dem der Fall wäre, wäre auch die Array Last Funktion noch ganz praktisch, weil das ist nämlich nicht weniger kompliziert. Da kannst du jetzt statt Reset kannst du mit End halt den Pointer aufs Ende setzen und kannst arbeiten. Oder du nimmst halt Array Key Last, holst den letzten Key und packst das halt in dein Array rein.

Dann findest du das auch. Aber es ist, du verwendest normalerweise, wenn du den Pointer nicht zurücksetzen willst, in beiden Varianten immer zwei Funktionen irgendwie ineinander verschachtelt. Oder du setzt halt irgendwie den Pointer zurück. Und das ist halt irgendwie ätzend. Und deswegen sei das an dieser Stelle nochmal gesagt, wir freuen uns auf 8.5, denn es wird mal mindestens Code innerhalb von Frameworks verschlanken, wenn nicht sogar unseren eigenen. Assoziative Arrays sind ja so ein bisschen eigentlich der Satz für so Objekte, wo man einfach Daten zusammenfasst und mit Keys so ein bisschen lesbar macht.

Und da macht es ja eigentlich keinen Sinn, da auf das erste oder letzte Element zurückzugreifen, weil die ja keine intrinsische Reihenfolge haben. So wenn du jetzt ein assoziatives Array für User hast und dann hast du ein Key Name und ein Key E-Mail. Warum willst du da auf das erste oder letzte zugreifen? Ja Kay, da würden wir natürlich jetzt einen Fass aufmachen. Aber also es gibt definitiv Anwendungsfälle dafür. Und man muss ja sagen, dass in PHP schon sehr, sehr viel mit Arrays gemacht wird. Also als man wirklich früher so Vanilla-PHP gemacht hat, also alles waren Arrays. Alles waren Arrays.

Und das musste ja leidvoll, musste ich mich dann umschulen in der Uni, als wir Java gemacht haben. Also ich war ja nicht lange in der Uni, nicht, dass das da draußen falsch ankommt. Aber ein paar Vorlesungen habe ich mir schlafend angehört. Und da ging es jedenfalls um Java. Und bei Java sind Arrays ja nicht so ein Ding, sondern dann sind es ja, ich weiß gar nicht, was es da gibt. Da habe ich alles schon wieder vergessen, aber so Collections und so ein Kram. Jedenfalls sind das andere Konstrukte, die man da verwendet. Und in PHP läuft eigentlich alles über Arrays. Alles, was man irgendwie an Daten hat, ballert man in Array rein,

weil man in PHP einfach super cool mit Arrays arbeiten kann. Obwohl es manche Funktionen nicht gibt, wie Array-First. Ja. Du wirst mehr natives PHP machen, Felix, damit wir da am Ball bleiben und diese ganzen neuen Sachen einsetzen können. Ja, dann suche uns einen Kunden, der uns das bezahlt. Und dann bin ich Feuer und Flamme. Also ich würde nichts mehr lieben als Vanilla, ja, JavaScript vielleicht nicht, aber Vanilla TypeScript. Also JavaScript würde ich auch machen. Oder Vanilla PHP, das liebe ich natürlich sehr, aber gibt es eigentlich keinen Grund mehr, das heute zu machen. Ja, der Zug ist durch.

Aber wenn es so Legacy-Projekte gibt, wo es gar nicht anders geht, gerne, gerne. Ich warte ja noch drauf, dass es mal so Zeiten gibt für PHP, wie das heutzutage mit COBOL ist, wo die Leute wahnsinnig gut bezahlt werden für ihre alten Code. Vielleicht kommen wir da mit PHP auch irgendwann mal hin. Da kannst du dann Array auch First wieder nicht einsetzen. Ah, da ist natürlich was dran. Da ist natürlich was dran. Ja, Kay, sollen wir noch ein Thema aufmachen? Oder reicht das für heute? Ja, also, hit me. Ich habe noch eine Kontroverse. Oh. Ja. Ich habe nämlich so ein Bild gefunden und ich suche dir das gerade raus.

Du hast es schon so mit einem Auge gestern auf meinem Bildschirm gesehen, aber ich habe es ganz schnell weggeklickt, dass du es nicht siehst. Und zwar habe ich bei, ja, irgendeinem Social Media, wo ich gar nicht so wahnsinnig aktiv bin, aber ich habe ein Bild gesehen von Mark Zuckerberg. Und da schreibt jemand drüber, How did he scale Facebook in 2005 without Kubernetes, Serverless Functions, Serverless Redis, Managed Auth-Service, Rust, Serverless Edge, Replicated Database with Real-Time Sync and Apache Kafka. Und die Liste können wir wahrscheinlich jetzt noch weiterführen. Da drunter ist dann so ein Bild, wo der Zuckerberg an so einem Windows XP, müsste es sein,

sitzt mit so einem irgendwie kaffeeüberspülten Stuhl und so weiter. Und da bin ich schon ein bisschen ins Grübeln gekommen, weil wir ja heute schon sehr heftige Setups aufbauen von Cloud-Server, Dock-Horizon, in Git den Code versionieren und so weiter und so fort. Und wir gehen halt nicht mehr mit FTP irgendwo hin und updaten man eine Datei. Oder ich habe früher noch ganz viel so mit AirSync, wenn man dann doch mehrere Server hatte, wo dann so ein Load-Balancer dazwischen war, hat man mit AirSync eben die Dateien auf die Server verteilt und so. Und da frage ich mich, die Seiten liefen ja wirklich damals, auch mit Millionen Usern.

Ist das alles übertrieben oder war das damals saukompliziert oder gab es immer nur einen Menschen, der das maintainen konnte? Was sind da unsere Gedanken zu, Kay? Es gibt ja ganz viele solche Geschichten, ich glaube ja auch bekanntermaßen WhatsApp, die unendlich viele Nachrichten mit nur so einer Handvoll Team-Membern organisiert haben. Und ich denke, das geht schon alles irgendwie. Die Frage ist, wie komfortabel das ist. Und klar, der Zuckerberg hat das damals hinbekommen, ohne diese Fancy-Tools, die wir heute haben. Aber es geht auch ohne diese Fancy-Tools, es ist nur sehr viel komplizierter.

Und ich würde auch mal argumentieren, dass der Feature-Umfang damals nicht so groß war. Und Sachen, die wir heute machen, sehr viel komplizierter sind, mehr Verstrebungen zu anderen Bereichen haben. Also das klassische Beispiel, was meiner Meinung nach in so einer Laravel-Anwendung von so einer einfachen Anwendung zu einer komplizierteren Anwendung der nächste Schritt ist,

ist, wenn man mit Queues arbeitet. Das heißt, die Anwendung selber, wenn sie irgendeine komplizierte Aufgabe erfüllen soll, zum Beispiel eine E-Mail versenden oder sowas, dann macht sie das nicht mehr als Teil des Requestes, in dem das angestoßen wurde, sondern sie schickt einen Auftrag in die Queue. Und diese Queue ist dann so ein separates System, das irgendwo parallel läuft. Und dort ist ein unabhängiger Arbeiter, der sich den neuesten Job rauszieht, den bearbeitet und dann entweder es funktioniert

oder wenn er nicht funktioniert hat, dann schickt er den auf so einen Failed-Queue-Stapel. Verstehe ich. Aber ich nehme jetzt mal die Perspektive vom Vergangenheits-Felix ein, wo wir diese riesen Ferienhaus-Portale gebaut haben, eben ohne all so ein Zeug. Und ich bin jetzt gar nicht wirklich Fan von, sondern ich liebe viele von den neuen Tools und von Docker bis Git sowieso.

Also ich nehme jetzt einfach nur mal für die Diskussion die Perspektive ein. Aber wir haben zum Beispiel damals einfach einen Con-Job laufen lassen. Das war dann, also konnte man ja Skripte dann ansteuern zu bestimmten Zeiten, also zum Beispiel alle fünf Minuten oder alle eine Minute oder nur nachts um drei Uhr oder alle zwei Wochen nachts um drei Uhr. Dann hat man bestimmte Skripte angesteuert und hat sich dann zum Beispiel die Jobs, die du jetzt gerade angesprochen hast, hat man sich einfach irgendwo in den Datenbank geschrieben. Und dann bin ich in den Datenbank reingegangen und habe gesehen,

ah, da soll eine E-Mail an Peter Müller rausgehen. Und dann habe ich halt die E-Mail an Peter Müller rausgeschickt. Das war, da habe ich wahrscheinlich ein Stück weit manuell das gemacht, was Laravel jetzt automatisiert. Aber da bräuchte ich jetzt kein wildes System für, um sowas zu machen, weil kompliziert ist es an sich nicht. Nö, genau. Und bei Laravel zum Beispiel gibt es ja auch die Möglichkeit, diese Crone-Jobs, also Crone-Jobs sind es ja nicht, sondern die Cute-Jobs auch über die Datenbank abzufrühstücken. Da brauchst du also kein Redis-System dahinter oder sowas. Und wahrscheinlich für die allermeisten Anwendungen wird das auch so funktionieren.

Man kann sich irgendwie selber behelfen, die Dinge zu programmieren. Und diese ganzen Fancy-Tools, die braucht man da nicht. Aber man wird wahrscheinlich auch immer wieder an Probleme stoßen, die daraus resultieren. Ein gutes Beispiel, was wir jetzt bei einem Kunden haben, da deployen wir so eine Laravel-Anwendung an Forge. Das ist auch so ein Laravel-Hoster, sag ich mal. Und das ist noch so ganz klassisch. Da ist ein Server, da läuft Lara, also da läuft PHP. Und wenn es einen Update gibt, dann wird da über Git das Projekt geklont und dann läuft das da. Und das funktioniert in 95 Prozent der Fälle total gut.

Und in 5 Prozent der Fälle hast du dann irgendeinen komischen PHP-Versions-Mismatch. Das heißt, du hast bei dir lokal mit einer bestimmten PHP-Version entwickelt, vielleicht auch mit anderen Erweiterungen oder sonst irgendwas, und da hat es funktioniert. Und aber auf dem Server, wo die ganze Zeit die gleiche PHP-Version läuft, da ist es dann anders. Und beim Deployment fliegt dir dann auf einmal der Live-Server in die Luft. Ah, das kenne ich von damals noch. Wenn du dann zum Beispiel, hattest du vier Server, haben wir schön über AirSync die PHP-Skripte hochgeballert. Das war da so ein bisschen gescheduled und so.

Das war eigentlich ganz cool. Das war aber ein Skript, das selbst gebaut ist. Das heißt, jeder, der von außen reinkam, kannte das erst mal nicht. Das ist natürlich jetzt schön auch an Docker und so, dass es so ein bisschen vereinheitlicht ist. Und dann hat ein Server auf einmal keinen Imagic zum Beispiel installiert. Und dann konnten bei jedem dritten Kunden so, sag ich jetzt einfach mal so, konnten dann bestimmte Bilder nicht angezeigt werden, weil die auf dem Server nicht generiert werden konnten. Und das hast du natürlich erst mal nicht gemerkt, weil deine Test-Server haben natürlich dann irgendwie wunderbar funktioniert.

Und du warst zufällig auf dem Production-Server, wo es gelaufen ist. Und dann ruft dich auf einmal um 20 Uhr abends dein Chef an und sagt, oh, hier ist alles auseinandergeflogen und es funktioniert gar nichts mehr. Die übertreiben dann natürlich auch direkt. Und dann darfst du erst mal suchen, woran ziehe ich. Das ist dieses klassische It worked on my machine. Ja, ja, genau. Das ist natürlich in der Docker-Umgebung schon klasse, das. Ja, siehst du, das ist dann eben, wenn du so eine Docker-Umgebung hast, da hast du dann bei dir auf dem lokalen System dasselbe Image, was du dann auch deployen würdest.

Und das heißt, diese Dinge können dir dann schon mal nicht passieren. Und das ist so ein klassischer Fall von, ja, anders funktioniert es auch, aber eben nicht so convenient. Und ich kann mir vorstellen, eine Queue in der Datenbank funktioniert auch, aber eine Queue überredest oder sowas, hat dann ganz andere Vorteile. Und wenn du in bestimmten Bereichen, in bestimmten Größenordnungen bist, was in deiner Anwendung so los ist, da kannst du es dir eben nicht mehr erlauben, dass die Anwendung in der Live-Umgebung abstürzt, weil du eine PHP-Version übersehen hast oder sowas. Genau, jetzt ist ja eben genau dieses Beispiel mit Zuckerberg,

weil die Facebook lief ja damals, soweit ich informiert bin, auch auf PHP. Und die haben ja dann irgendwann angefangen, was Eigenes zu bauen. Bist da vielleicht besser informiert als ich. Aber das lief ja lange und wie gesagt auch mit Millionen Nutzern gut. Und das ist ja das, was wir gesagt haben, auch in unserem PHP-Podcast. Wenn man PHP jetzt richtig verwendet, dann ist das schon auch sehr schnell und du kannst damit alles machen. Du kannst es nur mitunter vielleicht nicht so komfortabel machen, weil du dann schon mal ein Workaround bauen musst oder nochmal eine Sache manuell mehr cachen musst,

die dir vielleicht in ein anderes System, was mehrere Threads aufmacht oder so, dann automatisch abnehmen würde. Ja, genau. Also über PHP haben wir schon gesagt, dass es wahrscheinlich erst sehr spät PHP selber ein Bottleneck wird. Da hast du vorher Probleme mit SQL-Querys, die nicht richtig optimiert sind und solche Sachen. Also, ja, es geht schon alles irgendwie. Aber der Vorteil ist eben bei den ganzen Tools, die wir haben, dass wir uns genau das Richtige rauspicken können, was jetzt gerade uns am besten die Arbeit erleichtert. Und ich bin vollkommen bei dir. Wir haben ja auch so einen gewissen Tech-Stack,

den wir jetzt schon seit Jahren gut fahren. Und die Tendenz ist dann, für neue Projekte zu sagen, komm, wir werfen einfach das Gleiche wie immer drauf. Und dann passiert es natürlich schnell, dass man einen totalen Overkill macht und so ein komplettes Docker-Deployment mit Kubernetes für die allerkleinste Web-Anwendung aufsetzt. Aber da dann eben den Schritt zurückzugehen und zu sagen, okay, wir wissen, dass es das als Möglichkeit gibt, so ein fancy Docker-Setup. Aber ist das wirklich das Richtige? Oder tut es für diese kleine Seite nicht vielleicht doch auch erstmal ein Forge? Und wenn das dann läuft,

dann kann man nachher das irgendwie pivoten, wie wir Techniker sagen. Ja, das ist tatsächlich auch ein Punkt, den ich mir aufgeschrieben habe. Man muss wirklich bei dem Projekt bewerten so, also man denkt natürlich immer, jedes Projekt, was man so baut, wird irgendwann mal weltweit eingesetzt und vor Millionen Nutzern. Und so gehen viele auch an ihr Setup dran. Und manchmal muss man aber ein bisschen tiefer stapeln, um sich auch einfach die Entwicklung einfacher zu machen. Und du musst ja wirklich gucken, was du brauchst. Was ich jetzt ganz oft in letzter Zeit sehe, habe jetzt wieder ein kleines Projekt gehabt,

das eigentlich, ja, das ist eine Website, da sind vielleicht 20 registrierte Benutzer drauf. Und da ist eine Website davor, wo halt, ja, jetzt nicht übermäßig viel Traffic drauf ist. Ja, und das ist ein Cloud-Server, den du skalieren kannst. Aber wofür, frage ich mich dann? Da ist dann ein Volume eingehängt und alles. Und das kannst du skalieren in die Unendlichkeit, aber du machst es dir eigentlich nur unendlich kompliziert, wo du einfach ein, da wäre jeder Webspace ausreichend gewesen für das Ding. Und da muss man auch so ein bisschen realistisch, glaube ich, bewerten, wo man gerade steht und vielleicht so die ganz wilden Systeme erst draufziehen,

wenn man merkt, das funktioniert wirklich. Auf der anderen Seite ist es natürlich immer einfacher, direkt vom Start wegzumachen. Das Schönste ist ja, wenn wir Kunden über viele Jahre begleiten und dann am Anfang erstmal wirklich die aller rudimentärste Webseite aufsetzen und dann über die Jahre selber sehen, wie der Kunde viel erfolgreicher wird und das mehr Andrang findet und die Services beliebter werden und dann das dazu führt, dass eben die Sachen, die damals gut waren und diese einfachen Deployment-Strategien nicht mehr ausreichen, weil dann sehen wir ja auch, guck mal, den Mehrwert, den wir geschaffen haben,

der ist wirklich ein Mehrwert, der Kunde profitiert davon und dann macht es auch wirklich Spaß, sich an so Scaling zu wagen und zu überlegen, okay, Forge ist jetzt doch nicht mehr das Richtige, Was ist der nächste Schritt? Das finde ich super spannend. Ja, und dann ist immer ganz wichtig, dass man guckt, dass man trotz allem möglichst wenig einsetzt an verschiedenen Technologien und Tools, weil alles, was man so verwendet, kann auch sehr schnell veralten und du musst immer jemanden haben, der sich damit auch auskennt und auch dauerhaft auskennt und deswegen meine ich ja immer dazu, ja, so sparsam zu sein wie möglich.

Also, das geht natürlich bei MPM-Packages los, aber geht natürlich dann auch bei dem Setup weiter, dass man sagt, das, was ich vielleicht mit geringem Aufwand auch selbst gerade noch eben in einer Zeile bauen kann oder so, da muss ich jetzt vielleicht nicht irgendwie noch das nächste große Tool drauf schmeißen, sondern das kann man vielleicht auch mal einfach abhandeln. Sehr spannend ist es dann, diesen, eben den Scheitelpunkt zu finden, wo man sagt, okay, jetzt das, was wir bis jetzt gemacht haben, war bis jetzt super gut, aber jetzt reicht es nicht mehr. Jetzt brauchen wir eine bessere Strategie

fürs Deployment, vielleicht mehr Sicherheit oder sowas. Das ist nicht immer ganz offensichtlich und wenn man so ein Projekt erstmal abgeschlossen hat und der Kunde das benutzt, dann beobachtet man das ja auch nicht so jeden Tag und sieht dann, oh, die Nutzer nehmen zu, hier wird langsam Ressourcen knapp oder irgendwie solche Späße. Ja, hat aber bisher eigentlich immer ganz gut geklappt, die Projekte auch fit zu halten und die dann so im Nachhinein zu skalieren und skalieren war eigentlich weniger bei uns, dass wir wirklich an die Performance, also Performance sowieso im Code, das schon und dass die Datenbanken einfach

irgendwann riesig geworden sind und man dann gucken musste, gerade mit diesen Eloquent-Sachen und so, dass das alles noch flott bleibt im Laravel, das schon, aber oft war dann eher so, dass man dann auf einmal mit mehreren Leuten an einem Projekt gearbeitet hat und da hat man gemerkt, oh, da müssen wir jetzt vielleicht mal eine Pipeline einführen oder ein paar automatisierte Schritte, denn der eine, der es vorher gemacht hat, der wusste zwar, wie das manuell geht, aber das weiß jetzt vielleicht der Nächste nicht und das ist vielleicht auch nicht mehr der beste Weg und dann hat man so nach und nach

die Sachen automatisiert und das hat für uns in unseren Projekten jetzt eigentlich mal ziemlich cool funktioniert. Das ist natürlich auf so einem Screenshot, wie du ihn am Anfang zitiert hast, auch immer plakativ gesagt, aber jetzt müsste man mal den Zuckerberg von vor 20 Jahren fragen, 20 war es nicht, ob das wirklich alles so großartig war oder was da für Chaos und für Herd, also für Brandherde hinter den Kulissen waren, wo er sich auch dachte, hätten wir damals Docker gehabt, wäre vielleicht alles viel besser gewesen. Absolut. Und wenn es nur das persönliche Seelenheil ist. Genau, man blendet ja immer

so in der Rückschau ganz viele Sachen aus, die nicht funktioniert haben, aber ich weiß, dass wir jetzt jedenfalls in unseren Projekten oft geschwitzt haben und ewig nach Fehlern gesucht haben und ja, vielleicht hätte man sich drei Fehler gespart, aber ein neuer Fehler kommt natürlich dazu und das sind die, die wir heute sehen. mit den ganzen Setups, wenn dann wieder eine Pipeline nicht durchläuft, dann sind alle am Schimpfen, aber wahrscheinlich ist es am Ende sogar das geringere Übel. Auf jeden Fall. Cool. Kay, ich habe zwar noch mehr Punkte auf meiner Liste, aber ich denke, für heute lassen wir es dabei.

Ist auch schon spät. Ja. Und ich danke dir einfach für ein kurzes Gespräch und wir hören uns wieder. Ich danke dir auch. Bis dahin, Felix. Tschüss. Mach's gut. Ciao, ciao. Ciao, ciao.