As the title suggests this book is about advanced PHP related topics, being divided into 5 parts and 21 chapters. The title enunciates the book will cover many different aspects, but you'll get disappointed as soon as you perceive it's only about 300 pages.

First part starts with "OOP and Patterns" and will end up with PHP 6's new features. The Patterns chapter is the first one which disappoints you - you'll wish it was a little more verbose, covering some more patterns and being more than only 7 pages.

The next Part is about "Testing and Documentation", covering PHPDoc and DocBook in it's first chapter. In the next one about "Reflection API" - which I think is one of the best chapters - Kevin goes deep into two complete real world examples. But unfortunately then book disappoints you again, trying to cover some topics like "Development Environment", "Unit Testing", "Deployment" and "Continuous Integration" in just about 20 pages. Kevin just skims through introductory concepts of tools like Subversion, PHPUnit, Phing, Xinc and Xdebug.

The third part is all devoted to SPL. Kevin describes SPL from fundamentals to some advanced topics like "Array Overloading" and "Observer Pattern" in a way you wished that all of the book was written this way.

Part 4 covers another Pattern, MVC this time. Describing what it is, why it's good, and talking about criteria you may consider when choosing an MVC framework. Then it helps you to roll your own MVC framework by recommending to choose from one of the publicly available frameworks. The book also covers Zend Framework as one of those "publicly available frameworks" which meets the most criteria in his opinion.

And the final Part, and with no surprise it's titled "Web 2.0". In my opinion the first chapter of this part is the book's truly weakest chapter, it's about Ajax and JSON and it barely covers anything more than what you'll find in any of the beginner Ajax tutorials. But the rest chapters compensates, "Web Services" and "Certificate Authentication".

All in all I found the book a good one, a good next step if you are already familiar with PHP and looking for a book to extend your knowledge, then this one is a recommended one. But I by one would like to see some practical solutions applied to enterprise level when buying a book titled Pro.

With all the posts on interviewing PHP candidates popping up lately, I thought I’d post this draft that I’ve been sitting on for awhile that’s related to new jobs and interviewing candidates.

I’ve run into the Lone Wolf PHP Developer at several places I have done work. Sometimes, I’ve had to work side-by-side with the Lone Wolf. Other times, I’ve replaced the Lone Wolf who had moved on to different hunting grounds. Still other times I’ve had to hire people and had to choose between a Lone Wolf and several other candidates.

Just who is this Lone Wolf and why should we fear them so much? Here are some telltale signs of the Lone Wolf PHP Developer:

1. The Lone Wolf doesn’t understand how to work in a team of developers. They typically don’t even understand what benefits that would create. They do all development on their own, listening to very little input from qualified sources.
2. The Lone Wolf got to page 141 on Enter-A-Beginner-PHP-Book-Title-Here and no further. Objects? They’ve never heard of them. They must not need them.
3. The Lone Wolf re-invents the wheel for every project and doesn’t use standard tools and practices.
4. The Lone Wolf eats their young. OK, I made that one up. Frankly, how could a Lone Wolf have young anyway?
5. The Lone Wolf is perfectly satisfied with doing programming work on production servers and using FTP to deploy their code. It never occurs to them that they should strive to create development and test environments. It never occurs to them that deployment via FTP doesn’t scale higher then one developer.
6. The Lone Wolf doesn’t know what the letters SCM, CVS, or SVN are, or how to use them in their daily work.
7. The Lone Wolf never reads my blog or any other blogs on programming. The Lone Wolf may not know what a blog is.
8. The Lone Wolf says crazy things like “MySQL can’t do transactions” and somehow gets management to believe them.
9. The Lone Wolf was initially adored by management because they launched a lot of code live during their short stay. Too bad all that code is buggy and completely un-maintainable moving forward. Management doesn’t like that.
10. The Lone Wolf whips up incredibly stupid and unnecessarily complex solutions like template systems in which the templates are stored in a database instead of the file system/memory/cache. They shun using tried and true templating methods like PHP files, XSLT, or at the very least, Smarty. (see also: reinventing the wheel)
11. The Lone Wolf names variables after themselves that mean nothing to anyone else (ex, $lonewolfFlag )
12. And worst of all… The Lone Wolf PHP Developer fails to realize that there are other developers out there in the business world, trying to earn a living just like they are. By failing to conform to development standards that have been proven and tested, they make everyone’s job more difficult.

Now, I personally have run into this Lone Wolf scenario with other programming languages as well. But I think because it is so simple to work with PHP without much formal training that it lends itself to this problem much more readily then other languages. The blessing and curse of PHP is that it is the new VB 6.

Share this via del.icio.us, digg, email, etc.

We made it! Last Friday we have replaced the last two legacy components with their Zend Framework based counterpart: The gallery an the user registration. The whole site tilllate.com is now running on Trevi, our extension of Zend Framework. With a reach of 2.5 million unique clients a month, tilllate.com is one of the world’s biggest installation of Zend Framework.

Ciprian, Ivan, Jia-Yong, Kevin, Leo, Riv, Roger, Sanja, Thilo, Vanja, Vladimir and project manager Maarten have done a wonderful job reverse engineering the old, smelly spaghetti code and refactoring everything in a clean and solid MVC architecture: 115′480 Lines of code (Thanks StatSVN).

Custom DB layer

The first components of the refactored code have been released in December 2007. We observed the code to be much easier to maintain due to its good, DRY structure. We were really impressed by the flexibility and modular structure of the Zend Framwork. Some stuff does really look complicated in ZF (and sometimes it is), but through the flexibility it was really easy to replace components we did not like (or which were too slow).

We used specially the Zend MVC components. For performance and flexibility reason we wrote our own very light weight database layer. For configuration we used plain php files and Zend_Config which we extended only a little. We did use the Zend_Cache layer with memcached to cache our queries. For mailing we used eZ Mail.

