The Changelog: Software Development, Open Source - You’re just a devcontainer.json away (Interview)

Episode Date: March 1, 2023

This week we're joined by Brigit Murtaugh, Product Manager on the Visual Studio Code team at Microsoft, and we're talking about Development Containers and the Dev Container spec. Ever since we talked with Cory Wilkerson about Coding in the cloud with Codespaces we've wanted to get the Changelog.com codebase setup with a dev environment in the cloud to more easily support contributions. After getting a drive-by contribution from Chris Eggert to add a Dev Container spec to our codebase, we got curious and reached out to Brigit and asked her to come on the show to give us all the details.

What's up friends? This week on the ChangeLog, we're joined by Bridget Murtaugh, Product Manager on the Visual Studio Code team at Microsoft. We're talking about development containers and the Dev Container spec. Ever since we had Corey Wilkerson on the show, talking about coding in the Cloud with Codespaces, we wanted to get the ChangeLog.com code base set up with

a Dev environment in the cloud to more easily support contributions. After getting a drive-by contribution from Chris Eggert to add a dev container spec to our code base, we got curious. We reached out to Bridget and asked her to come on the show to give us all the details. And we also have a bonus on this show for our plus plus subscribers. But hey, if you're not a plus plus subscriber, it's too easy. changelog.com slash plus plus. A massive thank you to our friends and partners at Fastly and Fly. Those pods are fast to download globally

because Fastly, well, they're fast globally. Check them out at fastly.com and our friends at Fly help us put our app and our database closer to users. No ops. Learn more at fly.io. This episode is brought to you by our friends at Postman. Postman is an API platform for building and using APIs.

They are most known for API testing, and you may already use them, but they've built a full-featured API platform to help developers Thank you. and discoverability of APIs, they've built a full suite of tools to help teams build APIs together faster. Over 20 million developers use Postman to deliver their APIs. Plus they have a generous free tier. Start designing, developing, and testing APIs. Organize all your API development into workspaces and share those workspaces with other developers.

You can create public workspaces to collaborate with the world's developers. You can back up your work to Postman's cloud. You get their core tooling and collaboration for up to three users. Sign up and start using Postman for free today at postman.com slash changelogpod. Or for our listeners already using Postman, we encourage you to explore the entire API platform that Postman has to offer. Again, postman.com slash changelogpod. So we are joined by Bridget Murtaugh, a product manager on the Visual Studio Code team at Microsoft and one of the co-authors or the people working on the Dev Containers spec.

Bridget, welcome to the show. Thank you so much. I'm excited to be here. We are excited to have you. We're just learning about Dev Containers by way of a contributor to our changelog.com repo who wanted to hack on the repo and if you go to our repo at github.com slash the changelog slash changelog.com and you try to hack on it there's a contributing doc and it's like here's how you get all set up and it's mac os only and it's like very manual install this install that, blah, blah, blah. Kind of lame, but straightforward if you've done it before.

But if you're just a casual contributor or you're just getting started and you'd like to contribute, there's really no easy on-ramp. Until recently, when Chris Eggert, perhaps a colleague of yours, also working, he works on Azure Resource Manager, wanted to help us fix a bug. And before he could do that, he hooked us up with a devcontainer.json. And all of a sudden, boom, you could launch our repo in Codespaces

and be staring at our code and running our code super quick. And I was like, this is cool. And he pointed us to Dev Containers. We followed that trail and we found you. So here you are, here we are. I'm glad the trail led to me and we can talk today. So are we. It was awesome.

I'm glad that you agreed to join us. I think we hit you up six ways from Sunday, LinkedIn, GitHub, email, and then by way of our co-friend, Brett Cannon, who also put in a good word. And we're like, we're getting rigid on the show one way or another. I mean, you can't say no when you get that many. Well, you can say no.

Just wouldn't be polite. Yeah. You could just block us from everything and say these guys are creepy. But thankfully, you didn't. And yeah, we'd love to learn more about containers.dev, what it is and what you all are up to. You want to open up with us and just tell us what containers.dev is. Yeah, that sounds good. So anyone listening, you can go to containers.dev in your browser and you're going to see our overview spec site for the dev container specification. And like Jared was describing, dev containers are, if you haven't heard of them

before, this really awesome tool to help you get up and running with applications or projects or repos that you're working on without having to really download anything locally. Especially depending on your setup, maybe you need Docker locally, but you can also do other cloud-based environments like GitHub Codespaces, like Jared was describing. So that way you really don't even have to download or run anything locally. And essentially there's a couple of files that configure DevContainer. And so that's what was added to the changelogs repo.

So there's a devcontainer.json, which just describes the metadata about what should go into your container. And then you can also link out to a Docker file, which you may have heard of or be familiar with if you've worked with containers at all, that can talk about some other things to install or set up for your environment. And with DevContainer JSON, you can really extend it with what you want specifically for a development environment. And so with containers in general, if you've heard of them

or used them in other applications, you may think, okay, cool, that's the way to standardize what my app has when it's deployed or when it's off running in production. But there's a lot of other opportunities to standardize what your app is doing or how you're working on it earlier on from when you're developing it to doing CICD and testing. So then having a dev container now, which can have that same consistent tool set and languages, whatever your app needs from development all the way to production and testing, it really ensures that like, I know how it's running. When I'm testing it, I'm going to get that same experience that's deployed. Other teammates get that experience too, because it can all be checked directly into the source code or the repo. And it tries to kind of take away some

of the worries you may have like, oh, Linux or Docker container seems hard or complex. We really try to simplify some things with scripts or other ways that it's like, hey, Linux or Docker container seems hard or complex. We really try to simplify some things with scripts or other ways that it's like, hey, I can add this and I can add really advanced functionality, but I don't have to go learn everything about how to be a Linux scripting expert to get started. I love it conceptually. I know that when Docker first became a thing and people started using it, I thought of Docker as a thing to put production stuff in. And then I thought, well, I'll just put my development stuff in there. And then when I'm ready, I'll do like Docker go prod mode or something and I would be done.

And what I realized quickly was it wasn't the case. Like it was kind of, you could do them both, but most people use it for dev, or some people were using it for prod. Back then, really, it was dev first, and it was really cool to be able to ship your dev environment around to people via this Docker file. But what burned in my mind back then was how different dev and prod really were

with regard to the containers and, I guess, the concerns of those containers. They always seem to be slightly different, and that's something that you guys point out on the website is that dev containers and production containers often have different needs. And dev containers usually have a lot more needs. Is that right? Yeah, exactly. So you could think of if I'm opening up my favorite editor, IDE, and what am I typically using to work on my project? Like, yeah, if it's a Python app, I'm going to need Python installed. And I'm going to need that whether I'm in the process of creating my project, or if it's deployed.

But also, maybe I have some specific editor settings that I like, or maybe I have a theme, or maybe I have extensions or plugins. It'd be awesome if hey, that really helps with my development every time, especially if it's language-specific extensions that really enhance my coding experience. If I can just make sure every time I'm opening up my editor, those are already there, that saves me time and that helps if other people are working on this project too. I don't have to tell them,

