PHP and MySQL Web Development - P97 ppsx

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:

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 programmers 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 applications is that anyone and everyone will use Web applications.
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.
28 525x ch22 1/24/03 3:38 PM Page 452
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:

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:

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.

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

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.
28 525x ch22 1/24/03 3:38 PM Page 453
28 525x ch22 1/24/03 3:38 PM Page 454
23
Debugging
THIS CHAPTER WILL DEAL WITH DEBUGGING
PHP 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
Tr iggering 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
n
Logic errors
29 525x ch23 1/24/03 2:56 PM Page 455
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 discussing 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);
?>
29 525x ch23 1/24/03 2:56 PM Page 456