Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

Wicked Cool PHP 131

Posted by samzenpus from the totally-gnarly-books dept.
Michael J. Ross writes "Web developers familiar with a particular programming language, such as PHP, typically turn to books and forums for assistance only when they confront a specific problem that they believe has probably been encountered by many of their peers in the past, and who have published their answers in print or online. Hence the growing popularity of programming "cookbooks", which eschew flowing narratives in favor of self-contained problem descriptions and solutions. One example of a book that combines both styles is Wicked Cool PHP: Real-World Scripts That Solve Difficult Problems, by William Steinmetz with Brian Ward." Keep reading below for the rest of Michael's review.
Wicked Cool PHP: Real-World Scripts That Solve Difficult Problems
author William Steinmetz with Brian Ward
pages 224
publisher No Starch Press
rating 5/10
reviewer Michael J. Ross
ISBN 978-1593271732
summary Yet another PHP book that presents a variety of topics through sample code.
Published by No Starch Press on 9 February 2008, under the ISBNs 1593271735 and 978-1593271732, Wicked Cool PHP aims to provide the reader with a wide-ranging collection of complete PHP scripts and code fragments that solve specific problems frequently encountered by PHP coders. It is not intended for explaining the fundamentals of PHP, but assumes that the reader already understands the basics of the language. The book covers PHP versions 5 and 6. On the book's Web page, visitors can purchase it online, download a sample chapter (Chapter 4: Working with Forms), and download most of the sample code.

The book's material is organized into a dozen chapters, covering a range of topic areas: some simple scripts; configuring PHP; PHP security; forms; text and HTML; dates; files; user and session tracking; e-mail; images; using cURL to interact with Web services; and three intermediate projects. A brief appendix shows the MySQL commands for creating the product_info table used in many of the book's scripts. The book's back cover claims that it offers 76 scripts, but at least one section (#69) does not contain a script.

The first chapter is titled "The FAQs of Life — The Scripts Every PHP Programmer Wants (or Needs) to Know." That's quite a claim, unfulfilled by the chapter's material, which covers only seven narrow topics, such as how to include another file in a script (require_once) and how to print an array (print_r). Furthermore, there is no common theme for the scripts chosen, aside from their addressing questions that one of the authors — who is not identified — sees repeatedly in PHP forums and discussion groups. Some are extremely basic (e.g., print_r), while others address topics that are far more advanced and deserving lengthier treatment (e.g. templating your site with Smarty). That last topic would have been much better presented as an intermediate project in the book's final chapter.

Configuring PHP is an area that can prove perilous for programmers who are new to the language, and are, for whatever reason, having difficulty setting up PHP on their home Web server. For such individuals, Chapter 2 should prove quite useful, because it offers a clear overview of how they can configure their own PHP installations to match their needs. Some of the configuration advice could be a lifesaver, depending upon the reader's circumstances — such as the information on using open_basedir to limit directory access to PHP (and energetic hackers).

However, on page 20, when the authors provide advice on how the reader can find the php.ini file, they suggest that Windows users should look in "C:\php." Actually, the default installation file path is "C:\Program Files\PHP" (unless the reader has altered the value of ProgramFilesDir in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion key in their Windows Registry). They urge the reader to delete any phpinfo() script, for security reasons. But having such a script on a remote server could be quite valuable to the reader, at some point in the future; so it would be wiser to simply rename it, assuming that the reader has not allowed hackers to list file names on his or her Web server.

Several times in the book the authors advise the reader to set the error_reporting configuration option off for production servers — as well as for development servers lacking firewalls — so hackers and others do not see system information contained in error messages. But error_reporting is best used for specifying the level of error reporting, while the display_errors configuration option is best used for disabling the display of those errors to the site visitor. Errors should still be recorded in the Apache error log, so the developer can better diagnose what happened on a production site.

As with most first editions, this one contains several errata: "phpinfo()can" (page 21), "data to encrypted" (page 42), "six years" (page 55; should be 10 years, to match the code), and "timestamp() function" (page 82; should be "time() function").

