Testing JavaScript Applications by Lucas da Costa (Coupon for 40% off: podjsjabber19)

Lucas da Costa literally wrote the book on testing JavaScript. He's also maintainer on ChaiJS and Sinon. The podcast follows a three part structure for testing: Entrance tests, integration tests, and structural tests. These form a pyramid of testing that has the entrance tests at the base and the structural and system tests at the top. The episode also covers TDD and approaches to different kinds of JavaScript testing.

Panel

Guest

Sponsors

Links

Picks

Testing JavaScript Applications by Lucas da Costa (Coupon for 40% off: podjsjabber19)

Special Guest: Lucas F. Costa.

Sponsored By:

AIMEE_KNGHT: Hey everybody. Welcome to another episode of JavaScript Jabber. Today on the panel, we have Steve Edwards. 

STEVE_EDWARDS: Hello from Portland. 

AIMEE_KNGHT: We have AJ O'Neill. 

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

AIMEE_KNGHT: I am Amy Knight coming at everyone from Nashville per usual. And we have a guest today and I'm going to butcher his name because I've already forgotten how to pronounce it, but it is Lucas de Costa. 

LUCAS DA COSTA: Yeah, exactly. You're going right. Yeah. Speaking from London.

AIMEE_KNGHT: Thank you for coming. Do you want to introduce yourself? And then after that, probably let us know what we're going to be talking about today. 

LUCAS DA COSTA: Yep, absolutely. So, so yeah, I'm Lucas. Well, I am a software engineer. I live here in London, but I'm originally from Brazil. So I've been involved with like plenty of open-source communities. I'm a core maintainer of ChaiJS and SinonJS. So I've done a lot of work on that, contributed to numerous other projects as well, like Node School, like Jest. And more recently, I've also written a book about JavaScript testing, given all the things I've done in the ecosystem. And I also write a lot on my blog, lukezfcost.com, and I'm always speaking at conferences as well. So yeah, that's pretty much what I do. 

 

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 audibletrial.com slash code. That's audibletrial.com slash code. 

 

AIMEE_KNGHT: I am super excited to talk to you because I always say, I don't have many strong opinions as far as programming goes, but I do have very strong opinions about testing. So whether it be unit testing and end testing, I love it. You know, I don't know, I'm going to paint a little bit of a backstory for people that are on the fence about it. But basically, my second job, I had on-call rotation. And they're really... By the time that I'd been there for a while, we had different people kind of scattered around and there were really only like two of us. And so we were on call every other week. And we had a really, really, really sweet tech stack, but almost no tests, which meant not exaggerating, usually woken up in the middle of the night, two to three times a night, on average, a couple nights a week. So and still expected to be at your desk for your nine to whenever the next day. And it was exhausting. Absolutely exhausting. We had a couple hackathons there and I spent the entire hackathon weeks just writing tests because there are just so many regressions. And then also to the point where customers were potentially not going to pay their bills because we had so many regressions. So yeah. I am a huge, huge, huge proponent of testing. 

LUCAS DA COSTA: That's good. That's excellent. Yeah. Like that's one of the things with testing. I think like the more time you invest in it, the less time you spend in the long run. So it's just like, it's such an essential practice. I think it like touches as well, so many points of what makes a good software delivery process that I think is just like invaluable to invest in tests and automation. Like I think that's the subset of automation. That's probably one of the most, most valuable ones, you know.

AIMEE_KNGHT: Yeah, it's almost like a precursor. Like you can't have continuous delivery until you have tests in my opinion, or at least like kind of some overarching tests so that you have some level of confidence in what you're getting out the door to your customers. But I guess maybe talk to us about, it sounds like you are mostly in the unit testing realm. Can you, maybe we should like start off very briefly, like can you give the people listening maybe an overview of the different types of tests? 

LUCAS DA COSTA: Yeah, absolutely. So yeah, so on my, on my book, basically I divide tests into the traditional testing pyramid category. So there are entrance tests, integration tests, and unit tests. I've seen people that like to have like different divisions. I've seen, for example, I think it's Ken C. Dodds, if I'm not mistaken, he has like a testing trophy where he has like a bit of a different approach to it. I quite like the traditional approach. So basically like for, for the ones listening. The testing pyramid is basically a pyramid divided in three sections. So end-to-end tests come at the top, integration tests come in the middle, and unit tests come at the very base. So when you think about the structure of a pyramid, end-to-end tests come in the top because they are the ones that are less frequent and they are the ones that are like that require more integration between the different parts of your system. So they have like you have them in less frequency, but they're the ones that deliver more valuable, more value, but they take more time to write and they're more costful to maintain. Integration tests come in the middle because they're not so, so costful to write, but they're also end-to-end tests come at the top because they're less frequent and they're more costly. Then integration tests come in the middle because they're less costly than end-to-end tests, but they're also like a bit less valuable. And then you test them at the very base of the pyramid because they're very quick to write, easy to maintain, but they're not as valuable. So that's how I would separate the tests in different categories. And when I'm writing tests, I tend to keep the shape of the pyramid. So I write lots of unit tests I'm developing. I'm a big fan of TDD and I try to do that with a lot of discipline. So my tests really resemble a lot the structure of the testing pyramid. I also write a lot of integration tests, but I also place a lot of value on entrance tests and I try to make them as decoupled from the internals of my code as possible. So they don't cost them as much. I don't think that answers your question as you expected. 

AJ_O’NEAL: So, yeah, 

AIMEE_KNGHT: I think it does. Sorry, AJ, go ahead. 

AJ_O’NEAL: What were the three types or four types of tests you, you said, you said integration tests, did you say entrant test? 

LUCAS DA COSTA: No, sorry. So it's end to end at the very top. 

AJ_O’NEAL: Oh, end to end, end to end. 

LUCAS DA COSTA: Yeah. 

AJ_O’NEAL: End to end. 

LUCAS DA COSTA: Exactly. End to end integration in the middle and unit tests at the bottom. So yeah. So as you go to the top, you have more valuable, but the tests are also more costly. And then as you go towards the base, that's our last cost label, they deliver less, less valuable because they rely more on your internals. You're not really testing from a user perspective. So that's how you go from like the base unit tests to the top and twin tests. 

AJ_O’NEAL: Agreed. So what I'm curious about, you're writing a book called testing JavaScript applications. This is still in the early access phase, right?

LUCAS DA COSTA: Yeah, exactly. So it's currently on Manning's early access program. I think we have 12 chapters there. And we are now talking about whether we should go for the 13th because essentially I've already gone over the limit of pages we have talked through. So we're still checking whether that's going to happen, but almost everything is there already. 

STEVE_EDWARDS: Wouldn't that be bad luck to end on chapter 13 though? 

LUCAS DA COSTA: Sorry? 

STEVE_EDWARDS: Wouldn't that be bad luck to end on chapter 13? 

LUCAS DA COSTA: Oh. It depends on how superstitious you are. I'm not superstitious at all. So I wouldn't mind. I would actually love to try that chapter. 

AJ_O’NEAL: So, I want to talk a little bit about... Because one thing, we've had people on the show that have books. We haven't really talked much about the book process. And so I'm actually kind of curious to take us a little in that direction. So how many years of experience did you say you have?

LUCAS DA COSTA: So right now I've been working since I was 18. So I'm probably on the professional side at like seven years, something like that. 

AJ_O’NEAL: Okay. And how did you get to the point of deciding to write a book, especially on something that it feels like, you know, there's, there's a lot of books on JavaScript out there. I mean, there's, there's very popular book topics. So like, how did you get to the point of knowing that writing a book was something you even wanted to do and like getting in touch with these people and picking this topic and making it unique. 

