Since switching to 6.9 I had some trouble using the integrated Refactoring utility. There error I got was: The Rename refactoring cannot be applied in this context.

The solution is a simple one, use the built in shortcut “Ctrl + R” (or “Cmd + R” on a Mac).

The other thing that bothered me is that when you select a method or class and use the context menu to navigate to the declaration of the method/class Netbeans doesn’t do a thing. To make this work the method/class name must not be selected (or you can use the + click shortcut).

Since the creators of TinyMCE moved to Github it was a great opportunity to try and push these changes to the master branch. If you need this you can look at the changes that need to be made to the PSpellShell adapter or just clone my fork of the spellcheck plugin.

p.s. Have I mentioned how awesome Git and Github are?

Hudson definitively won me over with its clean interface and easy to setup tasks. Even plugin installation is a breeze and you can even do it right out of the comfort of your browser.

I found a nice tutorial about setting up Hudson with PHP here but I had some question marks hovering over my head during the installation so I have decided to write a more detailed installation tutorial.

If you are running a Debian flavored distribution (yes I mean Ubuntu) take a look at the tutorial, you should have Hudson working with your PHP projects in no time.

Bonus points if you integrate your Hudson installation to act as your staging server.

Open up Terminal.app and enter “sudo su” and enter your password when asked (I guess you must be using an account with administrator privileges).

pear upgrade PEAR
pear channel-discover pear.phpunit.de
pear install --alldeps phpunit/PHPUnit

That’s it. phpunit binary should be in your path now.

p.s.

For some reason phpUnit that is being used by Zend Studios (6.1) does not have mbstring extension compiled and that makes it unusable for me. I guess there is a way to force PHP interpreter that is being used in the Zend Studio to run with the mbstring extension, but this is a faster approach. Hudson or phpUnderControl (whichever you like) will take care of the code coverage reports.

Some acctually report big improvements in responsiveness of their applications and increase in number of transactions per second their hardware can handle because require_once() is quite an expensive operation, especially if the required file is already included prior to the call.

If you are wondering how to comment out all the require_once() calls from your Zend Framework without doing it by hand here is the solution. Navigate to the folder where your installation of ZF resides on the server and just enter this into your shell:

find ./ -type f -exec sed -i 's/require_once/\/\/require_once/' {} \;

My box is running PHP 5.2.6 with APC 3.0.19 and Zend Framework 1.7 PR and my include path is optimized for use with ZF. Stripping require_once() calls didn’t make a drastic impact on my setup and average performance gain was around 3 requests per second (from 63 to 66).

Update (May 16, 2009)

Since the release of Zend Framework 1.8 there is a script to strip requre_once calls from ZF in the ZF Performance guide. This script does not remove require_once calls to the new Zend_Loader_Autoloader component.

% cd path/to/ZendFramework/library
% find . -name '*.php' -not -wholename '*/Loader/Autoloader.php' -print0 | \
xargs -0 sed --regexp-extended --in-place 's/(require_once)/\/\/ \1/g'

Update 2 (October 3, 2010)

Thanks to Tom Anderson for noticing that this does not work since ZF 1.10.8 , the new script for stripping require_once calls is:

% cd path/to/ZendFramework/library
% find . -name '*.php' -not -wholename '*/Loader/Autoloader.php' \
-not -wholename '*/Application.php' -print0 | \
xargs -0 sed --regexp-extended --in-place 's/(require_once)/\/\/ \1/g'

Note that you must use autoloading if you strip the require_once from the ZF project.

There were also some things I really don’t agree that much. He showed a small PHP frameworks “benchmark” measuring the speed (response time and transactions per second) for each of this frameworks to output the simple HTML page printing out the “Hello world” string. Zend Framework (the framework of my choice) didn’t perform all that bad. Symfony was around 30% slower, and Solar was about 2 times faster. If you are really interested in the numbers have a look at the slides from the session.

The methodology was a little bit questionable. I believe that frameworks offering a caching solution out of the boxes should have been tested with the caching enabled.

Another thing he talked about was removing unnecessary require_once() and include_once() calls from the applications, and their impact on the frameworks speed, and how those calls are handled in PHP internally and how to set up your include path to minimize the impact).

Zend Framework didn’t do that well, as you can see on the graphs plotted out for every framework (dashed lines represent require_once() calls). The main reason for this is I guess that ZF is a loosely coupled framework. The other reason is probably that the ZF is still not mature enough to focus on the optimization issues while there is still so much other work to be done.