Home > Programming > Ideas on debugging your live website

Ideas on debugging your live website

October 16th, 2007 admin Leave a comment Go to comments

I write this article to share my experience that I had in fixing bugs on live site. With users live on your site and transactions worth 100s of dollars ready to be executed, you cannot risk down time to fix the bug and get live again. So what do you do? You definitely cannot keep that bug there; you cannot down the site; you cannot disable the feature that has the bug? What would you do?

Here are some ideas that I have been using to identify and fix issues on live site:

1. Make extensive use of HTML Comments

The best way to debug is to output statements or data contained in variables while execution; but you dont want the debug statements to be visible to your live users. In this case make extensive use of HTML comments. Instead of directly outputting to your browser, you should enclose that output within a HTML comment tag

Once you have made necessary additions to your code and uploaded your script, you can check and validate your debug statements by viewing the source of the HTML output.



2. Log statements to a Database

Another way to debug your App is to log debug messages to a database. A problem with this approach is that debug statements of all users will start to appear in the database. To resolve this problem you should create a separate file that will create a cookie on your machine.

Your script should check for the existence of the cookie and if it exists should record the statements in the database.

Ideas like these should actually be part of the top level architecture of the site and should be implemented at the design time itself.

3. Create a copy of the script

This is a very easy way of debuging, but not always feasible when you have a workflow to test. Reserve this method for testing a page that is not part of a workflow i.e. the existance of which does not depend on the data being passed from another page. Though you can hard code the data being passed, but I would recommend to reserve this method to debug standalone pages.

Additional notes

Lastly, write code that you can maintain later. It is easy to get the code working initially during development, but when your client wants you to maintain that code base, that is where the problem starts if the code has not been written from the perspective of maintenance.

Leave behind comments if you have other ideas as well and would want to share.

Categories: Programming Tags:

Warning: session_start(): Cannot send session cookie - headers already sent by (output started at /home/sunilb/www.sunilb.com/wp-content/plugins/all-in-one-seo-pack/aioseop.class.php:245) in /home/sunilb/www.sunilb.com/wp-content/plugins/mycaptcha/MyCaptcha.php on line 41

Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /home/sunilb/www.sunilb.com/wp-content/plugins/all-in-one-seo-pack/aioseop.class.php:245) in /home/sunilb/www.sunilb.com/wp-content/plugins/mycaptcha/MyCaptcha.php on line 41
  1. eed
    June 30th, 2009 at 03:39 | #1

    firePHP is nice tool,

  2. Yukti Khanna (Vig)
    July 21st, 2009 at 22:55 | #2

    Nice article Sunil ji
    Heres something that I follow:

    For PHP developers $_SERVER['REMOTE_ADDR'] can be used. The logic is, to print anything that you wish to ..( be it a dynamic value or a hardcoded alert “in if condition” / “in else”) under your ip address check.
    That is, if this value matches your IP Adress then print desired stuff on screen.
    But remember to remove the condition and prints after done ..

    thanks !!

  1. No trackbacks yet.
Enter this code to leave comment (Sorry, but bots get me crazy :) )