PHP 5 in Practice 116
Michael J. Ross writes "Computer programming books come in all varieties, but there are at least four general categories: introductory texts, which typically have the lowest content per page; language references, which have become increasingly supplanted by online sources; "advanced" treatments, which are often a mishmash of errata-riddled articles; and "how-to" books, usually at the intermediate level, and sometimes presented as "cookbooks." It is that last category that has been growing in popularity, and for good reason. When an experienced software developer needs assistance, it is rarely for language syntax, but instead a desire to see how someone else solved a specific problem. For solutions using the PHP language, one source of information is PHP 5 in Practice." Read the rest of Michael's review.
PHP 5 in Practice | |
author | Elliott White III and Jonathan D. Eisenhamer |
pages | 456 |
publisher | Sams Publishing |
rating | 8 |
reviewer | Michael J. Ross |
ISBN | 0672328887 |
summary | One of the most meaty, immediately useful, and fluff-free PHP books available |
The book was authored by Elliott White III and Jonathan D. Eisenhamer, and put out in July 2006 by Sams Publishing (an imprint of Pearson Education). Given today's standards of hefty technical books, this particular one is relatively light, weighing in at 456 pages, which are organized into an introduction, numerous chapters, and three appendices.
Its introduction is more interesting than that of most similar books, whose introductions usually consist of formatting conventions and explanations as to why the book was written — all such content providing little to no value to the impatient programmer facing a deadline, and invariably ignored (the content, that is, not the deadline).
White and Eisenhamer took a refreshingly different tack, and chose instead to explain their use of coding standards, comments and whitespace, braces and parentheses, PHP short tags, PHP mode, and other language considerations that are more useful than the typical rundown of somewhat childish icons used in other texts, such as light bulbs and red warning signs.
Switching to the other end of the book, we find three appendices. The first one briefly discusses issues one might face in migrating from PHP version 4 to 5. The second introduces the Standard PHP Library (SPL), and the objects related to its primary design pattern, the Iterator. The third appendix discusses what composes the bulk of output from my PHP programs: error messages. Seriously, this appendix is worth reading, if only for the suggestions as to what to look for when you encounter some of the most common PHP error messages.
The bulk of the book's material is divided into 20 chapters, which are themselves divided into two parts: PHP internals, and applications. The internals are: strings, numbers, time and date, variables, arrays, functions, classes and objects, and files and directories. Starting off with a discussion of strings, might seem odd to the neophyte programmer, but to the veteran who has had to learn several languages during their career, the choice makes a lot of sense. There must be countless developers out there who, being fluent in the C language and object-oriented concepts, jumped into writing their first C++ program, and had to hit the books for the first time when they wanted to do some non-array-based string handling.
The book's second part covers some of the most common applications in PHP programming: Web page creation (using XHTML and CSS), Web form handling, data validation and standardization, sessions and user tracking, Web services and other protocols, relational databases and other data storage methods, e-mail, XML, images, error reporting and debugging, and user authentication and encryption. That last chapter, in the next edition, should be relocated so that it precedes or follows the chapter on sessions and user tracking.
Many of the chapters begin with a "Quick Hits" section, which briefly summarizes how to perform many of the most common and essential tasks related to that chapter's topic. For instance, in the chapter covering the use of variables, this first section explains how to: check if a variable has no value or if it is empty (not synonymous in PHP), undefine a variable, cast it to a certain data type, and do the same thing for a value. There is one minor erratum that should be noted: On page 71, in the first "Quick Hit," it reads "a variable has bee. given a value." ("been"'s "n" ended too soon.)
Each section within the chapter briefly explains the problem domain, and then presents sample code to solve the given problem. The code itself is fairly well commented, and the variable names are adequately descriptive (unlike in some programming books, whose coding standards border on the criminal).
All in all, the book offers a lot of worthwhile solutions to a wide range of problems, and does so in a straightforward manner. It is for this reason that it is not evident as to why this particular PHP title has received so little notice. For instance, on Amazon.com, it has received only one reader review, as of this writing, and does not even make it into the top quarter million books ranked in sales by Amazon.com. It is a pity, because the book deserves much more attention.
Even though this book is to be recommended, and is packed with code and text that are well worth studying, it has one unmistakable weakness for which this writer can think of no adequate justification. The book contains almost no illustrations, even when they are clearly called for — in fact, especially in those cases. For instance, the section that shows how to generate a calendar, does not show a calendar! The code is present, but the sample output — which is what the poor reader would appreciate, to see the results of the code — is missing.
Granted, an absence of figures and screenshots might be understandable for the first part of the book, which covers the PHP language itself. But the second part, covering applications, has far too many unillustrated PHP scripts. These include sections focusing on drop-down menus, progress bars, and graphical charts Web forms. In the last chapter, there is a section with code that generates captchas, but the reader is not shown what they look like. The entire 18th chapter is devoted to images, but contains not a single one! I cannot imagine why the authors and/or publisher chose to leave out these essential graphics. Was it to save money? Whatever the reason, it was a significant mistake, and one that should be corrected in the next edition.
Readers who agree with this assessment, or who have other thoughts concerning this otherwise excellent book, can leave feedback via the book's Web page on the Web site for Sams Publishing. This page offers details on the book, a description and table of contents, links for requesting instructor or review copies, and a tool for searching the book's contents within the Safari online technical library. The book's introduction states that the Web site hosts all of the code listings, as well as a list of errata. Yet, I was unable to find either one. (Sadly, the Pearson Education sites are still some of the least usable in the technical book publishing world.) Much better results were obtained on Eli White's site.
Despite an inexcusable and almost complete lack of needed illustrations, PHP 5 in Practice is possibly one of the most meaty, immediately useful, and fluff-free PHP books available. No serious PHP programmer should be without it.
Michael J. Ross is a Web consultant, freelance writer, and the editor of PristinePlanet.com's free newsletter. He can be reached at www.ross.ws, hosted by SiteGround.
You can purchase PHP 5 in Practice from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Opposite way of thinking? (Score:5, Insightful)
Re:Opposite way of thinking? (Score:5, Insightful)
Congratulations, you have discovered the difference between "experienced software developers" and computer scientists. Computer scientists know what they need to do and how to do it, so long as they can express it in the language they're using. Experienced software developers often know incredible amounts of detail about programming languages, but not necessarily about advanced algorithms and data structures.
Re: (Score:1)
Computer scientists know what they need to do and how to do it, so long as they can express it in the language they're using. Experienced software developers often know incredible amounts of detail about programming languages, but not necessarily about advanced algorithms and data structures.
So does that make Computer Scientists better? Or software developers? Which is more important, knowing advanced algorithms and data structures, or knowing the intricate details of a programming language so you can optimize that much more.
I'm just a lowly college student (EE) so I don't know the answer.
Re: (Score:2)
Re: (Score:3, Insightful)
Knowing about algorithms and data structures is more important than knowing the detailed specifics of any particular language, since they illustrate more different ways to tackle a problem and seem to be harder to learn (well, for many people). It's also good to know lots of different languages, again because it effectively gives you more too
Re: (Score:1)
For example you can know that the Quicksort algorithm has the best characteristics for your task but be forced to implement it in a language you don't know OR you can know that someone else implemented Quicksort in your language and not know if it's properties are what you need. In both cases where you only know one or the other, you are using time. If you knew both, you potentially used zero time (knew it was the right algorithm for the task, knew that the language or a libra
Re: (Score:3, Interesting)
If you're a compu
Re: (Score:3, Insightful)
And true software engineers know both. :)
Re:Opposite way of thinking? (Score:4, Insightful)
As someone who knows fourteen programming languages, but also has a degree in CS with a minor in math, the reason for the that practice among software developers is not because they don't know how (although, admittedly, I've met a few who probably couldn't write low level stuff for themselves), but because there's a best practice way of doing a lot of stuff in any given environment.
In other words, you try to do things the same way that most people who use the language do it so that your code can be used by other people, and so that you can use other people's code to help you do it. Otherwise you have to reinvent the wheel a lot.
Programming languages are a math unto themselves. It's pattern recognition, and "speaking" the languages is the crux of most of it. A CS program should teach you how to learn them quickly. The seasoned programmer, whether CS grad or experienced developer, should be the ability to think in different languages by understanding the differences in their patterns.
Re: (Score:2)
For description languages, such as XSLT or VHDL, it's more like 100.
If your definition is stricter than that, fine. For my job I use Java, C#, Perl, HTML, Javascript, XSLT, VB, a few variants of SQL,
Re: (Score:3, Insightful)
Re: (Score:1)
Re: (Score:2, Interesting)
Thats a problem where you are not familiar enough with the syntax of a language. I would probably guess its because of your limited experience with it.
Thats a problem that even very experienced developers hit often, this is exactly what you were talking about in your (the parent to this
Re: (Score:1)
Re: (Score:2)
Yes.
Re: (Score:3, Insightful)
Actually the most common problem is usually a small typo, that I don't see for three hours...
Re: (Score:2)
Actually the most common problem is usually a small typo, that I don't see for three hours...
Heh, I know those little gotchas better than I'd like. It seems no matter how experienced I am with the language du jour [ldj], I'm going to lose some time to one or two of those guys every week.
But when I'm starting work in a language that is pretty new to me— PHP at the moment— what I'm most uncomfortable about is whether I'm choosing a suitable approach to the problem at hand. For an instance, with parsing and lexing issues, Perl's regular expressions make for some elegant ways to finesse
Re: (Score:1)
Re: (Score:3, Insightful)
Yes, but I think it also speaks to the level of challenge to your comfort you've been faced with. There are three major roadblocks programmers run into:
Re: (Score:2)
Re: (Score:2)
Buy my forthcoming PHP book instead (Score:3, Funny)
Re: (Score:1)
Where's the security section of the book? (Score:5, Insightful)
What PHP needs is not more features, but better designed security model.
Re: (Score:2)
While improvements in security should be high on the list of PHP development objectives I think PHP gets a bad rap for what are short comings in the design and coding of the applications written in PHP.
Many PHP applications are designed to use a single database user for all queries against the application database thus providing the equivalent of admin or root access to the application database if a security bug is found in PHP or in th
Re: (Score:2, Informative)
Application security should _not_ be the responsibility of the programming language. It should be the responsibility of the application developer.
Couldn't agree more!
Not to mention that PHP security is not that difficult to implement! If you verify =all= of your input (which you should be doing anyway, in any programming language, for any application), you've solved most of your security issues. If you allow a $_GET variable to go straight into an include statement without testing/filtering/verifying/SOMETHING, you don't understand security in the first place.
Re: (Score:2)
allow_url_include is Off in php.ini-recommended. You have to do something wrong to allow external includes.
Re: (Score:2)
[root@lnx_10kclust etc]# grep allow_url
allow_url_fopen = On
Here's the problem... in *most* cases, people just install the software and unless they have to change a default value, they won't. What PHP should do is have this feature turned off by default and then state in the ini file why it's turned off and by turning it on what the ramifications of that would be.
I guess I'm just one of thos
Re: (Score:2)
allow_url_fopen is still On by default, because it's used in fopen(), file_get_contents(),
Re: (Score:2)
What PHP needs is not more features, but better designed security model.
Noone is putting a gun on your head to do an external include on a random external file.
*Any* reasonably flexible language allows you to shoot yourself in the foot, if you so desire. This is why serious programming is best kept away from little children.
Missed it by one... (Score:2)
Re: (Score:1)
Re:PHP is... (Score:4, Funny)
Thus, the title of the next PHP book should be along the lines of "How To Write Real POOPy Code".
Re: (Score:1, Funny)
I think... (Score:5, Funny)
Re: (Score:1)
Perl can do it too. Look up Template::Toolkit on the CPAN. Mason does it too, if i recall.
Re: (Score:1)
class myClass
{
function someMethod() {
}
}
x = myClass::someMethod();
Re: (Score:1)
register globals - has anyone in the last four years ever located a PHP installation that uses this? Agreed this was a horribly bad idea, but long since been fixed.
confusion about escaped quotes - so the programmer can get confused, therefore the language isn't good enough?
osCommerce, one of the most widely used open source PHP packages, fails on both accounts. Most open source PHP projects I've seen suffer from one of those shortcomings. I've also seen plenty of server-generated emails and input fi
Teaching Bad Practices (Hopefully Not) (Score:3, Interesting)
So here is my point, all the tutorials, examples, and books that the neophytes are using to learn are _WRONG_. They are teaching _BAD_PRACTICES_. Because PHP is necessarily meant to be in a network environment (excluding the rarely used cli) and it WILL be exposed to potential maliciousness, secure practices should be taught markedly at the beginning, not as an aside. So as part of teaching how to pass form parameters they should include validation code, even if they have to comment that section as "
I think PHP is a great language for its purpose, which is simple web-apps. Lots of the criticism about its brain-dead defaults is correct, but they can be overcome with good practices by the application developer. PHP can be great, but it is typically taught wrong at the beginning and that just snowballs.
The editors and authors all the PHP books and tutorials out there need to make sure the new editions encapsulate good practice at the beginning of the learning process.
first disclaimer- I haven't read this particular book. I hope it is better than the other PHP books to which my comments apply.
Second, disclaimer- this is mostly a repost from my post [slashdot.org] at this discussion ( PHP Application Insecurity - PHP or Devs Fault? [slashdot.org])
Re: (Score:2)
So here is my point, all the tutorials, examples, and books that the neophytes are using to learn are _WRONG_. They are teaching _BAD_PRACTICES_.
Yes. Sort of.
I first encountered this when I was involved along with 2 or 3 other guys in helping a neophyte Delphi programmer write an inventory system for her husband's plumbing business. This was back in the days before time, when the intarweb was still Darpanet so all of us were using CompuServe. She would run into a snag trying to apply something from Jeff's book or the Borland manuals, post about it, and we would try to help her figure out why it wasn't working in her application.
After a while,
Is there a GOOD book on PHP "System Development" (Score:2)
Captchas (Score:2)
What the hell? How can you write about captchas without showing pictures?
How else do you get this point across properly?my recent delvings (Score:1, Funny)
A. Funnier than GWTW
B. Just as funny as GWTW
C. Not as funnier as GWTW
Your valued insight into this fine work would be greatly appreciated and it would help me make my next book purchase easier.
Thanks in advance.
Another big, fat book of examples. Yawn (Score:3, Insightful)
Another one of those huge low-density books of examples. Do we really need another one.
What's really hard today is finding a good reference manual. The original manual for Algol was 17 pages. The original manual for Scheme was 21 pages. 456 pages for PHP is a bit much. A big plastic card that boiled the language down to two pages - now that would be useful.
Re:Another big, fat book of examples. Yawn (Score:4, Informative)
http://www.ilovejackdaniels.com/cheat-sheets/php-
Enjoy
Useful cheat sheets. (Score:2)
Now that's useful.
Today I could use ones for Perl and Python; I'm converting someone else's regular expressions from Perl to Python. Both have almost the same syntax.
As a longtime(past tense) PHP developer I can say: (Score:3, Informative)
With languages like Ruby, Python, Perl, etc. around, why bother with PHP?
PHP has:
It does however have a good documentation. Without it though, programming PHP would be impossible. Try coding PHP without the documentation at hand.
"Was it function_name($foo, $bar) or functionname($bar, $foo)? Or rather prefix_function_name($foo,$bar,$baz) where $baz is always empty?"
I could go on and on. These are just the facts. What I ignored are the countless hours I wasted trying to debug some perfectly good looking piece of code only to find out in the end that PHP is the problem. On that occasions PHP ate away a part of my soul. (pretty poignant, eh?)
And yes, in case you wonder, I did very large PHP stuff. Megabytes of code in CVS. Luckily no more. (Could be written in kilobytes of Ruby anyway.)
Re: (Score:1, Troll)
I could go on and on. These are just the facts. What I ignored are the countless hours I wasted trying to debug some perfectly good looking piece of code only to find out in the end that PHP is the problem. On that occasions PHP ate away a part of my soul. (pretty poignant, eh?)
Are you SURE it was PHP? I wonder how you could spend "countless hours" debugging PHP code? I've been at the PHP language for years and the one thing you CAN say about PHP vs other languages is that it shouldn't take "countless hours" to debug. I mean...countless hours? Ate your soul? Perhaps programming isn't really for you. Maybe sales? or marketing?
Re: (Score:3, Interesting)
You are right. It shouldn't take countless hours to debug. Note my emphasis. Debugging code written by a sane developer in any sane language would not take co
Re: (Score:2)
Yet the world is full of programmers which abuse PHP to a level where you start to get the feeling that a complete rewrite of "the thing" is "the way to go"
so is it the language's fault or the programmers fault? you seem a bit confused.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Insightful)
Sure, it's possible to write bad code in any language. But PHP is like the BASIC of the web. Popular, (yes, there was a time BASIC was popular) yet treated with contempt because it's just so easy to shoot yourself hard in the foot. At least with C, you usually kn
Re:As a longtime(past tense) PHP developer I can s (Score:1)
Hide the kids; here comes another language/paradigm holy war....
Re:As a longtime(past tense) PHP developer I can s (Score:3, Interesting)
Namespaces are upcoming in PHP6 (again, AFAIK).
The rest of the observations are correct to the best of my knowledge and make PHP quite a horrible choice for all projects beyond a certain complexity
Re: (Score:2)
That's nice. Is not segfaulting when the stack depth is exceeded also a planned "feature"? Because every report on the problem is still WONTFIX.
Picking on PHP just isn't worth the effort anymore. Nor is waiting for it to be fixed.
Re: (Score:2, Interesting)
In perl's defense, I think that's sometimes the biggest reason I choose perl over the others. The good thing about duplicating or reinventing the wheel is some
Re: (Score:2)
You are wrong because you obviously don't have experience in this area. PHP is quite capable for deploying large, enterprise-grade (not judged by the number of users using it, but by the quality of the processes involved and the business functionality it serves) software without a lot of headaches.
I treasure PHP and all of its shortcomings an
Re: (Score:1)
I fail to see how one can treasure the shortcomings and inconsistencies of a development language (especially give that you expect t
Re: (Score:3, Informative)
So why do you post anonymously? :-)
Please do. I am sure they are 1. already fixed or 2. not present in the new parser (YARV) which is going to be Ruby 2.0
I began coding PHP around 1997. Then I did not know better. Now I do. Although I generally program
Re:As a longtime(past tense) PHP developer I can s (Score:1)
Re: (Score:1)
Re: (Score:1)
Re: (Score:1, Insightful)
Re:As a longtime(past tense) PHP developer I can s (Score:2)
Re:As a longtime(past tense) PHP developer I can s (Score:1)
Not all programming languages have and need this.
no usable object-model (check out response of developer below!)
self is bound at compile time. That's how it's defined. If you want to create active records like in Ruby just wait for PHP6 (currently the keyword is static).
problems with recursion
Infinite recursion is a problem in all programming languages - and a mistake. Several extensions help to avoid the segfault.
countless other horrible mi
Re: (Score:2)
Wow. That alone is enough to just make me double and triple take with WTF's. The very construct that is supposed to represent late binding in every other language is deliberately and specifically early-bound in PHP. In an otherwise duck-typed language, even. It's like the PHP devs read a book on object oriented design and then designed the language specifically to defeat it.
Re: (Score:2)
Re:As a longtime(past tense) PHP developer I can s (Score:1, Interesting)
Re: (Score:1)
Re:As a longtime(past tense) PHP developer I can s (Score:1)
Re:As a longtime(past tense) PHP developer I can s (Score:1)
I believe people hate php as much as they have experience in programming (and inversely, beginners usually enjoy it)
Short answer (Score:5, Funny)
Way shorter book summary:
Don't.
You'll get no disagreement here (Score:2, Interesting)
More good PHP Books (Score:2, Interesting)
Here is a good source for browsing PHP Book Reviews [top-books.org]. PHP In Practice [top-books.org] hasn't made the top 50 yet.
programmingbooks.org (Score:2)
http://www.programmingbooks.org/PHP [programmingbooks.org]
There's a lot of horrible programming books out there. I wrote this web app to help programmers easily find the good ones. Basically programmers rank their top 5 books based on category(in this case, php books). It only works if people use it though, so rank the good programming books you've read!
Picture books? (Score:1)
Wonderful! (Score:2)
(I kid, I kid)
Blah Blah Blah!!! (Score:2, Funny)
Some uber programmers doens't like PHP because of someting else... Then start to bashing again and again
Php can't do this, can't do that. Php can't scale, Php was ugly, yada yada yada....
First purpose of Php was templating engine for HTML.
Other things comes afer.
Also, Zend try to add OOP. WHY? Why we need OOP aproach, run once scripts...
In php you cannot store objects in the Memory by default... (if you not use Memcaced/Seralize things)
I still don't get it. It was stateless universe. E
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
i do know that it bothers some people (though i don't understand why) so i always mention that it is an associates link in the post and never post it ano