oh, hey, go check out this contributing file and figure out all these extra things you need to install. It's like, hey, just make sure that you have your dev container JSON in the branch you're working on and you're good to go. That is kind of beautiful that that can work like that. I mean, it's been a while since Docker. I mean, like Docker's been around, it's gotten better, this has been more mature. And I kind of feel like the resistance is somewhat futile for this cloud world to take over our dev environments. We talked to Cora Wilkerson about a while back.

I think it was called Coding in the Clouds, honestly, with Codespaces, which is a cool title for the show. But I think ever since then, we've had this idea to get changelog.com into a Codespace or into this, like Codespaces friendly, essentially. And only until this commit to this drive-by contribution to help us are we somewhat there. And the cool thing is, is that person wanted to contribute. And I think this is really great for open source, right? Like this is not just good for like dev environments and like plugins and extensions and themes and all these extra things that make your time go fast. but also like, well, we would love to encourage folks not to just contribute, but like just to play a role in where our platform is going and where this community is going in terms of how we entertain and inform developers

over many, many years, decades now, or at least one decade. Maybe it'll be two decades, Jerry, if we're lucky, right? Round up. Decade, right? For a decade now. It started as a contribution to get into the cloud. I think this is kind of cool,

but do you feel like, maybe Jared, this is more towards you, do you feel like this is futile, this resistance towards cloud dev environments, running this thing like that? Do you think it's resistance just like, forget it? I feel like you are attacking me personally at this point, because I am resistant. Well, as Bridget will probably

point out, Codespaces is very much in the cloud insofar as you're literally running it in a browser tab, right? And that's one thing. But what this dev container thing provides is not just, it's cloud based coding, but you're still local with your with your VS code, for instance. And of course, as we talk about the spec and what your what your team's desires are for this spec is, it's more, it's gonna be more than just. It's going to be more than just VS Code. It can be more than just code spaces. Of course, Microsoft is really front-running this idea and this spec.

I do think it's probably futile because there's so much upside to the containerization, to the repeatability, to the sort of like your dev infrastructure as code, like having it all right there. And then just teamwork, you know, teamwork tends to be what makes the dream work.

I don't know. What do you think, Bridget? Is it futile? I was going to say the same thing. I was like, maybe that's too cheesy, but you said it first. Sorry. Oh, I never let a cheesy moment go by. Yeah. Oh, I never let a cheesy moment go by. Yeah, I mean, I think as well as we're seeing all these kinds of systems and tools and tooling get better, like we're seeing cloud-based environment not be something where it's like, well, like I'm probably going to lose all my work there.

It's not going to run right. It's like, no, it probably is going to be a pretty consistent, reliable experience. And then yeah, if maybe you don't have an internet connection, or there's times where, yeah, like, I don't know, maybe I just prefer to have it locally on my machine, having that same consistent dev container setups, that way, I could use it in local VS code. And what we have is called the dev containers extension, or I could even use it just on the CLIs out of any kind of editor, because what's backing the dev containers extension and what's backing GitHub Codespaces is a CLI that can read in, hey, your project has a dev container JSON.

So let's go ahead and set things up right so that way you can develop in this development container. And so we've now open sourced that CLI. So hey, no matter where you want to code, you can have a consistent dev environment anywhere. I think for me the resistance has been against layers, like adding more and more layers. And for me, especially running on a Mac, Docker was always so slow. And I know there's been a lot of work put into that. I think it's gotten faster lately.

I've just never liked the Docker dev experience. That's why I was very excited that it was going to be like a production thing and that eventually manifested, at least in terms of containers. But I just didn't want so many layers and very little upside, especially working on small or individual projects, which I often do. And so that's my resistance. But when I see the upside and when I see the effect of the layering not be as dramatic as it has been in the past, we're like, wow, it's super slow now because I'm running through Docker, whereas it could be super fast because I'm right here on my local machine.

I think that I will not be as resistant in the future as I have been in the past. At least I hope not to be. You know, I am getting older. We do get set in our ways. And a certain point, for a lot of us, at a certain point, progress just kind of goes on and we just kind of stop at a certain place. Maybe I'll get there. I don't know.

I hope not to as a developer. I was just thinking this reminds me of like a smell. Like this is something that I think Steve Jobs kind of talked about back in the day. One of the more famous kind of interviews or quotes, I'm not really sure how you describe it, but one thing he said was you have to work backwards from the user experience, right? I think this is an example of a smell like your user experience, Jared, you desired is just

not what traditionally a cloud-based environment would really give you or Docker would give you. It's sort of like as these layers. And so this is a problem that bridget you and her team i'm sure probably very keen on and very sure of because you have to work from what's the user experience we desire back from the tech versus here's dev containers and what it offers and fit it into these non-round holes you know that's really what i think comes to mind here's like how close are we to this being the i guess magic slash silver bullet did you work backward from the experience to the tech or was it tech and then hey here's this beautiful tech where's the use for it yeah i mean i think definitely starting with user feedback the users

and what we want their experience to be what we really hope to do with anything dev container related or even just beyond in general product vs code sense and all that so we first published the remote development extensions in vs code where dev containers is one of them in 2019 and that was really with the mindset of hey like we're getting this customer feedback that i want to develop in something that has maybe the tools that i already need, and I don't need to clutter my local development environment, or it can be overwhelming. Or for some of our other remote development experiences, like we have a remote SSH extension, or we have a remote WSL or Windows for subsystem for Linux extension. And so with those, it's like we also got similar feedback of, hey, I want to use the Windows subsystem for Linux,

but maybe it doesn't interface with VS Code super nicely. And I love VS Code too. What can I do? I'm always like developing on a VM or on my desktop in the office when I'm away. But it'd be great if I could just have something that's like faster and I don't have to upload and download files specifically. It's all just there already and feels more built in and more native. So I think like getting that feedback is really what sculpted of, hey, let's start investing in remote development

as that's something that people really need. And that's where the market and user needs are going. And then from there, yeah, as we design new things with dev containers and trying to make it easier

for users to use and helping them a variety of apps. It's always coming back to like, what are they asking for? What are our top feature requests and issues and all that kind of stuff? Because all this, we really work in the open as much as possible. So getting that user feedback is something we really value and we really try to incorporate it every step of the way.

Is this VS Code users is like Visual Studio Code? Is there a difference between like Visual Studio Code and VS Code? Same thing. It's if you want to write out the whole name of Visual Studio Code, you totally can. VS Code is the same. When did it merge? Wasn't there like a paid version that wasn't open source? Well, it was Visual Studio. Visual Studio is a separate IDE.

Right. Okay. Such a confusing thing for me. I'm still, see, I'm still unclear to this moment right now. Clarity. Yeah. Yeah, it's tough because it broke off of Visual Studio, which was Microsoft's big IDE. Still exists today, right?

It's still progressing. But VS Code, Visual Studio Code, we remember the story of VS Code, Adam. We told it back in the day at Microsoft Build. Bridget, perhaps we have you here. We have a VS Code representative with us. Maybe you can dispel this notion that I've floated into the ether before. As VS Code continues to get better, but also just get more stuff more and more and more and more and more is like, is there a future where

