The SitePoint PHP blog continues their "How to Build Your Own PHP Package" series with their latest post (part two of the series) covering the use of test-driven development while working on the package code.

In part 1, we set up our development environment, baked in some rules as inherited from The League, and created two sample but useless classes - Diffbot and DiffbotException. In this part, we'll get started with Test Driven Development.

He starts by briefly introducing PHPUnit, a PHP-based unit testing tool, and how to use it to generate the HTML version of the code coverage report. He helps you define a good phpunit.xml configuration file and how to execute a first sample test (code provided) from inside PHPStorm. From there he adds one some more complex testing of exception handling and checking the class types. With this foundation, he moves into the test-driven development (TDD) practices. TDD means writing the tests before writing the code to make those tests pass. He gives an example of this and shows how test abstract classes too. He then comes back around and writes the code to satisfy the test.

In the next part of his series introducing the upcoming version of the Laravel framework Matt Stauffer has posted part 16, about generating missing events.

Sometimes it can seem like a lot of work to create an event, create its handler, and bind the two. Create a command, create its handler, bind the two. I've often wished for a workflow that handled the whole process together in one. The artisan commands for generating commands and events are a good start--they both create their own entity and (optionally) its handler. But you still can spend an hour writing the command and handler, and then waste another 15 minutes trying to figure out why it's not working, only to realize you never actually bound the two together.

The solution to this in Laravel 5 is the "event:generate" handling with the artisan command line tool. He includes a look at the event handlers directories and files before executing the command and what changes post-execution, including the sample code generated for the event.

In this new post on thePHP.cc blog Stefan Priebsch talks about some of the backwards compatibility breaks that will be coming with PHP's next major version, PHP7.

According to the PHP project's current time line, PHP 7 is scheduled to be released later this year. The version number 6 will be skipped for good reasons. As is expected of a new major release, there will be some breaks in backwards compatibility. Such breaks are always a double-edged sword: some have been eagerly awaiting the removal of legacy features, others expect that existing software keeps working without modifications. The PHP project is notorious for keeping some sins of the past dating back to PHP 3 in an effort to ensure backwards compatibility. Now, with the release of PHP 7, the decision has been made to remove some features that have been marked as "deprecated" in PHP 5.

He talks about how PHP will be "re-engineered" for this major release including a uniform variable syntax and some of the things this could break (like Magento 1). He also mentions the removal of the mysql (not mysqli) extension and a major issue - that PEAR has stopped working in recent versions of PHP7 (built from the current codebase) because of how it calls non-static methods statically.

The Loosely Coupled podcast, hosted by PHP community members Jeff Carouth and Matt Frost, has posted their latest episode - Episode 18: Best Practices. In it they talk about "best practices" as it relates to teams and working with other developers.

In this episode Jeff and Matt will talk about their experiences of getting teams moving on good practices. They will cover times when it has been challenging to convince higher-ups the value of doing certain things, all the way to how to go about changing teams by example. This episode is sponsored by our friend, Coderabbi, who is currently on the Wisdom as a Service World Tour 2015.

You can listen to this latest episode either through the in-page audio player or by downloading the mp3. If you enjoy the show, be sure to check out previous episodes and subscribe to their feed.

• briceburg/silverstripe-flexilink (0.1.0) Link to SiteTree Pages, External URLs, YouTube Videos, &c. from a single, flexible SilverStripe field.
  
  
• voku/simple-cache (1.0.6) Simple Cache library
  
  <

• PHP: rfc:error_handler_callback_parameters_passed_by_reference #phpquickfix, #rfc, #error, #handler, #parameters, #passbyreference
  
  
• PHP: rfc:date.timezone_warning_removal #phpquickfix, #datetime, #warning, #remove, #rfc
  
  
• Announcing Zend Framework 3 - The Future of PHP Frameworks - The Zend Blog #phpquickfix, #zendframework3, #announcement, #future
  
  
• The PHP Paradox #phpquickfix, #paradox, #jobs, #knowledge, #language
  
  
• PHP Benelux conference - Freek Lijten #phpquickfix, #phpbenelux15, #conference, #wrapup
  
  
• Five Minutes with Jonathan Deaves - Laravel News #phpquickfix, #fiveminutes, #artisanfiles, #jonathandeaves
  
  
• Creating Your Own Widgets Using Various WordPress APIs: Introduction - Tuts Code Tutorial #phpquickfix, #wordpress, #widget, #api, #introduction
  
  

