On the Symfony blog there's a post with a major announcement for the users of the framework - the end of the Symfony Standard Edition, a release version that tried to bundle in the common tools a developer might need.

When I started to work on Symfony 2 many moons ago, I decided to create a set of decoupled components instead of a monolith framework like symfony 1. This choice was probably one of the key reasons of the immediate success of Symfony 2. [...] Of course, people don't want to assemble the components themselves when starting a new project. To fill the gap, we created the Flex was born. [...] Thanks to the new Flex approach, we've decided to not provide the Symfony Standard Edition for Symfony 4.0.

In the post Fabien talks about some of the history behind the Standard Edition including why it was made and what problems it solved. He then points out that, with the introduction of Flex, many of the issues and flexibility the SE lacked are worked out. While it is a little more complex to get started with a Flex application, the unpacking functionality helps with bringing in bundles of packages related packages without having to require each individually.

The final day of 2016 has come and gone and with it came the end of active support for the PHP 5.6 series of releases. This also marks the end of active support for anything in the PHP 5.x major release and pushing on with PHP 7. In this post to thePHP.cc blog Sebastian Bergmann talks about what this means for you and the tools you use.

The active support by the PHP project for PHP 5.6, the final release series of PHP 5, ends today. What is "active support"? And what does it mean for you? To answer this, you need to understand PHP's release process.

He starts with the release schedule and when it shifted from the "consensus based model" over to an official process, introducing more formality to the whole process (in 2012). He mentions two key terms to the process: "active support" and "security support". PHP 5.6 has moved past active support and is now in the the security support phase with only security fixes to be released from here on out. Sebastian then talks about what this means for your current code and, if you're still running on PHP 5.6, what you should do to come up to speed with PHP 7.x. He lists some of the projects that are moving into the world of PHP 7 only including PhpSpec 4.0, Laravel 5.5 and Symfony 4.

The Three Devs & A Maybe podcast has posted their latest episode (#53, released December 31st) with a year in review and some of their own experiences over the last year.

In this weeks episode Mick and Edd reflect on their busy years. We first discuss how work has wrapped up for the new year, and how subtle design changes result in huge benefits. Following this, we compare our personal experiences with product and agency work - chatting about the different programming design mindsets and work-flows used in each case. This leads on to the well-timed appreciation for the work of Martin Fowler, Uncle Bob and Greg Young - inc. valuable tests, the importance of a name and there not being a single 'silver bullet' to solving a problem. Finally, we wrap up with what we both would like to learn this upcoming year and Edd's experiences building a mega PC for a friend.

Topics mentioned include hexagonal architecture, using pull requests as code reviews and domain driven design. You can listen to this latest episode either through the in-page audio player or download the mp3 directly. If you enjoy the show, be sure to subscribe to their feed too.

NetTuts.com has completed their series on refactoring with the posting of part eleven today: "The End?" This post finishes off a series where they've moved from the most basic level of testing out to a complex set of tests that can ensure your code's quality and functionality even after making their recommended refactoring changes.

In our previous lesson we've learned a new way to understand and make code better by extracting till we drop. While that tutorial was a good way to learn the techniques, it was hardly the ideal example to understand the benefits of it. In this lesson we will extract till we drop on all of our trivia game related code and we will analyze the final result.

They start off by "attacking the longest method" (wasCorrectlyAnswered) by starting the testing process. They make some simple checks to ensure the output is correct for various circumstances and values. With these tests in place, they safely refactor the method, splitting it up into functional pieces and completely dropping the method in favor of more targeted handling. They finish off the post with a look at some final results and comparing the refactored code with the original on things like lines of code, complexity, dependencies and structure (using this tool).

On the SitePoint PHP blog there's a new post with an interesting question for PHP developers that might go against how they were tought to code from their early days - should you close your PHP tags at the end of your code?

Even those with a modest grasp of PHP know that code must be enclosed within special tags. [...] However, if your file contains just PHP - and no escaped HTML code - the closing ?> tag is entirely optional. Many developers argue that unnecessary code should be removed but there's another reason you could consider scrapping the closing tag.

Their rationale is that, in some situations, extra characters or other information could pop up after that closing PHP tag and cause problems in your code. If you drop the closing tag completely, there's no risk that this could happen and PHP parses it the same way.

There's lots of great comments with opinions both for and against.

For those wondering about the status of his book, "Zend Framework: Survive The Deep End", Padraic Brady has posted an update of where he's at.

Since the rumor mill has been active a while, I confirm two chapters of the book will be released this week. [...] To kick off a new spell of book updates, the next Chapter will be "A Simple Hello World Example", with an Appendix titled "Virtual Hosts On Apache 2". The following Chapter approximately one week later will be an introduction to the application to be built for most of the first half of the book.

He notes that, while normal print books usually have schedules, self-publishing is a bit more flexible. He does want to assure the readers of the book that work is actively being done and the chapters will keep coming.

DevShed has posted their next-to-last article in their look at using XDebug in your applications - part six, a look at doing some benchmarking with functions the extension provides.

You'll be pleased to hear that the Xdebug extension comes equipped with additional functions that allow us to perform other debugging tasks, such as benchmarking PHP applications and checking in what order certain functions were called by the PHP engine. Therefore, in this sixth chapter of the series I’ll be discussing in depth how to take advantage of the benchmarking abilities offered by the Xdebug library, which rely heavily on its "xdebug_time_index()" function.

Their benchamrking example uses the xdebug_time_index function to compare the start and end times of a script. Dropping it into a method in a class makes it even easier - they call the getTime method in their Timer class to grab the latest value.

Padraic Brady has an update about his "Zend Framework: Survive the Deep End" book he's been self-publishing on his site including a change to his current donation set up.

In experimenting with making money (so I can buy that Macbook Pro) I'll be adding some changes to how donations work. One main change is that while the current PDF file for the existing chapters will remain available (including future updates), PDF files covering the entire book to date will only be available to those who donate.

The online HTML-only version of the chapters will always be free of charge, but the PDFs (from here on out) will be for those who donate. He is also considering adding screencasts to the series to provide a bit more interactive feel to the whole Zend Framework topic.

Sean Coates has a reminder posted to his blog for all of the aspiring PHP speakers out there to get their proposals in for this year's (well, next year's) php|tek 2008.

I just want to drop a quick reminder that the php|tek 2008 Call for Papers is about to close (on Oct. 31), so if you've been dragging your feet, now would be a good time to stop doing that and send in your proposals.

Some of the topics they're interested in this year are rich application development, PHP4->PHP5 migration and looks head at PHP6. Check out the Call for Papers page on the php|tek site for the full list of information you'll need to include along with the summary for your proposal.

Sean Coates has a reminder posted to his blog for all of the aspiring PHP speakers out there to get their proposals in for this year's (well, next year's) php|tek 2008.

I just want to drop a quick reminder that the php|tek 2008 Call for Papers is about to close (on Oct. 31), so if you've been dragging your feet, now would be a good time to stop doing that and send in your proposals.

Some of the topics they're interested in this year are rich application development, PHP4->PHP5 migration and looks head at PHP6. Check out the Call for Papers page on the php|tek site for the full list of information you'll need to include along with the summary for your proposal.