Slashdot Mirror
Wicked Cool PHP
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.
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.
While Wicked Cool PHP seems useful, I've gotten a lot of mileage out of O'Reilly's PHP Cookbook . 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.
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.
if (title contains wicked | cool)
then
author && editor == dumb fuck
endif
The title isn't just bad, it's wicked retahded.
Nice title if your boss is a 18 year old kid who you won't mind asking to buy you a book with "Wicked Cool" in the title.
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/ which allows users to generate animations(in a java applet) which can be played back in a flash animation(through PHP&Ming) which is stored in a mysql database in a script(text, not image based). I've mostly used the development of this website as a project for my academic programing classes(teachers love this integrated stuff). Gotta love cook books
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.
-- The act of censorship is always worse than whatever is being censored. Always.
From Developer's Library. Written by Christian Wenz. It balances the "how-tos" between core PHP and Libraries like PEAR.
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.
What's wrong with the online documentation? This is all I ever needed...
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.
Missing tag: oxymoron.
Sounds like you liked it then?
... 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.
Prov 9:8 Do not rebuke mockers or they will hate you; rebuke the wise and they will love you.
...too flippant for a professional work.
You picked up "Wicked Cool PHP" and expected a really stodgy, professional work?
[ check out my ruby book @ http://ww
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...
In the free world the media isn't government run; the government is media run.
has anyone actually read the sample chapter provided by the authors on their website?
retarded buttload of crap. i never encountered the problem "Excess Whitespace", nor "Importing Form Variables into an Array", every real programming language returns an array without me explicitly shitting name[] into the markup. "Using Multiple Submit Buttons", this is like "wicked cool cgi programming from the 20th century". Even "Checking Valid Email Addresses" is bullshit, double optin or nothing.
yes, i'm agitated, but its the forcefed crap from years ago, i wouldn't pay a dime!
BEFORE
Template file: AFTER
Data file: Template file: This code is way easier to customize (and looks much clearer in a syntax highlighting editor), besides eliminating the possibility of making a mistake while coding the HTML (the code for making an html select from an associative array is pretty standard, why bother reinventing the wheel with each template?). This alone has saved me not hours,but days of coding (clone the combo 5 times, and change the parameters in only 20 seconds; fiddle around with the inputs - move this up here, exchange these two fields including their calendar popups, etc.) and debugging (try debugging the first example when you're inside massively nested tables!).
Practical examples are a good study, but programming patterns theory and practice is certainly worth the time invested.
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 "require_once" and avoid that whole process.
A lot of time is spent on how to use a language but what really makes life easy on people who will have to fix your code later (including yourself) is how the code is organized.
That would be a good topic for beginner programmers who sometimes don't take the time to not only learn how to use a language better but also how to organize their code better.
Work Safe Porn
Yeah, it doesn't quite fit. Wicked PHP - ok. Wicked Cool - Ok. Cool PHP. Nope.
I use PHP all the time. It can be used well, though it has been abused terribly by the masses. But cool? I think it lost its coolness quite some time ago.
The reviewer also nitpicks about the use of single quotes vs double qoutes, as double quotes have to interpolate variables etc... Come on, most code out there has bigger performance problems to deal with. Variable interpolation is not that bad.
I keep finding blogger who benchmark millions of iterations of similar functions to prove method X is faster than method Y, but in the real world, those things just don't matter. Knowing how your data structures and sql code work, and minimizing your Big O runtime is far, far more important.
If you have a site that is getting so many hits that variable interpolation is truly an issue, you need to learn how to scale horizontally, or choose a different language/platform.
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
Can't we all get along and use Django, a wonderful Python framework which even beats the hell out of RoR?
Any language can be used well, but it's much easier to use some languages well than others. PHP is inconsistent and limiting; why would anyone who knows how to write good code use it instead of a different language?
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.
Do you even lift?
These aren't the 'roids you're looking for.
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 security problems with forms such as XSS attacks and SQL injection. Don't just start barfing out functions into your page, but instead organize your thoughts, and think about how you can generalize the problem. If you expect to be doing the same basic task repeatedly, spend more time on generalization. If not, you can keep it more basic, but you still want to group things together. Don't repeat yourself.
PHP as a language has moved far ahead from its shaky beginnings. It's far from perfect, but it can be used well. Compare the hideous old "formmail.php" script that used to be popular to the shiny new Swift Mailer to see just how far things have come. It's up to each programmer if they want to challenge themselves to write truly excellent code, or if they just want to keep kludging along. If you make the effort you'll be rewarded many times over.
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
Person X doesn't like items 1, 2, and 3 about language Y. Haven't we all heard this before? Yes, check my post history, I've done it too. There are plenty of people around here who would have issues with Java, .NET, Ruby, etc. To each his own. Me personally? Yeah, I have a bias. I already know PHP, so right now I can program in it faster than others. I know that PHP is inconsistent (string and array function parameter orders top the list), and the complete OO paradigm is not implemented, but php still works just fine for my situation(s). It must have done something right to be as popular as it is. There's also a lot of good PHP web hosting out there, lots of people in the community, and the documentation is pretty darn good at php.net Those might not be enough for some people, and that's why there are other projects out there.
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.
One reason could be the amount of built-in features. The last time I tried image manipulation with mod_perl the script required more include lines alone than the total lines of code in the equivalent PHP script. Even the Perl guru at work had to admit that mod_perl has some disadvantages when you're looking for a platform and not just a language. (use Image::JPEG::ohNoNotTheVersionInCPANWhichDidntCompileAnyway, use GD::ButSomeObscureDownloadBecauseOfADependencyFromHell)
(Don't get me wrong, I don't hate Perl as a language.)
How is this insightful? People use PHP because it's the right tool for the right job -- not necessarily because it's elegant, fast, or easy to use, but often because it's portable, already in place, or preferred by their employer. In an ideal world, I personally wouldn't use any of the popular programming languages, but this isn't an ideal world.
PHP is inconsistent and limiting; why would anyone who knows how to write good code use it instead of a different language?
Because many of the inconsistencies are minor (who cares if it's noun_verb, nounverb, or verb_noun? str_split, stripclashes, strip_tags... BFD!) and who cares about limits if you don't bump your head against them? Not everyone needs to write computer-science-textbook-worthy apps or bulletproof-scalable-enterprise-ready apps day in and day out. A shared phone book or simple inventory system that can be cooked up in a few hours is often worth its weight in gold. I'd rather solve ten problems in a usable fashion than solve one problem the "right" way.
http://www.jwz.org/doc/worse-is-better.html (Haters note: that piece wasn't written by JWZ.)
Ob. car analogy: Why would anyone who has access to a limo, a semi-trailer, and a Formula 1 car drive a beat-up old pickup? Because sometimes quick, cheap, and easy are the priorities!
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
You should run away when the chief advantage of a language is that it's "easy". "Powerful", "clean", "robust", and even "flexible" are all good words, but "easy" means "I don't have to think." Thinking is not optional. You will pay for not thinking one way or another. Consider that BASIC and PHP are both "easy", and you'll better understand my point.
You know what's really easy? Not re-inventing the wheel, or at least re-inventing it using robust, common libraries.It's a "BFD" when it leads to wrong-argument-order bugs, silent data corruption, or the user seeing a white page when he submits a form with a "'".
When we evaluate a new programmer for our legacy PHP projects, I always like to pick a site from his resume and type SQL metadata characters into one of the forms, hoping to cause an error. More than half the time, the applicant fails even this first test. PHP makes it too easy to take the ostrich approach of problem-solving, which is a bad thing for everyone in the long run.
Also, PHP's inconsistencies run deeper than you may think. Consider this:
function blah() {
return array("world", "other");
}
$noun = blah()[0];
print "hello, $noun\n";
blah()[0] is a syntax error because of a silly omission in PHP's grammar. Some other things that make writing good programs in PHP difficult and annoying:
-no namespaces, making it tedious to cleanly isolate modules
-half-hearted exception support still eschewed by the developers and PEAR
-lax error handling abused by many legacy programs, which break with E_STRICT | E_ALL
-the attitude adopted by even the maintainers that could be roughly summed up as "the right way doesn't matter, lulz." That attitude led to the absolute insanity that was PHP4 object support.
These aren't arcane "computer-science" concepts. They're real world limitations that make it hard to write good software in PHP. Other languages, like Perl, Python, and Ruby force you to think about the inherent problems in web development, and with them, you can write software just as quickly as you can in PHP: instead of embedding variables in SQL statements, use a query builder. Instead of mixing HTML and code, use a template library. Instead of using $GET indescribably, structure your code so data only flow where they're needed.
You can do all these things in PHP, true, but by the time you'll have done that, you'll have put as much work into the project as you would have in a cleaner language. So why not use that cleaner language in the first place?
I see your car analogy and raise you one: using PHP when you could be using, say, Python, is like driving a Ford Pinto instead of a Honda Civic because you're used to the Pinto, only drive to the local store, and don't think you need airbags. Who knows when these assumptions might change?
Funny, but I can write far better code in PHP than in Java, simply because the flexibility of PHP enables me more than limiting me. Some people needs flexibility, some need constraints. If you like constraints, choose something like Java. These are all personal preferences; there is no winner.
-- Home, James - it doesn't matter where that thing has b
list($noun,) = blah();
Which is really unfortunate, since now we're stuck with a popular Web language that is in many respects more messy then Perl. My only hope is that something decent like Python or Ruby will finally overtake it.
But neither VB nor PHP are not good tools if you know anything better (that is, pretty much anything else), and so they are rightly shunned by more experienced developers.
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"
s/$/ # XXX: PHP is braindead. What a hack./
http://smarty.php.net/ or just PHP, which is a template language (if you know how to separate)
http://php.net/filter
It's not like the language forces you to do all the evil things. Many of the problems have been solved and solutions are available by default. I guess the real problems are old books and people who still haven't upgraded (also people using PHP5 like PHP4).