Today the panel talks with Matt Holt who works full time on the Caddy Web Server. The panel discusses things such as how it compares to other popular tools as well as lessons learned while working on it.

Sponsors

Panel

Special Guest

Links

Picks

Aimee

AJ

Charles

Matthew Holt

Follow JavaScript Jabber on Twitter: @JSJabber

Special Guest: Matthew Holt.

CHARLES MAX_WOOD: Hey everybody and welcome to another episode of JavaScript Jabber. This week on our panel, we have AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo, coming at you live from sunny pleasant growth. 

CHARLES MAX_WOOD: Amy Knight.

AIMEE_KNIGHT: Hey, hey from Nashville. 

CHARLES MAX_WOOD: I'm Charles Max Wood, working on my MVP course for developers. Go check that out to level up your career. We have a special guest this week, and that is Matt Holt. Matt, do you want to say hello and introduce yourself? 

MATT_HOLT: Yeah, hi. I'm glad to be here. I work on the Cati web server. Been doing that for about five years. Just finished school with a master's degree in computer science, and I'm now working full time on the Cati web server.

CHARLES MAX_WOOD: Yeah, when my mom got her master's degree, we asked her if we should call her master. Of course, that didn't change much for us. 

 

Anyway, hey folks. One of the things that I find that really makes a difference for people being happy in their job is working in a place that makes a difference. And there's a terrific company out there that's looking to hire full-stack developer just like you, and that's Faithlife. Their average tenure is five years. I mean, five years, that's forever in developer years. Usually I see people changing jobs every one to two years, people are sticking around because they're great. They have a great values-based culture, and they are hiring developers in the United States. They're looking for full-stack developers, who can do C sharp or JavaScript on the back end and react on the front end. Go check them out at devchat.tv slash faithlife. That's devchat.tv slash faithlife. 

 

CHARLES MAX_WOOD: Very cool. So do you want to kind of give us the 10,000 foot view on caddy and what it does? 

MATT_HOLT: Sure. So caddy is a web server, just like, well, not just like, but it's in the same class as say NGINX or Apache or Envoy and so anytime you have a website that you're serving, there's like always a web server. I know that a lot of JavaScript developers use nodes built-in server. So a lot of programming languages and standard libraries also have HTTP servers built in. But caddy is a bit unique because, so it is a web server tool that you can write a config file for and deploy. It's completely static, self-contained binaries. So it's very easy to put out there. But it also does uniquely, it does HTTPS by default. It's the only web server to automate your HTTPS by default without having to turn it on, it will just use HTTPS for you and keep your certificates renewed. So that's kind of its, that's kind of its main unique thing, but there's a lot more to it, of course. So yeah, that's what it is. 

CHARLES MAX_WOOD: Nice. Now, AJ, you're the one that set this up. Was there a direction you wanted to go with this? Cause I could ask questions all day about HTTP and NGINX and reverse proxies and stuff like that. But I didn't know what exactly you had in mind here. 

AJ_O’NEAL: Yeah. Well, actually let me first dig in a little bit to the impetus behind caddy. Cause I think like from my experience with it, there's more to it than just it does HTTPS. I think that's the main selling point, but I think there's a lot of other stuff that's gone into it that, you know, about developer experience seem to be a really big key point on that. And so I'd wondering if you'd talk a little bit about that. And then afterwards, I've got some questions to ask about the HTTP HTTP stack. 

MATT_HOLT: Sure. So is there anything in particular you wanted to know about the developer experience? 

AJ_O’NEAL: Well, yeah, I mean, like just kind of the, the story of what brought you along, like why the choices that you made as you started building it, what, what the focus of, or what, cause I mean, I remember seeing a lot of stuff on the early web page and I think you know, is probably still there today, although I don't check the home pages as often about developer experience and what you were trying to improve. So what's the problem with other web servers aside from HTTPS not being present and, and what are you solving in that arena? 

MATT_HOLT: Right. Okay. Gotcha. Yeah. So one of the motivations I have writing caddy as a developer in college, my undergrad program was that I had to build a bunch of little websites and also my, my job that I was working at the time. And setting up other web servers to, to serve these little sites over and over. It's getting a little tedious and trying to figure out how to configure them and get them just right and get the features I needed to, especially like markdown rendering is like really tricky with your typical like Apache or nginx web server. And we're talking like 2014, 2013 at the time. So in 2014, I started writing caddy a new web server in go because go seemed like a good fit for it. And I could add the features that I needed. And so the idea is that you, at the time, at least the main focus for like the developer experience and enhancing that was that I just wanted a simple little config file where I just like type the name of the site, so like the domain name or the port that I want to serve on or whatever, and then hit enter and then just type the features I want one per line. So I type like Markdown hit enter and it could render Markdown files type proxy. And you know type a backend address and it could proxy it to, you know, some application I have running. Hit enter type root, you know, whatever, and it can serve static files out of a root directory. So that kind of thing. And then in like two minutes, you have this site working, whether locally or in production. And so the developer experience here was just make three or four line config file and then run caddy. And your site is up and running either, you know, locally as you're running working on all your little dev sites or, or in production and you can transfer that to production. It was a lot easier to figure out than kind of these more in the antiquity of these other web servers that also didn't cross platforms very well. That was something else I needed to do is cross-screen like Windows and Mac and Linux. So caddy does that very well, especially caddy too. So anyway the developer experience was like kind of the number one priority at first is like, oh, this is easy to use. This is simple. Look at all the stuff it can do. And it's kind of a new take on configuring back-end services. But then years later, as the project grew and became more popular, I found out that focusing on like, focusing on easy to use was probably the wrong idea. Cause like it severely limited what it could do. And I can go on for an hour about that, so I won't, but I think marketing caddy is like something that's easy to use was a mistake. It's not necessarily wrong, but I think people go in expecting it to work. They work the way that they want it to work. And when they find out that it's a little different or it doesn't work quite that way, but it's still easy. It's just not according to their assumptions. Then they get like, get upset or frustrated. So, so I no longer say caddy is easy to use, but like it's powerful tool that can be used very simply. You just have to first know how it works. Know how your stack works. Everything from the front end to the back end to how the internet works is just very important when using any web server. So again, a lot of you are JavaScript developers and you're very aware of the complexities of, of all of that stack. So, but, but Caddy tries to make it easier to wield. 

AJ_O’NEAL: Okay. I was just going to say, I think Caddy is super easy to use. Like I, I love this cross platform. I love that it's. You know, one or two command line flags and you can be up and running with a little local development server and not more than one or two command line flags. And you've got it up and running on a production server. So I am super, you know, I agree that it, from my perspective, it is easy to use. And, and the config is not always a hundred percent intuitive, but I I've yet to see a web server where that is the case. So anyway, go on.

AIMEE_KNIGHT: Yeah. So my question and Chuck kind of mentioned this too, but it feels like a good way to start the conversation. I feel like Nginx is just like the go-to for pretty much everyone. So would you mind comparing caddy to the, to Nginx? Like why would somebody either want to build with caddy instead of Nginx or why would somebody want to move their project over? 

