The SitePoint PHP blog has a tutorial posted giving you a crash course on the Wunderlist API and using Guzzle to connect with it. Wunderlist is a task-tracking, to-do list kind of application with support for multiple platforms and, for developers, a nice and relatively easy to use API.

Wunderlist is one of the most popular task management and list keeping applications out there. It allows you to create lists to which you can then add tasks that are easily checkable and have all sorts of functionality built into them. It has native apps for all the major OS’s and all your data syncs effectively over the cloud. It’s very nice to work with if you are trying to keep yourself organized and you can get a lot done even with the free version.

They've posted the final product in a demo repository but they still walk you through the whole process of setting up a simple application that can get, submit and update data via the API:

• Creating the Wunderlist class (a HTTP client)
• Returning data using the Wunderlist API
• Creating and updating data with the Wunderlist API

They also talk a bit more about the OAuth flow the API uses for authentication and points out that the repository also includes a bit more functionality allowing you to get a list and mark the items as complete with a little Ajax.

DZone.com has posted the second part of a two-part series looking at increasing the performance of your PHP applications (part one is here). In this new post, he looks at a few topics including caching, session handling and asynchronous processing with Resque and Redis.

Ultimately, scalability is about the entire architecture, not some minor code optimizations. Often times people get this wrong and naively think they should focus on the edge cases. Solid architectural decisions like doing blocking work in the background via tasks, proactively caching expensive calls, and using a reverse proxy cache will get you much further than arguing about single quotes or double quotes.

He briefly recaps some of the "core principles" for optimizing applications and gets right into explaining the later ones on the list:

• Optimize sessions through memcached handling
• HTTP request/response caching
• Caching Doctrine result sets
• Caching the web service responses made with Guzzle
• Handling asynchronous processing with Resque and Redis

He includes code and configuration examples for each item, helping to flesh them out a bit more. He also makes a recommendation of using something like AppDynamics to monitor the performance of your application (disclaimer: he works for them).

In a recent post to DZone.com Dustin Whittle talks about performance in PHP applications and gives you a crash course on some of the basics around it (this is part one of a series).

We all know performance is important, but performance tuning is too often an afterthought. As a result, taking on a performance tuning project for a slow application can be pretty intimidating – where do you even begin? In this series I’ll tell you about the strategies and technologies that (in my experience) have been the most successful in improving PHP performance. To start off, however, we’ll talk about some of the easy wins in PHP performance tuning. These are the things you can do that’ll get you the most performance bang for your buck, and you should be sure you’ve checked off all of them before you take on any of the more complex stuff.

He talks some about why performance matters and some of the more common practices to introduce immediate performance improvements into your application. His list includes things like: update PHP, use an opcode cache, use autoloading and session optimization. He also talks about using processing queues for blocking work and learning how to use code profiling tools to find the pain points.

On the main PHP site there's a new announcement about a critical update in a new version to both the PHP 5.2.x and 5.3.x series of releases to correct a problem that could cause a hang or crash from user input - 5.3.5 and 5.2.17.

The PHP development team would like to announce the immediate availability of PHP 5.3.5 and 5.2.17. This release resolves a critical issue, reported as PHP bug #53632 and CVE-2010-4645, where conversions from string to double might cause the PHP interpreter to hang on systems using x87 FPU registers. The problem is known to only affect x86 32-bit PHP processes, regardless of whether the system hosting PHP is 32-bit or 64-bit. You can test whether your system is affected by running this script from the command line.

All users are strongly encouraged to update their releases. While the problem only happens in certain circumstances, it can still be a huge problem since the data comes directly from the user. For more information about the issue see this post.

As reported by both The Register and Zend, there's a new remote exploit bug that possibly has something to do with the way 32-bit processors handle floating point numbers.

From Zend:

Due to the way the PHP runtime handles internal conversion of floating point numbers, it is possible for a remote attacker to bring down a web application simply by adding a specific parameter to a query string in their web browser.

The bug, found here on bugs.php.net, has been reproduced on Windows and 32-bit linux systems and can cause the server hang and/or crash as a result. The real issue comes from this bug on the x87 FPU design. The bug has already been fixed in the latest SVN versions (including 5.2 that was end-of-life recently). A release to fix the issue should be coming shortly.

On his IIS.net blog Don Raman is asking for help in testing Microsoft's WinCache caching tool because of a critical fix they had to make to the current version.

There has been several instances where people using WINCACHE have reported problem while running it on the actual production server. They have complained that WINCACHE works very well on development server but the users can see a crash (or different symptoms of it) while actually deploying it on a live production server.

There have been several reports of the issue where the site visitor gets an empty page back and WinCache will crash. For those wanting to get into the technical details, the post includes them or, if you just want to find out more about the bug, there's a few email addresses you can contact the WinCache team at.

On the Ibuildings techPortal blog today there's a new article (a case study of sorts) on how to survive a plane crash. More specifically, a look at how the NU.nl news website handled the load as a result of the crash of a Turkish Airliner.

On February 25th, 2009, less than 90 days after the new infrastructure was rolled out, it was stress tested when a Turkish Airliner crashed at Schiphol. On that day the new site set a single day traffic record by serving up 21 million page views in a 24 hour time period, all without any noticeable slowdown and without having to bring additional hardware online to handle the additional load.

Their framework of choice, CodeIgniter, allowed then to create snippets of content - cached versions - that could be pulled and displayed without having to render them every single time. They looked into the Varnish project and a ATK-based CMS to piece it all back together.

Stefan Esser has released the latest version of his Suhosin security patch for PHP:

Yesterday I released Suhosin 0.9.17 in response to a bug report by Ilia Alshanetsky and some crash problems with PHP 4 that were reported during the last weeks.

The issue dealt with a method to "bypass the hard_memory_limit of Suhosin due to a bug in PHP" that could result in memory consumption up into the gigabyte range for a single script. The patch takes care of the issue by not allowing negative memory_limit settings, preventing the problem from happening.

Stefan Esser has released the latest version of his Suhosin security patch for PHP:

Yesterday I released Suhosin 0.9.17 in response to a bug report by Ilia Alshanetsky and some crash problems with PHP 4 that were reported during the last weeks.

The issue dealt with a method to "bypass the hard_memory_limit of Suhosin due to a bug in PHP" that could result in memory consumption up into the gigabyte range for a single script. The patch takes care of the issue by not allowing negative memory_limit settings, preventing the problem from happening.

The PHP group has released the latest version of the PHP 4.4.x series today - PHP 4.4.6:

The PHP development team would like to announce the immediate availability of PHP 4.4.6. The main issue that this release addresses is a crash problem that was introduced in PHP 4.4.5. The problem occurs when session variables are used while register_globals is enabled. Details about the PHP 4.4.6 release can be found in the release announcement for 4.4.6, the full list of changes is available in the ChangeLog for PHP 4.

Head on over to your local downloads page to get this new release in either:

• tar.bz2 format
• tar.gz format
• Windows binaries