Michael Jolley joins us to talk all things containers, live coding and being bald! Michael is a Developer Advocate for Vonage with 20+ and does live coding multiple days a week on twitch as baldbeardedbuilder.

Hello, everybody, and welcome to another episode of adventuresin.net. I'm your host, Caleb Wells, and with me today is, a brand new cohost, Joel Schaubert. Hey, everyone. How are you doing? I'm doing great.

Good to be here. Good. And our guest today is the bald bearded builder, mister Michael Jolley. How are you doing? Doing great.

How are you doing? Good. Good. So, Michael, if you don't mind, I'm gonna let Joel tell us a little bit about himself since this is his first first sit in, and then we'll dive right into, your stuff. Sounds great.

Yeah. Good for me. Yeah. So I, just joined the show, this, dot net show for the first time here, and I've been programming for about 40, 42 years. Started when I was, 14 years old.

That's when I did my first program for a company. It was on a TRS 80 model 1, and it was doing some simulations of some voice digitization algorithms and that my father was working on at his company. So I found my start there and then spent probably about, oh, I don't know, maybe 8 or 9 years programming with the Microsoft Foundation classes, which was a predecessor to dot net. And since then, I've gone and become an independent consultant and dealt with all kinds of different technologies. And right now, I'm working with a friend on a Samrin for Android handheld app for people that do bids and estimates and installations of heating and air conditioning equipment in residential homes.

Cool. Very cool. Sounds like you have a wealth of knowledge to provide here. Well, we'll see. Lots of experiences, that's for sure.

We're happy to to have you with us. Looking forward to to more shows with you. So, Michael, can you tell us a little bit about yourself? Yeah. Sure.

I have been in development for about 20 years. I I was a little after the TRS 80. I think my first machine was probably the first one I really remember was a a Compaq Presario with Windows 95. I do I did have one earlier than that. I don't even know what it was.

It had the little cassette tapes, which is really high speed, you know, real through, but really got into programming probably around 95 or 96 with HTML, and there was no CSS then. There really wasn't JavaScript either. Our favorite thing was to use Blink and Marquee and and some in midi backgrounds. I remember those days, very well. Yeah.

I was actually in the air force, and I was the the techie guy in the office. And they're like, well, hey. Can you create a web page for our our division on base? And I'm like, sure. Let me see what I can figure out.

The blinky stuff doesn't really go very well with military. Alright. Right. Yeah. Can you make it spin?

That's right. Yeah. That's right. So, yeah, spent, 20 years doing custom software development, and recently I started with Vonage and Nexmo as a developer advocate. So I've been doing that for the last 5 or 6 months.

That's a lot of fun. Very cool. I understand that you, similar to, our guest last week, Mark Miller, you, live code several days a week on Twitch. That's true. Yeah.

Yeah. Mark's a good friend. Yeah. We do on Twitch at, bald bearded builder. It's, it's fun.

We go in there 3 days a week and just learn together. You know, my background is primarily with dotnet and Angular. We did that for a few months, and then I realized, you know, I'm I'm missing an opportunity to kind of expand my own knowledge. So we kinda changed up. So now the stream is just focused on learning new things, whether that's new things in dot net, whether that's Xamarin, whether that's JavaScript or Vue or React, all the plethora of new database technologies out there.

It's just playtime is what it is. I like to say we're here to have fun, and most of that time, that includes code. Cool. Good deal. So we we've got a number of things we can we can talk about today, but I noticed that you you have a a good deal of experience with containers and Docker in in particular.

Can you tell us a little bit for people who don't use them or aren't that familiar, What's the benefit of containers, and what are some of the cool stuff that that you've, done with them? Yeah. There's a couple things that are just really, you know, for those who don't know what really Docker is, my friends who are really into Docker will hate me for saying this, but it's similar to VM. However, with a VM, you're gonna abstract the hardware, like how much memory, how much CPU, that sort of thing. With a container, you're really abstracting the the operating system and getting that environment.

You don't really worry about the device, the hardware capabilities. You worry about the OS and that level as far as what's installed. But it really it's great as a way to provide a way to mimic different environments no matter where you're at. For instance, one of the things I've been giving a talk on recently is developing inside of containers. So a lot of places will use a container to maybe run their production sites or just processes.

A lot of times, microservices now are deployed via containers. But, you know, that that one phrase that all developers learns, like, the first thing to get your developer badge says, it works on my machine. You know? And, of course, none of our clients wanna ever hear that. You know, that's, like, the wrong thing to say.

