Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Book Reviews Books Media

PHP 5 in Practice 116

Posted by samzenpus
from the read-all-about-it dept.
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 biz0r (656300) on Monday February 12, 2007 @02:39PM (#17986840) Homepage

    ... I find myself more the opposite where I know how to solve a problem theoretically but I need to know the exact syntax ...
    Thats a problem where you are not familiar enough with the syntax of a language. I would probably guess its because of your limited experience with it.

    ... and sometimes even the libraries/classes already available) to allow me to do what I want. ...
    Thats a problem that even very experienced developers hit often, this is exactly what you were talking about in your (the parent to this) post.

    Language syntax is something you learn and then can mostly just take care of without having to refer to reference manuals...however, class definitions, function and method declarations, data structures, etc...those are all something you often will reference out of documentation of sorts when you need it. I have been developing in PHP for about 8 years now but I STILL go to the manual on php.net to see the function arguments/etc (although, granted, with PHP this is largely an issue with the inconsistent naming/etc).
  • by HighOrbit (631451) * on Monday February 12, 2007 @02:57PM (#17987114)
    A few years back (circa 2002), I whipped up a rapid application prototype with PHP while working off from some on-line tutorials and using Beginning Php 4 from Wrox. I think the book and the tutorials were good a teaching the basic language features and syntax, but they taught me to use PHP dangerously because they did not teach good practices. My application worked but never got out of the prototype/demo stage back then for business reasons. Recently, I went back to it on my own time to try to clean it up, move it to PHP5, and make it deployable. I now cringe with horror at the extremely bad practices I was using back then. Granted, it was just a prototype, but I thought I was doing it "right" because I was following the examples in the book and the tutorials. I was doing stuff like accepting form data and passing it to the DB with out validation, outputting user submitted variables without checking for XSS, registering globals, etc, etc, etc. I was doing the kind of things that give me nightmares now.

    So here is my point, all the tutorials, examples, and books that the neophytes are using to learn are _WRONG_. They are teaching _BAD_PRACTICES_. Because PHP is necessarily meant to be in a network environment (excluding the rarely used cli) and it WILL be exposed to potential maliciousness, secure practices should be taught markedly at the beginning, not as an aside. So as part of teaching how to pass form parameters they should include validation code, even if they have to comment that section as " /* trust us on this part for now, we'll show you how this part works latter, just remember you always have to validate the input before you use it */".

    I think PHP is a great language for its purpose, which is simple web-apps. Lots of the criticism about its brain-dead defaults is correct, but they can be overcome with good practices by the application developer. PHP can be great, but it is typically taught wrong at the beginning and that just snowballs.

    The editors and authors all the PHP books and tutorials out there need to make sure the new editions encapsulate good practice at the beginning of the learning process.

    first disclaimer- I haven't read this particular book. I hope it is better than the other PHP books to which my comments apply.

    Second, disclaimer- this is mostly a repost from my post [slashdot.org] at this discussion ( PHP Application Insecurity - PHP or Devs Fault? [slashdot.org])

  • by bbtom (581232) on Monday February 12, 2007 @04:30PM (#17988408) Homepage Journal
    I've gotta agree with some of the presuppositions and points in this review. PHP - in the right hands - is a powerful language. It's great that you can whip things up quickly. But too many of the books go through the fairly simple bits in mind-numbing detail (like, I know what an array is). Thanks to Eclipse and oXygen, most of the time that I'm at a screen, my editor can load the documentation in to a panel while I'm typing it (along with remembering class names, variable names and so on). If I'm coding PHP (or a lot of other languages, for that matter), Eclipse has the language reference. And oXygen gives me the documentation from XSD/RNG/DTD schemas for XML/XHTML etc. Language references aren't useful in dead tree format.

    But something that dead tree can be useful for is conveying development experience. Of course, this can be transmitted in other means. Books that give me best practice guidelines are often far more useful than language guides. For instance, in PHP, there is a function called file_get_contents(). It does what it says. You give it a URL or file and it reads it in to a string. But what the language reference *doesn't* tell you is that for getting things off the 'net libcurl is a better way of doing it - it's quicker, more powerful and has a lot of extremely useful options - in short, something which, if one is intent on building a serious web application in PHP, one should probably use. This is one of the reasons why I think language references would be better if managed on a wiki - or, as PHP does it, with comments attached. That way, people can post code samples, bug reports, workarounds, common errors and so on. This is useful.

    A measure of a successful technology book these days has to be "does this make me a better developer?". The fact that we have books which deal with best practice means that online documentation has gotten better and better and publishers are responding to that. Most of the languages and frameworks I use I carry the specifications for on my Palm Pilot in Plucker format. Reference books can't compete with that. A few publishers I've seen are shifting towards a tutorial style (in the web design sphere, Friends of Ed is a good example of this).
  • by georgeb (472989) on Monday February 12, 2007 @04:32PM (#17988426) Journal
    With regard to the link you provided under "no usable object-model" - I would have to agree with the PHP developers on that one. self::$var or self::CONSTANT is supposed to bind statically. That is how self is supposed to work and actually what the bug reporter was trying to achieve is impossible in C# too AFAIK.

    Namespaces are upcoming in PHP6 (again, AFAIK).

    The rest of the observations are correct to the best of my knowledge and make PHP quite a horrible choice for all projects beyond a certain complexity threshold. Personally I wouldn't think of Perl as a substitute, even though I understand in many respects Perl is superior to PHP, I just find it difficult to make the right choices when it comes to picking a module for a given job. I think Perl suffers from a lot of duplicated effort, there is no concerted effort to establish a de facto framework of modules.

    PHP is dying a slow death in my eyes because of all the inconsistencies. The object orientation feels more like a patch or a workaround rather than a core architectural choice. The total mess created by the ton of functions in the core is not going to go anywhere with the devs maintaining backwards compatibility indefinitely.

  • by LuckyStarr (12445) on Monday February 12, 2007 @04:56PM (#17988816)

    Are you SURE it was PHP? I wonder how you could spend "countless hours" debugging PHP code? I've been at the PHP language for years and the one thing you CAN say about PHP vs other languages is that it shouldn't take "countless hours" to debug. I mean...countless hours? Ate your soul? Perhaps programming isn't really for you. Maybe sales? or marketing?
    You are right. It shouldn't take countless hours to debug. Note my emphasis. Debugging code written by a sane developer in any sane language would not take countless hours. Yet the world is full of programmers which abuse PHP to a level where you start to get the feeling that a complete rewrite of "the thing" is "the way to go". Many of these programmers are good programmers and rather build abstraction-layers instead of spaghetti-code. On the other hand, 20 layers of abstraction on top of each other do not make it easier to find that bug that is hunting you (through Sales, or Marketing).

    And in the rare case when you actually find that bug, it turns out you can't fix it because the whole card-house would crumble into oblivion if you did. So you build workarounds (which accumulate) that are the heralds of death of the system.

    I should have said that I did not in fact write the whole 30ish MB code base myself. I inherited it and got to live with it or do something else. It wasn't planned, it wasn't built using development methodologies (think XP, Scrum, etc.) but rather using a whip. The explanation for the system then is something along the lines of "It has grown organically.".

    And although I see myself primarily as a programmer, I am in fact working on extending my abilities to encompass marketing. So your evaluation flatters me. ;-)
  • by tknd (979052) on Monday February 12, 2007 @05:45PM (#17989430)

    Personally I wouldn't think of Perl as a substitute, even though I understand in many respects Perl is superior to PHP, I just find it difficult to make the right choices when it comes to picking a module for a given job. I think Perl suffers from a lot of duplicated effort, there is no concerted effort to establish a de facto framework of modules.

    In perl's defense, I think that's sometimes the biggest reason I choose perl over the others. The good thing about duplicating or reinventing the wheel is sometimes you need different wheels for different tasks. It also facilitates evolution and a plethora of ideas that you would otherwise miss if you had put everyone together and told them to make THE ONE best module because there will always be drawbacks to even particularly good implementations. The result is perl's library (cpan.org) is massive. When I look at other things like Ruby, though I like the language features, the library work simply isn't there yet.

    As a side note, there's some really cool libraries out for perl. Check out moose [cpan.org] or catalyst [cpan.org] for example.

  • More good PHP Books (Score:2, Interesting)

    by nugsack (219073) on Monday February 12, 2007 @05:52PM (#17989524)

    Here is a good source for browsing PHP Book Reviews [top-books.org]. PHP In Practice [top-books.org] hasn't made the top 50 yet.

  • by specific_pacific (904746) <sicapitan@gmail.com> on Monday February 12, 2007 @06:44PM (#17990168)
    That's why Smart Developers (C) use http://cakephp.org/ [cakephp.org] ;)
  • by jadavis (473492) on Monday February 12, 2007 @10:41PM (#17992690)
    If you're an experienced developer, you'll be able to apply the right tools for the problem in a way that interfaces with complex business processes. You'll complete jobs quickly and have a lot of happy customers. However, sometimes customers might become unhappy if your solution doesn't continue to work for their changing needs, or becomes expensive to maintain or alter. You might occasionally surprise clients with additional cost because a tool you used doesn't work well for a new demand.

    If you're a computer scientist, you'll be able to solve complex problems in a robust, flexible way. However, you might use the wrong tools, not enough tools, or take longer to accomplish the task initially. Your customers will stay content because your solution will continue to work (although you should learn to equate silence with "thank you"). You are less likely to encounter unexpected extra costs (but that's because you probably wrote too much of the code yourself).

    I would say that for short-term projects, lean in the direction of "experienced developer". There's no substitute for a developer that just gets the job done, quickly and under-budget, in a way that works seamlessly with the business needs. However, for long-term projects, lean more in the direction of computer scientist. The computer scientist will be better able to respond to new demands from the system quickly (without costly rewrites or data migration nightmares). Ideally you want someone who is both, and understands when to use which principles.

Our policy is, when in doubt, do the right thing. -- Roy L. Ash, ex-president, Litton Industries

Working...