In a post to his site Matthieu Napoli shares some recommendations about how to organize the code in your application using a "domain modules" approach. This is an organization method that relates the code based on functionality it relates to rather than the type of object it is.

We recently discussed 2 topics seemingly unrelated with my colleagues at Wizaplace: how to organize code [and] how to organize teams.

Regarding “how to organize teams”, we were discussing Spotify’s Feature teams. In a “classic” organization, teams are usually formed by grouping people based on their job title. [...] But in a “feature team” organization, teams are organized… by features. [...] The pros of this kind of organization are numerous and I do not intend to go over them here. But what does this have to do with code organization?

He starts with the "classic" code structure - organized by each item's type (ex: Entity, Service, etc). He then suggests reorganizing it move by what it does in the application, namely which module it belongs in best. He briefly touches on dependencies, "agile design" and the differences between a normal "product" and a "product" in e-commerce. He then applies these ideas and shares a domain organized directory structure, trying to reduce the overall complexity of the structure and the overall cohesion of the codebase.

On the SitePoint PHP blog Larry Garfield, a member of the PHP-FIG group, has written up an article covering the past, present and future of the PHP-FIG. In it he tries to give readers a perspective on where the group came from, some of the growth they've seen along the way and, finally, the proposal for PHP-FIG 3.0 - a restructuring of the organization based on things they've learned so far.

The PHP Framework Interoperability Group (PHP-FIG, or just FIG for short) is at a crossroads. Many electrons have been sacrificed talking about FIG’s tribulations of late, but sadly much of it has been FUD, with little effort spent on the positive. At SitePoint’s invitation, I’d like to offer a more positive outlook on FIG and the PHP community, and demonstrate why FIG can, and should, continue to have a positive impact on the PHP ecosystem.

He starts with where the group began (an "uncomfortable beginning") at php[tek] 2015 and the proposal/passing of the PSR-0 autoloading specification soon after. He then gets into the "slow but steady growth" the group had over the next several years and some of the groups that became involved (not just framework projects either). He covers some of the other PSRs created/passed, the impact they've made on the community and the growing pains they've gone through. He ends the post talking about the PHP-FIG 3.0 proposal and some of the support, opposition and discussion that has come along with that.

Phil Sturgeon has a new post to his site giving a brief overview of the state of the PHP-FIG, the v3.0 proposal that's been put out and sharing some of his own thoughts on both.

I was involved in the PHP-FIG since 2012, and I have seen every conversation, been part of every decision, and know the reasoning for a lot of stuff, regardless of the result and my person preferences. Being so involved with this group for so long, I have a fair bit of context that other people are lacking.

The latest of about four large conversations in the FIG is: whether or not a new organization should take its place. Seeing it framed in this way is odd, because I'm not sure anyone is literally proposing that.

Phil covers some of the background behind the PHP-FIG group including some of the original goals and how it grew well beyond the "framework" part of its name. He talks about some of the reasons he sees that the group has stayed around. Then he gets into the FIG v3.0 proposal - a relaunch of the group with a different structure and different way of getting things done (after learning from some of the mistakes in the current group). He also talks about the other elephant (elePHPant?) in the room: whether this new structure calls for a new group to be formed or if the PHP-FIG should just adapt and move on.

It will be interesting to see how this all shakes out in the end but the PHP-FIG group has, undoubtedly, helped to usher in a lot of the "modern PHP" work we see in the community now especially when it comes to things like Composer, logger structure and middleware handling.

There's been a big discussion happening over on the PHP-FIG (Framework Interoperability Group) mailing list recently about the goals and vision for the project. While the group originally started out as a way to define standards for frameworks and projects to work together, some have begun to wonder if it's a bit more far reaching than that. This discussion/poll on Reddit sums up the question nicely:

There are some ongoing discussions on the PHP-FIG mailing list about, among other things, how the FIG is seen by the wider PHP community. [...] Since an earlier discussion pointed out that perhaps the FIG, while well-known, don't do enough "active outreach", consider this an attempt to "reach out."

Do you think:

• The FIG is a bunch of self-aggrandizing elitist jerks who couldn't write a competent or useful "proposed standards recommendation" if their lives depended on it, and should disband entirely.
• The FIG, while aware that the wider PHP community is watching, writes PSRs primarily for itself, and others can adopt or ignore as they wish;
• The FIG has become the closest thing to a userland standards group that the PHP community has, and should accept that role;
• Some other opinion?