Well, other developers don't wanna hear it either. That's true. That's true. I said I said it last I said it last week to one of my coworkers. Well, it was working for me.

Yeah. Yeah. Exactly. So that's the benefit of developing inside of a container is Yeah. You can actually build up an image that mimics your production environment and then have your developers bring that into, say, Versus Code, open open the code up like that.

And things that may need to be installed, I'm sure if you've onboarded someone or been onboarded, you spend that week maybe getting set up to even write a line of code. You have to get everything installed, and then you have to pull the code down from TFS or or get or wherever. Then you you finally get, you know, oh, you've gotta have this SDK or that CLI. You're ready to go. You're finally, I'm gonna work on a task and you you go to hit run, and, oh, wait.

You're supposed to have that special API key and, you have to have an environment variable with this, and there's just so much that involved. That's the benefit of a container in that instance because you can build all those settings, all those CLIs into the Docker image. So then all all the developer has to do is open up, say, Versus code, and all that stuff is just there. One example I give is doing a a Google Cloud function. I don't have Google Cloud yet, CLI on my machine, but in that container, it exists.

So I can, you know, run commands, same with the Azure CLI. I could have it just existing in that container. So when that container goes away, it's not on my machine. I haven't, you know, installed all this stuff that I have to keep patched and updated. The developer has a need to know about environment variables, that sort of stuff.

All that lives in that container and is there when he wants to work and is gone when he's done. So that's that's an interesting use case. If you were setting up something for a developer for yourself and you had, like, your SQL Server and maybe initial dataset laid in there and maybe a web server, would you put that all in one container, or would you split that up and run a couple containers? No. You you'd split that up.

You'd split that up. You'd probably want, the database in its own container. If you have a web app, front end, that's maybe its own, an API in its own. Sometimes you have, like, different teams working on those too. Right?

So maybe you have a development environment that just loads up the API for that team, then you have another image just for the front end developers to work in that. And, so in that case, they would probably use, like, a Docker Compose, which can orchestrate spinning out multiple containers at the same time and kinda automates networking those. So Gotcha. You could spend a container with your dotnetcoreapi. And then in conjunction with that container, it spends up another container with SQL Server in it.

And then those 2 are kind of on a private network together. So your connection string becomes SQL, whatever you named that container. Oh, that's great. So it actually handles all that, how the server files in React and SQL Server. Because that's a lot of that all that systems engineering work is just such a pain when you're new developer on a project trying to set up a machine.

Have y'all seen, Microsoft's e shop on containers? It's it's massive and and can be kinda nasty, but but it gives you a lot of different design patterns and methodologies, and it's all running on Docker. Right? So it's got, RabbitMQ and SQL and Angular and MVC and all these different pieces. Right?

And it and and they've got, like you said, they've got all the Compose docs to where it builds it all. This has been a year ago now, but I actually took it and I broke it down and got everything running locally, You know, the exact version of what's in Docker, and it's a heck of a lot easier to do it in Docker. It really is. It it will hand handles that when you use that Docker Compose that way, it orchestrates all that for you. So now you don't know how to do it.

Whenever somebody sets it up and gets it ready, it's it's it's almost like pressing a a Heroku button on a git repository to it up. Yeah. Yeah. You know, I actually approached this subject with my development team. It's been 2 years now, but they're they're not sold on containers in general.

And we have an interesting issue. Our old or existing code base is all classic ASP, written by the owner of the company. Right? And so it needs IS and all this other stuff. And Yes.

We're we're kind of in a unique situation there, but maybe we can we can slowly move there. I I bring it up every once in a while. That's kind of an interesting side question right there. What have you guys found is, like, the main objections people have about moving a dock or when they don't wanna do it? Well, you know, I honestly, I think there's a good bit of misinformation out there.

I think another thing is it's one more thing that they have to learn. They don't necessarily want to, or they feel it's one more thing they they don't wanna learn. Right? Those are a couple up right there. Michael, I'm sure you've you've run into a lot more questions about containers than I have, though.

I think the the main concern that people have, whether they'll admit it or not, is it just seems spooky. Mhmm. It's when I develop, a lot of times you're developing and maybe you have some hosted servers like you're talking about with IAS running. But even if you don't in your your coloed or or somewhere, you know it's still like a Windows VM with IAS running. It still feels natural to you.

You don't you don't really understand how the hardware virtualization and all that works, but to you, it feels the same. You can RDP into it and see the desktop and do whatever. With Docker, you can't do that. You could get into the terminal, but it it just feels spooky. You don't know what what's inside that thing, what's in that container.

