Deep Dive 187 –

DDEV mit Stephan Hochdörfer

22.07.2025

Stephan Hochdörfer Profil Deep Dive 186

// Podcast
// Deep Dive 187

Shownotes

Wer mit mehreren Entwickler:innen an verschiedenen Projekten arbeitet, kennt das Problem: Wie sorgt man für eine konsistente, konfliktfreie Entwicklungsumgebung?

Wir sprechen mit Stephan Hochdörfer über DDEV, ein Entwicklungswerkzeug von Platform.sh. Stephan erzählt, wie er in seiner Firma sowohl neue als auch alte Projekte erfolgreich auf DDEV umgestellt hat – und wie er damit sein Team und Freelancer überzeugt hat.

Wir klären die Docker-Compose-Grundlagen von DDEV, zeigen, wie ein Projekt aufgesetzt wird, und besprechen, welche Architekturentscheidungen DDEV so robust und gleichzeitig einfach handhabbar machen.

Außerdem hören wir von Stephan, wie DDEV es ermöglicht, neben den gängigen Sprachen wie PHP, JavaScript und TypeScript auch Java-Anwendungen und beliebige andere Webserver und Datenbanken zu unterstützen – dank Docker-Containern, Community-Erweiterungen und Framework-Integrationen.

Download

/transkript/programmierbar/deep-dive-187-ddev-mit-stephan-hochdoerfer