Memoization for performance

Often it was very easy to hook components in or extend stuff in an easy, flexible and object-oriented manner. We extended some stuff in Zend_Router and Zend MVC to make it more suitable for our needs. After profiling we also extended some functions with Memoization which specially get Zend_Date and Zend_Config a big performance boost. As the P in the LAMP stack scales pretty good, we did not a lot other performance optimization there. So far there was only one php function we did cache because of speed reason.

Software defects decreased partially due to consistent use of unit tests. We have a quick bug detection thanks to a consistent exception handling and a ActiveMQ based logging infrastructure. But most of all, the code performs much better than the spaghetti version. This is due a systematic use of caching with memcache. The number of queries needed per page have been reduced by 80%.

Keeping up the quality

So far, I am very happy with the outcome. But some questions still remain: How much more productive is our development team now with this better quality code? How will the code look in five years from now? How can we avoid it to become smelly like the year 2000 dated spaghetti code?

Sebastian Deutsch blogs about the use of Traits for implementing Active Record in PHP. With traits, possibly impemented sometime in the future of PHP (5.4?), you at least do not destroy your object semantics anymore - even several problems persist with AR, as discussed earlier.

OK, so my selection of puns is not exactly "funny" per se, but it is true: php|tek is all about phar and variant spellings of the 4 letter word, such as "pear".  If you're in the audience for my talk about smart PHP application deployment using phar, PEAR and Pyrus, come say hello, I'm looking forward to meeting just about everyone I've argu^H^H^Hconversed with over the years, and of course you can also check out a copy of my book, I'll stuff a few into the luggage.  In other news, phar is tentatively enabled by default in PHP 5.3, marking the exciting next phase in all of the back-breaking work that has gone into it.  Check out the complete manual at http://php.net/phar.

Although I perform all the time as part of my day job as cellist of the Chiara Quartet, this will be a very different kind of performing experience and I'm looking forward to the challenge of revealing the true dynamism and excitement that I see in app deployment stuff I've been working on the past several years.

See you in Chicago!

Tried to follow the php|tek twitter but as has been quite typical lately the Twitter service continues to be sporadic.

I partially agree with Blaine Cook's blog post that languages per-se don't scale on their own. However, there are two things that immediately jump to mind:

a) It is much easier to find people who have actually scaled PHP applications, especially in the bay area.

b) Over the past years PHP and its extensions have undergone a lot of tuning to enable them to scale more effectively. This includes optimizing file system access, memory management and various other sub systems which will ultimately affect throughput.

Twitter team: If you have interest in considering PHP (and Zend Framework) drop me a note.

I'm in the hotel, ready for day one of the PHP|Tek conference tomorrow. I'm looking forward to quite a few things about this conference, including seeing a mass of elePHPants. Each participant will get one courtesy of Oracle Technology Network's sponsorship.

You can follow general conference happenings in various places:

http://twitter.com/phptek

IRC has a channel #phptek on FreeNode

I'm sure Planet PHP (http://www.planet-php.org/) will pick up various blog reports, and google will discover others.

I'll mostly be updating my twitter feed: http://twitter.com/ghrd

And don't forget to check out http://tek.phparch.com/live

I’m heading off to php|tek tomorrow. I’ll be giving 2 talks I hope to see you all there. I hope my slides are complete as well :-).

About 24 hours ago I woke up to drive to Brussels for a long flight to Chicago. The fact that this was 24 hours ago is beginning to show: I'm randomly falling asleep even in noisy underground trains.

But it's been a fun day. The flight was ok (watched national treasure 2 and ocean's eleven, both of which I've already seen but it kills time; and in between I read a book I'm reviewing). Getting from the airport to the php|tek hotel was only a short ride, and my room is huge: Separate living room and bedroom, 2 tv's even. (And perhaps a US thing: an empty fridge instead of a minibar).

Since I won't have much time to see downtown Chicago later this week, I went there this afternoon. Saw some nice things, had a nice diner, and went back to the hotel.

Right now I'm sitting in the lobby with a bunch of the people that are also hanging around in the #phptek IRC channel. With everybody having different IRC nicks and different twitter usernames, it's a bit difficult to know who's who though. Some people can easily be recognized from their avatar, but others look completely different.

There isn't much PHP news worth mentioning yet, but it's still only day -1. (Except maybe for the Zend news from today; I think Andi can expect some questions about that during his opening keynote on wednesday.)

In any case, I'm looking forward to the actual conference. Tomorrow is tutorial day. Still haven't decided if I'm going to sit in on the ajax, web services, social networks or phpunit sessions, or maybe just hang out.

Just by accident (you should never browse your feed reader directly before going to bed), I stumbled upon an incredibly self-ironic posting in some dude’s blog. I have to ask myself: What are you guys taking? Are you seriously discussing any kind of name-dropping as an interview subject?

It’s not only irrelevant who created a programming language, it’s even a hindrance for interviewers since all that small-talk bullshit takes precious time off the actual knowledge assessment. And I’ll be damned before I let someone who happens to know how Rasmus’s mother’s cat’s brother was named get in the way of an actual developer who knows what they are doing. Then again, I’m in the lucky position not to be able (or have to, depending on your PoV) to hire “PHP developers”.

This whole discussion is just fat bullshit. What are you thinking? I couldn’t give a fat fuck about people who know names. I don’t give a shit if someone knows that a dude wrote an, erm... “magazine” about security at O’Reilly or if some dude named Lerdorf thought it’s a great idea to do some dynamic web stuff. I want to know if people know their trade.

Really. It’s unbelievably ridiculous. Get a hold of yourselves. Are you really thinking that knowing names is worth ANYTHING?