In any book, a sizable number of minor flaws will prompt the careful reader to begin questioning the editing of the book. This is especially true when encountered in the first paragraph of the first page of the Introduction: "stumbled on to," which should instead be two words. But it goes beyond just issues of line editing — to a question of judgment. That very first page also contains "After you calm down," which is too flippant for what should be a professional work, as are other instances: "living hell" (page 4), "hash-ish" (page 40), and "Mac users... [like] to buy expensive gadgets for the sole purpose of looking stylish" (page 113). The authors frequently use the term "I" without specifying which author is being referred to; presumably it is the first author listed. On page 64, they state that they had previously mentioned the === operator, but I cannot find it anywhere, and neither could whoever created the book's index.

In the sample code, the authors use double quotation marks — instead of single ones — for most of the strings, few of which contain variables. This slows down the PHP interpreter by forcing it to check for variables within the strings, to be interpolated. Moreover, they are not consistent in the usage — occasionally switching over to single quotes instead, for no apparent reason. The same is true of in-line comments, which switch back and forth between Java and C styles.

The code in general is not entirely consistent throughout the book, e.g., using print() in most cases, but echo() in the remaining ones, with no explanation as to why. Perhaps this is the result of having two authors. Most HTML tag names are in lowercase, but a couple are in uppercase.

Some of the book's code appears invalid. For instance, on page 5, one of the statements (abbreviated here), echo "$row[product_name]," generates two errors: "unexpected T_ENCAPSED_AND_WHITESPACE" and "Use of undefined constant key — assumed 'product_name'." The correct code would be: echo "{$row[ 'product_name' ]}." On page 41, $cipher is set to the string "MCRYPT_SERPENT_256," which generates an error, and probably instead should be set to the constant MCRYPT_SERPENT, which works fine. $mode is set to the string "MCRYPT_MODE_CBC," but that should be a constant as well. On page 72, the regex pattern for matching HTML anchor tags does not match an entire opening tag, but just a portion of it. In the downloadable code for section #68, getpage.php fails because "<?" should be "<?php." Readers shouldn't have to debug a book's code just to get it to run without error. Did no one test the sample code before publication?! In the code for section #71, mapdemo.php generates index errors when run without any GET parameters, and does not generate a map when values are entered in the form.

Some of the code may work in certain circumstances, but not in others. For example, on page 70, the pipe character (|) is recommended as a substitute for the forward slash (/) for regex patterns containing many such slashes. But the pipe character is a very poor choice, because it has a special meaning in regex patterns, namely, as the 'or' operator, and thus cannot be used for any pattern that needs to use that operator. In section #49, calculate_time_difference() fails if one or both of the timestamps is the epoch time (time zero). In section #61, get_ip() assumes that two $_SERVER keys are set, and fails when they are not.

Some of the code works but can give beginners the wrong impression. For instance, on page 25, the authors present a configuration setting (incorrectly referred to as an "extension"): ini_set(max_execution_time, "240"). But max_execution_time is not placed in quotation marks. Even though this does not cause an error, a newbie may do the same with ini_get(), and become confused as to why PHP then (rightly) complains. (One could argue that PHP should also flag the ini_set() call as erroneous.) Section #50 could mislead newbie programmers into using that multi-line script instead of PHP's file_get_contents(). Section #51 similarly re-creates the wheel, namely, file_put_contents().

Lastly, some of the code, comments, and variable naming choices are quite puzzling. For instance, in section #30, validate_cc_number defines a variable as $false = false, but this "variable" never gets changed in the rest of the script. That is what constants are for. In the downloadable time difference scripts for Chapter 6, we find "print abs(5 — 62);" with no apparent purpose. In timediff.php, calculate_time_difference() checks for divide by zero errors for a variable that is never used as a denominator.

Unlike most computer programming books, this one has no acknowledgments of any technical reviewers. Given all of the problems in the code, it is possible that there actually were no technical reviewers, though it is difficult to imagine any reason why a publisher would choose that unwise route.

In terms of formatting of the material in the book, most of the left-hand pages (the even-numbered ones) have the page contents shifted too far to the right, almost running into the crease of the book, and leaving a glaring amount of wasted whitespace in the left-hand margin. The only exceptions are on pages 163, 164, and 172, where portions of code awkwardly jut out into the left margin.