Jan: Hallo und herzlich willkommen zu 1 neuen DeepDive Folge hier in der programmier.bar. Heute wollen wir uns mit einem ganz interessanten Thema beschäftigen, über das ich auch schon, oh Gott, in meiner Karriere, glaub ich, mehrfach gestolpert bin, nämlich wie man das schafft, gute lokale Dev Environments irgendwie aufzusetzen. Und dafür haben wir uns einen ganz besonderen Gast in die programmier.bar eingeladen. Es gab, glaub ich, seitdem ich in dieser Techbranche hier so unterwegs bin, son paar Leute, die meinen Pfad, glaub ich, sehr geprägt haben. Der eine war Dennis, den wir auch schon hier in der Premiere hatten, mit dem haben wir über Docker und Dot Net gesprochen. Und der andere, den haben wir heute zu Gast. Stefan, Stefan Hochdörfer ist ja heute bei uns zu Gast. Hallo Stefan. Hallo. Stefan hab ich kennengelernt vor, es muss über 10 Jahre her gewesen sein. Da war ich das erste Mal in meinem Leben auf 1 User group, auf einem Meet-up für Softwareentwickler und war so angefixt, dass ich gleich beim zweiten Mal dann auch da einen Talk selber gehalten hab. Und das hat son Stein ins Rollen gebracht, der offensichtlich damit geändert ist, dass ich heute hier jetzt son Podcast über Softwareentwicklung mach. Also je nachdem, wie cool ihr das findet, dass ich hier sitze, habt ihr Stefan entweder besonders viel zu verdanken oder ihr ärgert euch heute noch über seinen Einfluss. Aber das auf alle Fälle kann ich behaupten, wenn ich damals nicht so angefixt geworden wäre, dann wär, glaub ich, meine meine Karriere sehr, sehr viel anders verlaufen. So, von daher, 1000 Dank schon mal von mir persönlich, so.
Stephan: Sehr gern, sehr gern.
Jan: Und vielleicht willst Du aber den Leuten da draußen noch erzählen, was Du eigentlich den ganzen Tag machst, wenn Du nicht diverse User groups im Rhein Main, Rhein Neckargebiet sonst wo betreust.
Stephan: Genau, also meine Reise begann, ich sag immer so schön, im letzten Jahrtausend, was Webentwicklung angeht, also ist schon sehr, sehr lange her. Habe 2003 mit Matthias, meinem Co founder BITExpert gegründet, eine Agentur aus Mannheim. Wir machen web- und mobile Entwicklungen für unsere Kunden, mittlerweile im Pro Code Bereich, im Low Code Bereich und natürlich auch KI, also der ganze ganze Themenspektrum. Meine tägliches Aufgabenfeld ist so zweigeteilt, also Tech ist immer noch das das große Thema bei mir. Also ich verantworte unsere interne Infrastruktur. Ich gucke, dass unsere Devs entwickeln können und bin immer interessiert, neue, coole Technologien zu finden, mit denen wir coole Dinge für unsere Kunden machen können. Und der zweite große Baustein ist dann das Thema Salesmarketing, also auch gucken, dass wir dann Projekte finden oder Kunden finden, die coole Projekte mit uns machen wollen. Genau, das ist so mein mein Tag und wenn da noch 'n bisschen Zeit übrig bleibt, dann organisier ich das das PHP Meet-up Rhein Neckar, das PHP Meet-up in in Frankfurt und unsere wunderbare Unkonf im Oktober.
Jan: Auch die kann man hier bestimmt mal erwähnen. Habt ihr schon 'n Datum?
Stephan: Elfter Zehnter. Ticketverkauf startet Zoom. Okay. Wo? WWW Ukunf d e.
Jan: Was ist das? So geht das. Wunderbar, wunderbar. Kann ich kann ich auch empfehlen. Wir wollten einmal sprechen über DDEV heute. DDEV ist ein Tool, das sich anschickt, das Erstellen und Verteilen von Entwicklungsumgebung zu automatisieren. Ist das fair zusammengefasst?
Stephan: Kann man sagen, ja. Das gute gute Zusammenfassung.
Jan: Du hast ja selber gesagt, so, wir haben mit der Webentwicklung angefangen im letzten Jahrtausend. Ich kann mich noch erinnern, früher Webentwicklung, ich musste irgendwie meinen Apache selber lokal installieren oder mein mein mein Mampstech, Lumpstech, was auch immer man man so benutzt hat. Dann haben wir irgendwann angefangen, so Sachen zu benutzen wie wie virtuelle Maschinen, so. Ich setz mir eine virtuelle Maschine auf pro Projekt und dann entwickle ich aber auch vielleicht in der virtuellen Maschine drin so, ja. Dann kamen so Tools wie, Vagrand, die das son bisschen vereinfachen wollten, dieses ganze VM erstellen und und konfigurieren. Dann kamen natürlich Docker und Container und jeder macht irgendwie seine eigenen Container und dieses berühmte, Du Du schiebst einfach dein Development, Environment, inproduction so, ja. Works on my Machine jetzt überall. Was was will DDEV da anders machen oder wo setzt DDEV da in dieser Kette an?
Stephan: Im Endeffekt ermöglicht es DDEF Entwicklern, die nicht so viel Docker Know how haben oder haben wollen, sehr einfach eine lokale Entwicklungsumgebung aufzusetzen in 'nem Docker Container. Das heißt, ich muss mal keine Tools mehr auf meinem Rechner installieren, hab keine Versionskonflikte, wenn man jetzt irgendwie an zig PHP Version denkt oder zig Node Versionen, die ich vielleicht dann irgendwie runterladen muss. Plus ich hab halt beliebigste Datenbanken, die ich verwenden kann, je nach Projektanforderung irgendwo. Und im Endeffekt kannst Du's dir vorstellen, es gibt Docker, auf setzt Docker Compos auf, Docker einfacher zu machen. Und DDEV setzt auf Docker Compos auf, Docker Compose einfacher zu machen. Mhm. Genau und bietet halt viele Tools intern, die dir viel Arbeit abnehmen. Beispielsweise kommt's mit 'nem mit 'nem Traffic Proxy mit, das heißt, das macht auch das Ganze SSL Handling, wenn Du's möchtest. Sobald der Traffic einmal gestartet ist, kann ich beliebig viele DDEV Projekte aufsetzen. Die nutzen alle den gleichen Traffic und hab's halt so auch einfacher dann auch mit mehreren Projekten halt gleichzeitig zu arbeiten, ohne dass ich diese Portkollisionsproblematik ja reinkomme, die ich ja zwangsweise hätte, wenn ich dann in 2, 3 Projekten halt einen Webserver hochfahren würde, der beide Alle
Jan: auf Port.
Stephan: 80 oder 4 4 3 oder 80 80, wie auch immer. Und das umgeht das Ganze.
Jan: Okay. Das heißt, ich muss aber 'n DDEV quasi einmal global installieren, damit dieser dieser Traffic läuft, damit das Tool irgendwie da ist. Und dann muss ich das pro Projekt quasi noch einmal konfigurieren.
Stephan: Richtig, genau. Du Du gehst quasi in einen Projektordner, dann dann schreibst Du, glaube ich, wenn er's grad richtig weiß. Und dann generiert er quasi diverse Konfigurationsdateien im im Jaml Format. Die kannst Du auch alle oder solltest Du alle in das ins G-Repo einchecken, dass jeder Entwickler den gleichen Stand hat. Mittlerweile ist es sogar so, Du kannst in dieser D-DeF Konfiguration angeben, welche D-DeF Version Du auch forcieren willst, sodass auch da die Entwickler den gleichen Stand haben. Konfigurierst deine Domains, die Du haben willst, deine Datenbanken und dann dann startet D-DeF. Und der der zweite große Vorteil ist, die DEF baut alle Docker Container fürs Projekt komplett neu für dich, nimmt deinen lokalen User und eine lokale User und Group ID in den Container mit rein. Das heißt, alles, was Du auf den Host zurückmoutest, hat genau deine Berechtigung. Du kannst damit arbeiten. Mhm. Kennst es ja aus vielen Projekten, Du startest jetzt mal 'n Docker Container und dann läuft da irgendwie 'n oder irgendwie 'n 'n 'n 'n WWW Data mit irgend 'ner komischen Youtube ID Und dann hast Du halt die Dateien halt als oder was und dann dann kommst Du halt lokal nicht irgendwie weiter. Und dann musst Du da immer Grätsch und Spagat machen, damit irgendwie zu arbeiten.
Jan: Ist da, fühlt sich das nur so an oder ist da auch son inherentes Risikotraining, wenn Du sagst, na ja, die Dockecontainer werden für jede lokale Installation quasi neu gebaut. Mhm. Das riecht son bisschen nach, na ja, wenn da jetzt in der Zwischenzeit die Node Version 26 1 Punkt 1 erschienen ist, dann hat vielleicht der eine Entwickler doch eine leicht abweichende Version als der andere oder so? Also wie deterministisch sind dann
Stephan: diese Builds? Genau, also sie sind schon sehr deterministisch. Also jetzt, Node oder wird im Nachgang noch mal installiert. Zumindest bei Node kannst Du, glaub ich, auch die Version relativ statisch angeben. Von daher sollte da eigentlich nicht das das Problem bestehen, dass Du da wirklich in in große Probleme reinlaufen solltest. Und alles andere, was mitkommt, x und und jetzt PHP, weil's jetzt aus der PHP Welt auch kommt, ist DDEV, ist halt dann in 'ner fixen Version erst mal im Container drin. Und damit konntest Du eigentlich wirklich gut arbeiten.
Jan: Okay. Jetzt hast Du grade schon gesagt, das kommt aus der aus der PHP Welt.
Stephan: Aber ich kann mehr als nur PHP damit machen? Genau, genau. Also originär kam's aus der Drupal Welt. Der Randy Fee, so rum. Der der Gründer von von diesem Projekt ist ist halt Trophalentwickler, hat hat nach 'ner Lösung gesucht, eben Docker in Trophal einzusetzen. Und da ist dann eben DDEV entstanden. Er hat's dann dann jahrelang mit seiner eigenen Firma irgendwie versucht, halt weiterzuentwickeln. Das ist dann irgendwann gescheitert und seit 'n paar Jahren ist er bei Plattform SH angestellt und die finanzieren ihn quasi und das Projekt. Okay. Mittlerweile kannst Du nicht nur Drupal damit machen. Wenn ich's richtig im Kopf hab, hab ich aufm am Wochenende in der Website in der DDEV Dokumentation gesehen, 20, 26 primär PHP Projekte sind aufgelistet, die die Dev kennt und damit arbeiten kann. Das heißt, die Dev versteht die Projektstruktur, jetzt zum Beispiel von Drupal, von TYPO3, von Magento, von Shopware und weiß dann, wo dir Dateien liegen, welche Konsolenkommandos es alles gibt und mapp das entsprechend alles. Du kannst aber auch komplett andere, also jetzt a PHP Projekte euch damit laufen lassen, b aber mittlerweile auch prinzipiell alles, was was irgend einen Art von Webserver hat. Also wegen vor 3 Monaten oder vor 4 Monaten wurde son generic Webserver Support integriert. Da kannst Du über auch über Kommandozahl, über über Konfigurations Dateien quasi regeln, was fürn Tool soll das aufgerufen werden, in welchem Port läuft das, wie mapt das dann auf den auf den Docker Container? Das heißt, Du kannst da Node mit Express reinhauen. Ich hab's jetzt mit Banden beispielsweise schon mal getestet. Ich hab's mit mit Springboot schon mal getestet, damit auch auch Java da im Container läuft. Also das ist jetzt mittlerweile schon sehr flexibel für
Jan: Und musst Du dann, wenn Du jetzt zum Beispiel mit 'nem Java Container arbeitest, musst Du den selber mitbringen? Oder gibt's da was von der Community oder oder wo Oder gibt's da was von der Community oder oder wo kommt das alles her, dieser Support?
Stephan: Genau. Also jetzt im im Fall von Java musst Du halt Java dann nachinstallieren in dem, was was DDEV quasi mit sich bringt. Also Du kannst es erweitern über über 'n separates Template, was Du einfach schreibst.
Jan: Und das ist Teil der Konfiguration, die mit eingecheckt wird in dein. Ja, das ist doch einmal angelegt, wenn Du und ich sag, die dürfen
Stephan: mir jetzt dieses Projekt sozusagen. Richtig, genau, genau.
Jan: Und ab dann kann ich da drin noch mehr kommen.
Stephan: Genau, also genau zu sein, es ist kein richtiges Docker File, es ist 'n Docker File Snippet, also Du fängst da nicht an mit bla bla bla, sondern Du hättest jetzt eine oder keinen, da Du setzt eine Endvariable, wie auch immer. Und DDEV dann dieses Snippet halt in In
Jan: son Standardcontainer quasi.
Stephan: Seine, in seinen DDEV, also in seinen quasi und baut damit dann das das ganze Dings zusammen. Okay. Genau. Das heißt, Du kannst da alles reininstallieren, was Du was Du irgendwie lustig bist und willst.
Jan: Okay. Und Du hast auch schon gesagt, das das kann son paar von diesen Projekten verstehen. Mhm. Was was versteht das da genau und was hilft mir das im Alltag?
Stephan: Ich kann's ja am am Beispiel jetzt von Magento oder von Symphony sagen. Also Magento gibt's zum Beispiel dann das das Binnen Magento Kommando, Seal Eye Kommando und das wird gemappt auf DDEV. Das heißt, ich kann dann schreiben, DDEV Magento. Und das ruft dann im Container die auf oder bei Symphonie die Symphonie Konsole. Das heißt, ich ich schreib aufm Host Konsole und bin dann im Container, im Webcontainer und rufe die.
Jan: Also also das ist son bisschen wie son Alias auf son.
Stephan: Im Endeffekt ist 'n Alias, richtig genau. Also Du kannst auch eigene diese Alias oder dir, diese Skripte schreiben, kannst da eigene Kommandos anlegen. Also wenn Du jetzt irgendwie einen einen Javascript Tool einsetzt oder jetzt 'n PHP Linter oder was auch immer, dann kannst Du dir son alias bauen und dann musst Du nicht immer in den Container rein, sondern Du schreibst dann immer auf dem Host d-Desv und dann den den Namen des Kommandos und dann wird das quasi ausgeführt im Container selbst. Cool. Cool. Genau.
Jan: Und was was bringt das für mich alles mit? Du hast jetzt eingangs schon gesagt, okay, Webserver, auch generisch, ne, sondern
Stephan: auch wenn Du den selber son bisschen anpasst und und Datenbanken auch. Genau, also standardmäßig kommt's mit mit MySquirl oder Postcay Support, kannst Du entsprechend Du sagst, Du willst gar keine Datenbank in deinem Projekt haben. Also wir haben beispielsweise 'n Kunden, wo wir einen ERP Connector gebaut haben, der halt dann zwischen Magento und dem ERP System sitzt. Und der ERP Connector ist 'n eigenes Repo und mit 'nem eigenen Setup brauch ich halt keine Datenbanken. Dann sag ich halt, ignorier mir die Datenbank, ich will halt einfach nur eine Webserver, dass ich halt sone abgespeckte Umgebung irgendwie habe mit, in der ich dann dann agieren kann. Darüber hinaus kannst Du diverse Add ons installieren, so nennt sich das bei bei DDEV. Das heißt 'n, 'n, 'n Vanish, 'n, MongoDB, so alles Mögliche, was es gibt. Zum Großteil bereitgestellt durch DDEVS selbst, also durch die Community oder halt von externen, die halt so ihre eigenen Repos auf GitHub machen und dann in 'nem bestimmten, in 'ner bestimmten Struktur halt diese Add ons bereitstellen müssen. Und dann kannst Du die da entsprechend dann installieren, dann werden auch die Dateien runtergeladen in ein lokales Repo abgelegt, die kannst Du wieder einchecken. Und dann hat dann jeder im Entwicklungsteam, hat halt dann den den gleichen Codestand und die gleichen Container.
Jan: Das heißt, so was könnte ich zum Beispiel auch firmeninternder nutzen, ich hab hier Genau. Weiß nicht, irgend eine ganz esoterische Datenbank oder vielleicht eine ganz Mainstream Datenbank, aber besonders konfiguriert oder so. Und dann stell ich mir quasi Richtig,
Stephan: genau, genau.
Jan: Ein ein Plug in intern zur Verfügung und dann hat jeder halt auch
Stephan: Genau, genau. Also brauchst einfach nur irgend einen, wo Du wo Du da wo Du rank kannst und dann lädt er sich den Kram da runter und dann integriert er das entsprechend. Genau.
Jan: Seid ihr auch schon mal über Projekte gestolpert, wo gesagt hast, boah, das haben wir mit dir da versucht, aber das war zu komplex, zu esoterisch,
Stephan: zu Hat er's irgendwie unbrauchbar gemacht? Tatsächlich nicht wirklich, nee. Also, bisher hat halt wirklich alles geklappt. Ich mein, wir machen natürlich relativ viel im PHP Bereich. Wir machen relativ viel im im Java- oder oder JavaScript Bereich.
Jan: Aber ich glaub dann, also ehrlicherweise hast Du dann halt auch einfach 90 Prozent da draußen erschlagen und 'n Javascript, Pipebet, PHP und Genau, genau. Genau.
Stephan: Genau. Also unsere unsere KI Leute nutzen's noch nicht für ihre KI Python Projekte beispielsweise. Das ist macht, glaub ich, in dem Kontext als auch weniger Sinn. Aber alles, was so Richtung Webanwendung geht, wüsst ich jetzt nicht, wo's da Probleme geben sollte. Also Du bist da schon sehr flexibel. Du kannst auch wirklich überall reinhängen und und alles Mögliche überschreiben, wenn Du's wirklich brauchen solltest, dass es eigentlich keine keine großen Hürde in diesen Hürden geben sollte, dass dass es nicht funktioniert.
Jan: Habt ihr schon mal versucht, wahrscheinlich nicht das auch sehr esoterisch, das mit 'nem remote Docker Server zu betreiben? Also weil normal, ne, weißt Du, die meisten füllen ja Docker bei sich lokal auf dem System aus. Ja, ja, ja. Und es gibt ja auch Setups, wo es sinnvoll sein kann, dass sowohl die Docker Registy als auch der Docker Server, der die Container ausführt, irgendwo zentral liegen und alle Entwickler eigentlich nur noch auf sonem sehr dünnen Client unterwegs sind.
Stephan: Nee, ist son Set-up.
Jan: Aber müsste eigentlich auch machen
Stephan: So Schweinereien haben wir nicht.
Jan: Aber ich mein, müsste eigentlich auch
Stephan: machen, weil
Jan: es ja nur eine Konzentration von dem Docker ist und dass der dem Deal wahrscheinlich egal ist.
Stephan: In der Theorie schon, ja. Ist 'n bisschen die Frage, wie kommst Du an die Remote Geschichte ran? Ich weiß, vor Jahren gab's mal dieses Docker Maschinen Zeugs, aber ich glaub, das lief auch noch so halbgar, bin ich mir jetzt sogar auch nicht. Das ist jetzt heute bisschen Ja,
Jan: egal.
Stephan: Okay. Bisschen Rätselraten.
Jan: Falls das da draußen jemand versucht hat, kann er sich gerne mal bei mir melden. Ich bin großer Freund von, also a vollständig automatisierten Devil of minds, das sowieso, ja? Aber ich find's auch cool, so dieser Trend hin zu so Cloud IDIs und so was, das ja auch viel auf Containern aufbaut
Stephan: Auf jeden Fall.
Jan: Aber halt auf aber halt nicht mehr zwangsweise bei dir auf der Maschine läuft, so, ja. Das stimmt, ja, ja. Das fand ich Thema. Aber deswegen sind wir hier morgen über Dieter reden. Was mich auch früh schon irgendwie an Docker so begeistert hat, war so dieser Punkt, ne, Du, ich kann halt diese Konfiguration, die ich hier hab, mein lokales Environment zusammenzubauen, kann ich auch nehmen, meinen Test und mein production Environment irgendwie zum Laufen zu bringen. Wie macht DDEV das? Oder macht es das überhaupt?
Stephan: Also es gibt eine Funktionalität, dass Du die Applikation publishen kannst, also gängige Cloud Provider. Das haben wir jetzt aber nicht genutzt, weil wir die Cloud Provider nicht verwenden. Von daher ist der Schritt tatsächlich separat bei uns, also wir bauen 'n separates mit 'nem separaten Image, deployen das dann auf auf unseren Systemen.
Jan: Und ihr könntet nicht das und Image nehmen, was DDF schon erzeugt?
Stephan: Na ja, könnte ich schon, das Der Nachteil ist natürlich, da laufen 'n Haufen Dev Tools drin, die man dann vielleicht nicht unbedingt in Produktion haben will. Das das der Nachteil. Und wem schon wie man sucht.
Jan: Wenn Du wenn Du das mit einem von diesen Cloud Provider, also wahrscheinlich wird ja zum Beispiel Plattform-SH oder so was Ja.
Stephan: Unterstützt. Gut geraten, aber ja.
Jan: Baut er dann trotzdem dafür 'n eigenständiges Image, damit eben nicht diese ganzen Development Tools und so was alles mit drin sind? Das gar nicht auch son Security Thema.
Stephan: Ja, das kann ich dir nicht sagen. Ich würde fast befürchten, dass er dir das ganze Dev Tooling da mitkopiert. Aber wie gesagt, da wir's nie eingesetzt haben, hab ich mich damit nie befasst.
Jan: Und für Tests auf CI zum Beispiel oder in meinen Pipelines oder so was?
Stephan: Na, da könntest Du's schon verwenden. Die Frage ist halt, macht wahrscheinlich mehr Sinn, dann das Produktivimage zu verwenden, weil Du dann einfach näher an dem bist, was dann auch in der Produktion läuft? Mhm. Weil ich mein, das willst Du dann eigentlich auch testen irgendwo.
Jan: Ja. Mhm. Also der der billigste und einfachste Weg wär wahrscheinlich als Teil von meiner Pipeline zu sagen, einfach so, hier, DF Start, weil ne, die ganze Konfiguration ist Teil von dem Repository und wenn es in der Pipeline
Stephan: Auto steckt Du kannst es richtig tun, ja.
Jan: Könnt ich zum Laufen bringen, aber dann kommt wahrscheinlich wieder dieses Argument vom Anfang, der ganze Container wird ja quasi für die jeweilige Installation neu gebaut und das ist wahrscheinlich grade im CI Contest sehr langwierig, ne.
Stephan: Ja, okay, das ist 'n guter Punkt, ja. Er würde dann wahrscheinlich, wenn Du's nicht cashst irgendwo, würde er das das halt dann dann jedes Mal neu bauen, ja. Ist jetzt nicht superlang im Sinne von, es dauert irgendwie Ja,
Jan: aber halb Kontakt, ja unnötig.
Stephan: Ja, ja,
Jan: natürlich, genau. Okay, okay. Habt ihr schon mal so Erweiterungen für DDEV selbst gebaut?
Stephan: Ich bin grade dran, so was zu tun. Also wir nutzen im im, ja, E-Commerce-Bereich eine eine Suchlösung, die nennt sich Galley. Relativ neues Ding auf auf API Plattformbasis und brauchen das jetzt in verschiedenen unserer E-Commerce-Projekte. Da bin ich grad dran, das als als DDEV Add on zu zu bauen, ja. Ist dem Fall jetzt 'n bisschen frulliger gewesen, weil die haben halt einen Warnisch, einen, den Webserver, dann auch das für für die für die Webapplikation, also sone riesen Riesen Rattenschwanz. Und da dann erst mal zu verstehen, wie haben Sie Ihr Setup gebaut und was hängt wie zusammen und wie transformiere ich das dann in in in in DDEV? Und die die Traffic Konfiguration, das war jetzt 'n bisschen aufwendiger, aber auf jeden Fall mach- und handelbar.
Jan: Und was beinhaltet son son Plug in dann als? Was hat er grade eben selber schon, weiß nicht, 5 Services genannt oder so was, die dann mit in dein Projekt kommen müssen. Das heißt, es ist ja mehr als nur schon mal, ich schmeiß einfach einen Container in meine irgendwie jetzt noch mit rein. Mhm. Sondern das sind ja wahrscheinlich einzelne Container Genau. Portfreigaben dazu, wie was ist da noch alles drin?
Stephan: Du kannst diese Wäsch Skripte reinpacken, dann mit deinem Service zu interagieren. Du hast dann natürlich das Docker Image logischerweise, Docker Compos Konfiguration, die dann reingemerged wird. Wenn Du jetzt son Trafficrouting brauchst, dann auch die entsprechende Traffickonfiguration, die dann auch zusammen wird, das ist so im im Großen und Ganzen. Also alles kann, nichts muss, je nachdem, wie viel Du reinpackst, packst Du rein und dann wird das halt dann entsprechend bei dir übernommen.
Jan: Jetzt hast Du so son paar Mal gesagt, ja, das wird dann halt irgendwie reingemerged in meine oder in meine Traffic Regeln und so was. Und das ist ja wahrscheinlich während der Installation relativ simpel. Also ich mein, Yummels übereinander zu mergen oder Tommels bei bei Traffic Genau. Geht ja. Kann mir DDEV auch dabei helfen, das rückgängig zu machen? Also beinhaltet ein ein ein Plug in quasi auch die Anweisung, was entfernt werden muss, wenn ich jetzt meinen Galley wieder entfernen will in dem Beispiel?
Stephan: Genau. Wenn Du ihm sagst, welche Dateien er löschen muss, dann löscht er die auch. Und dann würde er halt beim nächsten Start die jetzt Docker Compost beispielsweise neu generieren, ohne dein
Jan: Add on. Also Weil es geht nicht darum, dass quasi was rausgenommen wird aus der Docker Compost, sondern sie wird einfach quasi komplett neu gebaut ohne diese Art.
Stephan: Ja, ja, genau, genau, genau. Ja, interessant. Es ist schon clever.
Jan: Ja, weil ich hab gesagt, ne, wenn man sich anguckt, wie zum Beispiel bei bei Symphonyflex so Sachen zusammengemerged, werden da sind ja diese Pragma Marks in den Dateien dann immer drin so, Zeile 5 bis 15 gehört jetzt zu diesem Plug in und wenn Du das rausschmeißt, kannst Du diese Zeilen irgendwie löschen, so. So, mit so was hätt ich das irgendwie gerechnet, aber einfach zu sagen, na ja okay, Du schmeißt halt alles weg und merschst quasi den den Bestand einmal neu zusammen. Und Und wenn dein Plug in nicht mehr da ist, ist halt sein Einfluss auch nicht mehr da sozusagen auf das Endprodukt.
Stephan: Genau, genau.
Jan: Was ja relativ simpel eigentlich ist.
Stephan: Ich weiß jetzt noch nicht genau, ob er bei jedem Status zusammenmerged, aber er kennt, der total hat sich nicht geändert aufgrund von dem er es dann nicht macht. Ja, okay. Das das kann
Jan: nicht unser Problem sein.
Stephan: Ansonsten funktioniert's echt echt gut.
Jan: Cool. Habt ihr das grundsätzlich nur benutzt bei bei neuen Projekten oder habt ihr das auch schon in Bestandsprojekte integriert und wie war so die Erfahrung damit?
Stephan: Beides. Also da kam's jetzt auch son bisschen her vor, kurz überlegen, vor vielleicht 3, dreieinhalb Jahren musste ich in verschiedenen Projekten bei uns reinschauen und Dinge tun. Und damals war's halt wirklich so.
Jan: Sehr ominös. Ja, ja.
Stephan: Darf jetzt hier nicht so viel erzählen.
Jan: Alles alles gut.
Stephan: Und Zeit schon. Und jedes Projekt hat dann so seine eigene Art halt mit Docker und den Containern umzugehen und wo liegen Skripte und so weiter. Und das hat mich auch total genervt, da immer zu schauen, wer hat jetzt was wie konfiguriert. Und DIDEOF kannte ich schon, aber ich fand's eigentlich nie cool, weil ich mir dachte, na ja, ich hab son Alter erreicht, wo warum brauch ich noch eine Abstraktion auf noch eine Abstraktion auf noch eine Abstraktion? Und ich bin natürlich von mir aus gegangen, ich bin aus sonem son Linux Nerd, ich kann halt mit Docker umgehen. Also ich weiß, wie ich den Docker Fall schreibe, ich kenn die Implikationen und hab da natürlich fälschlicherweise gesagt, wenn ich das kann, dann kann das irgendwie jeder aus meinem Team oder jeder hat da Bock drauf.
Jan: Aber also das ist, glaub ich, 'n interessanter Punkt. Lass lass mich da kurz einhaken, weil, also ich könnte jetzt ja böse unterstellen quasi, ne. In dem Moment, wo Du DDEV einführst, nimmst Du ja quasi auch deinem Team son bisschen diese Kontaktoberfläche zu Docker weg. Und da ist es ja auch so die Frage, also kann man positiv sehen? Ist was, was sie nicht können müssen, müssen sich nicht mit beschäftigen und so weiter. Aber ist ja irgendwie auch 'n wertvoller Skill, den sie damit lernen müssen, wenn sie sich damit zwangsweise auseinandersetzen müssen, ne? Grade wenn's dann auch an Production oder andere Sachen so so rangeht. Ja,
Stephan: also kann man tatsächlich in beide Richtungen sehen. Wir haben im im im letzten Jahr einen einen Umschüler bei uns in der Firma gehabt, der 9 Monate Praktikum bei uns gemacht hat. Bisschen IT Kenntnis vorab, aber nicht wirklich nicht wirklich tief und umfangreich. Und der kam natürlich dann in der ersten Wochen auch und dachte, ich muss jetzt irgendwie Docker lernen, ich muss PHP lernen, ich muss Symphonie lernen und das irgendwie alles in 9 Monaten, dass ich da irgendwie mal sinnvoll mitarbeiten kann, ne, ja, gesagt Was
Jan: machst Du die anderen 8 Monate?
Stephan: Ja, fernab. Aber ja gesagt, pass auf, ne. Docker und Co ist erst mal alles egal. Du hast ja DDEV, Du sagst wieder Staat und dann läuft das alles. Also so kann halt jeder Entwickler irgendwie selbst entscheiden, wie tiefer da reingehen will oder halt auch nicht will. Ich mein, ich will jetzt hier überhaupt keinen Frontendentwickler Bashing treiben, aber son Frontendentwickler noch mal in diese Docker Thematik oder generell in diese devoxigere Welt reinzukriegen, ist vielleicht eher schwieriger. Weil's halt eine ganz andere Baustelle natürlich ist als als als Web Frontend Entwicklung.
Jan: Ja, und gleichzeitig geht's ja bestimmt auch in die andere Richtung, oder? Also ich mein, wenn mal das komplette Setup ist, hilft es mir vielleicht auch, dass mein Backend Entwickler sein Frontend schnell mal hochgefahren bekommt und gebaut bekommt, ohne dass er
Stephan: Genau.
Jan: Yarn und und hast Du alles nicht gesehen, irgendwie erst mal anschmeißen muss.
Stephan: Genau, genau. Du kannst auch Skripte bauen, die dann on Start-up quasi ausgeführt werden. Das heißt, der ganze Notkram wird halt schon mal kompaliert und so. Du brauchst dann die 1000 Befehle nicht selbst eintippen, die die's vielleicht braucht. Also Du kannst es schon sehr weit abstrahieren und verstecken und dann ist wieder dann ne, ist das gut oder schlecht? Sollte es natürlich irgendwie dokumentieren, das soll jeder versteht. Ja. Aber so im im im Daily Business oder so, musst Du jetzt auch nicht unbedingt jeder alles im Detail kennen, wie bau ich jetzt mein Frontend? Was sind da 1000 Möglichkeiten, die ich bei Webpack habe, ne? Also es ist halt einfach aufgesetzt, konfiguriert und es geht halt einfach.
Jan: Und wie ist es so angenommen worden dann bei euch, nachdem Du jetzt gesagt hast, na ja gut, ich hab da keine Lust mehr drauf gehabt auf diese ganzen unterschiedliche Konfiguration. Wir haben das jetzt mal vereinheitlicht. Was war die Reaktion vom Team?
Stephan: Eigentlich durchweg positiv. Also wir haben's dann bei, also ich hab's dann erst selbst in verschiedenen Projekten getestet, weil ich immer 'n bisschen bisschen so im im Lied mich sehe, dann auch Dinge zu zu auszuprobieren, zu schauen, wie könnte man sie denn sinnvoll bei uns einsetzen? Und dann haben wir's mit den ersten Projekten versucht und das hat dann echt gut funktioniert. Und da haben wir's jetzt nach und nach ausgerollt und sind jetzt auch dabei, Bestandsprojekte umzustellen. Also grad jetzt unsere Magento Projekte haben son relativ uralt spezielles Dock Setup. Jetzt auch gesagt, das macht jetzt keinen Sinn mehr, dass das irgendwie komplett getrennt ist. Wir switchen das jetzt auch alles auf auf DDEV und haben dann halt immer mehr Möglichkeiten. Genau. Mhm.
Jan: Wenn ich mir 'n so sonen fundamentalen Teil von meinem Tools Stack irgendwie umbau, ja, wie ihr jetzt quasi, da fragen sich vielleicht da draußen schon son paar Leute, na ja, wie wie nachhaltig ist es denn oder wie langfristig lebt denn dieses Projekt noch? Auf was für Biden steht das denn überhaupt? Du hast am Anfang schon gesagt, na ja, okay, Plattform s h supportet das son bisschen, ist ja auch keine kleine Firma. Aus Frankreich kommen die, glaub ich. Ja, ja, genau. Aber was ist so dein Eindruck von der Community, von dem Ökosystem? Wie wie wie groß ist das alles so, ja?
Stephan: Genau, also Randy, der Core Entwickler wird komplett von von Plattform SH bezahlt, also der ist der ist quasi safe. Es gibt parallel noch eine in den USA, die halt Spenden einsammelt von von Firmen und darüber andere Tributoren bezahlt. Also sie schauen schon, sie sind jetzt noch nicht ganz bei ihrem Ziel, das sie gesteckt haben, also 70, 80, 60, 70 Prozent von dem von dem monatlichen Geld, was Sie eigentlich gerne hätten, haben Sie schon erreicht durch durch Spenden, was schon mal nicht schlecht ist. Und da achten Sie schon sehr drauf, dass es halt auch andere gibt, die das dann auch pflegen können, weil das ist natürlich 'n riesen riesen riesenapplikation mittlerweile, ne. Also es läuft halt auf auf Linux, Windows und Mac. Es kann mit mit umgehen, mit 'nem Standard Setup, mit mit Desktop, mit mit mit mit mit mit. Gibt mittlerweile auch 'n Ticket, das das sie versuchen, hier mit mit Portman das auf die Reihe zu kriegen, was nicht ganz so einfach ist, weil da schon größere Unterschiede zu zu Docker bestehen. Also das ist schon ein ein größeres System natürlich, was was was
Jan: da im
Stephan: Hintergrund läuft. Von daher ist es mit Sicherheit auch nicht so einfach, da da reinzukommen. Aber die schauen, zumindest hab ich das Gefühl, schon sehr drauf, dass sie nicht nur auf einem Kontributor hängen, sondern dass da auch wirklich dann mehrere beteiligt sind. Von daher seh ich da schon sehr positiv in die Zukunft. Also sind auch sehr transparent, veröffentliche jeden Monat, was so passiert ist oder was sie dann auch planen. Also da kann man auch ganz gut nachverfolgen, was was ist so der aktuelle Entwicklungsstand.
Jan: Sagt 'n gutes Stichwort noch mal. Du hast eingangs schon gesagt, na ja, es kommt son bisschen aus der aus der PHP, aus aus aus Tropal heraus. Das ist jetzt mittlerweile geöffnet so für andere Sprachen oder generische Webserver. Aber wo wollen Sie denn so als großes und ganzes Sinn? Also wenn ich jetzt die die DDEV Community fragen würde, so, seid ihr fertig in Anführungszeichen, ja, oder oder fehlt euch noch irgendwas oder was wollt ihr noch erreichen? Was was würde da so kommen?
Stephan: Das ist eine gute Frage. Also ich kann es so aus meiner Sicht sagen, ich glaub, mir fehlt gar nicht mehr wirklich viel, also es tut eigentlich alles das, was es tut. Was ich ganz spannend finde oder fand und was auch den Ausschlag gegeben hab zu sagen, dass wir DDEV einsetzen, ist, es gibt auch Plug ins für verschiedene IDEs, Ph Phone beispielsweise. Und das war der totale Gamechanger, weil Du, sobald Du 'n DEF Projekt in in PHP Storm einbindest und das Plug in aktiv hast, dann erkennst die PHP Version. Es konfiguriert ja schon mal das PHP Unit im Docker Container läuft. Es konfiguriert ja die Datenbankverbindung, dass Du direkt ausm PHP Storm mal auf die Datenbank rauf kannst. Und jedes Mal, wenn Du's Projekt neu startest, wird die Konfiguration angepasst, weil Du hast natürlich den den Datenbankcontainer, der läuft halt immer aufm anderen Port irgendwo. Und das ist halt meganervig, dass halt jedes Mal, wenn Du Projekte im im PhHP Storm aufmachst, das halt umzustellen. Und das war für mich damals der totale Gamechanger, weil's halt echt supereinfach gemacht ist. Dazu kommt der der Hauptentwickler hinter dem PHPStone Plug in ist der Nico Löbler aus aus Darmstadt. Den kenn ich ganz gut über die PHP User groups, von daher hatt ich da ganz gute Connections und wusste, wenn wir mal 'n Problem haben, dann weil sie ja eigentlich rangehen kann. Und er hat auch schon gut geholfen, aber 'n blöden Bug zu beheben.
Jan: Im Podcast, nicht das gleich Nächste auch in jeder,
Stephan: weil die Du anrufen schon sagst. Aber da da genauso. Nico ist jetzt raus aus der PHP Entwicklung seit irgendwie 2, 3 Jahren. Er ist bisher in so in der in seiner Freizeit, wenn er Zeit hat, was hier und da schon mal 'n Problem war, weil natürlich, wenn's neue PHP Storm Version gibt, Du musst das Plug in neu bauen, Du kannst es vorab nicht richtig testen und dann dauert's halt Tage, kann auch mal
Jan: Wochen dauern, bis das halt alles
Stephan: gemacht ist. Ja, das ist bis das halt alles gemacht ist.
Jan: Ja, das ist ja auch dann
Stephan: ist der Freigabe Prozess dann dann durch ist. Und wenn ich's richtig im im Kopf hab, versucht jetzt Randy das auch son bisschen dieses dieses Projekt zu sich zu ziehen in in in die DDEV, in die DDEV Orga auf GitHub und und dann auch Leute zu finden, die's halt aktiver. Weil's halt schon, es ist schon verdammt cool. Und also es lief mal irgendwie 2, 3 Monate nicht und das war halt schon meganervig, ständig die Konfigurationen anzupassen, wenn Du wenn Du's Projekt neu startest. Genau. Da wird schon schon dann auch geguckt, dass dass das Ökosystem außen rum halt dann auch funktioniert. Genau, also von daher seh ich da sehr positiv in die Zukunft, dass es da auch auch sinnvoll weitergeht. Okay. Cool. Genau. Aber so meine 10 Kilometer Entfernung wie Du, ne, also zu sehr beteiligt.
Jan: Das ist echt Team. Wenn die Leute uns bis hierhin zugehört haben und aber immer noch große Skeptiker sind, Was waren denn so die ein, 2 Punkte, die TTF für euch wirklich oder also für dich oder fürs Team so fundamental erleichtert hat, wo Du sagst, okay, allein deshalb lohnt sich halt schon mal, über diesen Umstieg nachzudenken?
Stephan: Also eine auf jeden Fall, auf jeden Fall die Idee Unterstützung. Das war definitiv ein Gamechanger. Der zweite Gamechanger ist, Du Du schreibst und dann wird das ganze Projekt aufgesetzt und es läuft halt. Also Du musst dir nicht groß drüber nachdenken, wie muss ich das Composer installieren? Was muss ich wo beachten? Muss ich noch irgendwie Frontend kompalieren? Wo liegt der ganze Kram? Welche Befehlsparameter brauch ich irgendwo? Also das kann ich komplett automatisieren. Das heißt, unsere wurden deutlich verschlankt, was das angeht. Man hat's viel einfacher, mit Docker zu interagieren. Also wenn ich in den Docker Container rein möchte, irgendwas zu tun, also jetzt standardmäßig halt den den Webcontainer, schreib ich einfach nur. Und er weiß halt, standardmäßig gehst Du in den Webcontainer. Ich kann auch andere Container angeben. Ich muss halt nicht dann mit mir alle Container ausgeben lassen, die ID raussuchen und dann dann da viel machen. Ich hab mit mit Didolf Export DB und Import DB Funktionalitäten, dass ich halt Datenbanken importieren und exportieren kann, unabhängig, ob's jetzt Postquest ist, ne. Ich muss einfach nur sagen, DDDF Export DB und dann dann dammt er die Datenbank, die aktive grad raus. Das find ich auch ganz cool.
Jan: Und geht das auch für all diese dritten Datenbanken, die so über Plug ins kommen? Also es ist sone Anforderung von PDF, wenn Du 'n Datenbank Plug in bist, dann musst Du so was
Stephan: Nee, also wenn die Dritt Dritt Add ons das nicht anbieten als als separates Kommando, dann geht's tatsächlich nicht. Okay. Das wär tatsächlich, glaub ich, eine ganz coole, ganz coole Erweiterung, ja. Das stimmt.
Jan: Mhm. Genau. Ja, vielleicht generell da, wer wer ist denn da so der der Gatekeeper für diese ganzen Plugins? Also wenn ich jetzt sag, ich bau mir jetzt hier das, weiß nicht, es gibt, ich bau jetzt das Plug in, weil's das das gibt's noch nicht. Mhm. Wer wer wer lässt das denn da rein oder gibt's da überhaupt eine zentrale Registry oder kann da jeder so unabhängig was publis? Wie wie funktioniert das?
Stephan: Genau. Es gibt eine zentrale Registry, da kannst Du dann wahrscheinlich 'n stellen und dann wird das da irgendwie aufgenommen. Ansonsten kannst Du's einfach bauen und über 'n 'n 'n Git Depot URL Pfad einfach dann installieren bei dir lokal. Ja. Genau, also einfach machen, dem dem Randy irgendwie Bescheid sagen auf GitHub oder auf auf Discord irgendwie. Und dann, wenn's, gehen wir davon aus, der wird das irgendwie 'n bisschen Review und schauen, ob da alles ob da alles passt. Und dann, also ich glaub, die Hürde ist da relativ gering. Aber hab's jetzt auch nicht probiert, von daher.
Jan: Okay. Hattet ihr, Du hast vorhin von von 'nem Schüler oder von 'nem Praktik gesprochen, der das quasi schon mal gemacht hat. Aber hattet ihr jetzt schon mal so den Fall, dass ihr vielleicht mit 'nem Kunden zusammen an 'nem Projekt arbeiten musstet oder bei 'nem Kunden reinkommt seid, also also wo wo wirklich mal so sehr sichtbar war, okay, wie viel schneller geht denn der Einstieg für jemand neuen oder wie schnell arbeitet sich jemand Neues auch in dieses ganze DF Ökosystem ein? Mhm.
Stephan: Also mit Kunden tatsächlich nicht, weil in der Regel nur wir entwickeln oder wenn wir tatsächlich mal in 'nem Kundenteam drin sind, dann müssen wir uns halt dann nach deren nach deren Prozessen irgendwo richten. Wir haben jetzt mit mit verschiedenen Freelensern schon gearbeitet als als Unterstützung und keiner davon hatte die der Erfahrung und die kamen auch extrem schnell damit zurecht und konnten damit echt gut arbeiten. Also war anfangs, wie man's halt kennt, son bisschen reserviert natürlich, ne, mal gucken, was es ist. Aber da hat sich keiner irgendwie beschwert oder keiner Probleme gefunden oder so. Also es lief wirklich alles alles rund in 'nem, natürlich am Schnürchen.
Jan: Und die Dev selbst braucht aber keinen, braucht nichts lokal, also außer sich selbst natürlich lokal zu installieren. Genau. Weil es gibt ja, weiß nicht, wenn jetzt zum Beispiel die die oder so, die setzt ja quasi 'n lokales PHP und 'n lokales Komposer noch voraus. So was gibt's dann bei DDEV überhaupt nicht mehr. Mhm.
Stephan: Nee, Du brauchst, also klar, Docker Demon halt irgendwie schon mal vorinstalliert logischerweise, dann lädst Du die DEVf runter. DEVf selbst installiert sich eine eine separate Kopie von, also auch das brauchst Du nicht aufm aufm Rechner haben. Und dann war's das im Endeffekt. Also mehr brauchst Du's tatsächlich nicht. Wenn Du's unter Windows betreibst in der WSL, das ist so unser Standard Setup, dann macht's Sinn, dass Du's nicht nur in der WSL installierst und aufm Host, weil WSL, DDEV in der WSL erkennt dann, dass DDEV auch aufm Host läuft und nutzt das dann, zum Beispiel in der in der Hostdatei die die Sub Domains einzutragen, dass Du quasi dann auf die IP Adressen kommst.
Jan: Oh ja, mein, nur,
Stephan: dass das auch zustande.
Jan: Na ja, also ich bin nur, Ich glaub, ich hab's verstanden, aber es wär cool, wenn ich wenn das so ist. Also ich kann unter Windows, wenn ich DDEV sowohl unter Windows als auch in der WSL installiere und dann in der WSL mein mein Source Code liegt in meiner Linuxmaschine so, ja. Und meine IDI startet vielleicht auch aus der Linuxmaschine raus, damit sie dann hier dran ist, whatever. Aber wenn ich dann da drin 'n DDF irgendwas ausführ, dann erkennt der, ich bin hier in der WSL unter Windows und kommuniziert über, was auch immer, mit dem dem Windows Host und richtet da quasi mein ganzes networkgeschüssel für mich ein.
Stephan: Also nicht das Netzwerkgeschüssel, aber zumindest in der Hostdatei halt die Hostnamen eintragen, die Du halt den Podcast
Jan: schon mal hast, oder?
Stephan: Genau, genau, genau.
Jan: Das ist natürlich das Service.
Stephan: Ja, ja, absolut. Genau. Du kannst, also glaube ich, hab's auch noch nicht versucht, aber DDF natürlich auf der Windows Maschine selbst starten. Aber wir nutzen halt halt eigentlich primär primär die USL Geschichte irgendwo. Und das funktioniert echt gut damit.
Jan: Abgefahren.
Stephan: Na ja, deswegen sag ich ja, das ist halt schon 'n größeres Konstrukt, was er da gebaut hat. Und viele Edge Cases sind natürlich auch irgendwo abgefangen. Also da jetzt reinzukommen, wenn Du da was contributen willst, ist vielleicht dann dann tatsächlich nicht ganz so einfach.
Jan: Oder auch doch sehr einfach, weil's so viel Oberfläche gibt, weißt Du? Mhm. Also vielleicht kannst Du von dem Windows Host irgendwie, weiß ich nicht, die republik verbessern. Bei bei all diesen ganzen modernen Software Development Tools stellt sich immer die Frage, ist es in in Rust oder in Go geschrieben? Go. Ja. Okay.
Stephan: Aber ich hab keine Präferenz.
Jan: Nein, also ich auch nicht, aber gefühlt sind's ja wirklich alle in Russel in
Stephan: den Raum gegeben. Das ist richtig.
Jan: Also, andere Sachen gibt's ja nicht mehr. Ich bin ja auch ehrlicherweise froh, dass wir aus dieser Zeit raus sind, wo gefühlt alles irgendwie 'n NPX Executable war so, ja, Und alles irgendwie halb node auf meine Maschine runtergeladen hat zum zum Sachen ausführen. Und ich mein, ich hab selber nicht viel Go Erfahrung, ich hab 'n bisschen was in Rust gemacht, aber wenn die Leute damit alle zufrieden sind und es performant funktioniert und Cross Plattformen irgendwie machen kann, dann.
Stephan: Auf jeden Fall, ja. Ich bin nur froh, dass er mittlerweile Traffic verwendet und nicht mehr sone Engine-X-Proxy-Set-up. Von daher, das war meine einzige meine einzige Hürde.
Jan: Ach so, ja, genau. Dieser eine Traffic, den er irgendwie installiert hat, all deine Projekte zu managen, musst Du mich den irgendwie besonders kümmern? Gibt's da irgend 'n Edge Case, wo der mich interessieren muss oder läuft der einfach im Hintergrund Eigentlich
Stephan: nicht, eigentlich nicht, genau. Also Du kannst da 'n bisschen eingreifen. Du kannst dann kann kannst dann beispielsweise aktivieren, dass er ein bisschen mehr rauslockt, was er macht. Das war bei dieser DDF Add on Geschichte bei mir ganz gut, aber 'n bisschen zu verstehen, warum's nicht funktioniert oder was jetzt was da grad im Hintergrund passiert. Aber ansonsten läuft das Ding halt einfach und es ist gut.
Jan: Und Du hast ja auch gesagt, der macht SSL Support damit mit, also muss ja irgendwie 'n Zertifikat
Stephan: Genau, der generiert das und
Jan: installiert der dann selbst oder muss mich da am Anfang einmal drum kümmern, dass das
Stephan: Ja, das ist eine gute Frage. Das ist schon zu lange her, dass ich's gemacht habe. Ich glaube, unter Windows hat er das hat er das selbst installiert. Bin ich mir aber tatsächlich nicht ganz sicher.
Jan: Okay. Und da muss man am Anfang einmal abnicken und sagen, ja, ich vertrau dem z-vier.
Stephan: Ja, ja, genau, genau. Und dann ist es überall fein, also
Jan: Ja, okay. Ja. Das find ich ja auch immer, also ich mein, es gibt ja mittlerweile auch irgendwie viele von diesen Proxy Tunnel Tunneltools, so und so was alles, wo man auch mal schnell eine SSL Verbindung auf das eigene Projekt bekommt. Aber ist auch immer schön, wenn das lokal funktioniert und nicht Auftritte nicht
Stephan: Ja, auf jeden Fall. Also wir haben wir haben auch lange Jahre immer damit nur mit HTTP entwickelt und dann dann erst, wenn's Richtung Staging oder produktiv ging und wie's halt immer so ist, dann knallt's halt doch mal hier irgendwie oder das, dann hat irgendwer was vergessen und dann ist halt, da funktioniert's halt irgendwie nicht richtig, dann muss er wieder ran. Und so weißt Du halt schon lokal, wenn's läuft, dann läuft's auch aufm aufm Produktivsystem mit mit SSL und das alles irgendwie Also
Jan: ganz, ganz lange waren's ja irgendwie diese Kursfehler, die dich dann produktiv irgendwie rausgehauen haben, ja, weil irgendwas von irgend 'nem anderen Origin kommt und SSL dann nicht mehr so so happy ist oder sobald deine Domain über SSL aufgerufen wird, muss alles über SSL kommen und Sachen, die nicht erst, die fallen auf. Und mittlerweile, ich hatte das vor 'n paar Wochen, glaube ich, das erste Mal. Es gibt ja mittlerweile im Browser Web APIs, die nur im HTPS Kontext zur Verfügung stehen.
Stephan: Ah, okay.
Jan: Ja, wusste ich auch nicht. Interessant. Hab ich auch komplett überlesen, als ich mich eingelesen hab. Okay. Und dann haben wir hier son kleines NFC Projekt gebaut für die NTJS, als wir in Mannheim waren, haben wir son Tool gebaut, wo Du so Custom Playlists von der programmier.bar erzeugen kannst. Dann hast Du son NFC Tag dran gehalten und er schreibt es dir auf den Tag und haben mit den Leuten auf dem Badge geklebt und dann können sie zu Hause programmier.bar hören. Das war alles im Web. Und diese NFC Schnittstelle, die funktioniert halt ganz normal, aber dieser Wright Befehl, der läuft halt nur, wenn Du in 'nem HTTPS Kontext unterwegs bist, weil Security Bedenken so, ja. Und also da da ich gar nicht wusste, dass es so was gibt, sone Unterscheidung, bis ich das beim Debanken irgendwie mal gelesen hatte dann so, ja, dass das nicht immer zur Verfügung steht. Das war auch so krass. Okay. Von daher cool, wenn man mehr 'n Schadens hätte haben.
Stephan: Zugriff zu behalten, wenn irgendwann mal da son Edge Case Fehler passiert.
Jan: Ja. Okay. Ja, und ich glaube, jetzt bei diese ganzen Web GPU und Web AI Sachen, da gibt's, glaub ich, auch son paar Sachen, die dann nur in sonem Secure Kontext funktionieren. Mhm. Cool. Da haben wir, glaub ich, schon ziemlich ziemlich viel erschlagen. Meine Standardfrage am Ende ist immer, welche Frage haben wir dir nicht gestellt? So, also wo Du denkst so, da hätt ich gerne noch was zu DDEV erzählt oder wieso hat mich hierzu keiner gefragt? Das ist auch 'n sehr interessanter Aspekt, da sollte man unbedingt noch mal drüber reden.
Stephan: Ich glaube, wir haben eigentlich alles abgedeckt. Also mir fällt nichts ein, was ich mir so im Vorfeld notiert hatte geistig, was ich noch erwähnen müsste.
Jan: Cool. Dann haben wir hoffentlich 'n guten Pitch gemacht für DDEV und zukünftig viele, viele neue Leute motiviert, inspiriert, das auch mal zu probieren. Ich muss auch sagen, ich hab's erst einmal, zweimal probiert bei 'nem Projekt bei mir, aber also kommend von, wie Du halt auch sagst, ne. Ich, wenn man sich halt mit Docker auskennt, dann ist halt der Need erst mal nicht nicht ganz so groß, aber es war dann so ein Projekt, wo's einfach viel aufzusetzen. Da hab ich gesagt, okay, bevor ich mir diese Docker Konto selber zusammenschuster,
Stephan: Ja.
Jan: Lass mich doch mal deadda probieren. Und ich fand das auch sehr, sehr komfortabel so. Es war jetzt halt nur für mich, von daher kann es wahrscheinlich seine echte Stärke nur bedingt ausspielen. Ah ja. Wenn man's jetzt nicht mit jemandem teilt, den man da quasi das Leid noch mit erspart dann quasi. Aber ja, war war war cool und war, also wie gesagt, also DDEV installiert, hab ich über über Bruce, glaub ich, installiert und dann war das auch schnell da. Und dann, das Einzige, was mich damals gewurmt hat, war, dass in der Standardkonfiguration immer son MySQL mitgekommen ist, den ich nicht gebraucht hab. Und den dann wieder rauszukriegen, war son bisschen schwierig.
Stephan: Aber Ja, wenn er mal drin ist, kriegst Du, glaub ich, nicht so einfach raus, wenn ich's richtig
Jan: Deswegen war nämlich meine Frage, wer das das dann macht. Da muss man den nämlich wirklich also 'n paar Stellen entfernen, weil wenn man einfach nur Ja, da
Stephan: muss man das Projekt stoppen, wahrscheinlich alles runterfahren, alles löschen, also zumindest die die Dev Konfiguration löschen und dann neu starten.
Jan: Genau, weil ich, wie Du gesagt hast, nicht wusste, dass da einfach diese Dateien jedes Mal neu beugt. Ich hab einfach die Dogger Compost genommen, die er erstellt hat.
Stephan: Ah, okay.
Jan: Hab den Myscal Container da rausgeschmissen, hab sagt Dederv los und er war auf einmal wieder da. Das war wie sone Hydra, wo Du den Kopf abschlägst und es kommt einfach immer 'n neuer Container raus.
Stephan: Jetzt haben
Jan: wir 'n paar
Stephan: 'n paar 'n paar. Ja,
Jan: bis ich halt gemerkt hab, okay, Du musst quasi dieses Modul, dieses Plug in deaktivieren, aus der Konfiguration rausnehmen. Na ja, genau. Und dann
Stephan: Ja, das wär vielleicht auch clever, wenn Sie das in Ihrem Config Dialog irgendwie fragen würden, brauchst Du eine Datenbank? Ja, nein, welcher? Ich glaub, das wär noch ganz cool, dass Du vielleicht noch mal
Jan: Aber kommt aus diesem PHP Kontext macht das wahrscheinlich einfach Sinn, dass die Standardanforderung ist, irgend eine SQL Datenbank brauchst Du halt irgendwie schon.
Stephan: Gefühl schon, ja. Also Du machst ja Webanwendung und dann, ja, was willst Du? Also
Jan: ich hab ich wollt da halt eine Mongo haben. Ich bekomm ja so aus diesem Mongo Lager so. Und dann hatt ich ganz lange halt, eine Mongo Hunde ist ist quasi halt nichts gemacht, also. Aber ja. Lasst euch davon nicht abschrecken. Es hat trotzdem gut funktioniert und es war trotzdem supereinfach. Und ich muss sagen, allein für dieses Traffic Feature fand ich's halt megacool, so mit Domainnamen lokal arbeiten zu
Stephan: können. Total.
Jan: Nicht mehr irgendwie, ah, lokal Host 80 80 ist mein 1 Projekt, lokal Host 80 81 ist mein anderes, ist mein mein drittes Projekt so. Das irgendwie alles zu haben, einfach direkt sagen
Stephan: Und dann
Jan: kommst Du
Stephan: wieder diese Corsthematik, wenn Du vom Frontend halt halt kommst, ne. Das ist halt und das kriegst Du halt halt echt easy abgefrühstückt durch durch das Thema.
Jan: Ja, und vor allen Dingen, also das war son Feature, wo ich selber schon mal gedacht hab, also eigentlich müsst ich mir einfach lokal 'n Traffic installieren, genau das von Hand zu machen, ne, wo ich dann sone Tommeldatei von Hand pfleg und sag, Genau. So hier, da ist mein 1 Projekt, da ist mein anderes. Mach mir einfach den Reverse Proxy dafür. Und dann machst Du halt dann doch nie, weil Du immer zu faul bist und wenn DDEV das halt schon so selber mitbringt, das ist halt schon cool.
Stephan: Na ja, das und ich müsste dann müsste ja dann jedem Entwickler in meinem Team Schulen bei bringen, wie auch immer, ne. Du musst halt, als Erstes, wenn Du Rechner startest, musst halt dann der Traffic laufen irgendwie, damit's halt ordentlich funktioniert. Ja. Und so so sagt's einfach die, der Staat, entweder läuft der Traffic oder nicht und dann dann dann weiß das Ding, wie's wie's funktioniert. Also das halt nimmt ja halt schon viel, viel Arbeit ab mit, ja, nicht drüber nachdenken, sondern einfach mal machen, ne.
Jan: Das ist doch 'n gutes Stichwort. Nicht so viel drüber nachdenken, einfach mal machen. Damit können wir, glaub ich, diese DDEV Diskussion wunderbar wunderbar beenden. Aber wir sind noch nicht ganz am Ende vom Podcast, weil wir haben ja noch die, über die wir sprechen wollten.
Stephan: Ja, Du hast mich vorhin ja, ich will nicht sagen, genötigt, aber informiert, dass das ansteht und ich hab mir tatsächlich kurz überlegt, was ich hier was ich hier präsentieren kann. Und das das Sinnvollste, was mir eingefallen ist, ist der PH P Developer hatte in Dresden. Ich hab vor 'n paar Tagen
Jan: eine Mail War ich doch schon mal als Speaker. Dass sie,
Stephan: dass sie denn das Event wieder machen. Ich glaube am neunzehnten September, wenn ich's richtig weiß. Definitiv 'n ziemlich cooles Event, megacoole User Group sowieso. Also wer da irgendwie Bock hat, für sehr schlankes Geld eine coole Konferenz zu erleben, ist da definitiv gut aufgehoben.
Jan: Also ich war, wie gesagt, von vor 'n paar Jahren immer da und ich war selbst beeindruckt. Also ich würde gerne mal Ihre Budgetplanung sehen, wie Sie's schaffen, für den Ticketpreis so viel zu bieten. Weil das das war schon Weil
Stephan: sie finanzieren's zum Teil, glaub ich, quer halt, also sie haben ja 'n 'n 'n e v in Dresden und da wird's son bisschen querfinanziert, wenn ich's richtig weiß. Aber das jetzt auch nur höheren Fragen.
Jan: Ja, aber also auch damit mit 'nem, also der Verein hat ja auch keinen Käse im Keller so, ne. Also das hilft dir son bisschen, aber trotzdem war, es war cooles Rahmenprogramm, es war eine coole Location, es war gutes Catering irgendwie da. Mhm. Es war, man man man konnte nicht klagen so, ja. Als als Speaker waren wir irgendwie gut untergebracht und alles. Ich war, ist vielleicht heute nicht mehr so ganz politisch korrekt, aber ich war da eingeladen, ich weiß nicht mehr, wann das war, 20 17 oder so was, 18. Und sie haben nicht genau nachgefragt, sie haben einfach 'n Flug gebucht nach Dresden. Mhm. Und hätte auch zu fahren können, Autofahren, alles egal, okay, ich hatte 'n Flugticket. Und dann bin ich von Frankfurt nach Dresden geflogen. Und dann komm ich aus Flug aus diesem Flughafen raus. Ich weiß nicht, ob das schon mal im Flugzeug ist oder so. Und das ist ja komplett abgefahren. Also wenn man nur so Frankfurt als Flughafen kennt, der so so riesig und Du musst durch 37 Security schleus und so. In Dresden stolperst Du gefühlt aus dem Flugzeug auf den Parkplatz.
Stephan: Ja, definitiv.
Jan: Also der Flughafen ist nur son sone sehr dünne Schicht dazwischen.
Stephan: Das ist so, ne.
Jan: Und dann stand Helge da und hat mich abgeholt mitm Auto so, ja, auch Superservice so für für irgendwie die Speaker so. Auf einmal, das das hat nachhaltig Eindruck hinterlassen so. Zum einen die Einfachheit der Anreise und dass man da so von der von der Crew quasi abgeholt wurde. Fand ich alles, mit alles gut. Kann ich nur empfehlen. Grüne Veranstaltung. Ich hab ich hab einen ganz anderen Pick dabei. Ich hab einen Hardware Pick dabei, und zwar hab ich, ich weiß, hast hast Du son
Stephan: NAS zu Hause, Stefan? Nee. Nee.
Jan: Gar nicht? Okay. So, irgendwie so Heimnetzwerk, Infrastruktur, irgendwas. Ich bin in der Cloud. Ah, okay, okay. Ich bin ich bin zu Hause nicht in der Cloud. Der Hintergrund dazu ist, dass ich ganz lange mit sehr schlechtem Internet gelebt hab.
Stephan: Ja, erzähl mir mehr.
Jan: Und immer das Problem hatte, dass so diese ganzen Streamingdienste und hast Du nicht gesehen und Fotolibraries und so, das hat halt alles für mich nicht funktioniert, weil gebaffert, nicht gut runtergeladen, was auch immer. Und da hab ich sehr früh angefangen, ich glaub, es war so 20 10 oder 20 12, weil ich grad so aus der in der Uni war, zu Hause mir so irgendwie Heimnetzwerk und Storage im Netzwerk und so was alles aufzubauen. Das erste mit sonem Mac mini, den ich so gemacht hatte und so. Mittlerweile hab ich so 40 Terabyte Storage für mir zu Hause rumliegen.
Stephan: Okay.
Jan: Mein mein Nass ist so die Cloud für meine Familie, für meine Schwiegereltern, für meine Geschwister, für alle, die halt irgendwie so Zeug ablegen wollen. Ja. Und weil ich da son son großer Enthusiast von bin, hat U Green uns angeschrieben. Die machen ja auch Network Chat Storage Device haben gesagt, hey, wollt ihr hier nicht dieses Gerät mal in der in der Programme testen? Wir schicken euch das fürn paar Tage zu und dann könnt ihr damit 'n bisschen Spaß haben und dann wird uns einfach nur eure Meinung interessieren. Sie haben natürlich kein Geld dafür bezahlt. Wir bekommen da auch nichts für. Sie haben auch keinerlei Einfluss gehabt auf was wir sagen, wann wir sagen und und so weiter. Aber ich fand's mal ganz cool, mal mit was anderem zu spielen, als das, was ich sonst so hab. Mhm. Und das war schon ein ganz cooles Gerät, weil das so direkt auch in diesem media fokussierten Use Case von mir so reingefallen ist. Es kommt mit 'nem Okay. HDMI Port irgendwie. Es hat, ich kann's an meinen Fernseher anschließen, ich kann Videos entweder streamen oder direkt an am am Fernseher gucken. Es hat ordentlich Rechenpower. Es hat irgendwie 6 Threads, was irgendwie stärker ist als als mein Nass. So, jetzt, ich hab, ich konnte gar nicht genug irgendwie 4 k Streams drauf werfen, es irgendwie Okay. Ins ins Schwitzen zu bringen. Es hat, man kann es bis auf 64 Gigabyte RAM und über 100 Terabyte ausbauen. So viel Hardware hatt ich jetzt nicht ganz zu Hause rumliegen, aber es war es war ganz cool und es hat mehrere so Netzwerkanschlüsse. Ich weiß nicht, ob Du schon mal so Netzwerkbündelung gemacht hast, so ein Gerät mit 2 Ethernet Kabeln anzuschließen, dann noch mehr Wumms irgendwie zu haben. Das irgendwie alles ganz cool. Einrichtungen war war auch megaeasy und dann hab ich da einfach mal so terabyteweise Videos und und Fotos draufgeschmissen. Und das war war schon war schon cool. Also ich komm, wie gesagt, mach das macht das schon 'n bisschen länger, aber die seit Trend der letzten Jahren, dass halt diese diese nasse, die ja auch eine Weboberfläche mitbieten, wo ich halt wirklich auch Zugänge an meine Family vergeben kann und sie dann da ihre Fotos angucken und bearbeiten und Alben und so was. Also es macht so viel einfacher für mich. Und was ich außerdem noch cool fand, war, es gibt natürlich auch AI Features. AI Features dürfen ja heutzutage quasi nirgendwo mehr fehlen Und so ist es auch bei diesem Nast. Ihr könnt nämlich, je nachdem, was euer Use case ist, custom AI Modelle runterladen für das Fotolibry. Und zwar gibt's da Modelle, die quasi die Fotoindizierung supporten und euch helfen, Duplikate zu finden, Haustiere zu indizieren, bestimmte Szenen automatisch zu erkennen und vieles mehr. Und das halt alles optional. Das heißt, ihr müsst das nicht nutzen. Ihr könnt aber, wenn ihr wollt, eben diese Modelle runterladen und dann scrapen diese eure library. Dadurch. Die könnt ihr dann auch öffentlich tauschen, da wird son Link erzeugt. Den könnt ihr dann mit der Familie teilen oder mit anderen Usern, die ihr auf dem NAS angelegt habt und so könnt ihr quasi so gemeinsam an eurer Fotor library arbeiten und arbeiten lassen. Und auch da den Test direkt bestanden. Ich hab son Probeaccount gemacht meiner Frau gegeben und sagte, guck mal, ob Du dich damit zurechtfindest, so, ohne dass ich hier irgendwas was was groß erklär und und kannst Du's machen. War auch irgendwie begeistert. Und von daher so so son bisschen schade, dass ich schon was hab eigentlich, ne. Wie das wie das immer so bei bei Nerds
Stephan: wunderbar 3 Hindernis, ne.
Jan: Ja, ja, ja, wenn man immer son son neues neues Spielzeug sieht. Und hier unter uns alten alten Linuxhasen hier auch, ja, natürlich gleich mal so SSH Zugang drauf gemacht und geguckt, was da drunter ist. Da läuft halt eigentlich 'n ganz normales Debian. Okay. So, das heißt, ich konnt auch irgendwie meinen, ich benutz Tailscale für meinen VPN, weißt Du, ob Du das schon mal gehört hast, auch Ja. Minipic in meinem Pick sozusagen drin. Megacool, hab ich auch gleich installiert, für zu Hause unterwegs irgendwie drauf drauf zugreifen zu können. Bieten sie zwar auch sone eigene Cloud Lösung für an, aber ich find's immer cool, wenn das so in meinem, in meine Architektur mit mit drin ist, bei mir ist irgendwie auf allen Geräten installiert, also auf meinem Laptop, auf meinem Handy, auf meinem Server zu Hause. Ist ja auch so son bisschen, ich glaub, die machen ja auch so, wie heißt das? Wire, ich ich will immer, wirecard heißt das Wirecard, ja genau. Protokoll unten drunter. Ist ja auch eigentlich nur 'n cooles UI für eine Lösung, die es quasi schon gibt, aber
Stephan: Ah, okay, ich dachte, das ist ja was Eigenes, aber ich hab mich nie damit befasst.
Jan: Also Also ich ich dachte immer, Sie machen WireGuard und Sie betreiben halt quasi so diesen eigenen Server, der so das das Handshaking und die Koordination quasi davon alles macht, aber Sie haben kein eigenes VPN Protokoll jetzt oder sowas dafür.
Stephan: Ah, okay, okay.
Jan: Anyway, das hab ich auch drauf geschmissen, das hat auch funktioniert und dann dacht ich, ja, das ist schon cool. Docke hab ich da auch drauf installiert direkt so, ja. Okay.
Stephan: Aber mehr mehr brauchst Du dann auch nicht?
Jan: Nee, es ist wirklich so. Auf meinem alten NAS lief halt auch, also mein ganzes Heimset up Zeug, ich hab so home Assistant für meinen für meinen Smarthome und ich hatt früher Open Hub, jetzt hab ich home Assistant am Laufen, alles im im Docker Container. Das kann kann's halt an, auch einfach umziehen so einfach, ja, so dieses, warum wir auch wir auch alle Produktiv Docker nutzen, funktioniert auch privat genauso, diese Portability von irgendwie Anwendungen, ja. War war irgendwie ganz cool. Und ich muss sagen, ich bin am am Ende war ich war ich superbegeistert. Ich hab dann hab ich so gedacht, okay, ein ein Punkt in einem Punkt kann mein altes Nass vielleicht doch noch punkten, weil das war bestimmt und das war irgendwie bestimmt viel mehr wert damals. Dann hab ich mal die Preise verglichen, so, nein. Wenn man Inflationsbereich nicht die Preise vergleicht, kriegst Du einfach heute so viel mehr fürs Geld, ja? Also deswegen kostet Ist krass, ja. So Straßenpreis 600 Euro und Okay. Dafür halt 4 Bay mit zweimal Netzwerk mit irgendwie 4 USB oder so was, SD Karte, also ist ja im Prinzip ist ja 'n Rechner, so. Ja, klar. Also und dann überlegst, was Du was für das Geld alles kriegst. Also ich war war begeistert. Wer sich das auch mal angucken will, das UCREAN NAS DXP 4800 plus Serie. Gibt's auch in verschiedenen Varianten mit noch mehr Speicher und noch weniger Speicher. Könnt ich alles mal angucken. Fand ich cool. 1000 Dank an an UGreen, dass Sie uns das mal so testweise zur Verfügung gestellt haben. Und von uns bekommt's quasi eine eine Empfehlung. Vielleicht kann ich den Stefan noch überzeugen, von der Cloud aus lokale nass zu wechseln damit. Cool. So viel einmal dazu. Wenn es ansonsten noch Fragen, Rückmeldungen, Kritik, Feedback gibt, dann könnt ihr uns immer erreichen unter Podcast at Programmier Punkt bar. Ihr könnt aber auch einfach in den programmier.baren Discord Server kommen und da mit uns rumdiskutieren. Es ist viel netter als in irgendwelchen Youtube Kommentarspalten. Und wir freuen uns immer, wenn wir wenn wir von euch hören. Ansonsten danke Stefan, dass Du da warst und uns alles über DDEV erzählt hast. Sehr gern. Sehr cool. Ich hoffe, wir konnten viele Leute da draußen motivieren, sich DDEV auch mal anzuschauen. Und danke an alle da draußen, dass ihr zugehört habt und wir hören uns dann spätestens in 2 Wochen wieder zum nächsten Deep Dive. Ansonsten bis dahin.

DDEV mit Stephan Hochdörfer

Shownotes

Picks of the Day

PHP Developer Day

UGREEN DXP4800 Plus

Speaker Info

Stephan Hochdörfer