Debugging techniques for Web development 1 – Using the right tools

Over the years I’ve become a bit of a debugging freak.

I wish I was able to write code that works straightaway, but for some reason, I just love programming by trial and error. So I go through many cycles before it’s just right, and without some ways to shorten these cycles, programming would be a nightmare for me.

So I would like to share a few techniques gathered over time, which hopefully will help you as is, or will inspire you to develop a debugger’s mindset. Be it in Web programming or any scripting environment.

The techniques will be explained in several blog posts, which will be about

  1. Using the right tools – to do complex things in a simple way rather than the other way round…
  2. Configuring your environment for better productivity – if you don’t make yourself at home in your own codebase, who will?
  3. On-the-fly coding instead of edit/reload/edit/reload – coz’ life is to short to spend it waiting for your script to reinitialize.

Let’s then start with the first piece of advice, which I would assume is the easiest to apply

1. Using the right tools

To do complex things in a simple way rather than the other way round…

In the past, I’ve sometimes been doing stuff in a convoluted fashion because I was not aware that certain tools existed, which could have made things so much easier. This is a general principle, and so it’s mostly a question of discussion with the community to figure out which tools are going to help you in your particular project.

Let me however give a few tips specific for Web development.

Installing a [L/W]AMP stack

Unless you’re just writing 2-3 web pages, please do not do Web development by loading the files as is. Put yourself in an environment similar to the final deployment stage, by running all the pages through a proper webserver.

One reason for that is that Ajax call will likely not work from local pages due to the X-domain policy. You may also face issues of links working in your development environment but not on the server, or vice versa. And of course, PHP scripts and .htaccess stuff (i.e. Apache configs per directory) will definitely not run if you call them directly rather than through a webserver…

So – on Linux systems, the webserver  is usually provided out of the box by LAMP (Linux/Apache/MySQL/PHP), and on windows, you can install EasyPHP which provides these with minimal hassle.

Javascript

I really fell in love with JS the day I discovered the Chrome debugger. Obviously it requires using Chrome, which I fail to see a reason to do without – see table on the side (source: Wikipedia).

ScreenClip3

The debugger is invoked by pressing CTRL-SH-J, and will appear at the bottom of the page. It can be detached as a separate window, which can be desirable if your HTML layout is involved.

The debugger features a set of terrific features – see the Chrome Developer Tools page for more details.

One of them is the console (press ESC to open/close it, whilst the debugger is on). The console allows you to evaluate expressions on the fly after the page has loaded. This is extremely useful if you want to invoke functions defined in your script, or modify the state of global variables . It is also very cool for CSS experiments (see CSS debugging paragraph below).

The console is also terrific for leaving trails of your code’s execution using console.log, without impacting the HTML layout, like this

ScreenClip

As for modifying variables, this goes beyond just  numbers / strings. In a future issue I intend to discuss that more in detail, especially the use of the console to modify and test callbacks / event functions without having to reload the page. As a preview, let me mention the use of the console to modify DOM objects.

Say, for instance that you are trying to make your website look better by changing the css. Reloading your page might be fine if it’s a lightweight one, but as soon as your project starts growing, your main page is bound to load tons of stuff at startup. This might make it a pain to fine tune styles / colors / dimensions.

Assuming you are using JQuery, you can easily change attributes using the Chrome debugger. There are 2 methods

  • go on the part of the page you want to modify, right-click and choose ‘Inspect element’. This will open up the debugger, and will open a window on the right with all css attributes. You can modify any of these manually.
  • my preferred method is to go to the console, and do something like this
$("#someid").css( { width : '10px', color : 'white' } )
$("#somepopup").show().css( /* ... */ )

This will modify the object on-the-fly. Once you’ve sorted out your settings, you can integrate it in your script for the next time you reload your page.

PHP

The more advanced you are in PHP, the more likely you are to use frameworks which tend to provide extensive debugging information. One of these is Symfony, which I find very impressive, but personally way over-the-top for my usage. I therefore limit myself to CodeIgniter + Datamapper, which are fine, but do not have embedded debugging features.

However – debugging is made extremely simple using Xdebug. It is an apache extension that is part of the Zend framework, but can be installed on its own. In my case, it came bundled with EasyPHP, and it turned out that my editor Notepad++ has a simple plugin DBGp which communicates with Xdebug and allows debugging PHP scripts as easily as you would do it in Javascript in the Chrome debugger.

The setup consists of downloading Notepad++ and the DBGp plugin, and moving the plugin to the right Notepad++ folder. The Notepad++ settings require you to specify the server (typically this would be localhost), and turn the debugger on by going to the ‘DBGp / debugger’ menu, which will make the debugger appear in the bottom part of Notepad++.

On the server side you will need to enable Xdebug, which is done in the php.ini with something that in my case was this

zend_extension = "${path}\php\php546x130302144954\php_xdebug-2.2.1-5.4-vc9.dll"
xdebug.default_enable=0
xdebug.remote_enable=1
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_autostart = false

What then happens is that every time you load your page (i.e. by going to http://localhost/yourpage), it will invoke the debugger on Notepad++, which will start blinking. You will need to put breakpoints by pressing CTRL-F9 on a line of your scripts where you want to start stepping, and you can step the usual way (using the little buttons at the bottom left of the Notepad++ screen). It should look like this

ScreenClip2

MySQL

Working with databases can be a total nightmare without the proper tools. You need to be able to test your queries independently of your code, and I would recommend installing PHPMyAdmin, which comes bundled with EasyPHP or is easily installed on a LAMP stack (it’s all PHP based so requires no shell access to the server). Given that it is accessible through a web browser, this allows you to do basic tests or SQL operations from anywhere. It has a visual interface for many operations, including data modification, table creation, and even db synchronization.

A more powerful tool is MySQL workbench. The drawback is that it requires local installation on Windows, but the interface is less sluggish than what you would except from a web-based interface such as PHPMyAdmin.

Control versioning

Control versioning software allows you to track changes in software you are writing, by having the developer ‘committing’ changes when he deems they are worthy of being used in production. This then allows him to see differences in different versions of his scripts, which often helps to pinpoint the location of freshly introduced bugs.

Working on even small size projects without control versioning is a bit like driving with your eyes closed. If everything runs fine and you’re the only one on the road, it’s not an issue, but if there is any unexpected event, you’re heading for a crash.

Anyhow – installing control versioning is so simple that there is no excuse to do without.

I know git’s the most fashionable tool nowadays, but I happen to be using subversion which I find just fine.

The setup goes as follows

Server side – 2 possibilities (ok this might be confusing if the server is on your own machine)

  • Creating a local repository on your computer or any computer on your network. This is as simple as typing svnadmin create 'your_repository', then launching the server by doing svnserve -d -r 'c:\path\to\your_repository'.
  • Creating an account at CloudForge, for instance, which will host your code for free (but it is limited to a single user).

Client side

Once the server is running, you will need a client to access it, and modify the files. I like TortoiseSVN, which allows you to perform all kinds of operations from the Windows explorer.

The benefit of using a CVS system in a live environment such as a website is that you can do without FTP or SCP, and apply/rollback changes at a whim. In my case, I setup a batch script to ‘svn update’ my production server (through ssh). This means I can upgrade my production server without having to figure out what needs update or what not.

This does not prevent me from keeping external files (images / libraries) in separate directories which are ftp’ed once and for all, and can even be shared across different versions of my website by using (Linux filesystem) links.

Get a proper server

OK so unlike the other points, this one is not that easy to apply. People may not have the budget for an expensive setup, but I highly recommend getting server space with a shell access. I discovered Rackspace, which costs me 14£/month, for which I have a 512Mb ubuntu server with 20Gb RAM and root access. It took me less than an hour to install AMP / subversion, check out my repository, sync my db and have my website online as on my laptop. Just installing Ubuntu on a computer can sometimes take 45 minutes, whilst Rackspace provide preconfigured images which get installed in a minute.

Of course, you can do without, but having no shell access may mean that you can not use subversion to update your website, and you are at the mercy of any discrepancy between your home setup and the server (which at a typical provider will have an older version of PHP rather than a newer, resulting in some language idoms working at home and not on the server).

Given that you have root access, nothing refrains you from setting up several accounts and sharing the server with friends. Because of the root access, you can do the following

  • setup a subversion server for free, which would probably cost you 5-10£/month if you went  for the premium solutions at Cloudforge, for instance.
  • setup an unlimited number of domains hosted on your server (Rackspace provide you with a control panel to edit DNS entries)
  • install a nodejs server, or Django, or upgrade to whichever version you want / need

Conclusion

Depending on your experience and your luck googling for some of the tools above, you may have things working out-of-the-box, or you may struggle and give up and miss out on some terrific productivity boosters.

Don’t hesitate to ask for help if you are facing issues!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s