The PHP Anthology 2nd Edition 80
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 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.
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 |
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.
Re: (Score:2, Informative)
Warning, this is a goatse.
Re: (Score:2)
Re:I've said it before and I'll say it again: (Score:5, Informative)
PHP is not that bad of a language. Yes, it has it's issues and has brought on it's own stereotype because of it's ease of use. But really, when it comes to getting things done and done quick.. PHP excels very well.
I use PHP on a daily basis. Not just for work (I am a web developer by profession), but for quick dirty hacks (especially when bash is not available) it is great too. I've written entire daemons that watch and entire directory tree (1000+ files) and will alert me in some way of something happens, etc. I've written a IRC-style chat system way back in the day, and so on.
PHP has GTK [php.net], and apparently QT [php-qt.org] (server appears to be down ATM) bindings now. It has a lot of really useful low-level bindings, such as FAM [php.net]. Along with Sockets and friends PHP is very powerful. Especially if you can get out of the mentality that "PHP was designed for websites."
PHP really has evolved... I am very greatly anticipating the upcoming PHP 6. NAMESPACES! I can't wait.
I've used and worked with Ruby, Python, TCL, etc. etc. PHP just sits right with me.
Re: (Score:2)
It's rather like they took perl with all its faults, and stripped off what was left that it actually did right.
Re: (Score:2, Informative)
@eval("-=-=-=- INVALID SYNTAX GOES HERE -=-=-=-");
} catch (Exception $e) {}
echo "Yay, I'm still here!!";
Re: (Score:2, Informative)
Re: (Score:1)
PHP is not that bad of a language. Yes, it has it's issues and has brought on it's own stereotype because of it's ease of use.
so.. PHP is not bad, PHP developers are ..
but for quick dirty hacks (especially when bash is not available) it is great too. I've written entire daemons that watch and entire directory tree (1000+ files)
you might want to try perl .. i think in generally .. PHP should have been a template language for perl .. that would have made a great addition .. (if you take out all those pseudo database functions)
I've used and worked with Ruby, Python, TCL, etc. etc. PHP just sits right with me.
i have also used those (and perl,c,java, blah, blah) .. and i see no reason why i would ever use PHP if i'm not forced to ;)
I am very greatly anticipating the upcoming PHP 6. NAMESPACES! I can't wait.
are you sarcastic ?
Re: (Score:2)
It was a template language for perl, originally.
Re: (Score:1)
didn't know it was actually used as a template engine... ever..
Re: (Score:2)
Re: (Score:3, Funny)
Re: (Score:2)
Re: (Score:2)
Among interpreted languages, those who do not know Perl will reinvent it, badly. (Python and Ruby were designed learning from Perl, not by ignoring it, unlike PHP in which case I would say we cannot talk about design.)
PHP is an ugly templating engine. PHP IS for websites.
Yeah, right PHP is easy to use...until you don't know what you're doing and just want to get a website up. Once you need it for something p
Re: (Score:1)
Re: (Score:2)
PHP is a WONDERFUL language for development. It's very flexible, fast, easily developed, and has so many extensions to it you can solve just about anything. And it scales very, very nicely. (I use PHP to process tens of thousands of student records in California - it does the job nicely, reliably, 24x7)
The only difference is that I use PHP4 for just about everything, and haven't made the switch to PHP5, yet. (I have a very, very VERY large co
Re: (Score:2)
For example, say that you have a code library named Robert, which contains a class named Dole. Traditionally you'd define it like this:
class Robert_Dole() { }
With namespaces you'd do this:
namespace Robert;
class Dole() { }
And you'd use the class like this:
use Robert as Bob;
$myBob = new
Re: (Score:2)
From what you have described here, it looks like it will allow us to use some form of magic handler/config option to auto-load "modules"... kind of like the other language's "use" functions. While not true namespaces, it would be pretty handy for large CMS's, etc.
My biggest hope is that they use namespaces for all of the major modules such as GTK, even the DB's, and so on... but who knows for sure?
Re: (Score:2)
It will still be possible to set up autoloading with modules, but I have yet to see how it will be any better. Hopefully the usefulness will become apparent in time.
Braces on newline argument in book review? (Score:1, Insightful)
Re: (Score:1)
Re: (Score:1)
From page 448-
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.
Online tutorials are better and free. (Score:2, Interesting)
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!
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
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)
Re: (Score:2)
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)
Re: (Score:1)
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.
Re: (Score:2)
Reinventing the wheel (Score:5, Insightful)
If no one ever reinvented the wheel, we'd be rolling around on stone tires now.
Re: (Score:2)
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.
Re: (Score:2)
The problem is that php reinvented the stone tires !
Re: (Score:2)
Alternate chapter listing (Score:1, Funny)
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)
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
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)
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)
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.
Re: (Score:2)
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:
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
good book (Score:1)
congrats on the new book
That v. Who - the Relative Pronoun Debate (Score:4, Interesting)
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)
Re: (Score:2)
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
Re: (Score:1)
Good analogy (Score:2)
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.
Strange focus in review (Score:2)
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
Re: (Score:2)
"subsequent" should be "successive". I woulda gotten crucified for that too!
Re: (Score:2)
{ on their own lines (Score:2)
"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
Brace placement? (Score:1)
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.