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.

Phing is a tool designed for automated project building based on Apache Ant distributed as a PEAR extension. It provides the user with the possibility of building the project / application in the same manner as make does with its Makefiles, making complex process execution (which is commonly human error prone) much easier.

He walks you through the steps for getting Phing set up, the directory structure you'll need for your project and a sample build and property files as well as an example of the output from the build execution. He talks about filters, execution control, extensibility and looks at some of the things that he suggests automating.

In this post, I'll show you how to deploy your PHPUnit tests with your application, have the tests run as a start up task, and have the results written to your storage account for analysis. Attached to this post is a .zip file that contains a skeleton project that you can use to automatically run PHPUnit tests when you deploy a PHP application to Azure. I'll walk you though how to use the skeleton project, then provide a bit more detail as to how it all works (so you can make modifications where necessary).

He has it broken up into a few easy-to-follow steps:

• Download the AzurePHPWebRole zip archive and unpack it
• Copy your application, tests and PHP installation into the resulting file structure
• Create a skeleton "ServiceConfiguration.cscfg" file with the "cspack" command and edit it to change the "osfamily" and "osversion" settings
• Use "cspack" to package up the application and deploy the application

He walks you through the "how it works" steps too - the things that happen for you automatically on the server side to do things like set up the file to log to, configure the PHP environment and execute the "runtests" Powershell file as included in the AzurePHPWebRole download.

If you follow my blog for a while, you might have noticed that I'm a huge fan of automation. I just moved one of our development servers the other day and had one of these moments where something just paid off. Taking for granted that I can spin up fully operational EC2 instances in minutes, I also had our development stack installed and configured in an instant. My recipe basically follows Christer's instructions and because I distribute phpunit's command along with it, editing of the file is no longer required: when the chef run completes, phpunit34 is installed and ready to be used.

He includes the configuration needed to create a recipe for PHPUnit installation including how to use chef-solo to automate the install. It uses a "cookbook" from Till's collection on github to do some of the work for you. You can find out more about Chef on the OpsCode site.

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.

So you or your team has built anywhere between 5 and 500 projects in PHP 4, 5.1 and 5.2 over the past 5 years. And now PHP 5.3 is there, offering a lot of very interesting features, including namespace support, late static binding (finally !), closures, nested exceptions and a bunch more (see the new feature list). So naturally, you'd like to upgrade. But doing so might break some old code.

He suggests a few different options - just run your unit tests and hope for the best, test the application's code directly or, his preference, run compatibility tests with the help of PHP_CodeSniffer and this new sniff he created. The sniff finds things like deprecated functions hanging around from pre-5.3 times as a part of a subset that the code sniffer can easily find.

This tool has to do a good bit of database manipulation so I've decided I'll build it in PHP using Zend Framework. I'll be using Zend_Db_Table_Abstract to communicate with the db tables from my project and I'll be creating a model for each table as well to store and manipulate data. I'll be working with lots of tables in the database and many have lots of fields.

Because the component lets you dynamically create PHP code, it can easily be used to create the model classes. Joey includes a link to the code you can use to add it into your own projects.

The majority of our customers run PHP on Linux - most of them on Redhat variants. Therefore, it was critical for us to deliver the best possible experience for Zend Server on Linux. In order to show our commitment to Linux we made a strategic decision and decided to release the product in the de-facto, native format for Linux installations so that Zend Server fits into the Linux distributions like a glove.

He names off several advantages that made them head down this path (towards linux) including the use of the usual automated install tools (apt-get, yum, etc), the automatic install of dependencies that the Zend Server setup might need and a standardized mechanism for the hotfix/updates as they're released.

You can find out more about Zend Server on its page on Zend.com.

Yesterday we had to move about 300 domains from one machine to another. We bought a new machine recently and are taking this opportunity to move from Qmail (difficult to use, in my opinion) towards Postfix. After doing one or two by hand, i decided that's stupid - why not just automate the whole thing.

The script reads from vqadmin and pushes that information over to mailadmin who makes the emails over on the postfix side. The script makes heavy use of the cURL extension to get the job done.

This tutorial will set you through using Zend_Tool to jump-start development on your next ZF MVC application. Zend_Tool is both RAD tools as well as a framework for exposing your own set of tooling needs to the Zend_Tool user interface. While the areas in which extending Zend_Tool are exhaustive, we will focus merely on obtaining and using the current Zend_Tool toolset.

The tutorial walks you through the installation of the component, how to set it up correctly as a "binary" and how to automatically create a new project with a simple "create project" call. He also points out the ability it has to define some of the basic files for actions of your choosing.