MATT_HOLT: Yeah, that's a loaded question. I get that a lot. So web servers are complicated. There's a lot of dimensions, you know, which we can look at this. A lot of dimensions that people focus on, like performance, don't actually matter to most people. You can run Python simple HTTP server or PHP's little built-in server on most sites in production if you really wanted to, and it would be just fine performance-wise. But like, there's a lot of other dimensions that actually matter that affect your experience more, your developer experience. And that is configuration, feature set, how it handles errors and things like that. So, so that's a difficult question to answer, but I think the main things you'll notice when you compare Caddy and Nginx as a developer is, is one, the experience. I think the Caddy experience is a little better. You will notice that our community is, is newer. Obviously, Caddy is only about five or six years old, which by the way, is about the same age as Kubernetes. So like a lot of people are like, Oh, it's not mature enough to use Caddy in production. You know, we'll use Nginx. Well, I mean, using Kubernetes and Docker, like those are about the same age as caddy using core DNS, which is what Kubernetes uses for its DNS service. That's a caddy plugin and fork, which is newer than caddy. And you're already relying on that. So, so yeah, caddy is newer. You'll notice that its documentation is, we strive to make it good, but it, it it needs more examples or a community wiki could be flushed out more. So NGINX examples and documentation are probably more accessible and easier to find. I think overall though, you'll find that you can do more with caddy in less time, with less code, with less lines of config for really comparable performance across the board, unless you're like Google or cloudflare or Netflix, but all of them use go in production on at their edge anyway, and this is going to perform the same as any other go server. So yeah, I think you're going to find that it's easier to use the feature sets. If you use a lot of like NGINX modules that you might add, like dynamically link in caddy, everything is statically linked. So you'll have to recompile to add features. That's also nice because right. It's easy and we make it easy. We have tools. There's even our websites point, click and download, you know, with custom features. So, 

AJ_O’NEAL: And for reference, for those that I mean, cause there's a, compiling has a bad rap and I just want to make sure this is clear. This is not like compiling C. Compiling Go happens in the same... Go, the Go compiler is just as fast as the Node interpreter. You hit Node and you run some JavaScript and it takes it half of a second to load the modules and then your program starts running. Go, it goes through, reads the modules. Half a second later, it's done compiling. 

MATT_HOLT: Yeah, that's true. 

AJ_O’NEAL: And I don't know if... Catty might be big enough that it takes three or four seconds, but I imagine it doesn't take more than 10. 

MATT_HOLT: I mean, right. Yeah. And I mean, it should be a lot lighter weight than your NPM, like your node modules folder overall as well. My understanding is a lot of JavaScript. You have my understanding is a lot of JavaScript projects are compiled these days, which boggles the mind, but, but yeah, I think caddy compiling caddies is fine. It's a lot easier than compiling. Like if you have download NGINX, compile it from source and figure that stuff out, you got all these dependents. Like it's kind of a pain. I've done it. Go is much simpler, I think. 

CHARLES MAX_WOOD: So just, just, I'm not super familiar with go. I've talked to a few people about it, but I haven't actually done anything with it. So when you run caddy, then it actually compiles and then executes. Is that what you're saying? 

MATT_HOLT: Oh, no. So you'll, you'll compile it and then you'll have a static binary executable. Yeah, 

CHARLES MAX_WOOD: that makes sense. Okay. That's not, it's not in terms of, I wanted to make sure. Yeah. Well, yeah, to the point, you know, regarding JavaScript, I mean, It compiles and optimizes a ton of your code. It's just that it happens when you start the process to interpret it. And then it interprets the, you know, whatever it comes out of the other end after it does the abstract syntax tree and things like that. And it still does just in time compiling as it runs to optimize things further. So anyway. You could make the argument that JavaScript compiles. It just doesn't give you an executable binary at the end of the thing. You just run the process and it essentially compiles what it is going to compile, interprets the rest and runs it in a process. So that's why I was asked. 

MATT_HOLT: Gotcha. Okay. Gotcha. 

AJ_O’NEAL: If you're using something like, I think it's called PKG for node. And this is what Dino does automatically. Like that you actually, you actually can get single output binaries for node and for Dino as well. Oh, and it, and it, and similar to the way that go works and that some assets are packaged as assets, almost basically like a, if you were to, if you're familiar with cat, if you're like take cat and the node binary, and then you were to take your project and zip it together and you were to do cat node project dot zip, and then redirect that out to my executable name or project name, it's that's similar process is actually common across all three where. 

CHARLES MAX_WOOD: Okay. 

AJ_O’NEAL: Assets can get built in and the difference between say node and go node. You actually can get some of the byte code compilation as part of the package that it creates, but you don't get the assembly compilation, right? Whereas go always compiles all the way down to assembly on the first run. Whereas node is more of a hybrid approach.

CHARLES MAX_WOOD: So allow me to clear my throat and piss off everybody who loves JavaScript. So a.pkg file is essentially a jar file. 

AJ_O’NEAL: And not.pkg, but with the node, when you use the program pkg, you create a node self-contained package. 

CHARLES MAX_WOOD: Yep. I mean, that's what you described though, is effectively what a jar file is in Java. 

AJ_O’NEAL: Yeah. You zip bytecode along, but it does the jar also include like your default index index dot HTML or like PNG assets. 

CHARLES MAX_WOOD: I guess it does because it includes all of that. The only thing it doesn't include is the Java virtual machine. You have to have that installed on whatever, wherever you're running. And I think that would be the only difference. Okay. 

AJ_O’NEAL: Anyway, that's a bit of a tangent there. 

CHARLES MAX_WOOD: Nerdy out. Sorry. No, anyway. So, so yeah, so that's interesting. So with caddy, it's a whole lot easier. If I want to plug in, I just tell it I want the plugin and it'll recompile it in more or less if I use the tooling. 

AJ_O’NEAL: It's easier than NPM install and that is true. 

CHARLES MAX_WOOD: Wow. Good to know. 

AJ_O’NEAL: Yeah. Anyway, so I wanted to get on to, you know, you're talking about performance and that's something that I do want to touch on because regardless of how unimportant it is, it's something that, you know, people like to brag about at the water cooler. You know, like empires of code have risen and fallen based on micro ticks, which I don't even know what a micro tick is, but it's some fancy new term that's getting thrown around, at least in the JavaScript world to describe that basically, if I understand correctly, one fewer function call. I think a function call is considered a micro tick. But anyway, so like, you know, entire libraries rise and fall in popularity based on stupid benchmarks that don't, you know, even show real-world performance, but performance is something that's important to some degree. I mean, obviously, you're talking about the example of the Python web server. I would argue you can't run that in production because it can't handle more than one connection at a time. It's single-threaded, or depending on which version of it you use. If you're using the built-in Python 2.7 or 2.8 or whatever it is, it's single-threaded. So you could not use that in production. 

MATT_HOLT: I mean, the long tail of websites probably could. I think...Like three or four of my own little personal sites get like 10 visitors per day. And I think a lot of people sites fall in that category. That's, but yeah, sure. Right. Sure. You get more bot traffic and a Google indexing traffic than you get users. Yeah. 

AJ_O’NEAL: Sure. But I mean, and, and I, I, yeah, I totally hear what you're saying about it's newer, but the performance is not, you know, if you compare it to other tools, it's actually in the same category because. If you, if you run engine X with zero modules, like you're not going to get faster performance because it's, you know, hand-optimized event loop, you know, bite, all the bite buffers are picked very, very explicitly for the particular purpose of what it's doing, et cetera, et cetera. But I am sure that as this went from, okay, let's make something that's a little easy to set up to let's make something that's serves and serves HTTPS to let's make something that now, I mean, how many thousands of people are using this? Are you in, are you into the hundreds of thousands or is it millions? I mean, 

