 OK. So we're going to crack on with our next talk. We've got Katie Fenn, who's going to be going through debugging in Chrome. Thank you Katie. Good afternoon everyone. My name's Katie Fenn. I'm going to be talking to you today about debugging your code with Chrome DevTools. A quick content warning to everyone in the room before I start. Heavy animation is used frequently in my slides. So if this might make you uncomfortable, dyna i chi'n gweithio i'w gweithio'r gweithio'r gweithio. O'r ddangos, efallai y ddweud yma o'n nodi'r gweithio'n mynd i gael y link ac yr ysgrifennu sy'n mynd i ddweud o'r ddweud gweithio'n ddweud a oeddwn ni wedi'u gweithio'n ddweud mae'r gweithio sy'n gweithio'n gweithio'n ddweud i weithio i'r ddweud. So, this is as a talk about debugging. Let's remind ourselves what debugging means. It means to remove bugs or mistakes from a computer program, and we do that by monitoring application flow and state. We have to understand what our sites are doing before we can understand what they're doing wrong. wrth gwrs, mae'r ffordd yma yw'r tyfnwys yma, yn ymgyrch gael html a css. Mae'n rhaid i'r pwg ffwrdd Cromedewtileid, rhaid i'r pwg ffwrdd cyflwyddiol, ac yn ddiddordeb yn ddiddordeb yn ymgyrch, ac mae'n ddiddordeb yn cymdeithasol, ac mae'n ddiddordeb yn cyflwyddiol. Mae'n ddiddordeb yn ddiddordeb, mae'n ddiddordeb yn cyflwyddiol, ac mae'n ddiddordeb yn y pwg ffwrdd Cromedewtileid. Mae ydych chi'n gwybod i ddos o dddiddordeb yn yr ysgrifio cyflwyddiol, ac mae'n ddiddordeb yn yr ysgrifio cyflwyddiol. Mae'n ddiddordeb yn llawd y pwg ffwrdd i'r pwg ffwrdd cyflwyddiol, ac mae'n ddiddordeb yn ddiddordeb yn y pwg ffwrdd cwynhau i grifio cyflwyddiol, e. a oedd, mae Html ydych yn felly ffordd arall ddysgu ddysgu a pam wrth yng nghymru'r cymdeithasol ar y llwystiad. Dydian o'r ffordd ar y mein ydych i'r cyflwynt, company yw ddynnu'r cymdeithasol a gweld yr adrod yw'r hynny. Ac wrth gwrs, yw'r cyflwynt ddysgu fod y cyflwynt ddysgu. Fyddech chi'n wneud y bwrdd ar gyfer o'r cyflwynt froedd, pan yn ei ddysgu sydd fydd gradd ac yn chweithio'u pan fydd gennym. Ond yma'n cymdeilydd gyda'r gweithio yw'r websaith yn gwneud y system passengers a'r wneud yn ddwyio ddref ar unrhy warning. Un o'r tyn nhw y gallwch chi'n gwybod wedi ychydig ar gyfer mewn crème deff diwrnodd y pwysig yn cysigadraeth droi o bobl uchwnd o barandal ac mae stor i fynd o bwysig sedwn ar gyfer cyfweld. A dyna wnaethe'n gweithio, ychydig yw ychydig ein fhau by clicking on the false element state button. If you do a lot of work with CSS animations, you can click on the CSS animation button and you can slow them down to a fraction of the speed so you can see what's going on. So we can see the effects are reflected here and all the CSS animations have slowed right down, making it easier to see. A really fundamental part of building websites in the modern era is building websites for different devices such as tablets and phones. And a useful feature that Chrome DevTools gives you for that is the device mode. And you can launch it by clicking on the device mode button. And when you do that, you can see that your page is being resized to the kind of size and aspect ratio that you see on some devices. And you can change those settings so we can emulate an iPhone 5 or an iPhone 6 or even an iPad. And as well as emulating those sizes of the screen it also emulates things like user agents, the kind of DPI that you'd expect on high resolution screens and much, much more. Also when you interact with your site using a mouse you also see touch events being emulated to. So the next feature I'm going to talk about is the network tab and we use this for debugging HTTP requests that your site makes across the network. So this is what it looks like. You can see that a list of all the requests to resources that our site is making listed in a list as well as useful information such as the HTTP method to request them, the status code that your response has returned, the type of request so whether it's to a document or to a script or to a star sheet, the total size of the response returned and the time spent downloading it. There's also a visualization of all these requests and the visualization shows when the request starts, when it ends and how long it takes. Developers affectionately refer to this as the waterfall because the cascading nature that requests come in as your site loads. You might be able to see that requests, the quest bars are split up into two different bits. The lighter bit on the left is the time spent setting up network connections, everything to get requests ready before you actually download data. The darker bit on the right is time spent sending and receiving data across the network so you can see that quite a lot of time is sent not actually sending data across the network. The red line is the point that the DOM load event is fired in your scripts so you can see that's when content is actually finished downloading. There are lots of filters available if you just want to have a look at specific requests in particular so you can filter by the resource type that you're requesting whether it's a script, a star sheet, an image, a font. If you want to know where to filter AJAX requests you can find that in the XHR filter. There's also a filter field there as well and if you start typing into this it has an autocomplete function so if you start toying around and really playing around with different things that you put in there or suggest things that you can filter by and you can filter by all sorts of things like a file name as well as HTTP headers that you don't normally get to see. At the bottom there are some really broad metrics for your site such as the total size of requests downloaded the time it took for all your content to load down as well as the point at which the DOM content loaded and load events were actually fired. These can be used for really basic performance benchmarking if you want to start optimising performance of your site. Another fundamental part of modern web development is developing on devices that have really slow or very bad connectivity to the network so you can use the throttling feature to throttle down to 3G I'll just run that again so you can see. Here I'm clicking on the throttling feature it has a drop-down of lots of different networks and speeds so I'm going to select 3G. I'll reload my website and see how much longer it takes content to come down. As it's loading you can see it's taking many many seconds to come down and this is a really good way of just doing some really basic testing of your website under non-optimum circumstances. One of my favourite features of the network tab is the screenshot capture tool and you can enable that by clicking on the camera button at the top. What happens then is that when you reload your page DevTools will take a screenshot of your site at specific intervals as your page is loading. If you mouse over them you can see on the timeline the point that they were taken is highlighted and if you double click on them you can inspect them in detail. You can use this feature to really optimise the size of the request that you're making and their timing so you can deliver more meaningful content to your users sooner. The next feature I'm going to talk about is the sources tab and we use this for debugging scripts. If you've debug scripts before you might have come into contact with the console.log function and that's really was where I started doing it. In fact if you've been developing as long as I have you might remember debugging with the alert keyword which isn't really very that useful at all. But that's kind of a pain because every time that you want to change what you're debugging you have to go back into your file and reload your site. So next time you do this try instead using the debug keyword and what this will do is it will pause your script so you can interact with it in the middle of what it's doing. So some of the things that you can do with this that you can't do with console.log is that you can see all of the variables in your script. So you can see what this is. You can see global variables. You can actually change their values by double clicking on the values and changing them, allowing you to experiment with your scripts while they're running. You can also expand them so you can look into specific properties. There's also the call stack which is a list of functions that are currently being called. So a script here is paused in a function called update frame which was in turn called by a function called onScroll. And you can click on these functions and inspect the variables when they were called as well. There's also a watch expression, the watch expressions pane which allows you to put in arbitrary lines of JavaScript so you can keep an eye on really important variables that you're really interested in that you think are creating bugs. You can also call functions in that such as jQuery so you can keep an eye on what your DOM is doing if you want to. It's there for anything that you want. And these will be reevaluated every time your script is paused allowing you to see how those values change. Finally, there's execution controls at the top. These allow you to step through your script line by line so you can see how it's doing stuff. So let's take a look at how they work. The first one is the resume script execution button and I've told you how to pause your script but haven't told you how to restart it so you use this one to restart it. And what that would do is it will restart your script until it gets to the next debugger keyword or the next breakpoint where your script will pause again. These breakpoints on the left you can create them by right-clicking the line gutter. They work just the same as the debugger keyword. When your script gets to one of these lines DevTools will pause your script so you can look at what it's doing. So when your script is paused and you use the reason script execution button your script will resume until it gets to the next breakpoint. You can right-click breakpoints and you can set conditions for them to pause. So if you're debugging a part of your script that is executed very quickly or very often then you can set a condition and they'll only pause when that is true. So in this case this breakpoint will only pause when status is published. Next these controls is a step over next function control. And what that will do is it will tell DevTools to skim over any function calls that you're making and go to the immediate next line. It's important to understand that the functions are still evaluated. They're still running the code inside there but you're telling DevTools that you want to skim over that. You're not interested in seeing it and you want to pause on the next line. The step into next function control does exactly the opposite. It allows you to tell DevTools that you want to go, you want to step into that function. You want to follow your script into that function. So here I'm calling the get function and if I use the step into next function it will pause on the very first line of that function. If we were to pause back on the line later on after we've been through that function if we use the control again it would next step into the save function and it will do that for each function called. The step out of current function control will pause your script at the line that it was called after that function has been run. So if we use it here in the save function it will pause back at the point that it was called. Some people when they're developing or when they're testing their scripts or their sites in general like to write JavaScripts that help them do things such as fill out a registration form. We have a really long registration form on our website. So I've written a script that will fill out these forms for me and you can put it in the snippets tab which is in the sources panel. You can save these so that when you come back to DevTools later on even after closing Chrome they'll still be there waiting for you. You can quick open files as well by hitting command and P. You start typing in a file name and Chrome will do its best to find the file that it thinks matches your request. So this is a script that is on the production website. It's been minified and it's really difficult to read. So I'm going to click on the format button at the curly brackets at the bottom and Chrome will do its best to insert some breakpoint some line breaks to make it easier to read. So if you want to find out more about a couple more features there's black boxing. So quite often we're only interested in stepping through our own code. We're not really interested in stepping through jQuery or Angular for instance. So black boxing allows you to ignore some files in your site. Workspaces is a really neat feature that allows you to save changes that you make to files in DevTools to your local file system on your computer which will allow you to use DevTools as a text editor. The final feature that I'm going to talk about is the timeline and we use this for profiling the performance of our websites really broadly. So one of the things that it's really good for is debugging problems with frame rate when there's lots of animation going on in your site. So this is my old website. There's quite a lot of animation going on when I'm scrolling and I've noticed that the frame rate has really suffered. So I'm going to go into the timeline I'm going to hit record interact with my website and we can see that DevTools has gathered quite a lot of data and given us some results. So let's look at what they mean. The frames view at the top is a bar chart every frame of animation while the profiler is running and each bar corresponds to a single frame of animation and the taller it is the longer it is taken to render. There's two lines as well running horizontally through all of these. I'll highlight them so that you can see them. These are your budgets for rendering at 30 frames per second and 60 frames per second. If your bars are exceeding this you know that you're breaking these budgets and your site is rendering slowly and you've got a bad frame rate. There's also a list of all the events that's going on while our page is animating as well. In particular you can see that I've expanded some scripting events that's going on. You can see that lines of my script that are being executed. In particular there's a lot going on inside my on-scroll event which I expected. So if I want to try and debug this I might try and remove these lines of script to see if it makes a difference to the frame rate. So I've gone away and I've done that. I'm going to run the profile again. I'm going to hit record. Interact with my website and we can see that the frame rate has vastly improved and all those bars are safely underneath my budget for rendering at 60 frames per second. You can also see that all of those scripting events have gone as well. So a couple of other features that you might want to look into if you do a lot of... if you want to look in greater detail the animation and the rendering on your page the paint profile that allows you to look at that in detail and the frame viewer will allow you to see each individual line of CSS animations if you use those. It will allow you to see outlines of your content even stuff that's hidden which can be really useful for debugging stuff that you can't often see. Other dev tools are available as... Oh no, that's the next slide. If you do a lot of development with Angular, Ember or React then you can get plugins to help you debug applications that are written with those to allow you to look inside their state. And the breakpoint is a great podcast that was created by Adios Manny and Paul Irish at Google. It's a bit old now. It's sort of like two or three years old but it covers a lot of the fundamentals that I've mentioned in my talk in much greater detail. And there's hours of content there for you to look at. Also other dev tools are available. Firefox in particular has very matured dev tools of its own as well as Firebug which has been around forever now I think. Internet Explorer particularly since versions 9, 10, 11 and Edge also has been vastly improving their developer tools so definitely check those out. You might also not know that you can use Chrome to debug websites that are running on actual Android devices just as well as you can with the desktop browser. And you can use Safari to do the same with the iPhone. So if you do a lot of mobile development definitely debug your sites running on actual devices. So in summary we use the Elements tab for debugging HTML and CSS. We use the Network tab for debugging HTTP requests across the network. We use the Sources tab for debugging application flow and state in your scripts. And we use the Timeline for debugging performance broadly across your site. And I'm going to leave you with a quote from one of my heroes. This is Gene Kranz. He was the Apollo Flight Director for Apollo 11 and Apollo 13. And this quote was taken from the Apollo 13 logs about 20 minutes after the accident. Everyone keep cool. Let's solve the problem and not make it any worse by guessing. This is how I feel about learning how to use developer tools of all types as much as I can. And I feel that looking inside your sites, looking inside your applications to figure out what they're actually doing can make a real difference to how you feel and your competency as a developer. So thank you very much. My slides are available online at that address. All the videos, because there's lots of videos also available at the address below. And you can find me on katie underscore fen on Twitter. Thank you. Fantastic. Thank you very much, Katie. We've got 10 minutes now for some questions. So can you have some hands up if you'd like to ask a question? OK, we've got a hand up over here on the left. Hi there. Could you tell us a little bit more about those watch expressions, the arbitrary code that you can inject? Did you say that they could, they would be executed every time the script was paused? Yeah, so every time every time you resume your script and it's paused, the JavaScript code within each watch expression, in fact, I'll find the slide so you can see. Will be rerun. So if you've got, let's see, script, script, script. That's networks. I think it's this one. Yeah, so you can see that I've got some arbitrary lines of JavaScript in there. We've got a call to one of the global window properties. And also I've got a line of jQuery in there to keep an eye on the value inside one way HTML elements. And you can see that it's actually my name in there at the moment. But if my script has changed that, if it's changed after I impose it, those lines of JavaScript will be rerun and you can see the values change. So the most important things that you find as you're being a super sleuth going through your code. If you've identified things that are really important that you think might be causing a bug, you put them in there and it's the easiest place to see them. Functions will be rerun. You'll just get the result. Brilliant. Thank you very much. Have we got any more questions over here on the right? I was just wondering if you had any tips on inspecting canvas elements. I know that I've just recently switched from using Firefox for building to Chrome and I haven't found a good extension or plugin or way of doing it by default in Chrome tools. I've not done an awful lot of that myself, actually. I don't want to make something up on stage so find me afterwards and we can see if we can find something. Sorry, I can't answer your question. Thank you very much. We've got a hand just here. Thanks for talking. It's something I started getting into last year was just empowering myself rather than just going to a friend and saying to me why it broke, you know, finding out what it is. I think I just wanted to add to it. I don't know if you covered some of the CSS stuff in it but I noticed in, I think it's in Chrome to have tools that you can go in and what you might do is edit CSS on the fly and see its effects and then you can now map that to the actual file and just click save. So you can actually write CSS in the browser and it'll save it to the CSS. I only came across it a couple of months ago. I just wanted to add that to the conversation. Yeah, so the feature that we're talking about is the Workspaces feature. It's really simple. You just give Chrome DevTools access to your local file system and if you're looking at a star sheet in Chrome DevTools and you want to make some changes to it, you can just make those changes. Click save and it will save two files on your local file system. You won't even have to go and look at your text editor. One thing that's another really useful feature that I think we just touched on was the source mapping feature. If you're using a CSS preprocessor like SAS, for instance, you can... Chrome DevTools has the ability providing that your preprocessor and your build step supports it to map changes back to the CSS source files so you're not looking at post-precessed CSS so that you're looking at the code you actually write rather than the stuff that SAS has spit out. So that is really, really useful. We've got a hand just over here on the left in the heart. Hand in the heart. Thanks a lot for the great presentation. You know maybe this question is a little bit out of the big picture but I've been having this question for a long time. Do you know if there exists in the Chrome DevTools like a keyword that we can just type like a break point and put it in our code and then run our website and that stops in there without going to the... I can't quite... Could you repeat your question a bit louder, a bit closer to me? Yes. Well basically I was wondering for some time about the... You know if there is a keyword and that we can put in our code like a break point and then we just go to our website run it and then stop right there into the debugging tools. Do you mean is there a keyboard that will allow you to pull stuff? I've never seen anything like that I think. It's mostly just using the mouse but the debugger keyword does at least allow you to go into your script and put in debugger and then whenever that comes up in the script tag it will pause but wouldn't it be lovely to have a keyboard that has everything that you want on it? I really hope that answered your question. No, it's okay. I just wanted to ask, you know? Okay. Thank you. I could take your hand just over here. Hiya. Sometimes when you change stuff in DevTools and then you want to see how it loads you can't refresh because if you refresh you lose the changes you made in DevTools. Is there any way in the tools to emulate a refresh without actually refreshing the page? Not as far as I know. The keyboard shortcuts will work as you expect them to so if you hit command and R it will refresh but that's not what you want. Yeah. So... I suppose the work around would be to attach your files and then save and then refresh but there's no way sort of within the browser. I don't think there's any way to do that in the Chrome DevTools. A feature that you might want to look into is CSS Auto Refresh. Have you heard of that before? No. So it's a mixture of a grunt or gulp plug-in as well as a browser plug-in. Whenever you make changes within your local file system it will detect those and it will stream the changes to your site without actually reloading it. If you're building a React website you can actually go one step further and your code will update while keeping the state of your program intact. So while you're in the middle of your application and you're seeing it at a certain point you can make changes to your React components and they'll auto reload without changing the point that your application is in. That is React component autoloading. I can't remember the name of the feature. There's loads of cool stuff in different DevTools that you can get. Okay, cool. Thank you. CSS autoloader, I think. If you Google those terms you should get to it. If you're throwing gulp and grunt as well you'll definitely get it. Any more questions? Am I missing a hand? I think that's everyone. I've got a quick question for everyone actually. Can you put your hand up if you're currently using Chrome DevTools? All right. It's popular. Okie dokie. Thank you very much, Katie. That was a great talk. I really appreciate that.