In a post to his site Adelf aims to help you answer the question of the use of either the Entrust or Laravel-permission packages in your Laravel application to handle your authorization.

"Hmmm, I need some basic authorization, like admin role for admin panel and maybe some editor/moderator role... Let's google it. Wow! Laravel already has packages for that! zizaco/entrust, spatie/laravel-permission and others! Let's choose one!"

That's how it usually happens. Then package's migration will add about 5 tables to store roles, permissions and their relations. [...] It only looks simple: just install package, run ready migration and go on. From long-term point of view for 90% projects it's not the best choice.

He starts with an example of a common situation for most web developers: the inclusion of the package, the database changes that come with it and the management of keeping the permissions in sync. He makes the suggestion that maybe this seemingly "simple" way may not be the best and that, in most cases, they're overkill for what an application needs. He shows how to slim down this functionality using Laravel's own gates/policies and boil it down to just the checks that need to be made without the package overhead.

On the AWS Developer blog they've posted about a new update in their PHP SDK functionality: a "changelog builder" that helps with automated changelog generation.

Starting with version 3.22.10 of the AWS SDK for PHP, released February 23, 2017, the Changelog Builder automatically processes all changelog entries. Each pull request is required to have a changelog JSON blob as part of the request. The system also calculates the next version for the SDK based on the type of the changes that are defined in the given changelog JSON blob.

The update simplifies the process of adding release notes to the CHANGELOG.md file for each pull request. Each merged pull request that was part of the release results in a new entry to the CHANGELOG.md file. The entry describes the change and provides the TAG number and release date.

This changelog is generated from a required JSON document for each pull request that provides information about the type of change, category and a brief description. They explain each of these items to give a little more context as to what they should contain along with a few examples.

This is something that could definitely help to improve other libraries as well, gathering the required change information from the contributor rather than having a project administrator have to sift through the PR to locate all changes.

As Freek Van der Herten mentions in this recent post to his site, it was announced by both Fabien Potencier (Symfony) and Taylor Otwell (Laravel) that the upcoming versions of the frameworks - Symfony 4 and Laravel 5.5 - will require PHP 7 by default.

According to Fabien Potencier, lead of the Symfony project, the next major version of Symfony, to be released at then end of 2017, will require PHP 7. But Laravel will drop PHP 5 support even sooner. Taylor Otwell, the creator of Laravel, announced that Laravel 5.5, to be released in June 2017, will leave PHP 5 behind.

Freek talks some about the improvements that come with PHP 7 and which he thinks will show up in the different frameworks' codebase. He sees this as "a message" to the PHP community as a whole that the migration to PHP 7 should happen sooner rather than later (and some of his own work to help reinforce this).

In his latest post Jordi Boggiano (of the Composer project) has released his PHP usage statistics for the second half of 2016 based on the information gathered during Composer installations.

It's stats o'clock! See 2014, 2015 and 2016.1 for previous similar posts.

A quick note on methodology, because all these stats are imperfect as they just sample some subset of the PHP user base. I look in the packagist.org logs of the last 28 days for Composer installs done by someone. Composer sends the PHP version it is running with in its User-Agent header, so I can use that to see which PHP versions people are using Composer with.

He compares them to the statistics from May 2016 showing some interesting but not unexpected changes, mostly in the growth of PHP 7+ versions. He shares a few of his own observations of the results and encourages library authors to start focusing on PHP 7 functionality rather than 5.5/5.6 compatibility. He also shares a secondary data set - the PHP versions that libraries require that, surprisingly, is moving a lot slower than the actual PHP version adoption.

Jordi Boggiano has posted some updated statistics around the use of the Packagist site around PHP version requirements and the relation of package downloads to PHP versions.

Last year I posted stats about PHP versions, and the year before as well, both time in November. However this year I can't wait for November as I am curious to explore the PHP7 uptake!

A quick note on methodology, because all these stats are imperfect as they just sample some subset of the PHP user base. I look in the packagist.org logs of the last 28 days for Composer installs done by someone. Composer sends the PHP version it is running with in its User-Agent header, so I can use that to see which PHP versions people are using Composer with.

He compares the previous statistics against the ones gathered back in November 2015, both in numbers and graphs. He shows the stats for the PHP versions being used and for the PHP versions that are required. It's interesting to see that there's been a good uptick in supported versions including PHP 7.0+.

