PHPSpec is closing in on its first stable release, so the time had finally come to spruce up its output! No more the simple reporting of failed specs - now you get a few more details in a readable format, exceptions and errors even come with traces. In addition, I've implemented specdoc output as an option (using "-s") so you can get a list of specs in their plain text form.

He's also included an example of the new output in the post as well, showing the results of both successful and errored responses. You can check out the actual spec files on the googlecode repository for the project and get more details on the project itself (including the latest development snapshots) on the project's website.

• Tip number one involves a good recommendation - keeping your PHP version up to date. Many security issues and exploits have come around because of older versions and the issues they hold.
• Tip number two focuses on the errors that your site gives to the viewing public and the information they can betray (file locations, etc)
• Tip number three talks about using other applications to help you find issues in your code that you might not even know were there - such as Chorizo and the PHPSecInfo reporting tool.

Security in a scripting language such as PHP is more developer-dependent than language-dependent. In other words, although the language offers you the tools to create secure code, it cannot prevent insecure code. Thus, the degree to which code is secure almost entirely depends on how security conscious a developer is.

The article looks at three security-related topics:

• Register globals
• error reporting
• code exposure

If you use PEAR::MDB2, you can set a custom debug handler and collect all the queries you execute for debugging and performance tunning purposes, as shown before. But what if you're using PEAR::DB? Well, since PEAR::DB doesn't allow you such a functionality out of the box, you can hack it a bit to get similar results.

He creates a simple app to help with the illustration - a number of select queries to grab zipcode information from the database. As it stands, the PEAR::DB package doesn't handle the debugging well, so he adds in a few more lines to buffer the connection and some reporting code to check the resulting output (as well as some of his sample reports).

he collaboration between Zend and Actuate has resulted in new capabilities in the 3.0 version of the Zend Platform, which is available today for download as a pre-release version at www.zend.com. Zend Platform 3.0 allows PHP developers to quickly integrate reporting capabilities, including charting, to web applications by calling Actuate BIRT reports via the Zend Java Bridge.

New functionality included in this collaboration includes flexibility when generating the reports (output formats/export options), an easy-to-use visual environment, and an integrated charting system including various graphing formats (like pie, chart, area, scatter, and stock).

Check out the full press release for the full story on this collaboration.

Here are some bugfixing rules and tips I've learned working all these years with PHP. I emphasize mostly on fixing bugs than preventing them, which is another subject worth of its own article. I've moved to Rails, but I wanted to finish this post as a farewell and thanks to every article and documentation that was useful to me. Hope this is useful to you too.

Topics covered include:

• Assume nothing
• Turn Error Reporting to show all errors
• Read the error message
• Understand the bug
• "Scooby-Bug, where are you?"
• Get as much information as possible

I modified it to handle errors as well and added some features which make it useful in productive systems as well: Error logging, Error Mailing, and Configuration.

The script logs or mails unique errors only once to prevent your log file or mailbox to be spammed with the same error again and again. It also takes care of the error level including shutup operator. It's a little bit hacky but did well on our dev servers (where errors tend to happen) in the past few weeks.

The link to grab this latest version of a handy bit of functionality is here - two different files, one for the error handler and one for the exception handler. He also includes a sample code snippet of how to use it.

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 [...] reduce 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 optimized some hot spots in PHPUnit3 moving the initial six hours have been reduced to eight minutes.

Many congrats to Sebastian and the crew that helped make such a dramatic change in the code coverage report creation! He also notes there's a logger to come to manage the information gathered via the tests (into a SQLite database).

The screenshots include views of the summary page, a detail view of the same (and more) information, example test results output, and the code coverage for an internal class.

On perlmonks today, a user was needing to maintain a PHP app, and wanted to know what the PHP equivalent of "perl -wc script.pl" was -- specifically, they wanted to know how to run a PHP script from the commandline and have it display any warnings (ala perl's strict and warnings pragmas).

Unfortunately, there's not as simple a way to do this in PHP as in perl.

He suggets two ways to do it - one involving the display_errors setting and a change to the error_reporting level, and the other an automatically prepended file that does the same (just simpler to use). He also mentions a side note, a question the user had about running a PHP script on the command line.]]> Tue, 28 Mar 2006 06:52:40 -0600