I can't really RDP into it. It's I think it's more about the unknown. I think once you experience building an app, no matter how small, you start to realize, oh, this isn't that weird. It's actually just another tool on my tool belt. It's not necessarily you know, Docker's great, but it's not the the cure for every project either.

Right? So it's just a tool. Sometimes it's a good tool. Sometimes it's not. Yeah.

I could see that opaqueness, like, scaring some people off. So with regard to that, if you were on the team that was doing, like, the API server, so you're doing the part in the middle, and you were using the database as part of what you had to stand on top of, which completely makes sense. And then another team's doing the UI, so they're calling your API server. So if you're on that API team and now you've changed code and the UI team's gonna want that new stuff, what does the process look like then for getting them the newer containerized version of what you've got? So if you wanted to give them a containerized version of your API, that there's a couple options.

One would probably be a better separation of concerns there where the front end team isn't necessarily giving you an image that will run the API, but instead having some kind of resource that you can mock the API. Mhmm. Because for the purposes of your front end, you just needed to be able to call and receive certain bits of data, that you should be able to expect from the actual one. You you don't you don't wanna build tests on the front end for the API much like they won't build tests for you. So putting in some kind of mocked API there is probably a better idea.

If if you just, you know, felt like you had to have it, then probably the best thing to do would be to build an image and then pull that image. So in their in their environment, they would instead have a Docker Compose that says, open a container with my front end. And then for the container that has the API, rather than saying, you know, load that from this folder of source code, it would say, pull the specific image tagged, you know, whatever code slash API specific version and and orchestrate it that way. Oh, great. So your Docker build, you could actually have it sounds like you have, like, a Docker build script, and you can actually say, I'm gonna do this.

I'm gonna pull this current tag. Maybe I'll pull from master or whatever, and I want you to repackage and make me a new one. But I do like that idea of just going with, mock interfaces being the the best first step. Yeah. I think that's the best.

But, I mean, you know, you could have a situation where maybe you have a product that has nightly builds, and part of that nightly build is to spit out a specific tag of that image. So then the next day, the the front end team can come in and pull just that latest tag. Mhmm. Looks like, Y has joined us. As most of our listeners know, he's from Australia and, right, we had daylight savings time kick in, and I forgot to mention it to him.

So, hey, Wyatt. How's it going? Yeah. How are you doing? Yeah.

I'm I don't know. I I think I should have just looked at the invite. I just assumed that it was they were at the same time, but, like, lucky I wake up a bit earlier. So So that's now you're so now you're gonna have to be, up at 4:30 instead of 5:30 or something like that. That's that's, that's early.

It will normally, it's 7:30 in the morning, but 6:30. But I think at some point it becomes like 5:30. So, like yeah. Okay. So it's a good hour for 4:30.

Yeah. Well, my young kids, I'm always up, early anyway. So Right. So why we were, we were just talking with, Michael about Docker and containers and some of the things you can do with them and how you can use them with Versus Code and what kind of things you would actually put into containers and how how you would kind of segregate your your different layers, so to speak. Oh, yeah?

Cool. Nice. And we what are you guys been talking about so far? Like, like, are you using SQL Server, Linux for in containers and things? Or We haven't really talked about SQL Server and containers.

You can totally do that. How about you? I gave a talk. Well, luckily for all of us, Microsoft has official image tags for SQL Server. So it's just a matter of saying, you know, run that image and it'll fire up.

It's great. I actually gave a talk on that at dotnetconf this past year, and it's a wonderful tool to have. You know, a SQL Server is like the most attacked software on the Internet today. And don't believe me, just install it on your machine and open it up to the Internet and watch your logs and see how fast you start getting failed login attempt for SA, failed login attempt for SA, you know, over and over again. The great thing, once they install that or release that image for everybody, the first thing I did was remove SQL Server from my machine.

Right. Okay. The only thing I ever use it for is for development purposes or, like, maintenance not maintenance tasks, but still tasks for the customer. Like, we have one customer who used to send us a backup of their production database periodically and say, hey. Can you restore your testing environments with this data?

So they were very much an on prem company. Didn't wanna touch the cloud, but we, little did they know our test environment for them was in Azure. So we were using SQL Azure, and the it works great to restore a a a back file from SQL to Azure Cloud unless that back file contains a custom login. And, of course, this client had 1. So that would be like a maintenance task where somebody's gotta restore that backup locally, remove that login, back it up again, and then upload that backup to the cloud.

