PHP ClassesPHP 7 Migration guide Part 3: 11 Changed Functions and 21 New Functions (27.4.2016, 07:36 UTC)
By Atif Shahab Qureshi
In the first two parts of our series on PHP 7 migration guide we cover backwards incompatible changes and new features.

Read this article to learn more about functions that were changed and other new functions that were added.
Link
Matthew Weier O'PhinneyOn Deprecating ServiceLocatorAware (26.4.2016, 17:25 UTC)

A month or two ago, we pushed a new release of zend-mvc that provides a number of forwards-compatibility features to help users prepare their applications for the upcoming v3 release.

One of those was, evidently, quite controversial: in v3, zend-servicemanager no longer defines the ServiceLocatorAwareInterface, and this particular release of zend-mvc raises deprecation notices when you attempt to inject a service locator into application services, or pull a service locator within your controllers.

The arguments go something like this:

  • "Dependency injection is too hard to understand!"
  • "This feature simplifies development!"
  • "If this is so bad, why was it in there in the first place?"

These are usually followed by folks:

  • saying they'll switch frameworks (okay, I guess?);
  • asking for re-instatement of the feature (um, no);
  • asking for removal of the deprecation notices (why? so you can delay your pain until upgrading, when you'll ask for re-instatement of the feature?); or
  • asking for a justification of the change.

So, I've decided to do the last, justify the change, which addresses the reasons why we won't do the middle two, and addresses why the assumptions and assertions about ServiceLocatorAware's usefulness are mostly misguided.

Originally posted elsewhere

This was originally posted as a comment on an issue. I've decided to post it to my blog to reach a larger audience, and to provide a bit more background and detail.

The intent of zend-servicemanager is for use as an Inversion of Control container.

It was never intended as a general purpose service locator (interestingly, that link details mostly disadvantages to the pattern!); that role was something foisted onto it in the spirit of "rapid application development" and to "simplify initial development," but the intention even there was that, once a class has stabilized, you should refactor to inject dependencies. (And we all know what happens with busy developers: refactoring is put off or never occurs.)

Why shouldn't you inject a service locator?

Google for "service locator anti pattern" to get an idea of why it shouldn't be used. The main points boil down to:

  • Dependency hiding.
  • Error indirection.
  • Type safety.
  • Brittleness.

Let's look at each of these individually.

Dependency hiding

What is meant by "dependency hiding?"

Take a look at this class signature:

class Foo implements DispatchableInterface, ServiceLocatorAwareInterface
{
    /* Defined by DispatchableInterface */
    public function dispatch(Request $request, Response $response);

    /* Defined by ServiceLocatorAwareInterface */
    public function setServiceLocator(ServiceLocatorInterface $serviceLocator);
    public function getServiceLocator();
}

Based on that, you'd expect:

  • that you can instantiate the object with no dependencies.
  • if you feel the need to, you could pass a service locator to the instance.
  • you should be able to execute dispatch() by passing it a request and response instance, and it should successfully return.

The service locator is nebulous; its purpose isn't clear, and it's clearly not a required dependency, as it's in a setter method.

So, you go and write a test for the dispatch() method, and you get a ServiceNotFoundException. What's wrong?

You dive into the code of the dispatch() method:

public function dispatch(Request $request, Response $response)
{
    $authentication = $this->serviceLocator->get('authentication');

    if (! $authentication->hasIdentity()) {
        $response->setStatus(401);
        return $response;
    }

    $identity = $authentication->getIdentity();
    $response->setBody(
        $this->serviceLocator->get('renderer')->render(
            'foo',
            ['identity' => $identity]
        )
    );
    return $response;
}

There's two possible places that ServiceNotFoundException may have been thrown: on the first line of the method, or within the setBody() call. In both cases, you're faced with a conundrum:

  • You now know that the service locator is required. That wasn't obvious from looking at the class o

Truncated by Planet PHP, read more at the original (another 10717 bytes)

Link
Paul M. JonesMulti-Project Issue Tracking With Producer (26.4.2016, 14:06 UTC)

With Producer, you can get a list of the open issues from your remote origin by running producer issues from the project repository:

$ cd ~/Code/radarphp/Radar.Adr
$ producer issues
radarphp/Radar.Adr

    14. Separate Package for ResponderAcceptsInterface?
        https://github.com/radarphp/Radar.Adr/issues/14

    29. Service level actions?
        https://github.com/radarphp/Radar.Adr/issues/29

$

However, I’m the lead on about 40 different packages and projects, and at one point or another many of them have issues to be tracked on Github. It’s tedious to go to each package repository to list its issues separately. I want to be able to see a list of all issues on all my projects; then I can review them all at once to see what gets my attention.

To get a list of all open issues on several projects, you can create a bash script that changes to each project directory and runs project issues in each one:

cd ~/Code/atlasphp/Atlas.Cli; producer issues;
cd ~/Code/atlasphp/Atlas.Orm; producer issues;
cd ~/Code/auraphp/Aura.Accept; producer issues;
; ...
cd ~/Code/radarphp/Radar.Project; producer issues;
cd ~/Code/relayphp/Relay.Relay; producer issues;
cd ~/Code/relayphp/Relay.Middleware; producer issues;

Call the script all-issues.sh, make it executable with chmod +x all-issues.sh, and then you can issue ./all-issues.sh to get a list of all open issues on all your projects. Pipe the result to a file for easy viewing if you like!

Link
PHP ClassesUsing Microsoft Visual Studio as PHP IDE with the PHP Tools extension: Part 1 PHP Editing Support (26.4.2016, 06:37 UTC)
By Dave Smith
Microsoft Visual Studio is a very popular IDE among developers using Windows but it does not come with built-in support to PHP. On the other hand, 75% of the PHP developers use Windows when they are developing their PHP projects.

Fortunately for Visual Studio fans there is an extension called PHP Tools that adds PHP support to that IDE and works with the Micros

Read this first part of the article to learn how to use the PHP Tools extension so you can setup and edit PHP code projects from Visual Studio.
Link
Voices of the ElePHPantInterview with Juliette Reinders Folmer (26.4.2016, 04:00 UTC)

Video

Audio only

@jrf_nl

Show Notes

The post Interview with Juliette Reinders Folmer appeared first on Voices of the ElePHPant.

Link
Ben RamseyPost-Open Source (26.4.2016, 00:00 UTC)

I’m a tad late to this discussion, but I think it’s still pertinent today—perhaps even more so—and Jordi Boggiano’s recent post, “Common files in PHP packages,” got me thinking about the lack of open source licenses in public repositories.

In his post, Jordi explains how he analyzed all packages at Packagist, specifically for the sake of identifying common file names developers are using for their change logs. As part of that analysis, he was also able to tell how many projects have a license file, about which he writes:

55% [of PHP packages at Packagist] have a LICENSE file, that’s.. pretty disastrous but hopefully a lot of those that don’t at least indicate in the README and composer.json

In a 2013 analysis of software licenses on Github, Aaron Williamson, then Senior Staff Counsel at the Software Freedom Law Center, found that 14.9% of repositories had a top-level license file, while 3.7% only announce the license in the project’s README1. Of the top licenses, he noted that there has been a significant shift since 2000 in favor of more permissive licenses (MIT, BSD, etc.) and surmises this could be the result of “corporate influence/allergy to GPL” or a reaction against the GPL, favoring “freedom of developer over freedom of users.” Why are so few repositories adding open source licenses?

Luis Villa posits it might be because developers are rejecting permission culture.

The open license ecosystem assumes that sharing can’t (or even shouldn’t) happen without explicit permission in the form of licenses. What if “post open source” is an implicit critique of that assumption – saying, in essence, “I reject the permission culture”?

So, when James Governor posted in September 2012 his sentiment about younger developers being about “post open source software,” it was perhaps a bit of tongue-in-cheek crotchety cane-shaking about a cultural shift in developer attitudes toward open source and the need to grant permission.

If we’re in a post-open source era and open source licenses represent permission granted to use one’s code, then is this era marked by a reaction against the need for that permission? After all, the “younger devs” grew up in a post-Napster world full of DRM, EULAs, IP/copyright lobbyists, and legalspeak about what we can and cannot do with the content and software we’ve purchased. Open source licenses are yet another way to proliferate that permission culture. It’s no wonder there’s a backlash against the need for licenses.

In Lawrence Lessig’s 2004 book Free Culture, Lessig warned:

Free cultures are cultures that leave a great deal open for others to build upon; unfree, or permission, cultures leave much less. Ours was a free culture. It is becoming much less so.

Are open source licenses just another manifestation of the shift to a permission culture and away from a free culture? While companies have embraced open source software and many contribute back to open source projects under a variety of permissive licenses, I can’t help but feel that open source is losing its soul. These days, I don’t hear people talking about it as a philosophy. Rather, the focus is always on licensing and business cases—the permission to use it.

What do you think? Do open source licenses propagate permission culture? Are we in a post-open source era?

  1. The analysis used FOSSology to examine 1,692,135 Github repositories out of about 6 million. Alternate locations of licenses could not be accounted for (file headers, subdirectories, unexpected file names, etc.).

Truncated by Planet PHP, read more at the original (another 956 bytes)

Link
Adam CulpUbuntu 16.04 and PHP 7 not rendering (25.4.2016, 23:48 UTC)

After reloading my working laptop with Ubuntu 16.04 LTS (I prefer to do a reload versus an upgrade, for each LTS version) I was very excited to install PHP 7, and installed Apache2 and PHP7 using the standard Ubuntu repositories. I used the typical commands:

$ sudo apt-get install apache2
$ sudo apt-get install php7.0

However, after doing the installs I discovered the PHP scripts would not render in a browser. After a small amount of digging I realized that doing the installs did not include one important piece. The package ‘libapache2-mod-php7.0’ was not automatically installed as expected, and as it did in the past. (I don’t remember needing to install it separately in the past.)

$ sudo apt-get install libapache2-mod-php7.0

So one quick install like shown previous and all is working fine.

Happy PHP’ing.

Link
SitePoint PHPFirst Look at Pagekit CMS – Clean, Extensible, Fast, But… (25.4.2016, 16:00 UTC)

Pagekit hit version 1 recently, and as I'd been looking at personal blogging engines, I thought it'd only be fair to check it out. Granted, blogging is merely a subset of the functionality Pagekit can offer, but a good basic test-drive subset nonetheless.

Pagekit logo

Installation

Note: we'll be using Homestead Improved for the environment in which to test things. All the commands, if any, will be listed with that in mind. Adapt for your own OS if necessary.

To install, we download and extract their archive, then point the web server to the newly created folder. Pagekit will immediately greet us with the installer screen.

Pagekit installation screen

After a short but incredibly smooth installation process, we land on the dashboard.

Pagekit dashboard

From the dashboard, we can access all other parts of the site like managing users, configuring new pages and routes, installing themes and extensions, deal with widgets, and more.

The permissions/roles subsystem is a bit limited in its default state, supporting only authenticated users, admins, and guests, but for a blog, which is what we're testing here, that's more than enough. If need be, more roles can be added in the Roles screen later.

Setting up a Pagekit Blog

Custom Pages

First things first, let's set up an about page. If we head off to Site, and then Pages, we can set up a new page. Conveniently, Pagekit supports Markdown out of the box so we can use that to write the content.

Creating an about page

Continue reading %First Look at Pagekit CMS – Clean, Extensible, Fast, But…%

Link
Zeev SuraskiSelling PHP 7 to Your Boss (25.4.2016, 14:29 UTC)


Investing the time to upgrade to PHP 7 is one of the easier sells in PHP's history.
Still, if you need help convincing your boss it's worth the time, just use this simple illustration:

PHP 5.6


PHP 7.0


I tried to get the elePHPants to do that but they weren't nearly as collaborative...
Link
Voices of the ElePHPantPostcards From My Life – 007 (25.4.2016, 13:27 UTC)

Dear Reader, The view from the dock of our favorite dive boat. Until next time, I <3 |<</p>

The post Postcards From My Life – 007 appeared first on Postcards From My Life.

Link
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP