Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Book Reviews Books Media

The PHP Anthology 2nd Edition 80

Posted by samzenpus from the read-all-about-it dept.
Michael J. Ross writes "When veteran PHP developers have specific and nontrivial functionality that they want to implement in their code, they can do so from scratch, but this can be time-consuming or essentially reinventing the wheel. They can adopt completed code posted in an online discussion forum, but such code tends to be buggy. They can use an open source library or other packaged code, but this approach can oftentimes prove to be overkill. Consequently, many developers prefer focused solutions found in PHP cookbooks, such as The PHP Anthology: 101 Essential Tips, Tricks & Hacks." Read on for the rest of Michael's review.
The PHP Anthology: 101 Essential Tips, Tricks & Hacks, 2nd Edition
author Davey Shafik, Matthew O'Phinney, Ligaya Turmelle, Harry Fuecks, and Ben Balbo
pages 542
publisher SitePoint
rating 9/10
reviewer Michael J. Ross
ISBN 0975841998
summary A tasty cookbook of PHP recipes
The second edition of this book was published by SitePoint on 23 October 2007, under the ISBNs 0975841998 and 978-0975841990. On the book's Web page, the publisher makes available an overview of the book, links to the authors' sites, chapter descriptions, the table of contents, the index, editorial and customer reviews, the book's sample code, and errata (there are none as of this writing). In addition, there is a link for downloading three sample chapters (2, 10, and 11), in PDF format. The pop-up window for entering an e-mail address for receiving the download link, also gives one a chance to subscribe to SitePoint's Web development newsletters.

All of the authors of The PHP Anthology — Davey Shafik, Matthew O'Phinney, Ligaya Turmelle, Harry Fuecks, and Ben Balbo — appear to have plenty of experience with the language, and probably also have spent time interacting with other PHP programmers in online forums, including SitePoint's own PHP forum. Experience reading the questions posted by programmers of all skill levels, and especially trying to answer them, can give anyone a better understanding of what are the most common challenges encountered by the typical PHP coder. In the book's preface, the authors note that, for choosing the particular problems for their book, they chose ones frequently seen in the SitePoint forum, which is likely representative of all active PHP forums.

This new edition of the book has been updated for PHP version 5, including PHP's major improvements to its implementation of classes and objects, among other aspects of the language. It is one of a growing number of PHP books that depart from the traditional tutorial and reference formats, and is instead written in the increasingly popular "cookbook style." Each section presents first a common problem that Web programmers often encounter, followed by generally complete source code that solves the problem, and commentary that explains the overall solution, along with special considerations that the programmer should watch out for in adapting the given source code to their own situation.

As seen in the majority of cookbook-style programming books, this one groups the problem-and-solution sections into chapters, of which there are 13: an introduction; working with databases using the PHP Data Objects (PDO) extension; strings; dates and times; forms, tables, and clean URLs; files; e-mail; digital images; error handling; access control; client- and server-side caching; XML and Web services; PHP coding best practices. In addition to the preface and index, the book also has four appendices: configuring PHP; a checklist for choosing a Web hosting service; a security checklist; and working with the PHP Extension and Application Repository (PEAR). In total, the book is 542 pages long, and yet it is not visually overwhelming, partly because of the large and readable font chosen by the publisher, as well as the innumerable code snippets and browser screen shots interspersed throughout the narrative.

The primary strength of this book is the significant amount of information provided to the reader, in the form of summaries of critical Web programming problems, working PHP code that addresses those problems, discussion as to why each particular approach was taken, and occasional asides that warn the reader about special difficulties that they might encounter as they implement the solutions within their own development environments and for their own projects. Some of the material may be of little interest to the average reader — such as the chapters on PDO and XML — but most of the material would be of interest and benefit to any conscientious PHP programmer. The chapters on error handling and access control are alone worth the price of the book.

However, this second edition of the book has some weaknesses that may or may not have been introduced since the first edition (which was not readily available for comparison). But none of them are overwhelming or unfixable. Firstly, a reader hoping for a well-edited book will likely become distrustful by the authors' misuse of the term "that" in place of "who." Secondly, there are far too many ambiguous comments in the first-person, e.g., "I would dare to say that..." In a book written by five authors, the reader naturally has no idea who is speaking. Thirdly, there is a fair amount of inconsistency in the formatting of the code throughout the book, including indentation and other spacing, as well as variable naming. Also, every instance of a "{" on its own line (presumably to line up vertically with the corresponding "}"), is an antiquated waste of space, since any decent programmer's editor or integrated development environment (IDE) can do brace matching automatically.