In that in a sense, it was perfect because I could just spin up a container with SQL, copy in that backup file, restore it inside the container, remove the login, back it back up within the container, and copy that file out from the container to my local machine, and then upload that to Azure. All that SQL is never installed on my machine. I can still SSMS into it just like it was. It's it's really handy in that regard. I don't have that attack vector on my machine, but I can still do my day to day as needed.

You can share drives on your local host machine with that container. Mhmm. So if if it's something where you're developing and you actually wanna see the database, the files left over, you could simply tell it, hey. Mount that drive over here. And when the container goes away and SQL goes away, all that, you know, master and temp and your database, those files still live there so you can play with them.

How large are some of your, SQL databases? Because I I know for us, right, we have some that are several gigs large, and we do software as a service. So we, you know, in production, we have a 1,000 clients locally. We may have 50 of them, right, to test with. So some of ours get up in the gigs.

I say some of ours. At at at Vonage now, I have none. But yeah. In in the previous life, they were they were large. For that client, it wasn't big.

They were sending us their production data, but it was just like a subset of it. Like, they had some process that would duplicate their database and then suck in the last 30 days' worth of transactions or something. So it was much smaller. So it's a lot easier to restore. But you don't actually do you actually store the, the database in the container?

Because I thought the the the container would only store the instance of this of SQL here, but do you need to So by default, it will store it in the container. But but once you kill the container, wouldn't that delete all your data? It sure would. Yeah. So when you need to try to persist the data, why would you Yeah.

Doesn't that sound like a bad idea? Actually Yeah. So And we're we're gonna add this to the show notes from his dotnetconf, and he goes through it. But it's it's an interesting way of handling it, Michael. Yeah.

Can you fill us in? Yeah. You do not. I mean, yeah, I should probably have prefixed this whole conversation with we are not talking about production. If you are running SQL Server in a database in production, shame on you.

You you deserve to be flogged. Besides the issues you would have with that data persisting, you can get around that. So I we could mount a specific directory on the host to that container and persist that data without the container being there. But containers are really meant to be just kind of transient objects. Here today, gone tomorrow, they're not made to be running 247.

It's supposed to be very capable of healing itself. You know, that's why you get into, like, Kubernetes and those sorts of services, app service fabric that maintain the life cycles of those things and and protect them and bring them up when they fail, that sort of thing. This would only be for you'd only wanna use those in development scenarios or, like, maintenance little scenarios, where you're troubleshooting. All that to say, I did use them in production one time, but it was it was a very unique use case where we were using containers. We were actually trying to run an ASP NET Core API and an Angular front end, but it was running on a Raspberry Pi connected to a little 7 inch touchscreen as basically a kiosk.

It would open Chromium full screen. You you'd never see the Raspberry Pi other than this Angular app front end that came up on the screen. But behind the scenes, it was hitting an ASP NET Core API on the Raspberry Pi that was saving into SQL and then had some background processes running that would sync it to the company's, headquarters API. So the only data on that Pi was basically whatever business transactions were happening on that device that hadn't been synced because it would constantly be cleaning itself up. So in that case, where I don't have concurrency issues with the database file, there's only that one little pie handling its little transactions.

That works okay. And it's a small enough footprint that I can install it on a pie rather than having to, you know, have a lot of resources. But That's cool. So far, that's the only use case I've found. Yeah.

Sounds fun. So I always use, for me, because I work on a well, I work on a Mac a lot of times, and I work with dot net stuff. So the using the container to use, SQL just makes things well, that's the only way you can do it, but it's really It is. Yeah. It makes it it means you can trial things a lot easier.

Like, if I wanted to trial my SQL, I could just load up the MySQL container and I think, but Mhmm. I've got a p I've recently bought a PC. So would you recommend that I install SQL to developer edition or the just use a a docker container? Or I'd I'd just pull the image. Yeah.

I'd pull the image. That that's as soon as they release the images for SQL, I think it's like 19 that's that's available now. The first thing I did was uninstall SQL locally. Yeah. I don't want any version of it on there.

I've still got, management studio. Yeah. Of course. Yeah. Right.

But, with that said Yeah. It just it it's it's just it just boots up so fast, isn't it? You know, one command and just speeds it up. One command just shuts it down kind of thing. So Yeah.

It's really easy. And and because you can mount directories on the host, you could persist data if you need it. You know, if you Yeah. Yeah. Are testing something and wanted that data available to you tomorrow, just mount the host.

It'll save the data to your hard drive. And then tomorrow, when you spin up that container, it'll connect right back to it and act like it never stopped. Yeah. That, well, that actually brings up an interesting point because I think these days, anytime you install SQL locally, right, installs the MS SQL local DB entity framework thing. Right?