VS code is basically an IDE? Like, is it going to get so much that you'd say, well, we have two IDEs? Or is it always going to be a text editor with a bunch of niceties and features? Just curious from your perspective, is that something you all think about as a potentiality, something you're trying to avoid, etc.? Yeah, I mean, I think at its core, we always call VS Code an editor rather than a full-fledged IDE or integrated development environment. And I think that it's kind of somewhere in between. So it's like maybe more than just like a super simple editor without many additions. Cause when you can have extensions that can do basically anything you can think of and other kinds of support we're adding and everything with remote it's, I don't think we would go to, Hey, eventually, yeah,

it'll just be an IDE or that's what we'll call it. But I think we just want it to be the tool that you can edit anything from anywhere. It's kind of the tagline we've been adding on. So in 2021, we released VS Code for the web or VS Code.dev. So you can just go in your browser, type in VS Code.dev, and you'll see a version of VS Code running just entirely there in the browser. You didn't have to download anything. So with that, and then as we have a growing set of remote experiences and just more extensions and features overall, I think it's cool to see how much we can push VS Code and scenarios users are interested in and contributing back as well. But we always keep things like performance and not being too overwhelming in mind as well. So we try to keep the bigger vision as well of meeting what users want and what is

more modern development without being like, let's just build everything in. I think you can kind of see it as there's a series of extensions you install as well or different things like that. It's not just we're going to build in all of these extensions for you always or something. I think that's wise. I think it would be a shame if VS Code became so full of stuff that it was a full-on IDE by default. I mean, heck, you wouldn't really want to run that inside your web browser necessarily because it takes so long to load up or so much memory to run. So I've always liked that you had a clear break from Visual Studio and a fresh start.

And I think the editor over time has stayed relatively fast and lightweight. And it feels like you can just launch it immediately. And then from afar, I just see all the additional improvements and stuff. And I'm just like, wow, it's getting very full featured. And then I'm like, do they need Visual Studio eventually? Does it become one? Do they merge branches there? But I think you guys have a clear vision of what you want to do.

And I think it's a pretty good one with regard to what you say. You said code anything, anywhere. Is that the slogan? Yeah. We like to say, yeah, you can work on edit code, anything from anywhere, anything from anywhere. That's a, I like that one. So you're kind of on the anywhere side, right? Like your focus and your work is on the remote aspect, the anywhere aspect. How long have you been working on this spec in particular, dev containers? And when did you decide to take it beyond just a VS Code internal thing that allows VS Code to do remote and containers and stuff to be like a spec that you want other people to contribute to and other products and tool chains to adopt?

Yeah, so I've been on the VS Code team since 2020. And I first joined and focused on the remote extensions. We had three main remote extensions, WSL, SSH, and Dev Containers. And then over the next year as well, we work really closely with the GitHub Codespaces team, and they also support DevContainers, just it's in the cloud instead of on your local machine. And as we were working on our DevContainers extension and working with Codespaces, we saw, hey, like DevContainers can be something broadly useful beyond just VS Code or GitHub tooling or Microsoft tools. It's something that people want to use, even if they don't use VS Code, or maybe they can't, maybe their company uses something else, or maybe they're doing all their work in the command line.

And it makes sense to open it up as, hey, this is kind of like a standard that other people, other tools, other scenarios can adopt. And it doesn't need to be inherently tied just to VS Code. kind of like a standard that other people, other tools, other scenarios can adopt. And it doesn't need to be inherently tied just to VS Code. It's a general concept. It supports, instead of like becoming its own container orchestration format, we're seeking to just enrich other ones. So we're not trying to replace other things. We're trying to say, hey, how can we interact and interop with them and just support people with what they want to do and want to contribute. So then we started openly working on the dev container spec, the beginning of last year, maybe the end of the year before. So it's been a year,

year and a half or so. But I think like a vision going in was, hey, we don't think dev containers have to be tied to VS Code. And that was even when they were only a dev containers extension and GitHub code spaces thing. So that's why the file is like dev container.json. It doesn't have to say specific things about VS Code in the file name or in its content. And we've even been taking steps

as we've been working on the spec to generalize it beyond VS Code or code spaces. So for certain properties in dev container.json, like settings or extensions that may not make sense in other tooling, we've now extracted them to a top level property for specifically VS code and code spaces that way it's like, hey, use those tools. Awesome. They can handle it. And then over time, other supporting tools as other tools decide to support the spec or contribute to it

could also reserve their own properties in there as well. So it's all under customizations dot provision. There could be any tool in there. Yeah, I think it's really cool to open this up and have, you know, other tools, other sites, other cloud things adopted. I do think that Codespaces is such a killer intro to the possibility of using dev containers because it reminds me i don't know about you adam but it kind of reminds me of that deploy to heroku experience you know the one click button where you could take this current thing you're looking at deploy it as your own heroku app

and be running it in the cloud those have been replaced with i don't know deploy to vercell deploy to netlify deploy to whatever whatever's, maybe not replaced, but augmented in recent years. That experience, like the fact that we can just say now, just go to our repo, click on the little code button in the corner and say, launch on Codespaces or whatever the button says right there. Yeah. And literally three to five minutes later, it's not immediate.

It's close because, of course, there's lots of stuff that has to get set up inside of that container, the first run experience, right? In order for it to do its thing. And all of a sudden, like, there you are. You're both looking at editing and can execute code inside of what you were just staring at.

Like, who doesn't want that for their project, right? Like, it's awesome. Right, Adam? It's awesome. It's killer. It's a beautiful thing. You need this for open source in particular. What a great thing for would-be contributions that just get stopped because it's like, oh gosh, this contributing file. I love your stack, but I don't want to mess my pristine machine up. I don't want to deal with any of this stuff. For whatever reason, it's just there's a blocker there. Or even, I think, when I was watching your

YouTube series, Bridget, one thing I thought was pretty interesting was being able to jump around tech stacks. That's kind of cool. If you are traditionally a web stack developer, but you want to jump into a back-end focused thing or something like that, or into a whole new Python world, you know, you can sort of move around different stacks. And so that kind of like encourages the possibility of polyglot to some degree, or at least contributions to polyglot worlds.

You know, even if it's not something you're like a primary contributor to, but you're able to put your own contribution in, whether you're a designer or documentation or whatever it might be. To be able to move around like that, I think is a pretty interesting and compelling reason to consider the possibility with dev containers. Yeah, I think that's a great point. So the contribution we have, it's got a devcontainer.json file. It's got a darkcompose.yaml file. What part of this is the dev container spec and what part of this

is code spaces where is the line i suppose in that world is it like they adhere to or support your spec do they have their own spec demystify i guess the the ambiguity there between like where the dev container spec comes into play for us in regards to this contribution and then running that on code spaces yeah so you can kind of think of the spec as essentially that devcontainer.json file. So we're seeking to enrich other formats, whether it's a Docker file or a Docker compose or maybe potentially others over time with metadata from the devcontainer.json. So it can include those

