In his previous post ("PHP was meant to die") the point was made that PHP isn't really designed as a language to handle long running processes very well. It's made to handle a few operations and then die at the end of the request. In this follow up post he talks more about using PHP for long running processes and a library that could help.

Yes, I already acknowledged that PHP has a garbage collection implementation starting 5.3.0 and up (opt-in or opt-out, that's not the problem). I also acknowledge that garbage collection works, and is able to take care of most circular references just fine. [...] Anyway, as previously stated too, garbage collection is a great thing, but not enough for PHP. It's a borrowed feature that does not play well with old fundamental decisions inherited from the original design. Garbage collection is not a magical solution for every problem, like many tried to argue about. Let's illustrate with another example.

His example uses the React PHP library (a non-blocking I/O platform) to handle a lot of incoming data to a port and report back some memory usage and limit settings. He explains a bit about what's happening and shares the results of the test, including the end result - a fatal error when the memory limit was hit. He still comes to the same conclusion, ultimately...PHP is just not the language to use for long-running processes that do any large amount of work.

PHPClasses.org has posted the latest episode (#34) of their "Lately in PHP" podcast series. In this episode they talk about the current PHP voting process for features and a possibly better one that was proposed.

This was one of the main topics discussed by Manuel Lemos and Cesar Rodas on the episode 34 of the Lately in PHP podcast. They also discussed about the latest PHP releases, updating PHP with minimized downtime, as well how brilliant are some developers for creating pure PHP components that overcome PHP limitations without upgrading to a newer PHP version.

You can listen to this latest episode either through the in-page player, by downloading the mp3 or subscribing to their feed. If you'd like to see the video recording of the session you can check that out over on YouTube.

Gonzalo Ayuso has a new post today showing how he set up queuing with ZeroMQ and Symfony components and React.

Today I'd like to play with ZeroMQ. ZeroMQ is a great tool to work with sockets. I will show you the problem that I want to solve: One web application needs to execute background processes but I need to execute those processes in order. Two users cannot execute one process at the same time. OK, if we face to this problem we can use Gearman. I've written various posts about Gearman (here and here for example). But today I want to play with ZeroMQ.

He uses React and some ZeroMQ bindings and Symfony's Process component to make a simple client and server for working with the queue and processes. A screencast is included in the post showing them making the connection and adding the new process. The full code can be found on github (or installable via Composer)

In this new post, titled "PHP is meant to die", the author looks at one weakness he sees in the PHP language - how PHP handles long running scripts and functionality.

In my opinion, a lot of the hatred that PHP receives misses the utter basic point: PHP is meant to die. It doesn't mean that a perfectly capable (to some extent) programming language will disappear into nothingness, it just means that your PHP code can't run forever. Now, 13 years after the first official release in 2000, that concept still looks valid to me.

He talks about some of the "dying" that PHP is good at (like making general website-related requests) but notes that if you try to have it do much more, PHP acts up. He points to the complexity of web-based applications and notes that, while PHP is good for some of it, it's not a fit for all functionality. He also covers the bringing of processes to the foreground that are best left in the background and how - despite the best of intentions - making a PHP daemon to solve the problem isn't a viable option.

Do you see the pattern? I've inherited projects where PHP was used for daemons or other stuff that's not just regular websites (yes, I'm a hired keyboard), and all of them shared that same problem. No matter how good or clever your idea looked on paper, if you want to keep the processes running forever they will crash, and will do it really fast under load, because of known or unknown reasons. That's nothing you can really control, it's because PHP is meant to die. The basic implementation, the core feature of the language, is to be suicidal, no matter what.

In a new tutorial over on DZone.com Giorgio Sironi talks about handling external processes in PHP and how to work with streams.

I've come to known a bit about spawning and monitoring new processes from PHP code, while working at Onebip and trying to contribute to Paratest. Here's what you need to know if you think exec() or executing everything in a single .php script is always enough.

He starts with a look at the differences between using things like exec and streams for handling the spawning of other processes. He shows how you have more control when you go with the streams option and process handling with the "proc_*" methods. He also touches on some other things to think about like stream blocking, sleeping and dealing with multiple execution streams (and switching between them).

For anyone that's wondered how some of the features they use every day get into the PHP language, Chris Jones has written up a post making the RFC (Request for Comments) process they follow a bit more transparent for the average developer.

The PHP RFC process has been in place for a while, and users new to core PHP development are starting to use RFCs to propose desirable features. Here are some personal observations and suggestions that show how I have seen feature acceptance and the (newish) RFC process work in practice. These notes augment the steps in How To Create an RFC. I hope they help set expectations about the PHP RFC process and feature acceptance in the PHP language.

He lists the steps in the process from start to finish including things like:

• Avoid presenting an RFC idea to the "internals" mail list with email that begins "I don't know much about ... but ...". Do some research first.
• Your RFC should talk about all PHP areas that will be affected: php.ini, different SAPIs, engine, extensions, etc. List similar features. List similar features in other languages. Link to references. Give an estimate of the actual positive impact to user code.
• If you do have an implementation, make it clear whether the implementation is a simple prototype or is expected to be the final code. This is specially important during the vote.
• There is no need to respond to every discussion email individually. You should batch up your responses and manage the discussion intelligently.
• With long, fragmented discussions, not everyone will read every email. Update the RFC at regular intervals, and let people know what has changed.
• Some areas of PHP are complex or niche. Sometimes feature suggestions will be greeted by an apparent lack of interest. Don't be discouraged. This just means you need to take a stronger leadership role, and also prove your credentials by first working on the existing code base.
• During the voting period, it is common for people to continue mail list discussion. You may need to halt the vote and address any issues.

Obviously, there's a lot more to it than that - his post does a great job of letting you know what to expect and includes useful tips on helping you get your idea across.

Matt Frost has a new post today helping to explain test-driven development (TDD) for the unconverted and some of the things that come with it in practice.

You've heard of Test Driven Development, but you think; "I've got a horrifying monstrosity for a codebase, it's not testable so I can't do TDD". Let me be the first to tell you that you're wrong. I'm not into writing really controversial pieces, castigating people for not doing things a certain way. If you've considered TDD at any point in time, it's because you understand (at least in the theoretical sense) that having predictable software is beneficial. So this is for you, unconverted developer...

He talks about how using TDD can help you build confidence in your code, make debugging issues easier in the project simpler and how - despite the initial time it takes to implement it in the process - it's worth it in the end. He also includes a few helpful suggestions when your team doesn't want to follow the method.

The official start of the PHP 5.5.0 release process has started today with a new post from David Soria Parra and Julien Pauli about the release of the "alpha 1" version of the release now being available for testing. (Note: this is an alpha release and is by no means suitable for real-life usage).

As announced a few weeks ago, we tagged PHP 5.5.0alpha1 on Tuesday. This release marks the start of 5.5.0 release process. [...] This release includes a dozen new features, such as Generators, List support in foreach. the simplified password API, and many more. Thanks to everyone working 5.5.

The plan is to put this out there for testing and then tag "alpha 2" on the 27th and make the actual release on Thursday, the 29th. If you'd like to help with the testing, download the alpha and run your tests (including the "make test" on install). Windows builds are also available at windows.php.net/qa.

Matthias Noback has a new post today sharing some of his experiences working with Open Source software, specifically as it relates to this dealings with a "Symfony-friendly environment".

These days, good PHP object-oriented libraries are all around and easily available. To me, it is actually thrilling to be part of this flourishing community, while working with Symfony2 and blogging about the Framework, the Components and their neighbors (like Silex). [...] Still, to me, contributing felt like too big a step to take right now. Until a few weeks ago, when I was looking for something I needed (a PHP client for the Microsoft Translator API) and could not find a decent solution. I decided to make it myself, and share it online.

He shares his "checklist" of steps he followed to get the library up and working (less about the library and more about the process):

• Write the code
• Initialize a Git repository
• Add a composer.json file
• Add unit tests
• Make it open source and developer friendly
• Push your code to GitHub
• Register your project at packagist.org
• Register the Packagist Service Hook
• Versioning
• Continuous integration using Travis CI

He also suggests that, at least at the outset, you skip some of your tests that might rely on external data sources/resources (so the build can start as green on Travis) then coming back and refactoring to mock things out correctly. It might look like an intimidating list for a beginner, but it's a great process to follow to have a robust, effective development/deployment process.

On the Symfony blog, there's an announcement from Fabien Potencier about the framework's new release process (details here).

To make a long story short, Symfony now manages its releases through a time-based model. If you want to learn more about the Symfony release process, or about the first Symfony Long Term Support release, or about the release date for next version of Symfony, please take a minute to read the new process. You are also going to learn when we will start working on Symfony 3!

The full details also include a timeline they've projected for the upcoming 2.x versions of the framework, right up to the 3.0 release. The goal of the process is to provide transparency and predictability to the Symfony frmework's releases with 6 month releases and and open plan presented to the community up front.