Whatever. It's the it's the Mhmm. The default, right, outside of just having local. So I'm assuming in a container, you're not you're not necessarily gonna have that. So or maybe you are.

How how are you approaching that piece of it? And I know I'm getting very I'm getting down to the minutiae, but I'm just curious. You talking about connectors, like data connectors? Or Yeah. Well, like, you know, when you're in SSMS.

Right? Instead of doing local or doing MS SQL and local DB to to get to your databases, are you using an IP or Yeah. I mean, you could use local host the same. Okay. Okay.

Local host 127001, you know, all those. All the same. Okay. Yeah. See that this is coming from someone who doesn't use Docker on a regular basis.

Yeah. You can you can expose so that those those Docker ports, it has ports internally, but you can expose whatever ports you want. By default, they're all locked down and not accessible. But you may have an app inside of your container that maybe it's a web app that normally runs on port 80 because it's a web app. Right?

But on your machine, you don't necessarily want it being served up on port 80. So you could map it when you fire it up and say, you know, run what that container considers to be port 80 as port 3,000 on my machine. So then if you wanna go to that web app, you go to local host 3,000. Mhmm. At least ports the only way to communicate for a Docker container to to communicate outside of the container?

Like, can you use, like, map to a URL or something like that, or or it's just ports normally? You you, just ports. Yeah. Just ports. Yeah.

It's you're mapping it to the host, and then you would map a domain or something like that to your host. Yeah. Okay. Sure. Gotcha.

Yeah. What else do you use it for, actually? Because, for for me, that's that's my primary purpose for using Docker right now just to just for SQL Server, but I don't know why the use cases that that you can use it for in development. What have you what else do you use it for normally? Yeah.

But besides using it, for SQL Server, using it, I develop all my code inside a container now. Okay. So now I don't have to if if if client x comes to me and says, I use this I've got this project, this legacy. It was written in Python 2. Yeah.

You know? And then I've got this other client over here that says, I want something new in Python, you know, Python 3. Use Python 3 for me. Well, then I'm gonna have to install Python 2 on my machine. I'm gonna install Python 3 and, you know, just in the dot net world, somebody wants dotnetcore23, you know, you got full several flavors of the full framework up, you know, but dotnetcore.

If I go to the console now and say dotnetbuild, which one of them did it? Mhmm. Right. You know? It's it's been a while since I've had to do the commands to tell it which one to use.

Right? Yeah. Yeah. Somebody's answering me, but I don't know who. Yeah.

And you see, like, every different tool having to find their own way around that before Docker, like RVM for Ruby to manage the different Ruby versions to install the machine, and that works sometimes and sometimes it didn't. Python's a great example. The the problems between 23, been doing some Ansible programming to, the AWS cloud lately. And that's we're right there right in that whole thing. Do you want Python 2, or do you want Python 3?

That's like step 1 you're faced with. So that sounds wonderful. It's not a yeah. It's not a any language specific problem. They they all face it, and that is the benefit to building code in a container because you can say, in this container, have Python 2.

I don't have to install it locally. It's just there. So is it like running in in, like, a VM, but it's in a container? Like, it's a whole OS in the like There is. Yeah.

Mhmm. Oh, okay. Sure. Matter of fact, if so I I write a lot of my code in Versus code. Matter of fact, I can't remember the last time I opened Visual Studio at this point, probably for some Xamarin stuff.

But inside of that, I will have whatever frameworks, SDKs, CLIs installed, in that container, so I don't have to install it locally. And if actually, if you open it up in Versus Code, all my containers, whether I'm writing in c sharp or not, are Linux containers. So if you open up the terminal in Versus Code, it's bash. Yeah. Well, containers are all Linux.

Right? Is that right? Or all Docker? They're not all. There are Windows containers.

Oh, okay. They they have a heavier footprint. Right? They do. Yeah.

I think most people would agree that the Windows containers are probably not as good as Linux ones right now. Gotcha. But, yeah, the the the Linux everybody could alright. Even if it's dot net, it's it's Linux container. And it's it's interesting to see that bash command come up on my you know, I'll probably have a PowerShell window up in at the same time, but, you know and that's not even using WSL.

It's just inside that container. Right? Yeah. Oh, rest in peace, Segwin. So we have, like, things like app services, like, in Azure and stuff.

Are they just using, like, their own version of containers? Is that how all that stuff works? So like, all the cloud, like, deployment stuff. So I think I'm not, you know, an an Azure dev advocate, so I can't tell you exactly how that hardware works. But my understanding is that those app services are basically VMs.