tool-specific things like we were mentioning it can also be a spot where you can add or install other scripts or technology your parts of your text stack there like you might do in a docker file you could instead do it in the dev container json we have ways to kind of built in to make that easier for you to add more features so really dev container json is going to be the core of, hey, like, this is what is defined by the Dev Container spec. And then you can also then think of like a reference implementation for the spec or what is an example of how other tools could implement the spec over time is a Dev Container CLI that we open sourced. So go to github.com slash Dev Containers slash CLI. You'll see there's like, hey, that's the backing CLI that

Codespaces uses and that the dev containers extension uses. And that CLI is then how those tools are able to read in a dev container JSON and build a dev container or dev environment from it and make sure that the spec is supported. So then if another tool or individual wanted to support the spec, they could use the CLI and whether they integrated it into an editor or just used it in a terminal, that'd be considering, hey, like I support the spec here. I'm using the reference implementation of the spec. But there could also be like if somebody wanted to make modifications to the CLI, they could contribute those back or just use their own modified version too.

So these are the essential Lego, not the finalized Lego that you could build. These are the components that you could build to support essentially running code remotely or in a code spaces. So if I wanted to build my own code spaces, I could use the CLI tool. I can use different things and leverage essentially what you built to adhere to that SPAC and be able to do all those different things. Yeah, if you want to build your own tool that supports dev containers, like you're seeing in Codespaces, you're seeing the dev containers extension,

you can then use that same exact CLI and then hook it up to specifically what your tool needs. So if your tool needed other kinds of things, like maybe you have your own settings or extensions or names for those things or other properties. Maybe you work with secrets in a certain way. You could then make sure, oh, like the version of the CLI you're using respects or adds those kinds of properties. Maybe you work with secrets in a certain way. You could then make sure, oh, like the version of the CLI you're using respects or adds those kinds of properties. This episode is brought to you by our friends at Square,

developed on the platform that sellers trust. Here's what you could do with Square. You could bridge more experiences. You could build online, mobile, and in-person commerce experiences that connect more customers and sellers. You can build custom booking solutions. You can create and track orders. You can accept payments. You can manage and curate inventory. You can organize customers. You can manage employees. You can extend Square gift cards to your app. You can use Afterpay. And all this is powered by the world-class Square APIs and SDKs that enable you to build full feature business apps for yourself or millions of Square sellers. So much is available as a Square Solutions Partner. Learn more and get started at changelog.com

slash square again, changelog.com slash square. what's the experience like as a user of VS Code today? Let's say I open up VS Code, a project. I've cloned a repository that has a dev container JSON file. What does it change about the VS Code environment? Which extra buttons do I get? What all does it do, assuming the dev container does what a typical dev container does. I'm sure there's atypical things too, but just generally speaking, what does it do for the experience of VS Code? Yeah. So VS Code will detect if you have a.dev container folder, or if you have a dev container JSON, which could be in that.dev container folder

or at the root level of your project. And it'll recommend, hey, it looks like your project has a dev container configuration. Reopen in there to develop even more effectively or something along those lines. And then you'll have the option to reopen in that dev container, which will use the dev containers extension. So if you're familiar with the VS Code model of programming, it's essentially if you want different features, different functionality, you can install it through extensions. So we have a dev containers extension that then you can install from the VS Code marketplace. And that'll give you all the functionality to rebuild dev

containers, reopen within them, add dev container configuration files. So it'll guide you through that process of like creating a dev container JSON and adding things to it and adding the languages or tool sets that you need. So you don't have to look at me like, well, I've never used a dev container JSON. I don't know what to add or what to do. We try to guide you through that, through different quick picks and different check boxes.

You could be like, I want Git and I want Python and I want Node. You can just check box all of those. It'll be in your project and then you can just reopen in it. And the dev containers JSON, at least the one that we got from Chris Eggert is super basic. I mean, it's basically 10 lines and it's mostly setting up a workspace, a couple of port forwards

and then pointing to the Docker compose file that Adam was referencing. And the Docker compose file is the one that's actually doing the job of getting your container all set up for development. So if anybody's already using Docker compose for their, their own personal development environment, all they need to do is add the dev container, Jason, and point it to the right things, you know, a little bit of configuration goes a long way. And all of a sudden, you can run that same environment and code spaces, you can get the VS Code extras as well as, hopefully, as time passes, other tooling that adopts this spec. So you're really just a DevContainer JSON away from opening up that environment

to lots more people. Yeah, I like that statement. You're a DevContainer JSON away. You can use that as a tagline. Yeah, I like that too and you can even add you can even add more stuff to your dev container jason so i was mentioning like oh what if i'm thinking i really just need python in this project and like how should i add it i could install it in the command line but then either i have to install it locally or if i install it in the command line in my container, it'll get lost eventually if I kill this container,

which I install in the Docker file or somewhere else. So we have this concept called dev container features. So that's the steps that VS Code or Codespaces or other tools can guide you through via checkboxes of, hey, here's a list of features and maybe you just want to install one of them. Maybe you want to install a bunch of them and then it'll list those in your dev container JSON. And even if you're not using tooling like VS Code, you can just add those to your dev container JSON

via a features property. So you can say features and then name whatever feature you want to use. And it could be one you create, or one that the community or someone in your company created. And we have a list that community members can contribute a feature. So that way it's like, hey, I wrote this really awesome feature for something I work on or something that I use. And I think other people want to use it. You can add it to the index too.

So how far do you go with that? Because I expect, you know, we have so many different ways of specifying, you know, like editor config. Then you got your VS Code config. Maybe you got your Vim config. Maybe you have your git ignore. Of course, that's just a file that's in your repo. But there's just so many different ways that we specify what, how to configure our environments. And some of those we want to be global across the project, linters, etc, style rules, maybe

requirements for documentation, I don't know. There's a thousand different things you can think of. Some of those things are like personalized to the developer. And then other things are like, no, this is the whole project. What do you guys have found? You probably have more experience with devcontainer.json files than anybody that are like smart things that people are doing to share and like, hey, go ahead and put your editor config right here in your dev container.

Or no, that should be a thing that lives somewhere else. What are you finding? I think the way you put it of, is this something that the project really needs? Or is this something that I just like using or that I need is really a helpful distinction. So I think if it's something that's super specific, like, hey, I like this editor theme, or I like my editor sidebar configured this way or this specific editor setting. If it's just a dev container that you're using for your own personal projects, then totally put UI and very specific things in it. But if it feels like, hey, like probably not

everyone is going to love the same VS Code theme that I do. It's like, okay, I can probably maybe not put that in a dev container that I'm sharing with my whole team or the open source community on this project. So thinking about like, hey, if this project really needs this language, or if maybe this linting tool is really helpful, or maybe there are certain editor extensions, like language support extensions, like a Python or Java or C++ language extension for an editor. Those are probably really helpful additions where, yeah, maybe for some development you wouldn't necessarily need it, but it's going to make the development experience a lot better

and people aren't probably going to strongly disagree of, no, I think my development experience is way worse than them. Then I think adding those kinds of things in that feel like will be generally beneficial to open source community or the other teammates that you have on your project are great things to add. And there's so many things, so it can definitely be a lot of different options. But just think about how generally applicable they are, I think is the really helpful first or fundamental step there. Is there room for a.local file for that in that case?