STEVE_EDWARDS: I'm gonna guess it's not because you were gonna get rich from what I heard about people writing tech books. 

LUCAS DA COSTA: No, definitely not. Definitely not. Well, I'm a very avid reader. Like I read a lot. Like I just I love reading and I've always wanted to write a book. So I thought, well, why not start with something I know a lot about, you know. Because writing a novel is too hard. Writing a technical book is hard, but it's not as hard. And it's also a topic I love so much that I thought it was going to be like a nice achievement to write a book. So I'm doing mostly for personal, like as a personal thing, I love reading and I love writing. So that's why I decided to write a book. And I think that the reason I've chosen JavaScript testing is because I found it easy to find material like scattered online. So there's like lots of blog posts, like you can easily find lots of videos, but I thought it was hard to find good long form material that had all this knowledge condensed into like one single piece of content. So when I was researching for books, I've seen there's like books about how to test Vue.js, how to test React applications, or how to write like tests with Cypress or...I don't know if there's a book about Cyprus specifically, but like how to write like that's with Selenium and that kind of stuff. But I didn't find a book which touches all the subjects I touch in my book, which are like going from the very theory of like what's the testing pyramid, what are the different kinds of tests to how they deliver value. And then from that theory to practice of like, okay, now that we know how tests deliver value, how do we go about writing those tests and integrating them into our development process? So that's why I've decided to write about JavaScript testing specifically. 

AJ_O’NEAL: So I want to, I want to get into that. I'm I, but I want to back up a little bit first. So did you, were you like searching out different publishers that might want this book or did somebody contact you from your speaking engagements? How did that relationship with Manning get started? 

LUCAS DA COSTA: Right. So I went to an event in Serbia called Armada JS, which by the way, was brilliant organized by my friend Marco. So I went there and I was speaking to a friend of mine called Stefan, really great guy. And I was telling him about, you know, my, my desire to write a book that, you know, I've been wanting to do this for, for a long time. And he knew like an acquisition, Zetra and Manning. And basically he introduced me to them. And we went from there to like writing a proposal and then like talking through, you know, who would the minimum qualified reader and you know, the whole market and from there onwards, I got connected with my development editor Helen, which is also brilliant. And yeah, then I started writing. 

AJ_O’NEAL: So what is a minimum qualified reader? 

LUCAS DA COSTA: That's an excellent question. So a minimum qualified reader is the person you write for because when you're writing, it's very difficult to write good content without knowing what you can and you can't assume about what your readers know. So defining a minimum qualified reader consists of thinking about, okay, who, like, what does my average reader know? So like, does my, we like, does my average reader know how to write code professionally? Do they know like about JavaScript, like about promises and about other like advanced subjects within JavaScript? You know, what can I assume and what can't I assume and I explaining things. 

AJ_O’NEAL: Okay. So what, what did you decide your minimum qualified reader was for this book?

LUCAS DA COSTA: Right. So my minimum qualified reader for testing JavaScript applications or junior developers who can already write code professionally, you know, they've got a first job, they can deliver tasks like they had, they require some assistance, but they can essentially write JavaScript code and they understand the basics of how JavaScript works. So those people, they're my minimum qualified readers. 

AJ_O’NEAL: Okay. So what, tell me a little bit more about like, what is it? I, this is one I really honestly don't know anymore. What are the basics of JavaScript these days? Like what? 

LUCAS DA COSTA: Right, it's a debate. 

AJ_O’NEAL: Cause it's like, everybody's talking about React, everyone's talking about Vue, are those basics of JavaScript? Like, yeah, what is that? 

LUCAS DA COSTA: Yeah, I wouldn't say those are our basics of JavaScript. I think, so the knowledge I assume from my readers are they must know the basics about promises. Like for example, they know how to use promises. They don't need to know like anything about, you know, how I did like the designs of promises or how to use them properly. They need to know like, okay, this is like, this is how the event loop works. I have an idea of how promises work. So they can use promises. Um, they know like the, the standard library, you know, very well, like they know, like what functions they can call on the race, you know, they know how to use, uh, map the reduce, you know, just JavaScript like native. I'd say they can attach elements to the DOM. They can update the DOM using JavaScript. I think that's the basics. I wouldn't say knowing anything about React and Vue are basics also because since those are libraries that not everyone uses, like maybe you use React but not Vue or maybe use Vue and not React, I wouldn't include those as basics. And that's why on my chapter about testing React applications, I explained okay, this is what happens when you try to run JSX in the browser, you know? So I try to go through that process step by step so that we just know, okay, so if this is how it works on the browser, this is how it's going to work on Node.js when you're going to test it. 

AJ_O’NEAL: Okay. So you consider basics JavaScript knowing both Node and DOM? 

LUCAS DA COSTA: Yeah. I wouldn't say like knowing much about Node because I don't use anything that's Node specific. Like as long as you know JavaScript itself, like the syntax, like how promises work and that kind of stuff. And the DOM, I would say that's enough because I don't use anything really that's, that's node specific that you can't do in the browser. Like a very, very few things that, you know, are like hidden by the modules I use. Like for example, if I'm dealing with web server on my book, I use Koa. So that's kind of like hidden away because of the library you're using. So there's nothing really that specific about being able to use node itself. 

AJ_O’NEAL: Well, cause when I think of JavaScript unit tests, I think of nodes because that's where you can actually just use JavaScript. Whereas if you're in the browser, you have to have lots of other layers on top in order, you know, cause you only have console.log in the browser. And then like, how do you even, how do you even get JavaScript to load in the browser? You have to have like a web pack and that's,

LUCAS DA COSTA:  that's a very interesting, very interesting point. So the thing is because, okay, all your tests run and node, but I would say that like, when I assume that my readers know JavaScript, knowing JavaScript is enough for them to do what they need on the testing side, because I think the only thing that's really node specific that you need to know is how to install a module and how to run tests. So that's the only thing that's more node-specific. And another interesting thing is, okay, how do you go about running tests in the browser? Because in the past, I mean, I wouldn't say in the past, because there's many people that still use Mocha and it's a brilliant library. You can run Mocha in a browser. If you go to Chai's website, I think there's a page there which runs all of Chai's tests on your browser. And we even use run tests for Chai itself on many different browsers using Karma. So it's just for Jest that we are mandated to run tests on Node. I think it's also important to make that distinction because I think your tests are kind of different from the environment you run them in. It just happens that Jest can only run in Node and therefore, yeah, you need to have like the, we need, you need to know how to manage modules and how to do the basics of like using NPM, but those are all things that I go through in the book. So I don't go through them in detail, but I do teach you everything you need to know step by step so that you can get tests running. 

AJ_O’NEAL: So, but so here we still have another question. Like, are you teaching how to use, you know, like you've got these browser specific or, or ambi, I don't know multi-platform test frameworks. Like when you teach testing, are you teaching the frameworks or are you teaching like more underlying principles? How would somebody run a test in a browser? 

LUCAS DA COSTA: So in my book, I start with first explaining the value of tests. And then I talk about like the practices around organizing your test suite, how you go about thinking, okay, what is the formula I need to follow for every test? Because for every test, there's a minimum formula you can follow, which is arrange, act, and assert. That's the three A's pattern. So if you follow that pattern for all of your tests, you can write tests in whichever frameworks you're using. So you first arrange- 

AJ_O’NEAL: Say that again. The three A's pattern is what? Arrange? 