Oh, okay. Yeah. And then with those apps are like, when you set up an app service plan, those app service plans are exit are are tied to a VM. And, of course, you can have as many app services in that app service plan as you want, you know, that don't exceed the Yeah. Limits on it.

So Right. I'm not sure if you guys discussed this before I go here. Did can do we know what the difference between a VM and a container is? Yes. Yeah.

We, we asked Michael to explain it. Because some people definitely get them confused or or mixed up. So, yeah, unless you guys have any more questions about containers, I was gonna ask Michael when he got started live coding and, you know, and kind of how he got into it and and how he approaches it. I don't know. I I feel like you're asking that very accusatory like.

Well, no. I'm I'm actually asking because, you know, I've seen Mark's Mark Miller's stream, and I have actually watched, little bit of yours. And you guys, like, you're having way too much fun doing this. So may maybe that's the accusatory tone because I'm not getting to have that fun. Yeah.

Yeah. That's true. Yeah. Mark is great. Yeah.

So I guess it would be maybe a year and a half ago. I was I don't know how in the world I found it, but I started watching Jeff Fritz, with Microsoft in his stream as c sharp Fritz. Fantastic. He just focuses on dotnet and just dotnet everything. Just had a great time.

There's a great community in there of people to chat and interaction, a lot of pair programming with Jeff, and really thought, hey. I'd love to do this myself. So around January or February of last year, really February, I went live for the first time and thought, you know what? I've got to write this code anyway. So why not just do it and see if some friends wanna join in and chat about it, maybe get some feedback from them and ideas from them?

We did that for about a month or 2 with dotnet and Angular primarily because that was the stacks I was working in. Then realized, you know, I should probably start, doing things I don't know. So we started branching out and doing a lot more JavaScript, some c plus plus you name it. If we don't know it, let's try and learn it. So in what you know, I've read the community that drew me to it and, you know, I think I would encourage a lot of people to try it or at least get involved in watching it and join that community because it's really amazing you can how you can learn that way.

I mean, it's I love watching different streamers now because I learn something new every time. Heck, even as a streamer, I learn we had somebody this is last week, I believe. We were building a a little bot on stream, and there was a specific part of it. We were gonna put in the container, and it was just going to be basically receiving webhooks. That's the only only purpose for it would be I think it was receiving webhooks and then admitting an event on socket IO.

So we're standing it up and kind of fighting some battles with that, and someone comes into chat and says, hey. Have you why not just use an Azure function as the recipient of the webhook? And Yeah. As soon as they said it, I thought, I'm a complete idiot for wasting my time on this Docker container. How did I not think of that immediately when I had this problem?

So we we dropped in the middle of the stream and immediately, you know, turned on a dime and went down that route and, implemented it. So it's it truly is pair programming. Very cool. Only with about 50 to 60 other people. Right.

Right. Well, hey, if you miss something, one of them will definitely catch it. Right? That's right. That's right.

They'll let you know. Yeah. Yeah. They're very vocal. They're not shy.

And, of course, following that, that's that actually is what precipitated my move to dev relations is, I found as much as I enjoy building things, like, some of our projects, from the past, you know, are running in, you know, Coca Cola's war room and Harley Davidson and, you know, just some big companies and some startups. But, you know, you always have that enjoyment as a developer to know, you know, this customer's using what I built and it's working. But at the same time, I know, like, as as good as I felt seeing that up on the big screen in Coke's war room in Atlanta, I realized in 5 years, it's gonna be gone. You know? And at the same time, while I was streaming, I would have people sending me Twitter DMs and Discord messages that said, hey.

You know, I really appreciate what you're doing. One was specifically talking about Docker and said, I really appreciate your streams on that because I've always felt like that was just off limits to me, but, you know, you're presented in a way that it feels approachable now. I feel like I can try it. And for me, just it, you know, that became my new win. You know, I realized I'm not exactly in the right field.

So that's what kind of precipitated that that change, that pivot. So, on Twitch, I think you guys have a group, you're called LiveCoders. LiveCoders. I'm not sure if it started by Fritz or not, but there there seem to be quite a few of you in the group. How did that come about?

There's too many. We need to send the herd. No. No. It it was started by, Jeff Fritz.

Yeah. He he started it March or April, I guess, last year, And it has just really snowballed. I don't know how many members there are. That's growing. Just I want to I know there's over a 100.

I'm not sure there's a 150 yet, but we're adding members all the time and all different languages, all different styles. If if you're, you know, Twitch is very different than YouTube. If you ever go watch YouTube, those programmers never make a mistake. Right. They've never written a bug.

