Alejandro Celaya has a recent post to his site showing you how you can delay constructor execution in your services by making use of the "lazy services" functionality provided by the Zend ServiceManager component.

A couple years ago I wrote a post about how to improve PHP applications performance by using zend-servicemanager lazy services.

In that article I explained how the ServiceManager takes advantage of the proxy design pattern to delay the creation of services, when they are marked as lazy.

That can improve performance if the object is resource consuming, but that is not the only advantage behind proxies.

He starts with a use case for using these "lazy services" based on some changes in an open source library he maintains to add in geolocation support. The library requires a database file when the object is created but on the first run, no file is downloaded yet. He made use of the lazy service loading to only initialize the GeoIp2 library when it is requested and not when the script starts.

On the Laravel News site there's an announcement posted about a change in the Laravel release schedule, an update from the original 2013 announcement.

Yesterday, Taylor announced on Twitter that this is going to be changing to a January and July cycle, pushing each release out a month from its current schedule.

This has two primary advantages for the development team and the first is it allows more time for testing after Symfony’s release. The second advantage is it’ll better coincide with Laracon, the yearly Laravel conference.

This means a bit of a delay on the release of the next major version of the framework (v5.4) but only by one month. The six month cycle will then resume after that slight delay. You can find out more about the remainder of the release cycle in the original post based on Taylor's comments at Laracon 2013.

Christian Mackeprang has a new post to his site with some of his thoughts on why software estimates are impossible in any realistic project development process.

When you, as a programmer, start a new project, you will often not know full well how to do it, for many reasons. But you are a professional, and you’ve completed similar tasks in the past, so you either try to figure it out, or find someone who can, and ask them how, or just google it.

[...] The problem comes down to the difference between tasks which require a lot of thinking, and routine tasks which you already have some practice with.

He gives an example of solving a Rubik’s cube, how most people take a very long time to figure it out but there are some that can do it in a matter of seconds. He talks about unexpected complexity and how that can blow previous estimates out of the water. He points out that complexity can be cumulative (related to the number of tasks) and the difference between creative and mechanical tasks.

In a recent post to his site Mikkel Høgh makes the suggestion that Drupal is still a gated community, mostly as it relates to the process around the "Project Applications" process.

One of the things the Drupal community prides itself on, is how open the community is. And that is generally true, but there's one exception. And that is the Kafkaesque horror-show we subject any newcomers that would like to publish their code on Drupal.org to. It goes by the name of “Project Applications“. I know several people who've hit this wall when trying to contribute code. It's not uncommon to wait several months to get someone to review your code. And when it does happen, people are often rejected for tiny code style issues, like not ending their comments with a period or similar.

He talks about other factors involving reviews and delays that can also cause authors to abandon their work and feel "unwelcome and unappreciated". He mentions the "review bonus" system and how it's used to encourage participation (or "more hoops" as he puts it) from other authors. He notes that this situation mostly relates to those new to the tool and community and suggests that it just doesn't work (and really is unnecessary). He ends the post with a call to "end the madness" and move to a standardized role that would allow developers to publish without pushing people away and making them feel unwelcome.

The SitePoint PHP blog has posted the second part of their IronMQ and Laravel series, part 3: IronMQ and Laravel: Delays and Retries. In this latest post Rajiv Seelam looks at how to get the Laravel-based application to overcome some of the limitations of the system.

Previously, we saw how to use Iron push queues with Laravel. All we needed to do was set up an Iron account, add a subscriber URL, push a message to queue, and receive the message. The way Laravel supports Iron push queues out-of-the-box is amazing, but there are always limitations. In this article we focus on those limitations and learn to tackle them.

He briefly talks about the three different scenarios: the happy path where everything works, the job fails and the job being a long running process. He then walks you through code that covers each of these scenarios using subscribers and the IronMQ PHP library for successful handling. He shows the push of a message then how to handle delays and retries, defining them in the job configuration.

Paul Reinheimer had a problem - when he was making asynchronous requests back to his server from his frontend (Ajax) there was a slowness he noticed when more than one connection was fired off. In this new post to his site he traces through how he found the answer and what he did to fix it.

Digging a little deeper into the queries being executed, I was expecting return times in the order of 200ms, not the several seconds I was seeing. Installing XHGui only furthered my confusion: session_start() was the culprit with incredibly high run times.

He thought first about the number of session files (stored locally) being too large and causing issues, but that turned out to be a false lead. Instead, the issue was something PHP does by default...and does correctly. When PHP executes, it locks the session file, preventing another process from writing to it. This caused the delay he saw until it was unlocked. His solution? Use session_write_close immediately after writing information to unlock the session for further use.

By now everyone's heard about one of the more powerful and major advancements made in the PHP 5.3.x series of the language - closures. You might have read a description of them and been left wondering what a practical application might be to help drive the point home. Vance Lucas has written up a post to help with just that.

If you’re like me, you might be wondering what the practical uses for these new features are before you can rightly justify diving in and using them in new or existing projects. I experimented a lot with closures and possible uses over the past few weeks, and came up with some compelling reasons to start using them.

He's come up with five different examples of how you can use this handy feature:

• Templating
• Dynamic Code Extension
• Delayed Execution
• Caching
• Convenience (as in their role in one-off functions for callbacks)

Each of the tips comes with a bit of code (except delayed execution, that's a bit more involved) to help explain the point a bit more.

Derick Rethans has posted the third part of his series looking at the garbage collection handling in PHP (the first two parts are here: one, two). In this last part of the series, he'll look at some of the possible performance impacts the garbage collection functionality can have in your applications.

In the previous two parts of this column we have explored PHP's take on circular referenced variables and a mechanism that allows to clean up this particular problem with reference counted variable tracking. Of course, the implementation of the garbage collection mechanism in PHP 5.3 has some performance impacts. In this third and last part of the column I will cover the performance implications of the addition of this garbage collection mechanism.

He looks at the two possible places that the collection could have an impact - memory usage and run-time delays when the garbage collection routine is fired off and does its job. As before, each of the topics is accompanied by bits of code and a few graphs showing the differences between handling in PHP 5.2 and PHP 5.3 as well as a handy way to get a bit more information out of PHP (using the GC_BENCH CFLAG when compiling). ,/p>

As Lukas Smith mentions in his latest post to his blog, the release of PHP 5.3 that was originally slated for today has been put off just a bit longer.

It almost happened, but it didn't for now. Originally we planned to release today. But again a few issues came up, even with Johannes deciding that sleep is for the weak, it just seemed unwise to announce the release today. So we pushed things back a few days, so the new date is June 30th (meaning it will be a Tuesday release).

We'll announce this as soon as its posted as stable to the PHP.net website, so keep an eye out on Tuesday for this greatly anticipated release!