DevShed starts off a new series today focusing on security in web applications, specifically in PHP-based ones, with this first article - an overview.

With the web and web sites open to everyone -- including malicious hackers -- the security of web applications sits at the top of the list of issues on any web developer's mind. In this eight-part series, we will look at the security concerns of PHP developers, and what they can do to make their web applications more secure.

They talk about the importance of having a security plan from the start and look at a few simple steps to get started with in enhancing your application's security - the proper use of register globals, using error reporting to correctly catch problems and how to minimize the code exposure of your app.

The Zend Developer Zone has a review posted of a report that the O'Reilly Radar group put out concerning Open Source software and its place in the Enterprise business today.

It's not often that a report generates this much excitement but "Open Source in the Enterprise" says a lot of what needs to be said to C-Levels considering making the jump to Open Source.

Cal mentions one of the 6 factors that are driving more and more businesses to open source software (like PHP) - the community that surrounds them (how vibrant is it?). He also points out the concept of "vendor lock-in" and how open source can help companies accomplish it by ridding themselves of proprietary software. The report can be gotten from the O'Reilly Radar group for $399 for an individual copy or $995 for a sitewide license.

The DevX site has posted a new tutorial talking about their method for creating reports and generating statistics based off of data from your PHP application.

Statistics and reports analyze the change over time of any kind of phenomena. [...] For the software industry, statistics and reports provide both an ongoing challenge and an ongoing market. At present, programming languages such as PHP and Java come with built-in packages for developing applications around statistical problems.

They use two PEAR packages for the statistics - Text_Statistics and XML_Statistics to pull in different kinds of data and extract results from it. The next step is to make a meaningful report out of these numbers - that's where PHPReports comes in. It's a simple tool that makes simple reports for you that can then be styled with CSS however you'd like.

According to this post on O'Reilly's ONLamp.com website, Microsoft has released a new five page PDF file titled "PHP on Windows: Community Involvement Improves Performance" discussing the relationship between the software giant and the language over recent years.

The first effort described is the partnership between Microsoft and Zend that resulted in the development of the FastCGI Extension that essentially allowed PHP to be a first-class citizen when used on a Windows Server with IIS. The second effort described is the Microsoft SQL Server 2005 Driver for PHP developed internally by the SQL Server team.

They also mention Phlanger and the PHP for Microsoft Ajax projects.

Stefan Reuter has a very quick example of a method for profiling your PHP applications with Xdebug and KCachegrind.

Ever wondered where your PHP applications spend their time? [...] We wanted to gain performance insights of a newly developed application based on Zend Framework to spot areas worth receiving some fine tuning. We did not want to modify the application for that purpose so I had a look at the options available for PHP.

The resulting combination of XDebug and KCachegrind to grab the stats from the application and create great output images/reports to help make locating the problem a snap.

Lorna Mitchell has posted up a summary of her trip to the International PHP Conference for this year to the PHP Women website.

At the beginning of November I attended the International PHP Conference in Frankfurt, Germany. This was my first attendance at any of the larger conferences and I thought I'd share my experiences as a conference newbie.

She mentions the number and types of attendees, the venue for the conference, "Code Camp", some of the talks given (including keynotes) and some of the off times.

Sebastian Bergmann has posted about a bottle neck in the PHPUnit unit testing software for PHP:

Now that collecting code coverage information is not slow anymore (as of Xdebug 2.0.1), PHPUnit's report generation code (PHPUnit_Util_Report_*) has become a bottleneck.

There are several images included in the post (output of KCachegrind):

• generation at revision 1473
• generation at revision 1475
• generation at 1486
• generation at 1488

In a new post today, Tobias Schlitt reinforces something that several developers don't even seem to bother with - generating and understanding coder coverage reports for their applications.

I'm a fan of PHPUnits code coverage reports. And with this sentence I can see a lot of the developers out there shiver, because they are of the opinion, that code coverage reports for unit tests are nonsense and cannot give you any hint on the quality of a test suite. I see it a bit differently. Surely, a high code coverage rate of a test suite does never indicate, that code is well tested (if you have not written the code and tests yourself). But the other way around works: A small code coverage rate definitly means, that the test suite is not sufficient. But let me dig a bit deeper into code coverage and what it gives you.

Benefits he mentions include:

• Shows how much of your code is actually touched during execution
• Shows how well the unit test coverage is
• Helps you create all needed unit tests for your code (a guide or sorts)

He also mentions code mutation as a method for testing the quality of your test suite. However, it's currently not integrated into PHPUnit.

In this new post to his blog, Richard Thomas talks about a bug issue that he's "gotten in the middle of" and the conflict between the PHP group and the PEAR developers that came out of it.

Today I managed to get right in the middle of this. [...] Both pear and php are pointing the fingers at each other, neither seem to be able to work together and Im not even sure if either one of them has even taken the time to run my test code and realize what the issue is to begin with.

The problem comes when he created a a script with the Pear Mail, Mail_mime and Net_SMTP PEAR classes and, following the execution of the rest of the script, tried it both ways - turning the erro reporting back off or not messing with it at all. As a result, the code with the ending error_reporting() call throws an error, the one without does not.

Unfortunately, at the time of this writing both sides are still pointing at the other for blame on the issue.

After trying to get code coverage reports and unit testing with PHPUnit and XDebug to work, Matthew Weir O'Phinney succeeded and got the reports running. Fortunately, he's shared how he's done it and an example of how to run the report.

I've been playing with PHPUnit a lot of late, particularly with framework development. One thing that's always hard to determine is how well your code is exercised -- basically, how much of the code is tested in the unit tests?

He gives an "executive summary" of how to get XDebug working and playing nice with PHPUnit as well as something a bit more detailed, following his experience with getting things up and running.