On the Symfony blog Ryan Weaver shares a "behind the scenes" look at how the project handles and has automated their documentation generation process with the help of the Platform.sh service.

[Symfony's documentation](https://github.com/symfony/symfony-docs) is an open source project with more than 800 contributors. That’s great! But our goal is to always make it easier to contribute and faster to merge in changes. And today, we’ve started doing something really cool to improve our workflow: integration with [Platform.sh](https://platform.sh).

Platform.sh is a hosting solution that provides out-of-the-box continuous deployment for Symfony, Drupal and any other PHP applications. It extends the concept of a Git branch at the infrastructure level. Basically, this means that it’s easy to deploy every branch and/or Pull Request to its own URL.

He talks about the documentation's format (Sphinx) and how, while it does provide flexibility it also can lead to maintenance issues too. Changes can't be seen immediately and it's difficult to review. Instead they worked up a process where each pull request was automatically deployed to its own unique URL. This reduces both issues they were setting around instant feedback and review problems and provides a better experience for the developer overall.

The latest episode of the /Dev/Hell Podcast has been released - Episode 19: Pull Requests Welcome:

This week on /dev/hell is “let’s talk about arguments Chris got into on Twitter” week. Most of the discussion revolves around how we interact with users, both developer-types and average joes.

You can listen to this latest episode either via their in-page player, by grabbing the mp3 directly or by subscribing to their RSS feed.

Adam Peterson has posted an interesting idea for those out there running an internal staging server they want to constantly keep up to date with the main line of code (without manual intervention) - a git pull web frontend combined with git post-receive hooks.

This [move from svn to git] left a bit of a gap in my process where I could no longer test on a remote server without updating it manually by S/FTP or opening terminal and manually calling a git pull. Open terminal and manually git pull it did break up the work flow a bit so using the Dingo framework I created a very simple Git helper and gave it its own URL something like git/pull.

He added a post-receive hook to his git server that calls this "git/pull" URL on the staging server and updates the code on the server. This provides an easy asynchronous way to update things on another server. Note, though, that this should never be done on a publicly accessible server - it's a pretty large security hole (or at the very least made secure somehow). He used Dingo to create his interface, but something like the Slim micro-framework could have worked just as well. You can view his code on github.

In a new post to the ThinkPHP blog today there's a look at combining Comet with PHP to make a simple method for the client to talk back to the server outside the usual methods.

If a couple of users have opened the application there are already some hundred or thousand requests per second. The outcome of this is a big load for your server and a highly increased traffic - your server will in a senseless way be overloaded. In conclusion, our problem is the enormous amount of polling without knowing whether the server really wants to send a new push. Let's turn the initial situation around. And we get the solution to our problem: Comet.

With Coment, the model changes and the request is "cached" on the server-side automatically in a single Comet instance. Coordinate this with another recommendation of theirs, a PHP socket server, and you can do some pretty interesting things.

The IBM developerWorks site has posted part four of their series looking at the Zend Framework. This latest article focuses on the Zend_HTTP_Client package.

Part 3 explains how to use the Zend Framework to construct our online feed reader, Chomp, by creating an interface to subscribe to and read feeds, and to save feed entries into the database. Now you will learn how to use the Zend Framework to incorporate Web sites that do not support RSS feeds into the online feed-reader interface.

They work their way through an example of pulling in content from a remote site (one that's feedless). This is an enhancement to the "Chomp" application they've been developing all along, so if you need to catch up, here's the previous parts - Part 1, Part 2, Part 3.

They update the indexController, deleteEntryAction, and the saveEntryAction methods to handle this new incoming data and make the needed changes to the views to handle the new output. Finally, they demonstrate how to save the entries pulled in through the Zend_HTTP_Client component.

The IBM developerWorks site has posted part four of their series looking at the Zend Framework. This latest article focuses on the Zend_HTTP_Client package.

Part 3 explains how to use the Zend Framework to construct our online feed reader, Chomp, by creating an interface to subscribe to and read feeds, and to save feed entries into the database. Now you will learn how to use the Zend Framework to incorporate Web sites that do not support RSS feeds into the online feed-reader interface.

They work their way through an example of pulling in content from a remote site (one that's feedless). This is an enhancement to the "Chomp" application they've been developing all along, so if you need to catch up, here's the previous parts - Part 1, Part 2, Part 3.

They update the indexController, deleteEntryAction, and the saveEntryAction methods to handle this new incoming data and make the needed changes to the views to handle the new output. Finally, they demonstrate how to save the entries pulled in through the Zend_HTTP_Client component.