The Voices of the ElePHPant podcast has posted the latest in their series of interviews with PHP community members. In this new episode host Cal Evans talks with Morgan Tocker,

They talk about Morgan's talk at Sunshine PHP 2015 about tuning MySQL queries using some of the built-in tools). He also mentions some of the newer features of the EXPLAIN handling including more information provided and other metadata provided as a part of the output. They also talk about some of the "cost" data associated with different queries and how they effect performance.

You can listen to this latest episode either through the in-page audio player or you can grab the mp3 and listen to it at your leisure. If you enjoy the interview, be sure to subscribe to their feed.

• pecl_http 2.3.1 * Fixed build on platforms that need stddef.h to define ptrdiff_t (e.g. CentOS 7.5)
  
  
• pecl_http 2.3.0 + Preliminiary HTTP2 support for httpClient (libcurl with nghttp2 support) + Improved performance of HTTP info parser (request/response line) + Improved performance of updating client observers + Improved performance of httpEnvResponse output to streams + Improved the error messages of the header parser + Added httpHeaderParser class + Added httpClient::configure() method accepting an array with the following options for libcurl: . maxconnects (int, size of the connection cache) . max_host_connections (int, max number of connections to a single host, libcurl >= 7.30.0) . max_pipeline_length (int, max number of requests in a pipeline, libcurl >= 7.30.0) . max_total_connections (int, max number of simultaneous open connections of this client, libcurl >= 7.30.0) . pipelining (bool, whether to enable HTTP/1.1 pipelining) . chunk_length_penalty_size (int, chunk length threshold for pipelining, libcurl >= 7.30.0) . content_length_penalty_size (int, size threshold for pipelining, libcurl >= 7.30.0) . pipelining_server_bl (array, list of server software names to blacklist for pipelining, libcurl >= 7.30.0) . pipelining_site_bl (array, list of server host names to blacklist for pipelining, libcurl >= 7.30.0) . use_eventloop (bool, whether to use libevent, libcurl+libevent) + Added httpClient::getAvailableOptions() and httpClient::getAvailableConfiguration() methods + Added support for HTTP2 if libcurl was built with nghttp2 support. + Added httpClientCurlHTTP_VERSION_2_0 constant (libcurl >= 7.33.0) + Added httpClientCurlTLS_AUTH_SRP constant (libcurl >= 7.21.4) + Added pinned_publickey SSL request option (libcurl >= 7.39.0) + Added tlsauthtype, tlsauthuser and tlsauthpass SSL request option (libcurl >= 7.21.4) + Added verifystatus (a.k.a OCSP) SSL request option (libcurl >= 7.41.0) + Added proxyheader request option (libcurl >= 7.37.0) + Added unix_socket_path request option (libcurl >= 7.40.0) * Fixed compress request option * Fixed parsing authorities of CONNECT messages * Fixed parsing Content-Range messages * Fixed httpEnvResponse to default to chunked encoding over streams * Fixed superfluous output of Content-Length:0 headers * Fixed persistent easy handles to be only created for persistent multi handles * Fixed the header parser to accept not-yet-complete header lines * Fixed httpMessage::toStream() crash in ZTS mode * Fixed the message stream parser to handle intermediary data bigger than 4k * Fixed the message stream parser to handle single header lines without EOL * Fixed httpMessageBody to not generate stat based etags for temporary streams - Deprecated httpClient::enablePipelining(), use httpClient::configure(["pipelining" => true]) instead - Deprecated httpClient::enableEvents(), use httpClient::configure(["use_eventloop" => true]) instead - Removed the cookies entry from the transfer info, wich was very slow and generated a Netscape formatted list of cookies - Changed the header parser to reject illegal characters Changes from RC1: * Fixed a shutdown crash with chunked encoded stream responses
  
  
• xdebug 2.3.1 Tue, Feb 24, 2015 - xdebug 2.3.1 = Fixed bugs: - Fixed issue #1112: Setting an invalid xdebug.trace_format causes Xdebug to crash - Fixed issue #1113: xdebug.*_trigger do no longer work, due to NULL not being an empty string
  
  

The Voices of the ElePHPant podcast has posted their latest in their series of community interviews this time with Larry Garfield, an advocate and well-known speaker in the PHP and Drupal communities.

They talk about Larry's involvement with Cal's "secret project" (no longer secret): the Wisdom of the ElePHPant book. Larry shares the concept behind his entry based on a quote from Pablo Picasso and when to break the rules. They also talk about Drupal 8 and the current state of the project.

You can listen to this latest episode either through the in-page audio player or by downloading the mp3. If you enjoy the episode, be sure to subscribe to their feed to get the latest.

The SitePoint PHP blog has posted a request for responses to a survey about which PHP framework you consider to be the best for 2015.