The downloadable code archive is quite flawed, and a fair amount of the code needs to be cleaned up. For example, getpage.php contains a lot of redundant code. Much of the sample code in the book is not included in the archive; incredibly, this includes some of the largest scripts, such as the Smarty code in Chapter 1 and the credit card processing code in Chapter 4. In fact, the archive is missing the code for two entire chapters (2 and 3). Oddly enough, at least a couple scripts in the archive are not mentioned in the book. The archive needs a complete overhaul, including the cleanup or elimination of seemingly leftover scripts such as foo.php (three instances) and captcha_old.php.

On the positive side of the ledger, the book contains information that would be of interest to all levels of PHP programmers. For instance, readers who are just barely familiar with the language will benefit from the discussions concerning superglobals, form input security, date and file manipulation, and how to save user information with sessions and cookies. More advanced developers may profit from the discussions on encryption, PHPMailer, captchas, Web services, and other topics generally found later in the book.

In addition, many of the sections include a special subsection titled "What Can Go Wrong?," in which the authors consider potential problems with the code or overall approach presented in that section. Undoubtedly other technical books provide such information, interwoven with the main narrative; but explicitly identifying potential pitfalls is a worthy practice — one that we can only hope to see in other programming books in the future.

At 224 pages, it is a relatively slim volume, but contains a fair amount of useful information relative to its size — a pithiness welcome in the world of computer books. (Fortunately, the trend in the technical publishing world has shifted away from tomes sometimes exceeding 1000 pages that are padded with poorly-edited material shoveled in by multiple authors.)

Yet all in all, Wicked Cool PHP is largely disappointing. It contains no PHP scripts that could be considered "wicked cool." Moreover, the aforementioned code problems clearly call for an improved second edition, including a complete revision of the downloadable code archive. On the other hand, Wicked Cool PHP touches upon a number of key topics in PHP programming, with minimal fluff, and gets right to the point.

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

You can purchase Wicked Cool PHP: Real-World Scripts That Solve Difficult Problems 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.

Wicked Cool PHP More

Wicked Cool PHP