Maybe Jared and I, you know, this moves forward and we keep loving it. And there's a devcontainer.json in our repo. But let's say I like a special flavor of something whenever I spin up my personalized container. Can I have a devcontainer.local? Is that a bad idea to have sort of a localized version where it's like, here's the devcontainer and here's what it does normally. But after all that's done, give me this, this, and this because I'm Adam. Yeah, there's a few different ways you can handle it. So depending on the editor environment you use. So let's say you're using VS Code.

There's certain specific settings you may be able to take in your editor where then you don't even need to set certain things in your dev container. Like VS Code has extensions to always install. So you could set a list of extensions that you always want there, which could include language extensions, but also include theming or other specific UI or key bindings or things like that. But then thinking about other editors, or if you don't want to use those kinds of extensions, think like it depends, like there could be, you could actually have multiple dev container

JSONs in a project. And then you can, depending on how the supporting tool implements it, they can guide you for, hey, which one do you want to use right now when you're working on it? So maybe you could have your own version that either Yeah, maybe you're not checking into source code, if you don't want to confuse other people, or that's maybe on your own branch that you have a few. So that way, you can kind of have it of, hey, like, I specifically need this for this scenario. So I'm going to have this kind of dev container here, but then I need this other kind of scenario. So I'll have a secondary one that can also be helpful for maybe if you're working on a monorepo

that has different dependencies for different subparts of the project. Then you can have multiple dev container JSONs there depending on what you're specifically working on or what some of your other teammates are working on. Interesting. Keep my local flavors. I like my local flavors, you know? Gotta keep the local flavors.

You're special, man. Yeah. Keep it special. So when it comes to adoption, I'm Googling around frantically as we talk, like looking like, okay, is the Vim community

trying to do some of this? Is the Emacs community trying to do stuff? Some people are just switching. They're just switching to VS Code. Other people are like, you know, here's an open source

implementation of VS Code's dev container API. Here's a Neo Vim thing that does some stuff with dev container. So it seems like you have a, they're out there, but they're not like established, you know, 30 people supporting this one plugin, et cetera. What do you think it's going to take to get more people on board and doing this and maybe even contributing to the spec so you kind of have like the editor side but then you also have like the cloud provider side and you have two implementations vs code and code spaces but on both sides you have like the open source like vim emacs you know integrate it into small

projects like sublime text and then you have like, Gitpod, I'm sure there's other ones, StackBlitz. Like there's a lot of cloud IDE things or web dev things in the cloud. And I'm just curious what adoption looks like or if there's a clear path to that. I just wonder as an author of a spec, what it feels like to like put a spec out there and hope that people use it, you know?

Yeah, when we first were announcing, hey, we're working on this spec and there and hope that people use it, you know? Yeah. When we first were announcing, hey, we're working on this spec and we open sourced the CLI, we announced it on, for instance, the VS Code blog or Codespaces channels too. But we wanted to emphasize, hey, like even if you're finding out about it on the VS Code blog or something, the whole point is it's not just VS Code. So I think like having that in our messaging has been really key because I think that since dev containers for a while were just a VS code and a code spaces thing, some folks still totally understandably think, hey, like, well, if I'm not using those tools, I don't need to add a dev container to my project. I don't really need to worry about it.

Or it's not something for me to think about adopting in another tool or something like that. So I think like getting the word out more of like, hey, it's an open thing. And you can check it out here. And we're super looking forward to like your feedback. And we accept contributions. And we're happy to talk to you about questions, feedback, contributions, all that kind of stuff. I think just getting that open dialogue and awareness out there has been really helpful and chatting with folks who are part of different language communities or who use different tools or who drive different tools and kind of getting their feedback of like, what are gaps that maybe the spec is missing

or that you feel like Dev Containers overall could be better at. So that way we can prioritize that in the work that our team does and also get like additional feedback and see how we should shape the future roadmap. And yeah, like we add, we have a section on the containers.dev site about

supporting tools. So you'll see that it's like trickling out to some other like CLIs and projects and things like that. But I think also seeing more dev container JSON files or.dev container folders and other open source projects has been a huge help as well. Because then it kind of shows like, hey, folks who are part of this community, you can check out dev containers, you can use them. Like getting the word there out more and getting like feedback from those users too. Like, hey, I'm using it for this kind of scenario and it doesn't work so great. It's like, okay, cool. Like tell us more about that and see how we can make it better.

So that way it's better for this whole community and maybe other open source communities and projects over time. When you get this feedback, what are some of the, I guess the biggest hurdles to get over?, what are some of the, I guess, the biggest hurdles to get over? Like, what are the things that really stop people? Or what are the things that really get people excited? Obviously, the usefulness, but like, what are the things that really push back against using it? I think at the beginning, it was just them not feeling like a very open or like super adopted thing yet of like, okay, cool. Yeah.

Maybe there's good adoption and VS code specific tooling, but like what other tools are using them? So sometimes it can be like a chicken or the egg problem of it's like, Oh, like, should I support it or adopt it? And that'll like help other people adopt it. Or should I wait for other people to adopt it before I want to do it? So thinking about like, is this for sure something you all are investing in and going to keep open and going to keep freely available and no cost and that kind of stuff.

So I think establishing that trust and awareness with folks is definitely something that isn't just like an easy formula of, oh, yeah, here's how we get the word out to everyone who might want to use this. And yeah, they're just going to like know and trust and understand that, yeah, like we really want to prioritize and invest in this. But I think it's something you can just kind of show through continued action of, okay, we have an open community Slack channel. Hey, we have community discussions that we actually respond to and really want your feedback on. So just slowly trying to build that trust and understanding and getting that open feedback channel over time has been really cool, but it's something that we kind of needed to just experiment with over time. And we're still figuring out like

we're still figuring out, hey, what are some cool open source projects that this would make sense to and it doesn't feel like we don't want it to sound like, hey, we think dev containers are for sure the best thing for you. And we know everything about your developers or your community. So you have to take this PR, it's more, hey, like, here's what dev containers are. We think they could be a good fit. We'd love to know if you're open to this kind of PR, we can help you with it.

Or is there something you feel like that we're missing that we could add or we could change? And like, what can we do to get there for you? I mean, it seems like to me, the best pitch for cloud things is like, hey,

here's an easy adoption avenue, right? Like you can be there with your deploy to cloud thing or develop in cloud thing X, just like the one Codespaces works on github.com right now. And then on the indie side, like the developer side, I just feel like it's such an easy sell because it's like, hey, don't you want your open source project to be immediately hackable? Yeah, like more people can use it and contribute. That's awesome. Yeah, I mean, it's like, who doesn't want that?

And I think the demystification, so for us specifically, I know we kind of wanted a Codespaces setup for a little while, but like Adam and I thought, well, we need to talk to Corey and the Codespaces team. I don't think he's on the team anymore, but when he was, he came on the show

