The Master Zend Framework site has posted a new tutorial showing you how to automate your projects with Composer, making use of the "scripts" section to add commands that can be automatically executed via a "composer" command line call.

Here, in the second part of the series, we’ll look at the scripts section of composer.json. If you’ve never heard of this section, it provides a way to automate tasks in your project.

Perhaps you think that this is unnecessary, as there is already such a wealth of tools available; including Make, Ant, Phing, and so on. But I see a place for having automation in Composer — though at first I didn’t.

Why? Because you can bring everything that much closer together. Because you can keep everything in a very tidy, organized, and well-structured way.

He starts with a brief overview of how the "scripts" section of the composer.json configuration works. He also shows examples of setting up scripts for code sniffing, running tests and generating test coverage reports. He also shows how to run these commands via the Composer command line and an the use of event handlers (like "post-install-cmd") to execute things at a certain point in the install/update process. He finishes off the post with an example from Zend Expressive calling an "Automation" to clear out the contents of the caches.

Slack is awesome. Slack is the de-facto of modern team communication and I am pretty sure that this is not the first time you’re hearing something like this about slack. But if you’re really never used slack, oh boy, I feel pity for you. Anyway, in this article we’re going to make a slack bot that will monitor the sales in our envato account and notify from time to time as soon as someone purchased an item. Pretty useful, eh?

He shows how to make a new channel in your Slack instance (he uses "#sales") and how to add in a named webhook to connect the bot to. He then generates a token on the Envato service to access their API, giving it the needed permissions. He includes the simple curl-based script to make the request to the Envato API to get the latest results and then turn around and post it back to the Slack channel.

Hello friends. In this article we will be discussing automating the deployment of Laravel applications using the Capistrano tool. If you don't know what some of these things are, read on. [...] Why should we bother setting up Capistrano? Can't we just deploy to our servers by hand? Sure, maybe, but this quickly becomes annoying with anything more than a few servers, and isn't a scalable process.

He starts by laying out some of the prerequisites you'll need to get the deployment working: a Laravel application installed, some familiarity with Git/GitHub and a Linux-based system to work from. He talks about two methods of deployment, push and pull, and includes a summary (and illustration) for each. From there he starts to get into the detailed steps of setting up the deployment itself:

Protecting sensitive information (like configuration files)

Installing Capistrano as a Ruby gem

Setting up the SSH keys between systems

Setting up the receiving server

Setting up the Laravel project in a Capistrano deploy

Creating the steps in the deployment workflow

Doing the actual deployment

He includes all of the commands and configuration examples you'll need to make the deployment happen. He also finishes off with a few other things Capistrano could do for you including making a "sanity check" file and flushing memcache on deploy.

In a quick new post to his site Rob Allen shows you how to have Phing SSH into a Vagrant box as a part of the VM creation process. In his case, he uses it to run database migrations.

Now that I've started using migrations, I've discovered a minor irritant. I run this project on a Vagrant VM and have discovered that I keep forgetting to ssh into the vagrant box before running the migrations script. The obvious solution is to automate this and I decided to use Phing to do so.

He walks through the installation of the libssh2 software (if you don't already have it) and the ssh2 PHP extensionSshTask to make the connection as the "vagrant" user and execute the given PHP command.

Michael Dowling has a new post today with a new tool he's worked up that aims to make creating Changelogs simpler, building on the effort started by keepachangelog.com. A Changelog is a human-readable listing of changes between versions, ideally generated but usually manually created.

Open source projects often include some kind of changelog file that helps consumers of the project know the important changes that have been made between versions. The format and filename of a changelog typically varies from project to project; however, there’s some promising news…http://keepachangelog.com hopes to standardize how open source projects represent changelog files. I’ve recently begun modifying the changelog files of all of my projects to conform to this new changelog standard.

He then gets into the tool he's created, chag, and how to aims to help make this Changelog standardization even easier. He walks you through the installation and options it provides for extracting current contents, listing versions, getting the latest versions and updating the contents. There's also an option to tag the version with a Git tag and uses the entry data as the annotation. He then talks about the release process with two different flows: the one GitHub itself includes (GitHub Releases) and the other configured through Travis CI.

Geshan Manandhar has posted a "getting started" guide to getting a LEMP environment up and running (LEMP being Linux, Nginx, MySQL and PHP) through a Vagrant setup.

A software engineer tells to a colleague in his team "Man, it is working on your machine, but why is it not working on mine?", then they both find out that one has Ubuntu 12.04 LTS with PHP 5.3 and the other software engineer on which the code is working is Ubuntu 14.04 with PHP 5.5 after some investigation. If you have ever faced this or similar problem its high time to switch to a portable and a reproducible virtual development environment shared among all team members. This is a context where Vagrant comes into play.

He introduces Vagrant and some of the problems it can help with for development groups. He includes some of the basic terminology and mentions some of the alternatives, including Docker and some of the Google popularity results comparing the two. Finally, he gets down to creating the Vagrant configuration with the PuPHPet service with screenshots of each step of the way. He wraps up the post with a look at how you can determine if things are working and how to add records to your hosts file to make the machine easier to reference.

The SitePoint PHP blog has posted part two of their series looking at using Phake for automation in your applications. In this second part they take some of the basics they shared in part one and apply them in some more practical examples.

In part one, we covered the basics of Phake and demonstrated ways of executing tasks with it, covering groups, dependencies, and arguments. In this part, we’ll look at some sample real world applications of Phake. Note that the following examples are largely based on things that I usually do manually that need some sort of automation.

He includes three different task examples, each with the code to make them happen (and descriptions of what it's doing):

As developers, we often have to do repetitive tasks such as updating the database structure, seeding the database, writing CRUD code, running tests, and uploading files to a server. Wouldn’t it be great if we could automate these mundane tasks and proceed with solving the more important problems such as making our app more secure or more usable to our users? Phake, an automation tool written for PHP, can do those tasks for you.

They show you how to use Phake (not to be confused with this Phake) including getting it installed via Composer and the creation of a first Phakefile. The include examples of simple tasks, dependencies, grouping, adding descriptions and passing arguments. The command to run the tasks and the resulting output is also included.

My current project does periodic releases, we build a few things, then we work on getting a bunch of user feedback and changing/fixing things before we actually release. [...] When a branch merges in to the main line, we use the "fixes #42" notation to simultaneously close off the issue that it relates to. This has been working pretty well, and today I got the question "what's new since I last saw this project?" - so I created a changelog. It's rather rough-and-ready but I had fun so I thought I'd share.

The script operates off of a local git cloned version of the repository and grabs all commit messages with the tern "fixes" in it. The script then takes the log file, matches the issue ID and then makes a cur call out to the GitHub API to get that issue's description. This is then taken, formatted and dropped into the output.

Konstantin Kudryashov has posted a helpful hint for any web developer out there that knows the pain of constantly setting up VirtualHosts and local hostnames during their development. His suggestion makes setting them up simple using Apache2's "autohosts" support.

We all know, that web development is not as easy as it sounds and that it involves lot of different and sometimes really complex tools to just run or test stuff. We also know, that bootstrap (setup) of the project could take more time than you want it to. It’s not a big deal if you’re working on single project full time, but at KnpLabs, i’m bootstraping new sf2 project every 2 weeks. So this manual crafting of virtual host, edition of /etc/hosts and maintaining of those temp hosts everywhere made me really sick. So, at some point i’ve started to look for an elegant solution. Here is it.

He gives you all the commands, file contents and software you'll need to install (he uses Homebrew) to install dnsmasq and get it configured. The only Symfony-specific part of the process is the last step - getting the latest version of the framework and installing it.