There's already 50+ comments on the thread with several of the options being supported. There seems to be a leaning towards either the second option or the third with advantages and disadvantages for both. The group has undoubtably helped to change the way that modern PHP is written and they want to keep the tradition going and be what the community and language need. Go over an voice your own opinion on the matter too!

The PHP Mentoring organization has officially updated to an application rather than the GitHub wiki page for matching up mentors with potential apprentices. What is PHP Mentoring? Glad you asked...

We are a formal, personal, long term, peer to peer mentorship organization focused on creating networks of skilled developers from all walks of life. We are PHP developers first and foremost but that is not all we do, nor is it the only skill we intend to pass on to others.

We are mentors and apprentices, teachers and students, coaches, counselors and friends. We're not in this for profit but for the end result, a strong community of talented developers doing some fabulous work. We give back to the community as much as we take, we build up not tear down, and above all we believe in "play nice" and "code well".

The group looks to connect developers, matching those more experienced with ones maybe just starting out or wanting to learn more about a specific topic. They have some guidelines to follow if you're interested in becoming a mentor/apprentice. The application has just been launched and the mentor list is still being repopulated, but in the meantime you can check out the wiki page for more information on current mentors.

In the latest post to the SitePoint PHP blog Lukas Smith takes a look at content management systems comparing trees versus facets versus tags in content organization.

For several years I have been interested in content repositories as a key aspect of modern CMS. With “modern”, I mean CMS that are not just “page management systems” but CMS that actually manage content, thereby enabling authors to reuse their content on different devices and even different applications. But when evaluating [prismic.io and contentful.com], I noticed a surprising trend: they do not leverage trees, neither as a native storage concept nor as a visualization concept. Instead, they for the most part rely on flat structures with tagging. My gut feeling was telling me that this was a mistake, especially when managing larger content repositories. At the same time I wondered: “Am I just a dinosaur that is missing the ark?”.

He starts with an introduction to the concepts of trees, facets and tags and starts in on the advantages and disadvantages of each. For each topic he shares a brief summary of what they are and a screenshot showing how they could be visualized. He finishes the post with a "tl;dr;" summarizing the points made for those wanting the basics.

On the QaFoo blog there's a recent post interviewing Johann Peter Hartmann, the CTO of Mayflower, about current PHP testing practices and how to find that "sweet spot" that works for your development.

Talking to interesting people spawns ideas and spreads insight knowledge. Therefore, I talked to Johann Peter Hartmann about testing culture and how PHP projects should approach testing in 2013.

They talk about things like:

• The move from "spaghetti code" to "quality code"
• A discussion of the current tools
• Defining a unit testing strategy
• Test Driven Development

They also talk some about the training that the QaFoo folks provided to help them (Mayflower) work all of this out for their organization.

One of the more popular PHP microframeworks right now is Slim and Chris Hartjes has a new post to his blog about a good way he's found for organizing applications that use this handy tool.

I’ve never really used a microframework in PHP before. I used Flask for a Python project that I did to experiment with using Google App Engine. The principles seem to be quite similar (although I will admit that having decorators in PHP would be ineresting) but the trade-off with a microframework is that you usually have to figure out an application layout for yourself.

He also uses the Pimple dependency injection container, Twig templating and Composer for package management. He describes how he got it all set up - organizing the code so Composer could understand it, creating the Twig templates directory and creating some of his default routes.

On the DeveloperDrive.com site today, there's a new post with a few reminders for PHP developers out there of things it's easy to forget when writing your applications - some common mistakes to avoid.

Despite the high expectations placed on them at times, developers are human. They were the last time we checked anyways. As humans, we are bound to make mistakes from time to time. And simple, common mistakes often slip past our filters the more comfortable we become with something. [...] But knowing what these common mistakes are and how to avoid them can really help speed up the development process and keep our clients smiling.

His list includes three big ones that, if forgotten, could end up being detrimental to your application (sooner or later) - poor housekeeping/organization of code, forgetting punctuation and forgetting to validate input from users.

Matthew Weier O'Phinney has a new post today talking about why namespaces in PHP matter and why he thinks they're a valuable contribution to the language.

You've heard about PHP namespaces by now. Most likely, you've heard about -- and likely participated in -- the bikeshedding surrounding the selection of the namespace separator. Regardless of your thoughts on the namespace separator, or how namespaces may or may not work in other languages, I submit to you several reasons for why I think namespaces in PHP are a positive addition to the language.

He breaks down his reasons into four different categories - the code organization benefits that come with namespace "containers", simplified interface structure, improved readability (no more huge class names) and a simpler method for identifying dependencies