In a response to this previous post about the PSR-0 standard and why it might be "shortsighted", Phil Sturgeon has posted some of his own thoughts on the matter as a participant (and supporter) in the PHP-FIG group.

One of the fun things about trying to support the PHP-FIG and all the good its doing, is seeing blog posts written complaining about it by people that just don't know what they're talking about. I get involved in conversations on Reddit (dangerous I know) on a mission to understand the problems with its perception throughout the community, and try to make more knowledge readily available to avoid confusion. I put together the PHP-FIG FAQ and the rest of the group voted it in, which I believe helped a lot. Sadly some blog posts are sent out by people with a whole bunch of odd opinions that you just can't do anything about, so instead I'm going to respond with a play-by-play approach.

He goes through several of the points Tom made in his original post, pointing out places where the information was either misconceptions or just completely incorrect. He relates some of the autoloading suggestions Tom made back to things Composer can do and how this is different from "magic" on the part of the library user.

PSR-0 has its problems, but they are the two that I have pointed out and they are rather trivial. [...] If you'd like to add custom autoloaders to your Composer packages then go ahead. If you'd like to build your own custom autoloaders for all of your packages then you can do that too, but it ruins the entire purpose of what PSR-0 is meant to do. That's fine, because you don't need to use it, but I am happy as hell that PSR-0 exists and I wouldn't make drastic changes to it for anything.

On NetTuts.com there's a new tutorial about what they think is the one thing every web developer should understand - the HTTP protocol and how its used in web-based communications.

HTTP stands for Hypertext Transfer Protocol. It's a stateless, application-layer protocol for communicating between distributed systems, and is the foundation of the modern web. As a web developer, we all must have a strong understanding of this protocol. Let's review this powerful protocol through the lens of a web developer. We'll tackle the topic in two parts. In this first entry, we'll cover the basics and outline the various request and response headers.

They cover some of the basics of the protocol first including its statelessness, the concept of URLs and the HTTP "verbs" (like GET, POST and DELETE). They also briefly cover the HTTP response codes (ex. 200, 304) and the flow of the request and response to and from the web server. They also look at some of the basic HTTP headers and the actual low-level text formats of the requests/responses.

There's a section at the end of the post that links you to a few tools that you can use to view the HTTP messaging happening in your requests, some of which you might already have. They also briefly cover the use of HTTP in a few libraries - ExpressJS, Ruby on Rails and jQuery's Ajax handling.

On his blog today Hari KT has an Aura Framework-related post about one of its components, the Aura.Http component, and its handling of HTTP requests and responses.

The Aura.Http package provide you the tool to build and send request and response. [...] Probably you may not have bothered too much on building the http response either the framework does it for you, or until you need to send the correct response.

The post shows you how to use the component to send and receive HTTP requests. Code is included showing how to make Response objects and set headers, content, cookies and HTTP response code. He also shows how to output the response and a more complete example of the entire flow. The post finishes up with an example of using Aura.Http to make a request to another site - in this case back to GitHub to get the users on a repository.

Recently Lorna Mitchell asked the wide world of Twitter about some of their recommendations of things not to do when creating an API. In this new post to her site, she gathers together those responses including comments about documentation, consistency and response codes.

Recently I tweeted as a #linktuesday link the 10 Worst API Practices post from ProgrammableWeb. Today, in search of some concrete examples of APIs implementing unhelpful antipatterns, I sent out a tweet for help: "What's the most frustrating inconsistent/misleading bit of API you've seen? Looking for cautionary tales!" [...] In the raft of responses (and thankyou all, this was fabulous, helpful and entertaining in equal parts!), there were some definite patterns that I'd like to share with you, in no particular order.

Comments came in from all over and talked about things like:

• Response codes not matching the content (ex. 200 on an error)
• NullPointerExceptions
• Different endpoints for single vs collections
• Order-sensitive XML in requests
• Poor error handling
• Bad documentation
• Incorrect content type handling

So there you have it, the sins to avoid in your own APIs. If you've encountered any of these, please accept my condolences.

In his latest post Phil Sturgeon shares some thoughts in response to this article from Shawn McCool about the "death of CodeIgniter", citing a few specific points.

I have referenced Shawn McCool's blog a few times, "Why CodeIgniter is Dead" and people are wondering why I argued so hard against it back in May but then gave CodeIgniter such a hard time in my last article. For the record I'm not team CodeIgniter or team Laravel, I'm a PHP user who has some opinions, and some of those opinions change over time - which is fair enough.

He goes through several of Shawn's points including:

• Comments about best practices in CI (or lack of)
• Modularity/design pattern use
• The implementation of modules/sparks
• The community contributions to the Reactor project
• Dropping PHP4 support

Phil also notes that, just because something isn't making significant progress, it doesn't mean it's dead in the water:

Dead insinuates being closed right down. Repo removed, or just nothing is ever tagged again. Where CodeIgniter sits is closer to Smarty. Smarty is still active and has it's last stable release 2 months ago. It just hasn't changed much in years and probably never will.

Paul Jones has written up a response to Matthew Weier O'Phinney's recent post on shared interfaces and the PHP-FIG. In it he talks about the PHP-FIG group itself and specific references back to the original post.

He mentions the ideas of "new thinking" and the limitations that standardized interfaces might try to impose on an application:

One is able to imagine reasons why having shared interfaces of the kind described above is in opposition to, or at best orthogonal to, better development practices and greater innovation across PHP land. Even so, I assert that shared interfaces as described, while maybe preventing an imaginable ideal in theory, instead promote an actual good in practice.

Matthew Weier O'Phinney responded with some of his own comments and correcting some of the misinterpretation of his original comments.

A while back there was an article that put a negative spin on PHP ("PHP: a fractal of bad design") and there was a huge community response to it with over 1400 comments on the post itself. Over on the DevShed forums, there's a lengthy new post that goes back over that article, piece by piece, and evaluates everything that was said.

As I've seen this article a number of times, I'd like to go through it to see what everyone has to say on the subject. Warning: This is just stupidly, ludicrously long. it takes an existing 5-page article and tears it apart nearly sentence-by-sentence.

He goes back through each of the sections - Stance, Arguments, Philosophy, etc - and includes quotes from the articles and his own impressions/thoughts about them. There's a section covering some of the individual complaints that were mentioned and things like PHP's OOP model and security.

Michael Feichtinger has a new post that responds to a recent performance post that was over on DZone.com (by Gonzalo Ayuso).

I think, this article tells you very basic things that are not so important compared to others… so: I will tell you the things you should really check now … then what you should do and why … and you don't have to read much.

He breaks it down into six major points (with a little explanation for each):

• Benchmark using tools, not just microtime
• Install APC for an easy performance boost
• Caching is good, but your application should perform well without it too
• Log all background processes too (start, end, errors, etc)
• Database indexes are a good thing
• Load testing is a good thing, but planning for a high load is even better

PHPMaster.com has posted the second part of their series introducing you to one of the more popular design patterns in PHP frameworks right now - the Front Controller pattern. Part 1 introduced some of the fundamental concepts and this new article expands on that, getting more into the request and reponse handling process.

One of the best things about front controllers is that you can keep them running as tight structures, just routing and dispatching incoming requests, or you can let your wild side show and implement a full-fledged RESTful controller capable of parsing HTTP verbs, accommodating pre/post dispatch hooks, and the like, all behind a unified API. [I'd like to show] you how easy is to deploy a small, yet extensible, HTTP framework capable of putting to work a front controller along with the ones of a standalone router and a dispatcher. Plus, the whole request/response cycle will be independently handled by a couple of reusable classes, which naturally you'll be able to tweak at will.

He bases his examples off of the EPHPMVC project, showing how to implement a RequestInterface, ResponseInterface and link them together with a RouteInterface and use the DispatcherInterface to handle the requests. The front controller is then created with its run() method and an instance is created in a main PHP file that all requests are routed through.

Luc Perkins (of AppFog) has written up a new post with some of his thoughts in response to the PHP The Right Way project.

A few months back, I decided that I was going to learn PHP. [...] The reality that I discovered wasn't at all what I expected. Sure, there was plenty of spaghetti code out there (there's also plenty of spaghetti code in C++, Java, take your pick…), but there were also a variety of frameworks and communities devoted to using PHP to all kinds of productive ends. I was also surprised at just how much of the internet runs on PHP. I guess that something like a third of the internet up and decided to quietly not mind the haters.

He goes on to talk about a previous post of his supporting PHP and how, despite the negative comments on it, was still encouraged to learn more about the language. In his research, he came across The Right Way and was surprised and encouraged by the work and support the community is putting into it.

I think it's clear how best to respond to the group's provocation: if you're looking to make bold claims about what PHP necessarily is and isn't, don't make those claims on the basis of tutorials or blog posts written by PHP beginners. Ask people who are seasoned veterans in the language and in its corresponding best practices. They're the ones who fully understand PHP's breadth and power.