You know, They've never they barely ever have to backspace. You never see Stack Overflow or Google on there. It's super polished. Right? Right.

Right. Right. Twitch is the other side. It's it's the warts you don't see on YouTube. It's a real developer writing code, so you don't get to just see, you know, someone's prowess with c sharp.

You get to see their Google fu and, their Stack Overflow, you know, capabilities. You know? Hey. This person's a pro at copy paste just like me. You know?

Yeah. The unglamorous world of programming. Right? Yeah. Yeah.

You you feel like it it kinda combats that imposter syndrome that a lot of developers have when they go and look at that stuff. And they realize, hey. You know, if if Jeff Fritz, who is just killing it over here, struggles with stuff too Yeah. Maybe I'm not so, you know, incompetent. Very good one.

Yeah. Well, you know, I've I've found right that when you can watch another developer work, especially one that that you think, you know, knows their stuff, right, and is really good at what they do, you can learn so much more from their mistakes than you can from the things they do right. Absolutely. Yeah. I agree that that I think one of the most critical skills in our industry is the ability to debug and kind of deduce what's wrong without all the information.

And and, you know, like we mentioned that sometimes that includes googling, sometimes that includes stack overflowing, sometimes just looking through documentation as much as we don't wanna read the manual. All those are skills and and kind of the reasoning of, okay. Why are you looking at that? Why did you search for that phrase? Why you know, those kind of things, putting those pieces together really improves me when I'm watching those streams to think, oh, that's an interesting approach to to take that problem apart and try to figure out what is going on there.

You know, that was one of the biggest favors another programmer did for me. We we were I was in at a large online brokerage house working on the architecture team, and this guy was sort of the architect among architects. He was just fantastic. And he would debug these really hard problems. In our environment, you could only release code every 2 weeks.

So if you had a bug hard enough, you had to write extra code to kinda trap it down. He also had on this side or this side of the fence and keep working on it. It could take you a couple months for a really hard bug. Mhmm. But he would just show us all I've got to solve, so I thought he was magic.

And I thought, well, he's magic. I'm not. And one time he, like, worked with me and showed me how many 2 week cycles it take it would take him to pin down one of these bugs. And I'm like, wow. The smartest guy in the room also has to work really, really hard if it's a difficult problem.

And that just kinda dispel this myth I had of there are some people that are just magic and everything's easy for them. No. That's true. That's I think it's a myth that we all have. Right?

And as as we start out developing, how how fortunate you were to have him willing to pour in and mentor you. You know, I think we all need to be better at that mentoring and kind of pulling up those new developers that are coming after us and and building them up. We all write bugs, you know, believe it or not, we all write bug. If you've seen my stream, you definitely know I write bugs, but, you know, so so having that, empathy for each other and and carrying each other along, you know, it really goes a long way. You know, I've actually listening to the other developers about, like, you know, we've we've all had probably years years of experience, but just sometimes you just have someone fresh in the team, and that could be, I've been someone that's a little bit inexperienced, but just having that fresh, perspective makes a big difference as well.

Alright. Well, unless you guys have any more questions, for Michael, I think we might might move on to picks. Great. And, Michael, I'm not sure if we we filled you in, but we do picks at the end of every episode, and they can be anything. They don't have to be technology related.

Right? Books, movies, music, sleep. You can pick sleep. Right? Because I don't get enough of that.

So, Joel, why don't you go go first this time around? That sounds great. So mine is just, an old classic, but it's really, really helps me a lot. And that's the f lux or flux program running on my Mac that starts to suck the blue out of the screen so I can actually get sleepy when nighttime comes. And I've been using it's amazing.

It does it kinda subtly. So sometimes I'll be working, staying up a little late, and it'll start to suck the blue out. And I look at something, and it's like, that doesn't look right. And it's like, oh, yeah. Because I'm supposed to be asleep now.

That's why it doesn't look right. So that's been that's been a great one. And then the second one I gotta say is about a year ago, I started this Xamarin project with a a friend who has a consulting company working for this HVAC company, and I was really surprised. It's not often I use a framework that you don't have some part of a bug in the framework. You gotta work around or do some adjustment.

We just literally have not found a case yet where the Xamarin for Android didn't do what it said it was gonna do. So that's been, impressively refreshing. Yeah. That that Flux application is is pretty good. So it's still into a lot of OSes now, actually.