LUCAS DA COSTA: Arrange, act, and assert. So the three A's pattern consists of arrange, act, and assert. And if you have that pattern on your test, you can write tests in whichever framework you're using. So you first arrange a scenario, then you act, and then you check the results of the actions you've done. So with that pattern, you can write any tests you want. And because I teach you the fundamentals of that, like how to organize your tests, how to do proper assertions, how to follow the three ACE pattern, how to think about tests, you can easily bring that to your framework of choice. And in JavaScript, it becomes even easier because of how similar Jest is to Mocha. So it's very, very easy to, you know, if you want to use Mocha or if you want to use tape or whatever testing framework we want to use, I think there's many things you can bring from the book to all these other frameworks. And even if you're writing tests in other languages, there's many parts that will still apply, like for example, how to write good assertions, you know, how to organize your tests, how small they should be, you know, when should you do multiple assertions or what you should assert, you know, all that, all that kind of stuff. So the, the first part of the book covers those fundamentals like the values of tests and the fundamentals. And then the rest of the book is more practical. And in the end, I talk a bit more about business value and how to integrate tests, for example, in a CI CD pipeline and that kind of thing that's more business focused. 

AJ_O’NEAL: So when you say more practical, what does that mean to you? 

LUCAS DA COSTA: So that means like writing an application with the reader and showing them how we would go about testing it. So for example, writing a basic web server and showing them this is how I would test this program. So it's very hands-on. It's a very hands-on approach. So in the middle of the book, you have all those examples, you know, all the code is on GitHub, it's very practical. So you can read those chapters and the next day you can apply that at work. So that's what I mean by practical. 

AJ_O’NEAL: Okay. Cool. So I, is it, could you give us the title of each of the chapters, the draft titles, would that be okay?

LUCAS DA COSTA: Yep, that would be absolutely okay. I don't remember all of them by heart. I might need to cheat and go to Manning's website because it's 13. I just want to make sure I'll get the order right as well. 

AJ_O’NEAL: Take a second to do that. We'll just edit out the pause. 

LUCAS DA COSTA: Okay, cool. I got it here. So testing JavaScript application has three parts. So at the moment it starts with an introduction to automated testing, then explains what to test and when. The third chapter covers testing techniques. The fourth teaches you how to test backend applications. The fifth teaches you advanced backend testing techniques. The sixth covers testing frontend applications. Seventh talks about testing and the React ecosystem. Eighth talks about how to test React applications. Nine covers test-driven development. The 10th chapter is about UI-based end-to-end testing. So Cypress, Selenium, that kind of test. The 11th chapter covers how to write those kinds of tests, writing UI-based end-to-end tests. The 12th chapter covers continuous integration and continuous delivery. And the 13th is called a culture of quality. And in it, I talk a bit about other techniques and tools which you can use to amplify the benefits of your tests. Like for example, types, like for example, linters, formatters and that kind of tool. 

STEVE_EDWARDS: So I noticed that you've got two chapters on testing React versus other frameworks, Vue, Angular, Svelte, you name it. So I'm just curious, is that because you're more familiar with React or do basically the principles of testing with specific frameworks carry over to some of the other frameworks other than React? 

LUCAS DA COSTA: I think some of the principles do carry over. So the reason I've chosen React is because I think that's what most of my readers would be using in their day-to-day job. And I think that because I am very experienced with React, it makes it very easy to explain what's happening behind the scenes so that people actually understand how the testing environment is set up. And then I think if you can step back and before you write your test, understand what your tool is doing behind the scenes, how Babel is working, everything that's involved in actually getting the environment to work, I think you can apply similar steps to other frameworks and tools so that you can write tests for whichever frameworks and tools you're using. So I think it's both because of popularity and because it's one of the, I think, best ones to explain given my experience. 

AJ_O’NEAL: Oh, I'm just discovering it looks like, is the entire book online? Like anybody can look at the entire book right now in the draft preview state?

LUCAS DA COSTA: Yeah. So I think the, the way Manning's Manning works is you can go there and as you scroll, I think you have a limit of, of, of pages you can scroll for free, something like that. So I think you can jump to chapters and read that. And, and at once you've read the limit number of pages, I think you will, you will like start to, to not be able to, to scroll through anymore. 

AJ_O’NEAL: You got to open up a new incognito window. 

LUCAS DA COSTA: Sorry. 

AJ_O’NEAL: I was being facetious. I said, you got to open up a new incognito window. Because oftentimes when I hit a paywall on things like that, where I'm trying to read something and then it hits me with a paywall, I close the incognito window and then open up a new incognito window and then just continue reading. 

LUCAS DA COSTA: Right. That makes sense. Yeah. I think, by the way, I don't know exactly how the live region works. I think that would be good as schematic because I don't want to speak for them. Because I don't know how it works because that's more on their business side.

AJ_O’NEAL: Yeah. Anyway, I just, it's cool. You definitely, whatever the rule is, you definitely can preview a ton of content. Cause I've just been clicking around here and just scrolling and I can see like diagrams and the code snippets and the code snippets have like a thing you can copy. How, what's the format for this? Like how were you able to create these? Well, how were you able to create the diagrams and the code snippets? 

LUCAS DA COSTA: So the diagrams I've been using a tool called draw.io. I really like it because it produces like XMLs so I can, you know, edit everything. It's just like SVGs and it's super easy to export and export and import things into it. It's super good. And for the whole text and snippets, I've been using them. So I just write it all in plain text. And then I just generate the actual PDF manuscript using ASCII doc. So it's, it's been a great process. Like I'm very happy I've chosen to, to write it all in plain text. It's saved me so much time, you know, cause I can just copy like easily like write scripts to number images, to import and export images, you know, to copy snippets into my GitHub repo. So there's a lot of automation going on and it's just very pleasant to write with them. Yeah. It's amazing. 

AJ_O’NEAL: How does ASCII doc compare to like Markdown or other? 

LUCAS DA COSTA: So they're very similar. They're, they're very similar. The syntax is, is very similar. I would say that the difference between ASCII Doc and Markdown is that Markdown is usually meant for you to write single blog posts, documents that don't necessarily have correlation to each other. Of course you can do that. You can add header attributes. There's many things you could do, but ASCII Doc is a tool that was designed for you to write long-form content. So if I want to write a book, I can easily have multiple ASCII doc files and I can easily build them all into a single piece of content. So I think that's the main difference between ASCII doc and Mockdown is what they were designed for and Mockdown because of its intent, it deals a bit differently with snippets and images. So it has like some special formats for different kinds of call-outs. Uh, you can easily style things using CSS. So like if you're, if you're writing a book, that's excellent because it allows you to easily diagram things, like easily format things and, you know, alter the positions on pages and all that kind of stuff. So yeah, I'd say the main differences Markdown is more for like single doc to write a single document and you'd use ASCII doc to write an entire like book or long form content. 

AJ_O’NEAL: Okay, cool. I'll have to look into ASCII doc. That might be something good good for me. Did you find it to be very pleasurable? Well, you said you found it to be very pleasurable to use because it's just plain text. 

LUCAS DA COSTA: Yeah, it's I am a big fan of plain text. Like if I can do something plain text, I'll do it in plain text. 

AJ_O’NEAL: Well, yeah, because I mean, you do plain text and then it's kind of weird because it's the opposite of what people say. But what you see is what you get with plain text. You know, you know exactly what it's going to be. You know how to edit it. But with 

LUCAS DA COSTA: exactly 

AJ_O’NEAL: with whizzy wigs with the quote, what you see is what you get editors, you never know what it's going to look like when it actually like goes to a different format because you just see it in like the plane, the plane HTML version. But then when you put it on the page and it gets me or murdered. 