and like have them help us to set up a thing that makes it all happen. And just the knowledge of, no, you can just have a DevContainers JSON in your repo, and then that's all you've got to have. It's seven lines of code, kind of a thing. Of course, different setups are going to be different. We have a Docker Compose as well. You might have more stuff to do. But just like, oh, okay. And so I think that plays into this other thing you have on the website, which is the templates. You have kind of two subsections

of the Dev Containers website. You have the features, which you talked about, but now you have the templates, which to me, I'm reading this and help me understand exactly what these are. It seems like these are like starter spots. So if you have a specific kind of project or what are these templates?

Is that, am I thinking about it right? You can just kind of use one of these and take it started. Yeah, absolutely. And I think you also really nailed another challenge and something that I was kind of mentioning earlier of, hey, like, yeah, I don't know where to get started with containers or like maybe I've heard feedback from other folks that they're complex, confusing, time consuming, compute intensive. So is this something I want to invest in?

Or like, should I? Is this where the community or the market's going? So yeah, we really try to make it easier to get started with dev containers and make it so that we're really taking out complexity where folks might have previously found complexity when doing containerized development. So yeah, with templates,

we have a set that we host as part of the specs. So for a variety of different languages or scenarios like Python or even just like base Ubuntu or something like that. And so it'll give you the dev container files necessary to kick off development for that kind of project. And from there, then you can totally customize it of, hey, I want to add other features

or maybe I just want to add other settings or configuration that's not in the feature and that's totally okay. But we're trying to just give folks those building blocks. It doesn't feel like, hey, I'm starting from scratch and that's time consuming or that's intimidating. It's like, no, this can actually be a fun and even kind of straightforward process. Yeah, I think that's going to be key. I was looking at one of the templates there it's elixir phoenix node and postgres jared not my sequel postgres so hey that's perfect that's us we need all those things it doesn't look like ours though i mean not that it has to be the same but like there's obviously two different ways to roam in this case at least. So essentially what you're saying, Bridget, is this template exists there.

I could take the devcontainer.json, I can take the Docker Compose YAML file, essentially pull that into my project or something like that. I haven't read the README thoroughly, but I can essentially adopt this into my project or start a brand new one from it and have essentially the building blocks of what is our stack, Elixir, Phoenix, Node. We're not really using Node, we're using NPM, of course, and different JavaScript things, but Postgres in that case.

So that's essentially the building blocks of the majority of what our application stack is. Yep, for sure. And yeah, you can take it as inspiration. You could use it as your actual dev container, can add things to it over time. And you'll see as well, we also publish a set of images. So those are going to be referenced in like our templates, for instance. And so you can kind of extract any of the things that we're publishing and say, maybe I can use some of this, all of this, take it as inspiration and go from there for configuring my environment. And essentially you're spinning up a Docker image

if you're doing local environment stuff. So if I'm doing this locally, this lets me spin up a Docker image that has this environment baked into it when it comes to using VS Code or a different text editor, whether it's Vim or whatever, you have port forwarding for going

into and out of the container so that I can run the application. Let's say it's on port 4000, like any typical web application, let's say like a 5.4.3.2 or whatever for the SSL version of the application. So that's how that works. You split up a container, your editor is still editing the code, but it's inside. Is it inside that container? Is it just running it? Like, how does that work? Break it down. Yeah. So essentially like everything you're doing is living in that container. You can view it as, so you could view it as like kind of our model for remote development and VS code in general. Like you're really working in that remote environment, whether it is a dev container,

whether it is the Windows subsystem for Linux, whether it is a remote VM or desktop machine via SSH or tunneling. And so that way, you don't have to like, copy code in and out or back and forth, like you might have had to do in other environments or worry about Oh, like, I know my remote environment, whether it's a dev container, one of the other options, like have this dependency, I need it, but now I need to redownload it locally. It's like, no, you can just develop completely within that remote environment. And what's cool with Dev Containers, too, is there's a variety of ways that you can reference what you want to be set up or configured. So like you were saying, you could reference a Docker compose.eml. You could reference just a Docker file.

You could reference just an image. It really depends on just like what you want to do, how you have your project set up, or you pre building images that you could even have it where you're like publishing what you made in your image. So that way you can use it then, and like dev container reasons later, you don't have to redefine all that dev container Jason stuff and other people and other projects can use them too. There's a ton of flexibility there just depending on like how your team works. And are you pre building things? Or are you all docker compose.yaml so what happens whenever i spin that image down then so if my code lives in there my commits are in there does this thing have the keys to you know my github

essentially like how does that go one layer further like how am i building inside this container and how is it ephemeral can go away but yet yet I'm not losing my code like I'm five here. So yeah, essentially with containers, you have a couple of options or either you can mount your source code into the containers, you can use a bind mount or you can use a volume. And so then we have an option, for instance,

in the dev containers extension where you can clone a repo into a volume. And so volumes are the recommended way to work with containers because then essentially it's like a little bit more optimized for how like Docker, for instance, is handling it. And so then you don't have, it's like a little bit more efficient as well. So there's kind of a lot of things to get into like volume, by amounts, all those things.

But yeah, I don't know if that's helpful. Well, I just think of like the resistance. I got to imagine part of the pushback is this confusion i would say right like so i'm asking you to clarify because i think there's a lot of at least it's confusing for me so you know i would imagine like if you if i'm typically i'm jared i love my local machine i don't mind dirtying it up you know however it is it is. Elixir, Node, NPM, install it all. I love it. Oh, yeah. All the things.

But then you go to the container and say, well, where does my code live? Sure, I understand volumes and I understand binding. You know, and if I'm developing in that container, is the code in that container? Is it still on the local repository? Does it simply just run the mirror image version of it? And I'm still essentially, you know, get committing to my directory right here on my box. And it's not remote, even though it's Docker local,

you consider it remote based upon what you just said there, right? Like it's still, anytime it's not your actual machine and it's in an image, you're saying remote. Yeah, right. And so, yeah, if you have, like you mentioned, if I'm making like commits or something like that that, they're not going to be like, oh, these are just special commits that then got discarded outside of my container or something like that. It's going to be like, no, you can commit back to your GitHub repo and

your changes are still going to be there. And so that's kind of the cool thing about having a dev container and a GitHub repo, for instance, is cool. Yeah, then if I open Codespaces or open anywhere else that's supporting dev containers, I can just work on my code directly there with also the tools that I need. How do the credentials work? So if I open up, I'm logged into github.com, I'm looking at a repo, I open it in the Codespace,

now I'm logged into Jared Santo Fictional Journey, P775G6, et cetera. Is that the URL? Well, that's part of the URL. It's a fictional journey, P775G6, et cetera. Is that the URL? Well, that's part of the URL. It's a fictional journey. It's my current code space. And let's say I'm just hacking along inside my code space and I say, all right, I'm going to commit this code.

I'm going to push it back to my repo. How does it know it's me? How are my security credentials injected into the Codespace? Do you know? Yeah, so with Codespaces, so you can use Codespaces in the browser or you could use a Codespaces extension in desktop VS Code.

