Zeev SuraskiNightly builds for PHP 7.0 now available! (1.4.2015, 10:12 UTC)
For the many people that are interested in testing PHP 7 themselves - I have some good news.

We're now building the latest source snapshot of PHP 7 every night and posting it on http://php7.zend.com/.  Currently we're building tarballs for RHEL/CentOS and Debian/Ubuntu, but we'd be looking to add both .rpm and .deb installable packages as well as Mac and Windows builds.

Feedback welcome!

Paul M. JonesSeparate The User Interface Repository From The Core Application Repository (31.3.2015, 16:26 UTC)

tl;dr: Keep the core application (“model”, “domain”) code repository separate from the user interface (“controller/view”, “action/responder”) code repository; use a dependency manager in the user-interface repo to bring in the core-application repo.

Nihal Sahu asked on Twitter, “How do you ‘personally’ go about building an application? What Structure?” This post is my longer-than-140-characters response.

Obviously I’m a fan of Action-Domain-Responder as a pattern for web-based user interfaces. (ADR treats the request/response cycle itself as a user interface. The HTML/CSS/JS/etc that goes into the HTTP body is just one part of the presentation half of the user interface; ADR reminds us that the HTTP headers are part of the presentation, too.)

But ADR, and MVC, and the other user-interface patterns – they are not an application architecture in and of themselves. The “Domain” in ADR and the “Model” in MVC are just entry points into the underlying core of the overall application architecture. In a way, the “Action/Responder” and “Controller/View” portions of the UI are not the big deal in the application; the big deal is the underlying core. That’s where the real work happens.

With that in mind, one first thinks the right approach would be to separate the User Interface from the Core Application. This is obvious and uncontroversial; separation of concerns is a central tenet of good architecture.

What might be controversial is my extended advice regarding that approach. I don’t suggest a merely “logical” separation of concerns so that Action/Controller classes don’t have Domain/Model code in them. I suggest a “physical” separation. In other words:

Separate the User Interface repository from the Core Application repository.

Yes, I mean that you should have two code repositories for your application. Let’s explore that idea for a minute.

The first repository, the Core Application one, contains no user-interface code at all. No HTTP, no standard input/output, nothing. It expects to receive input in an interface-independent way, and it delivers output in an interface-independent way. Note that it receives the input. It has to be sent to the Core Application in some way, not read from the interface (no superglobals!). The injected input could be via method parameters, a plain old PHP array, an input object provided by the Core Application, a Command object provided by the Core application, etc. Likewise, the output could be via anything provided by the Core Application, such as a Model object, a Domain Payload, or something else. It is completely independent from any user interface code and can be tested on its own.

The other repository, the User Interface one, contains your “Action/Responder” or “Controller/View” (or “Command/Stdout”) code. There is no business logic at all. All it does it reformat the user input to something the Core Application will recognize, pass it to the Core Application, and receive back some output from the Core Application, which it reformats for presentation to the user.

But if the two repositores are “physically” separated, how can the User Interface get access to the Core Application? Composer becomes your best friend in this case. In the User Interface codebase, add "require": { "project-name/core-application": "dev-develop" } to composer.json. Issue composer update and voila: your Core Application is now available to the User Interface. The User Interface depends on the Core Applicatiion, but the Core Application has no dependency on the User Interface.

What’s great about keeping the repositories fully separated from each other is that it enforces developer discipline. It becomes difficult to put Core Application code in the User Interface code. Any attempts to do so are immediately obvious, and everyone watching can see it happening. It becomes harder to justify to yourself “I’ll add it just this one time” (and thus keeping off that particular slippery slope).

The tradeoff is that you now have to coordinate changes across two code repos. Breaks in the Core Application will break the User Interface. The disconnection can be a positive overall, since you can version the Core Application separately from the User Interface, but in practice it does mean you have to be more attentive to change management.

One more thing about keeping the User Interface “physically” separate from the User Interface in this way is that you start thinking differently about frameworks. I have begun to think that our vocabulary for describing frameworks in PHP land is insufficiently varied. MVC and ADR do not describe “application frameworks” – they might describe User Interface frameworks, but there’s no word for Core Application frameworks. Maybe they need their own separate framework term.

