I'm still bored and lacking posting ideas, so I figured I'd give a hyper-critical breakdown of "Four reasons to hate CakePHP" by A.J. Brown. Let's get right into it.

He responds to comments on: CakePHP's "heaviness", the (in)flexibility the framework allows, alpha releases, changes between versions, no namespace considerations and its use of global functions.

You can see the original post here: Four reasons to hate CakePHP as well as his AJ's own response to comments he recieved - Maybe I was too hard on CakePHP.

Conflict is not a bad thing. That is, if it leads eventually towards clarity and understanding rather than confusion and misunderstanding. [...] A debate about a technical matter may be conducted in parallel with an altercation that addresses the relationship between the participants. This is confusing in itself. Keeping these discussion apart will help maintain clarity.

Using this tact, he responds to the criticism made on the previous post, specifically one that points to this article as to why "considered harmful" articles should only be seen as fodder for argument and should be "considered harmful" themselves.

Here's an FJM style breakdown of Carl McDade's well thought out and persuasive article ("PHP is a skill, not a profession"). Haha...no really it's just flamebait crap.

Matt makes light of a lot of the things said in the Hiveminds article, including Carl's comments about the importance of PHP and how it compares to Carl's language of choice, ASP.NET.

More comments from Lukas Smith
• Thoughts from Danne Lundqvist
• Notes of disagreement from Michael Kimsal
• Comments from Paul Jones
• A push to move on from Johannes Schluter
• Ninh's comments (from a Ruby/Rails fan)
• PHP::Impact's post on the controversy
• Comments from Fredrik Holmstrom
• Jani Hartikainen looks at the choice of "" over "::"
• A post on the PHP::Impact blog
• Some of Michael Kimsal's thoughts on the choice

You can find out more about how this final implementation will be used in this entry on the PHP.net wiki.

The most important factor in making a Web application fast is its basic design. You must also know what kinds of processing your framework is doing, and what its bottlenecks are. The best way to find the performance bottlenecks is to monitor the performance counters and to have a thorough understanding of the framework your application is using.

Federico runs some benchmarks of his own (using the Apache benchmarking tool, ab) both with a default "base app" and with a more optimized "take out what you don't need" version.

This is part 3 of my article about writing a restful service server. If you haven't already, you might like to read part 1 (covering the core library and grabbing the information we need from the incoming request) and part 2 (covering the service handler itself) before reading this section. This part covers the Response object that I used to return the data to the user in the correct format.

She show how she created the object to push the response back out to the client with an output() method that displays the XML response in a manually generated format.

By popular request, here is an update of my web framework benchmarks report. [...] In the interest of putting to rest any accusations of bias or favoritism, the entire project codebase is available for public review and criticism here.

Follows the same methods as before, creating "hello world" controllers in each and running the stats against them with the Apache ab tool. A baseline non-framework example is created and tests are run against different versions (including release candidates) of each framework.

I won't spoil the results - you'll just need to check out his post to see who ranked where.

• Johannes Schluter looking at the actual release
• The PHP 10.0 blog mentioning the impact this new release will have on the language and the web
• and a few tests that Lars Strojny has already run on the release.
• Evert Pot's look at some of the upcoming features of PHP 5.3 (including code)
• Some testing from PHP Freaks
• A note about some testing with the Stubbles framework

You can check out this page on the PHP.net wiki for more information on what's left for the final release and a tentative schedule for the releases in between.

You may be wondering why it has been taking us such a long time to react. Here's the main reason: we had not a very strong security alert reporting and qualifying process. This has been fixed recently. So as of now, if you find a security bug in symfony, please send an email to security at symfony-project.com, with as much details as you can and ideally a patch if you can provide one.

The wiki has a whole section on how to report security issues to get them to the right place.

He summarizes the functionality in three different methods of handling: "page/file based", "action based", and "component based". He also notes that the interesting fact is that the "page/file based" method seems to be so dominant in the PHP world, only emphasizing the fact that PHP is more of a "get it done" language than anything.