And either way, Codespaces is going to handle your GitHub off. So it's up to the Codespaces extension or service to securely let you log in and make sure that it's really you logged in. So when you're working on that Codespaces extension or service to securely let you log in and make sure that it's really you logged in. So when you're working on that Codespace in the browser, it's tied to your GitHub account. So you can't use a Codespace anonymously or like at this point, it's just going to be

tied to you. So as long as like you authenticated into GitHub.com or you authenticated into the extension, then you're going to be offed and secure. Speaking of that, are you too afraid to GitHub, Jared? I feel like you're social engineering me right now. I mean, I want to know because at this point you're outing yourself to be maybe insecure potentially. So get secure if you're not too afraid.

I'm not going to answer that question. Okay. So if you are working locally in VS Code inside a dev container, the code is in the container, right? And you mount it locally somehow. VS Code handles whatever dance that is. And then as long as it has local credentials for SSH or however you're offing against your remote origin,

whether it's GitHub or some other provider, as long as you have access to that in your local system, it's just going to pass that through or use that directly. It should be pretty straightforward yep and you can use the same if you're using git or github commands via terminal or via extensions and vs code then you can install or use the same ones in your container and get that same access and authentication okay it's almost too good to be true adam almost true is it not true because usually when it's too good to be true not true going back to these templates so i'm looking at the go one now in

the official dev containers templates repo the go template and it's pointing that there's no docker composed there's no docker even in template. It's just like pointing at variants of an image. There's no image URL that I can even see. Documentation URL, license URL, image variant. Does this have built into it knowledge of this default repository of images perhaps? Because it looks like it's going to be pulling from a Microsoftrosoft hosted thing image

mcr.microsoft.com slash dev containers slash go according to this so i guess microsoft is hosting a bunch of these images for people and if you don't specify anything like specific image url or a docker file that grabs an image itself. It's just all falling back to Microsoft hosted stuff. Is that, am I reading this right? Yeah. So the set of templates that we host as part of the spec are all going to reference images that we're also publishing as part of the spec.

So if you go to github.com slash dev containers, then slash templates or slash images, you'll be able to see the corresponding templates and images that we're publishing. And in the templates, so for instance, the Go one that you pulled up, that image property is pointing to the Microsoft Container Registry or MCR, which is where we're publishing our first party spec images. And we try to just make it simpler of, hey, our templates just need to reference that image. That way you don't have to worry about like, oh, I need to manage additional files or like know how to work with or add a Docker file. But if you want to use a Docker file

or your project already has a Docker file, you can totally use that too. You would just move that image property over to your Docker file instead of in the dev container JSON and then have your dev container JSON point over to your Docker file. Right.

No, I mean, I love that. It's sensible defaults. You're actually providing a service here, right? Like you're providing an image repository that people can download images from in the case that they don't have their own or pointing at Docker Hub, which is what many images currently hosted on Docker Hub or elsewhere,

that it makes the getting started for the simplest case is pretty straightforward like if you're at if your code is just using go 1.19 or 1.18 you can just take this template drop it in your folder devcontainer.json maybe add a customization or two maybe not and you can have a dev container with go installed ready to run your code. Yep, exactly. I mean, who doesn't want to have a Go machine one click away? That's how you get there, is this. We just had that conversation with Matt, basically. We were talking about that, though.

We were just saying how allergic we are to just rando installs to different things. If I'm Go curious, which a lot of the Go time audience is, there's a lot of people who are in the Go world and they just don't even mind. You know, they drop things on their path at whatever, Go binary or whatever. Yeah, it's already set up. Yeah. But if you're Go curious, you're like, how does this work? You can just spin up a Go container via dev containers, play around and like your local machine is the same as it was, you know, when you close that machine down, when you close that container down. It's right there, which I think is super cool. I just love the ephemeralness of it, but also the permanence in

how the dev container spec lets you specify so much to use it within teams and different organizations. I guess the really interesting thing is when it goes beyond us nerds, we geek out on this stuff, right? This is great to us. But what about when my son who's seven is at school, right? And he wants to go into this class, which he's now in some GT classes

and they're doing computer things. Well, you know, I don't know if it's that mature yet, but I gotta imagine that like the teacher isn't gonna wanna have to set up every single machine and do all these different things for six or seven different computer environments that are all the same Go environment, for example. Let's say they're learning Go or they're learning Python as their first language. Wouldn't Dev Containers be amazing in that scenario where it's just like,

well, if you have Docker installed and you can borrow this template, which is pretty easy, right? You just copy it down. Wow, that teacher or whoever's leading that class has just got like a star next to their name because wow, they got six machines up running a ghost space or a Python space that a kid can play with essentially pretty quickly rather than the whole song and dance. Yeah. I love that you brought that up too, because education is the space that we've really identified too, that these could be super helpful in, especially in some of the more cloud powered or automated tools like Codespaces or other ones of like, I don't even have to like install anything locally. I can just go to the cloud and students alike that, hey, at the

beginning of a new semester, I have to spend first few days or weeks just getting everything I need for this class. And if I'm maybe studying computer science, I have a bunch of different dependencies that I need across a bunch of different classes. So like, what if either my professor added a dev container or us as a class, we had some dev container configuration that we could share. So it's like, oh, don't even worry about which version of Python do I need for this class or that class. Hey, no worries. It's just in the dev container. Go grab

it. That's music to my ears. For sure. It's also roots from the original GitHub inception which was permission to mess up. This is the ultimate permission just to play. If I'm Go curious and this Go container is one devcontainer.json away, Jared, as you said before,

that's so cool. Just one devcontainer.json away. That's so cool. A semi-tangent. I've kind of played with this in a different world. I've been tinkering with Proxmox and containers and stuff like that and I'm doing a lot of like home labby stuff and like I've been playing with trunas and other things more so because proxmox makes it so easy to spin up a brand new ubuntu image or a debian image or whatever I want to do and there's just a cool

world out there where it's like the same thing, but in the developer environment space. And, you know, that to me is just like so awesome because you don't have to figure out how do I create a Go environment or a Python environment. I mean, you can if you're going out your own route in your own bespoke way. But like you had said, for the most part, you've got a lot of templates that get you started or at least spark your curiosity to understand how can this be leveraged. It's just that easy. Yeah, absolutely. That's what we're hoping for, to make it just that easy. Come on. Jared's just over here laughing. Come on, Jared. Well, Bridget, you turned us into salespeople for you. He's like, it's just that easy. Yeah, I love it. Within an hour, I'm like, oh, I don't even have to be saying what are the pros. We're converted. We're converts. Anything like that. Thank you. Bridget just sits back and lets us get excited about it she's like yes we've got this is this is your

adoption strategy it works this is good yeah just got to find the right podcast right let's reel back and do our job of being you know good interviewers and say what's's the downside? What's the cons? Where does it struggle? Help us get some balance back into this. We've been effusive for the last 10 minutes and we need to balance it out. What's maybe left undone or painful today? Bridget, help us out. I think that some of the next things we're really thinking about is we've made a lot of changes over the past year from open sourcing the spec in the CLI to now moving to these new contribution models for templates and features and having indices for them and all that kind of stuff. And with that, now that it's like, feels like we have the major building blocks in place with the spec and the CLI,

