On the Laravel News site today there's a tutorial posted showing you how to combine Docker and Laravel's Scheduler/Queue and make them still run as they would on a virtual server.

In Laravel, one of the tricky changes when switching from a virtual server to Docker is figuring out how to run a scheduler and a queue worker. I see this question come up quite a bit when PHP developers are trying to figure out how to use Laravel with Docker.

Should you run them on the host server? Should you run via cron in a Docker container?

There are a couple of ways I recommend running the scheduler command and Laravel queues in Docker, and we’re going to cover the basics of running both with a complete (albeit simple) Docker setup you can use to experiment.

Their approach uses a single multi-purpose Docker image rather than splitting the functionality up and making it more complex (Laravel subscribes to the monolithic approach anyway). The post then gets into the setup of this environment using Docker and docker-compose to configure several services: application (app), a Redis container and a MySQL container. The contents of the docker-compose and Dockerfile configurations are included as well as the VirtualHost configuration for the main site. Next it shows the use of the CMD directive to run a bash script when the build is brought up. This is what kicks off the scheduler/queue handling. The post finishes up with a few other changes needed to the Docker configuration and the creation of the "scheduler" service.

In this post to his site Freek Van der Herten shares information about a tool that can help to streamline your development workflow. The phpunit-watcher tool mimics tools from other languages to watch for changes in the source of your application and automatically execute your PHPUnit tests when modifications are made.

In the JavaScript world Jest, built by Facebook, is an excellent tool to run tests. Not only can it automatically rerun your tests when source code changes, but there’s also an interactive mode where you can set a filter on which tests to run while the tool is running. Would it be great if we could have these awesome features while working with PHPUnit?

Our newly released phpunit-watcher tool provides a Jest like experience. You can simply install it by running composer global require spatie/phpunit-watcher.

Once the tool is installed it can then be run from the command line, sitting and waiting for changes to the target files and directory. It's configurable in case you don't follow some of the usual package directory structures and can be filtered to only run on certain filename matches. This can also be done manually (real-time) via the tool. Screenshots are included showing the tool in action too.

The SitePoint PHP blog has a new tutorial posted by author Thomas Punt that walks you through the execution of PHP - a "behind the scenes" look at how the PHP processing engine does its magic.

Inspired by a recent article on how Ruby code executes, this article covers the execution process for PHP code. [...] There’s a lot going on under the hood when we execute a piece of PHP code.

He then walks you through the four main steps the engine goes through to turn your PHP code into results: lexing, parsing, compilation and interpretation. For each stage in the process there's a brief description of what piece(s) of the language are doing the work and some examples of how to see the results in more user-land PHP code (like with the AST parser).

Rob Allen has posted a tutorial to his site making some updates to his previous work with the Doctrine migrations handling as a standalone component. In this new tutorial he talks about the newer way to use it in your projects.

Since, I last wrote about using the Doctrine project's Migrations tool independently of Doctrine's ORM, it's now stable and much easier to get going with.

He starts with the basic installation and configuration of the migrations tool, making use of a SQLite database as an example. He then shows the use of the basics of using it to make database changes:

• creating a new migration
• running the migrations

Each step comes with code, the commands you'll need to execute and an example of the resulting console output.

The Scotch.io site has posted a tutorial that aims to help you understand middleware in Laravel applications - how they work and how to create ones based on your custom needs.

HTTP Middlewares provide a convenient mechanism for filtering HTTP requests entering your application. Laravel, for example, has a middleware for verifying a user's authentication.

These are some cases where I have had to resort to using middleware. There are many more cases where you would like to use a middleware. [...] By the end of this article, you should be able to create a middleware, registers it and use it in your projects. We will be illustrating the creation till usage of middlewares by creating one of our own. Our middleware will enable maintenance either site-wide or on some routes.

They start by creating a middleware (theirs is DownForMaintenance) and how to register it with Laravel as a valid middleware option. By default they will execute with every request but you can narrow them down to only happening on certain routes (examples included). There's also mentions of middleware parameters, grouping middleware and deferring the response return until after other code is executed.

On DZone.com today there's a post covering the different kinds of handlers that can execute PHP - those pieces of code that work with the web servers we use every day to interpret and execute PHP code.

