On the IBM developerWorks site today there's a new tutorial showing you how to store shared data directly to a shared memory space of your PHP application.

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.

The ServerGrove blog, a hosting provider whose services include shared hosting, has posted a guide to help you deploy to shared hosting with Capifony, a Symfony-based tool for use with Capistrano.

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).

On his blog Martin Sikora shares a solution that many a Symfony developer out there might find handy for running their application in a shared hosting environment:

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.

On the ServerGrove blog today there's a new tutorial posted showing you, step by step, how to install the bbPress software (from the folks that brought you WordPress.

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.

Alvaro Videla has written up a response to Wade Arnold's Scala's easier than PHP post and some of the points he doesn't agree with him on.

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.

In this new post to his blog Rob Allen looks at how to use a standard installation of the Zend Framework on a shared hosting environment.

When you deploy a Zend Framework website to a shared host, you usually cannot change the DocumentRoot to point at the public/ folder of the website. As a result the URL to the website is now http://www.example.com/public/. This doesn't look very professional, so we'd like to remove it. The easiest way, given a ZF project created using Zend_Tool.

In the index.php file you'll need to define a constant and an .htaccess file to route everything back to that index. You'll need to be aware of this change when working with files and can check in the front controller for that constant to reset the base path if needed (code example included).

On the Zend Developer Zone a new tutorial has been posted showing how to compile PHP extensions to work with the Zend Server web platform.

To date, Zend Server includes 77 PHP extensions that Zend considers essential or just very helpful for most PHP developers. Still, what if the one that your code uses is not among them? Or you wish to compile one of the extensions Zend Server is shipped with in a different way (against your own libraries or to support additional, less common features)? If this scenario sounds familiar to you, you may find this tutorial useful.

You'll need to know a bit about compiling and some of the tools (like autoconf, automake, the gcc compiler, and libtool) before you get started. Two scenarios are described - one for installing and compiling the Newt extension (RedHat's Newt New Terminal library) and another slightly less automated for the Pspell extension.

Each of these examples make a shared module that can be included into the PHP installation via your php.ini.

On the Zend Developer Zone a new tutorial has been posted looking at taking your pre-existing C++ functionality and wrapping it in a PHP extension to be used directly in your code.

In this tutorial I am going to walk you through creating a PHP extension called "vehicles" which will expose a single class called "Car" (obviously in the real-world, your extensions will expose many classes, but I'm trying to keep things simple). The extension will be built for PHP 5. I am only going to give instructions for building the extension in a UNIX-like environment, although most of what I cover should apply to Windows extension development as well.

The tutorial walks you through everything - how the file layout should look, making a build system, the contents of his files (the sample extension lets you do things to the Car like shift gears and brake) and how to combine the C++ code with the build process to create a shared module you can include right in your php.ini.

The Zend Developer Zone has pointed out a recent blog post from Mauricio Cuenca showing how to run two (or more) Zend Framework applications on one account on a shared hosting environment.

Shared hosting environments can be a nightmare when it comes to PHP Web Development, specially in testing stages. Yes, I know one should not be using and paying for a hosting plan if the code is still not production ready, but I have seen some cases. I will try to show how to have the Zend Framework installed with as many projects as you want (if your server quota allows you to) in the same web space and all these projects sharing the same ZF copy.

He includes his basic directory structure - separate directories for each of the projects - and the boostrap code to keep the requests for that application inside of the correct directory (setting the LIBRARY_PATH, APP_PATH and CONTROLLERS_PATH).

Just for those PHP & Oracle users out there Chris Jones has posted a new entry to his Oracle blog detailing the different ways you can compile with oci8 support.

PHP OCI8 can be built using libraries from a full Oracle Database (or Database "Client") install, created from running the GUI installer. This is often referred to as an "ORACLE_HOME" install, since an environment variable of that name is set to the installed Oracle software directory. [...] Another dimension to the install is that PHP extensions can be statically compiled into the PHP executable(s), or built as shared binaries. If OCI8 is built as a shared library it is loaded into PHP as a result of setting the php.ini option "extension=oci8.so".

There's eight different methods he mentions including building it as a shared module, using the normal Oracle libraries to build and using the Instant Client libraries to run the build.