Almost a year and a half ago we published the results of a framework survey on the PHP channel. The survey, while producing fewer entries than our IDE survey still provided us with valuable insight into our audience and the state of individual vs. team developers out there.

With Laravel 5 fresh out of the oven, Phalcon being kickstarted into full-time development, and others reaching a much anticipated maturity, it's only natural we're curious about your preferences - have they changed? Do they remain unbudged? Do you wish you could switch so hard you can taste it, but aren't allowed to by your company? We're interested in all these points and much more.

The survey will run for a month and there's some prizes involved for the top "resharers" of the survey. You can submit your own votes directly through the post at the bottom. Questions range from which framework you prefer to which you use at your place of employment and why each was chosen. Submit your answers today and help get a better idea of the PHP framework landscape.

In an interesting new post to his site Matthew Setter wonders if an IDE like PHPStorm can be replaced by VIM, a standard in the editor community for decades.

Is it reasonable, even practical, to expect that a 30 year old application can match a modern one? Is it conceivable to be able to code as well using VIM, said 30 year old application, as I can in PhpStorm, with all the IntelliSense-lead functionality PhpStorm offers?

He starts with some of his recent experience with the editor and some of the things he's (happily) found it can do he didn't know before. He includes a screenshot of a multi-pane view, explains what each is and what he can do with them. He points out that this example is Markdown documents but it can just as easily be used for code too. Finally he talks about the subject any PHPStorm user wants to know about, the IntelliSense functionality. Unfortunately, while there are some tools he mentions that can do similar things, they don't provide the context PHPStorm can deliver.

He ends the post with an interesting question: is IntelliSense the right approach? He wonders if having more context is a better answer rather than just the auto-complete handling IntelliSense offers.

On his site today Jani Hartikainen has a new post helping to demystify some potential confusion around unit testing, test-driven development and behavior-driven development. He's talking about them in the context of Javascript in this case, but the fundamentals transfer to just about any other language, including PHP.

When you're just getting started with automating your JavaScript testing, there's a lot of questions. You'll probably see people talk about unit testing, TDD or Test-Driven Development, and BDD or Behavior-Driven Development. But which one of them is the best approach? Can you use all of them? I've talked to a number of JavaScript developers, and there seems to be some confusion about all this. So, let's take a look at Unit testing, TDD and BDD, and fix some of the common misconceptions about them out there.

For each he provides an overview of this basic concepts and a bit of sample code showing it in action. For TDD (test-driven development) there's not really a way to show it specifically in code as it's more of a practice. Instead he gives a "checklist" to follow when practicing it.

Unit Testing gives you the what. Test-Driven Development gives you the when. Behavior Driven-Development gives you the how. Although you can use each individually, you should combine them for best results as they complement each other very nicely.

• XML_Util 1.3.0
  
  
• Archive_Tar 1.3.14
  
  
• Structures_Graph 1.1.0
  
  
• Config_Lite 0.2.4
  
  

The GoPHP7 project has posted their initiative to try to improve the world of PHP for extensions and make them "first class citizens of the PHP community".

The goals of gophp7(ext) [are to]: get PHP extensions running "out of the box" when PHP7 is released (no lag time), make extensions in general easier to install and use (binaries, ppas), get more people involved in extension maintenance (and travis/appveyor running on them all, killing off bugs), get more documentation written for extension writing and codify some of the "best practices" of extension writing and design (a la PSR).

They're asking for help from anyone interested, even if you don't know C (what PHP extensions are written in). The project asks for just 30 minutes a day to help achieve their goals. The page also lists out the different ways you can help including cataloging the work that needs to be done on the catalog page and working on the development systems for PHP7 to make working with the extensions easier.

The "Snack Overflow" blog (from tech.graze.com) has a recent post sharing some suggestions to help unit test static calls without having to "refactor the world" away from them.

Imagine you have a situation [using a static method call] in some legacy code. Currently we can't unit test this as we can't mock out the doSomethingElse() call. So what do we do? Well we have two options really [...] neither of which is very appealing. [...] There is, however, a third option that gains us the ability to unit test Foo without having to touch Bar at all.

This option involves creating a "proxy" object of the "Bar" class that's non-static and only returns the result of the previous class' static method. You can then correctly mock that class and return the result in a more self-contained way. He lists a few caveats with this method including the fact that it could lead to a lot of proxy objects if there are a lot of static methods to replicate.

As is mentioned in this new post to the Laravel News site, the Homestead development environment now comes with support for the Blackfire.io profiler.

Blackfire Profiler by SensioLabs automatically gathers data about your code's execution, such as RAM, CPU time, and disk I/O. Homestead makes it a breeze to use this profiler for your own applications. All of the proper packages have already been installed on your Homestead box, you simply need to set a Blackfire ID and token in your Homestead.yaml file

With the configuration set up, the only installation the user needs to make is setting up the companion extension (Chrome) for your browser.