But, yeah, they say that that blue light is what kinda keeps you up at night, and and removing that kinda makes you a bit more sleepy. And, you know, I I know I have a problem with with our program, getting back getting to sleep, you know, at night kind of things. It might that might not have anything to do with a lot, but that might just have something to do with the fact that when you're programming, you're, like, you're kind of lost in in thought and focus and things like that. But yeah, I'll I'll say too sometimes when I need to see something with the right colors and I'll say, hey, disable this for an hour or whatever, and then it puts the blue back in. If it's late, it may it can just be it feels shocking to my eyes at first.

So it's doing something good. Yeah. So, why why don't you go next? Alright. So this week's, my, pick would be a a new podcast I started listening to.

It's called, Kingpins. So it's it's kinda like this kinda like a it's a podcast, and every week it shows it talks about like a like a gangster from from like the 19 twenties or like the 19 thirties and things like that, like Al Capone. And, yes, the production quality is like really good. It's got like music and sound effects and things like that. Yeah.

I've just really started listening to it and really enjoying it. So Oh, very cool. So my pick this week, not surprising to anyone who has listened to our podcast, has to do with gaming. And I may have actually already picked this one before, but it's so good. I'm gonna do it again.

Epic games.com. They're the creators of the unreal engine and Fortnite and all kinds of other stuff. Currently, they are giving away 2 to 3 games every Thursday to anyone who has an account and goes on and basically just adds them to their list. So I think I've gotten 30 games by now for free from them. I don't know that I'll ever play any of them because I never have enough time.

But, yeah, that's my pick for for this week. Yeah. I I see that. Is it actually catch up? Because I I saw it as, like, so it's all free.

Like, there must be some Well, it's not all free. Epic, they decided they wanted to compete with Steam because Steam takes a 30% cut from the developers, and Epic said, we're gonna do one better. We'll only take 15%. And so they they've taken some market share from Steam, and I think them selling or giving away these free games is just more incentive for people to come to their store and possibly buy other games. So Cool.

I might actually do it then. I was a little bit suspicious looking at it. So I'm not gonna be free. Right? I'm like Nothing suspicious at all.

There it's on the up and up. Cool. Alright. Michael, what you got for your pick? Yes.

I've got a few of them for you. On the tech related side, I'm gonna tell you about 2, Visual Studio Code extensions. I use Gists a lot on GitHub. Whether I'm preparing a talk and wanna record the abstracts just in a a place that I can get to easily, I'll keep them there. Of course, you're doing that.

People want bios, so it's a great place. All those little code snippets you always want, but they're not super easy to edit there. The, extension is called gist. It's by Ken Howard. It's on the marketplace, and it allows you to edit your gist from within Versus Code.

Save them there. It's just so handy to have. It's kinda out of the way. You can bring up a gist while you're in another project, edit it, save it back, and be done with it. The second is another extension.

It's called remote development. It's actually a an extension by Microsoft, and it is for building inside of containers, building over WSL, or building over SSH. Really goes along in what we were talking about here today. So that's how I do it, and those are both amazing picks as far as extensions. And then for all of those bald and bearded friends out there who wanna make sure they get the closest shave, no sponsorship, by the way.

I'm just this is not an ad. First of all, you can find, them both probably I know one you can find both of them you can find on Amazon. 1 is the, Viking's Blade Chieftain double edge safety razor to get that close shave on your head, you know, get that shine really good. To get that shine, you're gonna need to use Duke Cannon beard balm and beard oil. If you go look for it, it's probably called best damn beard oil and best damn beard balm.

They're both amazing to, soften up the beard and then give you that shine on top. So for those of you with the grooming tips, there you go. Well, I can tell you right now, you definitely have an awesome bald dome, unlike mine. It's got to shine, doesn't it? Well, I was I was gonna say and and this is definitely, Plutonic.

Well Well, thank you for joining us for this episode. Ben, been a good discussion. Hopefully, people learn a little bit about Docker. Got some, good extensions to go take a look at. I'm definitely gonna check out the remote development one.

That just one sounds pretty good for me, actually. Oh, there you go. My daughter just, and I'm always just cutting pasting into the browser, etcetera. So okay. Yeah.

It's good. So I'll check it out. But we we appreciate you joining us. And Joel survived his first podcast. Yay.

Hey. Thanks for going easy on me, Caleb. It only gets harder from here. That's right. There'll be 10 push ups next time.

Alright, guys. Well, to everyone listening, you know, if you want to, find out more about us, you can go to devchat.tv. There, you can find, our Discord link and not only adventures in dot net, but a number of other awesome podcasts that come from the network. And we'll see you next time. Bye, y'all.

Bye. Bye.