Lastly, almost all of the section titles begin with the phrase "How do I." That is fine within the body of the book, at the beginning of every section. But when dozens of these section titles are listed together in the table of contents, that phrase could be excised so each section's topic would be faster to spot, and there would be fewer unnecessary words. In fact, the section titles don't necessarily have to be posed as questions. For instance, "Using Sessions" would be just as clear as "How do I use sessions?" and faster to read.

It should be noted that this book is best suited for intermediate to advanced PHP programmers, who will certainly get the most out of it. A programmer new to PHP, who would like to begin learning the language, should start with any one of the many tutorial-style PHP books available.

For readers who prefer the portability or environmental benefits of e-books, a PDF version of The PHP Anthology is available from the publisher, on the aforesaid Web page. Any programmer who is — or anticipates — doing PHP work away from their print technical library, should definitely consider obtaining the e-book, which thus can be added to their laptop's development environment, and be readily available for quick reference. The e-book contains all of the content of the print version. It also makes good use of color, for screenshots and other illustrations, as well as using a blue background for the sample code, which is a bit easier to read than the gray used in the print version.

Overall, this new edition of The PHP Anthology offers practical solutions to many common PHP problems, clear explanations of those solutions, and working code — in print and online — that can be quickly used as is or modified as needed. PHP developers should find this book an informative and valuable part of their technical library.

Michael J. Ross is a Web developer, writer, and freelance editor.

You can purchase The PHP Anthology: 101 Essential Tips, Tricks & Hacks, 2nd Edition from amazon.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.

The PHP Anthology 2nd Edition More

The PHP Anthology 2nd Edition

Comments Filter:

  • Braces on newline argument in book review? (Score:1, Insightful)

    by Anonymous Coward
    That's like arguing over tabs versus spaces.... of all the things in a book to talk about, whether the code has its braces on the same or newline is as irrelevant as tabs vs. spaces or vi(m) vs. emacs
    • Yeah, any decent IDE can do syntax colouring so you can save space by putting more than one statement on the same line, your tabs vs. spaces comment is moot.

    • Re: (Score:1)

      by SkelVA ( 1055970 )
      Regarding the claim that different samples were written in different styles:

      From page 448-

      All the examples in this chapter are written using PEAR coding standards.


      So if there are samples not following the style, it's an error and no intended. I personally haven't looked through every single coding example though, so I can't make a claim other than that all the ones I've seen have followed the PEAR standard.
  • A programmer new to PHP, who would like to begin learning the language, should start with any one of the many tutorial-style PHP books available.

    I disagree. Beginning books are usually large tomes that are anything but concise (Python books from O'Reilly!), take pages to get to the point, and the examples can be difficult to follow.

    The free online tutorials are concise, provide links to other tutorials, sometimes even editing boxes where you can experiment with a concept, written better, and they're free!

    • Online tutorials (especially PHP ones!) tend to promote bad practices such as xss vulnerabilities and sql injection. Unfortunately, plenty of PHP books do as well.
      • That's right on the spot. I've seen several questions on forums where my answer was in the line of "Such-and-such and you may want to google for SQL injection".
      • Probably because the great majority of technical writers are not programmers. It's far easier to copy/paste code snippets on the web (preferably non-working), put in a few paragraphs of endless philosophical babble in-between and charge $80 for a thick heavy stack of ignorance.

        I find the concept of a "cookbook" rather pointless. When you read a culinary cookbook, you're reading an instruction sheet to make a particular dish; more importantly, you're not learning the fine art of cooking. Similarly, a prog

    • Re: (Score:3, Informative)

      by CastrTroy ( 595695 )
      A lot of the free online tutorials don't show best practices though. How many tutorials have you seen for PHP + MySQL where it wasn't shown that you should construct queries by concatenating strings with either not escaping quotes, using your own function (because the author has no clue that a proper function exists), using mysql_escape_string (which is deprecated), or using mysql_real_escape_string. The right answer is that in the majority of cases, people should be using prepared statements, so that the

      • Re: (Score:2)

        by Splab ( 574204 )
        I don't get why the programmer has to escape strings in the first place.

        q.prepare("select something from foo where bar = ?");
        q.execute(['foo'])

        the database magic should take care of putting in the string/int where it belongs. (Python ish code)

        • Re: (Score:1)

          by gazbo ( 517111 )
          From the parent:

          The right answer is that in the majority of cases, people should be using prepared statements, so that they don't have to worry about whether or not they are escaping strings properly
          So...ummm...yeah.

        • Prior to PHP 5 and the PDO (which does work like that), native sql access was done through calls like mysql_query, pg_query, etc. Most databases had functions to prepare a statement with place holders; MySQL didn't. (MySQL 5 does and anyhow PDO fakes it for databases that don't have native support).

          You don't get it. And the PHP developers didn't either.

  • Reinventing the wheel (Score:5, Insightful)

    by bhmit1 ( 2270 ) on Wednesday November 28, 2007 @04:46PM (#21509501) Homepage
    I forgot the source of this one, but it helps put things in perspective:

    If no one ever reinvented the wheel, we'd be rolling around on stone tires now.

    • Re: (Score:2)

      by s4m7 ( 519684 )

      I've got my own variation of this, which i think is original

      avoid reinventing the wheel if you can, but sometimes you don't need wheels, you need tank treads or an airscrew.

    • > If no one ever reinvented the wheel, we'd be rolling around on stone tires now.

      The problem is that php reinvented the stone tires !

    • Re: (Score:2)

      by Joebert ( 946227 )
      I like to think that if we didn't spend soo much time reinventing the wheel, we'd have flying cars by now.

  • Alternate chapter listing (Score:1, Funny)

    by Anonymous Coward
    1. How to crash your PHP blog
    2. Restoring your software after your PHP blog gets hacked
    3. Modifying your PHP blog to have no copyright information
    4. Using PHP for SQL injections, part I (of VII)
    5. Slowing your website with PHP
    6. How to cancel credit cards used with PHP e-commerce systems before identity thieves max them out
    7. PHP-driven cross site scripting (in Russian)
    8. Using PHP for ray tracing, just kidding, lol
    9. Variable spoofing in PHP blogs
    10. How to make a living writing about PHP

  • Forums. (Score:5, Insightful)

    by onion2k ( 203094 ) on Wednesday November 28, 2007 @05:08PM (#21509805) Homepage

    They can adopt completed code posted in an online discussion forum, but such code tends to be buggy.

    You what? Discussion forums are full of very helpful, very talented developers. When someone posts some code in one it's seen by many eyes ... it's commented upon, criticised, improved and refactored into a neat package much in the same way as a popular open source project only on a smaller scale. Code from forums is often a very high quality, well tested, and well thought out solution ... plus it can be very specfic to your precise needs if you ask the right questions to get the ball rolling.

    The implication of the comment is that a solution from a book is likely to be better code. I've found that not to be the case on several occasions. Bugs are often not caught by technical reviewers.

    I'd much rather use a forum solution than a book.

    Disclaimers: I'm a moderator on a large PHP forum.

    • Re:Forums. (Score:5, Funny)

      by bigdavex ( 155746 ) on Wednesday November 28, 2007 @05:46PM (#21510325)

      Discussion forums are full of very helpful, very talented developers. When someone posts some code in one it's seen by many eyes ... it's commented upon, criticised, improved and refactored into a neat package much in the same way as a popular open source project only on a smaller scale. Code from forums is often a very high quality, well tested, and well thought out solution ... plus it can be very specfic to your precise needs if you ask the right questions to get the ball rolling.

      Right. For instance, I borrowed some code from a forum awhile back. It helped me get promoted to team lead. I'm sure no one will notice.

    • Re: (Score:2)

      by Bogtha ( 906264 )

      Discussion forums are full of very helpful, very talented developers.

      Perhaps some are, but every time I've come across a link to somebody posting code in a forum, it's always been full of huge glaring mistakes, security holes, etc. In fact, I can't think of any place I've seen worse code than in forums.

      • It is not just the forums, it is in the php documentation itself. For instance, the documentation for the 'date()' function on the php.net website [php.net] has the following example code:

        mktime(0, 0, 0, date("m") , date("d")+1, date("Y"));

        The problem with this example is that the date() function can return a different value every time it is called - because time keeps on ticking (into the future). So this code has a good chance of failing at any midnight, end of month, or end of year.

        Many of the contribut

  • the first edition was very solid and taught me alot! especially about OO (or lack of it) in php5

    congrats on the new book

  • That v. Who - the Relative Pronoun Debate (Score:4, Interesting)

    by SitePoint Editor ( 1195639 ) on Wednesday November 28, 2007 @07:29PM (#21511609)
    Hey Michael,
    As the language editor on this SitePoint title, I'm ecstatic to read how much you enjoyed The PHP Anthology, Second Edition, and to note the great rating you gave it!

    I noticed that you made an interesting point about the that v. who confusion, and, being an editor (and therefore by necessity also being, though not always correct, a big, fat stickler), I turned to my style guide for clarification. Here at SitePoint, we rely on two AmE style manuals: The Chicago Manual of Style, and, to a lesser degree, The Elements of Style by the venerable Strunk & White.

    According to Chicago,

    Although "who" refers only to a person... it can be used in the first, second, or third person.
    "That" refers to a person, animal, or thing, and can be used in the first, second, or third person.

    Thus Chicago indicates that these two usages are equally correct:

    The PHP coders who heard the news raced to their own copies of Chicago to double-check the fact.
    The PHP coders that heard the news raced to their own copies of Chicago to double-check the fact.

    I know this is of small note, but I thought I'd mention it all the same (after all, it's not often that us lowly language editors have anything relevant to post to Slashdot!).

    Thanks again for this detailed review of the title,
    Georgina
    Editor
    www.sitepoint.com

    • Re: (Score:2)

      by Miniluv ( 165290 )
      I'm curious then since you mentioned both AmE style manuals to which you refer what Strunk and White say on the topic? I'd get my copy but it's at home and sadly I am not.

    • I know this is of small note, but I thought I'd mention it all the same (after all, it's not often that us lowly language editors have anything relevant to post to Slashdot!).

      No, it's not of small note at all. I'm a tech person and appreciate correct usage of language, and I've seen many people with the same preference. In fact, the 'grammar nazi' is a well known type of poster here and although I don't participate in the nitpicking, I like some off-topic discussion about the finer points.

      I've tagged you

    • Miniluv, they're silent on the point! The pronouns section does give examples in which "who" is used to refer to people, and I can't find any examples that use "that" to refer to people, but I can't find an explicit direction. That's why we call on S&W to a lesser degree than Chicago: it's nowhere near as specific or prescriptive (two factors that, when you're not a native AmE speaker, are much appreciated!). cerberusss, thanks for the encouragement :) Now you mention it, I'm pretty sure I've seen the

  • When veteran PHP developers ...

    That's a really good analogy! After writing my fair share of PHP code, and trying to make it behave correctly, I consider writing PHP code to be comparable to fighting in a war.

  • However, this second edition of the book has some weaknesses that may or may not have been introduced since the first edition...

    This begins a 160 word paragraph going on about:
    - "that" in place of "who"
    - ambiguous uses of first-person
    - inconsistency in indenting
    - excessive whitespace

    Are you kidding me? This is the most significant criticism you have of the book? This? Sure, stumbling upon standard high-school essay editing mistakes in a published work is a pain. But geez, summarize it briefly and move o
    • Even in high school I would have gotten crucified for beginning three subsequent sentences with "Firstly", "Secondly", and "Thirdly".

      "subsequent" should be "successive". I woulda gotten crucified for that too!
    • Not to mention that I don't care if my IDE can do brace matching, it's a damn reference book so I want to be able to see where things happen in the code without needing to put it into my IDE in order to get nice formatting!

  • "Also, every instance of a "{" on its own line (presumably to line up vertically with the corresponding "}"), is an antiquated waste of space, since any decent programmer's editor or integrated development environment (IDE) can do brace matching automatically. "

    Thats personal taste and has no place in a book review. Remember that you are not the one reading your own code all the time. Clarity helps other programmers understand what you are doing and curly brackets on their own lines helps immensely. gregor

  • Also, every instance of a "{" on its own line (presumably to line up vertically with the corresponding "}"), is an antiquated waste of space, since any decent programmer's editor or integrated development environment (IDE) can do brace matching automatically.

    Brace placement religion in a book review? Really? Brace placement, like editor choice, is a matter of taste and personal opinion. If you feel the need to expound on that topic, pop over to comp.lang.php; I'm sure you'll find a nice flame war there.

Slashdot Top Deals

BLISS is ignorance.

Close