Stuart Herbert has a new post today showing how to get the well-established PEAR package management system working on Windows 7 so you can easily call "pear install" on whatever your needs might be.

So that I don't forget how to do this next time around. Worked for me, your mileage may vary. First step is to get a working install of PHP. [...] At this point, you should be able to open up a Command Prompt, and type 'php -v', and see the response 'PHP v5.4.latest …' appear as expected. Now for PEAR itself.

He gives step-by-step instructions on how to get PEAR up and running - downloading and configuring it with the correct Windows-based paths and using the PEAR_ENV.reg file to update your registry.

On PHPMaster.com today there's a new tutorial by Daniel Gafitescu showing you how to work with Redis (a key-value store) via PHP with the help of the Predis library.

There is a lot of argument whether Redis or Memcache is better, though as the benchmarks show they perform pretty much on par with each other for basic operations. Redis has more features than Memcache has, such as in-memory and disk persistence, atomic commands and transactions, and not logging every change to disk but rather server-side data structures instead. In this article we'll take a look at some of the basic but powerful commands that Redis has to offer using the Predis library.

He helps you get a local redis server up and running and includes a link to the repository for the latest version of the Predis library. Some sample code is provided showing how to connect to the server, push data into a key/value combination, get the value back out, increment it and check to see if it exists. He also talks about some of the available data types Redis provides and a few other more complex operations you can perform on things other than strings.

On the Monitor.us blog there's a recent guide to performance tuning your PHP with sections on lots of topics, some related directly to the code and others more towards the environment it lives in.

The World-Wide Web offers more PHP performance tips than can be comfortably discussed in one article, so the following is merely a list that can be used for reference purposes. The tips are divided into categories to group similar things together and make it easier to find what we need. The author's search for tips was extensive, but completeness still cannot be guaranteed.These tips fall into category #3.1 (the server executes a script) in the taxonomy of tips that we have been working with.Because of the sheer volume, these tips have not been tested. The reader is expected to test them in his own production environment before relying on them. This is not unreasonable, though, because the value of most tips depends on the unique environment within which PHP operates.

Sections in the guide include:

• Caching
• Session handling
• Compression
• Memory Leaks
• Code optimization
• Using services

Also included in the post are a list of links that were references for the tips in the list..

On PHPMaster.com today there's a new tutorial for those on the bleeding edge of PHP using the latest released version (5.4) and a feature that comes with it - using the built-in webserver that comes bundled for testing purposes.

One of the cooler features of the new PHP 5.4 release is a built-in web server designed specifically for development and testing. Now you can write and test your code without having to have a full-fledged LAMP configuration - just launch a the built-in server from the command line, test your code, and then shut it down when you're finished. [...] In this article I'll explain some basic uses of the new built-in server and show you how to build a portable personal development server useful for quickly testing your applications

He starts with a look at how to start up the web server (a simple command line switch and host/port definition) and the resulting default phpinfo page it displays. Other options include the ability to specify a document root for your server and create a sort of "front controller" for it to route requests. They show how to create a simple application based on this that can dynamically load in the index file, a router and pass the request off to the correct file. Their example includes some "niceties" too like logging, "hosts allowed" and checks for requesting directories.

You can find their full code for this example over on github.

In this new post to his blog Phil Sturgeon talks about what he (and apparently several others) think is the "way forward for PHP" to make it a better language and ecosystem - packages.

What is a package? A package is a piece of reusable code that can be dropped into any application and be used without any tinkering to add functionality to that code. [...] Most package systems also allow for something called dependencies. [...] This is how most modern programming languages work, but to make a generalisation: PHP developers hate packages. Why? Well while other languages have great systems like CPAN for Perl, Gems for Ruby, PIP, PHP has had a terrible history with package management going back years.

He talks about one of the main current packaging systems, PEAR, and how, despite its attempts, it just hasn't seen the adoption the package management of other languages has. Phil makes a recommendation that is slowly becoming more and more popular in the PHP community - building "unframeworks". These sets of reusable components (similar to the ideas behind Aura, Symfony and Zend Framework 2) are designed to be dropped in and used without the dependencies of the frameworks they live in. He points to the Composer/Packagist dynamic duo as a way through all of the current packaging issues - a simple way to make any project an installable package just by adding a configuration file.

For those fans of virtualization (and running VMs for development) you're not stranger to VirtualBox. Over on the Google Code site, there's a project that wants to make it easier to work with your VirtualBox instances via a PHP-driven interface.

An open source, AJAX implementation of the VirtualBox user interface written in PHP. As a modern web interface, it allows you to access and control remote VirtualBox instances. Much of its verbage and some of its code is based on the (inactive) vboxweb project. phpVirtualBox was designed to allow users to administer VirtualBox in a headless environment - mirroring the VirtualBox GUI through its web interface.

The tool isn't designed to be a management tool for a "hosting" type of environment, but rather to help you admin all of your VMs at once (no "ownership"). It uses the SOAP service (vboxwebsrv) that comes with VirtualBox servers to create a clean interface.

On the php|architect site today there's a new article from Luke Stokes asking a question about the future of the web (and web serivces) - is the future in REST or SOAP?

I was recently asked why we chose REST over SOAP for our re-write of the FoxyCart.com API, and the short answer that immediately came to mind was, "Because I don't hate myself". To expand on that answer, let me give you a little bit of the back story.

He talks about their goals for the product and its API, how they wanted to create something useful, built by developers for developers. They leaned towards REST mostly because of the problems and overhead introduced with SOAP (and the complex nature of its requests). He also gives a few reasons why he's "excited about REST": working with known data types, standard interface methods and the fact that it's still such a hot topic of discussion.

These questions [about HATEOS, hypermedia, vendor-specific content types] might seem overwhelming, but for us they are exciting! We believe the future of consistent, powerful API development is being defined right now, and we get to be a part of it.

In a new post to his site Till Klampaeckel shows how to use PEAR and composer resources (two popular PHP package management tools) from inside of a chef deployment script.

This is something experimental I have been working on for our chef deployments. So the objective was/is to find a sane way to install PEAR packages and install dependencies with composer.

He shows how to set up the configuration script to discover a new PEAR channel, make the chef script not "fail hard" if a command returns a failed response code (as PEAR will do if the channel is already discovered). The "ignore_failure" configuration directive comes in handy for this. He also shows how to implement a LWRP in chef for both a PEAR and Composer resource.

You can find the code for this and other cookbook examples on his github account.

In this new article on DZone.com, Artur Mkrtchyan shows you how to get an Amazon EC2 instance up and running and get a LAMP server set up and ready to go.

In this article I'm going to show you how to create a free Amazon EC2 cloud based LAMP Server and Point your domain to Amazon EC2 Instance. There are 4 simple steps to do.

The setup process is pretty easy - getting an Amazon free account, creating a server from an existing image, installing the LAMP stack and pointing your domain at the EC2 instance. He gives a step-by-step guide of the process, including the commands you'll need to execute to get all of the LAMP packages installed.

Building on the graphing tutorial in his last post Sameer continues on looking at graphs in PHP with this new post showing how to create an "agency matrix" of a currently built graph.

Building a graph is not enough; we also need the ability to search through it. To make it easier to build search algorithms, it is useful if we can represent the graph and its connections in a different way; adjacency matrix being one such representation. An adjacency matrix is a means of representing which vertices (or nodes) of a graph are adjacent to which other vertices.

He includes some sample code to extract the data from a graph (built with the PEAR Structures_Graph package) and create a basic "table" of information about each nodes' connections.