Too often we make things difficult on ourselves. We don't take the time to learn our own tools. We do things the long and hard way, never realizing the various short cuts available to us. This is especially true of web development. I suspect way too many developers make small fixes, rebuild and retest, elongating their build/test cycles unnecessarily. Chrome Dev Tools have been around a long time and getting better every day, and yet I frequently find myself on teams with folks not taking advantage of it.
And yes there are similar tools for Firefox, Safari and even internet explorer, but to date, I've found myself most comfortable with chrome. So if you're on one of my teams, and you haven't spent a lot of time using Chrome Dev Tools, here's what I expect you to know:
Working with JavaScript? Use the Console
A few years ago, I used to add "debugger;" statements to debug javaScript in Internet Explorer. It wasn't pretty. Chrome's Dev tools give you everything you need to get your javaScript to work. If you rebuild your project to fix clientside javaScript issues, you're doing it wrong. If you write javaScript at all, you need to use the javaScript console. And by use it, I mean use if before, during and after you write JavaScript code.
Here are my tips for javaScript debugging with Chrome Dev Tools
- Add console.log statements generously. They make it a ton easier to see what's happening. Especially when asyncronous calls are made. Don't like having them in production code? Remove them with a pre-processor before deploying to production.
- Try out code in the console. Not sure the syntax of the code you're writing? Get it to run on a single line and run it in the console. This works especially well for testing to make sure you are using the correct jquery selectors.
- Make a copy of tempory data and inspect it later. Code ran with no errors but things still don't work? Assign values to global variables like "lastData" or "tempData" and inspect them after your code runs to see what happened. Maybe what you got isn't what you expected.
Eventually we'll get our javaScript code right, but until then, use the console.
Inspect Element for the Win
If we haven't been blessed with a design company throwing perfectly tested markup over the wall to the dev team, we're going to need to spend some time getting things to look right. And that means messing with CSS. When it comes to getting developers to maintain css files, you typically have a couple of options:
- Have them add inline styles to the markup.
- Have them add style tags to the markup pages themselves.
- Have them create their own override css file and mark all the rules that don't work !important!.
As daunting as it may seem to have to locate and edit a large complex set of style sheets, everything you need to figure out what and where to make changes is available in chrome dev tools. Here are my tips for working with CSS.
- Understand the space your divs take up. Right Click, Inspect Element. Scroll to the bottom of the styles tab to see the box (Or click on the computed tab). Margin, Border, Padding, Height and Width. If it's not right, there is a reason, but unless you understand the space your element is taking, good luck fixing it.
- Test out CSS changes in the browser. Use the style tab to toggle off CSS rules or add your own. Add inline styles to the markup, or edit the HTML directly if necessary. Get it right and then make the same changes in your source.
- Use Computed to learn where the style came from. The styles tab will tell you if a css rule is being applied or not, but instead of looking through every possible style, it's far easier to click on the computed tab and expand the property you care about. It will tell you where that style came from. Almost feels like you're a detective when you figure out where it originated.
There's a ton you can do click different elements and looking at their styles. You should be able to figure out exactly what changes need to be made before you apply them.
See what came over the wire on the Network Tab
The last super useful tool everyone should know is the network tab. I honestly prefer tools like Fiddler or Http Watch, but for 90% of cases, the network tab will give me what I'm looking for: What was sent to the server and what came back to the client.
Here are my tips for debugging client server communications:
- Look at posted values in the Headers tab. More and more I'm using complex user interfaces that are just facade's for hidden inputs. If you have a bug in your javaScript, it will be hard to tell what's going wrong unless you check exactly what data is being posted.
- Find your AJAX call and validate their payloads - Making async calls? Find out exactly what is being sent and received. Don't take anything for granted.
- Verify Cookies to make sure the right data is being sent across. The headers tab has what cookies are sent to the server, but you can see both incoming and outgoing cookies on the cookie tab. Either way, should give you enough info if your troubleshooting cookie related issues.
The network tool gives you a nice sanity check as to what is actually being sent between the client and server.
Sharpen the Saw
These are just the basics, but they are basics you'll need to master before getting to the hard stuff. Learn your tools and you'll be more efficient and proficient when developing. This goes way beyond browser tools and should be applied to all of your development tools.
Other areas for exploration
Lately I've been playing with Chrome canary and some of the advanced mobile emulation support it has. Previously I was using the Chrome Add on: Ripple Emulator, but find the support in canary is superior. I also have been playing with remote debugging and screen casting my phone's version of beta chrome. There's a lot of new features in Chrome that are worth looking at, if not tracking what's going on.
On the server side, I've been really enjoying using glimpse, a server side nuget add in for ASP.Net projects that gives you a chrome tools like feel to looking at things like routes and server configuration.