In this new post Scott Johnson shares a PHP debugging tip that's "too useful not to blog".

Every so often you, in a fit of frustration, you whip out a little internal tool - perhaps a debugging hack - that all of a sudden just makes things much more clear and then you feel good and, for me, that means blogging it.

Now I'm not a fan of IDE's for php coding - but I will acknowledge freely that an IDE makes this kind of debugging much easier - so I whipped up get_caller_context, a debugging function, to support this.

The function he describes performs similar to a call to debug_print_backtrace but with a bit less output. He gives a simple example of what that output would be as well as a brief explaination as to what it means. And, of course, he also includes a link to the code.

From the Toronto PHP User Group website today, Darryl Patterson shares some of his thoughts and feelings on the Zend Framework.

I decided to write this little article up after seeing the various responses to a post on the Zend Framework mailing list titled "What is the Zend Framework?" One of the contributors pointed out a post made to a different mailing list that essentially said that they had no clue what the Zend Framework is after visiting the official ZF website.

So, I fire up the browser, and went to http://framework.zend.com/ from the perspective of the beginner to novice PHP developer. Sure enough, the language used there is really meant to target developers who are quite familiar with the concept of frameworks, design patterns and APIs. Not easy topics to grasp when you're new to programming.

He suggests that, even though the site (and software) is targeted primarily at more experienced developers, why can't we have content on the Framework' site targeted to those just starting out? He also asks the question "why do we need the Zend Framework?" and gives some basic facts for beginning developers to consider before getting into it:

• it's not "production ready" yet
• you have to learn the Framework's "language" to use it
• it only works with PHP5 installations

If you're still wanting more information, however, head on over to the Framework's main site to get the full details.

Handling file uploads can be a little bit of a ticky concept to learn for developers just starting out, so it's good to have resources like this to look to for an introduction.

The post gives you a basic version of the two necessary parts for the upload - the HTML for the form and the PHP script to handle the uploaded data. Their sample script simply takes in the file and moves it over to their "/var/www/uploads" directory while ensuring it's a valid upload and that it could be moved.

It's nothing fancy, and there are some other considerations that need to be made for the uploads (like limiting the file type), but it's a place to start.

When I moved to Norway just over a month ago, the Code Coverage Reporting of PHPUnit 3 needed almost six hours to run the test suite and generate a Code Coverage report for the eZ components.

Then Derick Rethans committed a patch to Xdebug that introduced "a cache that prevents the code coverage functionality from running a ''which code is executable'' check on every function call, even if they were executed multiple times". This patch reduced the time spent on running the tests dramatically. It now took only two hours to run the test suite and generate the report.

Over the past couple of days, Michael Lively Jr., Jan Kneschke, and myself used Xdebug's profiling functionality to locate "hot spots" in PHPUnit 3's report generator. After optimizing most of these hot spots (I am not proud of all of these patches), the initial six hours have been reduced to eight minutes.

Wow.

I am also working on a "logger" that writes all information that is gathered during the execution of a test suite to an SQLite database. Think of this feature as the basis for a tool like CruiseControl. A web application queries this database and would allow, among other things, the analysis of differences between test runs: Which commit (by which developer :-) made a test fail? Which commit incurred a performance penalty?

The possibilities are virtually endless ;-)

When I moved to Norway just over a month ago, the Code Coverage Reporting of PHPUnit 3 needed almost six hours to run the test suite and generate a Code Coverage report for the eZ components.

Then Derick Rethans committed a patch to Xdebug that introduced "a cache that prevents the code coverage functionality from running a ''which code is executable'' check on every function call, even if they were executed multiple times". This patch reduced the time spent on running the tests dramatically. It now took only two hours to run the test suite and generate the report.

Over the past couple of days, Michael Lively Jr., Jan Kneschke, and myself used Xdebug's profiling functionality to locate "hot spots" in PHPUnit 3's report generator. After optimizing most of these hot spots (I am not proud of all of these patches), the initial six hours have been reduced to eight minutes.

Wow.

I am also working on a "logger" that writes all information that is gathered during the execution of a test suite to an SQLite database. Think of this feature as the basis for a tool like CruiseControl. A web application queries this database and would allow, among other things, the analysis of differences between test runs: Which commit (by which developer :-) made a test fail? Which commit incurred a performance penalty?

The possibilities are virtually endless ;-)

When I moved to Norway just over a month ago, the Code Coverage Reporting of PHPUnit 3 needed almost six hours to run the test suite and generate a Code Coverage report for the eZ components.

Then Derick Rethans committed a patch to Xdebug that introduced "a cache that prevents the code coverage functionality from running a ''which code is executable'' check on every function call, even if they were executed multiple times". This patch reduced the time spent on running the tests dramatically. It now took only two hours to run the test suite and generate the report.

Over past couple of days, Michael Lively Jr., Jan Kneschke, and myself used Xdebug's profiling functionality to locate "hot spots" in PHPUnit 3's report generator. After optimizing most of these hot spots (I am not proud of all of these patches), the initial six hours have been reduced to eight minutes.

Wow.

From The PHP Blog today, there's this tutorial covering the creation of a "pastebin" style website of your very own. Pastebins are a simple collaboration tool allowing the posting of textual data (most commonly code) to a public place anonymously.

This post will show you step by step, how to create your own personal pastebin. If you don't know already, a pastebin is a website that lets people share text. These kinds of sites are useful when collaborating with project members who are in different locations, because it lets you quickly share pasted data with all members, instead of emailing the text back and forth. Some popular pastebins are pastebin.com, and pastebin.ca.

They develop the backend first, creating a simple MySQL database to hold the information. From there, it's just a bit of PHP away from allowing users to post their information. It's a very basic kind of interface (no feedback capabilities or anything), but with a little tweaking, it could definitely do more.

Ben Ramsey has a note about something that I'm sure the PHP user group has noticed - the release of the latest Atlanta PHP website.

Over the weekend, Atlanta PHP launched its brand new Web site and forum. We hope that this new site and forum will allow us to serve our local developer community much more effectively.

Also, something that I've not pointed out in any of the language posted on the Atlanta PHP Web site is that the new forum allows members to get in touch with each other, something the Drupal installation we had did not allow. Members can send private messages or even e-mail to each other using the forum software.

He also notes that he's gone back to Meetup.com and created a group there for PHP developers looking for a group in the Atlanta, Georgia area, but it's mainly just there to funnel developers back to the main site.

I have just published an article about eZ publish 3.8 clustering in the articles section on ez.no. If you are interested in scaling eZ publish then this article should be of interest to you.

On the SitePoint PHP Blog today, Harry Fuecks has a few comments of his own about the just released PHP and Oracle Manual from the folks over at Oracle.

Chris Jones just announced the publication of the PHP and Oracle Manual (PDF) and from a high speed eyeballing, it's good-basically tells you everything you need to know to be able to do useful stuff with PHP + Oracle but with little assumed knowledge.

In fact it seems to be geared to the typical LAMP developer...

Harry does mention one thing he'd wished they've of added to this first edition - the SQL Developer desktop tool.