MATT_HOLT: you know, I don't know. We had a, we had telemetry for a while and it was expensive. So it shut it down. But without that, it's hard to, hard to tell. I mean, we have tens of millions of Docker polls and you know, millions of downloads on the website and hundreds of thousands of get clones as far as how many users that translates to, I don't know, because we never did collect, you know, personally identifiable stuff or IP addresses. So like, it's really hard to tell. 

AJ_O’NEAL: Well, at the very least, millions of people are benefiting from the caddy. 

MATT_HOLT: I think so. I do know it has secured trillions of connections now. Yeah. 

AJ_O’NEAL: So. Okay. And so as you get to that scale, I'm sure you've had to go back and tweak some things and I'm wondering what, what things came up from your, you know, original naive implementation, which was probably based on the standard library and some, you know, tutorials you found to what you have now, like what, what were some of the important things that changed and, and what parts of the stack were they influenced or did they? 

MATT_HOLT: That's a good question. Okay. Yeah. So I remember the first day it was on hacker news back in 20, early 2015. And there was a bug in caddy like 0.5 or whatever version it was where sometimes files would be like web pages. That'll all be downloaded as dot GZ files, like GZIP files. Sometimes not all the time. So that was, so we've had issues with like, so again, there's a lot of like there's a lot of dimensions and layers here of performance because this was in particular the compression module that had a bug and was sending GZIP content instead of GZIP encoded content. And any, anyway, so aside from like fixing the initial bugs that impacted performance, a lot of things, so there's not a whole lot we can do to actually improve performance beyond what the Go standard library does, which it already does very well. I think most of the performance gains probably do come from the Go runtime being optimized over the years, which it has really come a long way, in many ways is even superior to that of other language runtimes, especially at scheduler. And so, so we've seen performance improvements with regards to garbage collection. So the Go team has really worked hard on improving the garbage collector, getting it down to a few microseconds, you know, less often and stuff like that. Within caddy, the biggest performance bottlenecks are probably in proxying and encoding like on the fly. So anytime that we have to GZip a response that allocates memory typically, I mean, we can only, we can do so much. We can pull buffers and whatever, but Algorithms have some fundamental limits to their performance that only caching can really help with. Proxying, there's a lot to that because there's a lot of IO going on. Instead of your typical unidirectional IO where you're just serving like, let's say something out of memory to a client. You've got that one socket that you're doing IO with, but the reverse proxy, you've got two sockets and actually a third, because then you have your backend application and that complicates things even more, but you've got buffering in between those two sockets and managing that buffer, pooling your resources and managing concurrency and not just your memory usage and allocations, but also the network stack. There's a lot to manage there. And then how that interacts with the operating system, each operating system is a little different and with socket parameters and system calls. And it gets gnarly really fast. And that's only the stuff. 

AJ_O’NEAL: This is all stuff. That I don't think anybody well, not obviously not anybody we've got thousands of listeners But that's you're talking like you're talking a language that I think very few people in the node or javascript community Are familiar with right now, right? 

MATT_HOLT: No, you'll have no I yeah If you if all you do is javascript, you'll never need to touch or think about this kind of stuff 

AJ_O’NEAL: So people should just stick with javascript then 

MATT_HOLT: Well You have a lot of problems with that too javascripts uh I could I could JavaScript is neat. It's clever. It's a very clever language. And I'll say that as compliment genuinely, but it also does a lot of horrible things under the hood and including it's asynchronous like events or it's asynchronous model. Um, the concurrency primitives are anyway. Yeah. I won't, I won't go off on that though. 

AJ_O’NEAL: Well, yeah, that's, I think that would be good to go off on some, at some point.

MATT_HOLT: Um, yeah, it's fascinating how that into it too, because yeah, it is fascinating how the JavaScript runtime works and how it, how it manages the different concurrent, like asynchronous things going on. It's frustrating as a developer like me who wants to, like who wants to have control over that stuff when I'm in JavaScript sometimes like with pop up parse, that was actually a big frustration as I couldn't, I had to like, you have to sometimes do a little hacks in order to get certain concurrency things to work the way you want. 

AJ_O’NEAL: And we talked about this before the show, but Papa parse is like the most popular CSV parser. And it's the most performant CSV parser because it uses web workers. And this is a project of yours primarily. 

MATT_HOLT: Yeah. And even the web workers, I remember debugging like browsers had a lot of bugs and consistencies with how they implemented the, the web workers. Like you could do multi-threading in Java. I remember I gave a whole talk about this at Utah JS, AJ, you might remember. 

AJ_O’NEAL: I do. 

MATT_HOLT: Where I complained about how you can actually spin off these other threads in JavaScript, which was kind of mind blowing, like in a web browser anyway. Web browser had an API for this, but you couldn't share memory. So you had to copy the whole data set to these other, and like it defeated the point because now you, 

AJ_O’NEAL: because then your main threads tied up with your JSON dot parse and your JSON dot stringify. 

MATT_HOLT: Yeah. And you're allocating all this memory to copy yourself. Yeah. Anyway, 

AIMEE_KNIGHT: I feel maybe we shouldn't get into the asynchronous model for JavaScript for a little bit. Do we not want to? I want to have that back. Yeah, let's do it. Like 10, 15 minutes, 

MATT_HOLT: but I haven't looked into it for like five years. So it might've changed. 

AIMEE_KNIGHT: You probably still know more than we do. Or at least me, I won't speak for AJ. He probably knows a lot about it. 

MATT_HOLT: All I remember is that for, if I had a program in a tight loop, I have like a stack overflow question about this, where I've documented all this stuff, but I had a program in like a tight loop and it wasn't giving, I was running out of memory and it's because it wasn't the answers on stack overflow were saying that it's cause I wasn't giving the browser a chance to like interrupt or preempt, like it couldn't preempt the execution and do a garbage collection. 

AIMEE_KNIGHT: So is this a problem in node and JavaScript that runs in the browser? 

MATT_HOLT: I have no idea. Cause I, so I actually don't use node. I've never really written in node. I just send front end JavaScript. 

AJ_O’NEAL: So node is V8. So all of the problems that are pro- 

AIMEE_KNIGHT: It is the same thing. Okay. I should know that. Yeah. 

AJ_O’NEAL: Now node, node worker threads are not threads. They're processes. So that's a little bit confusing. 

MATT_HOLT: Probably why you can't share memory.

AJ_O’NEAL: Well, just that, yeah, there's a modeling issue there. So for those that are listening and you're not familiar, like what the heck does sharing memory mean? Imagine that you live in a virtual world where everything exists equally. So like the air is just as much material as a desk or as a glass of water. And the way that you change things is by just kind of wanting them to be different. So if I wanted a can of Mountain Dew here on my desk, I would just want it to be there and then it would form out of the materials and it would be there. And this is how memory in a computer kind of works. Like you just, you kind of want it to be there and then it just, it is, it exists in that space. So 100% of everything exists all the time, but what it exists as is based on what you want it to be or what you tell it to be. And so if you had a a can of Mountain Dew, which I do always. And let's say you want to tell the computer to place this can of Mountain Dew on the desk. You have one can of Mountain Dew. Now you have another part of your program that's going to read the desk and see, does a can of Mountain Dew exist there? And then if it does, it's going to place a second can of Mountain Dew next to it. But if it doesn't, it's going to place the can of Mountain Dew in the first can of Mountain Dew spot. So when you have shared memory, it means that you have to have some sort of communication because you actually are running more than one thread, which is very similar to running more than one program at a time. And if you do not, if you, if you do not have some sort of locking mechanism, then you get in the situation where one program is placing down a can of Mountain Dew, another program has seen that there is no can of Mountain Dew. And since this isn't a physical world, it's a virtual world. The other piece of the program just places the second Mountain Dew inside of the first one. And in one part of your program, you have a counter that says there's two cans of Mountain Dew. And then the other part of your program, you have one Mountain Dew. And then when you go to access the second one, the program crashes because it's not there and it just reads error. And then it's like, I don't know how to interpret error. And I, that was probably the worst explanation that anyone's ever given for shared memory. 

