There have been a few posts around the community related to the OXID application ever since the Zend Developer Zone posted the latest article in a series looking at using their eShop software. The quality of the application came up and several even questioned the "94% code coverge" they claimed.

Some of the posts on the matter include:

• Demian Turner's "PHPterror on OXID eShop"
• Arno Schneider's "oxid esales - the extend parade
• The PHPTerror article that caused some of the problem

However, in this piece from Lars Jankowfsky he tries to set the record straight on a few things:

As I am the guy who introduced the disliked functionality many years ago ( actually years before ZF popped up) I feel the need for a statement to put the things into the right order. Please note that I did work for OXID in the past (years ago) but I do not nowadays.

He responds to the criticism of the way modules/classes are used in the eShop application and the comments about the test coverage claims made without the proof released to show it's true.

In this new post to the PHP 10.0 blog Stas has some responses to the recent suggestions from Google as to how to optimize your applications.

There are a bunch of advices there, some of them are quite sound, if not new '" like use latest versions if possible, profile your code, cache whatever can be cached, etc. Some are of doubtful value '" like the output buffering one, which could be useful in some situations but do nothing or be worse in others, and if you're a beginner generally it's better for you to leave it alone until you've solved the real performance problems.

He mentions four things that need amending from what Google suggests:

• Don't copy variables for no reason
• Avoid doing SQL queries within a loop.
• Use single-quotes for long strings
• Use switch/case instead of if/else

On his blog, till has posted the second part of his testing on the Zend Framework and its performance in general usage tasks.

A disclaimer which I should have added to my last article would include that most of my pseudo benchmarks are very subjective and also way too basic. For example, our server setup is pretty comprehensive but we have to take everything into account in order to provide real benchmark. And when I write everything I mean CPU (cores), RAM, motherboard, HDD and so on. Maybe even the throughput of the network card -- if it's different.

This second post is an attempt to correct some of the sore points from the previous one. Here's a list:

• require/include(_once) and __autoload, or "Why is __autoload() 'better'?"
• Zend_Loader ERRATA
• Caching database results
• Zend_Db
• Zend Framework (what it currently lacks)

Correcting himself from some previous comments concerning PHP 5 versus PHP 4 usage among developers, Marco Tabini has posted something new to his blog with some updated stats.

In the past, I have not been shy about sharing my opinion that the impending death of PHP 4 would have wreaked all sorts of havoc over the PHP world. I am glad to say that I've been wrong - dead wrong, in fact - and that I have never been as happy to be so far off the mark before.

According to a readers survey that the php|architect magazine ran (about a year ago even) PHP 5 is stronger than ever, taking up well over sixty percent of the usage with only a small part still hanging with PHP 4. Check out his graph for the full rankings.

Matthew Turland has a few things to say about web scraping (and recent articles covering it) on his blog today as an author of a previous article published in php|architect covering the same topic:

A friend of mine who shall remain nameless pointed a post out to me on the PHP DZone web site recently. Noting that the article's content was misinformed at best and downright ignorant at worst, even when examining it sheerly from the author's knowledge of PHP as a language, this friend asked that I set the author straight.

He mentions his comments on the post correcting the author on some points as well as a more "clued in" post on the xml.lt website talking about using PHP's DOM functionality instead.

Christopher Jones has a correction on his blog for a developer guide that Oracle has put out (Oracle Database Express Edition 2 Day Plus PHP Developer Guide 10g Release 2) mentioning a problem in chapter three:

In chapter three "Connecting to the Database" at step 5 of you will get duplicate columns returned if you use the latest version of PHP.

By adding in a "OCI_ASSOC+" to the oci_fetch_array statement, all is corrected. This was due to a change in how oci_fetch_array worked (as seen in this bug).

In response to this recent article from the Hiveminds website, Marco Tabini has a few choice words about some of the topics they cover in the article, and cover incorrectly.

Over the last few years, I've made it a point of trying to respond to at least some of the "PHP is dead"-type articles that crop up on the Net from time to time. The latest one comes from Hiveminds and reveals a complete misunderstanding of almost every point it covers.

He notes that though the article seems to be a coherent whole for why PHP is dwindling, it's "based on nothing more than a string of misinformed concepts cobbled together to give the appearance that the author knows what he or she is talking about". Marco comes back against each of the points made in the article, setting things right and eliminating some of the FUD (fear, uncertainly, and doubt) that the Hiveminds article spreads.