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 a new post to his site Cees-Jan Kiewiet covers a new library he discovered - Cigar - and how to use it for smoke testing a ReactPHP application. Smoke testing (or "sanity testing") is the evaluation of the major functionality of an application rather than individual pieces of code.

Last week I came across Cigar, a smoke testing tool by Matt Brunt. Which, to me, is great stepping stone for my personal projects/sites to integration tests. In this post we not only go into Cigar, but also how to start your HTTP ReactPHP application, run cigar against it, and shut it down again. (Note that it doesn't have to be a ReactPHP application it can also be a NodeJS app, or PHP's build in webserver you use for testing.)

He then walks through the process of installing Cigar and creating the initial configuration file of endpoints to test (along with expected statuses). He then shows how to automate things further and creates a bash script that starts the ReactPHP application, runs the tests then shuts the application down. It's a simple script but can help save a few keystrokes every time the tests are run.

For the Laravel users out there the Laravel News site has shared some handy Bash aliases you can use from the command line to improve and streamline your workflow.

Bash aliases are shortcuts added to a file that allows you to reference another command through more memorable words, abbreviations, or characters. For example, if you use Git you may run git status many times throughout the day, so to save yourself time and keystrokes you could alias gs to git status and it’ll automatically expand and call the proper command.

Over the years I’ve seen a lot of unusual aliases and many are unique to the person. Shortcuts that make sense to me, might be confusing and weird to you. That’s what makes these so fun.

He shares how to create a basic alias in your .bash_aliases file and then shares some from different users in the community:

• WaveHack
• Jeffrey Way
• Bill Mitchell
• freekmurze
• sebastiaanluca

Each contribution includes the code needed to define their preferred aliases. They cover everything from general console command simplification out to more complex Laravel-specific functionality.

Rob Allen has a quick new post with a handy script you can use to auto-complete Composer script names on the command line (for bash).

As I add more and more of my own script targets to my composer.json files, I find that it would be helpful to have tab autocomplete in bash. I asked on Twitter and didn't get an immediate solution and as I had already done something similar for Phing, I rolled up my sleeves and wrote my own.

He created the bash completion file where Bash could locate it (a special "bash_completion.d" directory). He includes the code you'll need to have in the bash script and briefly explains how each line works. He also includes an example of the output showing how the script catches both the built-in and custom commands as auto-complete options.

In a new post to the ServerGrove blog they look at linting tools for various circumstances including standard PHP, Twig templates and Composer configuration.

Today’s projects are built up from dozens of different components, configuration files, third-party libraries, tests, build scripts, etc. And even if you have the greatest test suite, bad things can happen sometimes. It’s important to catch bugs as early as possible, and syntax validators can be a great (and easy) addition to your continuous integration system. You would be surprised at how many problems are caused by syntax errors. At ServerGrove, we see these kind of problems with our clients almost every day.

Their list shows you how to lint (syntax check) several different types of content:

• standard PHP code
• Twig templates
• Composer configuration
• XML files
• Bash scripts
• JSON files
• YAML files

Some of them use tools that already come built-in (like PHP's "-l" or Twig's "twig:lint") but others require the use of external software such as xmllint or melody. Command examples are also included for each.

Joshua Thijssen has a new post to his site sharing an interesting tool for those using PHPUnit for testing. It's a real-time plugin that executes your tests as soon as something in your files change.

Not all IDEs (actually, i haven’t seen even one IDE that does this), can run your unit-tests as soon as something changes. Inspired by Greg Young’s Mighty Moose system, the following script runs inside a shell, will wait for changes in your PHP-files, and runs the corresponding unit-test as soon as something changes. It doesn’t run the WHOLE unit-tests suite, but merely the test that matches up the source file.

His tool, found here on Github and uses a simple bash script that uses the file name being saved to locate the matching test and execute it, reporting back any errors that might have popped up. This could easily be hooked into most IDEs out there and keep the developer in one place.

Kevin van Zonneveld has a new post that, while not PHP specific, does have a handy script that will help you stop committing broken code.

Whatever the reason, it's almost 2014 and we are still committing broken code. This needs to stop because best case: Travis or Jenkins prevent those errors from hitting production and it's frustrating to go back and revert/redo that stuff. A waste of your time and state of mind, you were already working on other things. Worst case: your error goes unnoticed and hits production.

To help resolve the problem, he suggests using the "hook" system common to most version control software. In his specific example, he shows the use of a pre-commit hook that fires off a bash script on the files being committed. He includes the full code for this bash script that includes a check for PHP scripts using the built in PHP linter (the "-l" option on the command line). He also includes the commands and updates you'll need to make to get it installed on git.

There's a feature that's usage has been showing up more and more in software projects (both open source and not) that allows you to install their system with a single line command, usually involving curl and maybe piping it to a shell. In this recent post Michael Maclean takes a look at this trend and some of the possible pitfalls of the approach.

There has been a trend in the last while for various bits of useful software to have a one-line shell command recommended as the installation method. The usual form of this is to pipe something like curl or wget to some interpreter, be it bash, php, ruby, or some such. [...] This [type of] command takes the output of curl and pipes it straight to bash. I have several issues with this.

His three main points center around the fact that you cannot inspect the code before executing it with this method, that you can't verify the source of the code and that it teaches users bad habits of trusting in "magic commands" like these.

On the Zumba Engineering blog there's a new post showing you how to implement bash shell "autocomplete" with a special option for a second argument.

This weekend I saw the bash completion for CakePHP from Andy Dawson and had an idea to do the same for our service application, because we frequently forget the exactly job class or method name and add extra steps to verify these names before execute the job. I read his code, made some research and finally get our bash completion working fine.

In his case he wanted to see what things a module in the application had to offer, so he implemented a "__check__" argument that looked at the third argument and used reflection to get the methods allowed for it. Also included in the post is the bash alias you'll need to set up to get it working (and where to put it to make it cooperate).

Andrew Johnstone has a new post to his blog with a look at using Vagrant for continuous deployment of a PHP-based application.

Vagrant is simply a wrapper around Virtualbox headless that allows for provisioning virtual machines with support for puppet, chef-solo, chef, and bash. This allows you to automate the deployment and sandboxing of development sites. Additional base box images can be found at vagrantbox.es.

He walks you through the full process of setting up a first deployment - getting Vagrant installed, updating the config for a squeeze64.box image, configuring a virtualhost on the Apache web server and setting up a "preinstall" script to configure things like MySQL and install a long list of packages (via apt-get).