Recently Cal Evans took an informal survey of fellow Twitter users and asked them what they thought was most important to see in a job ad for a developer position. In this new post he shares some of the results and responses to the question (with a surprising range of answers).

In my book “Culture of Respect” I have a section on writing job ads that will attract developers. I am in the process of revising that chapter, so I thought I would ask the people who actually read the job ads what they look for. The results weren’t that surprising to me. Having read a lot of job ads though, I am guessing that the results will be surprising to some managers out there.

He's embedded the tweets themselves in the post (straight from the horse's mouth, so to speak). Responses touch on subjects like:

• salary requirements
• clear definition of duties
• less "buzz words"
• well-defined list of technologies they'll be working with

The results are interesting and a definite must read for anyone coming up with job postings for open developer roles in your company.

On the HHVM blog there's a recent post looking at some of the requirements around traits and interfaces in the Hack language. More specifically, they talk about type checking with traits and how interfaces can be used to help provide extra structure.

In PHP, traits are a mechanism of code reuse that, while very powerful, are also difficult to type check both efficiently and exhaustively. In this post we’ll dive more deeply into the reasons for that and see how Hack solves those problems, allowing you to use traits in a safe way without limiting their expressiveness.

They start by talking about the main problem with PHP's handling of traits (essentially copy and paste into the current class) and how they felt Hack should "just work" in allowing type checking on these "pasted" methods too. Performance limitations prevented them from handling it how they do with other variable types, so they changed things up, using a "require extends" syntax to tell the Hack engine how to allow the checking based on an interface. There's a lot more to it than this, so be sure to read the rest of the post on how they came to that conclusion.

The SitePoint PHP blog has a new post today from Arno Slatius that talks about some of the features coming in Yii 2.0, a PHP-based MVC framework with a target for a stable release coming very soon.

Yii 2.0 was released into beta last April and the goal for a first stable release was set for the middle of 2014. The GitHub issue list has 300 open issues and 2913 closed while I’m writing this and both numbers are still increasing. The progress to the 2.0RC milestone was at 99%. My guess is that the team is close, but we’ll probably have to wait just a little bit longer. While we’re all waiting, lets take a look at what we can expect by looking at an already available example.

He starts with a "tiny bit of history" about the framework (its origins, the work done on 2.0) and talks about some of the requirements to get it installed and working. He helps you set up a sample project and shows off the Twitter Bootstrap integration, the debug bar and the "Gii" tool that can help generate code automatically (following the conventions of the framework). He finishes off the post with a look at some of the main things that changed in the 2.0 release including moving some method calls to properties, datetime handling, behavior definitions and model/view updates.

In this new post to his blog Robert Basic takes a look at what he calls a "real gem" in defining the requirements of his application - PHP_CompatInfo.

Last night I was pondering how nice would it be to have a tool of some sort, that would simply spit out what version of PHP does my app require. Something like: here are my .php files, what PHP version and/or extensions do I need for it? First I thought about jumping right in and writing it myself, but hey, this kind of a tool sounds way to useful not to be written already! After a bit of a googling there it was: PHP_CompatInfo. A nice PEAR package that can tell me everything I want about my code and even a bit more.

He includes a code snippet showing it in action. It's a basic example that defines the driver type to use, options and the directory to parse through (using parseDir() naturally). Other output formats are available too like CSV and HTML.

Following his Day Camp 4 Developers event, Cal Evans needed a way to release the videos and materials from the day long even to those that paid to attend. Obviously, a download link just wouldn't do, so he went looking for something a bit more powerful and WordPress-y.

It sounds like such a simple thing; just put them up for download, right? Not really. Let's look at the actual requirements: Shopping cart to allow me to eventually sell the videos, a way to let my existing ticket holders "buy" them for free. (Coupon codes), a way to keep the real location of the files hidden so people don't just go download them. Those were the biggest items. Beyond that I was willing to either sacrifice or code it myself.

After searching around and trying out a few solutions, he decided on eShop ("it's good, not great) a WordPress plugin that lets you set up a quite configurable ecommerce website. It also includes some basic statistics features, uses the custom post types to configure products and lets customers sign into the site to handle their own options.