In his latest post Paul Jones recounts a Twitter-based discussion that happened between Taylor Otwell (@taylorotwell) and others on Twitter about the different types of coupling in libraries or applications. The discussion focused around three different types and their definitions: loosely-coupled, tightly-coupled and de-coupled.

The quotes from the conversation come from Taylor, but Paul includes some of his own thoughts in response (things better expressed in more than 140 characters. He talks about some of the assumptions that were made during the discussion, the general knowledge level of "basic programming terminology" and how Paul views the definition of "decoupled".

If your code has a dependency on classes in a particular thrid-party package, your code is tightly coupled to the code in that package. [...] The fact that your code could be tightly coupled to another package does not mean that the other package is coupled to anything else. That is to say, the other package might have no couplings of any sort to any other code outside itself. The other package in that case is de-coupled.

He talks about how one of the main goals of the packages that make up the Aura project is to be decoupled from the start and how that can help with changing requirements/dependencies down the road. He also defines what he sees as "loose" and "tight" coupling, largely defined by the packages required in the "composer.json".

There's been a lot of talk recently about unit testing (and testing in general) in the PHP community and some of the terms that are thrown around might be confusing for someone coming into it fresh. NetTuts.com is here with a guide to help those folks make some sense of it all.

Lately, we’ve been hearing and reading more and more about test-driven development. This domain, however, comes with a series of expressions and specific jargon that can be confusing to newcomers. This article will walk you through the most common definitions, test types and test parts. Use cases will be provided, and, where possible, some code in PHP will also be presented.

They cover several of the common terms you'll come across when working with testing including:

• Automated testing
• Test fixtures
• Test cases
• DOC - Dependency-on component
• Component tests
• Acceptance testing
• Continuous Integration/Delivery

Pádraic Brady continues his series looking at the creation of complex views in the Zend Framework with part six today all about gathering together the thoughts and ideas from the previous articles into a cohesive whole.

Part 6 now takes our previous fragments of theory and attempts to stitch them together into a cohesive whole - a description of a possible end solution. Yes, I know code talks loudly, and we'll get there with an almighty bang in Part 7 (which I promise is no more than a week away). Until then it's more verbosity.

He suggests a list of six terms to help get everyone on the same page when talking about the complex views:

• Includes
• Partials
• Dispatches
• Layouts
• Placeholders
• Response Segments

Since these terms would mean nothing without proper definitions, he provides a few paragraphs on each explaining what they are and, where necessary, using code to illustrate the point.

Pádraic Brady continues his series looking at the creation of complex views in the Zend Framework with part six today all about gathering together the thoughts and ideas from the previous articles into a cohesive whole.

Part 6 now takes our previous fragments of theory and attempts to stitch them together into a cohesive whole - a description of a possible end solution. Yes, I know code talks loudly, and we'll get there with an almighty bang in Part 7 (which I promise is no more than a week away). Until then it's more verbosity.

He suggests a list of six terms to help get everyone on the same page when talking about the complex views:

• Includes
• Partials
• Dispatches
• Layouts
• Placeholders
• Response Segments

Since these terms would mean nothing without proper definitions, he provides a few paragraphs on each explaining what they are and, where necessary, using code to illustrate the point.