MATT_HOLT: That was very, that was a very AJ explanation. It works. It didn't spin at all. That's a good one. Got that part. I think it was fine, but it's up to you guys. 

AJ_O’NEAL: Amy, did that make any sense? 

AIMEE_KNIGHT: It did. Yes. I thought it was a sorry. 

AJ_O’NEAL: Okay. I just want to make sure that now I just need them out and do. Yeah. I can help you out Chuck. Drive on down. I mean, okay. Closer, but not by much. 

CHARLES MAX_WOOD: So around the corner, you're around the corner down the freeway. 

AIMEE_KNIGHT: So what Matt said, I mean, it, it made me think so. Like how does the model in JavaScript compare to other languages and what makes the model in JavaScript? What makes the other ones better? 

MATT_HOLT: Well, I think the JavaScript model, the concurrency model there, has some advantages. For one, you can't have data races, which means that you can't have a situation that AJ was describing where one party program, for example, thinks that there are two Mountain Dews in the desk and the other part of the program thinks there's one Mountain Dew. Because you don't share memory, like it's impossible to have multiple perspectives on the same piece of, same variable basically. And so that's actually really nice because that's a problem in Go and a lot of other languages. You also cannot have, I think you, you avoid corruption and other like just problems. Let me think here. 

AIMEE_KNIGHT: I mean, like the isolation sounds nice. In summer. 

MATT_HOLT: it really is. Like, and when you want to do something that requires concurrency, so I, oh, like network requests and file reading, I think the way it works, or at least the way it worked a few years ago is you make blocking or a function call that requires IO and then the runtime JavaScript runtime will switch context to something else. That does not is not waiting anymore. And then when the thing that was waiting is now ready, it lets, I think it lets the current thread finish. I don't think it preempts threads. I think it lets it finish what it's doing. And then it pops this ready thread off the stack and then it continues to run your promises like your promises like your  thens and your afters or whatever that you have queued up. So that's pretty elegant in certain ways, if you like nesting and all that stuff. Callbacks. 

AJ_O’NEAL: Well, and so that does use real threats. So under the hood, you know, in the, in the layer between V8 and node, that is the C++ layer, it does have real threats. Those final reads are going out in a real thread, but they go back into the event loop and the main thread can only do exactly one thing at a time, which is why, like you said, you don't get the data races, whatever. Yeah. 

MATT_HOLT: Right. They aren't exposed to you, the programmer, which is good and bad. 

AJ_O’NEAL: Yes. It's good because you never have to think about data races, even though you still have things that, you still have concurrency issues you have to deal with, but not at the memory corruption. 

MATT_HOLT: Right. You won't corrupt memory, exactly, yeah. Yeah, your programs are going to crash. Yeah, you can still have logical problems. Right. Definitely can still have logical issues issues. Yes. 

AJ_O’NEAL: Yeah. But yeah, you don't, you don't get access to the threads. It's there's no, there's no, there's no locking mechanisms. Although with async await, you'd be surprised at things that people have managed to be able to do to create new problems that didn't exist before. 

MATT_HOLT: Yes. Like I said, JavaScript is clever. I'll just leave it at that. 

 

Are you stuck trying to figure out how to get to the next stage of your developer career? Maybe you're just not advancing fast enough in the job you're in, or you're trying to break in in the first place, or for whatever reason you keep going to interviews and it's just not working. You want to land that dream coding job, but it just doesn't seem to be working out. Well, John Sonmez has written a book for you called The Complete Software Developer's Career Guide. He walks through each stage of the development career and all of the things that you need to do in order to move up, keep learning, keep growing, and find that next job that's going to get you where you want to go. So if you're stuck and trying to figure this stuff out, go pick up the Complete Software Developer's Career Guide. It's the number one software development book on Amazon. It's sold over 100,000 copies so far. I actually have friends of mine that reach out to me and go, hey, do you know this John Sonmez guy? Cause his book is awesome. So go get the book. You can get it at devchat.tv slash complete guide. That's devchat.tv slash complete guide.

 

AJ_O’NEAL: It's yeah, it's got good men. So Amy, was there any more questions on that? 

AIMEE_KNIGHT: No, I think that's a pretty, that's good. And we kind of time box that. 

CHARLES MAX_WOOD: Yep. So I guess the last thing to, to know really is, you know, we've talked a lot about the internal workings and capabilities of some of these web servers, kind of going back to our original conversation. I mean, what, what do we need to know then? Cause it seems like it may or may not matter you know, which one we choose. We talked about the difference between Nginx and Caddy, but I mean, I don't know. It doesn't seem like there's a, I don't know, anyway. 

MATT_HOLT: Here's what I, here's maybe what I would recommend. If you already have an existing deployment, especially one that's moderately complex, so it has more than like two moving parts or something, and it's already on another server like Nginx or Apache. And it's working for you. Go ahead and just keep using it. However, I do, I would say that switching to caddy or using, and especially using caddy for new projects would be a good investment because caddy will typically result in fewer moving parts. So if you were to set up an HTTPS site with, you know, all your

JavaScript, you know, maybe your single page app, whatever, with a traditional web server. You're going to have to set up. Get a certificate and set up a maybe cert bot or whatever other CA or, or certificate management, however you manage your certificates, you have to set that up and set up cert bot on like a timer and set up other services to, to support your site. But with Caddy, it's all in one and just works. So it also works at scale. So if you're deploying sites across multiple regions or instances. Caddy will work better at scale, especially for managing certificates than any other server. So, I mean, but if you're talking like local development on your machine, it doesn't really matter, but Caddy will still give you a better user, like developer experience, I think. And, and also makes it honestly, it's not too, it's pretty easy to configure a single page app. It's like two lines of config in a caddy file. So if you do that a lot with your, with your JavaScript applications, it's also easy one-liner add a reverse proxy to your node app. That's very simple. I think I would, what I would recommend is just looking into caddy as an alternative because it's actually quite a compelling use case, I think once you start exploring it a bit, especially if you're into automating your, your infrastructure caddy is very highly programmable. It has a great API, but not JSON API. 

AJ_O’NEAL: All right. So I've got two more directions that I'd like to go with this. If we end up having time. One is earlier you talked about it's important to learn the web stack from. I don't remember exactly what you said, but I think it was like HTTP and DNS to file system, to the caching layer of the web server. 

MATT_HOLT: Yeah. 

AJ_O’NEAL: And I was wondering if you'd expand on that. Like what are the most important things that you have learned or noticed that, you know, when people that are using Caddy, which a lot of them, at least initially were front-end developers, were drawn to Caddy because it was so easy to set up and you had such great examples for here's how you do this with X, here's how you do this with Y. So I'm wondering, like, either from your own perspective or from the perspective of all those interactions with others, what are the key things that help make things click for people and give them new opportunities in their projects and in their work? 

MATT_HOLT: Hmm, that's a great question. So I would recommend, so this is like JavaScript developers, right? You've got a lot, you've got a lot that you have to think about, right? So your JavaScript gets run in the browser. You probably have JavaScript running on the backend with your node server. And you probably understand very well how your front end and your backend work together, how your front end makes HTTP requests. Are they still called Ajax requests? Can I call them that?

AJ_O’NEAL: No. 

MATT_HOLT: Will I get laughed at? 

AJ_O’NEAL: No, but I will. They are still called that probably by the majority of the world, but not in the schools that we interact with. 

MATT_HOLT: What do you call them? 

AJ_O’NEAL: Requests, just web requests. 

MATT_HOLT: OK. All right, well, I lost the specificity, but that's fine. OK, so you make me use. 

CHARLES MAX_WOOD: AJ is going to get hate mail now. 

AJ_O’NEAL: Why would I get? Oh, I get hate mail anyway, Chuck. I wouldn't notice.

MATT_HOLT: So your friend makes requests to your backend endpoints that you've set up, your routes that you've configured in your node app. And that might be all you know, and that might be all you need to know in order for your JavaScript service and your site to run. However, when you're working with a web server, especially beyond just like the standard node built-in server, you're really gonna need to know, one, how to use, I don't mean this condescendingly, but I don't really know how else to put it. You have to know how to use your computer. Like, you have to know how to set up services like system services and how to get them to run after you log out or quit your terminal. So we see a lot of confusion there, but that's a really important part of your stack actually is you may not think about it because maybe you were taught it in like your first undergrad class at college or something, how to like run commands in a terminal and how to, how to invoke node or NPM and stuff. And that's great. But I think really understanding how to run processes and services on your system is important. The next thing that would be good to learn is the networking stack. So the difference, especially the higher layers of the OSI model. So things like the IP layer, the transport layer, the application layer, how they work together. 

AJ_O’NEAL: So what does all that mean? 

AIMEE_KNIGHT: I'm loving that you're saying this.

AJ_O’NEAL: What's LSI? What are these layers about? 

MATT_HOLT: Oh, right. OSI is, all right, you caught me. I forgot what OSI stands for. 

AJ_O’NEAL: Well, it's the layers. 

MATT_HOLT: Open systems interconnection. No one knows what that means. It's just the OSI model. 

AJ_O’NEAL: Not what do the letters mean. What does it mean for someone that wants to learn it? Like, what does it mean? What is the real? 

MATT_HOLT: When you're connecting two computers or two processes on a computer, you'll. There are different layers in which it happens. The lowest layer is like the physical layer where the community, like the electronic signals and optical light impulses and things like that. We don't have to worry about that. Yeah. The actual hardware and 

CHARLES MAX_WOOD: fiber optic cable or the copper cable. 

MATT_HOLT: Yeah. Right. And those, I mean that without that, you don't have any communication, right? But this, this model also applies within the same computer, right? So because at higher layers, you have things like sockets and addressing, so you have like ports and IP addresses, and then you've, which you probably all use those as you set up your services before. So understanding- 

AJ_O’NEAL: Is example.com. 

MATT_HOLT: So, okay, so example.com is a domain name or a DNS name. And what your computer does is it has to make a lookup in some database, some registry called a name server, that will tell it what IP address that points to. So example.com has an entry and basically a phone book, an internet phone book, that points it to a computer's address, an IP address. And then that IP address is actually what's usable in communicating with that website. So your computer, once it has the address, it can send packets, which are little pieces of data, to to your home router, which your home router will then send to your ISP, which your ISP will then send it to, you know, across the country to whatever. And then it'll just keep getting closer and closer to its destination until it gets there. And then it will, of course, find its way back to you as the server replies. So that's layer like three ad addressing, I suppose, but it uses a bunch of systems. And this is, I think, I'm glad you brought this up because you should also really know how. At least the basics of how DNS works and how it's related to addressing. Because even within the same computer, you can set up DNS and, and routing using like a host file. 

AJ_O’NEAL: And if you're, if anybody's using Docker, this is critical because Docker containers talking to each other. 

MATT_HOLT: Right. So all this network stuff that we think we talk about happening over wires and across countries and continents also happens on your own computer, like our own physical machine. So understanding how sockets work and how how ad, how addresses like interconnect and get routed. Like you need to know how your computer is configured for that. Yeah. 

AIMEE_KNIGHT: This is where I want to come in and say really quickly, like not to discourage people, like, you know, we have bootcamp people listening, like, yeah, they're not going to cover this in the bootcamp. But when people talk about software engineering being like a lifelong journey, you know, it's important when you're done to, you know, learning the basics that you dig into this stuff. That's all I'm going to say. 

MATT_HOLT: Oh yeah. That's no, that's a great point. Yeah. And the bootcamp doesn't need to teach you this like, and that's okay. But I think if you do anything beyond the simplest stuff with your web server or your node application or whatever, you should, you should know like, what is a socket and does it have an address? And like it's in this state. What does that mean? 

AIMEE_KNIGHT: Like, why isn't it fascinating? Like when stuff goes down, you know, you don't want to just like throw your hands up and be like, oh, you know, it's not working. But you know, it's interesting to dig into why when you have outages. 

MATT_HOLT: Yeah, it's interesting, but it's also a valuable skill. Like something I've learned is, is just how, how much, how far you can really get if you just know how to troubleshoot problems, because someday it's going to happen where you're going to launch a node application and you're going to try connecting to it and it's not going to work and you're going to be like, Oh, well, and like nine, uh, 75% of the issues we get on caddy are. Actually, like not necessarily bugs and caddy. It's just helping people understand how their docker setup is configured and how their firewall is Misconfigured and stuff like that. 

AJ_O’NEAL: So you've been saying like caddy is the only you know web server that that does the HTTPS and and but I wasn't gonna butt it at the time, but green lock also does this, which is written in node, which obviously is not going to be as performant as caddy is, but for people that are working in node and want some kind of some configurability, like what you're talking about with caddy green lock does provide some of that's probably, probably about to a similar degree. And that's like most, I created a video a while back. I need to update it. Cause the one that's out there is out of date, but I, I created a troubleshooting video where I just went through the errors that people encounter, likeYou know, you get people probably commenting on your issue board about, you know, E Adder in use or about, um, you know, they've got a fake domain name that they, they actually used example.tld or y ou get stuff like that. 

MATT_HOLT: Yeah. 

AJ_O’NEAL: And that same, same thing. Like I get a ton of the issues that I get in for, for green lock are actually just people and, and Docker so much Docker because Docker is a very complex tool that requires like. I don't know how anyone could be using Docker without having learned sockets and hosting and but people do and then they have these weird complex situations where I don't even have the vocabulary to speak with them about it because it's like, well, you're using a tool that's extremely enterprising and has lots and lots and lots packed in there. I'd recommend, you know, I tell people this, I recommend just setting up on Digital Ocean starting out with like very, very simple, just files and folders. And then as you're more about that stuff, then go back to Docker. Once you have some of the foundational understanding, but some people, they want it, they want to go straight to Docker and I'm like, oh yeah, well you need to do this and they're like, what's that? I'm like, oh, oh, if you don't know about that, you know, and it's, it's stuff like. 

MATT_HOLT: Yeah. 

AIMEE_KNIGHT: Docker's cool. 

MATT_HOLT: You're right. 

AIMEE_KNIGHT: I mean, I'm totally getting, that's what drives me nuts. 

MATT_HOLT: Well, yeah, I mean, and Fun fact, you don't need Docker to deploy caddy because it's a self-contained binary and dependencies, but yeah, no, I could, that cannot be emphasized enough to start simple and then grew out from there. And I don't know exactly how boot camps work, at least these days, but like, I know that JavaScript, even for me nowadays, like if I was to jump in and do like write a node application, I feel like it's overwhelming because there's so much. Stuff so much framework, so much boilerplate, but really all you need to like really use JavaScript is a text editor and a JS file and, you know, window dot whatever, like for the browser anyway. 

AJ_O’NEAL: And tell that to the people on Twitter. 

MATT_HOLT: Oh, I know. Those are a little secret. But yeah, I wrote this article a couple of years ago. Hi, I just I write, I make websites with my bare hands. Like, I prefer to just keep it simple. And you don't need to introduce all this complexity into your stack. Especially if you don't understand it like you just have to know what's going on. It's okay to use these tools, but please for for your own productivity sake learn how they work and and that's hard and it takes time and But so worth it. 

AJ_O’NEAL: Awesome. So if there's no more questions on that, there's one more thing I'd like to squeeze in does anybody else have any more? 

AIMEE_KNIGHT: I'm enjoying your questions. 

AJ_O’NEAL: So one more thing I was squeezing Matt you have done an amazing job at building a community around caddy. And obviously you have a great product, right? Like what you have is valuable and it helps people. So many people, a lot of our listeners have little pet projects that are valuable that could solve a problem that thousands or millions of people could be getting benefit from but they don't know how to do it and they're sitting there with three stars on github and and I think like I mean obviously Caddy provides value, but you did something if all you did was just build caddy and put it up on github. I can't imagine that anyone would be using it. What did how did you garnish community? How did you make this accessible to people to the tune of you know? You're now one of the most popular web servers.

MATT_HOLT: Uh, yeah, so I don't actually know the answer to that question because I, I did publish it on GitHub and then I posted it to hacker news years ago and, and it got to the front page, which, so that's along with it, like, this is true of anything that goes like viral or like gets on the front page of like link aggregation sites like this or Reddit or whatever. A lot of it is luck and timing. There's plenty of stuff that should probably a page of sites like Hacker News that just never gets there. Some projects solve very niche problem, which don't necessarily serve a wide audience, but they serve a very like loyal and passionate audience, perhaps, but it's very like focused. Uh, web servers are very general, especially web servers in the class that Caddy is in, so that helped for sure. 

AJ_O’NEAL: So when I'm, I just Googled hacker news caddy, cause I wanted to find your original article. There are dozens of articles, uh, either directly about caddy or. 

MATT_HOLT: Oh yeah. Some of that's hate mail too. 

AJ_O’NEAL: Referencing caddy. Well, I don't think any of the stuff on this first, Oh yeah. Yeah. There are, there's, there's one or two things less flattering. So all news is good news. 

MATT_HOLT: I've made my mistakes for sure, but so is like, so have people.

AJ_O’NEAL: You know, like a lot of things mistakes too. 

MATT_HOLT: Well, I'm just saying I'm not the only one who's made mistakes, but yeah. 

AJ_O’NEAL: But there's, so if I, when I search hacker news, caddy, there are 1 million results. I don't think that's because there's 1 million articles, but maybe 1 million references to both hacker news and caddy. But yeah, like the first, like, I don't know, maybe 20 of these are all news.y combinator.com and they are directly referencing caddy. So it looks like this was a continued effort of Marketing caddy to hacker news over and over again over a period of years.

MATT_HOLT: Yeah, that's true doing some controversial things will also help like what well like changing licensing In not a bad way like again just you do things that get people's attention. Especially the outrageous things or things that they can twist as outrageous that that can actually help your popularity. People who are sensible may like, we'll see through that. And those are who you want in your community. And so again, I've made my share of mistakes, especially in the community building, but engaging with people, making sure that you answer issues, encouraging them to share and tell people can all help a lot. 

CHARLES MAX_WOOD: Cool. Well, the other thing that, that says to me just regarding hacker news is that like stuff doesn't just wind up high up on Hacker News, there's gotta be some interest in it, some desire for it. And having written plenty of XML to configure Apache web servers, and having tried to parse through some of the inscrutable bits of Nginx configs, it's understandable that people are gonna look at this and go, oh, this looks nice, right? Because if I could get a version of NGINX that only does the bits that I care about and makes that extremely easy or doesn't by default, and then gets out of my way for the rest of things. And you know, with caddy, you know, having, I mean, just by virtue of having fewer options, you know, if it has the right options is something that I'm just going to look at it and go, Oh yeah, I, you know, I'm going to, I need to pay attention to this. 

MATT_HOLT: Yeah. And beautiful way to put it. I wouldn't say that caddy has fewer options. If you look at its full JSON config structure, so caddy's config actually is natively it's JSON. The caddy files, a human readable, writable format that we convert to JSON under the hood. But if you look at the JSON options, it's actually very, there's a lot of stuff, but you don't have to use it all. Most of like all of those have same defaults. And that's, I think what you're getting at of course, is it's just, it just gets out of your way. That's why it's called caddy. It, it just gets you what you need. And then it gets out of your way.

AJ_O’NEAL: Uh, wait, I don't know what caddy means. I don't know how that's related to what you just said. 

MATT_HOLT: Oh, well, 

CHARLES MAX_WOOD: I need to take AJ golfing. 

MATT_HOLT: Yeah, there you go. I've never actually been golfing and I kind of hate the name personally. I think people don't take the project seriously because the name sounds kind of dumb, but yeah, I think of caddy has like two meat holder for things. So caddy, you can extend with all these modules and it can, you have fewer moving parts, like you can put more into this web server that does more for you automatically. The other thing is that it's like a helper. So like when you're golfing, it can just, it's out of your way and just makes your game, lets you focus on your game. 

AJ_O’NEAL: I miss the grass blade logo. I was so, so sad that you got rid of that. Still to this day. 

MATT_HOLT: Me too. I

AJ_O’NEAL: t was a better logo. You should bring it back. 

MATT_HOLT: I agree. 

AJ_O’NEAL: That's not what you said last time we talked about it, but I'm glad you changed that one. 

MATT_HOLT: Well, I just, okay, like I just hate branding all together. I'm just bad at it. But I'm glad you liked it. 

AJ_O’NEAL: I thought caddy was a good name. Cause I thought of it as like, I thought of it like golf, but I don't know what it means other than it's like a, I thought, okay, I'm going to sound really stupid. The caddy is the thing that holds your golf clubs. Is that true or false? 

CHARLES MAX_WOOD: That would be your golf bag. It is the person that carries your golf bag. The person that carries your golf bag. Okay. 

AJ_O’NEAL: You probably just said that, but I was looking at hacker news. Trying to find this guy. 

AIMEE_KNIGHT: I just laughed because I'm like, you can't just carry yourself. I don't understand. 

CHARLES MAX_WOOD: Not a pro. It didn't work that way. Anyway, golfer privilege. I freaking love golf. Anyway, but yeah. So the caddies also tend to if you've ever seen like the legend of Bagger Vance, he also like walks the golf course and can advise the the golfer on you know the the pitch of the fairway and stuff like that. 

