The Zend Developer Zone as posted a new screencast from Zend about the event debugging functionality offered with their Zend Platform product.

Zend Platform is a powerful tool both in development and in production. [...] One of the cool features of it is the Event Debugger. Here's a short screencast that demonstrates how it works and how it integrates with Zend Studio for Eclipse.

The screencast is only about three and a half minutes long, but they cram a lot of screenshots and output results into that time. Cal Evans himself does the narration.

This recent post on the PHP::Impact blog spotlights a useful little tool for those developers needing to span the gap between PHP and Java in their applications - the PHP/Java Bridge.

The PHP/Java bridge allows you to quickly access Java classes from within your PHP classes without having to know Java and vice versa. Because of this two-way flexibility, you can access hundreds of pre-built Java classes from PHP, and hundreds of pre-built PHP classes from Java opening up your applications to greater flexibility and enhanced functionality.

The post includes an introduction to the bridge's functionality - its functions/methods, how to make a new instance of it, catching exceptions and the type conversion it automatically does (like lang.java.String directly to the PHP String type).

They also mention the Zend Platform bridge functionality for a more commercial solution.

On the Zend Developer Zone today, there's a new article by Dotan Perry and Shie Erlich talking about what kind of scalability and responsiveness that the Zend Platform's Job Queue functionality has to offer.

The Zend Platform Job Queue is used to make applications more responsive by allowing tasks to be performed on other machines (e.g.: dedicated machine), and scheduling tasks to a future time (usually to low-traffic hours). [...] Job Queue offers both a web-based management UI, and a programmer-oriented rich API, which allows embedding sophisticated logic into applications. This article will demonstrate basic usage of Job Queue, through an imaginary company wesellalot.com.

They start by presenting a scenario where a simple cluster of machines behind a load balancer all work with the same database. Because of some of the tasks they want to perform, things could get overloaded very easily under a high load. Enter the Job Queue and their four step process to integrate it into this setup:

• Step 1: Off Load to a Dedicated Server
• Step 2: Scheduling to low-traffic hours
• Step 3: Breaking down tasks using dependencies
• Step 4: A recurring cleanup job

They also include an explanation as to why this method is preferable over just using croned scripts for the same purpose.

If you've read this post and gotten a little lost as to the struggle he (Tony Bibbs) faced to lead up to, you might want to check out the previous post outlining all of the things he came across when making the move from Zend Studio version 5.1 up to version 5.5.

So what have I concluded out of all of this? As clearly as I can state it here is the big problem. With Zend Studio 5.1 you could install Studio Server with no additional fee outside of the Zend Studio license. This allows you to debug via your local Apache instance running PHP. To get the same feature set out of Zend Studio 5.5 you would have to buy Zend Platform separate.

My hunch is the folks at Zend expect developers to debug on their local desktops with only the internal debugger which *can* produce different behavior than that under your web server environment. It's not good if your debugger can exhibit different behavior than your web server. I should also note that remote debugging with Zend Studio 5.1 while serviceable was not the most stable. It would occasionally kill Apache, possibly require me to restart Zend Studio or rare cases even force me to reboot.

He also lists out some of the other issues he's noticed in making the change (six of them).

Today, Tony Bibbs provides something that "Zend might not want you to know" about using their debugger in your application - that it enables an option silently, without asking the user at all.

A co-worker here was going through similar problems with Zend Studio 5.5. He'd even gotten so frustrated he tried installing phpEclipse and in doing that installed Zend's debugger. Little did he know that by doing that he had enabled remote debugging support in Zend Studio 5.5 without the need for Zend Platform and we can still happily use APC.

Now the million dollar question is why doesn't Zend document or promote this fact? Sure, they want you to install and test drive their "PHP Application Server" but if you don't desire all of that why force it down our throat?

He points out a PDF that only barely mentions that this could happen but couldn't find much else. If you don't want this to happen to you, he provided a different method to enable the debugging easily through a few php.ini settings.

In a new post, Lukas Smith mentions (among other things) an upcoming webcast via the folks over at php|architect covering the best practices of using the opcode cache in your applications.

oin us as we host PHP internals developer, Stas Malyshev (Zend) with a presentation on optimizing your use of PHP opcode caching software, be it APC, Zend Platform, or another.

This talk will cover techniques that you can use to squeeze the most performance out of your cache, such as avoiding runtime includes and conditional class declaration.

Register soon because the event happens this Friday (March 16th, 2007) and there is no cost to attend - but you do have to sign up.

Stefan Esser takes a look back at the first week (or so) of the Month of PHP Bugs he's doing for the month of March:

We are on day 5 of the Month of PHP Bugs, meanwhile details for 11 Vulnerabilities were disclosed, including 2 Bonus vulnerabilities covering local root vulnerabilities in the Zend Platform.

He mentions that, on the whole, the reaction has been positive, with those few out there that have their own thoughts on the bugs (such as one issues causing two bugs or that other bugs aren't viable because they're not included in a released version of PHP).

The Zend Developer Zone has posted this release announcement for the latest version of Zend's application server - Zend Platform 3.0:

Zend Technologies, the PHP company, today announced the general availability of Zend Platform 3.0. Zend Platform 3.0 is the only PHP application server created specifically to support the management, performance, integration and scalability requirements of organizations that use PHP to run business-critical web applications. Zend Platform improves the end user experience with these web applications by enabling better application responsiveness, reduced application downtime, and richer functionality.

Updates from the previous version include:

• Support for PHP 5.2
• Zend Optimizer 3.2.3 and Zend Debugger 5.2.4 are included
• New servers: Performance Mangement Server, Integration Servers & Enterprise Server
• PHP Configuration Control enhancements
• Actuate BIRT Reporting integration
• and more [txt]

You can check out the features and everything about the Zend Platform on it's official page on Zend's website.