Davey Shafik[Slides] PHP 5.NEW: The Best Bits (ConFoo 2015) (31.3.2015, 14:00 UTC)

Presented 2/20/2015 at ConFoo 2015 in Montreal, Canada

Derick RethansXdebug 2.3: Improvements to Tracing (31.3.2015, 08:12 UTC)

Xdebug 2.3: Improvements to Tracing

This is the fifth article in a series about new features in Xdebug 2.3, which was first released on February 22nd.

In this instalment we are going to have a look at the additions to the trace file functionality. Trace files are a way to document every function call, and if you enable it, variable assignment and function's return values — including when these functions were called, and how much memory PHP was using at the moment of function entry (and exit).

Xdebug 2.3 adds a new type of parameter rendering for stack traces and function traces through the xdebug.collect_params setting. Existing options are 1/2 for just the variable type, 3 for a string description, and 4 for a string description and a variable name. Xdebug 2.3 now also features a base64 encoded serialized representation of the variable's contents (option 5). Which means that the following lines:

$a = array(1, "foo", M_PI);

show up in the following 5 ways with different variations of the xdebug.collect_params setting:

  1. var_dump(array(3))

  2. var_dump(array(3))

  3. var_dump(array (0 => 1, 1 => 'foo', 2 => 3.1415926535898))

  4. var_dump(array (0 => 1, 1 => 'foo', 2 => 3.1415926535898))

  5. var_dump(YTozOntpOjA7aToxO2k6MTtzOjM6ImZvbyI7aToyO2Q6My4xNDE1OTI2NTM1ODk3OTMxO30=)

This is probably more useful with the computerized trace files that are easier to parse.

In Xdebug 2.3, normal (human readable) trace files now also show the time index and memory usage for function exit lines. Function exit lines are generated when xdebug.collect_return is set to 1. Which means that with with Xdebug 2.2 you would see:

TRACE START [2015-03-28 18:48:39]
  0.0008     275928   -> test1() …/closure-trace.phpt:27
  0.0008     276848     -> {closure:…/closure-trace.phpt:20-22}() …/closure-trace.phpt:24
  0.0009     277168       -> strlen() …/closure-trace.phpt:21
                           >=> 3
                         >=> 3
                       >=> NULL
  0.0010     276056   -> xdebug_stop_trace() …/closure-trace.phpt:28
  0.0010     276184
TRACE END   [2015-03-28 18:48:39]

But in Xdebug 2.3 you instead see:

TRACE START [2015-03-28 18:48:45]
  0.0008     269144   -> test1() …/closure-trace.phpt:27
  0.0009     270096     -> {closure:…/closure-trace.phpt:20-22}() …/closure-trace.phpt:24
  0.0009     270336       -> strlen() …/closure-trace.phpt:21
  0.0010     270504        >=> 3
  0.0010     270216      >=> 3
  0.0010     269264    >=> NULL
  0.0011     269264   -> xdebug_stop_trace() …/closure-trace.phpt:28
  0.0011     269384
TRACE END   [2015-03-28 18:48:45]

This makes it easier to see how much time and memory a specific function call took, similarly to what already was shown for "computerized" trace files.

And lastly, the computerized format (xdebug.trace_format=1), has now support for showing return values as well. The return value is part of a new "frame" for a function.

Take the following invocation of PHP:

php -dxdebug.collect_params=0 -dxdebug.collect_return=1 \
        -dxdebug.trace_format=1 \
        -r '$a = array(1, "foo", M_PI); xdebug_start_trace("/tmp/trace"); echo
        serialize($a);' \
>/dev/null && cat /tmp/trace.xt

In Xdebug 2.2 this shows:

TRACE START [2015-03-29 00:08:34]
2    1    1    0.000417    267192
2    2    0    0.000547    266848    serialize   0   Command line code   1   1 

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

Cal EvansInterview with David Stockton (31.3.2015, 05:00 UTC) Link
SitePoint PHPWelcoming New Authors: January – March 2015 (30.3.2015, 16:00 UTC)

