Tools and Techniques for Faster Development

Editor's Notes

• #2: Hey everyone, my name is Majd Taby, I’m a software engineer at Facebook and I'll be showing you some tools and techniques that can hopefully speed up your development process.\n\nThe bulk of the talk will discuss debugging techniques. In any development cycle, you spend only a fraction of your time writing code. More time is spent thinking and designing and architecting the system, but I posit that even more time is spent debugging issues and inspecting the app in the process of building it. Debugging time is the low-hanging fruit of programmer efficiency. Sure, a new text editor that can save you 15 keystrokes over 1 hour of usage is cool, but it doesn't help speed up your development. Cutting down your daily debugging time from 1 hour to 30 minutes though, means a lower national divorce rate.\n
• #3: \n
• #4: \n
• #5: So, why am I standing here today? Well, a few months I wrote a blog post that walked through the webkit inspector and it got a very positive reception, and Alex asked me to come talk a bit more about it. So here I am, trying to summarize the 6,000+ words of the blog post, highlight the takeaways, talk about some new features, and expand on some techniques. In my opinion, debugging a web application without using the webkit inspector is like taking a knife to a gun fight. I'll try to summarize common problems and efficient solutions to them.\n\nYou can use the blog post as a reference point for most of the inspector features I’m going to discuss today.\n
• #6: The talk will be split in two parts. The first will discuss debugging techniques and an analysis of often overlooked features and why they’re useful, then we’ll talk about some tools and workflow improvements that will hopefully increase your efficiency.\n
• #7: The talk will be split in two parts. The first will discuss debugging techniques and an analysis of often overlooked features and why they’re useful, then we’ll talk about some tools and workflow improvements that will hopefully increase your efficiency.\n
• #8: Debugging on the web can be split into four main parts: Debugging the DOM (both hierarchy and CSS), JavaScript, Network, and Performance. They follow the general app development process. First you get something on screen, then you give it some behavior, then you link it to a backend, then you make sure it’s fast.\n
• #9: Debugging on the web can be split into four main parts: Debugging the DOM (both hierarchy and CSS), JavaScript, Network, and Performance. They follow the general app development process. First you get something on screen, then you give it some behavior, then you link it to a backend, then you make sure it’s fast.\n
• #10: Debugging on the web can be split into four main parts: Debugging the DOM (both hierarchy and CSS), JavaScript, Network, and Performance. They follow the general app development process. First you get something on screen, then you give it some behavior, then you link it to a backend, then you make sure it’s fast.\n
• #11: Debugging on the web can be split into four main parts: Debugging the DOM (both hierarchy and CSS), JavaScript, Network, and Performance. They follow the general app development process. First you get something on screen, then you give it some behavior, then you link it to a backend, then you make sure it’s fast.\n
• #12: Before we start though, there are a few settings which may be of interest for you\n
• #13: Settings are accessible via the gear icon in the bottom left of the inspector. The first one I recommend enabling is Dock to right. This works great when you’re on a widescreen monitor since you are more constrained vertically than horizontally.\n\nUnless you’re debugging cache, you probably want to save yourself the headache and disable it too.\n\nEmulate touch events is one of my favourite additions recently. Instead of sending mouse events, it sends their touch equivalents. So touchstart intsead of mousedown, and touchend instead of mouseup. I only wish they’d add some sort of multi-touch support too. On a similar note, Override device metrics is great when you’re building a mobile web app and want to test what the app/site look like in their native resolution.\n
• #14: Settings are accessible via the gear icon in the bottom left of the inspector. The first one I recommend enabling is Dock to right. This works great when you’re on a widescreen monitor since you are more constrained vertically than horizontally.\n\nUnless you’re debugging cache, you probably want to save yourself the headache and disable it too.\n\nEmulate touch events is one of my favourite additions recently. Instead of sending mouse events, it sends their touch equivalents. So touchstart intsead of mousedown, and touchend instead of mouseup. I only wish they’d add some sort of multi-touch support too. On a similar note, Override device metrics is great when you’re building a mobile web app and want to test what the app/site look like in their native resolution.\n
• #15: Settings are accessible via the gear icon in the bottom left of the inspector. The first one I recommend enabling is Dock to right. This works great when you’re on a widescreen monitor since you are more constrained vertically than horizontally.\n\nUnless you’re debugging cache, you probably want to save yourself the headache and disable it too.\n\nEmulate touch events is one of my favourite additions recently. Instead of sending mouse events, it sends their touch equivalents. So touchstart intsead of mousedown, and touchend instead of mouseup. I only wish they’d add some sort of multi-touch support too. On a similar note, Override device metrics is great when you’re building a mobile web app and want to test what the app/site look like in their native resolution.\n
• #16: Settings are accessible via the gear icon in the bottom left of the inspector. The first one I recommend enabling is Dock to right. This works great when you’re on a widescreen monitor since you are more constrained vertically than horizontally.\n\nUnless you’re debugging cache, you probably want to save yourself the headache and disable it too.\n\nEmulate touch events is one of my favourite additions recently. Instead of sending mouse events, it sends their touch equivalents. So touchstart intsead of mousedown, and touchend instead of mouseup. I only wish they’d add some sort of multi-touch support too. On a similar note, Override device metrics is great when you’re building a mobile web app and want to test what the app/site look like in their native resolution.\n
• #17: Settings are accessible via the gear icon in the bottom left of the inspector. The first one I recommend enabling is Dock to right. This works great when you’re on a widescreen monitor since you are more constrained vertically than horizontally.\n\nUnless you’re debugging cache, you probably want to save yourself the headache and disable it too.\n\nEmulate touch events is one of my favourite additions recently. Instead of sending mouse events, it sends their touch equivalents. So touchstart intsead of mousedown, and touchend instead of mouseup. I only wish they’d add some sort of multi-touch support too. On a similar note, Override device metrics is great when you’re building a mobile web app and want to test what the app/site look like in their native resolution.\n
• #18: So, moving on to the DOM\n
• #19: The Elements panel is where you do your DOM debugging. It’s split up into three parts: the dom inspector, css editor, and the element properties. Let’s go over them\n
• #20: The Elements panel is where you do your DOM debugging. It’s split up into three parts: the dom inspector, css editor, and the element properties. Let’s go over them\n
• #21: The Elements panel is where you do your DOM debugging. It’s split up into three parts: the dom inspector, css editor, and the element properties. Let’s go over them\n
• #22: The Elements panel is where you do your DOM debugging. It’s split up into three parts: the dom inspector, css editor, and the element properties. Let’s go over them\n
• #23: The Elements panel is where you do your DOM debugging. It’s split up into three parts: the dom inspector, css editor, and the element properties. Let’s go over them\n
• #24: The Elements panel is where you do your DOM debugging. It’s split up into three parts: the dom inspector, css editor, and the element properties. Let’s go over them\n
• #25: The Elements panel is where you do your DOM debugging. It’s split up into three parts: the dom inspector, css editor, and the element properties. Let’s go over them\n
• #26: The Elements panel is where you do your DOM debugging. It’s split up into three parts: the dom inspector, css editor, and the element properties. Let’s go over them\n
• #27: The Elements panel is where you do your DOM debugging. It’s split up into three parts: the dom inspector, css editor, and the element properties. Let’s go over them\n
• #28: The Elements panel is where you do your DOM debugging. It’s split up into three parts: the dom inspector, css editor, and the element properties. Let’s go over them\n
• #29: The two main features of interest in the dom inspector are the ability to rearrange nodes and edit attributes. Here’s how they work\n
• #30: The two main features of interest in the dom inspector are the ability to rearrange nodes and edit attributes. Here’s how they work\n
• #31: \n
• #32: The CSS Editor is one of my favorite features. It allows you to rapidly fix problems, see them fixed, and then apply the styles. I want to highlight the number editor, color picker and pseudo selectors for this talk though\n
• #33: The CSS Editor is one of my favorite features. It allows you to rapidly fix problems, see them fixed, and then apply the styles. I want to highlight the number editor, color picker and pseudo selectors for this talk though\n
• #34: The CSS Editor is one of my favorite features. It allows you to rapidly fix problems, see them fixed, and then apply the styles. I want to highlight the number editor, color picker and pseudo selectors for this talk though\n
• #35: \n
• #36: \n
• #37: One last tip before we move on, $0...$9 represent a history of nodes you’ve selected\n
• #38: \n
• #39: Metrics and event listeners are also really handy, especially when you’re trying to fix positioning or event bugs.\n
• #40: Metrics and event listeners are also really handy, especially when you’re trying to fix positioning or event bugs.\n
• #41: \n
• #42: \n
• #43: \n
• #44: So you’ve got your UI looking bright and shiny, but your behavior is messed up.\n
• #45: The Sources panel (née Scripts) is going to be your new best friend. It includes a file browser, code editor, tab support, breakpoints, watch expressions, and call stacks.\n
• #46: \n
• #47: \n
• #48: \n
• #49: \n
• #50: \n
• #51: \n
• #52: \n
• #53: \n
• #54: Now that it’s responding properly, let’s talk about the network.\n
• #55: Waterfall is a term used to describe the cascading nature of network requests. Each request incurs a latency hit, then a download hit. You want to minimize the number of requests your app has to make. The steeper your waterfall, the less people have to wait to use your app, and well all know startup perf has dramatic impacts on engagement and retention!\n
• #56: It’s important to note, 3G is a high latency, high bandwidth network, so optimize for round trips, not download size\n
• #57: The inspector tries to help you out here by laying out the waterfall visually, separating latency and download time, and providing some HTTP introspection as wells\n
• #58: Note the blue line. That line needs to be pushed as far left as you can. It’s the line that fires the DOMContentLoaded event which means that JS has finished downloading, and you’re ready to bring your app to life\n
• #59: Now, as you’re building your app, you’ll probably end up making some extra HTTP requests. Clicking on any request in the sidebar will show you a list of all the request and response headers and lets you preview the response if it was JSON. You no longer need to install a shitty java app or an unreadable CLI to inspect your network!\n
• #60: DOM’s done, JavaScript is working, and XHRs are firing. You’re still not done yet. As your animation runs, you notice glitches. Things are slogging along instead of sliding. This is where you start analyzing your performance (which you should’ve been doing all along anyway)\n
• #61: They ran a test where they flickered a screen between black and white and they progressively increased the frequency of the flickr. At about 60 FPS, the eye stopped perceiving the flickr, and the screen appeared to be gray. This suggests that for anything that moves on your page to appear smooth and continuous, it needs to run at 60 FPS. So how do we speed up the process of finding out why your animations are running < 60 FPS?\n
• #62: The Timeline panel was recently updated with a new “Frames” feature. Previously, the Timeline would only show you a history of what happened and how long it took, but you had to infer that it was causing a delay, and you didn’t know how much. A frame in this context, is a single visual refresh. In other words, you make a change to the background color, the browser applies that to the layer tree, and when the screen has finished rendering, then you get a chance to do more work. \n
• #63: If you notice on the top right, the timeline panel includes helpful guildes to show you when a frame (represented by a blank rectangle), is taking 60 fps. Ideally, all your frames will be on or below that line. If they’re not, you can click-drag in the visualization to narrow it down to a single frame, and can actually inspect exactly what’s happening during that time.\n
• #64: One other problem to keep in mind when making sure your app feels responsive is to track its memory usage. The greater JS community has largely neglected memory perf since web sites never really got to the level of complexity where it became a problem. That’s not true anymore, and the more object allocation you go through, the more GC cycles you go through, and the more glitches you see in your animation.\n
• #65: This is an almost ideal graph of what you should strive to make your memory profile look like. It’s a sawtooth function, where a GC cycle will clear all unused memory. Notice how the troughs here in the graph have a slight upward slope. That indicates a memory leak: As the GC runs, it doesn’t get back to the previous run, and the area under the graph grows.\n
• #66: To Recap...\n
• #67: To Recap...\n
• #68: To Recap...\n
• #69: To Recap...\n
• #70: You may be wondering, can I use all this awesomeness for my mobile web apps? Well, The answer is yes and no\n
• #71: Compare what we have available for us on the desktop\n
• #72: \n
• #73: to what we have on mobile\n
• #74: The dreaded iOS console. Utterly unhelpful. No lines, no actual error, no help at all\n
• #75: Then there’s weinre. It doesn’t include the “Sources” panel, and it includes a very old version of the insepctor\n
• #76: Then there’s iWebInspector. This one is better, but the tools are still very outdated, and every time you refresh the page, you need to reconnect.\n
• #77: clearly, mobile web debugging sucks\n
• #78: however, very recently a few better solutions have come up\n
• #79: The WebKit project recently announced support for the remote inspector protocol, and Chrome for Android was the first mobile browser to support it. This is the ideal solution: Real tools, running on real hardware, in realtime. The problem is it takes some setup to get going\n
• #80: iOS 6’s MobileSafari which hasn’t yet come out also supports the remote inspector. This one is much easier to get to, available as a menu option in the Develop menu (so I’ve read online)\n
• #81: Finally, one of my coworkers, Thomas Aylott recently open sourced a little app he’s been working on which acts as a wrapper around the remote inspector protocol\n
• #82: Here’s what it looks like: essentially the tools, with a sidebar\n
• #83: The main advantages this app provides are automatic device discovery, so you don’t need to run any commands in Terminal nor dig through menus, the latest dev tools, and on-device development: Refresh the tools, the page on the device refreshes.\n
• #84: The main advantages this app provides are automatic device discovery, so you don’t need to run any commands in Terminal nor dig through menus, the latest dev tools, and on-device development: Refresh the tools, the page on the device refreshes.\n
• #85: The main advantages this app provides are automatic device discovery, so you don’t need to run any commands in Terminal nor dig through menus, the latest dev tools, and on-device development: Refresh the tools, the page on the device refreshes.\n
• #86: The main advantages this app provides are automatic device discovery, so you don’t need to run any commands in Terminal nor dig through menus, the latest dev tools, and on-device development: Refresh the tools, the page on the device refreshes.\n
• #87: \n
• #88: So that concludes the first and main part of the talk. Now I’m going to quickly go through some tools that I’ve found to be really helpful while doing front-end JS work\n
• #89: First up is iTerm 2.0 I love this mainly for its splits feature, which i depend on. It support cmd-clicking on file names to open them in their respective apps, and supports a better search feature than the built-in Terminal app.\n
• #90: First up is iTerm 2.0 I love this mainly for its splits feature, which i depend on. It support cmd-clicking on file names to open them in their respective apps, and supports a better search feature than the built-in Terminal app.\n
• #91: First up is iTerm 2.0 I love this mainly for its splits feature, which i depend on. It support cmd-clicking on file names to open them in their respective apps, and supports a better search feature than the built-in Terminal app.\n
• #92: First up is iTerm 2.0 I love this mainly for its splits feature, which i depend on. It support cmd-clicking on file names to open them in their respective apps, and supports a better search feature than the built-in Terminal app.\n
• #93: here’s what a split terminal looks like. This is great when you have a build script running and want to monitor its output, while operating on the app. It works much nicer in a widescreen monitor.\n
• #94: Just a quick note. This is one of my favourite aliases ever. It graphically shows you your the git history of any branch. Here’s what it looks like\n
• #95: I love it because it shows me instantly what the state of my branches is, who’s been active, and how stale my repo is. I use this command 10-15 times a day and can’t live without it\n
• #96: \n
• #97: GitX is one of many git GUIs. There’s one and only one reason why I love working with GitX and is a stable member of my toolbet, and that’s line-by-line committing. This is something that you’ve always been able to do with git, but it’s hidden behind one of the most terrible CLI’s ever conceived. Another neat feature is that it makes context around your diffs easier to see. It’s a free app, and those two features mean that whenever I’m about to commit something bigger than a 2-3 line diff, I quickly pop into gitx\n
• #98: GitX is one of many git GUIs. There’s one and only one reason why I love working with GitX and is a stable member of my toolbet, and that’s line-by-line committing. This is something that you’ve always been able to do with git, but it’s hidden behind one of the most terrible CLI’s ever conceived. Another neat feature is that it makes context around your diffs easier to see. It’s a free app, and those two features mean that whenever I’m about to commit something bigger than a 2-3 line diff, I quickly pop into gitx\n
• #99: GitX is one of many git GUIs. There’s one and only one reason why I love working with GitX and is a stable member of my toolbet, and that’s line-by-line committing. This is something that you’ve always been able to do with git, but it’s hidden behind one of the most terrible CLI’s ever conceived. Another neat feature is that it makes context around your diffs easier to see. It’s a free app, and those two features mean that whenever I’m about to commit something bigger than a 2-3 line diff, I quickly pop into gitx\n
• #100: this is what the main interface looks like\n
• #101: this is the context slider. As you drag it, more or less of code surrounding your diffs will be shown.\n
• #102: This is the Unstages Changes view. Note how it’s split into two chunks already with their own “Stage” and “Discard” buttons. When I click on a single line, you notice it, too, gets its own Stage button\n
• #103: After I click on stage, notice how index.html appears both in Unstaged Changes and Staged changes. By the way, to unstage changes you just drag the file to the unstaged changes list. No need to remember reset vs checkout vs god-knows-wtf-linus-was-thinking\n
• #104: Once you commit, you get the hash and notice that index.html is still unstaged. This model is fantastic for breaking up unrelated changes into their own commits which can be reverted easily. Another nice side-benefit is that commit messages are much more contextual so ‘git blame’ becomes much more useful\n
• #105: \n
• #106: Finally, I’ve been using this tool for over 2 years now and it’s fantastic. It’s called xScope, from the folks at icon factory, and the two main features I constantly use are the ruler and the loupe.\n
• #107: Finally, I’ve been using this tool for over 2 years now and it’s fantastic. It’s called xScope, from the folks at icon factory, and the two main features I constantly use are the ruler and the loupe.\n
• #108: Finally, I’ve been using this tool for over 2 years now and it’s fantastic. It’s called xScope, from the folks at icon factory, and the two main features I constantly use are the ruler and the loupe.\n
• #109: Finally, I’ve been using this tool for over 2 years now and it’s fantastic. It’s called xScope, from the folks at icon factory, and the two main features I constantly use are the ruler and the loupe.\n
• #110: The loupe acts as a magnifying glass, allowing you to position and count pixels and pick up colors, and the ruler complements it really nicely and allows you to align elements and measure dimensions. Saves a lot of time.\n
• #111: \n
• #112: \n
• #113: \n
• #114: \n