In this recent post to the Nodeable Blog, they suggest that the days of the typical LAMP stack (Linux, Apache, MySQL, PHP) are numbered because of what many of the cloud services have to offer.

For the past 10 years, the LAMP stack has laid waste to proprietary software stacks. Yes, Microsoft has held onto gargantuan profits, but LAMP has become the foundation for leading web services, whether Google or Facebook or [Insert Big Web Brand Here]. LAMP is the future. Or was. That is, until cloud killed it, as Eucalyptus CEO (and former MySQL CEO) Marten Mickos posits in a great keynote from the Percona Live: MySQL Conference & Expo 2012.

In the keynote he pointed out that it's becoming less about the whole setup and more about combining technologies to get the results you need - less "stack" and more "linked technology" (and not always the same tech for every node). He pointed to the Amazon AWS service as a prime example of a platform that allows endless flexibility as to what software can be installed and how it can be used, all with a few clicks of a mouse.

In this new post to his blog Brian Swan shares the process that he and other Microsoft-ers went through to migrate a site off of a LAMP stack and over to one based on Windows Azure. They moved was the SAG awards website because of issues it had seen with outages and slow performance.

In many ways, the SAG Awards website was a perfect candidate for Windows Azure. The website has moderate traffic throughout most of the year, but has a sustained traffic spike shortly before, during, and after the awards show in January. [...] The main challenge that SAG Awards and Microsoft engineers faced in moving the SAG Awards website to Windows Azure was in architecting for a very high, sustained traffic spike while accommodating the need of SAG Awards administrators to frequently update media files during the awards show. Both intelligent use of Windows Azure Blob Storage and a custom module for invalidating cached pages when content was updated were key to delivering a positive user experience.

He walks you through each of the five steps (high-level, obviously) that they took in the migration:

• Export data
• Install Drupal on Windows
• Import data into SQL Azure
• Copy media files to Azure Blob Storage
• Package and Deploy Durpal

Each step comes with some explanation and descriptions of the commands and tools used during the process.

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.

Matthew Weier O'Phinney has a new post to his blog today looking at one of the tools the Standard PHP Library (SPL) has to offer developers - the SplPriorityQueue (PHP 5.3+)

SplPriorityQueue is a fantastic new feature of PHP 5.3. However, in trying to utilize it in a few projects recently, I've run into some behavior that's (a) non-intuitive, and (b) in some cases at least, undesired. In this post, I'll present my solutions.

He talks about the "first in, first out" nature of queues and how it differs from a stack (including links to some of the other SPL offerings for both). He then moves into the problems he was seeing - that iteration removes values from the heap and the unexpected order of equal values in the queue. To solve the first problem, he creates an "outer iterator" that creates an "innerQueue" that's protected. The solution for the second issue - the random queue order - is a simple one: priority indexes aren't required to be integers. Strings can be substituted to help make things a bit more unique.

Andrew Curioso has a post to his blog looking at error handling in PHP 5.3, specifically in creating a "stack" that can provide more than one error handler at a time.

As you may know, set_error_handler can be used to set a custom error handler in PHP. It will catch any errors that happen in the script (with a few notable exceptions). If the function returns false then error handling resumes as normal; otherwise it is assumed that the custom handler took care of things. The problem is that you can only have one error handler active at one time. The purpose of this code is to provide a error handeling stack for PHP.

His example uses closures, so pre-5.3 installs won't be able to use it, but it's an interesting proof of concept to show how you could set four different error handlers on one execution. A code snippet is included to show how it all works.

New on his blog today, Simon Jones has posted a handy guide for those using the Zend Framework out there to the stack index for plugins the framework uses.

Zend Framework Controller plugins are a powerful way to inject logic into your controller system at various points, such as before and after an action dispatch. Plugins are run in the order they are added, though it is possible to change the order by defining a custom stack index. ZF internal plugins such as Zend_Controller_Plugin_ErrorHandler, which displays a nice Error 404 page, has a stack index of 999 to ensure it runs at the end of any plugin cycle. However, it's not so obvious from the ZF manual how to set a custom stack index.

He shows how to use the second parameter of registering a plugin to define the stack level and how to get the listing of the current stack to see just where yours might need to be placed. He also includes code samples and an output example of the default Zend Framework stack.

In this new article from Developer.com they take a look at some of the different web application stacks (including LAMP) and offer some advice as to which might be the right fit for you and your application.

Critically examining the underlying architecture for a web application is an important step in defining the end product. That explains why one of the first questions that developers ask each other is: "what stack are you using?"

They evaluate:

• LAMP Stack
• WISA Stack
• Java Web Stack
• SQL Anywhere for the Data Tier

They make recommendations for three kinds of users - start-up/hobbyist, SMB developers and enterprise-level developers.

On DevShed today the latest article in their XDebug series has been posted, a look at tracking the function call stack with help from functionality the extension provides.

Despite this inconvenience [pf not being able to get more in-depth], in this final part of the series, I'm going to show you how to work with a function of the library called "xdebug_get_function_stack()." This function can be used to keep track of the stack of function calls generated by a PHP script, in this manner completing this starting guide on this helpful extension.

After reviewing the script from the previous part (using xdebug_time_index) they get into this new function and what sort of output it provides. The stack is the trace of what functions and values were passed around in the script including information like the function name, parameters and the file it was in.

On the Blue Parabola blog Matthew Turland has written up a post about a PHP something that might need a bit more love - the Standard PHP Library.

If any PHP extension is underrated, it's probably the SPL (Standard PHP Library). From what I can tell without having been involved in its development, its purpose is somewhat similar to the STL. A while back, it was useful mainly for allowing class instances to be iterable and simulate array access. [...] Using the SPL classes actually turned out to be pretty straightforward once you got your hands on a good starting guide or two to help you beat the learning curve.

He mentions a few of the things offered by the SPL like the SplFixedArray/SplFastArray, Iterators, SplDoublyLinkedList, SplStack and SplQueue (among others). He also includes some benchmarks running standard code (like normal arrays) against a SPL counterpart - the SPL side beat the normal side hands down. Check out the full post for all of the numbers and comparison types.

Continuing on his his series looking at improvements in the upcoming PHP 5.3 release, Johannes Schluter uses this new post to look at some of the new data structures their update will have to offers in the Standard PHP Library.

In the programming world there are quite a few well understood and explored data structures. Which are commonly used in tons of applications, still the only things PHP offered till 5.3 in regards to structuring data were arrays (more precise: hash tables) and objects. So people had to either abuse them for other structures or implement the structures themselves on top of these. Thanks to Etienne things now are changing and PHP's Standard PHP Library (SPL) extension will offer quite a few standard implementations of data structures.

These new data structures are SplDoublyLinkedList, SplStack, SplQueue/SplPirorityQueue, SplHeap/SplMinHeap/SplMaxHeap and SplFixedArray. He explains a bit of what they are and more detail on one specifically - SplFixedArray.