Matthew Weier O'Phinney has a recent post about recent work that's been done to split up the componenents in Zend Framework 2 into their own repositories and linked as dependencies.

Today we accomplished one of the major goals towards Zend Framework 3: splitting the various components into their own repositories. This proved to be a huge challenge, due to the amount of history in our repository (the git repository has history going back to 2009, around the time ZF 1.8 was released!), and the goals we had for what component repositories should look like. This is the story of how we made it happen.

Matthew talks about the methods that were used to split things apart, even more so than they already were. While the components could be installed separately before, the methods used to get there were "cringeworthy". He talks about the different methods they've tried and the version bump issue that came with them, even when no changes were present. He talks about the ultimate goal of the refactor and the techniques to get there - a combination of grafts, subtree, subdirectory-filter and tree-filter through git. He covers some of the "stumbling blocks" they hit along the way including empty merge commits. The end result was a one-line command that could be executed and split out the provided component (well, with a lot of help behind the scenes).

He ends the post talking about the speed of the extraction process (hint: parallel processing is a happy thing), the ultimate results of the entire framework being split and a few lessons they learned along the way.

Freek Lijten has a new post today continuing his look at the world of PHP extensions and focusing in on testing this time. He hopes to answer the question of what makes a good, effective set of tests to help increase the stability and quality of the extensions you write.

In my previous blog I took you through the process of getting PHP and extensions compiled, generating code coverage and running tests. What I did not talk about was what makes a good test. I hope to correct on this by adding this post and going into more detail on the actual writing of tests itself.

Using the same extension as before (enchant) he goes through the addition of a test for the enchant_dict_add_to_session function. He start by showing how much the function is currently tested (hint: none) and code coverage. He points out that 100% coverage is just one metric in a set that should be considered and not the final goal. He shares a simple test for the function that checks to see if a certain word exists in a dictionary. The coverage report shows all lines being executed, but there's a lot not tested, at least conceptually. He shows how to test "the spirit" of the function with additional tests for non-existent words, spell checking and if a word is not in the dictionary at all. PHP example code shows these tests kinds of tests to illustrate the steps he's talking about.

In this new post to his site Mathias Verraes approaches the concept of the DRY principle (Don't Repeat Yourself) as being more about knowledge. He includes two "real world" examples where the business rules can change around you.

“Don’t Repeat Yourself” was never about code. It’s about knowledge. It’s about cohesion. If two pieces of code represent the exact same knowledge, they will always change together. Having to change them both is risky: you might forget one of them. On the other hand, if two identical pieces of code represent different knowledge, they will change independently. De-duplicating them introduces risk, because changing the knowledge for one object, might accidentally change it for the other object.

In his examples, he shows how hard-coded rules (like "a product container can only contain 3 products") could just be around certain needs, not the entire range of requests. He covers some of the principles of Domain-Driven Design and how they apply here, pointing out that changing rules in one part of the application can have an effect on other parts depending on it.

In a follow-up to his previous article about why languages don't matter, Brandon Savage has a new post (part two) carrying on the theme but getting more into the thought patterns behind language selection and use.

Developers like to think that companies hire developers to write code. But companies do not hire developers to write code; they hire developers to solve problems. They hire developers with the expectation that the developer knows about, or can learn about, the problems of the company, and find a creative solution to those problems at minimal cost.

It is therefore up to the developer to choose what tools they will use to achieve the outcome. The customer doesn’t much care what tools the developer uses; they only care that the outcome they desired is achieved.

He goes on to talk about preferences in the tools "used by craftsmen" and why they're less important than the result of the work they create. He notes that languages matter, but only in a certain context - as a piece of a puzzle, a part of a whole to reach an objective of functioning software.

Travis Swicegood, a member of the Standards Group that has formed in the PHP community, has posted some of his own thoughts about the group and what kinds of goals he sees it having.

A few weeks ago at php|tek, I corralled developers from all of the major PHP frameworks into one of the conferences rooms. The idea was simple: in the PEAR Group we've been discussing our new PEAR2 Coding Standard and have come to some conclusions on how PHP 5.3 code should be handled moving forward. A standard is only a standard if people use it, though, and PEAR is not entirely representative of the community at large. That's where this group comes in.

He mentions resolving namespacing issues around naming structures, classes/interfaces/abstracts and for Exceptions. He also sums up his thoughts on the openness of the group well:

I'd love to see an officially sanctioned standard come out of our work. All of us are too busy, both with real jobs and our various projects, to fight the battles that come of trying to make this a completely open process where anyone with an email address can contribute. Sad as it may be, pear-dev has demonstrated that coding standards *must* go the way of sausages and laws lest they devolve into a constant "but I think is better, and this is why..." followed by pages of well meaning, but generally irrelevant content.

Though it contains no code, this new article on PHPBuilder provides a good perspective for those looking to get into PHP and what to expect to find.

A couple of months ago, I knew almost nothing about PHP, only that is was a programming language that I needed to learn. Today, my whole site relies upon PHP and I have gained the confidence that almost anything is possible using PHP. I accomplished this achievement using methods that I will describe in this article.

The author talks about the methods followed to get into the language, including making smaller goals at first, just to get used to things. The manual is also suggested as a "best friend" for a developer and looking at other people's code can provide insight into your problems.

Though it contains no code, this new article on PHPBuilder provides a good perspective for those looking to get into PHP and what to expect to find.

A couple of months ago, I knew almost nothing about PHP, only that is was a programming language that I needed to learn. Today, my whole site relies upon PHP and I have gained the confidence that almost anything is possible using PHP. I accomplished this achievement using methods that I will describe in this article.

The author talks about the methods followed to get into the language, including making smaller goals at first, just to get used to things. The manual is also suggested as a "best friend" for a developer and looking at other people's code can provide insight into your problems.