Talking Drupal #318 - DDEV with Randy Fay

This is Talking Drupal, a weekly chat about the design and development from the group of people with one thing in common. We love Drupal. This is episode 318D Dev. Welcome to Talking Drupal. Today we're talking about D Dev with Randy Fe. Randy's been kicking around the Drupal world for ages, but for the last several years has been maintaining D Dev, the local and cloud development environment. Randy, welcome to the show and thank you for joining us. What fun to be here. Thank you so much. I'm Nick Lafflin and today my co-hosts are as usual. John Pagosi, what's new with you this week? Here I am everybody. So it's not so much what's new with me. It's more what's new with Talking Drupal. It's not really actually all that new. We have been posting on YouTube since the dawn of the since the dawn of the podcast. But we are approaching a milestone. We are getting up there. We're almost at a thousand subscribers, which is a milestone at least in my own head. So just asking if you're a listener right now and you subscribe to the podcast on your podcast, catch a roof choice. Maybe go over to YouTube and just hit the subscribe button and subscribe there. I'm not saying you necessarily have to watch it on there. If you don't want to, you prefer to listen. That's fine. I will say it is it is maybe more entertaining than just listening because you can see my facial expressions and you know. It's a fun thing to watch from time to time. Also, as since we're talking about the socials linked in we just created a LinkedIn page. So if you're on LinkedIn and you are so inclined, find our page and subscribe to that. We will have show related news going out there all the time. So that could be that could be a useful to some. And busy as again for the week Amy June was new with you this week. Well, you know, I live in Northern California and we don't get much of a winter, but I'm starting to prepare for it by going other places. So we have some nice vacations lined up, which is sort of exciting because new music is opening up and venues are opening up again. And I really like music and travel. We're getting ready to go to San Diego next week and see the current iteration of the grateful dead and then getting ready to go to a conference in Denver in November because bad religions playing. And I realized I don't own a jacket because I live in Northern California. So it's been this like what what what's a jacket? What does waterproof mean, you know, so that's been quite an adventure. And then work wise, I'm just lining up a good lineup for San Francisco, triple users group trying to facilitate some talks for the beginning of the New Year. And I'm really excited about the variety of talks we've had since we've been sheltering in place, you know, when. Like really valuable thing that it's added quality content from people who wouldn't normally get to come to San Francisco to visit us. So that's been pretty exciting. So I want to make sure I get all of these people I want before we go back to in person. So two two questions, Amy, I was going to ask this earlier, but what is the temperature outside there today? So I was just living by cariously through your your. But it's cold. I have a sweatshirt on and slippers, you know, so. And then as far as SF Doug goes, what is the next topic or speaker that you guys have? Valerie from rooted, rooted in Kalamuna, do a lot of nonprofit technology summits for bad camp. But that's not what she's going to be talking about. But I might as well give a plug is the one event that bad camp is having this year is the nonprofit technology summit October 28th. But Valerie's coming on and talking about how she manages like helping nonprofit websites do their thing, which will be really nice. And Martin Anderson, clutz is going to come on and talk to us about time and date. And then in January, Yergen is going to come and talk about a ECA, which is a new rules engine for Drupal 9, the event condition action module. So and then we have different things coming up like we're going to do some some talks on unit testing. We're going to talk to some talks on speaker diversity workshops before Drupal con comes up so we can get more speakers in the lineup for all of our events, you know, and we have the best well not the best, but we have a really good platform for doing that. So yeah, excited. Very cool. And Randy, thank you again for joining us. What's new with you this week? Well, it's been a crazy, crazy week. Those of you that know us know that a big part of our life has been taking care of my elderly mother for the last 10 or 12 years. She's been a very, very good person. She's been a very good person. I hope hopefully I'll be able to go see mom. This week after I get through my. 100% the place to be. It's a great, great place. I wish that I hope, if I could hope anything in these last whatever time this is, it would be that there would be some balance between her consciousness and her pain. Because so far, the pain is so much that they're just basically drugging her down to the, you know, and so her, the characteristic of her is she's very verbal, even though she's very demented, she's very verbal, and she's always delightful and wonderful, and to have her drugged out to where she can barely respond is hard and they're working hard to try to find that balance, but her pain is enormous. So we don't want her to have that. - Yeah, these types of transistors are always super difficult. And I mean, in the time of COVID, that just magnifies it. 'Cause, you know, in the normal times before, you can at least get together with family, get together with your loved one and spend some of that time together. Yeah, my heart goes up to you guys, that's really tough. I know my grandfather went through hospice and I remember, I knew you were a nurse, I knew you were a nurse, I didn't know you were a hospice nurse, but yeah, you know, thank you. I mean, what you said is true, those nurses were troopers. You know, it was very personal time for the family, obviously, but, you know, they seem to have a sixth sense for when to speak up and when to just, you know, be there for the patient. So, yeah, hopefully we hear some good news in the coming weeks from you, Randy. And I mean, that diagnoses the testing positive at that time can't imagine. I mean, again, that's a terrible timing. - Yeah, it's terrible. It's especially terrible after the whole pandemic, we did mine and we even got to, when they got this special thing called compassion care visitors, we were allowed to visit mom every day, so we put her back in, the assisted living she was in. So, we navigated the whole thing. and we're able to see her and be with her, the whole pandemic and not have that excluded problem. And then boom, the day is just as fast as I get symptoms. - Trying to transition out of a more serious topic. I feel a little awkward, we'll be on to my update for this week, we'll be on from that, but getting back to the show, my brother-in-law, I don't know if I've ever mentioned this in the show, but my brother-in-law does house clean-outs. It's one of his side jobs, so you know-- - Interval wrestling. - Yeah, so if you guys need-- - Making a mental note of that. - Yeah, so he's always coming home with these really interesting things and he sells some of the good stuff and then brings the rest of the dump or recycles it or sells it, but obviously I'm a pretty big Lego fan. He occasionally comes across, loose pieces or sets, and he always sets those aside for me. And this last week, he had a couple of, they were personally disassembled, but a couple of what looked like pretty complete sets. So I've been spending the last few days cleaning and sorting Lego sets and trying to do some detective work to find out which sets they belong to and how much of the, how much is complete. So-- - What's nice about Lego is they will send you missing pieces if you-- - Yep. - If you call them and say, hey, I'm missing Princess Leia's wig. They'll send you Princess Leia's wig. - You don't even have to call them. They have an amazing search feature on their website and you can literally buy any little tiny piece that you need. We, I had a Lego set, my son lost like one gray block and I went to, I had the book because I, you know, and I looked at the back of the book and was like, oh, there's the part number when looked it up, ordered it. They literally sent one little tiny block in a package. I think the piece was like, you know, 75 cents and the shipping was like $2. But it was great. - Yeah, I use that feature quite a bit. I mean, I don't say I lost it. If it's from a set like this or if I actually lost it, you know, I'll purchase them. But yeah, I mean, for viewers, that's where I got these about a week ago that a bunch of Lego sheep, they're like dollar and dollar 50 each. - If you're listening on the podcast, the audio right now, you could be watching on YouTube and you would have, you can see next sheep. It's a visual meme. - So we've got a module a week this week as usual. John, I think this is, I think I hear you talk about this except for Lingo Tech. I think this is the module I hear you talk about. - No way. - And we can not get through it. - Okay. - So what's module a week? - I'm, so I talked about it yesterday 'cause I was adding a feature to my website that involved the web form and I wanted that web form to have some spam protection on it. So I was asking about recapture. So recapture is just that. It's a form, form spam mechanism to help you prevent spam submissions on your forms. And when looking at recapture, I noticed that now they have, they have version two, which is like the Google, you know, you can use the Google recapture where it's like the picture, where they have version three, which seems to be, I don't know, more based on the user's actions on your website. So the module of the week is the recapture module. Not, you could also look at recapture V3. That's another version of recapture. But the recapture module basically lets you add a, you know, a recapture two forms to be able to prevent spam submissions. And it was super easy to set up even with like integrating with Google and going through it. Like I think I had it up and running and like, I don't know, 15, 20 minutes after I kind of like worked through some of my own, own like learning limitations. - I also wanted to point out for the stupe listener we talked about clean top clasery, which is also an anti spam module. But we've got to say what it did. So it's a week later, but clean top is also an anti spam module that helps block spam comments. - I'm glad to hear the recapture has come out with another version because I've used it for a lot of years before even Google bought it. But I don't use it very much, but when V2 came out, you know, with the pictures of which ones have a stop light and stuff, I can't even solve those. I never get them the first time. It's fun to use that example because literally yesterday, I was testing it and I got like where are the stop lights? And I was like, oh, here they are. But you know, I will say the one reason I went with recapture V2 versus V3 was because, you know, V3 kind of works in the background, which is great. But if it doesn't or can't, you know, make a determination or score the individual, it will go back to V2 and still prompt them with a, with a hey and check the pictures. And I don't know, for me, it felt like one extra module and one extra step, much rather just be like, hey, if you're already using Google, you click the button and it says, yeah, you're good or it gives you the pictures and you move on. - Yeah, you have to be careful with those capsules because they're not always accessible to people with for assistive technology or if you can't see the pictures. So I think recapture too allows a different alternative method. You know, you can click the sound and you can determine from sound and stuff like that. So great improvements with that one. - I mean, I have to say, Randy, whenever I fail to capture, I do have that accidental, existential crisis moment where I'm like, am I really, am I just a simulation? Am I not a human? - It makes me want to go back and like, did I really miss the picture of the curb or the picture of the tree? - I feel like, where did I go? - That's the one that makes me angry. So when it's like, okay, click on the sidewalk. You're like, okay, there's three sidewalks. So you click on the three and then three new pictures pop up. You're like, okay, one of those is a sidewalk. You click on it and then it replaces, it's like, okay, I've clicked on 14 images already. When are you gonna finally accept that I can, that I'm correct? - When you click on the right one's neck. - I finally, I really actually, I don't maintain very many sites. Just a few and they're from a long time ago and they don't matter. But I turned off all, I don't think I've not indicated submissions a long time ago 'cause it was unmanageable. So I mean, with or without Capture, it just, that's the way, more and more sites don't have any option to reply or anything. It's too bad. Too bad. Too much spam. As we said at the top of the show, this is about DDEV. Can you, can we start by, can you tell us a little bit about DDEV Rendy? What's the elevator pitch? - So DDEV is a way to work on your website on your own computer. Everybody should have a local environment to work on a website because otherwise, they're gonna screw up their production server. It's just a given. And so DDEV gives you a structured way to do that. It works the same on every operating system. It works on Windows, it works on WSL2 and Mac OS. It works on Linux, it works the same everywhere. It does a lot of the work for you and you can bring it up in just a couple of minutes. It's Docker-based, like, like, Lando and Doxel are also Docker-based. So it basically is running your site inside a little computer that is standard everywhere. - Can you give us a little bit of the backstory on DDEV admittedly? I don't actually know how DDEV got started. - Yeah, so it was started. It started, there was a company named DRAD that was trying to build a, their goal in life was to build a hosting environment. And they went through several iterations of that. But when I joined DRAD, it was about five years ago and DDEV was one little piece of the puzzle that they had. And the rest was a Kubernetes-based hosting environment. It was several generations before the one that you might have been familiar with when it got commercialized. That part, I've done so much hosting that hosting itself was kind of boring. I don't really, hosting is something I really know quite a lot about. I know a lot about Linux, I know a lot about, I've rolled my own, I've put up stuff and lots of things. But having yet another hosting product was not that interesting to me. But when I started realizing that with DDEV, with the local development piece of this, that it could let me have a different PHP version and a different MySQL version or MariaDB version for every project. So I started realizing that even though I can set up a local environment myself, just fine. I can do my own engine X, I can do my own PHP, I can do my own MySQL. It actually, it all works. It does great. It works well on Mac. You can even do it on Windows. But it's hard when you're working on more than one project that has different requirements. So if you have different PHP versions and one of your old ones stuck on PHP 5.6 and a new one wants to be PHP 8, that's not very easy when you just sling an engine X and PHP on your local machine as is. And so that's when I became a convert to the whole DDEV Docker based development environment idea was when I realized that I could have different projects running at the same time that had completely different configurations. And so that's when I got hooked. So that ability to configure different projects differently sold me on the whole thing. And eventually, after I'd spent about a year working on various things, they basically let me work just on DDEV. And so for the remaining years of the company Dread's life, I-- they sponsored me without really any requirements. Basically, they paid me a salary to just work on DDEV, to just maintain DDEV. It was incredibly generous. And I don't think it was likely that they have ever expected anything except maybe some happy thoughts from people from doing that. But that was incredible that they sponsored those years. So that's where DDEV comes from. And because of community support and just community involvement, it's just been growing all these years. So it's about-- it's about five years old now. And was it-- when it first started, was it an internal tool that they were using? Or was it always like a plan to be like a kind of an open source local development environment? Well, it was pretty-- the whole thing was pretty immature at that early time. But it was-- basically, it was all one-- it was basically all one command line tool back then. The one that would start up things on hosting and the one that would do local development. So I think the idea was that it would be an integrated local development and hosting tool. But it didn't-- to make it open source and to make it more focused, it got spun off into DDEV. Basically, as we know it, a really long time ago. And that-- because it couldn't have been open source to really use by the community until that happened. And that's been almost five years that it's been out there. So I'm fairly new to web development. I think today is my six-year, Drupal anniversary. When I first grew up doing web development, I started with Lando, because I worked for the folks at Kalamuna. And then now I work for a shop that uses Doxel, just because we have a maintainer in Doxel. What-- differ-- what makes DDEV different than those other local tools? So I think that the key thing is probably-- I have lots and lots and lots of answers, but I'll try to be sure. There's a lot of finish level in DDEV. So with DDEV, you get built-in trusted HTTPS. DDEV creates your-- DDEV will create your setting files for you. So if you're starting out a Drupal project, you just do it. A DDEV config and a DDEV start and it already works. You don't have to do any setting files by default. The performance, I think, is the overall best performance you'll get anywhere, especially now in the latest version with Mutagen Integrated. DDEV has database snapshots. So you can be working on a migration and snapshot your existing situation and then work some more and then just restore that snapshot to start back over on that. DDEV has XD bug built-in by default. No configuration required. It's just there. It also has profiling support, like XHPRoth and those kind of things. And it has explicit support for a lot more than just Drupal. So it has explicit support for the other things you might be working on, like typo three or WordPress or magento or Laravel or backdrop. So the community has been putting its input into what's important in DDEV for a lot of years now. And those get to get put in. We've made a lot of progress. And another thing I already had already mentioned is that DDEV works the same on every platform. It's tested through CI. Several hours of testing go into every push on every platform. So it gets tested on Windows and WSL2, just the same as it gets tested on macOS and Linux. If I wanted to test out DDEV, could I run it with other alongside other Docker-based tools with a conflict with those tools at all? That's a great question. Actually, Amy June made a big contribution to how that works some years ago at Drupal, Condenberg. But the answer is, I think everything works fine with all of them alongside. I know you can turn them off. And if you do a land-toe power off, then DDEV will work fine. And if you do a DDEV power off, then land-to-oh will work fine. But both land-toe and Drupal also are very careful not to step on each other's settings files. And DDEV got more careful about that one time when Amy June, and I were working on something. And she had a project that was running land-to-oh. And I said, here, we'll just do this. You won't do any harm. We'll just do it. And it'll work. And after we did it, it didn't work in land-toe because the settings files did not protect against yet being in the land-toe context. So I think both land-toe and DDEV checked context before they include any generated PHP files. But in general, people go back and forth all the time with all three of these environments and do well. Because some people like one, but their project is officially using the other, that kind of thing. So it should work fine. And remember that all three of those are Docker-based. So at the core, they should be using separate containers that have nothing to do with each other. I guess the one thing is land-toe is always trying to install its own version of Drupal-- I mean, of Docker, sorry. Land-toe is always trying to install its own version of Docker. And if you know how to avoid that, you click the advanced settings on the installer, then you can avoid that. But that's one of the problematic things is that land-toe, if you're not paying attention, might install its own version of Docker. Yeah, I guess when I asked the question, I was not suggesting that you are running DDEV and land-toe at the same time. It was more so, like, could I switch between the two in a responsible fashion of like, shut one off and then turn one on? I wouldn't be surprised if you could actually run land-toe and DDEV at the same time. I don't think you can. You do need to shut them off, because I think they both try to grab port 80. Oh. You can change the ports. OK, so you could change the ports. Yeah, because the land-toe kind of gets around that sometimes with-- because they use a separate domain that kind of handles that. But the people that I know that use both side by side, they always have to shut one off to use the other. It only makes it the pretty quick. Yeah, they're pretty quick. It feels like responsible use to me. So I'm a huge fan of Docker and all things Docker. And I'm always curious about these kind of meta projects, because with one of the things that DDEV, land-toe, dock, soldale, all I'll hope with is you have an environment that mirrors your production environment. You can make changes. You can test them and be reasonably sure that if something works locally, it's going to work in production. But when you have a tool like DDEV, where it's kind of the tool-- you're developing the tool rather than developing a website. I'm always curious about what that process is for you. So you mentioned you have CI that tests on a bunch of different platforms. But how are you writing-- what's DDEV written in? Is it a batch script? Is it Go? Is it something else? So DDEV is written in Go. And the beautiful thing about that is that Go has-- that binary isn't the exact right term. But you can build it. build on one platform, you can build your product for every other platform just with the compile. There's nothing to it. You don't have to do anything. You don't have to have anything except the binary. And so you can build the macOS and Linux and Windows binaries right from the make file on macOS or on Linux and boom, there it is, which is a great, that's a great thing about Go. The worst thing about Go is that it's separate from the community that is using this product. So it's harder for people to contribute, although lots of people have stepped up, learned a little bit of Go and made it happen. But Go is great for that. But really, even though the binary is written and go so much of DDAV has to do with the Docker files and the bash scripts and the testing scripts and all of the other little finish details that make things happen. So we have, so for example, we have ARM64 and AMD 64 images for the Docker images. Well, we have to get those all built and we have to figure out how to build multi, multi platform Docker files, all that kind of stuff that isn't going. There's an amazing amount of stuff. Do you maintain those images or images yourself? Like do you have a library open? Yeah, yeah. The official images are maintained by me. And there's, there's official images for every version of DDAV. And they're all derived from something upstream. But the whole thing about managing for ARM64 and AMD 64 so that, but I should have mentioned earlier, one distinctive thing about DDAV is it's had explicit Mac M1 support, native Mac M1 support since like a month since like a month after the M1 came out. So people really like it on the Mac M1. So you mentioned contributing to DDAV. How many people would you say are kind of on the DDAV team actively contributing? Well, the DDAV team is me. The community is a team of one bigger. What's that? It's a team of one. It's a team of one. The, there's a community. And the community is very active. The, the DDAV channel on Drupal Slack is very active. And typo 3 Slack is very active. If you look at the, at the GitHub contributions graph, it's two or three hundred different contributors. It's a lot. So, so it's good. I wish that, you know, go lang and the internals were more accessible to the PHP communities that we serve. But here we are. It works. It's good. Life is good. So I know Nick uses Docker for stuff other than web developments. I can't say that I do. I'm wondering, Randy, do you use Docker for, for things other than web development? Well, mostly I use it, you know, mostly I don't do web development. So mostly I do DDAV development. And that means testing a lot of web development environments, spinning up lots of sites and that kind of thing. But my, my web development chops are pretty sad right now. I just maintain, like I said, I maintain a few little sites. And that's about it. And I, and I try to help people out with trouble that they come up against. And a lot of times with Drupal trouble, I'll recognize the trouble because it's been the same trouble for 15 years, you know. But the, I use Docker for lots of things. So when, when somebody has a problem with just Ubuntu, I'll typically just run an Ubuntu container and see what happens. It's a lot faster than spinning up a VM. If some, if I, and of course I use Docker for all stages of the build process. So the actual go build for DDAV is actually done with a Dockerized go line container. And that, that means that no matter what the build is the same everywhere. And that's, that's a great use of Docker is to standardize build processes. So I guess standardizing build processes is a great, a great answer to that. Do you run Azure local machine Mac or Linux? Well, I have, I, right now I'm running Mac M1. And the, the main reason I'm on Mac right now is because the, the biggest feature in the latest version of DDAV is the mutagen feature, which is incredible performance enhancement on Mac. You probably heard people grumble about Docker based environments on, on Mac and how the web server will slow. And mutagen speeds that up by a lot, lot, lot. And it's, it's going very well. But I try to use what's the most likely needy support thing most of the time. And right now it's Mac. So I want to experience things before other people do. But I consider myself perfectly at home in Linux and on Windows, although I try to encourage people on Windows to use WSL 2, which is essentially Linux, it is Linux. So, but I, so I try to go back and forth with I try to be as comfortable as I can supporting everybody on their own platform. And I don't have anything bad to say about any of the platforms. I will say the sound bite there is going to be from Nick that Max are needy. There's no agenda here. Yeah. I always appreciated you at Contrib days, Randy, because you did have that extensive knowledge of all of the different platforms that people were using, which was super handy because if someone was to come into one of my contribution trainings with the Windows machine, I'd be like, well, I don't know what to tell you, but if you were there, you know, you were able to help them out a lot. So I want to shift to a listener question. Mark VanGen asked and says, I'd love to hear about the current state of the project given the change of ownership is it healthy financially? It's a great question and one that's near and dear to my heart. So probably most of you know that the company that sponsored DDA of all these years went poof in March or April or something like that. You know, it's the standard story. It doesn't make enough money. Investors get tired of it. They shut it down. It's just standard, standard story. But there was no reason for DDA to stop. So it's been maintained at the exact same velocity. The question of the financial side of things is slightly more complicated because DDA is a trademark that was owned by the company DRAD and the company fruition bought their assets. And fruition, their basic goal with the assets is to do something ongoing with that hosting environment that DDA of live was becoming. So, having fruition has been very generous about not yanking the trademark or anything like that. But their focus is on that hosting stuff. So we've been talking carefully about how to do the trademark thing and the answer is probably just going to be fruition gets acknowledged as the owner of the trademark and thank you very much and you know, comes up for fruition kind of thing. But I have started a, I have started a nonprofit foundation called the local Dev Foundation and the purpose for the, and it has a bank account, it has an EIN, it has a DUNS number and it has a Apple account, all those kinds of things. And the goal there is to make it so that we can reach toward financial sustainability. Because I know everybody in the community wants that. They want to know, can we count on this being their next year? And they also want to know how can we support it. So now that the V1.18 is out of DDA, that's been, that's my top priority. And there's an open issue for it, clarify DDA of governance and provide a way for orgs and individuals to contribute financially. So working very hard on making sure that people can contribute and that But DDEV can have a financially sustainable future. This transition from where you were and where you are now, how has your numbers changed? Not only the users, but people contributing. So I think everything has been going up in a pretty linear fashion when I look at the, you know, there's an opt in thing to send telemetry with DDEV. And all the numbers have continued to go up at a good pace. And I think that the, I think that the, I don't have any numbers for contributors, but I think the contributors, it seems to me like people have been more active and there have been more contributions. But the community is always very generous and the support that you get from the community is amazing. So, and I expect that to also solve the financial support issues. So we were very lucky this episode. We got a lot of listener questions, which was, which was great. Josh Miller said that Randy has a long history with Drupal, updating most over 16 years. So thank you for that. Josh's question was, how did your contributions start and how has it changed? And also, are you still building with Drupal? So that's, that's, that's a lot of questions. So it's always great to hear from Josh. Josh isn't an old friend and we work together back in the day, a long, long time ago. So I started building a few websites a long, long time ago, probably Drupal 4.4 or something like that and maintained some sites. But then after, you know, my wife and I went on a two and a half year bicycle trip through the Americas. And when we got done with that, I wanted to try being involved in an open source project. And I got involved. So I started just trying to contribute to Drupal and I, so I started getting into core development. I'd come across a core bug and I'd try to fix it. And then you'd have to figure out, well, what do we, how do you find the person, how do you wake up the person who would look at this? And how do you make anybody care, which is a real problem sometimes? Like, if you just drop a solution in an issue, you're nothing's ever going to happen. And you have to go find your way through the, through whatever the organization of the organization is to sort out what happens next. And Amy Junest done lots of work on trying to make that a simpler process. But it didn't used to be very simple. I'm not sure it's simple today, but just a lot better. The, anyway, I got sucked in. You know, WebChick said, when I finally got, whatever one I was working on, WebChick said, well, this has to have a test. And I'm like, there's no possible way to test that. And so I ended up, ended up writing a test finally. That got me sucked into core development. I eventually, I eventually got kind of chewed up and burned, burned out on trying to do too many things in droop, but I really tried to do too much. I tried to solve every problem that I discovered, and that could be a lot. And that's not a way to do things. So then I started writing about burnout. And then I started writing about governance. And eventually I started working kind of on the side of things, more working on, more working on things like, like infrastructure that went with Drupal. And then I ended up with the job at Drod, which kind of fit a bunch of those things together. Because knowing quite a lot about Drupal and knowing quite a lot about infrastructure and being able to put those together in a Docker world was a great thing. And I think I've already intimated the answer. I really don't maintain very many Drupal sites anymore. I only maintain Drupal sites. That's the few that I still maintain are Drupal. But I am not brave enough to take on any new ones anymore. And I do stay in the loop, especially with Drupal. Because a lot of times, it often happens that I'm the first one to discover like a core bug, because Drupal will try to update the PHP version and then I'll be testing. And there'll be a problem with the test results. And it turns out that it's Drupal or something like that. So I do have some of those early bugs, usually with a lot of versions of Drupal. So, Randy, this popped a question into my head. What was your first coding language? Was it PHP or was it something else? Probably 6502 assembler. No, basic. Basic would have been first, back in the 70s. Basic on an HP time share. My first round of college, I just had a couple of computer classes. But we had, there was an HP machine that had, with teletype writers, that we could type, you know, type in a basic program. And it was so much fun. But I didn't get into, I didn't get into programming professionally until the early 80s. And that was probably 6502 assembler and C. And we might, we did basic on the Apple too. We built a home automation system on the Apple too in the early 80s. And it would run your heating and air conditioning and turn on enough lights. Little before it's time. So John knows that we're going to go down that level now. I'm a huge fan of home automation. There we go. Was there a commercial product? Literally. It was called Tomorrow House. It was called Compu Home Systems. And I used to have a video. I still have some manuals from it. But I used to have a video of the, of me talking on the, of being interviewed by the local Denver TV station with one of the installations. It's a cool bit. Yeah, I'm actually, so I, we had a show on this about, probably about six months ago, but we talked about home assistant, which is the home automation software they use, which is also docked based, by the way. If you have those six hours of your life, go listen to that show. It's still our longer show today. It was a, we had a record over two different days and it's over two hours long. But I think even though it was not really too related, that still wouldn't have my favorite episodes. Yeah, home automation systems, you know, 40 years ago were, were something else. They were a bit ahead of their time, that's for sure. But kind of bringing things back to, to you to have a bit, you mentioned that one of the big things when you play right now is kind of flushing out that nonprofit that you talked about kind of building a robot for financial stability of the project. What are the types of things that are on the robot, either technical or non-technical for DDEV? So the, there's always an enormous amount of stuff going on behind the scenes of the build system and the testing and keeping that stuff running and maintainable, or at least maintainable by me, those kind of things. So that if you look at the V1.19 milestone on GitHub, there's a lot of stuff there. But the top one, as you said, is making sure that the governance is clear and making sure that the, that making sure that people can contribute and getting advisory group together and those kinds of things. The web-based development is a big initiative. You probably know about DrupalPod and BDEV GitPod. DrupalPod is a way, is a very Drupal.org specific way of running DDEV to solve issues on the Drupal project or on contributed projects. And that's a way to actually run DDEV in the cloud, uses GitPod. And what, what I want to do in this next round is to make it so that any project, so that with DDEV, it's easy to add GitPod support to any project so that you can develop using DDEV with any project in the cloud. And you can already do that, but I want to systematize that. And so that's, that's item number two on the next, on the next milestone. Longer term, I would love to see a gooey for DDoV. So many people can't relate to the command line. And I would love to see a gooey. But I think that I've always felt that that was too big a stretch as far as maintenance to take on with the current team of me. So it's always important to keep the project maintainable with the resources you have. Otherwise, it doesn't get maintained or doesn't get supported. But oh, I would love to see a gooey. It would help so many people. I mean, that would go ahead, Imager. I was going to say going back to that maintenance of a gooey as as assistive technology changes just keeping up with making sure that it's accessible across technology would be a huge task that I think your team of one might not be able to really not handle, but that's a pretty big task. Yeah. And I mean, that certainly would be a huge differentiator too between kind of the three or four Docker-based, triple local development systems that are out there. And I think that's the kind of thing that really drives innovation. I mean, I think it's great that there are multiple options. I think I'm sure you've pushed land owned oxo forward with some of your features and vice versa. But having none of them have a gooey that I'm aware of, you know, and having that would certainly-- I think Calibox had one at one point before they switched to lando, but it was a little clunky and-- Yeah. The GDF had one at one point too. And it might even still work. It was called DWI. But it was kind of a react-based thing built around. It actually was a runner of DW. And so it had huge performance consequence. And it was basically un maintainable and didn't have any test suite. It's just probably not the way to go. But in general, have so much complexity that you better be ready to commit to them for a long time if you're going to have one and maintain it. I know that-- I know that simply test me project. That's something that's always evolving. And one of the things that took so long to-- for that last release was making sure that that gooey was just accessible to everyone. So as we get ready to wrap the show up, we have one more-- actually, sorry, two more pieces of listener feedback slash questions. One is from our very own Stephen Cross who says he easily got DWI running on a Raspberry Pi while other tools do not run as simply. He was wondering-- and he talked about this a little bit earlier, but how has ARM adoption been? So the Mac M1 is ARM64 and the adoption is off the chart. Everybody loves it. The machines are fantastic. Dedev and Docker run great on it. So it's been great on the Mac. But there is some level of adoption in the Windows world with the-- is it the Surface Pro that's ARM64? So we have a number of contributors. Actually, the contributor who worked to make all of our images work on ARM64, he did an incredible-- Dennis Ameling, this is name-- he did incredible work working through getting ARM64 images all built for Dedev and making sure that we could solve the enormous number of problems that are required to do that. And that stuff was ready long before-- long before the M1 came out. And he was using it on his Surface Pro with ARM64. So there's a few people using it in other places than the M1, but mostly on the M1. And it mostly just works out. Most things work the same. Some things not. For example, there's no MySQL packages for ARM64. I'm struggling with that right now because I'm trying to make it so that we can support MySQL as opposed to just MariaDB on Dedev on M1. So as a follow-up to that question, you already kind of answered this in reference to the M1 chips. Josh was asking if Docker will ever work on these new, powerful processors. And if we are going to see any Docker performance improvements for the M1 and now the new chips that Apple released yesterday. So Docker actually works really, really well on the M1 on ARM64. I think what Josh is probably asking is can Docker solve the file system performance problem that has logged it on macOS. And Docker has spent enormous amount of effort and time on that. And Docker last year spent quite a bit of time trying to implement mutagen into their product into Docker desktop. And a lot of people really liked it. And I think it was clear to them that they were going to have an infinite number of support problems that would be infinitely unsolvable if they integrated that. Now, Dedev though in the latest release just a month or so ago came out with. And Dedev has a lot of work to do with mutagen integration, which makes that whole problem go away. And Dedev with mutagen is almost as fast as native Linux Docker. And so, I think it's a lot of work to do with mutagen. So, I think it's a lot of work to do with mutagen. And I think it's going to make sure that everything is consistent at stop. I'm going to make sure that everything is consistent. And so all the places where Dedev needs to check it checks for consistency at those points and runs the the mutagen command that is required to do that. And Docker couldn't do that because it doesn't know about the application. And I'm a little taken aback at how happy people are with it and how little trouble they're having. I'm really surprised to tell a little trouble they're having. So, Dedev in there a little bit. You're saying that the performance improvements because you're essentially able to control when file system updates are kind of sent back and forth between talker. That's a good that's a good description. Basically, mutagen does the file system updates asynchronously. So, by default, what happens is if something changes on the host, then mutagen will go change it in the container. If something changes in the container, mutagen will go change it on the host. So, that that process though is not very predictable. And so at certain times, you have to make sure that it's all done. And that's what Dedev does is make sure that it's all done. And as a result, the regular web serving behavior doesn't rely on syncing anything. So, when you're using any of the traditional techniques to touch a file inside the container. Means that that file has to be checked on the host. And that's why Docker file system performance is bad. And that doesn't have to happen with mutagen. So the Docker Mac performance question, Stephen notes in our show notes here is for the poor souls that won't give up on Mac and switch to Linux. However, sounds like Randy, they could just use DDEV with mutagen and stay on their Macs and be blissfully happy for the foreseeable future. People are really, really, really happy. I hope it continues to work out, but they are really happy. So they're Stephen. Hey, Linux is still the way to go. I had one final question for you, Randy. If somebody's looking to get started with DDEV, either to contribute or as a user, what's kind of the best place for them to, you know, to get started? Well, the best thing to do is just go to the DDEV docs and try the Drupal nine quick start. It'll take you like, you know, five minutes or less, just the Drupal nine quick start will just, you know, you set up, you do a DDEV composer install and there it is. And it comes up just like that. So let's play with that and understand it and they're good. Then, then join the pounded of channel on Drupal Slack. A lot of nice, nice people there. and that's the way to start. - And then every once in a while, you and Mike and Ella will have a class at a regional or local camp where you can get started in half an hour, 45 minutes too. - We bet. - Well, Randy, thank you for joining us. This has been a good episode. It's always great to have some of the tool developers that help the Jouple community on to talk about the contributions. Is there anything that you like to add as we close out the show? - Well, I just appreciate an amazing community because that's what makes DDEV happen is that wonderful community and their contributions and they're constantly trying to figure out how to make it work better for them. So the community is the thing, just like with Jouple. - So I'd also like to note that Randy's wearing a backdrop CMS t-shirt today. And our next show, our next recording next week, will be with Jen from backdrop. So a little future drop in there, put intended. Do you have questions or feedback? Reach out to Talking Drupal on Twitter with the handle Talking Drupal or via email at [email protected]. You can connect with our hosts and other listeners on Drupal Slack in the Talking Drupal channel. Our newsletter has gone through some changes. We recently added links to upcoming Drupal camps and local meetups. This week's newsletter, debuts Chad's book corner, where frequent host Chad Hester recommends books on technology, professional growth and health. Visit talkingdrupal.com/newsletter to sign up. And you can promote your Drupal camp on Talking Drupal. You can learn more about this at talkingdrupal.com/camppromall. Thank you patrons for supporting Talking Drupal, Jacob Rockowitz, James Shields, Kylinx, Cast Robert LaRue, Mike Perrag, Hawkeye Tenderval, Greg Marshall, John Aingham, Philip, Ben Linger, Aaron Minier, Patrick Kate, Peter Carrero, Mike Eason, and Stephen Cross. Your support is greatly appreciated. You can learn more about becoming a patron at talkingdrupal.com and choose becoming a patron, John Picosi. - Yeah, you did notice that my name was not in there. I'll see if it's about fixing that. - So if our listeners wanted to get in touch with you, Randy, had any follow up questions, would be the best way for them to get in touch with you? - Oh, there's that there's a thousand ways you can look at the support options on the docs. But PalmDev, for this crew, PalmDev and the Drupal Slack is the, I'm always there and there's lots of other wonderful people there. - Perfect, and Amy June, how about you? - Folks can get a hold of me with the name Volkswagen Check, V-O-L-K-S-W-A-G-E, and CH-I-C-K, and that's on Twitter, on LinkedIn, across all the appropriate Slack spaces. - John, how about you? - You can find me on all the major social networks at John Picosi, as well as Drupal.org, and you can find out about E-Pam and all the wonderful jobs we have, e-Pam.com. - And you can reach me pretty much everywhere at nextman and ICX V-A-N. - If you've enjoyed listening, we've enjoyed talking. - See you guys next week. Have a good one.