it's like really getting more user feedback of like, for instance, some of the questions you both have posed of, oh, okay., some of the questions you both have posed. Oh, OK, so it looks like the templates are just referencing an image. Like, is that clear to folks? Because we hosted a previous set of dev container templates, or we previously called them definitions, and those had Docker files in them. But we thought that as part of, like, the spec here with some simplification and with these new images that we're post-publishing more publicly in this images repo, hey, like, let's just reference an image there. It feels like that might be more straightforward, but that may not be everyone's scenario or expectation going in, especially for people who are already using dev containers and more familiar with the old model or the old repo.

So I think getting feedback on some of those, like, key choices that we're starting to make, and we're really open to that feedback of hey like if this isn't clear to users we want to make it a good experience so we don't want to say hey well like too bad we thought this was clearest and simplest so you need to live with it it's like no that's why we want to make it an open spec like what does the community think there sync with that and then um yeah i think it's cool to like seeing the other kinds of like templates and features that folks contribute. But like, for instance, is the contribution process clear for how I would publish?

And is it clear that, hey, like I could totally choose to publish this for the whole community or I could also leave this private just to me or just to my company? So I'm getting feedback on those kinds of flows and what we have built into the CLI or into some of our other things that we offer, like we have GitHub Actions or Azure DevOps Task to kind of help with some of those processes, like, are these things working well for users? Or are there still some points to optimize? Because we'll get feedback of like, hey, like, this command in the CLI wasn't really documented. And it's because, oh, if like, we just added it, then we got to make sure our docs are keeping up. So I think also just keeping like our docs going and updating and all that, since things are moving so fast, making sure that then it's clear to people as well.

Something we're always keeping in mind. So this, this go template we're looking at, that's been the example we've used here. So on line six, it's, it references an image with George dimension before it's an MCR dot Microsoft.com slash whatever you're around.

It's an image. So are you saying that because one line above that says or use a Docker file or Docker compose file. So essentially, you've removed the step, right? Is that what happened here? This newer version is the template. It uses an image you've already sort of pre-baked with what would normally be in a Docker file. Correct.

Yeah. And then if you go actually to the github.com slash dev containers slash images, then you can see what's contained in that Go image. And you'll see, okay, there's an actual Dockerfile. So like, ultimately, there is one we're just saying, hey, maybe it'll be clearer, less cluttery if we don't have it there. And we also added that comment that you saw there in line five for or use a Dockerfile or Docker compose, after we'd gotten some feedback of, hey, like, how can I use a Docker file or Docker compose after we'd gotten some feedback of, hey, like, how can I use a Docker file?

Or, hey, I used to know there were Docker files in your templates, but I'm not seeing them anymore. So it's cool that you saw the comment there and we're hoping things like that can help users, but seeing how we want to move forward with certain things like that. Yeah. Magic is good once you've, to graduate into,

you know, like magic isn't, it's good, I guess, out the gate, but like for the most part, you know, like magic isn't, it's good, I guess out the gate, but like for the most part, you're kind of primary target audience, at least right now wants to know all the lines, you know, let me compose that Docker file for myself,

or at least tell me, maybe there's two variants of this, this dot Jason file where you've got like the full feature one, which doesn't reference the image and the opposite one, which was before the image was created, essentially. Give me both versions. So that way, if I'm especially as you're sort of training wheelsing people into this world, it's like, well, you can go this simple if you've already pre-baked your images. Or you can do the full thing, Dockerfile, Docker Compose and all to get to the end result if you're familiar with that.

Because I mean, I would imagine a lot of people are pretty familiar with Docker and Docker Compose to get to that world. But like Jared, even with Line 6, kind of stumbled him. He was like, well, what's happening here? Is there an image you're hosting somewhere? And as you'd mentioned, why? Your reasoning is why. It makes sense, but I think if these are templates and they're meant to be initial exposure to how this works. Like if I want to write this myself,

would it be this simple? Probably not. I would probably reference similar to the way I would make a dark and composed file now, which is an image somewhere else and do all the different steps, that kind of thing. Anything left unsaid, Bridget? Anything you've been waiting for us to ask you

and we just haven't got around to it because we're adults or have we covered it all? I feel like we covered all the key parts from, yeah, talking about what dev containers are, the open spec, both of you getting excited about it and becoming endorsers for us here. So we've really come full circle. Put these soundbites on the homepage and really get people using it. Yeah, for sure. What's a good first step? If we're given the audience that

maybe they've started out like us, apprehensive at first and curious and learning and asking questions. And now we're sales folks for the DevContainers spec now. That's Jared and I. What about our listeners? So if they're new to this they're

like okay what's a good first step where do you tell people to go obviously dev containers.dev but what's a good first step for someone to do would you say a template or will be a first try for someone yeah i would say in an editor environment of your choosing talked about vs cut and code spaces a lot so those are great ones to start out with. Just try out adding a dev container and building within it and seeing like, hey, okay, like what, how does my interface look compared to what I'm used to locally. So we have commands for you to add dev container configuration files that should walk you through like, hey, the necessary steps and having those files in there. And then kind of getting used to Okay, yeah, then I'll just reopen in my container. And then if I make a change to the configuration, I'll just make sure

that I remember to rebuild. And like, once you get up and running with it, just a couple of steps or commands there, it should hopefully be pretty straightforward. And then just from there, you can become even more productive in them. So recommend checking out with containers.dev, you can kind of get an overview of the things that we talked about today. And then also in our supporting tools page on there, you can see oh cool, here's where I can learn more about using it in VS Code or Codespaces. Or here's how I could use it in maybe some of these other tools

that I'm already using. Yeah, I messed up there. I said devcontainers.dev. Sorry about that. Containers.dev for posterity and clarification. Say containers.dev. Just kidding. I had to say it really loud. Say it five times real fast.

Maintainer, maintainer, maintainer. Bridget, it's been awesome. Thank you so much for joining us and taking us into this new world. We're going to explore it a bit ourselves and encourage those who we see to do so as well. Thank you for coming on the show. Appreciate you. Yeah, totally. Sounds great. Thank you for coming on the show. Appreciate you. Yeah, totally. Sounds great.

Thank you so much. Okay, coming to a dev container near you, your code base. It's just too easy. You got to laugh at moments like that in shows. Thank you for laughing with me. It's just too easy. Hey, don't forget there is a bonus

on this show for our Plus Plus subscribers. We have a membership. It is called Change our Plus Plus subscribers. We have a membership. It is called ChangeLog Plus Plus. We drop the ads. We bring you a little closer to the metal. And then we give you bonus content. Check it out. Learn more at changelog.com slash plus plus.

Thank you once again to our friends and our partners at Fastly, Fly, and TypeSense. And to the Beats Master in residence, Breakmaster Cylinder, those beats, they're banging. And to you, our listener, thank you for listening to the show every single week. Tell a friend if you love this show. Word of mouth is definitely by far the best way to help us. Tell a friend if you love this show,

and we appreciate you. That's it, this show's done. We will see you on Monday. Thank you. Game on.