Debugging tools for the Web
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 | 133 | |
| Author | ||
| License | CC Attribution - NonCommercial - 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/48921 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
NDC London 201697 / 133
2
6
10
12
15
17
23
24
28
30
31
32
35
36
39
40
43
44
45
47
51
52
55
58
59
60
61
62
63
64
67
69
71
73
74
75
82
84
86
87
97
103
107
108
111
112
114
115
117
120
123
126
128
129
132
133
00:00
Software developerSoftwareTwitterComputer-generated imageryGoodness of fitSoftwareInformation technology consultingWeb applicationSoftware developerProjective planeCartesian coordinate systemDebuggerJSONXMLUMLComputer animation
00:50
Graphical user interfaceSoftware developerJava appletCross-site scriptingScripting languageClient (computing)Group actionGraphical user interfaceWeb 2.0Cartesian coordinate systemServer (computing)WordScripting languageSoftwareComputer animation
01:47
Computer-generated imagerySoftware developerSoftware bugCodeStatement (computer science)Uniform resource locatorGoodness of fitPhysical lawCartesian coordinate systemSoftware engineeringSoftware developerProgrammer (hardware)Video game consoleLoginDebuggerWeb 2.0Computer animation
02:40
Software developerVideo game consoleMultiplication signCartesian coordinate systemStatement (computer science)Web applicationLevel (video gaming)
03:33
Software developerWeb browserServer (computing)InternetworkingIntegrated development environmentGraphical user interfaceSoftware bugCartesian coordinate systemTelecommunicationAreaWeb browserServer (computing)MereologyWeb 2.0Integrated development environmentWeb applicationInternetworkingHypermediaSoftware developerGraphical user interfaceComputer animation
05:27
Software developerGraphical user interfaceComputer networkJava appletScripting languageGraphical user interfaceSet (mathematics)NeuroinformatikAndroid (robot)Cartesian coordinate systemWeb browserSoftware developerWeb applicationSoftwareWeb 2.0Software bugTablet computerScripting language
07:50
Software developerJava appletScripting languageComputer virusVideo game consoleLetterpress printingDrag (physics)InfinityFile formatLie groupGame theoryVideo game consoleComputer fileCodeGreatest elementWeb pageSoftware developerLetterpress printingDebuggerIntegrated development environmentCartesian coordinate systemSet (mathematics)Single-precision floating-point formatContext awarenessKeyboard shortcutSimilarity (geometry)Functional (mathematics)Variable (mathematics)Error messageSource codeFile formatLibrary (computing)Point (geometry)Server (computing)Web browserStatement (computer science)Visualization (computer graphics)Data structureWritingStructural loadRow (database)System callMultiplication signKey (cryptography)Open setGraphical user interfaceJava appletLocal ringStack (abstract data type)Scripting languageControl flowCausalityDoubling the cubeWindowReal-time operating systemProcess (computing)StatisticsConstraint (mathematics)Automatic differentiationCycle (graph theory)Video gameComputer animation
14:02
Software developerSource codeCodeGraphical user interfaceLibrary (computing)MappingRevision controlComputer fileMultiplication signWeb pageCartesian coordinate systemSource codeFile systemInformationLine (geometry)Data structureVariable (mathematics)Level (video gaming)Rational numberProcess (computing)Physical systemDifferent (Kate Ryan album)Control flowPoint (geometry)EstimatorComputer animation
16:11
Software developerJava appletScripting languageCross-site scriptingElement (mathematics)Video game consoleView (database)Inversion (music)Dean numberWeb pageTouchscreenFile formatReal numberTouch typingEvent horizonUniform resource locatorDependent and independent variablesContent (media)Address spaceTrailGraphical user interfaceQuicksortWeb applicationHome pageData structureCodeMultiplicationTouch typingSingle-precision floating-point formatElement (mathematics)WeightSoftwareSoftware developerCartesian coordinate systemView (database)CuboidAdditionProcess (computing)Web pageMoment (mathematics)TouchscreenDefault (computer science)Medical imagingEndliche ModelltheorieConnected spaceInternetworkingDependent and independent variablesMereologyString (computer science)Structural loadMultiplication signGreatest elementEmailElectronic mailing listAreaSemiconductor memoryLevel (video gaming)Profil (magazine)Different (Kate Ryan album)Computer fileComputer configurationPhase transitionLibrary (computing)Run time (program lifecycle phase)SurgeryCovering spacePoint (geometry)Software testingScaling (geometry)Link (knot theory)Scripting languageMathematicsMobile WebLocal ringHTTP cookieContent (media)Event horizonNetwork topologyKeyboard shortcutData storage deviceResultantReal-time operating systemRule of inferenceElectric generatorSet (mathematics)Combinational logicGoodness of fitMobile appComputer iconSlide ruleWeb 2.0Right angle
26:24
Software developerGraphical user interfaceGoogolLink (knot theory)MathematicsSoftwareTelecommunicationAreaCASE <Informatik>Computer animation
27:27
Graphical user interfaceSoftware developerHome pageAlgebraSingle-precision floating-point formatScripting languageJava appletCartesian coordinate systemTelecommunicationPairwise comparisonSingle-precision floating-point formatWeb pageProfil (magazine)MereologyGraphical user interfaceClient (computing)Structural loadInformationLevel (video gaming)SoftwareMultiplication signWeb application
28:58
Software developerClient (computing)Web browserServer (computing)Proxy serverNetwork socketMultiplication signExpert systemProxy serverWeb browserClient (computing)Socket-SchnittstelleWeb applicationMereologyWeb 2.0WebsiteJSON
29:56
Plot (narrative)Software developerVoltmeterMotion captureRight angleUser interfaceWeb pageWebsiteCartesian coordinate systemDataflowConcentricWeb applicationOrder (biology)Multiplication signInformationElectronic mailing listTheory of relativityResultantCommunications protocol
31:03
Uniform resource locatorSoftware developerInformationTheory of relativityComputer iconResultantCartesian coordinate systemInformationView (database)Right angleDependent and independent variablesGroup actionMereologyGreatest elementComputer animation
32:31
Software developer10 (number)EmailExtension (kinesiology)WindowWeb browserHTTP cookieCartesian coordinate systemMeasurementMedical imagingFigurate numberView (database)Computer fileDependent and independent variablesSource codePresentation of a groupGraph coloringSineNetwork topologyTexture mappingStatisticsParsingWeb pageWeb applicationHexagonContent (media)InformationRepresentation (politics)Web 2.0Row (database)EmailComputer animation
34:59
Software developerStatisticsGateway (telecommunications)Content (media)EmailCountingServer (computing)Disk read-and-write headGame theoryScripting languageLogic gateClient (computing)Web browserProxy serverStatisticsMeasurementCartesian coordinate systemWeb pageConnected spaceGraph (mathematics)Content (media)InformationGreatest elementMereologyClient (computing)Server (computing)Integrated development environmentProduct (business)Single-precision floating-point formatCASE <Informatik>BitJSONSource codeComputer animation
37:09
Software developerDrag (physics)Dependent and independent variablesServer (computing)Drag (physics)ResultantSet (mathematics)Virtual machineMoment (mathematics)Rule of inferenceComputer filePrice indexSoftware developerLine (geometry)Address spaceRegulärer Ausdruck <Textverarbeitung>Web pageMultiplicationMultiplication signSystem callClient (computing)Text editor2 (number)MiniDiscFile archiverCartesian coordinate systemMatching (graph theory)Directory serviceDrop (liquid)Uniform resource locatorComputer simulationDifferent (Kate Ryan album)Computer animation
40:25
InformationSoftware developerDemo (music)Software developerNeuroinformatikClient (computing)InformationOffice suiteServer (computing)Computer fileVirtual machineWeb 2.0IP addressWeb applicationWebsiteFile archiverResultantDemo (music)Dependent and independent variablesPlanning
42:37
Convex hullSoftware developerMIDIStructural loadVirtual machineInternet forumClient (computing)Server (computing)Web browserProxy serverNeuroinformatikComputer fileStructural loadReal-time operating systemView (database)Server (computing)Medical imagingUniform resource locatorWeb browserWeb applicationComputer animation
43:48
Software developerEmailView (database)Extension (kinesiology)Different (Kate Ryan album)Client (computing)MereologySource codeEmailGraphical user interfaceAddress spaceElectric generatorMetropolitan area networkData storage deviceDrag (physics)Row (database)MiniDisc
45:24
Drag (physics)Software developerDrop (liquid)Uniform resource locatorDigital filterGamma functionEmailFlagFormal languageControl flowData typeContent (media)Dependent and independent variablesView (database)MereologyMathematicsFilter <Stochastik>Web applicationCartesian coordinate systemSet (mathematics)Formal languageEmailGraphical user interfaceElectronic mailing listGreatest elementWeb browserSheaf (mathematics)SubsetWebsiteMoment (mathematics)Uniform resource locatorDebuggerControl flowPoint (geometry)Computer animation
48:14
Software developerEmailAddress spaceValidity (statistics)EmailLoginSystem administratorAddress spaceSign (mathematics)PasswordForm (programming)Server (computing)Web applicationoutputClient (computing)Open sourceMereologyCartesian coordinate systemFilter <Stochastik>
49:19
Software developerEmailInternet ExplorerServer (computing)FlagControl flowString (computer science)Query languageDependent and independent variablesContent (media)Data typeUniform resource locatorFormal languageProcess (computing)Filter <Stochastik>Control flowMultiplication signMereologyServer (computing)View (database)Web 2.0EmailString (computer science)Address spaceValidity (statistics)Field (computer science)System administratorWeb browserForm (programming)Client (computing)Query languageInformationParameter (computer programming)CASE <Informatik>Complete metric spaceComputer animation
50:47
Address spaceEmailPasswordSoftware developerService (economics)WebsiteWeb browserServer (computing)Address spaceServer (computing)Error messageoutputWeb browserValidity (statistics)Term (mathematics)Cartesian coordinate systemMultiplication signCASE <Informatik>System callEmailWebsiteConfiguration spaceMereologyProxy serverFront and back endsDebuggerSinc functionClient (computing)InformationPhysical systemAnalytic continuationSoftware developerVisualization (computer graphics)Food energyFigurate number
53:03
InformationSoftware developerEmailHost Identity ProtocolServer (computing)Gateway (telecommunications)AuthenticationComputerError messageComputer configurationWeb applicationEmailConnectivity (graph theory)Integrated development environmentWeb 2.0Gateway (telecommunications)Multiplication signCartesian coordinate systemNeuroinformatikAuthenticationConfiguration spaceSoftware testingFilter <Stochastik>Default (computer science)DataflowSoftwareComputer fileServer (computing)State observerProduct (business)Computer animation
55:33
Software developerTexture mappingWebsiteRevision controlRule of inferenceSound effectJSONComputer animation
56:40
Software developerExpressionComputerMathematicsServer (computing)Tablet computerWebsiteConnected spaceStress (mechanics)Configuration spaceLocal ringComputer fileData storage deviceWeb applicationJSONComputer animation
58:00
Software developerComputerFunction (mathematics)Heat transferNeuroinformatikWeb 2.0AuthorizationFunctional (mathematics)Integrated development environmentCartesian coordinate systemMultiplication signCore dump
59:20
Software developerExtension (kinesiology)Medical imagingExtension (kinesiology)SpacetimeInformationFlash memoryResultantComputer fileSet (mathematics)CAN busView (database)MetadataBand matrix
01:00:14
Software developerDifferent (Kate Ryan album)MereologyMultiplication signAuthorizationComputer animationXML
Transcript: English(auto-generated)
00:06
OK, good morning. Welcome to the final day of NDC. My name is Leonard, and I would like to talk to you about debugging tools that you can use with your web applications. I work at a very small software consultancy
00:23
in Finland, where, of course, we do consulting and development. But among other things, we also like to save projects. And how do you save projects? Well, we like to debug a lot.
00:43
And today, I would like to concentrate on web applications and how you might debug them. So I would like to say a few words about web debugging in general and then concentrate on two tools that I think are very useful in web debugging, the Chrome DevTools
01:06
and Fiddler. And so when talking about web debugging, there are two groups of technologies that are relevant.
01:21
One is the client-side technologies, HTML, CSS, and JavaScript that governs how your application looks and how it will behave and what it will do. And another important aspect is HTTP, or what your application communicates
01:40
with the back end or server. So I once had a colleague that was a very good software engineer, but also had the opinion that debugging is for weak programmers who don't know what they're doing.
02:01
And those that are good programmers don't need tools such as debuggers to catch their problems and mistakes. But then I did find out that what he does is add logging statements into his code
02:20
and then watch the logs of what the application did. And logging it this way is just another way of debugging your application. And I'm assuming you're here because you do some kind of web development, so you probably have many of you familiar with the alert statement.
02:41
So please raise your hands if you have used an alert statement to debug your web application. Almost everybody. The same goes for console.log, which is probably also very familiar for many of you. And these basic things are, I think,
03:01
what everybody tries out the first time when they hit some problems in their web applications if the problem concerns JavaScript. These are very simple, and they work if your application looks like where I'm coming from Finland. So this is the underground map for Helsinki,
03:22
which is very simple. If your application is very simple, then you can use alert to diagnose your problems. But if your application looks more like the London tube map, then maybe a couple of alerts will not do much good for diagnosing your problems.
03:44
So what do we want to debug when we think about web applications? There are three areas that might be interesting for web applications. The browser, the internet.
04:01
I use internet, but some kind of web or communication media, and the server, of course. And I'll just throw in some technologies there. So we will be concentrating on the browser and the internet and on the server side, you can see
04:21
that you can use a lot of technologies, but we will not be discussing that in this talk. And so it doesn't matter which one you prefer or you use. So when we talk about tools for web debugging,
04:40
let me ask how many of you use Microsoft technologies primarily for development? Most of the people. If we think of our development environment or IDEs, they usually cover some of the browser parts,
05:02
not maybe the whole one, and the server part. That's what we use to debug them. So what I'm going to talk about is the Chrome Developer Tools, which covers the whole browser and some of the internet, and then Fiddler, which kind of complements it. So it covers some of the browser
05:21
and most of the communication that our applications do. So let's talk about Chrome DevTools. And the first question probably that comes to mind is why Chrome DevTools? If you do web applications, you will probably
05:43
have used or will use most of the development tools that the different browsers offer, because there is one in IE, there is one in Firefox. Actually, for Firefox, there are, I think, several. And then there is the Chrome DevTools. So a DevTool you should use because it
06:04
helps you understand how your application is behaving, what it is doing, and if there are any problems, you can diagnose those problems. So why Chrome and why not something else? I found the Chrome DevTools to be the most comprehensive
06:21
feature set. But if you are comfortable in something else, feel free to use that. The feature sets are about on par. What I do like about the Chrome DevTools is that it allows remote debugging. So if you have an Android device, a tablet or phone,
06:43
you can use your development computer and, on that, Chrome to debug a web application that is running on your Android device. And you only need a cable to connect the mobile device to the computer.
07:04
So web applications often behave differently on the actual devices that they do on a development computer. And this way, the Chrome DevTools offer the most coverage for covering everything
07:24
that you would want to debug. We will concentrate on features that debug JavaScript, HTML, CSS, and networks. But the Chrome DevTools is a very broad subject.
07:41
And there are many more things that we could investigate or look at. So let's get started with JavaScript. And the first thing with debugging or analyzing
08:01
your JavaScript is start from the console. So if you have Chrome DevTools, there is one tab there in the console. And probably everybody has seen it because if you have some errors in your application, they also show up in the console.
08:22
But you can enter any kind of JavaScript into the console, and it will be evaluated in the context of your page. So essentially, you could write JavaScript code that performs things, uses the libraries your page uses, uses the global variables your page uses,
08:43
and evaluate them real time. So it can be used to check on your application or to try out things to do in your application. But the console is also very powerful because if you are debugging your JavaScript and it stops at the breakpoint somewhere,
09:03
then in the console, you are at the exact same scope and environment as the code is at the breakpoint. So if there are closures, function scopes, or embedded scopes, the console has access to the same things.
09:20
And it can be very, very powerful to analyze variables, data structures at that exact point in your code. But of course, a console is just a console. And essentially, you want to see your source codes and what's possible with them.
09:41
So there is a place in the DevTools, the Sources tab, which will show you every single JavaScript source that your application has loaded at that point in time. It also shows any possible snippets that you have dynamically loaded.
10:02
These are snippets that were not in any static file that was served by the server, rather that were later added dynamically into the application's lifecycle. So what you can do in the Sources view is you can set breakpoints and then execution stops.
10:23
And then you can see the call stack and local variables. And you can add watches. You can step through. You can step out of, over, and into function calls. Essentially, it's the same kind of debugging experience that you would have on the development IDE
10:44
or on the server side. Even the shortcut keys, if you're used to them, are very similar to, for example, Visual Studio shortcuts. And many more IDEs use the same keys. Because of time constraint, I won't talk much about it,
11:03
also because it behaves much the same as a regular debugger. It's just for your JavaScript code. Instead, I want to show some interesting things and tools that are available beyond the basic debugging.
11:22
So these development tools in most of the browsers have evolved to a place that if you place a breakpoint and then go away from the page and come back, it will still remember your breakpoint. So if you want to debug startup code, you can put a breakpoint there, refresh your page.
11:42
And because the breakpoints are remembered, you can then step through the steps of your startup code. But I mentioned that the DevTools also shows snippets of dynamically loaded code. And if your page loads JavaScript dynamically later
12:01
during its lifecycle, adding breakpoints there can be sometimes very difficult. And there is an interesting JavaScript statement called Debugger, which you can add to your code. Here, it's added to the beginning of one function
12:22
that's written in TypeScript. It doesn't really matter. But if you have a developer tool open or a JavaScript debugger attached to the browser, whenever execution hits this statement, it will behave as if there was
12:41
an actual set breakpoint there. So if you have the dynamically loaded JavaScript that you are not able to get to before it's loaded, but you want to stop execution when it is being loaded, then if you add a debugger statement, it will stop execution there.
13:06
One note about this debugger statement is that you should remove it before you go to production. But if you minimize your JavaScript, that should take care of it. Another useful feature that is available in the DevTools
13:21
is one called Pretty Print. So if you open up a JavaScript library or maybe your own code that has been minimized, it will look like this. This is even not just one row. Sometimes it's just one very long row of code.
13:42
And it can be hard to debug without having to resort to tricks like changing the code to the one that is not minimized. But at the bottom of the window, there is a little button that you can press. It says Pretty Print if you hover over it.
14:02
And what it does, it will format the minimized code so that it will look like, again, more readable. Of course, minification would rename all your variables to A, B, C, D, and one letter long variables, but still you can see the structure.
14:21
And it's not just that you can see the structure, but now that you have formatted it, you can also work with this code as if this was the one that is in the page. So if you set breakpoints to the formatted code, it will stop there and you can step through it one line at a time of the formatted code.
14:41
And you don't have to worry about that originally. It was a minimized version of it. But of course, there are other ways to solve this minification problem if it's your own JavaScript library that you want to debug.
15:01
And the Chrome DevTools supports a feature called source maps. And what source maps are is that when you minimize your JavaScript code, if you have source map support in your minification process, it will add a .js.map file to the file system
15:22
and also a reference to that file into the JavaScript file. And the DevTools can then see or use this file to show you the original code of it. And you can use that to then debug your application.
15:43
It's like a debug information file only for JavaScript applications. And it can be inserted later on into the minified version if for example, you want to enable source maps for just a small duration of time while you investigate
16:03
and then you wanted to remove that. So these were the very quick overview of some of the JavaScript debugging features that are available in the Chrome DevTools.
16:21
But of course, a web application is more than just the JavaScript code and there can be all sorts of other problems that you want to investigate or debug. And some of those affected the structure of our pages or the HTML and the CSS.
16:44
Now the elements view of DevTools is probably also familiar for many of you. The left hand side will show the DOM tree how it looks like at the moment and you can make edits there as well.
17:02
And then the right side shows by default the styles or the CSS rules that apply to one of the selected elements. So and you can use check boxes to manipulate the styles and see how your page reacts in real time.
17:21
But this is probably what's available in most of the developer tools. But then there is a very useful little addition called mobile view. And I think it's very overlooked feature. It's available again as a small icon hidden somewhere on the toolbar.
17:42
And what it will do for your page is that if your page looks like this, so it's a page that's available on a desktop, then it will transform, mobile view, when activated will transform into something like this.
18:00
The page itself is now just a small part of the screen. And the mobile view will emulate the size of a mobile device. So you can see how a responsive webpage would look like. It has a list of devices.
18:23
These affect the user agent string and the screen size that will be used. You can also use set throttling. I'll get back to that in a minute. And then it shows the visible size of the page.
18:40
And you can also resize that to any size you want if you want to test different sizes. And the page, if you have added responsiveness to it, it will shrink and modify itself to fit into that area. And in fact, there is this dark gray area under it.
19:03
Now it extends downwards. But depending on your page, this dark gray area can be anywhere. Essentially it shows which way your content is scrollable through that device view. And if some webpages don't implement
19:23
proper mobile scaling, then those will look that they extend to other sizes. And if you zoom in, you can also see that it extends to other sizes. And what is I think a very great feature
19:42
of this mobile view is that whenever you click inside the visible page size, it will generate touch events instead of click events. So if you want to see how your page reacts to touch events, you can click inside there and drag or just click,
20:03
and it will actually be a touch event that your page will be getting. It's limited to a single touch point. So this doesn't replace mobile testing, especially if you rely on gestures or multiple touch points, but it can be a good shortcut.
20:24
And I said to talk about throttling. The throttling setting here allows you to set the speed at which Chrome will then load these webpages. So you can set a slow 2G speed or a medium 3G mobile app speed.
20:45
And then when you next time refresh or load something, it will be applied to the loading process. And I was asked not long ago, somebody asked, I have a picture on my webpage. It's 800 kilobytes in size.
21:01
Is that big or small? And well, it depends. You should put in some kind of speed, say if a 2G speed to be the worst thing that can happen. So if you are out of a good coverage area and then check how your page loads. And if you are satisfied with the results,
21:22
then the image is probably a good size. And if you just wait there until some content appears, then well, you know that people who will not be at the best mobile coverage area wouldn't see your page in the best possible way.
21:44
Beyond HTML and CSS, your web application probably uses other resources. I will just quickly show that there is a place in the DevTools you can look at all the resources
22:00
that your page uses. Be it images, fonts, scripts, style sheets, or other things like cookies or local storage. You can check everything here of what is loaded into your application.
22:24
If you remember the slide I showed earlier about what we are debugging, the Chrome tool was extending into the internet part. So it offers possibility to analyze the network behavior of our application.
22:44
If you go to the network tab and load a page, it will show by default all the different connections that are made by your page. They will also be displayed visually along the top side.
23:02
So you can see what kind of requests are happening at what time and how many of them are there, how long they are taking. And then you can check out the individual requests at the bottom. Every image and JavaScript reference
23:20
or CSS reference will show up here. When you are debugging your web application, probably what you are interested about are Ajax calls and you can filter what you see using the tools.
23:41
So if you are interested only in images or just JavaScript files, you can filter that. Most often I find myself just selecting the XHR option which will show these Ajax calls that page makes.
24:02
So if you select an individual request, then you can preview all the headers in the response or the request. And you can also look at a preview of the content if it's something like a JSON data.
24:21
I have talked with people who say that they find this network part sufficient to analyze the network part of their application. But I will talk about Fiddler in a moment and it allows a much more broader tool set
24:40
for analyzing the network part of your applications. But if it's a simple thing to check what requests are sent and received by your application, then this network tab can be sufficient. There are some other tools
25:01
that I will just mention them quickly. There's one called the Timeline which shows you an overview of where time is spent in your application like rendering and loading and how fast your page is being rendered, how it looks at different stages.
25:23
So this allows you to analyze different things about the page and how it behaves. Profiles is actually a profiling tool for profiling execution time and memory usage where time is spent in your page.
25:43
Which library eats the most CPU and so on. And then there is the audit tab that will help you analyze the loading phase of your page. It provides suggestions how to optimize the page loading.
26:06
It says combine CSS, combine JavaScript and so on. So it can be used to optimize the loading phase of your page. The dev tools is a big topic
26:22
and there are a lot of features. And there is also a good documentation and I recommend remembering the link for the documentation because every once in a while they make smaller or larger changes to the dev tools and some features might get moved around or renamed
26:41
and then it can be hard to find what you knew where it was before. And with that, let's move on to another tool and to another area. So the network communication area and talk about Fiddler.
27:05
As I mentioned before, there is a overlap between the area of what these tools can be used to and what they can be used to check on and debug.
27:21
And it can be sometimes difficult to know which one is the best for the use case. So here is a very, very quick comparison. Chrome dev tools is best used for a single session and by session, I mean a page load.
27:40
So if you load your page and then you analyze that, it's the best thing is to use a Chrome dev tools. Although there is a star there because it allows you to retain the previous page load information on the network tab but it gets pretty messy pretty fast
28:01
if you have many sessions. So I'm not really comfortable using it that way. If you have a single page application then the dev tools can be a great use, especially all the profiling tools to see how your application behaves as time progresses
28:22
because single page applications are not loaded too often. And if you want to concentrate on the client side technology part of the web application then the dev tools is something that should be used.
28:40
Fiddler on the other hand is good with multiple requests and if the problem you want to see is on the HTTP level, so on the network communication part of the application and we will see that there are a lot of tools in there as well. So what is Fiddler?
29:01
Is there anyone who has used Fiddler before? Everybody. Is there someone who considers himself an expert in Fiddler or is it just that you tried it or? Okay. But I probably shouldn't spend much time
29:20
that it's an HTTP proxy and why you want to use it. The normal way for a Fiddler is to be in the middle between your client and the web application and the client of course can be not just a browser, it can be anything that generates HTTP traffic.
29:43
And also it can be used to debug web sockets but we will not be concentrating on web sockets today only on the HTTP part. So because everyone has used it before
30:00
probably the basic user interface is very familiar to everyone. So the left hand side contains the sessions and then the right hand side will contain all the tools that we will be using. If you would go to, well for example, the NDC London website in your browser
30:22
and come back to Fiddler, you will see a lot of requests that were made. And maybe at first it's surprising even how many requests are made just to display a simple web page. Why would you want to capture all these sessions?
30:41
It's because they allow you to investigate the flow of your web application. And when using Fiddler, most of the time you shouldn't concentrate on any single request but rather how they happen, in what order and what information flows between them.
31:05
So if you look at the session list, it will provide a fast overview of what's happening in the application with the result code, protocol, host name and relative path of the requests all shown.
31:24
And it tries to be helpful by showing little icons and coloring all the requests for you depending on if it's interesting or not. Usually gray is not that interesting. So what kind of information can you get
31:42
out of all these sessions and how you can analyze them? So sessions on the left and then on the right hand side, there are many tools from which, let's talk about the inspectors first.
32:01
And these allow you to inspect different aspects of every single request. On the top side, you can see the request. These tools will analyze the request part and on the, okay, in a bigger view as well.
32:22
And then on the bottom is the response and tools to analyze the response. And let's quickly go through the inspector views. So these allow you to view different aspects
32:40
of the same request. You can view the HTTP headers. You can see a textual overview of what was sent back. The next view is a syntax highlighted view. This is an extension to Fiddler that you need to install separately. But after that, JavaScript files, CSS files,
33:03
HTML files will all be colorized or syntax highlighted to find different information. If you select a session with an image, you can preview that image or see some information about that one.
33:21
I haven't used the hex view in a while, but you could analyze the hex representation of the entire request. Web view is an interesting thing because it's actually a small browser window that will show you, for example, the HTML content.
33:42
But this browser window or view will only show you what's inside this single request. So it will not go out and fetch any CSS files or it will not run your JavaScript files. It just shows you the pure HTML.
34:01
So it doesn't look pretty, but you can check if everything is there, what you want to have there. Cookies allows you to view any cookies. Row view allows you to view the row HTTP request or response that was sent through the wire.
34:22
And if you are debugging your web applications that use external data sources, then if it's a JSON, it can show you a parsed JSON view in a tree-like fashion. And of course, the same true for XML.
34:41
So you can check what is being sent back to your application. Of course, these views are not very useful if the data is very big, but it can be used to look at smaller data or just know if your data actually parses to XML.
35:00
Besides inspectors, there's statistics that you can view. These are available besides inspectors and this will show different measurements for your webpage. And also, it doesn't visible on the slide,
35:21
but at the bottom, you can have some kind of graphs of how your page was loading and how it would have loaded if it was a slower connection and so on. So these are the basic tools that you use to view your sessions and analyze their content and how information flows through your application.
35:44
And this is the scenario that Fiddler is used most often. But let's now move on to another scenario where we will cut off the right part of this and let Fiddler be the server.
36:03
And you can ask, why would I want to do that? I once had a client, it's not a case that should be modeled after, so it's a bad case, but anyway, they had a single production environment and they wanted to develop a new client application
36:24
against that existing production environment while it was working live. So it was a bit tricky because you wouldn't want to send illegal requests to a production server or manipulate data in a production environment
36:43
because that's not really a good thing to do while you are developing something new. But we will check out this autoresponder feature of Fiddler that can be used to emulate the server side and can be programmed to send back requests
37:04
to the client without ever touching the actual server. So the autoresponder tool can be found in Fiddler and there are just three lines here,
37:20
but you can have hundreds of lines here so you can simulate many, many different kind of requests. The easiest way to have something autoresponded is to just take a session from the left side and drag and drop it into the autoresponder tool and then just enable the rules
37:42
and from that moment, whenever the same request is sent to Fiddler, it will just send back the same response as before and never let it go to the actual server. Now you can of course either modify or add new rules here and the rule editor,
38:05
if you enter a URL there, it will be an exact match, but it's actually a regular expression and you can customize it of what it will match and then you can select what you want the result to be and the result can be either an existing session
38:24
that you have recorded with Fiddler, so if you make one request to the server, you can set up that from that time on, every time the same URL is requested, the same response should be sent back. It can be a generic response,
38:43
like send back a 404 or a 200 okay response or you can also select a file from your local disk and have Fiddler send back that to the client essentially you could simulate an API
39:01
by having the response JSON files in a directory and then just mapping addresses to those files and Fiddler will send back these files and you can simulate an API that way to the clients and they will not know that they are not talking with an actual server.
39:22
Beyond this, you can also set a latency value per these requests and this can be used to test how your application would behave if it would be slow. I like to use it to test for example these nice spinners we put on webpages,
39:44
so if some data requests last 50 seconds, how will your page behave? Will it show some kind of indication of that or will it just sit there and do nothing? On a development machine it's usually an instant response and it's easy to forget that in the real world
40:03
it's not always an instant response. Now you can of course drag and drop these requests and set them up but it can be tedious especially if you have multiple sets of requests
40:20
that you would like to auto respond. So there is a way to save sessions in Fiddler and these are called web archives which are just a single file that has a selected amount of sessions inside stored and available for later use.
40:43
And why would you want to save these sessions? And how can you use that? One scenario is when you have no access to the actual server, be it because you don't want to have access to it or because you actually don't have access
41:01
from a certain IP address. I often work with clients that allow requests from certain IP addresses and of course our office IP addresses are allowed to request this information. But if I go somewhere else or go working remotely
41:21
and I don't have VPN then I also cannot access these services and I cannot download information from them but I can do in the office that I do these requests, save the results in these web archives and then I have the responses available for me anywhere I go and I can just simulate the server.
41:42
I can also save the traffic and analyze it later or maybe analyze it in another computer because sometimes problems arise on one computer that's not your development machine or somebody does something and you don't really know
42:02
what he does but it breaks the web application. You can save the traffic on one site or one computer and then analyze it somewhere else and you could also run an offline demo if you just click through your website
42:20
with Fiddler active, save everything and then you set it up to autorespond all those. Same things, you can then demonstrate basically anything without having access to the actual server. So if you select some sessions or you tell Fiddler to save all sessions,
42:42
you can save them into one file and then you can later either on your own computer or another computer load them up. If you load an archive, it will load all the sessions that are stored inside it into your session view so it will essentially look the same
43:01
as if you would have recorded it just now and then you can use all these sessions the same way you use your quote real-time sessions. You can drag and drop them into the different tools, you can analyze them, you can check them with the inspectors, it's the same thing.
43:22
So we go back to this image of how Fiddler was used in the most natural or normal way when it's in the middle. We saw how we can cut off the web application or the server part.
43:40
Let's now look at what happens when there is actually no browser that is driving Fiddler. This tool that can be used to simulate requests is the Composer view and it allows you to set all the familiar parts of your request,
44:01
the HTTP method to use, the address to call, all the headers that will be sent. If it's a request that requires a body like a post or a put, you can specify that as well and it will also save these requests as you are doing them.
44:25
So how would you use something like this? We often get sent documentations for different APIs to call from an external source or external client
44:41
and then we need to develop a client that will call these APIs. And I like to use this Composer view to make these requests and send them to the server and see what it responds. And then when I have a better understanding of how it works, I can start coding the actual client.
45:02
Of course, some of you may have heard of a extension for, I think it's available at least for Chrome called Postman that can be used to generate, record, store, rest requests. It might be even better to use that but it's nothing stopping you from using this Composer view in Fiddler.
45:23
Actually, if you have existing sessions, you can just drag a session into the Composer view and it will take the request part of that session and pre-populate it into the Composer view which you can then use to make changes
45:42
and see how it will react to that. Let's talk about a feature in Fiddler called Filters that can be used to filter all the sessions and make minor changes to what is happening.
46:05
The filters are available in their own tab and you can tick a checkbox to enable them. And then the simplest use is probably to filter on the list of sessions that are shown
46:22
because sometimes the amount of traffic is very big and maybe you just want to look at traffic that goes to certain websites or it allows also to hide certain websites.
46:40
You can also show the sessions if something, or hide it if something is in the URL or you can start flagging them but also manipulating them like deleting request headers or setting request headers.
47:00
If you have ever tried to test an application of how it behaves when you change the language setting in your browser, you probably know that these settings are hidden under many clicks and dialogues inside the browsers and they are also moved around
47:20
sometimes, so in Chrome I think it's at least three dialogues deep at the moment and then you just have to select which language to prefer and which not to prefer and it's much faster to just set a simple accept language header and then check how your web application would respond to that.
47:44
And if you use request headers to other purposes it's very easy to manipulate them, remove them, add them or modify them through here. And then on the bottom part of filters
48:01
there is this breakpoint section which will turn Fiddler maybe closer to being a debugger actually because you can have breakpoints in there. And how do these breakpoints work and what can they be used for?
48:20
Let's imagine that we are creating a web application and we have added client-side validation to our forms. For example, our sign-in form which might look like this where you need to enter an email address and the password and then you can sign in.
48:40
What happens when you want to test how your server would respond to an illegal input? For example, if I want to enter the email address admin without anything else, of course the client-side validation will not allow us to press the login button and sign in.
49:01
There are ways to circumvent this like turn off client-side validation but what we could do instead is enter something that looks like an email address, admin.dd.dd but not press the login button yet. Instead go into the filters part of Fiddler
49:24
and turn on break request and post. What this will mean is that every time there is a post request, Fiddler will stop that request and not let it go to the server before we are allowed to do things with the request.
49:44
So there will be this red bar in the middle and if you look at the session view it will just show that there is no result yet. In this case, because it's a post request and because we send information to the server
50:00
we can use this web forms view to inspect the data that is in this request. There are no query string parameters here but in the body there are some members which correspond to the form fields of course and there is the email address we would have entered
50:21
and we can just modify that to read admin so the illegal value that the clients had validation didn't allow us to enter and then press run to completion. What will happen is then the modified request gets sent to the server and it will receive a value that is not an email address
50:41
in a field that should contain an email address and then we can see what is in the browser and it will render in this case two times the error message that it has to be a valid email address.
51:01
So essentially we can see that the server has validated the input but this method of breaking the requests and then manipulating them can be used to test how your server would react to different things that are happening while your application is running.
51:25
I use the term services to refer to the scenario where your browser calls your website and then your website calls some kind of service. If this call is happening over HTTP
51:42
then of course you can use Fiddler to also look at the information that is sent to this service. So in this case the request that Fiddler will be analyzing do not originate from any client browser. If you use for example IIS Express
52:05
which is very let's say normal scenario and if you use Visual Studio IIS Express will usually also pick up on the system proxy configuration
52:20
so if Fiddler is running when you start your application on the website part it will also automatically start sending the request through Fiddler if they are HTTP requests but since Fiddler is just a proxy it's usually not a problem to set up your website to use a proxy when it's making these service calls
52:44
and this way you can check on what's happening between the different parts of the back end and not just on the front end side of the application. Let's look at a few scenarios.
53:02
I was working with a client who needed to enrich the information, enrich the sessions with HTTP headers before they hit the actual web application adding headers there. So how it looked like is that our application
53:22
was deployed on the actual web server but there was this mysterious gateway computer that was handling authentication and what was happening is that when the request came in it went to the gateway first and then that would check if the user has already authenticated.
53:41
If not it would handle the authentication however it wanted to do it and then add a custom header, let's say x-myauth to the request and forward that request to our web application which would then check the HTTP header if it was authenticated and how it should react to that.
54:04
Of course this gateway computer and software it was running on was hidden from us and it would only be like this in the production environment. So when we were developing this application what would happen is by default
54:21
it wouldn't find this HTTP header and of course it wouldn't work. There are workarounds like you could add the configuration option that in certain environments you shouldn't read the HTTP header but behave as if it was something else but the problem with this approach is that it's then very hard to test the actual scenario
54:42
that will be deployed to the production environment where there will be an external component adding that header. Now if you use Fiddler it's very easy to add in the way in the filters tab
55:01
to add any header value into that session and so then it can be forwarded to the application and you essentially can test the same flow as would be happening in the production environment without needing to add a custom configuration options.
55:26
Another thing that many times gets hard to test is when you need to manipulate the hosts file to achieve something.
55:40
Maybe it's just simple that you want if somebody hits your website with the www prefix you want to forward them to the version without the three Ws or you want to do something else that you have to have multiple hosts and the usual way is to just edit the hosts file
56:02
which can get hard or slow you down but Fiddler actually has a host remapping feature which works much the same way as the hosts file but will only affect of course the sessions that go through Fiddler
56:22
and this way you can add and remove rules very fast and they will behave as if these were actually in the hosts file but they will just affect Fiddler alone.
56:42
Devices and device debugging. Sometimes we want to look at our website that is being developed, how it would look like on a phone or on a tablet while it's being developed and if you again use IIS Express or some other servers
57:03
sometimes the problem is that they will not allow access only from local host. Now IIS Express can be configured to allow connections not just from local host but I at least never remember where it stores the configuration file
57:20
let alone how to modify it without looking it up somewhere but it's relatively simple to have like using the hosts file to remap that host to local host so when your device connects to Fiddler
57:40
Fiddler will actually connect to local host and IIS Express will just allow it because it sees that the connection is coming from local host. So one last thing about Fiddler that I would like to talk about is what if your customer has a problem
58:02
with your web application? For example they want to do something and it just doesn't work and whenever you try it it works for you all the time. So you might think I want to run Fiddler maybe on their computer see what they are doing
58:20
I can save the session and then analyze it on my computer and then maybe I can see what my customer is doing that is breaking this application. There is a very small tool from the same author as Fiddler that is for very simple scenarios
58:40
allows traffic capturing and has a minimal UI and functionality. In the core of it it's the same engine as Fiddler it's just much more simple it doesn't need installation it can be started and then capture some sessions and then it can be saved. And then these saved sessions can be transferred
59:00
back to you and you can use the full Fiddler to analyze what was happening in that other environment. And it's I think much more user friendly to have a customer run a simple thing like this than the full Fiddler and then you have some problems explaining what is happening.
59:22
As I mentioned Fiddler has extensions and there are a lot of extensions one is this syntax view extension that I talked about there are extensions that will show you for example how much space is wasted in your image files by metadata and it will replace the images as they go through Fiddler
59:44
with an image that has a brick wall on the image so it changes the image but you can visually see that this image contains more than half of information that it was taken on this day with a flash setting of this one and the end result is that the image
01:00:01
contains a lot of information that is not needed by the users but takes up bandwidth. And there are many other extensions that you can download for free for Fiddler. If you really want to dig deep into Fiddler then I can recommend this book to you
01:00:21
it's written by Eric Lawrence who is also the author of the tool itself and it goes very deep into different parts of Fiddler. I don't know if we have time for any questions if you have no time for questions. All right, well you can come up to me
01:00:42
and ask if you want to ask something. Thank you for your attention.