Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Book Reviews Books Media

PHP 5 in Practice 116

Michael J. Ross writes "Computer programming books come in all varieties, but there are at least four general categories: introductory texts, which typically have the lowest content per page; language references, which have become increasingly supplanted by online sources; "advanced" treatments, which are often a mishmash of errata-riddled articles; and "how-to" books, usually at the intermediate level, and sometimes presented as "cookbooks." It is that last category that has been growing in popularity, and for good reason. When an experienced software developer needs assistance, it is rarely for language syntax, but instead a desire to see how someone else solved a specific problem. For solutions using the PHP language, one source of information is PHP 5 in Practice." Read the rest of Michael's review.
PHP 5 in Practice
author Elliott White III and Jonathan D. Eisenhamer
pages 456
publisher Sams Publishing
rating 8
reviewer Michael J. Ross
ISBN 0672328887
summary One of the most meaty, immediately useful, and fluff-free PHP books available


The book was authored by Elliott White III and Jonathan D. Eisenhamer, and put out in July 2006 by Sams Publishing (an imprint of Pearson Education). Given today's standards of hefty technical books, this particular one is relatively light, weighing in at 456 pages, which are organized into an introduction, numerous chapters, and three appendices.

Its introduction is more interesting than that of most similar books, whose introductions usually consist of formatting conventions and explanations as to why the book was written — all such content providing little to no value to the impatient programmer facing a deadline, and invariably ignored (the content, that is, not the deadline).

White and Eisenhamer took a refreshingly different tack, and chose instead to explain their use of coding standards, comments and whitespace, braces and parentheses, PHP short tags, PHP mode, and other language considerations that are more useful than the typical rundown of somewhat childish icons used in other texts, such as light bulbs and red warning signs.

Switching to the other end of the book, we find three appendices. The first one briefly discusses issues one might face in migrating from PHP version 4 to 5. The second introduces the Standard PHP Library (SPL), and the objects related to its primary design pattern, the Iterator. The third appendix discusses what composes the bulk of output from my PHP programs: error messages. Seriously, this appendix is worth reading, if only for the suggestions as to what to look for when you encounter some of the most common PHP error messages.

The bulk of the book's material is divided into 20 chapters, which are themselves divided into two parts: PHP internals, and applications. The internals are: strings, numbers, time and date, variables, arrays, functions, classes and objects, and files and directories. Starting off with a discussion of strings, might seem odd to the neophyte programmer, but to the veteran who has had to learn several languages during their career, the choice makes a lot of sense. There must be countless developers out there who, being fluent in the C language and object-oriented concepts, jumped into writing their first C++ program, and had to hit the books for the first time when they wanted to do some non-array-based string handling.

The book's second part covers some of the most common applications in PHP programming: Web page creation (using XHTML and CSS), Web form handling, data validation and standardization, sessions and user tracking, Web services and other protocols, relational databases and other data storage methods, e-mail, XML, images, error reporting and debugging, and user authentication and encryption. That last chapter, in the next edition, should be relocated so that it precedes or follows the chapter on sessions and user tracking.

Many of the chapters begin with a "Quick Hits" section, which briefly summarizes how to perform many of the most common and essential tasks related to that chapter's topic. For instance, in the chapter covering the use of variables, this first section explains how to: check if a variable has no value or if it is empty (not synonymous in PHP), undefine a variable, cast it to a certain data type, and do the same thing for a value. There is one minor erratum that should be noted: On page 71, in the first "Quick Hit," it reads "a variable has bee. given a value." ("been"'s "n" ended too soon.)

Each section within the chapter briefly explains the problem domain, and then presents sample code to solve the given problem. The code itself is fairly well commented, and the variable names are adequately descriptive (unlike in some programming books, whose coding standards border on the criminal).

All in all, the book offers a lot of worthwhile solutions to a wide range of problems, and does so in a straightforward manner. It is for this reason that it is not evident as to why this particular PHP title has received so little notice. For instance, on Amazon.com, it has received only one reader review, as of this writing, and does not even make it into the top quarter million books ranked in sales by Amazon.com. It is a pity, because the book deserves much more attention.

