These [support] scripts often run PHP in Gimme Bar land, and we make extensive use of the shebang syntax that uses common Unix practice of putting #!/path/to/interpreter at the beginning of our command-line code. Clearly, this is nothing special -lots of people do exactly this same thing with PHP scripts. One thing I have noticed, though, is that many developers of PHP scripts are not aware of the common Unix(y) environment helper, env.

The "env" alias makes use of your currently defined include path to track down a PHP binary to use to execute the script. Since there's only a "best practices" approach to places to put PHP on a server, the "env" usage makes your script more portable and it's one less thing to remember to change.

If you distribute a PHP application that has command-line scripts and shebang lines, I encourage you to adopt the practice of making your shebang line "#!/usr/bin/env php". Note that this doesn't just apply to PHP of course, but I've seen a definite lack of env in the PHP world.

In case you've been living under a rock for the past couple of years, Vagrant is the latest development in easily controlled virtualised environments. [...] Vagrant automates creation and provisioning of virtual machines within VirtualBox via the command line, whilst also allowing for easy distribution and reuse across multiple projects. In this article, I'm going to look at how it can make life considerably easier when dealing with development environments.

Included in the post is just about everything you'll need to get started using this powerful tool:

• A link to Vagrant images
• A guide to the VagrantFile
• the Provisioning process
• Interacting/Controllig the Vagrant VMs

He also includes a basic setup of an environment (with the Vagrant config to create it) and an example of using Puppet to provision the Vagrant VMs.

Doing development on multiple projects can be a burden from time to time. One project would be running on PHP 5.3, while another still needs 5.1. Sometimes you need a MySQL server, while on other occasions, you need a NoSQL solution like couchDB or MongoDB together with all kind of gearman functionality. This article shows you how I've setup such a development platform that allows you to quickly create new projects, and still maintain flexibility when you need it.

He uses VirtualBox with either a Debian or CentOS installation as a base platform. He uses Vagrant to set up and configure the machines to make setup almost automatic. He still has to go in and configure a few things like the VirtualHost and DNS settings for the site/application he's working on. Next up is setting up the tools he uses, specifically XDebug and setting up his editor of choice (PHPStorm) for remote debugging.

I've been playing around with Sublime Text (because of the awesome vim bindings) and was thinking about why do I always have to be logged into the remote server to do my work. Normally I connect using SSH, then attach to my tmux session and then fire up vim. This is okay but it lacks a certain elegance in it's approach. [...] What I'm chafing against is having to deal with multiple environments all the time to get my work done.

His ultimate goal is to be able to update and commit code without having to be logged into the remote server - essentially to replicate the local development experience regardless of the underlying technology. Have a suggestion or a method that's currently working for you? Leave him a comment!

Back in the good old days - and in internet-time, this actually means just a few years ago - people were quite happy with their LAMP stack: Linux, Apache, MySQL and PHP. With this quartet, or a variation on it like PostgreSQL instead of MySQL, we could do everything: create a blog-site, setup an e-commerce web shop, making a guestbook, you name it and it was there.. But times have changed... radically.

He talks about this "brave new world" developers live in today where they can't know everything that happens in every facet of the application (he likens it to the responsibilities of generals vs infantry in the army).

As a programmer, you simply cannot pretend that you and you alone are running a system. You are part of a whole, and even though you might be the most important part, or the controlling part, you still need to work with other components in order to get the job done. If you forget this, no matter how good your part is running, the whole system will fail because you either decided to do too much yourself, or did not correctly utilize the rest of the system.

Wondering what his acronym stands for? LAMPGMVNMCSTRAH is short for "Linux, Apache, MySQL, PHP, Gearman, Memcached, Varnish, Ngnix, MongoDB, CouchDB, Solr, Tika, Redit, ActiveMQ, Hadoop."

In the first two parts of this series we covered setting up the server and an introduction to Phing. This post will cover managing our database code with dbdeploy and Phing.

He points out that there's no "silver bullet" when it comes to automated database management but he's found dbdeploy as a good tool for his needs. He includes the configuration changes to get the database login information into Phing and a few new targets/tasks to add to the Phing configuration for initializing the database and applying patches.

Recently I have become quite interested in quality assurance. Not that many things are going wrong for me, but I'd really like to be more certain about the quality of my work. I've used some tools to help me achieve just that. In less than two hours you can set up your workspace and have the living daylights automated out of you!

He provides a full guide to getting the full stack set up including the command-line calls you'll need to make, creating a new build file for Ant and setting up the PHP tools (like Phpmd, DocBlox and Pdepend). In the end, you should see something similar to this setup in your Jenkins build.

With OS X 10.7, Apple continues to ship PHP 5.3 with PEAR, GD and PDO_MYSQL out of the box. This is how to set it up from a clean install of 10.7.

He goes through each of the pieces of software and talks about where to download the latest from and what configuration steps are needed:

• MySQL
• Apache
• the php.ini
• Xdebug
• PEAR
• PHPUnit (and friends)
• PECL OAuth
• mcrypt

In the first part of this series we looked at setting up our Apache installation to make life easier. Now that the basics are sorted we can start looking at how to structure our development environment and run some basic build tasks using Phing.

He shows how to use the PEAR installer to get Phing installed (including all of its dependencies) and creating the base directory for it to use in your build. He includes the contents of some of the configuration files (available on github) to set up some properties and the steps to the build process in the build.xml. He explains each part of the build process and includes some screenshots of the end result.

I dunno about anyone else but my development environment is usually in some form of barely-controlled chaos. It's one command away from collapse with folders full of test software, symlinks that lead to long-forgotten libraries and ancient VCS repos that only a mother could love, all held together with sticky-tape shell scripts. [...] This series of posts will look at the tools available to PHP developers who want to be liberated from the mundane and the frustrating tasks that plague our lives.

He doesn't describe the installation of the basic platform - Apache, PHP and MySQL on Ubuntu - but jumps right into the details of the settings. He shows how to:

• configure the VirtualHosts in Apache,
• installing and updating PEAR,
• Install/configure XDebug,
• Set up PHPUnit,
• and install git for version control

In the next post he'll show how to set up Phing for building/testing out the code.