Prying Open the Black Box
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 27 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/35696 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Producer | ||
| Production Year | 2018 |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EmberConf 201818 / 27
3
4
6
8
12
13
15
16
18
21
22
23
25
26
00:00
VideoconferencingOpen setLinker (computing)Mobile appInternetworkingGroup actionPoint (geometry)Scalar fieldMultiplication signShared memory1 (number)Online helpQuicksortOpen sourceProduct (business)Active contour modelClosed setLink (knot theory)Control flowGodCodeXMLComputer animation
02:25
Operator (mathematics)Workstation <Musikinstrument>Staff (military)Data modelError messageCategory of beingSocial classSingle-precision floating-point formatTelecommunicationIntegrated development environmentWordResultantTraffic reportingLibrary (computing)Regulator geneShift operatorWebsiteRight angleMereologyExpected valueMathematicsSoftware developerPoint (geometry)Group actionMessage passingSoftware testingForm (programming)Multiplication signProper mapQuicksortBit1 (number)TrailWorkstation <Musikinstrument>Drill commandsRow (database)System callTask (computing)TouchscreenMoment (mathematics)Category of beingInformationData managementAreaDressing (medical)NeuroinformatikProcess (computing)SoftwareCrash (computing)PlanningChainDependent and independent variablesOperator (mathematics)Arrow of timeFrustrationScripting languageCatastrophismVideo game consoleComputer programmingComputer animation
08:41
Category of beingDrill commandsError messageSystem callOperator (mathematics)Video game consoleSource codeComputer networkElement (mathematics)Read-only memoryInformation securityCAN busLocal GroupEvent horizonNormed vector spaceStatisticsException handlingCellular automatonComputer configurationWorkstation <Musikinstrument>MassSocial classInternet service providerStaff (military)Functional (mathematics)Software testingStack (abstract data type)Right angleMultiplication signGreatest elementCausalityCASE <Informatik>RootDescriptive statisticsReading (process)Error messageIncidence algebraMoment (mathematics)File formatSoftware bugLevel (video gaming)Video game consoleSource codeComputer fileMereologyCode refactoringException handlingVideo gameDrill commandsDifferent (Kate Ryan album)1 (number)Line (geometry)Data managementComputer configurationTrailDebuggerCycle (graph theory)NumberOperator (mathematics)CAN busCodeInternet service providerFrame problemWeb browserReal numberComputer wormFreezingWorkstation <Musikinstrument>Physical systemPolygonView (database)Web pageFigurate numberWordAreaWavePoint (geometry)Physical lawGradientBit rateFlow separationComputer animation
14:56
Frame problemDrill commandsEuler anglesOrbitWorkstation <Musikinstrument>Event horizonCASE <Informatik>Frame problemMultiplication signRight angleMoment (mathematics)Incidence algebraSoftwareDrill commandsCausalityRootOnline helpVery-high-bit-rate digital subscriber lineRing (mathematics)Point (geometry)FreewareReal numberUniformer RaumComputer animation
17:29
Software testingRead-only memoryInformation securityWalsh functionLetterpress printingPhysical systemProcess (computing)Video game consoleElement (mathematics)Source codeException handlingProgrammable read-only memoryComputer networkWindowSynchronizationComputer clusterSocial classLocal ringSystem callSturm's theoremSimulationSineGamma functionOrbitSystem programmingMultiplication signWordDecision theoryDebuggerGame controllerPoint (geometry)CASE <Informatik>Frame problemImplementationFunctional (mathematics)Process (computing)Default (computer science)Statement (computer science)Variable (mathematics)Line (geometry)Control flowCodeOcean currentException handlingWeb browserPulse (signal processing)Domain nameFamilySelf-organizationRight angleEvent horizonInformationSystem callComputer animation
20:13
Point (geometry)Mobile app
20:40
Source codeComputer networkVideo game consoleRead-only memoryElement (mathematics)Information securityResultantError messageCone penetration testEmailDebuggerDefault (computer science)Line (geometry)User interfaceInheritance (object-oriented programming)Image warpingoutputSocial classComa BerenicesCubeUniform resource locatorDependent and independent variablesCAN busAcoustic shadowSoftware frameworkScripting languageMaß <Mathematik>Computer wormStack (abstract data type)Data modelInclusion mapSystem callSpacetimeTouchscreenSound effectSource codeException handlingSet (mathematics)CodeImplementationFrame problemComputer fileSoftware frameworkNumberAbstractionWordSocial classMereologyWeb browserLoop (music)Multiplication signQuicksortMachine codeInformation overloadEntire functionSoftware developerAuthorizationServer (computing)Right angleInheritance (object-oriented programming)Functional (mathematics)Wrapper (data mining)Video gameRootCausalityStack (abstract data type)CASE <Informatik>Metra potential methodError messageBitGreatest elementMobile appComputer animation
24:48
Computer networkData modelLine (geometry)Read-only memoryInformation securityElement (mathematics)Source codeEmailComputer wormVideo game consoleStack (abstract data type)Cartesian coordinate systemPoint (geometry)Greatest elementMultiplication signControl flowCASE <Informatik>Web browserTouchscreenCodeError messageInheritance (object-oriented programming)Inductive reasoningEndliche ModelltheorieFrame problemRoundness (object)Water vaporMereologyHookingNumberSerial portRoutingSoftware bugRootMobile appEvent horizonRight angleOnline helpCausality
27:09
Stack (abstract data type)EmailError messageLocal GroupComputer networkRead-only memoryInformation securityElement (mathematics)Source codeVideo game consoleRule of inferenceLine (geometry)Event horizonResultantComa BerenicesTrailUniform resource locatorPoint (geometry)Selectivity (electronic)Functional (mathematics)Right angleAnalytic continuationCondition numberLine (geometry)Set (mathematics)CodeBoom (sailing)NumberError messageSound effectPairwise comparisonServer (computing)Mobile appCASE <Informatik>Software developerUniform resource locatorStatement (computer science)DebuggerUser profileAbstractionComputer animation
28:14
Read-only memoryPlastikkarteComputer wormPhysical systemProcess (computing)Software testingCondition numberData recoveryRange (statistics)DebuggerComputer networkInformation securityElement (mathematics)Source codeConditional probabilityException handlingStaff (military)Operator (mathematics)MereologyDebuggerPulse (signal processing)Line (geometry)Multiplication signLoop (music)Statement (computer science)Point (geometry)Computer animation
28:55
Function (mathematics)Set (mathematics)Default (computer science)Link (knot theory)DebuggerRead-only memoryInformation securityElement (mathematics)Source codeMobile appVideo game consoleSocial classData modelEuclidean vectorComputer networkGroup actionExecution unitCore dumpStatement (computer science)Mobile appFunctional (mathematics)Noise (electronics)Product (business)Order (biology)Multiplication signVariable (mathematics)Software bugObject (grammar)DebuggerLine (geometry)NumberComputer fileCodeBlock (periodic table)Cartesian coordinate systemReal numberRoutingType theoryWindowMappingProcess (computing)Group actionQuicksortCuboidRight angleVideo game consoleMessage passingGame controllerContext awarenessSource codeTemplate (C++)Computer animation
31:32
Information securityInterior (topology)Read-only memorySummierbarkeitDependent and independent variablesElement (mathematics)Video game consoleSource codePhysical lawLevel (video gaming)Computer wormMaxima and minimaMenu (computing)Computer networkTablet computerAddress spaceGroup actionCloud computingLink (knot theory)Thermal expansionRoute of administrationMathematicsForceElectronic visual displayGAUSS (software)Local GroupType theoryVariable (mathematics)Multiplication signMetropolitan area networkElement (mathematics)Traffic reportingCovering spaceAttribute grammarVideo game consoleRight angleState of matterFocus (optics)Computer animation
32:38
CodeLibrary (computing)Computer programmingOpen sourceSource codeSoftware bug
33:32
Linker (computing)AverageDaylight saving timeSquare numberRSA (algorithm)Coma BerenicesBlock (periodic table)Data typeComputer animationXML
Transcript: English(auto-generated)
00:02
I'm not messing with my own emoji today but I could do this all day but to be honest
00:28
I probably need that snack break more than you do, I just didn't eat that much alone. I'm just not much of a barbecue person you know.
00:41
Anyway I am Godfrey, that's me. You can find me on the internet as kenkincode. Before we begin, I've got to do the Snapchat so if you cannot share from me that would really help with the internet points, so are you ready, good to go?
01:03
Alright let's do this, wait that's, come on, let's try again, alright, oh my God welcome to EmberConf Canada, I'm so excited to be doing the closing keynote for EmberConf
01:22
Canada, I work at a local company called Tilda, we make lanyards, but if you like our lanyards you probably also like our performance monitoring product, we have a booth outside, and if
01:44
you like our lanyards you probably also be into cryptocurrencies and you should check out our ICO, you can find it at skylight.io slash febicon.ico is what it looks like, someday it's going to worth a lot of money.
02:01
But if you like money that much you should also sign up for Skylight using this referral link and that way you and I both will be swimming in Skylight credits or you can just come to the booth and we have a $50 promo code there as well. And finally if you maintain any open source Ruby apps you should definitely come over and
02:23
sign up for a completely free account. So with that out of the way let's talk about debugging. Before we dive in I just want to set some expectations. If you're a new developer, I had you in mind when writing this talk so I really hope I can help, if you have been programming for a while and Ember is your first or primary
02:46
programming environment, this talk is also for you. I know sometimes debugging in Ember could be intimidating or even a little bit frustrating so I hope to help reset your expectation of what debugging should be like and at the
03:01
end I will mention why debugging in Ember might feel a little bit more difficult and what you can do about it. And finally if you're an intermediate or advanced developer then you probably already know everything I'm about to tell you and this talk is probably not gonna blow your mind but I would like to invite you to follow along and think about how we can more
03:26
effectively teach these things to new developers and what we can do to improve the debugging experience for everyone. So let's get started. I've been pretty obsessed with failures lately, specifically engineering failures and catastrophes.
03:43
Not because I enjoy watching people suffer of course but I'm quite fascinated by the ways that we manage to analyze and learn from these mistakes that we make. A lot of things happened in 2017, however one of the things that didn't happen was
04:01
plane crashes, specifically crashes involving commercial passenger jets. You see we've flown over 4 billion passengers last year which is more than half of the world's population, pretty mind-blowing. And yet there was not a single fatality in commercial passenger jetliner in 2017. That wasn't always the case though.
04:21
In the early days of A-Vision history flying was a pretty risky business and in fact it was so risky that the early AML pilots called themselves members of a suicide club. They aren't wrong because it was later calculated that their average life expectancy was as low as 900 flying hours which is roughly how many hours a commercial pilot fly every
04:46
year today. And since those early days we have invested a lot of resources into improving the safety of flying for everyone. And in the modern aviation days every accident is very heavily scrutinized and investigated
05:01
with the results of these investigations leading into new regulations and engineering improvements to prevent the same kind of failure from ever happening again. So every time you fly today in some ways you fly safer in parts because of the pilots and passengers who lost lives in these hard-earned lessons.
05:21
Going back to 2017, outside of the aviation history one of the unfortunate things that did happen was the North Korean crisis. If you remember that year, last year the North Korean military fired some ICBM test missiles and got everyone seriously worried.
05:41
On January 13th this year, if you were watching TV at home in Hawaii, there was a pretty nasty surprise for you. The US Pacific command has detected a missile threat to Hawaii. A missile may impact on land or sea within minutes. This is not a drill. That was some pretty scary stuff, right?
06:02
Fortunately as we have later learned there were no actual missiles heading for Hawaii that day. It was a false alarm. But millions of people were terrified and many have sent farewells and last words to loved ones. So how did something like that happen? How did a false missile alarm get broadcasted on TV?
06:22
Well that's the question that the FCC investigators need to answer, but figuring that out is no easy task. Obviously the false alarm got broadcasted on TV because the TV station operator pressed the button to put it on the screen.
06:40
But if you go ask him, he will tell you, well I'm just doing my job because my manager called me up and told me to put it on the screen. And if you ask the manager, she will tell you, well I got a call from the Hawaii Emergency Management Agency, so that's not my fault either. And following this chain all the way up to the top, you will find out that, well turns out this was supposed to be a drill at the EMA, so what went wrong?
07:04
Clearly there's some miscommunication going on there, right? Because on one hand, the supervisor at the EMA intended that to be a drill, but on the other hand it came out as a real alert. So who didn't get the memo here?
07:21
Well according to the investigation report, the EMA supervisor initiated the unscheduled drill during a shift change. And despite including the phrase exercise, exercise, exercise as they're required to, he went off script a little bit and at one point said the phrase, this is not a drill mistakenly. And in turns, the employee responsible for sending out the alert claimed that he missed
07:45
the exercise part of the announcement and genuinely believed there was an actual emergency. Supposedly a coworker put the announcement on speakerphone partway into the message. And that's basically all we know. So unfortunately we don't have a very good record of what actually went down there,
08:07
so that's basically all we have to work with. But wouldn't this be a lot easier if we have some sort of proper paper trail of who talked to who during that time? Even better, wouldn't it be nice if we can just freeze time in that moment and
08:20
interrogate all the parties involved? Well, that probably sounds to be true for FCC investigators. Luckily for us software investigators, this is totally feasible and in fact your computer is always trying very hard to give you this information all the time. So if you remember this red arrow thing that you see in the console all the time,
08:43
if you don't know how to read it, it could be quite overwhelming. So why don't we try to use this format to describe what really went wrong in the Hawaii incident. So the top line is the error message, a description of what went wrong. This should always, always, always be the first thing you read because if you get lucky
09:05
sometimes this is all you need to read to figure out what went wrong. But in this case this is really just telling us something we already know, right? Like we know we send alert, we don't think we should have and so the real question is why do we do it?
09:21
This is where the stack trace comes in, right? Like the scary looking thing at the bottom of the error is a paper trail of who talked to who, something that the FCC investigators would love to have in this situation. At the very top that's where the error actually happened, right? So that's the TV operator triggering the alert and the next line is why he did it in this
09:46
case because the manager asked him to and in turns you can follow the trail all the way back to the EMA supervisor. And if you click on any file name in the stack trace your browser will actually just
10:01
take you directly to the definition of the function. So it looks something like this. So looking at the code here it might be very tempting to just fix the problem right here, right? Okay, we sent an alert and we shouldn't have sent the alert so maybe we can just
10:23
double check with the Pacific command before we do it. Now I totally understand why this might be tempting, right? Maybe this is the part of the code base that you know really well, perhaps you just don't want to open the cans of worm that is sitting in the other file that is the
10:40
legacy code that predicted you in the company. There's a bug in my code, I fixed the problem. I even wrote a test and it passed it so problem solved, right? Well there are two problems with that. The first problem, imagine how this code would look to the next person working with this code. Maybe they have to come fix a completely different bug, right?
11:03
If that's me I would probably look at this and think well I thought I knew what this method is supposed to do based on the name but now reading the source code I'm not so sure anymore, right? Like why would this method even be called when there are no incoming miss out? Like what does that mean? Like I guess probably that's probably because of some very complicated reasons I
11:24
don't understand yet so I don't want to break things so I just work around the problem somewhere else instead and with that history has repeated itself and we have seen the full life cycle of how a spaghetti code base is formed. So that's problem number one. Problem number two is that we didn't actually fix the problem enough, right?
11:44
Sure we have prevented the TV station from broadcasting a false alert but if you go a few frames up the stack you will see that the system is also supposed to notify the cell phone providers to send SMS and push notifications so we still have a problem
12:00
there. Sure we can add another conditional around it but I think the better thing to do is probably get to the bottom of this and try to fix it from there. Remember what we said about freezing time earlier. This is what the pause on exceptions button does. If you enable it, refresh the page, it will freeze everything as the error is
12:21
happening giving you a chance to go up and down the stack and capture any evidence you might want and interrogate the parties involved. So similar to the stack tracing error message, clicking through the call stack on the right will jump you directly to the function definition and
12:41
however because we are frozen in time there are more we can do. You can probably see it highlighted a variable there. Because we're frozen in time you can use the console to basically try to poke at any value that might be in scope in time at that point in time.
13:02
So here we can see that the problem is the employee is called with his drill set to false but his exercise is undefined. So they generally believe this to be a real missile threat. So how come his exercise is undefined here? Is that supposed to happen? To find out we have to go up one level and it looks like the problem is the
13:24
coworker forgot to pass that option along so we can fix that pretty easily. And after running tests everything is green and so like we're good to go. But is that good enough? Well we can actually go one level further than that.
13:41
If we go one more thing we'll see that this is really a bug in the supervisor, right? Like why are there two separate options for his drill and his exercise? We should probably just fix the supervisor so it doesn't go off script and pass two conflicting things in a critical moment like this. With that we have eliminated some unnecessary code and entangled some of the spaghetti for
14:03
future readers. So we fixed our first bug, we learned to read error messages, we learned to understand the stack trace, we learned to freeze time when exceptions are happening and use the debugger to go up and down stack to find the problem.
14:21
Most importantly though we learned that debugging is not just about fixing the immediate problem, we need to dig through the different layers to find out, to find the root cause and sometimes that might mean doing some refactoring to, some refactoring upstream to prevent similar errors from ever happening again.
14:45
All right, so that was quite a lot to take in so I'll give you a little break. Let me tell you now a story. This time we have to go back to 2003. On January 16, 2003 the Columbia space shuttle is ready to come home after spending 15 days
15:02
on mission in orbit. Sadly they never made it, the orbiter disintegrated completely during reentry, killing all seven crew members on board. So what happened here? If you were able to freeze time in this few critical minutes you'll notice that there
15:22
is a pretty big hole on the left wing so that's why it disintegrated because it overheated when it was during reentry. But this is only half of the story. The critical question is why is there a hole on the left wing of an orbiter in
15:42
the first place? Well unfortunately the ability to freeze time alone won't help you here. The event that led to the failure actually happened much earlier. It turns out during the launch a piece of foam broke off hitting the left wing at
16:02
very high speed leaving a hole behind. And these kind of problems where the root cause happened in a much earlier time frame than the eventual failure is very common in both the real world and in software. In the Hawaii incident we knew that the supervisor intended to perform a drill but it came out
16:21
wrong on the other end so we know to look for the problem somewhere in between those two points in time. As we explained the stack trace basically gave you a moment in time snapshot of the explosion which is represented on the right hand side here.
16:40
But in this case instead of just looking at the very last moment we need to look at the whole timeline of the mission to figure this out. We know that we didn't have a hole in the space shuttle before we launched it we checked and we knew that there was already a hole before the reentry so our answer must
17:04
lie somewhere in between these two points in time. So instead of going up and down the stack we need a way to go back and forth in time in this case and unfortunately time traveling is actually quite difficult but what we can
17:20
do is freeze time in some of the key moments in the timeline and inspect them individually. This is what breakpoints do. You can add breakpoints to your code by using a debugger statement which some of you probably already familiar with. When the browser encounter one of these debugger statements it will pause the execution
17:41
giving you a chance to inspect everything and as you can see we're currently paused in the time just before the pre-launch status check. Just like when we were paused on an exception you can navigate up and down the stack and inspect any variables that are in the scope but there's one additional thing you can do here you can go forward in time in a very precisely controlled manner.
18:07
The step over button let you go forward in time one statement at a time. Despite the pretty rude name it is usually pretty good default because it try to keep you in the current stack frame so you won't feel too disoriented.
18:24
So clicking on that will advance time one statement at a time inside the current function and in this case it will perform a status check in a different team in the mission control every time you click that button. So far so good but as we learned sometimes we need to go deeper than that.
18:42
So here we pause right before we pull the flight the flight director for the go and go or no go decision but what if we don't want to just take the word for it what if we want to double check to make sure they're doing the job correctly. That's where the step into button comes in handy instead of just calling the function
19:04
and going over the next line it brings you into the implementation of the function. Once you're inside everything works exactly the same way you can keep going forward one statement at a time you can keep going deeper if you want and in this case I'm happy with what I have seen here so I decided I don't need to micromanage them any longer in which case you
19:25
can use the step out button which for Canadians I find it root AF but naming is height. It does what you would expect if you it will keep going forward in time until you have returned out the current function back to the previous stack frame so and we I won't waste your time
19:46
here so if you think you can trust the rest of the teams you can just click the step ball function again and we'll be back to we'll back be I will back will be put back
20:00
in their previous stack frame so finally when you're done inspecting the current time frame the resume button will advance time until the next break point if you have one. So at this point you're probably thinking yes I feel invincible I can debug anything now so can't wait to try this in my amber app well before I let you off and go do that I do have
20:25
a few warnings for you remember when at the beginning when I said the debugging experience in amber could sometimes be less than amazing well I'm gonna tell you what the problems are why it exists and what you can do about them so the first problem is there are usually
20:43
a lot of things in the call stack in an amber app so this is I believe a screenshot from skylight the amber app so part of the problem well part part of the reason is that amber is doing a lot of legwork for you like managing the run loop or so so by the
21:04
time your your hope that the hope that you implemented is called there are already a million things in the stack and if nothing else that just makes everything feel very overwhelming and the other part is that you will often be going through a lot of amber abstractions in an amber
21:22
app that is intended to make your life easier when they're working properly such as dista underscore super right so if you try to step into this what you you end up inside the amber super wrapper function as we call it instead of where you properly want it which is
21:44
the the implementation you inherited from your superclass right so of course if you if you keep stepping like this is not magic so if you keep stepping you'll eventually end up in the place you want it but you would have to first understand how you got here in the first place and
22:03
like what a nerve you're looking at right so would be nice if you don't have to do that to solve this problem you can use the framework blackboxing feature the easy way the easiest way to do it is just right click on any frames that you don't want to see and you can click
22:20
blackbox script and as you can see it go away so it's hidden from you in the call stack on the right hand side but more importantly now when you try to step into it you will end up in directly inside the server class implementation instead of going through the dista underscore super wrapper so essentially you can label any code that is part of ember and
22:48
treat them sort of like native code in the browser you don't really need to look at their implementation because you just generally you can just assume that they work if you don't want to blackbox everything one by one alternatively you can also go into the developer tool settings
23:06
and blackbox the entire vendor.js file and with that setting you can see that everything in your from ember or other dependencies where they come from mpm or other sources
23:20
will be hidden away from the stack trace from the sorry from the call stack on the right and you can see that in in this case all we have left is code we have written in our application and that even fit inside one screen's worth of space so that's pretty neat a word of caution
23:45
though a lot of time ignoring the whole vendor file might end up hiding too much stuff that you might actually want to see in particular you might want to look at the implementation of some add-ons or sometimes if you have pause on exception turn on and the exception happens
24:04
inside the blackbox code like maybe an ember dot on error it isn't paused correctly so it probably takes some tweaking to find the the settings that work best for your for a team but like blackboxing the vendor file is certainly a pretty good starting point and okay onto the second
24:25
problem with debugging an ember this is essentially the same kind of problem as we encountered in the columbia space shuttle problem right where the root cause and where the root
24:40
cause and its effect is very very far apart as we saw earlier sometimes blackboxing helps a little bit here i don't know if you can see that but you can see at the bottom the bottom frame is basically the model hook and application route and you like go through all layers even including async code to your serializers and adapter so that's pretty neat but
25:05
sometimes the browser could never figure it out for you for example you might have loaded some data in your parent route and you didn't notice that you have a bug in your adapter so like it's not until way later when you try to access the data in your in your child route that you
25:24
notice that there's an error or maybe there's not even an error there's just a blank screen of nothing right as far as the browser is concerned those are completely separate events so it will be pretty hard for the browser to tie them together for you and arguably this problem
25:41
is not really unique to ember but it certainly is very common in ember apps because of the way we tend to the way we tend to do things in ember in this case you basically have to remember the tricks we learned from the columbia space shuttle example and basically drop in
26:03
breakpoints in strategic times to investigate the situation in summary you should try to ask yourself what did i expect the code to do and can i find a point in time where it was still behaving correctly and from there you can you can see when did it start diverging from
26:23
your expectation and from there you can you can use the tools that we we learned here to narrow in and find the root cause of your problem finally i will use the remaining time by which i mean the first five minutes of your snack rig
26:43
to show you an assortment of tips and tricks that may help you in your journey i'm going to go through these very very quickly so don't feel bad if you can't follow along you can always re-watch this part when you when you're working when you're running into problems so
27:00
let me drink some water and here we go so number one brick points so far we have been talking about using debugger statements in your code but you know you can also add them directly from the developer tools without editing and saving and reloading you can just click on the line number and boom there you go to remove it just click it again now you can even turn it
27:23
into a conditional brick point by right click on it and select edit brick point and for example you can turn this into a conditional brick point that only trigger when the set is it's not 200 so when you have an error from the server you will trigger this brick point otherwise it just goes through and for comparison this is the equivalent code that you would have
27:44
written in your code for the same effect and finally you can also set a brick point that triggers whenever your app tries to do any ajax requests or you can scope it more narrowly by matching certain url so in this case i matched it to me.json so it
28:06
triggers the brick point when the app is trying to load the user profile. Next continuation so let's say you have a brick point at the top of the function and you want to fast forward to the middle of it you can just keep pressing step over but you can also just
28:24
right click on the line and say continue to here and it will just do exactly that. Sometimes you may have the opposite problem where you have a debugger statement in a for loop that is triggering too many times because you're looping through a very big array you can right click and select never pause here or alternatively you can click on the resume
28:45
button and you can sorry you can click and hold on the resume button and you can press the play button instead which will ignore the brick points and go all the way to the end. Next up debug functions so you might have a lot of console.log statements in your app
29:02
they are pretty useful for debugging but maybe you don't want to ship them to production where they will spam your customer's console. So do you know that ember provide a debug function from the add ember slash debug package the nice thing about them is they are stripped in the production build so
29:22
a you won't have to worry about the noise that they produce but also they won't increase the file size of your app or they won't slow down your app if you're doing any expensive inspection inside the message. Along those lines you can also use the assert function
29:41
that is pretty useful for verifying some assumptions that you might have made in your code which can often help you catch bugs before they become a problem if nothing else it is a pretty good way to communicate to your readers that you expect certain things to be true all the time. They also strip from the production build so you can sprinkle them in
30:03
pretty liberally without worrying about performance or file size etc. Finally templates and debugging templates and ui did you know that there is also a debugger statement you can use in handlebars that would bring you into
30:22
the javascript debugger so you can just like a real debugger would so from there you can you can have access to your block params or your your context object etc so that's pretty handy and separately you probably already know about the ember inspector but you know that
30:42
anytime you see the dollar e button you can click on it and it will send the object to the console in the dollar e global variable so you can play around with it and by the way while we're here anytime you see a function in the console you can right click and click show it's that show function definition it would bring you directly to
31:05
the source code this is pretty handy if you have something like the actions hash where you're trying to figure out where the functions are coming from oh and also by the way if you have source maps you can do command p or like probably control p on windows and you can start typing a file name and it will open up the the file you want like you can do for example
31:26
command p and type uh routes slash application and it will generally do it right then and um and over in the elements panel similar to the ember inspector every time you select an element it will go to the dollar zero global variables so you can also play around
31:44
with it in the console and you can also right click on it to trigger things like hover state or focus state which are generally quite tricky to reproduce when you're debugging in the console right like you can't use one hand to hover it and type at the same time so this
32:01
will come in handy and finally one last thing you can um select an element and set a breakpoint on it so that every time that element is updated in any way it will put you in a javascript breakpoint this is pretty handy for debugging rendering problem where ember is adding
32:21
or removing nodes or attributes that you didn't expect and you don't know where they come from what triggered it so um yeah you can you can basically use this to set a breakpoint so you will have an opportunity to investigate that and that concludes my talk and i hope that
32:42
no matter where you're at in your debugging journey you will feel more empowered in some way after a talk and because in my opinion i think debugging is one of the most important programming skills you could learn that is not often talked about enough so once you have debugging your own code you can start peeling away the black box by stepping into other like
33:06
into the source code of libraries that you depend on to understand how they work and from there fixing bugs and sending pull requests to these libraries or even ember itself is only a small hop away and that's how i personally started contributing to open source and maybe
33:23
one day that could be you too so um that's it thank you very much