LUCAS DA COSTA: Exactly. And like one, one of the things that I've done that was that just proved how, how good my choice was, was when I had to like divide chapters, because I had some chapters that were like quite long and I had to split them and when you split chapters, you essentially have to change the numbers of all your figures, change their positions and all of that. So when I had to do that split, instead of me going through all the figures that I had, renaming them, manually moving things in like, like different folders, all that kind of stuff, all I've done was separate chapters, create a script which just read each figure call out on each chapter and automatically assign new numbers to them and rename the old files. And that took me like 10 minutes to do like all chapters instead of taking like hours in it. 

AJ_O’NEAL: So that's cool. And then these, these code blocks online, they have like, you can copy and stuff. By the way, I did hit the limit. So now it's applying a rot 13 to all the text. All the text is, uh, now it looks like gibberish. So it's all there and all the code, anything that's in a code block is correct. But all of the words that were English have now become gibberish. But when I do, so when you do a code block, Was there anything special that you had to do for like the note sections or the copy section or any of this stuff? Or is it just, you create a code block section in ASCII doc and then the way that Manning renders it, it gets a copy button because it knows it's a code block. How does that work? 

LUCAS DA COSTA: Yeah. So I do have to specify what kind of syntax I'm using and just like the note that it's a code block using, I think it's four dots. So as long as I do that, I put it like a file name. The the type of code I'm writing so that it can like syntax highlight and just like write the code block. The only thing I had done was I've written a small script, which validates the syntax of my snippets to make sure there's no typos. But that was mostly it. There's no, like, there's nothing special about. 

AJ_O’NEAL: So prettier, prettier doesn't run on ASCII doc yet. Huh? 

LUCAS DA COSTA: No, no, it doesn't. It doesn't. But that's a very good suggestion. I might, I might incorporate that.

AJ_O’NEAL: Yeah. I'd love that. Also, is there, is there a way you could give us a gist of that snippet that you used for ASCII doc for anybody that, I mean, like I, I would use this. I, I'm, I'm seeing what you did here and you know, we started the show about testing and hopefully nobody's upset. I've gone so much into the book, but I actually find what the process that you went through to write the book, the thinking process, the, how you align, you know, the knowledge and all that. I'm finding this to be very fascinating because this is something that I don't think we've actually talked about before on the show. 

LUCAS DA COSTA: Yeah. I am actually writing a blog post. I started writing a blog post last weekend about my process of writing the book. And in it, I'm going to like play some of my snippets, explain a few of the things I had done to make it more pleasant to write. I can probably like get a few snippets here. 

AJ_O’NEAL: Yeah. Do you know where that's going to be published? Is that on your like personal blog that you could just give us a link to and I could check that out next week? 

LUCAS DA COSTA: Yeah. So that's, that's going to be on my personal blog. It's probably not going to be out next week, but is that going to be out by the end of the month. 

AJ_O’NEAL: Okay. 

LUCAS DA COSTA: Because I'm going on holidays in the start of December and I want to get it done by then. Go ahead and give us a link to that. What is it? So yeah. So my blog is LucasF Costa.com. So let me copy the link and send it to you. So it is here. So yeah, by the end of November, I'll have a blog post there with the whole process, a few of my snippets, you know, how ASCII.com compares to Markdown, all that kind of stuff. 

AJ_O’NEAL: Oh man. I'm really interested to check that out. I hope I've been needing something a little more powerful. Oh, sorry. What'd you say? 

LUCAS DA COSTA: I was really looking forward to writing this since, you know, I've reached the half of the book, I thought, you know, ask you, ask you docs, just amazing. I should just write about this. 

AJ_O’NEAL: Oh yeah. Cause I I've really been needing something more powerful than markdown. And I've like, I was doing some stuff in Google docs and then that wasn't working out for me because that was just a terrible experience and then Dropbox paper has actually been working really good, but it's not, it's. It's just got a few quirks and, and so, uh, ASCII doc might be, might be the thing that I'm looking for. So I'm, I'm super glad that we're having this conversation and I'm thinking maybe we should get back a little bit to the testing topic. You had a couple other points here. Actually one, I don't, I don't know if this was testing related or not, but you've got one of the talking points you gave to us was about Vim and CLI tools. Tell me about that. I mean, I'm a Vim user, so I, I want to hear what you, you know, what, what, what do I need to know as a Vim user about testing in JavaScript?

LUCAS DA COSTA: Right. So as a Vim user, I don't think there's anything that's really that Vim specific. I think that, you know, I, as long as you have your ads to configure to match your like individual preferences and that it can like syntax highlights and, you know, as long as you have access to, you know, code completion and that kind of stuff, I think you should be fine. One of the things that I think helps a lot in terms of correctness in general, not necessarily about tests is having code of completion set up if you're using Vim or I don't know, I think IntelliJ IDs call it like IntelliSense and that kind of stuff for their like type detection and smart suggestions thing. So all of that is super useful when I'm writing code. Like many times I'll just press like shift K and then activate like the tooltips from code completion to see the types of, you know, types of like the types of function returns or what are the arguments it takes and just like make sure that, you know, all the types match everywhere. And as long as you know how to constrain your application state using types properly, it helps a lot. So if you are using TypeScript very strictly, then usually if it compiles, it will mostly work. I mean, it's not like Haskell, you know, you have to understand that not like Haskell or Rust, but it's definitely very, very helpful to have that in terms of correctness. 

AJ_O’NEAL: Yeah. I'm looking at your blog article that you put in the show notes and I guess I'll link that here too. But it looks like you've got to, I mean, this is fairly easy to read as, as someone who's used them, you know, I'm, I'm, I'm not new to VIM by any means. I've used it for years, but there's, I have not become an expert in terms of like the config and stuff. And I'm just kind of looking through you talking about your plugins that you use and stuff like that. So, but this, none of this is particularly related to testing. I thought maybe there was like some plugin that every time you hit save will automatically run tests or something like that. 

LUCAS DA COSTA: Right. No. So I, I leverage like other tools for that. So because I've worked mostly on my terminal, like I'm 99% of the term that all the time in my terminal, what I do is I usually just have like no demon running my tests whenever I save my files and then I use Tmux so that I can easily have multiple panes. And then whenever I save a file like on the pane on the left, it will run my tests on a small pane on the right. And then I can just like easily like make one of those full screen and then jump back and forth between, you know, the test output and VIM. So that helps me a lot in terms of workflow, but it doesn't make a difference in the actual code I write, but that's super helpful, you know, for running tests, being able to see the results of your tests as you write them and, you know, just have them quickly running whenever you save files, it's super useful. So for that, yeah, T-Mux helps you split panes, split windows into multiple panes. And then I just use Node Demon to keep my tests running. I am not really a big fan of Jest's watch. I prefer to use Node Demon. So yeah, so that's what I usually do. 

 

Have you ever wondered if you could be offering a faster, less buggy experience for your customers? I mean, let's face it, the only way you're gonna know that is by actually running it on production. So go figure it out, right? You run it on production, but you need something plugged in so that you can find out where those issues are, where it's slowing down, where it's having bugs. You just, you need something like that there. And Ray Gun is awesome at this. They just added the performance monitoring, which is really slick, and it works like a breeze. I just, I love it, I love it It's like, it's like you get the ray gun and you zap the bugs. It's anyway, definitely go check it out. It's going to save you a ton of time, a ton of money, a ton of sanity. I mean, let's face it, grepping through logs is no fun and having people not able to tell you that it's too slow because they got sidetracked into Twitter is also not fun. So go check out ray gun. They are definitely going to help you out. There are thousands of customer centric customer focused software companies who use Raygun every day to deliver great experiences for their customers. And if you go to Raygun and use our link, you can get a 14 day free trial. So you can go check that out at javascriptjabber.com slash raygun. 

 

AJ_O’NEAL: So now everybody, not everybody, but yeah, just about everybody I know that is big on the terminal, except for me uses Tmux. And I like, I use iTerm. So, and really I just make windows. Like I just. If I need three different windows, I just make three new I term windows. And I've never really gotten on the TMUX bus. Um, but I like what sell me on TMUX. Like why should I use TMUX rather than just have open three I term windows? 

LUCAS DA COSTA: Right. So I think I used to use item. It was very slow for me. And then I moved on to kitty, um, which it was way, way faster. And now I'm using Alacquity. Uh, and I just like if I were using iTerm and any specific configurations on iTerm, I wouldn't be able to port them as easily to other programs. So I think one of the things is portability. So if you're using Tmux, wherever you're using Tmux, it's just Tmux and it's your configuration, so it's very portable. And yeah, because it works anywhere, you can just switch terminomulators very easily. So I'd say that's the main reason to use Tmux. And also because I'm so familiar with the shortcuts because I've been using it for so long that I just think it's not worth switching now because I have all my plugins there, my configuration, you know, it has all the things I like in it. So I didn't see any reason not to use Tmux. 

AJ_O’NEAL: I guess like, I don't even know why you would use it in the first, because I thought what Tmux was, was just allows you to have different windows open. So like you said, you can see your testing is open in one window, you can see your editors open another window. So you edit some file you save and then you immediately can see your tests running, which I think that's like, that's a big benefit. I'm just saying like for me, I've never had a problem with it being slow, but I don't load any plugins for it. In fact, the only thing that I knew that you could do as far as a quote-unquote plugin is a color scheme. So I'm not even, I'm not even sure like what it is that somebody does with something like T-Mox that is what, like, what, what is it that you have all this configuration for that it does that like that you find useful or that you're like, Oh, I got to have team bucks. 

LUCAS DA COSTA: So I have a few plugins to like control Spotify from, from team bucks. So I can just like, you know, just do things there. I have like, you know, my looks, 

AJ_O’NEAL: so I make it play a bad song when tests fail. 

LUCAS DA COSTA: Well, you definitely could because it's just Apple script, but then it doesn't happen on Tmux. But it's not a bad idea. But also another thing I like about Tmux is that it's not bound to any GUI-specific elements. So you can just close iTerm or close whatever terminal emulator you're using. And then your sessions are still there, so you can attach and detach them from them. I don't know if you can do that in iTerm. I think on iterm, if you have a window and you close it, it's gone. But in TMUX, you can just attach and detach to two sessions and they're, they're just going to be there unless you actually killed them. So that's also not a brilliant part of TMUX that you, I don't think you can have on iterm for example. 

AJ_O’NEAL: Well, iterm has TMUX integration for that. But again, like I see, I see iterm and TMUX is like completely different realms of thing, cause you can use TMUX with iterm, you can use TMUX with terminal.apps. You can use TMUX with alacrity. You can use TMUX with, you know, anything likewise, you can use screen with anything. I think there's like one other terminal mux manager or whatever people use. Anyway, I, uh, I was just, yeah, I was just kind of curious about that. Cause I saw that in the list. So, okay. Yeah, that makes sense. There's one other thing in the material that you had here that I was curious about. Why flat earthers are bad at QA. 

LUCAS DA COSTA: Wow. All right. That's an excellent question. So that was the title of my talk last year at Holy JS in Moscow, which is a brilliant conference by the way. So essentially I was comparing tests and types to like mathematics and physics, like how you can know things in advance using types like with static analysis. And you do actually have to run experiments as you would have to do, like for example, if you're an experimental physicist Right. So that was the title of my talk last year at a Holy JS Moscow, which is a brilliant conference, by the way. So in that talk, I'm essentially explaining why you need to have scientific to be good at scientific thinking, you know, to, to be good at testing types, tests, and why flat dirters are better QA. Right. That was the title of my talk last year at Holy JS and in it, essentially I take an epistemological approach to explaining tests. 

AJ_O’NEAL: What does epistemological mean? 

LUCAS DA COSTA: So, right. So that's, so it means- 

AJ_O’NEAL: That's like something I do with my Bishop. 

LUCAS DA COSTA: Right, right. No, so it's like, it's essentially, we're trying to answer the question, how do we know what we know, right? Like how do we know what we know about our programs? So that's essentially the question we're trying to answer. So with that question in mind, I talk about types and tests and talk about how they complement each other. So I try to explain how you can get benefits from-using types to complement your tests. And I also explain what the scientific method can teach us about correctness because I think it has a lot to do with how types and tests complement each other. So my whole idea in the talk is to say that tests are like experiments. So basically we execute parts of our programs, you know, parts of our code, and we observe its behavior. So if you have a certain function, you're going to pass it, you know, a few inputs and you're going to check if the outputs are correct, right? And then we extrapolate and we say that. If for those inputs, the output was correct, well, it will be correct for a wider universe of inputs. And then types, they're different from tests, which types are different from tests because while tests are like experiments, types are more like proofs. So you can use a strict system of rules to prove properties about your programs before they even run. Right. So while tests use a small subset of experiments to prove things about your programs types just prove general properties about your programs. Because if you tell that a certain variable can only have three different values, well, if you ever try to assign a value that's not one of those, your program will not pass static analysis. But in your test, if you haven't checked for one of those, maybe it will pass for two of the values, but not pass for the third. So the only way you can really prove your programs are correct is with types, not with tests. But you can use types to reduce the possible universe of inputs you can give to your functions. And then you can test those inputs, right? So then you can have, you can have more confidence in the programs you write. 

AJ_O’NEAL: Yeah. So that makes sense. 

LUCAS DA COSTA: Was that an explanation that was too long-winded? I'm a bit concerned I might have... 

AJ_O’NEAL: The whole thing is we just ramble on the show. I mean, you don't have to worry that much about that sort of thing, because people are listening because they got nothing else to do. They're like sitting on a train for an hour or something. I don't know. 

AIMEE_KNGHT: It's all good. That's like eight days time. That's what we're here for, is to go on these... 

LUCAS DA COSTA: Okay, okay, cool. 

STEVE_EDWARDS: That's our tagline. Listen to us when you have nothing else to do. 

LUCAS DA COSTA: Okay, cool. Yeah, but I would highly recommend people to have a look at the talk. It's a one-hour talk. It's fairly long and has some quite good insights that are very hard to condense in a few minutes. 

AJ_O’NEAL: All right. Well, I think...That sounds good. We're, we're closing up on time here. There's maybe two other things I wanted to bring up at first. I wanted to give Steve and Amy a chance to, you guys haven't piped in. I've been stealing the show. 

AIMEE_KNGHT: I had to disappear for a little bit. So I'm coming in mid and don't have, I don't have questions. All the questions I tried to ask at the beginning, but yeah, 

STEVE_EDWARDS: I think we answered everything fair. There's some other specifics I wanted to get into, but that's fine. I thought it was interesting to talk about writing the book. I know I've been a technical editor on a on a book in the past. So I was a little bit privy to the process. But, you know, from my conversations or listening to people that have authored books, I say kudos because it's a big undertaking and I think you're probably doing it more to help other people and because you enjoy it than for the money. That's for sure. 

LUCAS DA COSTA: Yeah, absolutely. I just love writing and what got me into writing was really all the reading that I had been doing recently. And I remember when I wanted to get into writing, I emailed a guy that used to write for the New Yorker. So I loved the magazine and I thought, oh, this guy writes really well. I'm going to just write him an email and ask him to teach me how to write. And I didn't expect to get a response, to be honest. But then I got a response quite quickly with lots of good recommendations on books and just tips on how to write well. And that was super, super helpful. And, you know, since that day, it just like completely changed the way I approach writing and, you know, teaching things to people, I think after that day, I just became so much better explaining things that, you know, I can't thank him enough. 

AJ_O’NEAL: Awesome. That's really cool. I, yeah, I think that's a good thing for people to know to just, you missed a hundred percent of the shots you don't take and a lot of people will reach out and respond back with, yeah, I'd love to help. There was, there was two other things, three other things that I had notes on here. One in the book, this is going, going back to the book. It looks like the way that you've structured the chapters here is that you've got like introduction, learn exercise, and then you kind of repeat that pattern. Do you find that I guess you find that to be the most effective or let me rephrase my question here. One of the things I've struggled with when I'm looking at like how to teach somebody something is there's always this bootstrap knowledge that if you don't have this base foundation, that's usually broader, then you can't do any exercises and you can't learn any of the other things. Cause you have interconnected terms where one term relies on another term. If you don't know both terms, you can't go forward, but it, you can't explain the terms independently because they rely on one another. Like you couldn't talk about Congress without talking about the Senate because the two have to go together in order to understand the way the government functions in the United States, for example. And so with, with your, the layout of your book, how did you structure materials so that, so that you are able to break things down, able to do exercises and able to do deep dives? Like what, what was the ordering decision around that? 

LUCAS DA COSTA: So the, the first part of the book is really about foundational concepts. So, and that part of the book. I talk a lot about testing pyramid and different kinds of tests and how to approach the city, like how to decide which kinds of tests, right. And when, so once I've covered that the next chapters are all about applying those decisions to different kinds of projects and watch to take into account from those different kinds of projects. So that's the main intention of, of searching it this way so that you can first understand what the concepts are and then apply them to different kinds of projects. And then once you have applied that to different kinds of projects, go a bit deeper into TTT into tools like Cypress and like explain a bit about continuous integration and continuous delivery and the role of tests in those practices. 

AJ_O’NEAL: Okay, cool. And then also two other things you said you were an, you're an intern as a QA intern is how you got your start in the software industry. And then you went on from that to build Chai and Sinon, which are pretty big projects. 

LUCAS DA COSTA: Yeah. So I didn't, I didn't start Chai and Sinon. I jumped in after they had been written and I did plenty of contributions to the point where I became a core maintainer. So the, the credit of creating that goes to the original authors for, for sure. Even though I've, I've done quite a lot of contributions there, but yeah, I've, I've got started in tech industry as, as a QA intern. So I was doing a lot of manual testing at the time and I was quite frustrated with having to do repetitive actions. I just thought it wasn't that fun and I thought machines could do it way better than I could. So that's how I started getting to automated testing. It was from a different perspective. I wasn't writing any code. I was just writing code to test the code that others were writing. So I was not writing application code, just the tests themselves. And I got to the point where I had automated a lot of the stuff I did. So I barely had to do manual testing anymore. And then I ended up becoming a software developer. And because I was concerned with not having to do these repetitive actions, I just brought that with me when I became a developer. And another important thing I think is also that when developers write good tests and when they build quality into the code they write, you know, and quality is built in, not bolt on. I think it enables QA professional to do a more proactive job of finding bugs and finding, you know, failures in general. Cause you know, if you have the confidence that your application is not going to break because of trivial actions, then QA can be a lot more exploratory. You know, they can give you way better feedback about many other different aspects of your application. 

AJ_O’NEAL: Yeah, I definitely think that automating problems for yourself is a...I mean, it's a great way just to learn programming period. You know, if you've got a clear vision of what the problem is and a clear vision of the solution that you personally want as an outcome, it makes it a lot easier to understand the concepts that you're encountering. And it sounds like a QA position is just a really good start to get like patterns and principles down because you, you have to do that in order to have reproducible results. 

LUCAS DA COSTA: Yeah, absolutely one, and even before this, I was also a big fan of automation. I remember my first experience, my first contact with programming was when I was writing bots to play online RPGs for me. That was the first time I've ever written a line of code because at the time I was playing an MMORPG that was quite popular, so called Ragnarok Online. And all my friends liked killing monsters and doing all these things in the game. But what I really liked was writing codes for bots to do things for me. I thought it was way more interesting. You know, so I was just writing Perl, you know, learning about regular expressions and, you know, all that kind of stuff. So it was really fun. And from there on, I just fell in love with programming and I was just, you know, really big into automating, you know, manual stuff. 

AJ_O’NEAL: So we've got an ongoing debate on the show. I just want you to back me up here. Regular expressions are a critical and important part of being a software developer. Right? 

LUCAS DA COSTA: Yeah. 100% agree. I couldn't agree more. Regular expressions has saved my life so many times. Probably save 

AJ_O’NEAL: that other hosts take that. 

STEVE_EDWARDS: Expressions have cost me so much time in the past for no purpose. 

LUCAS DA COSTA: So regular expressions are just amazing. You know, the XKCD comic that, you know, has the characters just saying, you know, I love thinking about the thing, how the things I learned at one day, you know, going to save the world. Oh, that's such an amazing comic. Let me send you the link. Cause I definitely think you should include that in the show notes for this. So I'm just getting the link here, but yeah, regular expressions are absolutely fantastic. I just, you know, I love them. When I was writing my book, I was using regular expressions all the time to, you know, like just pause my snippets, you know, like get the things I wanted out of the, out of the manuscript. And well, yeah, regular expressions are just awesome. I can't, you know, I can't talk enough. I can't emphasize how much I love it. Yeah. Can't emphasize enough. 

AJ_O’NEAL: Good. That's, that's what I like to hear. Somebody who can speak truth and reason instead of cowering in their own ignorance, Steve. 

STEVE_EDWARDS: Or I haven't heard that yet. I'm kidding, I'm kidding. 

LUCAS DA COSTA: No, yeah, regular expressions. 

AIMEE_KNGHT: Oh, you're getting cruel. 

STEVE_EDWARDS: It's personal, sounds like. 

AJ_O’NEAL: Yeah, it's personal. And to all the other thousands of you that are listening that don't know regular expressions, yeah. Regular expressions. It's okay now. But I think they're important. I mean, they're just, I know how you can, I know you can get them wrong. I'm just saying they're a tool in the toolbox that makes something so easy. Because sometimes you don't need a full-blown parser. Sometimes a regular expression will do the job. And that's a lot of times for me. 

LUCAS DA COSTA: Yeah, I think once you know how to write regular expressions, you will find more use cases for them. I think the real problem with regular expressions is that their syntax is not verbose at all. So there's a lot of meaning in a single symbol. So it's very hard to understand know what a certain regular expression does if you're not initiated. Let's put it like that. 

AJ_O’NEAL: I feel the same way about TypeScript. 

LUCAS DA COSTA: Right, right. I'm not sure I agree. I think TypeScript is... I quite like the syntax. Sometimes it can be a bit cryptic, but I think regular expressions have so much... They have so much more meaning and so fewer characters that I think it's just so much more difficult. 

AJ_O’NEAL: All right. Well, this gives me some fodder for picks. And I think I sorry, my fault. I let us meander a little bit, but I like to meander a little bit and, and go through, you know, these different topics and stuff. So we started with testing and ended up on regular expressions, but I think it's been a good show. Do you have anything else that you feel like you want to make sure people know before we wrap things up? 

LUCAS DA COSTA: Yeah. There's one thing I think people should know. I think it's that VIM is by far the best tech status that exists. So yeah, I think that's, that's something that's important to say.

AJ_O’NEAL: But why, why, okay, but you gotta qualify it. Why use VAM over VS code or the more powerful editor Emacs? 

LUCAS DA COSTA: Oh, oh, so you're into Emacs. 

AJ_O’NEAL: Oh, well, I'm just channeling Chuck. I cannot, sorry. Said I'm just channeling Chuck. He's the one that runs, runs the show. He's an Emacs guy sometimes. 

LUCAS DA COSTA: Right. So I think, you know, I, I don't have anything against Emacs. You know, I haven't used it that much. I have friends who love it. You know for like, I think people should use whatever they feel comfortable, but you know, I just love them so much that I just want to make everyone use them, you know, whenever possible. Because it's just like, it makes things so much easier. Like you're writing the command line, you know, you already have all these tools which are like so easily extensible and everything just flows so easily. Like there's no proprietary interfaces that you need to, you know, to deal with. Everything just works because it's just like, it just relies on plain text and just fundamental concepts. And it's just so easy to extend tools, you know, so easy to extend your workflow. You don't have to leave the terminal for anything. It just makes the whole, like your whole workflow more pleasant. And yeah, I just love Vim. Like I love Vim so much. I've got like colon W tattooed on my ankle. Like I just, I just love it. 

AJ_O’NEAL: Did you say you have a tattoo? What? 

LUCAS DA COSTA: Yeah, I have a, you know, the right command on Vim. So yeah, I have a tattooed on me. That's how much I like them. 

AJ_O’NEAL: That's good. 

LUCAS DA COSTA: Yeah. I just love it. 

AJ_O’NEAL: Maybe taking a little too far, but too much is just enough. That's what I always say. All right. And then how do people, how do people get in touch with you? If they want to learn more about testing or book writing or VEM? 

LUCAS DA COSTA: Yeah. So yeah, people can get in touch with me on Twitter at the wizard Lucas on Twitter. They can also find me on GitHub at Lucas F Costa, and they can also find some other links on my blog at Lucas F Costa.com. If they want, they can send me an email at so javascriptjabber at LucasFCosta.com. So any emails that you send there will be automatically tagged. I promise I'll respond. I might take a while, but I'll try to respond to everyone. And yeah, that's it. 

AJ_O’NEAL: All right, it's 2020. Don't make promises. 

LUCAS DA COSTA: Right. We're almost at the end of it, so should be fine. 

AJ_O’NEAL: Maybe the, that somebody discovered time travel. That was in the news recently. So maybe 2020 is not ending after all. Maybe we're all going to get transported back. With that, though, should we move on to picks? What did you say? Amy? 

AIMEE_KNGHT: I said, what did I say? I said we're in the fourth quarter. Can get interesting. 

AJ_O’NEAL: Oh, yeah. Yeah. We'll see what happens tomorrow when we all wake up. If the world's still here. So for those of you listening to the show, today is the US election day, November 3rd. So the riots start, the toilet paper stops and the boards go up. We stocked up. We've got our six month supply. So if there's no more toilet paper for three months again, we're gonna be all right, at least here. But don't come to my house asking for any, because we're keeping it for us. You gotta protect your own in these trying times. 

 

Hey folks, this is Charles Maxwood, and I just launched my book, The Max Coders Guide to Finding Your Dream Developer Job. It's up on Amazon. We self-published it. I would love your support. If you wanna go check it out, you can find it there. The Max Coders Guide to Finding Your Dream Developer Job. Have a good one, Max out. 

 

AJ_O’NEAL: So anyway, let's get into picks. Who would like to go first? 

AIMEE_KNGHT: I can go. All right, Amy, you go. Okay, I'm gonna be like, I'm gonna say based on what we just said, and I mean this from the bottom of my heart, I think that no matter what happens today, people need to be loving and kind to each other. That's gonna be that. And I'm gonna pick a JavaScript thing here now. I feel like we need a framework like. We need a big framework fan on the show because I feel like we're all turning into like big vanilla JavaScript fans. 

AJ_O’NEAL: So this is because we're, we're more wise with our, our gray hairs of wisdom. 

AIMEE_KNGHT: So this is a GitHub repository and the guy went through and basically, let's see, it looks like he did a lot of different patterns in vanilla JavaScript that are like popular in different frameworks and if I, I star so much stuff on GitHub, sometimes I forget what I've starred. But if I remember correctly, this one also does like, he kind of goes through the performance of it. It's the readme is pretty big. So I might be mistaken on that part, but I'll drop a link either way. Anything that I star, I try not to just like star stuff willy nilly. I actually star stuff that's interesting. So hopefully this is good. This is a case study on viable techniques for vanilla web development. So that is going to be my pick and be kind to each other. Please, please, please, please. 

AJ_O’NEAL: I will not throw a Molokov cocktail at anyone, even people that I disagree with. 

AIMEE_KNGHT: Thank you. 

STEVE_EDWARDS: That's so big of you. 

AJ_O’NEAL: One does, one won't. 

AIMEE_KNGHT: Same thing, on like a super serious note. I mean, maybe I'm wrong. This is my own personal belief is that most people, if they're, you know, acting in a way that you disagree with. Uh, I feel like a lot of times people act in certain ways out of pain. So try to understand the people's pain that they're going through and, you know, do what you can to be a good person to them. So that's it. 

AJ_O’NEAL: Alrighty. I'll go next just cause I normally go last and I'll break it up. So I'm going to pick, I, oh gosh, I need to find the right link for this. There's a tool called RDM and I don't know what that's supposed to stand for, but basically if you're on Mac. And you want to turn any display into a retina display. You can get quartz debug and, and put your quartz in debug mode. Quartz is like the rendering engine for Mac OS for the graphics, you know, like you've got your terminal is your CLI and then quartz is your graphical interface. So I don't think anybody knows that it's called quartz, but anyway, there's, if you, if you Google RDM quartz debug and high DPI or retina. And I'll try to get the links for this so that I can actually put it in there. You can take like an old Thunderbolt display and turn that into a retina display. You can take other high DPI displays that are not Apple branded or Apple certified. And yeah, you just, you open up quartz debug, you go into the properties, you check a box that says enable high DPI, you do a reboot, you open up a RDM, but it's not the main one. It's like a a fork of RDM that's maintained. And then you open that up and it shows a lightning bolt every by every resolution that is a high DPI resolution. And then, uh, you, you can have a retina display out of, out of any screen. So that's pretty cool. I actually, in my list of things that I was going to pick today, I already had iterm two. So the thing about Alacrity that I cannot abide is that it does not have tabs. And the authors are a little bit cryptic about this. Uh, not that they're intended to be cryptic, but what they're saying doesn't come across the way that they intend to their audience, which is that they're not going to add tabs into Alacrity because the window manager of an operating system is what manages tabs. And so there needs to be a pull request to enhance the support of the Mac OS window manager in order for Alacrity to be able to take advantage of the tab system that is already native to Mac OS. But anyway, I don't even know why I wanted to think about Alacrity. Alacrity sounds cool, but iTerm2 has GPU rendering and all the stuff that it seems like Alacrity has, and it's got a nice selection of color themes and stuff. In particular, the two features that I like about it are the color themes, which everything has color themes, but the color themes are easy to download and use. And then also, the automatic profile switching. So I have it so that when my username is root, it switches into a really ugly profile. If no rules are matched, it switches into a different ugly profile. And then for my local username, it has a pretty profile. And then for my development system, it has a pretty profile. And then for my production system, it has another pretty profile. So as I'm SSH-ing into different machines, the color profile is automatically changing and that does require setting a setting, but it's just you pull a thing from the dropdown menu of preferences to install iTerm2 tools on whatever server you're on and it installs them for that user. So I've got a cheat sheet for that, how to do the things that I just talked about at webinstall.dev slash iTerm2, as well as you can install iTerm2 for Mac from webinstall.dev and then also Phish. I wasn't gonna pick Phish, I think I might have picked it in the past already. I mean, I was going to pick it eventually, but fish is a shell that is not like bash. It's not bash compatible, but it's very, very fast. And the problems that I've had with shells, we were talking earlier about things being slow. ZSH is slow. I mean, when you're using, oh, my ZSH and it's loading all those plugins, I don't know why, but it's slow. Maybe it's because I've got a hundred thousand lines of history that it has to parse or something because I've never actually cleared out my ZSH history as I've transferred it from one computer to the next. But fish is really fast. And it's really friendly and it has all this type head completion. And so I don't use it for scripting. I wouldn't recommend anybody use it for scripting because it's not bash compatible. And you should use something like, well, I mean, you should be using bash for writing scripts, cause that's, that's what's bash compatible, but I've learned a little bit of it, the way that it works. The variables almost work exactly the same. Exports work the same. Like many things work the same, but it's not intended to be bash compatible. So that's just important to know, but it's just, oh, I love it so much. I'm also going to pick, let's see, I think I'm going to, I'll save that for next week. I'm going to pick the cloud in cabulator. So the cloud and cabulator is this awesome new technology. It's Kubernetes enabled. It's got basically every buzzword you can think of. And it's just a great way to run your, your, your stuff in the cloud. So if you, you know, if you've got a system, you're going to be running stuff in the cloud and you haven't been looking at the cloud and cabulator for optimizing performance or simplifying your DevOps. Definitely take a look at that. And I gave a link to the explanatory video where it just nails it right on the head as to why cloud and calculator is such a better framework than most of the other stuff that's out there. And with that, that concludes my picks. So we'll move on. 