php[architect] magazine has just released their January 2015 issue - "Be The Boss". This issue includes articles talking about freelancing, the importance of communication in open source and the usual columns.

This month is a personal favorite of mine, as the theme is "Be the Boss". It speaks to those who wish stop working as an employee and strike out on there own, something I've done twice in my life. In Get Off the Freelance Roller Coaster!, Yitzchok Willroth (@coderabbi) talks on the importance of not placing all of your eggs in one basket (or projects with one vendor). In Choose Your Own Adventure-Freelancer or Founder?, Joshua Warren talks about the two avenues that are open to those going it on their own, freelancer or business founder.

Articles in this month's edition include:

• Get Off the Freelance Roller Coaster! (Yitzchok Willroth)
• Choose Your Own Adventure - Freelancer or Founder? (Joshua Warren)
• PHP and OS Communication (Julien Pauli)
• An Introduction to NodeJS

The usual columns (Laravel Tips and Education Station) return once again as well as a a new one from David Stockton called "Leveling Up" to help you become a better developer. You can pick up your own copy from the php[architect] website.

In part one of a new series on the SitePoint PHP blog Bruno Skvorc looks at the right way to start a PHP package using a set of guidelines that have evolved recently in well-structured, well-tested PHP packages.

In recent years, good standards for PHP package design have popped up, in no small part due to Composer, Packagist, The League and, most recently, The Checklist. Putting all these in a practical list we can follow here, but avoiding any tight coupling with The League (since our package won't be submitted there - it's specifically made for a third party API provider and as such very limited in context).

The list of rules includes topics like having a license selected, using PSR-4 autoloading and having in-depth code comments. Bruno uses these as a foundation and starts in on the creation of a package. He uses the PHP League skeleton structure to create the files and folders for a basic package. From there he updates the contents with details for his Diffbot example and installing other needed software libraries. The rest of the post is broken up into the two remaining steps and examples under each: sticking with the PSR-2 guidelines and planning for the structure of the package.

NetTuts.com has posted the next part of their series focusing on design patterns (and more specifically implementing them in PHP). In this latest post they look at a simple version of the Factory design pattern.

When you think of a factory, what comes to mind? For me, it's a place where things are created - that is, it's a centralized placed where things are produced. Later, the delivery of said products are done by the factory based on an order. Let's say that you're requesting a car. A factory will create one based on the specifications of the work order and will then deliver it once it's complete. Just as their real world counterparts, a software factory (that is, software that implements the factory design pattern), is an object that is responsible for creating and delivering other objects based on incoming parameters.

They mention the three different versions of the factory pattern but focus in on the simplest one (hence the "simple" in the title). They continue on with the car example, showing how to use a simple factory (a "carFactory") to build an instance of the "Car" class based on different classes of car types. The object is constructed when a "build" method is called with the type.

Matt Stauffer has a new post to his site today showing you how to extend Laravel's Application class to enhance its handling with other handy features.

It's seldom that we need to extend Laravel's core, and even when we do, it's most likely we're going to extend specific components, which is detailed in the docs. However, all of these instructions presume you're using the core Laravel Application (IOC Container) to extend the other classes. What if you want to extend the Application itself?

The example he provides is from his own real-world experience, based around changes they wanted to make in the default folder paths for things like the "storage" or "public" directories. He shares the three simple steps to making this custom handling work:

• Extend the class
• Register it in your application's bootstrap
• Override/extend the current methods to add in your own functionality

In this case, changing the default paths is something that's under discussion already, but it gives a good simple example of changing that default functionality.