Even though this book is to be recommended, and is packed with code and text that are well worth studying, it has one unmistakable weakness for which this writer can think of no adequate justification. The book contains almost no illustrations, even when they are clearly called for — in fact, especially in those cases. For instance, the section that shows how to generate a calendar, does not show a calendar! The code is present, but the sample output — which is what the poor reader would appreciate, to see the results of the code — is missing.

Granted, an absence of figures and screenshots might be understandable for the first part of the book, which covers the PHP language itself. But the second part, covering applications, has far too many unillustrated PHP scripts. These include sections focusing on drop-down menus, progress bars, and graphical charts Web forms. In the last chapter, there is a section with code that generates captchas, but the reader is not shown what they look like. The entire 18th chapter is devoted to images, but contains not a single one! I cannot imagine why the authors and/or publisher chose to leave out these essential graphics. Was it to save money? Whatever the reason, it was a significant mistake, and one that should be corrected in the next edition.

Readers who agree with this assessment, or who have other thoughts concerning this otherwise excellent book, can leave feedback via the book's Web page on the Web site for Sams Publishing. This page offers details on the book, a description and table of contents, links for requesting instructor or review copies, and a tool for searching the book's contents within the Safari online technical library. The book's introduction states that the Web site hosts all of the code listings, as well as a list of errata. Yet, I was unable to find either one. (Sadly, the Pearson Education sites are still some of the least usable in the technical book publishing world.) Much better results were obtained on Eli White's site.

Despite an inexcusable and almost complete lack of needed illustrations, PHP 5 in Practice is possibly one of the most meaty, immediately useful, and fluff-free PHP books available. No serious PHP programmer should be without it.

Michael J. Ross is a Web consultant, freelance writer, and the editor of PristinePlanet.com's free newsletter. He can be reached at www.ross.ws, hosted by SiteGround.


You can purchase PHP 5 in Practice from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

PHP 5 in Practice

Comments Filter:
  • by Larsiny ( 753559 ) on Monday February 12, 2007 @03:31PM (#17986704)

    When an experienced software developer needs assistance, it is rarely for language syntax, but instead a desire to see how someone else solved a specific problem.
    Is that really true? I find myself more the opposite where I know how to solve a problem theoretically but I need to know the exact syntax (and sometimes even the libraries/classes already available) to allow me to do what I want. Is this because I'm only a recent (2 yrs) CS grad? Isn't this the normal way to approach the problem due to the myriad languages used out there? It seems to me this might be true only if you're very familiar with a particular language and are trying to use that for everything which may or may not be possible.
  • by DamnStupidElf ( 649844 ) <Fingolfin@linuxmail.org> on Monday February 12, 2007 @03:37PM (#17986792)
    Is that really true? I find myself more the opposite where I know how to solve a problem theoretically but I need to know the exact syntax (and sometimes even the libraries/classes already available) to allow me to do what I want. Is this because I'm only a recent (2 yrs) CS grad? Isn't this the normal way to approach the problem due to the myriad languages used out there? It seems to me this might be true only if you're very familiar with a particular language and are trying to use that for everything which may or may not be possible.

    Congratulations, you have discovered the difference between "experienced software developers" and computer scientists. Computer scientists know what they need to do and how to do it, so long as they can express it in the language they're using. Experienced software developers often know incredible amounts of detail about programming languages, but not necessarily about advanced algorithms and data structures.
  • by Mysticalfruit ( 533341 ) on Monday February 12, 2007 @03:41PM (#17986878) Homepage Journal
    I'm a bit disappointed to read in the book review that there wasn't a chapter dedicated to security. Considering that PHP will let you do things like do external includes from other web servers that can modify your PHP environment, etc...

    What PHP needs is not more features, but better designed security model.
  • by jimstapleton ( 999106 ) on Monday February 12, 2007 @04:05PM (#17987238) Journal
    I'm the same way, but I've been programming for 10 years. I'm more likely to get tripped up on quirks of a language, even one I know well, than to not be able to figure out an algorithm to solve a problem.

    Actually the most common problem is usually a small typo, that I don't see for three hours...
  • by Animats ( 122034 ) on Monday February 12, 2007 @04:31PM (#17987580) Homepage

    Another one of those huge low-density books of examples. Do we really need another one.

    What's really hard today is finding a good reference manual. The original manual for Algol was 17 pages. The original manual for Scheme was 21 pages. 456 pages for PHP is a bit much. A big plastic card that boiled the language down to two pages - now that would be useful.

  • by jimicus ( 737525 ) on Monday February 12, 2007 @05:15PM (#17988234)
    I'd go on and say that IMO (which genuinely is humble, as I'm a sysadmin who's prepared to look at and tweak code if necessary, rather than a fulltime dev), PHP has promulgated an entire mass of badly written, badly commented, ill conceived code.

    Sure, it's possible to write bad code in any language. But PHP is like the BASIC of the web. Popular, (yes, there was a time BASIC was popular) yet treated with contempt because it's just so easy to shoot yourself hard in the foot. At least with C, you usually know pretty early on if your code is really badly thought up. With PHP, however, it seems that nobody quite realises what a festering mess they've produced until someone else points it out, by which time it's taken as a personal attack.
  • by dkf ( 304284 ) <donal.k.fellows@manchester.ac.uk> on Monday February 12, 2007 @05:21PM (#17988298) Homepage

    Which is more important, knowing advanced algorithms and data structures, or knowing the intricate details of a programming language so you can optimize that much more.
    Knowing about algorithms and data structures is more important than knowing the detailed specifics of any particular language, since they illustrate more different ways to tackle a problem and seem to be harder to learn (well, for many people). It's also good to know lots of different languages, again because it effectively gives you more tools for your mental box of tricks. After all, you wouldn't want to go round being seen as the person who uses a 12 pound hammer to drive in screws or saw intricate holes in a piece of wood...
  • by nadamsieee ( 708934 ) on Monday February 12, 2007 @06:03PM (#17988920)

    Congratulations, you have discovered the difference between "experienced software developers" and computer scientists. Computer scientists know what they need to do and how to do it, so long as they can express it in the language they're using. Experienced software developers often know incredible amounts of detail about programming languages, but not necessarily about advanced algorithms and data structures.

    And true software engineers know both. :)

  • by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Monday February 12, 2007 @06:27PM (#17989228) Homepage Journal

    Is that really true? I find myself more the opposite where I know how to solve a problem theoretically but I need to know the exact syntax (and sometimes even the libraries/classes already available) to allow me to do what I want. Is this because I'm only a recent (2 yrs) CS grad?

    Yes, but I think it also speaks to the level of challenge to your comfort you've been faced with. There are three major roadblocks programmers run into:

    1. Language syntax. This should mostly cure itself over time.
    2. Algorithm choice. Again, experience tends to take care of this, regardless of the language you're working with today.
    3. Best practice. Unless you become one of the experts in your field, you should be asking your self how those people have solved the same problem you're working on. The best algorithms and perfect syntax won't help you apply a bad solution to the problem at hand.

    Cookbooks mitigate the last of these. Sometimes you just want to be told how to best solve problem X - the syntax and algorithms will come naturally afterward.

  • by fireboy1919 ( 257783 ) <rustyp AT freeshell DOT org> on Monday February 12, 2007 @06:30PM (#17989264) Homepage Journal
    I take it you're a computer scientist. :)

    As someone who knows fourteen programming languages, but also has a degree in CS with a minor in math, the reason for the that practice among software developers is not because they don't know how (although, admittedly, I've met a few who probably couldn't write low level stuff for themselves), but because there's a best practice way of doing a lot of stuff in any given environment.

    In other words, you try to do things the same way that most people who use the language do it so that your code can be used by other people, and so that you can use other people's code to help you do it. Otherwise you have to reinvent the wheel a lot.

    Programming languages are a math unto themselves. It's pattern recognition, and "speaking" the languages is the crux of most of it. A CS program should teach you how to learn them quickly. The seasoned programmer, whether CS grad or experienced developer, should be the ability to think in different languages by understanding the differences in their patterns.
  • by drooling-dog ( 189103 ) on Monday February 12, 2007 @06:38PM (#17989354)
    Most often what I'm looking for in example code is not an algorithm, but rather an idea of what available functions, classes, and idioms address the problem at hand (and how to use them). That's usually the biggest nuisance when jumping between multiple languages, especially when they're used infrequently.
  • by Anonymous Coward on Monday February 12, 2007 @11:31PM (#17992570)
    He linked to them. Most of them are WONTFIXes right from PHP's bug tracking system. What the fuck more evidence do you require?

Any circuit design must contain at least one part which is obsolete, two parts which are unobtainable, and three parts which are still under development.

Working...