When you are teaching someone web development skills, when is the right time to start teaching code quality and testing practices? Karl Stolley believes it’s never too early.
Transcript for episode 187 of the Test & Code Podcast
This transcript starts as an auto generated transcript.
PRs welcome if you want to help fix any errors.
When you’re teaching somebody web development skills, when is the right time to start teaching code quality and testing practices? Karl Stoley believes it’s never too early. Let’s hear how he incorporates code quality into his courses.
Welcome to Test and Code.
Welcome to Test and Code. I am pleased to have Karl Stolley on. Did I get that right?
You absolutely did.
Awesome. Well, welcome, Karl. We are going to talk about testing web stuff like the front end and stuff like that. Right. But before we get into that, who are you, Earl?
Professionally, for my day job. I am an associate professor of information technology and management at Illinois Institute of Technology in Chicago.
I teach primarily intermediate and advanced undergraduate classes and students and then a range of primarily master’s degree students as well. So I’ve been doing web stuff and teaching web development kinds of topics for longer than I’d care to count. But really, it’s been about 1718 years now since I was in graduate school.
So I’ve taught a lot. I’ve seen my own teaching change in regard to the web and sort of it’s been within the last four or five years or so. That our topic for today, talking about testing, where testing has really been something even in the earliest intro classes that I like to introduce students to.
You said like the last few years, was testing just not taught on front end things or was it just not really done on front end?
Well, we’ve certainly had more tools available to us. And of course, one of the things that I think was the primary motivator for me is that for the longest time, if you wanted to do front end testing, you needed to use something like Selenium, which is a great tool, but it’s also a proprietary closed thing.
And really it was when the W Three C released the initial web driver specification, where now there is a standard API that browsers can and to the large part do now implement the Web driver API so that you’re able to programmatically access the browser. I mean, I think that’s the thing that in traditional unit and function testing, all of your code is sitting there is no client, there is no server. You’ve just got your code, you fire up your development environment or your test environment, you run your battery of tests, and that’s it at the end of the day. But of course, when we’re talking about web, you’ve got a test on the actual responses that are coming back from a server, and you need to generally feed those things through a browser so that if you’ve got JavaScript involved or something that you’re actually testing the output of that in the way that a user is going to experience it, rather than just as a blob of code that kind of benignly sits there on your hard drive.
Yeah, you said you’re teaching this to people, to students at a College level, when should they start? When should people start learning about testing? Is it right away?
Yeah. Well, that’s where I’ve moved to me. It used to be something that I would teach in my more advanced courses. So I teach an advanced sort of Capstone class for our students who are specializing in web development.
And that was the class where I had been. And this is going back three or four years. That’s where I’d kind of been doing all the really serious heavy duty testing, both functional and unit testing on server side code and then some basic sort of front end testing.
And the students that were in those early classes that I taught really liked it and they were also completely unprepared for it that I was asking them to make a bunch of different cognitive leaps. And so as I’ve tried to work on more sort of curricular cohesion for the sake of our students, but also for the sake of my own self, so that I can say like, oh yeah, we covered this or professor so and so covered this. And then not to build on that, it became more and more obvious to me that we can actually introduce testing or at least something code quality related that’s automated early on in the learning process. And so one of the places that I begin in my basic web courses is just with Linting and sort of coupling that alongside basic HTML and CSS validators so that you get students even ones that are really they love programming, they do all that testing is one of those things that it just doesn’t get picked up in the sort of natural flow of things. The way that how do I construct a function or how do I build a class definition? Like those things seem to have there’s like an Osmosis to them in ways that I don’t think testing really has because you have to be really intentional to introduce testing. So just even getting over that cognitive part that hey, you can write code or you can at least write a little configuration file that then go in and test your code. It’s sort of a big sort of moment for students to realize that I’m.
Not thinking about it right now. Things like Linters and HTML validators and things they might even be more important than other code. So like, for instance, well, I mean, a Python code, you can write bad code and if it doesn’t get run, it’s okay.
And there can be syntax errors. And as long as that file never gets picked up, it’s not going to hit anything, which is bad. That’s why we use coverage. But like in C and C Plus Plus, the compiler itself is picky enough and you can use warnings to where just getting it to compile is a big job. But in HTML and CSS our browsers are notoriously permissive.
They will let you drop off a closing tag or something and try to interpret what you meant and try to show things as you intended, or at least how they think you intended it, then that’s actually, I think, probably not helpful for people learning code like HTML and CSS, because if you’re just trying things out and showing it in a browser, you’re like, oh, it looks fine. What’s the problem?
No, you’re absolutely right. Browsers are permissive to a fault.
And I say fault very deliberately and making sure that students understand that. Yes. Let’s talk a little bit for just a few minutes about the origins of the Web. Html was written not with the kind of precision of even like a parallel markup language like XML, where XML is very demanding and will not tolerate any errors. And HTML is kind of the complete opposite school. And of course, the idea was to make the Web founded on languages that you didn’t necessarily need a lot of technical skill in order to write. The trade off there is that you don’t need a lot of technical skill to write them. And so if you’re going to talk about this in any kind of professional context or a classroom context, we expect higher than that. You should be doing more and better work than you could just sort of like, stumble upon on your own or file save as HTML from Microsoft Word or something awful like that. So you’re absolutely right. That permissiveness sort of invites testing and invites bringing your own batteries of tools to the problem. Because like you say, if you write something bad in CSS, the line just gets chucked. It’s like it doesn’t even exist. And if you write something you can push, the most butchered looking should be HTML at a browser, and it will do something with it. And of course, part of what made the leap from HTML 4.1 to HTML five, that specification ballooned by eight or nine times. And the whole reason was that the spec suddenly covered error handling to try to make it so that browsers would uniformly handle broken HTML in uniform way.
Interesting. Yeah. And then, of course, that becomes a very tough sell for students like, well, I just wrote this thing. It looks fine to me, works fine for me, which gets into another part where when you write for the Web, you’re giving up having a certain compiler or a certain runtime environment, you’re at the mercy of whatever wackadoo Internet connected toaster or whatever is displaying your Web page. And it’s got to work, because if it doesn’t work, it’s not like a typical user is going to say, oh, well, this is clearly a limitation of my device or it’s operating. No, look at this site is broken. It’s broken for me. And of course, if you’re building a site for somebody else, I think you’re.
Joking, but it’s probably not that far off. I mean, the store I walked by and I saw a refrigerator that has a news panel that you can watch the news on it and stuff. So I’m sure Internet like toasters with disability are not far off, right?
No, it’s kind of a running joke, but it’s not a joke.
There are these compliance, and of course, the mind reels about software updates and things like that. But these devices are in the world. These browsers are out there, older devices and things like that.
I want to text to tell me when my toast is ready. I mean, who doesn’t, right?
Okay, so after Validators and Linters, I assume you step it up and teach more testing tools. So where do you go from there?
From there, we tend to go to visual regression testing. So we used a framework in my class called Backstop, sometimes called backstop. Js, and it’s a very sort of easy to grasp concept. What it does is it makes use of the web driver API and can run I think it runs out of the box on Chrome, and you can even set it up to run Headless Chrome. So it almost mimics, like more of a traditional testing environment where you don’t necessarily have browsers flashing up on the screen.
But what it does is it allows you to set up a bunch of scenarios which are like, hey, here’s a viewport that approximates like a mobile screen. It’s 300 pixels wide by 700 tall, and here’s sort of like a middling tablet. So you come up with different viewpoints and then you give it a list of URLs that you wanted to test, and then all it does is go fire up Headless Chrome and take screenshots of the different pages. And you can do either just the viewport itself or you can actually do the whole giant CVS receipt long page of the entire thing. And then you have to approve the images that come back from that. Of course, your initial test run, there is nothing to run it against. So you just say yes, this is the way that the site is supposed to look like. Then on subsequent runs, as you’re mucking about with your CSS or rewriting things in your HTML, it does a basic image diff from your sort of set of images that you’ve said this is what it’s supposed to look like versus what this latest render looked like. And the interface of it, it actually opens up a little report right in the browser for you. And then you can look just to see here’s image A. And here’s the new one that we’ve got. It gives you a little slider tool, so you can actually slide back and forth and kind of compare it, and it even tries to sort of highlight the visual differences. Again, we’re talking about images here so that there can be limitations to that, but they are faithful screenshots of what you’ve got.
That’s the basic process that it works. It’s really about what is the visual output of this thing going to look like in a browser. And the sort of point that I drive home to students is this is more for your comfort as a developer, rather than to say, oh, yeah, if somebody’s looking at this on Ie Six, on Windows 98 or something like that, then it’s going to look great. It’s like, no, this is about you having your own internal consistency with your design.
So I got a question before we talk about other things.
So if I’m using these screenshots, I’m hoping that it’s not just static stuff that I can have. Like, let’s say I’ve got a shopping system, put a few things in the cart, and then go look at my cart summary and then take a screenshot there. I can do snapshots at various times in the workflow.
There’s a sort of little DSL that’s built into its configuration files that allow you to either wait for a certain amount of time or you can wait until a particular element is visible on the page if you’ve got some JavaScript that just runs automatically and makes, let’s say, an Ajax call or something like that. And I hope that it gets to be more robust over time. But you can do some basic sort of interaction with elements where you can say, all right, let’s trigger this warning message on a file input or something so you can make it go into an error state so that you can grab a screenshot that’s going to show, oh, this is what the form looks like when we’ve got an error message or something like that. And then again, sort of compare those things back and forth.
Okay.
All right. And then how about Indian stuff with utilizing a back end as well?
Sure.
Even when we’re talking about doing backstop, one of the other sort of things that I insist upon with students is that they’re not just using file open in the browser and have some ugly file URL. Like we run some kind of small, little development grade web server locally so that students are actually interacting over Http with that. So even when we’re talking about just like static HTML, CSS, and JS files, we’re still serving them over Http, which is itself sort of an interesting testing problem because browsers have locked down more and more what browser APIs are made available to you if you’re not in at least an Http context?
And it’s getting to the point now when we talk about like, the file system APIs or the traditional ones like audio and video APIs for accessing your camera and things like that, even if you’re running on localhost, you cannot reliably hit those things unless you’re serving on Https over local hosts. So we have to do the secure context as well.
That’s what I was curious about. If that’s a thing that we have to do local Https, is that something you can do?
It is something you can do. It adds, of course, layers of complexity, including the testing. So when we’re talking about doing more front end testing, we’re more interactively looking at not in the visual regression testing case of how the site looks, but how it behaves and how the content is presented there. So I’ve been teaching a framework called Nightwatch. Js for that, which actually within the last couple of months I think was acquired by Browser Stack, which I think Browser Stack had run Night Watch. And if you don’t know or your listeners don’t know Browser Stack, it’s one of the more long lived multi browser, multi device testing services. So what they can do is actually emulate. Okay, here’s what your site looks like on Internet Explorer Eight, or here’s what your site looks like on Firefox 32 or something like that, or on different mobile devices and things like that. But they just acquired Night Watch, which had historically been sort of like an independent open source project. And it now looks like this is actually going to be a good thing because the company actually uses the product and now the core development team works for Browser Stacks. So that gives so they get paid.
Now that’s a good thing.
They actually get paid from work and writing software. It’s this novel thing.
But even in that case, it’s a matter of we’re going to run all these tests, and usually when our students get more advanced, they’ll have a suite of tests that are meant to run over their local host or something like that, and then another suite of tests for when things get deployed to production, which is usually duplicated, but they’re just hitting the actual live URL instead of the one that’s happening over the local network. But you’re doing legitimate requests.
Thanks to the web driver API, you’re able to sort of programmatically interact with the Browser Nightwatch is a little bit different because it actually will open up a browser window where you can actually sit and see it for a few seconds while it runs your tests.
And then it basically does the old school like it releases an exit code, right? All your test pass exit code zero. And if it’s failed, then it’s exit one or bigger. So we still need those things for.
CI systems they depend on.
Well, yeah, that’s actually what I’m getting ready to talk about and teach this week is integrating these kinds of tests using GitHub so that you are protecting at least your mainline development branch against bad commits by running these batteries of tests as part of that commit lifecycle.
So I know that as a professional development, I know all this stuff is important, but how are the students reacting to learning these testing tools?
Are they grateful for them, or do they feel like they’re getting in the way of learning what they want to learn or.
Yeah, that’s a good question. I think I’ve got a reputation for being like the kind of teacher who puts way too much stuff in any given class.
I’m okay with that. And I learned to treat students in ways that they’re okay with it.
It’s possible to say we can take just a slice of maybe a third or something and really go deep. But I think students and teachers alike tend to overestimate what can really get done in the span of 16 weeks or however long a semester is that you’re not going to become. It doesn’t matter what level you’re at, if you’re a PhD student or a brand new undergrad, you’re not going to become an expert on the topic in 16 weeks, no matter how good the teacher is, no matter how skilled you are. And so as my career has advanced, I’ve been more interested in breadth than in depth because you’re going to have especially these are students who are going to be and do go on to be developers and cybersecurity experts and things like that. You get your whole career to sort of like go deep on the topics that are going to be most relevant to you. But if somebody doesn’t introduce you to the concept of testing until way late, or if they don’t talk about how to write really good documentation or how to use get hooked, then you can really go for a long time without even realizing those things exist unless you’re in a shop that deliberately uses those technologies. So to me, I’m always thinking about how do we use a class to expose students to a bunch of things to help them sort of work at a level of abstraction to say, okay, maybe I’m never going to write another Night Watch test beyond this class. Fine. But now I cannot pretend that I don’t know that automated testing exists. I cannot pretend that it won’t make my project better. And for some students, that means won’t earn me a better grade because, hey, I’ve got passing tests. So my professors are going to load this thing up and see a bunch of errors in the JavaScript console or whatever. And so they begin to see that. And then the other part that I love about testing and the thing that becomes the real selling point for it with students.
And this is the case where maybe I need to introduce this earlier.
So I teach like this two course sequence of web classes, and the fall is sort of like a class that’s really just about the fundamentals of language. We’re not making websites to please anybody or that look visually beautiful. It’s more like, can you write HTML and have it validate it, lint it out? Can you write JavaScript and have it not throw any uncaught errors like that’s the level we’re working at, but we do do CSS in there as well. And I teach responsive design and inclusive accessible design. And one of the things that we do in that class is students begin their early basic designs, and they’re all in absolute units, like Pixel units. So you’re saying, oh, this is an 18 Pixel paragraph, or this is a 37 Pixel heading? And then we make the conversion of that into relative units. And it’s simple algebra to go from a Pixel divided by another Pixel, and you get a mute on that. But students go to pieces in there. And of course, when you’re talking about a style sheet that for the more ambitious students, goes to several hundred lines and making all these calculations, and they’re sitting there and they’re constantly refreshing their browser window and watching to see that I do the conversion right. Because if I did it right, then nothing should shift around.
Flash forward to the spring, they come in and I’m like, hey, this is Backstop Jazz. It’ll take little photographs of your website, and then I’ll show them. I’m like, Here, this is all in pixels. Now let’s do the unit conversion into REMS. And then the tests pass, and they’re like, Why didn’t you show us this last semester?
You had us all sitting there, like, clicking the refresh button to make sure that everything was okay. And I’m like, I know, sorry. There’s only so much that you can teach in a single semester.
That’s the interesting part for me about the visual regression testing is that a lot of times the work of Refactoring CSS is usually not a whole lot of like, what we would see as refactoring and other kinds of code were like, oh, we’re simplifying this method or we’re turning this into a helper and we got to test it. And CSS, it’s usually like, where did I kind of go nuts when I was designing something? Where did I start writing what I usually call with students like Magic CSS or Desperation CSS, where you’re trying to get something to work? And so you throw everything at almost all you say display block here, we’ll throw in a whole bunch of stuff. Well, you want to go back and eventually clean that up.
And so what I love about even just in my professional work about Backstop is that I could go through and be like, I don’t think I need to put in this default property on Flexbox or whatever it is. And so I’ll delete it and then rerun my test. Like, sure enough, that had no effect on anything that I was doing. And so that’s been a useful tool this semester with my students to say, like, hey, let’s go back and actually try to lighten this style sheet up. Because I do have students who are like, they’re big on performance or whatever. It’s like, okay, we can do this JavaScript stuff, but maybe if you just lighten your CSS file a little bit, we don’t have to worry about.
Yeah, we’ve all been there in the refreshing the browser to see if what you’re trying to do is working.
I wonder if that’s important, you have to go through that.
Yeah, I think it’s helpful. And I think the other thing and this is why I kind of agree with you. Maybe that is the kind of like a rite of passage, cruel thing that we do to beginners.
But web browsers. And this is going to sound crazy, but web browsers are incredibly hostile web development environments because they all cache everything within an instrument’s life. So if you don’t know to open up your developer tools and to disable the Caching, you’re going to go. And I do have students that just get on our electronic discussion board and we’ll just vent. They’ll be like, I wrote this CSS style, like eight different ways, ten different times. And it turns out the browser was showing me the CSS file that I wrote yesterday. Like it wasn’t even Loading up the latest thing, even on local host, even on a local loop back, all of that. So being able to know those things and to understand how they impact you are important. But I don’t know. We’ll see. Maybe next fall. I’ll try to introduce some visual regression.
Testing earlier, like you said, maybe not going so deep, but more broad. I think it’s going to help them if they get into it.
None of this stuff is going to be surprising. When they get into a job interview, then if somebody asks about them, they can go, oh, yeah, I’ve used night watch and backstop.
That’s always the hard thing with any beginner, I think, is that they assume that, oh, if I’m really good at this, I’ll know this language backwards and forwards, or if I’m really good at this, I’ll know this tool backwards and forwards. It’s like the tools it’s here right now, but give it six months, it might not be. And so then the question becomes, how are you able to sort of abstract what you’re learning about this so that you can apply it elsewhere? And I would say before I get like, if any of my colleagues happen to listen to this and be like you’re going for breadth rather than depth, I think the other side of that is that I go for breadth, but I’m always talking about learning, not just like you should learn this thing because I’m teaching it to you, but paying attention to how you learn things and what is going to be really useful. So, yeah, the version control thing, one of the ways that I mean, that’s the sort of three legged stool that I like to teach on is testing version control and documentation. You need all of those things sort of working in concert if you’re going to develop a product, but also if you’re going to develop as a developer so that you can say, all right, I’m going to learn this language, I’m going to learn this framework or whatever it is, and be able to have sort of the confidence that like, yeah, I don’t know this right now, and there’s a whole bunch of stuff I don’t know. But here’s the repository that I built while I was working through this book or this tutorial or whatever, and be able to then use the things you know about creating a branch and get like, okay, I’m following along with Brian’s book, and I’m going to just make a branch here to try out some things myself and see if I’m learning. And so I’m always preaching version controls a lot of things. But as a learning tool, it’s just incomparable to be able to study what you’ve done and figure out what it is that you’re learning and how it is that you learn. So that when you don’t have a professor or a senior developer or a manager or somebody standing over you saying, hey, we’re going to do this, that you actually know how to pick up and learn those things on your own.
Yeah, man, I wish I was learning web stuff from you. That sounds like pretty good classes.
Yeah, it’s fun.
There’s only a small portion, especially in those earlier web classes. Only a small portion of those students are actually specializing in web. We have an interesting curriculum that requires all students to take classes in web, partially because the second class is the one I’m teaching now, which is also about sort of HCI and user interfaces and things like that, which I think is the other reason that I’ve really pushed more testing in there is that these are students that are not going to do web stuff, but they are going to do other kinds of development. And so I want to make sure that when they go into those next level software development classes, if they’re learning Java or they’re learning Python or whatever, they’re doing data science and they’re doing Python, that they know that these kinds of tools exist and that hopefully they at least feel guilty about not drawing upon them if they don’t actually draw upon them.
Yeah, sometimes I think about that because I just write a book just to appease people’s guilt over not testing their code.
But anyway.
Right. Well, the thing that I love about your book is that you do talk about testing in a way that I don’t know how to phrase it without accidentally insulting you, but I think there’s, like a value apparentness in the way that you write and talk about testing.
But sometimes it is useful to explicitly say this is why this is a good thing to do. And I think guilt is a powerful motivating force, especially professionally. It’s like, oh, I really ought to do that, but it takes too much time and so, okay, well, maybe I’m a lost cause at my age and my stage in my career, but this 19 or 20 year old that’s in my class, I will preach the gospel of testing or whatever to them and make it a more natural part of development instead of an optional thing that this little group of hardcore testing nerds likes to do or something. I don’t know.
Well, I mean, the industry is changing, so I think we’re going to see one of the things I’m pushing off often is developers need to test and even front end people need to test. That wasn’t always the case.
Some big companies do have QA teams.
I think a majority of the companies and majority of developers out there are not going to have a QA team looking over their shoulders. They have to test their own stuff.
Well, that’s an interesting question, too.
I think even in most shops, the border between QA team and automated testing can be a little fluctuated and fluid.
I had a student probably ten years ago who went on to work as a QA person, and she was very much kind of like every time there was a deploy sort of manually going and pushing all the buttons and make sure everything she was almost like a backstop for their automated testing. Like, I guess they tested everything before they deployed. But then you still like, what did we catch? What did we miss that came out on the other end? But I think is you’re able to do more things, like with front end testing. It’s not that like, oh, good, we can fire the Q and A. I don’t know why I keep saying Q and a QA team, we can fire them. It’s more like what testing does for even beginning developers. It’s like this relieves you of so much cognitive load. Like if you’ve got a Linter that’s enforcing a particular quotation Mark style and particular indentation or making sure you’re tagging or whatever, then you don’t have to worry about that anymore. You’ve got a tool that’s going to catch that. I think the same thing is true for QA is that we’ve already run this battery of tests that ensures these sort of low level knuckle draggy kinds of things have been addressed. Now you, as a QA person can go out and search of those edge cases or those weird combinations of browsers and time of day and phase of the moon or whatever it is that causes the site to break, that it ends up being a good value add across the entire organization.
And also just there’s a lot of teams without QA.
Right.
But one of the things that drives me nuts is a lot of the I think this is some old tutorials, but there’s still a lot of people that will say you need to learn testing practices. And at first it’s going to slow you down. And I wish I could just slap them because it’s a new thing. Anytime you learn anything new, it’s going to take a while to swap out for a different keyboard. It’s going to slow you down a little bit. Of course it will, but if you embrace having testing as part of your development process, you’re not doing it slower, you’re doing it faster because you can and with less stress, I think. But anyway, yeah, no, I agree with you.
It’s a lot like saying, well, stretching before you go for a run will slow you down. So what, you’re going to skip that? Like, to me, it’s much more in that category of things like, are you taking care of your body before you actually push it to some kind of limit?
I want to change gears a little bit. You mentioned that one of the things you like to teach people is just to get students to learn is that learning is an ongoing thing. They need to enjoy learning and things. And you, speaking of learning, are writing a book on WebRTC, which is very new. I didn’t even hear about it until I heard you were writing a book about it.
Are you okay with changing gears right now?
Yeah, sure. I love changing the subject and making wild shifts.
So this is through Pragmatic, also the same publisher that did the Python’s book.
Let’s just do a brief like, what is it? What is WebRTC and why are you writing a book on it? Sure.
Well, so WebRTC is if you expand the initialism it’s web Real time communication. This was a specification that had been in development at the W Three C for a little over a decade, depending on how you talk about it. It’s closely related. In fact, it’s built upon the real time communication specification, which is housed in bits and pieces with the IETF. So basically, it’s a web browser API, wrapper around RTC protocols, which lets you do things traditionally like VoIP calls, and now we can do video streaming and things like that. So it’s meant to be a peer to peer communication protocol. So if I Wire up and write a webrtcap, in the classical case, I can do basically something like a Zoom call where if we’re connected over WebRTC, I can see you, I can hear you, we can send data arbitrarily back and forth, and you’re doing it entirely with native browser APIs. So there’s no plugins, there’s no libraries, there’s no anything. It’s baked right into the browser. And of course, the way that I came to this thing was not that I was necessarily like a huge WebRTC enthusiast. I’m a web developer by trade, but I had an opportunity. This was right in the heart of the pandemic, and it was fall of 2020.
There was this WebRTC class on the books at my institution, and I asked somebody about it, do we teach this thing? And like, oh, yeah. So and so back when the Earth was still cooling, like, taught that class, and then he left, and so nobody’s touched it. I was like, well, I’m going to be teaching online.
Students are going to be attending classroom home. What better topic than to do this Web RTC thing. And I’m like, I don’t really know that much about it. I can pick this up. And so that was like, in spring of 2020, I was going to be teaching it that fall. I’m like, well, there has to be tons of book. Yeah, the spec isn’t finished yet. And so I started going to look for a book, and I was like, there’s nothing here that is any newer than 20 13, 20 14. Okay. Which, of course, is at least you’re talking five generations of browsers since then. Yeah. So I cobbled together what I could to teach that there was no book. It was clear that, yes, I could buy a book so students feel good about spending money, but nothing that I read was all that helpful. And the spec had changed so much at that point, and browsers implementations of it changed that it wasn’t going to be useful for students to know anyway. So I taught the class, wrote a ton of code, gave myself a sort of shotgun kind of education and WebRTC over that summer so that I can come in and not be an incompetent in front of my class and taught the class. It was great. It was super fun to actually teach that in a distance kind of model, because when we get to deploying WebRTC apps, I’m like, hey, who wants to come and join? And so students gave them the URL, and then suddenly, boom, here we all are in this application I’ve been writing as a demo in class and experiencing, like, when you’re talking about direct peer to peer, you have a lot of bandwidth you can work with, and you don’t have to compress the heck out of a video signal the way that you would if you’re using Google Meet or Zoom or whatever. So you don’t just run up a huge bandwidth. Bill said you burn through your own personal bandwidth instead.
Okay, I know we’re not, like, jumping deep into our Web RTC, but just my own concept. So if I’m using normal, like, a normal chat system or something like that, I’m going through the server and the servers are relaying it to the other person.
But with WebRTC, my message would just go directly from me to them. Or is it bypassing the server?
Yeah. No. Depending on how the network is set up, there are edge cases. So to set up a WebRTC call over the open Internet requires a few additional pieces of technology, one of which is called a Stun server. And what Stun does is basically allow your browser to basically dial out and say, hey, can you tell me where I am on the Internet and what the Port is? I can be reached on this particular network connection. Assuming you don’t have an overly restrictive corporate or military firewall, most of the time you’re able to establish that connection back and forth. But yeah, you’re absolutely right. When that is the case, which it is for most home and office networks, then you’re able to establish a connection directly between one browser another without passing anything through a third party server. And because of the way that the protocol was put together, it’s all encrypted out of the box. You don’t have to do anything special to make sure your audio signal, your video signal is encrypted at either end of that. So you’ve got full encryption, like all the modern stuff that you would expect.
And again, sometimes we have to make a fall back thing called the turn server, where you’re basically then going back to the relaying traffic. But most of the time you don’t have to do that. You can make it a direct peer to peer connection.
Okay, now this is in beta right now, right?
No, it’s done. Oh, the book is in beta.
I think I’m in the third beta right now. So I’ve got six of the nine chapters out, which are like the six bulk. Like, you can learn pretty much the core of WebRTC from that.
Your book is not done, but people can start learning it right away if they’re curious about it.
Yeah, that’s right. And there’s been a tremendous number of people who have bought because there is no other book. I mean, that’s the tail end of the story is that I finished teaching that class. It was great. And then I’m kind of like doing my end of the semester filing stuff away, and I’m looking at all this code and all this stuff that I wrote on WebRTC. I’m like, why am I putting this away? Like, there’s no other resource that kind of covers all this stuff on the market, and especially the one that does it from a web development perspective. Like to say, like, hey, web developers, this is another API that you can put into your Arsenal. So it’s exciting because this is the only book that’s on the market that I’m aware of right now that covers the completed Web RTC specification. It was a long time coming, and I’d actually started writing the book proposal for Prague and then as like an early Christmas present. I think it was in January of 2021 that they finalized and approved the W Three C spec. So it was done, which to me was like, okay, this is green light, because now we don’t have to write a book. And I’m not using the Royal Weebly, but without ever press I partnered with we’re not publishing a book that needs to be changed. We have a whole bunch of like, hey, well, this might change or, oh, this is what it looks like now. It’s like specs done. And of course, there’s going to be a new version and probably a second edition at some point down the road. But it is nice to have that nice confidence of a completed spec.
Well, good luck with the book. And good luck with teaching and I guess we’ll keep in touch.
Yeah, that sounds great Brian. Thank you so much for having me and great to talk to you.
Thank you Karl not only for this episode but also for teaching the next generation. Thank you Patreon supporters become a supporter by visiting Tesscode.com support every dollar helps if you found this episode interesting or useful please share it tweet about it end or share with a coworker help the show grow by one. Thank you for listening. Now go out and try to have some fun. Coding.