On the SitePoint PHP blog there's a recent article posted by Christopher Vundi looking at the new features coming in Laravel 5.5, the next major release of the popular PHP framework.

Laravel 5.5 will require PHP 7.0+. For the features this modern PHP version brings, please see our recap.

Laravel 5.5 will also be the next LTS (Long Term Support) release. This means bugfixes for two years and three years of security updates. That was also the case with Laravel 5.1, but its two-year window of bug fixes is coming to an end this year. Without further ado, let’s see what this new version has to offer.

Instead of just describing the new features, the article opts to walk you through the installation of v5.5 and showing examples of each. Topics covered include:

Rendering Mailables to the Browser

Exception Helper Functions

Introducing the migrate:fresh Command

Automatic Package Discovery

Whoops is Back!

Custom Exception Report Method

Validation Data Return

Custom Blade::if() Directives

Autoregistering of New Artisan Commands in the Kernel

...among many others. There's a long list of new features coming in this release and the tutorial covers each nicely and provides the code examples it would take to make it all work.

On the QaFoo blog there's a new post sharing some ideas on how you can add new code to a legacy application and ship it successfully without too much interruption to the current code.

Usually the problems software needs to solve get more complex over time. As the software itself needs to model this increased complexity it is often necessary to replace entire subsystems with more efficient or flexible solutions. Instead of starting from scratch whenever this happens (often!), a better solution is to refactor the existing code and therefore reducing the risk of losing existing business rules and knowledge.

[...] Instead of introducing a long running branch in your version control system (VCS) where you spend days and months of refactoring, you instead introduce an abstraction in your code-base and implement the branching part by selecting different implementations of this abstraction at runtime.

They then give a few examples of methods that can be use to get the new code in:

Replacing the Backend in a CMS

Rewriting a submodule without changing public API

Github reimplements Merge button

The final point is broken down into the process they recommend including the refactor of the current code, starting in on the new implementation and deleting the old code.

The SitePoint PHP blog has a new article posted sharing "what's new and exciting in PHP 7.1", the latest major version release in the PHP 7.x series. This version was released on December 1st of 2016.

The PHP community has gone viral with the latest PHP 7 announcement and all the goodies it brings to the language. The PHP 7.1 release has more good news and features to offer. This article highlights the most important ones, and you should check PHP RFC for the full list.

Included in their list of enhancements are features like:

the ArgumentCountError Exception

Nullable Types

the Iterable Type

Catching Multiple Exception Types

Invalid String Arithmetics

For each item on the list some brief code examples are provided, often showing the difference between the new behavior and previous PHP versions.

Until late 2015, the Hack and HHVM documentation site was a fork of PHP's own documentation site. This had many shortcomings, and ultimately we decided that the best approach would be something custom. As most of the public Hack code at that point was toy examples, we decided to also make the site itself open, and start investigating the greenfield problems.

There are 3 basic approaches to 'library code' in Hack if there isn't already a Hack version:

Use a PHP library, without typechecker support

Use a PHP library, and add HHI files so that Hack understands it

Write something new

The Hack/HHVM site uses a mix of all three, though mostly #2 and #3.

He talks some about using plain PHP libraries in Hack projects and how you won't get the full benefit of Hack's features without some of the type-checking enforced (sometimes required to get some libraries working). Following this he covers the integration of three projects/structures, changed a bit for supporting Hack: FastRoute, PHPUnit and the things based on the PSR-7 request/response structure. He wraps up the post talking about writing "something new" and things to consider to make its APIs more "Hack-like".

In an effort to improve their "developer experience" (DX) around using the Symfony framework the development team has introduced new searching functionality to help more effectively find what you're looking for in the expansive Symfony documentation.

Symfony boasts one of the largest documentation pools ever written for an Open- Source project. Considering the ten different Symfony versions (from 2.0 to master) and including the code samples, Symfony Documentation has around 3.6 million words, more than three times the word count of the entire Harry Potter series.

They share some of the things they learned around creating a search engine ("it's hard") and what they ultimately ended up using - the Algolia service. The post talks about how they indexed the current documentation and broke it up into "chunks" of meaningful content. They also include the simple Javascript they use that links the search field to the Algolia service and renders the results using a view partial.

The proof of concept for the new search engine was a success and we decided to stop the ElasticSearch integration and stick with Algolia. The new search engine is greatly faster than the previous one and the search results are more accurate and relevant.

Over on Laravel Quick Tips we've been looking at a few of these functions and their uses, and I thought it might be helpful to collect all of them together in a single (I hope) coherent post.

Without further preamble, let's get to it. I'm going to use the basic User object and table that ships with a default installation of Laravel so you can follow along if you like.

He starts with the difference between "new" and "create", pointing out the one fundamental difference: one saves, one does not. He then looks at some of the other new/create functions (like findOrNew, firstOrCreate, updateOrCreate), what each of them does in the background and a quick snippet of code showing.

With the next Laravel release (5.1) coming soon, the Laravel News site has gathered together all of the information that's been shared about what's to come. In this new post they list some of the updates and code where needed to illustrate.

Laravel 5.1 is scheduled for release in May and lots of new features will be included in this release. Here is a list of eight of the big changes and new features.

Their list of eight includes things like:

LTS, Long Time Support

Resolve a service from blade

Middleware Parameters

Broadcasting Events

You can find out more about these and others on the list in the full post.

The Symfony blog has been posted spotlights in several of the improvements in the 2.7 release of the framework over on their blog. Each of them describes the changes and includes some sample code showing the new feature in action:

Expanding on the previous post about how much testing may be too much, they're back with another post in the series, this time focusing on the "economy of tests". This time Mathias is joined by Konstantin Kudryashov as a co-author.

A common complaint with teams that first try their hand at automated testing, is that it is hard, costly, and not worth the effort. On the other hand, supporters say that it saves them time. In this post, we'll try to add some nuance to the discussion. We'll take a look at how different levels of automated testing affect the cost of development, both in the short and the long term, for both greenfield and brownfield projects. Finally, we'll look at a simple strategy for introducing tests and migrating them across test levels, in order to reduce maintenance costs.

They start with some baseline definitions so everyone's on the same page - unit test, integration testing and system testing. The article also covers some of the basic kinds of testing metrics including execution speed, fragility and understandability. It then moves on and looks at the other major final factor in the overall cost of testing, the age of the project (new vs existing). He mentions the Testing Pyramid, how it's recommended to migrate tests and some of the common opposing forces to the test migration/creation.