The PHP world is exploding with community conferences. In fact, web development technologies in general are seeing a wide range of community-driven conferences springing up around the world. I think there are many reasons for the proliferation of these conferences, and in this post, I present my opinion on how this trend came to be, along with a definition of what I think constitutes a technology-focused community conference.

So you're sure wat he means by "community conference" he offers a definition that has less to do with the content of the event and more to do with the group putting it on. These community conferences are organized by the community for the community and are usually people already established. He also mentions the "unconference phenomenon" and how it seemed like a precursor to the community conferences. He points out a few other criteria that make it "community".

Several conferences are mentioned both in the post and in the comments: PHP Community Conference, True North PHP, CodeConnexx, CoderFaire and others (not mentioned) like Lone Star PHP, North East PHP, Midwest PHP and many more.

I've blogged about getting started with ZF2 modules, as well as about ZF2 modules you can already use. But after fielding some questions recently, I realized I should talk about why modules are important for the ZF2 ecosystem.

He covers some of the history of the idea, starting with the MVC rework/refactor of the framework and the desire from several people to have self-contained components that could be native to a ZF app. ZFv1 made it work (kinda) with Zend_Application, but it was difficult so solving this became a main focus of ZFv2. He illustrates with a "building block" metaphor based on his current blog site (currently being refactored too).

This kind of building-block development makes your job easier as a developer - and allows you to focus on the bits and pieces that make your site unique. As such, I truly feel that modules are the most important new feature of ZF2.

No matter how advanced the techniques that we use, there is always something that we could be doing better. [...] Which one is right? The real problem is that the answer to that question is, "yes." That's because it lacks a specific context in which it can be inserted.

He suggests that, in our quest to figure out what the perfect case for any situation, we stop focusing on the practicality of writing applications to accomplish goals. Sometimes it's not about getting the right theory behind the code - sometimes it's just doing it.

Why does it seem so hard to deliver quality products to clients? Sometimes it feels like clients either don't appreciate quality, or they have their priorities all mixed up. [...] These seems rather obvious, but in-fact many developers get caught up in quality and then are totally surprised when their clients aren't happy. Why? Because as developers we notice and respect quality a great deal more than suitability.

Part of the problem is that clients don't care about the quality behind the scenes. Most of the time, they just want to see results and don't really care how it was done. He focuses on one thing that can really help you in dealing with these clients - keeping up with that their needs are, not just assuming. This includes a few more specific tips:

• Meet the Client
• See the Need
• Open Communication
• Frequent Client Feedback
• Usability Testing

With this fairly broad classification I set about working out exactly what a Focus Cloud should show. To me the name could only suggest one thing. It shows the area which currently is receiving the most Focus! [...] So a Focus Cloud should show not what has been the most popular tags overall, but what is the most popular tags at present. What is your current focus.

The post not only includes the theory behind these focus clouds but also has some PHP code to back it up (using the del.icio.us interface and tags as the foundation of the cloud's contents). The full code for the cloud can be grabbed here.

The posts will be researched and go through multiple drafts for professionalism before posting. In this hope, it will strive to enable discussion that isn't flaming and collective of the topic at hand. For as much as I can achieve at my level of writing skill and researching the topic at hand.

He he goes through the purpose of the posts, the areas he's going to focus on, some about the theory that will be used, and the implementation and documentation he'll provide through the series.

I like PHP, I really do. PHP5 is a great language and was a huge step in the right direction, unfortunately the community doesn't agree. It is not that the PHP community thinks PHP5 is bad, it is just that they don't agree on anything really. I am starting to wonder if the lack of cohesion is going to bring real trouble to success of PHP as a language.

Though he admits to no longer writing PHP, he's still interested to see it succeed. He just doesn't see the structure the language/community needs to make this happen and make the languagde advance. Jackson also comments on the fact that there doesn't seem to be one "solid" framework for the language, and that even the Zend offering seems on shaky ground.

He also looks at the "downward spiral" things started taking around the time PHP5 was just coming into view - arguing over petty issues, delays of releases, features being added and removed.

The luster was tarnished and the community hasn't recovered. I hope I am wrong, but it looks like it is not going to improve anytime soon.