[Frameworks] come in several different flavours that all have huge advantages, but also a few disadvantages. Over engineered (because their popularity demands that they be), updated too often, not updated enough. If you decide for example to update your application from using Zend Framework 1 to using Zend Framework 2, this will more than likely require, at least in part, a re-write of your code. This makes scalability difficult.

He talks some about the PSRs that the PHP-FIG group has proposed including the PSR-3 logging interface structure. He points out that, by having this same structure, it makes injecting dependencies easy while still leaving the actual functionality open to interpretation. He also suggests that maybe a framework isn't the right choice for all applications and that possibly using a collection of libraries, tied together by the PSR standards, could be a better answer.

He mentions the ideas of "new thinking" and the limitations that standardized interfaces might try to impose on an application:

One is able to imagine reasons why having shared interfaces of the kind described above is in opposition to, or at best orthogonal to, better development practices and greater innovation across PHP land. Even so, I assert that shared interfaces as described, while maybe preventing an imaginable ideal in theory, instead promote an actual good in practice.

Matthew Weier O'Phinney responded with some of his own comments and correcting some of the misinterpretation of his original comments.

A little over a year ago, there was a new push by a number of folks wanting to do more. Paul Jones did a remarkable job of spearheading the next two standards, which centered around coding style. [...] And this is when we started seeing proposals surface for shared interfaces, first around caching, and now around logging (though the latter is the first up for vote).

He talks a bit about shared interfaces - what they are and what kind of problem they aim to solve - and how he's not sure he "buys into them". He notes that "sharing is good, developing solutions is better" and stresses making it easier to operate with each other and not worry so much about standardized interfaces.

He's found a few problems with the concepts behind them like the Not Invented Here (NIH) idea they promote and that there's not really just a single solution to these kinds of problems ("space for multiple implementations"). He suggests an alternative to the idea of these shared interfaces - bridges/adapters. He illustrates this idea with some code showing the implementation of a "CacheInterface" and a "FrameworkACache" adapter that wraps the functionality of a "CacheItem" class that might be internal to your application already.

With the recently released PHP 5.4, the Suhosin patch and extension were removed from many Linux distribution packages (i.e., Debian et al.) and until three weeks ago, there was no possibility to compile and run the Suhosin extension under PHP 5.4. This little howto shall serve as installation instruction for Debian Wheezy users - your mileage may vary. I blogged about this here.

They start with the apt-get commands to install the latest PHP5 for your distribution (yum commands are similar, of course) and includes the location to download the latest Suhosin version from Stefan Esser's github account. Unpack it, compile and "phpize" it and if all goes well, you should have a shared module built and ready for use.

When you send an email, the mailer communicates with a remote server in charge of receiving the message and of delivering it to the recipient. This process can cause your form to submit slowly as it depends on how fast the mail server responds. Spooling allows us to decouple the application execution line from the process of the sending one, two, or as many emails as we need.

They show you how to configure the SwiftMailerBundle with the mail server's settings, how to set up the command to send the emails and the settings you'll need to put in your cron file to run the "send" operation periodically.

Once created, and given proper permissions, other processes in the same machine can manipulate those segments by: read, write, and delete. This means that an application written in C can share information with an application written in other languages, such as Java or PHP. They can all share information, as long as they can access and understand that information. [...] This article's proposal is simple, learn how to create and manipulate shared memory segments with PHP and use them to store datasets that other applications can use.

Your PHP installation will need to have been compiled with "enable-shmop" to work with the code in this tutorial. Their examples show how to use the shmop_open, shmop_write and other related functions to read, write, remove and close segments in the shared memory space. They also include an example of using the SimpleSHM library to make it easier to interact with the shared memory space as a standard storage location.

This article is meant to help you configure and deploy your projects developed with Symfony2 into a Shared Hosting environment, so if you need to deploy using capifony on a VPS, please read this article.

You'll need ssh access to the server to get things set up for the deployment as well as a local environment where you can install Ruby and Ruby Gems (their platform for the example is OSX). They help you get those installed and generate a key for use with the deployment. Once this key is copied over to the remote system, you can then set up the config to use the password-less connection and to deploy from either a local repository or a remote location (like github).

Some time ago (actually when I was making this blog) I posted on stackoveflow.com a question on how to configure Symfony to run on shared webservers where you can't change your website's document root. I solved it but forgot that I was asking and left it without any answer.

The main problem is that the DOCUMENT_ROOT for the hosting service can't be changed by the users of the shared host. To solve this he modified his routing rules (sfPatternRouting class) and changed his .htaccess file to rewrite things over from just "/page" to "/web/page" instead. A simple solution, but it might be evasive if you've never configured it before.

bbPress is a forum software developed by the same folks who created WordPress. It's a lightweight bulletin board system that seems to be gaining traction lately. bbPress runs really well on our shared hosting plans so we decided to put together a quick tutorial on how to install bbpress on our systems.

Despite the description, the guide can be followed to install it just about everywhere thanks to the simple installation process bbPress uses. He links you to the latest download, gives you an example of what you can expect from the installer and talks about setting up the database. This is where is get specific, using their Plesk tool to set it up. This is only to set up the actual database, though - you can do this through any number of tools, including the command line.

Before going on with the points, let me state something: please avoid flame wars, all the Scala vs. PHP stuff, fanboyism and what not. This post is not about that. Regarding Wade Arnold I have to say that I fully respect him. While I don't know him personally, I know him for his work on AMFPHP, since it was a platform I used to work with before.

Alvaro talks about functional programming and some of the main points he had made about Erlang in a talk he had given - code reload, being ready for multi-core and no shared state between scripts. He talks about how these (really) apply to PHP.