The php[architect] podcast, hosted by PHP community members Eric Van Johnson and John Congdon, has released their latest episode: Episode #16 - Remotely Working. In this episode they're joined by guests Jennifer Wadella and Oscar Merida.

Eric and John discuss learning about how the OPCache works, working with Jenkins, being a remote worker, and diving into PHP internals. Oscar talks lessons learned when adding AWS S3 service to phparch.com. He also describes the all-new approach to tracks and speakers for php[tek] 2019.

[The episode also includes an] interview with Jennifer Wadella from Kansas City about remote working, her community work to reach women and minorities in tech, and kombucha brewing,

You can listen to this latest episode either using the in-page audio player or by downloading the mp3 directly. If you enjoy the show, be sure to subscribe to their feed to get updates when new shows are released.

The php[architect] podcast, hosted by PHP community members Eric van Johnson and John Congdon, has posted their latest episode: Episode #12 - Whole lot of Xdebug

Our twelfth episode is in the can, thanks to Eric van Johnson and John Congdon. Eric and John discuss freelancing and how it changed John’s life, regular expressions, PhpStorm, and how the PHP community gets together. [Their guest] Oscar talks about trying to use Xdebug regularly and the value of debugging tools in general [and there's an] interview with Mark Niebergall on his Xdebug article, his day to day work, and working remotely.

You can listen to this latest episode either using the in-page audio player or by downloading it directly. If you enjoy the show, be sure to subscribe to their feed to get updates when new shows are released.

In a new post to his site Matthias Noback has a post showing you how to, when using the Behat functional testing framework, to create local and remote code coverage metrics.

PHPUnit has built-in several options for generating code coverage data and reports. Behat doesn't. As Konstantin Kudryashov (@everzet) points out in an issue asking for code coverage options in Behat: "Code coverage is controversial idea and code coverage for StoryBDD framework is just nonsense. If you're doing code testing with StoryBDD - you're doing it wrong."

He starts off by talking about code coverage and why you might want it for the tests created through Behat. Code coverage metrics are usually associated with unit tests but having those numbers for the functional tests can be helpful too. He then covers the two pieces of the puzzle needed to gather the coverage numbers: an extension for the local coverage and one for the remote coverage. He shows how to get both of these installed, configured and used in the code to gather the results. Finally he shows how to use the phpcov tool to merge these results with the PHPUnit results to get a better overall view of coverage numbers.

The Delicious Brains blog has an interesting post, the second part of a series, talking about staying healthy - both mentally and physically - while working from home. In this new article several people share their own ideas, habits and experiences that have helped them keep up while being a part of a remote team.

It’s been just over a year since we posted about our struggles to stay healthy whilst working from home in a remote team. In that time we’ve had two new members join the team, one full company meetup and one regional, one new baby, two engagements and three home moves, so I thought it was about time we give an update on where we are with our health. Ian did promise an update 6 months after the last, but don’t hold it against him.

He post shares thoughts and comments from eight different people, each with their own unique experiences and recommendations (what works for some doesn't for others). Most of the suggestions include recommendations of regular exercise, making mental health a priority and better sleep habits.

The SitePoint PHP blog has a recently posted tutorial showing you how to send event messages from PHP to a remote Logstash server running your PHP on a system with Windows installed. Logstash's goal is to centralize the logging in your environment, allowing you to input log information from a wide range of sources and stored in an Elasticsearch database.

By opening this article you’ve endeavored yourself to expanding your knowledge of PHP applications as part of event-based distributed systems. You’ll be given a quick intro into what we are referring to when we say event messages, what Logstash is, and why it is so cool.

If you’ve already heard of Beats or understand you can run Logstash locally to ship logs to another Logstash instance or directly to a datastore such as Elasticsearch, this article is still for you and will show you an easy-to-configure-and-run, hopefully more effective and certainly fun-to-use alternative.

They start with the quick introduction to Logstash and how the event handling they'll add in later will relay messages over to the waiting server. A code example is included showing how to manually write to rsyslog, pointing out that it and Logstash use a similar protocol to receive messages. The tutorial then shows how to view the messages in the log to ensure they're making it correctly and how to use this agent to stream messages over to the waiting server.

Adam Culp has followed up some of his previous posts about the setup and configuration of remote debugging in PHP applications (more specifically in Zend Studio) with this new post. In it he shows how to use a SSH tunnel to allow debugging to happen through a firewall for those cases when direct access isn't possible.

In a previous post I covered how to set up step debugging in Zend Studio. But if that doesn’t work there may be a firewall in between the server and the debugging client, or IDE, preventing the connection. Here is a possible way to get around that.

He assumes that you already have the SSH server and connection available to you (he doesn't cover the install of that part). He then steps you through the setup of Zend Studio to add a new server, configure the SSH tunneling and remote/local ports to use. In his case he was using Zend Server so switching on debugging was as easy as turning in debugging via the toolbar. It's also worth noting that another popular PHP IDE can handle SSH-based debugging as well - PHPStorm - as seen here.

The Three Devs & A Maybe podcast has released their latest episode today, Episode #68 - Podcasting, Remote Working and Testing with Adam Wathan.

This week we are very lucky to be joined by fellow podcaster and host of Full Stack Radio - Adam Wathan. We begin discussion with his reasons behind starting a podcast, experience being a solo-host and the secret to great podcast recordings. We then move on to how he got into programming at high school - with reflection on that if he had been using a Windows machine at college, he would most likely be a .NET developer by now. As both Edd and Adam work remotely at this time, the topic of remote pair-programming and Kanban style board implementations then arises. Finally, we discuss his thoughts on Message-passing vs. strict-contracts, Smalltalk and Elixir exploration and how it is hard to give a definitive answer on the best way to begin learning TDD.

You can listen to this latest episode either through the in-page audio player or by downloading the mp3. Be sure to subscribe to their feed if you enjoy the show too!

Gary Hockin has a recent post showing how you can debug PHP HTTP requests from the command line using PHPStorm and XDebug. These instructions aren't specific to PHPStorm, however. They can be used in any IDE/editor that supports remote XDebug connections.

At PHP North West I had huge difficulties configuring Xdebug and both my PHP and PHP Storm so they play nice in a CLI environment. So here, for others and almost certainly my future self, is how to do it.

He goes through each step of the setup process assuming that you already have the necessary software installed. He shows how to configure XDebug for remote debugging in the ini configuration, setting up PHPStorm to receive the connection and, finally, adding the "XDEBUG_CONFIG" environment variable to tell PHP to relay the requests back to your waiting IDE.

In the latest in his series covering some of the improvements in the latest Xdebug release, Derick Rethans has posted this new article detailing some of the performance enhancements related to remote debugging that come with this new version.

This is the fourth article in a series about new features in Xdebug 2.3, which was first released on February 22nd. In this article we are looking at the improvements towards "remote" debugging.

The updates include showing the values of user-defined constants, being able to set an exception breakpoint on all exceptions and additional features around debugging the exceptions themselves. The output now includes the exception's error code and which exception the flow was broken on (though in his example of PHPStorm, the IDE won't report that information back). The last change he mentions is a change that reverts the output to a log if it can't write to a socket (usually SELinux related).

On the Hack blog there's a new post talking about async, a feature in Hack that allows for code to "cooperatively multitask". This gives the language a way to keep moving on in the execution without having to wait for things like database queries or remote file fetches to finish.

This is somewhat similar to threading, in that multiple code paths are executed in parallel, however it avoids the lock contention issues common to multithreaded code by only actually executing one section at any given moment. “What’s the use of that?”, I hear you ask. You’re still bound to one CPU, so it should take the same amount of time to execute your code, right? Well, that’s technically true, but script code execution isn’t the only thing causing latency in your application. The biggest piece of it probably comes from waiting for backend databases to respond to queries.

She gives the example of pulling in a remote file (HTTPS, where there's a bit more latency) and how to use async, await, WaitHandle, and Awaitable to work around the timing issue. She shows how to make a method asynchronous and how to join the results of the operation back up with the rest of the script. This includes the use of various "handles" including RescheduleWaitHandle, SleepWaitHandle and the AwaitAllWaitHandle. She shows the integration of a custom cURL handler that makes use of this processing, marked async, to multithread the requests to the remote server(s).