Comments Filter:

  • O'Reilly's PHP cookbok preferable (Score:5, Informative)

    by Anonymous Coward on Monday April 07, 2008 @03:04PM (#22992104)
    While Wicked Cool PHP seems useful, I've gotten a lot of mileage out of O'Reilly's PHP Cookbook [amazon.com] . I just wish they would release a new, expanded edition. O'Reilly's cookbook series are really a pleasure to use, giving you just the info you need and not wasting space trying to be funny or zany like far too many CS books out now.

    • Forget PHP, use Python (Score:1, Interesting)

      by Anonymous Coward
      Can't we all get along and use Django, a wonderful Python framework which even beats the hell out of RoR?

  • PHP6? (Score:2, Insightful)

    by Spazholio ( 314843 )
    The book covers PHP versions 5 and 6. Do they know something we don't? Isn't PHP5 the most recent version?
  • If this is anything like the Shell Scripts or Java book, it will provide me with many dozens of hours of nerdy enjoyment and glee.

  • marketing 101 (Score:5, Funny)

    by Anonymous Coward on Monday April 07, 2008 @03:12PM (#22992186)
    if (title contains wicked | cool)
    then
                  author && editor == dumb fuck
    endif

    • Re: (Score:1)

      by nazsco ( 695026 )
      > author && editor == dumb fuck

      those are comparissons.

      $author = $editor = 'dumb fuck'

      php syntaxnazi

    • Re: (Score:2)

      by uhlume ( 597871 )
      Hm — I'm guessing you opted to take Marketing 101 instead of Programming 101.

  • title (Score:2, Funny)

    by Anonymous Coward
    The title isn't just bad, it's wicked retahded.
  • These books are amazing for random ideas, in my opinion.
    Story time:
    Not to give a random plug or anything, but a while back I read a PHP cookbook (2006ish) and it had a small section on a plugin called "Ming" which can generate flash animations without using proprietary tools. I took what little was available on the web and (for the past 2 years) have been developing http://www.icanimate.com/ [icanimate.com] which allows users to generate animations(in a java applet) which can be played back in a flash animation(through PH

    • Re: (Score:2)

      by h4rm0ny ( 722443 )

      I've read large chunks of the "PHP Cookbook" and it's not bad. There's useful information in there, though the tome is a little indigestible. The absolute best book I've read of this kind is the Python Cookbook. Admittedly, I was still learning Python at the time and so I was enjoying all the little discoveries about the language, but it's a seriously good book and in an age of convenient online references and tutorials, is maybe one of the few programming books that is absolutely worth buying. Absolutely

  • You shouldn't need a "cookbook". (Score:4, Insightful)

    by Chandon Seldon ( 43083 ) on Monday April 07, 2008 @03:31PM (#22992396) Homepage

    If you actually understand the language that you're using and the basics of programming, you should be able to handle most simple cookbook-type programming problems without any help.

    Now, sitting down and reading one of these "cookbooks" (straight through, like a novel) when you're learning a new language might be a good idea; it helps get an idea of the programming style used in the community around the language. But, if you find yourself constantly using one of these things as a reference book for solutions then you should take that as a sign that you should probably go pick up a "Learning Language X" book and actually read it.

    • What has helped me the most to work with PHP is reading articles about programming patterns (i.e. MVC) and reading reviews and technical documentation on frameworks (i.e. joomla). Plunging into the code of these architectural mammoths has really changed my way of thinking, and more than once. For example, after reading a bit of joomla i decided to make a class for form output to organize my form templates (which receive also css parameters), instead of hardcoding the values between control structures like f
      • sorry man but you fail! joomla is one the worst examples of how not to write any code. As much as i love open source software i have to say that joomla really is done badly. I am really looking forward to the next major typo3 release
        • Thanks for the tip. Joomla may be a worst example, but the idea of having form objects isn't :) In any case, mind enlightening us about why Joomla sucks? It's not a challenge, it's a sincere question - one never stops learning.

  • This slows down the PHP interpreter by forcing it to check for variables within the strings, to be interpolated.

    Say what?!

    e.g., using print() in most cases, but echo() in the remaining ones

    They are language constructs, not functions (so your notation is kinda wrong, otherwise valid point).

    On page 41, $cipher is set to the string "MCRYPT_SERPENT_256," which generates an error, and probably instead should be set to the constant MCRYPT_SERPENT, which works fine

    Their PHP was compiled with libmcrypt version 2.2.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      This slows down the PHP interpreter by forcing it to check for variables within the strings, to be interpolated.

      Say what?!

      Say what, what? Using "" strings which support interpolation is slower than using '' strings which don't (even accounting for the dot operator concatenation of the variables to the '' string). Often "" is preferable anyway for code readability and with the inherent latency of the web for which PHP is most often used it's like a drop in the ocean, but still, any benchmark of PHP will support the fact that "" is undoubtedly quite a bit slower than ''.

      • Re: (Score:2)

        by Firehed ( 942385 )
        Well the latency of the web isn't so much the problem as the scalability of the script. An extra 50ms means nothing to the end user, but if you're getting twenty page views a second, you're going to find your server getting back-logged really quickly.

        However, I think (hope) the confusion may have been in the word "interpolated", which should have been 'interpreted', 'substituted', 'replaced', or any number of other words.

        • Re: (Score:1)

          by chromatic ( 9471 )

          However, I think (hope) the confusion may have been in the word "interpolated", which should have been 'interpreted', 'substituted', 'replaced', or any number of other words.

          "Interpolated" is actually correct.

        • Re: (Score:2)

          by mortonda ( 5175 )

          Well the latency of the web isn't so much the problem as the scalability of the script. An extra 50ms means nothing to the end user, but if you're getting twenty page views a second, you're going to find your server getting back-logged really quickly.

          However, I think (hope) the confusion may have been in the word "interpolated", which should have been 'interpreted', 'substituted', 'replaced', or any number of other words.

          "50ms" is a made up number. Show me where a real world profiler (on a realistic php script) has shown interpolation to be a major bottleneck. Don't optimize prematurely - there are almost always far bigger problems to deal with than variable interpolation.

          And yes, "interpolation" is the exact correct word in this context.

          • Re: (Score:2)

            by Firehed ( 942385 )
            Yes, 50ms is a made up number. And it's an exceptionally large one, for no other purpose than to make a point. I just created a timed, "echo 10000 times" loop and the performance difference was next to nothing (though it appears to be specific to the order I do things in; when I increased it to a million I saw a tenfold speed difference, but the first was always the faster no matter whether it was the single or double quoted version). Not exactly real-world, so expect the numbers to change with normal us

      • Re: (Score:1)

        by chromatic ( 9471 )

        ... any benchmark of PHP will support the fact that "" is undoubtedly quite a bit slower than ''.

        If that's actually true to any substantive degree (network latency is likely your biggest bottleneck when talking about HTML generated by PHP), there's something very wrong in the PHP core. The right way to parse code into some sort of AST or optree means that the parser emits a different tree for a double-quoted string with no interpolation than for a double-quoted string with interpolation. That tree sho

        • You're right. That's there's something very wrong.

          "quoted text with $var" is converted to 'quoted' . ' ' . 'text' . ' ' . 'with' . ' ' . $var.

  • From Developer's Library. Written by Christian Wenz. It balances the "how-tos" between core PHP and Libraries like PEAR.
    • I was using that one for a while, but I got to the part about initializing an array, and it said:

      My hovercraft is full of eels

  • all too common problem (Score:4, Insightful)

    by dslbrian ( 318993 ) on Monday April 07, 2008 @03:37PM (#22992460)

    Did no one test the sample code before publication?!

    This is one of those things that I just can't understand. I ran into this same thing when trying to get up to speed on C++ on Windows a few years back. I picked up a copy of Visual C++ .NET Bible (only to find out it had almost nothing to do with .NET) and found it's examples were completely bug ridden. I found one example that had something like 20 bugs in it.

    One would think on the web where fast publication generally happens you might see this. But in an introductory text, where examples will cause profound confusion, you would think they could at least do a single editorial debug pass through it. More so, it's a freaking dead-tree book, if you are going to publish something that will last for years, and it has your name on the cover, try checking the examples!

    BTW, for those who think O'reilly is immune to this, it's not - I have a number of O'reilly texts I bought based on their rep only to find out they published a useless doorstop.

    • Re: (Score:1)

      by ClamIAm ( 926466 )
      it's examples were completely bug ridden.

      Well, hopefully it was less maddening than my class in Unix/C, where I enjoyed the insanity of a (nearly) 40-year-old operating system/language, coupled with the insanity of many typos.

    • Did no one test the sample code before publication?!

      This is one of those things that I just can't understand. I ran into this same thing when trying to get up to speed on C++ on Windows a few years back. I picked up a copy of Visual C++ .NET Bible (only to find out it had almost nothing to do with .NET) and found it's examples were completely bug ridden. I found one example that had something like 20 bugs in it.

      One would think on the web where fast publication generally happens you might see this. But in an introductory text, where examples will cause profound confusion, you would think they could at least do a single editorial debug pass through it. More so, it's a freaking dead-tree book, if you are going to publish something that will last for years, and it has your name on the cover, try checking the examples!

      BTW, for those who think O'reilly is immune to this, it's not - I have a number of O'reilly texts I bought based on their rep only to find out they published a useless doorstop.

      The things this reviewer complained about the most seemed to me to depend on environmental settings and would be very server specific. He complained about short tags (there are many scripts that rely on short tags, good bad or ugly)when short tags can be set in the server configuration. And complaining about the difference in quoting styles and the difference between print and echo? The review lost any sense of objectivity when he started picking nits.

    • Re: (Score:1)

      by UCFFool ( 832674 )
      I'd have to agree. I just finished a PHP book (will be available from www.phpreferencebook.com in a few days) and every single chunk of code was copy/pasted into a test.php file and ran with all errors enabled to make sure it was working as expected. Every time. If I changed a word in a comment, I copy/pasted the whole thing and tested it. Period.
      Sometimes I wonder. Maybe since I had the luxury of self-publishing I could make sure it was right, but if it isn't right, why bother publishing it!
  • What's wrong with the online documentation? This [php.net] is all I ever needed...

  • For instance, on page 5, one of the statements (abbreviated here), echo "$row[product_name]," generates two errors: "unexpected T_ENCAPSED_AND_WHITESPACE" and "Use of undefined constant key -- assumed 'product_name'."

    Both of those are Warnings, not Errors. And in true PHP tradition, unless it breaks the script completely (which Warnings don't by default), it's not only not wrong, but pretty close to best practices.

    Honestly, this sounds like one of those books that gives PHP its bad reputation.

    • Re: (Score:2)

      by neoform ( 551705 )
      You're confusing best practices and allowable practices.

      I code in PHP regularly and I don't even let notices slip by without correction. Yes, PHP lets any garbage code run, yes that's not a good thing; but that's why PHP is so popular, cause it's so damn easy to make a script.

      PHP trolls (I'm not accusing you of being one) never seem to get that.
      • I'm not confusing best practices with allowable practices; so many people who feel the need to write PHP tutorials on the internet (and who apparently get offered book deals) seem to.

        I actually like working in PHP, and I know the fact truly horrible code can run fine on it is one of the reasons it's so popular, but people who write these sorts of books should really know better than to think the fact that their crap code runs makes it fine to hold up as an example to students.
  • Sounds like you liked it then?

  • The 80s called ... (Score:5, Insightful)

    by Bob-taro ( 996889 ) on Monday April 07, 2008 @04:03PM (#22992746)

    ... they want their slang back. "Wicked cool"? Seriously? While it's entirely possible that this phrase has made a comeback of which I am unaware, I would think using the word "wicked" totally cancels out (or possibly negates) the word "cool". Why not name it "Totally far out PHP"? "Really swell PHP"? From a marketing POV, the slang used in the title of a programming language book should probably not pre-date the programming language itself.

    Just my opinion. I'm not an author or a marketer.

    • "No Starch Press" had another "Wicked cool" book, http://books.slashdot.org/article.pl?sid=06/01/25/1459239 [slashdot.org] on Java.

      I'm a transplant to New England, and hear "wicked" used with some frequency. They also say "cool beans." Sometimes I even hear "Wicked cool beans." I think they say that just to be "pissahs."

      • I'm a transplant to New England, and hear "wicked" used with some frequency.

        Oh, I didn't know it was a regional expression. Come to think of it, last time I was in New England was ... in the 80s. It's interesting that I got modded "+5 insightful" for an apparently unjustified criticism. Such is karma, I guess.

        • It's interesting that I got modded "+5 insightful" for an apparently unjustified criticism. Such is karma, I guess.
          A lot of posters gripe about moderators on crack when we see nonsensical moderations. I rather think that some mods are on Ritalin.

    • I asked a bunch of old Boston townies, they said the phrase never went out of style and then they drove off in a '86 Monte Carlo SS Aerocoupe, which BTW, was out of style in the showroom.

    • From a marketing POV, the slang used in the title of a programming language book should probably not pre-date the programming language itself.

      So my upcoming title "Awesomely Rad FORTRAN" is still ok?

    • Re: (Score:2)

      by jadin ( 65295 )
      You'd prefer current slang? I can't stand most of today's slang.

    • Re: (Score:1)

      by Geste ( 527302 )
      I agree 100 percent.

      It should have been "Wicked Pissah PHP"

    • Re: (Score:2)

      by sootman ( 158191 )
      From a marketing POV, the slang used in the title of a programming language book should probably not pre-date the programming language itself.

      But that would only leave OMG PHP LOL!!!11 as a possible title.

      Hmm... actually,

      O M G
      P H P
      L O L

      looks kinda cool. :-) Reminds me of an idea I had for a PHP site:

      < ? A N G L E B R A C K E T
      Q U E S T I O N M A R K ? >

      It even works as a cheer: "Angle bracket, question mark, P H P..."

  • "Professional work" (Score:4, Insightful)

    by graznar ( 537071 ) on Monday April 07, 2008 @04:11PM (#22992816) Homepage
    ...too flippant for a professional work.

    You picked up "Wicked Cool PHP" and expected a really stodgy, professional work?

  • cross-site scripting? (Score:3, Funny)

    by myowntrueself ( 607117 ) on Monday April 07, 2008 @04:21PM (#22992920)
    I sure hope they can help people to program cross-site scripting vulnerabilities...

    No book on php could miss examples of how to do this, surely? Its the number one thing that php programmers need to be able to do! Apparently...
  • A book titled "wicked cool" may appeal to kids who havn't yet learned that programming will never be mistaken for "cool" but I don't think it will appeal to professionals. Of course PHP tends to be seen as a "script kiddie" language anyway.

    From the review seeing "require_once" as the solution to including files shows that code organization is apparently not being taught. It's the "goto" of PHP. Instead of laying out the code in a clean logical fashion that avoids redundant includes you can simply use "re

    • Re: (Score:2)

      by mortonda ( 5175 )

      From the review seeing "require_once" as the solution to including files shows that code organization is apparently not being taught. It's the "goto" of PHP. Instead of laying out the code in a clean logical fashion that avoids redundant includes you can simply use "require_once" and avoid that whole process.

      It's not always that easy, and the test is simple. It's probably not worth the time to sort out.

      PHP isn't the only place this metaphor is used, many C headers have something like:

      #ifndef DATA_H /* ... code ... */

      #endif

  • While there are probably some exceptions about the Wicked Cool series of books, the fact that it has wicked cool in the title means I won't buy it. It might as well be named "Hella Awesome Gnarly Bitchin' PHP". I wouldn't buy that book, either.

    -fragbait
    • The title ("Wicked Cool") just shows east coast bias. If it were written in San Francisco it'd be "Hella Cool." If it were written in Sacramento it'd be "Hecka Cool." And if it were written in LA it'd have a picture of a babe on a beach on the cover.

  • php limitations (Score:2, Insightful)

    by larry bagina ( 561269 )

    For instance, in section #30, validate_cc_number defines a variable as $false = false, but this "variable" never gets changed in the rest of the script. That is what constants are for.

    It doesn't sound like it in this case, but if a function returns a value by reference, you would need to put a constant in a variable before returning it.

  • I just took a quick glance at chapter 4, and I can tell you that this book is complete shit. Their solution to handling web forms is to write some quick and dirty error handling functions. An approach like that guarantees you're going to overlook some security holes, and that every time you want to handle a form you'll be rewriting your code.

    Use classes. Take advantage of libraries like HTML_QuickForm or Zend_Form. If those don't meet your needs, build your own. In either case, learn about the common securi

    • Re: (Score:2)

      by Bob Ince ( 79199 )

      An approach like that guarantees you're going to overlook some security holes

      And indeed the book does - that chapter is chock-full of HTML injection holes, leading to cross-site-scripting vulnerabilities. After giving the standard "Very important is a security!" spiel at the beginning this is a bit disappointing.

      PHP as a language may have made some poor design choices, but the main reason so many PHP coders are security-ignorant - and consequently so many PHP applications are plagued with endless security

  • Anybody else think there should be a moratorium on Writers / Editors being reviewers?

    Overall I think the review had a few good points, but started devling into a one-upmanship type sitation. It became obvious to me that there was a virtual axe to grind and it was not a suprise to see the reviewer claims to be a writer and editor.

    Somewhere it stopped being about real flaws, and became a game of pointing out minutia
  • If the book is not quality then why are you advertising it so widely on Slashdot? Granted, you think you are giving a brutal review but wouldn't an Amazon comment be more effective without giving the book such wide exposure. Honestly I would have never heard about the book until it showed up here.
  • do the FAQ include this question and answer : "Q: How long until I'll have to rewrite my application ? A: About two years. Then the next version of PHP will get out, and in another year, or two if you're really lucky, there will be no support for the version you used, and due to backward incompatibilities, you'll be left with a ton of work that you cannot host anywhere but on your own datacenter. Oh, and watch the .x.x releases: we do love to break backward compatibility"

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close