In his latest post Matthias Noback suggests the idea that there's no such thing as an optional dependency when it comes to working with packages and Composer.

On several occasions I have tried to explain my opinion about “optional dependencies” (also known as “suggested dependencies” or “dev requirements”) and I’m doing it again: "There’s no such thing as an optional dependency." I’m talking about PHP packages here and specifically those defined by a composer.json file.

So that everyone's on the same page, he starts with an example of a true dependency in a sample adapter class. He asks the usual question - "what's needed to run this code?" - and looking a bit deeper at the "suggested" packages. As it turns out, some of these dependencies turn into actual requirements when you need certain features of the tool. He points out that this is a problem with quite a few packages in the Composer ecosystem and proposes a solution - splitting packages based on requirements. He gives an example based on his adapter with a Mongo requirement split off into a "knplabs/gaufrette-mongo-gridfs" package that's more descriptive of the requirements.

Michael Kimsal has a new post to his site with some recommendations for web developers as to the things they should know to do their job well.

The original question from was a 16 year old who’s been doing some basic CRUD apps, but is getting bored and wanted to move on to ‘real’ development. There were some good replies, but few went in to the depth of detail that I think beginners are even aware of. Granted, this might scare off some, but for others it might give them some ideas about what’s possible and what’s involved in professional web development. I know I’m going to leave off some topics, so feel free to add on!

He touches on topics ranging from version control to performance and even a mention of mobile development. Each section includes a brief summary of the topic and some have specific topics to check out to help narrow things down to the important parts.

In a new post to his blog, Pierre-Alain Joye has a suggestion for mailing list members (and really anyone else involved with the community) for reading materials - a chapter from "Producing Open Source Software".

A must read about OSS is the "Producing Open Source Software" written By Karl Fogel. One chapter covers nearly all problems that php Internals is experiencing.

No need to say that these rules should apply to IRC as well. You may think while reading the mailing lists that a certain level has been reached, what happens on IRC is even worst. Another chapter can be very interesting: Social and Political Infrastructure (and related). Mixing paid developers, volunteers or ambitious developers (as in need of an ego or career booster) is not an easy thing, but it should be possible (dreaming?).

Among the topics discussed in the chapter, Pierre mentions two - "nip rudeness in the bud" to keep things more civil and from escalating and to avoid private discussions about a project that everyone should be involved with.

In a new post to his blog, Pierre-Alain Joye has a suggestion for mailing list members (and really anyone else involved with the community) for reading materials - a chapter from "Producing Open Source Software".

A must read about OSS is the "Producing Open Source Software" written By Karl Fogel. One chapter covers nearly all problems that php Internals is experiencing.

No need to say that these rules should apply to IRC as well. You may think while reading the mailing lists that a certain level has been reached, what happens on IRC is even worst. Another chapter can be very interesting: Social and Political Infrastructure (and related). Mixing paid developers, volunteers or ambitious developers (as in need of an ego or career booster) is not an easy thing, but it should be possible (dreaming?).

Among the topics discussed in the chapter, Pierre mentions two - "nip rudeness in the bud" to keep things more civil and from escalating and to avoid private discussions about a project that everyone should be involved with.