AJ_O’NEAL: So let me let me tell you how much I haven't watched golf movies ever. I haven't even seen happy gilmore. That's a golf movie, right? 

CHARLES MAX_WOOD: I have to say golf movies. Are the best sports movies cricket? 

AIMEE_KNIGHT: Plus happy combined figure skating and golfing. 

MATT_HOLT: All right. Let's do quick though. 

CHARLES MAX_WOOD: We're way off in the field now. 

MATT_HOLT: Sorry. Real quick though, before we, before we finished, if I may, AJ, I think I'd be doing people at the service. If so, you know, we've talked about like a couple of things that make the pop project popular or whatever. I think I'd be doing the service. If I didn't mention that having a popular open source project is bittersweet though. Like it's cool. And sometimes self-flattering to have people using your project and to. It's somewhat satisfying to like write something that's useful for a lot of other people, but it's a lot of work and like doing this in through undergrad and grad school. And sometimes a lot of hate. Yep. Like so much so that I almost quit the project a couple of times. And anyway, I would, I think before writing a piece of software in like little libraries or whatever and open source, and that's great. But if you're going to in your own time and of your own volition, like write an open source project, you better be doing it for the sake of the community and to have really good, like, just, just have really good self control over that because it can become very demanding, especially without, without pay, without compensation. Like it's, it's frustrating. It can lead to burnout if it does get popular. So I wouldn't necessarily wish for anyone to make a new popular open source project on their own free time. However, I would encourage companies and employees of companies to open source stuff and get involved in open source. So basically a situation where you already have the funding and like it's your work hours or whatever, like doing open source for work is cool, is fun. It can be very satisfying with a lot less stress because you don't have to worry about the added burden and the fatigue of doing all this stuff in your spare time that you're probably already doing for work anyway during the day.Well, without pay, 

AJ_O’NEAL: But you didn't do it for, I mean, my understanding, if I, if I got it correct, you didn't really do it for pay or for the community. You did it because you wanted a better tool and you were learning new things. 

MATT_HOLT: I should have probably instead kept a close source and sold it. If I was optimizing for my own, like, well, like, like wellbeing, I guess, my, like reducing my own stress. Yeah. So, so now I, but now it's a better situation because I do work on caddy full time, I have a sponsor and employer actually API layer that is, that is paying me to work on it full time. So, 

AJ_O’NEAL: so do you, do you think, cause this is, this I think is where the edge went on the hacker news post and, and where, like I've seen it in the community. When you, when you try to get to the point of, Hey, thanks community for using this. Now will you support me in it? That's when they turn on you. That's when they become the wolves. Right. 

MATT_HOLT: Yeah, that's rough. But if you're a company and you then open source something, that's always a good luck, it's never a good look for some reason. I don't know why it's like a bad stigma, but it's never a good look to take something open source and then, and then like fiddle with the licensing or pricing. 

AJ_O’NEAL: The jump from zero to one is the biggest difference between two numbers. But the, so you wouldn't have, no one was going to hire you to do this, but you did it. And now someone is hiring you to continue it. So I think, and correct me if I'm wrong, but if you had not made this open source, I have a hard time believing that you would have been successful in getting the traction to be able to sell it, because somebody said, well, why would I buy something I've never heard of from you when there's something else that's you know, out there, which maybe I could be wrong. There might be a really great marketing spin on that with the, you know, whole let's encrypt integration, which would make it worth 99 bucks for a one year license or, you know, infinite license with one year of updates or whatever, but, but in taking it open source, it did lead you to being where you want to be being to work on what you love full time for a company that's sponsoring it, which is very rare. I mean, that happened with no JS, it's happened with many projects, but we're talking in a planet full of 7 billion people, there's, you know a couple thousand, 10,000 that that's happening for maybe. 

MATT_HOLT: Yeah. It's probably not super common. I also wouldn't say that everyone wants that. I mean, I wanted it, but, and yeah, I'm definitely lucky in that sense, but yeah, it's not the only way to do it though either because I could have totally have started as a business or I mean, it would have been a very different strategy, very different path would have been probably just as difficult. Yeah, just different. 

AJ_O’NEAL: Okay. 

CHARLES MAX_WOOD: Yep. So trade-offs are always interesting. 

MATT_HOLT: Yeah. It worked out well though. We have a good community. So I hope you'll give caddy a try if you haven't already. 

AJ_O’NEAL: And I hope you'll give it a try too. I'm AJ Neal and I approve this map and caddy. Not that that means much, but it means a lot AJ coming from you. 

CHARLES MAX_WOOD: Yeah. All right. Well, let's go ahead and do some picks. 

 

Leveling up is important. I spend at least an hour every day learning ways I can improve my business or take a break and listen to a good book. If you're looking to level up, I recommend you start out with the 12 week year as a system to plan out where you want to end up and how to get the results you want. You can get it free by going to audible trial.com slash code. That's audible trial.com slash code. 

 

CHARLES MAX_WOOD: I think we're kind of to that point. AJ, do you want to start us off with picks? 

AJ_O’NEAL: Yeah. So I'm going to pick caddy, of course. And I've got a little caddy cheat sheet. On web install.dev, which Matt, I'd love it if you'd take a look at that and give me some feedback, if you think there's some other stuff that should go there, some things I should do more correctly, but it's just very simple, like basic. Here's how you do a file server and a directory. And here's how you do like a typical reverse proxy. Oh yeah. This looks good. Looking at it now. Yeah. And the windows installer is ready. So that will certainly be published before this goes live. So And it's very simple. It's very simple. All this, all this does is the web installed. I've generates a bash script that depending on what system and architecture you're on, it goes and downloads the correct file. It checks. Is it a zip? Is it a tar? Is it already an uncompressed exe, whatever, and then just puts it in the right directory and then updates your path. And then it prints out the stuff to the screen. So there's no magic. It's like, this is where it downloaded from. This is where it installed to. And then when you, when you want to do an update, you've got a little bash script that's, you know, you do Webby, caddy, and then it just updates it to whatever the latest version is. 

MATT_HOLT: Cool. 

