On the Delicious Brains blog there'a a post that compares four different products for creating local PHP development environments: XAMPP, MAMP, DesktopServer and Local. Both package provide similar functionality but with slight differences.

An easy-to-use local testing server is one of the most important tools in a WordPress developer’s utility belt. Developing in a local environment lets you make changes to dev sites quickly and easily without having to transfer files anywhere and greatly reduces the risk of making breaking changes on a live server.

While many computers are capable of hosting a WordPress site without needing to install any extra packages, there are a few advantages that a dedicated local development environment can offer.

[...] There are quite a few different applications and tools that fit this bill, but for now we’ll be comparing the 4 GUI-based tools that seem to me to be the largest players in this space: XAMPP, MAMP (Pro), DesktopServer, and Local By Flywheel.

The post then walks through each piece of software, covering the installation and getting it up and running with a WordPress application. There's also a mini-review for each with good/bad comments and an overall rating.The post ends with some comments about the author's own preferences, which they use now and which they'd choose in the future.

On NetTuts.com there's a new article introducing Xdebug, a powerful tool that can help you with debugging your PHP applications. It works by investigating what's happening "on the inside" and reporting it back to your debugger.

Well, technically, Xdebug is an extension for PHP to make your life easier while debugging your code. [...] But just imagine for a moment, as your applications evolve, you might get into the habit of sprinkling your code all over with little echos, var_dumps and custom debuggers. [...] The next question is: how do you debug in production? [...] Now lastly, have you ever wished to be able to step through your code, line by line, watch expressions, and even step into a function call to see why it’s producing the wrong return value? Well, you should definitely dig into the world of professional debugging with Xdebug, as it can solve all of the problems above.

They walk you through the setup of a complete (MAMP-based) environment on an OSX installation. You'll also need Xcode and the command line tools to be able to compile Xdebug. They recommend installing Homebrew to make installing the needed tools easier. They use Homebrew to install the PHP 5.4 version of Xdebug which then compiles and outputs a shared module you can put in your PHP extensions directory.

On the other side of things, the article also helps you set up your IDE, in this case PHPStorm but it would work for lots of others - to accept the debug messages from the server. He includes a sample script with some calls to the Xdebug-enabled debugging functions and what kind of responses (with screenshots) you should see in your IDE.

In this new post to DZone.com Andy Hawthorne explains how to install MongoDB on OSX and get a local PHP working with it.

MongoDB is a document oriented, NoSQL database. It is gathering momentum and popularity amongst developers because it is flexible, and scalable at the same time. In this article I will describe how I got it set up and working on my Mac running OS X 10.8.2 and MAMP with PHP 5.2.17, and PHP 5.3.6.

They go a bit simpler route than trying to compile it yourself by using the binaries direct from the source. Instructions are included to test the installation, insert a record and how to install the MongoDB PHP driver for a MAMP installation. It's a shared object, though, so it's not specific to MAMP and could be installed even on the local OSX PHP functionality.

Danne Lundqvist has a new post today showing you how to install and use XDebug with MAMP, the popular all-in-one LAMP package for OS X.

MAMP is a full local server environment including Apache, PHP and MySQL in one package. Anyone feeling at home in *nix systems should feel at home using both OS X and MAMP. [...] As I have helped a few collegues setup Xdebug in MAMP I have discovered that a lot of developers don’t do this as they don’t know how simple it is. Even seasoned PHP developers use the old echo/die debugging techniques.

He includes all the changes you'll need to make to configuration files and makes a simple script you can use to test out that things are working. As his IDE of choice is PHPStorm, he shows how to set up the remote debugging to work and reply back as the script is executed.

Chance Garcia has a recent post to his blog showing how he fixed an issue with his MAMP install involving development of a SSH wrapper he developed and some testing out of PHPStorm and PHPUnit.

One thing I can say is that, even though I use a convenient app like MAMP PRO to set up my local development environment, I'm glad my sysadmin-fu is up to snuff enough to fly without the conveniences because after this ordeal, I feel like I might as well have made my MAMP stack from scratch with all the hoops I jumped tonight.

He shares a few of the things he discovered along the way like: the location of MAMP's "pecl" command, an error caused by a bad pear.conf file, doing custom compiles of PHP and libssh as a fallback and getting the extension to work in the CLI PHP version too.

On the EchoDitto Labs blog there's a new post about getting Eclipse PDT with Zend Server Debugger on MAMP for Drupal (by Jeremy John).

Anything involving Eclipse is always epic. First, you have to get your head around what distribution of it to use, as confusing as one's first introduction to Linux distributions (there are different kinds of Linux?). Next, you have to grok the fact that the Zend Debugger must be installed on your server. In this case, MAMP. Then, you have to make Eclipse listen to the debugging information being outputted, on the debug port. Finally, you have to figure out how to use a debugger effectively (not in scope, but careful, debugging will blow your mind).

After following along with this screencast he was still getting errors when trying to debug (connection failed message). Eventually, though, he finally figured out the problem - an extra zend_extension call to load the XDebug module.

Anna Filina has posted a new item to her blog about some of her experiences with PHP 5.3 on the OS X platform including some of the different software she tried (like the Symfony framework).

I wanted to play with Symfony 2 and so needed to install PHP 5.3 on my OSX 10.5. What seemed like a simple task turned into a huge waste of my time. I use MAMP because it’s a nice out-of-the-box solution. The problem is, it still doesn’t ship with 5.3 because it’s waiting for it to be "stable".

She tried to find a way to upgrade MAMP's installation to the latest stable version of PHP but was stopped by dependency errors and opted to go with XAMPP instead to get more of what she needed. She also has included a few edits to the post with more information - how to migrate your virtual hosts from MAMP to XAMPP and migrating over the MySQL structure.

On the Proof Group's blog there's a recent post about a "gotcha" Andy Chase found when using the Drush command line tool for Drupal installations and a system that has MAMP installed.

Recently, however, I installed MAMP to debug some older, PHP4-specific code. [...] I also use Drush, which is an indispensable Drupal command line tool, and I began getting the following error on some sites: Drush command could not be completed.

This only caused a problem when he went back to his previous PHP5-based installation. He finally found the culprit - a section of the Drush script that looked for MAMP installs and tried to use those binaries and configuration files (the PHP4 ones) instead of his more correct PHP5 ones. A quick commenting later everything worked fine.

On the Content with Style blog today Pascal Opitz has made a (very) quick post about how to get PHPUnit up nd running in your MAMP installation.

In order to run my unit tests, I needed to get phpunit running with MAMP. Thanks to the helpful post of Mark Kirby on this, I figured it out.

The key is in changing the interpreter path in one file and removing a bit of code from another to point to the new PHP binary's path. You'll also need to update your PEAR include path to add in the new pear.conf location.

On the NETTUTS.com website there's a new tutorial posted (by Tarek Farage) about creating your first custom Joomla template:

In this tutorial , you will learn about the basics of a Joomla template, and create one from scratch. We will quickly go through installing a local server and Joomla itself, and then create a basic functioning template.

The tutorial gives you a quick installation tutorial to get you up and running (if you're looking for a PHP installation guide, you'll need to find it elsewhere) with Joomla installed and working. He walks you through each step of the way - creating a simple template, installing it via the admin interface, and adding on more advanced features like layout features and modules.