PHP Handlers? mod_php? FPM? How do we make sense of the inner workings of PHP outside of our lines of code? We know we can run PHP on the server to build web applications swiftly, but how can we optimize our environment and configurations to reach maximum scale? We know that PHP has its drawbacks for not being asynchronous or event-driven, which is all the more reason to ensure maximum optimization. The impact of your server environment on your PHP application performance can be more than you think you can afford. A careful examination of your PHP ecosystem will help you avoid suffering performance loss in areas you can otherwise solve for easily.

They provide a brief summary of what PHP handers, well, handle and where they fit in the overall architecture of execution. They then get into the details on some of them:

• CGI – mod_cgi
• suPHP – mod_suphp
• DSO – mod_php
• FastCGI – mod_fcgid
• FPM (FastCGI Process Manager) – php-fpm

Included in each is an overview of how it works and some of the main advantages (and disadvantages) of their use. He also mentions two of the most popular web servers that work with these handlers: Apache and Nginx.

Stephan Hochdörfer has a quick post showing how he has PHPunit up and working on an HHVM instance. His problem was that the tests were actually executing using the "php" binary, not the HHVM one.

For quite some time we run the unit tests for our libs and tools against PHP and HHVM, at least that is what I thought up to now. As it turns out I missed a minor detail. [...] What happens now is that Phing is executed via HHVM but PHPUnit will still be executed via the PHP binary because the PHPUnit shell script will look for the php binary in the PATH configuration. Since we run HHVM side-by-side with PHP on our Jenkins build nodes I was not able to point /usr/bin/php to /usr/bin/hhvm - which would be the easiest and cleanest solution. I

He shares the workaround he created, creating a symbolic link between the hhvm and php binaries and then executing the Phing task to run the tests. This is being run via Jenkins and uses it's "WORKSPACE" as a container so the main "php" binary isn't overwritten.

The Mastering Zend Framework site (from Matthew Setter) has a new post today showing you how to execute SQL queries directly in a Zend Framework v2 application.

Whilst there are many ways for building and executing SQL queries in Zend Framework 2, the two that I usually use, and which are also used in the ZF2 manual, are closures and the selectWith function. I previously wrote a three part series, showing how to get started using the ZendDbSql classes with Zend Framework 2, but I didn’t cover how to actually run them. So in today’s tutorial, let’s do that.

He gives examples of these two methods starting with closures in a "tableGateway" select call. He shows how to add on parts of the query like "wheres" and an "order by" as well as some basic formatting. He then gets into the "selectWith" examples, showing the same criteria just added a different way. He also includes an example of the "tableGateway" objects used for the examples and how they're configured.

Maarten Balliauw has a new post to his site showing you how to execute your unit tests (in this case PHPUnit) when you deploy your instance out to the Windows Azure platform.

When deploying an application to Windows Azure Web Sites, a number of deployment steps are executed. For .NET projects, msbuild is triggered. For node.js applications, a list of dependencies is restored. For PHP applications, files are copied from source control to the actual web root which is served publicly. Wouldn’t it be cool if Windows Azure Web Sites refused to deploy fresh source code whenever unit tests fail? In this post, I’ll show you how.

He creates a super basic script using Silex and writes up a test with some dummy assertions, checking if true equals true. He then steps you through updating the current "deploy.sh" script to add in a call to execute PHPUnit and an "exitWithMessageOnError" statement. This statement kicks it back and causes the deployment to fail when tests don't pass (as seen here).

PHPUnit, the popular PHP unit testing tool, has undergone some changes in its methods of deployment. First it was integrated into the Composer/Packagist dependency management system and now it's been implemented as a phar archive. Sebastian Bergmann explains how to use it in his latest post.

Downloading a single file to use PHPUnit? Not an idea that is too phar out anymore! Starting with version 3.7.5, PHPUnit seems to finally work correctly when packaged as a PHP Archive (PHAR).

He includes a list of steps you can follow to pull down the latest code and use the phar branch that executes with the archive file instead of the local "phpunit" executable. Of course, you can still (as always) install PHPUnit via the PEAR process as well.