STEVE_EDWARDS: Oh, okay. Sorry. I was taking a nap doing your picks cause you always take so long, but anyway, I'm away from you. 

AJ_O’NEAL: I'm glad you're getting that in Steve. I know that you need those. 

STEVE_EDWARDS: Yes.

AIMEE_KNGHT: No, I'm not listening to my advice early.

AJ_O’NEAL: We love each other. 

STEVE_EDWARDS: Yeah, yeah, exactly. Yeah, that's it. Just paint on each other like. Yeah. So I just have one small pick today and this is totally floof, nothing technical, pink sugar, whatever. I'm a child of the 80s and so that music is, at least some of it, is near and dear to my heart. And so recently I came across a video for a group called The Midnight and it's sort of a retro synthwave type band. So a lot of the synthesizer music that was real popular in the eighties, and that wasn't necessarily my type of music, but I really, first time I heard this song, I really liked it. And then coupled that with that is somebody put that song to a video showing clips from a bunch of the really popular teen movies from the eighties. So if you're looking stuff like Real Genius and Weird Science and the all time cult ultimate classic, Better Off Dead and all the, you know, 16 candles and, and you name it. So it's just a retro song with a bunch of really fun movie clips. And the name of the song is called sunset by the midnight. So I'll stick a link to that in the show notes. 

AJ_O’NEAL: Alrighty. And Lucas, we saved the best for last. You already picked them. 

LUCAS DA COSTA: Oh, sorry. I was, I was muted. Right. So let me, let me get my, my saved links here. Just one second. I was not sure I was going to be on this. I didn't open my listed links, but I'm going to do that right now. Right. So, I'm going to just quickly pick a few things here. Do you like, would you like me to say like anything related to like my, like the show we've just done? Or can I, can you just be like any, sorry? 

AJ_O’NEAL: Pick anything. Pick anything you want. Pick a favorite TV show, pick something technical. I normally I'm not picking stuff that's directly related to the show. I just happened to, cause there were some things on my mind anyway. But yeah, just it could be a book, an author, an idea, anything. Just something that you think is good for the world. 

LUCAS DA COSTA: Okay. Cool. Right. So since we've talked a lot about writing today, I have two book recommendations that I think helped me a lot in writing my book. First one is, sorry, what's it's a book by Steven Pinker. It's called a sense of style. So that is an amazing book. If you want to understand how people actually you know, pause the things you've written and just if you want to know how to write better based on, you know, linguistics and all the research that Pinker has done and others have done as well. So that's an amazing book. The other book I would recommend is William Zinsser's On Writing Well. It's also an amazing book about technical, like not technical writing, sorry, like about nonfiction writing. Amazing book. I would highly recommend it. So those are the two books I recommend in regards to writing. I am also currently reading an amazing book. So the third book I recommend is Daniel Vacanti's Actionable Agile Metrics. So it's been an eye-opener for me because many times we think there's things that are wrong with our processes, but we don't actually stop to think about why they're happening and to think about what actions we can take. And his book has lots of good advice and good research on what actually makes teams work well. So yeah, that's been really, really good. And in addition to that, I think my only other recommendation is to really use them. Neo Vim actually these days. But yeah. 

AJ_O’NEAL: But why Neo Vim? What feature does Neo Vim have that Vim 8 doesn't have? 

LUCAS DA COSTA: Right. That's a very good question. So one of the things that I like about Neo Vim is I've been trying to write a few plugins recently, and it's just way easier to explore with Neo Vim, like writing some Lua and that kind of stuff. So I've been playing around with that. I haven't done anything significantly significant yet, but you know, I'm just playing around and I'm quite liking it. Yeah. Also, um. I think asynchronous running test asynchronously also saves me quite a lot of time. In Vim I used to have problems with syntastic and those kinds of plugins where it would just do actions synchronously and then my whole edge would freeze. So, 

AJ_O’NEAL: I just want to let you know that's not a thing anymore. We've got Vim 8. Now, nobody was using Vim 8, but Vim 8 has been out for like four years. It's just none of the base systems like Mac was still using Vim 7 or something. So that's why I asked. Vim actually, I think it solved all the problems that people were complaining about a long time ago. It just took forever for the package managers to catch up. 

LUCAS DA COSTA: Right. That makes sense. Well, I might as well just try VimMate then and go with the real thing. 

AJ_O’NEAL: I'll be interested to hear on your experience, because you might come back and say, no, Neo Vim is better, but it's just everything I've heard about Neo Vim. It sounds like it's from like old versions of Vim. Then people just kind of like kept with it because they got it when, you know, Vim didn't have those features and then they just stuck with it. 

LUCAS DA COSTA: Yeah, I've moved to Neo Vim because of the async actions, and then I stayed because I was playing with plugins. I was trying to make my every key I type make a piano sound. But yeah, it didn't go really well. 

AJ_O’NEAL: I can imagine that wouldn't go very well. Yeah. It'd be hard to get the sounds right. 

LUCAS DA COSTA: Yeah, absolutely. That was exactly the problem I found. Yeah, I tried to, you know, find ways around it, but you know, I don't really understand much about music. So... 

AJ_O’NEAL: Well, and then holding down the key at the right time. So you know, like, depending on how long you hold the key, it holds that sort of stuff. Anyway, thanks for coming on the show, Lucas. It's great to have you. I was super excited to learn about this book stuff. I hope that that was useful for other people and we all get a chance to check out ASCII doc. And yeah, I'll be interested to, uh, to hear more about the book. Is it, as you get closer to, well, I guess it's pretty close to being finished publishing, but, uh, you know, be interested to see it come out and, uh, we really, really enjoyed having you on the show. Do we do anything else as we say goodbye guys? I don't remember. 

AIMEE_KNGHT: Nope. Just bye. 

AJ_O’NEAL: Okay. Then bye. 

STEVE_EDWARDS: Bye.

LUCAS DA COSTA: Bye everyone, thanks for the invite, it was great to talk to you. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. To live your content fast with Cashfly, visit c-a-c-h-e-f-l-y dot com to learn more.