PHP and MySQL Web Development - P97 ppsx

Although closed source, it is free for download from Zend’s site: http://www.zend.com This add-on works by optimizing the code produced by the runtime compilation of your script.. First,

452 Chapter 22 Using PHP and MySQL for Large Projects

Using Zend Products

Zend Technologies owns the (Open Source) PHP scripting engine for used in PHP 4 onward In addition to the basic engine, you can also download the Zend Optimizer This is a multi-pass optimizer that will optimize your code for you, and can increase the speed at which your scripts run from 40% to 100%.You will need PHP 4.0.2 or upward

to run the optimizer Although closed source, it is free for download from Zend’s site: http://www.zend.com

This add-on works by optimizing the code produced by the runtime compilation of your script Other Zend products include the Zend Studio, Zend Accelerator, Zend Encoder, and commercial support agreements

Testing

Reviewing and testing code is another basic point of software engineering that is often overlooked in Web development It’s easy enough to try running the system with two or three test cases, and then say, “yup, it works fine.”This is a commonly made mistake Ensure that you have extensively tested and reviewed several scenarios before making the project production ready

We suggest two approaches you can use to reduce the bug level of your code (You can never eliminate bugs altogether; but you can certainly eliminate or minimize most of them.)

First, adopt a practice of code review.This is the process in which another program-mer or team of programprogram-mers look at your code and suggest improvements.This type of analysis will often suggest:

n Errors you have missed

n Test cases you have not thought of

n Optimization

n Improvements in security

n Existing components you could use to improve a piece of code

n Additional functionality Even if you work alone, it can be a good thing to find a “code buddy” who is in the same situation and review code for each other

The second suggestion that we have is that you find testers for your Web applications who represent the end users of the product.The primary difference between Web appli-cations and desktop appliappli-cations is that anyone and everyone will use Web appliappli-cations You shouldn’t make assumptions that users will be familiar with computers.You can’t supply them with a thick manual or quick reference card.You have to instead make Web applications self-documenting and self-evident.You must think about the ways in which users will want to use your application Usability is absolutely paramount

453 Next

It can be really difficult to understand the problems that naive end users will encounter if you are an experienced programmer or Web surfer One way to address this

is to get testers who represent the typical user

One way we have done this in the past is to release Web applications on a beta-only basis.When you think you have the majority of the bugs out, publicize the application to

a small group of test users and get a low volume of traffic through the site Offer free services to the first 100 users in return for feedback about the site I guarantee you that they will come up with some combination of data or usage you have not thought of If you are building a Web site for a client company, they can often supply a good set of naive users by getting staff at their company to work through the site (This has the intrinsic benefit of increasing a client’s sense of ownership in a site.)

Further Reading

There is so much material to cover in this area—basically we are talking about the sci-ence of software engineering, about which many, many books have been written

A great book that explains the Web-site-as-document versus Web-site-as-application

dichotomy is Web Site Engineering: Beyond Web Page Design by Thomas A Powell Any

software engineering book you like will do as a backup

For information on version control, visit the CVS Web site:

http://www.cvshome.org There aren’t many books on version control (this is surprising given how important it

is!), but you can try either Open Source Development with CVS by Karl Franz Fogel, or the CVS Pocket Reference by Gregor N Purdy.

If you are looking for PHP components, IDEs, or documentation systems, try SourceForge:

http://sourceforge.net Many of the topics we have covered in this chapter are discussed in articles on Zend’s site.You might consider going there for more information on the subject.You might also consider downloading the optimizer from the site when you are there

http://www.zend.com

If you have found this chapter interesting, you might want to look at Extreme Programming, which is a software development methodology aimed at domains where requirements change frequently, such as Web development.The Web site for Extreme Programming is at

http://www.extremeprogramming.org

Next

In Chapter 23, “Debugging,” we will look at different types of programming errors, PHP error messages, and techniques for finding and gracefully handling errors

Debugging

THIS CHAPTER WILL DEAL WITH DEBUGGINGPHP scripts If you have been through some of the examples in the book or used PHP before, you will probably have devel-oped some debugging skills and techniques of your own As your projects get more complex, debugging can become more difficult Although your skills improve, the errors are more likely to involve multiple files, or interactions between the code of multiple people

Topics in this chapter include:

n Programming error types

n Syntax errors

n Runtime errors

n Logic errors

n Error messages

n Error levels

n Triggering your own errors

n Handling errors gracefully

n Remote debugging

Programming Errors

Regardless of which language you are using, there are three general types of types of program errors:

n Syntax errors

n Runtime errors Logic errors

456 Chapter 23 Debugging

We will look briefly at each before discussing some tactics for detecting, handling, avoid-ing, and solving errors

Syntax Errors

Languages have a set of rules called the syntax of a language, which statements must

fol-low in order to be valid.This applies to both natural languages, such as English, and pro-gramming languages, such as PHP If a statement does not follow the rules of a language,

it is said to have a syntax error Syntax errors are often also called parser errors when dis-cussing interpreted languages, such as PHP, or compiler errors when disdis-cussing compiled languages, such as C or Java

If we break the English language’s syntax rules, there is a pretty good chance that people will still know what we intended to say.This usually is not the case with pro-gramming languages If a script does not follow the rules of PHP’s syntax—if it contains syntax errors—the PHP parser will not be able to process some or all of it People are good at inferring information from partial or conflicting data Computers are not Among many other rules, the syntax of PHP requires that statements end with semi-colons, that strings be enclosed in quotes, and that parameters passed to functions be sep-arated with commas and enclosed in parentheses If we break these rules, our PHP script

is unlikely to work, and likely to generate an error message the first time we try to exe-cute it

One of PHP’s great strengths is the useful error messages that it provides when things

go wrong A PHP error message will usually tell you what went wrong, which file the error occurred in, and which line the error was found at

An error message resembles the following:

Parse error: parse error in

/home/book/public_html/chapter23/error.php on line 2

This error was produced by the following script:

<?php

$date = date(m.d.y');

?>

You can see that we are attempting to pass a string to the date()function but have accidentally missed the opening quote that would mark the beginning of the string Simple syntax errors such as this one are usually the easiest to find.We can make a simi-lar, but harder to find error by forgetting to terminate the string, as shown in this example:

<?php

$date = date('m.d.y);