 Samantha. Thanks for being here virtually even. Today I will be talking about the power of the bagging and my idea is to not only show you a few tricks but how you can use these tools to go beyond just the bagging. So my journey with the bagging started several years ago back in college. I didn't know coding before that and my professor's philosophy was mostly to teach us the abstracts of programming and not so much the tools. That meant that we were left to figure those things out by ourselves so in my case in the beginning I would use no parts program and yeah that meant doing everything manually. Now I'd love to say that it took me just a little bit to learn about all the other tools that I could use to make my experience easier but one year later I was still programming in Notepad and just with a different language. Back then when I didn't know what was happening with my app when there was a bug or it was just like exploding not functioning at all I would add a printf that is like an equivalent for a console log and when I had like zero idea where my code was breaking I would literally just add printfs everywhere like one per line of code. Thankfully after a while I did learn about IDs and bagging tools and this was from the days that I would code in .NET and use Visual Studio for the bagging. One of the things that I miss the most about that debugger is being able to just keep lines of code. The professor still doesn't have it I guess it's a difficult feature to have but it was super helpful. Nowadays I'm a work developer mostly so I spent most of my day my working day on the browser and the bagging tools that I use are the ones that come with the browser. I also use the editor of course but yeah a lot of my time is spent here. So let's start with some of the challenges that I faced in like all-by-years coding and I will walk you through them and like we can see how the bagging tools help us through this. So one of the challenges that we usually face is mostly the difference between debugging or handling issues in development versus production so in development you actually have access to the code and you can change things and sort of see how they behave and in production that's not not as easy but we still have things we can do. So to demonstrate this I have a buggy app and let's say I have this application that is asking me a math question. I answer it and it's saying oh you have like it's not the right answer and I'm like I'm pretty sure that's the right answer. So if you've worked on this app and you know probably where is the issue happening so you would usually just go to like your editor and you go okay yes I know this error is happening on this component I can just add a bugger here and save and sort of start debugging oh first to answer that's where the error is happening and yeah you can step through the code see why is that working then I'm like oh actually I shouldn't have parsed the answer as an integer because it's not always going to be one then you can go back to your code fix the issue and go on with your life. Another way to do this would be to just add a breakpoint on the actual source here on the browser. Now if you ever look through the sources tab of your Ember app you will see that you have here like where your page is located and then you have an asset folder and this assets folder is going to have all the JavaScript and also CSS and other assets but what we care about here is mostly the JavaScript and you will find folders for the Ember framework that's like this Ember folder, Glimmer, also Ember, Testing, this add-on tree output folder will actually contain all the code for every add-on that you have including your app so if you never ever need to actually debug that code you can just walk through there and open it and add breaking points. Now let's say I hadn't put a breakpoint here I had everything closed you will find always a folder that has your app name in it and inside you will see all the app code mapped pretty much as you see it on your computer in development and I can just go where I know the issue is and also put a breakpoint answer and yeah we go back to like to the same point and we can see the same thing without having to change our code and reload the app. You can also find here a few other things that help you in debugging. I'm not going to go through all of them but yeah mostly you can watch variables to see how they change you can see where you close like the stack trace. Here you can actually see the variables we have declared and you can even change their value so let's say I want to make this code pass just because I want to continue working on the app and I just change it there you can see the breakpoint and yeah several other stuff so here now I've changed my solution just so the code can pass and I yeah just resume and hey we can continue like working on the app. Now this is perfect and it's easy to see in production sorry in development but the actual question is how do we find the same thing when we're in production and we don't have our code mapped that way so let's see the same app opened in a production environment if I go to the sources tab I see the assets folder also but I don't see like all the folders mapped and I have four files here the one that has your app name and a fingerprint will be the one that has all the app code so everything you've developed and you'll see a vendor's file that has all the framework code so everything related to ember every add-on you have added external libraries that may not be add-ons and the same thing for the CSS like you have one for your styles so yeah it's here my styles and you have one for styles that are added by add-ons like I don't have any here so it's empty now how do you find the code to the bag here in production you will see that even though it this is a mini file file and like yeah you don't actually have all the variable names you still have some strings that name the modules that we have declared so you can see for instance you can find the adapter you can see here a component definition actually this is a manager but here a component if you want to see it in a nicer way you can just click the pre-defy like let's go back here this icon and this will generate like a different tab but it has the same code but prints are nice printed nicely so you can actually find it easier and debug it so our issue here what's happening in components so we can just search for the name of the component we want to debug now you will see a lot of this is an initialization initialization code that's a hard word and if we keep looking we will eventually find the like our functions here you can see you have the evaluate answer and this is pretty much the same code we did back it before just format it differently and we can also set a break point there just write this thing and in this case I can still access the variables and let's say I want to just change this one to make the code pass and I can just go set the value I want and I know the comparison would work now and I can just continue yeah and that's how we can pretty much is the same thing we did in development but here in production so back to our slides a small recap of this section you can usually do all the bagging on the sources tab without changing your code you can just set break points there you will find while you're in development the app structured pretty much as it is in your computer you can access the scope section to view the value of the variables you have and also change them if you need to and just remember that in production this script will be all in one file but you can do the pretty formatting and also debug there so next what happened when we have external libraries and how can we debug them in case issues like sometimes issues will not be your fault they will be actually someone else's code yeah going back to our app I'm going to remove the break point here close this and I'm going to try to go to this level and I can see an error and we look at the message it's not like we know it's happening in the route but the message itself is not saying much and yeah the stack trace is not that helpful either so sometimes one of the issues that we have with Ember is that you will see a lot of the internal code in your stack trace and you may not actually find where the issues beginning but in this case we know it is happening when we try to navigate to the route so let's just open that route here so here I have my model and I'm using this is like the instance of an external library that I'm using to load the data I can set a few break points like maybe it's failing when I initialize it maybe it's failing there maybe failing here who knows now you step through it that part works this is actually a promise I need to sort of continue and my code is not actually stopping here so I guess it's failing inside this method so let's just try to step inside it here so now we are on the actual definition of the function on the library and we can step through it and oops now I find found the issue it's not like something on my code so I can just go to like the GitHub of that person and say hey you have a bug no joking like yet you can do that but let's just see what are other options we have here one of the things that I can do on the sources tab it is actually change the code and save it and this will allow me to try this function as without change so I commented that line of throwing the exception and I can just skip it yeah and now I get the results I wanted cool so one thing that I would like to point out here is the difference between add-ons and external libraries like this is an npm library that I'm importing through ember out to import and here like on the sources tab I will find it below this little cloud that is ember out to import and like the differences add-ons I will actually found find them in this other folder but you can still see like put the code of both type of libraries so yeah like if you want to back any of these other libraries you can just open them at a break point somewhere and see what happens if you're curious to see how something works yeah so I think that's it for this case let's go back to our slides there so just to recap yeah sometimes you will find issues that are not exactly on the code but on third-party libraries and don't be afraid to step in them like this was a very simple example but sometimes it will help you find where the actual error is coming from so for instance this talk was inspired because we had a similar problem production where we were interacting with our party library and the error message that we were getting was not helpful at least not for them like they couldn't reproduce the issue we were having but we didn't know exactly what was your original error and we had to sort of pair debug from someone else's computer while having the code introduction and by using both the formatting of the ember code and then being able to step on the actual library we managed to find the original error message and that's something we could use to actually contact like the third-party library that was used by another third-party library and give them the information they needed to fix the issue so sometimes you will step into code that will look weird to you you don't have to understand it like I don't understand most of the code I stepped into that it's not mine but you may still find the information you need even if you don't really understand the code or you don't really get to fix the issue you can edit on-site just as I did if you want to try something yeah like change the code a little bit maybe you want like something spelling a specific point but you actually need to see what happens afterwards yeah like this can work also just remember the difference between where the add-on code lies versus the infirm library code now the third challenge I want to walk you through today is what happens when you have an app and someone reports an issue but that's not something you actually developed it happens a lot I guess in every developer's life that you end up coding in an app that you didn't started from scratch and sometimes especially when you're new in a project that can be like super hard to figure out especially because people really want to fix you to fix the issue and you're like where do I start so let's go back to the app I'm going to go through my third example here now let's say I have this memory game like I think I don't know if you all know it but it's basically you have to like guess or remember where the cars were and when you have to that fail we actually want them to like turn back as they did but don't we don't want them to like take that long really like because we cannot do anything so let's say your manager comes and says yeah I have this issue I don't know why it's happening but I want it fixed by yesterday you're like oh I actually didn't develop this thing now we have the amber inspector and one thing that I like to use it for is learning a new app especially this view is very helpful because even if you don't will like you don't know straight away where things are you can at least see what components make this thing and you can actually start to figure out where you should start looking for like possible issues so here I know I have like my route and then link to that's not what is happening maybe it's not related I guess then I have a big component called memory game and several memory cards component one cute thing that I figured out just recently is that you can actually click here and you will be taken to like that instance of the component this the amber inspector has a lot of helpful tools I won't walk you through them today but you can find other talks and actually the guys I had a lot has a lot of information yeah so you can learn how to use these tools they're very helpful so now I know how my components are called and I can for instance say I have a feeling that the memory game is the one that is causing us issues so I can go to sources tab again and I can go to components and open memory game and yeah all this initialization code I can see the template here yeah it's pretty interesting to see I can see my properties being initialized and I continue looking and I have a hint like I have a function here called call card click that receives a card so I'm going to add a bugger here and see what happens so yeah now I'm checking that the unflip cards funny name is not running I'm comparing two cards I only have one I set it to flipped I set my flip card to it then I ask if the game passed so yeah that works fine now I have this unflips card and it steps through it and I can see that the cards didn't match and I got to call this task and this is a number concurrency task yeah this is just a hint like I sort of know some of these properties and I sort of I think this is a task and we can try like stepping into it whenever you step into this is actually amber code for getting like when you get to need to get property of something so like we're getting this task from the component we don't want to actually step into that so we can step out and go back yeah we don't want to go for that one either now if you try to again step into it you will actually be taken to code that is for amber concurrency now the thing is we won't really see like where the task is fine but I really want to actually debug the task itself not I'm better concurrency code in this case I'm just going to put a debugger here and one way to do this because we can try to find these cards and yeah it's like I cannot find the actual code so when it's like you're having a hard time finding the actual definition of a function you can use this thing that the crum tools do is like you take like here is the task and the actual function for the task is this one and whenever you have a function you will add the function location and I link to the actual file so we can click there and now I can actually debug that one and yeah now I see oh actually where's have this big number here like we probably want to have half a second not five seconds now if we want to as we did before and just edit it yeah we go back we try it and it's not not really working now the reason why these doesn't work as it did when we changed the other case is because this file is actually the source map is not the actual JS file for your app now how do we find the actual JS file let's close number let's close this one now here you will find a JS file with your app's name if you open it you will see that it's similar to what the one we saw in production but actually not minified and you can also find this memory card component here sorry so it's the same code and this thing like if we want to debug this one you'll notice that it will take you to the source map file that is because it's actually easier for you to debug that one but if you want to actually make changes to just try it out you need to do it on the whole file so we should find that big number we want to change so here we have the task you can try changing it and then now you see like we can actually see it work so a small recap use the inspector like there's a lot of information you can get from your app from there and it will help you especially in the beginning of a project that you don't know to figure out the models you have the structure of a page and a lot of other things if you don't know where a function is defined and you haven't a far time figuring it out but you do have access to the instance you can always go to the function location and remember that if you need to edit something to just try it out you should you should do it on the actual app file and not on the source map now other talks that you can see that will have a lot more information related also to debugging and also to amber debugging are listed here also don't forget to read the guides there's a lot of information there both for Chrome tools Firefox tools and the inspector thank you for listening again my name is Samantha I'm a software developer from Simplats and hope you had a nice time