There is no magic in local codecoverage. XDebug and PHP_CodeCoverage libraries do their job. The tricky thing is remote codecoverage. We attach small script into application's front controller. When a special header is sent this script starts to collect coverage information. And in the end of tests, this data is merged, serialized and sent back to Codeception. So you can test and collect coverage report even on staging servers in real environment.

They also mention a few other updates in the release - new Redis and MongoDb modules, UX improvements and the normal bugfixes. You can find out more about the code coverage feature in their manual or just about the project in general from the main site.

Three weeks ago PHPUnit 3.6 was released and it has a little new feature you might have missed until now. PHPUnit can now show you code coverage information on the command line.

Options for the report output include: colorizing, writing the output to a file, including a project summary, namespace separation and package (using the @package phpdoc tag) information. He includes a use case he's found for it - small projects where you can cover the whole codebase quickly (with a "watch" command example filtering based on a certain class).

This was a very social event from day one, warm and funny with a horde of geeks trying to mix with "normal people" (yes, that can happen if you attend the PHPNW conference, so try not to miss it next year). The best thing about PHP conferences is knowledge-sharing; you won't leave without a hundred different thoughts and ideas of how to do things better. Once again - definitely a good time, both personally and professionally. If you weren't there, you missed out!

The sessions he specifically mentions include the "Security" talk from Arne Blankerts, "Maintainable Applications in PHP Using Components" by Stuart Herbert, "PHP Extensions, why and what?" by Derick Rethans and "Acceptance & Integration Testing Using Behat" from Ben Waine.

In less than two weeks since the announcement was made at CICON that CodeIgniter was moving to GitHub, we've seen some incredible results from the change. Already CodeIgniter is the 10th most watched PHP project at GitHub (currently 758), with 42 open pull requests, 53 merged pull requests, 170 forks, and 41 individual contributors. Incredible!

[...] We also noticed what seemed to be a spike in activity on the #CodeIgniter Freenode IRC channel, so we've decided to make it more prominent to encourage its continued use. You'll now notice an IRC tab in the main navigation, letting you access the #CodeIgniter IRC channel right here at CodeIgniter.com.

If you want more details on why they made the switch over to git, check out this blog entry from the EllisLab site for an explanation from Derek Jones

Running the specific test cases for the part of the application you're working on is easy and fast, but that does not tell you when changes in part A of the app break part B - which happened several times, and all just because I didn't want to wait 45 seconds again and again. So a solution was badly needed; tests should be as fast as possible; preferably < 10 seconds. Before being able to make the slow tests faster, I had to find out which of the 80 tests were slow.

Tools like Jenkinks give more detail on test runs, but a normal PHPUnit install won't. So, he came up with a method that uses Phing's phpunitreport task to generate extra reporting easily. Here's some example screenshots: test results summary, test detail and single page views of the same sort of data.

I have a (highly optimised) report that takes way too long to generate, up to around 30 seconds. [There's] too many variables to prime caches for every possible combination [and] personally, I don't think the browsers inbuilt progress bar is enough feedback for todays web users.

He generates the data into memcache when the user requests it and uses the Gearman worker processes to handle requests for data that doesn't yet exist. The progress bar is a part of Dojo and uses the dijit.ProgressBar widget to keep checking the progress of the build. This way the user can even leave the page and come back if the process takes too long with no threat to the generating report. You can find all of his code he's used to make it happen on his github account.

One of the most common questions [from his previous post] has been "How do I render a report as an Excel document?" I've been telling folks that this is easy with the SSRS SDK for PHP (and it is easy), but when I sat down to do it, I ran into a problem. So, in this post, I'll show you how to render a SSRS report as an Excel document and how to avoid the one problem that caused me headaches.

This post's a short one with a code snippet (and download) showing how to connect to the server and create a "RenderAsEXCEL" object and request the report information with that in the rendering function. Then it's just as simple as pushing that information out to a file as a ".xls". The included download will also let you pull down the report as HTML or as a PDF.

"There is a problem with component Fooey-Bar-Bazzy, I think it's related to Nanny-Nanny-Neener. Please Fix Now." If you've written a bug/issue report like that in the past with no other details - shame on you! This may come as a shock, but as great as some developers might be, they cannot read minds.

He recommends a few things that can help make your report clearer - listing out your assumptions, creating a short use case, documentation on expected and actual results and how to make the script as generic as possible. To further illustrate, he also includes a sample reproduction script for a Zend Framework bug based on this issue with plenty of commenting, reproduction code and setup/assertion methods to show where the problem lies.

Using this method does not only make it easier for the developers to find the bug, but it also means that the person finding the bug doesn't have to know the internals of the application to point out where the issue lies.

From the Gartner post:

I just published a research note on PHP. Clients can find it here. The research note goes into *much* more detail but the overview is [in the rest of the post]. Keep in mind that this content is targeted at mainstream IT organizations. PHP has been a cornerstone technology on the Web for more than a decade. While its adoption among mainstream IT organizations has been limited in the past, many corporate application development (AD) projects are discovering the unique benefits of PHP.

Danne highlights two quotes that were of particular interest in the report - one from the quote above about PHP being a cornerstone of many corporate web application development and the other talking about PHP's role not just in backend application development but also it being useful in front-end toolsets too.

In their recently released report "Users' Choice: Scripting Language Ratings", Evans Data Corporation (no relation to the author of this article) gave PHP the highest overall ranking of the languages they included in their survey. [...] Given the wide variety of topics, there is no way PHP will ever score first place across the board, however, that is not a bad thing.

Categories the languages were rated on included ease of use, extensibility, community, availability of tools and memory management. PHP got high marks on most with a few (like client-side scripting) lagging behind. Cal sees it from two angles, though - one to celebrate how far PHP has come and the other to look forward to see what things the language needs to improve on.