Spring Into PHP 5 229
Michael J. Ross writes "A professional programmer could at any time be tasked with developing a nontrivial application using a language or Web technology with which he or she is unfamiliar. A common response is to quickly scan code snippets in Internet newsgroups and online tutorials, copy and paste code that looks applicable to the task at hand, and then lose valuable time trying to make it all work and control what was created -- not unlike Dr. Frankenstein's experience. A smarter approach is to learn the language basics in sequence as rapidly as possible, not getting bogged down in excessive sample code. For developers seeking to learn PHP using the latter approach, Steven Holzner's Spring Into PHP 5, published by Addison-Wesley, would be an excellent choice." Read on for the rest of Ross's review.
| Spring Into PHP 5 | |
| author | Steven Holzner |
| pages | 340 |
| publisher | Addison-Wesley |
| rating | 8 |
| reviewer | Michael J. Ross |
| ISBN | 0131498622 |
| summary | A comprehensive and no-nonsense primer on the basics of PHP. |
This title is another entry in Addison-Wesley's promising "Spring Into" series, which, as suggested by the name, is aimed at developers who want to jump into a new technology and get up to speed as quickly as possible, but without missing any of the essentials. In the case of Holzner's PHP book, this goal is pursued by presenting the information in so-called "chunks," with each spanning just a few pages. Every chunk attempts to cover only one or a few related ideas, and is designed to build upon earlier chunks. The bulk of the explanation takes the form of code samples, which fortunately are short enough in length and clear enough in composition to be easily digestible. This is in stark contrast to far too many other programming books on the market, whose code samples can span multiple pages, making it difficult for the reader to discern all of the ideas that the author is trying to get across -- especially when the reader has to flip back and forth between pages. Even worse is how some authors (such as Deitel and Deitel) use lengthy code listings -- sometimes even complete applications -- to demonstrate many ideas at once, which can be quite confusing, especially for the newbie reading about a challenging language for the first time. As Holzner notes in his preface, his book is example-oriented, with dozens of tested code samples. But none are overwhelming.
Spring Into PHP 5 was published on 12 April 2005. It is organized into nine chapters, covering a range of topics: PHP essentials; operators and flow control; strings and arrays; functions; PHP in HTML pages; Web forms and input validation; object-oriented programming and file handling; PHP and databases; cookies, user sessions, FTP, e-mail, and hit counters. The book has two appendices. The first one, on PHP language elements, is remarkably complete, considering that it only fills 18 pages. Owners of the book will likely find themselves turning to this material quite frequently. The second appendix lists the most commonly used functions in PHP, particularly those dealing with arrays, strings, and files. These two appendices combined go a long way to making this book more than an approachable primer -- it could serve as a reference book for the language for any reader not required to dig into the more obscure intricacies of PHP. Readers with those needs will have to use more detailed sources, such as the online PHP Manual.
Each one of Holzner's chapters explains the core concepts, using the bite-sized chunks mentioned earlier. This approach is somewhat similar to the "recipes" found in many books published by O'Reilly Media, and it works well here for introducing a computer language. Holzner's writing style is clear yet never condescending, and concise yet never cryptic. The intended reader only really needs an understanding of simple HTML and how to edit text files, to make this book worthwhile and usable. The book is meaty with information, and yet not too lengthy. This is a refreshing change of pace from countless other computer language books that are bloated with redundant sample code and overly wide margins, apparently in an attempt to entice the consumer with maximum page count per dollar.
Some programming books try to move the novice along at too rapid a pace, which can get quite discouraging if and when the reader is unable to follow the discussion, and particularly if trying to follow the author in building a working example. But a far more common mistake among programming books, is to drag out the process with humongous code listings or redundant verbiage (such as following the senseless rule of telling the reader something three times -- a technique that makes far more sense for speechwriting). Holzner sets and maintains an excellent pace, partly by keeping the code snippets reasonably sized, and partly through his modular approach of presenting ideas in chunks.
The physical book itself is well made and attractive, with a readable font face and size, and intelligent use of bolding to highlight those lines of code upon which the reader should focus. My only complaint in terms of the presentation, is that the gray background used for the code samples could be lightened up a bit, to make the text itself stand out more, especially the bold text. All of the screenshots are in black-and-white, which works just fine, as there would be no value in using color in the majority of the sample Web pages.
The author does an excellent job of explaining and illustrating all of the most commonly used and needed elements of the language. But he provides little guidance as to when a particular technique or approach should be used over another. For instance, when explaining how the programmer can use PHP to connect to a MySQL database, the author presents two alternatives -- direct layer and Pear::DB -- but no recommendations as to the choice of one over the other. On the other hand, one might argue that to include recommendations of techniques, as well as language best practices, would require the book to be much longer than it is, which would detract from the book's goal of getting a programmer up to speed on PHP in an efficient manner. The serious programmer who wishes to take PHP to the next level, can be expected to read more advanced books, to learn from expert PHP developers posting in online newsgroups, and to learn from experience as the programmer creates his or her own applications.
Another potential point of criticism could be that the book does not adequately explain how to use PHP with the various available database systems, only covering MySQL (the industry's favorite for use with PHP). But the database chapter, number 8, provides just enough information for the beginner to get started and to try out the basics. For simple database needs, the material in that chapter might be sufficient. Yet for more extensive MySQL usage, including installation and administration, other resources will need to be consulted. This book is clearly not intended to be one of those PHP + MySQL combo books that have proven so popular during the past few years.
The publisher's Web site for the book does not appear to have any collection of errata. Here are some that I found: On page 6, in the NOTE, "scripts can be used" should read "scripts cannot be used." On page 20, "#/ message to the user" should read "# message to the user." On page 49, in Table 2-4, in the last line, the formatting is partly wrong. Examples 3-1 through 4-14 contain incorrect indentation. On page 158, the last line in the $_FILES['userfile'] values is missing $_FILES['userfile']['error']. In Examples 5-19 and 5-20, the <head> and <h1> tags are missing ": Take 1." On page 169, the formatting of Example 6-2 is inconsistent with the others.
Aside from the errata, there were some other weaknesses -- none of them serious: The chapter summaries are useless, like in most other technical books, as there's not enough details to be instructive, and more details would make them even more redundant and space-consuming. On page 176, in Figure 6-6's caption, "Navigating" should be "Redirected." On page 197, the discussion of HTTP authentication is too brief to enable the typical reader to implement it. For instance, there is no mention of where to set $_SERVER[ 'PHP_AUTH_USER' ] to make it work. Chapter 7, on object-oriented programming and file handling, should be split into two chapters. Combining them makes no sense, and the author does not even transition from the first topic to the second.
Like others in the "Spring Into" series, this title is reasonably priced, at only $29.99 list for over 300 pages of quality material. The publisher, Addison-Wesley, has a page on their Web site devoted to the book, which includes a book description, a table of contents, an index, source code from the book, and a link for downloading a sample chapter (in PDF format), namely, Chapter 3, which covers strings and arrays. The site also has a link to a bonus chapter (also in PDF) that explains how to draw graphics interactively on a Web server and then send them back to the browser. Oddly enough, the page's title is "Spring Into PHP 5 - $20.99," but there's no indication as to how to get the book for only $20.99. That could simply be a typo. But there is a link to purchase the book online for $26.99. For those looking to spring into Web server-side development in general, or PHP in particular, it would be money well spent.
Michael J. Ross is a freelance writer, computer consultant, and the editor of the free newsletter for PristinePlanet.com. You can purchase Spring Into PHP 5 from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Re:PHP vs Ruby On Rails (Score:2, Informative)
Now you could compare Ruby to PHP or Rails to an mvc PHP framework like Cake.
But PHP against Ruby on Rails is Apples vs Oranges.
PHP 5 is trash (Score:1, Informative)
No accelerator: 1,746,752 bytes
eAccelerator: 782,576 bytes
APC: 772,200 bytes
Zend Platform: 333,856 bytes
Apparently the opensource accelerators just don't optimize PHP5's new object syntax much, if at all. Without any acceleration, the god damn script without any business logic uses more memory than the interpreter footprint!
For comparison, here are the same stats for phpMyAdmin 2.6.2-pl1 on this system:
No accelerator: 2,079,744 bytes
eAccelerator: 337,392 bytes
APC: 338,416 bytes
Zend Platform: 391,992 bytes
Notice the opensource accelerators come closer to Zend here. I think this is because phpMyAdmin is not written in the new PHP5 object syntax and uses the old syntax instead.
Basically Zend has made it so PHP limps along like a trash can unless you shell out $1500 per server. It would cost us over $15,000 to use Zend Platform, but without it we can't really move off of PHP4.
Pretty Home Pages (Score:2, Informative)
echo "TD> blah blah blah
echo "TD> and so on
echo "/TR";
echo "/TABLE";
ick.
And I remember somewhere it said PHP stands for "Pretty Home Pages"
wtf indeed.
I've just started to read this book... (Score:5, Informative)
Overall, this is a pretty good idea for a book, but the editors/author should not have rushed it to press - the quality of the book appears to have suffered.
I would strongly encourage a potential buyer of this book to spend several minutes with the book and see if the style suits your manner of learnig. Personally, I prefer the O'Reilly Learning series [oreilly.com] approach to teaching a topic, but preferences vary.
Re:Posting anon to protect the guilty (Score:4, Informative)
OO isn't a silver bullet. You almost always trade performance for development time and maintainability when you use it. That's not a bad thing and PHP minimizes the performance hit well enough to make it useful. In PHP its nice when the developer sticks to one or the other, though its obvious that most people don't because PHP is easy and the people writing it tend to be new to programming.
Strong typing isn't a silver bullet either, and I don't see how it makes your code more reliable. PHP tends to die when you perform numeric calculations on a string or vice-versa so problems can be fixed before going to production. I'd prefer it handle more like Perl where usually it does the "right thing" (it doesn't die at the very least).
Here's my problem list that I hoped would be fixed or at least improved in 5. (no such luck it seems)
Error handling is one of my biggest beefs with PHP. There are simply too many options and none of them are sane. Why can't we have a class as an error handler? Why is it that the error messages are spewed the screen as HTML by default? Why doesn't the command line mode revert to text only error messages? Why doesn't PHP just use the server error log like other languages and give you options to change it if you need to? That's what its there for!
References: Worse than PHP 4's objects are its references. Why can't I have references to objects or code? Why can't I pass a reference to any user defined or built-in function? (it used to work for user defined functions then they depricated it)? Seriously why does the function care if it has a reference or a value? To be fair I've heard some of these things have been fixed in 5 but I've still not found definitively if you can have code or object references.
Scoping: I suspect part of the problem with references are due to limitations in scoping. On the surface, having all locally scoped variables and specifying when you want to use a global one makes sense and keeps new programmers out of trouble. The problem is it leads to undefined variables everywhere when the programming forgets to use 'global $foo' in a function. This is also a problem that can be hard to spot initially because PHP doesn't bother to warn you if you've done that. The 'global' keyword also looks like a declaration so when I was first learning the language it was extremely confusing. PHP would be much more tolerable if they adopted something similar to Perl's strict mode where you declare your variable in the global, package, or local scope and it dies when you have variables that are undefined. This method is much better than having silently undefined variables.
Namespace polution: Why are there 14 billion functions I'll never use all in the same scope? Its silly. C came up with the idea of including what you need 35 years ago! Why are we regressing? Even if you don't like having separate namespaces, at the very least functions that go together could all be in a common file to be included and then you only import functions you need. And no OO won't solve this problem because all the core functions are still imported in, even in PHP 5.
Compiled modules: Why do I have to recompile PHP if I want to add image functions or some other module written in C?
HTML Centric: PHP centers around HTML (see my beef about the error messages above) This is a real annoyance if you want to output other things. Also the default embedding in presentation is irritating too. It was a bad idea with ASP, it was a bad idea with ColdFusion and its still a bad idea now and while the developers keep saying "you no longer have to embed it", so what? Make it where it can't be embeded. (yeah yeah, backward compatability and all that) Sure you can cause other languages to print out HTML using print statements, but its not the same. PHP is designed around embedding it within HTML. Print statements make obvious the need for templates. PHP makes a mess without making it obvious un
Re:I enjoy PHP ... (Score:3, Informative)
What I truly *meant* was: so many people out there are writing very basic-looking code, that, while it works, it's not optimal. It's not as efficient as it *could* be, and in my experience, writing more efficient code, especially code that's "hardened" or more secure, takes more advanced programming skills than a lot of the code I see out there. So, learning complex ideas, which you may NOT learn in these "learn ___ quickly" type of books, sometimes only comes from principles you've learned while writing in other languages. "Looking" more advanced, which I admit was poorly written in my original post, doesn't mean purposely obfuscating code for any kind of job security, but sometimes it's more efficient to write it in one way than another.
Take regular expressions for example... you could write 100 lines of PHP code to do strstr() calls in a giant if/elseif/elseif/elseif block to detect a string match in a block of data, or you could do a few lines of an ereg_* or preg_* call in PHP that "new" PHP programmers maybe wouldn't know about. If I didn't know Perl well enough to know regexp's, then I wouldn't have known that an ereg_ or preg_ call in PHP would do the same, and 5 or 6 years ago, *I'd* have been that guy writing 100 lines of strstr() calls to do what a single function could perform. Today, I work at taking someone else's 100 lines of code and reduce it to a much shorter block of more efficient code, using more advanced skills.
And based on conversations I've had with other people, yeah, many people do find Perl a little more difficult to learn with some of its cryptic syntax.
Sorry for the confusion of my previous post, and thanks for the laughs I've had over other people flaming my trigger-happy 'submit' skills.
Re:I enjoy PHP ... (Score:2, Informative)
Re:wtf? (Score:2, Informative)
Re:Pretty Home Pages (Score:1, Informative)
Now if Bill had named his operating system "WINDOWS Is Not the Devil's Own Work, Sandy". It would have been a lot better.
Re:Bogged down by sample code?? (Score:2, Informative)