AJ_O’NEAL: And then also one of the things that you mentioned, which I agree with you, it's good to know how your system works, but there's a balance between like the stuff that's tedious and the stuff that's helpful. I think it's helpful to understand that there's a thing called systemd and there's a thing called launch control and there's a, I don't know what the windows thing is, but it's helpful to know those things are there. But going through and like debugging all of the little itsy bitsy details of what could go wrong in a one-off config file. Cause there is no other config file in the world that looks like a launch de-config file. It is, it's its own XML format. That's really not similar to anything else. Well, I guess it's a plist, but people aren't dealing with plists. Same thing like system D system D is a completely custom format. It looks kind of like I and I ask, but it's a completely custom format. Right. And you're never going to use it for anything else. And then same thing with the windows thing. So I've got servicemen and servicemen. It's just, it's a go wrapper that templates out the correct file for whatever you want. And this is how I use to install caddy on different servers is I just run. So do ENV path equals path servicemen, and then give it the options that I want it to run with and it creates the system D file, it puts it in the right place, yada yada. So I'm, I, I'm going to pick on my own little utility that built Servicemen. And, um, there, uh, because of what we've been talking about, I'm going to pick the stack overflow 2020 developer survey. As, as all of you know, I'm a big advocate of learning the basics. I've been working on beyond code bootcamp.com, which is going to be, uh, it, it's a paid course, but I've got a couple of beta students right now that are going through the first versions of the material so I can iron the cakes out. I'm a big believer in, like, don't go to a boot camp for Python, you know, go to, like, learn how to be a software engineer and learn the fundamental pieces as well, or, I mean, like, do go to a boot camp or whatever, you know, like, do whatever you need to do that's a good option for you to enhance your quality of life. But, like, don't skip out on the basics. And the Stack Overflow Survey, which...There's a lot of different ways to interpret these numbers and whatnot. But if you look at the technology section and top paying technologies, you see up there, you've got Go, you've got Rust, you've got Bash. I can't imagine people are making a lot of money writing Bash. I suspect, this is my suspicion, but I suspect that the reason Bash is up there on high paying is that people that are up in high paying positions also know Bash. And so that's bringing bash way up there towards the top because bash is an old technology, it's not super useful in terms of you would net like if you could. Pretty much you'd always want to write whatever you're writing in bash. You'd want to write it in something like go or, you know, potentially Python, but it turns out to be really, really super useful. And, and you know, these old technologies, they're down at the bottom of the pay list, your C your Java, your PHP. Like that stuff is not. That's not up there. So I think learning skills that are, there's a difference between high availability and high demand. Like learning a few skills that are in high demand, that are the things that are making more money is a really good idea. And when you look at the Stack Overflow survey and you look at like the technology section, look at what languages are most loved, what languages are top paying, when you look at salary and you see like...Where is the trajectory going? You think, oh, well, maybe I want to go from being a junior front-end developer to a senior front-end developer. But is that really going to change your career trajectory that much and in a good time frame? When you look at some of these graphs, you see it's the people that know the networking layer, the SREs, the DevOps, and even the full-stack developers, the people that are on backend, they're they're ranking higher. So these core fundamental skills, it's not that like learning bash and how a file system works and how HTTP works is gonna get you a $150,000 a year job, but the people that have those jobs know those things. So anyway, take a look at it. 

CHARLES MAX_WOOD: Awesome. Amy, do you have some picks? 

AIMEE_KNIGHT: I'm gonna back up what AJ is saying. I completely agree. And I don't know, there's room for everybody, but as somebody who really enjoys this stuff. I feel like, and it's like, it's like a career craft, you know, something that's important to me, you know, always learning more and understanding more deeply. Like it's something I want to do because I, you know, take pride in what I do and I want to be as good as I can be. So anyways, I guess on that note, I dropped this in the chat already, but, and I feel like I've mentioned it before, but I really liked the cloud flare blog. They have like an education section. And they had pretty good, pretty short run down on the OSI model. So I'll pick that. I don't know. I'm trying to think of something else to pick. I'm going to pick learning about other cultures because we have an internet work from India and I've been learning, I've loved working with her and been learning a lot about her culture and I really enjoy it. And it helps me, you know, understand that Western culture is, you know, not the only way, so that'll be it for me. 

CHARLES MAX_WOOD: Nice. All right. I'm going to throw in a few picks. So I have been working on the MVP, most valuable programmer. And basically what it boils down to for me is it seems like, and we talked about this last time, I think every team seems to have that one or maybe two people on the team that everybody goes to, to get input on what they're doing. They tend to lead a lot of the technical discussions. They tend to take the lead on how the team runs, agile development or otherwise. And so there are certain behaviors that I found that certain that they have that make them that MVP. And so I'm putting together a course called the MVP bootcamp. Sorry, AJ, I kind of the branding anyway. So, uh, I'm going to be putting that out here within the next week. And I'm doing a prelaunch similar to what AJ is doing, but I think if you're new, it looks like AJ yours is geared more toward newer folks and mine's geared a little bit more toward advanced folks. 

AJ_O’NEAL: That's what I'm thinking. Yeah, I'm looking at how to help people either get that first job or get out of the junior rut. 

CHARLES MAX_WOOD: Yeah. Yep. And I'm looking more at the people who are kind of the junior to mid-level that are going, I'm stuck. So you know, and I'm really looking to help people get into things like podcasting, blogging, speaking, etc as well and advancing their careers that way. But anyway, I'm also working on a podcasting bootcamp. So if you're interested in either of those, the one is at devchat.tv slash MVP and the other one is at podcastplaybook.co. And so you can definitely go check those out. Besides that, I finally finished the Lightbringer series by Brent Weeks. And it's a terrific fantasy series. Holy cow. I was a little worried that I wasn't going to be able to find another fantasy series that I really loved. I knew they had to be out there, but I was having trouble finding them. And that one has just been tremendous. Really, really enjoyed it. I think initially it was supposed to be a trilogy wound up being five books. Whatever you call that, a pen till the cheap pendant anyway, but yeah, terrific books, so definitely enjoying that. And yeah, I'll have more picks to throw out next week to be sure. One other thing I want to throw out is I have put together a JavaScript resource guide. And so if you're looking for IDEs or CICD pipeline tools or things like that, I've got links to a bunch of them that I know about on a page on devchat.tv. I'll put a link to that in the show notes as well. And that way you can go and, you know, find the stuff that you need. And if there's a particular resource that you're looking for that's not listed there, let me know. And if you know of a tool that fits under one of those that's not listed there, also let me know so that I can make sure that those get listed. And yeah, that's, that's it. That's what I've got. Matt, do you have some picks for us? 

MATT_HOLT: Oh, I did not prepare. Let's see. What's on my mind right now? Source. I use, I like using source graph to explore source code code bases. I think it works for JavaScript too. This is really helpful. So you can like click and get information about like each identifier and find its documentation and where it's definitions and things like that. So I don't know. Is that a pick?

AJ_O’NEAL: That's definitely a pick. I'm surprised you found need to use something outside of the built-in GoTooling. What does Sourcegraph give you that GoDoc doesn't? 

MATT_HOLT: Oh, you know, so a lot of times if I'm linking people, it's when I'm linking people to various places within the code base, I'll use Sourcegraph. Yeah. Because like, yeah, my built-in editor, the GoTooling is great for what I need, especially nowadays. But it wasn't always that way. So I used Sourcegraph before that. But when I'm linking people to places in source code. I'll often link them to source graph. Yeah. 

CHARLES MAX_WOOD: Awesome. All right, well, Matt, if people want to check in with you later online, where do they find you? 

MATT_HOLT: You know, it's okay to just go to the caddy community. That's at caddy.community. And you can post there. And I usually read every topic. I don't have time to reply to all of them, but if, yeah, feel free to post there. We have a few active contributors who will answer. Pretty much everything. I think everything gets responded to. So yeah, we go there. 

AJ_O’NEAL: But what about you for you and like other projects you want to do or do you ever tweet career advice or what you learned today? 

MATT_HOLT: I do have Twitter. Yeah, you could ping me on Twitter. Mholt6, M-H-O-L-T-6 on Twitter. Yeah, I'd love to chat with you on Twitter or GitHub. Like you can always post an issue, especially if it's like technical about any one of the projects that I'm doing. 

CHARLES MAX_WOOD: Nice. All right, well, go ahead and put links to all that stuff in the chat and we'll make sure they wind up in the show notes. And yeah, this has been really fun. So we'll wrap it up. And until next time, folks, Max out. 

 
Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit C-A-C-H-E-F-L-Y dot com to learn more.