Master your debugger

I’ve met pretty big bunch of people during my studies and I’ve realized that many of them did not use debugger when problem had encountered. Not that it’s my business to tell anyone how to solve his bugs. Printing out variable dumps or debug messages can be pretty fast, but for extensive problem solving is debugger necessity which can save you hours.

Then I thought for a while and realized, that noone really teaches you how or why to use debugger. Not even at school which is really a shame. In this blogpost I’ll get through debuggers for web developers - in IDEs and in the browsers. Post is not about getting deep, but it provides useful links where you can get to know more. So let’s dive into it.


The basic concept of debugger is to pause execution of code in the very place you want at. The debugger always pauses before execution of code on line you selected. When you get there, you have couple of options which all debuggers provide by default:

And this is it. This is basically everything that debugger is. Couple of simple features that make printing out help messages to console pretty ancient. If you are still deciding whether to use advanced text editor (Sublime, Emacs) or IDE, debugger is one of the killing features which will make deciding one sided.

IDE debugging (by JetBrains)

To present debugger in IDE, I chose IDE by JetBrains as they provide IDEs for almost all popular languages related to web development. For standalone application development in C++ I encourage you to try Microsoft Visual Studio - Express Edition is free and it has one of the most advanced debugger I ever used.

I’m going to present two use cases. First is simpler scenario with local Ruby project developed in RubyMine. Then I’ll show something advanced with PHPStorm and remote development.


Debugging Ruby is pretty simple and it doesn’t matter whether it’s just your small script or complex Ruby on Rails application. First you need to place your breakpoints at places you want your code to be paused - clicking on the vertical bar left to your code will do the trick. Also CTRL+F8 is pretty handy shortcut for toggling breakpoint for line you’re currently at.

When you’re ready, start your application in debug mode (run - debug in menu, SHIFT+F10 as a keyboard shortcut and there’s also green bug icon next to the regular play icon in the toolbar). If you’re running the script, it should get there automatically. If you run Rails application, refresh the view which should trigger the breakpoint.

If you develop Rails project and run your debugger for the first time, RubyMine asks you to install debugger gem. This is mandatory and you can’t debug Rails application without it. It’s just one time thing so it won’t bother you again next time.

I’m not going to bother you with all the information when someone did it already better. Go and check RubyMine’s tutorial on how to use their debugger and use all the best features of it.


Debugging PHP is a bit harder than Ruby. First you have to set up xdebug extentsion on your PHP web server. There are many tutorials on the web how to install it (standalone, for LAMP, for WAMP..) so I won’t cover it in this tutorial. I recommend you to go visit official documentation and read through it.

When you are ready, let’s get to PHPStorm and setup everything else. As I said earlier, this part of tutorial will show you how to do debugging on remote server. Expecting that you enabled xdebug on that remote server, now you need to check PHPStorm settings whether they match settings on the server. The most important is listening port, everything else is up to you. You can find the setting in PHPStorm settings and filtering keyword xdebug.

Now some magic in the browser. JetBrains allows you to have debugging cookies which will tell IDE whether you want to debug or not. To allow debugging in your browser on selected domain, there are bookmarklets which you can add as bookmarks and run them when the site you want to debug is opened.

When everything is ready, in PHPStorm go to Run - Start listening PHP debug connections or just simply press green earpiece icon in the toolbar. Place your breakpoint now, go back to the browser and refresh the page. What you should see now is path mapping between your local files (e.g. /data/web/blog) and real path of files on the remote server (e.g. /usr/share/www/blog). You need to tell PHPStorm/Xdebug where it should look for source codes on the remote server. It probably already did path to index.php for you, all you need to do is do the same for the root of your project and for the any external libraries you want to have included in your debug sessions.

You’re done now and everything should work. I recommend you to check Xdebug installation guide for PHPStorm by JetBrains, which will lead you step by step if you still have any issues and these Ukrainian slides, which contain screenshot of every important view you will need to see and set up. JetBrains also recently made a blogpost and a screencast about debugging, I recommend you to check them as well.

Chrome Developer Tools

Google Chrome and its developer tools contain great tool for debugging JavaScript, CSS and HTML (with DOM manipulation). You can open developer tools by pressing F12, CTRL+SHIFT+I or via Inspect element option in context menu. Let’s split the features up a bit.


For HTML debugging, you’ll only use left side of elements tab. First, Inspect element option in context menu reveals hovered element in DOM tree. This DOM tree is real state of representation and differs with View source code. After you have selected element you want to work with, you can see all its ancestors in the status bar of developer tools (very bottom).

By right-clicking element in DevTools you get couple of handy options:

You can also drag'n'drop element anywhere in DOM and see how rearranging elements affect what browser renders.

To style your content, use right pane of elements tab. You can see what rules apply for selected elements, edit and create new styling options, force state of element to see how hovered version of it looks like etc. Developer tools provide autocomplete when you press CTRL+SPACE - when you go through the options, you can see the difference realtime, so even beginner can try new things and learn how they work.

Many I have not mentioned, but everything (with fancy gifs) is amazingly explained in the documentation of Chrome DevTools and you can check out my slides about developer tools from Webelement meetup.


Debugging javascript is very similar to what I mentioned earlier in IDE section. You’ve got the code which is being executed and you want to pause it.

First open your developer tools and switch to sources tab. There are three very important keyboard shortcuts I want you to know before we proceed, mostly because they bring IDE-like feeling when debugging:

Now when you open any file containing javascript, process is simple. Place your breakpoint on the specific line by clicking on the line number, refresh the page if needed and watch/play with your variables in the right pane of developer tools. You can find more about debugging javascript in the documentation (things such as event breakpoint, more handy shortcuts, pretty print of minified JS and more).

Taking one step further, going NodeJS

As you maybe thought, NodeJS is javascript too. So if Chrome DevTools are for frontend debugging, what to use for backend debugging? It’s DevTools again. Chrome’s developer tools are just a web app and you can get even to the state, where you use dev tools to debug dev tools. Nasty, huh?

Anyway, to debug NodeJS application you need to do two things:

When you’re ready, visit the page node inspector printed out and it will get attached to your running NodeJS instance. Place your breakpoints like you did in Chrome DevTools and wait until execution goes through them. Everything else is just the same. You can read more at node-inspector GitHub page.


I hope that if you haven’t used debugger yet, you’ll start now. And if you used debugger, you’ve learnt something new. There are plenty of tutorials on the web for each one of the debugger, so if you want to know more about any of them, Google them. If you had any issues or you want to know something more about part of the tutorial, leave the comment in the section below.