With a new schedule and regime, we changed the author introduction post to a once per three months frequency rather than every other month like it was. As March is drawing to an end (already?!), let’s see which new souls joined us in this era of peer review. We’ll also use this opportunity to mention our newest regular authors.

Regular Authors

We’ve seen an influx of increased enthusiasm from our most prolific members. The first two who get to pin this medal to their chest are as follows:

Younes Rafie, Morocco

Younes has been with us for a while, and has been aiming for the regular author position since Q3 2014. When a man knows what he wants, there’s little that will stand in his way, and Younes grabbed the opportunity by the throat. In 2014, he was one of our most prolific authors and in 2015 he only increased his output, always keeping quality and interesting topics in mind. I take great pride in being able to welcome him into the regulars circle, and I feel like he’s just getting started.

So far (in 2015), Younes published a whopping six posts and two quick tips. Keep up the great work!

Daniel Sipos, Belgium

Danny has been our Drupal expert since the day he joined. If anything was going on in the Drupal world we should know about, he was right on top of it, keeping everyone up to date and preparing the readership for Drupal 8’s imminent release. Danny earned his “R” badge in March, and starting with April, he’ll be a part of the regular circle.

Danny’s contributions not only to our Drupal corprus but also to the peer review process have been invaluable. He reviewed countless articles, shot pull requests left and right, and even made important suggestions for improving the entire workflow.

Danny’s 2015 portfolio counts five posts with more incoming. Excellent work!

New Authors

Apart from the regulars increasing their output, we’ve also had room to welcome some new souls on board. They are, in order:

Continue reading %Welcoming New Authors: January – March 2015%

PHP ClassesHow PHP 7 Can Help You Write Better Tests (30.3.2015, 11:57 UTC)
By Joseluis Laso
With the introduction strict type hinting, PHP 7 will creating more robust tests that will help us to develop better quality code.

Read this article to learn how you can write more robust tests in practice with the help of strict type hinting.
SitePoint PHPBest PHP Framework for 2015 – SitePoint Survey Results (28.3.2015, 17:00 UTC)

One month ago, we started the annual SitePoint framework popularity survey. Now that the month has expired, it’s time to look at the results and to distribute the prizes. The response was a whopping ~7800 entries, far more than any other survey we’ve held so far, and even after filtering out invalid entries we end up with a formidable number of valid participants.

First things first, as promised, here is the entire result set for your perusal: download. Do with it as you please - if you come up with some interesting graphs, please do share them with us! Read the “Data” paragraph below for some more details on the downloadable files.

Framework Winner

To view the full screen versions of all plots below, just click on them. They open in new tabs.

Continue reading %Best PHP Framework for 2015 – SitePoint Survey Results%

Paul M. JonesAura 3 Plans (27.3.2015, 15:25 UTC)

From the Aura blog:

  • The Past

    • Aura 1.x framework packages will see no new releases, and may be archived.

    • Aura 1.x library packages are near the end of active development; to prevent orphaning and end-of-life, ownership and authority over them they may be transferred to interested parties.

  • The Present

    • Aura 2.x packages that are currently stable will remain the center of development attention, with some modifications to Composer and PHPUnit support files, and with added testing on PHP 7.

    • Aura 2.x packages that are not currently stable will not see stable 2.x releases; they will become 3.x candidate packages.

  • The Future

    • Aura 3.x packages will target PHP 5.6, and additionally test on PHP 7.

    • Aura 3.x library packages will be allowed to depend on interface packages, though not other implementation packages.

    • Aura 3.x will not provide a framework under the Aura name, although the 2.x framework should be able to use 3.x components. Frameworks of Aura packages may be provided as separate projects.

    • Aura 3.x and later packages will have independent major version release cycles.

Read the entire post here.

PHP ClassesCreating a PHP Daemon Service (27.3.2015, 09:51 UTC)
By Dmitry Mamontov
Daemons are special applications that can monitor and process an important activity on a machine in the background.

Read this article to learn how to create a daemon in pure PHP, handling signals, handle multiple asynchronous I/O and events with libevent, monitoring daemon performance, starting the daemon and distribute your daemon application as a PHAR archive.
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP