Slashdot Mirror
Advanced PHP Programming
Many of the previous generation of PHP books were fattened with lots of filler: how PHP imports form-submitted variables into its namespace, definitions and examples of valid XML documents, one-line summaries of every PHP function, even an HTML reference. It's like going to Gallagher's Steak House and filling up on free bread. Ladies and gentlemen, may I submit the Atkins-Friendly PHP book. This is not a book about syntax or data structures. This is a book on how to use PHP in enterprise environments. During my first read, I realized around page 126 that I had already learned as much as I had expected to learn and I was just getting started!
The book is very well written, with a friendly tone that is neither pedantic nor partisan. A knowledge of PHP before version 5 is assumed, and the situations tackled are very much from the real world. The focus goes beyond getting what you want to appear in the browser, too; scaling problems of very large web sites, managing a code base with multiple developers, and building your own extensions to PHP are all discussed.
The author draws most examples from a Unix + Apache + PHP environment, and MySQL is the primary database used. The examples are all in PHP5, but many ideas can still be implemented in PHP4. In other words, you can still learn a lot even if you're committed to PHP4 for the near future.
Part I of the book is called Implementation and Development Methodologies (some of these part and chapter names could be a little less clunky, even if they are correct), and the first chapter is about coding style. After that comes a thorough discussion of the new features of PHP5. These are language aspects that are commonplace in other object-oriented languages (e.g., java and python), but which I admittedly knew little about:
- encapsulation: the ability to keep object attributes and methods private or protected;
- static attributes and methods to make class functions or singletons;
- user-definable constructor, destructor, accessor, mutator, and copier functions;
- interfaces, which are like abstract classes. A class can implement one or more of these as well as extend a concrete class;
- exceptions, which allow propagation of errors and warnings back up through the function stack.
Other PHP programming concepts are discussed in this part, such as templating, using the command-line interface, and unit testing. The chapter on Managing the Development Environment includes some CVS basics as well as how to organize and keep separate your development and production environments without breaking what works. Another topic discussed is when to use PEAR classes and when to roll your own.
Part II, Caching, is where the book gets hard-core. Once your application works, how do you optimize its performance and scale it so you can have hundreds of thousands of users?
- You can use static variables to reduce recalculations, and compile your regexps.
- You can cache data on the PHP level in flat files, DBM files, shared memory, or even in user cookies.
- There are also solutions outside of the PHP userspace. The ordinary PHP process takes the text which constitutes the programmer's code and compiles into a assembly-style intermediate code. Then the intermediate code is executed. If a script is executed several times without change, the same intermediate code is created, executed, and thrown away several times. A compiler cache saves this intermediate code and reuses it. The author has developed a free, open-source compiler cache.
- There are also code optimizers, which eliminate dead code and overly-verbose constants.
- Reverse proxies also work in web sites to reduce network latency. Latency occurs when a server is stuck waiting for a request to be completed before it can execute. A reverse proxy server only collects requests, then hands them off on a high-speed network to the actual server.
- This can be made even better with content caching. The proxy can determine if the request requires handling by the PHP webserver at all. If a stale, cached copy suffices, it is served instead.
- Content compression sends your data over the internet compressed. The client's browser is in charge of decompression.
Part III, Distributed Applications, is of big importance to the developer of medium-sized sites. The author discusses the familiar topics of database interaction (including how to troubleshoot your slow queries), authentication, and session handling. Then a chapter on clustering: how to arrange multiple, redundant servers to create a robust, fail-safe system.
The final chapter in this part covers another hot topic: Web Services. Say you want to edit your weblog entries on a real text editor rather than through a web form. If you have RPC (Remote Procedure Calls) set up on your web server, you need only write a script which manufactures a request to a web service and and ships it out. What's the sales rank on Amazon of the book you just wrote? What's the weather like in Medford, Massachusetts today? These are all jobs for web services. XML-RPC and SOAP are approaching the standards state of usage, so using one of these means you don't have to develop your own RPC client or server library. SOAP is even richer than XML-RPC: it's an all-purpose messaging protocol which is in use by many of the big players in web services (e.g., Amazon, Google).
In Part IV, Performance, the author returns to the optimization question. How can PHP scripts themselves be made to run faster? There are several techniques:
- Use the apache benchmarker or other load-generating programs to determine which requests take the most time.
- Use a PHP profiler such as the one the author has written to examine your script line-by-line and determine which function calls are most expensive.
- Use a synthetic benchmarker (such as the one included in PEAR) to analyze small bits of code and discover how efficiently they do their task. Which is faster: interpolation of variables or string concatenation (the latter, at least before PHP 4.3)? If you don't have a library compiled into PHP, can you implement all the functions in userspace efficiently (not really)?
Part V, Extensibility, is for people who want to adapt PHP on the language level for their needs. This part requires a knowledge of C and a strong grip on your hat! After a discussion of PHP and Zend Engine (the virtual machine on which compiled PHP runs) internals, the author shows how to make both simple and complex extensions. You can add new functions to PHP, add a suite of library wrappers, add and manipulate classes and objects, all using pre-defined macros. In the last chapter, you can extend Zend itself to (say) implement all errors as exceptions, create a PHP Shell, an opcode-dumper, or modify the author's compiler cache or profiler.
I very much enjoyed the book. I have chosen to take the plunge into PHP5 for a new web project, partly because this book convinced me it's worth it. I can't imagine I'm going to use everything I've learned from the book, but I'm glad to know how problems like these are solved.
There are a few typos and misspellings, but that's to be expected in such a large book with limited turnaround time. Definitely recommended.
Matthew Leingang is a Preceptor in Mathematics at Harvard University. He continues to try to integrate web development into his day job. You can purchase Advanced PHP Programming: A practical guide to developing large-scale Web sites and applications to PHP5 from bn.com. Slashdot welcomes readers' book reviews. To see your own review here, carefully read the book review guidelines, then visit the submission page.
Sigh, I really wish these books would get with the times and start using PostgreSQL (or even Firebird) and Apache 2.x (I assume the book uses Apache 1.x since the PHP developers seem so against 2.x).
John Kerry is a Joke!
Isn't that why we have used books? Ebay, Amazon, Half.com. I'm sure somewhere you can find a book for an older version of a piece of software.
no comment
I know what you're talking about, and you're right: new books are about new software.
Your point about web hosts is also true; it's difficult to find a PHP5 webhost. It takes guts to run a RC on production servers! However, you can be certain that soon enough PHP5 will become as ubiquitous as 4.
Anyways, just judging by the review, it seems like this book's intended readers are enterprise programmers: people who will leverage more control over their development platform than the average webmaster.
This seems to be a really common misconception among readers of slashdot. The truth is this:
- PHP developers are not opposed to Apache 2.x.
- PHP is stable on Apache 1.3 _AND_ 2.x.
- Apache 2.x has a large number of new features designed to better handle high volume sites (with or without PHP)
MySQL is still the standard web-hosting provider database backend, that is why most books cover it. mySQL is very similar to other SQL dialects. If you understand SQL, PostgreSQL is easy and you shouldn't need explanation on how to run queries from PHP. The books focus on PHP, not the SQL languages... if you want to learn about SQL, get a SQL book.
There are times when to use a strongly-typed, "true" OO language like Java or C++ and times to use a scripting language like PHP or Perl. Part of being a good programmer is being smart enough to use the right tool for the right job. If you want to torment yourself by over-engineering a small- or mid-sized website in EJB, go for it, but respect those who like being able to get stuff up quickly and easily, with a minimal learning curve. And YES, it is possible to build secure web apps in PHP, despite what you may have heard.
When you've only got a hammer, everything looks like a nail.
Atkins-Approved? What the crap is that?!
(I know what it means, but what is it doing here?)
The Sacred Chao says, "MU".
The issue is not weather PERL or PHP or C is better than the other.
Languages are just tools. Writing good software is a reflection of one's ability to plan, use OOP, and troubleshoot code, just to name a few.
When faced with a problem that needs solved, you examine the problem, and select the most appropriate tool(language) to get the job done, and hopefully you apply good software writing skills to the solution.
Even if you think PERL or something is so much better than PHP, but you suck at writing good software, your software is going to suck.
PHP was originally developed to make web programming easier in the same way Bash makes certain operating system tasks easier. PHP:Web::Bash:OS. ... The problem is you can't have both Bash-like scriptablity and Java-like power/maintainability. So PHP will take the road of Visual Basic -> VB.NET.
PHP5 is impressive, but it appears to be trying to change its scope and here is why. Like Bash, PHP is a big time saver for small programs, but is more difficult to write and maintain as the program gets larger and more complex. The features added to PHP5 will let it scale better, but it will lose its Bash-like advantages. It is trying to move into the arena with Java, ASP.Net(?Maybe), Python, Ruby,
After seeing MY limits with PHP I moved to Python although I still use PHP for simple web scripts. In my opinion, PHP5 is a new language in an old arena. You should choose the right tool for the job, and if you need the new features in PHP, have a look at a powerful, weathered language like Java, Python, or Ruby, or (add your language here).
I see a lot of posts making 'fun' of PHP/Apache/MySQL. Especially things like large scale applications, hard/difficult maintenance on larger projects and not good at scaling.
Well. That might be true.... For those few sites which actually DO require 'scalability', easy maintenance when the project get bigger and the target is millions of hits per hour/day for some really heavy computations and what-not.
But there are SO few of these projects around. So for all of you who thinks php stinks at least try to use the right tool for the right job. From my experience in web-application development in Norway almost every large software company will recommend some closed source, inhouse made, 'superheavy' application for whatever site you want to have. They will use every argument you post here to put their software in a better light than some 'light weight solution' like PHP/Apache/Linux/MySQL/postgresql.
Seriously, almost no web-sites in Norway targeted at norwegians will ever require 'large scale' solutions. There simply aren't enough people around. Still the companies will push forth their solution on unsuspecting customers.
I had a e-commerce site I made (using php/apache/mysql, python/perl for backend functionality running on TSLinux), reviewed by a respected IT-consultant company in Norway (Bekk - http://www.bekk.no/). Their conclusion was that it was a good solution, well written, but.... "It should have been made in a java/C# or something like that" Why? Because of scalability.
It's just absurd. They really don't take into account the target marked for the solution. And the current system setup is running just fine and dandy without any trouble. Should the number of visitors increase ten-fold (which it never will), well... Add some slave database servers and more webservers.
Suddenly you have the board of directors going: -Uhm, why didn't you write the system in Java. We hear Java is a good thing. Java is scalable. Java is more secure.
Why? Because it took me such a impossible short time to make the site with php and it's been going for 2 years now, without problems. That's why.
The solution they would have otherwise chosen would be 10-100 times more expensive, would require expensive servers and would probably take years to develop.
I think the most difficult decision is which tool/language should you use.
If you are a programmer it's always good to look around, see what this language can do, specially if better/faster than the current one.
When you have a software house this can be tricky. I've been doing some development from small sites to small applications and every now and then comes a question: should I change to java (jsp) ?
Seems that the EJB-something is a great thing but only pays if you have really big projects, otherwise you will end up having a complicated setup to do a simple thing.
OK, I'll byte. (1) Database access from a website. (2) Form manipulation. Name one other language or system where it's easier to dynamically create a set of html pages with data extracted from a database. Or a language where it's easier to get and use data from a form filled by the user.
Are you kidding ?
1) Java's db api is much more cleaner and database independent, You don't have to rewrite your function calls to switch the database implementation (e.g. moving from mysql to postgres and from postgres to oracle, in java you will only have to switch the string which chooses the db driver, in php you will have to rewrite all the code implementation that has [dbname]_connect, [dbname]_query etc. calls.). the same goes for perl. and python. imho this is seriously f_cked up in php, using the word 'clean' here is absolutely n00bish. and how to you update a blob from php ? (thinking SELECT bar FROM boo FOR UPDATE) ? it's simple, you just can't.
2) every proper MVC system has an implementation on DBForms which creates default forms from database structures without needing any kind of input in the code except the table name (input fields types & values are generated/validated/handled automatically). in php i have seen such features only in frameworks alike (php doesn't have any kind of dbforms implemented by default). so php doesn't really make anything "easier" here.
the worst in php in my experience is that i have to worry about how to get & feed my dates'n'times to the database, in java it's very simple, i always have one type of timestamp, no questions asked. in php i always have to be very aware of my DB behind the datamining cause it doesn't give me the same type of variables while asking them from mysql/postgres/oracle/sybase, if i want to compare the query result from different database types, i'll have to convert the timestamps in my code to compare them. this is pretty much absurd. at least for a "high level language".
so i can't really see how php is superior in any way.
it's backward compability is mostly zero. the dudes over zend just think that hey, let's make now php5 and break the whole OOP stuff that we had until now. (we're probably going to rewrite our 'framework' over here, to make it work again.
besides until there's no threading and variable sharing possibility, it's still far behind perl & python.
for a schoolboy, php might be cool. for a developer that has been working with code since 1990, it seems like an vegetable hamburger (sure it's edible at some times, but i prefer pizza,pasta or a proper meal with some meat in it.)
I'd tell you the chances of this story being a dupe, but you wouldn't like it.